From nobody Tue Jul 1 02:36: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 AD6A11A0015 for ; Tue, 1 Jul 2014 02:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 nROd1LEi01pz for ; Tue, 1 Jul 2014 02:36:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7D21A0010 for ; Tue, 1 Jul 2014 02:36:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL34889; Tue, 01 Jul 2014 09:35:59 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 10:35:58 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 17:35:53 +0800 From: Weixinpeng To: "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-re-classification. Thread-Index: Ac+VD9i/qBf4Di3iQFaoodULuL/J0g== Date: Tue, 1 Jul 2014 09:35:52 +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.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81A48Bnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CjDitTAKDxGXI0jsx6dzEHqbKHA Subject: [sfc] A new draft-wei-sfc-re-classification. X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 01 Jul 2014 09:36:03 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81A48Bnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A new draft on re-classification for SFC is submitted. Comments are welcome= d. Best Regards, Xinpeng Name: draft-wei-sfc-re-classification Revision: 00 Title: Re-classification analysis in SFC Document date: 2014-06-30 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-re-classi= fication-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-re-classific= ation/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-re-classification-= 00 Abstract: Service Function Chaining (SFC) provides the ability to classify and steer a flow via some network service(s). Some traffic flows require re-classification to a new service chain. This may be, for example, the result of further analysis of initial packets, or detection of multiple types of media. This document discusses re-classification scenarios in SFC, and several deployment models for the re-classifier and relevant analysis are provided. The proposal will recommend some architectural constraints for the SFC design. --_000_C5C3BB522B1DDF478AA09545169155B46D81A48Bnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

A new draft on re-classifica= tion for SFC is submitted. Comments are welcomed.

 

Best Regards,

Xinpeng

 

 

Name:    = ;           draft-wei-sfc= -re-classification

Revision:  00

Title:   &nbs= p;            &= nbsp; Re-classification analysis in SFC

Document date:  &n= bsp;    2014-06-30

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           10

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-sfc-re-classification-00.txt<= /a>

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-sfc-re-classification/<= /o:p>

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-sfc-re-classification-00

 

 

Abstract:<= /p>

   Service Functio= n Chaining (SFC) provides the ability to classify and

   steer a flow vi= a some network service(s). Some traffic flows require

   re-classificati= on to a new service chain. This may be, for example,

   the result of f= urther analysis of initial packets, or detection of

   multiple types = of media. This document discusses re-classification

   scenarios in SF= C, and several deployment models for the re-classifier

   and relevant an= alysis are provided. The proposal will recommend some

   architectural c= onstraints for the SFC design.

 

--_000_C5C3BB522B1DDF478AA09545169155B46D81A48Bnkgeml507mbxchi_-- From nobody Tue Jul 1 02:44: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 7C29D1A0016 for ; Tue, 1 Jul 2014 02:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 NE1fcIMlj30F for ; Tue, 1 Jul 2014 02:44:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BAC1A0015 for ; Tue, 1 Jul 2014 02:44:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGR14523; Tue, 01 Jul 2014 09:44:12 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 10:44:11 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 17:44:08 +0800 From: Weixinpeng To: "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjg== Date: Tue, 1 Jul 2014 09:44:07 +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.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81A4DFnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qj9HWZRqAzXnEPICst9nYqmnES0 Subject: [sfc] A new draft-wei-sfc-mobile-consideration-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, 01 Jul 2014 09:44:15 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81A4DFnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. --_000_C5C3BB522B1DDF478AA09545169155B46D81A4DFnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

A new draft on Interaction b= etween SFC network and 3GPP network has been submitted. Comments are welcom= ed!

 

Best Regards,

Xinpeng

 

 

Name:    = ;           draft-wei-sfc= -mobile-consideration-00

Revision:  00

Title:   &nbs= p;            &= nbsp; Interaction between SFC network and 3GPP network

Document date:  &n= bsp;    2014-06-30

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           7=

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:<= /p>

   This document p= rovides a discussion of how SFC (Service Function

   Chain) domain c= ould interact with carrier network to provide network

   service for tra= ffic. Here LTE (Long Term Evolution) network is used

   as an example o= f carrier network for discussion.

 

--_000_C5C3BB522B1DDF478AA09545169155B46D81A4DFnkgeml507mbxchi_-- From nobody Tue Jul 1 03:55: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 6A2591A0032 for ; Tue, 1 Jul 2014 03:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 23YFGC_NTluQ for ; Tue, 1 Jul 2014 03:55:16 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 097DB1A002B for ; Tue, 1 Jul 2014 03:55:14 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Tue, 01 Jul 2014 13:55:12 +0300 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, 1 Jul 2014 13:55:51 +0300 From: Alla Goldner To: Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7Q Date: Tue, 1 Jul 2014 10:55:51 +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: [37.142.232.97] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XMk1A93WV6cztNmgvp6N7ti0-v4 Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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, 01 Jul 2014 10:55:19 -0000 --_004_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very impor= tant, in my view, to show TDF (Traffic detection Function) as a Network E= lement residing on SGi as this element may function as a Traffic Classifi= er (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-c= ase-mobility/ ) 2. It should be clarified whether LSFC or PSFC includes the order o= f Service Functions to become parts of service chain. I would think that = LSFC should not only include a list, but also the order of SFs to be appl= ied. Then PSFC may handle physical routing. 3. "Besides LSFC, additional information such as subscriber ID, tha= t might be used but could not be accessed directly by SFC domain, will al= so be conveyed in service chain request procedure". I don't think this is= =20correct and believe that subscriber ID etc. should be leveraged and us= ed as an input for making LSFC decision by 3GPP network but not be convey= ed further to SFC domain (which is in line, by the way, with your followi= ng statement on sorts of information that could be used in creating of L= SFC". 4. With regard to sorts of information that could be used in creati= ng of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobi= le Service Steering (FMSS)". Please let me know if you have any questions or comments for my comments.= =20I would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been = submitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-= consideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-con= sideration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considera= tion-00 Abstract: =20 This document provides a discussion of how SFC (Service Function =20 Chain) domain could interact with carrier network to provide network= =20 service for traffic. Here LTE (Long Term Evolution) network is used =20 as an example of carrier network for discussion. #########################################################################= ##################### 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. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Dea= r Xinpeng,

 

Tha= nks for providing this Draft!

 

I h= ave the following comments:

 

1.       For the Figure 2 Basic LTE network architec= ture it is very important, in my view, to show TDF (Traffic detection Fun= ction) as a Network Element residing on SGi =20as this element may function as a Traffic Classifier (please also see = https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )<= o:p>

2.       It should be clarified whether LSFC or PSFC= =20includes the order of Service Functions to become parts of service cha= in. I would think that LSFC should not only =20include a list, but also the order of SFs to be applied. Then PSFC may= =20handle physical routing.

3.       "Besides LSFC, additional information = such as subscriber ID, that might be used but could not be accessed direc= tly by SFC domain, will also be conveyed in service =20chain request procedure". I don't think this is correct and belie= ve that subscriber ID etc. should be leveraged and used as an input for m= aking LSFC decision by 3GPP network but not be conveyed further to SFC do= main (which is in line, by the way, with your =20following statement on  sorts of information that could be used i= n creating of LSFC".

4.       With regard to sorts of information that co= uld be used in creating of LSFC, I suggest to reference 3GPP TR 22.808 &q= uot;Study on Flexible Mobile Service Steering (FMSS)".

 

Ple= ase let me know if you have any questions or comments for my comments. I = would be happy to work with you on resolving those.

=

 

Bes= t 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

&nb= sp;

3D"2=

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi a= ll,

A ne= w draft on Interaction between SFC network and 3GPP network has been subm= itted. Comments are welcomed!

 

Best= =20Regards,

Xinp= eng

 

 

Name= :            =    draft-wei-sfc-mobile-consideration-00

Revi= sion:  00

Titl= e:            = ;      Interaction between SFC network and 3GPP = network

Docu= ment date:       2014-06-30

Grou= p:            = ;   Individual Submission

Page= s:            = ;   7

URL:=             http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00= .txt

Stat= us:         https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/<= o:p>

Html= ized:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00=

 

 

Abst= ract:

&nbs= p;  This document provides a discussion of how SFC (Service Function=

&nbs= p;  Chain) domain could interact with carrier network to provide net= work

&nbs= p;  service for traffic. Here LTE (Long Term Evolution) network is u= sed

&nbs= p;  as an example of carrier network for discussion.

&n= bsp;

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Tue, 01 Jul 2014 10:55:51 GMT"; modification-date="Tue, 01 Jul 2014 10:55:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA70479349AFEA2LIONALLOTLOCAL_-- From nobody Tue Jul 1 20:13: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 5F6BC1A0A86 for ; Tue, 1 Jul 2014 20:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 06OSzQ5VU4pe for ; Tue, 1 Jul 2014 20:13:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A911A03CC for ; Tue, 1 Jul 2014 20:13:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGR79887; Wed, 02 Jul 2014 03:13:21 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 04:13:20 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 11:13:16 +0800 From: Weixinpeng To: Alla Goldner , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnA= Date: Wed, 2 Jul 2014 03:13:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/related; boundary="_004_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UTPAg0Gt76O2F9Pzn0kpTnYOHD0 Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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, 02 Jul 2014 03:13:27 -0000 --_004_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_ Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_" --_000_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alla, Thanks for your comments! And I am glad to work together with you on this = topic. And please see my comments inline. Best Regards, Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very importa= nt, in my view, to show TDF (Traffic detection Function) as a Network Eleme= nt residing on SGi as this element may function as a Traffic Classifier (pl= ease also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobi= lity/ ) [Wei] In the current version, this draft only provide a high level discussi= on on the interaction between 3GPP network and SFC domain, and more detaile= d discussion will be included in the following version. Figure2 is a brief = introduction about LTE network to show the relationship between LTE network= and IP networks , so things like PCC architecture including TDF is not inv= olved here. 2. It should be clarified whether LSFC or PSFC includes the order of = Service Functions to become parts of service chain. I would think that LSFC= should not only include a list, but also the order of SFs to be applied. T= hen PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC, n= ot just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, that = might be used but could not be accessed directly by SFC domain, will also b= e conveyed in service chain request procedure". I don't think this is corre= ct and believe that subscriber ID etc. should be leveraged and used as an i= nput for making LSFC decision by 3GPP network but not be conveyed further t= o SFC domain (which is in line, by the way, with your following statement o= n sorts of information that could be used in creating of LSFC". [Wei] Subscriber ID is provided as example of additional information, besid= es match rule and LSFC, that might be conveyed to SFC domain, some other in= formation could also be conveyed depending on specific SF(s) included in LS= FC. For example, Subscriber ID will be used by SF that implements HTTP head= er enrichment. I think we can go more deep on discussion for this issue. 4. With regard to sorts of information that could be used in creating= of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobile S= ervice Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments. I= would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ --_000_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alla= ,

Thanks = for your comments!  And I am glad to work together with you on this to= pic.

And ple= ase see my comments inline.

&n= bsp;

Best Re= gards,

Xinpeng=

From: Alla Goldner= [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 

Dear Xinpeng,

 

Thanks for providing this Draft!

 

I have the following comments:

 

1.       For the Figure 2 Basic LTE network architecture it is ver= y important, in my view, to show TDF (Traffic detection Function) as a Netw= ork Element residing on SGi as this element may function as a Traffic Classifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )

[= Wei] In the current version, this draft only provide a high level discussio= n on the interaction between 3GPP network and SFC domain, and more detailed= discussion will be included in the following version. Figure2 is a brief introduction about LTE network to show the rel= ationship between LTE network and IP networks , so things like PCC architec= ture including TDF is not involved  here.

2.       It should be clarified whether LSFC or PSFC includes the = order of Service Functions to become parts of service chain. I would think = that LSFC should not only include a list, but also the order of SFs to be applied. Then PSFC may handle physic= al routing.

[= Wei] Right, the order of SFs should be specified for both LSFC and PSFC, no= t just a list of them.

3.       "Besides LSFC, additional information such as subscr= iber ID, that might be used but could not be accessed directly by SFC domai= n, will also be conveyed in service chain request procedure". I don't think this is correct and believe that su= bscriber ID etc. should be leveraged and used as an input for making LSFC d= ecision by 3GPP network but not be conveyed further to SFC domain (which is= in line, by the way, with your following statement on  sorts of information that could be used in creating of = LSFC".

[= Wei] Subscriber ID is provided as example of additional information, beside= s match rule and LSFC, that might be conveyed to SFC domain, some other inf= ormation could also be conveyed depending on specific SF(s) included in LSFC. For example, Subscriber ID will be use= d by SF that implements HTTP header enrichment. I think we can go more deep= on discussion for this issue.

&n= bsp;

4.       With regard to sorts of information that could be used in= creating of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Fle= xible Mobile Service Steering (FMSS)".

[= Wei] Ok, thanks for providing this information.

 

Please let me know if you have any questions or comments for my c= omments. I would be happy to work with you on resolving those.

 

Best regards,

 

<= o:p> 

Alla Goldner

Director of Mobile Technologies and St= andards

Allot Communications

Tel +972 9 7619251<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Times New R= oman","serif";color:#004A8E">

Cell +972 54 2493985

Fax +972 9 7443626<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Times New R= oman","serif";color:#004A8E">

= agoldner@allot.com

www.allot.com

 

=3D"291X55_signature

<= o:p> 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 

Hi all,

A new draft on Interaction b= etween SFC network and 3GPP network has been submitted. Comments are welcom= ed!

 

Best Regards,

Xinpeng

 

 

Name:    = ;           draft-wei-sfc= -mobile-consideration-00

Revision:  00

Title:   &nbs= p;            &= nbsp; Interaction between SFC network and 3GPP network

Document date:  &n= bsp;    2014-06-30

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           7=

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:<= /p>

   This document p= rovides a discussion of how SFC (Service Function

   Chain) domain c= ould interact with carrier network to provide network

   service for tra= ffic. Here LTE (Long Term Evolution) network is used

   as an example o= f carrier network for discussion.

 

This message is intended only for the design= ated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distr= ibute this message. If you have mistakenly received this message, please no= tify the sender by a reply e-mail and delete this message. Thank you.

--_000_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_-- --_004_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Wed, 02 Jul 2014 03:13:15 GMT"; modification-date="Wed, 02 Jul 2014 03:13:15 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_C5C3BB522B1DDF478AA09545169155B46D81A627nkgeml507mbxchi_-- From nobody Tue Jul 1 20:14: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 690551A0400 for ; Tue, 1 Jul 2014 20:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 lH1VjWFXPfMr for ; Tue, 1 Jul 2014 20:14:33 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F131A03CC for ; Tue, 1 Jul 2014 20:14:33 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so11173595pde.38 for ; Tue, 01 Jul 2014 20:14:33 -0700 (PDT) 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=qrbfDWH2OUR1IJ7Hvqj7kvT9aj4c/l0lMddCOBQwojg=; b=b056oshtsn1UvuBf8gMTOz8ClfA6F66kINngrPpxdMrCVl3BEOxVlCNrp/An3vaaNw Kyrsex6zfCvjVUO409xlhhtESmfDRZHbJo3QJyDcFnE9eX1kag5PVi1duqprpr0EnUnS 4KEr0NgllDKZ9JkTFpkwW+urz3DRAt9p41YIeU8O/SZlHvO33DD1qBAyb89MFRkbOqqx iRVT4PMIOylvzUwFOT7pBC0tEfcc9ZM7OFcbtJJDcf7Uza+mJoJMIrkQQgZC114VPWqH iBBFV6QDdqAWNiMjhKmGfBDDhi2Zh59GtfB+deApdLeyODffv3cCBaHC1NQZR1PZxRZE S+ew== X-Received: by 10.69.25.69 with SMTP id io5mr68786011pbd.22.1404270873287; Tue, 01 Jul 2014 20:14:33 -0700 (PDT) Received: from USTC-PC ([202.38.75.80]) by mx.google.com with ESMTPSA id pr8sm34767990pbc.74.2014.07.01.20.14.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Jul 2014 20:14:32 -0700 (PDT) Date: Wed, 2 Jul 2014 11:14:30 +0800 From: "Hong Zhang" To: Weixinpeng References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201407021114287135913@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart620533135768_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Tui_iRjtE9yQ7R_1QRz6CMioEP8 Cc: "sfc@ietf.org" Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mmczhad List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 03:14:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart620533135768_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQogICBJIGhhdmUgcmVhZCB5b3VyIGRyYWZ0ICJkcmFmdC13ZWktc2ZjLW1vYmlsZS1jb25z aWRlcmF0aW9uLTAwIiwgYW5kIEkgdGhpbmsgaXQgaXMgdmVyeSB1c2VmdWwuIEhvd2V2ZXIsIEkg aGF2ZSBhIHF1ZXN0aW9uIHRoYXQsIGluIHRoZSBkcmFmdCwgaXQgaXMgc2FpZCB0aGF0IHRoZSBM VEUgbmV0d29yayBhbmQgU0ZDICBkb21haW4gYXJlIHR3byBzZXBlcmF0ZSBkb21haW5zLiBXaGF0 IEkgd29uZGVyZWQgaXMgdGhhdCB3aGV0aGVyIHRoZSBMVEUgbmV0d29yayBhbmQgU0ZDIGRvbWFp biAgYXJlIGRlcGxveWVkIGluIGRpZmZlcmVudCBuZXR3b3JrIGRvbWFpbnMgb3IgdGhleSAgYXJl IHNlcGFyYXRlZCBpbiBsb2dpYyBhbmQgZGVwbG95ZWQgcGh5c2ljYWxseSBpbiB0aGUgc2FtZSBu ZXR3b3JrIGRvbWFpbi4gDQoNCg0KDQoNCg0KSG9uZyBaaGFuZw0KDQpGcm9tOiBXZWl4aW5wZW5n DQpEYXRlOiAyMDE0LTA3LTAxIDE3OjQ0DQpUbzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2Zj XSBBIG5ldyBkcmFmdC13ZWktc2ZjLW1vYmlsZS1jb25zaWRlcmF0aW9uLTAwLg0KSGkgYWxsLA0K QSBuZXcgZHJhZnQgb24gSW50ZXJhY3Rpb24gYmV0d2VlbiBTRkMgbmV0d29yayBhbmQgM0dQUCBu ZXR3b3JrIGhhcyBiZWVuIHN1Ym1pdHRlZC4gQ29tbWVudHMgYXJlIHdlbGNvbWVkIQ0KIA0KQmVz dCBSZWdhcmRzLA0KWGlucGVuZw0KIA0KIA0KTmFtZTogICAgICAgICAgICAgICBkcmFmdC13ZWkt c2ZjLW1vYmlsZS1jb25zaWRlcmF0aW9uLTAwDQpSZXZpc2lvbjogIDAwDQpUaXRsZTogICAgICAg ICAgICAgICAgICBJbnRlcmFjdGlvbiBiZXR3ZWVuIFNGQyBuZXR3b3JrIGFuZCAzR1BQIG5ldHdv cmsNCkRvY3VtZW50IGRhdGU6ICAgICAgIDIwMTQtMDYtMzANCkdyb3VwOiAgICAgICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgICAgICAgNw0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdlaS1zZmMt bW9iaWxlLWNvbnNpZGVyYXRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2VpLXNmYy1tb2JpbGUtY29uc2lkZXJhdGlvbi8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktc2Zj LW1vYmlsZS1jb25zaWRlcmF0aW9uLTAwDQogDQogDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgcHJvdmlkZXMgYSBkaXNjdXNzaW9uIG9mIGhvdyBTRkMgKFNlcnZpY2UgRnVuY3Rpb24NCiAg IENoYWluKSBkb21haW4gY291bGQgaW50ZXJhY3Qgd2l0aCBjYXJyaWVyIG5ldHdvcmsgdG8gcHJv dmlkZSBuZXR3b3JrDQogICBzZXJ2aWNlIGZvciB0cmFmZmljLiBIZXJlIExURSAoTG9uZyBUZXJt IEV2b2x1dGlvbikgbmV0d29yayBpcyB1c2VkDQogICBhcyBhbiBleGFtcGxlIG9mIGNhcnJpZXIg bmV0d29yayBmb3IgZGlzY3Vzc2lvbi4NCiA= ------=_001_NextPart620533135768_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
   I have read your draft=20 "draft-wei-sfc-mobile-consideration-00", and I think it is very= =20 useful. However, I have a question that, in the draft, it is said that the= LTE=20 network and SFC  domain are two seperate domains. What I wondere= d is=20 that whether the LTE network and SFC domain  are deployed in dif= ferent=20 network domains or they  are separated in logic and deploye= d=20 physically in the same network domain. 
&nb=
sp;
 
Hong Zhang
 
From: Weixinpeng
Date: 2014-07-01 17:44
To: sfc@ietf.org
Subject: [sfc] A new=20 draft-wei-sfc-mobile-consideration-00.

Hi all,

A new draft on Interaction betw= een SFC=20 network and 3GPP network has been submitted. Comments are=20 welcomed!

 

Best Regards,=

Xinpeng

 

 

Name:         &n= bsp;    =20 draft-wei-sfc-mobile-consideration-00

Revision:  00

Title:         &= nbsp;       =20 Interaction between SFC network and 3GPP network

Document=20 date:       2014-06-30

Group:         &= nbsp;    =20 Individual Submission

Pages:         &= nbsp;    =20 7

URL:         &nb= sp; =20 http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-cons= ideration-00.txt

Status:         https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:       = http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00<= /o:p>

 

 

Abstract:

   This document prov= ides a=20 discussion of how SFC (Service Function

   Chain) domain coul= d interact=20 with carrier network to provide network

   service for traffi= c. Here=20 LTE (Long Term Evolution) network is used

   as an example of c= arrier=20 network for discussion.

 

------=_001_NextPart620533135768_=------ From nobody Tue Jul 1 20:39: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 A9B6B1A036F for ; Tue, 1 Jul 2014 20:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fwD977EGATRk for ; Tue, 1 Jul 2014 20:39:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529C31A00B0 for ; Tue, 1 Jul 2014 20:39:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGR81266; Wed, 02 Jul 2014 03:39:31 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 04:39:30 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 11:39:26 +0800 From: Weixinpeng To: mmczhad Thread-Topic: [sfc] A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgAksad5AABvkRA= Date: Wed, 2 Jul 2014 03:39:26 +0000 Message-ID: References: <201407021114287135913@gmail.com> In-Reply-To: <201407021114287135913@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81A653nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/os8LMsc695VxmksedH4ID_NTS8Q Cc: "sfc@ietf.org" Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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, 02 Jul 2014 03:39:35 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81A653nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hong, It's very likely that LTE network and SFC network are deployed by the same = network operator, but functionally they are treated as two separate network= . Just like LTE network and IMS. BR, Xinpeng From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hong Zhang Sent: Wednesday, July 02, 2014 11:15 AM To: Weixinpeng Cc: sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi, I have read your draft "draft-wei-sfc-mobile-consideration-00", and I th= ink it is very useful. However, I have a question that, in the draft, it is= said that the LTE network and SFC domain are two seperate domains. What I= wondered is that whether the LTE network and SFC domain are deployed in d= ifferent network domains or they are separated in logic and deployed physi= cally in the same network domain. ________________________________ Hong Zhang From: Weixinpeng Date: 2014-07-01 17:44 To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. --_000_C5C3BB522B1DDF478AA09545169155B46D81A653nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hong= ,

It̵= 7;s very likely that LTE network and SFC network are deployed by the same n= etwork operator, but functionally they are treated as two separate network.= Just like LTE network and IMS.

&n= bsp;

BR,

Xinpeng=

&n= bsp;

From: sfc [mailto:= sfc-bounces@ietf.org] On Behalf Of Hong Zhang
Sent: Wednesday, July 02, 2014 11:15 AM
To: Weixinpeng
Cc: sfc@ietf.org
Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00.=

 

Hi,

   I have read your draft &q= uot;draft-wei-sfc-mobile-consideration-00", and I think it is very use= ful. However, I have a question that, in the draft, it is said that the LTE network and SFC  domain are two= seperate domains. What I wondered is that whether the LTE network and= SFC domain  are deployed in different network domains or they&nb= sp; are separated in logic and deployed physically in the same network domain. 

 

 

Hong Zhang

 

= From: Weixinpeng

= Date: 2014-07-01 17:44

= To: sfc@ietf.org=

= Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

Hi all= ,

A new = draft on Interaction between SFC network and 3GPP network has been submitte= d. Comments are welcomed!

&= nbsp;

Best R= egards,

Xinpen= g

&= nbsp;

&= nbsp;

Name:&= nbsp;           &nbs= p;  draft-wei-sfc-mobile-consideration-00

Revisi= on:  00

Title:=             &nb= sp;     Interaction between SFC network and 3GPP networ= k

Docume= nt date:       2014-06-30

Group:=             &nb= sp;  Individual Submission

Pages:=             &nb= sp;  7

URL:&n= bsp;           http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status= :         https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmliz= ed:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

&= nbsp;

&= nbsp;

Abstra= ct:

 =   This document provides a discussion of how SFC (Service Function

 =   Chain) domain could interact with carrier network to provide network=

 =   service for traffic. Here LTE (Long Term Evolution) network is used<= o:p>

 =   as an example of carrier network for discussion.

&nbs= p;

--_000_C5C3BB522B1DDF478AA09545169155B46D81A653nkgeml507mbxchi_-- From nobody Tue Jul 1 23:10: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 63DE51B28D0 for ; Tue, 1 Jul 2014 23:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 xSY1UCPP-2wQ for ; Tue, 1 Jul 2014 23:10:16 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 185061B28D7 for ; Tue, 1 Jul 2014 23:09:54 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Wed, 02 Jul 2014 09:09:52 +0300 Received: from LION.ALLOT.LOCAL ([172.20.20.40]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 09:10:31 +0300 From: Alla Goldner To: Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsA== Date: Wed, 2 Jul 2014 06:10:30 +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: [172.17.18.22] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0XWX2WUehe3etlBXqkmxbTkyCho Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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, 02 Jul 2014 06:10:21 -0000 --_004_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Xinpeng, Thanks a lot for your response. And please see some further responses bel= ow. 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 [291X55_signature (2)] From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: Wednesday, July 02, 2014 6:13 AM To: Alla Goldner; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi Alla, Thanks for your comments! And I am glad to work together with you on thi= s topic. And please see my comments inline. Best Regards, Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very impor= tant, in my view, to show TDF (Traffic detection Function) as a Network E= lement residing on SGi as this element may function as a Traffic Classifi= er (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-c= ase-mobility/ ) [Wei] In the current version, this draft only provide a high level discus= sion on the interaction between 3GPP network and SFC domain, and more det= ailed discussion will be included in the following version. Figure2 is a = brief introduction about LTE network to show the relationship between LTE= =20network and IP networks , so things like PCC architecture including TD= F is not involved here. AG> TDF, in this regard, is not only a part of P= CC architecture, but a key entity for service classification with regard = to service chaining functionality. This is why it is very important, in m= y view, to include TDF. 2. It should be clarified whether LSFC or PSFC includes the order o= f Service Functions to become parts of service chain. I would think that = LSFC should not only include a list, but also the order of SFs to be appl= ied. Then PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC,= =20not just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, tha= t might be used but could not be accessed directly by SFC domain, will al= so be conveyed in service chain request procedure". I don't think this is= =20correct and believe that subscriber ID etc. should be leveraged and us= ed as an input for making LSFC decision by 3GPP network but not be convey= ed further to SFC domain (which is in line, by the way, with your followi= ng statement on sorts of information that could be used in creating of L= SFC". [Wei] Subscriber ID is provided as example of additional information, bes= ides match rule and LSFC, that might be conveyed to SFC domain, some othe= r information could also be conveyed depending on specific SF(s) included= =20in LSFC. For example, Subscriber ID will be used by SF that implements= =20HTTP header enrichment. I think we can go more deep on discussion for = this issue. AG> I see your point. In this case a more detailed requiremen= ts may be provided, as these parameters are already available to PGW and = TDF (i.e. service classifiers). 4. With regard to sorts of information that could be used in creati= ng of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobi= le Service Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments.= =20I would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been = submitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-= consideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-con= sideration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considera= tion-00 Abstract: =20 This document provides a discussion of how SFC (Service Function =20 Chain) domain could interact with carrier network to provide network= =20 service for traffic. Here LTE (Long Term Evolution) network is used =20 as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply 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. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Dea= r Xinpeng,

 

Tha= nks a lot for your response. And please see some further responses below.=

 

Bes= t 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

&nb= sp;

3D"2=

 

 

From: Weixinpeng [mailto:weixinpeng@huaw= ei.com]
Sent: Wednesday, July 02, 2014 6:13 AM
To: Alla Goldner; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi Alla,

Thanks for your comments!  And I am glad to work together wit= h you on this topic.

And please see my comments inline.

 

Best Regards,

Xinpeng

From: =20Alla Goldner [mailto:agoldner@al= lot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

 

Dear Xinpeng,

 

Thanks for providing this Draft!

 

I have the following comments:<= /p>

 

1.    =    For the Figure 2= =20Basic LTE network architecture it is very important, in my view, to sh= ow TDF (Traffic detection Function) as a Network =20Element residing on SGi as this element may function as a Traffic Clas= sifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/<= /a> )

[Wei] In the current version, this draft only provide a high= =20level discussion on the interaction between 3GPP network and SFC domai= n, and more detailed discussion will be included =20in the following version. Figure2 is a brief introduction about LTE ne= twork to show the relationship between LTE network and IP networks , so t= hings like PCC architecture including TDF is not involved  here. AG> TDF, in this regard, is not only a part of PCC architecture, but = a key entity for service classification with regard to service chaining f= unctionality. This is why it is very important, =20in my view, to include TDF.

2.    =    It should be cla= rified whether LSFC or PSFC includes the order of Service Functions to be= come parts of service chain. I would think =20that LSFC should not only include a list, but also the order of SFs to= =20be applied. Then PSFC may handle physical routing.

[Wei] Right, the order of SFs should be specified for both L= SFC and PSFC, not just a list of them.

3.    =    "Besides LS= FC, additional information such as subscriber ID, that might be used but = could not be accessed directly by SFC domain, will =20also be conveyed in service chain request procedure". I don't thi= nk this is correct and believe that subscriber ID etc. should be leverage= d and used as an input for making LSFC decision by 3GPP network but not b= e conveyed further to SFC domain (which is in =20line, by the way, with your following statement on  sorts of info= rmation that could be used in creating of LSFC".

[Wei] Subscriber ID is provided as example of additional inf= ormation, besides match rule and LSFC, that might be conveyed to SFC doma= in, some other information could also be conveyed =20depending on specific SF(s) included in LSFC. For example, Subscriber = ID will be used by SF that implements HTTP header enrichment. I think we = can go more deep on discussion for this issue. AG> I see your point. In this case a more detailed requirements may b= e provided, as these parameters are already available to PGW and TDF (i.e= . service classifiers).

 

4.    =    With regard to s= orts of information that could be used in creating of LSFC, I suggest to = reference 3GPP TR 22.808 "Study on Flexible =20Mobile Service Steering (FMSS)".

[Wei] Ok, thanks for providing this information.<= /b>

 

Please let me know if you have any questions or c= omments for my comments. I would be happy to work with you on resolving t= hose.

 

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

&nb= sp;

3D"291X=<= /span>

 

 

From: =20sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 

Hi a= ll,

A ne= w draft on Interaction between SFC network and 3GPP network has been subm= itted. Comments are welcomed!

 

Best= =20Regards,

Xinp= eng

 

 

Name= :            =    draft-wei-sfc-mobile-consideration-00

Revi= sion:  00

Titl= e:            = ;      Interaction between SFC network and 3GPP = network

Docu= ment date:       2014-06-30

Grou= p:            = ;   Individual Submission

Page= s:            = ;   7

URL:=             http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00= .txt

Stat= us:         https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/<= o:p>

Html= ized:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00=

 

 

Abst= ract:

&nbs= p;  This document provides a discussion of how SFC (Service Function=

&nbs= p;  Chain) domain could interact with carrier network to provide net= work

&nbs= p;  service for traffic. Here LTE (Long Term Evolution) network is u= sed

&nbs= p;  as an example of carrier network for discussion.

&n= bsp;

This message is intended on= ly for the designated recipient(s). It may contain confidential or =20proprietary information. If you are not the designated recipient, you = may not review, copy or distribute this message. If you have mistakenly r= eceived this message, please notify the sender by a reply e-mail and dele= te this message. Thank you.

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Wed, 02 Jul 2014 06:10:30 GMT"; modification-date="Wed, 02 Jul 2014 06:10:30 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA70479349B0BBBLIONALLOTLOCAL_-- From nobody Wed Jul 2 10:11: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 3AB431B27D9 for ; Wed, 2 Jul 2014 10:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 1qlg0jyKkgNp for ; Wed, 2 Jul 2014 10:11:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A29B1A039B for ; Wed, 2 Jul 2014 10:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1525; q=dns/txt; s=iport; t=1404321064; x=1405530664; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=nvSn57UpRqS7NSbA7uM5Yg0eKDwXzZVjofkXZZQaMVM=; b=lWf/bxFh7wrEqSbetxYYhz1m5aZqIzMCZOyLVP/0pA03pB5Yw7qfAJtJ AtjhlnjgyfJmdc5d1kEvjb22iyxVo2Lk6NuqF+eYuf8ZwzvNcHsz8ZCht aZfbaTv+XoWdRH9REXjZ/Xa2FM1t85is9FEYCnIrG2LZglHmB11vkuJLb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwPAEQ8tFOtJA2K/2dsb2JhbABagw1SUwerPAEBAQEBAQUBbgGZZQGBBxZ1hAo6NB0BPkIlAgQTCYg5CAWbeao7F4VwiTmEQwWabYFIkkKDQ2yBRA X-IronPort-AV: E=Sophos;i="5.01,589,1400025600"; d="scan'208";a="337105473" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jul 2014 17:11:03 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s62HB2EB003932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jul 2014 17:11:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 12:11:02 -0500 From: "Reinaldo Penno (repenno)" To: "sfc@ietf.org" Thread-Topic: SFC Yang models version 5 Thread-Index: AQHPlhiasMS3Xcw3Ck+LF25W64VF5w== Date: Wed, 2 Jul 2014 17:11:02 +0000 Message-ID: In-Reply-To: <20140702052841.7980.33489.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.2.3.120616 x-originating-ip: [10.21.146.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0pgLj3nzMZCU2qJhz6bxnZ_liwo Subject: [sfc] SFC Yang models version 5 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 02 Jul 2014 17:11:05 -0000 Changes in -05 Changes based on Opendaylight Implementation Testing and Sfc-dev mailing list feedback o Service Node becomes a container for Service Functions. Moved data plane items to SFF. o Fixed Service Function Forwarders into a list so we can have multiple in a system o Fixed Service Function Chain so it becomes a list of lists. o Created RPCs for Service Functions and Service Chain On 7/1/14, 10:28 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-penno-sfc-yang-05.txt >has been successfully submitted by Reinaldo Penno and posted to the >IETF repository. > >Name: draft-penno-sfc-yang >Revision: 05 >Title: Yang Data Model for Service Function Chaining >Document date: 2014-07-01 >Group: Individual Submission >Pages: 22 >URL: =20 >http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-05.txt >Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ >Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-05 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-05 > >Abstract: > This document defines a YANG data model that can be used to configure > and manage Service Function Chains. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Wed Jul 2 12:20: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 0153E1B281A for ; Wed, 2 Jul 2014 12:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 a-sGNnHfTcwc for ; Wed, 2 Jul 2014 12:20:44 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2531A04C8 for ; Wed, 2 Jul 2014 12:20:44 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so10370667qcz.28 for ; Wed, 02 Jul 2014 12:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A12UhsouXfeE6IMsWRiGVcE7fme7nEUr3361hi5iBo0=; b=ng7R2fvtXEi2WDLOXaLyzP4COUJqyJ71gsQ1XADXq2DDRppz5f+izzZyjG8/kZ9ZKV qjnimXqcfKmWdplqpEDkoq40k8ZAkMGiSDdkgZWfbHoE3eMdrohOt9qoyzQ33PKB6xW2 Q5WpWZLciPyTcg4J+x+WrNpBG4Zheo0zOxzRq+RkuUgudI5+aSjlfPXghxMDAcuYIo4X AFH9rgv8FfnoXMPdUFzM2c36WH0nozyebaisPeel/8BBivFTvmcFCGtTGPJTjWPmM8nX TKFdM82M46459nAVCxN0+xOaaWtCIc/1LddREdwDdSjj/0ga4tfh2JMecGS+lw1D2XP/ Uyhg== MIME-Version: 1.0 X-Received: by 10.140.49.194 with SMTP id q60mr74146957qga.7.1404328843680; Wed, 02 Jul 2014 12:20:43 -0700 (PDT) Received: by 10.96.70.106 with HTTP; Wed, 2 Jul 2014 12:20:43 -0700 (PDT) In-Reply-To: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> Date: Wed, 2 Jul 2014 12:20:43 -0700 Message-ID: From: Sam Aldrin To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a1135054ce0277504fd3ac991 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NZYKEP4WzpQ8b7zODHW6sfixsGk Cc: "Carlos Pignataro \(cpignata\)" , "Nobo Akiya \(nobo\)" Subject: [sfc] Fwd: New Version Notification for draft-aldrin-sfc-oam-framework-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, 02 Jul 2014 19:20:46 -0000 --001a1135054ce0277504fd3ac991 Content-Type: text/plain; charset=UTF-8 Hi, We have submitted a new draft for SFC OAM framework. Kindly review the ID and provide your comments. cheers -sam ---------- Forwarded message ---------- From: Date: Wed, Jul 2, 2014 at 12:17 PM Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt To: Nobo Akiya , "Sam K. Aldrin" , Carlos Pignataro A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt has been successfully submitted by Sam K. Aldrin and posted to the IETF repository. Name: draft-aldrin-sfc-oam-framework Revision: 00 Title: Service Function Chaining Operations, Administration and Maintenance Framework Document date: 2014-07-02 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.txt Status: https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/ Htmlized: http://tools.ietf.org/html/draft-aldrin-sfc-oam-framework-00 Abstract: This document provides reference framework for Operations, Administration and Maintenance (OAM) 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 --001a1135054ce0277504fd3ac991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We have submitted a new draft for S= FC OAM framework.
Kindly review the ID and provide your comments.=

cheers
-sam

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Wed, Jul 2, 2014 at 12:17 = PM
Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt=
To: Nobo Akiya <nobo@cisco.com= >, "Sam K. Aldrin" <aldrin.ietf@gmail.com>, Carlos Pignataro <cpignata@cisco.com>



A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt
has been successfully submitted by Sam K. Aldrin and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-aldrin-sfc-oam-framework
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Service Function Chaining Operatio= ns, Administration and Maintenance Framework
Document date: =C2=A02014-07-02
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker= .ietf.org/doc/draft-aldrin-sfc-oam-framework/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/d= raft-aldrin-sfc-oam-framework-00


Abstract:
=C2=A0 =C2=A0This document provides reference framework for Operations,
=C2=A0 =C2=A0Administration and Maintenance (OAM) of Service Function Chain= ing
=C2=A0 =C2=A0(SFC).




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

The IETF Secretariat


--001a1135054ce0277504fd3ac991-- From nobody Wed Jul 2 12:52: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 19E661B2A0F for ; Wed, 2 Jul 2014 12:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.051 X-Spam-Level: X-Spam-Status: No, score=-13.051 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, IXHASH_X1=1.5, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 072UfPhYFcU0 for ; Wed, 2 Jul 2014 12:52:38 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6781B28A7 for ; Wed, 2 Jul 2014 12:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5251; q=dns/txt; s=iport; t=1404330757; x=1405540357; h=from:to:subject:date:message-id:mime-version; bh=lGUEXdZnGMhxUI0lq0H+MFWAU2GAI/ZTSKm2VVbTatA=; b=mfAF7HSptKxNzs0V+6VLMtGyPtFO+z1XyypsUwxa8tWf3vvRM6S/wFPi oDv8JSbY6770Bjkgi6I3Fe7yCafehsXHMWGhZKBRuWe2okocxVCQOYRW8 TlTVo+zqxN8g5uMTN2DCwsZPxgrRmIWQBDXLRapW0xW+lkMwuTBtKksBp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcJAIRhtFOtJV2R/2dsb2JhbABagkZHgSyCbqhPAQEBAQEBBQFuAZl/bhZ1hAqBCwEMQAQwJwSIVY8ojQSPGwacGBeFcIhag1CBUgWWVYQYlAqDQ4FuQg X-IronPort-AV: E=Sophos; i="5.01,590,1400025600"; d="scan'208,217"; a="57843622" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 02 Jul 2014 19:52:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s62JqbK4015377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jul 2014 19:52:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 14:52:36 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Toronto SFC Meeting Agenda Thread-Index: AQHPli8r2R6/zSOUgEqgCTNvSQH7MQ== Date: Wed, 2 Jul 2014 19:52:35 +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.180] Content-Type: multipart/alternative; boundary="_000_CFD9DB372B9D8jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Bq6u5MtZujhr7ky4Zi3upiLirgg Subject: [sfc] Toronto SFC Meeting Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 19:52:40 -0000 --_000_CFD9DB372B9D8jguicharciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 R3JlZXRpbmdzIFdHOg0KDQpPdXIgbWVldGluZyBhdCB0aGUgdXBjb21pbmcgVG9yb250byB2ZW51 ZSBpcyBmYXN0IGFwcHJvYWNoaW5nLiAgQXMgYWx3YXlzLCB0aGUgZ29hbCBvZiB0aGUgbWVldGlu ZyB3aWxsIGJlIHRvIG1ha2UgdGhlIGJlc3QgdXNlIG9mIGxpbWl0ZWQgZmFjZS10by1mYWNlIHRp bWUuDQoNCkN1cnJlbnRseSwgd2UgaGF2ZSBhIG1lZXRpbmcgIHNsb3Qgc2NoZWR1bGVkIGZvciA5 QU0gV2VkbmVzZGF5IG1vcm5pbmcuDQoNCkFzIHdlIGJ1aWxkIHRoZSBtZWV0aW5nIGFnZW5kYSB3 ZSB3ZWxjb21lIHJlcXVlc3RzIGZvciBhZ2VuZGEgdGltZS4gSG93ZXZlciwgdGhlcmUgYXJlIG1h bnkgZHJhZnRzIGFuZCBpdCBpcyBwb3NzaWJsZSAoaWYgbm90IGxpa2VseSkgdGhhdCB3ZSB3aWxs IGJlIHVuYWJsZSB0byBnaXZlIGFsbCBvZiB0aGVtIGFnZW5kYSB0aW1lLiBBcyBhbHdheXMsIHRo ZSBnb2FsIG9mIGEgbWVldGluZyBzbG90IGlzIHRvIGJlc3QgZnVydGhlciB0aGUgd29yayBvZiB0 aGUgV0csIGFuZCB0aGF0IGdlbmVyYWxseSBtZWFucyBmb2N1c3Npbmcgb24ga2V5IGNoYXJ0ZXIg ZGVsaXZlcmFibGVzIGFuZCB0b3BpY3Mgd2l0aCBpbXBvcnRhbnQgb3BlbiBpc3N1ZXMgdG8gcmVz b2x2ZS4gSW4gdGhlIGNhc2Ugb2YgaW5kaXZpZHVhbCBJRHMsIHRoZSBnb2FsIGlzbj90IG5lY2Vz c2FyaWx5IHRvIHByZXNlbnQgd2hhdCBpcyBpbiB0aGUgZHJhZnQgYnV0IHJhdGhlciB0byBoZWxw IHRoZSBXRyBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoZSBJRC4gV2l0aCB0aGF0IGluIG1pbmQs IHdoZW4gbWFraW5nIGFuIGFnZW5kYSByZXF1ZXN0IHBsZWFzZSBjb25zaWRlciB3aGF0IHlvdSB0 aGluayB0aGUgV0cgc2hvdWxkIGRvIHdpdGggaXRzIGNvbnRlbnQuIEZvciBleGFtcGxlOg0KDQog ICogICBEb2VzIHRoZSBkb2N1bWVudCBoYXZlIHVzZWZ1bCBjb250ZW50IHRoYXQgc2hvdWxkIGJl IG1vdmVkIGludG8gYW5vdGhlciBXRyBkb2N1bWVudCBvciBwcm9ncmVzcyBvbiBpdKGvcyBvd24g bWVyaXQNCiAgKiAgIERvZXMgdGhlIGNvbnRlbnQgaGF2ZSBhIGdvb2QgYmFzaXMgZm9yIG9uZSBv ZiB0aGUgV0cgZG9jdW1lbnRzIHBlciB0aGUgY2hhcnRlciAoaW4gb3JkZXIgZm9yIHRoYXQgdG8g aGFwcGVuIHRoZSBkb2N1bWVudCBuZWVkcyB0byBiZSB0aGUgbW9zdCBhcHByb3ByaWF0ZSBvdXQg b2YgdGhlIGNvbGxlY3Rpb24gb2YgcmVsYXRlZCBkb2N1bWVudHMpDQogICogICBTaG91bGQgdGhl IGRvY3VtZW50IGNvbnRlbnQgYmUgbWVyZ2VkIHdpdGggb25lIG9yIG1vcmUgb3RoZXIgZG9jdW1l bnRzLCBzbyB0aGF0IGEgY29tYmluZWQgZG9jdW1lbnQgY291bGQgYmVjb21lIGEgV0cgZG9jdW1l bnQNCg0KSmltICYgVGhvbWFzDQo= --_000_CFD9DB372B9D8jguicharciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <28AF1C65E218454C8C2CEB901F857B4B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5H cmVldGluZ3MgV0c6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij5PdXIgbWVldGluZyBhdCB0aGUgdXBjb21pbmcgVG9yb250byB2ZW51ZSBp cyBmYXN0IGFwcHJvYWNoaW5nLiAmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07 Ij5BcyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07Ij5hbHdheXMs IHRoZSBnb2FsIG9mIHRoZSBtZWV0aW5nIHdpbGwgYmUgdG8gbWFrZSB0aGUgYmVzdCB1c2Ugb2Ym bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogbWVkaXVtOyI+bGltaXRlZA0KIGZh Y2UtdG8tZmFjZSB0aW1lLjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6IG1lZGl1bTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07 Ij5DdXJyZW50bHksIHdlIGhhdmUgYSBtZWV0aW5nJm5ic3A7Jm5ic3A7c2xvdCBzY2hlZHVsZWQg Zm9yIDlBTSBXZWRuZXNkYXkgbW9ybmluZy48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog bWVkaXVtOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IG1lZGl1bTsiPkFz IHdlIGJ1aWxkIHRoZSBtZWV0aW5nIGFnZW5kYSB3ZSB3ZWxjb21lIHJlcXVlc3RzIGZvciBhZ2Vu ZGEgdGltZS4gSG93ZXZlciwgdGhlcmUgYXJlIG1hbnkgZHJhZnRzIGFuZCBpdCBpcyBwb3NzaWJs ZSAoaWYgbm90IGxpa2VseSkgdGhhdCB3ZSB3aWxsIGJlIHVuYWJsZSB0byBnaXZlIGFsbCBvZiB0 aGVtIGFnZW5kYSB0aW1lLiBBcyBhbHdheXMsIHRoZSBnb2FsIG9mIGEgbWVldGluZyBzbG90DQog aXMgdG8gYmVzdCBmdXJ0aGVyIHRoZSB3b3JrIG9mIHRoZSBXRywgYW5kIHRoYXQgZ2VuZXJhbGx5 IG1lYW5zIGZvY3Vzc2luZyBvbiBrZXkgY2hhcnRlciBkZWxpdmVyYWJsZXMgYW5kIHRvcGljcyB3 aXRoIGltcG9ydGFudCBvcGVuIGlzc3VlcyB0byByZXNvbHZlLiBJbiB0aGUgY2FzZSBvZiBpbmRp dmlkdWFsIElEcywgdGhlIGdvYWwgaXNuP3QgbmVjZXNzYXJpbHkgdG8gcHJlc2VudCB3aGF0IGlz IGluIHRoZSBkcmFmdCBidXQgcmF0aGVyIHRvDQogaGVscCB0aGUgV0cgZGVjaWRlIHdoYXQgdG8g ZG8gd2l0aCB0aGUgSUQuIFdpdGggdGhhdCBpbiBtaW5kLCB3aGVuIG1ha2luZyBhbiBhZ2VuZGEg cmVxdWVzdCBwbGVhc2UgY29uc2lkZXIgd2hhdCB5b3UgdGhpbmsgdGhlIFdHIHNob3VsZCBkbyB3 aXRoIGl0cyBjb250ZW50LiBGb3IgZXhhbXBsZTo8L2Rpdj4NCjx1bD4NCjxsaT5Eb2VzIHRoZSBk b2N1bWVudCBoYXZlIHVzZWZ1bCBjb250ZW50IHRoYXQgc2hvdWxkIGJlIG1vdmVkIGludG8gYW5v dGhlciBXRyBkb2N1bWVudCBvciBwcm9ncmVzcyBvbiBpdKGvcyBvd24gbWVyaXQ8L2xpPjxsaT5E b2VzIHRoZSBjb250ZW50IGhhdmUgYSBnb29kIGJhc2lzIGZvciBvbmUgb2YgdGhlIFdHIGRvY3Vt ZW50cyBwZXIgdGhlIGNoYXJ0ZXIgKGluIG9yZGVyIGZvciB0aGF0IHRvIGhhcHBlbiB0aGUgZG9j dW1lbnQgbmVlZHMgdG8gYmUgdGhlIG1vc3QgYXBwcm9wcmlhdGUgb3V0IG9mIHRoZSBjb2xsZWN0 aW9uIG9mIHJlbGF0ZWQgZG9jdW1lbnRzKTwvbGk+PGxpPlNob3VsZCB0aGUgZG9jdW1lbnQgY29u dGVudCBiZSBtZXJnZWQgd2l0aCBvbmUgb3IgbW9yZSBvdGhlciBkb2N1bWVudHMsIHNvIHRoYXQg YSBjb21iaW5lZCBkb2N1bWVudCBjb3VsZCBiZWNvbWUgYSBXRyBkb2N1bWVudDwvbGk+PC91bD4N CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogbWVkaXVtOyI+SmltICZhbXA7IFRob21hczwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CFD9DB372B9D8jguicharciscocom_-- From nobody Wed Jul 2 16:29: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 4BE561A0ABD for ; Wed, 2 Jul 2014 16:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 mEO5aIgmgyhX for ; Wed, 2 Jul 2014 16:29:01 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9A81A03FD for ; Wed, 2 Jul 2014 16:29:01 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s62NPlj7012950; Wed, 2 Jul 2014 19:28:54 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0a-00103a01.pphosted.com with ESMTP id 1mvrxk8c63-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 02 Jul 2014 19:28:53 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 2 Jul 2014 19:28:52 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 2 Jul 2014 19:28:51 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 2 Jul 2014 19:28:51 -0400 From: "He, Peng" To: "sfc@ietf.org" Date: Wed, 2 Jul 2014 19:28:49 -0400 Thread-Topic: New Version Notification for draft-huang-sfc-use-case-recursive-service-00.txt Thread-Index: Ac+WO+YX3pQ+EW4nRd+JfoL3eT4aewAEMjMg Message-ID: References: <20140702211156.1466.90564.idtracker@ietfa.amsl.com> <53B4794A.10706@sce.carleton.ca> In-Reply-To: <53B4794A.10706@sce.carleton.ca> 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_B6D287BF58D35D4B882E012AD3E1756172C8FC6FONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-02_07:2014-07-02,2014-07-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407020240 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CpS3WTWUivlgkER5NYXqEQoatE0 Cc: Jiafeng Zhu , "huang@sce.carleton.ca" Subject: [sfc] FW: New Version Notification for draft-huang-sfc-use-case-recursive-service-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, 02 Jul 2014 23:29:03 -0000 --_000_B6D287BF58D35D4B882E012AD3E1756172C8FC6FONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyBhbmQgYW5hbHlz aXMgdGhlIHJlY3Vyc2l2ZSAoZS5nLiwgbmVzdGVkKSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5n IHNjZW5hcmlvL3VzZSBjYXNlLCB0byBzZWUgaWYgdGhlIGN1cnJlbnQgZXhpc3RpbmcgdG9vbHMg cHJvcG9zZWQgaW4gdGhlIFdHIGNhbiBjb3Zlci9zdXBwb3J0IHRoaXMgc2NlbmFyaW8sIG9yIHNv bWUgcG90ZW50aWFsIGltcHJvdmVtZW50IG5lZWRlZC4gS2luZGx5IHJldmlldyB0aGUgSUQgYW5k IHByb3ZpZGUgeW91ciBjb21tZW50cyBwbGVhc2UuIFRoYW5rcyBhIGxvdC4NCg0KDQpSZWdhcmRz LA0KUGVuZw0KDQoNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJq ZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXNmYy11c2Ut Y2FzZS1yZWN1cnNpdmUtc2VydmljZS0wMC50eHQNCg0KRGF0ZToNCg0KV2VkLCAwMiBKdWwgMjAx NCAxNDoxMTo1NiAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNCkppYWZlbmcgWmh1IDxqaWFm ZW5nLnpodUBodWF3ZWkuY29tPjxtYWlsdG86amlhZmVuZy56aHVAaHVhd2VpLmNvbT4sIFBlbmcg SGUgPHBoZUBjaWVuYS5jb20+PG1haWx0bzpwaGVAY2llbmEuY29tPiwgSmlhZmVuZyBaaHUgPGpp YWZlbmcuemh1QGh1YXdlaS5jb20+PG1haWx0bzpqaWFmZW5nLnpodUBodWF3ZWkuY29tPiwgQ2hh bmdjaGVuZyBIdWFuZyA8aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxtYWlsdG86aHVhbmdAc2NlLmNh cmxldG9uLmNhPiwgUGVuZyBIZSA8cGhlQGNpZW5hLmNvbT48bWFpbHRvOnBoZUBjaWVuYS5jb20+ LCBDaGFuZ2NoZW5nIEh1YW5nIDxodWFuZ0BzY2UuY2FybGV0b24uY2E+PG1haWx0bzpodWFuZ0Bz Y2UuY2FybGV0b24uY2E+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVhbmct c2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IENoYW5nY2hlbmcgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUNCg0K SUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgZHJhZnQtaHVhbmctc2ZjLXVz ZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlDQoNClJldmlzaW9uOiAgICAgIDAwDQoNClRpdGxlOiAg ICAgICAgIFNGQyBVc2UgQ2FzZXMgb24gUmVjdXJzaXZlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5p bmcNCg0KRG9jdW1lbnQgZGF0ZTogMjAxNC0wNy0wMQ0KDQpHcm91cDogICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAgNw0KDQpVUkw6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNl LXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1z ZXJ2aWNlLw0KDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwDQoNCg0KDQoNCg0KQWJz dHJhY3Q6DQoNCiAgIFNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgKFNGQykgcHJvdmlkZXMgdmFy aW91cyBzZXJ2aWNlcyB0aGF0IGNhbg0KDQogICBiZSB0YWlsb3JlZCB0byBkaWZmZXJlbnQgcmVx dWlyZW1lbnRzIGZyb20gZGl2ZXJzaWZpZWQgdXNlciBncm91cHMsDQoNCiAgIHdoZXJlIGVhY2gg dXNlciBncm91cCBmb3JtcyBhIGNvbGxlY3RpdmUgY2xpZW50IHRoYXQgcmVxdWlyZXMNCg0KICAg c2ltaWxhciBzZXJ2aWNlLiBTRkMgaXMgdHlwaWNhbGx5IGRlcGxveWVkIGFzIGEgc2VydmljZSBv dmVybGF5IHdpdGgNCg0KICAgaXRzIG93biBzZXJ2aWNlIHRvcG9sb2d5IG9uIHRvcCBvZiBleGlz dGluZyBuZXR3b3JrIHRvcG9sb2d5LiBUaGlzDQoNCiAgIGtpbmQgb2YgdmlydHVhbGl6ZWQgc3Ry dWN0dXJlIG5hdHVyYWxseSBlbmFibGVzIHJlY3Vyc2l2ZSBzZXJ2aWNlDQoNCiAgIHJlbGF0aW9u c2hpcCB3aGVyZSBhIGNsaWVudCBtYXkgYmVjb21lIGEgc2VydmljZSBwcm92aWRlciBhbmQgcmVz ZWxsDQoNCiAgIFNGQyBzZXJ2aWNlcyB0byBpdHMgb3duIHVzZXIgZ3JvdXBzLiBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBzb21lDQoNCiAgIGV4ZW1wbGFyeSB1c2UgY2FzZXMgdGhhdCBzaG93IHRo ZSB1c2FnZSBvZiByZWN1cnNpdmUgKGUuZy4gbmVzdGVkKQ0KDQogICBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIHJlbGF0aW9uc2hpcC4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoN Cg== --_000_B6D287BF58D35D4B882E012AD3E1756172C8FC6FONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1V UyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+SGk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz5XZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBk aXNjdXNzIGFuZCBhbmFseXNpcyB0aGUgcmVjdXJzaXZlIChlLmcuLCBuZXN0ZWQpIHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW5pbmcgc2NlbmFyaW8vdXNlIGNhc2UsIHRvIHNlZSBpZiB0aGUgY3VycmVu dCBleGlzdGluZyB0b29scyBwcm9wb3NlZCBpbiB0aGUgV0cgY2FuIGNvdmVyL3N1cHBvcnQgdGhp cyBzY2VuYXJpbywgb3Igc29tZSBwb3RlbnRpYWwgaW1wcm92ZW1lbnQgbmVlZGVkLiBLaW5kbHkg cmV2aWV3IHRoZSBJRCBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRzIHBsZWFzZS4gVGhhbmtzIGEg bG90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3Rl eHQnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6d2luZG93dGV4dCc+UGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+LS0t LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD48dGFibGUgY2xh c3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wPjx0 cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48 cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxi PlN1YmplY3Q6IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4g MGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS0wMC50eHQ8bzpw PjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHls ZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRk IHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPldlZCwg MDIgSnVsIDIwMTQgMTQ6MTE6NTYgLTA3MDA8bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0 ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNs YXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+RnJv bTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD48L3Rk PjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpy aWdodCc+PGI+VG86IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5KaWFmZW5nIFpodSA8YSBocmVmPSJt YWlsdG86amlhZmVuZy56aHVAaHVhd2VpLmNvbSI+Jmx0O2ppYWZlbmcuemh1QGh1YXdlaS5jb20m Z3Q7PC9hPiwgUGVuZyBIZSA8YSBocmVmPSJtYWlsdG86cGhlQGNpZW5hLmNvbSI+Jmx0O3BoZUBj aWVuYS5jb20mZ3Q7PC9hPiwgSmlhZmVuZyBaaHUgPGEgaHJlZj0ibWFpbHRvOmppYWZlbmcuemh1 QGh1YXdlaS5jb20iPiZsdDtqaWFmZW5nLnpodUBodWF3ZWkuY29tJmd0OzwvYT4sIENoYW5nY2hl bmcgSHVhbmcgPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+Jmx0O2h1YW5n QHNjZS5jYXJsZXRvbi5jYSZndDs8L2E+LCBQZW5nIEhlIDxhIGhyZWY9Im1haWx0bzpwaGVAY2ll bmEuY29tIj4mbHQ7cGhlQGNpZW5hLmNvbSZndDs8L2E+LCBDaGFuZ2NoZW5nIEh1YW5nIDxhIGhy ZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPiZsdDtodWFuZ0BzY2UuY2FybGV0b24u Y2EmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw cmU+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNp dmUtc2VydmljZS0wMC50eHQ8bzpwPjwvbzpwPjwvcHJlPjxwcmU+aGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBDaGFuZ2NoZW5nIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48 L286cD48L3ByZT48cHJlPklFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT48cHJlPk5hbWU6wqDCoMKgwqDCoMKgwqDCoMKgIGRyYWZ0LWh1 YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZTxvOnA+PC9vOnA+PC9wcmU+PHByZT5S ZXZpc2lvbjrCoMKgwqDCoMKgIDAwPG86cD48L286cD48L3ByZT48cHJlPlRpdGxlOsKgwqDCoMKg wqDCoMKgwqAgU0ZDIFVzZSBDYXNlcyBvbiBSZWN1cnNpdmUgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZzxvOnA+PC9vOnA+PC9wcmU+PHByZT5Eb2N1bWVudCBkYXRlOiAyMDE0LTA3LTAxPG86cD48 L286cD48L3ByZT48cHJlPkdyb3VwOsKgwqDCoMKgwqDCoMKgwqAgSW5kaXZpZHVhbCBTdWJtaXNz aW9uPG86cD48L286cD48L3ByZT48cHJlPlBhZ2VzOsKgwqDCoMKgwqDCoMKgwqAgNzxvOnA+PC9v OnA+PC9wcmU+PHByZT5VUkw6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVj dXJzaXZlLXNlcnZpY2UtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UtMDAudHh0PC9hPjxv OnA+PC9vOnA+PC9wcmU+PHByZT5TdGF0dXM6wqDCoMKgwqAgwqDCoMKgwqA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVj dXJzaXZlLXNlcnZpY2UvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o dWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UvPC9hPjxvOnA+PC9vOnA+PC9wcmU+ PHByZT5IdG1saXplZDrCoMKgwqDCoMKgwqAgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwIj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZl LXNlcnZpY2UtMDA8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48 L3ByZT48cHJlPsKgwqAgU2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyAoU0ZDKSBwcm92aWRlcyB2 YXJpb3VzIHNlcnZpY2VzIHRoYXQgY2FuPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgYmUgdGFp bG9yZWQgdG8gZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmcm9tIGRpdmVyc2lmaWVkIHVzZXIgZ3Jv dXBzLDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIHdoZXJlIGVhY2ggdXNlciBncm91cCBmb3Jt cyBhIGNvbGxlY3RpdmUgY2xpZW50IHRoYXQgcmVxdWlyZXM8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ wqDCoCBzaW1pbGFyIHNlcnZpY2UuIFNGQyBpcyB0eXBpY2FsbHkgZGVwbG95ZWQgYXMgYSBzZXJ2 aWNlIG92ZXJsYXkgd2l0aDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIGl0cyBvd24gc2Vydmlj ZSB0b3BvbG9neSBvbiB0b3Agb2YgZXhpc3RpbmcgbmV0d29yayB0b3BvbG9neS4gVGhpczxvOnA+ PC9vOnA+PC9wcmU+PHByZT7CoMKgIGtpbmQgb2YgdmlydHVhbGl6ZWQgc3RydWN0dXJlIG5hdHVy YWxseSBlbmFibGVzIHJlY3Vyc2l2ZSBzZXJ2aWNlPG86cD48L286cD48L3ByZT48cHJlPsKgwqAg cmVsYXRpb25zaGlwIHdoZXJlIGEgY2xpZW50IG1heSBiZWNvbWUgYSBzZXJ2aWNlIHByb3ZpZGVy IGFuZCByZXNlbGw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBTRkMgc2VydmljZXMgdG8gaXRz IG93biB1c2VyIGdyb3Vwcy4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc29tZTxvOnA+PC9vOnA+ PC9wcmU+PHByZT7CoMKgIGV4ZW1wbGFyeSB1c2UgY2FzZXMgdGhhdCBzaG93IHRoZSB1c2FnZSBv ZiByZWN1cnNpdmUgKGUuZy4gbmVzdGVkKTxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIHNlcnZp Y2UgZnVuY3Rpb24gY2hhaW5pbmcgcmVsYXRpb25zaGlwLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b248bzpwPjwvbzpwPjwvcHJlPjxwcmU+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286 cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_B6D287BF58D35D4B882E012AD3E1756172C8FC6FONWVEXCHMB04cie_-- From nobody Wed Jul 2 20:44: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 215621A02AC for ; Wed, 2 Jul 2014 20:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3cfxskepfOSd for ; Wed, 2 Jul 2014 20:44:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03DB1A01DD for ; Wed, 2 Jul 2014 20:44:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN23632; Thu, 03 Jul 2014 03:44:44 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 04:44:43 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 11:44:40 +0800 From: Weixinpeng To: Alla Goldner , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYug Date: Thu, 3 Jul 2014 03:44:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/related; boundary="_004_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CAy-UlMgDuigsGluAlh35zIgQbY Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 03:44:50 -0000 --_004_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_ Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_" --_000_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsYSwNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBUREYgd291bGQgcGxheSBhIHZlcnkgaW1w b3J0YW50IHJvbGUgaW4gcHJvdmlkaW5nIFNGQyB0byBMVEUgbmV0d29yaywgYnV0IGV4YWN0bHkg aG93IHRoZSB0d28gZG9tYWluIHNob3VsZCBpbnRlcmFjdCB3aXRoIGVhY2ggb3RoZXIgc3RpbGwg bmVlZHMgdG8gYmUgY29uc2lkZXJlZKOuDQpJIHRoaW5rIEkgY2FuIHByb3ZpZGUgdGhlIGRpc2N1 c3Npb24gb2YgVERGIHJlbGF0ZWQgaXNzdWUgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiBkcmFmdCwg YW5kIEkgaG9wZSB3ZSBjYW4gaGF2ZSBtb3JlIGRpc2N1c3Npb24gb24gdGhpcy4NCg0KQmVzdCBS ZWdhcmRzLA0KLVhpbnBlbmcNCg0KRnJvbTogQWxsYSBHb2xkbmVyIFttYWlsdG86YWdvbGRuZXJA YWxsb3QuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCA2OjU2IFBNDQpUbzogV2Vp eGlucGVuZzsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTog QSBuZXcgZHJhZnQtd2VpLXNmYy1tb2JpbGUtY29uc2lkZXJhdGlvbi0wMC4NCg0KRGVhciBYaW5w ZW5nLA0KDQpUaGFua3MgZm9yIHByb3ZpZGluZyB0aGlzIERyYWZ0IQ0KDQpJIGhhdmUgdGhlIGZv bGxvd2luZyBjb21tZW50czoNCg0KDQoxLiAgICAgICBGb3IgdGhlIEZpZ3VyZSAyIEJhc2ljIExU RSBuZXR3b3JrIGFyY2hpdGVjdHVyZSBpdCBpcyB2ZXJ5IGltcG9ydGFudCwgaW4gbXkgdmlldywg dG8gc2hvdyBUREYgKFRyYWZmaWMgZGV0ZWN0aW9uIEZ1bmN0aW9uKSBhcyBhIE5ldHdvcmsgRWxl bWVudCByZXNpZGluZyBvbiBTR2kgYXMgdGhpcyBlbGVtZW50IG1heSBmdW5jdGlvbiBhcyBhIFRy YWZmaWMgQ2xhc3NpZmllciAocGxlYXNlIGFsc28gc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXVzZS1jYXNlLW1vYmlsaXR5LyApDQpbV2VpXSBJbiB0 aGUgY3VycmVudCB2ZXJzaW9uLCB0aGlzIGRyYWZ0IG9ubHkgcHJvdmlkZSBhIGhpZ2ggbGV2ZWwg ZGlzY3Vzc2lvbiBvbiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiAzR1BQIG5ldHdvcmsgYW5kIFNG QyBkb21haW4sIGFuZCBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24gd2lsbCBiZSBpbmNsdWRlZCBp biB0aGUgZm9sbG93aW5nIHZlcnNpb24uIEZpZ3VyZTIgaXMgYSBicmllZiBpbnRyb2R1Y3Rpb24g YWJvdXQgTFRFIG5ldHdvcmsgdG8gc2hvdyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gTFRFIG5l dHdvcmsgYW5kIElQIG5ldHdvcmtzICwgc28gdGhpbmdzIGxpa2UgUENDIGFyY2hpdGVjdHVyZSBp bmNsdWRpbmcgVERGIGlzIG5vdCBpbnZvbHZlZCAgaGVyZS4gQUc+IFRERiwgaW4gdGhpcyByZWdh cmQsIGlzIG5vdCBvbmx5IGEgcGFydCBvZiBQQ0MgYXJjaGl0ZWN0dXJlLCBidXQgYSBrZXkgZW50 aXR5IGZvciBzZXJ2aWNlIGNsYXNzaWZpY2F0aW9uIHdpdGggcmVnYXJkIHRvIHNlcnZpY2UgY2hh aW5pbmcgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyB3aHkgaXQgaXMgdmVyeSBpbXBvcnRhbnQsIGlu IG15IHZpZXcsIHRvIGluY2x1ZGUgVERGLg0KDQoyLiAgICAgICBJdCBzaG91bGQgYmUgY2xhcmlm aWVkIHdoZXRoZXIgTFNGQyBvciBQU0ZDIGluY2x1ZGVzIHRoZSBvcmRlciBvZiBTZXJ2aWNlIEZ1 bmN0aW9ucyB0byBiZWNvbWUgcGFydHMgb2Ygc2VydmljZSBjaGFpbi4gSSB3b3VsZCB0aGluayB0 aGF0IExTRkMgc2hvdWxkIG5vdCBvbmx5IGluY2x1ZGUgYSBsaXN0LCBidXQgYWxzbyB0aGUgb3Jk ZXIgb2YgU0ZzIHRvIGJlIGFwcGxpZWQuIFRoZW4gUFNGQyBtYXkgaGFuZGxlIHBoeXNpY2FsIHJv dXRpbmcuDQpbV2VpXSBSaWdodCwgdGhlIG9yZGVyIG9mIFNGcyBzaG91bGQgYmUgc3BlY2lmaWVk IGZvciBib3RoIExTRkMgYW5kIFBTRkMsIG5vdCBqdXN0IGEgbGlzdCBvZiB0aGVtLg0KDQozLiAg ICAgICAiQmVzaWRlcyBMU0ZDLCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHN1Y2ggYXMgc3Vic2Ny aWJlciBJRCwgdGhhdCBtaWdodCBiZSB1c2VkIGJ1dCBjb3VsZCBub3QgYmUgYWNjZXNzZWQgZGly ZWN0bHkgYnkgU0ZDIGRvbWFpbiwgd2lsbCBhbHNvIGJlIGNvbnZleWVkIGluIHNlcnZpY2UgY2hh aW4gcmVxdWVzdCBwcm9jZWR1cmUiLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgY29ycmVjdCBhbmQg YmVsaWV2ZSB0aGF0IHN1YnNjcmliZXIgSUQgZXRjLiBzaG91bGQgYmUgbGV2ZXJhZ2VkIGFuZCB1 c2VkIGFzIGFuIGlucHV0IGZvciBtYWtpbmcgTFNGQyBkZWNpc2lvbiBieSAzR1BQIG5ldHdvcmsg YnV0IG5vdCBiZSBjb252ZXllZCBmdXJ0aGVyIHRvIFNGQyBkb21haW4gKHdoaWNoIGlzIGluIGxp bmUsIGJ5IHRoZSB3YXksIHdpdGggeW91ciBmb2xsb3dpbmcgc3RhdGVtZW50IG9uICBzb3J0cyBv ZiBpbmZvcm1hdGlvbiB0aGF0IGNvdWxkIGJlIHVzZWQgaW4gY3JlYXRpbmcgb2YgTFNGQyIuDQpb V2VpXSBTdWJzY3JpYmVyIElEIGlzIHByb3ZpZGVkIGFzIGV4YW1wbGUgb2YgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiwgYmVzaWRlcyBtYXRjaCBydWxlIGFuZCBMU0ZDLCB0aGF0IG1pZ2h0IGJlIGNv bnZleWVkIHRvIFNGQyBkb21haW4sIHNvbWUgb3RoZXIgaW5mb3JtYXRpb24gY291bGQgYWxzbyBi ZSBjb252ZXllZCBkZXBlbmRpbmcgb24gc3BlY2lmaWMgU0YocykgaW5jbHVkZWQgaW4gTFNGQy4g Rm9yIGV4YW1wbGUsIFN1YnNjcmliZXIgSUQgd2lsbCBiZSB1c2VkIGJ5IFNGIHRoYXQgaW1wbGVt ZW50cyBIVFRQIGhlYWRlciBlbnJpY2htZW50LiBJIHRoaW5rIHdlIGNhbiBnbyBtb3JlIGRlZXAg b24gZGlzY3Vzc2lvbiBmb3IgdGhpcyBpc3N1ZS4gQUc+IEkgc2VlIHlvdXIgcG9pbnQuIEluIHRo aXMgY2FzZSBhIG1vcmUgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIG1heSBiZSBwcm92aWRlZCwgYXMg dGhlc2UgcGFyYW1ldGVycyBhcmUgYWxyZWFkeSBhdmFpbGFibGUgdG8gUEdXIGFuZCBUREYgKGku ZS4gc2VydmljZSBjbGFzc2lmaWVycykuDQoNCg0KNC4gICAgICAgV2l0aCByZWdhcmQgdG8gc29y dHMgb2YgaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBiZSB1c2VkIGluIGNyZWF0aW5nIG9mIExTRkMs IEkgc3VnZ2VzdCB0byByZWZlcmVuY2UgM0dQUCBUUiAyMi44MDggIlN0dWR5IG9uIEZsZXhpYmxl IE1vYmlsZSBTZXJ2aWNlIFN0ZWVyaW5nIChGTVNTKSIuDQpbV2VpXSBPaywgdGhhbmtzIGZvciBw cm92aWRpbmcgdGhpcyBpbmZvcm1hdGlvbi4NCg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBjb21tZW50cyBmb3IgbXkgY29tbWVudHMuIEkgd291bGQg YmUgaGFwcHkgdG8gd29yayB3aXRoIHlvdSBvbiByZXNvbHZpbmcgdGhvc2UuDQoNCkJlc3QgcmVn YXJkcywNCg0KDQpBbGxhIEdvbGRuZXINCkRpcmVjdG9yIG9mIE1vYmlsZSBUZWNobm9sb2dpZXMg YW5kIFN0YW5kYXJkcw0KQWxsb3QgQ29tbXVuaWNhdGlvbnMNClRlbCArOTcyIDkgNzYxOTI1MQ0K Q2VsbCArOTcyIDU0IDI0OTM5ODUNCkZheCArOTcyIDkgNzQ0MzYyNg0KYWdvbGRuZXJAYWxsb3Qu Y29tPG1haWx0bzphZ29sZG5lckBhbGxvdC5jb20+DQp3d3cuYWxsb3QuY29tPGh0dHA6Ly93d3cu YWxsb3QuY29tLz4NCg0KWzI5MVg1NV9zaWduYXR1cmUgKDIpXQ0KDQoNCg0KRnJvbTogc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXZWl4aW5wZW5nDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDEyOjQ0IFBNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSBBIG5ldyBkcmFmdC13ZWktc2ZjLW1vYmls ZS1jb25zaWRlcmF0aW9uLTAwLg0KDQoNCkhpIGFsbCwNCg0KQSBuZXcgZHJhZnQgb24gSW50ZXJh Y3Rpb24gYmV0d2VlbiBTRkMgbmV0d29yayBhbmQgM0dQUCBuZXR3b3JrIGhhcyBiZWVuIHN1Ym1p dHRlZC4gQ29tbWVudHMgYXJlIHdlbGNvbWVkIQ0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpYaW5w ZW5nDQoNCg0KDQoNCg0KTmFtZTogICAgICAgICAgICAgICBkcmFmdC13ZWktc2ZjLW1vYmlsZS1j b25zaWRlcmF0aW9uLTAwDQoNClJldmlzaW9uOiAgMDANCg0KVGl0bGU6ICAgICAgICAgICAgICAg ICAgSW50ZXJhY3Rpb24gYmV0d2VlbiBTRkMgbmV0d29yayBhbmQgM0dQUCBuZXR3b3JrDQoNCkRv Y3VtZW50IGRhdGU6ICAgICAgIDIwMTQtMDYtMzANCg0KR3JvdXA6ICAgICAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAgICAgICAgIDcNCg0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdlaS1zZmMt bW9iaWxlLWNvbnNpZGVyYXRpb24tMDAudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13ZWktc2ZjLW1vYmlsZS1jb25zaWRlcmF0aW9u Lw0KDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2Vp LXNmYy1tb2JpbGUtY29uc2lkZXJhdGlvbi0wMA0KDQoNCg0KDQoNCkFic3RyYWN0Og0KDQogICBU aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZGlzY3Vzc2lvbiBvZiBob3cgU0ZDIChTZXJ2aWNlIEZ1 bmN0aW9uDQoNCiAgIENoYWluKSBkb21haW4gY291bGQgaW50ZXJhY3Qgd2l0aCBjYXJyaWVyIG5l dHdvcmsgdG8gcHJvdmlkZSBuZXR3b3JrDQoNCiAgIHNlcnZpY2UgZm9yIHRyYWZmaWMuIEhlcmUg TFRFIChMb25nIFRlcm0gRXZvbHV0aW9uKSBuZXR3b3JrIGlzIHVzZWQNCg0KICAgYXMgYW4gZXhh bXBsZSBvZiBjYXJyaWVyIG5ldHdvcmsgZm9yIGRpc2N1c3Npb24uDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IGRlc2lnbmF0ZWQgcmVjaXBpZW50KHMpLiBJdCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBkZXNpZ25hdGVkIHJl Y2lwaWVudCwgeW91IG1heSBub3QgcmV2aWV3LCBjb3B5IG9yIGRpc3RyaWJ1dGUgdGhpcyBtZXNz YWdlLiBJZiB5b3UgaGF2ZSBtaXN0YWtlbmx5IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IGEgcmVwbHkgZS1tYWlsIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlLiBUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5 IGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQocykuIEl0IG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGRlc2ln bmF0ZWQgcmVjaXBpZW50LCB5b3UgbWF5IG5vdCByZXZpZXcsIGNvcHkgb3IgZGlzdHJpYnV0ZSB0 aGlzIG1lc3NhZ2UuIElmIHlvdSBoYXZlIG1pc3Rha2VubHkgcmVjZWl2ZWQgdGhpcyBtZXNzYWdl LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgYSByZXBseSBlLW1haWwgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UuIFRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo= --_000_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alla= ,

I agree= with you that TDF would play a very important role in providing SFC to LTE= network, but exactly how the two domain should interact with each other st= ill needs to be considered=A3=AE

I think= I can provide the discussion of TDF related issue in the next version of d= raft, and I hope we can have more discussion on this.

&n= bsp;

Best Re= gards,

-Xinpen= g

 

From: Alla Goldner= [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 

Dear Xinpeng,

 

Thanks for providing this Draft!

 

I have the following comments:

 

1.       For the Figure 2 Basic LTE network architecture it is ver= y important, in my view, to show TDF (Traffic detection Function) as a Netw= ork Element residing on SGi as this element may function as a Traffic Classifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )

[= Wei] In the current version, this draft only provide a high level discussio= n on the interaction between 3GPP network and SFC domain, and more detailed= discussion will be included in the following version. Figure2 is a brief introduction about LTE network to show the rel= ationship between LTE network and IP networks , so things like PCC architec= ture including TDF is not involved  here. AG> TDF, in this regard,= is not only a part of PCC architecture, but a key entity for service class= ification with regard to service chaining functionality. This is why it is = very important, in my view, to include TDF.

2.       It should be clarified whether LSFC or PSFC includes the = order of Service Functions to become parts of service chain. I would think = that LSFC should not only include a list, but also the order of SFs to be applied. Then PSFC may handle physic= al routing.

[= Wei] Right, the order of SFs should be specified for both LSFC and PSFC, no= t just a list of them.

3.       "Besides LSFC, additional information such as subscr= iber ID, that might be used but could not be accessed directly by SFC domai= n, will also be conveyed in service chain request procedure". I don't think this is correct and believe that su= bscriber ID etc. should be leveraged and used as an input for making LSFC d= ecision by 3GPP network but not be conveyed further to SFC domain (which is= in line, by the way, with your following statement on  sorts of information that could be used in creating of = LSFC".

[= Wei] Subscriber ID is provided as example of additional information, beside= s match rule and LSFC, that might be conveyed to SFC domain, some other inf= ormation could also be conveyed depending on specific SF(s) included in LSFC. For example, Subscriber ID will be use= d by SF that implements HTTP header enrichment. I think we can go more deep= on discussion for this issue. AG> I see your point. In= this case a more detailed requirements may be provided, as these parameter= s are already available to PGW and TDF (i.e. service classifiers).

&n= bsp;

4.       With regard to sorts of information that could be used in= creating of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Fle= xible Mobile Service Steering (FMSS)".

[= Wei] Ok, thanks for providing this information.

 

Please let me know if you have any questions or comments for my c= omments. I would be happy to work with you on resolving those.

 

Best regards,

 

<= o:p> 

Alla Goldner

Director of Mobile Technologies and St= andards

Allot Communications

Tel +972 9 7619251<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Times New R= oman","serif";color:#004A8E">

Cell +972 54 2493985

Fax +972 9 7443626<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Times New R= oman","serif";color:#004A8E">

= agoldner@allot.com

www.allot.com

 

=3D"291X55_signature

<= o:p> 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 

Hi all,

A new draft on Interaction b= etween SFC network and 3GPP network has been submitted. Comments are welcom= ed!

 

Best Regards,

Xinpeng

 

 

Name:    = ;           draft-wei-sfc= -mobile-consideration-00

Revision:  00

Title:   &nbs= p;            &= nbsp; Interaction between SFC network and 3GPP network

Document date:  &n= bsp;    2014-06-30

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           7=

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:<= /p>

   This document p= rovides a discussion of how SFC (Service Function

   Chain) domain c= ould interact with carrier network to provide network

   service for tra= ffic. Here LTE (Long Term Evolution) network is used

   as an example o= f carrier network for discussion.

 

This message is intended only for the design= ated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distr= ibute this message. If you have mistakenly received this message, please no= tify the sender by a reply e-mail and delete this message. Thank you.

This message is intended only for the design= ated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distr= ibute this message. If you have mistakenly received this message, please no= tify the sender by a reply e-mail and delete this message. Thank you.

--_000_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_-- --_004_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 03:44:39 GMT"; modification-date="Thu, 03 Jul 2014 03:44:39 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_C5C3BB522B1DDF478AA09545169155B46D81A8D7nkgeml507mbxchi_-- From nobody Thu Jul 3 00:08: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 90F151A0AC7 for ; Thu, 3 Jul 2014 00:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PWiwM9afn5-u for ; Thu, 3 Jul 2014 00:08:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A4A1B27B2 for ; Thu, 3 Jul 2014 00:08:37 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 67D623740BB; Thu, 3 Jul 2014 09:08:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3EA1E384055; Thu, 3 Jul 2014 09:08:35 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 09:08:35 +0200 From: To: Linda Dunbar Thread-Topic: Suggestions to "draft-boucadair-sfc-requirements-04" Thread-Index: Ac+ASSw6EqtHtNzASnqrgNUnvnRaZQP1xq1QAEtbEGABT+Hc0A== Date: Thu, 3 Jul 2014 07:08:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002B60A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <4A95BA014132FF49AE685FAB4B9F17F645D2E2D7@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D6B87A@dfweml701-chm.china.huawei.com> <94e3ad39-feb7-49ea-9f30-7b6985026936@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: <94e3ad39-feb7-49ea-9f30-7b6985026936@OPEXCLILH01.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933002B60AOPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.3.54820 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RE7EcBxFbUzgR8Phb8VP7HC-0iM Cc: "sfc@ietf.org" Subject: Re: [sfc] Suggestions to "draft-boucadair-sfc-requirements-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: Thu, 03 Jul 2014 07:08:42 -0000 --_000_787AE7BB302AE849A7480A190F8B933002B60AOPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you again for reviewing the document and providing input. An updated = version is available at: http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/?include_t= ext=3D1 Given that you provided text, I listed you in the contributors section. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@oran= ge.com Envoy=E9 : jeudi 26 juin 2014 16:51 =C0 : Linda Dunbar; JACQUENET Christian IMT/OLN; Jiangyuanlong; Ron Parker;= Carlos Pignataro (cpignata) Cc : sfc@ietf.org Objet : Re: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04" Hi Linda, Thank you very much for your review. Your suggestion to group the requirements looks good to me. I'm currently w= orking on a revision to implement this change. Cheers, Med De : Linda Dunbar [mailto:linda.dunbar@huawei.com] Envoy=E9 : mercredi 25 juin 2014 19:18 =C0 : BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; Jiangyuanlong= ; Ron Parker; Carlos Pignataro (cpignata) Cc : sfc@ietf.org Objet : RE: Suggestions to "draft-boucadair-sfc-requirements-04" Mohamed, et al, When you get a chance, can you address those suggestions? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, June 04, 2014 6:03 PM To: mohamed.boucadair@orange.com; chri= stian.jacquenet@orange.com; Jiangyua= nlong; Ron Parker; Carlos Pignataro (cpignata) Cc: sfc@ietf.org Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements-04" Mohamed, et al, The draft-boucadair-sfc-requirements-04 has all the requirements lumped tog= ether, making it difficult for people to validate and provide comments. I think that it is beneficial to create multiple categories of requirements= . So each category can be reviewed and validated more intensively. With this in mind, I took the first stab of breaking the requirements in th= e draft to multiple categories. I didn't change the order of your original= ones, but shuffled them around, so that similar ones are put under one sub= -section. I also added some comments for the requirements that I don't thin= k make sense. I only added a few new requirements, however, I didn't add any new requirem= ent numbers. I suggest each sub-section has its own numbering scheme, such as "OAM-1, 2,= ..", so that any addition or deletion within one sub-section won't affect = other sections. Please see the attached with the changes marked. Linda --_000_787AE7BB302AE849A7480A190F8B933002B60AOPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thank you again for reviewing the document a= nd providing input. An updated version is available at:

http://datatracker.ietf.= org/doc/draft-boucadair-sfc-requirements/?include_text=3D1

 

Given that you provided text, I listed you i= n the contributors section.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : jeudi 26 juin 2014 16:51
=C0 : Linda Dunbar; JACQUENET Christian IMT/OLN; Jiangyuanlong;= Ron Parker; Carlos Pignataro (cpignata)
Cc : sfc@ietf.org
Objet : Re: [sfc] Suggestions to "draft-boucadair-sfc-requ= irements-04"

 

Hi Linda,

 

Thank you very much for your review.

 

Your suggestion to group the requirements lo= oks good to me. I’m currently working on a revision to implement this= change.

 

Cheers,

Med

 

De : Lind= a Dunbar [mailto:linda.dunbar@huawei.com]
Envoy=E9 : mercredi 25 juin 2014 19:18
=C0 : BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; J= iangyuanlong; Ron Parker; Carlos Pignataro (cpignata)
Cc : sfc@ietf.org
Objet : RE: Suggestions to "draft-boucadair-sfc-requiremen= ts-04"

 

Mohamed, et al, <= /o:p>

 

When you get a chance,= can you address those suggestions?

 

Linda

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 04, 2014 6:03 PM
To: mohamed.boucadai= r@orange.com; christian.jacquenet@orang= e.com; Jiangyuanlong; Ron Parker; Carlos Pignataro (cpignata)
Cc: sfc@ietf.org
Subject: [sfc] Suggestions to "draft-boucadair-sfc-requirements= -04"

 

Mohamed, et al,

 

The draft-boucadair-sfc-requirements-04 has all the = requirements lumped together, making it difficult for people to validate an= d provide comments.

 

I think that it is beneficial to create multiple cat= egories of requirements. So each category can be reviewed and validated mor= e intensively.

 

With this in mind, I took the first stab of breaking= the requirements in the draft to multiple categories.  I didn’t= change the order of your original ones, but shuffled them around, so that = similar ones are put under one sub-section. I also added some comments for the requirements that I don’t think mak= e sense.

 

I only added a few new requirements, however, I didn= ’t add any new requirement numbers.

 

I suggest each sub-section has its own numbering sch= eme, such as “OAM-1, 2, ..”, so that any addition or deletion w= ithin one sub-section won’t affect other sections.

 

Please see the attached with the changes marked.

 

Linda

--_000_787AE7BB302AE849A7480A190F8B933002B60AOPEXCLILM23corpor_-- From nobody Thu Jul 3 06:20: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 DF73F1B29B2 for ; Thu, 3 Jul 2014 06:20:54 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 r5vrjPFSIYG3 for ; Thu, 3 Jul 2014 06:20:52 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DEC1B29B1 for ; Thu, 3 Jul 2014 06:20:51 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 3DB8153E27; Thu, 3 Jul 2014 06:19:30 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 3 Jul 2014 06:19:30.198 -0700 x-echoworx-msg-id: 11bf5fe0-b1a5-478d-8d72-63082c7b5c0e x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 793; Thu, 3 Jul 2014 06:19:30 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 1760253E27; Thu, 3 Jul 2014 06:19:30 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 06:20:51 -0700 From: Ron Parker To: Weixinpeng , Alla Goldner , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYugABVHu6A= Date: Thu, 3 Jul 2014 13:20:50 +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: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/related; boundary="_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_"; type="multipart/alternative" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RkD-5RO5dVSMKQRnNWeusjc3NgE Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 13:20:55 -0000 --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_ Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_" --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi, Alla. Since DPI conclusions invariably occur on the Nth packet of a fully qualifi= ed flow, where N > 1, how does a TDF make practical steering decisions? D= on=1B$B!G=1B(Bt most service functions need to be involved from the first p= acket of a new fully qualified flow? If so, does the TDF need to perform = a proxy function to make this practical? Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Wednesday, July 02, 2014 11:45 PM To: Alla Goldner; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi Alla, I agree with you that TDF would play a very important role in providing SFC= to LTE network, but exactly how the two domain should interact with each o= ther still needs to be considered=1B$B!%=1B(B I think I can provide the discussion of TDF related issue in the next versi= on of draft, and I hope we can have more discussion on this. Best Regards, -Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very importa= nt, in my view, to show TDF (Traffic detection Function) as a Network Eleme= nt residing on SGi as this element may function as a Traffic Classifier (pl= ease also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobi= lity/ ) [Wei] In the current version, this draft only provide a high level discussi= on on the interaction between 3GPP network and SFC domain, and more detaile= d discussion will be included in the following version. Figure2 is a brief = introduction about LTE network to show the relationship between LTE network= and IP networks , so things like PCC architecture including TDF is not inv= olved here. AG> TDF, in this regard, is not only a part of PCC architectur= e, but a key entity for service classification with regard to service chain= ing functionality. This is why it is very important, in my view, to include= TDF. 2. It should be clarified whether LSFC or PSFC includes the order of = Service Functions to become parts of service chain. I would think that LSFC= should not only include a list, but also the order of SFs to be applied. T= hen PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC, n= ot just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, that = might be used but could not be accessed directly by SFC domain, will also b= e conveyed in service chain request procedure". I don't think this is corre= ct and believe that subscriber ID etc. should be leveraged and used as an i= nput for making LSFC decision by 3GPP network but not be conveyed further t= o SFC domain (which is in line, by the way, with your following statement o= n sorts of information that could be used in creating of LSFC". [Wei] Subscriber ID is provided as example of additional information, besid= es match rule and LSFC, that might be conveyed to SFC domain, some other in= formation could also be conveyed depending on specific SF(s) included in LS= FC. For example, Subscriber ID will be used by SF that implements HTTP head= er enrichment. I think we can go more deep on discussion for this issue. AG= > I see your point. In this case a more detailed requirements may be provid= ed, as these parameters are already available to PGW and TDF (i.e. service = classifiers). 4. With regard to sorts of information that could be used in creating= of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobile S= ervice Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments. I= would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi, Alla.

 

Since DPI conclusions invariably occur on the Nth pac= ket of a fully qualified flow, where N > 1, how does a TDF make practica= l steering decisions?   Don=1B$B!G=1B(Bt most service functions need to be involved from the first packet of a new fully qualifi= ed flow?   If so, does the TDF need to perform a proxy function t= o make this practical?

 

Thanks.

 

   Ron

 

 

From: = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Wednesday, July 02, 2014 11:45 PM
To: Alla Goldner; sfc@ietf.org
Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi Alla,

I agree with you that = TDF would play a very important role in providing SFC to LTE network, but e= xactly how the two domain should interact with each other still needs to be= considered=1B$B!%=1B(B<= /p>

I think I can provide = the discussion of TDF related issue in the next version of draft, and I hop= e we can have more discussion on this.

 

Best Regards,

-Xinpeng

=  

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Dear = Xinpeng,

=  

Thank= s for providing this Draft!

=  

I hav= e the following comments:

=  

1.       For the Figure 2 Basic LTE network architecture it is very important, in= my view, to show TDF (Traffic detection Function) as a Network Element res= iding on SGi as this element may function as a Traffic Classifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )

[Wei] In the cur= rent version, this draft only provide a high level discussion on the intera= ction between 3GPP network and SFC domain, and more detailed discussion wil= l be included in the following version. Figure2 is a brief introduction about LTE network to show the relationship= between LTE network and IP networks , so things like PCC architecture incl= uding TDF is not involved  here. AG> TDF, in this regard, is not only a = part of PCC architecture, but a key entity for service classification with = regard to service chaining functionality. This is why it is very important,= in my view, to include TDF.

2.       It should be clarified whether LSFC or PSFC includes the order of Servic= e Functions to become parts of service chain. I would think that LSFC shoul= d not only include a list, but also the order of SFs to be applied. Then PSFC may handle physical routing.

[Wei] Right, the= order of SFs should be specified for both LSFC and PSFC, not just a list o= f them.

3.       "Besides LSFC, additional information such as subscriber ID, that m= ight be used but could not be accessed directly by SFC domain, will also be= conveyed in service chain request procedure". I don't think this is correct and believe that subscriber ID etc. should b= e leveraged and used as an input for making LSFC decision by 3GPP network b= ut not be conveyed further to SFC domain (which is in line, by the way, wit= h your following statement on  sorts of information that could be used in creating of LSFC".

[Wei] Subscriber= ID is provided as example of additional information, besides match rule an= d LSFC, that might be conveyed to SFC domain, some other information could = also be conveyed depending on specific SF(s) included in LSFC. For example, Subscriber ID will be used by SF that= implements HTTP header enrichment. I think we can go more deep on discussi= on for this issue. AG> I see your point. In this case a mo= re detailed requirements may be provided, as these parameters are already a= vailable to PGW and TDF (i.e. service classifiers).

 

4.       With regard to sorts of information that could be used in creating of LS= FC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobile Se= rvice Steering (FMSS)".

[Wei] Ok, thanks= for providing this information.

 

Pleas= e let me know if you have any questions or comments for my comments. I woul= d be happy to work with you on resolving those.

=  

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

 

3D"291X55_signa=

 

=  

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 =

Hi all,

A new draft on Interaction between SFC network an= d 3GPP network has been submitted. Comments are welcomed!

 

Best Regards,

Xinpeng

 

 

Name:       &n= bsp;       draft-wei-sfc-mobile-consideration= -00

Revision:  00

Title:       &= nbsp;          Interaction bet= ween SFC network and 3GPP network

Document date:      = ; 2014-06-30

Group:       &= nbsp;       Individual Submission<= /p>

Pages:       &= nbsp;       7

URL:       &nb= sp;    http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:

   This document provides a discussion = of how SFC (Service Function

   Chain) domain could interact with ca= rrier network to provide network

   service for traffic. Here LTE (Long = Term Evolution) network is used

   as an example of carrier network for= discussion.

 

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 distribu= te this message. If you have mistakenly received this message, please notif= y 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 distribu= te this message. If you have mistakenly received this message, please notif= y the sender by a reply e-mail and delete this message. Thank you.

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_-- --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 13:20:50 GMT"; modification-date="Thu, 03 Jul 2014 13:20:50 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABC77MBX021W3CA2exch_-- From nobody Thu Jul 3 06:27: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 640FB1B29A5 for ; Thu, 3 Jul 2014 06:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 j-3Eeo0NF0Ic for ; Thu, 3 Jul 2014 06:27:36 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id C62B31B29B5 for ; Thu, 3 Jul 2014 06:27:33 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 03 Jul 2014 16:27:31 +0300 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, 3 Jul 2014 16:28:09 +0300 From: Alla Goldner To: Ron Parker , Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYugABVHu6AAADjSIA== Date: Thu, 3 Jul 2014 13:28:09 +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: [172.17.18.22] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oS5sXczVUViJTWE1SOO7iJ43pGE Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 13:27:39 -0000 --_004_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Ron, Thanks for your question! DPI algorithms are out of scope of 3GPP and of IETF. I would not make here a mandatorily assumption on N>1 for all application= s as well as I would not say those first few packets' (if exists) steerin= g is critical for implementation. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:21 PM To: Weixinpeng; Alla Goldner; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi, Alla. Since DPI conclusions invariably occur on the Nth packet of a fully quali= fied flow, where N > 1, how does a TDF make practical steering decisions?= =20 Don=1B$B!G=1B(Bt most service functions need to be involved from the= =20first packet of a new fully qualified flow? If so, does the TDF need= =20to perform a proxy function to make this practical? Thanks. =20 Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Wednesday, July 02, 2014 11:45 PM To: Alla Goldner; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi Alla, I agree with you that TDF would play a very important role in providing S= FC to LTE network, but exactly how the two domain should interact with ea= ch other still needs to be considered=1B$B!%=1B(B I think I can provide the discussion of TDF related issue in the next ver= sion of draft, and I hope we can have more discussion on this. Best Regards, -Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very impor= tant, in my view, to show TDF (Traffic detection Function) as a Network E= lement residing on SGi as this element may function as a Traffic Classifi= er (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-c= ase-mobility/ ) [Wei] In the current version, this draft only provide a high level discus= sion on the interaction between 3GPP network and SFC domain, and more det= ailed discussion will be included in the following version. Figure2 is a = brief introduction about LTE network to show the relationship between LTE= =20network and IP networks , so things like PCC architecture including TD= F is not involved here. AG> TDF, in this regard, is not only a part of P= CC architecture, but a key entity for service classification with regard = to service chaining functionality. This is why it is very important, in m= y view, to include TDF. 2. It should be clarified whether LSFC or PSFC includes the order o= f Service Functions to become parts of service chain. I would think that = LSFC should not only include a list, but also the order of SFs to be appl= ied. Then PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC,= =20not just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, tha= t might be used but could not be accessed directly by SFC domain, will al= so be conveyed in service chain request procedure". I don't think this is= =20correct and believe that subscriber ID etc. should be leveraged and us= ed as an input for making LSFC decision by 3GPP network but not be convey= ed further to SFC domain (which is in line, by the way, with your followi= ng statement on sorts of information that could be used in creating of L= SFC". [Wei] Subscriber ID is provided as example of additional information, bes= ides match rule and LSFC, that might be conveyed to SFC domain, some othe= r information could also be conveyed depending on specific SF(s) included= =20in LSFC. For example, Subscriber ID will be used by SF that implements= =20HTTP header enrichment. I think we can go more deep on discussion for = this issue. AG> I see your point. In this case a more detailed requiremen= ts may be provided, as these parameters are already available to PGW and = TDF (i.e. service classifiers). 4. With regard to sorts of information that could be used in creati= ng of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobi= le Service Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments.= =20I would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been = submitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-= consideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-con= sideration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considera= tion-00 Abstract: =20 This document provides a discussion of how SFC (Service Function =20 Chain) domain could interact with carrier network to provide network= =20 service for traffic. Here LTE (Long Term Evolution) network is used =20 as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply e-mail and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply 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. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable =

Hi = Ron,

 

Tha= nks for your question!

DPI= =20algorithms are out of scope of 3GPP and of IETF.

I w= ould not make here a mandatorily assumption on N>1 for all application= s as well as I would not say those first few packets' (if exists) steerin= g is critical for implementation.

 

Bes= t Regards,

 

 

Alla Goldner

Director of Mobile T= echnologies and Standards

Allot Communications

Tel +972 9= =207619251

Cell +972 5= 4 2493985

Fax +972 9= =207443626

agoldner@allot.com

www.allot.com<= /span>

 

3D"291X55_signature

 

 

From: Ron =20Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:21 PM
To: Weixinpeng; Alla Goldner; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi, Alla.

 

Since DPI conclusions invariably occur on the Nth= =20packet of a fully qualified flow, where N > 1, how does a TDF make = practical steering decisions?   Don=1B$B!G=1B(Bt most service =20functions need to be involved from the first packet of a new fully qua= lified flow?   If so, does the TDF need to perform a proxy func= tion to make this practical?

 

Thanks.

 

   Ron

 

 

From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Weixinpeng
Sent: Wednesday, July 02, 2014 11:45 PM
To: Alla Goldner; sfc@ietf.org=
Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi Alla,<= /span>

I agree with you tha= t TDF would play a very important role in providing SFC to LTE network, b= ut exactly how the two domain should interact with each other still needs= =20to be considered=1B$B!%=1B(B

I think I can provid= e the discussion of TDF related issue in the next version of draft, and I= =20hope we can have more discussion on this.

 

Best Regards,

-Xinpeng<= /span>

 

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Dea= r Xinpeng,

 

Tha= nks for providing this Draft!

 

I h= ave the following comments:

 

1.=        For the Figure 2 Ba= sic LTE network architecture it is very important, in my view, to show TD= F (Traffic detection Function) as a Network Element residing on SGi as th= is element may function as a Traffic Classifier =20(please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )<= o:p>

[Wei] In the c= urrent version, this draft only provide a high level discussion on the in= teraction between 3GPP network and SFC domain, and more detailed discussi= on will be included in the following version. =20Figure2 is a brief introduction about LTE network to show the relation= ship between LTE network and IP networks , so things like PCC architectur= e including TDF is not involved  here. AG> TDF, in this regard, is not only = a part of PCC architecture, but a key entity for service classification w= ith regard to service chaining functionality. This is why it is very impo= rtant, in my view, to include TDF.

2.=        It should be clarif= ied whether LSFC or PSFC includes the order of Service Functions to becom= e parts of service chain. I would think that LSFC should not only include= =20a list, but also the order of SFs to be =20applied. Then PSFC may handle physical routing.

[Wei] Right, t= he order of SFs should be specified for both LSFC and PSFC, not just a li= st of them.

3.=        "Besides LSFC,= =20additional information such as subscriber ID, that might be used but c= ould not be accessed directly by SFC domain, will also be conveyed in ser= vice chain request procedure". I don't think this =20is correct and believe that subscriber ID etc. should be leveraged and= =20used as an input for making LSFC decision by 3GPP network but not be c= onveyed further to SFC domain (which is in line, by the way, with your fo= llowing statement on  sorts of information =20that could be used in creating of LSFC".

[Wei] Subscrib= er ID is provided as example of additional information, besides match rul= e and LSFC, that might be conveyed to SFC domain, some other information = could also be conveyed depending on specific =20SF(s) included in LSFC. For example, Subscriber ID will be used by SF = that implements HTTP header enrichment. I think we can go more deep on di= scussion for this issue. AG> I see your point. In this case a = more detailed requirements may be provided, as these parameters are alrea= dy available to PGW and TDF (i.e. service classifiers).=

 

4.=        With regard to sort= s of information that could be used in creating of LSFC, I suggest to ref= erence 3GPP TR 22.808 "Study on Flexible Mobile Service Steering (FM= SS)".

[Wei] Ok, than= ks for providing this information.

 

Ple= ase let me know if you have any questions or comments for my comments. I = would be happy to work with you on resolving those.

=

 

Bes= t 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

&nb= sp;

3D"291X=<= /span>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi all,

A new draft on Interaction between SFC network = and 3GPP network has been submitted. Comments are welcomed!

 

Best Regards,

Xinpeng

 

 

Name:       =         draft-wei-sfc-mobile-considera= tion-00

Revision:  00

Title:       = ;           Interaction= =20between SFC network and 3GPP network

Document date:     &nb= sp; 2014-06-30

Group:       = ;        Individual Submission

Pages:       = ;        7

URL:       &= nbsp;    http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00= .txt

Status:      &nbs= p;  https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/<= o:p>

Htmlized:       <= a href=3D"http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-0= 0"> http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00=

 

 

Abstract:

   This document provides a discussio= n of how SFC (Service Function

   Chain) domain could interact with = carrier network to provide network

   service for traffic. Here LTE (Lon= g Term Evolution) network is used

   as an example of carrier network f= or discussion.

 

This message is intended only for the designated recip= ient(s). It may contain confidential or proprietary information. If =20you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please= =20notify the sender by a reply e-mail and delete this message. Thank you= .

This message is intended only for the designated recip= ient(s). It may contain confidential or proprietary information. If =20you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please= =20notify 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 con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 13:28:09 GMT"; modification-date="Thu, 03 Jul 2014 13:28:09 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA70479349B21F9LIONALLOTLOCAL_-- From nobody Thu Jul 3 06:35: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 115071B29C9 for ; Thu, 3 Jul 2014 06:35:17 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BnN1cr8hddXi for ; Thu, 3 Jul 2014 06:35:14 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078201B29CB for ; Thu, 3 Jul 2014 06:35:14 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 43F5053E1C; Thu, 3 Jul 2014 06:33:52 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 3 Jul 2014 06:33:52.180 -0700 x-echoworx-msg-id: 444a5fe7-802b-44e5-b58d-55eace17fbf1 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 108; Thu, 3 Jul 2014 06:33:52 -0700 (PDT) Received: from HUB021-CA-7.exch021.domain.local (unknown [10.254.4.109]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 0F25C53DFA; Thu, 3 Jul 2014 06:33:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 06:35:13 -0700 From: Ron Parker To: Alla Goldner , Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYugABVHu6AAADjSIAAAZXpw Date: Thu, 3 Jul 2014 13:35:12 +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: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/related; boundary="_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_"; type="multipart/alternative" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pQw-jt8-P7O2E6N0Qq5FfWwluwY Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 13:35:17 -0000 --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_ Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_" --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Alla, Perhaps I am reading too much into the original line of questions. When I= see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I think =1B$B!H=1B(BDPI=1B$B!I=1B(B. Is= that inaccurate? Regarding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B(B, wo= uldn=1B$B!G=1B(Bt some types of service functions have difficulty if they w= ere =1B$B!H=1B(Bswitched into=1B$B!I=1B(B the flow beyond its first packet? Thanks. Ron From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, July 03, 2014 9:28 AM To: Ron Parker; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi Ron, Thanks for your question! DPI algorithms are out of scope of 3GPP and of IETF. I would not make here a mandatorily assumption on N>1 for all applications = as well as I would not say those first few packets' (if exists) steering is= critical for implementation. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:21 PM To: Weixinpeng; Alla Goldner; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi, Alla. Since DPI conclusions invariably occur on the Nth packet of a fully qualifi= ed flow, where N > 1, how does a TDF make practical steering decisions? D= on=1B$B!G=1B(Bt most service functions need to be involved from the first p= acket of a new fully qualified flow? If so, does the TDF need to perform = a proxy function to make this practical? Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Wednesday, July 02, 2014 11:45 PM To: Alla Goldner; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi Alla, I agree with you that TDF would play a very important role in providing SFC= to LTE network, but exactly how the two domain should interact with each o= ther still needs to be considered=1B$B!%=1B(B I think I can provide the discussion of TDF related issue in the next versi= on of draft, and I hope we can have more discussion on this. Best Regards, -Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very importa= nt, in my view, to show TDF (Traffic detection Function) as a Network Eleme= nt residing on SGi as this element may function as a Traffic Classifier (pl= ease also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobi= lity/ ) [Wei] In the current version, this draft only provide a high level discussi= on on the interaction between 3GPP network and SFC domain, and more detaile= d discussion will be included in the following version. Figure2 is a brief = introduction about LTE network to show the relationship between LTE network= and IP networks , so things like PCC architecture including TDF is not inv= olved here. AG> TDF, in this regard, is not only a part of PCC architectur= e, but a key entity for service classification with regard to service chain= ing functionality. This is why it is very important, in my view, to include= TDF. 2. It should be clarified whether LSFC or PSFC includes the order of = Service Functions to become parts of service chain. I would think that LSFC= should not only include a list, but also the order of SFs to be applied. T= hen PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC, n= ot just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, that = might be used but could not be accessed directly by SFC domain, will also b= e conveyed in service chain request procedure". I don't think this is corre= ct and believe that subscriber ID etc. should be leveraged and used as an i= nput for making LSFC decision by 3GPP network but not be conveyed further t= o SFC domain (which is in line, by the way, with your following statement o= n sorts of information that could be used in creating of LSFC". [Wei] Subscriber ID is provided as example of additional information, besid= es match rule and LSFC, that might be conveyed to SFC domain, some other in= formation could also be conveyed depending on specific SF(s) included in LS= FC. For example, Subscriber ID will be used by SF that implements HTTP head= er enrichment. I think we can go more deep on discussion for this issue. AG= > I see your point. In this case a more detailed requirements may be provid= ed, as these parameters are already available to PGW and TDF (i.e. service = classifiers). 4. With regard to sorts of information that could be used in creating= of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobile S= ervice Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments. I= would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Alla,

 

Perhaps I am reading too much into the original line = of questions.   When I see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I think = =1B$B!H=1B(BDPI=1B$B!I=1B(B.   Is that inaccurate?   Re= garding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B(B, wouldn=1B$B!G=1B(Bt some types of service functions have difficulty if they were =1B$B!H=1B(Bs= witched into=1B$B!I=1B(B the flow beyond its first packet?

 

Thanks.

 

   Ron

 

 

From: Alla Goldner [mailto:agoldn= er@allot.com]
Sent: Thursday, July 03, 2014 9:28 AM
To: Ron Parker; Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi Ro= n,

=  

Thank= s for your question!

DPI a= lgorithms are out of scope of 3GPP and of IETF.

I wou= ld not make here a mandatorily assumption on N>1 for all applications as= well as I would not say those first few packets' (if exists) steering is c= ritical for implementation.

=  

Best = Regards,

=  

 

Alla Goldner

Director of Mobile Technol= ogies and Standards

Allot Communications

Tel +972 9 761= 9251

Cell +972 54 24= 93985

Fax +972 9 744= 3626

agoldner@allot.com

www.allot.com

 

3D"291X55_signature

 

=  

From: Ron Parker [mailto:Ron_Park= er@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:21 PM
To: Weixinpeng; Alla Goldner; sfc@ie= tf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi, Alla.

 

Since DPI conclusions invariably occur on the Nth pac= ket of a fully qualified flow, where N > 1, how does a TDF make practica= l steering decisions?   Don=1B$B!G=1B(Bt most service functions need to be involved from the first packet of a new fully qualifi= ed flow?   If so, does the TDF need to perform a proxy function t= o make this practical?

 

Thanks.

 

   Ron

 

 

 =

Hi Alla,

I agree with you that = TDF would play a very important role in providing SFC to LTE network, but e= xactly how the two domain should interact with each other still needs to be= considered=1B$B!%=1B(B<= /p>

I think I can provide = the discussion of TDF related issue in the next version of draft, and I hop= e we can have more discussion on this.

 

Best Regards,

-Xinpeng

=  

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Dear = Xinpeng,

=  

Thank= s for providing this Draft!

=  

I hav= e the following comments:

=  

1. =       For the Figure 2 Basi= c LTE network architecture it is very important, in my view, to show TDF (T= raffic detection Function) as a Network Element residing on SGi as this ele= ment may function as a Traffic Classifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )

[Wei] In the cur= rent version, this draft only provide a high level discussion on the intera= ction between 3GPP network and SFC domain, and more detailed discussion wil= l be included in the following version. Figure2 is a brief introduction about LTE network to show the relationship= between LTE network and IP networks , so things like PCC architecture incl= uding TDF is not involved  here. AG> TDF, in this regard, is not only a = part of PCC architecture, but a key entity for service classification with = regard to service chaining functionality. This is why it is very important,= in my view, to include TDF.

2. =       It should be clarifie= d whether LSFC or PSFC includes the order of Service Functions to become pa= rts of service chain. I would think that LSFC should not only include a lis= t, but also the order of SFs to be applied. Then PSFC may handle physical routing.

[Wei] Right, the= order of SFs should be specified for both LSFC and PSFC, not just a list o= f them.

3. =       "Besides LSFC, a= dditional information such as subscriber ID, that might be used but could n= ot be accessed directly by SFC domain, will also be conveyed in service cha= in request procedure". I don't think this is correct and believe that subscriber ID etc. should be leveraged and use= d as an input for making LSFC decision by 3GPP network but not be conveyed = further to SFC domain (which is in line, by the way, with your following st= atement on  sorts of information that could be used in creating of LSFC".

[Wei] Subscriber= ID is provided as example of additional information, besides match rule an= d LSFC, that might be conveyed to SFC domain, some other information could = also be conveyed depending on specific SF(s) included in LSFC. For example, Subscriber ID will be used by SF that= implements HTTP header enrichment. I think we can go more deep on discussi= on for this issue. AG> I see your point. In this case a mo= re detailed requirements may be provided, as these parameters are already a= vailable to PGW and TDF (i.e. service classifiers).

 

4. =       With regard to sorts = of information that could be used in creating of LSFC, I suggest to referen= ce 3GPP TR 22.808 "Study on Flexible Mobile Service Steering (FMSS)&qu= ot;.

[Wei] Ok, thanks= for providing this information.

 

Pleas= e let me know if you have any questions or comments for my comments. I woul= d be happy to work with you on resolving those.

=  

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

 

3D"291X55_signa=

 

=  

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 =

Hi all,

A new draft on Interaction between SFC network an= d 3GPP network has been submitted. Comments are welcomed!

 

Best Regards,

Xinpeng

 

 

Name:       &n= bsp;       draft-wei-sfc-mobile-consideration= -00

Revision:  00

Title:       &= nbsp;          Interaction bet= ween SFC network and 3GPP network

Document date:      = ; 2014-06-30

Group:       &= nbsp;       Individual Submission<= /p>

Pages:       &= nbsp;       7

URL:       &nb= sp;    http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:

   This document provides a discussion = of how SFC (Service Function

   Chain) domain could interact with ca= rrier network to provide network

   service for traffic. Here LTE (Long = Term Evolution) network is used

   as an example of carrier network for= discussion.

 

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 distribu= te this message. If you have mistakenly received this message, please notif= y 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 distribu= te this message. If you have mistakenly received this message, please notif= y the sender by a reply e-mail and delete this message. Thank you.

This message is intended only for th= e 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 messa= ge, please notify the sender by a reply e-mail and delete this message. Tha= nk you.

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_-- --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 13:35:11 GMT"; modification-date="Thu, 03 Jul 2014 13:35:11 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABCDDMBX021W3CA2exch_-- From nobody Thu Jul 3 06:46: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 464E61B29D7 for ; Thu, 3 Jul 2014 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 ChYugj6ci3vh for ; Thu, 3 Jul 2014 06:46:15 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0F1A009E for ; Thu, 3 Jul 2014 06:46:13 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 1, 6300) id ; Thu, 03 Jul 2014 16:46:12 +0300 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, 3 Jul 2014 16:46:49 +0300 From: Alla Goldner To: Ron Parker , Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYugABVHu6AAADjSIAAAZXpwAAA9w2A= Date: Thu, 3 Jul 2014 13:46:49 +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: [172.17.18.22] Content-Type: multipart/related; boundary="_004_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sIneq-p0Ly1f6cmokpe-Yn5te9I Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 13:46:20 -0000 --_004_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi, Ron, TDF includes DPI capabilities and goes beyond that in performing usage mo= nitoring, enforcement and charging for the detected applications. In case an application can't be detected from its very first packet, it m= ay put some limitations/restrictions/assumptions on implementation, howev= er, as I said, I don't think this is in scope of our discussions here. As= =20DPI algorithms are not under discussion - the consequences of those al= gorithms' accuracy can't be under discussion as well, I believe. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:35 PM To: Alla Goldner; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Alla, Perhaps I am reading too much into the original line of questions. When= =20I see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I think =1B$B!H=1B(BDPI=1B$B!I=1B(B= . Is that inaccurate? Regarding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B= (B, wouldn=1B$B!G=1B(Bt some types of service functions have difficulty i= f they were =1B$B!H=1B(Bswitched into=1B$B!I=1B(B the flow beyond its fir= st packet? Thanks. =20 Ron From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, July 03, 2014 9:28 AM To: Ron Parker; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi Ron, Thanks for your question! DPI algorithms are out of scope of 3GPP and of IETF. I would not make here a mandatorily assumption on N>1 for all application= s as well as I would not say those first few packets' (if exists) steerin= g is critical for implementation. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:21 PM To: Weixinpeng; Alla Goldner; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi, Alla. Since DPI conclusions invariably occur on the Nth packet of a fully quali= fied flow, where N > 1, how does a TDF make practical steering decisions?= =20 Don=1B$B!G=1B(Bt most service functions need to be involved from the= =20first packet of a new fully qualified flow? If so, does the TDF need= =20to perform a proxy function to make this practical? Thanks. =20 Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Wednesday, July 02, 2014 11:45 PM To: Alla Goldner; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi Alla, I agree with you that TDF would play a very important role in providing S= FC to LTE network, but exactly how the two domain should interact with ea= ch other still needs to be considered=1B$B!%=1B(B I think I can provide the discussion of TDF related issue in the next ver= sion of draft, and I hope we can have more discussion on this. Best Regards, -Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very impor= tant, in my view, to show TDF (Traffic detection Function) as a Network E= lement residing on SGi as this element may function as a Traffic Classifi= er (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-c= ase-mobility/ ) [Wei] In the current version, this draft only provide a high level discus= sion on the interaction between 3GPP network and SFC domain, and more det= ailed discussion will be included in the following version. Figure2 is a = brief introduction about LTE network to show the relationship between LTE= =20network and IP networks , so things like PCC architecture including TD= F is not involved here. AG> TDF, in this regard, is not only a part of P= CC architecture, but a key entity for service classification with regard = to service chaining functionality. This is why it is very important, in m= y view, to include TDF. 2. It should be clarified whether LSFC or PSFC includes the order o= f Service Functions to become parts of service chain. I would think that = LSFC should not only include a list, but also the order of SFs to be appl= ied. Then PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC,= =20not just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, tha= t might be used but could not be accessed directly by SFC domain, will al= so be conveyed in service chain request procedure". I don't think this is= =20correct and believe that subscriber ID etc. should be leveraged and us= ed as an input for making LSFC decision by 3GPP network but not be convey= ed further to SFC domain (which is in line, by the way, with your followi= ng statement on sorts of information that could be used in creating of L= SFC". [Wei] Subscriber ID is provided as example of additional information, bes= ides match rule and LSFC, that might be conveyed to SFC domain, some othe= r information could also be conveyed depending on specific SF(s) included= =20in LSFC. For example, Subscriber ID will be used by SF that implements= =20HTTP header enrichment. I think we can go more deep on discussion for = this issue. AG> I see your point. In this case a more detailed requiremen= ts may be provided, as these parameters are already available to PGW and = TDF (i.e. service classifiers). 4. With regard to sorts of information that could be used in creati= ng of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobi= le Service Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments.= =20I would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been = submitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-= consideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-con= sideration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considera= tion-00 Abstract: =20 This document provides a discussion of how SFC (Service Function =20 Chain) domain could interact with carrier network to provide network= =20 service for traffic. Here LTE (Long Term Evolution) network is used =20 as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply e-mail and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply e-mail and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may con= tain confidential or proprietary information. If you are not the designat= ed recipient, you may not review, copy or distribute this message. If you= =20have mistakenly received this message, please notify the sender by a r= eply 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. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable =

Hi,= =20Ron,

 

TDF= =20includes DPI capabilities and goes beyond that in performing usage mon= itoring, enforcement and charging for the detected applications.

In = case an application can't be detected from its very first packet, it may = put some limitations/restrictions/assumptions on implementation, however,= =20as I said, I don't think this is in scope =20of our discussions here. As DPI algorithms are not under discussion &#= 8211; the consequences of those algorithms' accuracy can't be under discu= ssion as well, I believe.

 

Bes= t Regards,

 

 

 

Alla Goldner

Director of Mobile T= echnologies and Standards

Allot Communications

Tel +972 9= =207619251

Cell +972 5= 4 2493985

Fax +972 9= =207443626

agoldner@allot.com

www.allot.com<= /span>

 

3D"291X55_signature

 

 

From: Ron =20Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:35 PM
To: Alla Goldner; Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Alla,

 

Perhaps I am reading too much into the original l= ine of questions.   When I see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I t= hink =1B$B!H=1B(BDPI=1B$B!I=1B(B.   Is that inaccurate? &n= bsp; Regarding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B(B, wouldn=1B$B!G=1B= (Bt =20some types of service functions have difficulty if they were =1B$B!H=1B= (Bswitched into=1B$B!I=1B(B the flow beyond its first packet?<= /span>

 

Thanks.

 

   Ron

 

 

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Thursday, July 03, 2014 9:28 AM
To: Ron Parker; Weixinpeng; sfc@ie= tf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi = Ron,

 

Tha= nks for your question!

DPI= =20algorithms are out of scope of 3GPP and of IETF.

I w= ould not make here a mandatorily assumption on N>1 for all application= s as well as I would not say those first few packets' (if exists) steerin= g is critical for implementation.

 

Bes= t Regards,

 

 

Alla Goldner

Director of Mobile T= echnologies and Standards

Allot Communications

Tel +972 9= =207619251

Cell +972 5= 4 2493985

Fax +972 9= =207443626

agoldner@allot.com

www.allot.com<= /span>

 

3D"291X55_signature

 

 

From: Ron =20Parker [mailto:Ron_= Parker@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:21 PM
To: Weixinpeng; Alla Goldner; sfc@= ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi, Alla.

 

Since DPI conclusions invariably occur on the Nth= =20packet of a fully qualified flow, where N > 1, how does a TDF make = practical steering decisions?   Don=1B$B!G=1B(Bt most service =20functions need to be involved from the first packet of a new fully qua= lified flow?   If so, does the TDF need to perform a proxy func= tion to make this practical?

 

Thanks.

 

   Ron

 

 

From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Weixinpeng
Sent: Wednesday, July 02, 2014 11:45 PM
To: Alla Goldner; sfc@ietf.org=
Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi Alla,<= /span>

I agree with you tha= t TDF would play a very important role in providing SFC to LTE network, b= ut exactly how the two domain should interact with each other still needs= =20to be considered=1B$B!%=1B(B

I think I can provid= e the discussion of TDF related issue in the next version of draft, and I= =20hope we can have more discussion on this.

 

Best Regards,

-Xinpeng<= /span>

 

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Dea= r Xinpeng,

 

Tha= nks for providing this Draft!

 

I h= ave the following comments:

 

1.=        For the Figure 2 Ba= sic LTE network architecture it is very important, in my view, to show TD= F (Traffic detection Function) as a Network Element residing on SGi as th= is element may function as a Traffic Classifier =20(please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )<= o:p>

[Wei] In the c= urrent version, this draft only provide a high level discussion on the in= teraction between 3GPP network and SFC domain, and more detailed discussi= on will be included in the following version. =20Figure2 is a brief introduction about LTE network to show the relation= ship between LTE network and IP networks , so things like PCC architectur= e including TDF is not involved  here. AG> TDF, in this regard, is not only = a part of PCC architecture, but a key entity for service classification w= ith regard to service chaining functionality. This is why it is very impo= rtant, in my view, to include TDF.

2.=        It should be clarif= ied whether LSFC or PSFC includes the order of Service Functions to becom= e parts of service chain. I would think that LSFC should not only include= =20a list, but also the order of SFs to be =20applied. Then PSFC may handle physical routing.

[Wei] Right, t= he order of SFs should be specified for both LSFC and PSFC, not just a li= st of them.

3.=        "Besides LSFC,= =20additional information such as subscriber ID, that might be used but c= ould not be accessed directly by SFC domain, will also be conveyed in ser= vice chain request procedure". I don't think this =20is correct and believe that subscriber ID etc. should be leveraged and= =20used as an input for making LSFC decision by 3GPP network but not be c= onveyed further to SFC domain (which is in line, by the way, with your fo= llowing statement on  sorts of information =20that could be used in creating of LSFC".

[Wei] Subscrib= er ID is provided as example of additional information, besides match rul= e and LSFC, that might be conveyed to SFC domain, some other information = could also be conveyed depending on specific =20SF(s) included in LSFC. For example, Subscriber ID will be used by SF = that implements HTTP header enrichment. I think we can go more deep on di= scussion for this issue. AG> I see your point. In this case a = more detailed requirements may be provided, as these parameters are alrea= dy available to PGW and TDF (i.e. service classifiers).=

 

4.=        With regard to sort= s of information that could be used in creating of LSFC, I suggest to ref= erence 3GPP TR 22.808 "Study on Flexible Mobile Service Steering (FM= SS)".

[Wei] Ok, than= ks for providing this information.

 

Ple= ase let me know if you have any questions or comments for my comments. I = would be happy to work with you on resolving those.

=

 

Bes= t 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

&nb= sp;

3D"291X=<= /span>

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi all,

A new draft on Interaction between SFC network = and 3GPP network has been submitted. Comments are welcomed!

 

Best Regards,

Xinpeng

 

 

Name:       =         draft-wei-sfc-mobile-considera= tion-00

Revision:  00

Title:       = ;           Interaction= =20between SFC network and 3GPP network

Document date:     &nb= sp; 2014-06-30

Group:       = ;        Individual Submission

Pages:       = ;        7

URL:       &= nbsp;    http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00= .txt

Status:      &nbs= p;  https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/<= o:p>

Htmlized:       <= a href=3D"http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-0= 0"> http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00=

 

 

Abstract:

   This document provides a discussio= n of how SFC (Service Function

   Chain) domain could interact with = carrier network to provide network

   service for traffic. Here LTE (Lon= g Term Evolution) network is used

   as an example of carrier network f= or discussion.

 

This message is intended only for the designated recip= ient(s). It may contain confidential or proprietary information. If =20you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please= =20notify the sender by a reply e-mail and delete this message. Thank you= .

This message is intended only for the designated recip= ient(s). It may contain confidential or proprietary information. If =20you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please= =20notify 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 proprieta= ry =20information. If you are not the designated recipient, you may not revi= ew, copy or distribute this message. If you have mistakenly received this= =20message, please notify the sender by a reply e-mail and delete this me= ssage. Thank you.

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_-- --_004_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 13:46:49 GMT"; modification-date="Thu, 03 Jul 2014 13:46:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_A6B8F2A767638641889989BC1BA70479349B2282LIONALLOTLOCAL_-- From nobody Thu Jul 3 06:52: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 111761B29E6 for ; Thu, 3 Jul 2014 06:52:26 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TCyUg47-WKnx for ; Thu, 3 Jul 2014 06:52:20 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406181B29ED for ; Thu, 3 Jul 2014 06:52:20 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 4C92D53DEE; Thu, 3 Jul 2014 06:51:39 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 3 Jul 2014 06:51:39.229 -0700 x-echoworx-msg-id: 710c2771-ba00-4e4e-8436-87799ad80f45 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 195; Thu, 3 Jul 2014 06:51:39 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 1F0C953DEE; Thu, 3 Jul 2014 06:51:39 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 06:52:19 -0700 From: Ron Parker To: Alla Goldner , Weixinpeng , "sfc@ietf.org" Thread-Topic: A new draft-wei-sfc-mobile-consideration-00. Thread-Index: Ac+VEP9zLQkvSsBQRTGLSmdPTEcnjgABxw7QAB63pnAACiMhsAAsEYugABVHu6AAADjSIAAAZXpwAAA9w2AAAF6g8A== Date: Thu, 3 Jul 2014 13:52:18 +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: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/related; boundary="_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_"; type="multipart/alternative" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1zDOdxZvCfgf7c9lhXBNqcU64io Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Thu, 03 Jul 2014 13:52:26 -0000 --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_ Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_" --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Thanks, Alla. I agree with your original comment that TDF is certainly eligible to be a c= lassifier/re-classifier. However, I wanted to bring out a discussion of th= e practicality and limitations of such an arrangement. Thanks for answeri= ng my questions. Ron From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, July 03, 2014 9:47 AM To: Ron Parker; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi, Ron, TDF includes DPI capabilities and goes beyond that in performing usage moni= toring, enforcement and charging for the detected applications. In case an application can't be detected from its very first packet, it may= put some limitations/restrictions/assumptions on implementation, however, = as I said, I don't think this is in scope of our discussions here. As DPI a= lgorithms are not under discussion - the consequences of those algorithms' = accuracy can't be under discussion as well, I believe. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:35 PM To: Alla Goldner; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Alla, Perhaps I am reading too much into the original line of questions. When I= see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I think =1B$B!H=1B(BDPI=1B$B!I=1B(B. Is= that inaccurate? Regarding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B(B, wo= uldn=1B$B!G=1B(Bt some types of service functions have difficulty if they w= ere =1B$B!H=1B(Bswitched into=1B$B!I=1B(B the flow beyond its first packet? Thanks. Ron From: Alla Goldner [mailto:agoldner@allot.com] Sent: Thursday, July 03, 2014 9:28 AM To: Ron Parker; Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi Ron, Thanks for your question! DPI algorithms are out of scope of 3GPP and of IETF. I would not make here a mandatorily assumption on N>1 for all applications = as well as I would not say those first few packets' (if exists) steering is= critical for implementation. 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 [291X55_signature (2)] From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Thursday, July 03, 2014 4:21 PM To: Weixinpeng; Alla Goldner; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Hi, Alla. Since DPI conclusions invariably occur on the Nth packet of a fully qualifi= ed flow, where N > 1, how does a TDF make practical steering decisions? D= on=1B$B!G=1B(Bt most service functions need to be involved from the first p= acket of a new fully qualified flow? If so, does the TDF need to perform = a proxy function to make this practical? Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Wednesday, July 02, 2014 11:45 PM To: Alla Goldner; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi Alla, I agree with you that TDF would play a very important role in providing SFC= to LTE network, but exactly how the two domain should interact with each o= ther still needs to be considered=1B$B!%=1B(B I think I can provide the discussion of TDF related issue in the next versi= on of draft, and I hope we can have more discussion on this. Best Regards, -Xinpeng From: Alla Goldner [mailto:agoldner@allot.com] Sent: Tuesday, July 01, 2014 6:56 PM To: Weixinpeng; sfc@ietf.org Subject: RE: A new draft-wei-sfc-mobile-consideration-00. Dear Xinpeng, Thanks for providing this Draft! I have the following comments: 1. For the Figure 2 Basic LTE network architecture it is very importa= nt, in my view, to show TDF (Traffic detection Function) as a Network Eleme= nt residing on SGi as this element may function as a Traffic Classifier (pl= ease also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobi= lity/ ) [Wei] In the current version, this draft only provide a high level discussi= on on the interaction between 3GPP network and SFC domain, and more detaile= d discussion will be included in the following version. Figure2 is a brief = introduction about LTE network to show the relationship between LTE network= and IP networks , so things like PCC architecture including TDF is not inv= olved here. AG> TDF, in this regard, is not only a part of PCC architectur= e, but a key entity for service classification with regard to service chain= ing functionality. This is why it is very important, in my view, to include= TDF. 2. It should be clarified whether LSFC or PSFC includes the order of = Service Functions to become parts of service chain. I would think that LSFC= should not only include a list, but also the order of SFs to be applied. T= hen PSFC may handle physical routing. [Wei] Right, the order of SFs should be specified for both LSFC and PSFC, n= ot just a list of them. 3. "Besides LSFC, additional information such as subscriber ID, that = might be used but could not be accessed directly by SFC domain, will also b= e conveyed in service chain request procedure". I don't think this is corre= ct and believe that subscriber ID etc. should be leveraged and used as an i= nput for making LSFC decision by 3GPP network but not be conveyed further t= o SFC domain (which is in line, by the way, with your following statement o= n sorts of information that could be used in creating of LSFC". [Wei] Subscriber ID is provided as example of additional information, besid= es match rule and LSFC, that might be conveyed to SFC domain, some other in= formation could also be conveyed depending on specific SF(s) included in LS= FC. For example, Subscriber ID will be used by SF that implements HTTP head= er enrichment. I think we can go more deep on discussion for this issue. AG= > I see your point. In this case a more detailed requirements may be provid= ed, as these parameters are already available to PGW and TDF (i.e. service = classifiers). 4. With regard to sorts of information that could be used in creating= of LSFC, I suggest to reference 3GPP TR 22.808 "Study on Flexible Mobile S= ervice Steering (FMSS)". [Wei] Ok, thanks for providing this information. Please let me know if you have any questions or comments for my comments. I= would be happy to work with you on resolving those. 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 [291X55_signature (2)] From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng Sent: Tuesday, July 01, 2014 12:44 PM To: sfc@ietf.org Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ ________________________________ This message is intended only for the designated recipient(s). It may conta= in confidential or proprietary information. If you are not the designated r= ecipient, you may not review, copy or distribute this message. If you have = mistakenly received this message, please notify the sender by a reply e-mai= l and delete this message. Thank you. ________________________________ --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Thanks, Alla.

 

I agree with your original comment that TDF is certai= nly eligible to be a classifier/re-classifier.  However, I wanted to b= ring out a discussion of the practicality and limitations of such an arrangement.   Thanks for answering m= y questions.

 

   Ron

 

 

From: Alla Goldner [mailto:= agoldner@allot.com]
Sent: Thursday, July 03, 2014 9:47 AM
To: Ron Parker; Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi, R= on,

=  

TDF i= ncludes DPI capabilities and goes beyond that in performing usage monitorin= g, enforcement and charging for the detected applications.

In ca= se an application can't be detected from its very first packet, it may put = some limitations/restrictions/assumptions on implementation, however, as I = said, I don't think this is in scope of our discussions here. As DPI algorithms are not under discussion –= ; the consequences of those algorithms' accuracy can't be under discussion = as well, I believe.

=  

Best = Regards,

=  

=  

 

Alla Goldner

Director of Mobile Technol= ogies and Standards

Allot Communications

Tel +972 9 761= 9251

Cell +972 54 24= 93985

Fax +972 9 744= 3626

agoldner@allot.com

www.allot.com

 

3D"291X55_signature

 

=  

From: Ron Parker [mailto:Ron_Park= er@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:35 PM
To: Alla Goldner; Weixinpeng; sfc@ie= tf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Alla,

 

Perhaps I am reading too much into the original line = of questions.   When I see =1B$B!H=1B(BTDF=1B$B!I=1B(B, I think = =1B$B!H=1B(BDPI=1B$B!I=1B(B.   Is that inaccurate?   Re= garding =1B$B!H=1B(Bfirst few packets=1B$B!I=1B(B, wouldn=1B$B!G=1B(Bt some types of service functions have difficulty if they were =1B$B!H=1B(Bs= witched into=1B$B!I=1B(B the flow beyond its first packet?

 

Thanks.

 

   Ron

 

 

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Thursday, July 03, 2014 9:28 AM
To: Ron Parker; Weixinpeng; sfc@ietf= .org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi Ro= n,

=  

Thank= s for your question!

DPI a= lgorithms are out of scope of 3GPP and of IETF.

I wou= ld not make here a mandatorily assumption on N>1 for all applications as= well as I would not say those first few packets' (if exists) steering is c= ritical for implementation.

=  

Best = Regards,

=  

 

Alla Goldner

Director of Mobile Technol= ogies and Standards

Allot Communications

Tel +972 9 761= 9251

Cell +972 54 24= 93985

Fax +972 9 744= 3626

agoldner@allot.com

www.allot.com

 

3D"291X55_signature

 

=  

From: Ron Parker [mailto:Ron_Park= er@affirmednetworks.com]
Sent: Thursday, July 03, 2014 4:21 PM
To: Weixinpeng; Alla Goldner; sfc@ie= tf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Hi, Alla.

 

Since DPI conclusions invariably occur on the Nth pac= ket of a fully qualified flow, where N > 1, how does a TDF make practica= l steering decisions?   Don=1B$B!G=1B(Bt most service functions need to be involved from the first packet of a new fully qualifi= ed flow?   If so, does the TDF need to perform a proxy function t= o make this practical?

 

Thanks.

 

   Ron

 

 

 =

Hi Alla,

I agree with you that = TDF would play a very important role in providing SFC to LTE network, but e= xactly how the two domain should interact with each other still needs to be= considered=1B$B!%=1B(B<= /p>

I think I can provide = the discussion of TDF related issue in the next version of draft, and I hop= e we can have more discussion on this.

 

Best Regards,

-Xinpeng

=  

From: Alla Goldner [mailto:agoldner@allot.com]
Sent: Tuesday, July 01, 2014 6:56 PM
To: Weixinpeng; sfc@ietf.org
Subject: RE: A new draft-wei-sfc-mobile-consideration-00.=

 =

Dear = Xinpeng,

=  

Thank= s for providing this Draft!

=  

I hav= e the following comments:

=  

1. =       For the Figure 2 Basi= c LTE network architecture it is very important, in my view, to show TDF (T= raffic detection Function) as a Network Element residing on SGi as this ele= ment may function as a Traffic Classifier (please also see https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ )

[Wei] In the cur= rent version, this draft only provide a high level discussion on the intera= ction between 3GPP network and SFC domain, and more detailed discussion wil= l be included in the following version. Figure2 is a brief introduction about LTE network to show the relationship= between LTE network and IP networks , so things like PCC architecture incl= uding TDF is not involved  here. AG> TDF, in this regard, is not only a = part of PCC architecture, but a key entity for service classification with = regard to service chaining functionality. This is why it is very important,= in my view, to include TDF.

2. =       It should be clarifie= d whether LSFC or PSFC includes the order of Service Functions to become pa= rts of service chain. I would think that LSFC should not only include a lis= t, but also the order of SFs to be applied. Then PSFC may handle physical routing.

[Wei] Right, the= order of SFs should be specified for both LSFC and PSFC, not just a list o= f them.

3. =       "Besides LSFC, a= dditional information such as subscriber ID, that might be used but could n= ot be accessed directly by SFC domain, will also be conveyed in service cha= in request procedure". I don't think this is correct and believe that subscriber ID etc. should be leveraged and use= d as an input for making LSFC decision by 3GPP network but not be conveyed = further to SFC domain (which is in line, by the way, with your following st= atement on  sorts of information that could be used in creating of LSFC".

[Wei] Subscriber= ID is provided as example of additional information, besides match rule an= d LSFC, that might be conveyed to SFC domain, some other information could = also be conveyed depending on specific SF(s) included in LSFC. For example, Subscriber ID will be used by SF that= implements HTTP header enrichment. I think we can go more deep on discussi= on for this issue. AG> I see your point. In this case a mo= re detailed requirements may be provided, as these parameters are already a= vailable to PGW and TDF (i.e. service classifiers).

 

4. =       With regard to sorts = of information that could be used in creating of LSFC, I suggest to referen= ce 3GPP TR 22.808 "Study on Flexible Mobile Service Steering (FMSS)&qu= ot;.

[Wei] Ok, thanks= for providing this information.

 

Pleas= e let me know if you have any questions or comments for my comments. I woul= d be happy to work with you on resolving those.

=  

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

 

3D"291X55_signa=

 

=  

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: Tuesday, July 01, 2014 12:44 PM
To: sfc@ietf.org
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

 =

Hi all,

A new draft on Interaction between SFC network an= d 3GPP network has been submitted. Comments are welcomed!

 

Best Regards,

Xinpeng

 

 

Name:       &n= bsp;       draft-wei-sfc-mobile-consideration= -00

Revision:  00

Title:       &= nbsp;          Interaction bet= ween SFC network and 3GPP network

Document date:      = ; 2014-06-30

Group:       &= nbsp;       Individual Submission<= /p>

Pages:       &= nbsp;       7

URL:       &nb= sp;    http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:

   This document provides a discussion = of how SFC (Service Function

   Chain) domain could interact with ca= rrier network to provide network

   service for traffic. Here LTE (Long = Term Evolution) network is used

   as an example of carrier network for= discussion.

 

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 distribu= te this message. If you have mistakenly received this message, please notif= y 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 distribu= te this message. If you have mistakenly received this message, please notif= y the sender by a reply e-mail and delete this message. Thank you.

This message is intended only for th= e 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 messa= ge, please notify the sender by a reply e-mail and delete this message. Tha= nk you.

This message is intended only for the de= signated 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 messa= ge, please notify the sender by a reply e-mail and delete this message. Tha= nk you.

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_-- --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=29141; creation-date="Thu, 03 Jul 2014 13:52:18 GMT"; modification-date="Thu, 03 Jul 2014 13:52:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/7gAOQWRvYmUA ZMAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIC AgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQIBAQICAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCAA3ASMDAREAAhEBAxEB/8QAyAAAAQQCAwEB AAAAAAAAAAAACAUGBwkECgACAwsBAQABBQADAQEAAAAAAAAAAAAIBAUGBwkAAQMCChAAAAcAAQMD AgMEBAkLBQAAAQIDBAUGBwgAERITFAkhFTEiFkFRMiNhQjUXcWJyMzQ3GDgKUqJzVHQlVTZWVxlj JGRlZhEAAgIBAwMCAwUDCAcFCAMAAQIDBAUREgYAEwchCDEiFEFhMiMVUTMWcaFCUmJyNAmBkUNT JFQXY3ODZDWx0ZKiRHQmNjcYOP/aAAwDAQACEQMRAD8A365KSYQ8e9lZV43j42ObLPHz52qRBs0a t0zKruF1lBAiaSSZREREfw6bsvlsZgcXYzeasRVcRUheWaaVgkcUcalnd2OgVVUEknpRUqWr9qOl SjeW3K4REUEszMdAoA9SSfQdBK63TYdsl38Hx0rreKq8e5OxkNQtaAJMyrkEoKfb0HSLpAFSFOBv blbPHQEMUyhW49yhnbd9yHnz3EZy1xz2oYqKhw2rKYZuQ5JNse8aamBJEkQEAhuyILVnYyPIlYkq CKh8bcC8d0Isl5YttPmZUDpjqx1YqfhvKlTodNN5kij1BCGUevWeXA+SLlIZB9yckkJsf5gM2EQ/ CCBX8fAUyTDMpku4dvo2KHb+r+zpyX2xe7W5H+q5HzFdiz/4uzDWm+k3faugswgrr9orKNP6H2FK fJ/iSF/pa3DoWx3w3vKne0/bqYn9f/EP8vSM70zkfx/USdbBEx2n52VRNN5daqkkhIRBFjEIVR+k VtH+1TSMfx7u0PRVOIF92Tpiu+Xfdt7YJkt+dqNXmfiveFlyuOVUsVQxAUyqI4NgUnb/AMTB25XK oLsZI6cIOH+JPKKmHgU8uG5WQSlSySY5SATohLPuJ01/KfcoBPYbozajbq9eq/HWeryKMpDSaXqN 3CXcpyHKPis2comAFWztsoAkUTOAGIYOwh1oBwXnXFvJPFqnMuGW47mAuJuSRfQgj0aORDo0csba rJGwDKw0I+HQ/Z3BZXjWUlw2ZiaHIQtoyn4EfYykejKw9VYehHTk6l3TR1zrnXOtd35KvnhpfF+0 WHC+McFX9c2euOXMRdLjOruV8vzqcbnOg8rxUIh2ykLxbopYhk3qCDpoxjnHZJVddwm5aIlH4m9t +Q5hTi5Hy+SWjgJQGiiQAWJ0PqH1YFYYmHqhKs7r8wVVKOw1+UfcFR4pbl4/xWOO7nIiVlkckwQu PQpopBlkX4MAyqh9CzMGRdc+wfLd8pGsSzyVj+Q2lIkTcKOAiszqsBXomLTMIHI1BvVKwgso2QIU AKLtVdQS/UxzCIiJT1fCXh3CwrDLi6hJGm6xI7s336ySEan+yAP2AdDPZ8x+WcxM0seStAa67YI0 RV+7SNAdB/aJP7Sep1wD59ufmK2Fu31Weg+QVTbuUkpeqaNXomtWZFskXwcIw90qURESsdJqdg/m ybaXSIICPoCIj3jnJvbT405BVLYaOTGXSDtkgdpIyT8C0UjMrL90bRE/1upBx33EeRMFZC5eSPJU wfmjmRUcD7Qssaqyt97rIB/V63D+EXOzCuemWm0bHJZw3lIRVnHaFnU8Ldvc89nHiKqrZnNM0FVU XcTKlbLHjpNuY7N8RFQpTEcIOW6AK+QvHPI/G2Y/Ss8gMMgLQTpqYp0BAJQkAhl1AeNtGQkEgqyM xqcD8gcf8hYn9TwjkSxkLNC+glhcjUBgPQq2h2OuquAR6MrKpndQLqcdc651zqB9r3quY60YsTM3 Nmu894J1unRYHUkH6iypm7ddyCCThdBqs5KKaQETUWcKFMVMggRQ6Y0e4f3NcU8C0q+NNebMeRsn oKGKratNMXYxo8mxXeOJpAY4wqPLPIGSGNgkzxWZ478Y5bn08lkSJT45W1Ni1JoEQAbmVdSoZguj NqyqikF2BZFeE2dP5g6eBZayX+HxuJeACiFcgmXu5pogcAUSFYzNYqzZYxD9jEVklTkMHYxSj9AH ilwL35eY1Ga5bymhwHC2NGSjSi7lqJD6rvMTB0YqdGSS+7owIZFIK9WJPnvAvDSaOIxc/IL0fo08 z7YWYeh03ghhqPQrXUEHUEj169nWV8tKR3kaXtbHQiNwBY9fuLEzVxJeP4tUnkirNN0/UAR+vrtP +kD8eva34U98PjkHK+P/ACJBykRfMaWUi7bzgf7JZJ2tIpb19e/W/wC8U+vXnDzXwdyP/hOQ8dkx Rf0E9V9yx/2isYiY6f3JP7p+HUg43yLSvM45zu/QDjP9VjAOVzXn5FUGst6SRllFYgXJzqlOLcgr FRE6xVEA9RFZYpVPTtLwF7rovI3IpfFXlDFy8X81VAQ9KYMkVrYu9mq9wlg2wGVYS0geD86CedBI Y4tz/wATycbxycr4xaXKcJm02zoQWi1OgEu0AabiELaKVf5JEjJXcTvRjdU51zrnXOmHo+kVTK6w 7tdufe0YNx9Fs3SAij+TemIdRKPjkDnTKs5UImYwiYxU00ymOoYpCmMFZ+WvLnCvCvDpua85s9nG xnZHGgDT2ZiCUgroSoeRgpPqyoiK0kjpGrMJNxLiOb5rmUwmCi32m9WY6hI01ALyMAdFBIHoCzEh VDMQCJjCy8q94IWYpqcRitAddzxchNNzObBMMj9vTcpILs1pBRNVJQDpLEJHJHDt4GOH5xB7F8u9 6/uXQZ7ga0fHnjCY615rSdy7ahPwkVXieZgykPHKkdKJ102PIPnN42sP4T8Zt9ByAz8i5QnpJHE2 2CJx8VLBggII0ZCZ2H9IKfl6V1cH5LRRCvq/yYeyMqH5jtLFFPjRJj/tKQFZCcTIT/Kan/wdPcvt n93uEjGR4z5gs281pqYr1ab6bd92+e4oX+Wu3SFPJniC6xrZTh8cVL7GglTu6ffokJJ/kkH8vXWu 8iNAzeyR9H5K1hGCGUVFvCaNDFKetyRiAUBO7O3D2hv4gMqZIrdVsUxRUbATyVL3xT3VeUfEnLKv jr3d4ePHC4+ypnqgBoTkaAmXZrHpqQZGjEMkAZDLTWMtKveW8U8X5diJeSeIbjWeyu6ahL6WI9fs UN833KGLrIQdsxbRCa6aiayZFUjkVSVIVRJVMxTpqJnKBiHIcoiU5DlEBAQHsIdaGxSxTxLPAyvC 6hlZSCrKRqCCPQgj1BHoR6jod3Ro2KOCrqdCD6EEfEEfYR1369OvnrGevWkazdyEg6QZMGDZd49e OlSINWjRskZZw5cLqmKmiggiQTHMYQKUoCI/TpHkMhQxNCfK5SaKvjK0LyyyyMEjiijUu8kjsQqI igszMQFAJJ0HXtXrz27CVaqNJZlcIiKCzMzHRVUD1JJIAA9SfToL3m3avssu/guPUG3jq0wWFo/0 uytgTQ9X8vc8c2eJLN0C+BwOVMyDt4ZMxTmRR/DrO3Je5Tzh7guQW+K+03FxV+KVJe1Y5DkE2RK/ pqYUlV0X0IcRGC1aaNkkeCvqR0RNbxrwfx/j4sr5ZtO+VmXfHj651cj+2UIJ9QQW3xRBgVDyfHrN DB+Qjovv33JKYQlh/OLNiyfhEAp+PgAJSDBD0vL/APCAO39Xpevtk921xP1TI+YLcWdPzdmGvP8A S7v2arYgTbr/AOUA0/ofZ14Hyb4jhb6Wtw+J6Pw3vJH3dP2+sbnX/wAb/T0lOdF5C4Oqi41eNZab QBWIk6ttbRRRlooqpiFIZcEm0akAEE/iBXbdMiyggQroBEAFkueYPdZ7YZ47PnulW5f4sMirJlsc qrYrbyAplAjrhdCdoFqBElkKxrdDEArYeHeKfJ8bR8BnlxHKgpK1LJJjl01J26tJrrpr+VIWVQWM JHRg1W0wN1gI2z1mRRlIWVQ9dm7R8g79jCmqiskcCqtnTZYhk1UjgVRNQolMACAh1oDwrmvGfIfG KnMeH247vHr0e+KVNf2kMjqdGSSNgUkjcB43VlYAgjofs1hcnx7JzYfMRNBkIG2sp/1ggj0ZWGhV gSGUggkHpwdSnpr651zrnQiaVyRlv1YrleGVn+8LQkxUSk3g9zVyuCkoCDgz1yVdqgcWaw+Cyqq6 LZBXsn3VUA6RQV8ue7XOnm7+F/bdh/4p8ooWWxMfWhQKnbJ3XDxoxiY7JZJJYq8MpWMtNKJIUvbi HiOj+hrzXyTc/SuKnQxr/t59RquxdGI3j1RVR5HX5tEQq5b7bGOU1oD39x5ChV3KoeqSKp8asdFo ZT8/tlnDNWtt1QRMPj3BM/cA/iH8eopW9vnvR5mgyXPPKn6Lcf5hXxcDlI9fURs0LUEOz8J0STXT 0c/EusvkHwthj9LgOK/Wwj0MlqQAtp6bgriww1+Pqw/kHWE8i+YWREGXZWKH3KuNB8nkIoxOhZva JiBlFmyKgFkXboxREClReuTgP19BT8OkF/C+/PwShzuPy1DyPxOD1lptCUyBjX1Z41IE8jkahVit 2GB0P08vw6UV7vgXnbfQWKljjeWf8EwcNX3H4BiPkVftJeGMfZ3F+PRCY3ttT2iEWkIMVY6YjTAj PVp+cv3KIceRkxEfypi5ZHVIYpFQIQfIolUImoAkAp/AXuJ4R7gePSZLjvcp8gpkLdx85H1FVzqN fgvchZgwSUKp1BWRIpA0Yqvn/jrOePsitXJbZsfMNYbCfu5V+P37XAIJXUjQgqzqQxmTq/eoB0E3 Jd9MaTf8643wD1xHNrScLRe37UwFVb1mOVXVIRMxjgmc6JY9ZUEzgIC6M0MH8IgOd/u8yOd8ueT+ Ke0zjNiWrSzJGRzE0foyUIGdlUEnaSggmlEbghrH0TD1XQkT4frUOI8Xy3lvKRrLNSH09NG+DWJA ASfTXQ70UsD+7E4+30iHadT0XP4YYfIftub5hn98c5AghFx7Z5YH07H1llZFn8gtJsnjGPinSTs3 tgJ5PHi3qOF1DAoUAor3D+Z/LHi7jhwvgw1eJeH+M8lk4yiwQJJenuQUYrzzTPZhliiryiRjAUJt WZBPZsyOZFVJ5484VxPlGQ+v533svzLKYxcoTI7JAkL2HrhEEbq7yKVHc10iiXbFGo2kkXh5CbsJ /U/vYt3fv37AeJAn49+3phFeHb+jt0GX/wDa33J9zufxpmt396DT/wCHsbf9GmnVzf8ASvxrt2/o dDT+SXX/AF9zXopeP266zOKF/X0nHXuiTl4reWvWk1HMGk2hK2+Ofrt3UYqxYN2E3GJIpFLJM3JD KFbn9UhgKVQpzS9rfuS83cjIPlK3W5J44yfI6HHnjtQQR2lsZSGZkeBooY4bVdETS9WnV3ELCWMq olD0t5S8a8Hxq/8A4vDNjOS1sbPkUaKR2hMdWRAyyB3Z4ZCSTBLGQpcbGBJUrImdMz8fOR7/ACRm soTNtVj17PTGSyxzpQcu3I4FWORUWObxIgLFRoUPqqqiqzKYwikHe1fFVKX2u+7S14QpSOPEnNqr 5DFxMxKU7SB9YVZidNvZkrAesksb0BI7NF6xTlk6+U/EsXOp1B5dhJRXtuAAZomK6SEAfFt6yH4K rLYIAD+h39aV9DR1Vx8wnLyc4ccJ7vc6RJKRGoaLLR2Q5rLNznI7gZ+1spR7K2ZkdL86EjXKhCyT pkt/AlIkbibuH5TXF4L4PX535Br0MggfD1UazOp+DpGVCxn9qvK6K4+JQvp+0VN5p5nY4TwSe9QY plrLrXgYfFHkDFnH7Ckauyn7H26/s61Zvhd+MyI516baNQ2pGRX485DIR6E7FoOnzFzqV+kCBJNa T94aHQdM4ONjPF7OLN103wJuWiCIkF2Zw3Mbz75cn8c4iHD8fKjlF5WKMQCK8K/KZdp1Bdm+SEMC mquza7AjCX4N8WQ+QMrLls6GPG6TAOoJBnmPzCLcNCEVfmlIIbRkVdN5Zd0w9nwrjBDwOV0KjsK4 0bNCqQuaZJT45v7NiUoJ+8NDxRY1g3FYqXcTqGBdfxE/5+wm6xj83+63hXjfkkOH5fPmM95BvR91 aNCFr98xan82RWkRY0Oh2h5FZlDFEKqSNQfH/h/J5nENLx6GhjOMV22d2ZlrVw3p8q7VJZvhuIUg Ejc2p6Fnkxw04a/JrntiZ2Cvx0Rp8c0O0iNTiIJvCa1ns4ZFQkYaa+jNxaa8VVESKxr5Vdg4IVUq CiDkhXCNw+2P3jYbk6SZbxdlJbFSlKqX8VaV4ZYCxb5J60mphdtrhLEO5C6MoeTZJH1W/mn28w2I hR5lSjhvTxk1b8G192gGjJKuglQajdDJodrA6IWR+tNPjLrGu/Ev8hnsbsZePHOb2tlm8V+PO5Xi rjl8pIMyy8hHIqCwUkm6sOdrY6+ooCPm4RaHUKCZlEzax8uwuD81+L+5j9G+qrCxTdtA0VhVO1WP rtO7dBMBroC4HqAes4uK5jM+HvJPbv6r9NYNe2g1KyQMRuKj03DbtmhJ01IQn0JHX0YUF0XKKLls sk4buEk10F0FCKorIqkBRJZFVMTEUSUIYBKYBEBAe4dZYMrIxVgQwOhB9CCPsPWmCsrKGUgqRqCP gR+0dYUzKs4GHlZyQP6TCGjX0q9U7gHptI9sq7cn7mEC/lRREfqIB0z8gzdDjOBu8jyrbMZj6k1m Zv6sUEbSyH10Hoik+vS3H0Z8nfgxtUbrViZI0H7Wdgqj/WR0GPFmqr36Ws3JO7pg+s1qmJaNpqTg BVb12vMVjRzlWM9T6EUcKImZJqAHmRm2AAN/OV8s/fZdwuz5PzOX93HkVBZ5fmr9mHFB9Xjo0Ym7 DtX3egZirU43A3pWrkBz9RMCQXmnNRcYo0/EXHD28PSrxSWyvo087juKJNPiFBErD4GWTUj8tNDg 60Z6HHqHdX3XOscYivbJkppZZA60dWIsCPbDJAQO/mkxBQhWjX97hydFuHYfz9/p1Q3mz3JeKfAm MNnnF8HNPGWgx9fSW9PoCdVh3ARRnQ/nTtFD6Eby3ymfcI8a8s59Z7eDrkUVYCSxJqkEev2F9Dub /s4w7n+rp69Dxr1ZmtcxKA3hGEJTNPqUf/eBWCRrhU8s2qKLgZlKDkpEyTczp+SGIV+n4pgRCQL4 pdinUMcV/PXD895w9vOO9yVWgmC8vYKuc1jjXdzYTGJIbUdaedkRpJRVC3o9IlENsGOEKssrSWtw PMY7gvkW140ksnIcNvS/RWDIoETWivaM0cerBUMpMDasS8B1fUqgUo8kvSelZxUrqUEiLTcUmo/T REPSSlGiijGUTSDyMJUQkGqnpgI+XpiHfoyfBnkqLy94lwXkNAiz5GkrTKn4VsxM0NlVGpIQTxyb AfXZt19eqX5zxp+IctvcdbcY605CE/ExsA8ZP37GXdp6a66dSN1bHUT6r5WauuQm/wBtmXUWW1UH B1m0RB1FR6g2jbLbF33pLKu1nnlHqNEF2CzxYDAYrhJuzSMU5O4Gy2sVL3uj9z2d5Dbo/rfjXxpJ HVpYxpkir38i8xR2keUGBo1eGW1Lrqs0dejBIkiMwYpopoPFni+jj4pzR5PyZWlmtBGaSvWCagKE +cMwdIk00KM9hwVbQgm7pdNahqhY5iCyxs+mY6KdOYyPLZySzly7KQASBKKjowi8kZITeYt010lF gIJCGAxgHouvIXkXzvgOB5bPcZ4TBYz9WlI9eH9SFp3kGgUirXrCSxs17hgjmjklCGONw7Keqi45 xvgWR5BTx+UzjxY6adVkk+mMSqpPrrLJIVj1/DvZGVCdzAgHoQIzkzyIzgIew7Rnx3dJsr1Zm0VC FLVZxmuiHkKTZA7tdJNVVLyUQbSJEFHhEzCkt9B6AfD+8z3YeIvoOWe4niUknjfL2Hiif6UY+5E6 aEoiFyFYpvkhgvRxPbWNjDOFVmBB3fC/iLmP1GJ8cZYR8lpRh2HeNqB1P2swRSQDoryVy6xFhvj9 R1Otg2TjRulcDPZq3NBPbVGkfHMJKNlouYjJ92oVGIdMHLuPK1ZTLJ+qX0lAVFMT/kMJkzGKYneQ +4n2fe5fiv8A0szWehabONHBBBPWtQWq9yQ7K0kUkkHaisxSsNj9wxE6o5eF3VqsxvjfzL40yp5X j8fJsoK8kkkckUsUkCjWVXVZNzxOgO4bQ2nzAKygjF4mWqfQjrnjNxcGcWXIZw8Kg4MBuzqvKKLE jjImMJjHboih6iPceybVygmUOxOvH2P8z5NUxXIPb/z2VpeWcEyJqxudfzKLM6wbCdSyIULREnRa 89eJQFj9OeccLjJbeP8AIOAUJiM9WEzL/VnABk1/Yx12t/Wkjkc+rdF/0eHVDdBxybkpi5WXOuP9 edKs1L29LM2t0kQTHRrMeuoKYeInKRw2KZg7dqpiJRMZikUDdjmAc+vefm+Q8/5ZxL2scQnkr2uV WhZyUqDVo8dA7HXTUB0UQWrMiaqS9OFA2kjAkH4XpY7AYrLeU8wiyRYqIx1kJ9GsOAP2EqTviiVv UATOdNVB6Kir1iEpsBGVmusUo6HiWxGrRskAd+xfqouup283DtyqIqLKm7nVUMJjCIiPRtcH4Txn xzxWlwvh9VKfHsfCI4o1+71Z3b4ySyMTJLK2rySMzuSzE9UlnM3k+R5WfNZiVpsjYcs7H+ZVHwVF Gioo9FUBQAB0v9Svpp68HTVs+bOGT1ug8Zu0FWrto6RTcNnTZdMyS7dwgqU6SyCyRhKchgEpiiIC HbpLeo0snSmxuShisY6xE0csUqLJHJG6lXjkRgVdHUlWVgVZSQQQevWCeerOlms7R2Y2DI6kqysp 1VlYaEMCAQQdQfUdBTlzdbDuQE5jiSyxqLoTBa20tuuoop9vkkUF1l2yZziYO/tY1y2UExjKKlaN zGHyEQHOTwfUse2r3TZT27wySN4z5PVbKYdJGZuxKEdniVm1/ClexXYszPIlam7HcxBI7nMsfkvx ZV8iuqjk2MlFW4VAHcUlQHIH7WkjkAACqZJgBoBobvWkvQ2dDxyf0t/mOUyb+DOoSzWJ41qtcOiY SuEZCVIuZV03EpiqJuUWLdUEFA+ibkyQj3D6CKvvI8vZPw/4TuZLjjMnL8tYjxtFkJ3pNZDlpU2k MHjhjk7Tj8E7QsQR6G1fDfEKvMebQ1ckAcPUjazOCNVKREaK32FS7LvU/ijDgft6bVNjM94iY+2k Lg7IhMSajNe0SLVt72btFteIGOSGiUEhMs7bRpAOi0SAxUUUEzrHEvkqoMT4BhvFnsX8EQ5PnU6x Zy40T5CZEEtvIZKVCwqV1U6yJAN8ddAyxRxJJYkKGSeQvHILnKvO3PXq4GMtQhDLXRm2Q16ytp3Z SfRWkOjStoXZ2WNQ21FGbm/LbJ9GkncMVeVqMm3ZO5JFG3N2ce2fsI9Azl+qzkWr58wFZk2IZRRF RRNX0wExQMUphKu8R++bwh5Zys+CWW7gstFBLOiZNIYEmhgQyTNFNHNNFuijDSPG7o+xWdFdVcqn 5d4L5xxKmmQKwX6byLGTVZnZHc7UDRsiPo7EKrKpXcQpIJALYac48Uc2AsSf9UtIdRyDZK4O4UqV fMBjgRN6sn7sZprFqd+4LqNCgUv5jgUvcwRKj/mM+3u7y0cdb9Zgwry9tcnJVVaR1ICyMvdNuOFt fSR6ykfF0RdSHif24eQ4cUby/RSXwm41Vl1n+GpQHb2mkH9RZTqfRST6dNLkBDkxnQabyVpCZEWE jLs4HS42OMQGk+xmAAEJgqZDlbqu5JukKCin1IZyDVwICdMxjQX3Q4FfAPlDj/u58dIExtm9HTz1 evt7d2C16iyFBCNJPGrRu/qhsLTslTKjyM++Lr7eQeLZDxDyMlrUUDTY+STXdA8X4otSNwWNjvUf ERmeIEKwANv9QQ3/AIi2/sf9Qf5wP7G/8R/7N/jdaIfxRx//AJuH/AfW/i/+k/3/AP3f9rodP0vI f7p/8R2Ph/tf93/e+7oQYP0i85bl9z/zx8ta/pv1P+SCNU+4e37/AL+y/ft/jf09Afxrtr/mQ8h/ V9e43DIvoN3w/Bju9s+/0n+H9v7+r4yQc+27Hmn+7Gab6jT9utnZu/8Ak/m6cnIrjkjpUNZJ+nun 8dd3beMerQpJErasXWQrpTEiRnWK6Z0E55tGqKtWb8h0DkA5CLmOiUAJMvdf7UIPMHHcryLg09mp 5BlSCZqqzLHQy09Iba5uROpX6yOuZK9S2skJQOsc7NAPkafE/lmTiGQqYvPJFLxxHkQSmPdYqJP6 y9lwQxhaQLJLCQ4JDNGFkJLVGKQc6lNjWFYKYTtASJIf9MmYLffhl1AKZOLLGgArHeqkOBilDuBi CBwHw/N1hPNxblEHJP4Mmxt9eYfVCt9CYJPq/qGICwiDbvMjagqANGUhgdp16OpcljHx36ylmucN 2jL9RvHZ7Q+Mnc+AQEEE/YflI19OrZuN/HEKBA1uxXhxJu7girITzerKyCS1WpkzNNisFnrFg2TB F5awgkyNHD9VRb0yiok38ExEx9yfaP7UT4r4ti+SeQZrk3Nw81xcc0yNj8XasoIWlihjXbLkPpFS Ce1JJME+eKttjG9wd8t+Wv4oydvFccSFMCypC1kIRZtxRNvCO7HVK3eJlSFVTcQry7mACp3JEUB2 riqVDwGTC+vTqgT/AEgIoJCq+sJ/H8/tvVD9v5e4D/T0x+7k1z7hvCa1dv6wOTzFtPx/Td/G7t2n rs3a/drr9/SvxGJB485s0uv0f6YgGv4e5ss6afZu0/0/Do0OtCOh761j/wDic28ybj/xmdoCp+nk diszeUABH0RmXVKWUghOH4CoDJpI+A/sDy/f0XXtEauOTZdG0+qNCMr+3YJRv/nKfzdCt7qlnPHM U66/TC64b9m4xHZ/MH/n6m//AIfK0Umu/GxZp1A6CKtV2fVZDQTIEAHJ5lrX6hItjKFHsK7paomj E0u38fiUgfUO3VZe9nk9TgfI8hzXk7snH8bgBaJ+J7EAnd1Qfa7SLIqIPVnYKPVh1N/afjTnuG18 JiADk7GXeFh/2snaClj9gEZQlvgFGv2dF7mdqt9sPdNAJcIfJ2UnNqur1qUuxbSr986cgCsFntTb ypgTKxhY5EhjJonBwbun5iYhUUx/Op4X5z5B56/JPLEfIcdwPG3cm0ua5NbhjtTzSyDdSwOLjtHa IKddEZo4WFhtYi5eNa8R1T5pguP4FcbxNsdYz1mCsFpYyJ2ijRV9J79povXfNISAzgxjR9oDGRgk obAtVtpptr/XEBfmSxggbDdIaGcViVn6u8cpMjtbjAKNmKAyVfEhV2q5Cm9ZJFHyWUAoFJHYvcRL wD3Gce8gPyfE8qxLf8HkMxUpyY2zexkjrE0eWotHAhs0NqzVZ1Dd6KKuHsShAsS+Tx4md8b5HAjG W8VaUd+vTmmWzFBZRS4apOGdu3PqUlQkbGeTbGm7VtWv/iCjQo/JJePtQoi+DMsnCyekKQn+9DWS mQ9x6f5vV/TpmHbz/N6fj/V8ev2He2RbA8TVWm17TWrJj/ud0g6fd3A/w9Ndft16/P8Ae47sf9T7 Ai07n0tff/e2emv37Nnx+zT7Ot33jEZ6bjXx6NI+f3A2HZMZ/wCp3FT3o0KAF16gm/N5+v5d+/17 9Z58v7Y5ZlBF+6/UbOn8nefT+bo8uKbzxfGmX979BX1/l7Ka/wA/StvSThbGNNI2Kc6v6NmziVMB E3opNDquR7B9fEGxDiP9Hfoafc3Dase3zmMdMMZv4fuHQfHYsRaT/QIwxP3a9Wz4yeKPyDh2mICf qEI9f2lgF/8AmI0+/pu8Xl2avH7LjtTJ+kjWU0FxKIACbxq7doSJVP2FUI9SU8+/18u/fqM+zi3j rHth4dNj2T6ZMTsYjQASxyypOD+wiVX3a/bqT06+ZorCeUs0s4O9rhYfejKpj0+4oV0+7oe7hyk0 Gbu8s7xCpnu+ZZaU394j1s19f9TA7OZFc0G9S7vGyMQkgqq2ValWOv4HWOmZsBDHFznnvL8o8h8h Xb3t2wb8j8Q8OB/W5o0DC+JG2Oaso/NRK6pI9eWuJDJtksyRyVEUtaeB8L8Wx3HIIPI14Y3mOa/w KM2n0+0ajvIfkYykqsiyFQmqxq4mLBRSgMMvOxTLHQYeszaGc6BoaUeMhNzDmwWVtWVnIKSE1JPX Y+/lYVNuis1I8FQfFYSlKApFBUQn457bPJnnrklfyliMRkIPFnI+UJB3bdqS3kY6JkUS2p5XXuz1 0jSSL6pn17o2alQJWu7J+SeN8Bx8nFr9ys3LMXii+yGJYK7WAuiQxovyRylikhi2+q6k6OSguKsY RkXT54HJEUIeOrcoC6QgBUEYxpFr+qQQH6Aim1TEP8kOt5+WDD4bgWTFtY4sBUxFjevwRK8Vd9w0 +G1Y1I/kHQDYn6y7nq3aLNfluR7T9pkaQaH+Usf9fQ18IkXCWBQZliKESXmZxVl5gIALUF00B9Pv /UK6RVKPb+sA9CL/AJdUFyH2x4+S0G7UuRuNET8DH3FQlfu7iSD0/pBvt6t73GSRP5PsrGQXWvCH 0/rbSfX79pU/yEdFx0dHVFdABxesjqpZxrU41rchaXkZqNofWOPh1macyhHMa9HPActWrxVAZRyc qBiJNkzAqocexe4j26y59mvMMhwPxFznk1LD283ep8zyM16Cq8K20rw0oJe5FHMyfUudjpHXRhI7 khNSdOij8x4aDP8ALsFi57kNGCfC1kryShzC0jzum1mQHtKNwZpGG1R8dB69TBmHLHMNCavSyrsc /mo9vJSLqHti6bUpYWOMiJpUsuJE4rsZJwUTIGUK5IIG/IYpfMb58M++Xwv5Xgs18vY/hjkdRJ5p KuScRr9NDsJnW2VSsdQ/rCzrOpSQiN41ErQjm3gbm3Ep4zQj/VsbK8cazVVLEzSa/ldrUy/FSA4U xsCvzBjtEk6eNWtFEeRMjFM7xDWOKCR+yR79uMpL11AzNy/nakBAVNJycK1dJPGoICU6igJlTOU5 yCNs+aX4TzTxhYweVo1+S8fy9IWPo4J4zZtUEMUk93FgB/qbFSKWO3WWEhpXESRSLJJGTDuE/rmE 5THfpzyYzI05+33pEbtRWG3qkFrXTtxzMrQylwQqly6lVbSp6wYBosXcmsNnzBxobF4wZXOk2eIW YotpOvA8RVjH0m4cumjeNfNnZU0lwESgYwgoQPE3YuF3Kfan5Ww3kivgfEkEvKMTaqw5bE5Gq0Qj noGVTBNM8kkSQSo+2OUMy6to6fKyno8cT5X4he47JkeWSpiLUcr07laUOWjn2ESJGqq7SIybmQgH Qaq3qNSbOXKrOOYmxuEGxWaSmfVs0+0SUKsk1sh2FLM4bGWT7pLLoD6hROAiBvEwh+PWlfhea1b9 +/PrcEIrwvxXHm7ErBkjvtDiTJHuX5XdD3FLD0YhyCdT0MHNEjh8CYCKRzI4ytjsORoWrh7YVtD6 hW+U6H1GoB6N7rRrocug0lQFDmxWhfgIg8zNYIQTfgApt7D64JiP7vbuu4B+8es8uQA1v8x3BNlA Stjh8opk/AFYrpfb/ojs6/yn9vRD489324XxV+MeYTvf6Wg01/8Aii/1dSZpOwSme6hmNTdRkYWp X1ZVg5sLxR0RwzlCOCtStkRIcrVMgKPGgiZQBDsqIiIAXv1dfl3z3mvFfmXh3B71OmvBeTu0Ml6V pA8VkSCMRroRGq7pa2rSAjSRiSoUnqE8R4FS5Tw3M5yCaY53GKHWBApV4yu7cdRuJ0SXQL9qgepO nU/9FF1V3UAm2GRecgUMehIyOfxEfWVZm2y4quQkIh57ZZdBsiQhvanSEXccU3kHkAuTfUBL26F9 /PeWv+6SLwJxynUtYKrh2t5O0Wk79WXtu6RoAe2V1loq24ag2GGoKgG0BwKpB4tbnuRmlivS3BFW i0XZKu4KWJPzA/LORodNIx6aHXqMth7rcoOPjdl9JBNGUcOPEweX24BkDqAIfj4C3bOQ/cP16pLz 7rY97Xiqrjv/AFRK1qSTQ+v0+6YnX7tkdj+X1/YepvwHSPwlyuWx/hWliVf+80T+fVo/5ujL60N6 HjoKuWoty2vjgeT/ALBLqjL7qKn+j/WTrntvW7/l/Yft3/q+X7O/WeXvk7C838SyZbX+GhzSL6nX 8GnfobN/2aaCT4/0d/2a9EP4MEpwnLVp/wDqZwr9vT8X7ufdp/N/p06bXPesTcjUqNa2TZZzCVGZ ly2EyJROWNSnmjNowlnJCgJiNEXTYUDqj+VL3ICbsAiIRT/M04XyXNcH47zLFRyy8fwl60LuwaiJ bkcMcE8gHwjWSIxM59FaZAfxah39sWYx1TO5LCWXVMjerxGDX07hhZ2eJT9rFW3hfi3bOnqAOqvz FKcAAwAYvcDAAh3DuH1KYOsYmRJF0cAr6H/3HoywSp1Hoeu5Wzp+qjHsWa8lISaycfHxrVI7h3JP nhvRbMGyCYGUXXcqnAoFAB/HuP0AR6U1qF7LWosTi4JLOUtyLDDDGrPJNLKdkcSIoLMzsQoVQSde vgzQ1ka1ZkWGrCpd5GIVY0X1Z2Y+gCga6n/29W2bpBr1Xhw4rdicpuZmDqFAhzrLHTUOedYyldbA RsoAmBRRJdIxSGKIiYhe/wC/rcv3KcbscL9gUvEeVyrNn8bgcLVZmIYm5DYoR6RtqdxV1ZUYEkqu uvqegZ8bZKPNefly+JQpQs37soABAELxztqw+wEEEg/AnTpv+El+5b/cU8PwP/aX7v8Apv8AndRb ZmP2Sf8A+atPt/xH7P738/Tpup/2f/5K1+z93/7v5ulXkzGTWe3bPeR9aYuJEKcoWu3iObD/ADXl WfqrpgJQEhkk/UCRXR9Q34OTNf2AIg/e8DEZ/wAWeReLe7TiVeW0mBYUcvBHrukx8zOqkDTYu7vz QmR9ds709AQCVReHrmO5TxzK+JMxIsJyA79ORvgtlAD+3U6dtG2j4xif7SASHe6czd5420HPoOV0 9vKINlISJqyjAjx+o5MJBI6Wk3TRvFlYKAYrv1R9VuYhiimZQPDorbnl/HZLxhB5N8Y0LfLal2NG qV6BjEkrPqNJWlZRXELArZ7gMkDKyGIyDZ1VVfhtiDlT8W5TZgw0sLMJpbIcogX11URqzSFxoYtv yyAghwp3dAgu55ILbk33AOObor5tXjVklcGYizInZmBUv3I8wC4KhNFSWFIFAb+AIh4fh1mtYue7 Kf3Gxe4ceKZBkIsZ9AKX1MBUx6OvfNrdu+p2v29/Y07QCaaenRLxw+JI/G7+OP4sQ1ntfUGftSah /T8sRaadrUbiN+u/5vj1YFTrm8nqkay22rSuaOWYOxmYm1uosPtibFMFnD8JRm7VYLw/oiJyuDCl +UpvMhBAQ61B4Pz27yHhbcs5riLfFLNcSG1XyEkIEAiQPJMLCP2nrBSSJ2EX4X3Im3oXM/x+vjM4 MPg7sGYik29qWssn5hc6KnbdQ6y6+hQBvUjaza9CbmLpbkFyHktmQbqlzjM49eqUVy4ROmE1JrJr gvIkSVTKIlXJIqu+xvFVBP2XkUBOPiDnh+3Y90Xurt+fa8Ug8T8OqvjcQ7qVFqywcNMEYDXcs8tr 5tssKHHhlDMdt48xhj8W+KYfH0jKeW5iUWbiqQe1GCukeoJ/D21i9NVdvqNDoo1O7rSroaOq6PlR 4fO+a/DXRMrrbduvpVeWY6ZkxXAokK4vtPRfChCFXcKIotVbdX5CQhiLKKJpIKSBVVB8CGAbT8Nc 5Tx/zyrmbZIxMoNezpr6QykavoNSe06pKQASQhUepHVZ+XOFvzrhFnEVQDlIiJ6+unrLGDoup0A7 iF4wSQAXBPoD1pP8Duc9w4VT+k5HeWc4ljerSsHG6zXTMHf6mo9opL6QSj7FHQbw6CiDli7cmbzr Eqabx0g2RDuZRomka3f8xr2o8u94ftru8K8TZKjR8jQyQ26gsMqVMtBFLFZfFy2xr9KbDwQy1LTb oEmQxTbIbEkyDr7SfPGO8AeUEyHMq00vFpiYpwobu05tGjFlYj+PYrPHPH6OUO9Q8kKRPug8MI7F ttoda0dtqWb7BX2aBl6fWKraYefgquaQBN5IPLXDNnB1G9ydqCQHLN+iRdmCRSLk9QhCN8Rfb17C ud8Dx1C37r8LPDmsXv8A0zAWkDU6PdYPPcsxrurW7lpwvzq08IijiLPIywpU1Q5x7iONcqeb/pFe jejcCm1ejcCebaNI4UOolghiUn5SI33M3ypq5ljD5LeXfB/jpmsqvdrVVZLbGDJRTP8ANs3cw8ho MxLAgc8bH2ZnFHOFapjs6Piu/lPRTQTAwtAWcgVuqWXkb/LoxPu+wH6FiqFXjWYjGkGdFMIldRoG jkSMRG7GyaqkAYmNysgMahy1Hw+62t4Mme3kLzZFJAQ2OE3ckkJBIZdd4rtr695wFI1BWQ6L1qF8 XMi2n5Xee8aW/vpKxv75Z2V73e4olVTbVTKqsWIjJFJu5BFwDBNnW2LKuwRVAMAulWaZx8fM5dns zZ437e/DVTA4WWeWnh8bFQotaZXtW7CoQJ7JUKrzzy9y5aKBVBaXYNAo6zNw9PN+cfKs2Qvoqvfu NZtdsFYoK4YapGDuKIibYIFYtoe2pY+rdfRzbt27Rug1aoItmrZFJu2bN0iIt27dEhU0UEEUylTS RSTKBSlKAFKUAAA7dZdszOxdyS5OpJ9SSfiSftJ60mVVRQiABANAB6AAfAAfs66PWbaQZu2DxIq7 R82XZukT9/FZs5SOiukbt2HxUSOID/QPSHIUKmVoT4u+gko2YXikQ/Bo5FKOp+5lJB/l6UV7EtWw lquxWeN1dSPiGUgg/wCggHqt2oshoyuh8QtFskvT4a5LP3uYX1i5KxFy2m1hMMSo5V8WopTKyAmF uIlTcLHeMhOBjJeWS3AaQ8bWOUexXy1lr2DwGdllm4/mIpBCJYrT6/StIdqbLZQ7oCVSaVr9AzB5 IdS4ztj+JExXnfidSC/kMeqJkaTrv2tCP3oUatrEDpvALIogsBdA+h3ZnnFZymnRVLqrUEI+OT83 Dk5S+9l5NUpPfTEkqUA9d8+UIAmH+EhAKmQCpkIUulPiHxPxHwpwKl4/4ZD28ZVXWSRgO7asMB3b U7D8U0pA1/oogSKMLFHGijRzDluY5vn5+Q5t91qU6Ko/BFGNdkUY+xEB9PtJJdiXZiX0mkmimRJF MiSSZSkTSTIUiaZCh2KQhCgBSlKAdgAA7B1ZEUMVeJYIFVIUACqoAVQPQAAegA+wD06jTu8jF5CW cnUknUk/tJPx6DXlDpi8qghx9zo33nRNDOhEzKLBQDhW626H1H4STggmIzdy7NM5BIf6oMBWcKeB ATMcAveV5fs5mrF7XfFB/UPKnKnStaSFgRQoyfNMLDjVY5LMQZXRx+TSNizN2k7LOQHhnh8VKRvK XLB9PxTFAyRFxp9RYX0TtqfV1icggj8c3biTcxcKTmf09ln9KrVNjz+q3r8U3Yiv4+AunQAKr56J O4+mL18qoqJQ+hRP2D8OjD8W8Bx3i7x3h/H+LbfUxVJId+mnck9Wml0/o92ZpJCvwXfoPQdU5ynP 2OUciucgtDSW1Oz7fjtX4Imv27ECrr9umvTx6n3TB0BKUqnxr5HWEZ4SsMr3NVOSbzRyelHQNsTc KHEXi3iCLVoR5ILIrj+UiSDlqocwEIfxzKgzMXtF92WVPJj9N4X8kOtiO2Rtgp5IOzHuv+CKNZZ5 YpdAqRw2ak0jrHE+hOPSfy94lqjGfm8142pjMQ9ZJqxUD5R8WYqiunxLPHMigsy6q+08OIrRJuSu dMsYQVhn5E0pNs5xNSXrsgsdoggRwxBuKbyJXEyHmYxRcJnE4iBC9g7uHuO/y+MF5e5Ha8h8Ay/6 byvJWGntRW1+oozs0aqHiMYE1diylnOs6vvIVY1UA+fjf3EXuI4yHjnI6f1WIqw9uF4CIrEYDMxV 92qSr82gB7bLoNWOvoq55j2x1qrVeqPpeCBxUn5nkVaX8q+mVq89M9WHvUI5BhHuXdSVrDk8W4ip B039Q4+omZIhSlM+eJ/b/wCf+G8NwfCMnfxn1GBtiWtkZrU9p6MveYE4uBIIZJMZJjXfHWMbesQ7 5GM0LQRIqMh5d5C8eZrOXs7Vr2uzfi2S1kiSEWE2D/FyM8ipaFlRZS1BHJtA2OrsSRK8ovn/AB1o 8/cphUh3ax1ncpImSbJTdvsT9dy8QiYtoiVNu3F9IOFPbsm5CNWpDHUEClKqr1euVk8Xe0/xxk+e 511fISF5bNgrGlzKXppJZ1rV40Cxx92eSQwVIFStWRpJWCos03UAqjlXlrklXj9BSK6ALFGCxhq1 0VUMsjtqzbI1XuTSFpJCFUEkonUb8TahPhEW/YLmgKNr1+bPPgibyD2tf81VowqRTgUybdcXJgRD t2OzRbnD+LqqfZDwXk36JnfPPP4zHzPneQNxUOv5dHV3r7QfVEkMjdoeoNaOs6nRtBK/OGexZvUO B8fbdhMDWEOv9afQCTUj4sNoLfsleVT8Oi76OrqiehK5QVGebFqG1UtuK9myx8L2SappqHPIVYyp XLv1wREF1WsYoQ/rJl8f/s3Tk4mDwDoEfepwDlMEOB9xHjiLuc34Ra78sYDEz4/cJJQ+w72ihIcS ou3/AIWzbdmAQA3v4V5Binkv+O+SPtwmci7aMSPy7Gm1SuvoGfVdjHX82KJQPm6dkixzfldlaXou xKmqKbls4QFI83TbImgIGRdNxEAMdMFTEVTN2SdtzeaZgAyapZ1fqeIPfL4RRqs5WNyroy7TcxGQ VNDHLGSPmXcUkjbSOzAwkicBoZlYoJeX+DebsJU1YAqQdezbrk+jI37DoCrD5opBtcah0MWN6HzI hGhanFaTTZGGTIDRlaJMgqTbViUoJEBY7qBePTugS/rHF0oA/gt9AEKbqeM/f/xyiOEYTl3H7fH0 URQ5GwN1uOEDaN5kpSymTb/SY2XB+E/oCJjLybwBkZznLuIyEWQJ3PXjOkLP8ToFmRAuv2Dtgj4x /EdSfm2a1PjzWLHbbdZwkp+V/wC87reJk5wUcKeZ1isWBVTuHhyKO1zCBe6jp85OAiAj6SSdxeJv EnA/adwvL8959mha5JcH1GXzFskFzqWEMIYySsGlckKDJZu2GUkM3Zhih/LOW57yxmqeAwFIxY2H 8upThA0UaAb30CoNFA1OixwxggEDe7RthjaV2DVrLyGmWSzCvNG7ip5wydFAFRapAdq8fkHuYOyD c6xFDEMdIzt44IU3ZEQ6pr2x0c75883Zr3Z8kqyVOMRxPjMBBKBvECaxyTD4/hRpRIVLRtZtWo0f SAjqZ+T56HAeEUvEuNlWbJsws5B1PoZG0ZU/0kIVBAYRRRMw/M16NbrRvoceh+5NZm91HKZWKhin NZYJ03tFbKl/nlZSKIuBmyHYBEzlyxcLFQL3AoufT8hAAEQFz3g+H8h5l8KXcNgFZuW4yePI0Av4 nsVg4MSaepeWGSVYl1AM/a3EKCRaXh7mFfhnNoLuQIGIso1exr8BHIR8zf2VdVLn4iPfp6+nXthG uQu20BM74rQ1mjmhIO/Vt0RJQyT8W4t3DhRisQAWhJ9MDKoiJBTMUx0h7nTUAFHtq858d9xHjBXy Agbl1SAU81QlCkrNsKPI0LDRql1Q0keqmMhpICS8UgHn5M4LkPHfKCKxkGHmczUrC6jVN25VDg+k 0J0VwDuBCuPldSRk2rhMR05LPYn7ONUdvm6clSpV2ZvCNk3jgiS8tAvjgqtHIsPUFdZiPmmdIpwb +BwIkcP/AHDf5dsGRuDk3t9MFKaewosYqxIVqIJXAaxUlOrQrESZZarb1aPf9NsdY4JLi8ee4loY jjPIncmWONjHbjXdMxVSVimQaCQvpsSYaMGKmXcu51IbEeM9IxxNCXEv6mvh2xknlskUSgZp65fF w1rrDuojCMjlESCYomcqlEQUVMUfECo9uvtB8deA4Y82F/V/JDQ7ZclOoHb3DR0ow6slWMglSylp 5FZhJMUbYtVeRfMHI+fM1AH6PjIfVa0Z/Fp+Fp39DM/2gHSNTptQEamHd7nR3XS6px1pzj3kVETT ex6nNMjAq2i0osQ7RBXJCKJlexqa4qKh3EhXyjVAwgcVCloT3Nckb3I+XcJ7U+AymfDUsgl7kVuE 7o66Vzoa/cAZe7Ars0gOqfWSVKzssolVZ94xxv8A004fe8r59O3dnrtXx0T+jSGT/a7SQdkhUKv2 mFZpQCu0k3vssT/1Bt/Zf2X/ADYf2T/1D/s3+L1or/D2D/5WH/BfSfh/+m/3H/d/2ehz/Ub3+9f9 93vj/tf6/wDe+/rKfMWcmzdx0i1bvmD9sszesnaRF2rtq4TMku3cIKlMmsiskcSmKYBAQHsPSzJY 7H5jHz4nKwxWcZZieKaKVQ8cscilXjdGBVkdSVZSCCCQR14VrNinYS3Udo7UThkdSVZWU6qykeoI IBBHqD0E0hx+1XIpyQsfG21NyQsm4F3J5paFhcRSy5uwGFmq7VI3VU7ABSqmWZuiplADrr9Z3ZT2 u+a/BHIrXK/aPmohx25L3bGAyL767Ppp+U8rBGPwAkaWrZWNQr2Z+iKq+UuE87xsWJ8uUmOQhTbH kKw2ygf2goLAfaVCSxliSscfWT/fVyrakGPe8cGjiX/gB8ynXX2cVPwA4gkm/RKn3+vb3gh/jft6 VJ7iPerVT9Kv+JYpc5+EzRWpBV3ft0AmTbr/AOb00/penXifHfhOZvqq/LXSh8djwr3dP2epQ6/+ ED93SWvkPIXd3CBNysUdRaERdFyvQKeoideR9MxVSpvlknMmiuAD28TOnTkiZygINe/5gaLHgr3U e5W1EnuOytXjPjVZUkfDYplMk+07gsrrJOjD4aNZsWFjdQy1N3zBbFzzxX4ziZvG9SXJcmKlRdtA gR6+hKArGV+8RxxlgdO9p6dGdV6tA0uBjq1WY1CKhYtH0WjNuBhAO5hOqssqcTLOXThUwnVVUMZR RQwmMIiIj1oHwzhfGPHvGanEOH1IqPHqUeyKJNfTUkszMSWkkdiXkkcs8jks7FiT0PmazWT5Dk5c xmJmnyEzaszf6gAB6KqjQKqgKqgAAAdODqUdNfXOudc6o1+SX4Sck5qzUrsWVzrLE+Qj9MFJuTGN M7z3SnSSfgk5u0THlLIRViOBSENNMQVVOmA+5auz+B0yJ8Ue4PN8ArpgszG2Q4wp+Rd2k8A/ZEzf KyfE9p9AD+B0GoNB+T/BGG51O+bxEi0OSMPmbbrDOf2yqPVX+A7qakj8SOdCNaC/fBj8mNAl12cf hjO/MU3CzZtZM70ahP4x+Qg9iuW7ObsNctDZquX6lF1HtzdvoYpR+nRa433FeJMnAJJci1aQgExz wTKw+4lEeMkf2Xb7iehayPgLynjpikdBbEYJAeGaEqfvAZ0kAP8AaRfvHUy4F/w8/O3T5tiGts6X x3qBjN1ZGXs9mg7vZhZqKlKsEJUqDLTKDqSSSETAjISMUmPbsKoD9OmHkvug8cYiu36I1jKXvUKs cbwx6/ZvkmVSFP7USQ/d0+cd9t3kDKzr+srBjaXoWaR1lfT7dscLMC33O8Y+/rb24R8EsJ4F5cfO sciHDiUnFGUhoOiz/t3N00KbZIqpNnc08QSSRaRMWVyqWOjGxU2bEiyhilO4XcuFwd8heR+R+Scx +qZ5wIYwVhgTURQITqQgJJLNoC8jas5ABIVUVTN4H4/4/wCPcT+m4RCZpCDNM+hlmYDQFiPQKup2 IuipqToWZmYzuoD1OOudc651GGqZFS9hr4wNvj/VFH1FIuWa+mlLQ66gEBRVi4UTVIKS3pl9VFQp 0VfEomL5EIYtOeavBPj3z1xf+Gud1S7RlmrWotq2artpq0MhVhtfavcidXik2qWTekbpMuFc75Dw LKfqeBl2htBJE2pilUa6B1BB1Gp2spDLqQDozAjU0znltlhAj6DoNd0isNv5UdF3VI4yrVsQABFI rl4sg5TSRIPiUoyaxQAodilDsACHT8Ue+bwwn6X4y5TieXcQi+WCvllP1EaD8K75WR1VR8qqMhIo CjRFGg6t+flvgvmjfVcnxVvEZh/WSSoR22Y/E7UBUkn1J+nU6n1JPqfVevc1b6UY6Zs9Jy2KUD03 bmuEKrMqJHECnFm6QWnl0lSlERD012hu4fRQB+vXrY4t/mG+TUOK5BmOO8Lw7ekslABrTKfQ9qRG uOrgEkFJ6x1H7wH16848r7eOMH6vH08jmro9VWwdIgR8N6kQqQft3JKP7J6mvHMApmOIOXUcLiet kp6gzVwmP5sq9MucqrhNDzUXMybOFygdQPUUWWMACqqp4k8SI8B+2DgHgSvNfxZlyfObu428pa+a zKXYO6xgl+zG7je43vLIwUzTS7I9ld8/8ocg59IkFvZWwcOnaqxekaaDRS2gG9lHovoqqNdiJubW dOiS6rbrnXOudMq/59VtNrL2qW6PK/i3fZQhiiCbxg8TIciEhHOBKf27xAFDAA9jEOQxiKFOmc5D V55Q8W8L8w8QscJ51VFnDT/MpB2ywSqCEngk0PblQMwB0ZWVmjkR4ndGkPF+U5rh2YjzeClMV2P0 P2q6EglJF1G5G0HpqCCAylXVWAiMKLylwgv2vOJSG12gNu4RlfsqoNpiIaFH8rRqu5fs3LdJIg+K aaTl2j+XuRBIB8OgVxnjf3oe2tRhvE9zH868Yw+lelfYR2qsQP7uNpJoXQKpCokVixF8pKV4tdnV 72uS+FvJZ+t5bDYwXJ3/AHk9cbopW/rMFR1Yk+pZo4m9dGkf8XSsfZOV8wUI+E47sIeSP/LPIzk0 4UjUjCAAKxCOfsKJwII9wAXIh/h6eZPP/vczy/pXHPFVahlz8vfuWnNdSfQuBIaaaD4gfUMD8PX7 UK8A8IUD9VkeVy2Kg9RHDCokP3Er3iNfh+7/ANXXtV+N1xvNlY37klaUrfIR4irDUWNH06vEiYxT gk4RSIizMn+UAVRSIcXHiALOFk/JMVPDfaVz/wAk8ureTfdxmkzuSqndVw1c6Y6tqQ22RVCRFfQC WKJG7+xfqLU8e6JvPNeXMBxvDycY8RUmoVZfSW5J62Jfs1UkltftVmI2antxRto4NIpSkKUhClIQ hQKQhQApSlKHYpSlDsBSlAOwAH4daEoiRoI4wFjUAAAaAAegAA+AH2DoeiSxLMSWJ9T126+uuuuC ACAgIdwH6CA/UBAfxAQ66IBGh9QeufD1Hx6ES18ZZCJsLm64RcVcznnZvN7BdlTVR8YxhOYCoIpu fZNxOYT+3O3dtQN29NNIADoCueezPJYjlk3kj2zcgl4Zy2c6zVV3fps5JJI7arII49SW7EkFmuG0 7UUIA6vvA+Zq9vEpxvybj1zWIj/BKdPqU+z8RKlm0AG9ZIpCPxs5PSWD/m00D7f9kzeTEvZL7767 JP1P2e5FL7nH9h/b29kX/J/Z0xi//mRUdMT9Hw67t+X609pS32dzYLUA+/T6Rf7n2dLux7bp/wDi +9mYdfXs/MQP7OvakP3fvT/e6/WPHG/aFKsprkJoR7KyYrlctaTWzrM4QDiAiJXDhJvFpoB4mFNT 2zYq6hPp7kOu8V7QPJvlTO1uS+6/lj5unVkEkWIoloqSt6/iZI66J6ExuYIBM6en1Y66teYOM8Vo y4zxRiVoyyrte3OA85H3AtIW+G5Q8mxT/sujCjo5hEMGcXFs20fGx7dJoxYs0U27Vo1QICaLdugk UqaSSRCgAFAAAA60BxWKxmCxsGGwteGriasSxQwxIsccUaAKqIigKqqAAAAAOh/tW7N6zJcuyPLb lcs7uSzMzHUsxPqST8Seszpw6T9c651zoTNR42O5G0jqGNWY2caV3VUeqI+ScHYDrGBRx9wRTQdJ oneHDycAdu5buDh5mSKqYywg75m9o9/K80PmX2/5c8T8ufO0xXUU7zOQXM6KsgRpWAacNDPBYcB5 IBKzztePDPLsFTC/wZ5ApjLcQ9AgPrNAB6LsJKkhB6IQ8bxj5VcoFjDVQ1Pl3VShH2jDoa5qpgCa c1WpQzMrzt9PXXbsFJ5FIT/iIeLf/IDqFQ+avfXwlP0zmPjejyCdPRbWPsGMSj+u6QtcVSftASD+ 4vw6e5OFeCc2fqsNySxj0J1MViMNt+4M4hJ0/lf+8esR6nzE2AgxLplAYdVnnkm+fMngurKqzN9F EkXKbpzJt1jlN9PSRjzD27esX8RQ5BPft55jOEt1sZ454VYBWaaOUvkGiI0ZVdZZLCOdfl7cdInT QzqCdfeu3gPgTfXQyWuSZqP1RHTbXDfYSpVY2A/tPOB8e2eiMyDF6fjECeJrSCjh++FNWcsD4CHk 5hymBhAVTlAQbs0lFDikgURKQTmMYTqGOocsfBHt84H7f+NNhOJRvNlLO1rl6bQ2LUig6biPwRIS xihUlU3MzNJK8kr1NzzyFn/IOTF7LsErR6iGBNe3Ep/YP6TEABnPqdAAFRVVZc6vTqC9axnMflzy lrvM/mzlWOb3vTPUMwHia44g8d80x6C0yhaJK3umVyW1yE0xcuazbqIhwTMLxFy/n4f0QcuVETOC olQIXfA+EcOtcB4/ms9jca2HufqQyd6xaevNAsMrrWeuO+gZv6JVIZddqBgu7cRP5xzTl1XnWew+ DyORXLVP0442lBWSeGZpokayk57DlV/pBnmj03MVLbdosYcfJg+aADEcWRezZfknY/HEKKOgC2Yq 2d3nRLeOlgsenuFG8WnPm+3mjOyhytwFyDsxg9AasXxJG/5n6gVr/wAJnOamHUiMT9rsad0ats+f uegLfJsA+bqzm8qyJ+X9AGsfxUMJoJtB3DD3O/r2zou/5Nnqdvz7z+HpB4F8peV2hcPuSWybBSob R9Eyy/8AItHO67XLfEA9vq+aydnM2y0qsHRYhhBEjJaJTg4yUO3fLySChHiyZTD4HU+SeHcLxnOs TgcFYkqYu5Womd3ibSETrHrY0eZi+5WM0ke5BGQY1JHqE/jrl3MclwnKZzNwR2snTs3RCiSLrMYG k0r/ACRKE2soijk0cuCHYD4Fml+YJhY2NJSzvHoazWTSapwmhKjGuNRWRiEORnNpOyy9cyK0TkbQ ZQIaBzOoUuVkpqaBBVyqdBNsWPROqByrz4MkqSWGyl6SGpUmyzysK4LGjie2r2Y0aZd72JZY44ot QoBLmVgNCh/62x2o64xlFJbVqHFrGpsEKLuU3slaR1hbakEcUjyy6FjoFEak6h70H5Sl7ZeMIzCX xBOIveh3fnHlWptGGjJy0RmOkcIaswslhYQUiaoMjXyv3wko3Bo7EkYoxIsAmSX8R6bsn4cWljsl mIMiXxtWviLFcmDa1iDLSNGhde6ey8O1ty6yByPQrr0vxvl1rmQx2Jnx4TI2bGVr2AJ9ywT4qMO4 Ru2O8k25draRlAfUNp16cfvko1HklqGF59nnFP1IfScHyvkRpd4ebNDoRuQ0XQ5+81122+0vKfHy V4mWT+poFZJM/RO8ByqdUjYjbur1ybxPh+J4fI5PKZrSepkrFGCEVWLWZoEhcHcJWWFSsh3ltQu1 QC5f5frjflPL8py+PxuMw+sFrHV7s8psqFrRTPKhG0xhpWBjG0LoW3EkKF9RZ5n81eSWGc8Nno8P f3sJx8DiZ+m49daKglonLOQ+oUDXZ3E76aQWhHDtFWZu+WpwxBfLLRvuJJMiiJhOQSTLgPj/AIny LxvQyM9ZZOT/AK33GAZw1ilXmrJbh2hwDthsGU7AJNsZIb0OsQ51zzlPH/Il/HwWWj41+jbFJVCt e7PDZerNuKEjdLXEQ3kpucAr6jTJyL5kk4VpxzzO6xNdvM+lkvCJHdLpP6IyqmrWrQOUue16eeWL JMiYUx0x0KvZupMtHlucEkoozMsiBWzY4IiJ/jOeBzYfK5fHvLWrG7ljTiSAyVo4cfO6BLNlpQYH n2stZTHJu2fO43en1hfOIgTF4q+kViyKWKFuV5hHYkmvwo5etWEREyQblay2+Pbv+VDt9cnjl8mf IWkvbqly5otdkalJc0uYuLIaDAX2PVa5GOE57ZdGZZcnGx+ZV5O3RDReprRMTMu120jJoqndLplM gCSvxyvxHxfIR124RYlS8mAxdowPCwNn6yeOA2NzWH7TESCSWJQyRkBFOjbl++L+VuS0JJ15pXia k+dydUTJMNK30kLzivtECdxQYzHHKxV3BLsNV0LshPm9qL3HUdYm8LlYRzCcb7/u2kUlK7qSc5Sr JGchonjbk+UuDkpLQxZbV7jNt5D3ztBn9rh/Nf2rrt26RWPb1ejzpwtfIpIkmWhpwS9raksbUmvW bI/NPy1okZNilu5Lou9Ollfz7SkwYzNjHvG8eLmtzxd3c8TrdWjXrn8ofNYlcPvYL249W2P0+bp8 pWt56EhmctxVgbZymg+Umf8AF+Sx6l7qgSqSUrsONyevZZc4HTLLnEQ1CGlUGHsJFB8xaHjTFUXM qYABIW7H+HMJlNuXgzMkHDZMNNkFtS0z3FWraWtYievHOx3KW3oUdg/ooA+PThf8u5nGbsVNh45u Xx5eGg1aK2O2zWazWa8qTyQKNrAbHDopT1Yk/Dpl8YPkD1uw8stn4oy7NXWNje8qbQm6p0jMxVXq 3GfjVU8/oMhcp1K0saudfQzxeh2FzBwUeVAruWVSM5XdNUOwmcOYeMcJV4VQ5pAwpYFcNHpKqtJJ fvyTTLEnbMmkG6BFmmfdtjBCKjt8EPEvJOas8yvcOnU3M42Yk1iZljjo0Y4YTK/cEes22Z2iiTTd IQXZ0X4ldz8542XhQ0j55PMKDO0xCmTl1mLXpm6QGTEtL+Dk2LIuO41WUa9d7louxS0e6UkSomjm MMzZIlFZ6KivgnC/Gnjep5BdqxuWY75sJEsdem9ntq6k/VWpC8MUFVWATXe8rOTtj0GpmHkfyJb4 Ei2BUrSURA8rST20r9wowH01ZAkss1llJfTYkSoPmk1OgYnE7k/yJ2Pn3zDzmyx0J/s80vN+OV0z dgpYIgtgo6Om06QsMEr9raVBlLzz3SY8q7yYTdSSyNcdR6LZsZyR0KvTjzXiHFsD40wWVqNJ/FFi 3einbY2yY15VR/mMpVBA2ixFYwZ1dncIU06b+G8t5PnPI2bxdpY/4agq0pYBvXfEJ4mdPlEYZzOu rShnIgZFRSwfXqv6+84eezS7bVDkdwsc6pvym8ZcEzunwNtp6qNgq96ZOTy+CyVld5ogaEq9wjTM 3y1ndpOH7J44VbFJ4ICJrNxnjzxs+Px85WR0n4bfuTyvFKCkkJG24sYnO+SJtyCupVHVVcnVvSt8 jz/yKl+/AGjR4OX0acMSSRkPHKDuqM5gGyORdrmdgzqzFANF9Z5ufzRzFKqkRHz2E55Vdpb6dyuz e71W+8hmlUzONkeJRohGxx9S0s2dSD21WbS5aeaxNaZHhmZFpL1fXWTQIRRWN0PAUGQuvLWyVqbA Gnjp4pIaRksMuS3FGkg76iOOBUaSdxKxEe3apYkLIr3naehTSKzjq0OeFvIQSxzXRHArY7bvEc/Z YySTs6xwL2lBfXcwUAmfuZPMm5veBOI7bx6lpbL7Hyuu3HOiVmyysPFydmy+O2+YjhnHZomSQfwr iywUUV0wAwlVRTcH9ZEwiVJTqM8D4HQj8lZDj3KES5Uwte9NJGrMsdhqitsG5SHEbttf7CVG1h6k dSPnPOb0njqhn+NO9S1mbFKKN2VWkrraZd52sCpkRdyfaA3zKfQHqN7nyI2z42Y1/SNk2ymcko7X t5hKPxdte9abH57MZ1Tz01efvz/lFrELmCEOyjK67aJnjRZQ8hIPRegQBKmJE2ztQ4vx/wAsSrkM Dj7GJlo415shHTrtOs8vdCQrj6z2CxZwSJN8qIuzX1Opdrvcmz3iyJqGcvwZWK7kVioSW51haGPt F5jfsLAFCoQCm2N3bdp6DQLHhvmvtllpkTaMw4kjOro8MLLzLvrG6bWyo4U2tZvslwx3SKyxMGeT p7WunJ1VN1BOkganlW0giY7ZuJTk6dB7fqVS+9PL5vtqc/Hi4TFUM3dknqxWoJD+enbG2QrMp3CN kYB31B6bD55uWqKW8The4wwT5OYS2hF2kgsy1p4x+S/cO6MNEw2mRXUlF0I6TXfyhbZmGqc+9Svd MjbRxzyfKuHdqxqimutcrs1A2TkixaNs/Zy0opTEVkY/QBl15O0O3j18FUShwTZIPwXEevVPD/H8 xhuM4bG2Hh5Vdu5SO1N2ndHjokmYqvdILQ7RHXVUT6gy6yNFt68n8t57E5jkeXyECTcYp08bJWi7 qIyPeAEIZu0CFm3GSdmZ/pxFpGsm7p9Rny96NcIrOIHJOLlU2rXb5yB2XjqhCULkbBJ5lMz2X0Cu 6PE6Fn2oTtDj2lrze11efO5Mu7aRTpl7Bwl6aynpAo3TeDsVQmt2c3mJsfg62Mq3i81F/qESxM8D QT10mYxzxyIF0VpFbep1UbtHCLzXlLsNWthcRDfzVjJWaQWG6nYZ68KTrNDYeFRJBJG5bVljZdjD Rjt1MDmJzVvXHW0ZZmGY4tFa5q2iZ9sesP4iwaQTOarWqLhdUZ2e3iaxEqtteSljnF3ycfENiMk2 5lxMq5XQSJ3NBuCeP8dymnczGXyD0cLVtVawZIO/JJNckMcXydyILGgBeVi5bTQIrMfSbc355kOM W6eJxNBLuYtVrNgq8/YjSGpGJJPn7chZ3JCRqFA11Lsqj1ErCOVG+coPkhyZ9COJup8U5ngpSOSF YzxtfoRoMghp55+C/VOl1xGkSTyw2WLuorwacQ2mm7NknFtZYjlQVlWSs25Jw3jXD/FN2OwI5+aR 8jmoyTmFztNfY/bgcyqEjaLSYytEzOZHgKDasghvHuX8j5b5RpSVzJDw+Tj0V2OETINRPvTuToIm LususQjWUKgjSYOdxjIscqudXOqkaT8ptbgJNlXarx40HgzE5X+np+mupyjRmtWSutft8KEzmyCd kcbvVHjiRlRl3ahKk8ArJsZ0kYXJJjwzxz45yGJ4bbso0tzKVcu1jekoSZq0bnc+yc9sU5AqR9pQ bK6yOEb5DD+YeQvIVDKcvq1nWKnjLOJWvseIvEth0G1d0A3m3GS8ncYiu35alx84LSb+XaVrETKV S95HlOTbtG8or1xweQ+m8i0obC4FvRMyj9Vf3qy7YjmR1GTZ9HSraIaMSQhlXMuumHqJlOJCwqv4 PhuTpdxt67d44+HhvBq9EvbczWGriGOobHqQytKz93RYgfQkamZ2PNM1SF6eRpU6XIVy8tIrPd21 EEUC2DK9rsegKssap2tWkI9QDoHdyf5wW67fD9dObmCr2LG7rNUGp2Kug+bRklO0qaDXK5SLXF/9 8xCsbKoJLpSDRF0oyIDpqcq5E0hOUCIeH+PKOP8AOdfx7yQRX8fHZkR9CypKn00ksbfK25SRsYqH O1gVJOh1W8t5/dv+E5+fcdMtG/JWjdNQrPE31KRSL8ylWGu9QxUblIYAajQMN35RbrxgrnNzLLzv 287DU6Jxv4sciM/vcZL5dmvIGmutM2Ws0C3VaN0iHyuRqDiJeuXQLid3WXK5I8yzVISqH9yM+45w 7jnMLfHszjsZjaF2zlcjRmhZbE9KUV6sk0UjQNYWUMANPlsKC+121A2dQXkPLuQ8Sq5/EZDJZG9S r4vH3YZlavBciM9mOGSNZ1rtGVJOvzQMdm5F0J3dGnHfKLapbkI0zWE47ISOKv8AmxK8EmOzPdaa x1nHVKbVk7BdJhxlwUd0detpqGOSPXSlwByRuYy3t1FE0eoBL4epQcYbLWMoU5AvH1zBqisWj+nl k2RKLHdGknwLgx/KWAXcAW6ncXlu5NyVcVXxgbAtnmxIsmwFk+oij3ysa/aOqD1CESfMAS20kL0H nD7nNyqvGhcII+sRV2v2IaVhXK+8WGF03V6Bdd30SUy3YrHXpF+8m2eW57ErWOqPGKEXWY1BaJjp Fi8D3rlIWh1xnXOvHXDMdi+Qy23r1uQ1MjjoUevWmipwLYqo6qENidgkgJksSESOjr+Wh3heoRwn yDzDIZPAR1EsWcBax+QldJ7EMtuZq9l0YlxXhUvGQI4EBjR0b8xhsLdK28fKbsF443cqWlFToGNb VhjXirc/1JiuxVrkNF16J2jeKzn1ly22zilEiqrHavSkFlmc2gxCYjQOuYEHXkmAm8eN+G8FjuV4 Z8ibN/j+RbIxdu3VkpM7Vack0diNO80jVpSA0RftPoBuTQ9e3IvL2byHFswmPFajnseMfLvq2Uuq i2raQvXkftLGtiIErKE7iak7X1HrYdzI2XUM55W/G/Q6RcH1ep+zbJp9a0+Cas4lw2t8JCZ4nNxL B6u/j3b5mmykiioUzRVucwmEDCYOwBV3A8Dh8rwvleSyMCy3qFCvJXclgYnefYxAVgDqvp8wYfs6 sznGcy+L5jxbHY+doqV69Ok6AKRIiQ71BJUkaN6/KQf29Bb8i/L3ZMWsfPGPxKxaBF3nLuK+HXGO dy93rKmZUyLvmkvKrO3Kj0RxnjqUR0lq3MRH1XUw4bOirAomk3O2L60/8WcHwOfq8bl5DFVfHXMz biYLFJ9RK0MAkSKaYThTAT66LErLpoSwc7YJ5O5rnMDa5FFgJbKZCph6kqlpY+xEs05jeWKIwlhO B6atKVbXUBSg3LlU+UKUxHWcq4i6JT0brZqlcOP/ABz1+yTW9Q103x7rev09nNubxWKPFZxWkNOy mky8tHx07YRNAOTO3w+1jVAQ8Vk13w/DyHCXecYuc16k8F29VjSm0VMVq0pQQyTNPIa9mVVd4YPz l2p88o3fKop+WpsBmafC8nALFuGenSsu1tZbhs2Yw5ljiWCMT14mZElm/Jbc/wAkR2/My7F8qu+7 VxJ5a6ji+R0fM5fNMluNvrk+pvFJsOl47J1fQ5WiyVc3TFp6mJWKkauaAh1rHCx3sJeAkkPFmrJo uQ8DOFXwzxrj/NsJh8/esW4Ld6KKRPo5UgtLJAsyyU7SSmOatvYQSvvimjOrrCyeoQ2fMHI89wzM 5fBUq9SapSlkR/q4nnrNHM0TJbqvFvisbFM8SbJIXHyGVX9DLtD+UzRYeQisd2HAo1htwaVwVyaK cwmphM1LQ0uY9fmJdHTY+QRzeIdNI6is6pIqyrVuxXbi6IKCbkhCiqDHkvDmLnifO4LJu3HvpMvZ YPX2SQfpbqprspnYFpjIgjYuDtO4oSdOnrHeXcnDImDzeOVc/wDVYmupWxujm/U0Zu+pECkLEI3M iqhG4bQwA16HOj/LZeMO4950vozyobZp9td8x9IXntT0WOxRCUzPAtptNIrmfUs0Hntnb2rZL0jF gyrsKm0QIudEBXc9zAPUqyPhLHci5PaXFLPj8PAuLgCV4GtlZ7lWOaSaXfPGY6sJbfPKWJAPyp6d RfH+Zshx/jVVso0F/LTNk5y9iZaoaCnakiSGLZDIJLMu3bDEFAJHzN69Wkf/ACD5T/6J1X/cM/8A kH/8rof6qf8A0T/aX+tX/wDV/wAH/wBbqnf+mGa/5il/+yfov7w/4n/e/h/w/wD2nx/s9W7/ANSs P/y9z/8AXf1n92P8P/uvxf4j/s/h/a6ceM41llQ5jc0NhqWyMLfpuvsOOrXXsfZzFZdvcgLQs9kY HPHM1ERTxWxxB73Ancv2gyqKIuEwUM2E6QD2SZ/PZm9wTAYK7QaDEUWvGtaKyAWe9OrzhGYBG7L7 Ubtk7ToH0bpTgsHiKXOM7m6V5Z8tdWkLNYNGTW7MLJCWVTvXvJude4BqNSmo6Bd7wnxBfdnehhz4 immcD8ldZ5BReEkXxM8e15vsocidkyeQu7lytc5O82KtppJNKomdrIRrHzUBo4WOVySxo/IPIV44 uL/hp2yv8JSUmuaW9xxJb8uysIAiWFJNS1khkkfQb1UbDXz8CwDchbJjkaLi/wCKo7i1Nau0ZUL8 9cyk91pXTQLXBV0TU7GY7wX3EPHa1x6zXe3OD7AvycpVh1HWdDo9HjpvNVGlUvj6Zn5e35ZGX6EO iyWkXtyW9m4UmnIDGOCdlQRAFe8G5xnbfKMtjU5JRGIyEVOtBNMyT6yQhUWKw0L6kKIhuURL+Yp9 N3y9TbhWEq8axWRbjt45ahLbsTRRK8GkcxZ2krrMugLGU7SZW/LYeu35uqguF/D/AI3TXE2Siz8j cFxDX7T8g9b5BYO6zvccX3dbDdcixkW/GXDZyRhbOaj7JaEKsymVE4NuqmaXQfuBQIBkT+F5c+5z yuvzVJhislkcHDxiSlcE9S1TFus2037aK8feqxmQxAzMD2ii7jow1pTgnCeLWOGvCcpjsfm5uSpc qGG3VtmpZXcKNR2WTtWZBGJSIlI7gdto1U6E2HBbBXr7BmdD+QuKrvJCh7LzTsdr0OvOcIl7br2m bLEQhOY8OxzZ6u+g6naqRXW7NJVs0avVKayVIo7bnVFJckQ/6jckjjyUmS4u8vFLNDFJHA4uLFWr 1Wf9LYzgB5I5XLEMzILTAhGA3KZX/wBPeOySY5MdyZIuU172UeSZDUaSzPZVP1NRASUjkiQKCqqx rKQXUnawJzhDxp48YveKvN5ByWgNnlozh5kuSR0HEWOgTJ5LKqtd7pNVTWU0arIPXqsTZZaXeMkH afeOWM0OVNVRQpvGI+Q+W8oz+Omr5zEy0IHztmyzsky7bMkUSSVtZFADRqquVPzjcCQARrLOAcV4 zgshDYwmVjvzJhK9dUV4W3V45ZWjsaRsTtdmZAw+Q7ToSQdGhy/4q8TtUmuZcluXKGrZux2DDMFo OpQs/dM7rTTH2VP0N/PY7o8otPyjFzFKWC7mO2j/ALkZBpIqlVbomUMYSlXcG5nzXDV8DFx3DzW5 KORuTV3SKeQ2jLAqWoFCKQ2yLRn7erICGYDTUoubcP4bmJ85LyDLw1Y7uPqQ2FeWFBWEUxetOxdg V3y6qm/RXOqqTroGDiXB/Ho7TYSb41c8zJV6FpHDdpyYoOXzGZWGe1wuB0CLZ4bNzNzhZh7P5JVd cpTJsvMMY5AqNrijD6C5EFTGM5ch8h52XESV+W8b1tSWMoaE1hbCJW+smY20WJ1CWZK0pYRO51ry fiUsAA3YDgGEiy0c/FeRaVY6+MF6Gu0DvZ+jhUVGaVGL1o7MQUyIg0sR/hYKTqwdu4J8P7pifJKn 3bnpX6pjms83bDsbGVkLhiEXFYjyRXC+PdXzKCtyzmM9ewykHMu2zqEkXIyMUwjR7JAIvTrOfHvI 3OaHIMTex/G5Zs7S48lUqsVtmt0R2RWsPEA2iK6qyyouyR5Pxfuwrbn/AB7wm/gcpSv8iihwdzPv ZDGSqq1bx7xsQJISursjMrRO2+NE+H7wsoW3hj8b0+7+R5xNcscujGfJRlmBNbZsNZyiGLxpc1e5 x7yqvfWJOF/T6Nh2H7UuCEwVBF0+RRZEAwqiBvKjz7yvWTii18Lcd8S1j6YmtZf68SRMJBps+cpV 7g1i1KoWkP4fT0u8F8XWX5Q0+ZqImVWD6kCxXX6ExygxnXf8gez2zpJoGcLGPj6vyL4f4ix0atSW z836ffOU0VzfxXdNGsByZFndjuupVXH3tRxTCS5hHTbkaehJZcC75iwS9xNSxDLvUzHT8RSbZudc hkxU0OA49PW4c/HrdOBP+JnSKvJaEtu59QyDulbGiO50ijO2MgHXc5Q8JwEeUilzufgscuTP1bc7 /wDDQvLYjrGOrU7Cse2Gg1dEGssg3SAkabekXxK4fr8qJiw5/wAu85i+YxuZFm5GItK5YcfkNsYN V6J9g1HjTL1lCTPcJbM5GnN1nD5msgm9ju6joBIJljKdzc25yvDY6uTwdp+CfoMdEl0tLUYibfXv rIV7S2FlIVGBKP6J66KB1FwzhLcvezjc1VTm/wCuSXQEes1oAw7LFFow3caBogS6kBk9X9NWJXee HErD9v3KZuNm5n1fjhc5jh9eMl1qmzamRS0vKcZ3dmk5yTu8M30SRbSmaRDCyOXDaYsbdFRuuyJ7 UFmipTLim8b825Dx7jsdCpgJsrQjzsNmtKn1Kqt8RqiwsYFKzsYwrRQMQyud+1wQvSjyJwzj+f5A 963nYcXefCS17MT/AEzM1EyM7SqJmDQKHLLJOAQVGzchBbqcuO3HXMqDym0vWMu5MpXWcncJ4/0P acYjX2dziAjS6YjEYnp8qWI9e2Uwk9T2cgvHt/JNhKFeOF0zKpppAlHeU8py+T4bUwuYxBr148ld mq2mE6H82Utbrru0jl2SlA59Xj2qpCknWQcZ4xicdy+1mcRlRPYkx1OG1VUwuPyottWdtuskW+MO UHokm5mBYAaD/aeHfGeR26+3x5zKiYxCwc9uNu2P8teWfJzNq5yozgCKV3LSvlnLayJWjUIcySKE Auf7l6JSHbIqj9Rk1PnXLYuPVsamBd2i41fqCwI7OsmOn/HY0AMfbrtqTMB29dQ7DqN3OEcUlz9n IvnERZeR0bRrmSvomQg/BX1JD9yddAIT8+mhVT0ypPg7jM1pclJYX8gcTnfIWV5H81r0wdQKmN3q xxTfc5Copch8iiKY6lkpdGzZNNxDNRCWKqEpWn7wfeIH80U03GLyJnq+JSHkfGHtcXTFYqFg/wBV CjGosppWWlClTHZRmDR6dudF/LYaMSgl4Bgp8q8vHuSJV5M+UykoKfTSuotmP62ssRbcJK7KpEgP cgdvnU6qAanJ7jviF24kVLAtY3aYoUJCvMkhc13m8aBXQ0EuuUl/Fnze0L2u4C3irjoNknYsPdIC Qq8ud04IiCSihDp1/wAQ5TyHH83n5LhcbHZsSLZeenDC/Z+mlDd+MRxatFDGjfKddIgqltwBBnnL eM4C/wAMh45mci9avG1ZYLcsyd76mIr2JDJJosszuvzDTWQswXaSCAeNwhyFq9kWst8htVfc9F+V EDrrjaJiMwr74nsDHJ31VjMwcccfuqEMWJfZM8WefZSKpSpwKR8muVBIqfVhjyFnHjR4OLzL42GG esKqtc2fSmyJGsC9tL7hZAXu6GMesZUsdeq//gHCJIyTcmhbyKcwlk2mWpv+pFcxrAaW4LtNclu1 qJD6SBgo06ctq4K8c4qWv8XqHOOTkdBf/G3e+POkyur6FQX1/Rx+0bZMaFbeSVkVsMshKx9YibpK LQrVVyUsHGNEUWXuBURARSUvI3Kpoa02H46iYteWQ3YFrQTCE2o6iwR0E2KVaRolErBfzpGLSbNG 6V3PHvGIZrMOX5A7ZJuLS0p2sTQmYVpLTTSXnLsGWNZWMSlvyo1Cx7tV6R7/AMIOKlhT3gXPOqNq 9fu+I8OKJpTAlsxEWlVv+UlrX+x9s0nIyYHdwZrUEKr9uhVVG8dayybj26hxBsKCjGeQ+Z1TjdvH Hms18hlJoG7dvWSGz3P1Oqqr6P2943ygM9btruA+fd4ZLgHD7IyO/kKw1rGPxkM47lXSOavs/TbT M3qnc2HZESqWO420n5ds4wfECr1bWOJtt3LmxM6XuVK2fb9RqDS5uaBVk9WtGgZdB1GcomU56D5V 3UqLntPhU5BCDg1XwN1Hbl0uYQWKZOO2Oc3LmFzdLjvH46nHbFCpXlMQmk+mjhsPKk1mfTSSaeVy hmmCbgqIo+Ugv8HCalTM4a7yDPSWuQQX7ViMSmGP6iSaBI3hrw66xxQxKHEURfQs7sfmGjt5y8ba JumhZRMs+VcZxi3Kp51uUDDrrpZ7ZHtww6912MitrKFGu0jGulUa5EtUF055qp6MEoqKrlNYpiAR D465ZkuOYy7Xkwr5jjs9qo7AGeMRW4XZqn50SsNXYkGFhrMBtQqQdVvkDi2O5Dkqc6ZhMTyCGrbR Sey5lqTIq2vypWU6IoBEynSInVg2o09eMXHfjTnG459d8V5AQV6Xr/A3LcKoecx1uoVodSmDVS8v 5Ws7aLyvLhLTzKz2UztsMs3QThnLo6pEh8ilTT65fynluV47ax/IMZJWWXkli5NO0U0YW5JCqyVN HG1DHHtbtsTKqhS3oST9cT4zxXF8grZDA5KOw0XHa9SGBZIZC1SOUtHa1Q7nEkm5e4AImYsB6gAD tya4XcaNL1jmXcZ3m/FZK31tfiUXk5nTixYyo0oV6zKTqbnjvMz72zKJWPP3txhoQzSLj3qqCM0a TVWTK5ErYiUo4jz7luJwuBoVuPPdaiMl9BOEtazQ2FkF5UEeqTCJ33SOgJi7aqSnzloxyvgnFMrm c7esZ9KS3Tjvr4S9XSGWBozSZzJ88JlVNsaMQJe4WAf5QvrbeHuFSmu2yx5Nzio+c8qJfmBpWwUO Rco41o81SdFsWLNKTq+NnymfmUQtqjbLzIyKjVcqMtEdkXw9iAIqdUudcjhwcFXN8dsWuGpgoKsy g2oElgS2Za1r6lEPb1saoGGscvzR/H4d3eE8emzU1rDcgr1eYPm57MLEVp3imeqIrFb6d2Hc0g0c qdJI/lk+HxJvkJxkyyZ+PO0cZNk5Jz9dzT9H1WCunJXV7lXHVgOpFXuv2A9itduuTlnXQcT9jZkZ fz1UyJFclQRMByp9RHi/LszX8oQ8uwOJily3fkeKhWicJ80LpsjiiBfRIyX9AddpZhoT1LOS8TxE /jSbimcyskWK7EaS3rEqF/lmR98kkpCau4C+pGm4KvqB0IOn8F+OT7JOWFJ5L8+0bBqew5xgjDVN n0Gw4hQ3+WYnQNJh5fKWzGixwV2r1Go221svYjJPQ8JZ8uHoqe57+c5w/kXlUebwuQ4lxkxYajbu NXqwJbmWxbmgZbJMzb5JZYozv7aesaD5hs+EJy3j7i8mFzNDlXIxJl71WmLFqZ6sJr1YZ1auBEuy OOOSQbN7ekjn5Tu+I3tsMkJrnTWbBSJGLz3IYf5Rbtp08d9yx43XzCLTrbbNhaWeIpdFhvtfIaF5 UXxdADv6VJIuWdYSBcUDqoLionK35FFX8czVcij2s5Jw+KummNvQ3I6xn1jaWZt1J8dCDoluMq1g 7dwDLoYuvH5Z/IUVmg6VsKnLpZ31yNGapJZEGkixRLturkJiNXquGWAbtpKtqJ1o3BDhzH5Rx5qt Y54Rbym51gvMilytkr19xY6Wz8c9bvNmmN6fDKgtKsa/EZtYZRZo/sUQIEiVW3g5OioUQCN5HyRz uXNZS7b42637WSxcqxvDa/4W9WhjWmNuil2nRQyQS+sgbVAwPUhx/jzg8eHxlOpyJGo1cdk4mdJq v/FUrEsjXDu1YIsDsVeaP0jK6MVI6akXwL40/wBxOlVC/wDyNUGzV22ceuJ9DLeokMCodfoeMZTu bG2YHZYttFTjmHVi75ZWIwyMvJOXSc9KOFjoqqKmTbJLpvJPLf4jqXsZxWzDagymSm7LfWTPNas1 DHcjYsgbdDGe6Yo1UwxqoZQoLlHD464r/D1ulkuUVpas2Mx0PdX6OFIate2JKbqFcrtmcdoSOzCa RmKknRBYJzf45VfetA4sSQcqFuMWx5vdb5L4a5jCZ1JWO7WaaqrVhYGNdq+geqSzvIattlVFUGrd yKbdc6ipOwEMWsfHnKrnGsZmYv0YZjBW68K2w3fVIo0kJQvJDp2w8hADMV1YAA/EGyef8XqciyWH l/WDic5VnmaoV7LPLI0YDhI5te4VQEkKG0BJI+BAt7Vwnwqxx/JaL5Cc82f94V94u5PmO63G3yOL UqdrFMq+uKXCq6nZ6+RWGiqqys0kdOCRVXQaMFik/lKHcj5BMeP+QeR1ZcTNxjjbfpdbMWbFOKJb UqSSyVu1JXjf52kMa6zEAs419QE9OojnuBcetRZWHkvIl/U7OIrwW5ZGqxPHFHZ7sdiRPlWMSNpE CQqH7CX9epmacQa1YeVV/wBLzjmnY4Cuu9Ty7QOROAZo/orScldnz+jwMLWo2zX6AekvtJp1xr7K MezdRcoqJy4GA6aqCKxSgwvzm3V4ZWxOV4/FLaWnYho3Z1mKLVmmd5GjhcdmWWJzIkVlSDF8CGZS en1OFVbPMLOVxeeljqtcrzXacBiDtahiRY1kmQ96KKVBG0tZgRJ8QVVgOhrjOC/G+AunKaI3X5BI TR9JnOIug4landpk8JpezZpx7ss5CS85pW9TrZcbNpVirzxvEtU7XY0WDJszAiR0vUWIqErm8i8r s0MNPxzjElTEx5yC3GI1uS1Z7saOqQU0I7cCODIxrQF3ZtWDaKV6isXj7i9a9l4eQ8kjtZSTCzVZ DI1SKzBTd0Z57bg9yd0IjUWJwiqugI1YN01K5gMW3+T3iHK6bp+dyjPjfxsjKrQNCvGxYiy0HlvN T8PeEMkkKrx/qUq1sEU3z1jbbORpMqsjBKLQ6ijXz9M65ltrk0zeIM5DiKdpJMtlmkmghq2zDjUR oTZWS7KpRjOY65aIP+WJQH01ChHV45CvlnCzZa3VdMXiljhmls1RNkWdZRWMdONg6iESThZSv5hj JTXQsXdXeCeJLwmMVfjf8hkPUdNgavygrLC81FfHL1cL9jGubE9s2vMqrHITibis2jONFUUYs7dC HK5gX/mi4TOoBUiIrXkfkK2L9zlfF5J8RLNj5GhlFqGKG1WqiOsZGKaSRzwaO1aYbZk0ZSBqStq+ PcA1ehU4tyZIMtHDfjEsZrSyzVbNkyWRGofWOSCbVFsxHdC+qsCdALSv9n6rf+7e0/7tn+z9/rbl v/K3/u3+P+un/wDrv9L6pz+J7n/I4/8A9W+t/wAMv7z/AJb/AO0/8t+Hq3f4bqf87f8A/Svo/wDE t+7/AOY/+6/8z+Lr/9k= --_004_CDF2F015F4429F458815ED2A6C2B6B0B1A8ABD59MBX021W3CA2exch_-- From nobody Thu Jul 3 09:35: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 08C271A0356 for ; Thu, 3 Jul 2014 09:35:51 -0700 (PDT) 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 zk7EerSZQ-tM for ; Thu, 3 Jul 2014 09:35:49 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBCF1B2800 for ; Thu, 3 Jul 2014 09:35:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9F062240875 for ; Thu, 3 Jul 2014 09:35:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-90.clppva.east.verizon.net [70.106.134.90]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2A3742401DF for ; Thu, 3 Jul 2014 09:35:49 -0700 (PDT) Message-ID: <53B58663.6060307@joelhalpern.com> Date: Thu, 03 Jul 2014 12:35:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> In-Reply-To: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HK1dP7tR_RfbCXw4zDiR99SwXxI Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 03 Jul 2014 16:35:51 -0000 There has been a lot of discussion among the many authors of various archtiecture document proposals, and other commenters on these documents. Carlos and I have tried to pull together what we think is a viable document based on the available input and issues. We hope that it will help carry the working group forward. (While the chairs requested that we try to do this, they did not decide what we picked, and the working group gets to decide if it is useful. Similarly while we took input from multiple places, we are to blame for any errors, confusions, etc. The various other author teams have NOT agreed that this represents their work. it is merely the best Carlos and I could manage.) We look forward to discussion on the list, and in Toronto. Yours, Joel (and Carlos) -------- Original Message -------- Subject: New Version Notification for draft-merged-sfc-architecture-00.txt Date: Thu, 03 Jul 2014 06:32:22 -0700 From: internet-drafts@ietf.org To: Joel Halpern , Carlos Pignataro , "Joel M. Halpern" , "Carlos Pignataro" A new version of I-D, draft-merged-sfc-architecture-00.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 00 Title: Service Function Chaining (SFC) Architecture Document date: 2014-07-03 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-00 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. 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 tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 14:59: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 044301A064C for ; Thu, 3 Jul 2014 14:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 8thpx_fpqRVE for ; Thu, 3 Jul 2014 14:59:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCF41A063B for ; Thu, 3 Jul 2014 14:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3048; q=dns/txt; s=iport; t=1404424751; x=1405634351; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JMui/AXnH8S1juA25PHD2rPtlIAAXZ4JqlOghNyCzBA=; b=PmnfdjjnZ+sAn01cFKW4bWsvE4WAlr3R5OkXPdC3CfrgbOLJrqW7dg4l rGH5k9bzBDcFhru5oSNek1Kv+sAJ0ZEYDcFPziLoOfCJrl7Z2Ptyh2aol LQyYUkdTAJqSSO+fSux3rKVo9Pi+A1tVwTSj1q2mhPnTgngxKDb59ENqv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHjRtVOtJV2d/2dsb2JhbABagw1SWr5hhz8BgQ4WdYQDAQEBBAEBAWsEBQ4GAQgRAQIBAlYLFwYIAgQBEgkSiCcNyRwXjykGhD0FiheQX4FIkkOCAYFCbIFE X-IronPort-AV: E=Sophos;i="5.01,597,1400025600"; d="scan'208";a="58196075" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 03 Jul 2014 21:59:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s63LxAZM012735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 21:59:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 16:59:10 -0500 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPlwoEnf82CU/jp02QUEqNpvJCmA== Date: Thu, 3 Jul 2014 21:59:10 +0000 Message-ID: In-Reply-To: <53B58663.6060307@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.82.230.242] 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/jH0Ehj0D-4qSQoOficgJrbOg4-Q Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 03 Jul 2014 21:59:13 -0000 Hi Joel, One question as it pertains to our ODL implementation. Can a SFC aware function be reached/shared by more than one SFF? So, imagine in figure 3 another NF + SFF (in a completely different Service Node/device) but also capable of using the SFC-aware Function. I=B9m not advocating for it since it brings quite a few complications (M:N relationship) but I also want to clear things up in the beginning. Thanks, Reinaldo On 7/3/14, 9:35 AM, "Joel M. Halpern" wrote: >There has been a lot of discussion among the many authors of various >archtiecture document proposals, and other commenters on these documents. >Carlos and I have tried to pull together what we think is a viable >document based on the available input and issues. We hope that it will >help carry the working group forward. > >(While the chairs requested that we try to do this, they did not decide >what we picked, and the working group gets to decide if it is useful. >Similarly while we took input from multiple places, we are to blame for >any errors, confusions, etc. The various other author teams have NOT >agreed that this represents their work. it is merely the best Carlos >and I could manage.) > >We look forward to discussion on the list, and in Toronto. > >Yours, >Joel (and Carlos) > >-------- Original Message -------- >Subject: New Version Notification for draft-merged-sfc-architecture-00.txt >Date: Thu, 03 Jul 2014 06:32:22 -0700 >From: internet-drafts@ietf.org >To: Joel Halpern , Carlos Pignataro >, "Joel M. Halpern" , "Carlos >Pignataro" > > >A new version of I-D, draft-merged-sfc-architecture-00.txt >has been successfully submitted by Carlos Pignataro and posted to the >IETF repository. > >Name: draft-merged-sfc-architecture >Revision: 00 >Title: Service Function Chaining (SFC) Architecture >Document date: 2014-07-03 >Group: Individual Submission >Pages: 22 >URL:=20 >http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt >Status:=20 >https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >Htmlized: =20 >http://tools.ietf.org/html/draft-merged-sfc-architecture-00 > > >Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. This document does not propose solutions, > protocols, or extensions to existing protocols. > >=20 > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jul 3 15:04: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 5FEDC1A03AF for ; Thu, 3 Jul 2014 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_23=1, J_CHICKENPOX_32=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 6vPQYrzBJAqH for ; Thu, 3 Jul 2014 15:04:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2067A1A032E for ; Thu, 3 Jul 2014 15:04:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E25C324056A; Thu, 3 Jul 2014 15:04:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-98.clppva.east.verizon.net [70.106.134.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 38F5B24034E; Thu, 3 Jul 2014 15:04:16 -0700 (PDT) Message-ID: <53B5D35E.6050709@joelhalpern.com> Date: Thu, 03 Jul 2014 18:04:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" , "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/CXJJjApULSEdg5oEWxH9BXu_Z30 Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 03 Jul 2014 22:04:19 -0000 I suppose that a given SF might be reachable by multiple SFF. presumably on different chains. The architecture does not,as far as I can tell, either require or prohibt such construction. Presumably, specific solutions (such as the one the WG adopts) may have more to say on the topic. I can imagine constructions where these is easy (if the SF<->SFF interface is a single power, and the SF always sends packets back on the port it arrives on, for example) and others where this would get quite complicated. Yours, Joel On 7/3/14, 5:59 PM, Reinaldo Penno (repenno) wrote: > Hi Joel, > > One question as it pertains to our ODL implementation. > > Can a SFC aware function be reached/shared by more than one SFF? > > So, imagine in figure 3 another NF + SFF (in a completely different > Service Node/device) but also capable of using the SFC-aware Function. > > I¹m not advocating for it since it brings quite a few complications (M:N > relationship) but I also want to clear things up in the beginning. > > Thanks, > > Reinaldo > > > On 7/3/14, 9:35 AM, "Joel M. Halpern" wrote: > >> There has been a lot of discussion among the many authors of various >> archtiecture document proposals, and other commenters on these documents. >> Carlos and I have tried to pull together what we think is a viable >> document based on the available input and issues. We hope that it will >> help carry the working group forward. >> >> (While the chairs requested that we try to do this, they did not decide >> what we picked, and the working group gets to decide if it is useful. >> Similarly while we took input from multiple places, we are to blame for >> any errors, confusions, etc. The various other author teams have NOT >> agreed that this represents their work. it is merely the best Carlos >> and I could manage.) >> >> We look forward to discussion on the list, and in Toronto. >> >> Yours, >> Joel (and Carlos) >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-merged-sfc-architecture-00.txt >> Date: Thu, 03 Jul 2014 06:32:22 -0700 >> From: internet-drafts@ietf.org >> To: Joel Halpern , Carlos Pignataro >> , "Joel M. Halpern" , "Carlos >> Pignataro" >> >> >> A new version of I-D, draft-merged-sfc-architecture-00.txt >> has been successfully submitted by Carlos Pignataro and posted to the >> IETF repository. >> >> Name: draft-merged-sfc-architecture >> Revision: 00 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-07-03 >> Group: Individual Submission >> Pages: 22 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: >> http://tools.ietf.org/html/draft-merged-sfc-architecture-00 >> >> >> Abstract: >> This document describes an architecture for the specification, >> creation, and ongoing maintenance of Service Function Chains (SFC) in >> a network. It includes architectural concepts, principles, and >> components used in the construction of composite services through >> deployment of SFCs. 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 tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Jul 3 21:04: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 9D2931B2B9A for ; Thu, 3 Jul 2014 21:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 8N44m66AKx7T for ; Thu, 3 Jul 2014 21:04:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73501A0522 for ; Thu, 3 Jul 2014 21:04:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP66031; Fri, 04 Jul 2014 04:04:48 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 05:04:47 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 12:04:45 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-07.txt Thread-Index: AQHPlyWR6IY79xHh0kSs0ddrhN2VtJuPSbGg Date: Fri, 4 Jul 2014 04:04:44 +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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bc1SIyNBT5jE4pMm_ud1-CELTU4 Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-07.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, 04 Jul 2014 04:04:52 -0000 SGkgYWxsLA0KDQpXZSd2ZSBqdXN0IHN1Ym1pdCBhIG5ldyB2ZXJzaW9uLiBUaGUgbWFpbiBjaGFu Z2VzIGFyZSBzdW1tYXJpemVkIGFzIGZvbGxvd2luZzoNCjEuIFRoZSAidXNlIGNhc2UiIGluIHRp dGxlIGFuZCBhYnN0cmFjdCBpcyBjaGFuZ2VkIHRvICJnZW5lcmFsIHVzZSBjYXNlIiwgdG8gc2hv dyB0aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGFuZCByZWxhdGlvbnNoaXAgd2l0aCBvdGhlcnMu DQoNCjIuIFRoZSBzZWN0aW9ucyBvZiBNb2JpbGUgYW5kIERDIGFyZSBjdXQgc2hvcnQgYWNjb3Jk aW5nIHRvIGNoYWlycycgYWR2aWNlLiBXZSBkZWxldGUgc29tZSBmaWd1cmVzIGFuZCBwYXJhZ3Jh cGhzLCBhbmQgYWRkIHBvaW50ZXJzIHJlZmVycmluZyB0byB0aGUgdHdvIHN0YW5kIGFsb25lIGRy YWZ0cy4NCg0KMy4gQSBuZXcgc2VjdGlvbiBuYW1lZCAiIDMuMy4gQ29tbW9uIFNlcnZpY2UgQ2hh aW4gTmV0d29yazogQSBDb252ZXJnZW5jZSBUb29sIiBpcyBhZGRlZCB0byBkZXNjcmliZSBhIGNv bnZlcmdlbmNlIHVzZSBjYXNlIG9mIG1vYmlsZSBhbmQgZml4ZWQgbmV0d29yayBmb3IgaW50ZWdy YXRlZCBvcGVyYXRvcnMgdGhhdCBydW4gYm90aC4gVGhpcyB1c2UgY2FzZSBpcyBtb3JlIHN1aXRh YmxlIHRvIGJlIHB1dCBpbiB0aGUgZ2VuZXJhbCB1c2UgY2FzZSBkcmFmdCB0aGFuIGFueSBvdGhl ciBleGlzdGluZyBvbmVzLg0KDQo0LiBBIHBhcmFncmFwaCBhYm91dCBCcm9hZGJhbmQgRm9ydW0g KEJCRikgaXMgYWRkZWQgaW4gU2VjdGlvbiAzLjEgZml4ZWQgYnJvYWRiYW5kIG5ldHdvcmtzIHVz ZSBjYXNlLg0KDQo1LiBBIHNlY3Rpb24gYWJvdXQgUmVjdXJzaXZlIFNGQyBpcyBhZGRlZCBpbiA0 LjcuDQoNCldpdGggdGhlc2UgbW9kaWZpY2F0aW9uLCB3ZSB0aGluayB0aGUgdmFsdWUgb2YgdGhp cyBkcmFmdCBpcyBjbGVhciBhcyBpdCBpcyB0aGUgc3VtbWFyeSBhbmQgcG9pbnRlciBvZiBzdGFu ZGFsb25lIHVzZSBjYXNlcywgYXMgd2VsbCBhcyB0aGUgcGVyZmVjdCBwbGFjZSBmb3IgY29tbW9u IHVzZSBjYXNlcy4gVGhlcmUgaXMgbm8gY29uZmxpY3Qgb3IgcmVkdW5kYW5jeSBiZXR3ZWVuIHRo aXMgZHJhZnQgYW5kIG90aGVyIFdHIGRyYWZ0cy4gDQoNCkFueSBjb21tZW50cyB3aWxsIGJlIGFw cHJlY2lhdGVkLg0KDQpSZWdhcmRzLA0KV2lsbCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1bHkgMDQsIDIwMTQgOToxNiBBTQ0KVG86IFFp b25nIFN1bjsgSmlhZmVuZyBaaHU7IENoYW5nY2hlbmcgSHVhbmc7IE5pY29sYWkgTGV5bWFubjsg SG9uZ3l1IExpIChKdWxpbyk7IExpdXNodWNoZW5nIChXaWxsKTsgUWlvbmcgU3VuOyBQZW5nIEhl OyBDaGFuZ2NoZW5nIEh1YW5nOyBNb2hhbWVkIEJvdWNhZGFpcjsgWmhlbiBDYW87IE5pY29sYWkg TGV5bWFubjsgSHVhbmd5b25nIChPbGl2ZXIpOyBNb2hhbWVkIEJvdWNhZGFpcjsgUGVuZyBIZTsg Q2h1b25nIFBoYW07IFpoZW4gQ2FvOyBKaWFmZW5nIFpodTsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBI b25neXUgTGkgKEp1bGlvKTsgQ2h1b25nIFBoYW07IEh1YW5neW9uZyAoT2xpdmVyKQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0w Ny50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMt MDcudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2lsbChTaHVjaGVuZykg TGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWxp dS1zZmMtdXNlLWNhc2VzDQpSZXZpc2lvbjoJMDcNClRpdGxlOgkJU2VydmljZSBGdW5jdGlvbiBD aGFpbmluZyAoU0ZDKSBHZW5lcmFsIFVzZSBDYXNlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNy0w Mw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTkNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtc2ZjLXVz ZS1jYXNlcy0wNy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wNw0KRGlmZjogICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS1zZmMtdXNl LWNhc2VzLTA3DQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbGl2ZXJ5IG9mIHZhbHVlLWFkZGVkIHNl cnZpY2VzIHJlbGllcyBvbiB0aGUgaW52b2NhdGlvbiBvZg0KICAgYWR2YW5jZWQgU2VydmljZSBG dW5jdGlvbnMgaW4gYSBzZXF1ZW50aWFsIG9yZGVyLiAgVGhpcyBtZWNoYW5pc20gaXMNCiAgIGNh bGxlZCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiAgVGhlIHNldCBvZiBpbnZvbHZl ZCBTZXJ2aWNlDQogICBGdW5jdGlvbnMgYW5kIHRoZWlyIG9yZGVyIGRlcGVuZHMgb24gdGhlIHNl cnZpY2UgY29udGV4dCBhbmQgb3RoZXINCiAgIGRlcGxveW1lbnQtc3BlY2lmaWMgY29uc2lkZXJh dGlvbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBzZXQgb2YgZ2VuZXJhbCB1c2Ug Y2FzZXMgb2YgU2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5pbmcgKFNGQykuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 4 01:12: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 50D041B2C6A for ; Fri, 4 Jul 2014 01:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 6j1K1GvNVLu1 for ; Fri, 4 Jul 2014 01:12:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E34F1B2C6B for ; Fri, 4 Jul 2014 01:12:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU09485; Fri, 04 Jul 2014 08:12:03 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 09:12:02 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 16:11:58 +0800 From: "Hongyu Li (Julio)" To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmaKTw/TYF/nUWy7r8QrveSG5uPnZbg Date: Fri, 4 Jul 2014 08:11:57 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA4ACA3@SZXEMA509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] 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/YmxBHT7OHvL23fT0hWx1DydAAOY Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2014 08:12:10 -0000 VGhpcyBsYXRlc3QgcmV2aXNpb24gbG9va3MgZ29vZCB0byBtb3ZlIGZvcndhcmQuIEp1c3Qgb25l IG1pbm9yIGNvbW1lbnQuDQoNClNlY3Rpb24gMy4zIERhdGFwbGFuZSBtZXRhZGF0YSwgc2Vjb25k IHBhcmFncmFwaCAiTWV0YWRhdGEgY2FuIGluY2x1ZGUgdGhlIHJlc3VsdCBvZiBhbnRlY2VkZW50 IGNsYXNzaWZpY2F0aW9uIGFuZC9vciBpbmZvcm1hdGlvbiBmcm9tIGV4dGVybmFsIHNvdXJjZXMu ICIgIFN1Y2ggZGVzY3JpcHRpb24gY2FuJ3Qgc3VwcG9ydCBleGNoYW5naW5nIGRhdGEgYmV0d2Vl biBTRnMsIHRoZSBjYXNlIG1lbnRpb25lZCBpbiBwcmV2aW91cyBwYXJhZ3JhcGggIkRhdGEgcGxh bmUgbWV0YWRhdGEgcHJvdmlkZXMgdGhlIGFiaWxpdHkgdG8gZXhjaGFuZ2UgaW5mb3JtYXRpb24g YmV0d2VlbiAuLi4gYW5kIGJldHdlZW4gc2VydmljZSBmdW5jdGlvbnMuIiAnY2F1c2UgcHJvY2Vz c2luZyBieSBhIFNGIHRvIGNyZWF0ZSBtZXRhZGF0YSBpcyBub3QgbmVjZXNzYXJpbHkgYSBjbGFz c2lmaWNhdGlvbi4gUHJvcG9zZSB0byBhZGQgInByb2Nlc3NpbmciLg0KDQpCVFcsIGEgdHlwbyBp biBhYnN0cmFjdGlvbi4gInJlZmxlY3QiIC0+ICJyZWZsZWN0cyIuDQoNCkhvbmd5dQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMgTmFydGVuDQpTZW50OiBUaHVyc2RheSwgSnVuZSAy NiwgMjAxNCAzOjE0IEFNDQpUbzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2ZjXSAybmQgV0cg TGFzdCBDYWxsIG9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpLg0KDQpXZSByYW4gYSBXR0xDIG9u IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdA0KKGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3Rh dGVtZW50LTA3LnR4dCkgYmFjayBpbiBNYXkuDQpBbHRob3VnaCB0aGUgZHJhZnQgcmVjZWl2ZWQg c2lnbmlmaWNhbnQgcmV2aWV3IGFuZCBzdXBwb3J0IHByaW9yIHRvIHRoZSBmb3JtYWwgTEMsIHRo ZSBhY3R1YWwgbGFzdCBjYWxsIHJlc3VsdGVkIGxhcmdlbHkgaW4gc2lsZW5jZS4NCg0KV2hpbGUg aXQgd291bGQgYmUgY29udmVuaWVudCB0byB0YWtlIHNpbGVuY2UgYXMgYWNjZXB0YW5jZSwgdGhh dCdzIG5vdCBnb29kIGVub3VnaC4gVG8gc2hvdyB0aGUgZG9jdW1lbnQgaXMgcmVhZHksIHdlIG5l ZWQgV0cgbWVtYmVycyB0byBzcGVhayB1cCBhbmQgaW5kaWNhdGUgdGhleSBoYXZlIHJlYWQgYSBy ZWNlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgYW5kIHRoaW5rIGl0cyByZWFkeSB0byBnby4N Cg0KTm90ZSB0aGF0IHRoZSBkb2N1bWVudCB3YXMganVzdCByZWlzc3VlZC4gU2VjdGlvbiAzIGhh cyBiZWVuIGVkaXRlZCB0byByZW1vdmUgc29tZSBvZiB0aGUgdGV4dCB3YXMgZGVlbWVkIHRvIGJl IGVuY3JvYWNoaW5nIG9uIGFyY2hpdGVjdHVyZS4gWW91IGNhbiBzZWUgdGhlIGNoYW5nZXMgYXQg aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3NmYy9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRl bWVudC9kcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0wNy1mcm9tLTA2LmRpZmYuaHRt bA0KDQpXaXRoIHRoYXQsIHdlIGFyZSByZXN0YXJ0aW5nIGEgMi13ZWVrIFdHTEMgb24gdGhlIGRv Y3VtZW50LiBXZSBzcGVjaWZpY2FsbHkgbmVlZCB0byBzZWUgc3VmZmljaWVudCBpbmRpY2F0aW9u cyBmcm9tIFdHIG1lbWJlcnMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYWR2YW5jZSwg YW5kIHRoYXQgdGhlIGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4gc2lnbmlmaWNhbnQgZGVmaWNp ZW5jaWVzLg0KDQpUaG9tYXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri Jul 4 01:17: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 04A261B2C6F for ; Fri, 4 Jul 2014 01:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 sJdg8N2kniWp for ; Fri, 4 Jul 2014 01:17:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1881B2C66 for ; Fri, 4 Jul 2014 01:17:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP84363; Fri, 04 Jul 2014 08:17:21 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 09:17:19 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 16:17:11 +0800 From: Jiangyuanlong To: Sam Aldrin , "sfc@ietf.org" Thread-Topic: Fault management in SFC Thread-Index: AQHPl2BZnihIAWDDGk+mZUqgkXcH3w== Date: Fri, 4 Jul 2014 08:17:09 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/r1Sb9rDMHWjphz5ZzJaqQJedzrg Cc: "Carlos Pignataro \(cpignata\)" , "Nobo Akiya \(nobo\)" Subject: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2014 08:17:28 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8szxema506mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtIGFuZCBhbGwsDQoNCg0KDQpJ4oCZbSBnbGFkIHRvIHNlZSB5b3VyIGRyYWZ0IG9uIFNG QyBPQU0gZnJhbWV3b3JrLCBpdCBpcyBhIHZlcnkgYmFzaWMgYW5kIGltcG9ydGFudCBwaWVjZSBv ZiB3b3JrIGluIG15IHZpZXcuDQoNCg0KDQpXZSBoYXZlIGFsc28gdXBsb2FkZWQgYW4gSS1EIGRp c2N1c3NpbmcgZmF1bHQgbWFuYWdlbWVudCBpbiBTRkMsIGRvZXMgYW55b25lIG9mIHlvdSBoYXZl IGFuIGludGVyZXN0IGluIHRoaXMga2luZCBvZiB3b3JrPw0KDQpUaGUgbGluayB0byB0aGlzIEkt RCBpczoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtanhjLXNmYy1mbS0wMA0K DQoNCg0KWW91ciBvcGluaW9ucyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KDQoNClRoYW5r cywNCll1YW5sb25nDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgU2FtIEFsZHJpbg0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQgMzoy MSBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KQ2M6IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsg Tm9ibyBBa2l5YSAobm9ibykNClN1YmplY3Q6IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0DQoNCkhpLA0K DQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBmb3IgU0ZDIE9BTSBmcmFtZXdvcmsuDQpL aW5kbHkgcmV2aWV3IHRoZSBJRCBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRzLg0KDQpjaGVlcnMN Ci1zYW0NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4N CkRhdGU6IFdlZCwgSnVsIDIsIDIwMTQgYXQgMTI6MTcgUE0NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAwLnR4dA0K VG86IE5vYm8gQWtpeWEgPG5vYm9AY2lzY28uY29tPG1haWx0bzpub2JvQGNpc2NvLmNvbT4+LCAi U2FtIEsuIEFsZHJpbiIgPGFsZHJpbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YWxkcmluLmlldGZA Z21haWwuY29tPj4sIENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86 Y3BpZ25hdGFAY2lzY28uY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1h bGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFNhbSBLLiBBbGRyaW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yaw0KUmV2 aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu ZyBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UgRnJhbWV3b3JrDQpE b2N1bWVudCBkYXRlOiAgMjAxNC0wNy0wMg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDExDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDANCg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgcmVmZXJlbmNlIGZyYW1ld29yayBm b3IgT3BlcmF0aW9ucywNCiAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBv ZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nDQogICAoU0ZDKS4NCg0KDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8szxema506mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+ac rDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aW h+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv 5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpIFNhbSBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+STwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij7igJk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPm0gZ2xhZCB0byBzZWUgeW91ciBk cmFmdCBvbiBTRkMgT0FNIGZyYW1ld29yaywgaXQgaXMgYSB2ZXJ5IGJhc2ljIGFuZCBpbXBvcnRh bnQgcGllY2Ugb2Ygd29yayBpbiBteSB2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+V2Ug aGF2ZSBhbHNvIHVwbG9hZGVkIGFuIEktRCBkaXNjdXNzaW5nIGZhdWx0IG1hbmFnZW1lbnQgaW4g U0ZDLCBkb2VzIGFueW9uZSBvZiB5b3UgaGF2ZSBhbiBpbnRlcmVzdCBpbiB0aGlzIGtpbmQgb2Yg d29yaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGxpbmsgdG8gdGhpcyBJLUQgaXM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWp4Yy1zZmMtZm0tMDAiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWp4Yy1zZmMtZm0tMDA8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5Zb3VyIG9waW5pb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVy LWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPll1YW5sb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+U2FtIEFsZHJpbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAwMywg MjAxNCAzOjIxIEFNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+ IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibyk8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldl IGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBTRkMgT0FNIGZyYW1ld29yay48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+S2luZGx5IHJldmlldyB0aGUgSUQgYW5kIHByb3ZpZGUgeW91ciBjb21t ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNo ZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPi1z YW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KRGF0ZTogV2VkLCBKdWwgMiwgMjAxNCBhdCAxMjoxNyBQTTxicj4NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3 b3JrLTAwLnR4dDxicj4NClRvOiBOb2JvIEFraXlhICZsdDs8YSBocmVmPSJtYWlsdG86bm9ib0Bj aXNjby5jb20iPm5vYm9AY2lzY28uY29tPC9hPiZndDssICZxdW90O1NhbSBLLiBBbGRyaW4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb20iPmFsZHJpbi5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7LCBDYXJsb3MgUGlnbmF0YXJvICZsdDs8YSBocmVmPSJtYWlsdG86 Y3BpZ25hdGFAY2lzY28uY29tIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxicj4N Cjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1m cmFtZXdvcmstMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBT YW0gSy4gQWxkcmluIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4N Cjxicj4NCk5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtYWxk cmluLXNmYy1vYW0tZnJhbWV3b3JrPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDAwPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVu YW5jZSBGcmFtZXdvcms8YnI+DQpEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA3LTAyPGJyPg0K R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQpQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzExPGJy Pg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsZHJpbi1zZmMtb2Ft LWZyYW1ld29yay0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0PC9hPjxi cj4NClN0YXR1czogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay8i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsZHJp bi1zZmMtb2FtLWZyYW1ld29yay0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAwPC9hPjxicj4NCjxi cj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Zp ZGVzIHJlZmVyZW5jZSBmcmFtZXdvcmsgZm9yIE9wZXJhdGlvbnMsPGJyPg0KJm5ic3A7ICZuYnNw O0FkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBvZiBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyhTRkMpLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8szxema506mbschi_-- From nobody Fri Jul 4 02:37: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 1285A1B27BD for ; Fri, 4 Jul 2014 02:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 WnNBpXK_I15Z for ; Fri, 4 Jul 2014 02:37:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF021A0ABF for ; Fri, 4 Jul 2014 02:37:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP92576; Fri, 04 Jul 2014 09:37:50 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 10:37:49 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 17:37:45 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPltzlEg5CFXiXvUueXO4KwF/QopuPg4Pw Date: Fri, 4 Jul 2014 09:37:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> In-Reply-To: <53B58663.6060307@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bKrV_XfHwhiBjSVNZwl3ui799gY Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 04 Jul 2014 09:37:54 -0000 Hi Joel, I have some comments as follows: 1. It said "..The SFC encapsulation enables service function path selection= and the sharing of metadata/context information... " I wonder whether it w= ould be more efficient and flexible by decoupling the service function path= selection and the metadata convey functionalities by using different encap= sulation headers. Since this framework draft is more or less related to the= NSH draft (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take= the NSH as example for illustration: First, it seems the information (e.g.= , service path identifier information) contained in the SFC encapsulation (= e.g., NSH) except the metadata is not interesting to SFs, and therefore it = seems unnecessary to convey that information to the (SFC-aware) SFs, especi= ally for those externally attached SFs. As for the O(AM) bit, I wonder whet= her the SFC OAM message must be forwarded to the SF. In other words, why ca= n't the SFF process the OAM packets on behalf of the SF with the help of so= me health-check like mechanism between SFFs and SFs. As for the Service Ind= ex information, I wonder whether Service index MUST be decremented by servi= ce functions (see the corresponding description in the NSH draft). In other= words, why can't it be decremented by the SFF on behalf of the SF; Second,= the metadata is optional rather than mandatory. In a word, compared to the= SFC-unware SF, it seems that the only additional mandatory requirement on = the SFC-aware SF is to be capable of processing metadata.=20 2. in Figure 3: Service Function Chain Architecture Components, it doesn't = illustrate the relationship between those components as shown in the Figure= and service nodes. I wonder whether the following figure could demonstrate= the relationship correctly, e.g., SFF, NF and SFC proxy are three mandator= y components of service nodes, while SFC-aware SFs could either be embedded= on service nodes (e.g., SF X in the following figure) or be physically att= ached to service nodes (e.g., SF Y in the following figure). +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function X| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation +-------+-----------------------------------------+-------------+ | | SFC Encapsulation +---------+ | | +------------------+ +-------------|SFC Proxy| | | \ / +---------+ | | +-------+--------+ +----------------+ | | | SF Forwarder | | SFC-aware | | | | (SFF) +------+Service Function Y| | | +-------+--------+ +-------+--------+ | | | | | SFC Encapsulation | | | | | +-------+--------+ | | | SFC Network | | | | Forwarder (NF) | | | +----------------+ Service Node | | | | +---------------------------------------------------------------+ 3. If my understanding of the relationship as mentioned above is correct, I= suggest updating the following definition "SFC Network Forwarder (NF): SFC network forwarders provide network connectivity for service function forwarders (SFF) and service functions (SF)." by "SFC Network Forwarder (NF): SFC network forwarders provide network connectivity for service nodes." 4. According to the description about Transport Derived SFF in section 4.3.= 1, it seems that the SFC approach as described in (http://tools.ietf.org/ht= ml/draft-xu-spring-sfc-use-case-02) is an instantiation of such Transport D= erived SFF model. Is my understanding of the Transport Derived SFF concept = correct? 5. in the definition of SFC proxy (in section 4.5), it seems that partial f= unctionalities of SFC proxy are overlapped with that of SFF, see below: o Identifies the required SF to be applied based on information carried in the SFC encapsulation. o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This information is derived from the SFC encapsulation or from local configuration. Examples of a local attachment circuit include, but are not limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet-ordering or modification by the SF may necessitate additional classification in order to re-apply the correct SFC encapsulation. o Imposes the appropriate SFC encapsulation based on the identification of the SFC to be applied. IMHO, the only necessary functionality of SFC proxy is to remove the header= containing metadata before forwarding the packet to the SFC-unware SF and = while adding that header when receiving the packet returned from the SFC-un= ware SF. 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service Function make up an SF" ----s/make up an SF/make up an SFC-aware SF=20 Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, July 04, 2014 12:36 AM > To: sfc@ietf.org > Subject: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-00.txt >=20 > There has been a lot of discussion among the many authors of various > archtiecture document proposals, and other commenters on these documents. > Carlos and I have tried to pull together what we think is a viable docume= nt based > on the available input and issues. We hope that it will help carry the w= orking > group forward. >=20 > (While the chairs requested that we try to do this, they did not decide w= hat we > picked, and the working group gets to decide if it is useful. > Similarly while we took input from multiple places, we are to blame for a= ny > errors, confusions, etc. The various other author teams have NOT agreed = that > this represents their work. it is merely the best Carlos and I could man= age.) >=20 > We look forward to discussion on the list, and in Toronto. >=20 > Yours, > Joel (and Carlos) >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-merged-sfc-architecture-00.tx= t > Date: Thu, 03 Jul 2014 06:32:22 -0700 > From: internet-drafts@ietf.org > To: Joel Halpern , Carlos Pignataro > , "Joel M. Halpern" , "Carlos > Pignataro" >=20 >=20 > A new version of I-D, draft-merged-sfc-architecture-00.txt > has been successfully submitted by Carlos Pignataro and posted to the IET= F > repository. >=20 > Name: draft-merged-sfc-architecture > Revision: 00 > Title: Service Function Chaining (SFC) Architecture > Document date: 2014-07-03 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt > Status: > https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-= 00 >=20 >=20 > Abstract: > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. This document does not propose solutions, > protocols, or extensions to existing protocols. >=20 >=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 >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 4 06:48: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 C60501B2963 for ; Fri, 4 Jul 2014 06:48:16 -0700 (PDT) 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 2mHWMY89VBNR for ; Fri, 4 Jul 2014 06:48:14 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8681B27B0 for ; Fri, 4 Jul 2014 06:48:14 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s64DbBkF022605; Fri, 4 Jul 2014 06:48:08 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1mvk0g1hwa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 04 Jul 2014 06:48:07 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Jul 2014 06:48:06 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Fri, 4 Jul 2014 06:48:06 -0700 From: ramki Krishnan To: Jiangyuanlong , Sam Aldrin , "sfc@ietf.org" Date: Fri, 4 Jul 2014 06:48:05 -0700 Thread-Topic: Fault management in SFC Thread-Index: AQHPl2BZnihIAWDDGk+mZUqgkXcH35uP7M8w Message-ID: References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8457HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-04_04:2014-07-04,2014-07-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407040153 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/brTtOOiG-nIrc7icqwr3oszW9IE Cc: "Carlos Pignataro \(cpignata\)" , "Nobo Akiya \(nobo\)" , "draft-krishnan-sfc-oam-req-framework@tools.ietf.org" Subject: Re: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2014 13:48:16 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8457HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLCBZdWFubG9uZywgQWxsLA0KDQpXZSB1cGxvYWRlZCBhIGRvY3VtZW50IG9uIHRoZSBT RkMgT0FNIHRvcGljIHllc3RlcmRheSAg4oCTIHRoaXMgaW5jbHVkZXMgcmVxdWlyZW1lbnRzIGJl c2lkZXMgZnJhbWV3b3JrLiBHaXZlbiB0aGUgaW1wb3J0YW5jZSBvZiB0aGlzIHRvcGljLCBndWVz cyBtYW55IG9mIHVzIHdlcmUgd29ya2luZyBvbiB0aGlzIGluIHBhcmFsbGVsLiBXZSBzaG91bGQg cHJvYmFibHkgZ2V0IHRvZ2V0aGVyIGluIFRvcm9udG8gdG8gdGFrZSB0aGUgYXBwcm9wcmlhdGUg bmV4dCBzdGVwcy4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3Jp c2huYW4tc2ZjLW9hbS1yZXEtZnJhbWV3b3JrLw0KDQpUaGFua3MsDQpSYW1raQ0KDQpGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYW5neXVhbmxv bmcNClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCAxOjE3IEFNDQpUbzogU2FtIEFsZHJpbjsg c2ZjQGlldGYub3JnDQpDYzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyBOb2JvIEFraXlh IChub2JvKQ0KU3ViamVjdDogW3NmY10gRmF1bHQgbWFuYWdlbWVudCBpbiBTRkMNCg0KDQpIaSBT YW0gYW5kIGFsbCwNCg0KDQoNCknigJltIGdsYWQgdG8gc2VlIHlvdXIgZHJhZnQgb24gU0ZDIE9B TSBmcmFtZXdvcmssIGl0IGlzIGEgdmVyeSBiYXNpYyBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIHdv cmsgaW4gbXkgdmlldy4NCg0KDQoNCldlIGhhdmUgYWxzbyB1cGxvYWRlZCBhbiBJLUQgZGlzY3Vz c2luZyBmYXVsdCBtYW5hZ2VtZW50IGluIFNGQywgZG9lcyBhbnlvbmUgb2YgeW91IGhhdmUgYW4g aW50ZXJlc3QgaW4gdGhpcyBraW5kIG9mIHdvcms/DQoNClRoZSBsaW5rIHRvIHRoaXMgSS1EIGlz Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qeGMtc2ZjLWZtLTAwDQoNCg0K DQpZb3VyIG9waW5pb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQoNCg0KVGhhbmtzLA0K WXVhbmxvbmcNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTYW0gQWxkcmluDQpTZW50OiBUaHVyc2RheSwgSnVseSAwMywgMjAxNCAzOjIxIEFN DQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpDYzogQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpOyBOb2JvIEFraXlhIChub2JvKQ0KU3ViamVjdDogW3NmY10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29y ay0wMC50eHQNCg0KSGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBTRkMg T0FNIGZyYW1ld29yay4NCktpbmRseSByZXZpZXcgdGhlIElEIGFuZCBwcm92aWRlIHlvdXIgY29t bWVudHMuDQoNCmNoZWVycw0KLXNhbQ0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0t LS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogV2VkLCBKdWwgMiwgMjAxNCBhdCAxMjoxNyBQTQ0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1m cmFtZXdvcmstMDAudHh0DQpUbzogTm9ibyBBa2l5YSA8bm9ib0BjaXNjby5jb208bWFpbHRvOm5v Ym9AY2lzY28uY29tPj4sICJTYW0gSy4gQWxkcmluIiA8YWxkcmluLmlldGZAZ21haWwuY29tPG1h aWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb20+PiwgQ2FybG9zIFBpZ25hdGFybyA8Y3BpZ25hdGFA Y2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+Pg0KDQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2FtIEsuIEFsZHJpbiBhbmQgcG9zdGVkIHRvIHRo ZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtYWxkcmluLXNmYy1v YW0tZnJhbWV3b3JrDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVu YW5jZSBGcmFtZXdvcmsNCkRvY3VtZW50IGRhdGU6ICAyMDE0LTA3LTAyDQpHcm91cDogICAgICAg ICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMTENClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGRyaW4tc2Zj LW9hbS1mcmFtZXdvcmstMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZy YW1ld29yay0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyByZWZl cmVuY2UgZnJhbWV3b3JrIGZvciBPcGVyYXRpb25zLA0KICAgQWRtaW5pc3RyYXRpb24gYW5kIE1h aW50ZW5hbmNlIChPQU0pIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCiAgIChTRkMpLg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8457HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpT aW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy IDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJueazqOahhuaWh+ac rDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6U2ltU3VuO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pys IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jm oYbmlofmnKw7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLmEwLCBsaS5hMCwgZGl2LmEwDQoJe21zby1zdHlsZS1u YW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uQ2hhcjANCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+ac rCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH 5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4g MS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t PjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFz cz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SGkgU2FtLCBZdWFubG9uZywgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgdXBsb2FkZWQgYSBk b2N1bWVudCBvbiB0aGUgU0ZDIE9BTSB0b3BpYyB5ZXN0ZXJkYXkgwqDigJMgdGhpcyBpbmNsdWRl cyByZXF1aXJlbWVudHMgYmVzaWRlcyBmcmFtZXdvcmsuIEdpdmVuIHRoZSBpbXBvcnRhbmNlIG9m IHRoaXMgdG9waWMsIGd1ZXNzIG1hbnkgb2YgdXMgd2VyZSB3b3JraW5nIG9uIHRoaXMgaW4gcGFy YWxsZWwuIFdlIHNob3VsZCBwcm9iYWJseSBnZXQgdG9nZXRoZXIgaW4gVG9yb250byB0byB0YWtl IHRoZSBhcHByb3ByaWF0ZSBuZXh0IHN0ZXBzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNobmFuLXNmYy1vYW0t cmVxLWZyYW1ld29yay8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWty aXNobmFuLXNmYy1vYW0tcmVxLWZyYW1ld29yay88L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlJhbWtpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZiA8L2I+Smlhbmd5dWFubG9uZzxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDE6MTcgQU08YnI+PGI+VG86PC9iPiBTYW0gQWxkcmluOyBzZmNAaWV0Zi5v cmc8YnI+PGI+Q2M6PC9iPiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk7IE5vYm8gQWtpeWEg KG5vYm8pPGJyPjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBGYXVsdCBtYW5hZ2VtZW50IGluIFNGQzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTic+SGkgU2FtIGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5JPC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Jz7igJk8L3NwYW4+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz5tIGds YWQgdG8gc2VlIHlvdXIgZHJhZnQgb24gU0ZDIE9BTSBmcmFtZXdvcmssIGl0IGlzIGEgdmVyeSBi YXNpYyBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIHdvcmsgaW4gbXkgdmlldy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPldlIGhhdmUg YWxzbyB1cGxvYWRlZCBhbiBJLUQgZGlzY3Vzc2luZyBmYXVsdCBtYW5hZ2VtZW50IGluIFNGQywg ZG9lcyBhbnlvbmUgb2YgeW91IGhhdmUgYW4gaW50ZXJlc3QgaW4gdGhpcyBraW5kIG9mIHdvcms/ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0n bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPlRoZSBsaW5rIHRvIHRoaXMgSS1EIGlzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qeGMtc2ZjLWZtLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1q eGMtc2ZjLWZtLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTic+WW91ciBvcGluaW9ucyBhcmUgZ3JlYXRseSBhcHByZWNpYXRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxl PSdtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnknPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOJz5ZdWFubG9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPiBzZmMgWzxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5TYW0gQWxkcmluPGJyPjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAwMywgMjAxNCAzOjIxIEFNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj48Yj5DYzo8L2I+IENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibyk8YnI+PGI+U3ViamVjdDo8L2I+ IFtzZmNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbGRyaW4tc2Zj LW9hbS1mcmFtZXdvcmstMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPldlIGhhdmUg c3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBTRkMgT0FNIGZyYW1ld29yay48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOJz5LaW5kbHkgcmV2aWV3IHRoZSBJRCBhbmQgcHJvdmlkZSB5 b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04nPmNoZWVyczxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+LXNhbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTic+LS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPkZyb206ICZsdDs8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj5EYXRlOiBXZWQsIEp1bCAyLCAyMDE0IGF0IDEyOjE3IFBNPGJyPlN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJh bWV3b3JrLTAwLnR4dDxicj5UbzogTm9ibyBBa2l5YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vYm9A Y2lzY28uY29tIj5ub2JvQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtTYW0gSy4gQWxkcmluJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWxkcmluLmlldGZAZ21haWwuY29tIj5hbGRyaW4uaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OywgQ2FybG9zIFBpZ25hdGFybyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbSI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZndDs8YnI+PGJyPjxi cj48YnI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29y ay0wMC50eHQ8YnI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTYW0gSy4gQWxk cmluIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPklFVEYgcmVwb3NpdG9yeS48YnI+PGJyPk5hbWU6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJh bWV3b3JrPGJyPlJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDxicj5UaXRsZTogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg T3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIEZyYW1ld29yazxicj5E b2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA3LTAyPGJyPkdyb3VwOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPlBhZ2VzOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTE8YnI+VVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMC50eHQiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGRyaW4t c2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0PC9hPjxicj5TdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmsvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLzwvYT48 YnI+SHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZy YW1ld29yay0wMDwvYT48YnI+PGJyPjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7ICZuYnNwO1RoaXMg ZG9jdW1lbnQgcHJvdmlkZXMgcmVmZXJlbmNlIGZyYW1ld29yayBmb3IgT3BlcmF0aW9ucyw8YnI+ Jm5ic3A7ICZuYnNwO0FkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBvZiBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nPGJyPiZuYnNwOyAmbmJzcDsoU0ZDKS48YnI+PGJyPjxicj48 YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4uPGJyPjxicj5UaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8457HQ1EXCH01corp_-- From nobody Fri Jul 4 11:47: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 485F71B2EB2 for ; Fri, 4 Jul 2014 11:47:24 -0700 (PDT) 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 rGVyeR-H2JHu for ; Fri, 4 Jul 2014 11:47:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FC91B2B19 for ; Fri, 4 Jul 2014 11:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47EFE2412B7; Fri, 4 Jul 2014 11:47:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-98.clppva.east.verizon.net [70.106.134.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 18791240273; Fri, 4 Jul 2014 11:47:20 -0700 (PDT) Message-ID: <53B6F6B8.4040606@joelhalpern.com> Date: Fri, 04 Jul 2014 14:47:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Xuxiaohu , "sfc@ietf.org" References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8dD3R1F3jbUp9fifOwEBN_soHSY Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 04 Jul 2014 18:47:24 -0000 I need to think about your other questions, but I wanted to highlight confusion around yoru question 2. What you have drawn as Service Node is exactly the opposite of what we intended. So we need help with better wording. The Service Node is simply the housing for Service Functions. For a dedicate (physical, ...) service function this would be the device. For a virtual service function this would be the platform and hypervisor hosting the service function(s). Yours, Joel On 7/4/14, 5:37 AM, Xuxiaohu wrote: > Hi Joel, > > I have some comments as follows: > > 1. It said "..The SFC encapsulation enables service function path selection and the sharing of metadata/context information... " I wonder whether it would be more efficient and flexible by decoupling the service function path selection and the metadata convey functionalities by using different encapsulation headers. Since this framework draft is more or less related to the NSH draft (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the NSH as example for illustration: First, it seems the information (e.g., service path identifier information) contained in the SFC encapsulation (e.g., NSH) except the metadata is not interesting to SFs, and therefore it seems unnecessary to convey that information to the (SFC-aware) SFs, especially for those externally attached SFs. As for the O(AM) bit, I wonder whether the SFC OAM message must be forwarded to the SF. In other words, why can't the SFF process the OAM packets on behalf of the SF with the help of some health-che ck like m echanism between SFFs and SFs. As for the Service Index information, I wonder whether Service index MUST be decremented by service functions (see the corresponding description in the NSH draft). In other words, why can't it be decremented by the SFF on behalf of the SF; Second, the metadata is optional rather than mandatory. In a word, compared to the SFC-unware SF, it seems that the only additional mandatory requirement on the SFC-aware SF is to be capable of processing metadata. > > 2. in Figure 3: Service Function Chain Architecture Components, it doesn't illustrate the relationship between those components as shown in the Figure and service nodes. I wonder whether the following figure could demonstrate the relationship correctly, e.g., SFF, NF and SFC proxy are three mandatory components of service nodes, while SFC-aware SFs could either be embedded on service nodes (e.g., SF X in the following figure) or be physically attached to service nodes (e.g., SF Y in the following figure). > > +----------------+ +----------------+ > | SFC-aware | | SFC-unaware | > |Service Function X| |Service Function| > +-------+--------+ +-------+--------+ > | | > SFC Encapsulation No SFC Encapsulation > +-------+-----------------------------------------+-------------+ > | | SFC Encapsulation +---------+ | > | +------------------+ +-------------|SFC Proxy| | > | \ / +---------+ | > | +-------+--------+ +----------------+ | > | | SF Forwarder | | SFC-aware | | > | | (SFF) +------+Service Function Y| | > | +-------+--------+ +-------+--------+ | > | | | > | SFC Encapsulation | > | | | > | +-------+--------+ | > | | SFC Network | | > | | Forwarder (NF) | | > | +----------------+ Service Node | > | | | > +---------------------------------------------------------------+ > 3. If my understanding of the relationship as mentioned above is correct, I suggest updating the following definition > > "SFC Network Forwarder (NF): SFC network forwarders provide network > connectivity for service function forwarders (SFF) and service > functions (SF)." > by > "SFC Network Forwarder (NF): SFC network forwarders provide network > connectivity for service nodes." > > 4. According to the description about Transport Derived SFF in section 4.3.1, it seems that the SFC approach as described in (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an instantiation of such Transport Derived SFF model. Is my understanding of the Transport Derived SFF concept correct? > > 5. in the definition of SFC proxy (in section 4.5), it seems that partial functionalities of SFC proxy are overlapped with that of SFF, see below: > > o Identifies the required SF to be applied based on information > carried in the SFC encapsulation. > > o Selects the appropriate outbound local attachment circuit through > which the next SF for this SFP is reachable. This information is > derived from the SFC encapsulation or from local configuration. > Examples of a local attachment circuit include, but are not > limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. > > o Applies the required SFC encapsulation. The determination of the > encapsulation details may be inferred by the local attachment > circuit through which the packet and/or frame was received, or via > packet classification, or other local policy. In some cases, > packet-ordering or modification by the SF may necessitate > additional classification in order to re-apply the correct SFC > encapsulation. > > o Imposes the appropriate SFC encapsulation based on the > identification of the SFC to be applied. > > IMHO, the only necessary functionality of SFC proxy is to remove the header containing metadata before forwarding the packet to the SFC-unware SF and while adding that header when receiving the packet returned from the SFC-unware SF. > > 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service > Function make up an SF" ----s/make up an SF/make up an SFC-aware SF > > Best regards, > Xiaohu > > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Friday, July 04, 2014 12:36 AM >> To: sfc@ietf.org >> Subject: [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-00.txt >> >> There has been a lot of discussion among the many authors of various >> archtiecture document proposals, and other commenters on these documents. >> Carlos and I have tried to pull together what we think is a viable document based >> on the available input and issues. We hope that it will help carry the working >> group forward. >> >> (While the chairs requested that we try to do this, they did not decide what we >> picked, and the working group gets to decide if it is useful. >> Similarly while we took input from multiple places, we are to blame for any >> errors, confusions, etc. The various other author teams have NOT agreed that >> this represents their work. it is merely the best Carlos and I could manage.) >> >> We look forward to discussion on the list, and in Toronto. >> >> Yours, >> Joel (and Carlos) >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-merged-sfc-architecture-00.txt >> Date: Thu, 03 Jul 2014 06:32:22 -0700 >> From: internet-drafts@ietf.org >> To: Joel Halpern , Carlos Pignataro >> , "Joel M. Halpern" , "Carlos >> Pignataro" >> >> >> A new version of I-D, draft-merged-sfc-architecture-00.txt >> has been successfully submitted by Carlos Pignataro and posted to the IETF >> repository. >> >> Name: draft-merged-sfc-architecture >> Revision: 00 >> Title: Service Function Chaining (SFC) Architecture >> Document date: 2014-07-03 >> Group: Individual Submission >> Pages: 22 >> URL: >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-00 >> >> >> Abstract: >> This document describes an architecture for the specification, >> creation, and ongoing maintenance of Service Function Chains (SFC) in >> a network. It includes architectural concepts, principles, and >> components used in the construction of composite services through >> deployment of SFCs. 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 tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Jul 4 12:41: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 4722B1B2F1B for ; Fri, 4 Jul 2014 12:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 A804-HhrcuZ3 for ; Fri, 4 Jul 2014 12:41:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68971B2F2B for ; Fri, 4 Jul 2014 12:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18390; q=dns/txt; s=iport; t=1404502870; x=1405712470; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wYv3TE0RUr3ZKljRt10FKFjp+JnE05DJVAN+K6kANwY=; b=gtuJ9UtoEJQiIN/EVxBIYcz09ji2pJ4RZ5wyb7tMlPwE6o1EhCPcyZV/ hP4tI7RKHh4C0Y9Qp+Re1oyp1frFeRlTacVWQME5YCivrNcwHfddMYsZK tgkjFwtWVr5ntDJ0PkLSd7z6B2gwQWRddKAHOKVViFcXnXxrDI1rnOY9A Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAKUCt1OtJA2I/2dsb2JhbABagkdHUlq9FokVAYELFnWEAwEBAQR5EAIBCBEDAQEBKAchERQJCAIEDgUJiCUDEQ3DdA2GUheMeoFFUg0EBgEGA4MkgRYFhWqTDIIAgUiMMIYUg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,603,1400025600"; d="scan'208,217";a="334729569" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jul 2014 19:41:09 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s64Jf9JI030948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 19:41:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 14:41:08 -0500 From: "Carlos Pignataro (cpignata)" To: ramki Krishnan Thread-Topic: Fault management in SFC Thread-Index: AQHPl2CHHSuc/a/+tke6YdVWoqakFJuQQjmAgABipYA= Date: Fri, 4 Jul 2014 19:41:07 +0000 Message-ID: <255EC6AA-C077-4169-9110-8462CF4655E0@cisco.com> References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.231.106] Content-Type: multipart/alternative; boundary="_000_255EC6AAC077416991108462CF4655E0ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mxZg3eOGuKMVh7ZOQ7P3Qf4oO4c Cc: Sam Aldrin , Jiangyuanlong , "Nobo Akiya \(nobo\)" , "sfc@ietf.org" , "draft-krishnan-sfc-oam-req-framework@tools.ietf.org" Subject: Re: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Jul 2014 19:41:12 -0000 --_000_255EC6AAC077416991108462CF4655E0ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Ramki, Yuanlong, Thanks for bringing up these two documents! Here's my initial observations: draft-krishnan-sfc-oam-req-framework: * This document seems to be really thin in actual content. * Removing the introduction, acronyms, and boiler, there's a bit over a= page of very generic very high-level requirements. * Although the title says "SFC OAM Requirements and Framework", I do no= t see text supporting a framework. draft-jxc-sfc-fm-00: * I am concerned with the creation of a new OAM Protocol in Section 3. = SFC architectural documents have a goal of reusing OAM protocols, not re-in= venting. * It's not clear of the value of defining a TLV structure when there's = no Types. In other words, why draw TLV ASCII diagrams when the requirements= and gap analysis are not clear? * The document says things like "BFD can also be used as a tool of proa= ctive CC & CV in SFC.", but then goes on into drawing packets... I agree this can be a topic for discussions in Toronto. Thanks, Carlos. On Jul 4, 2014, at 9:48 AM, ramki Krishnan > wrote: Hi Sam, Yuanlong, All, We uploaded a document on the SFC OAM topic yesterday =96 this includes re= quirements besides framework. Given the importance of this topic, guess man= y of us were working on this in parallel. We should probably get together i= n Toronto to take the appropriate next steps. https://datatracker.ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, July 04, 2014 1:17 AM To: Sam Aldrin; sfc@ietf.org Cc: Carlos Pignataro (cpignata); Nobo Akiya (nobo) Subject: [sfc] Fault management in SFC Hi Sam and all, I=92m glad to see your draft on SFC OAM framework, it is a very basic and i= mportant piece of work in my view. We have also uploaded an I-D discussing fault management in SFC, does anyon= e of you have an interest in this kind of work? The link to this I-D is: http://tools.ietf.org/html/draft-jxc-sfc-fm-00 Your opinions are greatly appreciated. Thanks, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 03, 2014 3:21 AM To: sfc@ietf.org Cc: Carlos Pignataro (cpignata); Nobo Akiya (nobo) Subject: [sfc] Fwd: New Version Notification for draft-aldrin-sfc-oam-frame= work-00.txt Hi, We have submitted a new draft for SFC OAM framework. Kindly review the ID and provide your comments. cheers -sam ---------- Forwarded message ---------- From: > Date: Wed, Jul 2, 2014 at 12:17 PM Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt To: Nobo Akiya >, "Sam K. Aldrin" >, Carlos Pignataro > A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt has been successfully submitted by Sam K. Aldrin and posted to the IETF repository. Name: draft-aldrin-sfc-oam-framework Revision: 00 Title: Service Function Chaining Operations, Administration and Ma= intenance Framework Document date: 2014-07-02 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-fr= amework-00.txt Status: https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-frame= work/ Htmlized: http://tools.ietf.org/html/draft-aldrin-sfc-oam-framework-0= 0 Abstract: This document provides reference framework for Operations, Administration and Maintenance (OAM) of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_255EC6AAC077416991108462CF4655E0ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9B41D10C41F9954B87426CD5676ECFA9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi, Ramki, Yuanlong,

Thanks for bringing up these two documents! Here's my initial observat= ions:

draft-krishnan-sfc-oam-req-framework:
  • This document seems to be really thin in actual content.
  • Removi= ng the introduction, acronyms, and boiler, there's a bit over a page of ver= y generic very high-level requirements.
  • Although the title says &qu= ot;SFC OAM Requirements and Framework", I do not see text supporting a= framework.

draft-jxc-sfc-fm-00:
  • I am concerned with the creation of a new OAM Protocol in Section 3. SF= C architectural documents have a goal of reusing OAM protocols, not re-inve= nting.
  • It's not clear of the value of defining a TLV structure when= there's no Types. In other words, why draw TLV ASCII diagrams when the req= uirements and gap analysis are not clear?
  • The document says things = like "BFD can also be used as a tool of proactive CC & CV in SFC.&= quot;, but then goes on into drawing packets...

I agree this can be a topic for discussions in Toronto.

Thanks,

Carlos.

On Jul 4, 2014, at 9:48 AM, ramki Krishnan <ramk@Brocade.com> wrote:

Hi Sam, Yuanlong, All,
 
We uploaded a document on the SFC OAM topic yesterday =  =96 this includes requirements besides framework. Given the importance of this topic, guess many of us were worki= ng on this in parallel. We should probably get together in Toronto to take = the appropriate next steps.
 
 
Thanks,
Ramki
 
Fr= om: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong
Sent: Friday, July= 04, 2014 1:17 AM
To: Sam Aldrin; sfc@ietf.org<= br> Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fau= lt management in SFC
 
Hi Sam and all,
 
I=92m= glad to see your draft on SFC OAM framework, it is a very basic and import= ant piece of work in my view.
 
We have also uploaded an I-D discussing fault management in SFC, does= anyone of you have an interest in this kind of work?
The link to this I-D is:
 
Your opinions are greatly appreciated.
 
Thanks,
Yuanlong
 
Fr= om: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Thursday, Ju= ly 03, 2014 3:21 AM
To: sfc@= ietf.org
Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fwd= : New Version Notification for draft-aldrin-sfc-oam-framework-00.txt
 
Hi,
 
We have submitted a new draft for SFC OAM framework.
Kindly review the ID and provide your comments.=
 
cheers

-sam

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jul 2, 2014 at 12:17 PM
Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt=
To: Nobo Akiya <nobo@cisco.com>, "Sam K. Aldrin&= quot; <aldrin.ietf@gmail.com>, Carlos Pignataro <cpignata@cisco.com>



A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt
has been successfully submitted by Sam K. Aldrin and posted to the
IETF repository.

Name:           draft-aldrin-sfc-oam-framework
Revision:       00
Title:          Service Function Chaining Operatio= ns, Administration and Maintenance Framework
Document date:  2014-07-02
Group:          Individual Submission
Pages:          11
URL:            http://www.ietf.org/in= ternet-drafts/draft-aldrin-sfc-oam-framework-00.txt
Status:        &n= bsp;https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-framework/
Htmlized:       <= /span>= http://tools.ietf.org/html/draft-aldrin-sfc-oam-framework-00


Abstract:
   This document provides reference framework for Operations,
   Administration and Maintenance (OAM) of Service Function Chain= ing
   (SFC).




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

The IETF Secretariat


--_000_255EC6AAC077416991108462CF4655E0ciscocom_-- From nobody Fri Jul 4 13:07: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 C55561B2EA2; Fri, 4 Jul 2014 13:07:42 -0700 (PDT) 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 26GbZmoz_7tJ; Fri, 4 Jul 2014 13:07:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCA71B2F15; Fri, 4 Jul 2014 13:07:36 -0700 (PDT) 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.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704200736.17618.99581.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 13:07:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JvvOM10Jz90sAULmRuB6-0X8834 Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-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, 04 Jul 2014 20:07: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 Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-01.txt Pages : 23 Date : 2014-07-04 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 specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-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 Jul 4 13:28: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 3AF711B2F6F for ; Fri, 4 Jul 2014 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 3e77fOQWELSq for ; Fri, 4 Jul 2014 13:28:36 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0F11B2F6E for ; Fri, 4 Jul 2014 13:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10784; q=dns/txt; s=iport; t=1404505716; x=1405715316; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jhCe7pZ60mD/rRKwq985BYbsoArjzy/GmTlAtCBSvhQ=; b=fkdkuFryIllL4iNVkuB9iKYKvX+93brCrNybyH5pw/+kUKYcwEJe8IYY Qlpf9P9We/OHipkZFOCI7G71kqGOGzHbhrxkHxOpc0SHbFnBRwtr2LWiU bA6BD0rHzBsXP5mOqz5CM99B/drR0TjZnoA6vvCEedgr0SrTk1XS5rhja o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADENt1OtJV2d/2dsb2JhbABagw5SWr5shz8BgQsWdYQDAQEBAwEBAQE3LQcEBQIFBwQCAQgRAQIBAQEBHgkHJwsUAwYIAgQOBQkSiB8IDcpUF4llhFoLJS4FBwaDJ4EWBZZchBqBSJJEggGBQmyBAkI X-IronPort-AV: E=Sophos;i="5.01,603,1400025600"; d="scan'208";a="58392420" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 04 Jul 2014 20:28:34 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s64KSYRr025693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 20:28:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 15:28:33 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPlsQSt1dpjGM2ikW1EIaQL4eLM5uPg4PwgAETiwCAABxKgA== Date: Fri, 4 Jul 2014 20:28:33 +0000 Message-ID: <6BDBD4A5-8AFE-4019-A0D8-43BD6B146A51@cisco.com> References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> In-Reply-To: <53B6F6B8.4040606@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.231.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <89534E06158503428AE17989806115FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QXMV5fLj1F59D08V89MxYEOYUlM Cc: Xiaohu Xu , "sfc@ietf.org" Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 04 Jul 2014 20:28:38 -0000 Joel, Xiaohu, Would this help clarify? Old: Service Node (SN): Element within an SFC-enabled domain that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. New: Service Node (SN): Element within an SFC-enabled domain that hosts one or more service functions (SFs) and has one or more network locators associated with it for reachability and service delivery. The Service Node is simply the housing for Service Functio= ns, and can be a dedicated device for a physical SF, or a VM for a virtu= al SF. Thanks, Carlos. On Jul 4, 2014, at 2:47 PM, Joel M. Halpern wrote: > I need to think about your other questions, but I wanted to highlight con= fusion around yoru question 2. What you have drawn as Service Node is exac= tly the opposite of what we intended. So we need help with better wording. >=20 > The Service Node is simply the housing for Service Functions. For a dedi= cate (physical, ...) service function this would be the device. For a virt= ual service function this would be the platform and hypervisor hosting the = service function(s). >=20 > Yours, > Joel >=20 > On 7/4/14, 5:37 AM, Xuxiaohu wrote: >> Hi Joel, >>=20 >> I have some comments as follows: >>=20 >> 1. It said "..The SFC encapsulation enables service function path select= ion and the sharing of metadata/context information... " I wonder whether i= t would be more efficient and flexible by decoupling the service function p= ath selection and the metadata convey functionalities by using different en= capsulation headers. Since this framework draft is more or less related to = the NSH draft (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me t= ake the NSH as example for illustration: First, it seems the information (e= .g., service path identifier information) contained in the SFC encapsulatio= n (e.g., NSH) except the metadata is not interesting to SFs, and therefore = it seems unnecessary to convey that information to the (SFC-aware) SFs, esp= ecially for those externally attached SFs. As for the O(AM) bit, I wonder w= hether the SFC OAM message must be forwarded to the SF. In other words, why= can't the SFF process the OAM packets on behalf of the SF with the help of= some health-che > ck like m > echanism between SFFs and SFs. As for the Service Index information, I wo= nder whether Service index MUST be decremented by service functions (see th= e corresponding description in the NSH draft). In other words, why can't it= be decremented by the SFF on behalf of the SF; Second, the metadata is opt= ional rather than mandatory. In a word, compared to the SFC-unware SF, it s= eems that the only additional mandatory requirement on the SFC-aware SF is = to be capable of processing metadata. >>=20 >> 2. in Figure 3: Service Function Chain Architecture Components, it doesn= 't illustrate the relationship between those components as shown in the Fig= ure and service nodes. I wonder whether the following figure could demonstr= ate the relationship correctly, e.g., SFF, NF and SFC proxy are three manda= tory components of service nodes, while SFC-aware SFs could either be embed= ded on service nodes (e.g., SF X in the following figure) or be physically = attached to service nodes (e.g., SF Y in the following figure). >>=20 >> +----------------+ +----------------+ >> | SFC-aware | | SFC-unaware | >> |Service Function X| |Service Function| >> +-------+--------+ +-------+--------+ >> | | >> SFC Encapsulation No SFC Encapsulation >> +-------+-----------------------------------------+-------------+ >> | | SFC Encapsulation +---------+ | >> | +------------------+ +-------------|SFC Proxy| | >> | \ / +---------+ | >> | +-------+--------+ +----------------+ | >> | | SF Forwarder | | SFC-aware | | >> | | (SFF) +------+Service Function Y| | >> | +-------+--------+ +-------+--------+ | >> | | | >> | SFC Encapsulation | >> | | | >> | +-------+--------+ | >> | | SFC Network | | >> | | Forwarder (NF) | | >> | +----------------+ Service Node | >> | | | >> +---------------------------------------------------------------+ >> 3. If my understanding of the relationship as mentioned above is correct= , I suggest updating the following definition >>=20 >> "SFC Network Forwarder (NF): SFC network forwarders provide network >> connectivity for service function forwarders (SFF) and service >> functions (SF)." >> by >> "SFC Network Forwarder (NF): SFC network forwarders provide network >> connectivity for service nodes." >>=20 >> 4. According to the description about Transport Derived SFF in section 4= .3.1, it seems that the SFC approach as described in (http://tools.ietf.org= /html/draft-xu-spring-sfc-use-case-02) is an instantiation of such Transpor= t Derived SFF model. Is my understanding of the Transport Derived SFF conce= pt correct? >>=20 >> 5. in the definition of SFC proxy (in section 4.5), it seems that partia= l functionalities of SFC proxy are overlapped with that of SFF, see below: >>=20 >> o Identifies the required SF to be applied based on information >> carried in the SFC encapsulation. >>=20 >> o Selects the appropriate outbound local attachment circuit through >> which the next SF for this SFP is reachable. This information is >> derived from the SFC encapsulation or from local configuration. >> Examples of a local attachment circuit include, but are not >> limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. >>=20 >> o Applies the required SFC encapsulation. The determination of the >> encapsulation details may be inferred by the local attachment >> circuit through which the packet and/or frame was received, or via >> packet classification, or other local policy. In some cases, >> packet-ordering or modification by the SF may necessitate >> additional classification in order to re-apply the correct SFC >> encapsulation. >>=20 >> o Imposes the appropriate SFC encapsulation based on the >> identification of the SFC to be applied. >>=20 >> IMHO, the only necessary functionality of SFC proxy is to remove the hea= der containing metadata before forwarding the packet to the SFC-unware SF a= nd while adding that header when receiving the packet returned from the SFC= -unware SF. >>=20 >> 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service >> Function make up an SF" ----s/make up an SF/make up an SFC-aware SF >>=20 >> Best regards, >> Xiaohu >>=20 >>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Friday, July 04, 2014 12:36 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Fwd: New Version Notification for >>> draft-merged-sfc-architecture-00.txt >>>=20 >>> There has been a lot of discussion among the many authors of various >>> archtiecture document proposals, and other commenters on these document= s. >>> Carlos and I have tried to pull together what we think is a viable docu= ment based >>> on the available input and issues. We hope that it will help carry the= working >>> group forward. >>>=20 >>> (While the chairs requested that we try to do this, they did not decide= what we >>> picked, and the working group gets to decide if it is useful. >>> Similarly while we took input from multiple places, we are to blame for= any >>> errors, confusions, etc. The various other author teams have NOT agree= d that >>> this represents their work. it is merely the best Carlos and I could m= anage.) >>>=20 >>> We look forward to discussion on the list, and in Toronto. >>>=20 >>> Yours, >>> Joel (and Carlos) >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-merged-sfc-architecture-00.= txt >>> Date: Thu, 03 Jul 2014 06:32:22 -0700 >>> From: internet-drafts@ietf.org >>> To: Joel Halpern , Carlos Pignataro >>> , "Joel M. Halpern" , "Carlos >>> Pignataro" >>>=20 >>>=20 >>> A new version of I-D, draft-merged-sfc-architecture-00.txt >>> has been successfully submitted by Carlos Pignataro and posted to the I= ETF >>> repository. >>>=20 >>> Name: draft-merged-sfc-architecture >>> Revision: 00 >>> Title: Service Function Chaining (SFC) Architecture >>> Document date: 2014-07-03 >>> Group: Individual Submission >>> Pages: 22 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.tx= t >>> Status: >>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architectur= e-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes an architecture for the specification, >>> creation, and ongoing maintenance of Service Function Chains (SFC) = in >>> a network. It includes architectural concepts, principles, and >>> components used in the construction of composite services through >>> deployment of SFCs. This document does not propose solutions, >>> protocols, or extensions to existing protocols. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 4 13:40: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 987A81B2F80 for ; Fri, 4 Jul 2014 13:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 B17i61IZgx9e for ; Fri, 4 Jul 2014 13:40:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC491B2854 for ; Fri, 4 Jul 2014 13:40:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJQ34691; Fri, 04 Jul 2014 20:40:38 +0000 (GMT) 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; Fri, 4 Jul 2014 21:40:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 13:40:26 -0700 From: Linda Dunbar To: "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-05.txt Thread-Index: AQHPl8VLboJB7w3rOE2Gk/WJhy5SqJuQYCBg Date: Fri, 4 Jul 2014 20:40:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D732C7@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.147.193] 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/vVaRXkccg7qs537t2SFkkLBvECI Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-05.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, 04 Jul 2014 20:40:42 -0000 SGksIA0KDQpXZSByZXZpc2VkIHRoZSBMZWdhY3ktTDQtTDctQ2hhaW4tQXJjaGl0ZWN0dXJlIGRy YWZ0IHRvIGFkZHJlc3MgY29tbWVudHMgcmVjZWl2ZWQuIEFwcHJlY2lhdGUgbW9yZSBjb21tZW50 cyBmcm9tIHRoZSBncm91cC4gDQoNClRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBhcmNoaXRlY3R1 cmUgZm9yIGNoYWluaW5nIGV4aXN0aW5nIExheWVyIDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0 IGFyZSBub3QgYXdhcmUgb2YgbmV3bHkgZGVmaW5lZCBTRkMgaGVhZGVyLg0KVGhlIGludGVudCBp cyB0byBpZGVudGlmeSBvcHRpbWFsIGFyY2hpdGVjdHVyZSBmb3IgZmxleGlibHkgY2hhaW5pbmcg ZXhpc3RpbmcgTGF5ZXIgNC03IGZ1bmN0aW9ucyB0byBtZWV0IHZhcmlvdXMgc2VydmljZSBuZWVk cy4NCg0KVGhhbmtzLCBMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCAzOjE5IFBNDQpUbzogTGluZGEgRHVuYmFy OyBOaW5nIFNvOyBSb24gUGFya2VyOyBSb24gUGFya2VyOyBEb25hbGQgRWFzdGxha2U7IExpbmRh IER1bmJhcjsgTmluZyBTbzsgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZA0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFp bi1hcmNoaXRlY3R1cmUtMDUudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1 bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wNS50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3 LWNoYWluLWFyY2hpdGVjdHVyZQ0KUmV2aXNpb246CTA1DQpUaXRsZToJCUFyY2hpdGVjdHVyZSBm b3IgQ2hhaW5pbmcgTGVnYWN5IExheWVyIDQtNyBTZXJ2aWNlIEZ1bmN0aW9ucw0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wNy0wNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDUudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVu YmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3 LWNoYWluLWFyY2hpdGVjdHVyZS0wNQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hp dGVjdHVyZS0wNQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBhcmNo aXRlY3R1cmUgZm9yIGNoYWluaW5nIGV4aXN0aW5nIExheWVyIDQtDQogICA3IHNlcnZpY2UgZnVu Y3Rpb25zIHRoYXQgYXJlIG5vdCBhd2FyZSBvZiBuZXdseSBkZWZpbmVkIFNGQyBoZWFkZXIuDQog ICBUaGUgaW50ZW50IGlzIHRvIGlkZW50aWZ5IG9wdGltYWwgYXJjaGl0ZWN0dXJlIGZvciBmbGV4 aWJseSBjaGFpbmluZw0KICAgZXhpc3RpbmcgTGF5ZXIgNC03IGZ1bmN0aW9ucyB0byBtZWV0IHZh cmlvdXMgc2VydmljZSBuZWVkcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jul 4 13:49: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 8B27E1B2FAC for ; Fri, 4 Jul 2014 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 BSNlmYfOYnge for ; Fri, 4 Jul 2014 13:48:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0411B2F96 for ; Fri, 4 Jul 2014 13:48:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU59684; Fri, 04 Jul 2014 20:48:54 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 21:48:53 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 13:48:41 -0700 From: Linda Dunbar To: "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGg Date: Fri, 4 Jul 2014 20:48:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D73306@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.147.193] 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/rrlXLA9OqjhRtZSqLqbelXmEzEs Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 04 Jul 2014 20:48:57 -0000 SGksIA0KDQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgZnJhbWV3b3JrIG9mIHByb3RlY3Rpb24g YW5kIHJlc3RvcmF0aW9uIG9mDQogICBTZXJ2aWNlIENoYWluIEluc3RhbmNlIFBhdGggd2hlbiBz b21lIGluc3RhbmNlcyBvbiB0aGUgcGF0aCBmYWlsIG9yDQogICBuZWVkIHRvIGJlIHJlcGxhY2Vk Lg0KDQpBcHByZWNpYXRlIHRvIGhlYXIgeW91ciBjb21tZW50cyBvciBzdWdnZXN0aW9ucy4gDQoN CkxpbmRhICYgQW5keQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMzAsIDIwMTQgMTE6MjUgQU0NClRvOiBBbmRyZXcgRy4gTWFs aXM7IExpbmRhIER1bmJhcjsgQW5kcmV3IEcuIE1hbGlzOyBMaW5kYSBEdW5iYXINClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFu Y2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1k dW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpbmRhIER1bmJhciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVz dG9yYXRpb24NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlGcmFtZXdvcmsgZm9yIFNlcnZpY2UgRnVu Y3Rpb24gSW5zdGFuY2VzIFJlc3RvcmF0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA0LTI5DQpH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1zZmMtZnVu LWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVz dG9yYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgZnJhbWV3b3JrIG9mIHByb3RlY3Rpb24gYW5k IHJlc3RvcmF0aW9uIG9mDQogICBTZXJ2aWNlIENoYWluIEluc3RhbmNlIFBhdGggd2hlbiBzb21l IGluc3RhbmNlcyBvbiB0aGUgcGF0aCBmYWlsIG9yDQogICBuZWVkIHRvIGJlIHJlcGxhY2VkLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jul 4 14:53: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 9D5A31A00DF for ; Fri, 4 Jul 2014 14:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.602 X-Spam-Level: X-Spam-Status: No, score=-96.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 l57tw7KJWKE3 for ; Fri, 4 Jul 2014 14:53:30 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5861A00DA for ; Fri, 4 Jul 2014 14:53:27 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 5 Jul 2014 06:53:23 +0900 Received: from SMTP1.etri.info ([169.254.1.81]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Sat, 5 Jul 2014 06:53:23 +0900 From: =?euc-kr?B?wMy9wsDN?= To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-lee-sfc-dynamic-instantiation-00.txt Thread-Index: AQHPl9A6tIq6+Z123E2mce1ECDTj4g== Date: Fri, 4 Jul 2014 21:53:22 +0000 Message-ID: <417B669D-2B83-40A2-B19C-90C018BFB345@etri.re.kr> References: <20140704213754.31672.87558.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/U1NKLvtLSVMIr4K2ZdgS-NYkW04 Subject: [sfc] Fwd: New Version Notification for draft-lee-sfc-dynamic-instantiation-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, 04 Jul 2014 21:53:32 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgd2hpY2ggZGVzY3JpYmVzIGR5bmFtaWMg aW5zdGFudGlhdGlvbiBvZiBTRkMgc3BlY2lmaWNhbGx5Lg0KDQpDb21tZW50cyBvciBzdWdnZXN0 aW9ucyBhcmUgYXBwcmVjaWF0ZWQuDQoNCkxlZS4gDQoNCsD8tN61yCC43r3DwfYgvcPA2zoNCg0K PiC6uLO9ILvntvc6IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+IMGmuPE6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVlLXNmYy1keW5hbWljLWluc3RhbnRpYXRpb24t MDAudHh0DQo+ILOvwqU6IDIwMTSz4iA3v/kgNcDPIL/AwPwgNr3DIDM3utAgNTTDyiBHTVQrOQ0K PiC53rTCILvntvc6IFNldW5nLUlrIExlZSA8c2V1bmdpa2xlZUBldHJpLnJlLmtyPiwgTXl1bmct S2kgU2hpbiA8bWtzaGluQGV0cmkucmUua3I+LCBTZXVuZ2lrIExlZSA8c2V1bmdpa2xlZUBldHJp LnJlLmtyPiwgTXl1bmctS2kgU2hpbiA8bWtzaGluQGV0cmkucmUua3I+DQo+IA0KPiANCj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxlZS1zZmMtZHluYW1pYy1pbnN0YW50aWF0aW9uLTAw LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNldW5nLUlrIExlZSBh bmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQt bGVlLXNmYy1keW5hbWljLWluc3RhbnRpYXRpb24NCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJ U0ZDIGR5bmFtaWMgaW5zdGFudGlhdGlvbg0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA3LTA0DQo+ IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNw0KPiBVUkw6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGVlLXNmYy1k eW5hbWljLWluc3RhbnRpYXRpb24tMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZWUtc2ZjLWR5bmFtaWMtaW5zdGFudGlhdGlv bi8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxl ZS1zZmMtZHluYW1pYy1pbnN0YW50aWF0aW9uLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg U0ZDIGluc3RhbnRpYXRpb24gbWF5IGJlIHN0YXRpYyBvciBkeW5hbWljLiAgSW4gYSBzdGF0aWMN Cj4gICBpbnN0YW50aWF0aW9uLCBzcGVjaWZpYyBTRiBpbnN0YW5jZXMgYXJlIHByZWRldGVybWlu ZWQgYnkgbmV0d29yaw0KPiAgIG9wZXJhdG9yJ3MgY29uZmlndXJhdGlvbiBvciBwb2xpY3kuICBI b3dldmVyLCBzaW5jZSBpdCBkb2VzIG5vdA0KPiAgIGNvbnNpZGVyIHRoZSBjdXJyZW50IHN0YXRl IG9mIG5ldHdvcmsgcmVzb3VyY2VzIHN1Y2ggYXMgYXZhaWxhYmlsaXR5DQo+ICAgb2YgdGhlIFNG IGluc3RhbmNlcywgdGhlIHN0YXRpYyBpbnN0YW50aWF0aW9uIG1heSBjcmVhdGUgbW9yZQ0KPiAg IHZ1bG5lcmFibGUgU0ZQcyB0byBzdGF0ZSBjaGFuZ2VzIG9mIHRoZSBuZXR3b3JrIHJlc291cmNl cyBzdWNoIGFzDQo+ICAgZmFpbHVyZSBvciBvdmVybG9hZC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIFNGQyBkeW5hbWljDQo+ICAgaW5zdGFudGlhdGlvbiBjYXBhYmlsaXR5IHRvIGNyZWF0ZSBh bmQgdXBkYXRlIFNGUHMgY29uc2lkZXJpbmcNCj4gICB0cmFmZmljIG9wdGltaXphdGlvbiwgZmFp bG92ZXIgb2YgU0ZJcywgYW5kIGxvYWQgYmFsYW5jaW5nLg0KPiANCj4gDQo+IA0KPiANCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4gDQoNCg== From nobody Fri Jul 4 17:34: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 B06671A019A for ; Fri, 4 Jul 2014 17:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 fYF6sxDSygJU for ; Fri, 4 Jul 2014 17:34:27 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AEF1A0092 for ; Fri, 4 Jul 2014 17:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10979; q=dns/txt; s=iport; t=1404520468; x=1405730068; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Wa+Tz4nshOdWSEN1rG38Kqtm2OJWSqa4YV4qe5E16t0=; b=mKGMoksZV3SE3Mvg3hz/u+irtIeUL7InZX8gD442PNZ7KjHNF4oDAdfo Me+12rtOOPSE99JiiWZifXwH0R8nTTijN3cpz6e63gBnmXeWa6HpFdjpi VYvUckqjmej4V8ReiG3c95O9I+3TZ6LtZ+DSlNB0pzUPC5oqKOiB8WvKu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMxHt1OtJV2Z/2dsb2JhbABagw5SWr5shz8BgQYWdYQDAQEBAwEBAQE3LQcEBQ4EAgEIEQECAQEBAR4JBycLFAMGCAIEARIJEogfCA3KMxeJZYRaC1MMBoQ9BZZchBqBSJJEggGBQmyBAkI X-IronPort-AV: E=Sophos;i="5.01,604,1400025600"; d="scan'208";a="58441433" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 05 Jul 2014 00:34:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s650YG8P028579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jul 2014 00:34:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.80]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 19:34:16 -0500 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , Xuxiaohu , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPl2ul9/MDa2+HH0Kn2ZWHcoTTB5uQlb8A///rkwA= Date: Sat, 5 Jul 2014 00:34:15 +0000 Message-ID: References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> In-Reply-To: <53B6F6B8.4040606@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.95.207] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TuVVD8zQzwvP1tuBWET91ejGnso Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 05 Jul 2014 00:34:29 -0000 I have some comments inline. On 7/4/14 11:47 AM, "Joel M. Halpern" wrote: >I need to think about your other questions, but I wanted to highlight >confusion around yoru question 2. What you have drawn as Service Node >is exactly the opposite of what we intended. So we need help with >better wording. > >The Service Node is simply the housing for Service Functions. For a >dedicate (physical, ...) service function this would be the device. For >a virtual service function this would be the platform and hypervisor >hosting the service function(s). > >Yours, >Joel > >On 7/4/14, 5:37 AM, Xuxiaohu wrote: >> Hi Joel, >> >> I have some comments as follows: >> >> 1. It said "..The SFC encapsulation enables service function path >>selection and the sharing of metadata/context information... " I wonder >>whether it would be more efficient and flexible by decoupling the >>service function path selection and the metadata convey functionalities >>by using different encapsulation headers. Since this framework draft is >>more or less related to the NSH draft >>(http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), SK> there is a rev-03 btw. >>Let me take the NSH as example for illustration: First, it seems the >>information (e.g., service path identifier information) contained in the >>SFC encapsulation (e.g., NSH) except the metadata is not interesting to >>SFs, and therefore it seems unnecessary to convey that information to >>the (SFC-aware) SFs, especially for those externally attached SFs. SK> Not sure I understand this. That ID is the one identifying the SF forwarding state and is needed in order to keep the traffic on a certain SFC, or SFP to be specific. Moreover that ID may be correlate to the metadata. That ID also allows for state-less SFF implementation. So, that ID is absolutely necessary. >>As for the O(AM) bit, I wonder whether the SFC OAM message must be >>forwarded to the SF. In other words, why can't the SFF process the OAM >>packets on behalf of the SF with the help of some health-che > ck like m >echanism between SFFs and SFs. SK> There are benefits to having OAM sent up to the SFs, depending on how OAM is implemented. If not anything, it verifies the path through the SFs. >As for the Service Index information, I wonder whether Service index MUST >be decremented by service functions (see the corresponding description in >the NSH draft). In other words, why can't it be decremented by the SFF on >behalf of the SF; Second, the metadata is optional rather than mandatory. >In a word, compared to the SFC-unware SF, it seems that the only >additional mandatory requirement on the SFC-aware SF is to be capable of >processing metadata. SK> SFF MUST decrement-able by the SFF. That wording needs to be updated as far as I can tell >> >> 2. in Figure 3: Service Function Chain Architecture Components, it >>doesn't illustrate the relationship between those components as shown in >>the Figure and service nodes. I wonder whether the following figure >>could demonstrate the relationship correctly, e.g., SFF, NF and SFC >>proxy are three mandatory components of service nodes, while SFC-aware >>SFs could either be embedded on service nodes (e.g., SF X in the >>following figure) or be physically attached to service nodes (e.g., SF Y >>in the following figure). >> >> +----------------+ +----------------+ >> | SFC-aware | | SFC-unaware | >> |Service Function X| |Service Function| >> +-------+--------+ +-------+--------+ >> | | >> SFC Encapsulation No SFC Encapsulation >> +-------+-----------------------------------------+-------------+ >> | | SFC Encapsulation +---------+ | >> | +------------------+ +-------------|SFC Proxy| | >> | \ / +---------+ | >> | +-------+--------+ +----------------+ | >> | | SF Forwarder | | SFC-aware | | >> | | (SFF) +------+Service Function Y| | >> | +-------+--------+ +-------+--------+ | >> | | | >> | SFC Encapsulation | >> | | | >> | +-------+--------+ | >> | | SFC Network | | >> | | Forwarder (NF) | | >> | +----------------+ Service Node | >> | | | >> +---------------------------------------------------------------+ SK> I would not draw it this way. However, NF+SFF+SF could potentially be in the same box, irrespective of what we call it. A firewall with forwarding capability that also hosts an SFF and a host of security SFs, is an example I can think of. So, that boundary depends on the implementation. >> 3. If my understanding of the relationship as mentioned above is >>correct, I suggest updating the following definition >> >> "SFC Network Forwarder (NF): SFC network forwarders provide network >> connectivity for service function forwarders (SFF) and service >> functions (SF)." >> by >> "SFC Network Forwarder (NF): SFC network forwarders provide network >> connectivity for service nodes." >> >> 4. According to the description about Transport Derived SFF in section >>4.3.1, it seems that the SFC approach as described in >>(http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an >>instantiation of such Transport Derived SFF model. Is my understanding >>of the Transport Derived SFF concept correct? >> >> 5. in the definition of SFC proxy (in section 4.5), it seems that >>partial functionalities of SFC proxy are overlapped with that of SFF, >>see below: >> >> o Identifies the required SF to be applied based on information >> carried in the SFC encapsulation. >> >> o Selects the appropriate outbound local attachment circuit through >> which the next SF for this SFP is reachable. This information is >> derived from the SFC encapsulation or from local configuration. >> Examples of a local attachment circuit include, but are not >> limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. >> >> o Applies the required SFC encapsulation. The determination of the >> encapsulation details may be inferred by the local attachment >> circuit through which the packet and/or frame was received, or >>via >> packet classification, or other local policy. In some cases, >> packet-ordering or modification by the SF may necessitate >> additional classification in order to re-apply the correct SFC >> encapsulation. >> >> o Imposes the appropriate SFC encapsulation based on the >> identification of the SFC to be applied. >> >> IMHO, the only necessary functionality of SFC proxy is to remove the >>header containing metadata before forwarding the packet to the >>SFC-unware SF and while adding that header when receiving the packet >>returned from the SFC-unware SF. >> >> 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service >> Function make up an SF" ----s/make up an SF/make up an SFC-aware >>SF >> >> Best regards, >> Xiaohu >> >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Friday, July 04, 2014 12:36 AM >>> To: sfc@ietf.org >>> Subject: [sfc] Fwd: New Version Notification for >>> draft-merged-sfc-architecture-00.txt >>> >>> There has been a lot of discussion among the many authors of various >>> archtiecture document proposals, and other commenters on these >>>documents. >>> Carlos and I have tried to pull together what we think is a viable >>>document based >>> on the available input and issues. We hope that it will help carry >>>the working >>> group forward. >>> >>> (While the chairs requested that we try to do this, they did not >>>decide what we >>> picked, and the working group gets to decide if it is useful. >>> Similarly while we took input from multiple places, we are to blame >>>for any >>> errors, confusions, etc. The various other author teams have NOT >>>agreed that >>> this represents their work. it is merely the best Carlos and I could >>>manage.) >>> >>> We look forward to discussion on the list, and in Toronto. >>> >>> Yours, >>> Joel (and Carlos) >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>>draft-merged-sfc-architecture-00.txt >>> Date: Thu, 03 Jul 2014 06:32:22 -0700 >>> From: internet-drafts@ietf.org >>> To: Joel Halpern , Carlos Pignataro >>> , "Joel M. Halpern" , "Carlos >>> Pignataro" >>> >>> >>> A new version of I-D, draft-merged-sfc-architecture-00.txt >>> has been successfully submitted by Carlos Pignataro and posted to the >>>IETF >>> repository. >>> >>> Name: draft-merged-sfc-architecture >>> Revision: 00 >>> Title: Service Function Chaining (SFC) Architecture >>> Document date: 2014-07-03 >>> Group: Individual Submission >>> Pages: 22 >>> URL: >>>=20 >>>http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>> Htmlized: =20 >>>http://tools.ietf.org/html/draft-merged-sfc-architecture-00 >>> >>> >>> Abstract: >>> This document describes an architecture for the specification, >>> creation, and ongoing maintenance of Service Function Chains >>>(SFC) in >>> a network. It includes architectural concepts, principles, and >>> components used in the construction of composite services through >>> deployment of SFCs. 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 tools.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 From nobody Fri Jul 4 18:17: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 CFF551A00E6; Fri, 4 Jul 2014 18:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Xl4X39qFQGKH; Fri, 4 Jul 2014 18:17:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464841A0011; Fri, 4 Jul 2014 18:17:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJQ44941; Sat, 05 Jul 2014 01:17:33 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 5 Jul 2014 02:17:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sat, 5 Jul 2014 09:17:20 +0800 From: Qin Wu To: ramki Krishnan , Jiangyuanlong , Sam Aldrin , "sfc@ietf.org" , "time@ietf.org" Thread-Topic: Fault management in SFC Thread-Index: AQHPl2IwdP+ejxTE2UyNesn6tN0/7ZuPaEiAgAFGH6A= Date: Sat, 5 Jul 2014 01:17:19 +0000 Message-ID: References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8457F430nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ej5sqpKdU7F_VQjqCmZnbBjM6P8 Cc: "Carlos Pignataro \(cpignata\)" , "Nobo Akiya \(nobo\)" , "draft-krishnan-sfc-oam-req-framework@tools.ietf.org" Subject: Re: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 05 Jul 2014 01:17:40 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8457F430nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugc2VlIGEgbG90IG9mIGVuZXJneSB0byBkbyB0aGlzIGtpbmQgb2Ygc3VydmV5LCB3b3VsZCBp dCBiZSBnb29kIHRvIGRpc2N1c3MgdGhpcyBpbiBUSU1FIG1haWxpbmcgbGlzdCBhcyB3ZWxsPw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aW1lDQoNClJlZ2FyZHMhDQot UWluDQrlj5Hku7bkuro6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSDku6Pooagg cmFta2kgS3Jpc2huYW4NCuWPkemAgeaXtumXtDogMjAxNOW5tDfmnIg05pelIDIxOjQ4DQrmlLbk u7bkuro6IEppYW5neXVhbmxvbmc7IFNhbSBBbGRyaW47IHNmY0BpZXRmLm9yZw0K5oqE6YCBOiBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk7IE5vYm8gQWtpeWEgKG5vYm8pOyBkcmFmdC1rcmlz aG5hbi1zZmMtb2FtLXJlcS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtz ZmNdIEZhdWx0IG1hbmFnZW1lbnQgaW4gU0ZDDQoNCkhpIFNhbSwgWXVhbmxvbmcsIEFsbCwNCg0K V2UgdXBsb2FkZWQgYSBkb2N1bWVudCBvbiB0aGUgU0ZDIE9BTSB0b3BpYyB5ZXN0ZXJkYXkgIOKA kyB0aGlzIGluY2x1ZGVzIHJlcXVpcmVtZW50cyBiZXNpZGVzIGZyYW1ld29yay4gR2l2ZW4gdGhl IGltcG9ydGFuY2Ugb2YgdGhpcyB0b3BpYywgZ3Vlc3MgbWFueSBvZiB1cyB3ZXJlIHdvcmtpbmcg b24gdGhpcyBpbiBwYXJhbGxlbC4gV2Ugc2hvdWxkIHByb2JhYmx5IGdldCB0b2dldGhlciBpbiBU b3JvbnRvIHRvIHRha2UgdGhlIGFwcHJvcHJpYXRlIG5leHQgc3RlcHMuDQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNobmFuLXNmYy1vYW0tcmVxLWZyYW1ld29y ay8NCg0KVGhhbmtzLA0KUmFta2kNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKaWFuZ3l1YW5sb25nDQpTZW50OiBGcmlkYXksIEp1bHkgMDQs IDIwMTQgMToxNyBBTQ0KVG86IFNhbSBBbGRyaW47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KQ2M6IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9i bykNClN1YmplY3Q6IFtzZmNdIEZhdWx0IG1hbmFnZW1lbnQgaW4gU0ZDDQoNCg0KSGkgU2FtIGFu ZCBhbGwsDQoNCg0KDQpJ4oCZbSBnbGFkIHRvIHNlZSB5b3VyIGRyYWZ0IG9uIFNGQyBPQU0gZnJh bWV3b3JrLCBpdCBpcyBhIHZlcnkgYmFzaWMgYW5kIGltcG9ydGFudCBwaWVjZSBvZiB3b3JrIGlu IG15IHZpZXcuDQoNCg0KDQpXZSBoYXZlIGFsc28gdXBsb2FkZWQgYW4gSS1EIGRpc2N1c3Npbmcg ZmF1bHQgbWFuYWdlbWVudCBpbiBTRkMsIGRvZXMgYW55b25lIG9mIHlvdSBoYXZlIGFuIGludGVy ZXN0IGluIHRoaXMga2luZCBvZiB3b3JrPw0KDQpUaGUgbGluayB0byB0aGlzIEktRCBpczoNCg0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtanhjLXNmYy1mbS0wMA0KDQoNCg0KWW91 ciBvcGluaW9ucyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0KDQoNClRoYW5rcywNCll1YW5s b25nDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgU2FtIEFsZHJpbg0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQgMzoyMSBBTQ0KVG86 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KQ2M6IENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibykNClN1YmplY3Q6IFtzZmNdIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAu dHh0DQoNCkhpLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBmb3IgU0ZDIE9BTSBm cmFtZXdvcmsuDQpLaW5kbHkgcmV2aWV3IHRoZSBJRCBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRz Lg0KDQpjaGVlcnMNCi1zYW0NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t LQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPj4NCkRhdGU6IFdlZCwgSnVsIDIsIDIwMTQgYXQgMTI6MTcgUE0NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3 b3JrLTAwLnR4dA0KVG86IE5vYm8gQWtpeWEgPG5vYm9AY2lzY28uY29tPG1haWx0bzpub2JvQGNp c2NvLmNvbT4+LCAiU2FtIEsuIEFsZHJpbiIgPGFsZHJpbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 YWxkcmluLmlldGZAZ21haWwuY29tPj4sIENhcmxvcyBQaWduYXRhcm8gPGNwaWduYXRhQGNpc2Nv LmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNhbSBLLiBBbGRyaW4gYW5kIHBvc3RlZCB0byB0aGUNCklF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWFsZHJpbi1zZmMtb2FtLWZy YW1ld29yaw0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgU2VydmljZSBGdW5j dGlvbiBDaGFpbmluZyBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2Ug RnJhbWV3b3JrDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNy0wMg0KR3JvdXA6ICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDExDQpVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWxkcmluLXNmYy1vYW0t ZnJhbWV3b3JrLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay8NCkh0bWxpemVkOiAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdv cmstMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgcmVmZXJlbmNl IGZyYW1ld29yayBmb3IgT3BlcmF0aW9ucywNCiAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVu YW5jZSAoT0FNKSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nDQogICAoU0ZDKS4NCg0KDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+ Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8457F430nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29Q bGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/m lofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9 kzt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFt ZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuUGxh aW5UZXh0LCBsaS5QbGFpblRleHQsIGRpdi5QbGFpblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk65a6L5L2TO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuQmFsbG9vblRleHQsIGxp LkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OuWui+S9kzt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHNlZSBhIGxv dCBvZiBlbmVyZ3kgdG8gZG8gdGhpcyBraW5kIG9mIHN1cnZleSwgd291bGQgaXQgYmUgZ29vZCB0 byBkaXNjdXNzIHRoaXMgaW4gVElNRSBtYWlsaW5nIGxpc3QgYXMgd2VsbD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aW1lIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpbWU8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnJhbWtpIEtyaXNobmFuPGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFu IGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaXpTxz cGFuIGxhbmc9IkVOLVVTIj4gMjE6NDg8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gSmlhbmd5dWFubG9uZzsg U2FtIEFsZHJpbjsgc2ZjQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibyk7IGRyYWZ0LWtyaXNobmFuLXNmYy1vYW0tcmVx LWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW3NmY10gRmF1bHQg bWFuYWdlbWVudCBpbiBTRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFNhbSwgWXVhbmxvbmcs IEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgdXBsb2FkZWQgYSBk b2N1bWVudCBvbiB0aGUgU0ZDIE9BTSB0b3BpYyB5ZXN0ZXJkYXkgJm5ic3A74oCTIHRoaXMgaW5j bHVkZXMgcmVxdWlyZW1lbnRzIGJlc2lkZXMgZnJhbWV3b3JrLiBHaXZlbiB0aGUgaW1wb3J0YW5j ZSBvZiB0aGlzIHRvcGljLCBndWVzcw0KIG1hbnkgb2YgdXMgd2VyZSB3b3JraW5nIG9uIHRoaXMg aW4gcGFyYWxsZWwuIFdlIHNob3VsZCBwcm9iYWJseSBnZXQgdG9nZXRoZXIgaW4gVG9yb250byB0 byB0YWtlIHRoZSBhcHByb3ByaWF0ZSBuZXh0IHN0ZXBzLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWtyaXNobmFuLXNmYy1vYW0tcmVxLWZyYW1ld29yay8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNobmFuLXNmYy1vYW0tcmVxLWZyYW1ld29yay88L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhbWtpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppYW5neXVhbmxvbmc8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBKdWx5IDA0LCAyMDE0IDE6MTcgQU08YnI+DQo8Yj5Ubzo8L2I+IFNhbSBBbGRyaW47IDxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8 L2I+IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibyk8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3NmY10gRmF1bHQgbWFuYWdlbWVudCBpbiBTRkM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFNhbSBh bmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bQ0KIGdsYWQg dG8gc2VlIHlvdXIgZHJhZnQgb24gU0ZDIE9BTSBmcmFtZXdvcmssIGl0IGlzIGEgdmVyeSBiYXNp YyBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIHdvcmsgaW4gbXkgdmlldy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5X ZSBoYXZlIGFsc28gdXBsb2FkZWQgYW4gSS1EIGRpc2N1c3NpbmcgZmF1bHQgbWFuYWdlbWVudCBp biBTRkMsIGRvZXMgYW55b25lIG9mIHlvdSBoYXZlIGFuIGludGVyZXN0IGluIHRoaXMga2luZCBv ZiB3b3JrPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBsaW5rIHRvIHRoaXMg SS1EIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWp4Yy1zZmMtZm0tMDAiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWp4Yy1zZmMtZm0tMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WW91ciBvcGlu aW9ucyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WXVhbmxvbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5TYW0gQWxkcmluPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDAzLCAyMDE0IDM6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibyk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W3NmY10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFsZHJpbi1zZmMt b2FtLWZyYW1ld29yay0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlIGhhdmUgc3VibWl0 dGVkIGEgbmV3IGRyYWZ0IGZvciBTRkMgT0FNIGZyYW1ld29yay48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+S2luZGx5IHJldmlldyB0aGUgSUQgYW5kIHByb3ZpZGUgeW91ciBjb21tZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNoZWVyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPi1zYW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0 ZTogV2VkLCBKdWwgMiwgMjAxNCBhdCAxMjoxNyBQTTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAwLnR4dDxi cj4NClRvOiBOb2JvIEFraXlhICZsdDs8YSBocmVmPSJtYWlsdG86bm9ib0BjaXNjby5jb20iPm5v Ym9AY2lzY28uY29tPC9hPiZndDssICZxdW90O1NhbSBLLiBBbGRyaW4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb20iPmFsZHJpbi5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7LCBDYXJsb3MgUGlnbmF0YXJvICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lz Y28uY29tIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAu dHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTYW0gSy4gQWxkcmlu IGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtYWxkcmluLXNmYy1vYW0t ZnJhbWV3b3JrPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDAwPGJyPg0KVGl0 bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSBGcmFtZXdv cms8YnI+DQpEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA3LTAyPGJyPg0KR3JvdXA6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQ YWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzExPGJyPg0KVVJMOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0w MC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmstMDAudHh0PC9hPjxicj4NClN0YXR1czog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay8iIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFsZHJpbi1zZmMt b2FtLWZyYW1ld29yay88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFsZHJpbi1zZmMtb2FtLWZy YW1ld29yay0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCkFi c3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHJlZmVyZW5j ZSBmcmFtZXdvcmsgZm9yIE9wZXJhdGlvbnMsPGJyPg0KJm5ic3A7ICZuYnNwO0FkbWluaXN0cmF0 aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nPGJy Pg0KJm5ic3A7ICZuYnNwOyhTRkMpLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFy aWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA8457F430nkgeml501mbschi_-- From nobody Sat Jul 5 05: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 AD7711A04CA for ; Sat, 5 Jul 2014 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.001 X-Spam-Level: X-Spam-Status: No, score=-96.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 R_n5mECcID4I for ; Sat, 5 Jul 2014 05:42:47 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5735C1A04F1 for ; Sat, 5 Jul 2014 05:42:47 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 5 Jul 2014 21:42:43 +0900 Received: from SMTP1.etri.info ([169.254.1.81]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Sat, 5 Jul 2014 21:42:45 +0900 From: =?ks_c_5601-1987?B?wMy9wsDN?= To: "sfc@ietf.org" Thread-Topic: [sfc] Toronto SFC Meeting Agenda Thread-Index: AQHPli8r2R6/zSOUgEqgCTNvSQH7MZuQH8oAgAFREm4= Date: Sat, 5 Jul 2014 12:42:43 +0000 Message-ID: References: , <47827519-B16B-4A19-AE2E-738B39B32FA3@etri.re.kr> In-Reply-To: <47827519-B16B-4A19-AE2E-738B39B32FA3@etri.re.kr> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C008BF867BC045FAAFD61FE06E85DD24etrirekr_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OkCDctCDQFeaIQPfh2F7Vzu_HYs Subject: [sfc] Fwd: Toronto SFC Meeting Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:42:49 -0000 --_000_C008BF867BC045FAAFD61FE06E85DD24etrirekr_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RllJLCBJIG1pc3NlZCBzZW5kaW5nIGl0IHRvIHRoZSBsaXN0Lg0KDQoNCsD8tN61yCC43r3DwfYg vcPA2zoNCg0KurizvSC757b3OiBTZXVuZy1JayBMZWUgPHNldW5naWtsZWVAZXRyaS5yZS5rcjxt YWlsdG86c2V1bmdpa2xlZUBldHJpLnJlLmtyPj4NCrOvwqU6IDIwMTSz4iA3v/kgNcDPIL/AwPwg MTC9wyAzNrrQIDE4w8ogR01UKzkNCrnetMIgu+e29zogIkppbSBHdWljaGFyZCAoamd1aWNoYXIp IiA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KwvzBtjog vcW47bHiIDxta3NoaW5AZXRyaS5yZS5rcjxtYWlsdG86bWtzaGluQGV0cmkucmUua3I+Pg0Kwaa4 8TogUmU6IFtzZmNdIFRvcm9udG8gU0ZDIE1lZXRpbmcgQWdlbmRhDQoNCkppbSwNCg0KV2UndmUg YWxyZWFkeSBnb3Qgc2V2ZXJhbCBJLURzIGZvciB0aGUgYmFzaXMgb2YgUFMsIHVzZSBjYXNlcywg YXJjaGl0ZWN0dXJlLg0KTm93IGl0oa9zIGdvb2QgdGltZSB0byB0b3VjaCB0aGUgY29udHJvbCBw bGFuZSBtZWNoYW5pc21zIGZvciB0aGVtIGFjY29yZGluZyB0byB0aGUgV0cgY2hhcnRlciwgSU1I Ty4NCg0KQmFzZWQgb24gdGhlIHJlY2VudGx5IHN1Ym1pdHRlZCBJLURzLCB3ZSBnb3Qgc2V2ZXJh bCBpc3N1ZXMgcmVsZXZhbnQgdG8gdGhlIGNvbnRyb2wgYXMgZm9sbG93czoNCi0gbG9hZCBiYWxh bmNpbmcNCi0gcGF0aCBvcHRpbWl6YXRpb24NCi0gZHluYW1pYyBjaGFpbiBpbnN0YW50aWF0aW9u DQotIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgcmVzdG9yYXRpb24NCi0gY2hhaW4gcmVkdW5k YW5jeQ0KDQpUaGV5IGNvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgdGhlIGNvbnRyb2wgcGxhbmUg bWVjaGFuaXNtcyBhbmQgbWF5IGV4dHJhY3Qgc29tZSBvdGhlciByZXF1aXJlbWVudHMgYW5kIGFy Y2hpdGVjdHVyYWwgY29tcG9uZW50cy4NCg0KV2hhdCBhYm91dCBtYWtpbmcgdGhlbSBkaXNjdXNz ZWQgaW4gNSBtaW5zIHBlciBlYWNoIGF0IHRoaXMgbWVldGluZyB3aXRoIHdoYXQgaW1wYWN0IHRo ZXkgd291bGQgbWFrZSB0byB0aGUgcmVxdWlyZW1lbnQgYW5kIGFyY2hpdGVjdHVyZSBkb2N1bWVu dHM/IEFmdGVyIHRoYXQsIHdlIGNhbiBnbyBmb3J3YXJkIHRvIGRpc2N1c3NpbmcgaG93IHRvIGhh bmRsZSB0aGUgY29udHJvbCBwbGFuZSBtZWNoYW5pc21zLCBlLmcuLCBpbnRlZ3JhdGluZyB0aGVt IGludG8gdGhlIGV4aXN0aW5nIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBvciBzcGVjaWZ5aW5nIHRo ZW0gaW4gYSBzaW5nbGUgZG9jdW1lbnQgZm9yIGNvbnRyb2wgbWVjaGFuaXNtcy4NCg0KUmVnYXJk cywNCkxlZS4NCg0KMjAxNC4gNy4gMy4sIL/AwPwgNDo1MiwgSmltIEd1aWNoYXJkIChqZ3VpY2hh cikgPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4gwNu8ujoN Cg0KR3JlZXRpbmdzIFdHOg0KDQpPdXIgbWVldGluZyBhdCB0aGUgdXBjb21pbmcgVG9yb250byB2 ZW51ZSBpcyBmYXN0IGFwcHJvYWNoaW5nLiAgQXMgYWx3YXlzLCB0aGUgZ29hbCBvZiB0aGUgbWVl dGluZyB3aWxsIGJlIHRvIG1ha2UgdGhlIGJlc3QgdXNlIG9mIGxpbWl0ZWQgZmFjZS10by1mYWNl IHRpbWUuDQoNCkN1cnJlbnRseSwgd2UgaGF2ZSBhIG1lZXRpbmcgIHNsb3Qgc2NoZWR1bGVkIGZv ciA5QU0gV2VkbmVzZGF5IG1vcm5pbmcuDQoNCkFzIHdlIGJ1aWxkIHRoZSBtZWV0aW5nIGFnZW5k YSB3ZSB3ZWxjb21lIHJlcXVlc3RzIGZvciBhZ2VuZGEgdGltZS4gSG93ZXZlciwgdGhlcmUgYXJl IG1hbnkgZHJhZnRzIGFuZCBpdCBpcyBwb3NzaWJsZSAoaWYgbm90IGxpa2VseSkgdGhhdCB3ZSB3 aWxsIGJlIHVuYWJsZSB0byBnaXZlIGFsbCBvZiB0aGVtIGFnZW5kYSB0aW1lLiBBcyBhbHdheXMs IHRoZSBnb2FsIG9mIGEgbWVldGluZyBzbG90IGlzIHRvIGJlc3QgZnVydGhlciB0aGUgd29yayBv ZiB0aGUgV0csIGFuZCB0aGF0IGdlbmVyYWxseSBtZWFucyBmb2N1c3Npbmcgb24ga2V5IGNoYXJ0 ZXIgZGVsaXZlcmFibGVzIGFuZCB0b3BpY3Mgd2l0aCBpbXBvcnRhbnQgb3BlbiBpc3N1ZXMgdG8g cmVzb2x2ZS4gSW4gdGhlIGNhc2Ugb2YgaW5kaXZpZHVhbCBJRHMsIHRoZSBnb2FsIGlzbj90IG5l Y2Vzc2FyaWx5IHRvIHByZXNlbnQgd2hhdCBpcyBpbiB0aGUgZHJhZnQgYnV0IHJhdGhlciB0byBo ZWxwIHRoZSBXRyBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoZSBJRC4gV2l0aCB0aGF0IGluIG1p bmQsIHdoZW4gbWFraW5nIGFuIGFnZW5kYSByZXF1ZXN0IHBsZWFzZSBjb25zaWRlciB3aGF0IHlv dSB0aGluayB0aGUgV0cgc2hvdWxkIGRvIHdpdGggaXRzIGNvbnRlbnQuIEZvciBleGFtcGxlOg0K DQogICogICBEb2VzIHRoZSBkb2N1bWVudCBoYXZlIHVzZWZ1bCBjb250ZW50IHRoYXQgc2hvdWxk IGJlIG1vdmVkIGludG8gYW5vdGhlciBXRyBkb2N1bWVudCBvciBwcm9ncmVzcyBvbiBpdKGvcyBv d24gbWVyaXQNCiAgKiAgIERvZXMgdGhlIGNvbnRlbnQgaGF2ZSBhIGdvb2QgYmFzaXMgZm9yIG9u ZSBvZiB0aGUgV0cgZG9jdW1lbnRzIHBlciB0aGUgY2hhcnRlciAoaW4gb3JkZXIgZm9yIHRoYXQg dG8gaGFwcGVuIHRoZSBkb2N1bWVudCBuZWVkcyB0byBiZSB0aGUgbW9zdCBhcHByb3ByaWF0ZSBv dXQgb2YgdGhlIGNvbGxlY3Rpb24gb2YgcmVsYXRlZCBkb2N1bWVudHMpDQogICogICBTaG91bGQg dGhlIGRvY3VtZW50IGNvbnRlbnQgYmUgbWVyZ2VkIHdpdGggb25lIG9yIG1vcmUgb3RoZXIgZG9j dW1lbnRzLCBzbyB0aGF0IGEgY29tYmluZWQgZG9jdW1lbnQgY291bGQgYmVjb21lIGEgV0cgZG9j dW1lbnQNCg0KSmltICYgVGhvbWFzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_C008BF867BC045FAAFD61FE06E85DD24etrirekr_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
FYI, I missed sending it to the list. 


=C0=FC=B4=DE=B5=C8 =B8=DE=BD=C3=C1=F6 =BD=C3=C0=DB:

=BA=B8=B3=BD =BB=E7=B6=F7: Seung-Ik Lee <seungiklee@etri.re.kr>
=B3=AF=C2=A5: 2014=B3=E2 7=BF=F9 5=C0=CF =BF=C0=C0=FC 10=BD=C3 36=BA= =D0 18=C3=CA GMT+9
=B9=DE=B4=C2 =BB=E7=B6=F7: "Jim Guichard (jguichar)" <<= a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com>
=C2=FC=C1=B6: =BD=C5=B8=ED=B1=E2 <mkshin@etri.re.kr>
=C1=A6=B8=F1: Re: [sfc] Toronto SFC Meeting Agenda

Jim,

We've already got several I-Ds for the basis of PS, use cases, archite= cture.
Now it=A1=AFs good time to touch the control plane mechanisms for them= according to the WG charter, IMHO.

Based on the recently submitted I-Ds, we got several issues relevant t= o the control as follows:
- load balancing
- path optimization
- dynamic chain instantiation
- service function instance restoration
- chain redundancy

They could be a good start for the control plane mechanisms and may ex= tract some other requirements and architectural components.

What about making them discussed in 5 mins per each at this meeting wi= th what impact they would make to the requirement and architecture document= s? After that, we can go forward to discussing how to handle the control pl= ane mechanisms, e.g., integrating them into the existing architecture document or specifying them in a singl= e document for control mechanisms.

Regards,
Lee. 

2014. 7. 3., =BF=C0=C0=FC 4:52, Jim Guichard (jguichar) <jguichar@cisco.com> =C0=DB=BC=BA:

Greetings WG:

Our meeting at the upcomin= g Toronto venue is fast approaching.  As always, the goal of the me= eting will be to make the best use of limited face-to-face time.

Currently, we have a meeting  slo= t scheduled for 9AM Wednesday morning.

As we build the meeting agenda we welcome r= equests for agenda time. However, there are many drafts and it is possible = (if not likely) that we will be unable to give all of them agenda time. As = always, the goal of a meeting slot is to best further the work of the WG, and that generally means focussing = on key charter deliverables and topics with important open issues to resolv= e. In the case of individual IDs, the goal isn?t necessarily to present wha= t is in the draft but rather to help the WG decide what to do with the ID. With that in mind, when making = an agenda request please consider what you think the WG should do with its = content. For example:
  • Does the document have useful content that should be moved into another= WG document or progress on it=A1=AFs own merit
  • Does the content ha= ve a good basis for one of the WG documents per the charter (in order for t= hat to happen the document needs to be the most appropriate out of the coll= ection of related documents)
  • Should the document content be merged = with one or more other documents, so that a combined document could become = a WG document
Jim & Thomas
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_C008BF867BC045FAAFD61FE06E85DD24etrirekr_-- From nobody Sun Jul 6 13:56: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 99BB31A0AA3 for ; Sun, 6 Jul 2014 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 b67-4Yq9ZBOx for ; Sun, 6 Jul 2014 13:55:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C801A0AA2 for ; Sun, 6 Jul 2014 13:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10652; q=dns/txt; s=iport; t=1404680156; x=1405889756; h=from:to:subject:date:message-id:mime-version; bh=SJMDmb2x1rw23HXk6qmhhZ9hDAktJTvBv60DFxG4BiU=; b=hn2fUfAbsge/q70AjiXXk9Xo2celltRO2+1vPoPl56tY+n3XnZwuLWXb HmuHAjZlZOa+tKM4gIT2llDMhLMQialEDNvd27dGdcuY3PjKg3Vnmilx6 mQWfM+mMzyIdno0FCa6sKA8qrI/8wubNXWbonaZYp3yy8nuOtfiUtvt5h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAMS2uVOtJA2E/2dsb2JhbABagkdHUlq9F4kVgQ0WdYQDAQIELTokAQgRAQIBAig5FAMGCgQBEgmIOQ3JNBeJZYUsDYROBZp2gUiSRINDbIFE X-IronPort-AV: E=Sophos;i="5.01,613,1400025600"; d="scan'208,217";a="338025157" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jul 2014 20:55:55 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s66KttDE031499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jul 2014 20:55:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Sun, 6 Jul 2014 15:55:55 -0500 From: "Ken Gray (kegray)" To: Weixinpeng , "sfc@ietf.org" Thread-Topic: [sfc] A new draft-wei-sfc-mobile-consideration-00. Thread-Index: AQHPmVytesF+qQXHNUCUaFj9V9Ni4w== Date: Sun, 6 Jul 2014 20:55:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.203] Content-Type: multipart/alternative; boundary="_000_CFDF2CB13904Dkegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DkcbWuzHQoQFH_yR_1tIT_jtCNM Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Sun, 06 Jul 2014 20:55:58 -0000 --_000_CFDF2CB13904Dkegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey, Wei. Thanks for the document. I would suggest that you normalize your terminolo= gy in 2.1 (LSFC and PSFC) with whatever Joel and Carlos are cooking (draft-= merged-sfc-architecture) =96 otherwise it looks like you're adding to archi= tecture through a use case. That is, try and use their terms and not new o= nes. You take a shot at the interactions between LTE and SFC, and as someone els= e has already identified, maybe you need more detail? When you dig into the mobile architecture, is there a specific requirement = you see of the chain itself, like the relaying of metadata, the need for fo= rking in some of the flow paths (e.g. Charging)? Instead of mapping/wiring SFC into mobile (the GiLAN is an obvious use and = I encourage you to walk through a complete example), any thought to how the= LTE service chain might be re-envisioned in the presence of SFC (change in= roles, less reliance on DNS tricks, lower Diameter requirements)? Thanks for the document. From: Weixinpeng > Date: Tuesday, July 1, 2014 5:44 AM To: "sfc@ietf.org" > Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. --_000_CFDF2CB13904Dkegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <59D96F21B125F748900A9DB5E4C88E82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hey, Wei.

Thanks for the document.  I would suggest that you normalize your= terminology in 2.1 (LSFC and PSFC) with whatever Joel and Carlos are cooki= ng (draft-merged-sfc-architecture) =96 otherwise it looks like you're addin= g to architecture through a use case.  That is, try and use their terms and not new ones.  

You take a shot at the interactions between LTE and SFC, and as someon= e else has already identified, maybe you need more detail?

When you dig into the mobile architecture, is there a specific require= ment you see of the chain itself, like the relaying of metadata, the need f= or forking in some of the flow paths (e.g. Charging)?  

Instead of mapping/wiring SFC into mobile (the GiLAN is an obvious use= and I encourage you to walk through a complete example), any thought to ho= w the LTE service chain might be re-envisioned in the presence of SFC (chan= ge in roles, less reliance on DNS tricks, lower Diameter requirements)?

Thanks for the document.

From: Weixinpeng <weixinpeng@huawei.com>
Date: Tuesday, July 1, 2014 5:44 AM=
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] A new draft-wei-sfc-= mobile-consideration-00.

Hi all,

A new draft on Interaction b= etween SFC network and 3GPP network has been submitted. Comments are welcom= ed!

 

Best Regards,

Xinpeng

 

 

Name:    = ;           draft-wei-sfc= -mobile-consideration-00

Revision:  00

Title:   &nbs= p;            &= nbsp; Interaction between SFC network and 3GPP network

Document date:  &n= bsp;    2014-06-30

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           7=

URL:    =         http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 

 

Abstract:<= /p>

   This document p= rovides a discussion of how SFC (Service Function

   Chain) domain c= ould interact with carrier network to provide network

   service for tra= ffic. Here LTE (Long Term Evolution) network is used

   as an example o= f carrier network for discussion.

 

 --_000_CFDF2CB13904Dkegrayciscocom_-- From nobody Sun Jul 6 18:34: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 C03CB1A0089 for ; Sun, 6 Jul 2014 18:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gHkzc4vuIt64 for ; Sun, 6 Jul 2014 18:34:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6A71A0085 for ; Sun, 6 Jul 2014 18:34:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR61522; Mon, 07 Jul 2014 01:34:37 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 02:34:36 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 09:34:29 +0800 From: "Songhaibin (A)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-song-sfc-legacy-sf-mapping-02.txt Thread-Index: AQHPmYNhiQFVFzdPikmK6aR8cGgjk5uT1B3A Date: Mon, 7 Jul 2014 01:34:28 +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.138.41.49] 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/tGyQh8zCh4RXzhadCX9uvZWABj8 Subject: [sfc] FW: New Version Notification for draft-song-sfc-legacy-sf-mapping-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, 07 Jul 2014 01:34:40 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogTW9uZGF5 LCBKdWx5IDA3LCAyMDE0IDk6MzMgQU0NCj4gVG86IFNvbmdoYWliaW4gKEEpOyBMdWN5IHlvbmc7 IFlvdWppYW5qaWU7IFNvbmdoYWliaW4gKEEpOyBMdWN5IHlvbmc7IFlvdWppYW5qaWU7DQo+IEpp YW5neXVhbmxvbmc7IEppYW5neXVhbmxvbmcNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wMi50eHQNCj4gDQo+ IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBp bmctMDIudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZ b3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRy YWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nDQo+IFJldmlzaW9uOgkwMg0KPiBUaXRsZToJ CVNGQyBIZWFkZXIgTWFwcGluZyBmb3IgTGVnYWN5IFNGDQo+IERvY3VtZW50IGRhdGU6CTIwMTQt MDctMDQNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkxMg0KPiBV Ukw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNvbmctc2Zj LWxlZ2FjeS1zZi1tYXBwaW5nLTAyLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLw0KPiBIdG1s aXplZDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc29uZy1zZmMtbGVnYWN5 LXNmLW1hcHBpbmctMDINCj4gRGlmZjoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmctMDINCj4gDQo+IEFic3RyYWN0Og0K PiAgICBBIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQykgZ29lcyB0aHJvdWdoIGEgbGlzdCBv ZiBvcmRlcmVkIHNlcnZpY2UNCj4gICAgZnVuY3Rpb25zLiAgT25lIGFzc3VtcHRpb24gb2YgdGhp cyBkb2N1bWVudCBpcyB0aGF0IGxlZ2FjeSBzZXJ2aWNlDQo+ICAgIGZ1bmN0aW9uIGNhbiBwYXJ0 aWNpcGF0ZSBpbiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiwgYnV0IHRoZXkgYXJlDQo+ICAg IG5vdCBhd2FyZSBvZiB0aGUgU0ZDIGhlYWRlciwgbm9yIGludGVycHJldCBpdC4gIFRoaXMgZG9j dW1lbnQNCj4gICAgcHJvdmlkZXMgYSBtZWNoYW5pc20gYmV0d2VlbiBhbiBTRkMgcHJveHkgYW5k IGFuIFNGQy11bmF3YXJlIFNlcnZpY2UNCj4gICAgRnVuY3Rpb24gKGkuZS4gIGxlZ2FjeSBTRiks IHRvIGlkZW50aWZ5IHRoZSBTRkMgaGVhZGVyIGFzc29jaWF0ZWQNCj4gICAgd2l0aCBhIHBhY2tl dCB0aGF0IGlzIHJldHVybmVkIGZyb20gYSBsZWdhY3kgU0YsIHdpdGhvdXQgU0ZDIGhlYWRlcg0K PiAgICBiZWluZyBleHBsaWNpdGx5IGNhcnJpZWQgaW4gdGhlIHdpcmVkIHByb3RvY29sIGJldHdl ZW4gU0ZDIFByb3h5IGFuZA0KPiAgICBsZWdhY3kgU0YuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0K From nobody Sun Jul 6 19:32: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 991F41A00D2 for ; Sun, 6 Jul 2014 19:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3J6guPi6n1rj for ; Sun, 6 Jul 2014 19:32:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EE71A00C2 for ; Sun, 6 Jul 2014 19:32:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGV87028; Mon, 07 Jul 2014 02:32:32 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 03:32:32 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 10:32:25 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPl7hpdOHHacDAok+pQlwxvJ4ZgZuT24yw Date: Mon, 7 Jul 2014 02:32:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082908FB@NKGEML512-MBS.china.huawei.com> References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> In-Reply-To: <53B6F6B8.4040606@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rbK4qKqXD5jO6gV8Pr0yMl0kJos Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 07 Jul 2014 02:32:37 -0000 Hi Joel, > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Saturday, July 05, 2014 2:47 AM > To: Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-00.txt >=20 > I need to think about your other questions, but I wanted to highlight con= fusion > around yoru question 2. What you have drawn as Service Node is exactly t= he > opposite of what we intended. So we need help with better wording. >=20 > The Service Node is simply the housing for Service Functions. For a dedi= cate > (physical, ...) service function this would be the device. For a virtual= service > function this would be the platform and hypervisor hosting the service > function(s). For the housing for service functions, it seems better to simply call it as= service function node. For the device on which SFF and NF are mandatory co= mponents while SFC proxy and SF are optional component, it looks more impor= tant to the description of SFC architecture since it's the totally new devi= ce type (note that the service function nodes could be legacy service funct= ion nodes). Therefore we need to give it a name. I strongly believe "servic= e node" is a very appropriate name for such device. SFs could either be emb= edded on such "service node" or be attached to such "service node". To some= extent, the attached SF could be looked as an external service interface b= oard of such "service node". Best regards, Xiaohu > Yours, > Joel >=20 > On 7/4/14, 5:37 AM, Xuxiaohu wrote: > > Hi Joel, > > > > I have some comments as follows: > > > > 1. It said "..The SFC encapsulation enables service function path > > selection and the sharing of metadata/context information... " I > > wonder whether it would be more efficient and flexible by decoupling > > the service function path selection and the metadata convey > > functionalities by using different encapsulation headers. Since this > > framework draft is more or less related to the NSH draft > > (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the > > NSH as example for illustration: First, it seems the information > > (e.g., service path identifier information) contained in the SFC > > encapsulation (e.g., NSH) except the metadata is not interesting to > > SFs, and therefore it seems unnecessary to convey that information to > > the (SFC-aware) SFs, especially for those externally attached SFs. As > > for the O(AM) bit, I wonder whether the SFC OAM message must be > > forwarded to the SF. In other words, why can't the SFF process the OAM > > packets on behalf of the SF with the help of some health-che > ck like m > echanism between SFFs and SFs. As for the Service Index information, I wo= nder > whether Service index MUST be decremented by service functions (see the > corresponding description in the NSH draft). In other words, why can't it= be > decremented by the SFF on behalf of the SF; Second, the metadata is optio= nal > rather than mandatory. In a word, compared to the SFC-unware SF, it seems > that the only additional mandatory requirement on the SFC-aware SF is to = be > capable of processing metadata. > > > > 2. in Figure 3: Service Function Chain Architecture Components, it does= n't > illustrate the relationship between those components as shown in the Figu= re and > service nodes. I wonder whether the following figure could demonstrate th= e > relationship correctly, e.g., SFF, NF and SFC proxy are three mandatory > components of service nodes, while SFC-aware SFs could either be embedded > on service nodes (e.g., SF X in the following figure) or be physically at= tached to > service nodes (e.g., SF Y in the following figure). > > > > +----------------+ +----------------+ > > | SFC-aware | | SFC-unaware | > > |Service Function X| |Service Function| > > +-------+--------+ +-------+--------+ > > | | > > SFC Encapsulation No SFC Encapsulation > > +-------+-----------------------------------------+-------------+ > > | | SFC Encapsulation +---------+ | > > | +------------------+ +-------------|SFC Proxy| | > > | \ / +---------+ | > > | +-------+--------+ +----------------+ | > > | | SF Forwarder | | SFC-aware | > | > > | | (SFF) +------+Service Function Y| | > > | +-------+--------+ +-------+--------+ | > > | | > | > > | SFC Encapsulation > | > > | | > | > > | +-------+--------+ | > > | | SFC Network | > | > > | | Forwarder (NF) | > | > > | +----------------+ Service Node | > > | | > | > > +---------------------------------------------------------------+ > > 3. If my understanding of the relationship as mentioned above is > > correct, I suggest updating the following definition > > > > "SFC Network Forwarder (NF): SFC network forwarders provide > network > > connectivity for service function forwarders (SFF) and service > > functions (SF)." > > by > > "SFC Network Forwarder (NF): SFC network forwarders provide > network > > connectivity for service nodes." > > > > 4. According to the description about Transport Derived SFF in section = 4.3.1, it > seems that the SFC approach as described in > (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an instan= tiation of > such Transport Derived SFF model. Is my understanding of the Transport > Derived SFF concept correct? > > > > 5. in the definition of SFC proxy (in section 4.5), it seems that parti= al > functionalities of SFC proxy are overlapped with that of SFF, see below: > > > > o Identifies the required SF to be applied based on information > > carried in the SFC encapsulation. > > > > o Selects the appropriate outbound local attachment circuit throug= h > > which the next SF for this SFP is reachable. This information i= s > > derived from the SFC encapsulation or from local configuration. > > Examples of a local attachment circuit include, but are not > > limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. > > > > o Applies the required SFC encapsulation. The determination of th= e > > encapsulation details may be inferred by the local attachment > > circuit through which the packet and/or frame was received, or v= ia > > packet classification, or other local policy. In some cases, > > packet-ordering or modification by the SF may necessitate > > additional classification in order to re-apply the correct SFC > > encapsulation. > > > > o Imposes the appropriate SFC encapsulation based on the > > identification of the SFC to be applied. > > > > IMHO, the only necessary functionality of SFC proxy is to remove the he= ader > containing metadata before forwarding the packet to the SFC-unware SF and > while adding that header when receiving the packet returned from the > SFC-unware SF. > > > > 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service > > Function make up an SF" ----s/make up an SF/make up an SFC-aware > SF > > > > Best regards, > > Xiaohu > > > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: Friday, July 04, 2014 12:36 AM > >> To: sfc@ietf.org > >> Subject: [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-00.txt > >> > >> There has been a lot of discussion among the many authors of various > >> archtiecture document proposals, and other commenters on these > documents. > >> Carlos and I have tried to pull together what we think is a viable > >> document based on the available input and issues. We hope that it > >> will help carry the working group forward. > >> > >> (While the chairs requested that we try to do this, they did not > >> decide what we picked, and the working group gets to decide if it is u= seful. > >> Similarly while we took input from multiple places, we are to blame > >> for any errors, confusions, etc. The various other author teams have > >> NOT agreed that this represents their work. it is merely the best > >> Carlos and I could manage.) > >> > >> We look forward to discussion on the list, and in Toronto. > >> > >> Yours, > >> Joel (and Carlos) > >> > >> -------- Original Message -------- > >> Subject: New Version Notification for > >> draft-merged-sfc-architecture-00.txt > >> Date: Thu, 03 Jul 2014 06:32:22 -0700 > >> From: internet-drafts@ietf.org > >> To: Joel Halpern , Carlos Pignataro > >> , "Joel M. Halpern" , > >> "Carlos Pignataro" > >> > >> > >> A new version of I-D, draft-merged-sfc-architecture-00.txt > >> has been successfully submitted by Carlos Pignataro and posted to the > >> IETF repository. > >> > >> Name: draft-merged-sfc-architecture > >> Revision: 00 > >> Title: Service Function Chaining (SFC) Architecture > >> Document date: 2014-07-03 > >> Group: Individual Submission > >> Pages: 22 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00. > >> txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architectu= re-00 > >> > >> > >> Abstract: > >> This document describes an architecture for the specification, > >> creation, and ongoing maintenance of Service Function Chains (SFC= ) in > >> a network. It includes architectural concepts, principles, and > >> components used in the construction of composite services through > >> deployment of SFCs. 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 tools.= ietf.org. > >> > >> The IETF Secretariat > >> > >> > >> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Sun Jul 6 19:39: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 BD7D21A00D5 for ; Sun, 6 Jul 2014 19:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 9u_t55mW-aok for ; Sun, 6 Jul 2014 19:39:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CDFDA1A00C9 for ; Sun, 6 Jul 2014 19:39:35 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 93D061248F95 for ; Mon, 7 Jul 2014 10:39:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s672dG8p028180 for ; Mon, 7 Jul 2014 10:39:16 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: sfc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Mon, 7 Jul 2014 10:39:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-07 10:39:15, Serialize complete at 2014-07-07 10:39:15 Content-Type: multipart/alternative; boundary="=_alternative 000E4CB548257D0E_=" X-MAIL: mse01.zte.com.cn s672dG8p028180 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yQlMH2AD249K3Gpxt7wE9OmqtU4 Subject: [sfc] FW: New Version Notification for draft-meng-sfc-broadband-usecases-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, 07 Jul 2014 02:39:38 -0000 This is a multipart message in MIME format. --=_alternative 000E4CB548257D0E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KICBXZSBoYXZlIHN1bW1pdHRlZCBhIG5ldyB2ZXJzaW9uIGFib3V0IGJyb2Fk YmFuZC11c2VjYXNlcyB0byANCiAgZWxhYnJhdGUgc2V2ZXJhbCB0eXBpY2FsIHVzZWNhc2VzIGlu IEJyb2FkYmFuZCBOZXR3b3JrLg0KDQogIFdlIGFyZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBy ZXZpZXcgYW5kIGNvbW1lbnRzIG9uIHRoZSBsaXN0LCANCiAgYW5kIGluIFRvcm9udG8uDQoNCiAg VGhhbmtzIGEgbG90Lg0KDQpCZXN0IFJlZ2FyZHMsDQpMaW5kYSBXYW5nIGFuZCBNZW5nIFdlaQ0K DQoNCi0tLS0tINeqt6LIyyDN9bTkMDg3MTc1L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTQtMDctMDcg MTA6MzAgLS0tLS0NCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxNC0wNy0wNCAy MDo1MTo0MzoNCg0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1lbmctc2ZjLWJy b2FkYmFuZC11c2VjYXNlcy0wMi50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBXZWkgTWVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0K PiBOYW1lOiAgICAgIGRyYWZ0LW1lbmctc2ZjLWJyb2FkYmFuZC11c2VjYXNlcw0KPiBSZXZpc2lv bjogICAwMg0KPiBUaXRsZTogICAgICBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIFVzZSBDYXNlcyBp biBCcm9hZGJhbmQNCj4gRG9jdW1lbnQgZGF0ZTogICAyMDE0LTA3LTA0DQo+IEdyb3VwOiAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczogICAgICAyNQ0KPiBVUkw6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWVuZy1zZmMtDQo+ IGJyb2FkYmFuZC11c2VjYXNlcy0wMi50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lbmctc2ZjLQ0KPiBicm9hZGJhbmQtdXNlY2Fz ZXMvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t ZW5nLXNmYy1icm9hZGJhbmQtDQo+IHVzZWNhc2VzLTAyDQo+IERpZmY6ICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tZW5nLXNmYy0NCj4gYnJvYWRiYW5k LXVzZWNhc2VzLTAyDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkaXNjdXNz ZXMgYWJvdXQgc2VydmljZSBmdW5jdGlvbiB1c2UgY2FzZXMgaW4gZGlmZmVyZW50DQo+ICAgIHNj ZW5hcmlvcyBmb3IgZWFjaCBwYXJ0IG9mIGJyb2FkYmFuZCBuZXR3b3JrLiAgVGhlIGRvY3VtZW50 IHByb3ZpZGVzDQo+ICAgIGFuYWx5c2lzIG9mIGRpZmZlcmVudCBzb2x1dGlvbnMgYW5kIGFsc28g ZGVzY3JpYmVzIHRoZSBzdWl0YWJsZQ0KPiAgICBzY2VuYXJpb3MgdGhhdCBlYWNoIHNvbHV0aW9u IG1heSBiZSBkZXBsb3llZCBpbi4NCj4gDQo+ICANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCnN1Ym1p c3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KDQo= --=_alternative 000E4CB548257D0E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBhbGwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgV2UgaGF2ZSBzdW1t aXR0ZWQgYSBuZXcgdmVyc2lvbg0KYWJvdXQgYnJvYWRiYW5kLXVzZWNhc2VzIHRvIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IGVsYWJyYXRlIHNldmVy YWwgdHlwaWNhbCB1c2VjYXNlcw0KaW4gQnJvYWRiYW5kIE5ldHdvcmsuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgV2UgYXJlIGxvb2tpbmcg Zm9yd2FyZCB0byB5b3VyDQpyZXZpZXcgYW5kIGNvbW1lbnRzIG9uIHRoZSBsaXN0LCA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBhbmQgaW4gVG9yb250 by48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyBUaGFua3MgYSBsb3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5CZXN0IFJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5MaW5kYSBXYW5nIGFuZCBNZW5nIFdlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsg zfW05DA4NzE3NS91c2VyL3p0ZV9sdGQNCsqxvOQgMjAxNC0wNy0wNyAxMDozMCAtLS0tLTwvZm9u dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyDQ tNPaIDIwMTQtMDctMDQgMjA6NTE6NDM6PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tZW5nLXNmYy1icm9hZGJhbmQtdXNlY2FzZXMtMDIudHh0 PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaSBNZW5nIGFu ZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJmd0OyBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtbWVuZy1zZmMtYnJvYWRiYW5k LXVzZWNhc2VzPGJyPg0KJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAyPGJyPg0KJmd0OyBUaXRsZTog Jm5ic3A7ICZuYnNwOyAmbmJzcDtzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIFVzZSBDYXNlcyBpbiBC cm9hZGJhbmQ8YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAyMDE0LTA3LTA0PGJyPg0K Jmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+ DQomZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzI1PGJyPg0KJmd0OyBVUkw6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbWVuZy1zZmMtPGJyPg0KJmd0OyBicm9hZGJhbmQtdXNlY2Fz ZXMtMDIudHh0PGJyPg0KJmd0OyBTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZW5nLXNmYy08YnI+DQomZ3Q7 IGJyb2FkYmFuZC11c2VjYXNlcy88YnI+DQomZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZW5nLXNmYy1icm9hZGJhbmQt PGJyPg0KJmd0OyB1c2VjYXNlcy0wMjxicj4NCiZndDsgRGlmZjogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1t ZW5nLXNmYy08YnI+DQomZ3Q7IGJyb2FkYmFuZC11c2VjYXNlcy0wMjxicj4NCiZndDsgPGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRpc2N1 c3NlcyBhYm91dCBzZXJ2aWNlIGZ1bmN0aW9uIHVzZSBjYXNlcw0KaW4gZGlmZmVyZW50PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7c2NlbmFyaW9zIGZvciBlYWNoIHBhcnQgb2YgYnJvYWRiYW5kIG5l dHdvcmsuICZuYnNwO1RoZQ0KZG9jdW1lbnQgcHJvdmlkZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDthbmFseXNpcyBvZiBkaWZmZXJlbnQgc29sdXRpb25zIGFuZCBhbHNvIGRlc2NyaWJlcyB0aGUN CnN1aXRhYmxlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c2NlbmFyaW9zIHRoYXQgZWFjaCBzb2x1 dGlvbiBtYXkgYmUgZGVwbG95ZWQgaW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YNCnN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyA8YnI+DQo8 L2ZvbnQ+PC90dD4NCg== --=_alternative 000E4CB548257D0E_=-- From nobody Sun Jul 6 19:40: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 2A9571A00D6 for ; Sun, 6 Jul 2014 19:40:46 -0700 (PDT) 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 7EhYtxiPXyPS for ; Sun, 6 Jul 2014 19:40:43 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF401A00C9 for ; Sun, 6 Jul 2014 19:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BCFB5240F1C; Sun, 6 Jul 2014 19:40:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-98.clppva.east.verizon.net [70.106.134.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8DB0D240949; Sun, 6 Jul 2014 19:40:42 -0700 (PDT) Message-ID: <53BA08AA.1070109@joelhalpern.com> Date: Sun, 06 Jul 2014 22:40:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Xuxiaohu , "sfc@ietf.org" References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082908FB@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082908FB@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jXu9f5oog_d0s4ybk3oibCE2bhU Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 07 Jul 2014 02:40:46 -0000 It is not clear to me that the archtiecture requires a physical device which must house both an NF and an SFF. Certainly it permits such a device. But there clearly are devices which provide NF without SFF. And it seems likely that some solutions will allow for SFF without NF. Yours, Joel On 7/6/14, 10:32 PM, Xuxiaohu wrote: > Hi Joel, > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Saturday, July 05, 2014 2:47 AM >> To: Xuxiaohu; sfc@ietf.org >> Subject: Re: [sfc] Fwd: New Version Notification for >> draft-merged-sfc-architecture-00.txt >> >> I need to think about your other questions, but I wanted to highlight confusion >> around yoru question 2. What you have drawn as Service Node is exactly the >> opposite of what we intended. So we need help with better wording. >> >> The Service Node is simply the housing for Service Functions. For a dedicate >> (physical, ...) service function this would be the device. For a virtual service >> function this would be the platform and hypervisor hosting the service >> function(s). > > For the housing for service functions, it seems better to simply call it as service function node. For the device on which SFF and NF are mandatory components while SFC proxy and SF are optional component, it looks more important to the description of SFC architecture since it's the totally new device type (note that the service function nodes could be legacy service function nodes). Therefore we need to give it a name. I strongly believe "service node" is a very appropriate name for such device. SFs could either be embedded on such "service node" or be attached to such "service node". To some extent, the attached SF could be looked as an external service interface board of such "service node". > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> On 7/4/14, 5:37 AM, Xuxiaohu wrote: >>> Hi Joel, >>> >>> I have some comments as follows: >>> >>> 1. It said "..The SFC encapsulation enables service function path >>> selection and the sharing of metadata/context information... " I >>> wonder whether it would be more efficient and flexible by decoupling >>> the service function path selection and the metadata convey >>> functionalities by using different encapsulation headers. Since this >>> framework draft is more or less related to the NSH draft >>> (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the >>> NSH as example for illustration: First, it seems the information >>> (e.g., service path identifier information) contained in the SFC >>> encapsulation (e.g., NSH) except the metadata is not interesting to >>> SFs, and therefore it seems unnecessary to convey that information to >>> the (SFC-aware) SFs, especially for those externally attached SFs. As >>> for the O(AM) bit, I wonder whether the SFC OAM message must be >>> forwarded to the SF. In other words, why can't the SFF process the OAM >>> packets on behalf of the SF with the help of some health-che >> ck like m >> echanism between SFFs and SFs. As for the Service Index information, I wonder >> whether Service index MUST be decremented by service functions (see the >> corresponding description in the NSH draft). In other words, why can't it be >> decremented by the SFF on behalf of the SF; Second, the metadata is optional >> rather than mandatory. In a word, compared to the SFC-unware SF, it seems >> that the only additional mandatory requirement on the SFC-aware SF is to be >> capable of processing metadata. >>> >>> 2. in Figure 3: Service Function Chain Architecture Components, it doesn't >> illustrate the relationship between those components as shown in the Figure and >> service nodes. I wonder whether the following figure could demonstrate the >> relationship correctly, e.g., SFF, NF and SFC proxy are three mandatory >> components of service nodes, while SFC-aware SFs could either be embedded >> on service nodes (e.g., SF X in the following figure) or be physically attached to >> service nodes (e.g., SF Y in the following figure). >>> >>> +----------------+ +----------------+ >>> | SFC-aware | | SFC-unaware | >>> |Service Function X| |Service Function| >>> +-------+--------+ +-------+--------+ >>> | | >>> SFC Encapsulation No SFC Encapsulation >>> +-------+-----------------------------------------+-------------+ >>> | | SFC Encapsulation +---------+ | >>> | +------------------+ +-------------|SFC Proxy| | >>> | \ / +---------+ | >>> | +-------+--------+ +----------------+ | >>> | | SF Forwarder | | SFC-aware | >> | >>> | | (SFF) +------+Service Function Y| | >>> | +-------+--------+ +-------+--------+ | >>> | | >> | >>> | SFC Encapsulation >> | >>> | | >> | >>> | +-------+--------+ | >>> | | SFC Network | >> | >>> | | Forwarder (NF) | >> | >>> | +----------------+ Service Node | >>> | | >> | >>> +---------------------------------------------------------------+ >>> 3. If my understanding of the relationship as mentioned above is >>> correct, I suggest updating the following definition >>> >>> "SFC Network Forwarder (NF): SFC network forwarders provide >> network >>> connectivity for service function forwarders (SFF) and service >>> functions (SF)." >>> by >>> "SFC Network Forwarder (NF): SFC network forwarders provide >> network >>> connectivity for service nodes." >>> >>> 4. According to the description about Transport Derived SFF in section 4.3.1, it >> seems that the SFC approach as described in >> (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an instantiation of >> such Transport Derived SFF model. Is my understanding of the Transport >> Derived SFF concept correct? >>> >>> 5. in the definition of SFC proxy (in section 4.5), it seems that partial >> functionalities of SFC proxy are overlapped with that of SFF, see below: >>> >>> o Identifies the required SF to be applied based on information >>> carried in the SFC encapsulation. >>> >>> o Selects the appropriate outbound local attachment circuit through >>> which the next SF for this SFP is reachable. This information is >>> derived from the SFC encapsulation or from local configuration. >>> Examples of a local attachment circuit include, but are not >>> limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. >>> >>> o Applies the required SFC encapsulation. The determination of the >>> encapsulation details may be inferred by the local attachment >>> circuit through which the packet and/or frame was received, or via >>> packet classification, or other local policy. In some cases, >>> packet-ordering or modification by the SF may necessitate >>> additional classification in order to re-apply the correct SFC >>> encapsulation. >>> >>> o Imposes the appropriate SFC encapsulation based on the >>> identification of the SFC to be applied. >>> >>> IMHO, the only necessary functionality of SFC proxy is to remove the header >> containing metadata before forwarding the packet to the SFC-unware SF and >> while adding that header when receiving the packet returned from the >> SFC-unware SF. >>> >>> 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service >>> Function make up an SF" ----s/make up an SF/make up an SFC-aware >> SF >>> >>> Best regards, >>> Xiaohu >>> >>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Friday, July 04, 2014 12:36 AM >>>> To: sfc@ietf.org >>>> Subject: [sfc] Fwd: New Version Notification for >>>> draft-merged-sfc-architecture-00.txt >>>> >>>> There has been a lot of discussion among the many authors of various >>>> archtiecture document proposals, and other commenters on these >> documents. >>>> Carlos and I have tried to pull together what we think is a viable >>>> document based on the available input and issues. We hope that it >>>> will help carry the working group forward. >>>> >>>> (While the chairs requested that we try to do this, they did not >>>> decide what we picked, and the working group gets to decide if it is useful. >>>> Similarly while we took input from multiple places, we are to blame >>>> for any errors, confusions, etc. The various other author teams have >>>> NOT agreed that this represents their work. it is merely the best >>>> Carlos and I could manage.) >>>> >>>> We look forward to discussion on the list, and in Toronto. >>>> >>>> Yours, >>>> Joel (and Carlos) >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-merged-sfc-architecture-00.txt >>>> Date: Thu, 03 Jul 2014 06:32:22 -0700 >>>> From: internet-drafts@ietf.org >>>> To: Joel Halpern , Carlos Pignataro >>>> , "Joel M. Halpern" , >>>> "Carlos Pignataro" >>>> >>>> >>>> A new version of I-D, draft-merged-sfc-architecture-00.txt >>>> has been successfully submitted by Carlos Pignataro and posted to the >>>> IETF repository. >>>> >>>> Name: draft-merged-sfc-architecture >>>> Revision: 00 >>>> Title: Service Function Chaining (SFC) Architecture >>>> Document date: 2014-07-03 >>>> Group: Individual Submission >>>> Pages: 22 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00. >>>> txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ >>>> Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-00 >>>> >>>> >>>> Abstract: >>>> This document describes an architecture for the specification, >>>> creation, and ongoing maintenance of Service Function Chains (SFC) in >>>> a network. It includes architectural concepts, principles, and >>>> components used in the construction of composite services through >>>> deployment of SFCs. 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 tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Sun Jul 6 20:17: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 7C7721A0AD2 for ; Sun, 6 Jul 2014 20:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 OySguRH_Zl2M for ; Sun, 6 Jul 2014 20:17:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9301A0AD0 for ; Sun, 6 Jul 2014 20:17:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR67198; Mon, 07 Jul 2014 03:17:05 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 04:17:03 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 11:16:58 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPl7hpdOHHacDAok+pQlwxvJ4ZgZuT24yw//+IlwCAAIflkA== Date: Mon, 7 Jul 2014 03:16:57 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829093F@NKGEML512-MBS.china.huawei.com> References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082908FB@NKGEML512-MBS.china.huawei.com> <53BA08AA.1070109@joelhalpern.com> In-Reply-To: <53BA08AA.1070109@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fdwXPjuas6XinEj3H9IGd20IAQg Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 07 Jul 2014 03:17:11 -0000 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, July 07, 2014 10:41 AM > To: Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-00.txt >=20 > It is not clear to me that the archtiecture requires a physical device wh= ich must > house both an NF and an SFF. Certainly it permits such a device. But th= ere I agree NF and SFF could be implemented on separate devices in theory. Howe= ver, I'm not sure whether it will be implemented in that way in reality. > clearly are devices which provide NF without SFF. Sure, that device which provides NF w/o SFF is called as tunnel encapsulato= r/decapsualtor. > And it seems likely that some solutions will allow for SFF without NF. Did you mean that SFF would receive unencapsulated traffic with the NSH as = the outermost header? BTW, it seems that there are some functionality overlapping (i.e., overlay = encap/decap) between SFF and NF: "If there is another hop in the SFP, the SFF, encapsulates the traffic in the appropriate network transport and delivers it to the NF for delivery to the next SFF along the path... When traffic arrives at the SFF after the last SF has finished servicing it, SFF fails to find the next SF or knows from the service forwarding state that the SFC is complete. SFF removes the SFC encapsulation and delivers the packet to an NF for forwarding..." " ...This component (NF) is responsible for performing the overlay encapsulation/de-capsulation and forwarding of packets on the overlay network..." In addition, according to the following statement "However, the SFC encapsu= lation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. The SFC encapsulation therefore, relies on an outer network transport." The SFC encapsulation just mean the NSH, if so, when= a packet with SFC encapsulation is received from SFF, should the NF be res= ponsible for encapsulating it with the appropriate transport header? If so,= how could the NF determine that appropriate transport header? By reading t= he path id information in the SFC encapsulation? If so, it seems conflict w= ith the following description: " NF forwarding may consult the SFC encapsulation or the inner payload of an incoming packet only in the necessary cases to achieve optimal forwarding in the network. " Best regards, Xiaohu > Yours, > Joel >=20 > On 7/6/14, 10:32 PM, Xuxiaohu wrote: > > Hi Joel, > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Saturday, July 05, 2014 2:47 AM > >> To: Xuxiaohu; sfc@ietf.org > >> Subject: Re: [sfc] Fwd: New Version Notification for > >> draft-merged-sfc-architecture-00.txt > >> > >> I need to think about your other questions, but I wanted to highlight > >> confusion around yoru question 2. What you have drawn as Service > >> Node is exactly the opposite of what we intended. So we need help wit= h > better wording. > >> > >> The Service Node is simply the housing for Service Functions. For a > >> dedicate (physical, ...) service function this would be the device. > >> For a virtual service function this would be the platform and > >> hypervisor hosting the service function(s). > > > > For the housing for service functions, it seems better to simply call i= t as service > function node. For the device on which SFF and NF are mandatory component= s > while SFC proxy and SF are optional component, it looks more important to= the > description of SFC architecture since it's the totally new device type (n= ote that > the service function nodes could be legacy service function nodes). There= fore > we need to give it a name. I strongly believe "service node" is a very ap= propriate > name for such device. SFs could either be embedded on such "service node"= or > be attached to such "service node". To some extent, the attached SF could= be > looked as an external service interface board of such "service node". > > > > Best regards, > > Xiaohu > > > >> Yours, > >> Joel > >> > >> On 7/4/14, 5:37 AM, Xuxiaohu wrote: > >>> Hi Joel, > >>> > >>> I have some comments as follows: > >>> > >>> 1. It said "..The SFC encapsulation enables service function path > >>> selection and the sharing of metadata/context information... " I > >>> wonder whether it would be more efficient and flexible by decoupling > >>> the service function path selection and the metadata convey > >>> functionalities by using different encapsulation headers. Since this > >>> framework draft is more or less related to the NSH draft > >>> (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the > >>> NSH as example for illustration: First, it seems the information > >>> (e.g., service path identifier information) contained in the SFC > >>> encapsulation (e.g., NSH) except the metadata is not interesting to > >>> SFs, and therefore it seems unnecessary to convey that information > >>> to the (SFC-aware) SFs, especially for those externally attached > >>> SFs. As for the O(AM) bit, I wonder whether the SFC OAM message must > >>> be forwarded to the SF. In other words, why can't the SFF process > >>> the OAM packets on behalf of the SF with the help of some health-che > >> ck like m > >> echanism between SFFs and SFs. As for the Service Index information, > >> I wonder whether Service index MUST be decremented by service > >> functions (see the corresponding description in the NSH draft). In > >> other words, why can't it be decremented by the SFF on behalf of the > >> SF; Second, the metadata is optional rather than mandatory. In a > >> word, compared to the SFC-unware SF, it seems that the only > >> additional mandatory requirement on the SFC-aware SF is to be capable = of > processing metadata. > >>> > >>> 2. in Figure 3: Service Function Chain Architecture Components, it > >>> doesn't > >> illustrate the relationship between those components as shown in the > >> Figure and service nodes. I wonder whether the following figure could > >> demonstrate the relationship correctly, e.g., SFF, NF and SFC proxy > >> are three mandatory components of service nodes, while SFC-aware SFs > >> could either be embedded on service nodes (e.g., SF X in the > >> following figure) or be physically attached to service nodes (e.g., SF= Y in the > following figure). > >>> > >>> +----------------+ +----------------+ > >>> | SFC-aware | | SFC-unaware > | > >>> |Service Function X| |Service Function| > >>> +-------+--------+ +-------+--------+ > >>> | | > >>> SFC Encapsulation No SFC Encapsulation > >>> +-------+-----------------------------------------+-------------+ > >>> | | SFC Encapsulation +---------+ > | > >>> | +------------------+ +-------------|SFC Proxy| | > >>> | \ / +---------+ > | > >>> | +-------+--------+ +----------------+ | > >>> | | SF Forwarder | | SFC-aware > | > >> | > >>> | | (SFF) +------+Service Function > Y| | > >>> | +-------+--------+ +-------+--------+ | > >>> | | > >> | > >>> | SFC Encapsulation > >> | > >>> | | > >> | > >>> | +-------+--------+ > | > >>> | | SFC Network | > >> | > >>> | | Forwarder (NF) | > >> | > >>> | +----------------+ Service Node | > >>> | | > >> | > >>> > >>> +---------------------------------------------------------------+ > >>> 3. If my understanding of the relationship as mentioned above is > >>> correct, I suggest updating the following definition > >>> > >>> "SFC Network Forwarder (NF): SFC network forwarders provide > >> network > >>> connectivity for service function forwarders (SFF) and serv= ice > >>> functions (SF)." > >>> by > >>> "SFC Network Forwarder (NF): SFC network forwarders provide > >> network > >>> connectivity for service nodes." > >>> > >>> 4. According to the description about Transport Derived SFF in > >>> section 4.3.1, it > >> seems that the SFC approach as described in > >> (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an > >> instantiation of such Transport Derived SFF model. Is my > >> understanding of the Transport Derived SFF concept correct? > >>> > >>> 5. in the definition of SFC proxy (in section 4.5), it seems that > >>> partial > >> functionalities of SFC proxy are overlapped with that of SFF, see belo= w: > >>> > >>> o Identifies the required SF to be applied based on information > >>> carried in the SFC encapsulation. > >>> > >>> o Selects the appropriate outbound local attachment circuit > through > >>> which the next SF for this SFP is reachable. This informatio= n is > >>> derived from the SFC encapsulation or from local configuratio= n. > >>> Examples of a local attachment circuit include, but are not > >>> limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. > >>> > >>> o Applies the required SFC encapsulation. The determination of > the > >>> encapsulation details may be inferred by the local attachment > >>> circuit through which the packet and/or frame was received, o= r > via > >>> packet classification, or other local policy. In some cases, > >>> packet-ordering or modification by the SF may necessitate > >>> additional classification in order to re-apply the correct SF= C > >>> encapsulation. > >>> > >>> o Imposes the appropriate SFC encapsulation based on the > >>> identification of the SFC to be applied. > >>> > >>> IMHO, the only necessary functionality of SFC proxy is to remove the > >>> header > >> containing metadata before forwarding the packet to the SFC-unware SF > >> and while adding that header when receiving the packet returned from > >> the SFC-unware SF. > >>> > >>> 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service > >>> Function make up an SF" ----s/make up an SF/make up an > SFC-aware > >> SF > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. > >>>> Halpern > >>>> Sent: Friday, July 04, 2014 12:36 AM > >>>> To: sfc@ietf.org > >>>> Subject: [sfc] Fwd: New Version Notification for > >>>> draft-merged-sfc-architecture-00.txt > >>>> > >>>> There has been a lot of discussion among the many authors of > >>>> various archtiecture document proposals, and other commenters on > >>>> these > >> documents. > >>>> Carlos and I have tried to pull together what we think is a viable > >>>> document based on the available input and issues. We hope that it > >>>> will help carry the working group forward. > >>>> > >>>> (While the chairs requested that we try to do this, they did not > >>>> decide what we picked, and the working group gets to decide if it is= useful. > >>>> Similarly while we took input from multiple places, we are to blame > >>>> for any errors, confusions, etc. The various other author teams > >>>> have NOT agreed that this represents their work. it is merely the > >>>> best Carlos and I could manage.) > >>>> > >>>> We look forward to discussion on the list, and in Toronto. > >>>> > >>>> Yours, > >>>> Joel (and Carlos) > >>>> > >>>> -------- Original Message -------- > >>>> Subject: New Version Notification for > >>>> draft-merged-sfc-architecture-00.txt > >>>> Date: Thu, 03 Jul 2014 06:32:22 -0700 > >>>> From: internet-drafts@ietf.org > >>>> To: Joel Halpern , Carlos Pignataro > >>>> , "Joel M. Halpern" , > >>>> "Carlos Pignataro" > >>>> > >>>> > >>>> A new version of I-D, draft-merged-sfc-architecture-00.txt > >>>> has been successfully submitted by Carlos Pignataro and posted to > >>>> the IETF repository. > >>>> > >>>> Name: draft-merged-sfc-architecture > >>>> Revision: 00 > >>>> Title: Service Function Chaining (SFC) Architecture > >>>> Document date: 2014-07-03 > >>>> Group: Individual Submission > >>>> Pages: 22 > >>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00= . > >>>> txt > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >>>> Htmlized: > http://tools.ietf.org/html/draft-merged-sfc-architecture-00 > >>>> > >>>> > >>>> Abstract: > >>>> This document describes an architecture for the specification, > >>>> creation, and ongoing maintenance of Service Function Chains > (SFC) in > >>>> a network. It includes architectural concepts, principles, an= d > >>>> components used in the construction of composite services > through > >>>> deployment of SFCs. 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 > >>> > > From nobody Mon Jul 7 01:39: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 AD1A61B27CF for ; Mon, 7 Jul 2014 01:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gR44fZKKfDFm for ; Mon, 7 Jul 2014 01:39:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7221A00FD for ; Mon, 7 Jul 2014 01:39:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR94448; Mon, 07 Jul 2014 08:39:18 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 09:39:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 16:39:11 +0800 From: Xuxiaohu To: "Surendra Kumar (smkumar)" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-00.txt Thread-Index: AQHPl7hpdOHHacDAok+pQlwxvJ4ZgZuQHCWAgAQnuNA= Date: Mon, 7 Jul 2014 08:39:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290D27@NKGEML512-MBS.china.huawei.com> References: <20140703133222.6715.8975.idtracker@ietfa.amsl.com> <53B58663.6060307@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903B4@NKGEML512-MBS.china.huawei.com> <53B6F6B8.4040606@joelhalpern.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lAEvj0zSCz64NK7CYyVNIzQwKWE Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-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, 07 Jul 2014 08:39:23 -0000 Hi Surendra, > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Saturday, July 05, 2014 8:34 AM > To: Joel M. Halpern; Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Fwd: New Version Notification for > draft-merged-sfc-architecture-00.txt >=20 > I have some comments inline. >=20 > On 7/4/14 11:47 AM, "Joel M. Halpern" wrote: >=20 > >I need to think about your other questions, but I wanted to highlight > >confusion around yoru question 2. What you have drawn as Service Node > >is exactly the opposite of what we intended. So we need help with > >better wording. > > > >The Service Node is simply the housing for Service Functions. For a > >dedicate (physical, ...) service function this would be the device. > >For a virtual service function this would be the platform and > >hypervisor hosting the service function(s). > > > >Yours, > >Joel > > > >On 7/4/14, 5:37 AM, Xuxiaohu wrote: > >> Hi Joel, > >> > >> I have some comments as follows: > >> > >> 1. It said "..The SFC encapsulation enables service function path > >>selection and the sharing of metadata/context information... " I > >>wonder whether it would be more efficient and flexible by decoupling > >>the service function path selection and the metadata convey > >>functionalities by using different encapsulation headers. Since this > >>framework draft is more or less related to the NSH draft > >>(http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), > SK> there is a rev-03 btw. Thanks for pointing out this revision.=20 > >>Let me take the NSH as example for illustration: First, it seems the > >>information (e.g., service path identifier information) contained in > >>the SFC encapsulation (e.g., NSH) except the metadata is not > >>interesting to SFs, and therefore it seems unnecessary to convey that > >>information to the (SFC-aware) SFs, especially for those externally att= ached > SFs. > SK> Not sure I understand this. That ID is the one identifying the SF > forwarding state and is needed in order to keep the traffic on a certain = SFC, or > SFP to be specific. Moreover that ID may be correlate to the metadata. Th= at ID > also allows for state-less SFF implementation. So, that ID is absolutely = necessary. I have no doubt that the path ID information is necessary for the SFF. I'm = just wondering what's meaning of that path ID information to the SF.=20 >=20 > >>As for the O(AM) bit, I wonder whether the SFC OAM message must be > >>forwarded to the SF. In other words, why can't the SFF process the OAM > >>packets on behalf of the SF with the help of some health-che > > ck like m > >echanism between SFFs and SFs. > SK> There are benefits to having OAM sent up to the SFs, depending on > SK> how > OAM is implemented. If not anything, it verifies the path through the SFs= . Suppose the SF is an SFC-unware SF, could we still perform SF OAM functions= (e.g.., SF availability check) on that SFC-unware SF? For example, could t= he SFF or the SF proxy process the OAM messages on behalf of the SFC-unware= SF? > >As for the Service Index information, I wonder whether Service index > >MUST be decremented by service functions (see the corresponding > >description in the NSH draft). In other words, why can't it be > >decremented by the SFF on behalf of the SF; Second, the metadata is opti= onal > rather than mandatory. > >In a word, compared to the SFC-unware SF, it seems that the only > >additional mandatory requirement on the SFC-aware SF is to be capable > >of processing metadata. > SK> SFF MUST decrement-able by the SFF. That wording needs to be updated > as far as I can tell "Service Index (SI): provides location within the service path. =20 Service index MUST be decremented by service functions or proxy node= s =20 after performing required services" ---quoted from -03 version of NS= H draft. Did you agree that the service index MUST be decremented by the SFF, rather= than the SF? > >> > >> 2. in Figure 3: Service Function Chain Architecture Components, it > >>doesn't illustrate the relationship between those components as shown > >>in the Figure and service nodes. I wonder whether the following figure > >>could demonstrate the relationship correctly, e.g., SFF, NF and SFC > >>proxy are three mandatory components of service nodes, while SFC-aware > >>SFs could either be embedded on service nodes (e.g., SF X in the > >>following figure) or be physically attached to service nodes (e.g., SF > >>Y in the following figure). > >> > >> +----------------+ +----------------+ > >> | SFC-aware | | SFC-unaware | > >> |Service Function X| |Service Function| > >> +-------+--------+ +-------+--------+ > >> | | > >> SFC Encapsulation No SFC Encapsulation > >> +-------+-----------------------------------------+-------------+ > >> | | SFC Encapsulation +---------+ | > >> | +------------------+ +-------------|SFC Proxy| | > >> | \ / +---------+ | > >> | +-------+--------+ +----------------+ | > >> | | SF Forwarder | | SFC-aware > | | > >> | | (SFF) +------+Service Function Y| | > >> | +-------+--------+ +-------+--------+ | > >> | | > | > >> | SFC Encapsulation > | > >> | | > | > >> | +-------+--------+ | > >> | | SFC Network | > | > >> | | Forwarder (NF) | > | > >> | +----------------+ Service Node | > >> | | > | > >> +---------------------------------------------------------------+ > SK> I would not draw it this way. However, NF+SFF+SF could potentially > SK> be > in the same box, irrespective of what we call it. A firewall with forward= ing I think we should define a term for such box which contains SFF and NF comp= onents at least. SFs could be embedded on such box or be attached to such b= ox. Best regards, Xiaohu > capability that also hosts an SFF and a host of security SFs, is an examp= le I can > think of. So, that boundary depends on the implementation. >=20 >=20 > >> 3. If my understanding of the relationship as mentioned above is > >>correct, I suggest updating the following definition > >> > >> "SFC Network Forwarder (NF): SFC network forwarders provide > network > >> connectivity for service function forwarders (SFF) and servic= e > >> functions (SF)." > >> by > >> "SFC Network Forwarder (NF): SFC network forwarders provide > network > >> connectivity for service nodes." > >> > >> 4. According to the description about Transport Derived SFF in > >>section 4.3.1, it seems that the SFC approach as described in > >>(http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an > >>instantiation of such Transport Derived SFF model. Is my understanding > >>of the Transport Derived SFF concept correct? > >> > >> 5. in the definition of SFC proxy (in section 4.5), it seems that > >>partial functionalities of SFC proxy are overlapped with that of SFF, > >>see below: > >> > >> o Identifies the required SF to be applied based on information > >> carried in the SFC encapsulation. > >> > >> o Selects the appropriate outbound local attachment circuit throu= gh > >> which the next SF for this SFP is reachable. This information = is > >> derived from the SFC encapsulation or from local configuration. > >> Examples of a local attachment circuit include, but are not > >> limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN. > >> > >> o Applies the required SFC encapsulation. The determination of t= he > >> encapsulation details may be inferred by the local attachment > >> circuit through which the packet and/or frame was received, or > >>via > >> packet classification, or other local policy. In some cases, > >> packet-ordering or modification by the SF may necessitate > >> additional classification in order to re-apply the correct SFC > >> encapsulation. > >> > >> o Imposes the appropriate SFC encapsulation based on the > >> identification of the SFC to be applied. > >> > >> IMHO, the only necessary functionality of SFC proxy is to remove the > >>header containing metadata before forwarding the packet to the > >>SFC-unware SF and while adding that header when receiving the packet > >>returned from the SFC-unware SF. > >> > >> 6. "Architecturally, the SFC Proxy along with an SFC-unaware Service > >> Function make up an SF" ----s/make up an SF/make up an SFC-aware > >>SF > >> > >> Best regards, > >> Xiaohu > >> > >> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >>> Sent: Friday, July 04, 2014 12:36 AM > >>> To: sfc@ietf.org > >>> Subject: [sfc] Fwd: New Version Notification for > >>> draft-merged-sfc-architecture-00.txt > >>> > >>> There has been a lot of discussion among the many authors of various > >>>archtiecture document proposals, and other commenters on these > >>>documents. > >>> Carlos and I have tried to pull together what we think is a viable > >>>document based on the available input and issues. We hope that it > >>>will help carry the working group forward. > >>> > >>> (While the chairs requested that we try to do this, they did not > >>>decide what we picked, and the working group gets to decide if it is > >>>useful. > >>> Similarly while we took input from multiple places, we are to blame > >>>for any errors, confusions, etc. The various other author teams > >>>have NOT agreed that this represents their work. it is merely the > >>>best Carlos and I could > >>>manage.) > >>> > >>> We look forward to discussion on the list, and in Toronto. > >>> > >>> Yours, > >>> Joel (and Carlos) > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>>draft-merged-sfc-architecture-00.txt > >>> Date: Thu, 03 Jul 2014 06:32:22 -0700 > >>> From: internet-drafts@ietf.org > >>> To: Joel Halpern , Carlos Pignataro > >>>, "Joel M. Halpern" , > >>>"Carlos Pignataro" > >>> > >>> > >>> A new version of I-D, draft-merged-sfc-architecture-00.txt > >>> has been successfully submitted by Carlos Pignataro and posted to > >>>the IETF repository. > >>> > >>> Name: draft-merged-sfc-architecture > >>> Revision: 00 > >>> Title: Service Function Chaining (SFC) Architecture > >>> Document date: 2014-07-03 > >>> Group: Individual Submission > >>> Pages: 22 > >>> URL: > >>> > >>>http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00. > >>>txt > >>> Status: > >>> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ > >>> Htmlized: > >>>http://tools.ietf.org/html/draft-merged-sfc-architecture-00 > >>> > >>> > >>> Abstract: > >>> This document describes an architecture for the specification, > >>> creation, and ongoing maintenance of Service Function Chains > >>>(SFC) in > >>> a network. It includes architectural concepts, principles, and > >>> components used in the construction of composite services throug= h > >>> deployment of SFCs. 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 > >>>tools.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 From nobody Mon Jul 7 02:10: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 794951B27F0 for ; Mon, 7 Jul 2014 02:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 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.651, 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 egRFaQPvorub for ; Mon, 7 Jul 2014 02:10:11 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id AE7511B27EB for ; Mon, 7 Jul 2014 02:10:11 -0700 (PDT) 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 s679A3ax032605 for ; Mon, 7 Jul 2014 18:10:03 +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 43C42E012D for ; Mon, 7 Jul 2014 18:10:03 +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 2DFD5E012C for ; Mon, 7 Jul 2014 18:10:03 +0900 (JST) Received: from [127.0.0.1] ([129.60.20.75]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id s679A2ux005709 for ; Mon, 7 Jul 2014 18:10:03 +0900 Message-ID: <53BA63A9.7040407@lab.ntt.co.jp> Date: Mon, 07 Jul 2014 18:08:57 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sfc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UoDn_aeD_WNJL6_8_r_NDOkGXmM Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 09:10:13 -0000 Support. Kengo (2014/06/26 4:13), Thomas Narten wrote: > Hi. > > We ran a WGLC on the problem statement draft > (draft-ietf-sfc-problem-statement-07.txt) back in May. > Although the draft received significant review and support prior to > the formal LC, the actual last call resulted largely in silence. > > While it would be convenient to take silence as acceptance, that's not > good enough. To show the document is ready, we need WG members to > speak up and indicate they have read a recent version of the document > and think its ready to go. > > Note that the document was just reissued. Section 3 has been edited to > remove some of the text was deemed to be encroaching on > architecture. You can see the changes at > http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sfc-problem-statement-07-from-06.diff.html > > With that, we are restarting a 2-week WGLC on the document. We > specifically need to see sufficient indications from WG members that > the document is ready to advance, and that the document does not > contain significant deficiencies. > > Thomas > > _______________________________________________ > 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 Jul 7 02:22: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 2F1AA1B27EB for ; Mon, 7 Jul 2014 02:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 G9wc3yON3D0f for ; Mon, 7 Jul 2014 02:22:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72941A00FD for ; Mon, 7 Jul 2014 02:22:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR99957; Mon, 07 Jul 2014 09:22:51 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 10:22:50 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 17:22:45 +0800 From: Weixinpeng To: "Ken Gray (kegray)" , "sfc@ietf.org" Thread-Topic: [sfc] A new draft-wei-sfc-mobile-consideration-00. Thread-Index: AQHPmVytesF+qQXHNUCUaFj9V9Ni45uT2ACA Date: Mon, 7 Jul 2014 09:22:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81B1E7nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZvJsUonD7I0GMG9lOOs1wC-Ndtk Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-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: Mon, 07 Jul 2014 09:22:56 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81B1E7nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ken, Please see my answers inline. Thanks! BR, Xinpeng From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Monday, July 07, 2014 4:56 AM To: Weixinpeng; sfc@ietf.org Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hey, Wei. Thanks for the document. I would suggest that you normalize your terminolo= gy in 2.1 (LSFC and PSFC) with whatever Joel and Carlos are cooking (draft-= merged-sfc-architecture) - otherwise it looks like you're adding to archite= cture through a use case. That is, try and use their terms and not new one= s. [Wei] Ok, comparing the two documents, I think LSFC is equivalent to SFC an= d PSFC is equivalent to SFP. You take a shot at the interactions between LTE and SFC, and as someone els= e has already identified, maybe you need more detail? [Wei] Yes, I will provide more detailed discussion on this. When you dig into the mobile architecture, is there a specific requirement = you see of the chain itself, like the relaying of metadata, the need for fo= rking in some of the flow paths (e.g. Charging)? [Wei] Before the discussion of requirement for the chain, I think we shoul= d first have a clear view of how LTE network and SFC network could interact= with each other. Instead of mapping/wiring SFC into mobile (the GiLAN is an obvious use and = I encourage you to walk through a complete example), any thought to how the= LTE service chain might be re-envisioned in the presence of SFC (change in= roles, less reliance on DNS tricks, lower Diameter requirements)? [Wei] I think you mentioned a good point, but currently I have not seen any= impact, which you mentioned, on LTE service chain. Thanks for the document. From: Weixinpeng > Date: Tuesday, July 1, 2014 5:44 AM To: "sfc@ietf.org" > Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00. Hi all, A new draft on Interaction between SFC network and 3GPP network has been su= bmitted. Comments are welcomed! Best Regards, Xinpeng Name: draft-wei-sfc-mobile-consideration-00 Revision: 00 Title: Interaction between SFC network and 3GPP network Document date: 2014-06-30 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-co= nsideration-00.txt Status: https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consi= deration/ Htmlized: http://tools.ietf.org/html/draft-wei-sfc-mobile-considerati= on-00 Abstract: This document provides a discussion of how SFC (Service Function Chain) domain could interact with carrier network to provide network service for traffic. Here LTE (Long Term Evolution) network is used as an example of carrier network for discussion. --_000_C5C3BB522B1DDF478AA09545169155B46D81B1E7nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ken,=

Please = see my answers inline. Thanks!

&n= bsp;

BR,

Xinpeng=

&n= bsp;

From: Ken Gray (ke= gray) [mailto:kegray@cisco.com]
Sent: Monday, July 07, 2014 4:56 AM
To: Weixinpeng; sfc@ietf.org
Subject: Re: [sfc] A new draft-wei-sfc-mobile-consideration-00.=

 

Hey, Wei.=

&nbs= p;

Thanks fo= r the document.  I would suggest that you normalize your terminology i= n 2.1 (LSFC and PSFC) with whatever Joel and Carlos are cooking (draft-merg= ed-sfc-architecture) – otherwise it looks like you're adding to architecture through a use case.  That is, try and u= se their terms and not new ones.  

[= Wei] Ok, comparing the two documents, I think LSFC is equivalent to SFC and= PSFC is equivalent to SFP.

&nbs= p;

You take = a shot at the interactions between LTE and SFC, and as someone else has alr= eady identified, maybe you need more detail?

[= Wei] Yes, I will provide more detailed discussion on this.

&nbs= p;

When you = dig into the mobile architecture, is there a specific requirement you see o= f the chain itself, like the relaying of metadata, the need for forking in = some of the flow paths (e.g. Charging)?  =

[= Wei] Before the discussion of requirement for the chain,  I think we s= hould first have a clear view of how LTE network and SFC network could inte= ract with each other.

&nbs= p;

Instead o= f mapping/wiring SFC into mobile (the GiLAN is an obvious use and I encoura= ge you to walk through a complete example), any thought to how the LTE serv= ice chain might be re-envisioned in the presence of SFC (change in roles, less reliance on DNS tricks, lower Diame= ter requirements)?

[= Wei] I think you mentioned a good point, but currently I have not seen any = impact, which you mentioned, on LTE service chain.

&nbs= p;

Thanks fo= r the document.

&nbs= p;

From: Weix= inpeng <weixinpeng@huawei.com>
Date: Tuesday, July 1, 2014 5:44 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] A new draft-wei-sfc-mobile-consideration-00.

&nbs= p;

Hi all= ,

A new = draft on Interaction between SFC network and 3GPP network has been submitte= d. Comments are welcomed!

 =

Best R= egards,

Xinpen= g

 =

 =

Name:&= nbsp;           &nbs= p;  draft-wei-sfc-mobile-consideration-00

Revisi= on:  00

Title:=             &nb= sp;     Interaction between SFC network and 3GPP networ= k

Docume= nt date:       2014-06-30

Group:=             &nb= sp;  Individual Submission

Pages:=             &nb= sp;  7

URL:&n= bsp;           http://www.ietf.org/internet-drafts/draft-wei-sfc-mobile-consideration-00.t= xt

Status= :         https://datatracker.ietf.org/doc/draft-wei-sfc-mobile-consideration/

Htmliz= ed:       http://tools.ietf.org/html/draft-wei-sfc-mobile-consideration-00

 =

 =

Abstra= ct:

 =   This document provides a discussion of how SFC (Service Function

 =   Chain) domain could interact with carrier network to provide network=

 =   service for traffic. Here LTE (Long Term Evolution) network is used<= o:p>

 =   as an example of carrier network for discussion.

 

--_000_C5C3BB522B1DDF478AA09545169155B46D81B1E7nkgeml507mbxchi_-- From nobody Mon Jul 7 02:52: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 04DC51B2800 for ; Mon, 7 Jul 2014 02:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 F2ZdoZj8U2tO for ; Mon, 7 Jul 2014 02:52:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D201B27FE for ; Mon, 7 Jul 2014 02:52:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS03696; Mon, 07 Jul 2014 09:52:29 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 10:52:27 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 17:52:16 +0800 From: Weixinpeng To: "He, Peng" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-huang-sfc-use-case-recursive-service-00.txt Thread-Index: Ac+WO+YX3pQ+EW4nRd+JfoL3eT4aewAEMjMgAN4zywA= Date: Mon, 7 Jul 2014 09:52:15 +0000 Message-ID: References: <20140702211156.1466.90564.idtracker@ietfa.amsl.com> <53B4794A.10706@sce.carleton.ca> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D81B224nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/l1CqmBB_bAI4_APe9zrQmT666U0 Cc: Jiafeng Zhu , "huang@sce.carleton.ca" Subject: Re: [sfc] New Version Notification for draft-huang-sfc-use-case-recursive-service-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, 07 Jul 2014 09:52:36 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D81B224nkgeml507mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGVuZywNClRoYW5rcyBmb3IgdGhlIGRvY3VtZW50LCBhbmQgaGVyZSBhcmUgc29tZSBvZiBt eSBxdWVzdGlvbnM6DQooMSkgSW4gRmlnLiAyLCBpdCBpcyBzYWlkIOKAnOKApmRvdCBsaW5lcyBz aG93IG1hcHBpbmcgIHJlbGF0aW9uc2hpcOKApuKAnSwgc28gd2hhdOKAmXMgdGhlIG1lYW5pbmcg b2Yg4oCcbWFwcGluZ+KAnSBoZXJlPyAgRG9lcyBpdCBtZWFuIHRoZSB1cHBlciBsYXllciBTRnMg KGUuZy4gU0ZzIGluIELigJlzIFNGQykgIHdpbGwgdXNlIHRoZSBjb3JyZXNwb25kaW5nIFNGcyAg aW4gdGhlIGxvd2VyIGxheWVyIChlLmcuIEHigJlzIGxldmVsKT8NCigyKSBXaGF04oCZcyB0aGUg U0ZDc+KAmSByZWxhdGlvbiBvZiBBLCBCIGFuZCBDPyBFbWJlZGRlZCBvciBjb25jYXRlbmF0ZWQ/ DQoNCkJSLA0KWGlucGVuZw0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIZSwgUGVuZw0KU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQgNzoy OSBBTQ0KVG86IHNmY0BpZXRmLm9yZw0KQ2M6IEppYWZlbmcgWmh1OyBodWFuZ0BzY2UuY2FybGV0 b24uY2ENClN1YmplY3Q6IFtzZmNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS0wMC50eHQNCg0KSGkNCg0K V2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyBhbmQgYW5hbHlzaXMgdGhl IHJlY3Vyc2l2ZSAoZS5nLiwgbmVzdGVkKSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIHNjZW5h cmlvL3VzZSBjYXNlLCB0byBzZWUgaWYgdGhlIGN1cnJlbnQgZXhpc3RpbmcgdG9vbHMgcHJvcG9z ZWQgaW4gdGhlIFdHIGNhbiBjb3Zlci9zdXBwb3J0IHRoaXMgc2NlbmFyaW8sIG9yIHNvbWUgcG90 ZW50aWFsIGltcHJvdmVtZW50IG5lZWRlZC4gS2luZGx5IHJldmlldyB0aGUgSUQgYW5kIHByb3Zp ZGUgeW91ciBjb21tZW50cyBwbGVhc2UuIFRoYW5rcyBhIGxvdC4NCg0KDQpSZWdhcmRzLA0KUGVu Zw0KDQoNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0K DQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1y ZWN1cnNpdmUtc2VydmljZS0wMC50eHQNCg0KRGF0ZToNCg0KV2VkLCAwMiBKdWwgMjAxNCAxNDox MTo1NiAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNCkppYWZlbmcgWmh1IDxqaWFmZW5nLnpo dUBodWF3ZWkuY29tPjxtYWlsdG86amlhZmVuZy56aHVAaHVhd2VpLmNvbT4sIFBlbmcgSGUgPHBo ZUBjaWVuYS5jb20+PG1haWx0bzpwaGVAY2llbmEuY29tPiwgSmlhZmVuZyBaaHUgPGppYWZlbmcu emh1QGh1YXdlaS5jb20+PG1haWx0bzpqaWFmZW5nLnpodUBodWF3ZWkuY29tPiwgQ2hhbmdjaGVu ZyBIdWFuZyA8aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9u LmNhPiwgUGVuZyBIZSA8cGhlQGNpZW5hLmNvbT48bWFpbHRvOnBoZUBjaWVuYS5jb20+LCBDaGFu Z2NoZW5nIEh1YW5nIDxodWFuZ0BzY2UuY2FybGV0b24uY2E+PG1haWx0bzpodWFuZ0BzY2UuY2Fy bGV0b24uY2E+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVhbmctc2ZjLXVz ZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IENoYW5nY2hlbmcgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVURiBy ZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNl LXJlY3Vyc2l2ZS1zZXJ2aWNlDQoNClJldmlzaW9uOiAgICAgIDAwDQoNClRpdGxlOiAgICAgICAg IFNGQyBVc2UgQ2FzZXMgb24gUmVjdXJzaXZlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCg0K RG9jdW1lbnQgZGF0ZTogMjAxNC0wNy0wMQ0KDQpHcm91cDogICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAgICAgNw0KDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vy c2l2ZS1zZXJ2aWNlLTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNl Lw0KDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVh bmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNlLTAwDQoNCg0KDQoNCg0KQWJzdHJhY3Q6 DQoNCiAgIFNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgKFNGQykgcHJvdmlkZXMgdmFyaW91cyBz ZXJ2aWNlcyB0aGF0IGNhbg0KDQogICBiZSB0YWlsb3JlZCB0byBkaWZmZXJlbnQgcmVxdWlyZW1l bnRzIGZyb20gZGl2ZXJzaWZpZWQgdXNlciBncm91cHMsDQoNCiAgIHdoZXJlIGVhY2ggdXNlciBn cm91cCBmb3JtcyBhIGNvbGxlY3RpdmUgY2xpZW50IHRoYXQgcmVxdWlyZXMNCg0KICAgc2ltaWxh ciBzZXJ2aWNlLiBTRkMgaXMgdHlwaWNhbGx5IGRlcGxveWVkIGFzIGEgc2VydmljZSBvdmVybGF5 IHdpdGgNCg0KICAgaXRzIG93biBzZXJ2aWNlIHRvcG9sb2d5IG9uIHRvcCBvZiBleGlzdGluZyBu ZXR3b3JrIHRvcG9sb2d5LiBUaGlzDQoNCiAgIGtpbmQgb2YgdmlydHVhbGl6ZWQgc3RydWN0dXJl IG5hdHVyYWxseSBlbmFibGVzIHJlY3Vyc2l2ZSBzZXJ2aWNlDQoNCiAgIHJlbGF0aW9uc2hpcCB3 aGVyZSBhIGNsaWVudCBtYXkgYmVjb21lIGEgc2VydmljZSBwcm92aWRlciBhbmQgcmVzZWxsDQoN CiAgIFNGQyBzZXJ2aWNlcyB0byBpdHMgb3duIHVzZXIgZ3JvdXBzLiBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBzb21lDQoNCiAgIGV4ZW1wbGFyeSB1c2UgY2FzZXMgdGhhdCBzaG93IHRoZSB1c2Fn ZSBvZiByZWN1cnNpdmUgKGUuZy4gbmVzdGVkKQ0KDQogICBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu aW5nIHJlbGF0aW9uc2hpcC4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N Cg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg== --_000_C5C3BB522B1DDF478AA09545169155B46D81B224nkgeml507mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag vOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLkhU TUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9ybWF0dGVk DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUGVuZyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhl IGRvY3VtZW50LCBhbmQgaGVyZSBhcmUgc29tZSBvZiBteSBxdWVzdGlvbnM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oMSkgSW4gRmlnLiAyLCBpdCBpcyBzYWlk IOKAnOKApmRvdCBsaW5lcyBzaG93IG1hcHBpbmcgJm5ic3A7cmVsYXRpb25zaGlw4oCm4oCdLCBz byB3aGF04oCZcyB0aGUgbWVhbmluZyBvZiDigJxtYXBwaW5n4oCdIGhlcmU/ICZuYnNwO0RvZXMg aXQgbWVhbiB0aGUgdXBwZXIgbGF5ZXIgU0ZzDQogKGUuZy4gU0ZzIGluIELigJlzIFNGQykgJm5i c3A7d2lsbCB1c2UgdGhlIGNvcnJlc3BvbmRpbmcgU0ZzICZuYnNwO2luIHRoZSBsb3dlciBsYXll ciAoZS5nLiBB4oCZcyBsZXZlbCk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4oMikgV2hhdOKAmXMgdGhlIFNGQ3PigJkgcmVsYXRpb24gb2YgQSwgQiBhbmQgQz8g RW1iZWRkZWQgb3IgY29uY2F0ZW5hdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpbnBl bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+SGUsIFBlbmc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMDMs IDIwMTQgNzoyOSBBTTxicj4NCjxiPlRvOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i PiBKaWFmZW5nIFpodTsgaHVhbmdAc2NlLmNhcmxldG9uLmNhPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtzZmNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXNmYy11 c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+V2UgaGF2 ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gZGlzY3VzcyBhbmQgYW5hbHlzaXMgdGhlIHJlY3Vy c2l2ZSAoZS5nLiwgbmVzdGVkKSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIHNjZW5hcmlvL3Vz ZSBjYXNlLCB0byBzZWUgaWYgdGhlIGN1cnJlbnQgZXhpc3RpbmcgdG9vbHMgcHJvcG9zZWQgaW4g dGhlIFdHIGNhbiBjb3Zlci9zdXBwb3J0DQogdGhpcyBzY2VuYXJpbywgb3Igc29tZSBwb3RlbnRp YWwgaW1wcm92ZW1lbnQgbmVlZGVkLiBLaW5kbHkgcmV2aWV3IHRoZSBJRCBhbmQgcHJvdmlkZSB5 b3VyIGNvbW1lbnRzIHBsZWFzZS4gVGhhbmtzIGEgbG90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5QZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1h bGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1YmplY3Q6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNl LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5v d3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5EYXRlOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZWQsIDAyIEp1bCAyMDE0IDE0OjExOjU2IC0w NzAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFw PSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i cmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+VG86 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkppYWZlbmcgWmh1IDxhIGhyZWY9Im1haWx0bzpqaWFmZW5nLnpodUBodWF3ZWkuY29tIj4NCiZs dDtqaWFmZW5nLnpodUBodWF3ZWkuY29tJmd0OzwvYT4sIFBlbmcgSGUgPGEgaHJlZj0ibWFpbHRv OnBoZUBjaWVuYS5jb20iPiZsdDtwaGVAY2llbmEuY29tJmd0OzwvYT4sIEppYWZlbmcgWmh1DQo8 YSBocmVmPSJtYWlsdG86amlhZmVuZy56aHVAaHVhd2VpLmNvbSI+Jmx0O2ppYWZlbmcuemh1QGh1 YXdlaS5jb20mZ3Q7PC9hPiwgQ2hhbmdjaGVuZyBIdWFuZw0KPGEgaHJlZj0ibWFpbHRvOmh1YW5n QHNjZS5jYXJsZXRvbi5jYSI+Jmx0O2h1YW5nQHNjZS5jYXJsZXRvbi5jYSZndDs8L2E+LCBQZW5n IEhlIDxhIGhyZWY9Im1haWx0bzpwaGVAY2llbmEuY29tIj4NCiZsdDtwaGVAY2llbmEuY29tJmd0 OzwvYT4sIENoYW5nY2hlbmcgSHVhbmcgPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRv bi5jYSI+Jmx0O2h1YW5nQHNjZS5jYXJsZXRvbi5jYSZndDs8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2Ut MDAudHh0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5o YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENoYW5nY2hlbmcgSHVhbmcgYW5kIHBv c3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPklFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2ZS1zZXJ2aWNl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXZpc2lv bjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRkMgVXNlIENhc2VzIG9uIFJlY3Vyc2l2ZSBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5Eb2N1bWVudCBkYXRlOiAyMDE0LTA3LTAxPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5QYWdlczombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VVJMOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWFuZy1zZmMtdXNl LWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UtMDAu dHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1zZmMt dXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UvPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SHRtbGl6ZWQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS0w MCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJl Y3Vyc2l2ZS1zZXJ2aWNlLTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgKFNG QykgcHJvdmlkZXMgdmFyaW91cyBzZXJ2aWNlcyB0aGF0IGNhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGJlIHRhaWxvcmVkIHRv IGRpZmZlcmVudCByZXF1aXJlbWVudHMgZnJvbSBkaXZlcnNpZmllZCB1c2VyIGdyb3Vwcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyB3aGVyZSBlYWNoIHVzZXIgZ3JvdXAgZm9ybXMgYSBjb2xsZWN0aXZlIGNsaWVudCB0aGF0IHJl cXVpcmVzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgc2ltaWxhciBzZXJ2aWNlLiBTRkMgaXMgdHlwaWNhbGx5IGRlcGxveWVkIGFz IGEgc2VydmljZSBvdmVybGF5IHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBpdHMgb3duIHNlcnZpY2UgdG9wb2xvZ3kgb24g dG9wIG9mIGV4aXN0aW5nIG5ldHdvcmsgdG9wb2xvZ3kuIFRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBraW5kIG9mIHZpcnR1 YWxpemVkIHN0cnVjdHVyZSBuYXR1cmFsbHkgZW5hYmxlcyByZWN1cnNpdmUgc2VydmljZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 IHJlbGF0aW9uc2hpcCB3aGVyZSBhIGNsaWVudCBtYXkgYmVjb21lIGEgc2VydmljZSBwcm92aWRl ciBhbmQgcmVzZWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsgU0ZDIHNlcnZpY2VzIHRvIGl0cyBvd24gdXNlciBncm91cHMuIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBleGVtcGxhcnkgdXNlIGNhc2VzIHRoYXQg c2hvdyB0aGUgdXNhZ2Ugb2YgcmVjdXJzaXZlIChlLmcuIG5lc3RlZCk8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluaW5nIHJlbGF0aW9uc2hpcC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C5C3BB522B1DDF478AA09545169155B46D81B224nkgeml507mbxchi_-- From nobody Mon Jul 7 03:13: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 1F9291B2806 for ; Mon, 7 Jul 2014 03:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 tUDNiRTEUXQp for ; Mon, 7 Jul 2014 03:13:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9A01B2805 for ; Mon, 7 Jul 2014 03:13:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS05963; Mon, 07 Jul 2014 10:13:08 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 11:13:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 18:12:59 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: Comments on draft-quinn-sfc-nsh-03 Thread-Index: Ac+ZzAbBunw2/w5WSTauVCDXWCC+HA== Date: Mon, 7 Jul 2014 10:12:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290D73@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Wegri-jCLGvECAh0e9JnzQxXaZ0 Subject: [sfc] Comments on draft-quinn-sfc-nsh-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:13:11 -0000 Hi co-authors of this draft, I'm glad to see that the Service Path Header is decoupled from the Base Hea= der of the NSH while the MD Type field is introduced. With such MD Type fie= ld, it becomes possible that the Base Header could be followed by 1) a Serv= ice Path Header, 2) a context header or 3) both. Option 1 would be used bet= ween SFFs in the case where metadata is not required to be shared. Option 2= would be used between SFFs and SFs in the case where SFs don't care about = the service path information at all. Option 3 would be used between SFFs in= the case where metadata is required to be shared. If you agree with the ab= ove possible usages, it may be helpful to allocate two additional MT Type c= odes besides 0x1 so as to indicate the above three options. Best regards, Xiaohu From nobody Mon Jul 7 04:03: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 031581B2818 for ; Mon, 7 Jul 2014 04:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 3tBp_wJTlvCT for ; Mon, 7 Jul 2014 04:03:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7A51B2815 for ; Mon, 7 Jul 2014 04:03:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS11222; Mon, 07 Jul 2014 11:03:44 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 12:03:43 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 19:03:35 +0800 From: Jiangyuanlong To: "Carlos Pignataro (cpignata)" , ramki Krishnan Thread-Topic: Fault management in SFC Thread-Index: AQHPl2BZnihIAWDDGk+mZUqgkXcH35uP7M8w///eH4CABAbowA== Date: Mon, 7 Jul 2014 11:03:34 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BAED@szxema506-mbs.china.huawei.com> References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> <255EC6AA-C077-4169-9110-8462CF4655E0@cisco.com> In-Reply-To: <255EC6AA-C077-4169-9110-8462CF4655E0@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BAEDszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zd9_ZACbHQMnovGFSEXg3vIcP4s Cc: Sam Aldrin , "Nobo Akiya \(nobo\)" , "draft-krishnan-sfc-oam-req-framework@tools.ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 11:03:51 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BAEDszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for your comments. Reusing OAM protocols is also what we are after, = but that does not necessarily preclude an SFC encapsulation of OAM message. We discussed several types of OAM, for example, CC & CV, trace route, PM; i= t appears these are very basic requirements. Look forward to discussing more with you on this topic in Toronto. Thanks, Yuanlong From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Saturday, July 05, 2014 3:41 AM To: ramki Krishnan Cc: Jiangyuanlong; Sam Aldrin; sfc@ietf.org; Nobo Akiya (nobo); draft-krish= nan-sfc-oam-req-framework@tools.ietf.org Subject: Re: Fault management in SFC Hi, Ramki, Yuanlong, Thanks for bringing up these two documents! Here's my initial observations: draft-krishnan-sfc-oam-req-framework: * This document seems to be really thin in actual content. * Removing the introduction, acronyms, and boiler, there's a bit over a= page of very generic very high-level requirements. * Although the title says "SFC OAM Requirements and Framework", I do no= t see text supporting a framework. draft-jxc-sfc-fm-00: * I am concerned with the creation of a new OAM Protocol in Section 3. = SFC architectural documents have a goal of reusing OAM protocols, not re-in= venting. * It's not clear of the value of defining a TLV structure when there's = no Types. In other words, why draw TLV ASCII diagrams when the requirements= and gap analysis are not clear? * The document says things like "BFD can also be used as a tool of proa= ctive CC & CV in SFC.", but then goes on into drawing packets... I agree this can be a topic for discussions in Toronto. Thanks, Carlos. On Jul 4, 2014, at 9:48 AM, ramki Krishnan > wrote: Hi Sam, Yuanlong, All, We uploaded a document on the SFC OAM topic yesterday - this includes requ= irements besides framework. Given the importance of this topic, guess many = of us were working on this in parallel. We should probably get together in = Toronto to take the appropriate next steps. https://datatracker.ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jiangyuanlong Sent: Friday, July 04, 2014 1:17 AM To: Sam Aldrin; sfc@ietf.org Cc: Carlos Pignataro (cpignata); Nobo Akiya (nobo) Subject: [sfc] Fault management in SFC Hi Sam and all, I'm glad to see your draft on SFC OAM framework, it is a very basic and imp= ortant piece of work in my view. We have also uploaded an I-D discussing fault management in SFC, does anyon= e of you have an interest in this kind of work? The link to this I-D is: http://tools.ietf.org/html/draft-jxc-sfc-fm-00 Your opinions are greatly appreciated. Thanks, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 03, 2014 3:21 AM To: sfc@ietf.org Cc: Carlos Pignataro (cpignata); Nobo Akiya (nobo) Subject: [sfc] Fwd: New Version Notification for draft-aldrin-sfc-oam-frame= work-00.txt Hi, We have submitted a new draft for SFC OAM framework. Kindly review the ID and provide your comments. cheers -sam ---------- Forwarded message ---------- From: > Date: Wed, Jul 2, 2014 at 12:17 PM Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt To: Nobo Akiya >, "Sam K. Aldrin" >, Carlos Pignataro > A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt has been successfully submitted by Sam K. Aldrin and posted to the IETF repository. Name: draft-aldrin-sfc-oam-framework Revision: 00 Title: Service Function Chaining Operations, Administration and Ma= intenance Framework Document date: 2014-07-02 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-fr= amework-00.txt Status: https://datatracker.ietf.org/doc/draft-aldrin-sfc-oam-frame= work/ Htmlized: http://tools.ietf.org/html/draft-aldrin-sfc-oam-framework-0= 0 Abstract: This document provides reference framework for Operations, Administration and Maintenance (OAM) of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BAEDszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

Thanks for= your comments. Reusing OAM protocols is also what we are after, but that d= oes not necessarily preclude an SFC encapsulation of OAM message.

We discuss= ed several types of OAM, for example, CC & CV, trace route, PM; it appe= ars these are very basic requirements.

 = ;

Look forwa= rd to discussing more with you on this topic in Toronto.<= /p>

 = ;

Thanks,

Yuanlong



From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Saturday, July 05, 2014 3:41 AM
To: ramki Krishnan
Cc: Jiangyuanlong; Sam Aldrin; sfc@ietf.org; Nobo Akiya (nobo); draf= t-krishnan-sfc-oam-req-framework@tools.ietf.org
Subject: Re: Fault management in SFC

 

Hi, Ramki, Yuanlong, =

 

Thanks for bringing up these tw= o documents! Here's my initial observations:

 

draft-krishnan-sfc-oam-req-fram= ework:

  • This document seems to be really thin in actual conten= t.
  • Removing the introduction, acronyms, and boiler, there= 's a bit over a page of very generic very high-level requirements.
  • Although the title says "SFC OAM Requirements and= Framework", I do not see text supporting a framework.

 

draft-jxc-sfc-fm-00:=

  • I am concerned with the creation of a new OAM Protocol= in Section 3. SFC architectural documents have a goal of reusing OAM proto= cols, not re-inventing.
  • It's not clear of the value of defining a TLV structur= e when there's no Types. In other words, why draw TLV ASCII diagrams when t= he requirements and gap analysis are not clear?
  • The document says things like "BFD can also be us= ed as a tool of proactive CC & CV in SFC.", but then goes on into = drawing packets...

 

I agree this can be a topic for= discussions in Toronto.

 

Thanks,

 

Carlos.

 

On Jul 4, 2014, at 9:48 AM, ram= ki Krishnan <ramk@Brocade.com>= ; wrote:



Hi Sam, Yu= anlong, All,<= /o:p>

 

We uploade= d a document on the SFC OAM topic yesterday  – this includes req= uirements besides framework. Given the importance of this topic, guess many of us were working on this in parallel. We should probably get togeth= er in Toronto to take the appropriate next steps.

 

 

Thanks,

Ramki

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Jiangyuanlong
Sent: Friday, July= 04, 2014 1:17 AM
To: Sam Aldrin; sfc@ietf.org
Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fau= lt management in SFC

&n= bsp;

Hi Sam and all,

 =

I’= m glad to see your draft on SFC OAM framework, it is a very basic and import= ant piece of work in my view.

 =

We have also uploaded an= I-D discussing fault management in SFC, does anyone of you have an interes= t in this kind of work?

The link to this I-D is:=

 =

Your opinions are greatl= y appreciated.

 =

Thanks,

Yuanlong

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Sam Aldrin
Sent: Thursday, Ju= ly 03, 2014 3:21 AM
To: sfc@ietf.org
Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fwd= : New Version Notification for draft-aldrin-sfc-oam-framework-00.txt=

&n= bsp;

Hi= ,

&n= bsp;

We= have submitted a new draft for SFC OAM framework.

Ki= ndly review the ID and provide your comments.

&n= bsp;

ch= eers

-sam

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jul 2, 2014 at 12:17 PM
Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt=
To: Nobo Akiya <nobo@cisco.com>, "Sam K. Aldrin" <aldrin.ietf@= gmail.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt
has been successfully submitted by Sam K. Aldrin and posted to the
IETF repository.

Name:           draft-aldrin-sfc-oam-framework
Revision:       00
Title:          Service Function Chaining Operatio= ns, Administration and Maintenance Framework
Document date:  2014-07-02
Group:          Individual Submission
Pages:          11
URL:            = http://www.ietf.org/internet-drafts/draft-aldr= in-sfc-oam-framework-00.txt
Status:        &n= bsp;https://datatra= cker.ietf.org/doc/draft-aldrin-sfc-oam-framework/
Htmlized:       <= /span>http://tools.ietf.org/ht= ml/draft-aldrin-sfc-oam-framework-00


Abstract:
   This document provides reference framework for Operations,
   Administration and Maintenance (OAM) of Service Function Chain= ing
   (SFC).




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

The IETF Secretariat

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BAEDszxema506mbschi_-- From nobody Mon Jul 7 05:05: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 D23C21B2834 for ; Mon, 7 Jul 2014 05:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 Pgr6_u64gGY1 for ; Mon, 7 Jul 2014 05:05:43 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.119]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C779E1A03B6 for ; Mon, 7 Jul 2014 05:05:42 -0700 (PDT) Received: from [193.109.255.99:60031] by server-15.bemta-14.messagelabs.com id 00/55-11012-41D8AB35; Mon, 07 Jul 2014 12:05:40 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-10.tower-48.messagelabs.com!1404734740!7013836!1 X-Originating-IP: [195.232.224.76] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5176 invoked from network); 7 Jul 2014 12:05:40 -0000 Received: from mailout07.vodafone.com (HELO mailout07.vodafone.com) (195.232.224.76) by server-10.tower-48.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2014 12:05:40 -0000 Received: from mailint07.vodafone.com (localhost [127.0.0.1]) by mailout07.vodafone.com (Postfix) with ESMTP id 01D72223552 for ; Mon, 7 Jul 2014 14:05:24 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint07.vodafone.com (Postfix) with ESMTPS id E1E52222BED; Mon, 7 Jul 2014 14:05:20 +0200 (CEST) Received: from VOEXC28W.internal.vodafone.com (145.230.103.200) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 14:05:20 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.244]) by voexc28w ([145.230.103.200]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 14:05:19 +0200 From: "Haeffner, Walter, Vodafone DE" To: Kengo Naito , "sfc@ietf.org" Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmYOx2ljufgF0WTLebDGmm7OZuUQ1CAgABSnjA= Date: Mon, 7 Jul 2014 12:05:19 +0000 Message-ID: References: <53BA63A9.7040407@lab.ntt.co.jp> In-Reply-To: <53BA63A9.7040407@lab.ntt.co.jp> 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/D4SQtHU9zlyxBI8fM-JjFIcqN7U Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 12:05:45 -0000 Also support - Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Kengo Naito Gesendet: Montag, 7. Juli 2014 11:09 An: sfc@ietf.org Betreff: Re: [sfc] 2nd WG Last Call on Problem Statement Support. Kengo (2014/06/26 4:13), Thomas Narten wrote: > Hi. > > We ran a WGLC on the problem statement draft > (draft-ietf-sfc-problem-statement-07.txt) back in May. > Although the draft received significant review and support prior to=20 > the formal LC, the actual last call resulted largely in silence. > > While it would be convenient to take silence as acceptance, that's not=20 > good enough. To show the document is ready, we need WG members to=20 > speak up and indicate they have read a recent version of the document=20 > and think its ready to go. > > Note that the document was just reissued. Section 3 has been edited to=20 > remove some of the text was deemed to be encroaching on architecture.=20 > You can see the changes at=20 > http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ie > tf-sfc-problem-statement-07-from-06.diff.html > > With that, we are restarting a 2-week WGLC on the document. We=20 > specifically need to see sufficient indications from WG members that=20 > the document is ready to advance, and that the document does not=20 > contain significant deficiencies. > > Thomas > > _______________________________________________ > 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 From nobody Mon Jul 7 05:52: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 DED2B1A0403 for ; Mon, 7 Jul 2014 05:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VUxfuFnBmCnH for ; Mon, 7 Jul 2014 05:52:29 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446371A0400 for ; Mon, 7 Jul 2014 05:52:29 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 37D4853E13; Mon, 7 Jul 2014 05:51:32 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 7 Jul 2014 05:51:32.105 -0700 x-echoworx-msg-id: 506ea6ee-20a8-4185-a0b8-6e77d3490e9c x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 649; Mon, 7 Jul 2014 05:51:32 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 0311653E13; Mon, 7 Jul 2014 05:51:32 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 05:52:28 -0700 From: Ron Parker To: Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuA= Date: Mon, 7 Jul 2014 12:52:27 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D73306@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/k2GspxzsLsl5LUvEeuaiXuezt_4 Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 07 Jul 2014 12:52:32 -0000 Linda & Andy, Thanks for putting this together. I'm happy to see more work on the "chai= n-to-path" topic. I agree with all of your analysis regarding pros/cons o= f various approaches. Encapsulation and Control Plane will be dependent= on our architectural decisions in this area. The elusive thing for all o= f us, as a group, is to come to some conclusions! Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, July 04, 2014 4:49 PM To: 'sfc@ietf.org' Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instan= ces-restoration-00.txt Hi,=20 This draft describes the framework of protection and restoration of Service Chain Instance Path when some instances on the path fail or need to be replaced. Appreciate to hear your comments or suggestions.=20 Linda & Andy -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, April 30, 2014 11:25 AM To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restor= ation-00.txt A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt has been successfully submitted by Linda Dunbar and posted to the IETF repo= sitory. Name:=09=09draft-dunbar-sfc-fun-instances-restoration Revision:=0900 Title:=09=09Framework for Service Function Instances Restoration Document date:=092014-04-29 Group:=09=09Individual Submission Pages:=09=0912 URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-in= stances-restoration-00.txt Status: https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-insta= nces-restoration/ Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-r= estoration-00 Abstract: This draft describes the framework of protection and restoration of Service Chain Instance Path when some instances on the path fail or need to be replaced. = =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 Mon Jul 7 05:57: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 C0C921A0400; Mon, 7 Jul 2014 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 FtYoDfZc-mtC; Mon, 7 Jul 2014 05:57:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29CB1A0008; Mon, 7 Jul 2014 05:57:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS22592; Mon, 07 Jul 2014 12:57:34 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 13:57:15 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 20:57:05 +0800 From: Qin Wu To: "Carlos Pignataro (cpignata)" , ramki Krishnan , "time@ietf.org" , "daniel@olddog.co.uk" Thread-Topic: Fault management in SFC Thread-Index: AQHPl2IwdP+ejxTE2UyNesn6tN0/7ZuPaEiAgABio4CABMd+EA== Date: Mon, 7 Jul 2014 12:57:05 +0000 Message-ID: References: <20140702191729.12270.32098.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77ADC8@szxema506-mbs.china.huawei.com> <255EC6AA-C077-4169-9110-8462CF4655E0@cisco.com> In-Reply-To: <255EC6AA-C077-4169-9110-8462CF4655E0@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8457FDDEnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xkKQotJkxQxF30XQ-kOX82kFOfU Cc: Sam Aldrin , Jiangyuanlong , "Nobo Akiya \(nobo\)" , "sfc@ietf.org" , "draft-krishnan-sfc-oam-req-framework@tools.ietf.org" Subject: Re: [sfc] Fault management in SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 12:57:39 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8457FDDEnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGdlbmVyaWMgcmVxdWlyZW1lbnRzIGFzcGVjdCBvZiBkcmFmdC1rcmlzaG5hbi1zZmMtb2Ft LXJlcS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWtyaXNobmFuLXNmYy1v YW0tcmVxLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZz4gbWF5YmUgbW9yZSBmaXQgaW50bw0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2luZy1vcHNhd2ctdGltZS1tdWx0aS1sYXll ci1vYW0tdXNlLWNhc2UtMDEuDQpkcmFmdC1raW5nLW9wc2F3Zy10aW1lLW11bHRpLWxheWVyLW9h bS11c2UtY2FzZS0wMSBkaWQgc29ydCBvdXQgc29tZSBoaWdoIGxldmVsIHJlcXVpcmVtZW50cyBp biB0aGUgc2VjdGlvbiA0Lg0KQnV0IGhpZ2ggbGV2ZWwgcmVxdWlyZW1lbnRzIGluIGRyYWZ0LWtp bmctb3BzYXdnLXRpbWUtbXVsdGktbGF5ZXItb2FtLXVzZS1jYXNlLTAxIGFyZSBub3Qgc3BlY2lm aWMgdG8gU0ZDIE9BTS4NClRoZXkgYWxzbyBjYW4gYmUgYXBwbGljYWJsZSB0byBPdmVybGF5IE9B TSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjMgb2YgZHJhZnQta2luZy1vcHNhd2ctdGltZS1tdWx0 aS1sYXllci1vYW0tdXNlLWNhc2UuDQoNClJlZ2FyZGluZyBkcmFmdC1qeGMtc2ZjLWZtLTAwLCBp cyBpdCB0b28gcnVzaCB0byBnbyB0byBzb2x1dGlvbiBzY29wZSB0byBkaXNjdXNzIHdoYXQga2lu ZCBvZiBTRkMgc3BlY2lmaWMgT0FNIGZ1bmN0aW9uYWxpdGllcyBuZWVkIHRvIGJlIHN1cHBvcnQg YW5kDQpXaGF0IFNGQyBzcGVjaWZpYyBwYWNrZXQgZm9ybWF0IGxvb2tzIGxpa2U/DQoNClJlZ2Fy ZHMhDQotUWluDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjXI1SAzOjQx DQrK1bz+yMs6IHJhbWtpIEtyaXNobmFuDQqzrcvNOiBTYW0gQWxkcmluOyBKaWFuZ3l1YW5sb25n OyBOb2JvIEFraXlhIChub2JvKTsgc2ZjQGlldGYub3JnOyBkcmFmdC1rcmlzaG5hbi1zZmMtb2Ft LXJlcS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6IFJlOiBbc2ZjXSBGYXVsdCBtYW5h Z2VtZW50IGluIFNGQw0KDQpIaSwgUmFta2ksIFl1YW5sb25nLA0KDQpUaGFua3MgZm9yIGJyaW5n aW5nIHVwIHRoZXNlIHR3byBkb2N1bWVudHMhIEhlcmUncyBteSBpbml0aWFsIG9ic2VydmF0aW9u czoNCg0KZHJhZnQta3Jpc2huYW4tc2ZjLW9hbS1yZXEtZnJhbWV3b3JrOg0KDQogICogICBUaGlz IGRvY3VtZW50IHNlZW1zIHRvIGJlIHJlYWxseSB0aGluIGluIGFjdHVhbCBjb250ZW50Lg0KICAq ICAgUmVtb3ZpbmcgdGhlIGludHJvZHVjdGlvbiwgYWNyb255bXMsIGFuZCBib2lsZXIsIHRoZXJl J3MgYSBiaXQgb3ZlciBhIHBhZ2Ugb2YgdmVyeSBnZW5lcmljIHZlcnkgaGlnaC1sZXZlbCByZXF1 aXJlbWVudHMuDQogICogICBBbHRob3VnaCB0aGUgdGl0bGUgc2F5cyAiU0ZDIE9BTSBSZXF1aXJl bWVudHMgYW5kIEZyYW1ld29yayIsIEkgZG8gbm90IHNlZSB0ZXh0IHN1cHBvcnRpbmcgYSBmcmFt ZXdvcmsuDQoNCmRyYWZ0LWp4Yy1zZmMtZm0tMDA6DQoNCiAgKiAgIEkgYW0gY29uY2VybmVkIHdp dGggdGhlIGNyZWF0aW9uIG9mIGEgbmV3IE9BTSBQcm90b2NvbCBpbiBTZWN0aW9uIDMuIFNGQyBh cmNoaXRlY3R1cmFsIGRvY3VtZW50cyBoYXZlIGEgZ29hbCBvZiByZXVzaW5nIE9BTSBwcm90b2Nv bHMsIG5vdCByZS1pbnZlbnRpbmcuDQogICogICBJdCdzIG5vdCBjbGVhciBvZiB0aGUgdmFsdWUg b2YgZGVmaW5pbmcgYSBUTFYgc3RydWN0dXJlIHdoZW4gdGhlcmUncyBubyBUeXBlcy4gSW4gb3Ro ZXIgd29yZHMsIHdoeSBkcmF3IFRMViBBU0NJSSBkaWFncmFtcyB3aGVuIHRoZSByZXF1aXJlbWVu dHMgYW5kIGdhcCBhbmFseXNpcyBhcmUgbm90IGNsZWFyPw0KICAqICAgVGhlIGRvY3VtZW50IHNh eXMgdGhpbmdzIGxpa2UgIkJGRCBjYW4gYWxzbyBiZSB1c2VkIGFzIGEgdG9vbCBvZiBwcm9hY3Rp dmUgQ0MgJiBDViBpbiBTRkMuIiwgYnV0IHRoZW4gZ29lcyBvbiBpbnRvIGRyYXdpbmcgcGFja2V0 cy4uLg0KDQpJIGFncmVlIHRoaXMgY2FuIGJlIGEgdG9waWMgZm9yIGRpc2N1c3Npb25zIGluIFRv cm9udG8uDQoNClRoYW5rcywNCg0KQ2FybG9zLg0KDQpPbiBKdWwgNCwgMjAxNCwgYXQgOTo0OCBB TSwgcmFta2kgS3Jpc2huYW4gPHJhbWtAQnJvY2FkZS5jb208bWFpbHRvOnJhbWtAQnJvY2FkZS5j b20+PiB3cm90ZToNCg0KDQpIaSBTYW0sIFl1YW5sb25nLCBBbGwsDQoNCldlIHVwbG9hZGVkIGEg ZG9jdW1lbnQgb24gdGhlIFNGQyBPQU0gdG9waWMgeWVzdGVyZGF5ICCoQyB0aGlzIGluY2x1ZGVz IHJlcXVpcmVtZW50cyBiZXNpZGVzIGZyYW1ld29yay4gR2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2Yg dGhpcyB0b3BpYywgZ3Vlc3MgbWFueSBvZiB1cyB3ZXJlIHdvcmtpbmcgb24gdGhpcyBpbiBwYXJh bGxlbC4gV2Ugc2hvdWxkIHByb2JhYmx5IGdldCB0b2dldGhlciBpbiBUb3JvbnRvIHRvIHRha2Ug dGhlIGFwcHJvcHJpYXRlIG5leHQgc3RlcHMuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWtyaXNobmFuLXNmYy1vYW0tcmVxLWZyYW1ld29yay8NCg0KVGhhbmtzLA0K UmFta2kNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKaWFuZ3l1YW5sb25nDQpTZW50OiBGcmlkYXksIEp1bHkgMDQsIDIwMTQgMToxNyBBTQ0K VG86IFNhbSBBbGRyaW47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KQ2M6IENh cmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgTm9ibyBBa2l5YSAobm9ibykNClN1YmplY3Q6IFtz ZmNdIEZhdWx0IG1hbmFnZW1lbnQgaW4gU0ZDDQoNCkhpIFNhbSBhbmQgYWxsLA0KDQpJoa9tIGds YWQgdG8gc2VlIHlvdXIgZHJhZnQgb24gU0ZDIE9BTSBmcmFtZXdvcmssIGl0IGlzIGEgdmVyeSBi YXNpYyBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIHdvcmsgaW4gbXkgdmlldy4NCg0KV2UgaGF2ZSBh bHNvIHVwbG9hZGVkIGFuIEktRCBkaXNjdXNzaW5nIGZhdWx0IG1hbmFnZW1lbnQgaW4gU0ZDLCBk b2VzIGFueW9uZSBvZiB5b3UgaGF2ZSBhbiBpbnRlcmVzdCBpbiB0aGlzIGtpbmQgb2Ygd29yaz8N ClRoZSBsaW5rIHRvIHRoaXMgSS1EIGlzOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtanhjLXNmYy1mbS0wMA0KDQpZb3VyIG9waW5pb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVk Lg0KDQpUaGFua3MsDQpZdWFubG9uZw0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDAz LCAyMDE0IDM6MjEgQU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCkNj OiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk7IE5vYm8gQWtpeWEgKG5vYm8pDQpTdWJqZWN0 OiBbc2ZjXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWxkcmluLXNm Yy1vYW0tZnJhbWV3b3JrLTAwLnR4dA0KDQpIaSwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcg ZHJhZnQgZm9yIFNGQyBPQU0gZnJhbWV3b3JrLg0KS2luZGx5IHJldmlldyB0aGUgSUQgYW5kIHBy b3ZpZGUgeW91ciBjb21tZW50cy4NCg0KY2hlZXJzDQotc2FtDQotLS0tLS0tLS0tIEZvcndhcmRl ZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRlOiBXZWQsIEp1bCAyLCAyMDE0IGF0 IDEyOjE3IFBNDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFs ZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMC50eHQNClRvOiBOb2JvIEFraXlhIDxub2JvQGNpc2Nv LmNvbTxtYWlsdG86bm9ib0BjaXNjby5jb20+PiwgIlNhbSBLLiBBbGRyaW4iIDxhbGRyaW4uaWV0 ZkBnbWFpbC5jb208bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbT4+LCBDYXJsb3MgUGlnbmF0 YXJvIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+DQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWxkcmluLXNmYy1vYW0tZnJhbWV3b3JrLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTYW0gSy4gQWxkcmluIGFu ZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFm dC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdvcmsNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAg ICAgICAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRp b24gYW5kIE1haW50ZW5hbmNlIEZyYW1ld29yaw0KRG9jdW1lbnQgZGF0ZTogIDIwMTQtMDctMDIN Ckdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAx MQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWFsZHJpbi1zZmMtb2FtLWZyYW1ld29yay0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbGRyaW4tc2ZjLW9hbS1mcmFtZXdv cmsvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWxk cmluLXNmYy1vYW0tZnJhbWV3b3JrLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IHByb3ZpZGVzIHJlZmVyZW5jZSBmcmFtZXdvcmsgZm9yIE9wZXJhdGlvbnMsDQogICBBZG1pbmlz dHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UgKE9BTSkgb2YgU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu Zw0KICAgKFNGQykuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0 cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== --_000_B8F9A780D330094D99AF023C5877DABA8457FDDEnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The generi= c requirements aspect of draft-krishnan-sfc-oam-req-f= ramework@tools.ietf.org maybe more fit into

http://tools.ietf.o= rg/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.=

draft-king= -opsawg-time-multi-layer-oam-use-case-01 did sort out some high level requi= rements in the section 4.

But high l= evel requirements in draft-king-opsawg-time-multi-layer-oam-use-case-01 are= not specific to SFC OAM.

They also = can be applicable to Overlay OAM described in section 3.3 of draft-king-ops= awg-time-multi-layer-oam-use-case.

 = ;

Regarding = draft-jxc-sfc-fm-00, is it too rush to go to solution scope to discuss what= kind of SFC specific OAM functionalities need to be support and

What SFC s= pecific packet format looks like?

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: sfc [ma= ilto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Carlos Pignataro (cpignata)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C25=C8=D5 3:41
=CA=D5=BC=FE=C8=CB: ramki Krishnan
=B3=AD=CB=CD: Sam Aldrin; Jiangyuanlong; Nobo Akiya (nobo); sfc@ietf.org; draft-krishna= n-sfc-oam-req-framework@tools.ietf.org
=D6=F7=CC=E2: Re: [sfc] Fault management in SFC

 

Hi, Ramki, Yuanlong, =

 

Thanks for bringing up these tw= o documents! Here's my initial observations:

 

draft-krishnan-sfc-oam-req-fram= ework:

  • This document seems to be really thin in actual conten= t.
  • Removing the introduction, acronyms, and boiler, there= 's a bit over a page of very generic very high-level requirements.
  • Although the title says "SFC OAM Requirements and= Framework", I do not see text supporting a framework.

 

draft-jxc-sfc-fm-00:=

  • I am concerned with the creation of a new OAM Protocol= in Section 3. SFC architectural documents have a goal of reusing OAM proto= cols, not re-inventing.
  • It's not clear of the value of defining a TLV structur= e when there's no Types. In other words, why draw TLV ASCII diagrams when t= he requirements and gap analysis are not clear?
  • The document says things like "BFD can also be us= ed as a tool of proactive CC & CV in SFC.", but then goes on into = drawing packets...

 

I agree this can be a topic for= discussions in Toronto.

 

Thanks,

 

Carlos.

 

On Jul 4, 2014, at 9:48 AM, ram= ki Krishnan <ramk@Brocade.com>= ; wrote:



Hi Sam, Yu= anlong, All,=

 

We uploade= d a document on the SFC OAM topic yesterday  =A8C this includes requir= ements besides framework. Given the importance of this topic, guess many of us were working on this in parallel. We should probably get togeth= er in Toronto to take the appropriate next steps.

 

 

Thanks,

Ramki

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Jiangyuanlong
Sent: Friday, July= 04, 2014 1:17 AM
To: Sam Aldrin; sfc@ietf.org
Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fau= lt management in SFC

 

Hi Sam and all,

 =

I=A1=AF<= /span>m glad to see your draft on SFC OAM framework, it is a very basic and import= ant piece of work in my view.

 =

We have also uploaded an= I-D discussing fault management in SFC, does anyone of you have an interes= t in this kind of work?

The link to this I-D is:=

 =

Your opinions are greatl= y appreciated.

 =

Thanks,

Yuanlong

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Sam Aldrin
Sent: Thursday, Ju= ly 03, 2014 3:21 AM
To: sfc@ietf.org
Cc: Carlos Pignata= ro (cpignata); Nobo Akiya (nobo)
Subject: [sfc] Fwd= : New Version Notification for draft-aldrin-sfc-oam-framework-00.txt= <= /p>

 

Hi,

 

We have submitted a new draft for SFC OAM framework.=

Kindly review the ID and provide your comments.

 

cheers

-sam

---------- Forwarded message ----------<= br> From: <internet-drafts@ietf.org>
Date: Wed, Jul 2, 2014 at 12:17 PM
Subject: New Version Notification for draft-aldrin-sfc-oam-framework-00.txt=
To: Nobo Akiya <nobo@cisco.com>, "Sam K. Aldrin" <aldrin.ietf@= gmail.com>, Carlos Pignataro <cpignata@cisco.com>


A new version of I-D, draft-aldrin-sfc-oam-framework-00.txt
has been successfully submitted by Sam K. Aldrin and posted to the
IETF repository.

Name:           draft-aldrin-sfc-oam-framework
Revision:       00
Title:          Service Function Chaining Operatio= ns, Administration and Maintenance Framework
Document date:  2014-07-02
Group:          Individual Submission
Pages:          11
URL:            = http://www.ietf.org/internet-drafts/draft-aldr= in-sfc-oam-framework-00.txt
Status:        &n= bsp;https://datatra= cker.ietf.org/doc/draft-aldrin-sfc-oam-framework/
Htmlized:       <= /span>http://tools.ietf.org/ht= ml/draft-aldrin-sfc-oam-framework-00


Abstract:
   This document provides reference framework for Operations,
   Administration and Maintenance (OAM) of Service Function Chain= ing
   (SFC).




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

The IETF Secretariat

 

--_000_B8F9A780D330094D99AF023C5877DABA8457FDDEnkgeml501mbschi_-- From nobody Mon Jul 7 06:13: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 073781A0016 for ; Mon, 7 Jul 2014 06:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 wMgGCdm-31Be for ; Mon, 7 Jul 2014 06:13:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F343F1A000F for ; Mon, 7 Jul 2014 06:12:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW43527; Mon, 07 Jul 2014 13:12:58 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 14:12:57 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 21:12:46 +0800 From: Qin Wu To: Ron Parker , Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuCAAAWfIA== Date: Mon, 7 Jul 2014 13:12:45 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OChp7Rn3qK5ptSONhBcc8EMfHuI Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 07 Jul 2014 13:13:03 -0000 Um9uOg0KV2UgYWxzbyBoYXZlIGRyYWZ0IHRvIGRpc2N1c3MgaG93IHRvIGluc3RhbnRpYXRlIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCB1c2luZyBQQ0UtaW5pdGlhdGUgTFNQIGluc3RhbnRpYXRpb24u DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmlu Zy1zZmMtMDQNCkl0IHN1cHBvcnRzIGR5bmFtaWMgY3JlYXRpb24gYW5kIGRlbGV0aW9uIG9mIHNl cnZpY2UgZnVuY3Rpb24gcGF0aC4NCllvdXIgbWF5IGNoZWNrIG91dC4NCg0KUmVnYXJkcyENCi1R aW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBSb24gUGFya2VyDQq3osvNyrG85DogMjAxNMTqN9TCN8jVIDIwOjUyDQrK 1bz+yMs6IExpbmRhIER1bmJhcjsgJ3NmY0BpZXRmLm9yZycNCtb3zOI6IFJlOiBbc2ZjXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMC50eHQNCg0KTGluZGEgJiBBbmR5LA0KDQpUaGFua3MgZm9yIHB1dHRpbmcg dGhpcyB0b2dldGhlci4gICBJJ20gaGFwcHkgdG8gc2VlIG1vcmUgd29yayBvbiB0aGUgImNoYWlu LXRvLXBhdGgiIHRvcGljLiAgIEkgYWdyZWUgd2l0aCBhbGwgb2YgeW91ciBhbmFseXNpcyByZWdh cmRpbmcgcHJvcy9jb25zIG9mIHZhcmlvdXMgYXBwcm9hY2hlcy4gICAgIEVuY2Fwc3VsYXRpb24g YW5kIENvbnRyb2wgUGxhbmUgd2lsbCBiZSBkZXBlbmRlbnQgb24gb3VyIGFyY2hpdGVjdHVyYWwg ZGVjaXNpb25zIGluIHRoaXMgYXJlYS4gICBUaGUgZWx1c2l2ZSB0aGluZyBmb3IgYWxsIG9mIHVz LCBhcyBhIGdyb3VwLCBpcyB0byBjb21lIHRvIHNvbWUgY29uY2x1c2lvbnMhDQoNCiAgIFJvbg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1bmJhcg0KU2VudDogRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDQ6NDkgUE0NClRvOiAnc2ZjQGlldGYub3JnJw0KU3ViamVjdDogW3NmY10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5z dGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KDQpIaSwgDQoNClRoaXMgZHJhZnQgZGVzY3JpYmVz IHRoZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCiAgIFNlcnZp Y2UgQ2hhaW4gSW5zdGFuY2UgUGF0aCB3aGVuIHNvbWUgaW5zdGFuY2VzIG9uIHRoZSBwYXRoIGZh aWwgb3INCiAgIG5lZWQgdG8gYmUgcmVwbGFjZWQuDQoNCkFwcHJlY2lhdGUgdG8gaGVhciB5b3Vy IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zLiANCg0KTGluZGEgJiBBbmR5DQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAzMCwgMjAx NCAxMToyNSBBTQ0KVG86IEFuZHJldyBHLiBNYWxpczsgTGluZGEgRHVuYmFyOyBBbmRyZXcgRy4g TWFsaXM7IExpbmRhIER1bmJhcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0 b3JhdGlvbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluZGEg RHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbg0KUmV2aXNpb246CTAwDQpUaXRs ZToJCUZyYW1ld29yayBmb3IgU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMgUmVzdG9yYXRpb24N CkRvY3VtZW50IGRhdGU6CTIwMTQtMDQtMjkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTEyDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMt cmVzdG9yYXRpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRo ZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCiAgIFNlcnZpY2Ug Q2hhaW4gSW5zdGFuY2UgUGF0aCB3aGVuIHNvbWUgaW5zdGFuY2VzIG9uIHRoZSBwYXRoIGZhaWwg b3INCiAgIG5lZWQgdG8gYmUgcmVwbGFjZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz ZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon Jul 7 06:29: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 7DB071A000F for ; Mon, 7 Jul 2014 06:29:15 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iXvw02Enx72V for ; Mon, 7 Jul 2014 06:29:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319581A002A for ; Mon, 7 Jul 2014 06:29:13 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 950E3264134 for ; Mon, 7 Jul 2014 15:29:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 74E6223805E for ; Mon, 7 Jul 2014 15:29:11 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 15:29:11 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-boucadair-sfc-requirements-05.txt Thread-Index: AQHPlo0eTR8w7zO3akabfLLO+wBtZJuUoVPQ Date: Mon, 7 Jul 2014 13:29:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002E369@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20140703070446.19294.79075.idtracker@ietfa.amsl.com> In-Reply-To: <20140703070446.19294.79075.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] 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.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/K9-2YpvddqTWrG82riCHG929amo Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-requirements-05.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, 07 Jul 2014 13:29:15 -0000 Dear all, A new version of this draft is available online. The requirements are now o= rganized into groups: 3.1. Instantiating and Invoking Service Functions . . . . . . 3 3.2. Chaining Service Functions . . . . . . . . . . . . . . . 4 3.3. MTU Requirements . . . . . . . . . . . . . . . . . . . . 5 3.4. Independence from the Underlying Transport Infrastructure Requirements . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Traffic Classification Requirements . . . . . . . . . . . 6 3.6. Data Plane Requirements . . . . . . . . . . . . . . . . . 7 3.7. OAM Requirements . . . . . . . . . . . . . . . . . . . . 8 3.8. Recovery and Load Balancing Requirements . . . . . . . . 10 3.9. Compatibility with Legacy Service Functions Requirements 11 3.10. QoS Requirements . . . . . . . . . . . . . . . . . . . . 11 3.11. Security Requirements . . . . . . . . . . . . . . . . . . 11 Comments are more than welcome. 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: jeudi 3 juillet 2014 09:05 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-sfc-requirements-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Service Function Chaining (SFC) Authors : Mohamed Boucadair Christian Jacquenet Yuanlong Jiang Ron Parker Carlos Pignataro Kengo Naito Filename : draft-boucadair-sfc-requirements-05.txt Pages : 15 Date : 2014-07-03 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-sfc-requirements-05 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 nobody Mon Jul 7 06:46: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 C04371A006F for ; Mon, 7 Jul 2014 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 3dmEp4aCi0vb for ; Mon, 7 Jul 2014 06:46:49 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819A01A0063 for ; Mon, 7 Jul 2014 06:46:49 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 3A90853DF1; Mon, 7 Jul 2014 06:45:52 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 7 Jul 2014 06:45:52.174 -0700 x-echoworx-msg-id: 249e16b0-a388-4a27-9782-51b1c2d236d7 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 409; Mon, 7 Jul 2014 06:45:52 -0700 (PDT) Received: from HUB021-CA-7.exch021.domain.local (unknown [10.254.4.109]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 136FD53DF1; Mon, 7 Jul 2014 06:45:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 06:46:48 -0700 From: Ron Parker To: Qin Wu , Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuCAAAWfIIAACETA Date: Mon, 7 Jul 2014 13:46:48 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/C6t7ap0FQUHjTqZ9aTHraP0WSkc Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 07 Jul 2014 13:46:50 -0000 UWluLA0KDQpJIGFncmVlIHRoYXQgUlNWUC1URSBzdHlsZSBNUExTIGlzIGEgY2xvc2UgYXJjaGl0 ZWN0dXJhbCBtYXRjaCB0byB3aGF0IFNGQyBpcyB0cnlpbmcgdG8gYWNoaWV2ZSwgYW5kIHRoYXQg YW4gTVBMUyBsYWJlbCBzdGFjayBpbiB0aGlzIGNvbnRleHQgaXMgbGlrZWx5IHRoZSBtb3N0IGVm ZmljaWVudCB3YXkgdG8gZW5jb2RlIGV4cGxpY2l0IHNvdXJjZSByb3V0aW5nLCBwYWNrZXQtYnkt cGFja2V0LCB3aGlsZSBwcmVzZXJ2aW5nIGFsbCB0aGUgcmVzaWxpZW5jeSBjYXBhYmlsaXRpZXMg dGhhdCBhcmUgcmVxdWlyZWQgZm9yIHJlYWwtd29ybGQgU0ZDLiAgICANCg0KQnV0IG9uZSBjb25j ZXJuIEkgaGF2ZSBpcyB0aGUgdWJpcXVpdHksIG9yIGxhY2sgdGhlcmVvZiwgb2YgTVBMUyB3aGVy ZSBTRkMgd291bGQgYmUgdXNlZC4gICBJbiBtb2JpbGUgY2FycmllciBlbnZpcm9ubWVudHMsIHRo ZSBTRkMgaXMgc2VlbiBhcyBhcHBsaWNhYmxlIHRvIHRoZSAiR2ktTEFOIiBzZXQgb2YgdmFsdWUg YWRkZWQgc2VydmljZXMgdGhhdCBhcmUgZGVwbG95ZWQgYmV0d2VlbiB0aGUgc3Vic2NyaWJlciBt YW5hZ2VtZW50IHN5c3RlbSAoaS5lLiwgR0dTTi9QRE4tR1cpIGFuZCB0aGUgSW50ZXJuZXQuICAg IEluIHNvbWUgY2FzZXMsIHRoaXMgbWF5IGJlIE1QTFMgdW5kZXJwaW5uaW5nIHRoaXMgcGFydCBv ZiB0aGUgbmV0d29yaywgYnV0IGluIG90aGVycyBpdCBpcyBzaW1wbGUgRXRoZXJuZXQgb3IgU0RO IG92ZXJsYXkgb3ZlciBFdGhlcm5ldC4NCg0KUGxlYXNlIHNoYXJlIHlvdXIgdGhvdWdodHMgb24g dGhpcy4NCg0KVGhhbmtzLg0KDQogICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBR aW4gV3UNClNlbnQ6IE1vbmRheSwgSnVseSAwNywgMjAxNCA5OjEzIEFNDQpUbzogUm9uIFBhcmtl cjsgTGluZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0KU3ViamVjdDogUmU6IFtzZmNdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJl c3RvcmF0aW9uLTAwLnR4dA0KDQpSb246DQpXZSBhbHNvIGhhdmUgZHJhZnQgdG8gZGlzY3VzcyBo b3cgdG8gaW5zdGFudGlhdGUgc2VydmljZSBmdW5jdGlvbiBwYXRoIHVzaW5nIFBDRS1pbml0aWF0 ZSBMU1AgaW5zdGFudGlhdGlvbi4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1 LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0wNA0KSXQgc3VwcG9ydHMgZHluYW1pYyBjcmVhdGlv biBhbmQgZGVsZXRpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRoLg0KWW91ciBtYXkgY2hlY2sg b3V0Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCreiy83KsbzkOiAy MDE0xOo31MI3yNUgMjA6NTINCsrVvP7IyzogTGluZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0K 1vfM4jogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFy LXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KDQpMaW5kYSAmIEFuZHksDQoN ClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyLiAgIEknbSBoYXBweSB0byBzZWUgbW9y ZSB3b3JrIG9uIHRoZSAiY2hhaW4tdG8tcGF0aCIgdG9waWMuICAgSSBhZ3JlZSB3aXRoIGFsbCBv ZiB5b3VyIGFuYWx5c2lzIHJlZ2FyZGluZyBwcm9zL2NvbnMgb2YgdmFyaW91cyBhcHByb2FjaGVz LiAgICAgRW5jYXBzdWxhdGlvbiBhbmQgQ29udHJvbCBQbGFuZSB3aWxsIGJlIGRlcGVuZGVudCBv biBvdXIgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgaW4gdGhpcyBhcmVhLiAgIFRoZSBlbHVzaXZl IHRoaW5nIGZvciBhbGwgb2YgdXMsIGFzIGEgZ3JvdXAsIGlzIHRvIGNvbWUgdG8gc29tZSBjb25j bHVzaW9ucyENCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGluZGEgRHVu YmFyDQpTZW50OiBGcmlkYXksIEp1bHkgMDQsIDIwMTQgNDo0OSBQTQ0KVG86ICdzZmNAaWV0Zi5v cmcnDQpTdWJqZWN0OiBbc2ZjXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQoNCkhpLCANCg0K VGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIGZyYW1ld29yayBvZiBwcm90ZWN0aW9uIGFuZCByZXN0 b3JhdGlvbiBvZg0KICAgU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0 YW5jZXMgb24gdGhlIHBhdGggZmFpbCBvcg0KICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCg0KQXBw cmVjaWF0ZSB0byBoZWFyIHlvdXIgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMuIA0KDQpMaW5kYSAm IEFuZHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDMwLCAyMDE0IDExOjI1IEFNDQpUbzogQW5kcmV3IEcuIE1hbGlzOyBMaW5k YSBEdW5iYXI7IEFuZHJldyBHLiBNYWxpczsgTGluZGEgRHVuYmFyDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0 b3JhdGlvbi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZHVuYmFyLXNm Yy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBMaW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9u DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJRnJhbWV3b3JrIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIElu c3RhbmNlcyBSZXN0b3JhdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNC0yOQ0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5j ZXMtcmVzdG9yYXRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9u Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJh ci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkcmFmdCBkZXNjcmliZXMgdGhlIGZyYW1ld29yayBvZiBwcm90ZWN0aW9uIGFuZCByZXN0b3Jh dGlvbiBvZg0KICAgU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5j ZXMgb24gdGhlIHBhdGggZmFpbCBvcg0KICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo= From nobody Mon Jul 7 08:16: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 81EE11A0162 for ; Mon, 7 Jul 2014 08:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 NZz2ufB5o_oI for ; Mon, 7 Jul 2014 08:16:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C07E1A0166 for ; Mon, 7 Jul 2014 08:16:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS34857; Mon, 07 Jul 2014 15:16:05 +0000 (GMT) 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; Mon, 7 Jul 2014 16:16:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 08:15:43 -0700 From: Lucy yong To: Xuxiaohu , "sfc@ietf.org" Thread-Topic: Comments on draft-quinn-sfc-nsh-03 Thread-Index: Ac+ZzAbBunw2/w5WSTauVCDXWCC+HAAKZtmw Date: Mon, 7 Jul 2014 15:15:42 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BD05A@dfweml701-chm.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290D73@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290D73@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/G_51PgFaA3JHJSeFG_QGtl1DZ4Y Subject: Re: [sfc] Comments on draft-quinn-sfc-nsh-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:16:10 -0000 IMO: this is good suggestion. We should allow the solution that the SFP is = configured by the control plane ahead so no SFP info is in SFC encapsulatio= n. We should also allow the solution that no metadata is conveyed along SFC= path. Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Monday, July 07, 2014 5:13 AM To: sfc@ietf.org Subject: [sfc] Comments on draft-quinn-sfc-nsh-03 Hi co-authors of this draft, I'm glad to see that the Service Path Header is decoupled from the Base Hea= der of the NSH while the MD Type field is introduced. With such MD Type fie= ld, it becomes possible that the Base Header could be followed by 1) a Serv= ice Path Header, 2) a context header or 3) both. Option 1 would be used bet= ween SFFs in the case where metadata is not required to be shared. Option 2= would be used between SFFs and SFs in the case where SFs don't care about = the service path information at all. Option 3 would be used between SFFs in= the case where metadata is required to be shared. If you agree with the ab= ove possible usages, it may be helpful to allocate two additional MD Type c= odes besides 0x1 so as to indicate the above three options. Best regards, Xiaohu _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 7 13:09: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 70BCF1A0515 for ; Mon, 7 Jul 2014 13:09:01 -0700 (PDT) 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 mcVyUYNn3ekH for ; Mon, 7 Jul 2014 13:08:51 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93A81B28A0 for ; Mon, 7 Jul 2014 13:08:51 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s67K1Bxm031701; Mon, 7 Jul 2014 13:08:51 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1mw6npsgvt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 07 Jul 2014 13:08:51 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 13:08:50 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Mon, 7 Jul 2014 13:08:50 -0700 From: ramki Krishnan To: "sfc@ietf.org" Date: Mon, 7 Jul 2014 13:08:50 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybA== 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_C7634EB63EFD984A978DFB46EA5174F2C14FDB8586HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_03:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070227 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TcW3I-L6TwgVtzNd1WgrawUgM-g Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 20:09:02 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8586HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8586HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Overview of proposed IRTF Network Functions Virtualiz= ation Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emerging = area for network operators, hardware and software vendors, cloud service pr= oviders, and in general network practitioners and researchers. This area re= quires exploring new directions and working collaboratively on how to creat= e network services that utilize a virtualized infrastructure. Network funct= ions that are traditionally implemented in dedicated hardware appliances wi= ll need to be decomposed and executed in virtual machines running in data c= enters. One key goal of this new area is to reduce capital and operating ex= penditures for future deployments for networks and associated services. Ano= ther important goal is for the network operators to be able to offer value = added cloud services to their customers. Finally, new business models will = open for the provision of network services.

The technologies enabling the virt= ualization of network functions are currently in an early stage of, and the= y need researchers to develop new architectures, systems, and software, and= to explore tradeoffs and possibilities for leveraging virtualized infrastr= ucture to provide support for network functions. The Network Functions Virt= ualization Research Group (NFVRG) will bring together researchers and grow = the community around the world in both academia and industry to explore thi= s new research area through workshops, research group meetings etc. at prem= ier conferences such as IEEE ICC, IEEE Globecom and inviting special issues= in well-known journals. Some of the key topics of research include virtual= ization of fixed and mobile network infrastructures, new network architectu= res based on virtualized network functions, virtualization of the home and = enterprise network environments, co-existence with non-virtualized infrastr= ucture and services, and application to growing areas of concern such as In= ternet of Things (IoT) and next generation content distribution.=

The NFVRG wil= l focus on research problems associated with these topics and on bringing a= research community together that can jointly address such problems, concen= trating on problems that relate not just to networking but also to computin= g and storage constraints in such environments. It is also hoped that the o= utcome of the research will benefit standardization efforts that can get sp= awned via IRTF & IETF BoF meetings and/or provide useful input to other= related standards efforts in ETSI or other standards bodies.

More details can= be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<= /p>

First face-to-face Meeting in Toronto

 

The first face-to-face mee= ting of the proposed NFVRG will be held along with the IETF meeting in Toro= nto on July 30th Wednesday from 11:30am to 1:00pm in the Canadian (C) Room = (immediately after the SFC meeting). Please let us know if you have researc= h topics to present during the meeting. Would really appreciate active disc= ussions in the mailing list nfvrg@irtf.org.

Thanks,

Ramki on behalf of the NFVRG co-chairs

= = --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8586HQ1EXCH01corp_-- From nobody Mon Jul 7 13:28: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 BFC171B28BA for ; Mon, 7 Jul 2014 13:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 cFSYsQBL0FBh for ; Mon, 7 Jul 2014 13:28:47 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6FF1B28AB for ; Mon, 7 Jul 2014 13:28:47 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h15so65855igd.3 for ; Mon, 07 Jul 2014 13:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8wH1CaMS37nuW+9rFMsTwRrHp6VBBtWZraJOcd3eVPc=; b=FpDBin3WI8jerb1Nrdgtp19oAUznxCEDvPBQBula/lMV/HtXikzw0rKgILrfwQ7AZP sdolYspFDGpatR2G/IJF4I3IbVfsqNkGdudpyTgIpGStalipYBAttD3sNwwkIR+N8ErN PZL3T2kaitMKIC6+fW5nbBhrsahRZdoE0Lk0TB0fcUfEt+la9bQe3MkeRJMBrtjM4REi zgeZeSLH1SotgMj4xKirUw3sjYGxvtUg+3DVRi4IzR7gd40LOCHr8HN1va7lY8IhqAHE zsBd2UePzlpF6sFoN0Vnufze2rXFwca/yM68LL3DYN4ZCUkl2of6yZiPXAT/+SvjDBD6 pfuw== MIME-Version: 1.0 X-Received: by 10.50.136.135 with SMTP id qa7mr56964278igb.21.1404764926828; Mon, 07 Jul 2014 13:28:46 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Mon, 7 Jul 2014 13:28:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 22:28:46 +0200 X-Google-Sender-Auth: OJg9yly2T4u9rgy9c_pUFq3-x2E Message-ID: From: Robert Raszuk To: ramki Krishnan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YmeKySPzkcurO8_siBEJYoiNzLQ Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "sfc@ietf.org" , "dilikris@in.ibm.com" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 20:28:49 -0000 Hi Ramki, > Another important goal is for the network operators to be able to > offer value added cloud services to their customers. The above goal of NFVRG seems like identical goal of IETF SFC WG. Per your write-up I think there may be significant overlap between the two groups. That is not to say that NFVRG could not be build and chartered to be unique with zero overlap, but that is not what your overview says. I think it may be useful to clarify this before the face to face meeting. Thx, R. On Mon, Jul 7, 2014 at 10:08 PM, ramki Krishnan wrote: > Overview of proposed IRTF Network Functions Virtualization Research Group > (NFVRG) > > > > Network Function Virtualization (NFV) is a key emerging area for network > operators, hardware and software vendors, cloud service providers, and in > general network practitioners and researchers. This area requires exploring > new directions and working collaboratively on how to create network services > that utilize a virtualized infrastructure. Network functions that are > traditionally implemented in dedicated hardware appliances will need to be > decomposed and executed in virtual machines running in data centers. One key > goal of this new area is to reduce capital and operating expenditures for > future deployments for networks and associated services. Another important > goal is for the network operators to be able to offer value added cloud > services to their customers. Finally, new business models will open for the > provision of network services. > > The technologies enabling the virtualization of network functions are > currently in an early stage of, and they need researchers to develop new > architectures, systems, and software, and to explore tradeoffs and > possibilities for leveraging virtualized infrastructure to provide support > for network functions. The Network Functions Virtualization Research Group > (NFVRG) will bring together researchers and grow the community around the > world in both academia and industry to explore this new research area > through workshops, research group meetings etc. at premier conferences such > as IEEE ICC, IEEE Globecom and inviting special issues in well-known > journals. Some of the key topics of research include virtualization of fixed > and mobile network infrastructures, new network architectures based on > virtualized network functions, virtualization of the home and enterprise > network environments, co-existence with non-virtualized infrastructure and > services, and application to growing areas of concern such as Internet of > Things (IoT) and next generation content distribution. > > The NFVRG will focus on research problems associated with these topics and > on bringing a research community together that can jointly address such > problems, concentrating on problems that relate not just to networking but > also to computing and storage constraints in such environments. It is also > hoped that the outcome of the research will benefit standardization efforts > that can get spawned via IRTF & IETF BoF meetings and/or provide useful > input to other related standards efforts in ETSI or other standards bodies. > > More details can be found at - > http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg > > First face-to-face Meeting in Toronto > > > > The first face-to-face meeting of the proposed NFVRG will be held along with > the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in > the Canadian (C) Room (immediately after the SFC meeting). Please let us > know if you have research topics to present during the meeting. Would really > appreciate active discussions in the mailing list nfvrg@irtf.org. > > Thanks, > > Ramki on behalf of the NFVRG co-chairs > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 7 14:28: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 D30AB1B2935 for ; Mon, 7 Jul 2014 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 6kkoTNbMsk5w for ; Mon, 7 Jul 2014 14:28:14 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71CFD1B28E1 for ; Mon, 7 Jul 2014 14:28:14 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s67LS83H012330 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 7 Jul 2014 17:28:09 -0400 Message-ID: <53BB1223.7020802@sce.carleton.ca> Date: Mon, 07 Jul 2014 14:33:23 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Weixinpeng References: <20140702211156.1466.90564.idtracker@ietfa.amsl.com> <53B4794A.10706@sce.carleton.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000505030208060809070603" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Xh1kIw3AVQxVJDM-eil43kKIOMI Cc: sfc@ietf.org Subject: Re: [sfc] New Version Notification for draft-huang-sfc-use-case-recursive-service-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:28:18 -0000 This is a multi-part message in MIME format. --------------000505030208060809070603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Xinpeng, Thank you for your interest. Yes, mapping means upper level SFs will use the corresponding lower level SFs. When a packet arrives at a lower level SF node, the node applies certain functions as defined by the lower level node first. After that, how the upper level functions are applied to the packet depends on how the upper level functions are implemented. In the draft, we defined two modes: transparent vs. opaque. In the transparent mode, the upper level decides what upper level functions are needed and asked the lower level node to implement and apply those functions after the lower level functions are finished. In the opaque mode, in addition to deciding what upper level functions are required, the upper level also implements the upper level service functions using its own software. After the lower level node finishes its own service functions, the packet will be passed to upper level service function module and processed there. The packet will then be forwarded to the next SF node at lower level. You can find more details about the two modes in the draft. I am not quite sure what you mean by "embedded" and "concatenated". My interpretation is that "embedded" seems to correspond to our transparent mode while "concatenated" seems to mean opaque mode. Best regards, Chang On 07/07/2014 02:52 AM, Weixinpeng wrote: > > Hi Peng, > > Thanks for the document, and here are some of my questions: > > (1) In Fig. 2, it is said "...dot lines show mapping > relationship...", so what's the meaning of "mapping" here? Does it > mean the upper layer SFs (e.g. SFs in B's SFC) will use the > corresponding SFs in the lower layer (e.g. A's level)? > > (2) What's the SFCs' relation of A, B and C? Embedded or concatenated? > > BR, > > Xinpeng > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *He, Peng > *Sent:* Thursday, July 03, 2014 7:29 AM > *To:* sfc@ietf.org > *Cc:* Jiafeng Zhu; huang@sce.carleton.ca > *Subject:* [sfc] FW: New Version Notification for > draft-huang-sfc-use-case-recursive-service-00.txt > > Hi > > We have submitted a new draft to discuss and analysis the recursive > (e.g., nested) service function chaining scenario/use case, to see if > the current existing tools proposed in the WG can cover/support this > scenario, or some potential improvement needed. Kindly review the ID > and provide your comments please. Thanks a lot. > > Regards, > > Peng > > > > -------- Original Message -------- > > *Subject: * > > > > New Version Notification for > draft-huang-sfc-use-case-recursive-service-00.txt > > *Date: * > > > > Wed, 02 Jul 2014 14:11:56 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Jiafeng Zhu , > Peng He , Jiafeng Zhu > , Changcheng > Huang , Peng He > , Changcheng Huang > > > A new version of I-D, draft-huang-sfc-use-case-recursive-service-00.txt > has been successfully submitted by Changcheng Huang and posted to the > IETF repository. > > Name: draft-huang-sfc-use-case-recursive-service > Revision: 00 > Title: SFC Use Cases on Recursive Service Function Chaining > Document date: 2014-07-01 > Group: Individual Submission > Pages: 7 > URL:http://www.ietf.org/internet-drafts/draft-huang-sfc-use-case-recursive-service-00.txt > Status:https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ > Htmlized:http://tools.ietf.org/html/draft-huang-sfc-use-case-recursive-service-00 > > > Abstract: > Service function chaining (SFC) provides various services that can > be tailored to different requirements from diversified user groups, > where each user group forms a collective client that requires > similar service. SFC is typically deployed as a service overlay with > its own service topology on top of existing network topology. This > kind of virtualized structure naturally enables recursive service > relationship where a client may become a service provider and resell > SFC services to its own user groups. This document describes some > exemplary use cases that show the usage of recursive (e.g. nested) > service function chaining relationship. > > > > > 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 --------------000505030208060809070603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Xinpeng,

Thank you for your interest. Yes, mapping means upper level SFs will use the corresponding lower level SFs. When a packet arrives at a lower level SF node, the node applies certain functions as defined by the lower level node first. After that, how the upper level functions are applied to the packet depends on how the upper level functions are implemented. In the draft, we defined two modes: transparent vs. opaque.

In the transparent mode, the upper level decides what upper level functions are needed and asked the lower level node to implement and apply those functions after the lower level functions are finished.

In the opaque mode, in addition to deciding what upper level functions are required, the upper level also implements the upper level service functions using its own software. After the lower level node finishes its own service functions, the packet will be passed to upper level service function module and processed there. The packet will then be forwarded to the next SF node at lower level.

You can find more details about the two modes in the draft.

I am not quite sure what you mean by "embedded" and "concatenated". My interpretation is that "embedded" seems to correspond to our transparent mode while "concatenated" seems to mean opaque mode.

Best regards,

Chang
  
On 07/07/2014 02:52 AM, Weixinpeng wrote:

Hi Peng,

Thanks for the document, and here are some of my questions:

(1) In Fig. 2, it is said “…dot lines show mapping  relationship…”, so what’s the meaning of “mapping” here?  Does it mean the upper layer SFs (e.g. SFs in B’s SFC)  will use the corresponding SFs  in the lower layer (e.g. A’s level)?

(2) What’s the SFCs’ relation of A, B and C? Embedded or concatenated?

 

BR,

Xinpeng

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of He, Peng
Sent: Thursday, July 03, 2014 7:29 AM
To: sfc@ietf.org
Cc: Jiafeng Zhu; huang@sce.carleton.ca
Subject: [sfc] FW: New Version Notification for draft-huang-sfc-use-case-recursive-service-00.txt

 

Hi

 

We have submitted a new draft to discuss and analysis the recursive (e.g., nested) service function chaining scenario/use case, to see if the current existing tools proposed in the WG can cover/support this scenario, or some potential improvement needed. Kindly review the ID and provide your comments please. Thanks a lot.

 

 

Regards,

Peng

 

 



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

Subject:

New Version Notification for draft-huang-sfc-use-case-recursive-service-00.txt

Date:

Wed, 02 Jul 2014 14:11:56 -0700

From:

internet-drafts@ietf.org

To:

Jiafeng Zhu <jiafeng.zhu@huawei.com>, Peng He <phe@ciena.com>, Jiafeng Zhu <jiafeng.zhu@huawei.com>, Changcheng Huang <huang@sce.carleton.ca>, Peng He <phe@ciena.com>, Changcheng Huang <huang@sce.carleton.ca>

 

A new version of I-D, draft-huang-sfc-use-case-recursive-service-00.txt
has been successfully submitted by Changcheng Huang and posted to the
IETF repository.
 
Name:          draft-huang-sfc-use-case-recursive-service
Revision:      00
Title:         SFC Use Cases on Recursive Service Function Chaining
Document date: 2014-07-01
Group:         Individual Submission
Pages:         7
URL:            http://www.ietf.org/internet-drafts/draft-huang-sfc-use-case-recursive-service-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/
Htmlized:       http://tools.ietf.org/html/draft-huang-sfc-use-case-recursive-service-00
 
 
Abstract:
   Service function chaining (SFC) provides various services that can
   be tailored to different requirements from diversified user groups,
   where each user group forms a collective client that requires
   similar service. SFC is typically deployed as a service overlay with
   its own service topology on top of existing network topology. This
   kind of virtualized structure naturally enables recursive service
   relationship where a client may become a service provider and resell
   SFC services to its own user groups. This document describes some
   exemplary use cases that show the usage of recursive (e.g. nested)
   service function chaining relationship.
 
                                                                                  
 
 
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

--------------000505030208060809070603-- From nobody Mon Jul 7 15:35: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 747571A0AAD for ; Mon, 7 Jul 2014 15:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 amJzvVElxP82 for ; Mon, 7 Jul 2014 15:35:22 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D3F1B297B for ; Mon, 7 Jul 2014 15:35:14 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D192860160; Tue, 8 Jul 2014 00:35:11 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id B72F76015A; Tue, 8 Jul 2014 00:35:11 +0200 (CEST) Received: from ESTGVMSP221.EUROPE.telefonica.corp ([fe80::79b8:304b:ea62:691d]) by ESTGVMSP108.EUROPE.telefonica.corp ([fe80::49d3:7c99:c221:b2a5%11]) with mapi id 14.03.0146.002; Tue, 8 Jul 2014 00:35:11 +0200 From: DIEGO LOPEZ GARCIA To: Robert Raszuk Thread-Topic: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybP//5OUAgAAjT4A= Date: Mon, 7 Jul 2014 22:35:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.92.4.9] Content-Type: multipart/alternative; boundary="_000_B2BF2321C70448A59D47CB902882A232telefonicacom_" MIME-Version: 1.0 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xKHfUez_KE1xyoRiK-H1VXjmR3s Cc: ramki Krishnan , "dilikris@in.ibm.com" , "sfc@ietf.org" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jul 2014 22:35:32 -0000 --_000_B2BF2321C70448A59D47CB902882A232telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGFtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIHRlcm0gImNs b3VkIHNlcnZpY2VzIiBoYXMgYSB0b28gd2lkZSBtZWFuaW5nLiBXaGlsZSBpbiBTRkMgSSB1bmRl cnN0YW5kIHdlIGFyZSB0YWxraW5nIG9uIHNlcnZpY2VzIGxvY2F0ZWQgaW4gZGF0YWNlbnRlcnMs IGluIHRoZSBORlYgY29udGV4dCB3ZSBhcmUgdGFsa2luZyBhYm91dCBuZXR3b3JrIGZ1bmN0aW9u cyB0aGF0IGhhdmUgYmVlbiB2aXJ0dWFsaXplZCBpbnRvIGEgY2xvdWQtbGlrZSBpbmZyYXN0cnVj dHVyZS4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgdGVybSBoYXMgdG8gYmUgY2xhcmlmaWVk LCB0aG91Z2ggSSB0aGluayBpdCBpcyBjbGVhciBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciBhdmFp bGFibGUgaW4gdGhlIFdpa2kuDQoNCkFueXdheSwgU0ZDIGhhcyB0aGUgcHJvdmlzaW9uIG9mIE5G ViBzZXJ2aWNlIGZvcndhcmRpbmcgZ3JhcGhzIGFzIG9uZSBvZiBpdHMgdXNlIGNhc2VzLCBzbyBh IGNlcnRhaW4gaW50ZXJzZWN0aW9uIGlzIG5vdCBvbmx5IHVuYXZvaWRhYmxlIGJ1dCBuZWNlc3Nh cnkuDQoNCkJlIGdvb2RlLA0KDQpPbiA3IEp1bCAyMDE0LCBhdCAyMjoyOCAsIFJvYmVydCBSYXN6 dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+IHdyb3RlOg0K DQpIaSBSYW1raSwNCg0KQW5vdGhlciBpbXBvcnRhbnQgZ29hbCBpcyBmb3IgdGhlIG5ldHdvcmsg b3BlcmF0b3JzIHRvIGJlIGFibGUgdG8NCm9mZmVyIHZhbHVlIGFkZGVkIGNsb3VkIHNlcnZpY2Vz IHRvIHRoZWlyIGN1c3RvbWVycy4NCg0KVGhlIGFib3ZlIGdvYWwgb2YgTkZWUkcgc2VlbXMgbGlr ZSBpZGVudGljYWwgZ29hbCBvZiBJRVRGIFNGQyBXRy4NCg0KUGVyIHlvdXIgd3JpdGUtdXAgSSB0 aGluayB0aGVyZSBtYXkgYmUgc2lnbmlmaWNhbnQgb3ZlcmxhcCBiZXR3ZWVuIHRoZQ0KdHdvIGdy b3Vwcy4NCg0KVGhhdCBpcyBub3QgdG8gc2F5IHRoYXQgTkZWUkcgY291bGQgbm90IGJlIGJ1aWxk IGFuZCBjaGFydGVyZWQgdG8gYmUNCnVuaXF1ZSB3aXRoIHplcm8gb3ZlcmxhcCwgYnV0IHRoYXQg aXMgbm90IHdoYXQgeW91ciBvdmVydmlldyBzYXlzLg0KDQpJIHRoaW5rIGl0IG1heSBiZSB1c2Vm dWwgdG8gY2xhcmlmeSB0aGlzIGJlZm9yZSB0aGUgZmFjZSB0byBmYWNlIG1lZXRpbmcuDQoNClRo eCwNClIuDQoNCg0KDQoNCk9uIE1vbiwgSnVsIDcsIDIwMTQgYXQgMTA6MDggUE0sIHJhbWtpIEty aXNobmFuIDxyYW1rQGJyb2NhZGUuY29tPG1haWx0bzpyYW1rQGJyb2NhZGUuY29tPj4gd3JvdGU6 DQpPdmVydmlldyBvZiBwcm9wb3NlZCBJUlRGIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxpemF0 aW9uIFJlc2VhcmNoIEdyb3VwDQooTkZWUkcpDQoNCg0KDQpOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1 YWxpemF0aW9uIChORlYpIGlzIGEga2V5IGVtZXJnaW5nIGFyZWEgZm9yIG5ldHdvcmsNCm9wZXJh dG9ycywgaGFyZHdhcmUgYW5kIHNvZnR3YXJlIHZlbmRvcnMsIGNsb3VkIHNlcnZpY2UgcHJvdmlk ZXJzLCBhbmQgaW4NCmdlbmVyYWwgbmV0d29yayBwcmFjdGl0aW9uZXJzIGFuZCByZXNlYXJjaGVy cy4gVGhpcyBhcmVhIHJlcXVpcmVzIGV4cGxvcmluZw0KbmV3IGRpcmVjdGlvbnMgYW5kIHdvcmtp bmcgY29sbGFib3JhdGl2ZWx5IG9uIGhvdyB0byBjcmVhdGUgbmV0d29yayBzZXJ2aWNlcw0KdGhh dCB1dGlsaXplIGEgdmlydHVhbGl6ZWQgaW5mcmFzdHJ1Y3R1cmUuIE5ldHdvcmsgZnVuY3Rpb25z IHRoYXQgYXJlDQp0cmFkaXRpb25hbGx5IGltcGxlbWVudGVkIGluIGRlZGljYXRlZCBoYXJkd2Fy ZSBhcHBsaWFuY2VzIHdpbGwgbmVlZCB0byBiZQ0KZGVjb21wb3NlZCBhbmQgZXhlY3V0ZWQgaW4g dmlydHVhbCBtYWNoaW5lcyBydW5uaW5nIGluIGRhdGEgY2VudGVycy4gT25lIGtleQ0KZ29hbCBv ZiB0aGlzIG5ldyBhcmVhIGlzIHRvIHJlZHVjZSBjYXBpdGFsIGFuZCBvcGVyYXRpbmcgZXhwZW5k aXR1cmVzIGZvcg0KZnV0dXJlIGRlcGxveW1lbnRzIGZvciBuZXR3b3JrcyBhbmQgYXNzb2NpYXRl ZCBzZXJ2aWNlcy4gQW5vdGhlciBpbXBvcnRhbnQNCmdvYWwgaXMgZm9yIHRoZSBuZXR3b3JrIG9w ZXJhdG9ycyB0byBiZSBhYmxlIHRvIG9mZmVyIHZhbHVlIGFkZGVkIGNsb3VkDQpzZXJ2aWNlcyB0 byB0aGVpciBjdXN0b21lcnMuIEZpbmFsbHksIG5ldyBidXNpbmVzcyBtb2RlbHMgd2lsbCBvcGVu IGZvciB0aGUNCnByb3Zpc2lvbiBvZiBuZXR3b3JrIHNlcnZpY2VzLg0KDQpUaGUgdGVjaG5vbG9n aWVzIGVuYWJsaW5nIHRoZSB2aXJ0dWFsaXphdGlvbiBvZiBuZXR3b3JrIGZ1bmN0aW9ucyBhcmUN CmN1cnJlbnRseSBpbiBhbiBlYXJseSBzdGFnZSBvZiwgYW5kIHRoZXkgbmVlZCByZXNlYXJjaGVy cyB0byBkZXZlbG9wIG5ldw0KYXJjaGl0ZWN0dXJlcywgc3lzdGVtcywgYW5kIHNvZnR3YXJlLCBh bmQgdG8gZXhwbG9yZSB0cmFkZW9mZnMgYW5kDQpwb3NzaWJpbGl0aWVzIGZvciBsZXZlcmFnaW5n IHZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlIHRvIHByb3ZpZGUgc3VwcG9ydA0KZm9yIG5ldHdv cmsgZnVuY3Rpb25zLiBUaGUgTmV0d29yayBGdW5jdGlvbnMgVmlydHVhbGl6YXRpb24gUmVzZWFy Y2ggR3JvdXANCihORlZSRykgd2lsbCBicmluZyB0b2dldGhlciByZXNlYXJjaGVycyBhbmQgZ3Jv dyB0aGUgY29tbXVuaXR5IGFyb3VuZCB0aGUNCndvcmxkIGluIGJvdGggYWNhZGVtaWEgYW5kIGlu ZHVzdHJ5IHRvIGV4cGxvcmUgdGhpcyBuZXcgcmVzZWFyY2ggYXJlYQ0KdGhyb3VnaCB3b3Jrc2hv cHMsIHJlc2VhcmNoIGdyb3VwIG1lZXRpbmdzIGV0Yy4gYXQgcHJlbWllciBjb25mZXJlbmNlcyBz dWNoDQphcyBJRUVFIElDQywgSUVFRSBHbG9iZWNvbSBhbmQgaW52aXRpbmcgc3BlY2lhbCBpc3N1 ZXMgaW4gd2VsbC1rbm93bg0Kam91cm5hbHMuIFNvbWUgb2YgdGhlIGtleSB0b3BpY3Mgb2YgcmVz ZWFyY2ggaW5jbHVkZSB2aXJ0dWFsaXphdGlvbiBvZiBmaXhlZA0KYW5kIG1vYmlsZSBuZXR3b3Jr IGluZnJhc3RydWN0dXJlcywgbmV3IG5ldHdvcmsgYXJjaGl0ZWN0dXJlcyBiYXNlZCBvbg0Kdmly dHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbnMsIHZpcnR1YWxpemF0aW9uIG9mIHRoZSBob21lIGFu ZCBlbnRlcnByaXNlDQpuZXR3b3JrIGVudmlyb25tZW50cywgY28tZXhpc3RlbmNlIHdpdGggbm9u LXZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlIGFuZA0Kc2VydmljZXMsIGFuZCBhcHBsaWNhdGlv biB0byBncm93aW5nIGFyZWFzIG9mIGNvbmNlcm4gc3VjaCBhcyBJbnRlcm5ldCBvZg0KVGhpbmdz IChJb1QpIGFuZCBuZXh0IGdlbmVyYXRpb24gY29udGVudCBkaXN0cmlidXRpb24uDQoNClRoZSBO RlZSRyB3aWxsIGZvY3VzIG9uIHJlc2VhcmNoIHByb2JsZW1zIGFzc29jaWF0ZWQgd2l0aCB0aGVz ZSB0b3BpY3MgYW5kDQpvbiBicmluZ2luZyBhIHJlc2VhcmNoIGNvbW11bml0eSB0b2dldGhlciB0 aGF0IGNhbiBqb2ludGx5IGFkZHJlc3Mgc3VjaA0KcHJvYmxlbXMsIGNvbmNlbnRyYXRpbmcgb24g cHJvYmxlbXMgdGhhdCByZWxhdGUgbm90IGp1c3QgdG8gbmV0d29ya2luZyBidXQNCmFsc28gdG8g Y29tcHV0aW5nIGFuZCBzdG9yYWdlIGNvbnN0cmFpbnRzIGluIHN1Y2ggZW52aXJvbm1lbnRzLiBJ dCBpcyBhbHNvDQpob3BlZCB0aGF0IHRoZSBvdXRjb21lIG9mIHRoZSByZXNlYXJjaCB3aWxsIGJl bmVmaXQgc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMNCnRoYXQgY2FuIGdldCBzcGF3bmVkIHZpYSBJ UlRGICYgSUVURiBCb0YgbWVldGluZ3MgYW5kL29yIHByb3ZpZGUgdXNlZnVsDQppbnB1dCB0byBv dGhlciByZWxhdGVkIHN0YW5kYXJkcyBlZmZvcnRzIGluIEVUU0kgb3Igb3RoZXIgc3RhbmRhcmRz IGJvZGllcy4NCg0KTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBhdCAtDQpodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMvd2lraS9uZnZyZw0KDQpGaXJzdCBmYWNlLXRv LWZhY2UgTWVldGluZyBpbiBUb3JvbnRvDQoNCg0KDQpUaGUgZmlyc3QgZmFjZS10by1mYWNlIG1l ZXRpbmcgb2YgdGhlIHByb3Bvc2VkIE5GVlJHIHdpbGwgYmUgaGVsZCBhbG9uZyB3aXRoDQp0aGUg SUVURiBtZWV0aW5nIGluIFRvcm9udG8gb24gSnVseSAzMHRoIFdlZG5lc2RheSBmcm9tIDExOjMw YW0gdG8gMTowMHBtIGluDQp0aGUgQ2FuYWRpYW4gKEMpIFJvb20gKGltbWVkaWF0ZWx5IGFmdGVy IHRoZSBTRkMgbWVldGluZykuIFBsZWFzZSBsZXQgdXMNCmtub3cgaWYgeW91IGhhdmUgcmVzZWFy Y2ggdG9waWNzIHRvIHByZXNlbnQgZHVyaW5nIHRoZSBtZWV0aW5nLiBXb3VsZCByZWFsbHkNCmFw cHJlY2lhdGUgYWN0aXZlIGRpc2N1c3Npb25zIGluIHRoZSBtYWlsaW5nIGxpc3QgbmZ2cmdAaXJ0 Zi5vcmcuDQoNClRoYW5rcywNCg0KUmFta2kgb24gYmVoYWxmIG9mIHRoZSBORlZSRyBjby1jaGFp cnMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KDQoNCi0tDQpQTEVBU0UgTk9URSBNWSBORVcgRU1BSUwgQUREUkVT Uw0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28g Ui4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Bl ei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tDQpUZWw6ICAgICszNCA5 MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpF c3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1 IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBv IGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50 aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRv LCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVs Z2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRh IGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0 ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOz bi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSBy ZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCBy ZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUg aXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1l bnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmls ZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Eg b3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3Rp bmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGls aXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2Rl IGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJl Y2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVu aXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVz dHJ1acOnw6NvDQo= --_000_B2BF2321C70448A59D47CB902882A232telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQpIaSBSb2JlcnQsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFt IHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIHRlcm0gJnF1b3Q7Y2xvdWQgc2VydmljZXMm cXVvdDsgaGFzIGEgdG9vIHdpZGUgbWVhbmluZy4gV2hpbGUgaW4gU0ZDIEkgdW5kZXJzdGFuZCB3 ZSBhcmUgdGFsa2luZyBvbiBzZXJ2aWNlcyBsb2NhdGVkIGluIGRhdGFjZW50ZXJzLCBpbiB0aGUg TkZWIGNvbnRleHQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgbmV0d29yayBmdW5jdGlvbnMgdGhhdCBo YXZlIGJlZW4gdmlydHVhbGl6ZWQgaW50byBhIGNsb3VkLWxpa2UNCiBpbmZyYXN0cnVjdHVyZS4g SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgdGVybSBoYXMgdG8gYmUgY2xhcmlmaWVkLCB0aG91 Z2ggSSB0aGluayBpdCBpcyBjbGVhciBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlciBhdmFpbGFibGUg aW4gdGhlIFdpa2kuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Bbnl3YXks IFNGQyBoYXMgdGhlIHByb3Zpc2lvbiBvZiBORlYgc2VydmljZSBmb3J3YXJkaW5nIGdyYXBocyBh cyBvbmUgb2YgaXRzIHVzZSBjYXNlcywgc28gYSBjZXJ0YWluIGludGVyc2VjdGlvbiBpcyBub3Qg b25seSB1bmF2b2lkYWJsZSBidXQgbmVjZXNzYXJ5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QmUgZ29vZGUsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pk9uIDcgSnVsIDIwMTQsIGF0IDIyOjI4ICwgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPkhpIFJhbWtpLDxicj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPkFub3RoZXIgaW1wb3J0YW50IGdvYWwgaXMgZm9yIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyB0 byBiZSBhYmxlIHRvPGJyPg0Kb2ZmZXIgdmFsdWUgYWRkZWQgY2xvdWQgc2VydmljZXMgdG8gdGhl aXIgY3VzdG9tZXJzLjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NClRoZSBhYm92ZSBnb2FsIG9m IE5GVlJHIHNlZW1zIGxpa2UgaWRlbnRpY2FsIGdvYWwgb2YgSUVURiBTRkMgV0cuPGJyPg0KPGJy Pg0KUGVyIHlvdXIgd3JpdGUtdXAgSSB0aGluayB0aGVyZSBtYXkgYmUgc2lnbmlmaWNhbnQgb3Zl cmxhcCBiZXR3ZWVuIHRoZTxicj4NCnR3byBncm91cHMuPGJyPg0KPGJyPg0KVGhhdCBpcyBub3Qg dG8gc2F5IHRoYXQgTkZWUkcgY291bGQgbm90IGJlIGJ1aWxkIGFuZCBjaGFydGVyZWQgdG8gYmU8 YnI+DQp1bmlxdWUgd2l0aCB6ZXJvIG92ZXJsYXAsIGJ1dCB0aGF0IGlzIG5vdCB3aGF0IHlvdXIg b3ZlcnZpZXcgc2F5cy48YnI+DQo8YnI+DQpJIHRoaW5rIGl0IG1heSBiZSB1c2VmdWwgdG8gY2xh cmlmeSB0aGlzIGJlZm9yZSB0aGUgZmFjZSB0byBmYWNlIG1lZXRpbmcuPGJyPg0KPGJyPg0KVGh4 LDxicj4NClIuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gTW9uLCBKdWwgNywgMjAx NCBhdCAxMDowOCBQTSwgcmFta2kgS3Jpc2huYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyYW1rQGJy b2NhZGUuY29tIj5yYW1rQGJyb2NhZGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+T3ZlcnZpZXcgb2YgcHJvcG9zZWQgSVJURiBOZXR3b3JrIEZ1bmN0aW9u cyBWaXJ0dWFsaXphdGlvbiBSZXNlYXJjaCBHcm91cDxicj4NCihORlZSRyk8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uIChORlYpIGlzIGEga2V5 IGVtZXJnaW5nIGFyZWEgZm9yIG5ldHdvcms8YnI+DQpvcGVyYXRvcnMsIGhhcmR3YXJlIGFuZCBz b2Z0d2FyZSB2ZW5kb3JzLCBjbG91ZCBzZXJ2aWNlIHByb3ZpZGVycywgYW5kIGluPGJyPg0KZ2Vu ZXJhbCBuZXR3b3JrIHByYWN0aXRpb25lcnMgYW5kIHJlc2VhcmNoZXJzLiBUaGlzIGFyZWEgcmVx dWlyZXMgZXhwbG9yaW5nPGJyPg0KbmV3IGRpcmVjdGlvbnMgYW5kIHdvcmtpbmcgY29sbGFib3Jh dGl2ZWx5IG9uIGhvdyB0byBjcmVhdGUgbmV0d29yayBzZXJ2aWNlczxicj4NCnRoYXQgdXRpbGl6 ZSBhIHZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlLiBOZXR3b3JrIGZ1bmN0aW9ucyB0aGF0IGFy ZTxicj4NCnRyYWRpdGlvbmFsbHkgaW1wbGVtZW50ZWQgaW4gZGVkaWNhdGVkIGhhcmR3YXJlIGFw cGxpYW5jZXMgd2lsbCBuZWVkIHRvIGJlPGJyPg0KZGVjb21wb3NlZCBhbmQgZXhlY3V0ZWQgaW4g dmlydHVhbCBtYWNoaW5lcyBydW5uaW5nIGluIGRhdGEgY2VudGVycy4gT25lIGtleTxicj4NCmdv YWwgb2YgdGhpcyBuZXcgYXJlYSBpcyB0byByZWR1Y2UgY2FwaXRhbCBhbmQgb3BlcmF0aW5nIGV4 cGVuZGl0dXJlcyBmb3I8YnI+DQpmdXR1cmUgZGVwbG95bWVudHMgZm9yIG5ldHdvcmtzIGFuZCBh c3NvY2lhdGVkIHNlcnZpY2VzLiBBbm90aGVyIGltcG9ydGFudDxicj4NCmdvYWwgaXMgZm9yIHRo ZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBiZSBhYmxlIHRvIG9mZmVyIHZhbHVlIGFkZGVkIGNsb3Vk PGJyPg0Kc2VydmljZXMgdG8gdGhlaXIgY3VzdG9tZXJzLiBGaW5hbGx5LCBuZXcgYnVzaW5lc3Mg bW9kZWxzIHdpbGwgb3BlbiBmb3IgdGhlPGJyPg0KcHJvdmlzaW9uIG9mIG5ldHdvcmsgc2Vydmlj ZXMuPGJyPg0KPGJyPg0KVGhlIHRlY2hub2xvZ2llcyBlbmFibGluZyB0aGUgdmlydHVhbGl6YXRp b24gb2YgbmV0d29yayBmdW5jdGlvbnMgYXJlPGJyPg0KY3VycmVudGx5IGluIGFuIGVhcmx5IHN0 YWdlIG9mLCBhbmQgdGhleSBuZWVkIHJlc2VhcmNoZXJzIHRvIGRldmVsb3AgbmV3PGJyPg0KYXJj aGl0ZWN0dXJlcywgc3lzdGVtcywgYW5kIHNvZnR3YXJlLCBhbmQgdG8gZXhwbG9yZSB0cmFkZW9m ZnMgYW5kPGJyPg0KcG9zc2liaWxpdGllcyBmb3IgbGV2ZXJhZ2luZyB2aXJ0dWFsaXplZCBpbmZy YXN0cnVjdHVyZSB0byBwcm92aWRlIHN1cHBvcnQ8YnI+DQpmb3IgbmV0d29yayBmdW5jdGlvbnMu IFRoZSBOZXR3b3JrIEZ1bmN0aW9ucyBWaXJ0dWFsaXphdGlvbiBSZXNlYXJjaCBHcm91cDxicj4N CihORlZSRykgd2lsbCBicmluZyB0b2dldGhlciByZXNlYXJjaGVycyBhbmQgZ3JvdyB0aGUgY29t bXVuaXR5IGFyb3VuZCB0aGU8YnI+DQp3b3JsZCBpbiBib3RoIGFjYWRlbWlhIGFuZCBpbmR1c3Ry eSB0byBleHBsb3JlIHRoaXMgbmV3IHJlc2VhcmNoIGFyZWE8YnI+DQp0aHJvdWdoIHdvcmtzaG9w cywgcmVzZWFyY2ggZ3JvdXAgbWVldGluZ3MgZXRjLiBhdCBwcmVtaWVyIGNvbmZlcmVuY2VzIHN1 Y2g8YnI+DQphcyBJRUVFIElDQywgSUVFRSBHbG9iZWNvbSBhbmQgaW52aXRpbmcgc3BlY2lhbCBp c3N1ZXMgaW4gd2VsbC1rbm93bjxicj4NCmpvdXJuYWxzLiBTb21lIG9mIHRoZSBrZXkgdG9waWNz IG9mIHJlc2VhcmNoIGluY2x1ZGUgdmlydHVhbGl6YXRpb24gb2YgZml4ZWQ8YnI+DQphbmQgbW9i aWxlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzLCBuZXcgbmV0d29yayBhcmNoaXRlY3R1cmVzIGJh c2VkIG9uPGJyPg0KdmlydHVhbGl6ZWQgbmV0d29yayBmdW5jdGlvbnMsIHZpcnR1YWxpemF0aW9u IG9mIHRoZSBob21lIGFuZCBlbnRlcnByaXNlPGJyPg0KbmV0d29yayBlbnZpcm9ubWVudHMsIGNv LWV4aXN0ZW5jZSB3aXRoIG5vbi12aXJ0dWFsaXplZCBpbmZyYXN0cnVjdHVyZSBhbmQ8YnI+DQpz ZXJ2aWNlcywgYW5kIGFwcGxpY2F0aW9uIHRvIGdyb3dpbmcgYXJlYXMgb2YgY29uY2VybiBzdWNo IGFzIEludGVybmV0IG9mPGJyPg0KVGhpbmdzIChJb1QpIGFuZCBuZXh0IGdlbmVyYXRpb24gY29u dGVudCBkaXN0cmlidXRpb24uPGJyPg0KPGJyPg0KVGhlIE5GVlJHIHdpbGwgZm9jdXMgb24gcmVz ZWFyY2ggcHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIHRoZXNlIHRvcGljcyBhbmQ8YnI+DQpvbiBi cmluZ2luZyBhIHJlc2VhcmNoIGNvbW11bml0eSB0b2dldGhlciB0aGF0IGNhbiBqb2ludGx5IGFk ZHJlc3Mgc3VjaDxicj4NCnByb2JsZW1zLCBjb25jZW50cmF0aW5nIG9uIHByb2JsZW1zIHRoYXQg cmVsYXRlIG5vdCBqdXN0IHRvIG5ldHdvcmtpbmcgYnV0PGJyPg0KYWxzbyB0byBjb21wdXRpbmcg YW5kIHN0b3JhZ2UgY29uc3RyYWludHMgaW4gc3VjaCBlbnZpcm9ubWVudHMuIEl0IGlzIGFsc288 YnI+DQpob3BlZCB0aGF0IHRoZSBvdXRjb21lIG9mIHRoZSByZXNlYXJjaCB3aWxsIGJlbmVmaXQg c3RhbmRhcmRpemF0aW9uIGVmZm9ydHM8YnI+DQp0aGF0IGNhbiBnZXQgc3Bhd25lZCB2aWEgSVJU RiAmYW1wOyBJRVRGIEJvRiBtZWV0aW5ncyBhbmQvb3IgcHJvdmlkZSB1c2VmdWw8YnI+DQppbnB1 dCB0byBvdGhlciByZWxhdGVkIHN0YW5kYXJkcyBlZmZvcnRzIGluIEVUU0kgb3Igb3RoZXIgc3Rh bmRhcmRzIGJvZGllcy48YnI+DQo8YnI+DQpNb3JlIGRldGFpbHMgY2FuIGJlIGZvdW5kIGF0IC08 YnI+DQo8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMv d2lraS9uZnZyZyI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaXJ0Zi90cmFjL3dp a2kvbmZ2cmc8L2E+PGJyPg0KPGJyPg0KRmlyc3QgZmFjZS10by1mYWNlIE1lZXRpbmcgaW4gVG9y b250bzxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBmaXJzdCBmYWNlLXRvLWZhY2UgbWVldGlu ZyBvZiB0aGUgcHJvcG9zZWQgTkZWUkcgd2lsbCBiZSBoZWxkIGFsb25nIHdpdGg8YnI+DQp0aGUg SUVURiBtZWV0aW5nIGluIFRvcm9udG8gb24gSnVseSAzMHRoIFdlZG5lc2RheSBmcm9tIDExOjMw YW0gdG8gMTowMHBtIGluPGJyPg0KdGhlIENhbmFkaWFuIChDKSBSb29tIChpbW1lZGlhdGVseSBh ZnRlciB0aGUgU0ZDIG1lZXRpbmcpLiBQbGVhc2UgbGV0IHVzPGJyPg0Ka25vdyBpZiB5b3UgaGF2 ZSByZXNlYXJjaCB0b3BpY3MgdG8gcHJlc2VudCBkdXJpbmcgdGhlIG1lZXRpbmcuIFdvdWxkIHJl YWxseTxicj4NCmFwcHJlY2lhdGUgYWN0aXZlIGRpc2N1c3Npb25zIGluIHRoZSBtYWlsaW5nIGxp c3QgbmZ2cmdAaXJ0Zi5vcmcuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NClJhbWtpIG9u IGJlaGFsZiBvZiB0aGUgTkZWUkcgY28tY2hhaXJzPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBs aXN0PGJyPg0Kc2ZjQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxicj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApOyBsZXR0ZXItc3Bh Y2luZzpub3JtYWw7IG9ycGhhbnM6YXV0bzsgdGV4dC1hbGlnbjpzdGFydDsgdGV4dC1pbmRlbnQ6 MHB4OyB0ZXh0LXRyYW5zZm9ybTpub25lOyB3aGl0ZS1zcGFjZTpub3JtYWw7IHdpZG93czphdXRv OyB3b3JkLXNwYWNpbmc6MHB4OyB3b3JkLXdyYXA6YnJlYWstd29yZCI+DQotLTxicj4NClBMRUFT RSBOT1RFIE1ZIE5FVyBFTUFJTCBBRERSRVNTPGJyPg0KJnF1b3Q7RXN0YSB2ZXogbm8gZmFsbGFy ZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJyPg0KPGJyPg0KRHIgRGllZ28gUi4gTG9wZXo8 YnI+DQpUZWxlZm9uaWNhIEkmIzQzO0Q8YnI+DQo8YSBocmVmPSJodHRwOi8vcGVvcGxlLnRpZC5l cy9kaWVnby5sb3Blei8iPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LzwvYT48YnI+ DQo8YnI+DQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208YnI+DQpUZWw6ICZu YnNwOyAmbmJzcDsmIzQzOzM0IDkxMyAxMjkgMDQxPGJyPg0KTW9iaWxlOiAmIzQzOzM0IDY4MiAw NTEgMDkxPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPC9k aXY+DQo8YnI+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0i R3JheSIgc2l6ZT0iMSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmln ZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9y bWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNp dm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVs IGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0 dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nD s24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmln ZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBx dWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkg cHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sDQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21t dW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0 ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11 bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEgbWVu c2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0 aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZp ZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUg ZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNh ZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2 dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJp ZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1l bnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRh bWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo288YnI+ DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B2BF2321C70448A59D47CB902882A232telefonicacom_-- From nobody Mon Jul 7 19:12: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 3E29D1B29E9; Mon, 7 Jul 2014 19:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ytvDyLjfiv_z; Mon, 7 Jul 2014 19:12:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C841B29EA; Mon, 7 Jul 2014 19:12:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW85141; Tue, 08 Jul 2014 02:12:00 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 03:11:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 10:11:53 +0800 From: Xuxiaohu To: Ron Parker Thread-Topic: Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF Thread-Index: AQHPmlH7odT5H7A+MEepJZdtU3RfXw== Date: Tue, 8 Jul 2014 02:11:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4o5hhT5xMf9AphpgnImiChqshj0 Cc: "" , "sfc@ietf.org" Subject: [sfc] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 02:12:04 -0000 (Note that I changed the subject since this is a totally different topic) Hi Ron, I agree there are some cases where the underlay network is not MPLS-capable= . In those cases, you could actually just take the MPLS label stack which r= epresents a given SFP (http://tools.ietf.org/html/draft-xu-spring-sfc-use-c= ase-02) as an overlay, just like the SFC encapsulation header (http://tools= .ietf.org/html/draft-merged-sfc-architecture-00). The MPLS packets on the o= verlay could be transported over IP underlay networks with MPLS-over-IP tun= nels (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip= -00). IMHO, this MPLS label stack based (or SPRING based) SFC approach is a= concrete example of Transport Derived SFF (see below) as defined in sectio= n 4.3.1 of the SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-= architecture-00): 4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. Existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use a transport mechanism which carries the service path information from the SFC encapsulation, and information derived from the SFC encapsulation, to build transport information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, July 07, 2014 9:47 PM > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org' > Subject: Re: [sfc] New Version Notification for > draft-dunbar-sfc-fun-instances-restoration-00.txt >=20 > Qin, >=20 > I agree that RSVP-TE style MPLS is a close architectural match to what SF= C is > trying to achieve, and that an MPLS label stack in this context is likely= the most > efficient way to encode explicit source routing, packet-by-packet, while > preserving all the resiliency capabilities that are required for real-wor= ld SFC. >=20 > But one concern I have is the ubiquity, or lack thereof, of MPLS where SF= C > would be used. In mobile carrier environments, the SFC is seen as appli= cable > to the "Gi-LAN" set of value added services that are deployed between the > subscriber management system (i.e., GGSN/PDN-GW) and the Internet. In > some cases, this may be MPLS underpinning this part of the network, but i= n > others it is simple Ethernet or SDN overlay over Ethernet. >=20 > Please share your thoughts on this. >=20 > Thanks. >=20 > Ron >=20 From nobody Mon Jul 7 20:02: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 AF8611B2A14 for ; Mon, 7 Jul 2014 20:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Iq2XxFvzKbpb for ; Mon, 7 Jul 2014 20:02:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 386AC1A00D6 for ; Mon, 7 Jul 2014 20:02:15 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 856401256C1C for ; Tue, 8 Jul 2014 11:02:03 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 1378772EDEA for ; Tue, 8 Jul 2014 11:02:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s68323Dm017684 for ; Tue, 8 Jul 2014 11:02:03 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <007d01cf9a54$e9400110$bbc00330$@gmail.com> To: sfc@ietf.org MIME-Version: 1.0 X-KeepSent: 95C3BBE5:7C717E26-48257D0F:000E4B8F; 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, 8 Jul 2014 11:02:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-08 11:02:00, Serialize complete at 2014-07-08 11:02:00 Content-Type: multipart/alternative; boundary="=_alternative 0010E54C48257D0F_=" X-MAIL: mse02.zte.com.cn s68323Dm017684 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mJnhsYLk3HpSHIouyc4wznflwGY Subject: [sfc] [SFC] Comments of draft-krishnan-sfc-oam-req-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, 08 Jul 2014 03:02:19 -0000 This is a multipart message in MIME format. --=_alternative 0010E54C48257D0F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgY28tYXV0aG9yc6OsIGd1eXOjrA0KDQpIZXJlIGFyZSB0d28gY29tbWVudHMgYW5kIHF1ZXN0 aW9ucyBvbiB0aGlzIGRyYWZ0Lg0KDQoxKQ0KKy0tLSsgKy0rICstKyArLS0tKw0KfE5WRXwtfEJ8 LXxCfC18TlZFfA0KKy0tLSsgKy0rICstKyArLS0tKw0KICAgICAgIHgtLS14ICAgICAgICAgIEwy DQoNCg0KSSBkb24ndCBrbm93IHdoeSBCJkIgYXJlIGJldHdlZW4gTlZFcyByYXRoZXIgdGhhbiAi TDMgbmV0d29yayIuDQpJZiByZWZlciB0byBkcmFmdC1pZXRmLW52bzMtYXJjaC0wMSwgaGVyZSBz aG91bGQgYmUgIlIiIGFuZCBJUC1PQU0uDQoNCjIpIA0KKy0rICstLSsgKy0rICstKyArLS0rDQp8 QnwtfFNGfC18UnwtfFJ8LXxTRnwNCistKyArLS0rICstKyArLSsgKy0tKw0KQ2xhc3NpZmVyIGlz IHRoZSBiZWdpbm5pbmcgb2YgU0ZDLCB0aGVyZSBtaWdodCBiZSBhIG92ZXJsYXkgbmV0d29yayAN CmJldHdlZW4gYSBjbGFzc2lmZXIgYW5kIGFuIFNGLiBJJ20gbm90IHN1cmUgY2xhc3NpZmVyIHNo b3VsZCBiZSBkaXNzY3Vzc2VkDQpoZXJlIGFuZCB0aGVyZSBtaWdodCBleGlzdCBhbiBPQU0gbWVj aGFuaXNtIGJldHdlZW4gY2xhc3NpZmVycyBhbmQgU0ZzLg0KDQoyKSBBbnkgb3RoZXIgc2NlbmFy aW9zPyBPbmx5IERDIGlzIG5vdCBzdWZmaWNpZW50LiBJIHByb3Bvc2UgdG8gDQphZGQgc29tZSBi cm9hZGJhbmQgJiBtb2JpbGl0eSBzY2VuYXJpb3MuDQoNCg0KVGhhbmtzLA0KV2VpDQo= --=_alternative 0010E54C48257D0F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGNvLWF1dGhvcnOjrCBndXlz o6w8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlcmUg YXJlIHR3byBjb21tZW50cyBhbmQgcXVlc3Rpb25zDQpvbiB0aGlzIGRyYWZ0LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MSk8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPistLS0rICstKyArLSsgKy0tLSs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnxOVkV8LXxCfC18QnwtfE5WRXw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPistLS0rICstKyArLSsgKy0t LSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3gtLS14ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 TDI8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkkgZG9uJ3Qga25vdyB3aHkgQiZhbXA7QiBhcmUgYmV0d2Vlbg0KTlZFcyByYXRoZXIgdGhhbiAm cXVvdDtMMyBuZXR3b3JrJnF1b3Q7LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SWYgcmVmZXIgdG8gZHJhZnQtaWV0Zi1udm8zLWFyY2gtMDEsDQpoZXJlIHNob3Vs ZCBiZSAmcXVvdDtSJnF1b3Q7IGFuZCBJUC1PQU0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yKSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPistKyArLS0rICstKyArLSsgKy0tKzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+fEJ8LXxTRnwtfFJ8LXxSfC18U0Z8PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4rLSsgKy0tKyArLSsgKy0rICstLSs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNsYXNzaWZlciBpcyB0aGUgYmVn aW5uaW5nIG9mIFNGQywgdGhlcmUNCm1pZ2h0IGJlIGEgb3ZlcmxheSBuZXR3b3JrIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YmV0d2VlbiBhIGNsYXNzaWZlciBh bmQgYW4gU0YuIEknbSBub3QNCnN1cmUgY2xhc3NpZmVyIHNob3VsZCBiZSBkaXNzY3Vzc2VkPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5oZXJlIGFuZCB0aGVyZSBt aWdodCBleGlzdCBhbiBPQU0gbWVjaGFuaXNtDQpiZXR3ZWVuIGNsYXNzaWZlcnMgYW5kIFNGcy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIpIEFueSBv dGhlciBzY2VuYXJpb3M/IE9ubHkgREMgaXMgbm90DQpzdWZmaWNpZW50LiBJIHByb3Bvc2UgdG8g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hZGQgc29tZSBicm9h ZGJhbmQgJmFtcDsgbW9iaWxpdHkgc2NlbmFyaW9zLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2VpPC9mb250Pg0K --=_alternative 0010E54C48257D0F_=-- From nobody Mon Jul 7 20:08: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 190E01A00D6 for ; Mon, 7 Jul 2014 20:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZF6whF0tMoyq for ; Mon, 7 Jul 2014 20:08:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B081A00C6 for ; Mon, 7 Jul 2014 20:08:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS70215; Tue, 08 Jul 2014 03:08:51 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 04:08:50 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 11:08:46 +0800 From: Qin Wu To: Ron Parker , "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuCAAAWfIIAACETAgADagEA= Date: Tue, 8 Jul 2014 03:08:45 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/u95XCP5XGF8fC7l-D8tZ7_O9zKk Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 08 Jul 2014 03:08:56 -0000 SGksIFJvbjoNClRoZSBQQ0UgYmFzZWQgYXBwcm9hY2ggd2UgcHJvcG9zZWQgaW4gZHJhZnQtd3Ut cGNlLXRyYWZmaWMtc3RlZXJpbmctc2ZjLTA0IGNhbiBiZSBhcHBsaWVkIHRvIE1QTFMgbmV0d29y aywgYnV0IG5vdCBuZWNlc3NhcnkgdG8gUlNWUC1URSBzdHlsZSBNUExTLg0KWW91IGNhbiB1c2Ug d2hhdGV2ZXIgc2lnbmFsaW5nIHlvdSBsaWtlIHRvIGluc3RhbnRpYXRlIFNlcnZpY2UgRnVuY3Rp b24gUGF0aC4gQnV0IG5vdCBuZWNlc3NhcnkgdG8gbGltaXRlIHRvIG9ubHkgdXNpbmcgUlNWUCBh cyBzaWduYWxpbmcuDQoNCllvdSBhcmUgcmlnaHQsIFNGQyBjYW4gYmUgdXNlZCB3aXRob3V0IE1Q TFMsIGUuZy4sIElQIG5ldHdvcmssIGJ1dCB3ZSBhcmUgaG9waW5nIHRoZSBhcHByb2FjaCB3ZSBw cm9wb3NlZCBhbHNvIGNhbiBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggU0ROIGNvbnRyb2xsZXIgb3Ig T1NTL05NUyBzaW5jZQ0KU3RhdGVmdWwgUENFIGFzIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIgc3Vw cG9ydHMgZWl0aGVyIHN0YXRpYyBzZXJ2aWNlIGZ1bmN0aW9uIHBsYWNlbWVudCBvciBkeW5hbWlj IGNyZWF0aW9uIGFuZCBkZWxldGlvbiBvZiB0aGUgcGF0aC4NClRoZXJlZm9yZSBJdCBkb2Vzbid0 IG1hdHRlciB3aGF0IHNpZ25hbGluZyB5b3UgYXJlIHVzaW5nIHRvIHNldHVwIHBhdGguDQoNClJl Z2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogUm9uIFBhcmtlciBbbWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jfU wjfI1SAyMTo0Nw0KytW8/sjLOiBRaW4gV3U7IExpbmRhIER1bmJhcjsgJ3NmY0BpZXRmLm9yZycN Ctb3zOI6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMt ZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCg0KUWluLA0KDQpJIGFncmVlIHRoYXQg UlNWUC1URSBzdHlsZSBNUExTIGlzIGEgY2xvc2UgYXJjaGl0ZWN0dXJhbCBtYXRjaCB0byB3aGF0 IFNGQyBpcyB0cnlpbmcgdG8gYWNoaWV2ZSwgYW5kIHRoYXQgYW4gTVBMUyBsYWJlbCBzdGFjayBp biB0aGlzIGNvbnRleHQgaXMgbGlrZWx5IHRoZSBtb3N0IGVmZmljaWVudCB3YXkgdG8gZW5jb2Rl IGV4cGxpY2l0IHNvdXJjZSByb3V0aW5nLCBwYWNrZXQtYnktcGFja2V0LCB3aGlsZSBwcmVzZXJ2 aW5nIGFsbCB0aGUgcmVzaWxpZW5jeSBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgcmVxdWlyZWQgZm9y IHJlYWwtd29ybGQgU0ZDLiAgICANCg0KQnV0IG9uZSBjb25jZXJuIEkgaGF2ZSBpcyB0aGUgdWJp cXVpdHksIG9yIGxhY2sgdGhlcmVvZiwgb2YgTVBMUyB3aGVyZSBTRkMgd291bGQgYmUgdXNlZC4g ICBJbiBtb2JpbGUgY2FycmllciBlbnZpcm9ubWVudHMsIHRoZSBTRkMgaXMgc2VlbiBhcyBhcHBs aWNhYmxlIHRvIHRoZSAiR2ktTEFOIiBzZXQgb2YgdmFsdWUgYWRkZWQgc2VydmljZXMgdGhhdCBh cmUgZGVwbG95ZWQgYmV0d2VlbiB0aGUgc3Vic2NyaWJlciBtYW5hZ2VtZW50IHN5c3RlbSAoaS5l LiwgR0dTTi9QRE4tR1cpIGFuZCB0aGUgSW50ZXJuZXQuICAgIEluIHNvbWUgY2FzZXMsIHRoaXMg bWF5IGJlIE1QTFMgdW5kZXJwaW5uaW5nIHRoaXMgcGFydCBvZiB0aGUgbmV0d29yaywgYnV0IGlu IG90aGVycyBpdCBpcyBzaW1wbGUgRXRoZXJuZXQgb3IgU0ROIG92ZXJsYXkgb3ZlciBFdGhlcm5l dC4NCg0KUGxlYXNlIHNoYXJlIHlvdXIgdGhvdWdodHMgb24gdGhpcy4NCg0KVGhhbmtzLg0KDQog ICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW4gV3UNClNlbnQ6IE1vbmRheSwg SnVseSAwNywgMjAxNCA5OjEzIEFNDQpUbzogUm9uIFBhcmtlcjsgTGluZGEgRHVuYmFyOyAnc2Zj QGlldGYub3JnJw0KU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KDQpS b246DQpXZSBhbHNvIGhhdmUgZHJhZnQgdG8gZGlzY3VzcyBob3cgdG8gaW5zdGFudGlhdGUgc2Vy dmljZSBmdW5jdGlvbiBwYXRoIHVzaW5nIFBDRS1pbml0aWF0ZSBMU1AgaW5zdGFudGlhdGlvbi4N Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5n LXNmYy0wNA0KSXQgc3VwcG9ydHMgZHluYW1pYyBjcmVhdGlvbiBhbmQgZGVsZXRpb24gb2Ygc2Vy dmljZSBmdW5jdGlvbiBwYXRoLg0KWW91ciBtYXkgY2hlY2sgb3V0Lg0KDQpSZWdhcmRzIQ0KLVFp bg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCreiy83KsbzkOiAyMDE0xOo31MI3yNUgMjA6NTINCsrV vP7IyzogTGluZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0K1vfM4jogUmU6IFtzZmNdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJl c3RvcmF0aW9uLTAwLnR4dA0KDQpMaW5kYSAmIEFuZHksDQoNClRoYW5rcyBmb3IgcHV0dGluZyB0 aGlzIHRvZ2V0aGVyLiAgIEknbSBoYXBweSB0byBzZWUgbW9yZSB3b3JrIG9uIHRoZSAiY2hhaW4t dG8tcGF0aCIgdG9waWMuICAgSSBhZ3JlZSB3aXRoIGFsbCBvZiB5b3VyIGFuYWx5c2lzIHJlZ2Fy ZGluZyBwcm9zL2NvbnMgb2YgdmFyaW91cyBhcHByb2FjaGVzLiAgICAgRW5jYXBzdWxhdGlvbiBh bmQgQ29udHJvbCBQbGFuZSB3aWxsIGJlIGRlcGVuZGVudCBvbiBvdXIgYXJjaGl0ZWN0dXJhbCBk ZWNpc2lvbnMgaW4gdGhpcyBhcmVhLiAgIFRoZSBlbHVzaXZlIHRoaW5nIGZvciBhbGwgb2YgdXMs IGFzIGEgZ3JvdXAsIGlzIHRvIGNvbWUgdG8gc29tZSBjb25jbHVzaW9ucyENCg0KICAgUm9uDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGluZGEgRHVuYmFyDQpTZW50OiBGcmlkYXksIEp1 bHkgMDQsIDIwMTQgNDo0OSBQTQ0KVG86ICdzZmNAaWV0Zi5vcmcnDQpTdWJqZWN0OiBbc2ZjXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0 YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQoNCkhpLCANCg0KVGhpcyBkcmFmdCBkZXNjcmliZXMg dGhlIGZyYW1ld29yayBvZiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBvZg0KICAgU2Vydmlj ZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24gdGhlIHBhdGggZmFp bCBvcg0KICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCg0KQXBwcmVjaWF0ZSB0byBoZWFyIHlvdXIg Y29tbWVudHMgb3Igc3VnZ2VzdGlvbnMuIA0KDQpMaW5kYSAmIEFuZHkNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDMwLCAyMDE0 IDExOjI1IEFNDQpUbzogQW5kcmV3IEcuIE1hbGlzOyBMaW5kYSBEdW5iYXI7IEFuZHJldyBHLiBN YWxpczsgTGluZGEgRHVuYmFyDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3Rv cmF0aW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBE dW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQt ZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxl OgkJRnJhbWV3b3JrIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyBSZXN0b3JhdGlvbg0K RG9jdW1lbnQgZGF0ZToJMjAxNC0wNC0yOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N ClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgdGhl IGZyYW1ld29yayBvZiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBvZg0KICAgU2VydmljZSBD aGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24gdGhlIHBhdGggZmFpbCBv cg0KICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNm YyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon Jul 7 20:38: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 42CC21A0119 for ; Mon, 7 Jul 2014 20:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 emY3uk7crpUm for ; Mon, 7 Jul 2014 20:38:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2497F1A0AC5 for ; Mon, 7 Jul 2014 20:38:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW90346; Tue, 08 Jul 2014 03:38:17 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 04:38:16 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 11:38:08 +0800 From: Jiangyuanlong To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmYYJzzmHwmoEq/Blwej5BLzZuVlc9g Date: Tue, 8 Jul 2014 03:38:08 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BD67@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CXUmZLPcobXm4s_z39Eo-3gmVhw Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 03:38:22 -0000 Hi Thomas and all, After a review of draft-ietf-sfc-problem-statement-07, I have the following= comments and suggestions: 1. The definition of "Classification" does not parse to me, it says: " Classification: Locally instantiated policy that results in matching of traffic flows for identification of appropriate outbound forwarding actions." Classification seems to be defined as a kind of policy, but it is not. It is suggested to be defined as: " Classification: Identification of traffic flows based on locally=20 instantiated policy for appropriate outbound forwarding actions." 2. "Network Overlay" is defined but not used at all in the contexts - excep= t in Section "Related IETF Work", however, the definition of "Service Overl= ay" introduces a new terminology "overlay network": =20 " Service Overlay: An overlay network created for the purpose of forwarding data along a service function path. " Is this "overlay network" actually a typo of "network overlay"?=20 3. "Service Function Path" is defined as: " Service Function Path (SFP): The instantiation of a service function chain in the network. Packets follow a service function path from a classifier through the required instances of service functions in the network." SFP seems to be instantiation of an SFC, that is very confusing. Maybe it w= ill be more concrete to be repharased as: =20 " Service Function Path (SFP): A path for packet forwarding constructed=20 from a classifier through the required instances of service functions= =20 after the instantiation of a service function chain in the network." 4. In Section 2.10, the title is "Per-Service (re)Classification", but it a= ctually discusses per-service-function (re)classification. Therefore, it is suggested: s/Per-Service/Per-Service-Function/ s/per-service/per-service-function/ 5. In Section 3.2, it says: "Symmetric classification ensures that forward and reverse chains are in pl= ace." But what is "Symmetric classification"? What does it mean by "in place"? 6. In Section 3.3, it says: "...As such metadata is not used as forwarding information to deliver packe= ts=20 along the service overlay." It is strange to have such a negative phrase here. From the definition of "= service overlay" and the contexts, it is unclear who will forward the packe= t, and what forwarding information is realy needed, therefore, it is too ea= rly to make such a statement, and it should be rightfully considered in an = architecture draft IMHO. 7. In Section 3.3, it says: " ... Service functions utilize metadata, as required, for localized policy decisions." Is "localized policy decisions" the only valid thing for metadata to be = used? Or is it just an example? =20 Other minor editorial proposals: s/real or virtualized/physical or virtualized/ =20 s/fearing misconfiguration and downtime/for fear of misconfiguration and co= nsequent downtime/=20 s/inter- vendor/inter-vendor/ s/decoupling of policy from the topology/decoupling of policy from the netw= ork topology/ (BTW, we only defined service topology in the document) Regards, Yuanlong -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Thursday, June 26, 2014 3:14 AM To: sfc@ietf.org Subject: [sfc] 2nd WG Last Call on Problem Statement Hi. We ran a WGLC on the problem statement draft (draft-ietf-sfc-problem-statement-07.txt) back in May. Although the draft received significant review and support prior to the formal LC, the actual last call resulted largely in silence. While it would be convenient to take silence as acceptance, that's not good enough. To show the document is ready, we need WG members to speak up and indicate they have read a recent version of the document and think its ready to go. Note that the document was just reissued. Section 3 has been edited to remove some of the text was deemed to be encroaching on architecture. You can see the changes at http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf-sf= c-problem-statement-07-from-06.diff.html With that, we are restarting a 2-week WGLC on the document. We specifically need to see sufficient indications from WG members that the document is ready to advance, and that the document does not contain significant deficiencies. Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 7 21:31: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 E2E271A0AD1 for ; Mon, 7 Jul 2014 21:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.052 X-Spam-Level: X-Spam-Status: No, score=-99.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 7-kEm-eSDqAr for ; Mon, 7 Jul 2014 21:31:26 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606671A015D for ; Mon, 7 Jul 2014 21:31:26 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 8 Jul 2014 13:31:24 +0900 Received: from SMTP1.etri.info ([169.254.1.81]) by SMTP2.etri.info ([10.2.6.31]) with mapi id 14.01.0355.002; Tue, 8 Jul 2014 13:31:21 +0900 From: =?ks_c_5601-1987?B?wMy9wsDN?= To: Linda Dunbar Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuCAAOlkYA== Date: Tue, 8 Jul 2014 04:31:21 +0000 Message-ID: <2EDFB4D974E4AC45B641E2B5F734E6C21CD18203@SMTP1.etri.info> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.170.46] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/I6NXh6utwIpktKjs6dfpZq1oAPM Cc: "'sfc@ietf.org'" , Ron Parker Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 08 Jul 2014 04:31:29 -0000 TGluZGEsDQoNCkFsc28gZ2xhZCB0byBzZWUgdGhpcyBpbiBhY3RpdmUuDQoNCjEuIFJlZ2FyZGlu ZyB0ZXJtaW5vbG9naWVzOiAic2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBjb21wb25lbnQiIGFu ZCAic2VydmljZSBjaGFpbiBpbnN0YW5jZSBwYXRoIiwNCndoYXQgZGlmZmVyZW5jZXMgZG8geW91 IGhhdmUgaW4geW91ciBtaW5kIGNvbXBhcmluZyB3aXRoICJzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlIiBhbmQgInNlcnZpY2UgZnVuY3Rpb24gcGF0aCIsIHJlc3BlY3RpdmVseT8NCg0KMi4gSXQg c2VlbXMgdG8gbWUgdGhhdCB5b3VyIHRleHQgaXMgYWJvdXQgZHluYW1pYyB1cGRhdGUgb2YgU0ZD IHJhdGhlciB0aGFuIHJlc3RvcmF0aW9uIGZyb20gZmFpbHVyZS4gV2hhdCBkbyB5b3UgdGhpbms/ DQoNClJlZ2FyZHMsDQpTZXVuZy1pay4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJv biBQYXJrZXINCj4gU2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDk6NTIgUE0NCj4gVG86IExp bmRhIER1bmJhcjsgJ3NmY0BpZXRmLm9yZycNCj4gU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4tDQo+IGluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMC50eHQNCj4gDQo+IExpbmRhICYgQW5keSwNCj4gDQo+IFRoYW5rcyBmb3Ig cHV0dGluZyB0aGlzIHRvZ2V0aGVyLiAgIEknbSBoYXBweSB0byBzZWUgbW9yZSB3b3JrIG9uIHRo ZQ0KPiAiY2hhaW4tdG8tcGF0aCIgdG9waWMuICAgSSBhZ3JlZSB3aXRoIGFsbCBvZiB5b3VyIGFu YWx5c2lzIHJlZ2FyZGluZw0KPiBwcm9zL2NvbnMgb2YgdmFyaW91cyBhcHByb2FjaGVzLiAgICAg RW5jYXBzdWxhdGlvbiBhbmQgQ29udHJvbCBQbGFuZSB3aWxsDQo+IGJlIGRlcGVuZGVudCBvbiBv dXIgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgaW4gdGhpcyBhcmVhLiAgIFRoZSBlbHVzaXZlDQo+ IHRoaW5nIGZvciBhbGwgb2YgdXMsIGFzIGEgZ3JvdXAsIGlzIHRvIGNvbWUgdG8gc29tZSBjb25j bHVzaW9ucyENCj4gDQo+ICAgIFJvbg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTGluZGEgRHVuYmFyDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA0OjQ5IFBNDQo+ IFRvOiAnc2ZjQGlldGYub3JnJw0KPiBTdWJqZWN0OiBbc2ZjXSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWZ1bi0NCj4gaW5zdGFuY2VzLXJlc3RvcmF0 aW9uLTAwLnR4dA0KPiANCj4gSGksDQo+IA0KPiBUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgZnJh bWV3b3JrIG9mIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIG9mDQo+ICAgIFNlcnZpY2UgQ2hh aW4gSW5zdGFuY2UgUGF0aCB3aGVuIHNvbWUgaW5zdGFuY2VzIG9uIHRoZSBwYXRoIGZhaWwgb3IN Cj4gICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCj4gDQo+IEFwcHJlY2lhdGUgdG8gaGVhciB5b3Vy IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zLg0KPiANCj4gTGluZGEgJiBBbmR5DQo+IA0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMzAsIDIwMTQgMTE6MjUgQU0NCj4gVG86IEFuZHJldyBHLiBNYWxpczsgTGluZGEgRHVuYmFy OyBBbmRyZXcgRy4gTWFsaXM7IExpbmRhIER1bmJhcg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy0NCj4gcmVzdG9y YXRpb24tMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0K PiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNl cy1yZXN0b3JhdGlvbg0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlGcmFtZXdvcmsgZm9yIFNl cnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIFJlc3RvcmF0aW9uDQo+IERvY3VtZW50IGRhdGU6CTIw MTQtMDQtMjkNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkxMg0K PiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZHVuYmFyLXNmYy1mdW4tDQo+IGluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCj4gU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWR1bmJh ci1zZmMtZnVuLQ0KPiBpbnN0YW5jZXMtcmVzdG9yYXRpb24vDQo+IEh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMt DQo+IHJlc3RvcmF0aW9uLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZHJhZnQg ZGVzY3JpYmVzIHRoZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YN Cj4gICAgU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24g dGhlIHBhdGggZmFpbCBvcg0KPiAgICBuZWVkIHRvIGJlIHJlcGxhY2VkLg0KPiANCj4gDQo+IA0K PiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0K From nobody Tue Jul 8 06:31: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 A72A21B2837 for ; Tue, 8 Jul 2014 06:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 hsL3TEf__GJ6 for ; Tue, 8 Jul 2014 06:31:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455671B282B for ; Tue, 8 Jul 2014 06:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19655; q=dns/txt; s=iport; t=1404826284; x=1406035884; h=from:to:cc:subject:date:message-id:mime-version; bh=v4+IcwflSLfH5NsmFzco/N5eAIFDN8kmXVkGX5pKN1g=; b=cJVf6Hf9E1ivHsccgEEyTwPTnktHybAVyIJzCNLSavdz8W7dwzHcViUC KWl0tpJZljMdVkgavMf8qi++H6khUAnaytuNCYjG2nUzA+aT5/QkazRzA Qh7aLuuhM8EGgSn/2+CKmdwLWFKvx50Mf9BfI4Vp8c1vzdy9Aa84zHfxz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFALfxu1OtJV2R/2dsb2JhbABZgkdHUlq9KIkagRYWdYQDAQIELTkCBgEDAgUSAQgRAwECJAQ5FAkKBAENBRSILg3JHReOWTgRhEoFmnaBSJJEggGBQmyBA0E X-IronPort-AV: E=Sophos; i="5.01,625,1400025600"; d="scan'208,217"; a="59117880" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 08 Jul 2014 13:31:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s68DVN3v029365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 13:31:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 08:31:22 -0500 From: "Ken Gray (kegray)" To: ramki Krishnan , "sfc@ietf.org" Thread-Topic: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: AQHPmrDo6CSCRSj9SQmnsz9pyqRybA== Date: Tue, 8 Jul 2014 13:31:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.197] Content-Type: multipart/alternative; boundary="_000_CFE1670C391E0kegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/21aXYGbf1u0vVWFKbFiCoXwEu6s Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 13:31:27 -0000 --_000_CFE1670C391E0kegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey, Ramki. Couple minor nits on my part: First, how is this different than the two years of work that was done in ET= SI NFV (papers, PoCs, gap-analysis, the works)? Assuming the fundamental d= ifference is the word "research", how will the research be "qualified" (uni= que/not-presented-in-another-forum, non-derivative, vendor-agnostic/no-mark= eting-please, etc.)? Second, the wording " input to other related standards efforts in ETSI" =85= brings me back to question one but with a clarification =85 that was a "st= udy group", right =85 so, in that specific example wouldn't this be duplica= tion (where "study" and "research" have a good deal of overlap semantically= )? Finally, as Robert has pointed out, there are areas for overlap that need a= bit of delineation =85and not just in SFC. My example would be the SDNRG = =85how will content distribution be decided between the two (of course SDN = is not NFV, but there is a relationship in some cases/architectures there s= o why not just add this to their charter)? From: ramki Krishnan > Date: Monday, July 7, 2014 4:08 PM To: "sfc@ietf.org" > Cc: "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" >, "dilikris@in.ibm.com" > Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Grou= p (NFVRG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_CFE1670C391E0kegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B0F7900AEA374499DDBCF7A5782C32F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hey, Ramki.

Couple minor nits on my part:

First, how is this different than the two years of work that was done in ET= SI NFV (papers, PoCs, gap-analysis, the works)?  Assuming the fundamen= tal difference is the word "research", how will the research be &= quot;qualified" (unique/not-presented-in-another-forum, non-derivative, vendor-agnostic/no-marketing-please, etc.)?

Second, the wording " input to other related standards efforts in ETSI" =85 brings me back to question= one but with a clarification =85 that was a "study group&qu= ot;, right =85 so, in that specific example wouldn't this be duplicati= on (where "study" and "research" have a good deal of over= lap semantically)?
Fin= ally, as Robert has pointed out, there are areas for overlap that need a bi= t of delineation =85and not just in SFC.  My example would be the SDNRG =85how will content di= stribution be decided between the two (of course SDN is not NFV, but there = is a relationship in some cases/architectures there so why not just add this to their charter)?

From: ramki Krishnan <ramk@Brocade.com>
Date: Monday, July 7, 2014 4:08 PM<= br> To: "sfc@ietf.org" <sfc@ietf.= org>
Cc: "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com= )" <diego.r.lopez@t= elefonica.com>, "dilikri= s@in.ibm.com" <dilikris@in.ibm.com>
Subject: [sfc] Proposed IRTF Networ= k Functions Virtualization Research Group (NFVRG) - first face-to-face meet= ing at Toronto

Overview of prop= osed IRTF Network Functions Virtualization Research Group (NFVRG)

 <= /span>

Network Function Virtualization (NFV) is a key emerg= ing area for network operators, hardware and software vendors, cloud servic= e providers, and in general network practitioners and researchers. This are= a requires exploring new directions and working collaboratively on how to create network services that utilize= a virtualized infrastructure. Network functions that are traditionally imp= lemented in dedicated hardware appliances will need to be decomposed and ex= ecuted in virtual machines running in data centers. One key goal of this new area is to reduce capital and op= erating expenditures for future deployments for networks and associated ser= vices. Another important goal is for the network operators to be able to of= fer value added cloud services to their customers. Finally, new business models will open for the provision = of network services.

The technologies enabling the virtualization of netw= ork functions are currently in an early stage of, and they need researchers= to develop new architectures, systems, and software, and to explore tradeo= ffs and possibilities for leveraging virtualized infrastructure to provide support for network functions. The N= etwork Functions Virtualization Research Group (NFVRG) will bring together = researchers and grow the community around the world in both academia and in= dustry to explore this new research area through workshops, research group meetings etc. at premier conference= s such as IEEE ICC, IEEE Globecom and inviting special issues in well-known= journals. Some of the key topics of research include virtualization of fix= ed and mobile network infrastructures, new network architectures based on virtualized network functions, virtuali= zation of the home and enterprise network environments, co-existence with n= on-virtualized infrastructure and services, and application to growing area= s of concern such as Internet of Things (IoT) and next generation content distribution.

The NFVRG will focus on research problems associated= with these topics and on bringing a research community together that can j= ointly address such problems, concentrating on problems that relate not jus= t to networking but also to computing and storage constraints in such environments. It is also hoped that the ou= tcome of the research will benefit standardization efforts that can get spa= wned via IRTF & IETF BoF meetings and/or provide useful input to other = related standards efforts in ETSI or other standards bodies.

More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg

First face-to-fa= ce Meeting in Toronto

 <= /span>

The first face-to-face meeting of the proposed NFVRG= will be held along with the IETF meeting in Toronto on July 30th Wednesday= from 11:30am to 1:00pm in the Canadian (C) Room (immediately after the SFC= meeting). Please let us know if you have research topics to present during the meeting. Would really appreciat= e active discussions in the mailing list nfvrg@irtf.org.

Thanks,

Ramki on behalf of the NFVRG co-chairs

--_000_CFE1670C391E0kegrayciscocom_-- From nobody Tue Jul 8 07:12: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 4C32C1B2AE5 for ; Tue, 8 Jul 2014 07:12:10 -0700 (PDT) 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 X8eA7LfnALHP for ; Tue, 8 Jul 2014 07:12:06 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55531B2ADE for ; Tue, 8 Jul 2014 07:12:06 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s68EAHu2005660; Tue, 8 Jul 2014 07:12:06 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n040g89e6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 07:12:05 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 07:12:04 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 8 Jul 2014 07:12:04 -0700 From: ramki Krishnan To: "sfc@ietf.org" Date: Tue, 8 Jul 2014 07:12:00 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAl3k9A 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_C7634EB63EFD984A978DFB46EA5174F2C14FDB867EHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_04:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080148 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_TOpzli5tUmJGa8GWuZa1goR9oc Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 14:12:10 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867EHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The face-to-face meeting date is July 23rd and not July 30th. Sorry for the= confusion caused. Thanks, Ramki From: ramki Krishnan Sent: Monday, July 07, 2014 1:09 PM To: sfc@ietf.org Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com Subject: Proposed IRTF Network Functions Virtualization Research Group (NFV= RG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867EHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The face-to-face meeting date is July 23rd and not= July 30th. Sorry for the confusion caused.

 

Thanks,<= /span>

Ramki

 =

From: ramki Krishnan Sent: Monday, July 07, 2014 1:09 PM
To: sfc@ietf.org
<= b>Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ib= m.com
Subject: Proposed IRTF Network Functions Virtualization Res= earch Group (NFVRG) - first face-to-face meeting at Toronto

 

Overview of proposed IRTF Network= Functions Virtualization Research Group (NFVRG)

=

 

Network Function Virtualization (NFV= ) is a key emerging area for network operators, hardware and software vendo= rs, cloud service providers, and in general network practitioners and resea= rchers. This area requires exploring new directions and working collaborati= vely on how to create network services that utilize a virtualized infrastru= cture. Network functions that are traditionally implemented in dedicated ha= rdware appliances will need to be decomposed and executed in virtual machin= es running in data centers. One key goal of this new area is to reduce capi= tal and operating expenditures for future deployments for networks and asso= ciated services. Another important goal is for the network operators to be = able to offer value added cloud services to their customers. Finally, new b= usiness models will open for the provision of network services.<= /p>

 

The techn= ologies enabling the virtualization of network functions are currently in a= n early stage of, and they need researchers to develop new architectures, s= ystems, and software, and to explore tradeoffs and possibilities for levera= ging virtualized infrastructure to provide support for network functions. T= he Network Functions Virtualization Research Group (NFVRG) will bring toget= her researchers and grow the community around the world in both academia an= d industry to explore this new research area through workshops, research gr= oup meetings etc. at premier conferences such as IEEE ICC, IEEE Globecom an= d inviting special issues in well-known journals. Some of the key topics of= research include virtualization of fixed and mobile network infrastructure= s, new network architectures based on virtualized network functions, virtua= lization of the home and enterprise network environments, co-existence with= non-virtualized infrastructure and services, and application to growing ar= eas of concern such as Internet of Things (IoT) and next generation content= distribution.

 

The NFVRG will focus on research problems associated with = these topics and on bringing a research community together that can jointly= address such problems, concentrating on problems that relate not just to n= etworking but also to computing and storage constraints in such environment= s. It is also hoped that the outcome of the research will benefit standardi= zation efforts that can get spawned via IRTF & IETF BoF meetings and/or= provide useful input to other related standards efforts in ETSI or other s= tandards bodies.

 

More details can be found at - http://trac.tools.ietf.org/group/i= rtf/trac/wiki/nfvrg

 

First face-to= -face Meeting in Toronto

<= o:p> 

The first face-to-face meeting of the proposed NFVRG will be = held along with the IETF meeting in Toronto on July 30th Wednesday from 11:= 30am to 1:00pm in the Canadian (C) Room (immediately after the SFC meeting)= . Please let us know if you have research topics to present during the meet= ing. Would really appreciate active discussions in the mailing list nfvrg@irtf.org.

 

Thanks,

Ramki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB867EHQ1EXCH01corp_-- From nobody Tue Jul 8 08:40: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 D1B9D1B2B2C for ; Tue, 8 Jul 2014 08:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 as3poUBsu7Ey for ; Tue, 8 Jul 2014 08:40:27 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE91F1B2B2D for ; Tue, 8 Jul 2014 08:40:26 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA6A5880E8; Tue, 8 Jul 2014 17:40:23 +0200 (CEST) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id BD357880B5; Tue, 8 Jul 2014 17:40:23 +0200 (CEST) Received: from ESTGVMSP221.EUROPE.telefonica.corp ([fe80::79b8:304b:ea62:691d]) by ESTGVMSP103.EUROPE.telefonica.corp ([fe80::fdd5:310c:8725:2a72%11]) with mapi id 14.03.0146.002; Tue, 8 Jul 2014 17:40:23 +0200 From: DIEGO LOPEZ GARCIA To: "Ken Gray (kegray)" Thread-Topic: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: AQHPmrDo6CSCRSj9SQmnsz9pyqRybJuWLvaA Date: Tue, 8 Jul 2014 15:40:23 +0000 Message-ID: <7206447B-AE08-41C4-AB4C-E975979D3DC3@telefonica.com> References: In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.92.4.9] Content-Type: multipart/alternative; boundary="_000_7206447BAE0841C4AB4CE975979D3DC3telefonicacom_" MIME-Version: 1.0 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EqfhLXMdTBJT67LLaGTSm1XSGII Cc: ramki Krishnan , "dilikris@in.ibm.com" , "sfc@ietf.org" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 15:40:30 -0000 --_000_7206447BAE0841C4AB4CE975979D3DC3telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ken, What the ETSI ISG has done was conceived as pre-standardization tasks, no a= ctive research. I'd say the research will be qualified in the same way it i= s done in the other IRTF groups: by the chairs of the group, with the colla= boration of the IRTF chair and the whole community. An ISG in ETSI is an "Industrial Specification Group", not "study", and its= purpose is to produce essentially pre-standardization results (as well as = some normative material in terms of requirements, for example, if agreed by= the group) and not to report research results. Finally, the idea of making it an extension of SDNRG is something we discus= sed, but the SDNRG is already extended enough to accommodate a new item tha= t by itself constitutes a separate approach to networking and hopefully wil= l attract significative attention. For sure there will be boundary cases (w= here aren't they?) and we'll have to coordinate this with the SDNRG chairs. Be goode, On 8 Jul 2014, at 15:31 , Ken Gray (kegray) > wrote: Hey, Ramki. Couple minor nits on my part: First, how is this different than the two years of work that was done in ET= SI NFV (papers, PoCs, gap-analysis, the works)? Assuming the fundamental d= ifference is the word "research", how will the research be "qualified" (uni= que/not-presented-in-another-forum, non-derivative, vendor-agnostic/no-mark= eting-please, etc.)? Second, the wording " input to other related standards efforts in ETSI" =85= brings me back to question one but with a clarification =85 that was a "st= udy group", right =85 so, in that specific example wouldn't this be duplica= tion (where "study" and "research" have a good deal of overlap semantically= )? Finally, as Robert has pointed out, there are areas for overlap that need a= bit of delineation =85and not just in SFC. My example would be the SDNRG = =85how will content distribution be decided between the two (of course SDN = is not NFV, but there is a relationship in some cases/architectures there s= o why not just add this to their charter)? From: ramki Krishnan > Date: Monday, July 7, 2014 4:08 PM To: "sfc@ietf.org" > Cc: "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" >, "dilikris@in.ibm.com" > Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Grou= p (NFVRG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_7206447BAE0841C4AB4CE975979D3DC3telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ken,

What the ETSI ISG has done was conceived as pre-standardization tasks,= no active research. I'd say the research will be qualified in the same way= it is done in the other IRTF groups: by the chairs of the group, with the = collaboration of the IRTF chair and the whole community.

An ISG in ETSI is an "Industrial Specification Group", not &= quot;study", and its purpose is to produce essentially pre-standardiza= tion results (as well as some normative material in terms of requirements, = for example, if agreed by the group) and not to report research results.

Finally, the idea of making it an extension of SDNRG is something we d= iscussed, but the SDNRG is already extended enough to accommodate a new ite= m that by itself constitutes a separate approach to networking and hopefull= y will attract significative attention. For sure there will be boundary cases (where aren't they?) and we'll have = to coordinate this with the SDNRG chairs.

Be goode,

On 8 Jul 2014, at 15:31 , Ken Gray (kegray) <kegray@cisco.com> wrote:

Hey, Ramki.

Couple minor = nits on my part:

First, how is= this different than the two years of work that was done in ETSI NFV (paper= s, PoCs, gap-analysis, the works)?  Assuming the fundamental differenc= e is the word "research", how will the research be "qualified" (unique/not-presented-in-another-forum, = non-derivative, vendor-agnostic/no-marketing-please, etc.)?

Second, the wording " input to other= related standards efforts in ETSI" =85 brings me back to question one but with a clarification =85 that = ;was a "study group", right =85 so, in that specific example= wouldn't this be duplication (where "study" and "research&q= uot; have a good deal of overlap semantically)?

Final= ly, as Robert has pointed out, there are areas for overlap that need a bit = of delineation =85and not just in SFC.  My example would be the SDNRG =85how will content distribut= ion be decided between the two (of course SDN is not NFV, but there is a re= lationship in some cases/architectures there so why not just add this to their charter)?

From: ramki Krishnan <ramk@Brocade.com>=
Date: Monday, July 7, 2014 4:08 PM
To:&= nbsp;"sfc@ietf.org" <sfc@ietf.= org>
Cc:&= nbsp;"DIEGO LOPEZ GARCIA (diego.r= .lopez@telefonica.com)" <diego.r.lopez@t= elefonica.com>, "dilikris@in.ibm.com" <dilikr= is@in.ibm.com>
Subject: [sfc] Proposed IRTF Network Functions Virtualizatio= n Research Group (NFVRG) - first face-to-face meeting at Toronto

Overview of proposed IRTF Network Functio= ns Virtualization Research Group (NFVRG)
 
Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services that utilize a virtualized infrastructur= e. Network functions that are traditionally implemented in dedicated hardwa= re appliances will need to be decomposed and executed in virtual machines r= unning in data centers. One key goal of this new area is to reduce capital and operating expenditures for = future deployments for networks and associated services. Another important = goal is for the network operators to be able to offer value added cloud ser= vices to their customers. Finally, new business models will open for the provision of network services.
The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network functions. The Network Functions Virtualiza= tion Research Group (NFVRG) will bring together researchers and grow the co= mmunity around the world in both academia and industry to explore this new = research area through workshops, research group meetings etc. at premier conferences such as IEEE ICC, IEEE= Globecom and inviting special issues in well-known journals. Some of the k= ey topics of research include virtualization of fixed and mobile network in= frastructures, new network architectures based on virtualized network functions, virtualization of the home and ent= erprise network environments, co-existence with non-virtualized infrastruct= ure and services, and application to growing areas of concern such as Inter= net of Things (IoT) and next generation content distribution.
The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hoped that the outcome of the research wi= ll benefit standardization efforts that can get spawned via IRTF & IETF= BoF meetings and/or provide useful input to other related standards effort= s in ETSI or other standards bodies.
More details can be found at - <= /span>http://trac.tools.ietf.org/g= roup/irtf/trac/wiki/nfvrg
First face-to-face Meeting in Toronto
 
The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would really appreciate active discussions = in the mailing list nfvrg@irtf.org.
Thanks,
Ramki on behalf of the NFVRG co-chairs

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_7206447BAE0841C4AB4CE975979D3DC3telefonicacom_-- From nobody Tue Jul 8 10:49: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 69EF51A040E for ; Tue, 8 Jul 2014 10:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 5fqrOF1V9EDm for ; Tue, 8 Jul 2014 10:49:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2999B1A036D for ; Tue, 8 Jul 2014 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26404; q=dns/txt; s=iport; t=1404841755; x=1406051355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AuC4+J4QBUoaNc6/GOaNpERXZM6nkizfLKqWa7FPeRU=; b=FIQO1g4N1e0RyUQUgxrzSKTgBtZfCt0susjOq7WaW7YshGHz5ScOO8Tu z+uniTcoFFpWT6ShQQDAr8NinsMInIpYfdvJ/ppDpf01+tAKxYgjkq+yN iOCXz/lfqRhXJuvs45SEIcISC7aRa3sRFc9fKwfTMzvvCCqOsHsCq3Zrg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAKEuvFOtJV2Y/2dsb2JhbABZgkdHUlq9LYFeh0EBgRgWdYQDAQEBBGYCBgEDAgUQAgEIEQMBAiEDBAcpCRQJCAIEDgUUiC4NyDMXjmARAQc4EQcGhD0FjHaMGgGBZYFIkkSCAYFCbIEDCBci X-IronPort-AV: E=Sophos; i="5.01,626,1400025600"; d="scan'208,217"; a="59205787" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 08 Jul 2014 17:49:14 +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 s68Hn9U9024403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 17:49:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 12:49:09 -0500 From: "Ken Gray (kegray)" To: DIEGO LOPEZ GARCIA Thread-Topic: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: AQHPmrDo6CSCRSj9SQmnsz9pyqRybJuWLvaAgABWQIA= Date: Tue, 8 Jul 2014 17:49:08 +0000 Message-ID: References: <7206447B-AE08-41C4-AB4C-E975979D3DC3@telefonica.com> In-Reply-To: <7206447B-AE08-41C4-AB4C-E975979D3DC3@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.197] Content-Type: multipart/alternative; boundary="_000_CFE18AF239232kegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1oaeavXSptvIkGuMvJ2Hxh_HpuA Cc: ramki Krishnan , "dilikris@in.ibm.com" , "sfc@ietf.org" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 17:49:18 -0000 --_000_CFE18AF239232kegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hey, Diego, thanks for replying. To be frank, I'm skeptical about the statement that the outputs of the grou= p might be used as inputs to other SDOs, though I admire the optimism. I wonder, if the work isn't unique to the IRTF, then why wouldn't the resea= rcher just plug it directly into other SDOs where it might be applicable wi= thout the IRTF middleman? The proposal accurately states that topics in the NFV space have already be= en broached in other venues (like the IEEE). What I would hope, should thi= s proceed, is that there be some clear research areas defined/sponsored by = the IRTF that are not already being covered elsewhere =85 rather than attra= cting the same work to be presented or repeated in the IRTF. I think the fundamental test of creation should be in the answer to "what w= ill you produce?" and the answer, again =85 IMO, should be "new ideas/findi= ngs". From: DIEGO LOPEZ GARCIA > Date: Tuesday, July 8, 2014 11:40 AM To: Ken Gray > Cc: ramki Krishnan >, "sfc@ietf.o= rg" >, "dilikris@in.= ibm.com" > Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research = Group (NFVRG) - first face-to-face meeting at Toronto Hi Ken, What the ETSI ISG has done was conceived as pre-standardization tasks, no a= ctive research. I'd say the research will be qualified in the same way it i= s done in the other IRTF groups: by the chairs of the group, with the colla= boration of the IRTF chair and the whole community. An ISG in ETSI is an "Industrial Specification Group", not "study", and its= purpose is to produce essentially pre-standardization results (as well as = some normative material in terms of requirements, for example, if agreed by= the group) and not to report research results. Finally, the idea of making it an extension of SDNRG is something we discus= sed, but the SDNRG is already extended enough to accommodate a new item tha= t by itself constitutes a separate approach to networking and hopefully wil= l attract significative attention. For sure there will be boundary cases (w= here aren't they?) and we'll have to coordinate this with the SDNRG chairs. Be goode, On 8 Jul 2014, at 15:31 , Ken Gray (kegray) > wrote: Hey, Ramki. Couple minor nits on my part: First, how is this different than the two years of work that was done in ET= SI NFV (papers, PoCs, gap-analysis, the works)? Assuming the fundamental d= ifference is the word "research", how will the research be "qualified" (uni= que/not-presented-in-another-forum, non-derivative, vendor-agnostic/no-mark= eting-please, etc.)? Second, the wording " input to other related standards efforts in ETSI" =85= brings me back to question one but with a clarification =85 that was a "st= udy group", right =85 so, in that specific example wouldn't this be duplica= tion (where "study" and "research" have a good deal of overlap semantically= )? Finally, as Robert has pointed out, there are areas for overlap that need a= bit of delineation =85and not just in SFC. My example would be the SDNRG = =85how will content distribution be decided between the two (of course SDN = is not NFV, but there is a relationship in some cases/architectures there s= o why not just add this to their charter)? From: ramki Krishnan > Date: Monday, July 7, 2014 4:08 PM To: "sfc@ietf.org" > Cc: "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" >, "dilikris@in.ibm.com" > Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Grou= p (NFVRG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_CFE18AF239232kegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <370E7B6A6857D14794915E4A04B41C9A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hey, Diego, thanks for replying.

To be frank, I'm skeptical about the statement that the outputs of the= group might be used as inputs to other SDOs, though I admire the optimism.=  

I wonder, if the work isn't unique to the IRTF, then why wouldn't the = researcher just plug it directly into other SDOs where it might be applicab= le without the IRTF middleman?

The proposal accurately states that topics in the NFV space have alrea= dy been broached in other venues (like the IEEE).  What I would hope, = should this proceed, is that there be some clear research areas defined/spo= nsored by the IRTF that are not already being covered elsewhere =85 rather than attracting the same work to be pre= sented or repeated in the IRTF.   

I think the fundamental test of creation should be in the answer to &q= uot;what will you produce?" and the answer, again =85 IMO, should be &= quot;new ideas/findings". 


From: DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com&= gt;
Date: Tuesday, July 8, 2014 11:40 A= M
To: Ken Gray <kegray@cisco.com>
Cc: ramki Krishnan <ramk@Brocade.com>, "sfc@ietf.org" <sfc= @ietf.org>, "dilikris@in= .ibm.com" <dilikris@in.ibm.com>
Subject: Re: [sfc] Proposed IRTF Ne= twork Functions Virtualization Research Group (NFVRG) - first face-to-face = meeting at Toronto

Hi Ken,

What the ETSI ISG has done was conceived as pre-standardization tasks,= no active research. I'd say the research will be qualified in the same way= it is done in the other IRTF groups: by the chairs of the group, with the = collaboration of the IRTF chair and the whole community.

An ISG in ETSI is an "Industrial Specification Group", not &= quot;study", and its purpose is to produce essentially pre-standardiza= tion results (as well as some normative material in terms of requirements, = for example, if agreed by the group) and not to report research results.

Finally, the idea of making it an extension of SDNRG is something we d= iscussed, but the SDNRG is already extended enough to accommodate a new ite= m that by itself constitutes a separate approach to networking and hopefull= y will attract significative attention. For sure there will be boundary cases (where aren't they?) and we'll have = to coordinate this with the SDNRG chairs.

Be goode,

On 8 Jul 2014, at 15:31 , Ken Gray (kegray) <kegray@cisco.com> wrote:

Hey, Ramki.

Couple minor = nits on my part:

First, how is= this different than the two years of work that was done in ETSI NFV (paper= s, PoCs, gap-analysis, the works)?  Assuming the fundamental differenc= e is the word "research", how will the research be "qualified" (unique/not-presented-in-another-forum, = non-derivative, vendor-agnostic/no-marketing-please, etc.)?

Second, the wording " inpu= t to other related standards efforts in ETSI" =85 brings me back to question one but with a clarification =85 that = ;was a "study group", right =85 so, in that specific example= wouldn't this be duplication (where "study" and "research&q= uot; have a good deal of overlap semantically)?

Final= ly, as Robert has pointed out, there are areas for overlap that need a bit = of delineation =85and not just in SFC.  My example would be the SDNRG =85how will content distribut= ion be decided between the two (of course SDN is not NFV, but there is a re= lationship in some cases/architectures there so why not just add this to their charter)?

From: ramki Krishnan <ramk@Brocade.com>=
Date: Monday, July 7, 2014 4:08 PM
To:&= nbsp;"sfc@ietf.org" <sfc@ietf.= org>
Cc:&= nbsp;"DIEGO LOPEZ GARCIA (diego.r= .lopez@telefonica.com)" <diego.r.lopez@t= elefonica.com>, "dilikris@in.ibm.com" <dilikr= is@in.ibm.com>
Subject: [sfc] Proposed IRTF Network Functions Virtualizatio= n Research Group (NFVRG) - first face-to-face meeting at Toronto

Overview of proposed IRTF Network Functio= ns Virtualization Research Group (NFVRG)
 
Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services that utilize a virtualized infrastructur= e. Network functions that are traditionally implemented in dedicated hardwa= re appliances will need to be decomposed and executed in virtual machines r= unning in data centers. One key goal of this new area is to reduce capital and operating expenditures for = future deployments for networks and associated services. Another important = goal is for the network operators to be able to offer value added cloud ser= vices to their customers. Finally, new business models will open for the provision of network services.
The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network functions. The Network Functions Virtualiza= tion Research Group (NFVRG) will bring together researchers and grow the co= mmunity around the world in both academia and industry to explore this new = research area through workshops, research group meetings etc. at premier conferences such as IEEE ICC, IEEE= Globecom and inviting special issues in well-known journals. Some of the k= ey topics of research include virtualization of fixed and mobile network in= frastructures, new network architectures based on virtualized network functions, virtualization of the home and ent= erprise network environments, co-existence with non-virtualized infrastruct= ure and services, and application to growing areas of concern such as Inter= net of Things (IoT) and next generation content distribution.
The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hoped that the outcome of the research wi= ll benefit standardization efforts that can get spawned via IRTF & IETF= BoF meetings and/or provide useful input to other related standards effort= s in ETSI or other standards bodies.
More details can be found at - <= /span>http://trac.tools.ietf.org/g= roup/irtf/trac/wiki/nfvrg
First face-to-face Meeting in Toronto
 
The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would really appreciate active discussions = in the mailing list nfvrg@irtf.org.
Thanks,
Ramki on behalf of the NFVRG co-chairs

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_CFE18AF239232kegrayciscocom_-- From nobody Tue Jul 8 12:37: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 CB8BC1A05CB for ; Tue, 8 Jul 2014 12:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 tPD_Xr7S6ShX for ; Tue, 8 Jul 2014 12:37:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779841A0305 for ; Tue, 8 Jul 2014 12:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4380; q=dns/txt; s=iport; t=1404848246; x=1406057846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pzeUcEhuXXnE4IvqnjZlqjTZodXdpkPB7gN8IoJEjqM=; b=fzw/LSfEUTByLVEwkB8f3Um9AT0zqKm6gNTlDaNG1+XOUZ+5L2IQjuEz yXCDQ3P8ta7cV4k2o+Gpq1NIm6fGxkwfuOEe2GUeI2RyBebGTtRwk6w54 b7en9vmBZI+3S6ZKF0YisZEZXnSH0TU7fsTgCshMRNjA9ZdVHGQF/fp8k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACtIvFOtJV2Z/2dsb2JhbABZgw6BLMZNAYEYFnWEAwEBAQMBcgcFCwIBCBI0MhcOAgQOBRSIJgjIERePDzMHgy2BFgEEmnaUDINDgjA X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="59227409" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 08 Jul 2014 19:37:25 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s68JbO3F016127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 19:37:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 14:37:24 -0500 From: "Paul Quinn (paulq)" To: Jiangyuanlong Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmY2GzMEM1YrUSzZ89YzxwzcZuV7o8AgAEMEAA= Date: Tue, 8 Jul 2014 19:37:24 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BD67@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BD67@szxema506-mbs.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.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pdldV-MGPk3ZfzzzyBIYOmKV5Bk Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 19:37:26 -0000 Hi, Thank you for your comments, please see inline. On Jul 7, 2014, at 11:38 PM, Jiangyuanlong wrote= : > Hi Thomas and all, >=20 > After a review of draft-ietf-sfc-problem-statement-07, I have the followi= ng comments and suggestions: >=20 > 1. The definition of "Classification" does not parse to me, it says: > " Classification: Locally instantiated policy that results in matching > of traffic flows for identification of appropriate outbound > forwarding actions." > Classification seems to be defined as a kind of policy, but it is not. > It is suggested to be defined as: > " Classification: Identification of traffic flows based on locally=20 > instantiated policy for appropriate outbound forwarding actions.=94 PQ> I don=92t think this improves the definition. Unless there=92s consen= sus from the community, this doesn=92t need to change. >=20 > 2. "Network Overlay" is defined but not used at all in the contexts - exc= ept in Section "Related IETF Work", however, the definition of "Service Ove= rlay" introduces a new terminology "overlay network": =20 > " Service Overlay: An overlay network created for the purpose of > forwarding data along a service function path. " > Is this "overlay network" actually a typo of "network overlay=94?=20 PQ> We use the term overlay network appropriately here. The service overl= ay is an overlay network. =20 >=20 > 3. "Service Function Path" is defined as: > " Service Function Path (SFP): The instantiation of a service function > chain in the network. Packets follow a service function path from > a classifier through the required instances of service functions > in the network." > SFP seems to be instantiation of an SFC, that is very confusing. Maybe it= will be more concrete to be repharased as: =20 > " Service Function Path (SFP): A path for packet forwarding constructed= =20 > from a classifier through the required instances of service function= s=20 > after the instantiation of a service function chain in the network.= =94 PQ> Thank you for this comment, the original defn explains a key concept w= hich is the relationship to an SFC; your suggested text makes that less cle= ar. >=20 > 4. In Section 2.10, the title is "Per-Service (re)Classification", but it= actually discusses per-service-function (re)classification. > Therefore, it is suggested: > s/Per-Service/Per-Service-Function/ > s/per-service/per-service-function/ >=20 PQ> Will update. > 5. In Section 3.2, it says: > "Symmetric classification ensures that forward and reverse chains are in = place." > But what is "Symmetric classification"? What does it mean by "in place=94= ? Symmetric classification involves the use of classification criteria that r= eflect the =93forward=94 and =93reverse=94 traffic. For example: src a =97= > dst b and src b =97> dst a. =20 >=20 > 6. In Section 3.3, it says: > "...As such metadata is not used as forwarding information to deliver pac= kets=20 > along the service overlay." > It is strange to have such a negative phrase here. From the definition of= "service overlay" and the contexts, it is unclear who will forward the pac= ket, and what forwarding information is realy needed, therefore, it is too = early to make such a statement, and it should be rightfully considered in a= n architecture draft IMHO. PQ> We bound the problem to not include forwarding based on metadata. Thu= s far the consensus is that this makes sense. >=20 > 7. In Section 3.3, it says: > " ... Service functions utilize > metadata, as required, for localized policy decisions." > Is "localized policy decisions" the only valid thing for metadata to be= used? Or is it just an example? >=20 PQ> This is an example. >=20 > Other minor editorial proposals: > s/real or virtualized/physical or virtualized/ =20 > s/fearing misconfiguration and downtime/for fear of misconfiguration and = consequent downtime/=20 > s/inter- vendor/inter-vendor/ > s/decoupling of policy from the topology/decoupling of policy from the ne= twork topology/ (BTW, we only defined service topology in the document) >=20 PQ> Those edits will be reflected in the draft. Thanks again, Paul = From nobody Tue Jul 8 13:31: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 E17331A0045 for ; Tue, 8 Jul 2014 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtF0Pd-1cZsV for ; Tue, 8 Jul 2014 13:30:53 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06FB1A0026 for ; Tue, 8 Jul 2014 13:30:52 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 151D6880CB; Tue, 8 Jul 2014 22:30:50 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id ED5C2880BB; Tue, 8 Jul 2014 22:30:49 +0200 (CEST) Received: from ESTGVMSP221.EUROPE.telefonica.corp ([fe80::79b8:304b:ea62:691d]) by ESTGVMSP108.EUROPE.telefonica.corp ([fe80::49d3:7c99:c221:b2a5%11]) with mapi id 14.03.0146.002; Tue, 8 Jul 2014 22:30:49 +0200 From: DIEGO LOPEZ GARCIA To: "Ken Gray (kegray)" Thread-Topic: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: AQHPmrDo6CSCRSj9SQmnsz9pyqRybJuWLvaAgABWQID///riAA== Date: Tue, 8 Jul 2014 20:30:49 +0000 Message-ID: <7BCED61F-8273-4BAA-A73B-9C5086353611@telefonica.com> References: <7206447B-AE08-41C4-AB4C-E975979D3DC3@telefonica.com> In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.92.4.9] Content-Type: multipart/alternative; boundary="_000_7BCED61F82734BAAA73B9C5086353611telefonicacom_" MIME-Version: 1.0 X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HZnF8L1p6weVCRME3qjhhJ8ISZM Cc: ramki Krishnan , "dilikris@in.ibm.com" , "sfc@ietf.org" Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 20:31:00 -0000 --_000_7BCED61F82734BAAA73B9C5086353611telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ken, I can assure you that at least for the NFV ISG the results will be used: th= e dynamic of that group would welcome the results of the group. And I do ho= pe some of IETF WGs will do as well. The rest of your concerns is applicable to any other hot topic. You name it= , but probably SDN would be the archetypal example. The only we can commit = is to our best to encourage the production of new ideas and findings. Be goode, On 8 Jul 2014, at 19:49 , Ken Gray (kegray) > wrote: Hey, Diego, thanks for replying. To be frank, I'm skeptical about the statement that the outputs of the grou= p might be used as inputs to other SDOs, though I admire the optimism. I wonder, if the work isn't unique to the IRTF, then why wouldn't the resea= rcher just plug it directly into other SDOs where it might be applicable wi= thout the IRTF middleman? The proposal accurately states that topics in the NFV space have already be= en broached in other venues (like the IEEE). What I would hope, should thi= s proceed, is that there be some clear research areas defined/sponsored by = the IRTF that are not already being covered elsewhere =85 rather than attra= cting the same work to be presented or repeated in the IRTF. I think the fundamental test of creation should be in the answer to "what w= ill you produce?" and the answer, again =85 IMO, should be "new ideas/findi= ngs". From: DIEGO LOPEZ GARCIA > Date: Tuesday, July 8, 2014 11:40 AM To: Ken Gray > Cc: ramki Krishnan >, "sfc@ietf.o= rg" >, "dilikris@in.= ibm.com" > Subject: Re: [sfc] Proposed IRTF Network Functions Virtualization Research = Group (NFVRG) - first face-to-face meeting at Toronto Hi Ken, What the ETSI ISG has done was conceived as pre-standardization tasks, no a= ctive research. I'd say the research will be qualified in the same way it i= s done in the other IRTF groups: by the chairs of the group, with the colla= boration of the IRTF chair and the whole community. An ISG in ETSI is an "Industrial Specification Group", not "study", and its= purpose is to produce essentially pre-standardization results (as well as = some normative material in terms of requirements, for example, if agreed by= the group) and not to report research results. Finally, the idea of making it an extension of SDNRG is something we discus= sed, but the SDNRG is already extended enough to accommodate a new item tha= t by itself constitutes a separate approach to networking and hopefully wil= l attract significative attention. For sure there will be boundary cases (w= here aren't they?) and we'll have to coordinate this with the SDNRG chairs. Be goode, On 8 Jul 2014, at 15:31 , Ken Gray (kegray) > wrote: Hey, Ramki. Couple minor nits on my part: First, how is this different than the two years of work that was done in ET= SI NFV (papers, PoCs, gap-analysis, the works)? Assuming the fundamental d= ifference is the word "research", how will the research be "qualified" (uni= que/not-presented-in-another-forum, non-derivative, vendor-agnostic/no-mark= eting-please, etc.)? Second, the wording " input to other related standards efforts in ETSI" =85= brings me back to question one but with a clarification =85 that was a "st= udy group", right =85 so, in that specific example wouldn't this be duplica= tion (where "study" and "research" have a good deal of overlap semantically= )? Finally, as Robert has pointed out, there are areas for overlap that need a= bit of delineation =85and not just in SFC. My example would be the SDNRG = =85how will content distribution be decided between the two (of course SDN = is not NFV, but there is a relationship in some cases/architectures there s= o why not just add this to their charter)? From: ramki Krishnan > Date: Monday, July 7, 2014 4:08 PM To: "sfc@ietf.org" > Cc: "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" >, "dilikris@in.ibm.com" > Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Grou= p (NFVRG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_7BCED61F82734BAAA73B9C5086353611telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <47E37B0D6577FB4D8F0C9AA3313F0721@telefonica.com> Content-Transfer-Encoding: quoted-printable Hi Ken,

I can assure you that at least for the NFV ISG the results will be use= d: the dynamic of that group would welcome the results of the group. And I = do hope some of IETF WGs will do as well.

The rest of your concerns is applicable to any other hot topic. You na= me it, but probably SDN would be the archetypal example. The only we can co= mmit is to our best to encourage the production of new ideas and findings.<= /div>

Be goode,


On 8 Jul 2014, at 19:49 , Ken Gray (kegray) <kegray@cisco.com> wrote:

Hey, Diego, thanks for replying.

To be frank, I'm skeptical about the statement that the outputs of the= group might be used as inputs to other SDOs, though I admire the optimism.=  

I wonder, if the work isn't unique to the IRTF, then why wouldn't the = researcher just plug it directly into other SDOs where it might be applicab= le without the IRTF middleman?

The proposal accurately states that topics in the NFV space have alrea= dy been broached in other venues (like the IEEE).  What I would hope, = should this proceed, is that there be some clear research areas defined/spo= nsored by the IRTF that are not already being covered elsewhere =85 rather than attracting the same work to be pre= sented or repeated in the IRTF.   

I think the fundamental test of creation should be in the answer to &q= uot;what will you produce?" and the answer, again =85 IMO, should be &= quot;new ideas/findings". 


From: DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com&= gt;
Date: Tuesday, July 8, 2014 11:40 A= M
To: Ken Gray <kegray@cisco.com>
Cc: ramki Krishnan <ramk@Brocade.com>, "sfc@ietf.org" <sfc= @ietf.org>, "dilikris@in= .ibm.com" <dilikris@in.ibm.com>
Subject: Re: [sfc] Proposed IRTF Ne= twork Functions Virtualization Research Group (NFVRG) - first face-to-face = meeting at Toronto

Hi Ken,

What the ETSI ISG has done was conceived as pre-standardization tasks,= no active research. I'd say the research will be qualified in the same way= it is done in the other IRTF groups: by the chairs of the group, with the = collaboration of the IRTF chair and the whole community.

An ISG in ETSI is an "Industrial Specification Group", not &= quot;study", and its purpose is to produce essentially pre-standardiza= tion results (as well as some normative material in terms of requirements, = for example, if agreed by the group) and not to report research results.

Finally, the idea of making it an extension of SDNRG is something we d= iscussed, but the SDNRG is already extended enough to accommodate a new ite= m that by itself constitutes a separate approach to networking and hopefull= y will attract significative attention. For sure there will be boundary cases (where aren't they?) and we'll have = to coordinate this with the SDNRG chairs.

Be goode,

On 8 Jul 2014, at 15:31 , Ken Gray (kegray) <kegray@cisco.com> wrote:

Hey, Ramki.

Couple minor = nits on my part:

First, how is= this different than the two years of work that was done in ETSI NFV (paper= s, PoCs, gap-analysis, the works)?  Assuming the fundamental differenc= e is the word "research", how will the research be "qualified" (unique/not-presented-in-another-forum, = non-derivative, vendor-agnostic/no-marketing-please, etc.)?

Second, the wording " input to other= related standards efforts in ETSI" =85 brings me back to question one but with a clarification =85 that = ;was a "study group", right =85 so, in that specific example= wouldn't this be duplication (where "study" and "research&q= uot; have a good deal of overlap semantically)?

Final= ly, as Robert has pointed out, there are areas for overlap that need a bit = of delineation =85and not just in SFC.  My example would be the SDNRG =85how will content distribut= ion be decided between the two (of course SDN is not NFV, but there is a re= lationship in some cases/architectures there so why not just add this to their charter)?

From: ramki Krishnan <ramk@Brocade.com>=
Date: Monday, July 7, 2014 4:08 PM
To:&= nbsp;"sfc@ietf.org" <sfc@ietf.= org>
Cc:&= nbsp;"DIEGO LOPEZ GARCIA (diego.r= .lopez@telefonica.com)" <diego.r.lopez@t= elefonica.com>, "dilikris@in.ibm.com" <dilikr= is@in.ibm.com>
Subject: [sfc] Proposed IRTF Network Functions Virtualizatio= n Research Group (NFVRG) - first face-to-face meeting at Toronto

Overview of proposed IRTF Network Functio= ns Virtualization Research Group (NFVRG)
 
Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services that utilize a virtualized infrastructur= e. Network functions that are traditionally implemented in dedicated hardwa= re appliances will need to be decomposed and executed in virtual machines r= unning in data centers. One key goal of this new area is to reduce capital and operating expenditures for = future deployments for networks and associated services. Another important = goal is for the network operators to be able to offer value added cloud ser= vices to their customers. Finally, new business models will open for the provision of network services.
The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network functions. The Network Functions Virtualiza= tion Research Group (NFVRG) will bring together researchers and grow the co= mmunity around the world in both academia and industry to explore this new = research area through workshops, research group meetings etc. at premier conferences such as IEEE ICC, IEEE= Globecom and inviting special issues in well-known journals. Some of the k= ey topics of research include virtualization of fixed and mobile network in= frastructures, new network architectures based on virtualized network functions, virtualization of the home and ent= erprise network environments, co-existence with non-virtualized infrastruct= ure and services, and application to growing areas of concern such as Inter= net of Things (IoT) and next generation content distribution.
The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hoped that the outcome of the research wi= ll benefit standardization efforts that can get spawned via IRTF & IETF= BoF meetings and/or provide useful input to other related standards effort= s in ETSI or other standards bodies.
More details can be found at - <= /span>http://trac.tools.ietf.org/g= roup/irtf/trac/wiki/nfvrg
First face-to-face Meeting in Toronto
 
The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would really appreciate active discussions = in the mailing list nfvrg@irtf.org.
Thanks,
Ramki on behalf of the NFVRG co-chairs

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_7BCED61F82734BAAA73B9C5086353611telefonicacom_-- From nobody Tue Jul 8 15: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 D230F1A015F for ; Tue, 8 Jul 2014 15:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 e9EG48R6Py0E for ; Tue, 8 Jul 2014 15:33:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF241A0151 for ; Tue, 8 Jul 2014 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6934; q=dns/txt; s=iport; t=1404858791; x=1406068391; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UKVx2akm0mgGm/7eYWr+X6M5pZxrgiJd0zkNIsUeQzE=; b=HDgzDtwOUXXfRs/iJuNCJDNWAOSuwX3IGXp4AWEw12eUD+poFhFiQNHV 97kDMMJsc6l5SvpbKnrzWlwGClXFFk9OvetqSEnRivCGkFuUua+Z3irsX SQyyfd+Zh9kurCpNzl1qhgaDJw0ezMyrKUUJdis2vSrXSp1dapQbDNhJ8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAPZwvFOtJA2M/2dsb2JhbABagw5SWr8mCoc/gRMWdYQDAQEBBAEBAQtXCQkOBgEIEQQBASguCxQIAQoEARIJEognDcZtF45fCwEkQIQ9BZZchBqBSJJEggGBQoFuAQEeBhw X-IronPort-AV: E=Sophos;i="5.01,628,1400025600"; d="scan'208";a="338625819" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2014 22:33:10 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68MXAuG022925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 22:33:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 17:33:09 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPmvyXNnB3Xo9JN0+E/lYgsNPsdw== Date: Tue, 8 Jul 2014 22:33:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.50] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7A789183717B1341B395A5BF867E75BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eYTbUz-GremT7EHCx0XBBrBMauE Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-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, 08 Jul 2014 22:33:14 -0000 Hi, guys. I found the document a little confusing (could be me). I think you're trying to describe elasticity, but I don't think it connects well. A comment fairly common for the flurry of drafts that just came out =8A you= r SFIC is a new item not in any of the main documents. If we're to expand our lexicon even for local discussion, I think the term Component is unnecessary. Instance is fine. In the definition and throughout the document, I think you mix simple elasticity and the function of a load_balancer/ADC (an SFF with non-publicly visible instances behind it) with directly addressable instances of the same function as well as overlook anycast IP for stateless functions. So, your scenarios need to be much more explicit, IMO, so they can be validated. In section 4.1 the scenario described in "It is also possible to have multiple identical SFICs attached to one Service Function Forwarder (SFF) node, especially in a Network Function Virtualization (NFV) environment where each SFIC is a virtual service function instance with limited capacity." seems unlikely to me. It seems that it would be more likely that solution to the problem described would be to spawn the SFC with more resources instead of more instances UNLESS you are getting down to the ultimate resource limit of bandwidth out of a NIC (10G limit) in which case you would probably drop back to a load balancing scenario? A minor nit to the section " At the functional level, the order of service functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which SFIC of the Service Function "s1" is selected for the Chain #1 is not." If it's a stateful function, it probably does matter. On " The benefit of encoding the exact path in every data packet is less contention when there the Service Chain Instance Path changes.", I would have to say that the benefits I see in encoding the path are that the traversed path is captured in the flow for debugging and other use and you are passing metadata along with it (optionally). I don't see how the path encoding helps with contention if the path changes. Can you explain what you mean by contention and how this mitigates? On " However, there are major drawbacks, such as - extra packet header fields are needed to carry the exact instance path, that can increase the likelihood of packet fragmentation due to MTU size, and - extra encapsulation processing load at the head end Service Chain classifier node.", I'D venture that this is a bit speculative and perhaps temporal (limited to some scenarios and the capabilities of existing hardware). We have endured header expansion and encapsulation changes before, what makes this one so hard to cope with in the long term or are you only talking about short term (in which case, is it major)? For " Packet fragmentation and reassembly is very processor and memory intensive. Good practice is to avoid packet fragmentation and reassembly as much as possible. Carry an exact instance path in every packet might be possible if service function instances can be represented by compact labels, similar to the MPLS label stack.", I think our our IPv6 brethren might find that a parochial view. Generally, for most of section 4, it seems to me that the problems described are essentially handled by elasticity controls, and abstraction (e.g. anycast IP or a load balance function). The entities are normally managed (open source tools are available) in a feedback loop =8A in short, this is a very addressable and well known problem with existing products and methodologies to mitigate, are you suggesting a unique solution or the general scenario of how elasticity works =8A if the latter, I think you nee= d to make that clear? Section 5 displays the amount of detail that these simple abstractions should actually hide from classification and that we made explicit example of in earlier documents (these things shouldn't cause an explosion in the number of discrete service chains). That is kind of amplified in the earlier text " If each Service Function has a large number of SFICs, it scales better if the Service Chain classifier only identifies the service chain at the functional level, and there is another entity managing the detailed service instance path." Can you explain this in more depth? This is where I think you're actually trying to describe what we discussed as "should be avoided and unnecessary" =8Athat is the explosion of paths in the face of elasticity. Section 6, Are you talking about discretely addressable functions or non? If non, and the SFF is responsible for "distribution", the numbering of the instances is really irrelevant and is again a back end elasticity function known only to the SFF =8A and, to me, it's really unlikely that yo= u would track or move a discrete element from behind one SFF that provides such a distribution function to another and still consider it the same element. Rather, it is "one of many". On 7/4/14 4:48 PM, "Linda Dunbar" wrote: >Hi,=20 > >This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > >Appreciate to hear your comments or suggestions. > >Linda & Andy > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Wednesday, April 30, 2014 11:25 AM >To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >Subject: New Version Notification for >draft-dunbar-sfc-fun-instances-restoration-00.txt > > >A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt >has been successfully submitted by Linda Dunbar and posted to the IETF >repository. > >Name: draft-dunbar-sfc-fun-instances-restoration >Revision: 00 >Title: Framework for Service Function Instances Restoration >Document date: 2014-04-29 >Group: Individual Submission >Pages: 12 >URL: =20 >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-restora >tion-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restoratio >n/ >Htmlized: =20 >http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00 > > >Abstract: > This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 8 18:28: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 A6E381A01E8; Tue, 8 Jul 2014 18:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 6U2Jd5AeAQnb; Tue, 8 Jul 2014 18:28:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EC01A01E5; Tue, 8 Jul 2014 18:28:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT65169; Wed, 09 Jul 2014 01:27:58 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 02:27:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 09:27:52 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QABY9lIA= Date: Wed, 9 Jul 2014 01:27:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xyLdGbmPfaapqFUChBWl9wWnQY0 Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "'sfc@ietf.org'" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] YANG models for OAM X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 01:28:12 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhOg0KSSBkb26hr3QgdGhpbmsgdGhlIGlkZWEgeW91IHByb3Bvc2VkIGhhdmUgYW55 IGluY29uc2lzdGVuY3kgd2l0aCB3aGF0IHdlIGFyZSBwcm9wb3NpbmcgaW4gZHJhZnQtd3ctb3Bz YXdnLW11bHRpLWxheWVyLW9hbS0wMi4gQnV0IGxvb2tzIGxpa2Ugd2UgYXJlIGRlYmF0aW5nIHNv bWV0aGluZyw6KQ0KWW91IGFuZCB1cyBhcmUgYm90aCBsb29raW5nIGZvciBPQU0gY29uc29saWRh dGlvbiBpbiB0aGUgbWFuYWdlbWVudCwgaW4gYWRkaXRpb24sIHdlIGFyZSBsb29raW5nIGZvciBP QU0gY29uc29saWRhdGlvbiBpbiB0aGUgZGF0YSBwbGFuZS4NClBsZWFzZSBzZWUgbXkgcmVwbHkg aW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBUaXNzYSBTZW5ldmlyYXRo bmUgKHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0 xOo31MI4yNUgMjI6NDgNCsrVvP7IyzogUWluIFd1OyB0aW1lQGlldGYub3JnDQqzrcvNOiBuZXRt b2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRmLm9y Zzsgb3BzYXdnQGlldGYub3JnDQrW98ziOiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSBR aW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUuDQoNCg0KMS4gICAgICAgVGhvdWdo dCBTRkMgY2FuIGdvIHVwIGFuZCBkb3duIG9uIGxheWVycywgd2hhdCBjb250cm9scyB0aGF0IGJl aGF2aW9yID8gSXOhr250IGl0IHRoZSBTZXJ2aWNlIGhlYWRlciA/DQpbUWluXTogSXQgaXMgcG9z c2libGUsIGJ1dCB3aG8gY29udHJvbCB0aGF0IGJlaGF2aW9yLCBpdCBpcyB0aGUgbWFuYWdlbWVu dCBwbGFuZSwgdGhlIG1hbmFnZW1lbnQgcGxhbmUgbmVlZCB0byBpbnRlcmFjdCB3aXRoIGRpZmZl cmVudCBsYXllciBPQU0gaW4gdGhlIGRhdGEgcGxhbmUgb3INCk1hbmFnZW1lbnQgcGxhbmUgbmVl ZCB0byBpbnRlcmFjdCB3aXRoIE9BTSBwcm90b2NvbCB0aGF0IGlzIGRlZmluZWQgZm9yIFNGQyBh dCB0aGUgdG9wIG9mIGxheWVyIDMuDQoNCg0KMi4gICAgICAgSXMgdGhlIE9BTSBjb21lcyBkb3du IHRvIGZhdWx0IGlzb2xhdGlvbiwgdmVyaWZpY2F0aW9uICwgbW9uaXRvcmluZyBldGMgZm9yIHRo ZSBzcGVjaWZpZWQgU0ggPw0KW1Fpbl06IE5vdCBjbGVhciB3aGV0aGVyIFNIIGlzIHRoZSBvbmx5 IGFwcHJvYWNoLiBPQU0gaW5mb3JtYXRpb24gY2FuIGJlIHB1dCBpbnRvIEJERiBwcm90b2NvbCBv ciBHZW5lcmljIFRMViBhcyB3ZWxsLg0KDQpMaWtlIGRpc2N1c3NlZCBiZWZvcmUgKG1hbnkgdGlt ZXMpIGV4YWN0IGVuLWNhcCBpcyBsZXNzIGltcG9ydGFudCB3aGF0IGlzIGltcG9ydGFudCBpcyB0 byBoYXZlIGEgbW9kZWwgdGhhdCBkZWZpbmUgT0FNIGZyYW1ld29yayBhbmQgc2NvcGUuIENGTSB0 byBteSBvcGluaW9uIGRvIGFuIGV4Y2VsbGVudCBqb2IgaW4gZGVmaW5pbmcgd2hhdCBpcyBuZWVk ZWQuIEhlbmNlIHRoZSBjaG9pY2Ugb2YgYSBzaW1pbGFyIG1vZGVsIGZvciB0aGUgWUFORyBNb2Rl bC4NCg0KW1Fpbl06IFdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLCBidXQgaXNuoa90IG1vcmUgc3Ry YWlnaHRmb3J3YXJkIGFuZCByZWFzb25hYmxlIHRvIGRlZmluZSBHZW5lcmljIE9BTSBmcmFtZXdv cmsgc2VwYXJhdGVkIGZyb20gWWFuZyBEYXRhIG1vZGVsIGZvciBHZW5lcmljIE9BTS4NClRoYXSh r3Mgd2hhdCB3ZSBsaWtlIHRvIHByb3Bvc2UgaW4gdGhlIGRyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1s YXllci1vYW0tMDIuIERldmVsb3Bpbmcgc2VwYXJhdGUgQXJjaGl0ZWN0dXJlIGFuZCBGcmFtZXdv cmsgZnJvbSBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIFByb2JsZW0gc3RhdGVtZW50IGRyYWZ0 Lg0KR2VuZXJpYyBPQU0gZnJhbWV3b3JrIHNob3VsZCBhbHNvIGFsbG93IG1vcmUgaW50ZXJhY3Rp b24gYmV0d2VlbiBkYXRhIHBsYW5lIGFuZCBtYW5hZ2VtZW50IHBsYW5lIGFuZCBtb3JlIGludGVy d29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBsYXllciBPQU0gcHJvdG9jb2wuDQoNCllvdSBoYXZl IG5vdGVkIEJGRCBhbmQgQ0ZNIGFyZSBzaW1pbGFyIGJlY2F1c2UgdGhleSBoYXZlIHNpbWlsYXIg c2V0IG9mIHRpbWVycy4gVGhhdCBpcyBhIHdyb25nIGNvbXBhcmlzb24uIEhhdmUgc2ltaWxhciBz ZXQgb2YgdGltZXJzIGRvZXMgbm90IG1ha2UgdHdvIHByb3RvY29scyB0aGUgc2FtZS4NCg0KW1Fp bl06IFRoYXShr3Mgbm90IHdoYXQgd2UgYXJlIHByb3Bvc2luZywgd2UgaG9wZSBpbiB0aGUgbWFu YWdlbWVudCBwbGFuZSB0aGVyZSBpcyBzb21lIGNvbW1vbiBjb21wb25lbnRzIG9yIGVsZW1lbnRz IHRoYXQgY2FuIGJlIHVzZWQgYnkgbm90IG9ubHkgQkZELCBidXQgYWxzbyBDRk0uDQoNCldoYXQg bWFrZXMgdGhlbSBpcyB3aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQg a2V5IHdvcmQgQ0ZNIGhlcmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNl cHRzIGZvcm0gQ0ZNIHRoZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVk Lg0KDQpJIGhhdmUgcmVxdWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRN T0Qgd29ya2luZyBncm91cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhv dyBlYWNoIG9uZSBvZiB0aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRl ZCBoZXJlLg0KDQpbUWluXTogVGhhdCB3b3VsZCBiZSBhIHZlcnkgZ29vZCBzdXJ2ZXksIGluIG15 IG9waW5pb24sIGJlZm9yZSBnb2luZyB0aGVyZSwgaXNuoa90IG1vcmUgbmljZSB0byBoYXZlIGEg Z2FwIGFuYWx5c2lzIGRvY3VtZW50IHRvDQphIC5JZGVudGlmeSB0ZWNobm9sb2d5IGRlcGVuZGVu dCBhbmQgaW5kZXBlbmRlbnQgY29tcG9uZW50DQpiLiAgYW5hbHl6ZSBhbmQgdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW50IG1vdGl2YXRpb25zIGFuZCBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWlzYXRp b24gb2YgT0FNIGluIGRpZmZlcmVudCB0ZWNobm9sb2d5IG5ldHdvcmtzLA0KYW5kIHRoZSB0cmFk ZS1vZmZzIGJldHdlZW4gdGhvc2Ugb3B0aW1pc2F0aW9ucyBhbmQgdGhlIG92ZXJhbGwgYWR2YW50 YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpGcm9tOiBRaW4gV3UgW21haWx0bzpi aWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDU6MDcgQU0N ClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGltZUBpZXRmLm9yZzxtYWlsdG86 dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxt YWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRoZXJlIGFyZSBtYW55IG9wdGlv bnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMgSGVhZGVyIGV4dGVuc2lvbiwg R2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4aXN0aW5nIE9BTSBwcm90b2Nv bHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBhZGRyZXNzIE9BTSBmb3IgdGhl IHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZDIGhhdmVuoa90IGRldmVsb3Bl ZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIgMy4NCg0KQmVmb3JlIHRoZXkg ZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIg dGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRlbnQgT0FNIHByb3RvY29sLA0K T3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wgc2luY2UgU0ZDIE9BTSBhbmQg T3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVzKGUuZy4sIGJvdGggY2FuIHVz ZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9mIG92ZXJsYXkgbm9kZSBvciBz ZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRoKS4gV2h5IG5vdCBidWlsZCBv bmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9zIHdoeSB3ZSBicmluZyB1cCB0 cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBu ZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25zb2xpZGF0ZSBPQU0gaW4gYm90 aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDINCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVsdGktbGF5ZXItb2FtLXVzZS1j YXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3aHkgbm90IHJldXNlIGVudHJv cHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWluZyB0cmFuc3BvcnQuIEhvdyBp cyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9pY2UgeW91IHByb3Bvc2VkIGlu IHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSUVFRSA4MDIuMWFn IG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVjaGFuaXNtIGluc3RlYWQgb2Yg RUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5b3UgcHJvcG9zaW5nIHRvIGNv bWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0aCBFQ01QIHN1cHBvcnRlZCBi eSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBhdCB0aGUgc2FtZSB0aW1lIGlu IHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVFIDgwMi4xYWcgQ0ZNIHNoYXJl IGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2YWwsIEJGRCBpbnRlcnZhbC4g SWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxseSBuZWVkIHRvIHRoaW5rIGFi b3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0aGUgbWFuYWdlbWVudCBwbGFu ZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2FuIGRlZmluZSBmb3IgYm90aD8g SG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2UgdGhlbSBtb3JlIGV4dGVuc2li bGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjMwyNUg MDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+ DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0 Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxA aWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dA aWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6IFJFOiBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3YXkgdGhpcyBpcyBhcHBsaWNh YmxlIHRvIFNGQw0KDQoNCjEuICAgICAgIFNGQyBpcyB1bmRlcmxheWVyIGluZGVwZW5kZW50ICwg d2hpY2ggbWVhbnMgaXQgY2FuIGhhdmUgYWxsIHNvcnRzIG9mIGVuY2FwIHR5cGVzIHVuZGVybmVh dGgsIHRoZSBtb2RlbCBwcmVzZW50ZWQgaW4gdGlzc2EtbmV0bW9kLW9hbSwgYWRkcmVzcyBleGFj dGx5IHRoYXQgaXNzdWUuIEluc3RlYWQgb2YgcmUtaW52ZW50aW5nIGFuZCByZS1pbXBsZW1lbnRp bmcgdmFyaW91cyBkaWZmZXJlbnQgT0FNIHRoZSBkcmFmdCBwcm9wb3NlIHRvIGludGVncmF0ZSB0 aGVtIGF0IHRoZSBtYW5hZ2VtZW50IGxheWVyLg0KDQoyLiAgICAgICBJbiB0aGlzIGRyYWZ0IHdl IGRlZmluZSBhIGZsb3ctZW50cm9weSBhcyBhbiBvcGFxdWUgZWxlbWVudCB0aGF0IGVhY2ggb2Yg dGhlIHRlY2hub2xvZ3kgdHlwZSBjYW4gc3BlY2lmeSBhbmQgaW5jbHVkZS4gSWYgd2UgbG9vayBh dCBkcmFmdC1xdWlubi1zZmMtbnNoLTAyLnR4dCwgaXQgZGVmaW5lIGEgYmxvY2sgdGhhdCBzcGVj aWZpZXMgU0ZDLiBTRkMgdmVyc2lvbiBvZiBZQU5HICBjYW4gc3BlY2lmeSB0aGlzIGFzIHBhcnQg b2YgaXRzIGZsb3cgZW50cm9weS4gVGhlIGJlYXV0eSBpcyB0aGF0IGl0IGlzIGFsbCB1cCB0byB0 aGUgdGVjaG5vbG9neSB0byBzcGVjaWZ5IHRoYXQgKHNpemUgYW5kIHNoYXBlIGlzIHRlY2hub2xv Z3kgZGVwZW5kZW50KSBhbmQgYmFzZSBtb2RlbCBpcyBzdGlsbCBpbnRhY3QuDQoNCldpdGggdGhl IGFib3ZlIGluIG1pbmQgLCBjYW4geW91IHBsZWFzZSByZXZpZXcgZHJhZnQtdGlzc2EtbmV0bW9k LW9hbSBhbmQgc2VlIGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIGVub3VnaCB0byBmb3Ig dGhlIHB1cnBvc2UuIElmIHRoaW5ncyBhcmUgbWlzc2luZyB3ZSBjYW4gYWRkIGFuZCBleHRlbmQu DQoNCkkgaGF2ZSByZXF1ZXN0ZWQgbmV0bW9kIFdHIGNoYWlycyBmb3IgYSBwcmVzZW50YXRpb24g c2xvdCBmb3IgZnVydGhlciBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRnJvbTogUWluIFd1 IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAx NCA5OjIyIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5v cmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+DQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgdHJpbGxA aWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSwgVGlzc2E6DQpUaGFua3MgZm9y IGluaXRpYXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLg0KVW5pZmllZCBPQU0gZm9yIG11 bHRpLUxheWVyIG5ldHdvcmsgaXMgYSBnb29kIGlkZWEgdG8gbWUuDQpkcmFmdC13dy1vcHNhd2ct bXVsdGktbGF5ZXItb2FtLTAwIHdlIHByb3Bvc2VkIGluIG9wc2F3ZyBsYWlkIG91dCB0aGUgYW4g aW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbS4NClRoZSBxdWVzdGlvbiB0byBkcmFm dC10aXNzYS1uZXRtb2Qtb2FtIGlzDQpJIGFtIHdvbmRlcmluZyBob3cgdGhpcyBnZW5lcmljIFlh bmcgTW9kZWwgY2FuIGJlIGFwcGxpZWQgdG8gU0ZDIGVudmlyb25tZW50Pw0KSG93IGRvIHlvdSBz dXBwb3J0IHRoZSBjYXNlIHdoZXJlIHR3byBlbmRwb2ludHMgc3VwcG9ydCBkaWZmZXJlbnQgbGF5 ZXIgT0FNIG9yIGRvZXNuoa90IHN1cHBvcnQgYW55IE9BTSBhdCB0aGF0IGxheWVyLg0KDQpCVFc6 IEkgaGF2ZSBjY6GvZWQgdGltZSBtYWlsaW5nIGxpc3Qgc2luY2UgSSBiZWxpZXZlIHRoaXMgbWFp bGluZyBsaXN0IGlzIHB1cnBvc2VkIHRvIGxvb2sgZm9yIGdlbmVyaWMgYW5kIGludGVncmF0ZWQg T0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xvZ2ll cy4NClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQq3osvNyrG85Dog MjAxNMTqNtTCMTHI1SAzOjAzDQrK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k QGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IHRyaWxsQGll dGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0K1vfM 4jogW25ldG1vZF0gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNo ZWQgWUFORyBtb2RlbCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBm cmFtZXdvcmsgZm9yIE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVj aG5vbG9naWVzLiAjMiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5W TzMgYW5kIFRSSUxMLA0KDQoNCjEuICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLw0KDQozLiAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0K DQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2EN Cg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Tissa:

I don=A1=AFt think the idea you proposed have any inconsistency w= ith what we are proposing in draft-ww-opsawg-multi-layer-oam-02. But looks = like we are debating something,J

You and us are both looking for OAM consolidation in the manageme= nt, in addition, we are looking for OAM consolidation in the data plane.

Please see my reply inline below.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C28=C8=D5 22:48
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ie= tf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

May be = a point is missed here.

&n= bsp;

= 1.       Thought SFC can go up and down on layers, what controls that behavior ? Is= =A1=AFnt it the Service header ?

[Qin]: It is possible, but who control that behavior, it is the m= anagement plane, the management plane need to interact with different layer= OAM in the data plane or

Management plane need to interact with OAM protocol that is defin= ed for SFC at the top of layer 3.

 

= 2.       Is the OAM comes down to fault isolation, verification , monitoring etc fo= r the specified SH ?

[Qin]: = Not clear whether SH is the only approach. OAM information can be put into = BDF protocol or Generic TLV as well.

 

Like di= scussed before (many times) exact en-cap is less important what is importan= t is to have a model that define OAM framework and scope. CFM to my opinion= do an excellent job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

[Qin]: We are on the same page, but isn=A1=AFt more straightforwa= rd and reasonable to define Generic OAM framework separated from Yang Data = model for Generic OAM.

That=A1=AFs what we like to propose in the draft-ww-opsawg-multi-= layer-oam-02. Developing separate Architecture and Framework from Transport= Independent OAM Problem statement draft.

Generic OAM framework should also allow more interaction between = data plane and management plane and more interworking between different lay= er OAM protocol.

&n= bsp;

You hav= e noted BFD and CFM are similar because they have similar set of timers. Th= at is a wrong comparison. Have similar set of timers does not make two prot= ocols the same.

 

[Qin]: That=A1=AFs not what we are proposing, we hope in the mana= gement plane there is some common components or elements that can be used b= y not only BFD, but also CFM.

 

What ma= kes them is what framework they follows.  We have used key word CFM he= re loosely. Though we borrow lots of concepts form CFM there are things tha= t needed to be revisited.

&n= bsp;

I have = requested presentation slots in nvo3 and NETMOD working groups and will be = going through in details how each one of the technologies map to YANG model= presented here.

 

[Qin]: That would be a very good survey, in my opinion, before go= ing there, isn=A1=AFt more nice to have a gap analysis document to

a .Identify technology dependent and independent component

b.  analyze and understand the different motivations and opp= ortunities for optimisation of OAM in different technology networks,

and the trade-offs between those optimisations and the overall ad= vantage of a generic OAM mechanism.

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

There are many options for SFC OAM, BFD extension, Generic Header= extension, Generic TLV extension.

Unlike other existing OAM protocols, mechanisms and tools, SFC ne= ed to address OAM for the technology that is above layer 3.

SFC haven=A1=AFt developed OAM protocol yet at the top of layer 3= .

 

Before they developing OAM protocol, they need to figure out whet= her they need to develop technology dependent OAM protocol,

Or technology independent OAM protocol since SFC OAM and Overlay = OAM share a lot of similarities(e.g., both can use overlay technology to st= itch a set of overlay node or service node to form the end to end path). Why not build one protocol to support b= oth?

 

That=A1=AFs why we bring up transport independent OAM covering va= rious heterogeneous network technologies and propose to consolidate OAM in = both

Management plane and data plane.

http://tools.ietf.org/html/draft= -ww-opsawg-multi-layer-oam-02

http://tools= .ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

 

Regarding flow-entropy, why not reuse entropy mechanisms in the e= xisting underlying transport. How is flow entropy different from ECMP choic= e you proposed in the draft.

If my understanding is correct, IEEE 802.1ag only support Equal C= ost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are you proposing to combine ECT supported by IEEE 802.1ag with E= CMP supported by IEEE 802.1Qbp and use them together at the same time in th= e same network?

 

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., C= CM-interval, BFD interval. If we integrate them together, we really need to= think about how to integrate them together in the management plane. Is there any common component we can define for b= oth? How we define these component and make them more extensible.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenev= ir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

There a= re several way this is applicable to SFC

&n= bsp;

= 1.       SFC is underlayer independent , which means it can have all sorts of encap= types underneath, the model presented in tissa-netmod-oam, address exactly= that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate t= hem at the management layer.

= 2.       In this draft we define a flow-entropy as an opaque element that each of t= he technology type can specify and include. If we look at draft-quinn-sfc-n= sh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entrop= y. The beauty is that it is all up to the technology to specify that (size = and shape is technology dependent) and base model is still intact.

&n= bsp;

With th= e above in mind , can you please review draft-tissa-netmod-oam and see it i= s flexible and extensible enough to for the purpose. If things are missing = we can add and extend.

&n= bsp;

I have = requested netmod WG chairs for a presentation slot for further discussion o= f the draft.  

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

Thanks for initiating discussion on this topic.=

Unified OAM for multi-Layer network is a good idea to me.

draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out= the an initial description of the problem.

The question to draft-= tissa-netmod-oam is

I am wondering how this generic Yang Model can be applied to SFC = environment?

How do you support the case where two endpoints support different= layer OAM or doesn=A1=AFt support any OAM at that layer.=

 

BTW: I have cc=A1=AFed time mailing list since I believe this mai= ling list is purposed to look for generic and integrated OAM covering vario= us heterogeneous networking technologies.

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org<= /a>] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for OAM

 

All

 

We have published YANG model fo= r OAM. #1 draft below place the generic framework for OAM, that can be augm= ented for different technologies. #2 and #3 are application of the concept = to NVO3 and TRILL,

 

1. &nbs= p;     http://datatracker.ietf.org/do= c/draft-tissa-netmod-oam/

2. &nbs= p;     http://datatracker.ietf.org= /doc/draft-tissa-nvo3-yang-oam/

3. &nbs= p;     http://datatracker.ietf.or= g/doc/draft-tissa-trill-yang-oam/

 

Please review and share your co= mments

 

Thanks

Tissa

 

 

--_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_-- From nobody Tue Jul 8 19:24: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 476241A028A for ; Tue, 8 Jul 2014 19:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.363 X-Spam-Level: X-Spam-Status: No, score=-12.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 IO3_bnpcV34u for ; Tue, 8 Jul 2014 19:24:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AF01A0276 for ; Tue, 8 Jul 2014 19:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5170; q=dns/txt; s=iport; t=1404872649; x=1406082249; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uYBUXsucpRlY04PbZRfyNnP5/O75i1531bJrqNFkS2k=; b=D9PbgJDJSUSNa3MnJvXvSAcHr/B465aUysKsJI1Hl/Bq+sNwv1YExmuY 67uFbHSdyJxgO2vDsHNAliZmO7XND+82sAEI8rSfTiPayM8U7jv6gNKgQ qpI2uN7DciTvF6XdxirjrBYDhFMcpxCyZ9/tPfp1bJGNygqMTikIy4kd+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAJ2mvFOtJV2Y/2dsb2JhbABagw5SWoJvvDgKhz8afRZ1hAMBAQEEAQEBMToXBgEGAg4DBAEBBSMFBCULFAkKBAESCYg5DZIknCEImVwXgSiNNkkogm2BUAWadoFIkkSDQ4FuQg X-IronPort-AV: E=Sophos;i="5.01,630,1400025600"; d="scan'208";a="59261486" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 09 Jul 2014 02:24:08 +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 s692O6wB006336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 02:24:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 21:24:06 -0500 From: "Ken Gray (kegray)" To: Qin Wu , Ron Parker , Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: draft-wu-pce-traffic-steering-sfc-04 Thread-Index: AQHPmxzb7qK3d3xA0EGKphRP2OMpJw== Date: Wed, 9 Jul 2014 02:24:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.50] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kNUW4ogDIv84XdOXhVZNSYR15g4 Subject: Re: [sfc] draft-wu-pce-traffic-steering-sfc-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: Wed, 09 Jul 2014 02:24:09 -0000 SSBoYWQgYSBjb3VwbGUgcXVlc3Rpb25zIG9uIHRoaXMgoa0NCg0KSWYgdGhlIHBvaW50IGlzIHRo YXQgYSBQQ0UgY291bGQgY29tcHV0ZSB0aGUgcGF0aCBiYXNlZCBvbiBhIHBvbGljeSwgd2UncmUN CnByb2JhYmx5IGFsbCBpbiBhZ3JlZW1lbnQuIFdoZXJlIEkgZ2V0IGxvc3QgaXMgaW4gdGhlIG5l ZWQgZm9yIHRoZSBUTFYNCmV4dGVuc2lvbiB0byBpbmRpY2F0ZSBpdCdzIGFuIFNGUC4gIFRoYXQg ZmFjdCB3b3VsZCwgSU1PLCBiZSBtYW5hZ2VkIGF0IGENCmhpZ2hlciBsZXZlbCAtIGFzIGl0IHdv dWxkIGJlIGZvciBhbnkgb3ZlcmxheSBjb25zdHJ1Y3QgKFZYTEFOLCBHUkUsDQp5b3VyLWZhdm9y aXRlLW92ZXJsYXktZW5jYXAtaGVyZSkuICBJdCBhcHBlYXJzIGFuIHVubmVjZXNzYXJ5DQppbmZv cm1hdGlvbmFsIGJ1cmRlbiwgSU1PLiAgQ2FuIHlvdSBleHBsYWluIGhvdyB5b3UgZW52aXNpb24g dGhpcyBiZWluZw0KdXNlZD8NCg0KT24gNy83LzE0IDk6MTIgQU0sICJRaW4gV3UiIDxiaWxsLnd1 QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+Um9uOg0KPldlIGFsc28gaGF2ZSBkcmFmdCB0byBkaXNj dXNzIGhvdyB0byBpbnN0YW50aWF0ZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGgNCj51c2luZyBQQ0Ut aW5pdGlhdGUgTFNQIGluc3RhbnRpYXRpb24uDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtd3UtcGNlLXRyYWZmaWMtc3RlZXJpbmctc2ZjLTA0DQo+SXQgc3VwcG9ydHMgZHluYW1p YyBjcmVhdGlvbiBhbmQgZGVsZXRpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRoLg0KPllvdXIg bWF5IGNoZWNrIG91dC4NCj4NCj5SZWdhcmRzIQ0KPi1RaW4NCj4tLS0tLdPKvP7Urbz+LS0tLS0N Cj63orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvbiBQYXJr ZXINCj63osvNyrG85DogMjAxNMTqN9TCN8jVIDIwOjUyDQo+ytW8/sjLOiBMaW5kYSBEdW5iYXI7 ICdzZmNAaWV0Zi5vcmcnDQo+1vfM4jogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj5kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0 DQo+DQo+TGluZGEgJiBBbmR5LA0KPg0KPlRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVy LiAgIEknbSBoYXBweSB0byBzZWUgbW9yZSB3b3JrIG9uIHRoZQ0KPiJjaGFpbi10by1wYXRoIiB0 b3BpYy4gICBJIGFncmVlIHdpdGggYWxsIG9mIHlvdXIgYW5hbHlzaXMgcmVnYXJkaW5nDQo+cHJv cy9jb25zIG9mIHZhcmlvdXMgYXBwcm9hY2hlcy4gICAgIEVuY2Fwc3VsYXRpb24gYW5kIENvbnRy b2wgUGxhbmUgd2lsbA0KPmJlIGRlcGVuZGVudCBvbiBvdXIgYXJjaGl0ZWN0dXJhbCBkZWNpc2lv bnMgaW4gdGhpcyBhcmVhLiAgIFRoZSBlbHVzaXZlDQo+dGhpbmcgZm9yIGFsbCBvZiB1cywgYXMg YSBncm91cCwgaXMgdG8gY29tZSB0byBzb21lIGNvbmNsdXNpb25zIQ0KPg0KPiAgIFJvbg0KPg0K Pg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaW5kYSBEdW5iYXINCj5TZW50OiBGcmlkYXks IEp1bHkgMDQsIDIwMTQgNDo0OSBQTQ0KPlRvOiAnc2ZjQGlldGYub3JnJw0KPlN1YmplY3Q6IFtz ZmNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtZHVuYmFyLXNmYy1m dW4taW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KPg0KPkhpLCANCj4NCj5UaGlzIGRyYWZ0 IGRlc2NyaWJlcyB0aGUgZnJhbWV3b3JrIG9mIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIG9m DQo+ICAgU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24g dGhlIHBhdGggZmFpbCBvcg0KPiAgIG5lZWQgdG8gYmUgcmVwbGFjZWQuDQo+DQo+QXBwcmVjaWF0 ZSB0byBoZWFyIHlvdXIgY29tbWVudHMgb3Igc3VnZ2VzdGlvbnMuDQo+DQo+TGluZGEgJiBBbmR5 DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+U2VudDogV2VkbmVz ZGF5LCBBcHJpbCAzMCwgMjAxNCAxMToyNSBBTQ0KPlRvOiBBbmRyZXcgRy4gTWFsaXM7IExpbmRh IER1bmJhcjsgQW5kcmV3IEcuIE1hbGlzOyBMaW5kYSBEdW5iYXINCj5TdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJl c3RvcmF0aW9uLTAwLnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kdW5i YXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQo+aGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0K PnJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1y ZXN0b3JhdGlvbg0KPlJldmlzaW9uOgkwMA0KPlRpdGxlOgkJRnJhbWV3b3JrIGZvciBTZXJ2aWNl IEZ1bmN0aW9uIEluc3RhbmNlcyBSZXN0b3JhdGlvbg0KPkRvY3VtZW50IGRhdGU6CTIwMTQtMDQt MjkNCj5Hcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJMTINCj5VUkw6ICAg ICAgICAgICAgDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVu YmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmENCj50aW9uLTAwLnR4dA0KPlN0YXR1czogICAg ICAgICANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2Zj LWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpbw0KPm4vDQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0 b3JhdGlvbi0wMA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRo ZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCj4gICBTZXJ2aWNl IENoYWluIEluc3RhbmNlIFBhdGggd2hlbiBzb21lIGluc3RhbmNlcyBvbiB0aGUgcGF0aCBmYWls IG9yDQo+ICAgbmVlZCB0byBiZSByZXBsYWNlZC4NCj4NCj4gICAgICAgICAgICAgICAgICANCj4g ICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+dG9vbHMuaWV0Zi5vcmcuDQo+DQo+ VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNm Y0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFp bGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg0K From nobody Tue Jul 8 19:36: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 AD81E1A0294 for ; Tue, 8 Jul 2014 19:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ir8huCOmg6zw for ; Tue, 8 Jul 2014 19:35:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540C51A0299 for ; Tue, 8 Jul 2014 19:35:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX85125; Wed, 09 Jul 2014 02:35:54 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 03:35:53 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 10:35:45 +0800 From: Qin Wu To: "Ken Gray (kegray)" , Ron Parker , Linda Dunbar , "'sfc@ietf.org'" Thread-Topic: draft-wu-pce-traffic-steering-sfc-04 Thread-Index: AQHPmxzb7qK3d3xA0EGKphRP2OMpJ5uXBEZA Date: Wed, 9 Jul 2014 02:35:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/56TtLLBGOe0JhtWRBv_3pQRV1o4 Cc: Dhruv Dhody Subject: Re: [sfc] draft-wu-pce-traffic-steering-sfc-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: Wed, 09 Jul 2014 02:36:00 -0000 Tm90IG9ubHkgaW5kaWNhdGUgaXQgaXMgYW4gU0ZQLCBidXQgYWxzbyB5b3UgbmVlZCB0byB0ZWxs IGNsYXNzaWZpZXIgd2hpY2ggc2VydmljZSBmdW5jdGlvbiBwYXRoIHlvdSBuZWVkIHRvIGluc3Rh bnRpYXRlPw0KV2l0aG91dCBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggSUQsIGhvdyBkbyB5b3Uga25v dyB3aGljaCBwYXRoIHlvdSBuZWVkIHRvIGNyZWF0ZSwgd2hpY2ggcGF0aCB5b3UgbmVlZCB0byB1 cGRhdGUgLHdoaWNoIHBhdGggeW91IG5lZWQgdG8gZGVsZXRlPw0KDQpSZWdhcmRpbmcgd2hlcmUg dG8gcHV0IFNGUCwgSSB0aGluayBhdCBsZWFzdCBjbGFzc2lmaWVyIHNob3VsZCBtYWludGFpbiBw YXRoIGluZm9ybWF0aW9uIHdoaWNoIHVzZSBTRlAgSUQgdG8gZGlzdGluY3Qgb25lIHBhdGggZnJv bSBhbm90aGVyLA0KWW91IG1heSBwdXQgaXQgaW50byB3aGF0ZXZlciBvdmVybGF5IGhlYWRlciB5 b3Ugd2FudCB0byB1c2UuIElmIHlvdSB0aGluayBpdCBpcyBhIGJ1cmRlbiwgeW91IGNhbiBjaG9v c2Ugbm90IHB1dCBpdCBpbnRvIHRoZSBvdmVybGF5IGhlYWRlciBhbmQgDQp1c2Ugb3RoZXIgc2ln bmFsaW5nIHRvIHNldHVwIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCwgZS5nLiwgeW91IGhhdmUgU0RO IGNvbnRyb2xsZXIgb3IgeW91IGhhdmUgTk1TL09TUywgTk1TL09TUyB3aWxsIHRyYW5zbGF0ZSBT ZXJ2aWNlIGZ1bmN0aW9uIGNoYWluDQppbnRvIHBhdGggaW5mb3JtYXRpb24gYmFzZWQgb24gU0ZQ IElEIGFuZCBwb3B1bGF0ZSBzdWNoIHBhdGggaW5mb3JtYXRpb24gd2l0aCBTRlAgSUQgdG8gZWFj aCBwYXJ0aWNpcGF0aW5nIG5vZGUgaW4gdGhlIHNlcnZpY2UgY2hhaW4uDQpBbGwgaW4gYWxsLCBh cyBJIGNsYXJpZmllZCBlYXJsaWVyLCBTRlAgSUQgYmFzZWQgc29sdXRpb24gZG9lc24ndCBjb3Vw bGUgd2l0aCB0aGUgc2lnbmFsaW5nIHlvdSBhcmUgdXNlZC4NCg0KUmVnYXJkcyENCi1RaW4NCi0t LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3Jh eUBjaXNjby5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjnI1SAxMDoyNA0KytW8/sjLOiBRaW4g V3U7IFJvbiBQYXJrZXI7IExpbmRhIER1bmJhcjsgJ3NmY0BpZXRmLm9yZycNCtb3zOI6IFJFOiBk cmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1zZmMtMDQNCg0KSSBoYWQgYSBjb3VwbGUgcXVl c3Rpb25zIG9uIHRoaXMgoa0NCg0KSWYgdGhlIHBvaW50IGlzIHRoYXQgYSBQQ0UgY291bGQgY29t cHV0ZSB0aGUgcGF0aCBiYXNlZCBvbiBhIHBvbGljeSwgd2UncmUgcHJvYmFibHkgYWxsIGluIGFn cmVlbWVudC4gV2hlcmUgSSBnZXQgbG9zdCBpcyBpbiB0aGUgbmVlZCBmb3IgdGhlIFRMViBleHRl bnNpb24gdG8gaW5kaWNhdGUgaXQncyBhbiBTRlAuICBUaGF0IGZhY3Qgd291bGQsIElNTywgYmUg bWFuYWdlZCBhdCBhIGhpZ2hlciBsZXZlbCAtIGFzIGl0IHdvdWxkIGJlIGZvciBhbnkgb3Zlcmxh eSBjb25zdHJ1Y3QgKFZYTEFOLCBHUkUsIHlvdXItZmF2b3JpdGUtb3ZlcmxheS1lbmNhcC1oZXJl KS4gIEl0IGFwcGVhcnMgYW4gdW5uZWNlc3NhcnkgaW5mb3JtYXRpb25hbCBidXJkZW4sIElNTy4g IENhbiB5b3UgZXhwbGFpbiBob3cgeW91IGVudmlzaW9uIHRoaXMgYmVpbmcgdXNlZD8NCg0KT24g Ny83LzE0IDk6MTIgQU0sICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+ Um9uOg0KPldlIGFsc28gaGF2ZSBkcmFmdCB0byBkaXNjdXNzIGhvdyB0byBpbnN0YW50aWF0ZSBz ZXJ2aWNlIGZ1bmN0aW9uIHBhdGggDQo+dXNpbmcgUENFLWluaXRpYXRlIExTUCBpbnN0YW50aWF0 aW9uLg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBjZS10cmFmZmljLXN0 ZWVyaW5nLXNmYy0wNA0KPkl0IHN1cHBvcnRzIGR5bmFtaWMgY3JlYXRpb24gYW5kIGRlbGV0aW9u IG9mIHNlcnZpY2UgZnVuY3Rpb24gcGF0aC4NCj5Zb3VyIG1heSBjaGVjayBvdXQuDQo+DQo+UmVn YXJkcyENCj4tUWluDQo+LS0tLS3Tyrz+1K28/i0tLS0tDQo+t6K8/sjLOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb24gUGFya2VyDQo+t6LLzcqxvOQ6IDIwMTTE6jfU wjfI1SAyMDo1Mg0KPsrVvP7IyzogTGluZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0KPtb3zOI6 IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPmRyYWZ0LWR1bmJhci1z ZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCj4NCj5MaW5kYSAmIEFuZHksDQo+ DQo+VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIuICAgSSdtIGhhcHB5IHRvIHNlZSBt b3JlIHdvcmsgb24gdGhlDQo+ImNoYWluLXRvLXBhdGgiIHRvcGljLiAgIEkgYWdyZWUgd2l0aCBh bGwgb2YgeW91ciBhbmFseXNpcyByZWdhcmRpbmcNCj5wcm9zL2NvbnMgb2YgdmFyaW91cyBhcHBy b2FjaGVzLiAgICAgRW5jYXBzdWxhdGlvbiBhbmQgQ29udHJvbCBQbGFuZSB3aWxsDQo+YmUgZGVw ZW5kZW50IG9uIG91ciBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucyBpbiB0aGlzIGFyZWEuICAgVGhl IGVsdXNpdmUNCj50aGluZyBmb3IgYWxsIG9mIHVzLCBhcyBhIGdyb3VwLCBpcyB0byBjb21lIHRv IHNvbWUgY29uY2x1c2lvbnMhDQo+DQo+ICAgUm9uDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIExpbmRhIER1bmJhcg0KPlNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA0OjQ5IFBN DQo+VG86ICdzZmNAaWV0Zi5vcmcnDQo+U3ViamVjdDogW3NmY10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgDQo+ZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0 aW9uLTAwLnR4dA0KPg0KPkhpLA0KPg0KPlRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdv cmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCj4gICBTZXJ2aWNlIENoYWluIElu c3RhbmNlIFBhdGggd2hlbiBzb21lIGluc3RhbmNlcyBvbiB0aGUgcGF0aCBmYWlsIG9yDQo+ICAg bmVlZCB0byBiZSByZXBsYWNlZC4NCj4NCj5BcHByZWNpYXRlIHRvIGhlYXIgeW91ciBjb21tZW50 cyBvciBzdWdnZXN0aW9ucy4NCj4NCj5MaW5kYSAmIEFuZHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBXZWRuZXNkYXksIEFwcmlsIDMwLCAyMDE0IDEx OjI1IEFNDQo+VG86IEFuZHJldyBHLiBNYWxpczsgTGluZGEgRHVuYmFyOyBBbmRyZXcgRy4gTWFs aXM7IExpbmRhIER1bmJhcg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IN Cj5kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQo+DQo+ DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMC50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExp bmRhIER1bmJhciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KPnJlcG9zaXRvcnkuDQo+DQo+TmFt ZToJCWRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbg0KPlJldmlzaW9u OgkwMA0KPlRpdGxlOgkJRnJhbWV3b3JrIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyBS ZXN0b3JhdGlvbg0KPkRvY3VtZW50IGRhdGU6CTIwMTQtMDQtMjkNCj5Hcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJMTINCj5VUkw6ICAgICAgICAgICAgDQo+aHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2Vz LXJlc3QNCj5vcmENCj50aW9uLTAwLnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVz dG9yYQ0KPnRpbw0KPm4vDQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wDQo+MA0K Pg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdvcmsg b2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCj4gICBTZXJ2aWNlIENoYWluIEluc3Rh bmNlIFBhdGggd2hlbiBzb21lIGluc3RhbmNlcyBvbiB0aGUgcGF0aCBmYWlsIG9yDQo+ICAgbmVl ZCB0byBiZSByZXBsYWNlZC4NCj4NCj4gICAgICAgICAgICAgICAgICANCj4gICAgICAgIA0KPg0K Pg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIA0KPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj50b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBT ZWNyZXRhcmlhdA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QN Cj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KDQo= From nobody Tue Jul 8 19:39: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 856EA1A02B9 for ; Tue, 8 Jul 2014 19:39:51 -0700 (PDT) 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_29=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 R7SNreTOpsKo for ; Tue, 8 Jul 2014 19:39:50 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD32F1A01E5 for ; Tue, 8 Jul 2014 19:39:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 57232682566 for ; Tue, 8 Jul 2014 19:39:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 97207682565 for ; Tue, 8 Jul 2014 19:39:49 -0700 (PDT) Message-ID: <53BCAB74.4060801@joelhalpern.com> Date: Tue, 08 Jul 2014 22:39:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JeRn8XiSn4HhDEXHE6GiDeX2BK0 Subject: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 02:39:51 -0000 I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel From nobody Tue Jul 8 20: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 44E7F1A02F6 for ; Tue, 8 Jul 2014 20:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 CyqtMKtezvlo for ; Tue, 8 Jul 2014 20:24:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F921A00B5 for ; Tue, 8 Jul 2014 20:24:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX87986; Wed, 09 Jul 2014 03:24:48 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 04:24:47 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 11:24:37 +0800 From: Jiangyuanlong To: "Paul Quinn (paulq)" Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmYYJzzmHwmoEq/Blwej5BLzZuVlc9ggACK1gCAAPTTAA== Date: Wed, 9 Jul 2014 03:24:37 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77C9A5@szxema506-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A77BD67@szxema506-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PcgTfDEITm_YugsHFGU-Y7i_VPg Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 03:24:52 -0000 Hi Paul, Please see my further comments inline with [JY]. BTW, another editorial proposal: s/both forwarding directions/both forwarding and reverse directions/ Thanks, Yuanlong -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, July 09, 2014 3:37 AM To: Jiangyuanlong Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] 2nd WG Last Call on Problem Statement Hi, Thank you for your comments, please see inline. On Jul 7, 2014, at 11:38 PM, Jiangyuanlong wrote= : > Hi Thomas and all, >=20 > After a review of draft-ietf-sfc-problem-statement-07, I have the followi= ng comments and suggestions: >=20 > 1. The definition of "Classification" does not parse to me, it says: > " Classification: Locally instantiated policy that results in matching > of traffic flows for identification of appropriate outbound > forwarding actions." > Classification seems to be defined as a kind of policy, but it is not. > It is suggested to be defined as: > " Classification: Identification of traffic flows based on locally=20 > instantiated policy for appropriate outbound forwarding actions." PQ> I don't think this improves the definition. Unless there's consensus = from the community, this doesn't need to change. >=20 > 2. "Network Overlay" is defined but not used at all in the contexts - exc= ept in Section "Related IETF Work", however, the definition of "Service Ove= rlay" introduces a new terminology "overlay network": =20 > " Service Overlay: An overlay network created for the purpose of > forwarding data along a service function path. " > Is this "overlay network" actually a typo of "network overlay"?=20 PQ> We use the term overlay network appropriately here. The service overl= ay is an overlay network. =20 [JY] Then definition of "Network Overlay" is suggested to be removed, as i= t is only referred by Section 4 [NVO3]. It is actually a terminology freque= ntly used in NVO3, thus there is no need to be defined in this SFC PS. >=20 > 3. "Service Function Path" is defined as: > " Service Function Path (SFP): The instantiation of a service function > chain in the network. Packets follow a service function path from > a classifier through the required instances of service functions > in the network." > SFP seems to be instantiation of an SFC, that is very confusing. Maybe it= will be more concrete to be rephrased as: =20 > " Service Function Path (SFP): A path for packet forwarding constructed= =20 > from a classifier through the required instances of service function= s=20 > after the instantiation of a service function chain in the network." PQ> Thank you for this comment, the original defn explains a key concept w= hich is the relationship to an SFC; your suggested text makes that less cle= ar. [JY] if it is a key concept, then "instantiation of a service function cha= in" needs to be explained in the first place.=20 >=20 > 4. In Section 2.10, the title is "Per-Service (re)Classification", but it= actually discusses per-service-function (re)classification. > Therefore, it is suggested: > s/Per-Service/Per-Service-Function/ > s/per-service/per-service-function/ >=20 PQ> Will update. > 5. In Section 3.2, it says: > "Symmetric classification ensures that forward and reverse chains are in = place." > But what is "Symmetric classification"? What does it mean by "in place"? Symmetric classification involves the use of classification criteria that r= eflect the "forward" and "reverse" traffic. For example: src a -> dst b an= d src b -> dst a. =20 [JY] Can we add this into the document to make it clear? >=20 > 6. In Section 3.3, it says: > "...As such metadata is not used as forwarding information to deliver pac= kets=20 > along the service overlay." > It is strange to have such a negative phrase here. From the definition of= "service overlay" and the contexts, it is unclear who will forward the pac= ket, and what forwarding information is realy needed, therefore, it is too = early to make such a statement, and it should be rightfully considered in a= n architecture draft IMHO. PQ> We bound the problem to not include forwarding based on metadata. Thu= s far the consensus is that this makes sense. [JY] Section 2 "Problem Space" does not have such a requirement, it is def= initely in solution space.=20 Even there is consensus that metadata cannot be used as forwarding informat= ion to deliver packets, the statement should be better made in SFC architec= ture document. >=20 > 7. In Section 3.3, it says: > " ... Service functions utilize > metadata, as required, for localized policy decisions." > Is "localized policy decisions" the only valid thing for metadata to be= used? Or is it just an example? >=20 PQ> This is an example. [JY] To be clearer, it is suggested to replace "as required" with "e.g.". >=20 > Other minor editorial proposals: > s/real or virtualized/physical or virtualized/ =20 > s/fearing misconfiguration and downtime/for fear of misconfiguration and = consequent downtime/=20 > s/inter- vendor/inter-vendor/ > s/decoupling of policy from the topology/decoupling of policy from the ne= twork topology/ (BTW, we only defined service topology in the document) >=20 PQ> Those edits will be reflected in the draft. Thanks again, Paul=20 From nobody Tue Jul 8 21:00: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 48F881A0305; Tue, 8 Jul 2014 21:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 0kQ0xxZrhGIL; Tue, 8 Jul 2014 21:00:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0530A1A0302; Tue, 8 Jul 2014 21:00:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT73437; Wed, 09 Jul 2014 04:00:35 +0000 (GMT) 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; Wed, 9 Jul 2014 05:00:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 12:00:29 +0800 From: Xuxiaohu To: "" , "sfc@ietf.org" Thread-Topic: Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF Thread-Index: AQHPmlH7odT5H7A+MEepJZdtU3RfX5uWmeJw Date: Wed, 9 Jul 2014 04:00:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08291A4F@NKGEML512-MBS.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Gk69URQoSDHShsKbuYPpbHS0aAY Subject: Re: [sfc] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 04:00:40 -0000 Hi all, The following are some drafts related to the SPRING-based SFC approach whic= h may be useful for you to get the whole picture of the SRPING-based SFC ap= proach. Any comments and suggestions are welcome. Use Case draft: http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02 SF Auto-discovery through IGP: http://tools.ietf.org/html/draft-xu-isis-service-function-adv-02 http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-02 SF Auto-discovery through DNS-SD: http://tools.ietf.org/html/draft-xu-dnssd-sf-discovery-01 SFP Computation through PCE: http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01 http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01 Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 08, 2014 10:12 AM > To: Ron Parker > Cc: ; sfc@ietf.org > Subject: [sfc] Taking the MPLS label stack representing an SFP as an > overlay=3DTransport Derived SFF >=20 > (Note that I changed the subject since this is a totally different topic) >=20 > Hi Ron, >=20 > I agree there are some cases where the underlay network is not MPLS-capab= le. > In those cases, you could actually just take the MPLS label stack which > represents a given SFP > (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) as an overla= y, just > like the SFC encapsulation header > (http://tools.ietf.org/html/draft-merged-sfc-architecture-00). The MPLS p= ackets > on the overlay could be transported over IP underlay networks with > MPLS-over-IP tunnels > (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00= ). > IMHO, this MPLS label stack based (or SPRING based) SFC approach is a con= crete > example of Transport Derived SFF (see below) as defined in section 4.3.1 = of the > SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-architecture-= 00): >=20 > 4.3.1. Transport Derived SFF >=20 > Service function forwarding, as described above, directly depends > upon the use of the service path information contained in the SFC > encapsulation. Existing implementations may not be able to act on > the SFC encapsulation. These platforms may opt to use a transport > mechanism which carries the service path information from the SFC > encapsulation, and information derived from the SFC encapsulation, to > build transport information. >=20 > This results in the same architectural behavior and meaning for > service function forwarding and service function paths. It is the > responsibility of the control components to ensure that the transport > path executed in such a case is fully aligned with the path > identified by the information in the service chaining encapsulation. >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > > Sent: Monday, July 07, 2014 9:47 PM > > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org' > > Subject: Re: [sfc] New Version Notification for > > draft-dunbar-sfc-fun-instances-restoration-00.txt > > > > Qin, > > > > I agree that RSVP-TE style MPLS is a close architectural match to what > > SFC is trying to achieve, and that an MPLS label stack in this context > > is likely the most efficient way to encode explicit source routing, > > packet-by-packet, while preserving all the resiliency capabilities that= are > required for real-world SFC. > > > > But one concern I have is the ubiquity, or lack thereof, of MPLS where = SFC > > would be used. In mobile carrier environments, the SFC is seen as > applicable > > to the "Gi-LAN" set of value added services that are deployed between t= he > > subscriber management system (i.e., GGSN/PDN-GW) and the Internet. I= n > > some cases, this may be MPLS underpinning this part of the network, > > but in others it is simple Ethernet or SDN overlay over Ethernet. > > > > Please share your thoughts on this. > > > > Thanks. > > > > Ron > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 00:04: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 5B0091A030B for ; Wed, 9 Jul 2014 00:04:55 -0700 (PDT) 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, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=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 CXf9Dfhfu2TQ for ; Wed, 9 Jul 2014 00:04:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368DE1A01D9 for ; Wed, 9 Jul 2014 00:04:53 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 17FCF190358; Wed, 9 Jul 2014 09:04:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E439CC8064; Wed, 9 Jul 2014 09:04:50 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 09:04:50 +0200 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8SNUJcDw+fY0G65MVlxCUTgpuXSJIg Date: Wed, 9 Jul 2014 07:04:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> In-Reply-To: <53BCAB74.4060801@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pKt8aQ6YuWp631lorsEQ3w5zXmw Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 07:04:55 -0000 Hi Joel, 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 9 juillet 2014 04:40 >=C0=A0: sfc@ietf.org >Objet=A0: [sfc] Service Chains, Paths, and Load Balancers > >I have been trying to figure out how to clearly answer a number of >comments that have been made about the proposed merged archtiecture >draft. Assuming we can get working group agreement on the intent, we >will work to improve the wording so that readers who have not >participated in the WG discussion will understnd it the way the working >group intends. > >But what do we intend? I will try to explain my personal view, and see >if that helps. > >In this regard, it is important to keep in mind that what we are >defining is the data plane architecture. We are not attempting to >define the architecture for the entire solution for service chaining. >That would encompass OSS/BSS, various control and policy functions, >virtual machine and image management, and many other aspects. [Med] OSS/BSS considerations are out of scope for sure, but the functional = entity(ies) responsible for the structuring of chains should be in scope IM= O. The title and the abstract of the merged draft do not exclude those: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. > >As a result there are many things which clearly need to exist in the >larger system, [Med] I don't understand what you mean by the large system.=20 but which are dealt with above where we are functioning, >and are not directly required by the work we are doing. > >In order to get to service chain vs service path, as I understand them, >I need to first discuss load balancing. There are at least three >different ways that load balancing can and will interact with service >chaining. There probably are more. The point of the archtiecture is to >permit all of these, but not to mandate that any particular kind be used >in any solution. [Med] Agree. How load balancing is managed within a SFC-enabled domain is u= p to the responsibility of the administrative entity managing that domain. = One or a mix of these flavors can co-exist.=20 > >1) Load balancing as a service provided to the end user. This is a >service function. It receives user packets, and modifies them (or marks >them, or ...) so as to choose an end user service instance to receive >the users packet. This is an important service function to be able to >include in service chaining. It's behavior may affect requirements on >how service chaining is done. But it has very little impact on the >archtiecture. From an architectural pe3rspective it is simply a service >function which may modify the underlying packet. > >2) There is internal load balancing. That is, one can have what appears >to the service chaining architecture as a single point of contact for a >specific service function, but is actually delivered by a collection of >virtual or physical machines, possibly including one or several load >balancers (for example using VRRP-like techniques to share a MAC >address.) mostly, this is invisible to the service chaining data plane >mechanisms. It is likely that it is visible to various control >mechanisms, such as those responsible for scale-in, scale-out, and vm >instantiation. The architectural impact of permitting this is largely >that we need to be careful that our terminology does not lead readers to >think we are prohibiting it. > >3) There can also be load balancing done by selecting packet paths for >the service chaining that direct traffic to different places. We would >not want to require that a given service function appear at only one >place in the network. > >It is of course the case that these may be combined. I tend to refer to >the collection of entities that appear to service chaining as a single >point as a cluster. Not because cluster is a good term. But because I >do not have another one. Thus, the point of type 3 load balancing is to >direct different subsets of traffic to different singular or clustered >service functions in different places in the network. > >Now with that said, what do I mean when I talk about service chain and >service path/ Service chain is a sequence of logical functions to be >applied to a subset of packets. It is equivalent of saying that some >subset of traffic is to get DPI, charging, content inspection, and >firewall while a different subset is to go directly to the cache without >visiting any other service functions. > >That is not enough information to direct the packets.=20 [Med] A service chain can also be defined as an order list of service funct= ion identifiers. I understand the examples you provide as liberal descripti= on of service chains (that I thought you considered it out of scope). A ser= vice function identifier does not necessarily hint the service offered by t= hat SF; its purpose is to uniquely identify a SF among those present in a S= FC-enabled domain. A service path >is, in some fashion, a sequence of locations in the network. [Med] so, this is an order list of service function locators.=20 Those >locations will be singular or clustered service function delivery >locations. They may be addressed by IP address. They may be addressed >as ports on an SFF. There are many different ways that the locations >may be known to the service chaining infrastructure and the transport. > > From the point of view of the work of the SFC group, we need to be able >to talk about the high level abstraction, the service chain, which >drives the forwarding. And we need to talk about the actual data path >packets will take in the network. > >Several of the comments have said "but the whole path may not be known >at the front." [Med] Which is true. The entity responsible for structure the service chain= cannot decide in advance the actual packet of packets because of various c= onsiderations such SF-specific LBs, but also for other traffic engineering = purposes such as dispatching the traffic among two service PoPs hosting the= same set of SFs, etc. This architecture deals with that issue in two ways. >First, as noted in item (2) on load balancers above, there can be >decisions and behaviors which are invisible to the service chaining >mechanisms (in much the same way that bridging within a LAN is largely >invisible to routing between LANs.) [Med] Which means that you cannot determine a list of locator a priori give= n that the decision on which SF instance will be invoked is the responsibil= ity of that LB. The other provision we make is that >reclassification can be done in mid-chain when necessary. [Med] Re-classification is optional and is deployment-specific. Mandating r= e-classification to justify a design choice is odd.=20 That will >direct packets to a new chain. Based on information available at the >re-classification point. [Med] That's not optimal for some deployments that do not require to embed = a classification function in these service functions.=20 > >I hope that this helps explain what we are after.=20 [Med] I still disagree that an ordered list of locators can be determined i= n advance for all deployments. I suggest that SFC forwarding be based on th= e service chain itself (characterized as an order list of service function = identifiers). This is more compliant with the LB constraints above: decidin= g which locator to use for a given flow will be a local decision not a cent= ralized one. If it does, and if >the intent is acceptable to the working group, we can figure out what >additional words are needed to convey this. >If the working group disagree with the intent, then we will of course >adjust to match the working group agreements. >If this is still unclear, I am not sure what to try next. > >Yours, >Joel > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 01:31: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 890971A03B6 for ; Wed, 9 Jul 2014 01:30:59 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 eZrSuBzk-NdN for ; Wed, 9 Jul 2014 01:30:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF9E1A0324 for ; Wed, 9 Jul 2014 01:30:57 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 4A9D8C0875; Wed, 9 Jul 2014 10:30:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 2C1BD18005C; Wed, 9 Jul 2014 10:30:55 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 10:30:55 +0200 From: To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] 2nd WG Last Call on Problem Statement Thread-Index: AQHPkKmY9qSFs7H3PEuqW94c8j769puXetcg Date: Wed, 9 Jul 2014 08:30:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002F519@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.7.9.34819 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/42EV5rAtNQPATtk8fQO2F0Ji_o0 Subject: Re: [sfc] 2nd WG Last Call on Problem Statement X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 08:30:59 -0000 Hi Thomas, Great to see the document updated to remove some architectural discussion. = Many thanks to the editors. This version is much better, nevertheless the document is still touching on= architectural point or hinting some design choices (the point about re-cla= ssification as an example, or mentioning metadata that is an optional compo= nent of the overall architecture).=20 The document defines also terms that are not cited in the document, and whi= ch belong to the architecture discussion (e.g. SFP, service node). The actu= al definition + what exact term is to be used is still ongoing. Having thos= e terms in a PS is not only odd, but will make it harder for the reader. Pl= ease remove these terms from the document. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >Envoy=E9=A0: mercredi 25 juin 2014 21:14 >=C0=A0: sfc@ietf.org >Objet=A0: [sfc] 2nd WG Last Call on Problem Statement > >Hi. > >We ran a WGLC on the problem statement draft >(draft-ietf-sfc-problem-statement-07.txt) back in May. >Although the draft received significant review and support prior to >the formal LC, the actual last call resulted largely in silence. > >While it would be convenient to take silence as acceptance, that's not >good enough. To show the document is ready, we need WG members to >speak up and indicate they have read a recent version of the document >and think its ready to go. > >Note that the document was just reissued. Section 3 has been edited to >remove some of the text was deemed to be encroaching on >architecture. You can see the changes at >http://tools.ietf.org/wg/sfc/draft-ietf-sfc-problem-statement/draft-ietf- >sfc-problem-statement-07-from-06.diff.html > >With that, we are restarting a 2-week WGLC on the document. We >specifically need to see sufficient indications from WG members that >the document is ready to advance, and that the document does not >contain significant deficiencies. > >Thomas > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 05:40: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 9E8F41A04F6 for ; Wed, 9 Jul 2014 05:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 hl5Fp8NThsqK for ; Wed, 9 Jul 2014 05:40:39 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C2F1A04F1 for ; Wed, 9 Jul 2014 05:40:39 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 17CBB53E64; Wed, 9 Jul 2014 05:38:55 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 05:38:50.884 -0700 x-echoworx-msg-id: 9a7e43a7-9185-4943-b92c-1edb7edf7a03 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 809; Wed, 9 Jul 2014 05:38:50 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id C03F453E0B; Wed, 9 Jul 2014 05:38:50 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 05:40:35 -0700 From: Ron Parker To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXx0EA///mFfA= Date: Wed, 9 Jul 2014 12:40:33 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/H0BfPzsxI6zzSUItszVVzElQCgo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 12:40:41 -0000 When I read this comment: =09[Med] I still disagree that an ordered list of locators can be determine= d in advance for all deployments. I suggest that SFC forwarding be based on= the service chain itself (characterized as an order list of service functi= on identifiers). This is more compliant with the LB constraints above: deci= ding which locator to use for a given flow will be a local decision not a c= entralized one. "DNS" popped into my head. While this may be an imperfect analogy, a URL= is logical location that uses an explicit mechanism to bind it to one or m= ore actual network locators (i.e., IPv4 and/or IPv6). Just thinking out l= oud here, but is there benefit in using a similar scheme? That the SFC is= truly logical with some sort of "Just-in-time" binding, a la DNS (keeping = in mind that DNS clients will often locally cache so as to decrease the amo= unt of DNS queries)? Would that approach provide simplification and resil= iency with respect to the load balancing of service functions problem -- th= e number of network locators for a logical service function can change at a= ny time due to failures or due to intentional scale-in or scale-out? Also= , this wouldn't preclude the scenario where one or more located service fun= ctions are clustered, since the cluster appears as a single network locator= to the "DNS-like" mechanism. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Wednesday, July 09, 2014 3:05 AM To: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Joel, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >Envoy=E9=A0: mercredi 9 juillet 2014 04:40 =C0=A0: sfc@ietf.org Objet=A0: = [sfc]=20 >Service Chains, Paths, and Load Balancers > >I have been trying to figure out how to clearly answer a number of=20 >comments that have been made about the proposed merged archtiecture=20 >draft. Assuming we can get working group agreement on the intent, we=20 >will work to improve the wording so that readers who have not=20 >participated in the WG discussion will understnd it the way the working=20 >group intends. > >But what do we intend? I will try to explain my personal view, and see=20 >if that helps. > >In this regard, it is important to keep in mind that what we are=20 >defining is the data plane architecture. We are not attempting to=20 >define the architecture for the entire solution for service chaining. >That would encompass OSS/BSS, various control and policy functions,=20 >virtual machine and image management, and many other aspects. [Med] OSS/BSS considerations are out of scope for sure, but the functional = entity(ies) responsible for the structuring of chains should be in scope IM= O. The title and the abstract of the merged draft do not exclude those: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. > >As a result there are many things which clearly need to exist in the=20 >larger system, [Med] I don't understand what you mean by the large system.=20 but which are dealt with above where we are functioning, >and are not directly required by the work we are doing. > >In order to get to service chain vs service path, as I understand them,=20 >I need to first discuss load balancing. There are at least three=20 >different ways that load balancing can and will interact with service=20 >chaining. There probably are more. The point of the archtiecture is=20 >to permit all of these, but not to mandate that any particular kind be=20 >used in any solution. [Med] Agree. How load balancing is managed within a SFC-enabled domain is u= p to the responsibility of the administrative entity managing that domain. = One or a mix of these flavors can co-exist.=20 > >1) Load balancing as a service provided to the end user. This is a=20 >service function. It receives user packets, and modifies them (or=20 >marks them, or ...) so as to choose an end user service instance to=20 >receive the users packet. This is an important service function to be=20 >able to include in service chaining. It's behavior may affect=20 >requirements on how service chaining is done. But it has very little=20 >impact on the archtiecture. From an architectural pe3rspective it is=20 >simply a service function which may modify the underlying packet. > >2) There is internal load balancing. That is, one can have what=20 >appears to the service chaining architecture as a single point of=20 >contact for a specific service function, but is actually delivered by a=20 >collection of virtual or physical machines, possibly including one or=20 >several load balancers (for example using VRRP-like techniques to share=20 >a MAC >address.) mostly, this is invisible to the service chaining data plane=20 >mechanisms. It is likely that it is visible to various control=20 >mechanisms, such as those responsible for scale-in, scale-out, and vm=20 >instantiation. The architectural impact of permitting this is largely=20 >that we need to be careful that our terminology does not lead readers=20 >to think we are prohibiting it. > >3) There can also be load balancing done by selecting packet paths for=20 >the service chaining that direct traffic to different places. We would=20 >not want to require that a given service function appear at only one=20 >place in the network. > >It is of course the case that these may be combined. I tend to refer=20 >to the collection of entities that appear to service chaining as a=20 >single point as a cluster. Not because cluster is a good term. But=20 >because I do not have another one. Thus, the point of type 3 load=20 >balancing is to direct different subsets of traffic to different=20 >singular or clustered service functions in different places in the network= . > >Now with that said, what do I mean when I talk about service chain and=20 >service path/ Service chain is a sequence of logical functions to be=20 >applied to a subset of packets. It is equivalent of saying that some=20 >subset of traffic is to get DPI, charging, content inspection, and=20 >firewall while a different subset is to go directly to the cache=20 >without visiting any other service functions. > >That is not enough information to direct the packets.=20 [Med] A service chain can also be defined as an order list of service funct= ion identifiers. I understand the examples you provide as liberal descripti= on of service chains (that I thought you considered it out of scope). A ser= vice function identifier does not necessarily hint the service offered by t= hat SF; its purpose is to uniquely identify a SF among those present in a S= FC-enabled domain. A service path >is, in some fashion, a sequence of locations in the network. [Med] so, this is an order list of service function locators.=20 Those >locations will be singular or clustered service function delivery=20 >locations. They may be addressed by IP address. They may be addressed=20 >as ports on an SFF. There are many different ways that the locations=20 >may be known to the service chaining infrastructure and the transport. > > From the point of view of the work of the SFC group, we need to be=20 >able to talk about the high level abstraction, the service chain, which=20 >drives the forwarding. And we need to talk about the actual data path=20 >packets will take in the network. > >Several of the comments have said "but the whole path may not be known=20 >at the front." [Med] Which is true. The entity responsible for structure the service chain= cannot decide in advance the actual packet of packets because of various c= onsiderations such SF-specific LBs, but also for other traffic engineering = purposes such as dispatching the traffic among two service PoPs hosting the= same set of SFs, etc. This architecture deals with that issue in two ways. >First, as noted in item (2) on load balancers above, there can be=20 >decisions and behaviors which are invisible to the service chaining=20 >mechanisms (in much the same way that bridging within a LAN is largely=20 >invisible to routing between LANs.) [Med] Which means that you cannot determine a list of locator a priori give= n that the decision on which SF instance will be invoked is the responsibil= ity of that LB. The other provision we make is that >reclassification can be done in mid-chain when necessary. [Med] Re-classification is optional and is deployment-specific. Mandating r= e-classification to justify a design choice is odd.=20 That will >direct packets to a new chain. Based on information available at the=20 >re-classification point. [Med] That's not optimal for some deployments that do not require to embed = a classification function in these service functions.=20 > >I hope that this helps explain what we are after.=20 [Med] I still disagree that an ordered list of locators can be determined i= n advance for all deployments. I suggest that SFC forwarding be based on th= e service chain itself (characterized as an order list of service function = identifiers). This is more compliant with the LB constraints above: decidin= g which locator to use for a given flow will be a local decision not a cent= ralized one. If it does, and if >the intent is acceptable to the working group, we can figure out what=20 >additional words are needed to convey this. >If the working group disagree with the intent, then we will of course=20 >adjust to match the working group agreements. >If this is still unclear, I am not sure what to try next. > >Yours, >Joel > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 06:10: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 2646E1A05CB for ; Wed, 9 Jul 2014 06:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 0mSTsrwuRCM2 for ; Wed, 9 Jul 2014 06:10:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8051A050E for ; Wed, 9 Jul 2014 06:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10464; q=dns/txt; s=iport; t=1404911394; x=1406120994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z41t+9jzGMm70+nulw1HREpOD41fRIknnT6D7PZQ0Eo=; b=hYQ5HfZxSp6xBlqmJNT13L2Rj2mcaGo8q5rQLsDryE3WAHFpvVx20Hoz We0ALviBw1yV35bWMYD+O4665a1/IBuFOSHjshpnK3ZlR9wiehmakcJas SNYy3KRQOWBLj+pvfcOt1ci1qp39UqA/viz+QjMBu/ZevDCGbQRQLWYnr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPk+vVOtJA2B/2dsb2JhbABPCoMOUlq/EwiHQQGBEBZ1hAMBAQEDAQEBAWIJCwULAgEIDgQtBycLFAMOAgQOBRuIHwgNyGoTBI5mKTMHgy2BFgWKF4t/RoQai16ILoNDgjA X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59434882" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 09 Jul 2014 13:09:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s69D9iBF031312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 13:09:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 08:09:44 -0500 From: "Carlos Pignataro (cpignata)" To: Med Boucadair Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WxKjmuDn4BEiFVdMuQoKu35uXpbkAgABmBoA= Date: Wed, 9 Jul 2014 13:09:43 +0000 Message-ID: <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.1] 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/7qPDQ6yPMyWnGY8cgwKas919LGc Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 13:10:09 -0000 Hi, Med, Please see inline, all the way at the bottom. On Jul 9, 2014, at 3:04 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoy=E9 : mercredi 9 juillet 2014 04:40 >> =C0 : sfc@ietf.org >> Objet : [sfc] Service Chains, Paths, and Load Balancers >>=20 >> I have been trying to figure out how to clearly answer a number of >> comments that have been made about the proposed merged archtiecture >> draft. Assuming we can get working group agreement on the intent, we >> will work to improve the wording so that readers who have not >> participated in the WG discussion will understnd it the way the working >> group intends. >>=20 >> But what do we intend? I will try to explain my personal view, and see >> if that helps. >>=20 >> In this regard, it is important to keep in mind that what we are >> defining is the data plane architecture. We are not attempting to >> define the architecture for the entire solution for service chaining. >> That would encompass OSS/BSS, various control and policy functions, >> virtual machine and image management, and many other aspects. >=20 > [Med] OSS/BSS considerations are out of scope for sure, but the functiona= l entity(ies) responsible for the structuring of chains should be in scope = IMO. The title and the abstract of the merged draft do not exclude those: >=20 > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. >=20 >>=20 >> As a result there are many things which clearly need to exist in the >> larger system, >=20 > [Med] I don't understand what you mean by the large system.=20 >=20 > but which are dealt with above where we are functioning, >> and are not directly required by the work we are doing. >>=20 >> In order to get to service chain vs service path, as I understand them, >> I need to first discuss load balancing. There are at least three >> different ways that load balancing can and will interact with service >> chaining. There probably are more. The point of the archtiecture is to >> permit all of these, but not to mandate that any particular kind be used >> in any solution. >=20 > [Med] Agree. How load balancing is managed within a SFC-enabled domain is= up to the responsibility of the administrative entity managing that domain= . One or a mix of these flavors can co-exist.=20 >=20 >>=20 >> 1) Load balancing as a service provided to the end user. This is a >> service function. It receives user packets, and modifies them (or marks >> them, or ...) so as to choose an end user service instance to receive >> the users packet. This is an important service function to be able to >> include in service chaining. It's behavior may affect requirements on >> how service chaining is done. But it has very little impact on the >> archtiecture. From an architectural pe3rspective it is simply a service >> function which may modify the underlying packet. >>=20 >> 2) There is internal load balancing. That is, one can have what appears >> to the service chaining architecture as a single point of contact for a >> specific service function, but is actually delivered by a collection of >> virtual or physical machines, possibly including one or several load >> balancers (for example using VRRP-like techniques to share a MAC >> address.) mostly, this is invisible to the service chaining data plane >> mechanisms. It is likely that it is visible to various control >> mechanisms, such as those responsible for scale-in, scale-out, and vm >> instantiation. The architectural impact of permitting this is largely >> that we need to be careful that our terminology does not lead readers to >> think we are prohibiting it. >>=20 >> 3) There can also be load balancing done by selecting packet paths for >> the service chaining that direct traffic to different places. We would >> not want to require that a given service function appear at only one >> place in the network. >>=20 >> It is of course the case that these may be combined. I tend to refer to >> the collection of entities that appear to service chaining as a single >> point as a cluster. Not because cluster is a good term. But because I >> do not have another one. Thus, the point of type 3 load balancing is to >> direct different subsets of traffic to different singular or clustered >> service functions in different places in the network. >>=20 >> Now with that said, what do I mean when I talk about service chain and >> service path/ Service chain is a sequence of logical functions to be >> applied to a subset of packets. It is equivalent of saying that some >> subset of traffic is to get DPI, charging, content inspection, and >> firewall while a different subset is to go directly to the cache without >> visiting any other service functions. >>=20 >> That is not enough information to direct the packets.=20 >=20 > [Med] A service chain can also be defined as an order list of service fun= ction identifiers. I understand the examples you provide as liberal descrip= tion of service chains (that I thought you considered it out of scope). A s= ervice function identifier does not necessarily hint the service offered by= that SF; its purpose is to uniquely identify a SF among those present in a= SFC-enabled domain. >=20 > A service path >> is, in some fashion, a sequence of locations in the network. >=20 > [Med] so, this is an order list of service function locators.=20 >=20 > Those >> locations will be singular or clustered service function delivery >> locations. They may be addressed by IP address. They may be addressed >> as ports on an SFF. There are many different ways that the locations >> may be known to the service chaining infrastructure and the transport. >>=20 >> From the point of view of the work of the SFC group, we need to be able >> to talk about the high level abstraction, the service chain, which >> drives the forwarding. And we need to talk about the actual data path >> packets will take in the network. >>=20 >> Several of the comments have said "but the whole path may not be known >> at the front." >=20 > [Med] Which is true. The entity responsible for structure the service cha= in cannot decide in advance the actual packet of packets because of various= considerations such SF-specific LBs, but also for other traffic engineerin= g purposes such as dispatching the traffic among two service PoPs hosting t= he same set of SFs, etc. >=20 > This architecture deals with that issue in two ways. >> First, as noted in item (2) on load balancers above, there can be >> decisions and behaviors which are invisible to the service chaining >> mechanisms (in much the same way that bridging within a LAN is largely >> invisible to routing between LANs.) >=20 > [Med] Which means that you cannot determine a list of locator a priori gi= ven that the decision on which SF instance will be invoked is the responsib= ility of that LB. >=20 >=20 > The other provision we make is that >> reclassification can be done in mid-chain when necessary. >=20 > [Med] Re-classification is optional and is deployment-specific. Mandating= re-classification to justify a design choice is odd.=20 >=20 > That will >> direct packets to a new chain. Based on information available at the >> re-classification point. >=20 > [Med] That's not optimal for some deployments that do not require to embe= d a classification function in these service functions.=20 >=20 >>=20 >> I hope that this helps explain what we are after.=20 >=20 > [Med] I still disagree that an ordered list of locators can be determined= in advance for all deployments. I suggest that SFC forwarding be based on = the service chain itself (characterized as an order list of service functio= n identifiers). This is more compliant with the LB constraints above: decid= ing which locator to use for a given flow will be a local decision not a ce= ntralized one. >=20 >=20 Bypassing the concept of a Service Function Path would eliminate the abstra= cted nature of the Chain itself, and tie the chain to a forwarding construc= t. In other words, the idea of an SFC is the abstract set of service functions= , whereas the SPF is the instantiation of an actual path in the service top= ology. This separation allows for the set of load-balancing constructs desc= ribed above. Please note that none of this talks about a centralized versus a local deci= sion. To take it more concrete, these are the actual definitions in draft-merged: Service Function Chain (SFC): A service Function chain defines an ordered set of service functions that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for nodes that copy to more than one branch. The term service chain is often used as shorthand for service function chain. Service Function Path (SFP): The instantiation of an SFC in the network. Packets follow a service function path from a classifier through the requisite service functions It the WG agrees with the usefulness of separating these concepts, but the = text does not convey the intended meaning, let's adjust with suggestions. Thanks, Carlos. > If it does, and if >> the intent is acceptable to the working group, we can figure out what >> additional words are needed to convey this. >> If the working group disagree with the intent, then we will of course >> adjust to match the working group agreements. >> If this is still unclear, I am not sure what to try next. >>=20 >> Yours, >> Joel >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 07:27: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 68D0D1A0AB8 for ; Wed, 9 Jul 2014 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 KG-WZUoWWlKX for ; Wed, 9 Jul 2014 07:26:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D4D1A0AAE for ; Wed, 9 Jul 2014 07:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6930; q=dns/txt; s=iport; t=1404916020; x=1406125620; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kbN0Ii7mgqkeiImIezLugs5/EUScTATaooL/zwUoN2I=; b=DoulALi/tUafT6VJm75U65vdtfuVORO9t6dtT9c4/FBrbWcmmxxGvsup dIQpf13RBZbnypsbwVEdWqhuCE0Uovu3vAaIaPyTQ6xg5w5DFK8ls4U2L xu7KKVWfY+9rwUAQGDm1kC4xnhGr+Tmz4WL05/ti9iy3VK0wh4VESnge/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMlQvVOtJV2P/2dsb2JhbABZgw5SWr8UCIdBAYEPFnWEBAEBBAEBAWIJGwIBCBI0JwsXDgIEARIbiCcNyG0TBI8POoRDBZYWRoQai16ILoNDgjA X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59458219" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 09 Jul 2014 14:26:59 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s69EQusf008013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 14:26:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:26:55 -0500 From: "Ken Gray (kegray)" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W1xFLfwWzB0GPcC0T+kkpD5uX3i2A Date: Wed, 9 Jul 2014 14:26:55 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> In-Reply-To: <53BCAB74.4060801@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.50] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gSbfipI5HCKveck-9aojB_qF3k8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 14:26:59 -0000 In line ... On 7/8/14 10:39 PM, "Joel M. Halpern" wrote: >I have been trying to figure out how to clearly answer a number of >comments that have been made about the proposed merged archtiecture >draft. Assuming we can get working group agreement on the intent, we >will work to improve the wording so that readers who have not >participated in the WG discussion will understnd it the way the working >group intends. > >But what do we intend? I will try to explain my personal view, and see >if that helps. > >In this regard, it is important to keep in mind that what we are >defining is the data plane architecture. We are not attempting to >define the architecture for the entire solution for service chaining. >That would encompass OSS/BSS, various control and policy functions, >virtual machine and image management, and many other aspects. > >As a result there are many things which clearly need to exist in the >larger system, but which are dealt with above where we are functioning, >and are not directly required by the work we are doing. Hallelujah! =20 > >In order to get to service chain vs service path, as I understand them, >I need to first discuss load balancing. There are at least three >different ways that load balancing can and will interact with service >chaining. There probably are more. The point of the archtiecture is to >permit all of these, but not to mandate that any particular kind be used >in any solution. Nor describe in great detail how they work, please. > >1) Load balancing as a service provided to the end user. This is a >service function. It receives user packets, and modifies them (or marks >them, or ...) so as to choose an end user service instance to receive >the users packet. This is an important service function to be able to >include in service chaining. It's behavior may affect requirements on >how service chaining is done. But it has very little impact on the >archtiecture. From an architectural pe3rspective it is simply a service >function which may modify the underlying packet. > >2) There is internal load balancing. That is, one can have what appears >to the service chaining architecture as a single point of contact for a >specific service function, but is actually delivered by a collection of >virtual or physical machines, possibly including one or several load >balancers (for example using VRRP-like techniques to share a MAC >address.) mostly, this is invisible to the service chaining data plane >mechanisms. It is likely that it is visible to various control >mechanisms, such as those responsible for scale-in, scale-out, and vm >instantiation. The architectural impact of permitting this is largely >that we need to be careful that our terminology does not lead readers to >think we are prohibiting it. Bingo. In fact, this will be a common scenario. One of the things I've seen recur as well is the notion that somehow the path needs to include specific instance information for when you enter one of your clusters (which may be one of the reasons you're getting the comment about the path not being known a priori) =8A it does not =8A the on= ly reason we would need to include that information is if it causes some change in the subsequent chain AFTER the abstracted blob of functionality. In this way we avoid the explosion of path information, constant updating of the path, etc. Further, IF you have a scenario where the chain would deviate, I'd venture that it was through a packet alteration that led to reclassification (and again, no need to imbed instance information in the path). From a management perspective, as you point out, this information (what instance flow matching tuple "blah" was sent to) can be gleaned (if you desire) from the distribution agent itself. > >3) There can also be load balancing done by selecting packet paths for >the service chaining that direct traffic to different places. We would >not want to require that a given service function appear at only one >place in the network. > >It is of course the case that these may be combined. I tend to refer to >the collection of entities that appear to service chaining as a single >point as a cluster. Not because cluster is a good term. But because I >do not have another one. Thus, the point of type 3 load balancing is to >direct different subsets of traffic to different singular or clustered >service functions in different places in the network. or provide an ambiguous, already optimized location via something like an anycast address for the service > >Now with that said, what do I mean when I talk about service chain and >service path/ Service chain is a sequence of logical functions to be >applied to a subset of packets. It is equivalent of saying that some >subset of traffic is to get DPI, charging, content inspection, and >firewall while a different subset is to go directly to the cache without >visiting any other service functions. > >That is not enough information to direct the packets. A service path >is, in some fashion, a sequence of locations in the network. Those >locations will be singular or clustered service function delivery >locations. They may be addressed by IP address. They may be addressed >as ports on an SFF. There are many different ways that the locations >may be known to the service chaining infrastructure and the transport. > > From the point of view of the work of the SFC group, we need to be able >to talk about the high level abstraction, the service chain, which >drives the forwarding. And we need to talk about the actual data path >packets will take in the network. > >Several of the comments have said "but the whole path may not be known >at the front." This architecture deals with that issue in two ways. >First, as noted in item (2) on load balancers above, there can be >decisions and behaviors which are invisible to the service chaining >mechanisms (in much the same way that bridging within a LAN is largely >invisible to routing between LANs.) The other provision we make is that >reclassification can be done in mid-chain when necessary. That will >direct packets to a new chain. Based on information available at the >re-classification point. Amen > >I hope that this helps explain what we are after. If it does, and if >the intent is acceptable to the working group, we can figure out what >additional words are needed to convey this. >If the working group disagree with the intent, then we will of course >adjust to match the working group agreements. >If this is still unclear, I am not sure what to try next. > >Yours, >Joel > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 07:31: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 36CB61A0AD5 for ; Wed, 9 Jul 2014 07:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 LtP_GOQYy8NT for ; Wed, 9 Jul 2014 07:31:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2EC1A0AC5 for ; Wed, 9 Jul 2014 07:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3204; q=dns/txt; s=iport; t=1404916277; x=1406125877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ze6zqc+EeU1dA2aZSEHSloV5GV0NiDp91LNOcJHmqmk=; b=bxhYKyGgdVqo+GtsLcTt6NfnU806GeBr6L0wOA8OjYb3d1UUr/MujCoB 7h8bHstLeYVCjMcc/n7ZAI4s1lyVFKV1JUlljUpFpidsVV7FO0OCKCbXB CapzYYHQRmT9C9Nhkg7552zpRwbP4rARKPKh1CHVA41VHLo3xzeWMmp1S w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAAhRvVOtJV2a/2dsb2JhbABZgmokgSzGXQGBDxZ1hAQBAQQ6KxQQAgEIEhAUEDIXDgIEAQ0NiDoByHoXjxExB4MtgRYFllyPeIgug0OCMA X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="338788490" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jul 2014 14:31:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s69EV86Q011902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 14:31:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:31:08 -0500 From: "Nobo Akiya (nobo)" To: "Carlos Pignataro (cpignata)" , Med Boucadair Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8Wz+avP3VyDEaNuxmFkkx26ZuXpbkAgABl84D//7ubUA== Date: Wed, 9 Jul 2014 14:31:07 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> In-Reply-To: <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QYuZyzPQYXBw5ppM00Q8ypCV7EE Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 14:31:11 -0000 Hi Carlos, Joel, Med, et al, > > [Med] I still disagree that an ordered list of locators can be determin= ed in > advance for all deployments. I suggest that SFC forwarding be based on th= e > service chain itself (characterized as an order list of service function > identifiers). This is more compliant with the LB constraints above: decid= ing > which locator to use for a given flow will be a local decision not a > centralized one. > > > > >=20 > Bypassing the concept of a Service Function Path would eliminate the > abstracted nature of the Chain itself, and tie the chain to a forwarding > construct. >=20 > In other words, the idea of an SFC is the abstract set of service functio= ns, > whereas the SPF is the instantiation of an actual path in the service top= ology. > This separation allows for the set of load-balancing constructs described > above. >=20 > Please note that none of this talks about a centralized versus a local > decision. >=20 > To take it more concrete, these are the actual definitions in draft-merge= d: >=20 > Service Function Chain (SFC): A service Function chain defines an > ordered set of service functions that must be applied to packets > and/or frames selected as a result of classification. The > implied order may not be a linear progression as the > architecture allows for nodes that copy to more than one branch. > The term service chain is often used as shorthand for service > function chain. >=20 > Service Function Path (SFP): The instantiation of an SFC in the > network. Packets follow a service function path from a > classifier through the requisite service functions >=20 > It the WG agrees with the usefulness of separating these concepts, but th= e > text does not convey the intended meaning, let's adjust with suggestions. Conceptually on an SN: @next_sf_locations =3D lookup_next_sf_locations($NSH); $sf_location =3D load_balance(@next_fs_locations, $NSH, $original_packet); send_to_sf_location($sf_location, $NSH, $original_packet); Where @next_sf_locations may contain: 1. location1, active 2. location2, active 3. location3, not-reachable, diag: continuity check failed This model looks to be useful (for resiliency purpose) whether the SN is ho= sting a load-balancer SF or a non-load-balancer SF. Thus: I see SFC to be a list of SFs. I see SFP to be the actual list of SF locations that packet traversed. So I agree with the usefulness of separating the terms SFC and SFC, but ... [snip from Section 2.3] When an SFC is instantiated into the network it is necessary to select the specific instances of SFs that will be used, and to create the service topology for that SFC using SF's network locator. Thus, instantiation of the SFC results in the creation of a Service Function Path (SFP) and is used for forwarding packets through the SFC. In other words, an SFP is the instantiation of the defined SFC. [snip] As Med indicated above, perhaps we do not want to restrict SFP to always be= pre-determined at the time of SFC creation. Thanks! -Nobo From nobody Wed Jul 9 07:40: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 EF2151A0AE7 for ; Wed, 9 Jul 2014 07:40:09 -0700 (PDT) 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, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=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 UKbyI9OWU7t4 for ; Wed, 9 Jul 2014 07:40:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100401A0AE6 for ; Wed, 9 Jul 2014 07:40:07 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3AD992AC5E6; Wed, 9 Jul 2014 16:40:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0BCEE158074; Wed, 9 Jul 2014 16:40:05 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 16:40:04 +0200 From: To: Ron Parker , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXx0EA///mFfCAACKycA== Date: Wed, 9 Jul 2014 14:40:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002F9CF@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.7.9.34819 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VBHKi98WE4v8S1gvjmWzeIY-wds Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 14:40:10 -0000 Ron, I'm not asking to revive RFC1383 ;-) More seriously, SF locators can be provisioned or whatever to the SFF to pe= rform its operations. This does not require an external lookup unless you d= ecide to use a name as a locator, then a resolution will be needed of cours= e.. but this is deployment-specific. Cheers, Med >-----Message d'origine----- >De=A0: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Envoy=E9=A0: mercredi 9 juillet 2014 14:41 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org >Objet=A0: RE: [sfc] Service Chains, Paths, and Load Balancers > >When I read this comment: > > [Med] I still disagree that an ordered list of locators can be >determined in advance for all deployments. I suggest that SFC forwarding b= e >based on the service chain itself (characterized as an order list of >service function identifiers). This is more compliant with the LB >constraints above: deciding which locator to use for a given flow will be = a >local decision not a centralized one. > > >"DNS" popped into my head. While this may be an imperfect analogy, a UR= L >is logical location that uses an explicit mechanism to bind it to one or >more actual network locators (i.e., IPv4 and/or IPv6). Just thinking out >loud here, but is there benefit in using a similar scheme? That the SFC >is truly logical with some sort of "Just-in-time" binding, a la DNS >(keeping in mind that DNS clients will often locally cache so as to >decrease the amount of DNS queries)? Would that approach provide >simplification and resiliency with respect to the load balancing of servic= e >functions problem -- the number of network locators for a logical service >function can change at any time due to failures or due to intentional >scale-in or scale-out? Also, this wouldn't preclude the scenario where >one or more located service functions are clustered, since the cluster >appears as a single network locator to the "DNS-like" mechanism. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >mohamed.boucadair@orange.com >Sent: Wednesday, July 09, 2014 3:05 AM >To: Joel M. Halpern; sfc@ietf.org >Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >Hi Joel, > >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 9 juillet 2014 04:40 =C0=A0: sfc@ietf.org Objet=A0:= [sfc] >>Service Chains, Paths, and Load Balancers >> >>I have been trying to figure out how to clearly answer a number of >>comments that have been made about the proposed merged archtiecture >>draft. Assuming we can get working group agreement on the intent, we >>will work to improve the wording so that readers who have not >>participated in the WG discussion will understnd it the way the working >>group intends. >> >>But what do we intend? I will try to explain my personal view, and see >>if that helps. >> >>In this regard, it is important to keep in mind that what we are >>defining is the data plane architecture. We are not attempting to >>define the architecture for the entire solution for service chaining. >>That would encompass OSS/BSS, various control and policy functions, >>virtual machine and image management, and many other aspects. > >[Med] OSS/BSS considerations are out of scope for sure, but the functional >entity(ies) responsible for the structuring of chains should be in scope >IMO. The title and the abstract of the merged draft do not exclude those: > > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. > >> >>As a result there are many things which clearly need to exist in the >>larger system, > >[Med] I don't understand what you mean by the large system. > > but which are dealt with above where we are functioning, >>and are not directly required by the work we are doing. >> >>In order to get to service chain vs service path, as I understand them, >>I need to first discuss load balancing. There are at least three >>different ways that load balancing can and will interact with service >>chaining. There probably are more. The point of the archtiecture is >>to permit all of these, but not to mandate that any particular kind be >>used in any solution. > >[Med] Agree. How load balancing is managed within a SFC-enabled domain is >up to the responsibility of the administrative entity managing that domain= . >One or a mix of these flavors can co-exist. > >> >>1) Load balancing as a service provided to the end user. This is a >>service function. It receives user packets, and modifies them (or >>marks them, or ...) so as to choose an end user service instance to >>receive the users packet. This is an important service function to be >>able to include in service chaining. It's behavior may affect >>requirements on how service chaining is done. But it has very little >>impact on the archtiecture. From an architectural pe3rspective it is >>simply a service function which may modify the underlying packet. >> >>2) There is internal load balancing. That is, one can have what >>appears to the service chaining architecture as a single point of >>contact for a specific service function, but is actually delivered by a >>collection of virtual or physical machines, possibly including one or >>several load balancers (for example using VRRP-like techniques to share >>a MAC >>address.) mostly, this is invisible to the service chaining data plane >>mechanisms. It is likely that it is visible to various control >>mechanisms, such as those responsible for scale-in, scale-out, and vm >>instantiation. The architectural impact of permitting this is largely >>that we need to be careful that our terminology does not lead readers >>to think we are prohibiting it. >> >>3) There can also be load balancing done by selecting packet paths for >>the service chaining that direct traffic to different places. We would >>not want to require that a given service function appear at only one >>place in the network. >> >>It is of course the case that these may be combined. I tend to refer >>to the collection of entities that appear to service chaining as a >>single point as a cluster. Not because cluster is a good term. But >>because I do not have another one. Thus, the point of type 3 load >>balancing is to direct different subsets of traffic to different >>singular or clustered service functions in different places in the >network. >> >>Now with that said, what do I mean when I talk about service chain and >>service path/ Service chain is a sequence of logical functions to be >>applied to a subset of packets. It is equivalent of saying that some >>subset of traffic is to get DPI, charging, content inspection, and >>firewall while a different subset is to go directly to the cache >>without visiting any other service functions. >> >>That is not enough information to direct the packets. > >[Med] A service chain can also be defined as an order list of service >function identifiers. I understand the examples you provide as liberal >description of service chains (that I thought you considered it out of >scope). A service function identifier does not necessarily hint the servic= e >offered by that SF; its purpose is to uniquely identify a SF among those >present in a SFC-enabled domain. > > A service path >>is, in some fashion, a sequence of locations in the network. > >[Med] so, this is an order list of service function locators. > > Those >>locations will be singular or clustered service function delivery >>locations. They may be addressed by IP address. They may be addressed >>as ports on an SFF. There are many different ways that the locations >>may be known to the service chaining infrastructure and the transport. >> >> From the point of view of the work of the SFC group, we need to be >>able to talk about the high level abstraction, the service chain, which >>drives the forwarding. And we need to talk about the actual data path >>packets will take in the network. >> >>Several of the comments have said "but the whole path may not be known >>at the front." > >[Med] Which is true. The entity responsible for structure the service chai= n >cannot decide in advance the actual packet of packets because of various >considerations such SF-specific LBs, but also for other traffic engineerin= g >purposes such as dispatching the traffic among two service PoPs hosting th= e >same set of SFs, etc. > > This architecture deals with that issue in two ways. >>First, as noted in item (2) on load balancers above, there can be >>decisions and behaviors which are invisible to the service chaining >>mechanisms (in much the same way that bridging within a LAN is largely >>invisible to routing between LANs.) > >[Med] Which means that you cannot determine a list of locator a priori >given that the decision on which SF instance will be invoked is the >responsibility of that LB. > > > The other provision we make is that >>reclassification can be done in mid-chain when necessary. > >[Med] Re-classification is optional and is deployment-specific. Mandating >re-classification to justify a design choice is odd. > > That will >>direct packets to a new chain. Based on information available at the >>re-classification point. > >[Med] That's not optimal for some deployments that do not require to embed >a classification function in these service functions. > >> >>I hope that this helps explain what we are after. > >[Med] I still disagree that an ordered list of locators can be determined >in advance for all deployments. I suggest that SFC forwarding be based on >the service chain itself (characterized as an order list of service >function identifiers). This is more compliant with the LB constraints >above: deciding which locator to use for a given flow will be a local >decision not a centralized one. > > > If it does, and if >>the intent is acceptable to the working group, we can figure out what >>additional words are needed to convey this. >>If the working group disagree with the intent, then we will of course >>adjust to match the working group agreements. >>If this is still unclear, I am not sure what to try next. >> >>Yours, >>Joel >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 07:42: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 73D711A0AC7 for ; Wed, 9 Jul 2014 07:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 Umays6zInIC9 for ; Wed, 9 Jul 2014 07:42:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228171A0AC5 for ; Wed, 9 Jul 2014 07:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11557; q=dns/txt; s=iport; t=1404916950; x=1406126550; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Uyy8vyoOZgnEFv3N5ZHlX6HPGBCh5FGfjf1suI67fiw=; b=jddmcwLKwMd4cx2JDhpsYiidcWjJYe2RZbe//xUf59UdAX/JrRZYwucd wl2bmmcjPA1JmObx2aS9iXCfvwAm3PgwaLNhIjSx9vUIw4KQqGqooM009 UJ8dOO+JmKGM1fMyTDTbbO38xMP26d6digu/QJISEo0r5lWNom7jKlR4p A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABlUvVOtJV2U/2dsb2JhbABPCoMOUlq/FQiHQQGBDxZ1hAMBAQEEAQEBYgkXBAIBCBEBAwEBKAcnCxQDBggCBAESG4gnDch5EwSOZjEyAgSEPQWWFkaEGoteiC6DQ4Iw X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="338745305" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 09 Jul 2014 14:42:29 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s69EgIEG000620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 14:42:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:42:18 -0500 From: "Ken Gray (kegray)" To: Ron Parker , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W1xFLfwWzB0GPcC0T+kkpD5uXpbkAgABdzYD//97ygA== Date: Wed, 9 Jul 2014 14:42:17 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.50] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dxFrjV8efGuCc-uxyR0VteOOoMM Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 14:42:22 -0000 While I can see using anycast for some generalities, I don't see us as having to solve the problem of how elasticity works =8A via any means, including DNS (avoid requirement coupling at all costs). I DO believe the path needs to resolve to a set of next-hops and can't be generic function widgets descriptors (the chain), primarily because of the on-the-fly overhead to the classifier (resolution) and the traceability (should you log the packets path as a debugging tool, what WERE the DNS records at that time if all you have are the chain). I don't think the load balancing scenario is a great example of not knowing the destination in the path a priori, so I disagree with Med and agree wholeheartedly with Joel. BUT, the fundamental point of an abstraction is to hide detail. We have a destination IP for the coupled LB and it's scaled-out function via the LB abstraction (anycast, specific, whatever) =8A why do you NEED to resolve what is inside that abstraction and put it in the path? On 7/9/14 8:40 AM, "Ron Parker" wrote: >When I read this comment: > > [Med] I still disagree that an ordered list of locators can be >determined in advance for all deployments. I suggest that SFC forwarding >be based on the service chain itself (characterized as an order list of >service function identifiers). This is more compliant with the LB >constraints above: deciding which locator to use for a given flow will be >a local decision not a centralized one. > > >"DNS" popped into my head. While this may be an imperfect analogy, a >URL is logical location that uses an explicit mechanism to bind it to one >or more actual network locators (i.e., IPv4 and/or IPv6). Just thinking >out loud here, but is there benefit in using a similar scheme? That the >SFC is truly logical with some sort of "Just-in-time" binding, a la DNS >(keeping in mind that DNS clients will often locally cache so as to >decrease the amount of DNS queries)? Would that approach provide >simplification and resiliency with respect to the load balancing of >service functions problem -- the number of network locators for a logical >service function can change at any time due to failures or due to >intentional scale-in or scale-out? Also, this wouldn't preclude the >scenario where one or more located service functions are clustered, since >the cluster appears as a single network locator to the "DNS-like" >mechanism. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >mohamed.boucadair@orange.com >Sent: Wednesday, July 09, 2014 3:05 AM >To: Joel M. Halpern; sfc@ietf.org >Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >Hi Joel, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>Envoy=E9 : mercredi 9 juillet 2014 04:40 =C0 : sfc@ietf.org Objet : [sfc] >>Service Chains, Paths, and Load Balancers >> >>I have been trying to figure out how to clearly answer a number of >>comments that have been made about the proposed merged archtiecture >>draft. Assuming we can get working group agreement on the intent, we >>will work to improve the wording so that readers who have not >>participated in the WG discussion will understnd it the way the working >>group intends. >> >>But what do we intend? I will try to explain my personal view, and see >>if that helps. >> >>In this regard, it is important to keep in mind that what we are >>defining is the data plane architecture. We are not attempting to >>define the architecture for the entire solution for service chaining. >>That would encompass OSS/BSS, various control and policy functions, >>virtual machine and image management, and many other aspects. > >[Med] OSS/BSS considerations are out of scope for sure, but the >functional entity(ies) responsible for the structuring of chains should >be in scope IMO. The title and the abstract of the merged draft do not >exclude those: > > This document describes an architecture for the specification, > creation, and ongoing maintenance of Service Function Chains (SFC) in > a network. It includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs. > >> >>As a result there are many things which clearly need to exist in the >>larger system, > >[Med] I don't understand what you mean by the large system. > > but which are dealt with above where we are functioning, >>and are not directly required by the work we are doing. >> >>In order to get to service chain vs service path, as I understand them, >>I need to first discuss load balancing. There are at least three >>different ways that load balancing can and will interact with service >>chaining. There probably are more. The point of the archtiecture is >>to permit all of these, but not to mandate that any particular kind be >>used in any solution. > >[Med] Agree. How load balancing is managed within a SFC-enabled domain is >up to the responsibility of the administrative entity managing that >domain. One or a mix of these flavors can co-exist. > >> >>1) Load balancing as a service provided to the end user. This is a >>service function. It receives user packets, and modifies them (or >>marks them, or ...) so as to choose an end user service instance to >>receive the users packet. This is an important service function to be >>able to include in service chaining. It's behavior may affect >>requirements on how service chaining is done. But it has very little >>impact on the archtiecture. From an architectural pe3rspective it is >>simply a service function which may modify the underlying packet. >> >>2) There is internal load balancing. That is, one can have what >>appears to the service chaining architecture as a single point of >>contact for a specific service function, but is actually delivered by a >>collection of virtual or physical machines, possibly including one or >>several load balancers (for example using VRRP-like techniques to share >>a MAC >>address.) mostly, this is invisible to the service chaining data plane >>mechanisms. It is likely that it is visible to various control >>mechanisms, such as those responsible for scale-in, scale-out, and vm >>instantiation. The architectural impact of permitting this is largely >>that we need to be careful that our terminology does not lead readers >>to think we are prohibiting it. >> >>3) There can also be load balancing done by selecting packet paths for >>the service chaining that direct traffic to different places. We would >>not want to require that a given service function appear at only one >>place in the network. >> >>It is of course the case that these may be combined. I tend to refer >>to the collection of entities that appear to service chaining as a >>single point as a cluster. Not because cluster is a good term. But >>because I do not have another one. Thus, the point of type 3 load >>balancing is to direct different subsets of traffic to different >>singular or clustered service functions in different places in the >>network. >> >>Now with that said, what do I mean when I talk about service chain and >>service path/ Service chain is a sequence of logical functions to be >>applied to a subset of packets. It is equivalent of saying that some >>subset of traffic is to get DPI, charging, content inspection, and >>firewall while a different subset is to go directly to the cache >>without visiting any other service functions. >> >>That is not enough information to direct the packets. > >[Med] A service chain can also be defined as an order list of service >function identifiers. I understand the examples you provide as liberal >description of service chains (that I thought you considered it out of >scope). A service function identifier does not necessarily hint the >service offered by that SF; its purpose is to uniquely identify a SF >among those present in a SFC-enabled domain. > > A service path >>is, in some fashion, a sequence of locations in the network. > >[Med] so, this is an order list of service function locators. > > Those >>locations will be singular or clustered service function delivery >>locations. They may be addressed by IP address. They may be addressed >>as ports on an SFF. There are many different ways that the locations >>may be known to the service chaining infrastructure and the transport. >> >> From the point of view of the work of the SFC group, we need to be >>able to talk about the high level abstraction, the service chain, which >>drives the forwarding. And we need to talk about the actual data path >>packets will take in the network. >> >>Several of the comments have said "but the whole path may not be known >>at the front." > >[Med] Which is true. The entity responsible for structure the service >chain cannot decide in advance the actual packet of packets because of >various considerations such SF-specific LBs, but also for other traffic >engineering purposes such as dispatching the traffic among two service >PoPs hosting the same set of SFs, etc. > > This architecture deals with that issue in two ways. >>First, as noted in item (2) on load balancers above, there can be >>decisions and behaviors which are invisible to the service chaining >>mechanisms (in much the same way that bridging within a LAN is largely >>invisible to routing between LANs.) > >[Med] Which means that you cannot determine a list of locator a priori >given that the decision on which SF instance will be invoked is the >responsibility of that LB. > > > The other provision we make is that >>reclassification can be done in mid-chain when necessary. > >[Med] Re-classification is optional and is deployment-specific. Mandating >re-classification to justify a design choice is odd. > > That will >>direct packets to a new chain. Based on information available at the >>re-classification point. > >[Med] That's not optimal for some deployments that do not require to >embed a classification function in these service functions. > >> >>I hope that this helps explain what we are after. > >[Med] I still disagree that an ordered list of locators can be determined >in advance for all deployments. I suggest that SFC forwarding be based on >the service chain itself (characterized as an order list of service >function identifiers). This is more compliant with the LB constraints >above: deciding which locator to use for a given flow will be a local >decision not a centralized one. > > > If it does, and if >>the intent is acceptable to the working group, we can figure out what >>additional words are needed to convey this. >>If the working group disagree with the intent, then we will of course >>adjust to match the working group agreements. >>If this is still unclear, I am not sure what to try next. >> >>Yours, >>Joel >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 08:01: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 3C8CB1A0197 for ; Wed, 9 Jul 2014 08:01:06 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BnkCiyf8YL3Z for ; Wed, 9 Jul 2014 08:01:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F76E1A0645 for ; Wed, 9 Jul 2014 08:01:02 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 992532AC615; Wed, 9 Jul 2014 17:01:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 77983384049; Wed, 9 Jul 2014 17:01:00 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 17:01:00 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WxKjmuDn4BEiFVdMuQoKu35uXpbkAgABmBoD//8gFkA== Date: Wed, 9 Jul 2014 15:01:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002FA41@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> In-Reply-To: <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.7.9.34819 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vz8qrYd2bHPdF6kcsBnjRac6AkY Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 15:01:06 -0000 Hi Carlos,=20 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >Envoy=E9=A0: mercredi 9 juillet 2014 15:10 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Joel M. Halpern; sfc@ietf.org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >Hi, Med, > >Please see inline, all the way at the bottom. > >On Jul 9, 2014, at 3:04 AM, mohamed.boucadair@orange.com wrote: > >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>> Envoy=E9 : mercredi 9 juillet 2014 04:40 >>> =C0 : sfc@ietf.org >>> Objet : [sfc] Service Chains, Paths, and Load Balancers >>> >>> I have been trying to figure out how to clearly answer a number of >>> comments that have been made about the proposed merged archtiecture >>> draft. Assuming we can get working group agreement on the intent, we >>> will work to improve the wording so that readers who have not >>> participated in the WG discussion will understnd it the way the working >>> group intends. >>> >> >> [Med] I still disagree that an ordered list of locators can be determine= d >in advance for all deployments. I suggest that SFC forwarding be based on >the service chain itself (characterized as an order list of service >function identifiers). This is more compliant with the LB constraints >above: deciding which locator to use for a given flow will be a local >decision not a centralized one. >> >> > >Bypassing the concept of a Service Function Path would eliminate the >abstracted nature of the Chain itself, and tie the chain to a forwarding >construct. [Med] Not sure to understand the causality effect here. We have 2 levels of= abstraction in fact:=20 (1) the one which is represented as a the set of SFs to be invoked to deliv= er a service.=20 (2) the one which reflects the actual forwarding path of a packet bound to = chain: i.e., the actual SF instances invoked when forwarding the packet in = the context of a given chain. Multiple paths can correspond to a single cha= in.=20 > >In other words, the idea of an SFC is the abstract set of service >functions, whereas the SPF is the instantiation of an actual path in the >service topology. This separation allows for the set of load-balancing >constructs described above. [Med] I don't have a problem with the separation but to assume that path is= pre-determined. I'm saying that what should be determined is the chain its= elf, not the actual path. The path may not be known in advance because of v= arious reasons mentioned in another message. That's what I'm for relying on= e service chain itself to achieve forwarding. How that information is trans= lated to a path is all about details.=20 From nobody Wed Jul 9 08:02: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 9AA5B1B2AEB; Tue, 8 Jul 2014 07:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.701 X-Spam-Level: X-Spam-Status: No, score=-12.701 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, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 NCUIGNfKrphP; Tue, 8 Jul 2014 07:52:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F6C1B2AF3; Tue, 8 Jul 2014 07:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35716; q=dns/txt; s=iport; t=1404831180; x=1406040780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JQ3eooMUAp6BTMN8ivm7l0C04NjTlzwDsOxXD2Q9uuU=; b=dfqfyVwvJixGOSAqRBQUQOtvc0+bQsOAN32HVuJ3bVtO1w3FjFuu3sKJ m4+tBFfLIoj24D9B/pEkChJQYLDsBi9XlwHGAfzXvSO+m1LkhY1ICy4u8 j3lzar86zybygHyOF9IbB69NYFzdXi1GsV/43dbiMJuyOBPSYgDXdtkN2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAGUFvFOtJA2M/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1acIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208,217";a="335402635" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jul 2014 14:52:59 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68EqwEV022467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:52:58 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:52:57 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QAACxHpA= Date: Tue, 8 Jul 2014 14: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: [10.21.119.34] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jG-Jcdu5eydWcDUBTrYtqHTkA4c X-Mailman-Approved-At: Wed, 09 Jul 2014 08:02:43 -0700 Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] YANG models for OAM X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jul 2014 14:53:06 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 K1NGQyB3b3JraW5nIGdyb3VwLg0KDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNClNlbnQ6 IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgNzo0OCBBTQ0KVG86IFFpbiBXdTsgdGltZUBpZXRmLm9y Zw0KQ2M6IGwydnBuQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IG5l dG1vZEBpZXRmLm9yZzsgdHJpbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnZvM10gWUFORyBt b2RlbHMgZm9yIE9BTQ0KDQpIaSBRaW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUu DQoNCg0KMS4gICAgICBUaG91Z2h0IFNGQyBjYW4gZ28gdXAgYW5kIGRvd24gb24gbGF5ZXJzLCB3 aGF0IGNvbnRyb2xzIHRoYXQgYmVoYXZpb3IgPyBJc6GvbnQgaXQgdGhlIFNlcnZpY2UgaGVhZGVy ID8NCg0KMi4gICAgICBJcyB0aGUgT0FNIGNvbWVzIGRvd24gdG8gZmF1bHQgaXNvbGF0aW9uLCB2 ZXJpZmljYXRpb24gLCBtb25pdG9yaW5nIGV0YyBmb3IgdGhlIHNwZWNpZmllZCBTSCA/DQoNCkxp a2UgZGlzY3Vzc2VkIGJlZm9yZSAobWFueSB0aW1lcykgZXhhY3QgZW4tY2FwIGlzIGxlc3MgaW1w b3J0YW50IHdoYXQgaXMgaW1wb3J0YW50IGlzIHRvIGhhdmUgYSBtb2RlbCB0aGF0IGRlZmluZSBP QU0gZnJhbWV3b3JrIGFuZCBzY29wZS4gQ0ZNIHRvIG15IG9waW5pb24gZG8gYW4gZXhjZWxsZW50 IGpvYiBpbiBkZWZpbmluZyB3aGF0IGlzIG5lZWRlZC4gSGVuY2UgdGhlIGNob2ljZSBvZiBhIHNp bWlsYXIgbW9kZWwgZm9yIHRoZSBZQU5HIE1vZGVsLg0KDQpZb3UgaGF2ZSBub3RlZCBCRkQgYW5k IENGTSBhcmUgc2ltaWxhciBiZWNhdXNlIHRoZXkgaGF2ZSBzaW1pbGFyIHNldCBvZiB0aW1lcnMu IFRoYXQgaXMgYSB3cm9uZyBjb21wYXJpc29uLiBIYXZlIHNpbWlsYXIgc2V0IG9mIHRpbWVycyBk b2VzIG5vdCBtYWtlIHR3byBwcm90b2NvbHMgdGhlIHNhbWUuIFdoYXQgbWFrZXMgdGhlbSBpcyB3 aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQga2V5IHdvcmQgQ0ZNIGhl cmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNlcHRzIGZvcm0gQ0ZNIHRo ZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVkLg0KDQpJIGhhdmUgcmVx dWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRNT0Qgd29ya2luZyBncm91 cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhvdyBlYWNoIG9uZSBvZiB0 aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRlZCBoZXJlLg0KDQpGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDA4LCAyMDE0IDU6MDcgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGlt ZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRo ZXJlIGFyZSBtYW55IG9wdGlvbnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMg SGVhZGVyIGV4dGVuc2lvbiwgR2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4 aXN0aW5nIE9BTSBwcm90b2NvbHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBh ZGRyZXNzIE9BTSBmb3IgdGhlIHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZD IGhhdmVuoa90IGRldmVsb3BlZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIg My4NCg0KQmVmb3JlIHRoZXkgZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBm aWd1cmUgb3V0IHdoZXRoZXIgdGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRl bnQgT0FNIHByb3RvY29sLA0KT3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wg c2luY2UgU0ZDIE9BTSBhbmQgT3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVz KGUuZy4sIGJvdGggY2FuIHVzZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9m IG92ZXJsYXkgbm9kZSBvciBzZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRo KS4gV2h5IG5vdCBidWlsZCBvbmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9z IHdoeSB3ZSBicmluZyB1cCB0cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlv dXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25z b2xpZGF0ZSBPQU0gaW4gYm90aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0t MDINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVs dGktbGF5ZXItb2FtLXVzZS1jYXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3 aHkgbm90IHJldXNlIGVudHJvcHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWlu ZyB0cmFuc3BvcnQuIEhvdyBpcyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9p Y2UgeW91IHByb3Bvc2VkIGluIHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdCwgSUVFRSA4MDIuMWFnIG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVj aGFuaXNtIGluc3RlYWQgb2YgRUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5 b3UgcHJvcG9zaW5nIHRvIGNvbWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0 aCBFQ01QIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBh dCB0aGUgc2FtZSB0aW1lIGluIHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVF IDgwMi4xYWcgQ0ZNIHNoYXJlIGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2 YWwsIEJGRCBpbnRlcnZhbC4gSWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxs eSBuZWVkIHRvIHRoaW5rIGFib3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0 aGUgbWFuYWdlbWVudCBwbGFuZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2Fu IGRlZmluZSBmb3IgYm90aD8gSG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2Ug dGhlbSBtb3JlIGV4dGVuc2libGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqx vOQ6IDIwMTTE6jbUwjMwyNUgMDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFp bHRvOnRpbWVAaWV0Zi5vcmc+DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRm Lm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6 IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3 YXkgdGhpcyBpcyBhcHBsaWNhYmxlIHRvIFNGQw0KDQoNCjEuICAgICAgU0ZDIGlzIHVuZGVybGF5 ZXIgaW5kZXBlbmRlbnQgLCB3aGljaCBtZWFucyBpdCBjYW4gaGF2ZSBhbGwgc29ydHMgb2YgZW5j YXAgdHlwZXMgdW5kZXJuZWF0aCwgdGhlIG1vZGVsIHByZXNlbnRlZCBpbiB0aXNzYS1uZXRtb2Qt b2FtLCBhZGRyZXNzIGV4YWN0bHkgdGhhdCBpc3N1ZS4gSW5zdGVhZCBvZiByZS1pbnZlbnRpbmcg YW5kIHJlLWltcGxlbWVudGluZyB2YXJpb3VzIGRpZmZlcmVudCBPQU0gdGhlIGRyYWZ0IHByb3Bv c2UgdG8gaW50ZWdyYXRlIHRoZW0gYXQgdGhlIG1hbmFnZW1lbnQgbGF5ZXIuDQoNCjIuICAgICAg SW4gdGhpcyBkcmFmdCB3ZSBkZWZpbmUgYSBmbG93LWVudHJvcHkgYXMgYW4gb3BhcXVlIGVsZW1l bnQgdGhhdCBlYWNoIG9mIHRoZSB0ZWNobm9sb2d5IHR5cGUgY2FuIHNwZWNpZnkgYW5kIGluY2x1 ZGUuIElmIHdlIGxvb2sgYXQgZHJhZnQtcXVpbm4tc2ZjLW5zaC0wMi50eHQsIGl0IGRlZmluZSBh IGJsb2NrIHRoYXQgc3BlY2lmaWVzIFNGQy4gU0ZDIHZlcnNpb24gb2YgWUFORyAgY2FuIHNwZWNp ZnkgdGhpcyBhcyBwYXJ0IG9mIGl0cyBmbG93IGVudHJvcHkuIFRoZSBiZWF1dHkgaXMgdGhhdCBp dCBpcyBhbGwgdXAgdG8gdGhlIHRlY2hub2xvZ3kgdG8gc3BlY2lmeSB0aGF0IChzaXplIGFuZCBz aGFwZSBpcyB0ZWNobm9sb2d5IGRlcGVuZGVudCkgYW5kIGJhc2UgbW9kZWwgaXMgc3RpbGwgaW50 YWN0Lg0KDQpXaXRoIHRoZSBhYm92ZSBpbiBtaW5kICwgY2FuIHlvdSBwbGVhc2UgcmV2aWV3IGRy YWZ0LXRpc3NhLW5ldG1vZC1vYW0gYW5kIHNlZSBpdCBpcyBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJs ZSBlbm91Z2ggdG8gZm9yIHRoZSBwdXJwb3NlLiBJZiB0aGluZ3MgYXJlIG1pc3Npbmcgd2UgY2Fu IGFkZCBhbmQgZXh0ZW5kLg0KDQpJIGhhdmUgcmVxdWVzdGVkIG5ldG1vZCBXRyBjaGFpcnMgZm9y IGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQu DQoNCkZyb206IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEp1bmUgMTAsIDIwMTQgOToyMiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpOyB0aW1lQGlldGYub3JnPG1haWx0bzp0aW1lQGlldGYub3JnPg0KQ2M6IG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0Bp ZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3Bz YXdnQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KSGksIFRp c3NhOg0KVGhhbmtzIGZvciBpbml0aWF0aW5nIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NClVu aWZpZWQgT0FNIGZvciBtdWx0aS1MYXllciBuZXR3b3JrIGlzIGEgZ29vZCBpZGVhIHRvIG1lLg0K ZHJhZnQtd3ctb3BzYXdnLW11bHRpLWxheWVyLW9hbS0wMCB3ZSBwcm9wb3NlZCBpbiBvcHNhd2cg bGFpZCBvdXQgdGhlIGFuIGluaXRpYWwgZGVzY3JpcHRpb24gb2YgdGhlIHByb2JsZW0uDQpUaGUg cXVlc3Rpb24gdG8gZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBpcw0KSSBhbSB3b25kZXJpbmcgaG93 IHRoaXMgZ2VuZXJpYyBZYW5nIE1vZGVsIGNhbiBiZSBhcHBsaWVkIHRvIFNGQyBlbnZpcm9ubWVu dD8NCkhvdyBkbyB5b3Ugc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSB0d28gZW5kcG9pbnRzIHN1cHBv cnQgZGlmZmVyZW50IGxheWVyIE9BTSBvciBkb2VzbqGvdCBzdXBwb3J0IGFueSBPQU0gYXQgdGhh dCBsYXllci4NCg0KQlRXOiBJIGhhdmUgY2Ohr2VkIHRpbWUgbWFpbGluZyBsaXN0IHNpbmNlIEkg YmVsaWV2ZSB0aGlzIG1haWxpbmcgbGlzdCBpcyBwdXJwb3NlZCB0byBsb29rIGZvciBnZW5lcmlj IGFuZCBpbnRlZ3JhdGVkIE9BTSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMgbmV0d29y a2luZyB0ZWNobm9sb2dpZXMuDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjExyNUgMzowMw0KytW8/sjLOiBuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZz4NCtb3zOI6IFtuZXRtb2RdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KQWxsDQoN CldlIGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwgZm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxh Y2UgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBPQU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBm b3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIgYW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0 aGUgY29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCwNCg0KDQoxLiAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vDQoN CjMuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmls bC15YW5nLW9hbS8NCg0KUGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cw0KDQpU aGFua3MNClRpc3NhDQoNCg0K --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+SFC working group= .

 

From: nvo3 [ma= ilto:nvo3-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Tuesday, July 08, 2014 7:48 AM
To: Qin Wu; time@ietf.org
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

 

Hi Qin

 

May be a point is miss= ed here.

 

1.&n= bsp;     Thought SFC ca= n go up and down on layers, what controls that behavior ? Is=A1=AFnt it the= Service header ?

2.&n= bsp;     Is the OAM com= es down to fault isolation, verification , monitoring etc for the specified= SH ?

 

Like discussed before = (many times) exact en-cap is less important what is important is to have a = model that define OAM framework and scope. CFM to my opinion do an excellen= t job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

You have noted BFD and= CFM are similar because they have similar set of timers. That is a wrong c= omparison. Have similar set of timers does not make two protocols the same.= What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lo= ts of concepts form CFM there are things that needed to be revisited.<= /o:p>

 

I have requested prese= ntation slots in nvo3 and NETMOD working groups and will be going through i= n details how each one of the technologies map to YANG model presented here= .

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

There= are many options for SFC OAM, BFD extension, Generic Header extension, Gen= eric TLV extension.

Unlik= e other existing OAM protocols, mechanisms and tools, SFC need to address O= AM for the technology that is above layer 3.

SFC h= aven=A1=AFt developed OAM protocol yet at the top of layer 3.

=  

Befor= e they developing OAM protocol, they need to figure out whether they need t= o develop technology dependent OAM protocol,

Or te= chnology independent OAM protocol since SFC OAM and Overlay OAM share a lot= of similarities(e.g., both can use overlay technology to stitch a set of o= verlay node or service node to form the end to end path). Why not build one protocol to support both?

=  

That= =A1=AFs why we bring up transport independent OAM covering various heteroge= neous network technologies and propose to consolidate OAM in both

Manag= ement plane and data plane.

http://tools.ietf.org/html/draft-ww-opsawg-multi-laye= r-oam-02

http://tools.ietf.org/html/draft-= king-opsawg-time-multi-layer-oam-use-case-01.txt

=  

Regar= ding flow-entropy, why not reuse entropy mechanisms in the existing underly= ing transport. How is flow entropy different from ECMP choice you proposed = in the draft.

If my= understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) = mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are y= ou proposing to combine ECT supported by IEEE 802.1ag with ECMP supported b= y IEEE 802.1Qbp and use them together at the same time in the same network?=

=  

Also = BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BF= D interval. If we integrate them together, we really need to think about ho= w to integrate them together in the management plane. Is there any common component we can define for both? Ho= w we define these component and make them more extensible.

=  

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin

 

There are several way = this is applicable to SFC

 

1.&n= bsp;     SFC is underla= yer independent , which means it can have all sorts of encap types undernea= th, the model presented in tissa-netmod-oam, address exactly that issue. In= stead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the managemen= t layer.

2.&n= bsp;     In this draft = we define a flow-entropy as an opaque element that each of the technology t= ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d= efine a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. Th= e beauty is that it is all up to the technology to specify that (size and s= hape is technology dependent) and base model is still intact.

 

With the above in mind= , can you please review draft-tissa-netmod-oam and see it is flexible and = extensible enough to for the purpose. If things are missing we can add and = extend.

 

I have requested netmo= d WG chairs for a presentation slot for further discussion of the draft. &n= bsp;

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

Thank= s for initiating discussion on this topic.

Unifi= ed OAM for multi-Layer network is a good idea to me.

draft= -ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial= description of the problem.

The q= uestion to draft-tissa-netmod-oam is

I am = wondering how this generic Yang Model can be applied to SFC environment?

How d= o you support the case where two endpoints support different layer OAM or d= oesn=A1=AFt support any OAM at that layer.

=  

BTW: = I have cc=A1=AFed time mailing list since I believe this mailing list is pu= rposed to look for generic and integrated OAM covering various heterogeneou= s networking technologies.

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: netmod [mailto:= netmod-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevi= r)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for O= AM

 

All

 

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o= am/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang= -oam/

 

Please review and share your comments

 

Thanks

Tissa

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_-- From nobody Wed Jul 9 08:09: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 B86831A0AC7 for ; Wed, 9 Jul 2014 08:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw2jc0eNCs0n for ; Wed, 9 Jul 2014 08:09:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD4A1A0396 for ; Wed, 9 Jul 2014 08:09:28 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 62b5db35.0.7721197.00-2353.18324270.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 15:09:28 +0000 (UTC) X-MXL-Hash: 53bd5b28298af028-917e008e761f4954096ba5ba28ccf26d93ee1690 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69F9PGV006516; Wed, 9 Jul 2014 11:09:25 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69F9F5E006300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 11:09:20 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 15:09:04 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 11:08:30 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuX1QjA Date: Wed, 9 Jul 2014 15:08:30 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D42038@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> In-Reply-To: <53BCAB74.4060801@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jftlN24UKz2yHHQniukA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Hzv8hnNZTGk6bYjQbX9Trporwh0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 15:09:30 -0000 Joel, > 2) There is internal load balancing. That is, one can have what appears > to the service chaining architecture as a single point of contact for a > specific service function, but is actually delivered by a collection of > virtual or physical machines, possibly including one or several load > balancers (for example using VRRP-like techniques to share a MAC > address.) mostly, this is invisible to the service chaining data plane > mechanisms. It is likely that it is visible to various control > mechanisms, such as those responsible for scale-in, scale-out, and vm > instantiation. The architectural impact of permitting this is largely > that we need to be careful that our terminology does not lead readers to > think we are prohibiting it. I would make a stronger statement here: that any SFC solution not only does= not prohibit it but makes it possible. Any SFC solution has to make it po= ssible for a service in a service chain to scale horizontally to 10 or even= 100s of instances.=20 =20 > 3) There can also be load balancing done by selecting packet paths for > the service chaining that direct traffic to different places. We would > not want to require that a given service function appear at only one > place in the network. Yes, this is also very important. Ideally, one would like to have the same= solution for (2) and (3). Maria From nobody Wed Jul 9 09:18: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 655CF1A0331 for ; Wed, 9 Jul 2014 09:18:54 -0700 (PDT) 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 hv6y7SdIDq5b for ; Wed, 9 Jul 2014 09:18:50 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562501A0067 for ; Wed, 9 Jul 2014 09:18:50 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s69GEcbo017257; Wed, 9 Jul 2014 09:18:49 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1myy3shn84-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Jul 2014 09:18:49 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Jul 2014 09:18:48 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Wed, 9 Jul 2014 09:18:48 -0700 From: ramki Krishnan To: "meng.wei2@zte.com.cn" , "sfc@ietf.org" Date: Wed, 9 Jul 2014 09:18:46 -0700 Thread-Topic: [sfc] [SFC] Comments of draft-krishnan-sfc-oam-req-framework Thread-Index: Ac+aWQ6EceNrrNVZQjekcPf4lcvKSABMxAmQ Message-ID: References: <007d01cf9a54$e9400110$bbc00330$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8855HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-09_05:2014-07-09,2014-07-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090194 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jGH9UbiNbafOVeMz7zUFHsYWl8o Subject: Re: [sfc] [SFC] Comments of draft-krishnan-sfc-oam-req-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, 09 Jul 2014 16:18:55 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8855HQ1EXCH01corp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Meng, Thanks for the comments. Please find inline. Thanks, Ramki From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of meng.wei2@zte.com.cn Sent: Monday, July 07, 2014 8:02 PM To: sfc@ietf.org Subject: [sfc] [SFC] Comments of draft-krishnan-sfc-oam-req-framework Hi co-authors=1B$B!$=1B(B guys=1B$B!$=1B(B Here are two comments and questions on this draft. 1) +---+ +-+ +-+ +---+ |NVE|-|B|-|B|-|NVE| +---+ +-+ +-+ +---+ x---x L2 I don't know why B&B are between NVEs rather than "L3 network". If refer to draft-ietf-nvo3-arch-01, here should be "R" and IP-OAM. Ramki: This is an exemplary depiction and not exhaustive - it is hard to co= ver all the possibilities in a single line in a figure; we will try to make= this figure better as we evolve the draft. Please see text from draft belo= w clarifying this aspect. The SFC layer resides above the transport layer (where the transport layer can simply be implemented using VLANs or may be done using overlays such as VXLAN or NVGRE), and below the application layer (APP). Depending on the underlying network technology, other OAM layers may be present (NVO3 OAM [NVO3 OAM], L3/MPLS OAM [RFC 7276], IEEE 802.1ag CFM [IEEE 802.1ag], etc.). The use of the terms maintenance end point (MEP) and maintenance (MIP) are consistent with IEEE 802.1Q are simply used to denote points where monitoring services are configured. 2) +-+ +--+ +-+ +-+ +--+ |B|-|SF|-|R|-|R|-|SF| +-+ +--+ +-+ +-+ +--+ Classifer is the beginning of SFC, there might be a overlay network between a classifer and an SF. I'm not sure classifer should be disscussed here and there might exist an OAM mechanism between classifers and SFs. Ramki: We don=1B$B!G=1B(Bt have any text on classifier. Can you please clar= ify your question ? 2) Any other scenarios? Only DC is not sufficient. I propose to add some broadband & mobility scenarios. Ramki: We are not restricting this draft to DCs. Please see my first commen= t. Also, what do you see additionally needed for broadband and mobility sce= narios ? Thanks, Wei --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8855HQ1EXCH01corp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Meng,<= o:p>

 

Thanks for the comments. Please find inline.<= o:p>

 

Thanks,

Ramki

&nb= sp;

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of meng.wei2@zte.com.cn
Sent: Monday, July 0= 7, 2014 8:02 PM
To: sfc@ietf.org
Subject: [sfc] [SFC] C= omments of draft-krishnan-sfc-oam-req-framework

 


Hi co-authors=1B$B!$=1B(B guys=1B$B!$=1B(B

Here are two comme= nts and questions on this draft.

1)
+---+ +-+ +-+ +---+
= |NVE|-|B|= -|B|-|NVE|
+---+ +-+ +-+ +---+
       x---x   =        L2


I don't know why B&B are betwee= n NVEs rather than "L3 network".
If refer to draft-ietf-nvo3-ar= ch-01, here should be "R" and IP-OAM.

 

Ramki: This is an exemplary depict= ion and not exhaustive - it is hard to cover all the possibilities in a sin= gle line in a figure; we will try to make this figure better as we evolve t= he draft. Please see text from draft below clarifying this aspect.

 

The SFC layer resides above the transport layer (wher= e the transport

 &nbs= p; layer can simply be implemented using VLANs or may be done using

   overlays such as VXL= AN or NVGRE), and below the application layer

   (APP).  Depending on the underlying n= etwork

   techno= logy, other OAM layers may be present (NVO3 OAM [NVO3 OAM],

   L3/MPLS OAM [RFC 7276], IEEE= 802.1ag CFM [IEEE 802.1ag], etc.).  The

   use of the terms maintenance end point (ME= P) and maintenance (MIP)

&= nbsp;  are consistent with IEEE 802.1Q are simply used to denote point= s

   where monit= oring services are configured.

2)
+-= + +--+ +-+ +-+ +--+
|B|-|SF|-|R|-|R|-|SF|
+-+ +--+ +-+ +-+ +--+ =
Class= ifer is the beginning of SFC, there might be a overlay network
<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>between a = classifer and an SF. I'm not sure classifer should be disscussed here and= there might exist an OAM mechanism between classifers and SFs.

 

Ramki: We don=1B$B= !G=1B(Bt have any text on classifier. Can you please clarify your question = ?

2) Any other scenarios? Only DC is not sufficient. I propose to
ad= d some broadband & mobility scenarios.

 

Ramki: We are not restricting this draf= t to DCs. Please see my first comment. Also, what do you see additionally n= eeded for broadband and mobility scenarios ?

Thanks,
Wei

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8855HQ1EXCH01corp_-- From nobody Wed Jul 9 10:59: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 A32C11A0B12 for ; Wed, 9 Jul 2014 10:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 EOUdVQ3hlrut for ; Wed, 9 Jul 2014 10:59:42 -0700 (PDT) Received: from mxebdp04ex-public.idz.gs.com (mxe6.gs.com [207.17.33.102]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7F21A0395 for ; Wed, 9 Jul 2014 10:59:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,632,1400040000"; d="scan'208,217";a="125192363" Received: from unknown (HELO mxpbd02-public.ny.fw.gs.com) ([148.86.115.129]) by mxebdp04ex.idz.gs.com with ESMTP; 09 Jul 2014 13:59:41 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp15ex.firmwide.corp.gs.com ([10.135.172.24]) by mxpbd02.ny.fw.gs.com with ESMTP; 09 Jul 2014 13:59:41 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp15ex.firmwide.corp.gs.com ([10.135.172.24]) with mapi; Wed, 9 Jul 2014 13:59:40 -0400 To: "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Date: Wed, 9 Jul 2014 13:59:37 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8Wz+avP3VyDEaNuxmFkkx26ZuXpbkAgABl84D//7ubUIAANNtA Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708D66CF0GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zqq7ZB7U6R6esx77ODfW9mtEi30 Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 17:59:46 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66CF0GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Nobo and Med. But I do have questions of my own, which may alr= eady have been discussed. (Apologies if that's the case.) 1. I don't see how it's possible to predetermine the SFP with load bal= ancers in the middle - IF an SFP is defined as the entire path between the = client and the end server (whatever that end server happens to be. See my p= oint 2.) o Load balancers, by definition, choose the next backend entity to lo= ad balance to, based on the configured LB algorithm (e.g., round robin, lea= st response time, etc.), which can be overridden by persistence/stickiness = requirements (as well as other custom methods). * How does the "system" know in advance which backend needs to be sel= ected? If it does take on that role in some fashion, the system has taken o= n the role of the load balancer. * Even if the system somehow knows which backend entity the load bala= ncer will choose the first time, subsequent connections may be overridden. o And let's not forget the return path. (I haven't seen any discussio= ns on it; though it's possible I may have missed it.) Many load balancers a= re TCP (in many cases HTTP/SSL) proxys. This requires the return traffic to= traverse the same LB. So when we talk about creating the service "path", o= r service "chain", we'll also need to ensure that the return traffic someho= w gets back to the original LB. 2. But must we define the SFP as such-in an expansive way? Why can't t= he SFP be shorter (say, demarcated at the 5-tuple level)? E.g., why can't w= e have an SFP between the client and the LB, and another SFP between the LB= and the server? 3. If we define the SFP as the entire end-to-end flow, then, we must f= irst define what that means! What's the demarcation? When does an SFP end? = If SFPs can be shorter, then can't we have correspondingly scoped SFCs as w= ell? Wouldn't we then be able to bypass some of the complications introduce= d by the middle boxes like load balancers? Myo -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) Sent: 9 July 2014 10:31 AM To: Carlos Pignataro (cpignata); Med Boucadair Cc: Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Carlos, Joel, Med, et al, > > [Med] I still disagree that an ordered list of locators can be > > determined in > advance for all deployments. I suggest that SFC forwarding be based on > the service chain itself (characterized as an order list of service > function identifiers). This is more compliant with the LB constraints > above: deciding which locator to use for a given flow will be a local > decision not a centralized one. > > > > > > Bypassing the concept of a Service Function Path would eliminate the > abstracted nature of the Chain itself, and tie the chain to a > forwarding construct. > > In other words, the idea of an SFC is the abstract set of service > functions, whereas the SPF is the instantiation of an actual path in the = service topology. > This separation allows for the set of load-balancing constructs > described above. > > Please note that none of this talks about a centralized versus a local > decision. > > To take it more concrete, these are the actual definitions in draft-merge= d: > > Service Function Chain (SFC): A service Function chain defines an > ordered set of service functions that must be applied to packets > and/or frames selected as a result of classification. The > implied order may not be a linear progression as the > architecture allows for nodes that copy to more than one branch. > The term service chain is often used as shorthand for service > function chain. > > Service Function Path (SFP): The instantiation of an SFC in the > network. Packets follow a service function path from a > classifier through the requisite service functions > > It the WG agrees with the usefulness of separating these concepts, but > the text does not convey the intended meaning, let's adjust with suggesti= ons. Conceptually on an SN: @next_sf_locations =3D lookup_next_sf_locations($NSH); $sf_location =3D loa= d_balance(@next_fs_locations, $NSH, $original_packet); send_to_sf_location(= $sf_location, $NSH, $original_packet); Where @next_sf_locations may contain: 1. location1, active 2. location2, active 3. location3, not-reachable, diag: continuity check failed This model looks to be useful (for resiliency purpose) whether the SN is ho= sting a load-balancer SF or a non-load-balancer SF. Thus: I see SFC to be a list of SFs. I see SFP to be the actual list of SF locations that packet traversed. So I agree with the usefulness of separating the terms SFC and SFC, but ... [snip from Section 2.3] When an SFC is instantiated into the network it is necessary to select the specific instances of SFs that will be used, and to create the service topology for that SFC using SF's network locator. Thus, instantiation of the SFC results in the creation of a Service Function Path (SFP) and is used for forwarding packets through the SFC. In other words, an SFP is the instantiation of the defined SFC. [snip] As Med indicated above, perhaps we do not want to restrict SFP to always be= pre-determined at the time of SFC creation. Thanks! -Nobo _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66CF0GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Nobo and Med. But I do have quest= ions of my own, which may already have been discussed. (Apologies if that&#= 8217;s the case.)
 
  1. I don't see how it's possible to predetermine the SFP with load balance= rs in the middle – IF an SFP is defined as the entire path bet= ween the client and the end server (whatever that end server happens to be.= See my point 2.)
    2.
  • Load balancers, by definition, choose the next backend entity to load b= alance to, based on the configured LB algorithm (e.g., round robin, least r= esponse time, etc.), which can be overridden by persistence/stickiness requ= irements (as well as other custom methods).
    •
  • How does the "system" know in advance which backend needs to = be selected? If it does take on that role in some fashion, the system has t= aken on the role of the load balancer.
  • Even if the system somehow k= nows which backend entity the load balancer will choose the first time, sub= sequent connections may be overridden.
    •
  • And let's not forget the return path. (I haven't seen any discussions o= n it; though it's possible I may have missed it.) Many load balancers are T= CP (in many cases HTTP/SSL) proxys. This requires the return traffic to tra= verse the same LB. So when we talk about creating the service "path", or service “chain”= , we'll also need to ensure that the return traffic somehow gets back to th= e original LB.
    •
 
  1. But must we define the SFP as such—in an expansive way? Why can&#= 8217;t the SFP be shorter (say, demarcated at the 5-tuple level)? E.g., why= can’t we have an SFP between the client and the LB, and another SFP = between the LB and the server?
    2.
 
  1. If we define the SFP as the entire end-to-end flow, then, we must first= define what that means! What’s the demarcation? When does an SFP end= ? If SFPs can be shorter, then can’t we have correspondingly scoped S= FCs as well? Wouldn’t we then be able to bypass some of the complications introduced by the middle boxes like load b= alancers?
    2.
 
Myo
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Nobo Akiya (nobo)
Sent: 9 July 2014 10:31 AM
To: Carlos Pignataro (cpignata); Med Boucadair
Cc: Joel M. Halpern; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
 
Hi Carlos, Joel, Med, et al,
 
> > [Med] I still disagree that an ordered list of locators can = be
> > determined in
> advance for all deployments. I suggest that SFC forwarding be bas= ed on
> the service chain itself (characterized as an order list of servi= ce
> function identifiers). This is more compliant with the LB constra= ints
> above: deciding which locator to use for a given flow will be a l= ocal
> decision not a centralized one.
> >
> >
>
> Bypassing the concept of a Service Function Path would eliminate = the
> abstracted nature of the Chain itself, and tie the chain to a
> forwarding construct.
>
> In other words, the idea of an SFC is the abstract set of service=
> functions, whereas the SPF is the instantiation of an actual path= in the service topology.
> This separation allows for the set of load-balancing constructs <= /div>
> described above.
>
> Please note that none of this talks about a centralized versus a = local
> decision.
>
> To take it more concrete, these are the actual definitions in dra= ft-merged:
>
>    Service Function Chain (SFC):  A service F= unction chain defines an
>         ordered set of se= rvice functions that must be applied to packets
>         and/or frames sel= ected as a result of classification.  The
>         implied order may= not be a linear progression as the
>         architecture allo= ws for nodes that copy to more than one branch.
>         The term service = chain is often used as shorthand for service
>         function chain.
>
>    Service Function Path (SFP):  The instanti= ation of an SFC in the
>         network.  Pa= ckets follow a service function path from a
>         classifier throug= h the requisite service functions
>
> It the WG agrees with the usefulness of separating these concepts= , but
> the text does not convey the intended meaning, let's adjust with = suggestions.
 
Conceptually on an SN:
 
@next_sf_locations =3D lookup_next_sf_locations($NSH); $sf_location = =3D load_balance(@next_fs_locations, $NSH, $original_packet); send_to_sf_lo= cation($sf_location, $NSH, $original_packet);
 
Where @next_sf_locations may contain:
1. location1, active
2. location2, active
3. location3, not-reachable, diag: continuity check failed
 
This model looks to be useful (for resiliency purpose) whether the SN = is hosting a load-balancer SF or a non-load-balancer SF.
 
Thus:
 
I see SFC to be a list of SFs.
I see SFP to be the actual list of SF locations that packet traversed.=
 
So I agree with the usefulness of separating the terms SFC and SFC, bu= t ...
 
[snip from Section 2.3]
   When an SFC is instantiated into the network it is necess= ary to
   select the specific instances of SFs that will be used, a= nd to create
   the service topology for that SFC using SF's network loca= tor.  Thus,
   instantiation of the SFC results in the creation of a Ser= vice
   Function Path (SFP) and is used for forwarding packets th= rough the
   SFC.  In other words, an SFP is the instantiation of= the defined SFC.
[snip]
 
As Med indicated above, perhaps we do not want to restrict SFP to alwa= ys be pre-determined at the time of SFC creation.
 
Thanks!
 
-Nobo
 
_______________________________________________
sfc mailing list
 
 --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66CF0GSCMAMP19EXfi_-- From nobody Wed Jul 9 11:54: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 E90A41A036D for ; Wed, 9 Jul 2014 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.652 X-Spam-Level: X-Spam-Status: No, score=-7.652 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.651, 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 NDJNGiLolsaI for ; Wed, 9 Jul 2014 11:54:22 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C4B1A0332 for ; Wed, 9 Jul 2014 11:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1404932063; x=1436468063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1oakAN0IC62HHT0Z6YSyipj1oKkKXkltczNkALG0e/Q=; b=SkHqv7spaoSWmkW8QmiRdMRDpsjpDF4dAQqZ9dXHODXvXeZMpxa1trI4 r6kJadJvTUGj2UHdLjuIyyFio5+V6AVP+aI5EpJg+L4TYotmBa7Y2YYl+ QebHLU96IYNLPmgUeYRcDvJgfvYJYTzpmfEy14xexzFRhd6UDi68FkluB s=; X-IronPort-AV: E=Sophos;i="5.01,632,1400025600"; d="scan'208";a="121261065" X-IPAS-Result: AqMEAB+PvVPAqArr/2dsb2JhbABag2BavxyHRAGBJnWEBAEBBA4sKxQQAgEIIhQQMiUCBAENDdEXF48RMQeDLYEWBZZcj3iLcYIw Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 09 Jul 2014 18:54:22 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 11:54:21 -0700 From: Ian Smith To: "Zarny, Myo" , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgABl8oCAABa+gIAAOkGA//+RfCE= Date: Wed, 9 Jul 2014 18:54:21 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5hzX_2MXPAx9sTOVRQcnTPgzK1M Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 18:54:25 -0000 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example:=0A= =0A= service-chain 100 {=0A= 10 url-filter=0A= 20 web-cache=0A= 30 web-optimizer=0A= 40 firewall=0A= }=0A= =0A= Translation: send to instances of these 4 services in this order.=0A= =0A= 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example:=0A= =0A= service-function url-filter {=0A= dns _http._tcp.url-filter.example.com=0A= fallback bypass=0A= }=0A= =0A= Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function.=0A= =0A= 3. You may define a service function conditionally. Example:=0A= =0A= service-function web-optimizer {=0A= if { [class match [HTTP::url] eq optimizable-content] } {=0A= ip 2001:db8:0:22::137.80=0A= } else {=0A= service-function firewall=0A= }=0A= } =0A= =0A= Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall.=0A= =0A= 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example:=0A= =0A= service-function web-cache {=0A= lb carp [HTTP::url] @2001:db8:0:21::224.80=0A= } =0A= =0A= Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic.=0A= =0A= 5. You may load balance directly in the path selection process. Example:= =0A= =0A= service-function firewall {=0A= pool {=0A= least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections}=0A= ip 2001:db8:23::130=0A= ip 2001:db8:23::131=0A= ip 2001:db8:23::132=0A= ip 2001:db8:23::133=0A= } =0A= }=0A= =0A= Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections.=0A= =0A= 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example:=0A= =0A= service-function url-filter {=0A= opaque=0A= dns _http._tcp.url-filter.example.com=0A= }=0A= =0A= Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain.=0A= =0A= =0A= From nobody Wed Jul 9 12:07: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 4F0D81B27AF for ; Wed, 9 Jul 2014 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSnmQFcy_on5 for ; Wed, 9 Jul 2014 12:07:00 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A0B1B27AA for ; Wed, 9 Jul 2014 12:06:59 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 2d29db35.0.5608492.00-1995.15497126.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 09 Jul 2014 19:06:59 +0000 (UTC) X-MXL-Hash: 53bd92d375711de3-27b5f48c838c05c96bef0299b84051e39a7e642e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69J6v5q017838; Wed, 9 Jul 2014 15:06:58 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69J6js6017528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 15:06:52 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 19:06:28 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 15:06:27 -0400 From: "NAPIERALA, MARIA H" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yA= Date: Wed, 9 Jul 2014 19:06:27 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=iZaEh1TM1Nudkxe1bzUA:9 a=CjuIK1q_8ugA:10 a=bLxgk_] X-AnalysisOut: [TGzasA:10 a=WwcCu2TKFuMA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pyRIh-8LycBi_mk4hcbJmyi9bfQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 19:07:03 -0000 > [Med] I still disagree that an ordered list of locators can be determined= in > advance for all deployments. I suggest that SFC forwarding be based on th= e > service chain itself (characterized as an order list of service function > identifiers). This is more compliant with the LB constraints above: decid= ing > which locator to use for a given flow will be a local decision not a > centralized one. Absolutely. I cannot imagine how else it can be done. Maria From nobody Wed Jul 9 12:41: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 6999C1A0418 for ; Wed, 9 Jul 2014 12:40:59 -0700 (PDT) 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 C2y3kcHmigOz for ; Wed, 9 Jul 2014 12:40:58 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1EC1A0401 for ; Wed, 9 Jul 2014 12:40:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id D790852126A; Wed, 9 Jul 2014 12:40:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 031BE5211F2; Wed, 9 Jul 2014 12:40:56 -0700 (PDT) Message-ID: <53BD9AC8.5080904@joelhalpern.com> Date: Wed, 09 Jul 2014 15:40:56 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kwpXJVwvZXF6OYc_8F1B2lg4ySM Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 19:40:59 -0000 The archtiecture allows for this local decision, while still having the global decision that is directing the traffic. That is, the global decision directs the traffic to places in the network. Those places may be singular or clusters. If they are clusters, those clusters can use any number of algorithms to distribute the traffic internally, without any effect on service chaining. (And yes, this can be done in such a way that return traffic, if delivered globally to the same place, can then be delivered to the right internal state.) The definition of the service path is about how service chaining will direct the traffic. it is not about how the internal load balancing is doen, as there are MANY ways to do that, and they can give the same external interface. We could write the architecture pretending that it always addresses singular instances, but knowing that reality would allow load balanced clusters at those locations. But that would be a misleading architectural description and might be read to outlaw some solutions that fall within the goal the WG wishes to meet. Yours, Joel On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >> [Med] I still disagree that an ordered list of locators can be determined in >> advance for all deployments. I suggest that SFC forwarding be based on the >> service chain itself (characterized as an order list of service function >> identifiers). This is more compliant with the LB constraints above: deciding >> which locator to use for a given flow will be a local decision not a >> centralized one. > > Absolutely. I cannot imagine how else it can be done. > > Maria > From nobody Wed Jul 9 12:42: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 CE91F1A0415 for ; Wed, 9 Jul 2014 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 W5tQY1M8z1WU for ; Wed, 9 Jul 2014 12:42:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363161A02FE for ; Wed, 9 Jul 2014 12:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1702; q=dns/txt; s=iport; t=1404934948; x=1406144548; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yf2Wj5cePuY5vdar1Rupl8MzY5Qxkd6MKPFzbTTXwQY=; b=e0QEOQt1kQCY9vYc4tioDqyRUl9Gj0ZyN+JmO/kq/4gh5s412E8+7RRo JLiYYPVG6UFQY/XMTg0KQrnNsrgCShQl0Wzynw5Q736lDrnRkqsPemZJX j+CgB23js4zaK2rF8e+cNUWjy33rbvc6MXwOXqgEJdr57TJwDiM02v5Tc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFALeZvVOtJV2Q/2dsb2JhbABagw5SWr8ZCIdBAYEQFnWEBAEBBAEBAWIJGwIBCEYnCyUCBAESiEINyDoTBI8POoRDAQSWXIQai16ILoNDgjA X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="338872264" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jul 2014 19:42:27 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s69JgBZI002527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 19:42:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 14:42:11 -0500 From: "Ken Gray (kegray)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W1xFLfwWzB0GPcC0T+kkpD5uXpbkAgADJn4D//8brgA== Date: Wed, 9 Jul 2014 19:42:10 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.101.50] Content-Type: text/plain; charset="Windows-1252" Content-ID: <235B7E7FA130F849930533AA8B8ECA50@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uvqcWjmfvaXiqmUNIeAFjE1BkZs Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 19:42:13 -0000 I think you have to go back to Joel's original description of a chain and a path: Service chain is a sequence of logical functions to be applied to a subset of packets. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. =8Awhich I fully agree is a reasonable definition. You do need a locator t= o find the device in the chain in the network and you better know what that is when you classify the traffic. That applies even when the device locator is an abstraction for thousands of devices that it manages locally as "function X". What I have been saying is that you do NOT need to know the address of whatever instance X is managing as long as the next function in the chain is not a divergent locator after that point of abstraction (because then you do have different discrete chains and paths). In this respect, I don't think LB/ADC applies as an example of not knowing the full path a priori. On 7/9/14 3:06 PM, "NAPIERALA, MARIA H" wrote: >> [Med] I still disagree that an ordered list of locators can be >>determined in >> advance for all deployments. I suggest that SFC forwarding be based on >>the >> service chain itself (characterized as an order list of service function >> identifiers). This is more compliant with the LB constraints above: >>deciding >> which locator to use for a given flow will be a local decision not a >> centralized one. > >Absolutely. I cannot imagine how else it can be done. > >Maria > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 12:46: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 936C01A041F for ; Wed, 9 Jul 2014 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OaY-NwfmRxaC for ; Wed, 9 Jul 2014 12:46:22 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13FC1A040D for ; Wed, 9 Jul 2014 12:46:22 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 3571553DC1; Wed, 9 Jul 2014 12:45:16 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 12:45:16.163 -0700 x-echoworx-msg-id: e58f57d9-5a60-47bc-b3fb-fbff56c11ad8 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 841; Wed, 9 Jul 2014 12:45:16 -0700 (PDT) Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 0FF9C53DC1; Wed, 9 Jul 2014 12:45:16 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 12:46:21 -0700 From: Ron Parker To: "Ken Gray (kegray)" , "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXx0EAgADJnoCAAAn6AP//izDw Date: Wed, 9 Jul 2014 19:46:21 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NP2pgpXE2loahfBpzZYFOSYMF28 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 19:46:24 -0000 I think the discussion point, in my mind, is around architecturally, where = and how is the chain resolved to a set of sequential next hops? Is it do= ne centrally, distributed, or some combination? Does it hold for the life= of a fully qualified flow, barring failures and reclassification? What h= appens when there are failures? How is scale-out/scale-in handled? Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) Sent: Wednesday, July 09, 2014 3:42 PM To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. Halpern; sfc@= ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I think you have to go back to Joel's original description of a chain and a= path: Service chain is a sequence of logical functions to be applied to a subset = of packets. That is not enough information to direct the packets. A service path is, i= n some fashion, a sequence of locations in the network. =A9which I fully agree is a reasonable definition. You do need a locator t= o find the device in the chain in the network and you better know what that= is when you classify the traffic. That applies even when the device locat= or is an abstraction for thousands of devices that it manages locally as "f= unction X". What I have been saying is that you do NOT need to know the ad= dress of whatever instance X is managing as long as the next function in th= e chain is not a divergent locator after that point of abstraction (because= then you do have different discrete chains and paths). In this respect, I don't think LB/ADC applies as an example of not knowing = the full path a priori. On 7/9/14 3:06 PM, "NAPIERALA, MARIA H" wrote: >> [Med] I still disagree that an ordered list of locators can be=20 >>determined in advance for all deployments. I suggest that SFC=20 >>forwarding be based on the service chain itself (characterized as an=20 >>order list of service function identifiers). This is more compliant=20 >>with the LB constraints above: >>deciding >> which locator to use for a given flow will be a local decision not a =20 >>centralized one. > >Absolutely. I cannot imagine how else it can be done. > >Maria > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 12:47: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 4A7A01A041F for ; Wed, 9 Jul 2014 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 RPS91Zk0kw56 for ; Wed, 9 Jul 2014 12:46:58 -0700 (PDT) Received: from mxecd01.gs.com (mxe1.gs.com [204.4.187.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C431A040D for ; Wed, 9 Jul 2014 12:46:58 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,633,1400040000"; d="scan'208,217"; a="82702267" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxecd01.idz.gs.com with ESMTP; 09 Jul 2014 15:46:56 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp11ex.firmwide.corp.gs.com ([10.135.172.20]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 09 Jul 2014 15:46:56 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp11ex.firmwide.corp.gs.com ([10.135.172.20]) with mapi; Wed, 9 Jul 2014 15:46:57 -0400 To: 'Ian Smith' , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Date: Wed, 9 Jul 2014 15:46:55 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgABl8oCAABa+gIAAOkGA//+RfCGAABIEsA== Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708D66D3AGSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/deUryUC0alBwenmcitJ7ijU0SkE Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 19:47:01 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66D3AGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ian, Thanks for the write-up. Just to confirm I get this right: You're saying the SFC is a collection of = abstracted desired service functions (your point 1) while the actual path a= given application flow traverses is determined by the service functions th= emselves? E.g., your examples in points (2, 3, 4 and 5)? In your examples, the actual flows (say, TCP connections between the same p= air of endpoints) can traverse different SF paths-nothing wrong with that-e= ven if they follow the same exact SF chain. This mean the SFP isn't predete= rmined (since it's the actual entities that decide the next service functio= n). Do I get that right? Myo PS: Btw, no one has tackled my reverse path question. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: 9 July 2014 2:54 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } Translation: send to instances of these 4 services in this order. 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example: service-function url-filter { dns _http._tcp.url-filter.example.com fallback bypass } Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function. 3. You may define a service function conditionally. Example: service-function web-optimizer { if { [class match [HTTP::url] eq optimizable-content] } { ip 2001:db8:0:22::137.80 } else { service-function firewall } } Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall. 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example: service-function web-cache { lb carp [HTTP::url] @2001:db8:0:21::224.80 } Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic. 5. You may load balance directly in the path selection process. Example: service-function firewall { pool { least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections} ip 2001:db8:23::130 ip 2001:db8:23::131 ip 2001:db8:23::132 ip 2001:db8:23::133 } } Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections. 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example: service-function url-filter { opaque dns _http._tcp.url-filter.example.com } Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain. --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66D3AGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ian,
 
Thanks for the write-up.
 
Just to confirm I get this right: You’re= saying the SFC is a collection of abstracted desired service functions (yo= ur point 1) while the actual path a given application flow traverses is det= ermined by the service functions themselves? E.g., your examples in points (2, 3, 4 and 5)?
 
In your examples, the actual flows (say, TCP c= onnections between the same pair of endpoints) can traverse different SF pa= ths—nothing wrong with that—even if they follow the same exact = SF chain. This mean the SFP isn’t predetermined (since it’s the actual entities that decide the next service function= ).
 
Do I get that right?
 
Myo
 
PS: Btw, no one has tackled my reverse path qu= estion.
 
 
 
1. You don't have to know the particular service function instances to= define the service function chain.  Example:
 
service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimize= r
          40 firewall
}
 
Translation:  send to instances of these 4 services in this order= .
 
2. You don't have to know the ip address of a service function instanc= e to define that an instance does exist.  Example:
 
service-function url-filter {
         dns _http._tcp.url-fi= lter.example.com
         fallback bypass
}
 
Translation:  query DNS for the address and use it, if you can't = resolve an address, skip this function.
 
3. You may define a service function conditionally.  Example:
 
service-function web-optimizer {
         if { [class match [HT= TP::url] eq optimizable-content] } {
            ip = 2001:db8:0:22::137.80
         } else {
            ser= vice-function firewall
         }
}
 
Translation:  if the url is known to be optimizable, use this IP = address, otherwise skip this function and go directly to the firewall.
 
4. You may pre-select a load balancing decision at the time that the S= ervice Function Path is being selected.  Example:
 
service-function web-cache {
         lb carp [HTTP::url] @= 2001:db8:0:21::224.80 } 
 
Translation: instruct the load balancer at the given virtual address t= o make a load balancing decision using the carp hash of the url and expect = us to send it traffic.
 
5. You may load balance directly in the path selection process.  = Example:
 
service-function firewall {
         pool {
           &nbs= p;  least-connections {urn:oid:[Firewall.connections.active] || local:= active_connections}
           &nbs= p;  ip 2001:db8:23::130
           &nbs= p;  ip 2001:db8:23::131
           &nbs= p;  ip 2001:db8:23::132
           &nbs= p;  ip 2001:db8:23::133
         }   &n= bsp;         
}
 
Translation:  using either the snmp query to the given oid, or ou= r own internal counters, pick the ip address from this list that has the le= ast amount of current connections.
 
6. You may just declare that the service function is a complex of serv= ers behind a screening device (like a nat or load balancer).  Example:=
 
service-function url-filter {
         opaque
         dns _http._tcp.url-fi= lter.example.com }
 
Translation: use dns to select the instance, but know that there will = be a hidden service function path segment inserted before the next link in = the service function chain.
 
 
 
 --_000_A3233753A4B65F43BCA1B64DA99A9C230708D66D3AGSCMAMP19EXfi_-- From nobody Wed Jul 9 13:02: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 B9B971A0463 for ; Wed, 9 Jul 2014 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 9kDGSE3IEm36 for ; Wed, 9 Jul 2014 13:02:33 -0700 (PDT) Received: from omr-m07.mx.aol.com (omr-m07.mx.aol.com [64.12.143.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA871A03C0 for ; Wed, 9 Jul 2014 13:02:33 -0700 (PDT) Received: from mtaout-mab02.mx.aol.com (mtaout-mab02.mx.aol.com [172.26.249.82]) by omr-m07.mx.aol.com (Outbound Mail Relay) with ESMTP id 9A78D70035475; Wed, 9 Jul 2014 16:02:31 -0400 (EDT) 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-mab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2E5E638000087; Wed, 9 Jul 2014 16:02:31 -0400 (EDT) Date: Wed, 9 Jul 2014 16:02:30 -0400 From: "mikebianc@aol.com" To: jmh@joelhalpern.com, sfc@ietf.org Message-ID: <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <53BCAB74.4060801@joelhalpern.com> References: <53BCAB74.4060801@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_55007_2009090019.1404936150807" X-Originating-IP: 10.178.59.65, 10.178.59.65 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1404936151; bh=N6u+WYVwiaVsx5PC0sLPj+c76MQCrkx7PTcgrgP8sPg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=BYM95Oi3TYac5d/AzrRfw9CRcjxlxFifDpU6xbnuG/nMtU5p/7QqncJUF2RJnvCTV pOLE9T8cvQAfvmMp/hWNnDenpq0m+P0SgC8OfxdABTGmWXrxiZ0Up/VX5y22Jx7fyD fwijo3ZLWQqe/bt9XIgh8bh8JdDUUcdkhxp4XYx8= x-aol-sid: 3039ac1af95253bd9fd70e8b X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lJFt6LgfLcEU1Lwvh7mkPxe1ud8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 20:02:35 -0000 ------=_Part_55007_2009090019.1404936150807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is anyone still questioning the difference between SF Chain and SF Path? = =C2=A0Other than clarifying the definition so that it's clear to those not = familiar with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. =C2=A0 If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. From: jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. But what do we intend? I will try to explain my personal view, and see=20 if that helps. In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used=20 in any solution. 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to=20 think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without=20 visiting any other service functions. That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_55007_2009090019.1404936150807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is anyone still= questioning the difference between SF Chain and SF Path?  Other than = clarifying the definition so that it's clear to those not familiar with the= draft, it seems that everyone agrees on these terms.

<= div>To me, the one point that is still unclear is whether it is the intent = of this draft to ultimately specify what the ID of the SFC Header should re= ference (the chain or the path), or if this draft simply intends to leave t= hat ambiguous, allowing other drafts to dictate the mechanisms for forwardi= ng based on chain or path and the choice of chain or path to be negotiated = in the control-plane.  

If the latter (ambigu= ous), then the draft would have require that both SFP and SFC be supported = (or make one required and the other optional) to avoid some vendors only su= pporting SFP and others only supporting SFC.


<= /div>



at the front." This a= rchitecture deals with that issue in two ways.
First, as noted in item = (2) on load balancers above, there can be
decisions and behaviors which= are invisible to the service chaining
mechanisms (in much the same way= that bridging within a LAN is largely
invisible to routing between LAN= s.) The other provision we make is that
reclassification can be done i= n mid-chain when necessary. That will
direct packets to a new chain. = Based on information available at the
re-classification point.

I= hope that this helps explain what we are after. If it does, and if
th= e intent is acceptable to the working group, we can figure out what
add= itional words are needed to convey this.
If the working group disagree w= ith the intent, then we will of course
adjust to match the working grou= p agreements.
If this is still unclear, I am not sure what to try next.<= br>
Yours,
Joel

______________________________________________= _
sfc mailing list
sfc@ietf.orghttps://www.ietf.or= g/mailman/listinfo/sfc
------=_Part_55007_2009090019.1404936150807-- From nobody Wed Jul 9 13:19: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 F1C811A0463 for ; Wed, 9 Jul 2014 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T0o7NJRbgfq for ; Wed, 9 Jul 2014 13:18:56 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3B41AD6B0 for ; Wed, 9 Jul 2014 13:18:56 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 0b3adb35.2b15dc606940.7935780.00-2404.18866545.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 20:18:56 +0000 (UTC) X-MXL-Hash: 53bda3b00695d202-32502a68f18fa600a7500a5d8bdf27f78c202a74 Received: from unknown [144.160.229.24] by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with SMTP id da3adb35.0.7934750.00-2279.18866443.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 20:18:55 +0000 (UTC) X-MXL-Hash: 53bda3af1bb75d90-34a8dcff15036246511bffe6dd0a8de8c4689a69 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69K25Eh028716; Wed, 9 Jul 2014 16:02:07 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69K20ps028548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 16:02:02 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 20:01:34 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 16:00:37 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSg Date: Wed, 9 Jul 2014 20:00:37 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> In-Reply-To: <53BD9AC8.5080904@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=WMseuCGqEqwWHEt] X-AnalysisOut: [gWUIA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=zrx5XUls-1zO6NN1:21 a=DqIf8cJ2p0sS9aEi:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/07kB2rCe986DTGjf8um6bhKG5X4 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 20:19:00 -0000 I had in mind singular instances, say, 20 virtual firewall instances somewh= ere in the middle of a chain. Are you saying that you will decide (make a l= oad balancing decision) at the entry to the chain which of those 20 firewal= ls will be used by a particular flow? Maria > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct > Sent: Wednesday, July 09, 2014 3:41 PM > To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > The archtiecture allows for this local decision, while still having the > global decision that is directing the traffic. That is, the global > decision directs the traffic to places in the network. Those places may > be singular or clusters. If they are clusters, those clusters can use > any number of algorithms to distribute the traffic internally, without > any effect on service chaining. (And yes, this can be done in such a > way that return traffic, if delivered globally to the same place, can > then be delivered to the right internal state.) >=20 > The definition of the service path is about how service chaining will > direct the traffic. it is not about how the internal load balancing is > doen, as there are MANY ways to do that, and they can give the same > external interface. >=20 > We could write the architecture pretending that it always addresses > singular instances, but knowing that reality would allow load balanced > clusters at those locations. But that would be a misleading > architectural description and might be read to outlaw some solutions > that fall within the goal the WG wishes to meet. >=20 > Yours, > Joel >=20 > On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >> [Med] I still disagree that an ordered list of locators can be determi= ned > in > >> advance for all deployments. I suggest that SFC forwarding be based on > the > >> service chain itself (characterized as an order list of service functi= on > >> identifiers). This is more compliant with the LB constraints above: > deciding > >> which locator to use for a given flow will be a local decision not a > >> centralized one. > > > > Absolutely. I cannot imagine how else it can be done. > > > > Maria > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 13:26: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 E1EB51A0463 for ; Wed, 9 Jul 2014 13:26:03 -0700 (PDT) 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 OjkTemC2_1hM for ; Wed, 9 Jul 2014 13:26:01 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFD41A0421 for ; Wed, 9 Jul 2014 13:26:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 87E8852126B; Wed, 9 Jul 2014 13:26:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 946FC521268; Wed, 9 Jul 2014 13:26:00 -0700 (PDT) Message-ID: <53BDA558.1070701@joelhalpern.com> Date: Wed, 09 Jul 2014 16:26:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sTDZeS9gm-rT6fNXfZh0D9l-TyE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 20:26:04 -0000 I am saying that if the 20 virtual firewalls are deployed separately, then the service chaining infrastructure would treat them as such, and would use distinct service paths. Alternative, if you as the operator choose to deploy them as a cluster, with sutiable load balancing, such that they appear as a single place for service chaining, then there would be one service path. And the operator could choose a hybrid, for exanmple, deploying two clusters of 10 each, requiring two service paths. Typically, different clusters would be used to provide geographic diversity or because there was a policy reason to distinguish them. While clusters would typically be used to allow the scale-in and scale-out to occur without affecting service chaining. The architecture is structured to allow this range. Yours, Joel On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > I had in mind singular instances, say, 20 virtual firewall instances somewhere in the middle of a chain. Are you saying that you will decide (make a load balancing decision) at the entry to the chain which of those 20 firewalls will be used by a particular flow? > > Maria > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >> Sent: Wednesday, July 09, 2014 3:41 PM >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> The archtiecture allows for this local decision, while still having the >> global decision that is directing the traffic. That is, the global >> decision directs the traffic to places in the network. Those places may >> be singular or clusters. If they are clusters, those clusters can use >> any number of algorithms to distribute the traffic internally, without >> any effect on service chaining. (And yes, this can be done in such a >> way that return traffic, if delivered globally to the same place, can >> then be delivered to the right internal state.) >> >> The definition of the service path is about how service chaining will >> direct the traffic. it is not about how the internal load balancing is >> doen, as there are MANY ways to do that, and they can give the same >> external interface. >> >> We could write the architecture pretending that it always addresses >> singular instances, but knowing that reality would allow load balanced >> clusters at those locations. But that would be a misleading >> architectural description and might be read to outlaw some solutions >> that fall within the goal the WG wishes to meet. >> >> Yours, >> Joel >> >> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>> [Med] I still disagree that an ordered list of locators can be determined >> in >>>> advance for all deployments. I suggest that SFC forwarding be based on >> the >>>> service chain itself (characterized as an order list of service function >>>> identifiers). This is more compliant with the LB constraints above: >> deciding >>>> which locator to use for a given flow will be a local decision not a >>>> centralized one. >>> >>> Absolutely. I cannot imagine how else it can be done. >>> >>> Maria >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 9 13:50: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 8613C1A002E for ; Wed, 9 Jul 2014 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOjaPIFNVGKi for ; Wed, 9 Jul 2014 13:50:14 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5888A1A0011 for ; Wed, 9 Jul 2014 13:50:12 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 20badb35.0.7955606.00-2399.18917110.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 20:50:13 +0000 (UTC) X-MXL-Hash: 53bdab05483cc1f0-e56729cc61b6731026c947c8cb8e9188cdf266cc Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69Ko9s9021947; Wed, 9 Jul 2014 16:50:10 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69KntNN021431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 16:50:05 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 20:49:39 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 16:48:56 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSggABL5AD//7770A== Date: Wed, 9 Jul 2014 20:48:55 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> In-Reply-To: <53BDA558.1070701@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=cRgwOWEfkcY1JYb] X-AnalysisOut: [S7moA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=edpdRA1MsNdTlLDh:21 a=3KRuz8TJnotF0dDg:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qFvYCBT0Y6L0648-OWqr-ZoXA0c Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 20:50:15 -0000 > I am saying that if the 20 virtual firewalls are deployed separately, > then the service chaining infrastructure would treat them as such, and > would use distinct service paths. If I have a 4 hop service chain with 20 instances at each hop, then I have = to globally manage 160,000 service paths (for one chain)? Well, we have yet= to see a solution that work this way and scales.. Maria > On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > > I had in mind singular instances, say, 20 virtual firewall instances > somewhere in the middle of a chain. Are you saying that you will decide > (make a load balancing decision) at the entry to the chain which of those= 20 > firewalls will be used by a particular flow? > > > > Maria > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Dire= ct > >> Sent: Wednesday, July 09, 2014 3:41 PM > >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> The archtiecture allows for this local decision, while still having th= e > >> global decision that is directing the traffic. That is, the global > >> decision directs the traffic to places in the network. Those places m= ay > >> be singular or clusters. If they are clusters, those clusters can use > >> any number of algorithms to distribute the traffic internally, without > >> any effect on service chaining. (And yes, this can be done in such a > >> way that return traffic, if delivered globally to the same place, can > >> then be delivered to the right internal state.) > >> > >> The definition of the service path is about how service chaining will > >> direct the traffic. it is not about how the internal load balancing i= s > >> doen, as there are MANY ways to do that, and they can give the same > >> external interface. > >> > >> We could write the architecture pretending that it always addresses > >> singular instances, but knowing that reality would allow load balanced > >> clusters at those locations. But that would be a misleading > >> architectural description and might be read to outlaw some solutions > >> that fall within the goal the WG wishes to meet. > >> > >> Yours, > >> Joel > >> > >> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>> [Med] I still disagree that an ordered list of locators can be > determined > >> in > >>>> advance for all deployments. I suggest that SFC forwarding be based > on > >> the > >>>> service chain itself (characterized as an order list of service func= tion > >>>> identifiers). This is more compliant with the LB constraints above: > >> deciding > >>>> which locator to use for a given flow will be a local decision not a > >>>> centralized one. > >>> > >>> Absolutely. I cannot imagine how else it can be done. > >>> > >>> Maria > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Jul 9 13:59: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 F0F8E1A0009 for ; Wed, 9 Jul 2014 13:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 PpOpaNlpWN7r for ; Wed, 9 Jul 2014 13:59:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB1B1A002E for ; Wed, 9 Jul 2014 13:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4860; q=dns/txt; s=iport; t=1404939553; x=1406149153; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ClTha9InZOkLrPf1Fk4swOUrVgivJXvqvBXcMKI2uXw=; b=mN9ZUujwJF3aQ0+0mCFK5VppsgxGu0Ckp4RqoNiE7Lmv7hgV4GD7oiTU elMz3aWmwbyXSh957IVDthCQ4CXBE+Kp5s+i0JrAzAH4Pr7J3sp8ir/u3 OwXIqxUX/okAXMOrSf6zaHQhXmqDME22RDcTtMZx7rCYCp+3bCAwMcjKz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAACsvVOtJV2a/2dsb2JhbABZgmokUlq/HAiHQQGBEBZ1hAMBAQEEAQEBNysJFwQCAQgRAQMBAQEKFAkHJwsUAwYIAgQBEggTiCcBDMhDEwSPETgGgyeBFgWWXI94iC6DQ4Iw X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="59570438" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 09 Jul 2014 20:59:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s69KxToc010691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 20:59:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 15:59:29 -0500 From: "Nobo Akiya (nobo)" To: "Joel M. Halpern" , "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8Wz+avP3VyDEaNuxmFkkx26ZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwD//7LPEA== Date: Wed, 9 Jul 2014 20:59:28 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> In-Reply-To: <53BDA558.1070701@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QlymnhgUWVWIPAAneXU-NSSUvQQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 20:59:35 -0000 Hi Joel, I'm starting to get your definition of SFP. So the locator can be an SN or a cluster ingress where the job of the clust= er ingress is to distribute the packets/frames to the actual SNs within the= cluster. Couple of questions from "failure" point of view. How do you protect the cluster ingress (or reachability to the cluster ingr= ess) being a single point of failure? Usage of anycast, VRRP-like or trigge= ring path-protection to switchover the entire SFC to another SFP? If an SN can resolve the next SF to multiple locators, then wouldn't it be = easier to perform local protections (w/o depending on anycast, VRRP-like or= path-protection)? Thanks! Nobo > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 09, 2014 4:26 PM > To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > I am saying that if the 20 virtual firewalls are deployed separately, the= n the > service chaining infrastructure would treat them as such, and would use > distinct service paths. > Alternative, if you as the operator choose to deploy them as a cluster, w= ith > sutiable load balancing, such that they appear as a single place for serv= ice > chaining, then there would be one service path. >=20 > And the operator could choose a hybrid, for exanmple, deploying two > clusters of 10 each, requiring two service paths. >=20 > Typically, different clusters would be used to provide geographic diversi= ty > or because there was a policy reason to distinguish them. > While clusters would typically be used to allow the scale-in and scale-ou= t to > occur without affecting service chaining. >=20 > The architecture is structured to allow this range. >=20 > Yours, > Joel >=20 > On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > > I had in mind singular instances, say, 20 virtual firewall instances > somewhere in the middle of a chain. Are you saying that you will decide > (make a load balancing decision) at the entry to the chain which of those= 20 > firewalls will be used by a particular flow? > > > > Maria > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern > >> Direct > >> Sent: Wednesday, July 09, 2014 3:41 PM > >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> The archtiecture allows for this local decision, while still having > >> the global decision that is directing the traffic. That is, the > >> global decision directs the traffic to places in the network. Those > >> places may be singular or clusters. If they are clusters, those > >> clusters can use any number of algorithms to distribute the traffic > >> internally, without any effect on service chaining. (And yes, this > >> can be done in such a way that return traffic, if delivered globally > >> to the same place, can then be delivered to the right internal > >> state.) > >> > >> The definition of the service path is about how service chaining will > >> direct the traffic. it is not about how the internal load balancing > >> is doen, as there are MANY ways to do that, and they can give the > >> same external interface. > >> > >> We could write the architecture pretending that it always addresses > >> singular instances, but knowing that reality would allow load > >> balanced clusters at those locations. But that would be a misleading > >> architectural description and might be read to outlaw some solutions > >> that fall within the goal the WG wishes to meet. > >> > >> Yours, > >> Joel > >> > >> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>> [Med] I still disagree that an ordered list of locators can be > >>>> determined > >> in > >>>> advance for all deployments. I suggest that SFC forwarding be based > >>>> on > >> the > >>>> service chain itself (characterized as an order list of service > >>>> function identifiers). This is more compliant with the LB constraint= s > above: > >> deciding > >>>> which locator to use for a given flow will be a local decision not > >>>> a centralized one. > >>> > >>> Absolutely. I cannot imagine how else it can be done. > >>> > >>> Maria > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Wed Jul 9 14:05: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 845B71A0025 for ; Wed, 9 Jul 2014 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 7DHarZmPi0gl for ; Wed, 9 Jul 2014 14:05:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37CC1B27A9 for ; Wed, 9 Jul 2014 14:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3864; q=dns/txt; s=iport; t=1404939960; x=1406149560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z/xkcvlNQxyYZ342mRDbHzn1TH64oMH5RDxX6f4Laa8=; b=AMvLQaKRzbDCauvR2PxNSbfPhSrQdep0xn9dcPtMKKEG+Owzy+FYvj8K ouNHFHMMWdjlzBryYJ/U9FcAmB7QFMGlO2Lapyx/0s2N97kq1/SrUbCGO Dtoi5XE7ibzYsCmZsOv+dLjxaARXY5b4I25FLB7/Ssz15PpjgmeJtVLlK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABSuvVOtJA2J/2dsb2JhbABZgw5Sv3YIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwwEAgEIEQEDAQEBHgkHJwsUAwYIAgQOBRuIHwgNyEETBI8PMwcGgyeBFgWWXIQai16ILoND X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="338897852" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2014 21:05:58 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s69L5ga8030534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 21:05:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 16:05:41 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01 Date: Wed, 9 Jul 2014 21:05:40 +0000 Message-ID: <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M6cvFDund8oRclVQJxpniUI7PYI Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:05:46 -0000 Hi Maria, Absolutely and categorically no! If you have 20 instances at each hop then = you can choose to load balance among them locally resulting in exactly 4 pa= ths. What Joel is saying is that if for some very odd and certainly not rec= ommended reason you want to treat each instance separately then the archite= cture does not prevent it. Sent from my iPhone On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" wrote: >> I am saying that if the 20 virtual firewalls are deployed separately, >> then the service chaining infrastructure would treat them as such, and >> would use distinct service paths. >=20 > If I have a 4 hop service chain with 20 instances at each hop, then I hav= e to globally manage 160,000 service paths (for one chain)? Well, we have y= et to see a solution that work this way and scales.. >=20 > Maria >=20 >>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>> I had in mind singular instances, say, 20 virtual firewall instances >> somewhere in the middle of a chain. Are you saying that you will decide >> (make a load balancing decision) at the entry to the chain which of thos= e 20 >> firewalls will be used by a particular flow? >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Dire= ct >>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> The archtiecture allows for this local decision, while still having th= e >>>> global decision that is directing the traffic. That is, the global >>>> decision directs the traffic to places in the network. Those places m= ay >>>> be singular or clusters. If they are clusters, those clusters can use >>>> any number of algorithms to distribute the traffic internally, without >>>> any effect on service chaining. (And yes, this can be done in such a >>>> way that return traffic, if delivered globally to the same place, can >>>> then be delivered to the right internal state.) >>>>=20 >>>> The definition of the service path is about how service chaining will >>>> direct the traffic. it is not about how the internal load balancing i= s >>>> doen, as there are MANY ways to do that, and they can give the same >>>> external interface. >>>>=20 >>>> We could write the architecture pretending that it always addresses >>>> singular instances, but knowing that reality would allow load balanced >>>> clusters at those locations. But that would be a misleading >>>> architectural description and might be read to outlaw some solutions >>>> that fall within the goal the WG wishes to meet. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>> [Med] I still disagree that an ordered list of locators can be >> determined >>>> in >>>>>> advance for all deployments. I suggest that SFC forwarding be based >> on >>>> the >>>>>> service chain itself (characterized as an order list of service func= tion >>>>>> identifiers). This is more compliant with the LB constraints above: >>>> deciding >>>>>> which locator to use for a given flow will be a local decision not a >>>>>> centralized one. >>>>>=20 >>>>> Absolutely. I cannot imagine how else it can be done. >>>>>=20 >>>>> Maria >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:07: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 D69BF1B27BB for ; Wed, 9 Jul 2014 14:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMEHU53O9vFR for ; Wed, 9 Jul 2014 14:07:52 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C4F1A0025 for ; Wed, 9 Jul 2014 14:07:51 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 72fadb35.2b1612e4a940.7966658.00-2498.18945364.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 21:07:51 +0000 (UTC) X-MXL-Hash: 53bdaf271e828174-9ac36d7347ed5024a8e78a25fbd8b6c9ae015cb0 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 62fadb35.0.7966647.00-2379.18945319.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 21:07:50 +0000 (UTC) X-MXL-Hash: 53bdaf26726982d8-10a050127ef07107dcc3fbe68e61264bb6ac359e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69L7nqT017351; Wed, 9 Jul 2014 17:07:50 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69L7eEF017140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 17:07:45 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 21:07:29 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 17:07:28 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSggABL5AD//7770IAATBoA//+9cIA= Date: Wed, 9 Jul 2014 21:07:28 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> In-Reply-To: <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=vUjUPeIxXfAaT_WhotEA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a] X-AnalysisOut: [=NCjeZFekEwIB16Xo:21 a=RfUQho__PonAjY8Y:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uNI9j3sD7B-A8YDs32Ws2Ywhf14 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:07:54 -0000 Hi Jim, When you say "locally", where is it? Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, July 09, 2014 5:06 PM > To: NAPIERALA, MARIA H > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Hi Maria, >=20 > Absolutely and categorically no! If you have 20 instances at each hop the= n > you can choose to load balance among them locally resulting in exactly 4 > paths. What Joel is saying is that if for some very odd and certainly not > recommended reason you want to treat each instance separately then the > architecture does not prevent it. >=20 > Sent from my iPhone >=20 > On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > wrote: >=20 > >> I am saying that if the 20 virtual firewalls are deployed separately, > >> then the service chaining infrastructure would treat them as such, and > >> would use distinct service paths. > > > > If I have a 4 hop service chain with 20 instances at each hop, then I h= ave > to globally manage 160,000 service paths (for one chain)? Well, we have y= et > to see a solution that work this way and scales.. > > > > Maria > > > >>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > >>> I had in mind singular instances, say, 20 virtual firewall instances > >> somewhere in the middle of a chain. Are you saying that you will decid= e > >> (make a load balancing decision) at the entry to the chain which of th= ose > 20 > >> firewalls will be used by a particular flow? > >>> > >>> Maria > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern > Direct > >>>> Sent: Wednesday, July 09, 2014 3:41 PM > >>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > >> sfc@ietf.org > >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> The archtiecture allows for this local decision, while still having = the > >>>> global decision that is directing the traffic. That is, the global > >>>> decision directs the traffic to places in the network. Those places= may > >>>> be singular or clusters. If they are clusters, those clusters can u= se > >>>> any number of algorithms to distribute the traffic internally, witho= ut > >>>> any effect on service chaining. (And yes, this can be done in such = a > >>>> way that return traffic, if delivered globally to the same place, ca= n > >>>> then be delivered to the right internal state.) > >>>> > >>>> The definition of the service path is about how service chaining wil= l > >>>> direct the traffic. it is not about how the internal load balancing= is > >>>> doen, as there are MANY ways to do that, and they can give the same > >>>> external interface. > >>>> > >>>> We could write the architecture pretending that it always addresses > >>>> singular instances, but knowing that reality would allow load balanc= ed > >>>> clusters at those locations. But that would be a misleading > >>>> architectural description and might be read to outlaw some solutions > >>>> that fall within the goal the WG wishes to meet. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>>>> [Med] I still disagree that an ordered list of locators can be > >> determined > >>>> in > >>>>>> advance for all deployments. I suggest that SFC forwarding be base= d > >> on > >>>> the > >>>>>> service chain itself (characterized as an order list of service fu= nction > >>>>>> identifiers). This is more compliant with the LB constraints above= : > >>>> deciding > >>>>>> which locator to use for a given flow will be a local decision not= a > >>>>>> centralized one. > >>>>> > >>>>> Absolutely. I cannot imagine how else it can be done. > >>>>> > >>>>> Maria > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:08: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 9FE691B27BB for ; Wed, 9 Jul 2014 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 5SBO9MdPF1fj for ; Wed, 9 Jul 2014 14:08:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049401B27C7 for ; Wed, 9 Jul 2014 14:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4262; q=dns/txt; s=iport; t=1404940109; x=1406149709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WX7I8KLPC8X7Efc6uwXP5frtfD99TKzHZedyeaixwYM=; b=USM3ArqFJ4WHcyaCMALhOz843gaKgYGkG3ESYOPZT9ByB1Sc226zwm+R aNwuJmNXQlMFxw6PQ0ig5m8VqWl5ZhQ/KcJ5I2wa/kwnKyMf4EoGUiPCG I8lSwfs6Ux6+Ncwkri9ihOGYb6pH8wbveZiVnMcAqYhIWLNIDFCkjlkki o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOqtvVOtJV2S/2dsb2JhbABZgw5Sv3YIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgUbiB8IDchDEwSPDzMHBoMngRYFllyEGoteiC6DQw X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="338680481" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2014 21:08:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s69L80oO021373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 21:08:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 16:08:00 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01gAAApDE= Date: Wed, 9 Jul 2014 21:07:58 +0000 Message-ID: <3527B3FB-131C-4159-A69D-A1C915D71252@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com>, <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> In-Reply-To: <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xIcyQQDke04U_bXM4t5i4LYtChM Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:08:05 -0000 Typo in previous .. 1 path Sent from my iPhone > On Jul 9, 2014, at 5:05 PM, "Jim Guichard (jguichar)" wrote: >=20 > Hi Maria, >=20 > Absolutely and categorically no! If you have 20 instances at each hop the= n you can choose to load balance among them locally resulting in exactly 4 = paths. What Joel is saying is that if for some very odd and certainly not r= ecommended reason you want to treat each instance separately then the archi= tecture does not prevent it. >=20 > Sent from my iPhone >=20 > On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" wrote: >=20 >>> I am saying that if the 20 virtual firewalls are deployed separately, >>> then the service chaining infrastructure would treat them as such, and >>> would use distinct service paths. >>=20 >> If I have a 4 hop service chain with 20 instances at each hop, then I ha= ve to globally manage 160,000 service paths (for one chain)? Well, we have = yet to see a solution that work this way and scales.. >>=20 >> Maria >>=20 >>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>> I had in mind singular instances, say, 20 virtual firewall instances >>> somewhere in the middle of a chain. Are you saying that you will decide >>> (make a load balancing decision) at the entry to the chain which of tho= se 20 >>> firewalls will be used by a particular flow? >>>>=20 >>>> Maria >>>>=20 >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Dir= ect >>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> The archtiecture allows for this local decision, while still having t= he >>>>> global decision that is directing the traffic. That is, the global >>>>> decision directs the traffic to places in the network. Those places = may >>>>> be singular or clusters. If they are clusters, those clusters can us= e >>>>> any number of algorithms to distribute the traffic internally, withou= t >>>>> any effect on service chaining. (And yes, this can be done in such a >>>>> way that return traffic, if delivered globally to the same place, can >>>>> then be delivered to the right internal state.) >>>>>=20 >>>>> The definition of the service path is about how service chaining will >>>>> direct the traffic. it is not about how the internal load balancing = is >>>>> doen, as there are MANY ways to do that, and they can give the same >>>>> external interface. >>>>>=20 >>>>> We could write the architecture pretending that it always addresses >>>>> singular instances, but knowing that reality would allow load balance= d >>>>> clusters at those locations. But that would be a misleading >>>>> architectural description and might be read to outlaw some solutions >>>>> that fall within the goal the WG wishes to meet. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>> [Med] I still disagree that an ordered list of locators can be >>> determined >>>>> in >>>>>>> advance for all deployments. I suggest that SFC forwarding be based >>> on >>>>> the >>>>>>> service chain itself (characterized as an order list of service fun= ction >>>>>>> identifiers). This is more compliant with the LB constraints above: >>>>> deciding >>>>>>> which locator to use for a given flow will be a local decision not = a >>>>>>> centralized one. >>>>>>=20 >>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>=20 >>>>>> Maria >>>>>=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 nobody Wed Jul 9 14:11: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 72AE51A0025 for ; Wed, 9 Jul 2014 14:11:04 -0700 (PDT) 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 UfzrgchpHkRK for ; Wed, 9 Jul 2014 14:11:02 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1981A0007 for ; Wed, 9 Jul 2014 14:11:02 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hy4so8450039vcb.5 for ; Wed, 09 Jul 2014 14:11:01 -0700 (PDT) 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=a/bipHMfAhUgTai2gOEXxaE7oSx53O9RE23/lvSIxMo=; b=ZwxNRqYCGFDHKOtSH17UjcxCv0r70aM+LrCEZPM9BYcf5p3lUGDidO62B1e/bLjDy2 Ukt8819uEPJQuYgX0zzPZMZkbzZCG2skrXZsW8hELOhhTGiNXRVWacRpJO3GA+BoAjwq 8wnIqS6bxL87gGrEHIQnz2Dupt5sowxFAoqDeQ4jrVuPFdEWhnMBxn1o4EdZzIjpi34M aKWK64hdBMb4ElGZ2LUWTK88D/Oar+1SZLz1H8hIbC0Nvz578JsiuTaMlw8g4R/Y8sa6 1ZYHixPFdv8fxRqvcEckRJnkjX0+TZ69FE7wWLrP29PHU1pJcXoZaIshTlqlOp5TAG2U TGiQ== X-Received: by 10.52.28.231 with SMTP id e7mr68491vdh.55.1404940261554; Wed, 09 Jul 2014 14:11:01 -0700 (PDT) Received: from [10.18.44.233] (108-71-93-159.lightspeed.sntcca.sbcglobal.net. [108.71.93.159]) by mx.google.com with ESMTPSA id i24sm79530771yha.12.2014.07.09.14.10.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 14:11:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (11D257) In-Reply-To: <53BDA558.1070701@joelhalpern.com> Date: Wed, 9 Jul 2014 14:10:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <57E76B09-5982-40F0-992C-8C5604CC260C@gmail.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KW_sdyDveqPUeO3f7ScOtho4Vz0 Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:11:04 -0000 If we translate the draft standards literally to products this way we will e= nd up chaining a bunch of load balancers, that's it. These will in-turn need to figure what function to chain for this punt. That= 's not enough progress in most cases over stitching load balancers with vlan= s. Perhaps we need to draft an informational on how to build one distributed= - interoperable load balancer using the SFC spec ? --szb > On Jul 9, 2014, at 1:26 PM, "Joel M. Halpern" wrote:= >=20 > I am saying that if the 20 virtual firewalls are deployed separately, then= the service chaining infrastructure would treat them as such, and would use= distinct service paths. > Alternative, if you as the operator choose to deploy them as a cluster, wi= th sutiable load balancing, such that they appear as a single place for serv= ice chaining, then there would be one service path. >=20 > And the operator could choose a hybrid, for exanmple, deploying two cluste= rs of 10 each, requiring two service paths. >=20 > Typically, different clusters would be used to provide geographic diversit= y or because there was a policy reason to distinguish them. While clusters w= ould typically be used to allow the scale-in and scale-out to occur without a= ffecting service chaining. >=20 > The architecture is structured to allow this range. >=20 > Yours, > Joel >=20 >> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >> I had in mind singular instances, say, 20 virtual firewall instances some= where in the middle of a chain. Are you saying that you will decide (make a l= oad balancing decision) at the entry to the chain which of those 20 firewall= s will be used by a particular flow? >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct= >>> Sent: Wednesday, July 09, 2014 3:41 PM >>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> The archtiecture allows for this local decision, while still having the >>> global decision that is directing the traffic. That is, the global >>> decision directs the traffic to places in the network. Those places may= >>> be singular or clusters. If they are clusters, those clusters can use >>> any number of algorithms to distribute the traffic internally, without >>> any effect on service chaining. (And yes, this can be done in such a >>> way that return traffic, if delivered globally to the same place, can >>> then be delivered to the right internal state.) >>>=20 >>> The definition of the service path is about how service chaining will >>> direct the traffic. it is not about how the internal load balancing is >>> doen, as there are MANY ways to do that, and they can give the same >>> external interface. >>>=20 >>> We could write the architecture pretending that it always addresses >>> singular instances, but knowing that reality would allow load balanced >>> clusters at those locations. But that would be a misleading >>> architectural description and might be read to outlaw some solutions >>> that fall within the goal the WG wishes to meet. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>> [Med] I still disagree that an ordered list of locators can be determi= ned >>> in >>>>> advance for all deployments. I suggest that SFC forwarding be based on= >>> the >>>>> service chain itself (characterized as an order list of service functi= on >>>>> identifiers). This is more compliant with the LB constraints above: >>> deciding >>>>> which locator to use for a given flow will be a local decision not a >>>>> centralized one. >>>>=20 >>>> Absolutely. I cannot imagine how else it can be done. >>>>=20 >>>> Maria >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:12: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 198CB1A0025 for ; Wed, 9 Jul 2014 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 xswgXAuHvBo2 for ; Wed, 9 Jul 2014 14:12:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF971A0007 for ; Wed, 9 Jul 2014 14:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4736; q=dns/txt; s=iport; t=1404940324; x=1406149924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xh4VQVzx5wBcbiB59u1fFNpJFX6nKtqY1kiLRzRf2+k=; b=cM8m91NMbl8CAW9q9myMwwKoToWDml27BQChLu2BidBJo5vsXkZ7EpDY A59N80mox39AROQIP2DmvZOklvDlf4mjSdUG922mJjTy2NXg/ySAaoAjh EWznJFFMB/fdwEM3rhfj5RjukHX1liOYkDwNwQQkGojnDHFj4lYJP3S2z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMGvvVOtJA2J/2dsb2JhbABZgw5Sv3cIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgUbiB8IDchLEwSPDzMHBoMngRYFllyEGoteiC6DQw X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="59520725" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP; 09 Jul 2014 21:11:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s69LBciT001766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 21:11:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 16:11:37 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01gABUUQD//61X8w== Date: Wed, 9 Jul 2014 21:11:36 +0000 Message-ID: <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mh0zd8Lm3X7FNkZWonJSK_ln_io Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:12:03 -0000 At the node through which the 20 instances are reachable. IOW you don't hav= e to individually address packets to each and every instance. Sent from my iPhone > On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote: >=20 > Hi Jim, >=20 > When you say "locally", where is it? >=20 > Maria >=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:06 PM >> To: NAPIERALA, MARIA H >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Hi Maria, >>=20 >> Absolutely and categorically no! If you have 20 instances at each hop th= en >> you can choose to load balance among them locally resulting in exactly 4 >> paths. What Joel is saying is that if for some very odd and certainly no= t >> recommended reason you want to treat each instance separately then the >> architecture does not prevent it. >>=20 >> Sent from my iPhone >>=20 >> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >> wrote: >>=20 >>>> I am saying that if the 20 virtual firewalls are deployed separately, >>>> then the service chaining infrastructure would treat them as such, and >>>> would use distinct service paths. >>>=20 >>> If I have a 4 hop service chain with 20 instances at each hop, then I h= ave >> to globally manage 160,000 service paths (for one chain)? Well, we have = yet >> to see a solution that work this way and scales.. >>>=20 >>> Maria >>>=20 >>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>> I had in mind singular instances, say, 20 virtual firewall instances >>>> somewhere in the middle of a chain. Are you saying that you will decid= e >>>> (make a load balancing decision) at the entry to the chain which of th= ose >> 20 >>>> firewalls will be used by a particular flow? >>>>>=20 >>>>> Maria >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >> Direct >>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> The archtiecture allows for this local decision, while still having = the >>>>>> global decision that is directing the traffic. That is, the global >>>>>> decision directs the traffic to places in the network. Those places= may >>>>>> be singular or clusters. If they are clusters, those clusters can u= se >>>>>> any number of algorithms to distribute the traffic internally, witho= ut >>>>>> any effect on service chaining. (And yes, this can be done in such = a >>>>>> way that return traffic, if delivered globally to the same place, ca= n >>>>>> then be delivered to the right internal state.) >>>>>>=20 >>>>>> The definition of the service path is about how service chaining wil= l >>>>>> direct the traffic. it is not about how the internal load balancing= is >>>>>> doen, as there are MANY ways to do that, and they can give the same >>>>>> external interface. >>>>>>=20 >>>>>> We could write the architecture pretending that it always addresses >>>>>> singular instances, but knowing that reality would allow load balanc= ed >>>>>> clusters at those locations. But that would be a misleading >>>>>> architectural description and might be read to outlaw some solutions >>>>>> that fall within the goal the WG wishes to meet. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>> determined >>>>>> in >>>>>>>> advance for all deployments. I suggest that SFC forwarding be base= d >>>> on >>>>>> the >>>>>>>> service chain itself (characterized as an order list of service fu= nction >>>>>>>> identifiers). This is more compliant with the LB constraints above= : >>>>>> deciding >>>>>>>> which locator to use for a given flow will be a local decision not= a >>>>>>>> centralized one. >>>>>>>=20 >>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>=20 >>>>>>> Maria >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:17: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 B07CE1B27D9 for ; Wed, 9 Jul 2014 14:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nR3LkJHw18d6 for ; Wed, 9 Jul 2014 14:17:33 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5BF1A0025 for ; Wed, 9 Jul 2014 14:17:33 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id D6F2A53DF8; Wed, 9 Jul 2014 14:16:26 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 14:16:26.715 -0700 x-echoworx-msg-id: 3d23114f-fa8d-40c6-ab2d-a88209b6ac79 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 276; Wed, 9 Jul 2014 14:16:26 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 96B4453DF8; Wed, 9 Jul 2014 14:16:26 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 14:17:32 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IA Date: Wed, 9 Jul 2014 21:17:32 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> In-Reply-To: <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/g2aKDqGxfxj08KINSDSYWL3mPN4 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:17:35 -0000 Jim, There may not be a single node through which all of the instances can be re= ached (at some reasonable limit of L2 or L3 hops). Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, July 09, 2014 5:12 PM To: NAPIERALA, MARIA H Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers At the node through which the 20 instances are reachable. IOW you don't hav= e to individually address packets to each and every instance. Sent from my iPhone > On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote: >=20 > Hi Jim, >=20 > When you say "locally", where is it? >=20 > Maria >=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:06 PM >> To: NAPIERALA, MARIA H >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Hi Maria, >>=20 >> Absolutely and categorically no! If you have 20 instances at each hop=20 >> then you can choose to load balance among them locally resulting in=20 >> exactly 4 paths. What Joel is saying is that if for some very odd and=20 >> certainly not recommended reason you want to treat each instance=20 >> separately then the architecture does not prevent it. >>=20 >> Sent from my iPhone >>=20 >> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >> wrote: >>=20 >>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>> separately, then the service chaining infrastructure would treat=20 >>>> them as such, and would use distinct service paths. >>>=20 >>> If I have a 4 hop service chain with 20 instances at each hop, then=20 >>> I have >> to globally manage 160,000 service paths (for one chain)? Well, we=20 >> have yet to see a solution that work this way and scales.. >>>=20 >>> Maria >>>=20 >>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>> instances >>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>> decide (make a load balancing decision) at the entry to the chain=20 >>>> which of those >> 20 >>>> firewalls will be used by a particular flow? >>>>>=20 >>>>> Maria >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >> Direct >>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> The archtiecture allows for this local decision, while still=20 >>>>>> having the global decision that is directing the traffic. That=20 >>>>>> is, the global decision directs the traffic to places in the=20 >>>>>> network. Those places may be singular or clusters. If they are=20 >>>>>> clusters, those clusters can use any number of algorithms to=20 >>>>>> distribute the traffic internally, without any effect on service=20 >>>>>> chaining. (And yes, this can be done in such a way that return=20 >>>>>> traffic, if delivered globally to the same place, can then be=20 >>>>>> delivered to the right internal state.) >>>>>>=20 >>>>>> The definition of the service path is about how service chaining=20 >>>>>> will direct the traffic. it is not about how the internal load=20 >>>>>> balancing is doen, as there are MANY ways to do that, and they=20 >>>>>> can give the same external interface. >>>>>>=20 >>>>>> We could write the architecture pretending that it always=20 >>>>>> addresses singular instances, but knowing that reality would=20 >>>>>> allow load balanced clusters at those locations. But that would=20 >>>>>> be a misleading architectural description and might be read to=20 >>>>>> outlaw some solutions that fall within the goal the WG wishes to mee= t. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>> determined >>>>>> in >>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>> based >>>> on >>>>>> the >>>>>>>> service chain itself (characterized as an order list of service=20 >>>>>>>> function identifiers). This is more compliant with the LB constrai= nts above: >>>>>> deciding >>>>>>>> which locator to use for a given flow will be a local decision=20 >>>>>>>> not a centralized one. >>>>>>>=20 >>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>=20 >>>>>>> Maria >>>>>>=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 nobody Wed Jul 9 14:28: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 CCE171B280B for ; Wed, 9 Jul 2014 14:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 CHgQTIVosX-3 for ; Wed, 9 Jul 2014 14:28:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F0E1B27F2 for ; Wed, 9 Jul 2014 14:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5785; q=dns/txt; s=iport; t=1404941326; x=1406150926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P3MmjCD2oAZpQTkb8n77ojU61G0wobDLdu5nESnaSPc=; b=hxTpN6n1b0puTmhKULQpMWNn6ALWyc/0PbvoofpTADZiESjAoLylsyaT bGfU82UcdPeue4qQpTA/PBoahPLZgJivNpldBZV7yHczRO8vbVxQJJlo5 Ux0juGtv+1ntAi2YRbCg1ZoGjBTyRnWCYuyuWcMwDX771tU+Qakm5mEYb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIKzvVOtJA2J/2dsb2JhbABZgw5Sv3cIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgUbiB8IDchKEwSOayQIKwcGgyeBFgWWXIQai16ILoNDgW8 X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="59582713" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 09 Jul 2014 21:28:44 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s69LSaeA011777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 21:28:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 16:28:35 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01gABUUQD//61X84AAVXkA//+vRr0= Date: Wed, 9 Jul 2014 21:28:35 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/P4o4a6P7ne1zgTQqktuiHdkrxpY Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:28:40 -0000 Well of course not; in that case you load balance up a level between those = nodes and then locally. Sent from my iPhone > On Jul 9, 2014, at 5:17 PM, "Ron Parker" wrote: >=20 > Jim, >=20 > There may not be a single node through which all of the instances can be = reached (at some reasonable limit of L2 or L3 hops). >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar) > Sent: Wednesday, July 09, 2014 5:12 PM > To: NAPIERALA, MARIA H > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > At the node through which the 20 instances are reachable. IOW you don't h= ave to individually address packets to each and every instance. >=20 > Sent from my iPhone >=20 >> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote: >>=20 >> Hi Jim, >>=20 >> When you say "locally", where is it? >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 5:06 PM >>> To: NAPIERALA, MARIA H >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> Hi Maria, >>>=20 >>> Absolutely and categorically no! If you have 20 instances at each hop=20 >>> then you can choose to load balance among them locally resulting in=20 >>> exactly 4 paths. What Joel is saying is that if for some very odd and=20 >>> certainly not recommended reason you want to treat each instance=20 >>> separately then the architecture does not prevent it. >>>=20 >>> Sent from my iPhone >>>=20 >>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> wrote: >>>=20 >>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>> separately, then the service chaining infrastructure would treat=20 >>>>> them as such, and would use distinct service paths. >>>>=20 >>>> If I have a 4 hop service chain with 20 instances at each hop, then=20 >>>> I have >>> to globally manage 160,000 service paths (for one chain)? Well, we=20 >>> have yet to see a solution that work this way and scales.. >>>>=20 >>>> Maria >>>>=20 >>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>> instances >>>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>>> decide (make a load balancing decision) at the entry to the chain=20 >>>>> which of those >>> 20 >>>>> firewalls will be used by a particular flow? >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>> Direct >>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>=20 >>>>>>> The archtiecture allows for this local decision, while still=20 >>>>>>> having the global decision that is directing the traffic. That=20 >>>>>>> is, the global decision directs the traffic to places in the=20 >>>>>>> network. Those places may be singular or clusters. If they are=20 >>>>>>> clusters, those clusters can use any number of algorithms to=20 >>>>>>> distribute the traffic internally, without any effect on service=20 >>>>>>> chaining. (And yes, this can be done in such a way that return=20 >>>>>>> traffic, if delivered globally to the same place, can then be=20 >>>>>>> delivered to the right internal state.) >>>>>>>=20 >>>>>>> The definition of the service path is about how service chaining=20 >>>>>>> will direct the traffic. it is not about how the internal load=20 >>>>>>> balancing is doen, as there are MANY ways to do that, and they=20 >>>>>>> can give the same external interface. >>>>>>>=20 >>>>>>> We could write the architecture pretending that it always=20 >>>>>>> addresses singular instances, but knowing that reality would=20 >>>>>>> allow load balanced clusters at those locations. But that would=20 >>>>>>> be a misleading architectural description and might be read to=20 >>>>>>> outlaw some solutions that fall within the goal the WG wishes to me= et. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>>> determined >>>>>>> in >>>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>>> based >>>>> on >>>>>>> the >>>>>>>>> service chain itself (characterized as an order list of service=20 >>>>>>>>> function identifiers). This is more compliant with the LB constra= ints above: >>>>>>> deciding >>>>>>>>> which locator to use for a given flow will be a local decision=20 >>>>>>>>> not a centralized one. >>>>>>>>=20 >>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>=20 >>>>>>>> Maria >>>>>>>=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 nobody Wed Jul 9 14:31: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 C25721A002B for ; Wed, 9 Jul 2014 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 S0wYbOCtW72s for ; Wed, 9 Jul 2014 14:31:29 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B1C1A0002 for ; Wed, 9 Jul 2014 14:31:28 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id E6E9F53E16; Wed, 9 Jul 2014 14:29:42 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 14:29:42.918 -0700 x-echoworx-msg-id: 58fe4ee6-2dba-4ae6-8b5f-8cfe886cba80 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 22; Wed, 9 Jul 2014 14:29:42 -0700 (PDT) Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id C7A8B53E2F; Wed, 9 Jul 2014 14:29:42 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 14:31:28 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsA== Date: Wed, 9 Jul 2014 21:31:27 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ByKiPe9ZRduiQUldygRumIuPrQk Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:31:30 -0000 Agreed. But is that in scope for SFC or out of scope for SFC? -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, July 09, 2014 5:29 PM To: Ron Parker Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; sfc@= ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Well of course not; in that case you load balance up a level between those = nodes and then locally. Sent from my iPhone > On Jul 9, 2014, at 5:17 PM, "Ron Parker" wrote: >=20 > Jim, >=20 > There may not be a single node through which all of the instances can be = reached (at some reasonable limit of L2 or L3 hops). >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard=20 > (jguichar) > Sent: Wednesday, July 09, 2014 5:12 PM > To: NAPIERALA, MARIA H > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > At the node through which the 20 instances are reachable. IOW you don't h= ave to individually address packets to each and every instance. >=20 > Sent from my iPhone >=20 >> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote: >>=20 >> Hi Jim, >>=20 >> When you say "locally", where is it? >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 5:06 PM >>> To: NAPIERALA, MARIA H >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> Hi Maria, >>>=20 >>> Absolutely and categorically no! If you have 20 instances at each=20 >>> hop then you can choose to load balance among them locally resulting=20 >>> in exactly 4 paths. What Joel is saying is that if for some very odd=20 >>> and certainly not recommended reason you want to treat each instance=20 >>> separately then the architecture does not prevent it. >>>=20 >>> Sent from my iPhone >>>=20 >>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> wrote: >>>=20 >>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>> separately, then the service chaining infrastructure would treat=20 >>>>> them as such, and would use distinct service paths. >>>>=20 >>>> If I have a 4 hop service chain with 20 instances at each hop, then=20 >>>> I have >>> to globally manage 160,000 service paths (for one chain)? Well, we=20 >>> have yet to see a solution that work this way and scales.. >>>>=20 >>>> Maria >>>>=20 >>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>> instances >>>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>>> decide (make a load balancing decision) at the entry to the chain=20 >>>>> which of those >>> 20 >>>>> firewalls will be used by a particular flow? >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 >>>>>>> Halpern >>> Direct >>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>=20 >>>>>>> The archtiecture allows for this local decision, while still=20 >>>>>>> having the global decision that is directing the traffic. That=20 >>>>>>> is, the global decision directs the traffic to places in the=20 >>>>>>> network. Those places may be singular or clusters. If they are=20 >>>>>>> clusters, those clusters can use any number of algorithms to=20 >>>>>>> distribute the traffic internally, without any effect on service=20 >>>>>>> chaining. (And yes, this can be done in such a way that return=20 >>>>>>> traffic, if delivered globally to the same place, can then be=20 >>>>>>> delivered to the right internal state.) >>>>>>>=20 >>>>>>> The definition of the service path is about how service chaining=20 >>>>>>> will direct the traffic. it is not about how the internal load=20 >>>>>>> balancing is doen, as there are MANY ways to do that, and they=20 >>>>>>> can give the same external interface. >>>>>>>=20 >>>>>>> We could write the architecture pretending that it always=20 >>>>>>> addresses singular instances, but knowing that reality would=20 >>>>>>> allow load balanced clusters at those locations. But that would=20 >>>>>>> be a misleading architectural description and might be read to=20 >>>>>>> outlaw some solutions that fall within the goal the WG wishes to me= et. >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>>> determined >>>>>>> in >>>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>>> based >>>>> on >>>>>>> the >>>>>>>>> service chain itself (characterized as an order list of=20 >>>>>>>>> service function identifiers). This is more compliant with the LB= constraints above: >>>>>>> deciding >>>>>>>>> which locator to use for a given flow will be a local decision=20 >>>>>>>>> not a centralized one. >>>>>>>>=20 >>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>=20 >>>>>>>> Maria >>>>>>>=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 nobody Wed Jul 9 14:34: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 C64321A002B for ; Wed, 9 Jul 2014 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbRFJZs7CvjI for ; Wed, 9 Jul 2014 14:34:44 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE5C1A0002 for ; Wed, 9 Jul 2014 14:34:43 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 375bdb35.2b15e8606940.7983418.00-2464.18987719.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 21:34:43 +0000 (UTC) X-MXL-Hash: 53bdb5736f58ff5c-993f3b8ac44855f066ffa92315eaeb3ea7290949 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 275bdb35.0.7983410.00-2295.18987690.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 09 Jul 2014 21:34:42 +0000 (UTC) X-MXL-Hash: 53bdb5724bb6e513-d5a67fec72fbba7fd18c66e273a320f761f50722 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69LYfQJ014873; Wed, 9 Jul 2014 17:34:41 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s69LYZs8014761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 17:34:37 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 9 Jul 2014 21:34:30 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.194]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 17:32:14 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSggABL5AD//7770IAATBoA//+9cIAACIceAAAIF7EA Date: Wed, 9 Jul 2014 21:32:14 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D423D3@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> In-Reply-To: <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=i3_nGvEx2lkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=UKq8Evhswg5dWnUpNHQA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a] X-AnalysisOut: [=sY17LNniscg0fd1D:21 a=iYK-ChWiTyaxtbUl:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M5jG9uSIMll9kfURl9r7eYTz1vw Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:34:45 -0000 In case of network overlay, this is pretty clear, these are all the nodes t= hat constitute a previous hop. =20 In any case, this is how we started this thread, i.e., by saying that it is= hop-by-hop load balancing.=20 Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, July 09, 2014 5:12 PM > To: NAPIERALA, MARIA H > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > At the node through which the 20 instances are reachable. IOW you don't > have to individually address packets to each and every instance. >=20 > Sent from my iPhone >=20 > > On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" > wrote: > > > > Hi Jim, > > > > When you say "locally", where is it? > > > > Maria > > > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Wednesday, July 09, 2014 5:06 PM > >> To: NAPIERALA, MARIA H > >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> Hi Maria, > >> > >> Absolutely and categorically no! If you have 20 instances at each hop > then > >> you can choose to load balance among them locally resulting in exactly= 4 > >> paths. What Joel is saying is that if for some very odd and certainly = not > >> recommended reason you want to treat each instance separately then > the > >> architecture does not prevent it. > >> > >> Sent from my iPhone > >> > >> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > >> wrote: > >> > >>>> I am saying that if the 20 virtual firewalls are deployed separately= , > >>>> then the service chaining infrastructure would treat them as such, a= nd > >>>> would use distinct service paths. > >>> > >>> If I have a 4 hop service chain with 20 instances at each hop, then I > have > >> to globally manage 160,000 service paths (for one chain)? Well, we hav= e > yet > >> to see a solution that work this way and scales.. > >>> > >>> Maria > >>> > >>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > >>>>> I had in mind singular instances, say, 20 virtual firewall instance= s > >>>> somewhere in the middle of a chain. Are you saying that you will > decide > >>>> (make a load balancing decision) at the entry to the chain which of > those > >> 20 > >>>> firewalls will be used by a particular flow? > >>>>> > >>>>> Maria > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern > >> Direct > >>>>>> Sent: Wednesday, July 09, 2014 3:41 PM > >>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > >>>> sfc@ietf.org > >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>> > >>>>>> The archtiecture allows for this local decision, while still havin= g the > >>>>>> global decision that is directing the traffic. That is, the globa= l > >>>>>> decision directs the traffic to places in the network. Those plac= es > may > >>>>>> be singular or clusters. If they are clusters, those clusters can= use > >>>>>> any number of algorithms to distribute the traffic internally, > without > >>>>>> any effect on service chaining. (And yes, this can be done in suc= h a > >>>>>> way that return traffic, if delivered globally to the same place, = can > >>>>>> then be delivered to the right internal state.) > >>>>>> > >>>>>> The definition of the service path is about how service chaining w= ill > >>>>>> direct the traffic. it is not about how the internal load balanci= ng is > >>>>>> doen, as there are MANY ways to do that, and they can give the > same > >>>>>> external interface. > >>>>>> > >>>>>> We could write the architecture pretending that it always addresse= s > >>>>>> singular instances, but knowing that reality would allow load > balanced > >>>>>> clusters at those locations. But that would be a misleading > >>>>>> architectural description and might be read to outlaw some > solutions > >>>>>> that fall within the goal the WG wishes to meet. > >>>>>> > >>>>>> Yours, > >>>>>> Joel > >>>>>> > >>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>> [Med] I still disagree that an ordered list of locators can be > >>>> determined > >>>>>> in > >>>>>>>> advance for all deployments. I suggest that SFC forwarding be > based > >>>> on > >>>>>> the > >>>>>>>> service chain itself (characterized as an order list of service > function > >>>>>>>> identifiers). This is more compliant with the LB constraints abo= ve: > >>>>>> deciding > >>>>>>>> which locator to use for a given flow will be a local decision n= ot a > >>>>>>>> centralized one. > >>>>>>> > >>>>>>> Absolutely. I cannot imagine how else it can be done. > >>>>>>> > >>>>>>> Maria > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:35: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 064AD1A0040 for ; Wed, 9 Jul 2014 14:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 rAZEZ8apSS6W for ; Wed, 9 Jul 2014 14:35:35 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A9B1A0026 for ; Wed, 9 Jul 2014 14:35:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="121155855" X-IPAS-Result: AqQEADD7RVPAqArr/2dsb2JhbAA/EAqCQn9XxBOBN3SCJQEBAQEDDgxLFAwEAgEIEQEDAQELFgcHMhQDBggCBAENBQiIATbLWheOCgYLAR8fCAoGAQYDgxuBFASUcYUiiT+BeIkGgXI5 Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 09 Jul 2014 21:35:34 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 14:35:34 -0700 From: Ian Smith To: "Zarny, Myo" , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgABl8oCAABa+gIAAOkGA//+RfCGAABIEsIAABZCr Date: Wed, 9 Jul 2014 21:35:33 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83AF92SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qT-bB_JAAPLwz7FJu0ZTHpci5IQ Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:35:43 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83AF92SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mostly. I've been defining things like this: * Service Function Domain as the logical area in which Service Function= Chains are defined. There are various names for them but basically all th= e architectures define an "ingress" and an "egress" node that anchors a cha= in at each end - this is the space between them. * Service Function Chain as "an ordered sequence of a finite number of = functions" * Service Function Path as "an ordered sequence of particular instances= of service functions within a Service Function Chain". * Service Function as an abstract thing - "URL Filter" * Service Function Node as the physical piece of hardware that houses t= he Service Function - "this server" * Service Function Instance as a particular instance of a service funct= ion - "this URL Filter on this Service Function Node" - and it can be a vir= tual machine, a container, or just an instance of software on the SFN. This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there. I may have incorrectly believed this to be a case o= f settled meaning. Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture. It does exist, and by definition it exists becaus= e packets are moving along it. In the most rudimentary case, you are passi= ng from node to node to some destination far away using only their default = gateway; the SFI is the agglomeration of their default gateways. This easi= ly evolves to IP Source Routes, MPLS lable stacks, and other in-packet mech= anisms, but it just as easily evolves to an orchestration system inserting = policy routes into nodes in a "just in time" fashion or tying the client IP= to a pre-existing policy that includes the next hop. The latter case is w= hat my previous example showed. You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service= Function Path (and if you don't have that path defined, recurse through th= e id to find the Service Function Chain to make whatever evaluation is requ= ired by you to send me on my way.)" or a orchestration system. I confess t= o geekishly liking the idea of using the IPX+ address schema for this. Example: 6 byte SFD:4 byte SFC:6 byte SFP aabbccddeeff:0123:6e01e1f421d3 (I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using ex= isting mechanisms.) You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. Thi= s is perhaps too plainly stated, but it is easy and seems to be the path we= are chartered to take. So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met. I think that is not what people are asking for= . What I think people are asking for is a method for channelizing services= on packet switched networks, which I understand to mean that I should disa= ggregate flows at the boundary of a SFD, and force them into channels accor= ding to some external policy, keep them in their channel all the way throug= h the domain, and then reaggregate them on the other side. And to give the= people what they want, I think you do have to say something like, "the pat= h may vary but only amongst the SFIs that are defined by the SFC and once a= n SFI is selected for use by a flow, it stays selected until dismissed or i= t fails" which to me implies that you MUST select the chain, and you MAY s= elect as many instances within that chain that the policy allows, but you M= UST respect conditional elements of the chain and to do that you have to, i= n essence, select all the possible instances implied by the chain. (I don'= t know if calling it a Markov chain problem helps, but it is an apt descrip= tion in my mind.) That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important. Once you= evaluate the conditional requirements however, then the path is set and it= SHOULD remain fixed until an input to the conditional requirements changes= . I would expect that change to come from four principal areas: Failure, = packet inspection, content switching, or policy update. There could be mor= e, but those seem to be the main archetypes. Of those two, packet inspecti= on results and content switching are clearly the kind of conditional requir= ement that belong in a SFC definition, while there is a strong case that no= de or network failures and policy updates will be orthogonal inputs the the= whole system, not something that can be clearly identified and dealt with = on the data plane. Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Service Funct= ions have discretionary rules that leave the next hop in the chain indeterm= inate until a packet presents itself to the Service Function Instance (most= ly because of middle-boxes), but the Service Function itself MUST be declar= ed before we can select (by any means) a Service Function Instance. And on= ce in the midst of evaluating the conditional requirement, we have a finite= set of "next Service Functions". I can define a completely deterministic = conditional statement, and we should permit such things and leave them to t= he implementers to restrict if they want, but my gut says that most of the = conditional rules will be of the sort where all the possible outcomes MAY b= e foreseen before evaluation (eg. if this, then that, else that2) in which = case the SPI is not indeterminate (that is, entirely unknown until evaluati= on), merely uncertain (that is, which of these possible outcomes is more li= kely), which is significantly easier to deal with. That is the example fro= m my first email in this thread. How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread". If= we don't what to get into that at all, then it is sufficient to say that a= SFC definition MUST include a way to identify all potential SFI's for incl= uded SF's, and that implementations SHOULD resolve as many of the possible = SFI's implied by a SFC before making an assignment and that if there are co= nditional rules in the SFC, then implementations MUST resolv all of the pos= sible SFI's and, by use of the magic thread, tell them all that they should= be prepared to participate in SFI-x for client-A. I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. Example: show service-chain client 2001:db8:0::abc:123:def:456 all service-chain 100 path da29c34de0af:0123:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION url-filter 2001:db8:0:20::80.45.80 opaque web-cache 2001:db8:0:21::80.224.80 carp {http://gothamist.com/2014= /07/09/cooler_weather_arrives_on_the_anniv.php} web-optimizer 2001:db8:0:22::80.137.80 conditional match firewall 2001:db8:0:23::80.132 current-conns 3245 {3992,4503,3= 389} service-chain 109 path da29c34de0af:0134:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION dns-filter 2001:db8:0:100::53:98.53 passed dns-cache 2001:db8:0:100::53:129.53 miss dns-switch 2001:db8:0:100::53:223.53 off-net, icann tld dns-server 2001:db8:0:99::53:23.53 SOA 2001:db8:fa99:e8b4:123:abcd= :4567:ef01.53 Translation: The client at 2001:db8:0::abc:123:def:456 currently has Servi= ce Function Paths active in two Service Function Chains - 100 and 109 - wi= th the particular Service Function Instances listed in correspondence to th= e Service Function and any information reported by the SFI pertaining to th= e state of the SFP. You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. ________________________________ From: Zarny, Myo [Myo.Zarny@gs.com] Sent: Wednesday, July 09, 2014 3:46 PM To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Bou= cadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hi Ian, Thanks for the write-up. Just to confirm I get this right: You=92re saying the SFC is a collection o= f abstracted desired service functions (your point 1) while the actual path= a given application flow traverses is determined by the service functions = themselves? E.g., your examples in points (2, 3, 4 and 5)? In your examples, the actual flows (say, TCP connections between the same p= air of endpoints) can traverse different SF paths=97nothing wrong with that= =97even if they follow the same exact SF chain. This mean the SFP isn=92t p= redetermined (since it=92s the actual entities that decide the next service= function). Do I get that right? Myo PS: Btw, no one has tackled my reverse path question. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: 9 July 2014 2:54 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } Translation: send to instances of these 4 services in this order. 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example: service-function url-filter { dns _http._tcp.url-filter.example.com fallback bypass } Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function. 3. You may define a service function conditionally. Example: service-function web-optimizer { if { [class match [HTTP::url] eq optimizable-content] } { ip 2001:db8:0:22::137.80 } else { service-function firewall } } Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall. 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example: service-function web-cache { lb carp [HTTP::url] @2001:db8:0:21::224.80 } Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic. 5. You may load balance directly in the path selection process. Example: service-function firewall { pool { least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections} ip 2001:db8:23::130 ip 2001:db8:23::131 ip 2001:db8:23::132 ip 2001:db8:23::133 } } Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections. 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example: service-function url-filter { opaque dns _http._tcp.url-filter.example.com } Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain. --_000_419417C345CA5F48BF45F0A23955A0634A83AF92SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mostly.

I've been defining things like this:
  • Service Function Domain as the logical area in which Service Function C= hains are defined.  There are various names for them but basically all= the architectures define an "ingress" and an "egress" = node that anchors a chain at each end - this is the space between them.
  • Service Function Chain as "an ordered sequence = of a finite number of functions"
  • Service Function Path as &quo= t;an ordered sequence of particular instances of service functions within a= Service Function Chain". 
  • Service Function as an abstract thing - "URL Filter"
  • Service Function Node as the physical piece of hardware that houses th= e Service Function - "this server"
  • Service Function Insta= nce as a particular instance of a service function - "this URL Filter = on this Service Function Node" - and it can be a virtual machine, a co= ntainer, or just an instance of software on the SFN.

This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there.  I may have incorrectly believed this to be a c= ase of settled meaning.

Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture.  It does exist, and by definition it exists b= ecause packets are moving along it.  In the most rudimentary case, you= are passing from node to node to some destination far away using only their default gateway; the SFI is the agglomeration of= their default gateways.  This easily evolves to IP Source Routes, MPL= S lable stacks, and other in-packet mechanisms, but it just as easily evolv= es to an orchestration system inserting policy routes into nodes in a "just in time" fashion or tying th= e client IP to a pre-existing policy that includes the next hop.  The = latter case is what my previous example showed.

You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service Function Path (and if you d= on't have that path defined, recurse through the id to find the Service Fun= ction Chain to make whatever evaluation is required by you to send me on my= way.)" or a orchestration system.  I confess to geekishly liking the idea of using the IPX+ address schema = for this. 

Example:

6 byte SFD:4 byte SFC:6 byte SFP
aabbccddeeff:0123:6e01e1f421d3 

(I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using existing mechanisms.)

You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. = ; This is perhaps too plainly stated, but it is easy and seems to be the path we are chartered to take.

So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met.  I think that is not what people are askin= g for.  What I think people are asking for is a method for channelizin= g services on packet switched networks, which I understand to mean that I should disaggregate flows at the boundary of a= SFD, and force them into channels according to some external policy, keep = them in their channel all the way through the domain, and then reaggregate = them on the other side.  And to give the people what they want, I think you do have to say something like,= "the path may vary but only amongst the SFIs that are defined by the = SFC and once an SFI is selected for use by a flow, it stays selected until = dismissed or it fails" which  to me implies that you MUST select the chain, and you MAY select as many instances withi= n that chain that the policy allows, but you MUST respect conditional eleme= nts of the chain and to do that you have to, in essence, select all the pos= sible instances implied by the chain.  (I don't know if calling it a Markov chain problem helps, but it is an apt= description in my mind.)

That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important.  Onc= e you evaluate the conditional requirements however, then the path is set a= nd it SHOULD remain fixed until an input to the conditional requirements changes.  I would expect that change = to come from four principal areas:  Failure, packet inspection, conten= t switching, or policy update.  There could be more, but those seem to= be the main archetypes.  Of those two, packet inspection results and content switching are clearly the kind of condition= al requirement that belong in a SFC definition, while there is a strong cas= e that node or network failures and policy updates will be orthogonal input= s the the whole system, not something that can be clearly identified and dealt with on the data plane.

Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Ser= vice Functions have discretionary rules that leave the next hop in the chai= n indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the= Service Function itself MUST be declared before we can select (by any mean= s) a Service Function Instance.  And once in the midst of evaluating t= he conditional requirement, we have a finite set of "next Service Functions".  I can define a com= pletely deterministic conditional statement, and we should permit such thin= gs and leave them to the implementers to restrict if they want, but my gut = says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluat= ion (eg. if this, then that, else that2) in which case the SPI is not indet= erminate (that is, entirely unknown until evaluation), merely uncertain (th= at is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is= the example from my first email in this thread.

How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread&= quot;.  If we don't what to get into that at all, then it is sufficien= t to say that a SFC definition MUST include a way to identify all potential SFI's for included SF's, and that implementation= s SHOULD resolve as many of the possible SFI's implied by a SFC before maki= ng an assignment and that if there are conditional rules in the SFC, then i= mplementations MUST resolv all of the possible SFI's and, by use of the magic thread, tell them all that the= y should be prepared to participate in SFI-x for client-A.

 

I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. 

Example:

show service-chain client 2001:db8:0::abc:123:de= f:456 all

service-chain 100 path da29c34de0af:0123:6e01e1f421d3
FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
url-filter      2001:db8:0:20::80.45.80  = ;   opaque
web-cache       2001:db8:0:21::80.224.80 = ;   carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_= on_the_anniv.php}
web-optimizer   2001:db8:0:22::80.137.80    condit= ional match
firewall        2001:db8:0:23::80.132 &n= bsp;     current-conns 3245 {3992,4503,3389}  &nbs= p;    

service-chain 109 path da29c34de0af:0134:6e01e1f421d3

FUNCTION        INSTANCE&n= bsp;               &= nbsp;   DESCRIPTION
dns-filter      2001:db8:0:100::53:98.53  &nb= sp; passed
dns-cache       2001:db8:0:100::53:129.53 &nb= sp; miss
dns-switch      2001:db8:0:100::53:223.53   o= ff-net, icann tld
dns-server      2001:db8:0:99::53:23.53  = ;   SOA 2001:db8:fa99:e8b4:123:abcd:4567:ef01.53

Translation:  The client at 2001:d= b8:0::abc:123:def:456 currently has Service Function Paths active in two Se= rvice Function Chains - 100 and 109  - with the particular Service Fun= ction Instances listed in correspondence to the Service Function and any information reported by the SFI pertaining to= the state of the SFP.

You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. 


From: Zarny, Myo [Myo.Zarny@gs.com]
Sent: Wednesday, July 09, 2014 3:46 PM
To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; '= Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Hi Ian,
 
Thanks for the write-up.
 
Just to confirm I get this right: You=92re say= ing the SFC is a collection of abstracted desired service functions (your p= oint 1) while the actual path a given application flow traverses is determi= ned by the service functions themselves? E.g., your examples in points (2, 3, 4 and 5)?
 
In your examples, the actual flows (say, TCP c= onnections between the same pair of endpoints) can traverse different SF pa= ths=97nothing wrong with that=97even if they follow the same exact SF chain= . This mean the SFP isn=92t predetermined (since it=92s the actual entities that decide the next service function).<= /font>
 
Do I get that right?
 
Myo
 
PS: Btw, no one has tackled my reverse path qu= estion.
 
 
-----Original Message-----
From: Ian Smith [mailto= :I.Smith@F5.com]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers
 
1. You don't have to know the particular service function instances to= define the service function chain.  Example:
 
service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimize= r
          40 firewall
}
 
Translation:  send to instances of these 4 services in this order= .
 
2. You don't have to know the ip address of a service function instanc= e to define that an instance does exist.  Example:
 
service-function url-filter {
         dns _http._tcp.url-fi= lter.example.com
         fallback bypass
}
 
Translation:  query DNS for the address and use it, if you can't = resolve an address, skip this function.
 
3. You may define a service function conditionally.  Example:
 
service-function web-optimizer {
         if { [class match [HT= TP::url] eq optimizable-content] } {
            ip = 2001:db8:0:22::137.80
         } else {
            ser= vice-function firewall
         }
}
 
Translation:  if the url is known to be optimizable, use this IP = address, otherwise skip this function and go directly to the firewall.
 
4. You may pre-select a load balancing decision at the time that the S= ervice Function Path is being selected.  Example:
 
service-function web-cache {
         lb carp [HTTP::url] @= 2001:db8:0:21::224.80 } 
 
Translation: instruct the load balancer at the given virtual address t= o make a load balancing decision using the carp hash of the url and expect = us to send it traffic.
 
5. You may load balance directly in the path selection process.  = Example:
 
service-function firewall {
         pool {
           &nbs= p;  least-connections {urn:oid:[Firewall.connections.active] || local:= active_connections}
           &nbs= p;  ip 2001:db8:23::130
           &nbs= p;  ip 2001:db8:23::131
           &nbs= p;  ip 2001:db8:23::132
           &nbs= p;  ip 2001:db8:23::133
         }   &n= bsp;         
}
 
Translation:  using either the snmp query to the given oid, or ou= r own internal counters, pick the ip address from this list that has the le= ast amount of current connections.
 
6. You may just declare that the service function is a complex of serv= ers behind a screening device (like a nat or load balancer).  Example:=
 
service-function url-filter {
         opaque
         dns _http._tcp.url-fi= lter.example.com }
 
Translation: use dns to select the instance, but know that there will = be a hidden service function path segment inserted before the next link in = the service function chain.
 
 
 
--_000_419417C345CA5F48BF45F0A23955A0634A83AF92SEAEMBX02olympu_-- From nobody Wed Jul 9 14:47: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 817641B2826 for ; Wed, 9 Jul 2014 14:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 2lSISvjq3l6L for ; Wed, 9 Jul 2014 14:47:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B081B2820 for ; Wed, 9 Jul 2014 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6635; q=dns/txt; s=iport; t=1404942487; x=1406152087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iGUfScztLQa9iaw3CgIovksygpTet16SUafRzE8gNdQ=; b=jDx+5b2/DhQaEbE2IGr18Q8Y3bqWDCpt69unjG1Ml0THa04KMVdAVBU0 zjsSr4WMyNPPERIycVs7xFTQ+9cUEgEajwBUXPz8zelGIQzzBkzCaZm1Y wezYmXFGp3FbnDi/TRiM3IDjLvM05gTv1W62yb9tOJ7BI9yIaC7e1xbyS s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOe3vVOtJA2J/2dsb2JhbABZgw5Sv3YIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgUbiB8IDchLEwSOayQIKwcGgyeBFgWWXIQai16ILoNDgW8 X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208";a="338907568" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2014 21:48:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s69LldNb022429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 21:47:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 16:47:38 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01gABUUQD//61X84AAVXkA//+vRr0ACpPHgP//sLQX Date: Wed, 9 Jul 2014 21:47:38 +0000 Message-ID: <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UX-JjdcT9bC4TecdypKnWc1KwDs Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 21:47:43 -0000 I would say that's implementation. Sent from my iPhone > On Jul 9, 2014, at 5:31 PM, "Ron Parker" wrote: >=20 > Agreed. But is that in scope for SFC or out of scope for SFC? >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, July 09, 2014 5:29 PM > To: Ron Parker > Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; sf= c@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Well of course not; in that case you load balance up a level between thos= e nodes and then locally. >=20 > Sent from my iPhone >=20 >> On Jul 9, 2014, at 5:17 PM, "Ron Parker" wrote: >>=20 >> Jim, >>=20 >> There may not be a single node through which all of the instances can be= reached (at some reasonable limit of L2 or L3 hops). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard=20 >> (jguichar) >> Sent: Wednesday, July 09, 2014 5:12 PM >> To: NAPIERALA, MARIA H >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> At the node through which the 20 instances are reachable. IOW you don't = have to individually address packets to each and every instance. >>=20 >> Sent from my iPhone >>=20 >>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote= : >>>=20 >>> Hi Jim, >>>=20 >>> When you say "locally", where is it? >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>> To: NAPIERALA, MARIA H >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> Hi Maria, >>>>=20 >>>> Absolutely and categorically no! If you have 20 instances at each=20 >>>> hop then you can choose to load balance among them locally resulting=20 >>>> in exactly 4 paths. What Joel is saying is that if for some very odd=20 >>>> and certainly not recommended reason you want to treat each instance=20 >>>> separately then the architecture does not prevent it. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>> wrote: >>>>=20 >>>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>>> separately, then the service chaining infrastructure would treat=20 >>>>>> them as such, and would use distinct service paths. >>>>>=20 >>>>> If I have a 4 hop service chain with 20 instances at each hop, then=20 >>>>> I have >>>> to globally manage 160,000 service paths (for one chain)? Well, we=20 >>>> have yet to see a solution that work this way and scales.. >>>>>=20 >>>>> Maria >>>>>=20 >>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>>> instances >>>>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>>>> decide (make a load balancing decision) at the entry to the chain=20 >>>>>> which of those >>>> 20 >>>>>> firewalls will be used by a particular flow? >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 >>>>>>>> Halpern >>>> Direct >>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>=20 >>>>>>>> The archtiecture allows for this local decision, while still=20 >>>>>>>> having the global decision that is directing the traffic. That=20 >>>>>>>> is, the global decision directs the traffic to places in the=20 >>>>>>>> network. Those places may be singular or clusters. If they are=20 >>>>>>>> clusters, those clusters can use any number of algorithms to=20 >>>>>>>> distribute the traffic internally, without any effect on service=20 >>>>>>>> chaining. (And yes, this can be done in such a way that return=20 >>>>>>>> traffic, if delivered globally to the same place, can then be=20 >>>>>>>> delivered to the right internal state.) >>>>>>>>=20 >>>>>>>> The definition of the service path is about how service chaining=20 >>>>>>>> will direct the traffic. it is not about how the internal load=20 >>>>>>>> balancing is doen, as there are MANY ways to do that, and they=20 >>>>>>>> can give the same external interface. >>>>>>>>=20 >>>>>>>> We could write the architecture pretending that it always=20 >>>>>>>> addresses singular instances, but knowing that reality would=20 >>>>>>>> allow load balanced clusters at those locations. But that would=20 >>>>>>>> be a misleading architectural description and might be read to=20 >>>>>>>> outlaw some solutions that fall within the goal the WG wishes to m= eet. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>>>> determined >>>>>>>> in >>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>>>> based >>>>>> on >>>>>>>> the >>>>>>>>>> service chain itself (characterized as an order list of=20 >>>>>>>>>> service function identifiers). This is more compliant with the L= B constraints above: >>>>>>>> deciding >>>>>>>>>> which locator to use for a given flow will be a local decision=20 >>>>>>>>>> not a centralized one. >>>>>>>>>=20 >>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>=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 From nobody Wed Jul 9 15:00: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 3C6EF1A002A for ; Wed, 9 Jul 2014 15:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 z9sU41yjM8Sx for ; Wed, 9 Jul 2014 15:00:20 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E4C1A0080 for ; Wed, 9 Jul 2014 15:00:19 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 1899C53E27; Wed, 9 Jul 2014 14:59:13 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 14:59:13.035 -0700 x-echoworx-msg-id: 46833741-5d14-49a2-8297-1c4fee115579 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 655; Wed, 9 Jul 2014 14:59:13 -0700 (PDT) Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id E26F853E27; Wed, 9 Jul 2014 14:59:12 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 15:00:18 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRA= Date: Wed, 9 Jul 2014 22:00:18 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> In-Reply-To: <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/knimth5nTO01TNP-Oy4nQdDdYD4 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 22:00:22 -0000 Jim, Respectfully, I'm not comfortable with that. While it is easy to say that= this is a layered problem and that load balancing belongs at a lower level= , it seems to me that load balancing of the service functions (not load bal= ancer as a service function) should be an explicit consideration of the SFC= architecture. I say this not only from a scale perspective, but also wi= th resiliency in mind. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Wednesday, July 09, 2014 5:48 PM To: Ron Parker Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA,= MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I would say that's implementation. Sent from my iPhone > On Jul 9, 2014, at 5:31 PM, "Ron Parker" wrote: >=20 > Agreed. But is that in scope for SFC or out of scope for SFC? >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, July 09, 2014 5:29 PM > To: Ron Parker > Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com;=20 > sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Well of course not; in that case you load balance up a level between thos= e nodes and then locally. >=20 > Sent from my iPhone >=20 >> On Jul 9, 2014, at 5:17 PM, "Ron Parker" wrote: >>=20 >> Jim, >>=20 >> There may not be a single node through which all of the instances can be= reached (at some reasonable limit of L2 or L3 hops). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >> (jguichar) >> Sent: Wednesday, July 09, 2014 5:12 PM >> To: NAPIERALA, MARIA H >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> At the node through which the 20 instances are reachable. IOW you don't = have to individually address packets to each and every instance. >>=20 >> Sent from my iPhone >>=20 >>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrote= : >>>=20 >>> Hi Jim, >>>=20 >>> When you say "locally", where is it? >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>> To: NAPIERALA, MARIA H >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> Hi Maria, >>>>=20 >>>> Absolutely and categorically no! If you have 20 instances at each=20 >>>> hop then you can choose to load balance among them locally=20 >>>> resulting in exactly 4 paths. What Joel is saying is that if for=20 >>>> some very odd and certainly not recommended reason you want to=20 >>>> treat each instance separately then the architecture does not prevent = it. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>> wrote: >>>>=20 >>>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>>> separately, then the service chaining infrastructure would treat=20 >>>>>> them as such, and would use distinct service paths. >>>>>=20 >>>>> If I have a 4 hop service chain with 20 instances at each hop,=20 >>>>> then I have >>>> to globally manage 160,000 service paths (for one chain)? Well, we=20 >>>> have yet to see a solution that work this way and scales.. >>>>>=20 >>>>> Maria >>>>>=20 >>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>>> instances >>>>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>>>> decide (make a load balancing decision) at the entry to the chain=20 >>>>>> which of those >>>> 20 >>>>>> firewalls will be used by a particular flow? >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 >>>>>>>> Halpern >>>> Direct >>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>=20 >>>>>>>> The archtiecture allows for this local decision, while still=20 >>>>>>>> having the global decision that is directing the traffic. That=20 >>>>>>>> is, the global decision directs the traffic to places in the=20 >>>>>>>> network. Those places may be singular or clusters. If they=20 >>>>>>>> are clusters, those clusters can use any number of algorithms=20 >>>>>>>> to distribute the traffic internally, without any effect on=20 >>>>>>>> service chaining. (And yes, this can be done in such a way=20 >>>>>>>> that return traffic, if delivered globally to the same place,=20 >>>>>>>> can then be delivered to the right internal state.) >>>>>>>>=20 >>>>>>>> The definition of the service path is about how service=20 >>>>>>>> chaining will direct the traffic. it is not about how the=20 >>>>>>>> internal load balancing is doen, as there are MANY ways to do=20 >>>>>>>> that, and they can give the same external interface. >>>>>>>>=20 >>>>>>>> We could write the architecture pretending that it always=20 >>>>>>>> addresses singular instances, but knowing that reality would=20 >>>>>>>> allow load balanced clusters at those locations. But that=20 >>>>>>>> would be a misleading architectural description and might be=20 >>>>>>>> read to outlaw some solutions that fall within the goal the WG wis= hes to meet. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> [Med] I still disagree that an ordered list of locators can=20 >>>>>>>>>> be >>>>>> determined >>>>>>>> in >>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>>>> based >>>>>> on >>>>>>>> the >>>>>>>>>> service chain itself (characterized as an order list of=20 >>>>>>>>>> service function identifiers). This is more compliant with the L= B constraints above: >>>>>>>> deciding >>>>>>>>>> which locator to use for a given flow will be a local=20 >>>>>>>>>> decision not a centralized one. >>>>>>>>>=20 >>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>=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 From nobody Wed Jul 9 15:16: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 9D4B91A010A for ; Wed, 9 Jul 2014 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 ud6FTRabeT90 for ; Wed, 9 Jul 2014 15:16:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94541A0109 for ; Wed, 9 Jul 2014 15:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6080; q=dns/txt; s=iport; t=1404944209; x=1406153809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wTuqEktKvxLrVvvuWsH4Bg7e6TBZyUvCOdlLohem4fg=; b=b1xhwUijvgpBTHEJjFe3YYqGNgp7BM7NiymX0W09X9u7/FEeQlbBdzc9 SwR45MZk4VYY0zwjM7ZVh9Yol0HnK0E+zboYt9QnecrS8cBUfFj3TpW8s +IC+/YF1nVLpSo4XlyEndexG6Gq/qNYQ8Z7/mF5tSHFoIrbCeL5qSHrlX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FALK+vVOtJV2T/2dsb2JhbABZgw5SWr8cCIdBAYEQFnWEAwEBAQQBAQELLCsJCwwEAgEIEQEDAQEBHgkHJwsUAwYIAgQBDQUbiCcNyFETBI5rLCsHBoQ9BZZchBqLXogug0OBb0E X-IronPort-AV: E=Sophos;i="5.01,634,1400025600"; d="scan'208";a="335797110" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2014 22:16:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s69MGeDQ016897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 22:16:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 17:16:39 -0500 From: "Ken Gray (kegray)" To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W1xFLfwWzB0GPcC0T+kkpD5uXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogIAABK4AgAAAgACAAAEoAIAAAagAgAADF4D//8pdgA== Date: Wed, 9 Jul 2014 22:16:38 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.142] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jVwOA9spLSD8CfXqWsBOPt_-i20 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 22:16:42 -0000 Exactly.=20 On 7/9/14 5:28 PM, "Jim Guichard (jguichar)" wrote: >Well of course not; in that case you load balance up a level between >those nodes and then locally. > >Sent from my iPhone > >> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >> wrote: >>=20 >> Jim, >>=20 >> There may not be a single node through which all of the instances can >>be reached (at some reasonable limit of L2 or L3 hops). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>(jguichar) >> Sent: Wednesday, July 09, 2014 5:12 PM >> To: NAPIERALA, MARIA H >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> At the node through which the 20 instances are reachable. IOW you don't >>have to individually address packets to each and every instance. >>=20 >> Sent from my iPhone >>=20 >>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>wrote: >>>=20 >>> Hi Jim, >>>=20 >>> When you say "locally", where is it? >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>> To: NAPIERALA, MARIA H >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> Hi Maria, >>>>=20 >>>> Absolutely and categorically no! If you have 20 instances at each hop >>>> then you can choose to load balance among them locally resulting in >>>> exactly 4 paths. What Joel is saying is that if for some very odd and >>>> certainly not recommended reason you want to treat each instance >>>> separately then the architecture does not prevent it. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>> wrote: >>>>=20 >>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>> separately, then the service chaining infrastructure would treat >>>>>> them as such, and would use distinct service paths. >>>>>=20 >>>>> If I have a 4 hop service chain with 20 instances at each hop, then >>>>> I have >>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>> have yet to see a solution that work this way and scales.. >>>>>=20 >>>>> Maria >>>>>=20 >>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>> instances >>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>> which of those >>>> 20 >>>>>> firewalls will be used by a particular flow? >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>> Direct >>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>=20 >>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>> having the global decision that is directing the traffic. That >>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>> network. Those places may be singular or clusters. If they are >>>>>>>> clusters, those clusters can use any number of algorithms to >>>>>>>> distribute the traffic internally, without any effect on service >>>>>>>> chaining. (And yes, this can be done in such a way that return >>>>>>>> traffic, if delivered globally to the same place, can then be >>>>>>>> delivered to the right internal state.) >>>>>>>>=20 >>>>>>>> The definition of the service path is about how service chaining >>>>>>>> will direct the traffic. it is not about how the internal load >>>>>>>> balancing is doen, as there are MANY ways to do that, and they >>>>>>>> can give the same external interface. >>>>>>>>=20 >>>>>>>> We could write the architecture pretending that it always >>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>> allow load balanced clusters at those locations. But that would >>>>>>>> be a misleading architectural description and might be read to >>>>>>>> outlaw some solutions that fall within the goal the WG wishes to >>>>>>>>meet. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> [Med] I still disagree that an ordered list of locators can be >>>>>> determined >>>>>>>> in >>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>> based >>>>>> on >>>>>>>> the >>>>>>>>>> service chain itself (characterized as an order list of service >>>>>>>>>> function identifiers). This is more compliant with the LB >>>>>>>>>>constraints above: >>>>>>>> deciding >>>>>>>>>> which locator to use for a given flow will be a local decision >>>>>>>>>> not a centralized one. >>>>>>>>>=20 >>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>=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 nobody Wed Jul 9 15:17: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 1C8771A0109 for ; Wed, 9 Jul 2014 15:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 4HcfVJo5yUru for ; Wed, 9 Jul 2014 15:17:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82101A0103 for ; Wed, 9 Jul 2014 15:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8061; q=dns/txt; s=iport; t=1404944262; x=1406153862; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6Wtb8w8iHciD/nSmrA3zY2BgMuw3vxCXQTpvNBQqy3A=; b=S8bGUADfGOMXYoO6QP12n9AivNlDsRfOcSFS2aMkJ5lzg6xL4P4W8er1 JfE2MihoW+7akRZhEmWdnWLUNQuP81JdMNY4mH5CDJfeAVTgfc3XgKCi/ fwjpnIxuBJLKx/LeC7rLvarzdJ/6yDbteymjNSVxV5AvExdPJEez3xtcD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHm+vVOtJV2P/2dsb2JhbABZgw5Sv3YIh0EBgRAWdYQDAQEBAwEBAQELLCsJCwUHBAIBCBEBAwEBAR4JBycLFAMGCAIEDgUbiB8IDchREwSOayQIKwcGgyeBFgWWXIQai16ILoNDgW8 X-IronPort-AV: E=Sophos;i="5.01,634,1400025600"; d="scan'208";a="338913343" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2014 22:17:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s69MHLeD026902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 22:17:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 17:17:21 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogP//sN01gABUUQD//61X84AAVXkA//+vRr0ACpPHgP//sLQXgABXWwD//7DyJw== Date: Wed, 9 Jul 2014 22:17:20 +0000 Message-ID: <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YmzUR5MRsQsITYVTIEb7H3wrutk Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 22:17:26 -0000 I should clarify that my statement was made as a personal opinion and it is= up to the WG to evaluate if there exists anything at the architectural lev= el that is new and therefore needs to be addressed. Sent from my iPhone > On Jul 9, 2014, at 6:01 PM, "Ron Parker" wrote: >=20 > Jim, >=20 > Respectfully, I'm not comfortable with that. While it is easy to say th= at this is a layered problem and that load balancing belongs at a lower lev= el, it seems to me that load balancing of the service functions (not load b= alancer as a service function) should be an explicit consideration of the S= FC architecture. I say this not only from a scale perspective, but also = with resiliency in mind. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Wednesday, July 09, 2014 5:48 PM > To: Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERAL= A, MARIA H > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > I would say that's implementation. >=20 > Sent from my iPhone >=20 >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" wrote: >>=20 >> Agreed. But is that in scope for SFC or out of scope for SFC? >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:29 PM >> To: Ron Parker >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com;=20 >> sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Well of course not; in that case you load balance up a level between tho= se nodes and then locally. >>=20 >> Sent from my iPhone >>=20 >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" wrote: >>>=20 >>> Jim, >>>=20 >>> There may not be a single node through which all of the instances can b= e reached (at some reasonable limit of L2 or L3 hops). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>> (jguichar) >>> Sent: Wednesday, July 09, 2014 5:12 PM >>> To: NAPIERALA, MARIA H >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> At the node through which the 20 instances are reachable. IOW you don't= have to individually address packets to each and every instance. >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" wrot= e: >>>>=20 >>>> Hi Jim, >>>>=20 >>>> When you say "locally", where is it? >>>>=20 >>>> Maria >>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> Hi Maria, >>>>>=20 >>>>> Absolutely and categorically no! If you have 20 instances at each=20 >>>>> hop then you can choose to load balance among them locally=20 >>>>> resulting in exactly 4 paths. What Joel is saying is that if for=20 >>>>> some very odd and certainly not recommended reason you want to=20 >>>>> treat each instance separately then the architecture does not prevent= it. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>>=20 >>>>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>>>> separately, then the service chaining infrastructure would treat=20 >>>>>>> them as such, and would use distinct service paths. >>>>>>=20 >>>>>> If I have a 4 hop service chain with 20 instances at each hop,=20 >>>>>> then I have >>>>> to globally manage 160,000 service paths (for one chain)? Well, we=20 >>>>> have yet to see a solution that work this way and scales.. >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>>>> instances >>>>>>> somewhere in the middle of a chain. Are you saying that you will=20 >>>>>>> decide (make a load balancing decision) at the entry to the chain=20 >>>>>>> which of those >>>>> 20 >>>>>>> firewalls will be used by a particular flow? >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 >>>>>>>>> Halpern >>>>> Direct >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>> sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>=20 >>>>>>>>> The archtiecture allows for this local decision, while still=20 >>>>>>>>> having the global decision that is directing the traffic. That=20 >>>>>>>>> is, the global decision directs the traffic to places in the=20 >>>>>>>>> network. Those places may be singular or clusters. If they=20 >>>>>>>>> are clusters, those clusters can use any number of algorithms=20 >>>>>>>>> to distribute the traffic internally, without any effect on=20 >>>>>>>>> service chaining. (And yes, this can be done in such a way=20 >>>>>>>>> that return traffic, if delivered globally to the same place,=20 >>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>=20 >>>>>>>>> The definition of the service path is about how service=20 >>>>>>>>> chaining will direct the traffic. it is not about how the=20 >>>>>>>>> internal load balancing is doen, as there are MANY ways to do=20 >>>>>>>>> that, and they can give the same external interface. >>>>>>>>>=20 >>>>>>>>> We could write the architecture pretending that it always=20 >>>>>>>>> addresses singular instances, but knowing that reality would=20 >>>>>>>>> allow load balanced clusters at those locations. But that=20 >>>>>>>>> would be a misleading architectural description and might be=20 >>>>>>>>> read to outlaw some solutions that fall within the goal the WG wi= shes to meet. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> [Med] I still disagree that an ordered list of locators can=20 >>>>>>>>>>> be >>>>>>> determined >>>>>>>>> in >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>>>>>>> based >>>>>>> on >>>>>>>>> the >>>>>>>>>>> service chain itself (characterized as an order list of=20 >>>>>>>>>>> service function identifiers). This is more compliant with the = LB constraints above: >>>>>>>>> deciding >>>>>>>>>>> which locator to use for a given flow will be a local=20 >>>>>>>>>>> decision not a centralized one. >>>>>>>>>>=20 >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>=20 >>>>>>>>>> Maria >>>>>>>>>=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 From nobody Wed Jul 9 15:39: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 B5A7E1A0065 for ; Wed, 9 Jul 2014 15:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 VluZE7dyrZQV for ; Wed, 9 Jul 2014 15:39:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE901A0064 for ; Wed, 9 Jul 2014 15:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9250; q=dns/txt; s=iport; t=1404945552; x=1406155152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z2HPgQYpbgvui1OvqJAJNRxyJbBuckzjg8Zt9PW038c=; b=N84GF02qtyxst2dNolGgJcux1proGN/47T0JURE6DcaIyonuc8NQ1HXu kTkBl2ZUaO+kCREh+PByRoy7dDawBIAWpHZeL2FCLK0qAWGkOuwKMhtMY Rg27+LaacUvU39I0THkwFB8A0Lsuc2THK2dYEeFewtxKoOzLZEhxl978V M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABTEvVOtJV2T/2dsb2JhbABZgw5SWr8cCIdBAYEQFnWEAwEBAQQBAQELVwkLDAQCAQgRAQMBAQEnBycLFAMGCAIEAQ0FG4gnDchJEwSOaywrBwaEPQEEllyEGoteiC6DQ4FvQQ X-IronPort-AV: E=Sophos;i="5.01,634,1400025600"; d="scan'208";a="338982290" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jul 2014 22:39:11 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s69Md7cO031235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 22:39:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 17:39:07 -0500 From: "Ken Gray (kegray)" To: Ron Parker , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W1xFLfwWzB0GPcC0T+kkpD5uXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigD//8fDgA== Date: Wed, 9 Jul 2014 22:39:06 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.142] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1BDF49868FE4344DB32A73BE66678964@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RIsCesJxSfK0TrG2M_Dkzu9bgac Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 22:39:11 -0000 The whole idea of dynamic elasticity control is to hide this detail from you and to make the instances ephemeral. When you send a packet from your classifier to my elastic firewall, the component(s) that make it elastic are what you address =8A the elastic control of my elastic firewall picks the instance based on it's own local policy or higher level orchestration/policy control at an out-of-scope-above-the-line-for-sfc layer. Yes, I can layer this abstraction to scale to a very, very large number of instances and still present a single addressable point of distribution. The very scale problem you mention is what the scheme addresses, yet we seem to be wanting to peel that away. As Jim stated, IF you want to separately address each instance (with either the explosion of paths or the huge feedback loop from orchestration and control, central micro-flow control, volume of changes to your classifiers, etc.) - go for it. The architecture allows it. Has to. Some people might deploy that way. The very basic point made in the original argument is "you don't have to do that". This is readily demonstrable (I or a number of other vendors can send a sales guy to do a demo). What I won't agree to here is that elasticity somehow creates an unknowable path element. It shouldn't unless you did it wrong. Maybe there's a better example that might justify substituting the chain for the path (and then dynamically resolving this in the background adding huge scale considerations) =8Abut it's not elasticity. On 7/9/14 6:00 PM, "Ron Parker" wrote: >Jim, > >Respectfully, I'm not comfortable with that. While it is easy to say >that this is a layered problem and that load balancing belongs at a lower >level, it seems to me that load balancing of the service functions (not >load balancer as a service function) should be an explicit consideration >of the SFC architecture. I say this not only from a scale perspective, >but also with resiliency in mind. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, July 09, 2014 5:48 PM >To: Ron Parker >Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >NAPIERALA, MARIA H >Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >I would say that's implementation. > >Sent from my iPhone > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >> wrote: >>=20 >> Agreed. But is that in scope for SFC or out of scope for SFC? >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:29 PM >> To: Ron Parker >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Well of course not; in that case you load balance up a level between >>those nodes and then locally. >>=20 >> Sent from my iPhone >>=20 >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> wrote: >>>=20 >>> Jim, >>>=20 >>> There may not be a single node through which all of the instances can >>>be reached (at some reasonable limit of L2 or L3 hops). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>> (jguichar) >>> Sent: Wednesday, July 09, 2014 5:12 PM >>> To: NAPIERALA, MARIA H >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> At the node through which the 20 instances are reachable. IOW you >>>don't have to individually address packets to each and every instance. >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>wrote: >>>>=20 >>>> Hi Jim, >>>>=20 >>>> When you say "locally", where is it? >>>>=20 >>>> Maria >>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> Hi Maria, >>>>>=20 >>>>> Absolutely and categorically no! If you have 20 instances at each >>>>> hop then you can choose to load balance among them locally >>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>> some very odd and certainly not recommended reason you want to >>>>> treat each instance separately then the architecture does not >>>>>prevent it. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>>=20 >>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>> separately, then the service chaining infrastructure would treat >>>>>>> them as such, and would use distinct service paths. >>>>>>=20 >>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>> then I have >>>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>>> have yet to see a solution that work this way and scales.. >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>> instances >>>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>>> which of those >>>>> 20 >>>>>>> firewalls will be used by a particular flow? >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>> Halpern >>>>> Direct >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>> sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>=20 >>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>> having the global decision that is directing the traffic. That >>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>=20 >>>>>>>>> The definition of the service path is about how service >>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>> that, and they can give the same external interface. >>>>>>>>>=20 >>>>>>>>> We could write the architecture pretending that it always >>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>> would be a misleading architectural description and might be >>>>>>>>> read to outlaw some solutions that fall within the goal the WG >>>>>>>>>wishes to meet. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>> be >>>>>>> determined >>>>>>>>> in >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>>> based >>>>>>> on >>>>>>>>> the >>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>> service function identifiers). This is more compliant with the >>>>>>>>>>>LB constraints above: >>>>>>>>> deciding >>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>> decision not a centralized one. >>>>>>>>>>=20 >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>=20 >>>>>>>>>> Maria >>>>>>>>>=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 > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 16:20: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 53BEA1B282C for ; Wed, 9 Jul 2014 16:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 YQZsSSamEoV6 for ; Wed, 9 Jul 2014 16:20:33 -0700 (PDT) Received: from mxecd03.gs.com (mxe1.gs.com [204.4.187.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8FE1A016E for ; Wed, 9 Jul 2014 16:20:31 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,634,1400040000"; d="scan'208,217"; a="49798362" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxecd03.idz.gs.com with ESMTP; 09 Jul 2014 19:20:30 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp09ex.firmwide.corp.gs.com ([10.135.172.18]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 09 Jul 2014 19:20:30 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp09ex.firmwide.corp.gs.com ([10.135.172.18]) with mapi; Wed, 9 Jul 2014 19:20:30 -0400 To: 'Ian Smith' , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Date: Wed, 9 Jul 2014 19:20:29 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgABl8oCAABa+gIAAOkGA//+RfCGAABIEsIAABZCrgAAvCkA= Message-ID: References: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4CF7GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/m8vJISSamMNw42jS4qMO3EJOptw Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 23:20:44 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4CF7GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks so much for the detailed explanation, Ian. Please see below. ..."predetermination is that it is possible in the initial state, but not i= mportant"... "Where I perceive confusion on the list is when the Service Function Chain = is in some sense "To Be Determined" because one or more of the Service Func= tions have discretionary rules that leave the next hop in the chain indeter= minate until a packet presents itself to the Service Function Instance (mos= tly because of middle-boxes), but the Service Function itself MUST be decla= red before we can select (by any means) a Service Function Instance. And o= nce in the midst of evaluating the conditional requirement, we have a finit= e set of "next Service Functions". I can define a completely deterministic= conditional statement, and we should permit such things and leave them to = the implementers to restrict if they want, but my gut says that most of the= conditional rules will be of the sort where all the possible outcomes MAY = be foreseen before evaluation (eg. if this, then that, else that2) in which= case the SPI is not indeterminate (that is, entirely unknown until evaluat= ion), merely uncertain (that is, which of these possible outcomes is more l= ikely), which is significantly easier to deal with. That is the example fr= om my first email in this thread." I see that in some cases, some omniscient system could foresee the backend = server (next-hop) a given app flow should go to, in the initial state. Say,= if the load balancing algorithm is "round-robin" on the load balancer. But= not everything can be foreseen. How would it work for those load balancing= algorithms that use real-time metrics like "least number of connections", = "least amount of response time", "least bandwidth"? The omniscient system w= ill have to predict what the load balancer will be seeing by the time the f= irst packets show up at the load balancer, and put the predicted server in = the SFP? So while I agree that predetermination is possible is some cases, I'd argue= that it's not possible in all cases. The issue is how to deal with those "= to be determined" cases. I'm still digesting your "magic thread" explanatio= n. Regards, From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith Sent: 9 July 2014 5:36 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Mostly. I've been defining things like this: * Service Function Domain as the logical area in which Service Func= tion Chains are defined. There are various names for them but basically al= l the architectures define an "ingress" and an "egress" node that anchors a= chain at each end - this is the space between them. * Service Function Chain as "an ordered sequence of a finite number= of functions" * Service Function Path as "an ordered sequence of particular insta= nces of service functions within a Service Function Chain". * Service Function as an abstract thing - "URL Filter" * Service Function Node as the physical piece of hardware that hous= es the Service Function - "this server" * Service Function Instance as a particular instance of a service f= unction - "this URL Filter on this Service Function Node" - and it can be a= virtual machine, a container, or just an instance of software on the SFN. This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there. I may have incorrectly believed this to be a case o= f settled meaning. Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture. It does exist, and by definition it exists becaus= e packets are moving along it. In the most rudimentary case, you are passi= ng from node to node to some destination far away using only their default = gateway; the SFI is the agglomeration of their default gateways. This easi= ly evolves to IP Source Routes, MPLS lable stacks, and other in-packet mech= anisms, but it just as easily evolves to an orchestration system inserting = policy routes into nodes in a "just in time" fashion or tying the client IP= to a pre-existing policy that includes the next hop. The latter case is w= hat my previous example showed. You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service= Function Path (and if you don't have that path defined, recurse through th= e id to find the Service Function Chain to make whatever evaluation is requ= ired by you to send me on my way.)" or a orchestration system. I confess t= o geekishly liking the idea of using the IPX+ address schema for this. Example: 6 byte SFD:4 byte SFC:6 byte SFP aabbccddeeff:0123:6e01e1f421d3 (I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using ex= isting mechanisms.) You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. Thi= s is perhaps too plainly stated, but it is easy and seems to be the path we= are chartered to take. So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met. I think that is not what people are asking for= . What I think people are asking for is a method for channelizing services= on packet switched networks, which I understand to mean that I should disa= ggregate flows at the boundary of a SFD, and force them into channels accor= ding to some external policy, keep them in their channel all the way throug= h the domain, and then reaggregate them on the other side. And to give the= people what they want, I think you do have to say something like, "the pat= h may vary but only amongst the SFIs that are defined by the SFC and once a= n SFI is selected for use by a flow, it stays selected until dismissed or i= t fails" which to me implies that you MUST select the chain, and you MAY s= elect as many instances within that chain that the policy allows, but you M= UST respect conditional elements of the chain and to do that you have to, i= n essence, select all the possible instances implied by the chain. (I don'= t know if calling it a Markov chain problem helps, but it is an apt descrip= tion in my mind.) That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important. Once you= evaluate the conditional requirements however, then the path is set and it= SHOULD remain fixed until an input to the conditional requirements changes= . I would expect that change to come from four principal areas: Failure, = packet inspection, content switching, or policy update. There could be mor= e, but those seem to be the main archetypes. Of those two, packet inspecti= on results and content switching are clearly the kind of conditional requir= ement that belong in a SFC definition, while there is a strong case that no= de or network failures and policy updates will be orthogonal inputs the the= whole system, not something that can be clearly identified and dealt with = on the data plane. Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Service Funct= ions have discretionary rules that leave the next hop in the chain indeterm= inate until a packet presents itself to the Service Function Instance (most= ly because of middle-boxes), but the Service Function itself MUST be declar= ed before we can select (by any means) a Service Function Instance. And on= ce in the midst of evaluating the conditional requirement, we have a finite= set of "next Service Functions". I can define a completely deterministic = conditional statement, and we should permit such things and leave them to t= he implementers to restrict if they want, but my gut says that most of the = conditional rules will be of the sort where all the possible outcomes MAY b= e foreseen before evaluation (eg. if this, then that, else that2) in which = case the SPI is not indeterminate (that is, entirely unknown until evaluati= on), merely uncertain (that is, which of these possible outcomes is more li= kely), which is significantly easier to deal with. That is the example fro= m my first email in this thread. How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread". If= we don't what to get into that at all, then it is sufficient to say that a= SFC definition MUST include a way to identify all potential SFI's for incl= uded SF's, and that implementations SHOULD resolve as many of the possible = SFI's implied by a SFC before making an assignment and that if there are co= nditional rules in the SFC, then implementations MUST resolv all of the pos= sible SFI's and, by use of the magic thread, tell them all that they should= be prepared to participate in SFI-x for client-A. I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. Example: show service-chain client 2001:db8:0::abc:123:def:456 all service-chain 100 path da29c34de0af:0123:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION url-filter 2001:db8:0:20::80.45.80 opaque web-cache 2001:db8:0:21::80.224.80 carp {http://gothamist.com/2014= /07/09/cooler_weather_arrives_on_the_anniv.php} web-optimizer 2001:db8:0:22::80.137.80 conditional match firewall 2001:db8:0:23::80.132 current-conns 3245 {3992,4503,3= 389} service-chain 109 path da29c34de0af:0134:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION dns-filter 2001:db8:0:100::53:98.53 passed dns-cache 2001:db8:0:100::53:129.53 miss dns-switch 2001:db8:0:100::53:223.53 off-net, icann tld dns-server 2001:db8:0:99::53:23.53 SOA 2001:db8:fa99:e8b4:123:abcd= :4567:ef01.53 Translation: The client at 2001:db8:0::abc:123:def:456 currently has Servi= ce Function Paths active in two Service Function Chains - 100 and 109 - wi= th the particular Service Function Instances listed in correspondence to th= e Service Function and any information reported by the SFI pertaining to th= e state of the SFP. You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. ________________________________ From: Zarny, Myo [Myo.Zarny@gs.com] Sent: Wednesday, July 09, 2014 3:46 PM To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Bou= cadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hi Ian, Thanks for the write-up. Just to confirm I get this right: You're saying the SFC is a collection of = abstracted desired service functions (your point 1) while the actual path a= given application flow traverses is determined by the service functions th= emselves? E.g., your examples in points (2, 3, 4 and 5)? In your examples, the actual flows (say, TCP connections between the same p= air of endpoints) can traverse different SF paths-nothing wrong with that-e= ven if they follow the same exact SF chain. This mean the SFP isn't predete= rmined (since it's the actual entities that decide the next service functio= n). Do I get that right? Myo PS: Btw, no one has tackled my reverse path question. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: 9 July 2014 2:54 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } Translation: send to instances of these 4 services in this order. 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example: service-function url-filter { dns _http._tcp.url-filter.example.com fallback bypass } Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function. 3. You may define a service function conditionally. Example: service-function web-optimizer { if { [class match [HTTP::url] eq optimizable-content] } { ip 2001:db8:0:22::137.80 } else { service-function firewall } } Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall. 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example: service-function web-cache { lb carp [HTTP::url] @2001:db8:0:21::224.80 } Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic. 5. You may load balance directly in the path selection process. Example: service-function firewall { pool { least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections} ip 2001:db8:23::130 ip 2001:db8:23::131 ip 2001:db8:23::132 ip 2001:db8:23::133 } } Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections. 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example: service-function url-filter { opaque dns _http._tcp.url-filter.example.com } Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain. --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4CF7GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks so= much for the detailed explanation, Ian. Please see below.

 

 

…= ”predetermination is that it is possible in the initial state, but no= t important”…

 

“= Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Ser= vice Functions have discretionary rules that leave the next hop in the chai= n indeterminate until a packet presents itself to the Service Function Inst= ance (mostly because of middle-boxes), but the Service Function itself MUST= be declared before we can select (by any means) a Service Function Instanc= e.  And once in the midst of evaluating the conditional requirement, w= e have a finite set of "next Service Functions".  I can defi= ne a completely deterministic conditional statement, and we should permit s= uch things and leave them to the implementers to restrict if they want, but= my gut says that most of the conditional rules will be of the sort where a= ll the possible outcomes MAY be foreseen before evaluation (eg. if this, th= en that, else that2) in which case the SPI is not indeterminate (that is, e= ntirely unknown until evaluation), merely uncertain (that is, which of thes= e possible outcomes is more likely), which is significantly easier to deal = with.  That is the example from my first email in this thread.”<= br>

I se= e that in some cases, some omniscient system could foresee the backe= nd server (next-hop) a given app flow should go to, in the initial state. S= ay, if the load balancing algorithm is “round-robin” on the loa= d balancer. But not everything can be foreseen. How would it work for those= load balancing algorithms that use real-time metrics like “least num= ber of connections”, “least amount of response time”, = 220;least bandwidth”? The omniscient system will have to predict what= the load balancer will be seeing by the time the first packets show up at = the load balancer, and put the predicted server in the SFP?

 

So while I agree that predetermination is possible is some c= ases, I’d argue that it’s not possible in all cases. The issue = is how to deal with those “to be determined” cases. I’m s= till digesting your “magic thread” explanation.

 

Regards,

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 

Fro= m: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: 9 July 2014 5:36 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya= (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joe= l M. Halpern'; 'sfc@ietf.org'
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers

 

Mostly.

I've been defining things= like this:

·= ;     = ;    Service Function Dom= ain as the logical area in which Service Function Chains are defined. = There are various names for them but basically all the architectures defin= e an "ingress" and an "egress" node that anchors a chai= n at each end - this is the space between them.

·         Service Function Chain as "an ordered sequence of a fi= nite number of functions"

· &nbs= p;       S= ervice Function Path as "an ordered sequence of particular instances o= f service functions within a Service Function Chain". 

·         <= /span>Service Function as an abstract thing - &= quot;URL Filter"

·   &= nbsp;     Service Fu= nction Node as the physical piece of hardware that houses the Service Funct= ion - "this server"

·  = ;       Se= rvice Function Instance as a particular instance of a service function - &q= uot;this URL Filter on this Service Function Node" - and it can be a v= irtual machine, a container, or just an instance of software on the SFN.


This is consis= tent with material presented at IETF89 and it didn't seem a matter of debat= e there.  I may have incorrectly believed this to be a case of settled= meaning.

Where the Service Function Path is defined is, in my mind= , somewhat irrelevant to the architecture.  It does exist, and by defi= nition it exists because packets are moving along it.  In the most rud= imentary case, you are passing from node to node to some destination far aw= ay using only their default gateway; the SFI is the agglomeration of their = default gateways.  This easily evolves to IP Source Routes, MPLS lable= stacks, and other in-packet mechanisms, but it just as easily evolves to a= n orchestration system inserting policy routes into nodes in a "just i= n time" fashion or tying the client IP to a pre-existing policy that i= ncludes the next hop.  The latter case is what my previous example sho= wed.

You could enter each of those example config stanzas onto a si= ngle node (that might happen to be an NFVi platform), or you could enter th= em each on a different piece of networking hardware and tie them together w= ith some sort of "magic thread" like an header field that says &q= uot;I belong on this Service Function Path (and if you don't have that path= defined, recurse through the id to find the Service Function Chain to make= whatever evaluation is required by you to send me on my way.)" or a o= rchestration system.  I confess to geekishly liking the idea of using = the IPX+ address schema for this. 

Example:

6 byte S= FD:4 byte SFC:6 byte SFP
aabbccddeeff:0123:6e01e1f421d3 

(I concede it is too indulgent for most people, but it delivers ma= ssive amounts of address space with scale out in domains, chains, and paths= while still being human readable and relatively easy to shim into lots of = places in a packet or in control plane systems and make referential queries= using existing mechanisms.)

You could assume that all of the metada= ta and orchestration stuff that the WG is not covering will deal with how t= o propagate a policy, and that once it is distributed and installed in the = nodes, it takes care of itself.  This is perhaps too plainly stated, b= ut it is easy and seems to be the path we are chartered to take.

So= , you ask if the path can vary between SFIs and if that is ok as long as th= e SFC requirement is met.  I think that is not what people are asking = for.  What I think people are asking for is a method for channelizing = services on packet switched networks, which I understand to mean that I sho= uld disaggregate flows at the boundary of a SFD, and force them into channe= ls according to some external policy, keep them in their channel all the wa= y through the domain, and then reaggregate them on the other side.  An= d to give the people what they want, I think you do have to say something l= ike, "the path may vary but only amongst the SFIs that are defined by = the SFC and once an SFI is selected for use by a flow, it stays selected un= til dismissed or it fails" which  to me implies that you MUST sel= ect the chain, and you MAY select as many instances within that chain that = the policy allows, but you MUST respect conditional elements of the chain a= nd to do that you have to, in essence, select all the possible instances im= plied by the chain.  (I don't know if calling it a Markov chain proble= m helps, but it is an apt description in my mind.)

That, I hope, exp= lains why my answer to your question about predetermination is that it is p= ossible in the initial state, but not important.  Once you evaluate th= e conditional requirements however, then the path is set and it SHOULD rema= in fixed until an input to the conditional requirements changes.  I wo= uld expect that change to come from four principal areas:  Failure, pa= cket inspection, content switching, or policy update.  There could be = more, but those seem to be the main archetypes.  Of those two, packet = inspection results and content switching are clearly the kind of conditiona= l requirement that belong in a SFC definition, while there is a strong case= that node or network failures and policy updates will be orthogonal inputs= the the whole system, not something that can be clearly identified and dea= lt with on the data plane.

Where I perceive confusion on the list is= when the Service Function Chain is in some sense "To Be Determined&qu= ot; because one or more of the Service Functions have discretionary rules t= hat leave the next hop in the chain indeterminate until a packet presents i= tself to the Service Function Instance (mostly because of middle-boxes), bu= t the Service Function itself MUST be declared before we can select (by any= means) a Service Function Instance.  And once in the midst of evaluat= ing the conditional requirement, we have a finite set of "next Service= Functions".  I can define a completely deterministic conditional= statement, and we should permit such things and leave them to the implemen= ters to restrict if they want, but my gut says that most of the conditional= rules will be of the sort where all the possible outcomes MAY be foreseen = before evaluation (eg. if this, then that, else that2) in which case the SP= I is not indeterminate (that is, entirely unknown until evaluation), merely= uncertain (that is, which of these possible outcomes is more likely), whic= h is significantly easier to deal with.  That is the example from my f= irst email in this thread.

How we deal with them, as a matter of arc= hitecture, really has to do with how much we want to talk about what I call= ed earlier "the magic thread".  If we don't what to get into= that at all, then it is sufficient to say that a SFC definition MUST inclu= de a way to identify all potential SFI's for included SF's, and that implem= entations SHOULD resolve as many of the possible SFI's implied by a SFC bef= ore making an assignment and that if there are conditional rules in the SFC= , then implementations MUST resolv all of the possible SFI's and, by use of= the magic thread, tell them all that they should be prepared to participat= e in SFI-x for client-A.

 

I'll follow up my earlier ex= ample with this example of how I might query for the service function path = from a network console that has a suitable omniscient view to actually tell= me the answer. 

Example:

show service-chain client = 2001:db8:0::abc:123:def:456 all

service-chain 100 path da29c34de0af:= 0123:6e01e1f421d3

FUNCTION       = INSTANCE             &nb= sp;      DESCRIPTION
url-filter   &nb= sp;  2001:db8:0:20::80.45.80     opaque
web-cac= he       2001:db8:0:21::80.224.80  =   carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_on_the_= anniv.php}
web-optimizer   2001:db8:0:22::80.137.80  = ;  conditional match
firewall        = 2001:db8:0:23::80.132       current-conns 3245 {39= 92,4503,3389}       

service-chain 10= 9 path da29c34de0af:0134:6e01e1f421d3

FUNCTION   &nbs= p;    INSTANCE         &n= bsp;          DESCRIPTION
dns-filter&= nbsp;     2001:db8:0:100::53:98.53    passed<= br>dns-cache       2001:db8:0:100::53:129.53 =   miss
dns-switch      2001:db8:0:100::53:223.5= 3   off-net, icann tld
dns-server     = ; 2001:db8:0:99::53:23.53     SOA 2001:db8:fa99:e8b4:12= 3:abcd:4567:ef01.53

Translation:  The client at 2001= :db8:0::abc:123:def:456 currently has Service Function Paths active in two = Service Function Chains - 100 and 109  - with the particular Service F= unction Instances listed in correspondence to the Service Function and any = information reported by the SFI pertaining to the state of the SFP.

= You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. 

From: Zarny, Myo [Myo.Zarny@gs.= com]
Sent: Wednesday, July 09, 2014 3:46 PM
To: Ian Smi= th; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
= Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] S= ervice Chains, Paths, and Load Balancers=

Hi Ian,

 <= /o:p>

= Thanks for the write-up.

 =

Just to confirm I get this right: You’re saying the SFC = is a collection of abstracted desired service functions (your point 1) whil= e the actual path a given application flow traverses is determined by the s= ervice functions themselves? E.g., your examples in points (2, 3, 4 and 5)?=

 

In your examples, t= he actual flows (say, TCP connections between the same pair of endpoints) c= an traverse different SF paths—nothing wrong with that—even if = they follow the same exact SF chain. This mean the SFP isn’t predeter= mined (since it’s the actual entities that decide the next service fu= nction).

 

Do I get th= at right?

 

<= /div>

Myo=

 

PS: Btw, no one has tackle= d my reverse path question.

 =

 

-----Original Message-----
From: Ia= n Smith [mailto:I.Smith= @F5.com]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo = Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel = M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, an= d Load Balancers

 

1. You don't have to know the = particular service function instances to define the service function chain.=   Example:

 

service-chain 100 {=

=           10 url-filter

<= span style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:bla= ck'>          20 web-cache

          30 web-optimi= zer

          40 fir= ewall

}

 

Translation:  send to ins= tances of these 4 services in this order.

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

2. You= don't have to know the ip address of a service function instance to define= that an instance does exist.  Example:

 

ser= vice-function url-filter {

      &n= bsp;  dns _http._tcp.url-filter.example.com

  &nbs= p;      fallback bypass

}

&nbs= p;

Translation:  query DNS for the address and use it, if yo= u can't resolve an address, skip this function.

=

 =

= 3. You may define a service function conditionally.  Example:

 

service-function web-optimizer {

  &= nbsp;      if { [class match [HTTP::url] eq optimi= zable-content] } {

       &nbs= p;    ip 2001:db8:0:22::137.80

   &= nbsp;     } else {

    &n= bsp;       service-function firewall

         }

<= /div>

}

 

Translation:  if the url is known to be optimizable,= use this IP address, otherwise skip this function and go directly to the f= irewall.

 

4. You may pre-select a load balancing = decision at the time that the Service Function Path is being selected. = ; Example:

 

service-function web-cache {

         lb carp [HTTP::url] @200= 1:db8:0:21::224.80 } 

 

Translation: instruc= t the load balancer at the given virtual address to make a load balancing d= ecision using the carp hash of the url and expect us to send it traffic.

 

5. You may load balance directly in the path sel= ection process.  Example:

 

=

service-function = firewall {

         pool = {

          &nb= sp;   least-connections {urn:oid:[Firewall.connections.active] ||= local:active_connections}

      &n= bsp;       ip 2001:db8:23::130

&nbs= p;             = ip 2001:db8:23::131

       &nb= sp;      ip 2001:db8:23::132

=

  = ;            ip 2001= :db8:23::133

         }&n= bsp;            = ;

}

 

Translation:  using eithe= r the snmp query to the given oid, or our own internal counters, pick the i= p address from this list that has the least amount of current connections.<= o:p>

 

6. You may just declare that the service functio= n is a complex of servers behind a screening device (like a nat or load bal= ancer).  Example:

 

service-function url-filt= er {

         opaque=

         dns _http._tcp.url-f= ilter.example.com }

 

Translation: use dns to sele= ct the instance, but know that there will be a hidden service function path= segment inserted before the next link in the service function chain.<= /o:p>

=  

 

 

= --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4CF7GSCMAMP19EXfi_-- From nobody Wed Jul 9 16:28: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 63CFF1A016E for ; Wed, 9 Jul 2014 16:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 K8vbt73HR9Fc for ; Wed, 9 Jul 2014 16:28:20 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421181A0169 for ; Wed, 9 Jul 2014 16:28:20 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D003353E16; Wed, 9 Jul 2014 16:26:33 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 9 Jul 2014 16:26:33.765 -0700 x-echoworx-msg-id: 1de869db-52cc-4f86-8843-bfd9006b467e x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 721; Wed, 9 Jul 2014 16:26:33 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 9DD0553E16; Wed, 9 Jul 2014 16:26:33 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Wed, 9 Jul 2014 16:28:20 -0700 From: Ron Parker To: "Ken Gray (kegray)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5k7AP//lq6j Date: Wed, 9 Jul 2014 23:28:18 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xWjKpUNKePaD6C_NfuDKeVdGdyc Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 23:28:22 -0000 Ken, As I pointed out in my previous email, my concern is more about resiliency = than elasticity. I understand the benefits of layered load balancing, but= what about when this is hierarchical? Maria spoke of 20 instances, and t= he prevailing thinking seems to be that the top-level behavior of the SFC s= houldn't care. But what if the front-end entity fails? What if its inte= rnal redundancy, if any, fails to perform when called upon? Might the net= work designer choose to divide the 20 instances into 2 groupings of 10 and = have a front-end entity for each grouping? So now the top-level behavior = of the SFC must choose amongst 2 rather than 20 for this particular logical= service function. But a choice still needs to be made. Is this, too, o= utside the scope of SFC? If not, is the architecture going to explicitly = address it, or leave it as an implementation issue? Ron ________________________________________ From: Ken Gray (kegray) [kegray@cisco.com] Sent: Wednesday, July 09, 2014 6:39 PM To: Ron Parker; Jim Guichard (jguichar) Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H; sfc= @ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The whole idea of dynamic elasticity control is to hide this detail from you and to make the instances ephemeral. When you send a packet from your classifier to my elastic firewall, the component(s) that make it elastic are what you address =8A the elastic control of my elastic firewall picks the instance based on it's own local policy or higher level orchestration/policy control at an out-of-scope-above-the-line-for-sfc layer. Yes, I can layer this abstraction to scale to a very, very large number of instances and still present a single addressable point of distribution. The very scale problem you mention is what the scheme addresses, yet we seem to be wanting to peel that away. As Jim stated, IF you want to separately address each instance (with either the explosion of paths or the huge feedback loop from orchestration and control, central micro-flow control, volume of changes to your classifiers, etc.) - go for it. The architecture allows it. Has to. Some people might deploy that way. The very basic point made in the original argument is "you don't have to do that". This is readily demonstrable (I or a number of other vendors can send a sales guy to do a demo). What I won't agree to here is that elasticity somehow creates an unknowable path element. It shouldn't unless you did it wrong. Maybe there's a better example that might justify substituting the chain for the path (and then dynamically resolving this in the background adding huge scale considerations) =8Abut it's not elasticity. On 7/9/14 6:00 PM, "Ron Parker" wrote: >Jim, > >Respectfully, I'm not comfortable with that. While it is easy to say >that this is a layered problem and that load balancing belongs at a lower >level, it seems to me that load balancing of the service functions (not >load balancer as a service function) should be an explicit consideration >of the SFC architecture. I say this not only from a scale perspective, >but also with resiliency in mind. > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Wednesday, July 09, 2014 5:48 PM >To: Ron Parker >Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >NAPIERALA, MARIA H >Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >I would say that's implementation. > >Sent from my iPhone > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >> wrote: >> >> Agreed. But is that in scope for SFC or out of scope for SFC? >> >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:29 PM >> To: Ron Parker >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Well of course not; in that case you load balance up a level between >>those nodes and then locally. >> >> Sent from my iPhone >> >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> wrote: >>> >>> Jim, >>> >>> There may not be a single node through which all of the instances can >>>be reached (at some reasonable limit of L2 or L3 hops). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>> (jguichar) >>> Sent: Wednesday, July 09, 2014 5:12 PM >>> To: NAPIERALA, MARIA H >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> At the node through which the 20 instances are reachable. IOW you >>>don't have to individually address packets to each and every instance. >>> >>> Sent from my iPhone >>> >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>wrote: >>>> >>>> Hi Jim, >>>> >>>> When you say "locally", where is it? >>>> >>>> Maria >>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Hi Maria, >>>>> >>>>> Absolutely and categorically no! If you have 20 instances at each >>>>> hop then you can choose to load balance among them locally >>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>> some very odd and certainly not recommended reason you want to >>>>> treat each instance separately then the architecture does not >>>>>prevent it. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>> >>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>> separately, then the service chaining infrastructure would treat >>>>>>> them as such, and would use distinct service paths. >>>>>> >>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>> then I have >>>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>>> have yet to see a solution that work this way and scales.. >>>>>> >>>>>> Maria >>>>>> >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>> instances >>>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>>> which of those >>>>> 20 >>>>>>> firewalls will be used by a particular flow? >>>>>>>> >>>>>>>> Maria >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>> Halpern >>>>> Direct >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>> sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>> having the global decision that is directing the traffic. That >>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>> >>>>>>>>> The definition of the service path is about how service >>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>> that, and they can give the same external interface. >>>>>>>>> >>>>>>>>> We could write the architecture pretending that it always >>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>> would be a misleading architectural description and might be >>>>>>>>> read to outlaw some solutions that fall within the goal the WG >>>>>>>>>wishes to meet. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>> be >>>>>>> determined >>>>>>>>> in >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>>> based >>>>>>> on >>>>>>>>> the >>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>> service function identifiers). This is more compliant with the >>>>>>>>>>>LB constraints above: >>>>>>>>> deciding >>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>> decision not a centralized one. >>>>>>>>>> >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>> >>>>>>>>>> Maria >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 16:52: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 D15771B2843 for ; Wed, 9 Jul 2014 16:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfc8l_rzkjTy for ; Wed, 9 Jul 2014 16:52:31 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 40F861A0177 for ; Wed, 9 Jul 2014 16:52:31 -0700 (PDT) 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, 9 Jul 2014 19:52:30 -0400 From: Dave Dolson To: "'kegray@cisco.com'" , "'Ron_Parker@affirmednetworks.com'" , "'jguichar@cisco.com'" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8TiXG39PP2ykqnE6BUP5ie9puXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgABGooCAAADNgIAABIYAgAADigCAAArXAP//0XRC Date: Wed, 9 Jul 2014 23:52:30 +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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JbgOGWRmjmN8X3y3w6s9LbXYMNY Cc: "'jmh@joelhalpern.com'" , "'mohamed.boucadair@orange.com'" , "'mn1921@att.com'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jul 2014 23:52:34 -0000 S2VuLA0KV2hlbiB5b3Ugc2F5LCAiaGlkZSB0aGUgZGV0YWlsIGZyb20geW91Iiwgd2hvIGlzIGl0 IGJlaW5nIGhpZGRlbiBmcm9tPw0KDQpZb3Ugc2VlbSB0byBiZSBzYXlpbmcgdGhlIGNsYXNzaWZp ZXIgZG9lc24ndCBuZWVkIHRoZSBkZXRhaWxzLiANCg0KSSd2ZSBiZWVuIHRoaW5raW5nIHRoZSBj bGFzc2lmaWVyIGlzIHBhcnQgb2YgdGhlIFNGQyBzeXN0ZW0gYW5kIHdvdWxkIHRoZXJlZm9yZSBy ZWFzb25hYmx5IGJlIGF3YXJlIG9mIGFsbCBvZiB0aGUgcGF0aHMuIA0KDQpJbiBmYWN0LCBpZiB5 b3Ugd2FudCB0byBoaWRlIHRoZSBkZXRhaWxzIGZyb20gdGhlIGNsYXNzaWZpZXIsIHlvdSBuZWVk IGFub3RoZXIgY2xhc3NpZmllci1saWtlIHRoaW5nIHdpdGhpbiB0aGUgc3lzdGVtIHRoYXQga25v d3MgdGhlIGRldGFpbHMuIFRoaXMgaXMgYSBoaWVyYXJjaGljYWwgaW1wbGVtZW50YXRpb24uIA0K DQpTbyBJJ20gbGVkIGluIHRoZSBkaXJlY3Rpb24gdGhhdCBpdCBpcyBvayBmb3IgYWxsIHBhdGgg Y29tcGxleGl0aWVzIHRvIGJlIGtub3duIGluIHRoZSBzeXN0ZW0uIA0KQXMgc29vbiBhcyB5b3Ug aGlkZSBzdHVmZiwgdGhhdCBpcyBjcmVhdGluZyBhIGhpZXJhcmNoeSwgd2hpY2ggaXMgT0ssIHJl Y29nbml6aW5nIGl0IGFzIHN1Y2guIA0KDQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwOSwgMjAxNCAwNjozOSBQTQpUbzogUm9uIFBhcmtlciA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT47IEppbSBHdWljaGFyZCAoamd1aWNoYXIp IDxqZ3VpY2hhckBjaXNjby5jb20+DQpDYzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT47IHNmY0BpZXRmLm9yZyA8c2ZjQGlldGYub3JnPjsgTkFQSUVSQUxBLCBNQVJJ QSBIIDxtbjE5MjFAYXR0LmNvbT4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpUaGUgd2hvbGUgaWRlYSBvZiBkeW5hbWljIGVs YXN0aWNpdHkgY29udHJvbCBpcyB0byBoaWRlIHRoaXMgZGV0YWlsIGZyb20NCnlvdSBhbmQgdG8g bWFrZSB0aGUgaW5zdGFuY2VzIGVwaGVtZXJhbC4NCg0KV2hlbiB5b3Ugc2VuZCBhIHBhY2tldCBm cm9tIHlvdXIgY2xhc3NpZmllciB0byBteSBlbGFzdGljIGZpcmV3YWxsLCB0aGUNCmNvbXBvbmVu dChzKSB0aGF0IG1ha2UgaXQgZWxhc3RpYyBhcmUgd2hhdCB5b3UgYWRkcmVzcyDFoCB0aGUgZWxh c3RpYw0KY29udHJvbCBvZiBteSBlbGFzdGljIGZpcmV3YWxsIHBpY2tzIHRoZSBpbnN0YW5jZSBi YXNlZCBvbiBpdCdzIG93biBsb2NhbA0KcG9saWN5IG9yIGhpZ2hlciBsZXZlbCBvcmNoZXN0cmF0 aW9uL3BvbGljeSBjb250cm9sIGF0IGFuDQpvdXQtb2Ytc2NvcGUtYWJvdmUtdGhlLWxpbmUtZm9y LXNmYyBsYXllci4NCg0KWWVzLCBJIGNhbiBsYXllciB0aGlzIGFic3RyYWN0aW9uIHRvIHNjYWxl IHRvIGEgdmVyeSwgdmVyeSBsYXJnZSBudW1iZXIgb2YNCmluc3RhbmNlcyBhbmQgc3RpbGwgcHJl c2VudCBhIHNpbmdsZSBhZGRyZXNzYWJsZSBwb2ludCBvZiBkaXN0cmlidXRpb24uDQoNClRoZSB2 ZXJ5IHNjYWxlIHByb2JsZW0geW91IG1lbnRpb24gaXMgd2hhdCB0aGUgc2NoZW1lIGFkZHJlc3Nl cywgeWV0IHdlDQpzZWVtIHRvIGJlIHdhbnRpbmcgdG8gcGVlbCB0aGF0IGF3YXkuDQoNCkFzIEpp bSBzdGF0ZWQsIElGIHlvdSB3YW50IHRvIHNlcGFyYXRlbHkgYWRkcmVzcyBlYWNoIGluc3RhbmNl ICh3aXRoDQplaXRoZXIgdGhlIGV4cGxvc2lvbiBvZiBwYXRocyBvciB0aGUgaHVnZSBmZWVkYmFj ayBsb29wIGZyb20gb3JjaGVzdHJhdGlvbg0KYW5kIGNvbnRyb2wsIGNlbnRyYWwgbWljcm8tZmxv dyBjb250cm9sLCB2b2x1bWUgb2YgY2hhbmdlcyB0byB5b3VyDQpjbGFzc2lmaWVycywgZXRjLikg LSBnbyBmb3IgaXQuICBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBpdC4gIEhhcyB0by4NClNvbWUg cGVvcGxlIG1pZ2h0IGRlcGxveSB0aGF0IHdheS4NCg0KVGhlIHZlcnkgYmFzaWMgcG9pbnQgbWFk ZSBpbiB0aGUgb3JpZ2luYWwgYXJndW1lbnQgaXMgInlvdSBkb24ndCBoYXZlIHRvDQpkbyB0aGF0 Ii4NCg0KVGhpcyBpcyByZWFkaWx5IGRlbW9uc3RyYWJsZSAoSSBvciBhIG51bWJlciBvZiBvdGhl ciB2ZW5kb3JzIGNhbiBzZW5kIGENCnNhbGVzIGd1eSB0byBkbyBhIGRlbW8pLg0KDQpXaGF0IEkg d29uJ3QgYWdyZWUgdG8gaGVyZSBpcyB0aGF0IGVsYXN0aWNpdHkgc29tZWhvdyBjcmVhdGVzIGFu DQp1bmtub3dhYmxlIHBhdGggZWxlbWVudC4gIEl0IHNob3VsZG4ndCB1bmxlc3MgeW91IGRpZCBp dCB3cm9uZy4gIE1heWJlDQp0aGVyZSdzIGEgYmV0dGVyIGV4YW1wbGUgdGhhdCBtaWdodCBqdXN0 aWZ5IHN1YnN0aXR1dGluZyB0aGUgY2hhaW4gZm9yIHRoZQ0KcGF0aCAoYW5kIHRoZW4gZHluYW1p Y2FsbHkgcmVzb2x2aW5nIHRoaXMgaW4gdGhlIGJhY2tncm91bmQgYWRkaW5nIGh1Z2UNCnNjYWxl IGNvbnNpZGVyYXRpb25zKSDFoGJ1dCBpdCdzIG5vdCBlbGFzdGljaXR5Lg0KDQpPbiA3LzkvMTQg NjowMCBQTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiB3 cm90ZToNCg0KPkppbSwNCj4NCj5SZXNwZWN0ZnVsbHksIEknbSBub3QgY29tZm9ydGFibGUgd2l0 aCB0aGF0LiAgIFdoaWxlIGl0IGlzIGVhc3kgdG8gc2F5DQo+dGhhdCB0aGlzIGlzIGEgbGF5ZXJl ZCBwcm9ibGVtIGFuZCB0aGF0IGxvYWQgYmFsYW5jaW5nIGJlbG9uZ3MgYXQgYSBsb3dlcg0KPmxl dmVsLCBpdCBzZWVtcyB0byBtZSB0aGF0IGxvYWQgYmFsYW5jaW5nIG9mIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9ucyAobm90DQo+bG9hZCBiYWxhbmNlciBhcyBhIHNlcnZpY2UgZnVuY3Rpb24pIHNob3Vs ZCBiZSBhbiBleHBsaWNpdCBjb25zaWRlcmF0aW9uDQo+b2YgdGhlIFNGQyBhcmNoaXRlY3R1cmUu ICAgIEkgc2F5IHRoaXMgbm90IG9ubHkgZnJvbSBhIHNjYWxlIHBlcnNwZWN0aXZlLA0KPmJ1dCBh bHNvIHdpdGggcmVzaWxpZW5jeSBpbiBtaW5kLg0KPg0KPiAgIFJvbg0KPg0KPg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0 bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBKdWx5IDA5LCAyMDE0IDU6 NDggUE0NCj5UbzogUm9uIFBhcmtlcg0KPkNjOiBKb2VsIE0uIEhhbHBlcm47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZzsNCj5OQVBJRVJBTEEsIE1BUklBIEgNCj5T dWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCj4NCj5JIHdvdWxkIHNheSB0aGF0J3MgaW1wbGVtZW50YXRpb24uDQo+DQo+U2VudCBmcm9t IG15IGlQaG9uZQ0KPg0KPj4gT24gSnVsIDksIDIwMTQsIGF0IDU6MzEgUE0sICJSb24gUGFya2Vy Ig0KPj48Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+PiANCj4+IEFn cmVlZC4gICBCdXQgaXMgdGhhdCBpbiBzY29wZSBmb3IgU0ZDIG9yIG91dCBvZiBzY29wZSBmb3Ig U0ZDPw0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSmltIEd1 aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMDksIDIwMTQgNToyOSBQTQ0KPj4gVG86IFJvbiBQYXJrZXINCj4+IENj OiBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTsNCj4+IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiANCj4+IFdlbGwgb2YgY291 cnNlIG5vdDsgaW4gdGhhdCBjYXNlIHlvdSBsb2FkIGJhbGFuY2UgdXAgYSBsZXZlbCBiZXR3ZWVu DQo+PnRob3NlIG5vZGVzIGFuZCB0aGVuIGxvY2FsbHkuDQo+PiANCj4+IFNlbnQgZnJvbSBteSBp UGhvbmUNCj4+IA0KPj4+IE9uIEp1bCA5LCAyMDE0LCBhdCA1OjE3IFBNLCAiUm9uIFBhcmtlciIN Cj4+PjxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4+PiANCj4+PiBK aW0sDQo+Pj4gDQo+Pj4gVGhlcmUgbWF5IG5vdCBiZSBhIHNpbmdsZSBub2RlIHRocm91Z2ggd2hp Y2ggYWxsIG9mIHRoZSBpbnN0YW5jZXMgY2FuDQo+Pj5iZSByZWFjaGVkIChhdCBzb21lIHJlYXNv bmFibGUgbGltaXQgb2YgTDIgb3IgTDMgaG9wcykuDQo+Pj4gDQo+Pj4gIFJvbg0KPj4+IA0KPj4+ IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQNCj4+PiAoamd1 aWNoYXIpDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDA5LCAyMDE0IDU6MTIgUE0NCj4+PiBU bzogTkFQSUVSQUxBLCBNQVJJQSBIDQo+Pj4gQ2M6IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gDQo+Pj4gQXQg dGhlIG5vZGUgdGhyb3VnaCB3aGljaCB0aGUgMjAgaW5zdGFuY2VzIGFyZSByZWFjaGFibGUuIElP VyB5b3UNCj4+PmRvbid0IGhhdmUgdG8gaW5kaXZpZHVhbGx5IGFkZHJlc3MgcGFja2V0cyB0byBl YWNoIGFuZCBldmVyeSBpbnN0YW5jZS4NCj4+PiANCj4+PiBTZW50IGZyb20gbXkgaVBob25lDQo+ Pj4gDQo+Pj4+IE9uIEp1bCA5LCAyMDE0LCBhdCA1OjA3IFBNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb20+DQo+Pj4+d3JvdGU6DQo+Pj4+IA0KPj4+PiBIaSBKaW0sDQo+Pj4+ IA0KPj4+PiBXaGVuIHlvdSBzYXkgImxvY2FsbHkiLCB3aGVyZSBpcyBpdD8NCj4+Pj4gDQo+Pj4+ IE1hcmlhDQo+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZy b206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0K Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDA5LCAyMDE0IDU6MDYgUE0NCj4+Pj4+IFRvOiBO QVBJRVJBTEEsIE1BUklBIEgNCj4+Pj4+IENjOiBKb2VsIE0uIEhhbHBlcm47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4+PiANCj4+Pj4+ IEhpIE1hcmlhLA0KPj4+Pj4gDQo+Pj4+PiBBYnNvbHV0ZWx5IGFuZCBjYXRlZ29yaWNhbGx5IG5v ISBJZiB5b3UgaGF2ZSAyMCBpbnN0YW5jZXMgYXQgZWFjaA0KPj4+Pj4gaG9wIHRoZW4geW91IGNh biBjaG9vc2UgdG8gbG9hZCBiYWxhbmNlIGFtb25nIHRoZW0gbG9jYWxseQ0KPj4+Pj4gcmVzdWx0 aW5nIGluIGV4YWN0bHkgNCBwYXRocy4gV2hhdCBKb2VsIGlzIHNheWluZyBpcyB0aGF0IGlmIGZv cg0KPj4+Pj4gc29tZSB2ZXJ5IG9kZCBhbmQgY2VydGFpbmx5IG5vdCByZWNvbW1lbmRlZCByZWFz b24geW91IHdhbnQgdG8NCj4+Pj4+IHRyZWF0IGVhY2ggaW5zdGFuY2Ugc2VwYXJhdGVseSB0aGVu IHRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QNCj4+Pj4+cHJldmVudCBpdC4NCj4+Pj4+IA0KPj4+ Pj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPj4+Pj4gDQo+Pj4+PiBPbiBKdWwgOSwgMjAxNCwgYXQg NDo1MCBQTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPj4+Pj4gd3Jv dGU6DQo+Pj4+PiANCj4+Pj4+Pj4gSSBhbSBzYXlpbmcgdGhhdCBpZiB0aGUgMjAgdmlydHVhbCBm aXJld2FsbHMgYXJlIGRlcGxveWVkDQo+Pj4+Pj4+IHNlcGFyYXRlbHksIHRoZW4gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUgd291bGQgdHJlYXQNCj4+Pj4+Pj4gdGhlbSBhcyBz dWNoLCBhbmQgd291bGQgdXNlIGRpc3RpbmN0IHNlcnZpY2UgcGF0aHMuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gSWYgSSBoYXZlIGEgNCBob3Agc2VydmljZSBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBl YWNoIGhvcCwNCj4+Pj4+PiB0aGVuIEkgaGF2ZQ0KPj4+Pj4gdG8gZ2xvYmFsbHkgbWFuYWdlIDE2 MCwwMDAgc2VydmljZSBwYXRocyAoZm9yIG9uZSBjaGFpbik/IFdlbGwsIHdlDQo+Pj4+PiBoYXZl IHlldCB0byBzZWUgYSBzb2x1dGlvbiB0aGF0IHdvcmsgdGhpcyB3YXkgYW5kIHNjYWxlcy4uDQo+ Pj4+Pj4gDQo+Pj4+Pj4gTWFyaWENCj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIDcvOS8xNCwgNDowMCBQ TSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4+Pj4+Pj4gSSBoYWQgaW4gbWluZCBzaW5n dWxhciBpbnN0YW5jZXMsIHNheSwgMjAgdmlydHVhbCBmaXJld2FsbA0KPj4+Pj4+Pj4gaW5zdGFu Y2VzDQo+Pj4+Pj4+IHNvbWV3aGVyZSBpbiB0aGUgbWlkZGxlIG9mIGEgY2hhaW4uIEFyZSB5b3Ug c2F5aW5nIHRoYXQgeW91IHdpbGwNCj4+Pj4+Pj4gZGVjaWRlIChtYWtlIGEgbG9hZCBiYWxhbmNp bmcgZGVjaXNpb24pIGF0IHRoZSBlbnRyeSB0byB0aGUgY2hhaW4NCj4+Pj4+Pj4gd2hpY2ggb2Yg dGhvc2UNCj4+Pj4+IDIwDQo+Pj4+Pj4+IGZpcmV3YWxscyB3aWxsIGJlIHVzZWQgYnkgYSBwYXJ0 aWN1bGFyIGZsb3c/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE1hcmlhDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbA0KPj4+Pj4+Pj4+IEhh bHBlcm4NCj4+Pj4+IERpcmVjdA0KPj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwOSwg MjAxNCAzOjQxIFBNDQo+Pj4+Pj4+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsNCj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhlIGFyY2h0aWVjdHVyZSBhbGxvd3MgZm9yIHRoaXMg bG9jYWwgZGVjaXNpb24sIHdoaWxlIHN0aWxsDQo+Pj4+Pj4+Pj4gaGF2aW5nIHRoZSBnbG9iYWwg ZGVjaXNpb24gdGhhdCBpcyBkaXJlY3RpbmcgdGhlIHRyYWZmaWMuICBUaGF0DQo+Pj4+Pj4+Pj4g aXMsIHRoZSBnbG9iYWwgZGVjaXNpb24gZGlyZWN0cyB0aGUgdHJhZmZpYyB0byBwbGFjZXMgaW4g dGhlDQo+Pj4+Pj4+Pj4gbmV0d29yay4gIFRob3NlIHBsYWNlcyBtYXkgYmUgc2luZ3VsYXIgb3Ig Y2x1c3RlcnMuICBJZiB0aGV5DQo+Pj4+Pj4+Pj4gYXJlIGNsdXN0ZXJzLCB0aG9zZSBjbHVzdGVy cyBjYW4gdXNlIGFueSBudW1iZXIgb2YgYWxnb3JpdGhtcw0KPj4+Pj4+Pj4+IHRvIGRpc3RyaWJ1 dGUgdGhlIHRyYWZmaWMgaW50ZXJuYWxseSwgd2l0aG91dCBhbnkgZWZmZWN0IG9uDQo+Pj4+Pj4+ Pj4gc2VydmljZSBjaGFpbmluZy4gIChBbmQgeWVzLCB0aGlzIGNhbiBiZSBkb25lIGluIHN1Y2gg YSB3YXkNCj4+Pj4+Pj4+PiB0aGF0IHJldHVybiB0cmFmZmljLCBpZiBkZWxpdmVyZWQgZ2xvYmFs bHkgdG8gdGhlIHNhbWUgcGxhY2UsDQo+Pj4+Pj4+Pj4gY2FuIHRoZW4gYmUgZGVsaXZlcmVkIHRv IHRoZSByaWdodCBpbnRlcm5hbCBzdGF0ZS4pDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhlIGRl ZmluaXRpb24gb2YgdGhlIHNlcnZpY2UgcGF0aCBpcyBhYm91dCBob3cgc2VydmljZQ0KPj4+Pj4+ Pj4+IGNoYWluaW5nIHdpbGwgZGlyZWN0IHRoZSB0cmFmZmljLiAgaXQgaXMgbm90IGFib3V0IGhv dyB0aGUNCj4+Pj4+Pj4+PiBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZyBpcyBkb2VuLCBhcyB0aGVy ZSBhcmUgTUFOWSB3YXlzIHRvIGRvDQo+Pj4+Pj4+Pj4gdGhhdCwgYW5kIHRoZXkgY2FuIGdpdmUg dGhlIHNhbWUgZXh0ZXJuYWwgaW50ZXJmYWNlLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFdlIGNv dWxkIHdyaXRlIHRoZSBhcmNoaXRlY3R1cmUgcHJldGVuZGluZyB0aGF0IGl0IGFsd2F5cw0KPj4+ Pj4+Pj4+IGFkZHJlc3NlcyBzaW5ndWxhciBpbnN0YW5jZXMsIGJ1dCBrbm93aW5nIHRoYXQgcmVh bGl0eSB3b3VsZA0KPj4+Pj4+Pj4+IGFsbG93IGxvYWQgYmFsYW5jZWQgY2x1c3RlcnMgYXQgdGhv c2UgbG9jYXRpb25zLiAgQnV0IHRoYXQNCj4+Pj4+Pj4+PiB3b3VsZCBiZSBhIG1pc2xlYWRpbmcg YXJjaGl0ZWN0dXJhbCBkZXNjcmlwdGlvbiBhbmQgbWlnaHQgYmUNCj4+Pj4+Pj4+PiByZWFkIHRv IG91dGxhdyBzb21lIHNvbHV0aW9ucyB0aGF0IGZhbGwgd2l0aGluIHRoZSBnb2FsIHRoZSBXRw0K Pj4+Pj4+Pj4+d2lzaGVzIHRvIG1lZXQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gWW91cnMsDQo+ Pj4+Pj4+Pj4gSm9lbA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIDcvOS8xNCwgMzowNiBQTSwg TkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gW01lZF0gSSBzdGlsbCBkaXNh Z3JlZSB0aGF0IGFuIG9yZGVyZWQgbGlzdCBvZiBsb2NhdG9ycyBjYW4NCj4+Pj4+Pj4+Pj4+IGJl DQo+Pj4+Pj4+IGRldGVybWluZWQNCj4+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4+Pj4gYWR2YW5jZSBm b3IgYWxsIGRlcGxveW1lbnRzLiBJIHN1Z2dlc3QgdGhhdCBTRkMgZm9yd2FyZGluZyBiZQ0KPj4+ Pj4+Pj4+Pj4gYmFzZWQNCj4+Pj4+Pj4gb24NCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+IHNl cnZpY2UgY2hhaW4gaXRzZWxmIChjaGFyYWN0ZXJpemVkIGFzIGFuIG9yZGVyIGxpc3Qgb2YNCj4+ Pj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gaWRlbnRpZmllcnMpLiBUaGlzIGlzIG1vcmUgY29t cGxpYW50IHdpdGggdGhlDQo+Pj4+Pj4+Pj4+PkxCIGNvbnN0cmFpbnRzIGFib3ZlOg0KPj4+Pj4+ Pj4+IGRlY2lkaW5nDQo+Pj4+Pj4+Pj4+PiB3aGljaCBsb2NhdG9yIHRvIHVzZSBmb3IgYSBnaXZl biBmbG93IHdpbGwgYmUgYSBsb2NhbA0KPj4+Pj4+Pj4+Pj4gZGVjaXNpb24gbm90IGEgY2VudHJh bGl6ZWQgb25lLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gQWJzb2x1dGVseS4gSSBjYW5ub3Qg aW1hZ2luZSBob3cgZWxzZSBpdCBjYW4gYmUgZG9uZS4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ IE1hcmlhDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+ Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+ Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNA aWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+ PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Wed Jul 9 19:08: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 7913D1A03D7 for ; Wed, 9 Jul 2014 19:08:23 -0700 (PDT) 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 ml9TMyDaGn2r for ; Wed, 9 Jul 2014 19:08:17 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14921A0403 for ; Wed, 9 Jul 2014 19:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 90E24821A5F; Wed, 9 Jul 2014 19:08:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id A1A18821A5E; Wed, 9 Jul 2014 19:08:14 -0700 (PDT) Message-ID: <53BDF58D.7070108@joelhalpern.com> Date: Wed, 09 Jul 2014 22:08:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker , "Ken Gray (kegray)" , "Jim Guichard (jguichar)" References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KAYsOGbTNamrBBfJHOiPhIWd-zc Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 02:08:23 -0000 THere are multiple ways that the internal redundancy with the load balancers can be implemented. Any of them can be used with the service chaining architecture. There may be some aspects which need to be covered in the solution work. For example, I would expect solutions to have to discuss how we cope with SFF failure. And with failure of the linkage between the SFF and the SF. We could add text to the architecture indicating that solutions will need to be robust in dealing with failures of service chaining components and linkages. But I think we should not spell out the detailed mechanisms for that robustness in this document. Would adding a small section on robustness issues help? Yours, Joel On 7/9/14, 7:28 PM, Ron Parker wrote: > Ken, > > As I pointed out in my previous email, my concern is more about resiliency than elasticity. I understand the benefits of layered load balancing, but what about when this is hierarchical? Maria spoke of 20 instances, and the prevailing thinking seems to be that the top-level behavior of the SFC shouldn't care. But what if the front-end entity fails? What if its internal redundancy, if any, fails to perform when called upon? Might the network designer choose to divide the 20 instances into 2 groupings of 10 and have a front-end entity for each grouping? So now the top-level behavior of the SFC must choose amongst 2 rather than 20 for this particular logical service function. But a choice still needs to be made. Is this, too, outside the scope of SFC? If not, is the architecture going to explicitly address it, or leave it as an implementation issue? > > Ron > > > ________________________________________ > From: Ken Gray (kegray) [kegray@cisco.com] > Sent: Wednesday, July 09, 2014 6:39 PM > To: Ron Parker; Jim Guichard (jguichar) > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > The whole idea of dynamic elasticity control is to hide this detail from > you and to make the instances ephemeral. > > When you send a packet from your classifier to my elastic firewall, the > component(s) that make it elastic are what you address Š the elastic > control of my elastic firewall picks the instance based on it's own local > policy or higher level orchestration/policy control at an > out-of-scope-above-the-line-for-sfc layer. > > Yes, I can layer this abstraction to scale to a very, very large number of > instances and still present a single addressable point of distribution. > > The very scale problem you mention is what the scheme addresses, yet we > seem to be wanting to peel that away. > > As Jim stated, IF you want to separately address each instance (with > either the explosion of paths or the huge feedback loop from orchestration > and control, central micro-flow control, volume of changes to your > classifiers, etc.) - go for it. The architecture allows it. Has to. > Some people might deploy that way. > > The very basic point made in the original argument is "you don't have to > do that". > > This is readily demonstrable (I or a number of other vendors can send a > sales guy to do a demo). > > What I won't agree to here is that elasticity somehow creates an > unknowable path element. It shouldn't unless you did it wrong. Maybe > there's a better example that might justify substituting the chain for the > path (and then dynamically resolving this in the background adding huge > scale considerations) Šbut it's not elasticity. > > On 7/9/14 6:00 PM, "Ron Parker" wrote: > >> Jim, >> >> Respectfully, I'm not comfortable with that. While it is easy to say >> that this is a layered problem and that load balancing belongs at a lower >> level, it seems to me that load balancing of the service functions (not >> load balancer as a service function) should be an explicit consideration >> of the SFC architecture. I say this not only from a scale perspective, >> but also with resiliency in mind. >> >> Ron >> >> >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Wednesday, July 09, 2014 5:48 PM >> To: Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >> NAPIERALA, MARIA H >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> I would say that's implementation. >> >> Sent from my iPhone >> >>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> wrote: >>> >>> Agreed. But is that in scope for SFC or out of scope for SFC? >>> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 5:29 PM >>> To: Ron Parker >>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Well of course not; in that case you load balance up a level between >>> those nodes and then locally. >>> >>> Sent from my iPhone >>> >>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>>> wrote: >>>> >>>> Jim, >>>> >>>> There may not be a single node through which all of the instances can >>>> be reached (at some reasonable limit of L2 or L3 hops). >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>> (jguichar) >>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>> To: NAPIERALA, MARIA H >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> At the node through which the 20 instances are reachable. IOW you >>>> don't have to individually address packets to each and every instance. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>> >>>>> Hi Jim, >>>>> >>>>> When you say "locally", where is it? >>>>> >>>>> Maria >>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> Hi Maria, >>>>>> >>>>>> Absolutely and categorically no! If you have 20 instances at each >>>>>> hop then you can choose to load balance among them locally >>>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>>> some very odd and certainly not recommended reason you want to >>>>>> treat each instance separately then the architecture does not >>>>>> prevent it. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>>> wrote: >>>>>> >>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>> separately, then the service chaining infrastructure would treat >>>>>>>> them as such, and would use distinct service paths. >>>>>>> >>>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>>> then I have >>>>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>>>> have yet to see a solution that work this way and scales.. >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>> instances >>>>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>>>> which of those >>>>>> 20 >>>>>>>> firewalls will be used by a particular flow? >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>> Halpern >>>>>> Direct >>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>> sfc@ietf.org >>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>>> having the global decision that is directing the traffic. That >>>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>> >>>>>>>>>> The definition of the service path is about how service >>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>>> that, and they can give the same external interface. >>>>>>>>>> >>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>>> would be a misleading architectural description and might be >>>>>>>>>> read to outlaw some solutions that fall within the goal the WG >>>>>>>>>> wishes to meet. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>>> be >>>>>>>> determined >>>>>>>>>> in >>>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>>>> based >>>>>>>> on >>>>>>>>>> the >>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>> service function identifiers). This is more compliant with the >>>>>>>>>>>> LB constraints above: >>>>>>>>>> deciding >>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>> >>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 9 20:30: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 B30A41A0290 for ; Wed, 9 Jul 2014 20:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 0TUIYdGt7jqP for ; Wed, 9 Jul 2014 20:30:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BB61A028E for ; Wed, 9 Jul 2014 20:30:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGY84027; Thu, 10 Jul 2014 03:30:28 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 04:30:27 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 11:30:24 +0800 From: Xuxiaohu To: Joel Halpern Direct , "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WI7utfJ2LekG5x1cj4qbXj5uWy8wAgAGqDpyAADIMMA== Date: Thu, 10 Jul 2014 03:30:24 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08291F17@NKGEML512-MBS.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> In-Reply-To: <53BD9AC8.5080904@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hbQSxGWxWiycxPc4Iy1MrL5rz0g Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 03:30:32 -0000 Fully agree. Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct > Sent: Thursday, July 10, 2014 3:41 AM > To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > The archtiecture allows for this local decision, while still having the g= lobal > decision that is directing the traffic. That is, the global decision dir= ects the > traffic to places in the network. Those places may be singular or cluste= rs. If > they are clusters, those clusters can use any number of algorithms to dis= tribute > the traffic internally, without any effect on service chaining. (And yes= , this can > be done in such a way that return traffic, if delivered globally to the s= ame place, > can then be delivered to the right internal state.) >=20 > The definition of the service path is about how service chaining will dir= ect the > traffic. it is not about how the internal load balancing is doen, as the= re are > MANY ways to do that, and they can give the same external interface. >=20 > We could write the architecture pretending that it always addresses singu= lar > instances, but knowing that reality would allow load balanced clusters at= those > locations. But that would be a misleading architectural description and = might > be read to outlaw some solutions that fall within the goal the WG wishes = to > meet. >=20 > Yours, > Joel >=20 > On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >> [Med] I still disagree that an ordered list of locators can be > >> determined in advance for all deployments. I suggest that SFC > >> forwarding be based on the service chain itself (characterized as an > >> order list of service function identifiers). This is more compliant > >> with the LB constraints above: deciding which locator to use for a > >> given flow will be a local decision not a centralized one. > > > > Absolutely. I cannot imagine how else it can be done. > > > > Maria > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 20: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 4C6A31A028E for ; Wed, 9 Jul 2014 20:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 LIlSsGea2vuP for ; Wed, 9 Jul 2014 20:34:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8211A02B9 for ; Wed, 9 Jul 2014 20:34:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU69900; Thu, 10 Jul 2014 03:34:33 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 04:34:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 11:34:26 +0800 From: Qin Wu To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uWy8wAgAHc57A= Date: Thu, 10 Jul 2014 03:34:25 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/M35tPiI3VNIe66SrruXqwurHekI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 03:34:38 -0000 SSBhZ3JlZSB3aXRoIG1lZCB0aGF0IFNlcnZpY2UgZnVuY3Rpb24gcGF0aCBkb2VzbuKAmXQgbmVl ZCB0byBiZSBwcmUtZGV0ZXJtaW5lZC4NCldoZW4gbXVsdGlwbGUgaW5zdGFuY2VzIGZvciB0aGUg c2FtZSBzZXJ2aWNlIGZ1bmN0aW9uIGluIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIGFs bG93ZWQgYW5kIGRpZmZlcmVudCBpbnN0YW5jZSBjaG9vc2UgZGlmZmVyZW50IGxvY2F0b3IgZm9y IHRoZSBzYW1lIHNlcnZpY2UgZnVuY3Rpb24sIHRoZW4gb25lIHNlcnZpY2UgY2hhaW4gbWF5IGJl IGNvcnJlc3BvbmRpbmcgdG8gbXVsdGlwbGUgc2VydmljZSBmdW5jdGlvbiBwYXRocy4gQnV0IG9u bHkgb25lIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpcyBtYXBwZWQgdG8gc2VydmljZSBmdW5jdGlv biBjaGFpbiBhdCBvbmUgdGltZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ih qCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyI OeaXpSAxNTowNQ0K5pS25Lu25Lq6OiBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0K5Li7 6aKYOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cg0KSGkgSm9lbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+LS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9lbCBNLiBIYWxwZXJuIA0KPkVudm95w6nCoDogbWVy Y3JlZGkgOSBqdWlsbGV0IDIwMTQgMDQ6NDAgw4DCoDogc2ZjQGlldGYub3JnIE9iamV0wqA6IFtz ZmNdIA0KPlNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+DQo+SSBo YXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGEgbnVt YmVyIG9mIA0KPmNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlIHByb3Bvc2Vk IG1lcmdlZCBhcmNodGllY3R1cmUgDQo+ZHJhZnQuICBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdvcmtp bmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIA0KPndpbGwgd29yayB0byBpbXBy b3ZlIHRoZSB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgDQo+cGFydGljaXBh dGVkIGluIHRoZSBXRyBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdv cmtpbmcgDQo+Z3JvdXAgaW50ZW5kcy4NCj4NCj5CdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/ICBJIHdp bGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZSANCj5pZiB0aGF0IGhl bHBzLg0KPg0KPkluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5k IHRoYXQgd2hhdCB3ZSBhcmUgDQo+ZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0 dXJlLiAgV2UgYXJlIG5vdCBhdHRlbXB0aW5nIHRvIA0KPmRlZmluZSB0aGUgYXJjaGl0ZWN0dXJl IGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLg0KPlRoYXQgd291 bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9u cywgDQo+dmlydHVhbCBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhl ciBhc3BlY3RzLg0KDQpbTWVkXSBPU1MvQlNTIGNvbnNpZGVyYXRpb25zIGFyZSBvdXQgb2Ygc2Nv cGUgZm9yIHN1cmUsIGJ1dCB0aGUgZnVuY3Rpb25hbCBlbnRpdHkoaWVzKSByZXNwb25zaWJsZSBm b3IgdGhlIHN0cnVjdHVyaW5nIG9mIGNoYWlucyBzaG91bGQgYmUgaW4gc2NvcGUgSU1PLiBUaGUg dGl0bGUgYW5kIHRoZSBhYnN0cmFjdCBvZiB0aGUgbWVyZ2VkIGRyYWZ0IGRvIG5vdCBleGNsdWRl IHRob3NlOg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgZm9y IHRoZSBzcGVjaWZpY2F0aW9uLA0KICAgY3JlYXRpb24sIGFuZCBvbmdvaW5nIG1haW50ZW5hbmNl IG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zIChTRkMpIGluDQogICBhIG5ldHdvcmsuICBJdCBp bmNsdWRlcyBhcmNoaXRlY3R1cmFsIGNvbmNlcHRzLCBwcmluY2lwbGVzLCBhbmQNCiAgIGNvbXBv bmVudHMgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uIG9mIGNvbXBvc2l0ZSBzZXJ2aWNlcyB0aHJv dWdoDQogICBkZXBsb3ltZW50IG9mIFNGQ3MuDQoNCj4NCj5BcyBhIHJlc3VsdCB0aGVyZSBhcmUg bWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZSANCj5sYXJnZXIg c3lzdGVtLA0KDQpbTWVkXSBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGUg bGFyZ2Ugc3lzdGVtLiANCg0KIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3aGVyZSB3 ZSBhcmUgZnVuY3Rpb25pbmcsDQo+YW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhl IHdvcmsgd2UgYXJlIGRvaW5nLg0KPg0KPkluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWlu IHZzIHNlcnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0YW5kIHRoZW0sIA0KPkkgbmVlZCB0byBmaXJz dCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiAgVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIA0KPmRp ZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdp dGggc2VydmljZSANCj5jaGFpbmluZy4gIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiAgVGhlIHBv aW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgDQo+dG8gcGVybWl0IGFsbCBvZiB0aGVzZSwgYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSANCj51c2VkIGluIGFu eSBzb2x1dGlvbi4NCg0KW01lZF0gQWdyZWUuIEhvdyBsb2FkIGJhbGFuY2luZyBpcyBtYW5hZ2Vk IHdpdGhpbiBhIFNGQy1lbmFibGVkIGRvbWFpbiBpcyB1cCB0byB0aGUgcmVzcG9uc2liaWxpdHkg b2YgdGhlIGFkbWluaXN0cmF0aXZlIGVudGl0eSBtYW5hZ2luZyB0aGF0IGRvbWFpbi4gT25lIG9y IGEgbWl4IG9mIHRoZXNlIGZsYXZvcnMgY2FuIGNvLWV4aXN0LiANCg0KPg0KPjEpIExvYWQgYmFs YW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuICBUaGlzIGlzIGEg DQo+c2VydmljZSBmdW5jdGlvbi4gIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kIG1vZGlm aWVzIHRoZW0gKG9yIA0KPm1hcmtzIHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVu ZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gDQo+cmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiAg VGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBiZSANCj5hYmxlIHRvIGlu Y2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gIEl0J3MgYmVoYXZpb3IgbWF5IGFmZmVjdCANCj5y ZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4gIEJ1dCBpdCBoYXMg dmVyeSBsaXR0bGUgDQo+aW1wYWN0IG9uIHRoZSBhcmNodGllY3R1cmUuICBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIA0KPnNpbXBseSBhIHNlcnZpY2UgZnVuY3Rpb24g d2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQo+DQo+MikgVGhlcmUgaXMg aW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuICBUaGF0IGlzLCBvbmUgY2FuIGhhdmUgd2hhdCANCj5h cHBlYXJzIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBw b2ludCBvZiANCj5jb250YWN0IGZvciBhIHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBp cyBhY3R1YWxseSBkZWxpdmVyZWQgYnkgYSANCj5jb2xsZWN0aW9uIG9mIHZpcnR1YWwgb3IgcGh5 c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3IgDQo+c2V2ZXJhbCBsb2Fk IGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlIHRlY2huaXF1ZXMgdG8gc2hh cmUgDQo+YSBNQUMNCj5hZGRyZXNzLikgIG1vc3RseSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhl IHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZSANCj5tZWNoYW5pc21zLiAgSXQgaXMgbGlrZWx5 IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wgDQo+bWVjaGFuaXNtcywgc3Vj aCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtIA0K Pmluc3RhbnRpYXRpb24uICBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0 aGlzIGlzIGxhcmdlbHkgDQo+dGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVy bWlub2xvZ3kgZG9lcyBub3QgbGVhZCByZWFkZXJzIA0KPnRvIHRoaW5rIHdlIGFyZSBwcm9oaWJp dGluZyBpdC4NCj4NCj4zKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5 IHNlbGVjdGluZyBwYWNrZXQgcGF0aHMgZm9yIA0KPnRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQg ZGlyZWN0IHRyYWZmaWMgdG8gZGlmZmVyZW50IHBsYWNlcy4gIFdlIHdvdWxkIA0KPm5vdCB3YW50 IHRvIHJlcXVpcmUgdGhhdCBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkg b25lIA0KPnBsYWNlIGluIHRoZSBuZXR3b3JrLg0KPg0KPkl0IGlzIG9mIGNvdXJzZSB0aGUgY2Fz ZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gIEkgdGVuZCB0byByZWZlciANCj50byB0aGUg Y29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlIGNoYWluaW5nIGFz IGEgDQo+c2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMg YSBnb29kIHRlcm0uICBCdXQgDQo+YmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiAg VGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIA0KPmJhbGFuY2luZyBpcyB0byBkaXJlY3Qg ZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgDQo+c2luZ3VsYXIgb3Ig Y2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5l dHdvcmsuDQo+DQo+Tm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFs ayBhYm91dCBzZXJ2aWNlIGNoYWluIGFuZCANCj5zZXJ2aWNlIHBhdGgvICBTZXJ2aWNlIGNoYWlu IGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgDQo+YXBwbGllZCB0byBh IHN1YnNldCBvZiBwYWNrZXRzLiAgSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21l IA0KPnN1YnNldCBvZiB0cmFmZmljIGlzIHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGlu c3BlY3Rpb24sIGFuZCANCj5maXJld2FsbCB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8g Z28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlIA0KPndpdGhvdXQgdmlzaXRpbmcgYW55IG90aGVyIHNl cnZpY2UgZnVuY3Rpb25zLg0KPg0KPlRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBk aXJlY3QgdGhlIHBhY2tldHMuIA0KDQpbTWVkXSBBIHNlcnZpY2UgY2hhaW4gY2FuIGFsc28gYmUg ZGVmaW5lZCBhcyBhbiBvcmRlciBsaXN0IG9mIHNlcnZpY2UgZnVuY3Rpb24gaWRlbnRpZmllcnMu IEkgdW5kZXJzdGFuZCB0aGUgZXhhbXBsZXMgeW91IHByb3ZpZGUgYXMgbGliZXJhbCBkZXNjcmlw dGlvbiBvZiBzZXJ2aWNlIGNoYWlucyAodGhhdCBJIHRob3VnaHQgeW91IGNvbnNpZGVyZWQgaXQg b3V0IG9mIHNjb3BlKS4gQSBzZXJ2aWNlIGZ1bmN0aW9uIGlkZW50aWZpZXIgZG9lcyBub3QgbmVj ZXNzYXJpbHkgaGludCB0aGUgc2VydmljZSBvZmZlcmVkIGJ5IHRoYXQgU0Y7IGl0cyBwdXJwb3Nl IGlzIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGEgU0YgYW1vbmcgdGhvc2UgcHJlc2VudCBpbiBhIFNG Qy1lbmFibGVkIGRvbWFpbi4NCg0KIEEgc2VydmljZSBwYXRoDQo+aXMsIGluIHNvbWUgZmFzaGlv biwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuDQoNCltNZWRdIHNvLCB0 aGlzIGlzIGFuIG9yZGVyIGxpc3Qgb2Ygc2VydmljZSBmdW5jdGlvbiBsb2NhdG9ycy4gDQoNCiAg VGhvc2UNCj5sb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvciBjbHVzdGVyZWQgc2VydmljZSBm dW5jdGlvbiBkZWxpdmVyeSANCj5sb2NhdGlvbnMuICBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkg SVAgYWRkcmVzcy4gIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCANCj5hcyBwb3J0cyBvbiBhbiBTRkYu ICBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMgDQo+bWF5 IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUg dHJhbnNwb3J0Lg0KPg0KPiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8gYmUgDQo+YWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdo IGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggDQo+ZHJpdmVzIHRo ZSBmb3J3YXJkaW5nLiAgQW5kIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGEg cGF0aCANCj5wYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay4NCj4NCj5TZXZlcmFsIG9m IHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUgcGF0aCBtYXkgbm90IGJlIGtu b3duIA0KPmF0IHRoZSBmcm9udC4iDQoNCltNZWRdIFdoaWNoIGlzIHRydWUuIFRoZSBlbnRpdHkg cmVzcG9uc2libGUgZm9yIHN0cnVjdHVyZSB0aGUgc2VydmljZSBjaGFpbiBjYW5ub3QgZGVjaWRl IGluIGFkdmFuY2UgdGhlIGFjdHVhbCBwYWNrZXQgb2YgcGFja2V0cyBiZWNhdXNlIG9mIHZhcmlv dXMgY29uc2lkZXJhdGlvbnMgc3VjaCBTRi1zcGVjaWZpYyBMQnMsIGJ1dCBhbHNvIGZvciBvdGhl ciB0cmFmZmljIGVuZ2luZWVyaW5nIHB1cnBvc2VzIHN1Y2ggYXMgZGlzcGF0Y2hpbmcgdGhlIHRy YWZmaWMgYW1vbmcgdHdvIHNlcnZpY2UgUG9QcyBob3N0aW5nIHRoZSBzYW1lIHNldCBvZiBTRnMs IGV0Yy4NCg0KICBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRoYXQgaXNzdWUgaW4gdHdv IHdheXMuDQo+Rmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFi b3ZlLCB0aGVyZSBjYW4gYmUgDQo+ZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGlu dmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyANCj5tZWNoYW5pc21zIChpbiBtdWNoIHRo ZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5IA0KPmludmlz aWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pDQoNCltNZWRdIFdoaWNoIG1lYW5zIHRoYXQg eW91IGNhbm5vdCBkZXRlcm1pbmUgYSBsaXN0IG9mIGxvY2F0b3IgYSBwcmlvcmkgZ2l2ZW4gdGhh dCB0aGUgZGVjaXNpb24gb24gd2hpY2ggU0YgaW5zdGFuY2Ugd2lsbCBiZSBpbnZva2VkIGlzIHRo ZSByZXNwb25zaWJpbGl0eSBvZiB0aGF0IExCLg0KDQoNCiAgVGhlIG90aGVyIHByb3Zpc2lvbiB3 ZSBtYWtlIGlzIHRoYXQNCj5yZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFp biB3aGVuIG5lY2Vzc2FyeS4NCg0KW01lZF0gUmUtY2xhc3NpZmljYXRpb24gaXMgb3B0aW9uYWwg YW5kIGlzIGRlcGxveW1lbnQtc3BlY2lmaWMuIE1hbmRhdGluZyByZS1jbGFzc2lmaWNhdGlvbiB0 byBqdXN0aWZ5IGEgZGVzaWduIGNob2ljZSBpcyBvZGQuIA0KDQogIFRoYXQgd2lsbA0KPmRpcmVj dCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiAgQmFzZWQgb24gaW5mb3JtYXRpb24gYXZhaWxhYmxl IGF0IHRoZSANCj5yZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCg0KW01lZF0gVGhhdCdzIG5vdCBv cHRpbWFsIGZvciBzb21lIGRlcGxveW1lbnRzIHRoYXQgZG8gbm90IHJlcXVpcmUgdG8gZW1iZWQg YSBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBpbiB0aGVzZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gDQoN Cj4NCj5JIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIA0K DQpbTWVkXSBJIHN0aWxsIGRpc2FncmVlIHRoYXQgYW4gb3JkZXJlZCBsaXN0IG9mIGxvY2F0b3Jz IGNhbiBiZSBkZXRlcm1pbmVkIGluIGFkdmFuY2UgZm9yIGFsbCBkZXBsb3ltZW50cy4gSSBzdWdn ZXN0IHRoYXQgU0ZDIGZvcndhcmRpbmcgYmUgYmFzZWQgb24gdGhlIHNlcnZpY2UgY2hhaW4gaXRz ZWxmIChjaGFyYWN0ZXJpemVkIGFzIGFuIG9yZGVyIGxpc3Qgb2Ygc2VydmljZSBmdW5jdGlvbiBp ZGVudGlmaWVycykuIFRoaXMgaXMgbW9yZSBjb21wbGlhbnQgd2l0aCB0aGUgTEIgY29uc3RyYWlu dHMgYWJvdmU6IGRlY2lkaW5nIHdoaWNoIGxvY2F0b3IgdG8gdXNlIGZvciBhIGdpdmVuIGZsb3cg d2lsbCBiZSBhIGxvY2FsIGRlY2lzaW9uIG5vdCBhIGNlbnRyYWxpemVkIG9uZS4NCg0KDQogSWYg aXQgZG9lcywgYW5kIGlmDQo+dGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5n IGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IA0KPmFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZCB0byBjb252ZXkgdGhpcy4NCj5JZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRo IHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgDQo+YWRqdXN0IHRvIG1hdGNoIHRo ZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuDQo+SWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJ IGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5leHQuDQo+DQo+WW91cnMsDQo+Sm9lbA0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxp bmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Jul 9 22:13: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 E74F11A0326 for ; Wed, 9 Jul 2014 22:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 ZtbMyU2MfRp9 for ; Wed, 9 Jul 2014 22:13:08 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8131A031D for ; Wed, 9 Jul 2014 22:13:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="121187926" X-IPAS-Result: AhwHADD7RVPAqArr/2dsb2JhbAAXKBAKgkJ/V8QTgTd0giUBAQEBAw4MAUoUDAQCAQgRAQMBAQsWAQYHMhQDBggCBAENBQiIATaKIcE5F44KBgUGAR8fCAoGAQYDgxuBFASUcYUiiT+BeIkGgWoIOQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 10 Jul 2014 05:13:06 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 22:13:05 -0700 From: Ian Smith To: "Zarny, Myo" , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" , 'Med Boucadair' Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgABl8oCAABa+gIAAOkGA//+RfCGAABIEsIAABZCrgAAvCkCAAFSsMw== Date: Thu, 10 Jul 2014 05:13:05 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83B820@SEAEMBX02.olympus.F5Net.com> References: <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83B820SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VVIwIsonUcLm05OXr86oyZT6TbQ Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 05:13:13 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83B820SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The answer lies in the fact that there are a finite number of pool members = behind the load balancer and that, at least at the initial state, they each= have an equal probability of being selected. As that decision time moves = closer, the probabilities are changing, and maybe the implementation can ad= just in real time, or maybe it just waits until it is at the limit (the hop= where it is forced to decide) to let all of those probabilities come crash= ing in at the instant it makes the decision. >From the outside looking in, I don't think the two methods look different: = you match a flow to a chain, and then you select a path within that chain,= it includes a load balancer with four pool members, and at the moment the = first packet enters the chain, the probability that it will use the load ba= lancer is 100% but the probability it will go to each of those four pool me= mbers is the same - but unknown, so all four are included in the path at th= e same sequence point. Example: path {sfi0, sfi2, sfi3, {sfi4, sfi5, sfi6, sfi7}, sfi8, sfi9} Translation: the Service Function Path is an ordered list of Service Funct= ion Instances, but occupying position 4 in the sequence are four possible S= FI's that the SFI in position 3 in the sequence is going to select one and = only one to occupy position 4 in real time using the proscribed method. Th= e method only matters when SFI3 is actually making the decision. Example: path {sfi0, sfi2, sfi3, {opaque}, sfi8, sfi9} Translation: here the pool members behind the load balancer aren't include= d in the path (for whatever reason), but the path still shows that there is= a segment there. The load balancing decision gets made at sfi3, something= happens, and then the flow moves to sfi8. If you were to make a lookup using my toy cli tool, before that decision th= at resolves the uncertainty is made, you might see something like this: show service-chain client 2001:db8:0::abc:123:def:456 all service-chain 100 path da29c34de0af:0109:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION url-filter 2001:db8:0:20::80.45.80 opaque web-cache 2001:db8:0:21::80.224.80 carp {http://gothamist.com/2014= /07/09/cooler_weather_arrives_on_the_anniv.php} web-optimizer uncertain 2001:db8:0:22::80:[137..140].80= fastest firewall 2001:db8:0:23::80.132 current-conns 3245 {3992,4503,3= 389} It shows that the Service Function Instance for the Service Function "web-o= ptimizer" hasn't been selected. It also shows that there are four consecut= ively numbered possibilities, and tells you that response time will be used= to make the decision. One "magic-thread" scenario might look something like this: Instead of pic= king a path through a chain, I'm assigned a path id da29c34de0af:0109:6e01e= 1f421d3, some sort of multicast or anycast or ecmp scheme gets used and for= each position in the sequence, I show up a random Service Function Instanc= e. The SFI reads my header, identifies me as user 6e01e1f421d3 and notes t= hat the policy that should be applied is chain 0109 in domain da29c34de0af = and it verifies that it knows what that policy is. It does whatever it is = supposed to do, and forwards me to the next hop as indicated in the policy.= Then it reports that da29c34de0af:0109:6e01e1f421d3 paid it a visit and w= as successfully sent along the chain. It knows the policy because every policy in the Service Function Domain is = known by every Service Function Instance it applies to. Some mechanism bey= ond the scope of the WG is responsible to make sure that happens. In the r= eal world today, that is done with Diameter or NETCONF or an orchestration = framework. Certainly, there are thought experiments that will poke holes in any of the= se ideas: What if you provision a new pool member after the path selection has been m= ade, but before the decision has been made, and you are supposed to pick th= e least busy pool member? (make the right choice and report why you did so the path can be updated,= just like you would if there were four pool members) What if one of the pool members disappears in the same interval? (same thing) What if a SFI doesn't know the policy for the path-id? (perform your default action) There are lots of "what-if's?" that tend to be well managed by reasonable d= efault actions. The architecture needs to be able to handle the middle 80%= of use cases and give reasonable guidance about what to do at the extremes= in that liminal state between normal and catastrophe so that implementers = can wrestle with them. ________________________________ From: Zarny, Myo [Myo.Zarny@gs.com] Sent: Wednesday, July 09, 2014 7:20 PM To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Bou= cadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Thanks so much for the detailed explanation, Ian. Please see below. =85=94predetermination is that it is possible in the initial state, but not= important=94=85 =93Where I perceive confusion on the list is when the Service Function Chai= n is in some sense "To Be Determined" because one or more of the Service Fu= nctions have discretionary rules that leave the next hop in the chain indet= erminate until a packet presents itself to the Service Function Instance (m= ostly because of middle-boxes), but the Service Function itself MUST be dec= lared before we can select (by any means) a Service Function Instance. And= once in the midst of evaluating the conditional requirement, we have a fin= ite set of "next Service Functions". I can define a completely determinist= ic conditional statement, and we should permit such things and leave them t= o the implementers to restrict if they want, but my gut says that most of t= he conditional rules will be of the sort where all the possible outcomes MA= Y be foreseen before evaluation (eg. if this, then that, else that2) in whi= ch case the SPI is not indeterminate (that is, entirely unknown until evalu= ation), merely uncertain (that is, which of these possible outcomes is more= likely), which is significantly easier to deal with. That is the example = from my first email in this thread.=94 I see that in some cases, some omniscient system could foresee the backend = server (next-hop) a given app flow should go to, in the initial state. Say,= if the load balancing algorithm is =93round-robin=94 on the load balancer.= But not everything can be foreseen. How would it work for those load balan= cing algorithms that use real-time metrics like =93least number of connecti= ons=94, =93least amount of response time=94, =93least bandwidth=94? The omn= iscient system will have to predict what the load balancer will be seeing b= y the time the first packets show up at the load balancer, and put the pred= icted server in the SFP? So while I agree that predetermination is possible is some cases, I=92d arg= ue that it=92s not possible in all cases. The issue is how to deal with tho= se =93to be determined=94 cases. I=92m still digesting your =93magic thread= =94 explanation. Regards, From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith Sent: 9 July 2014 5:36 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Mostly. I've been defining things like this: =B7 Service Function Domain as the logical area in which Service Fu= nction Chains are defined. There are various names for them but basically = all the architectures define an "ingress" and an "egress" node that anchors= a chain at each end - this is the space between them. =B7 Service Function Chain as "an ordered sequence of a finite numb= er of functions" =B7 Service Function Path as "an ordered sequence of particular ins= tances of service functions within a Service Function Chain". =B7 Service Function as an abstract thing - "URL Filter" =B7 Service Function Node as the physical piece of hardware that ho= uses the Service Function - "this server" =B7 Service Function Instance as a particular instance of a service= function - "this URL Filter on this Service Function Node" - and it can be= a virtual machine, a container, or just an instance of software on the SFN= . This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there. I may have incorrectly believed this to be a case o= f settled meaning. Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture. It does exist, and by definition it exists becaus= e packets are moving along it. In the most rudimentary case, you are passi= ng from node to node to some destination far away using only their default = gateway; the SFI is the agglomeration of their default gateways. This easi= ly evolves to IP Source Routes, MPLS lable stacks, and other in-packet mech= anisms, but it just as easily evolves to an orchestration system inserting = policy routes into nodes in a "just in time" fashion or tying the client IP= to a pre-existing policy that includes the next hop. The latter case is w= hat my previous example showed. You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service= Function Path (and if you don't have that path defined, recurse through th= e id to find the Service Function Chain to make whatever evaluation is requ= ired by you to send me on my way.)" or a orchestration system. I confess t= o geekishly liking the idea of using the IPX+ address schema for this. Example: 6 byte SFD:4 byte SFC:6 byte SFP aabbccddeeff:0123:6e01e1f421d3 (I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using ex= isting mechanisms.) You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. Thi= s is perhaps too plainly stated, but it is easy and seems to be the path we= are chartered to take. So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met. I think that is not what people are asking for= . What I think people are asking for is a method for channelizing services= on packet switched networks, which I understand to mean that I should disa= ggregate flows at the boundary of a SFD, and force them into channels accor= ding to some external policy, keep them in their channel all the way throug= h the domain, and then reaggregate them on the other side. And to give the= people what they want, I think you do have to say something like, "the pat= h may vary but only amongst the SFIs that are defined by the SFC and once a= n SFI is selected for use by a flow, it stays selected until dismissed or i= t fails" which to me implies that you MUST select the chain, and you MAY s= elect as many instances within that chain that the policy allows, but you M= UST respect conditional elements of the chain and to do that you have to, i= n essence, select all the possible instances implied by the chain. (I don'= t know if calling it a Markov chain problem helps, but it is an apt descrip= tion in my mind.) That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important. Once you= evaluate the conditional requirements however, then the path is set and it= SHOULD remain fixed until an input to the conditional requirements changes= . I would expect that change to come from four principal areas: Failure, = packet inspection, content switching, or policy update. There could be mor= e, but those seem to be the main archetypes. Of those two, packet inspecti= on results and content switching are clearly the kind of conditional requir= ement that belong in a SFC definition, while there is a strong case that no= de or network failures and policy updates will be orthogonal inputs the the= whole system, not something that can be clearly identified and dealt with = on the data plane. Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Service Funct= ions have discretionary rules that leave the next hop in the chain indeterm= inate until a packet presents itself to the Service Function Instance (most= ly because of middle-boxes), but the Service Function itself MUST be declar= ed before we can select (by any means) a Service Function Instance. And on= ce in the midst of evaluating the conditional requirement, we have a finite= set of "next Service Functions". I can define a completely deterministic = conditional statement, and we should permit such things and leave them to t= he implementers to restrict if they want, but my gut says that most of the = conditional rules will be of the sort where all the possible outcomes MAY b= e foreseen before evaluation (eg. if this, then that, else that2) in which = case the SPI is not indeterminate (that is, entirely unknown until evaluati= on), merely uncertain (that is, which of these possible outcomes is more li= kely), which is significantly easier to deal with. That is the example fro= m my first email in this thread. How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread". If= we don't what to get into that at all, then it is sufficient to say that a= SFC definition MUST include a way to identify all potential SFI's for incl= uded SF's, and that implementations SHOULD resolve as many of the possible = SFI's implied by a SFC before making an assignment and that if there are co= nditional rules in the SFC, then implementations MUST resolv all of the pos= sible SFI's and, by use of the magic thread, tell them all that they should= be prepared to participate in SFI-x for client-A. I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. Example: show service-chain client 2001:db8:0::abc:123:def:456 all service-chain 100 path da29c34de0af:0123:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION url-filter 2001:db8:0:20::80.45.80 opaque web-cache 2001:db8:0:21::80.224.80 carp {http://gothamist.com/2014= /07/09/cooler_weather_arrives_on_the_anniv.php} web-optimizer 2001:db8:0:22::80.137.80 conditional match firewall 2001:db8:0:23::80.132 current-conns 3245 {3992,4503,3= 389} service-chain 109 path da29c34de0af:0134:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION dns-filter 2001:db8:0:100::53:98.53 passed dns-cache 2001:db8:0:100::53:129.53 miss dns-switch 2001:db8:0:100::53:223.53 off-net, icann tld dns-server 2001:db8:0:99::53:23.53 SOA 2001:db8:fa99:e8b4:123:abcd= :4567:ef01.53 Translation: The client at 2001:db8:0::abc:123:def:456 currently has Servi= ce Function Paths active in two Service Function Chains - 100 and 109 - wi= th the particular Service Function Instances listed in correspondence to th= e Service Function and any information reported by the SFI pertaining to th= e state of the SFP. You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. ________________________________ From: Zarny, Myo [Myo.Zarny@gs.com] Sent: Wednesday, July 09, 2014 3:46 PM To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Bou= cadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hi Ian, Thanks for the write-up. Just to confirm I get this right: You=92re saying the SFC is a collection o= f abstracted desired service functions (your point 1) while the actual path= a given application flow traverses is determined by the service functions = themselves? E.g., your examples in points (2, 3, 4 and 5)? In your examples, the actual flows (say, TCP connections between the same p= air of endpoints) can traverse different SF paths=97nothing wrong with that= =97even if they follow the same exact SF chain. This mean the SFP isn=92t p= redetermined (since it=92s the actual entities that decide the next service= function). Do I get that right? Myo PS: Btw, no one has tackled my reverse path question. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: 9 July 2014 2:54 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } Translation: send to instances of these 4 services in this order. 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example: service-function url-filter { dns _http._tcp.url-filter.example.com fallback bypass } Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function. 3. You may define a service function conditionally. Example: service-function web-optimizer { if { [class match [HTTP::url] eq optimizable-content] } { ip 2001:db8:0:22::137.80 } else { service-function firewall } } Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall. 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example: service-function web-cache { lb carp [HTTP::url] @2001:db8:0:21::224.80 } Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic. 5. You may load balance directly in the path selection process. Example: service-function firewall { pool { least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections} ip 2001:db8:23::130 ip 2001:db8:23::131 ip 2001:db8:23::132 ip 2001:db8:23::133 } } Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections. 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example: service-function url-filter { opaque dns _http._tcp.url-filter.example.com } Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain. --_000_419417C345CA5F48BF45F0A23955A0634A83B820SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The answer lies in the fact that there are a finite number of pool m= embers behind the load balancer and that, at least at the initial state, th= ey each have an equal probability of being selected.  As that decision time moves closer, the probabili= ties are changing, and maybe the implementation can adjust in real time, or= maybe it just waits until it is at the limit (the hop where it is forced t= o decide) to let all of those probabilities come crashing in at the instant it makes the decision.   

>From the outside looking in, I don't think the two methods look different:&= nbsp; you match a flow to a chain, and then you select a path within that c= hain, it includes a load balancer with four pool members, and at the moment= the first packet enters the chain, the probability that it will use the load balancer is 100% but the probability= it will go to each of those four pool members is the same - but unknown, s= o all four are included in the path at the same sequence point. 

Example:

path {sfi0, sfi2, sfi3, {sfi4, sfi5, sfi6, sfi7}= , sfi8, sfi9}

Translation:  the Service Function Path is an ordered list of Service = Function Instances, but occupying position 4 in the sequence are four possi= ble SFI's that the SFI in position 3 in the sequence is going to select one= and only one to occupy position 4 in real time using the proscribed method.  The method only matters when = SFI3 is actually making the decision.

Example:

path {sfi0, sfi2, sfi3, {opaque}, sfi8, sfi9}
Translation:  here the pool members behind the load balancer aren't in= cluded in the path (for whatever reason), but the path still shows that the= re is a segment there.  The load balancing decision gets made at sfi3,= something happens, and then the flow moves to sfi8.

If you were to make a lookup using my toy cli tool, before that deci= sion that resolves the uncertainty is made, you might see something like th= is:

show service-chain client 2001:db8:0::abc:123:def:456 all

service-chain 100 path da29c34de0af:0109:6e01e1f421d3

FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
url-filter      2001:db8:0:20::80.45.80  = ;   opaque
web-cache       2001:db8:0:21::80.224.80 = ;   carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_= on_the_anniv.php}
web-optimizer   uncertain         &= nbsp;         = 2001:db8:0:22::80:[137..140].80  fastest
firewall        2001:db8:0:23::80.132 &n= bsp;     current-conns 3245 {3992,4503,3389}

It shows that the Service Function Instance for the Service Function "= web-optimizer" hasn't been selected.  It also shows that there ar= e four consecutively numbered possibilities, and tells you that response ti= me will be used to make the decision.

One "magic-thread" scenario might look something like this: = Instead of picking a path through a chain, I'm assigned a path id da29c34de0af:0109:6e01e1f421d3, some sort of multicast or anycast or ecmp scheme gets used and for each po= sition in the sequence, I show up a random Service Function Instance. = The SFI reads my header, identifies me as user 6e01e1f421d3 and notes th= at the policy that should be applied is chain 0109 in domain da29c34de0af and it verifies that it knows what that policy is.  It does whatever = it is supposed to do, and forwards me to the next hop as indicated in the p= olicy.  Then it reports that <= /font><= font size=3D"2">= da29c34de0af:0109:6e01e1f421d3 paid it a visit and was successfully sent along the chain.

It knows the policy because every policy in the Service Function Domain is = known by every Service Function Instance it applies to.  Some mechanis= m beyond the scope of the WG is responsible to make sure that happens. = ; In the real world today, that is done with Diameter or NETCONF or an orchestration framework.

Certainly, there are thought experiments that will poke holes in any of the= se ideas:

What if you provision a new pool member after the path selection has been m= ade, but before the decision has been made, and you are supposed to pick th= e least busy pool member?
  (make the right choice and report why you did so the path can be = updated, just like you would if there were four pool members) 

What if one of the pool members disappears in the same interval?
    (same thing) 

What if a SFI doesn't know the policy for the path-id?
    (perform your default action)

There are lots of "what-if's?" that tend to be well managed by re= asonable default actions.  The architecture needs to be able to handle= the middle 80% of use cases and give reasonable guidance about what to do = at the extremes in that liminal state between normal and catastrophe so that implementers can wrestle with them.


From: Zarny, Myo [Myo.Zarny@gs.com]
Sent: Wednesday, July 09, 2014 7:20 PM
To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; '= Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Thanks so much for the = detailed explanation, Ian. Please see below.

 

 

=85=94predetermination is = that it is possible in the initial state, but not important=94=85

 

=93Where I perceive confus= ion on the list is when the Service Function Chain is in some sense "T= o Be Determined" because one or more of the Service Functions have discretionary rules that leave the next hop in the chain indeterminate unt= il a packet presents itself to the Service Function Instance (mostly becaus= e of middle-boxes), but the Service Function itself MUST be declared before= we can select (by any means) a Service Function Instance.  And once in the midst of evaluating the c= onditional requirement, we have a finite set of "next Service Function= s".  I can define a completely deterministic conditional statemen= t, and we should permit such things and leave them to the implementers to restrict if they want, but my gut says that most of th= e conditional rules will be of the sort where all the possible outcomes MAY= be foreseen before evaluation (eg. if this, then that, else that2) in whic= h case the SPI is not indeterminate (that is, entirely unknown until evaluation), merely uncertain (that is, w= hich of these possible outcomes is more likely), which is significantly eas= ier to deal with.  That is the example from my first email in this thr= ead.=94

I see that in some cases, some omniscient system could foresee the backend server = (next-hop) a given app flow should go to, in the initial state. Say, if the= load balancing algorithm is =93round-robin=94 on the load balancer. But no= t everything can be foreseen. How would it work for those load balancing algorithms that use real-time metrics lik= e =93least number of connections=94, =93least amount of response time=94, = =93least bandwidth=94? The omniscient system will have to predict what the = load balancer will be seeing by the time the first packets show up at the load balancer, and put the predicted server i= n the SFP?

 

So while I agree that p= redetermination is possible is some cases, I=92d argue that it=92s not poss= ible in all cases. The issue is how to deal with those =93to be determined=94 cases. I=92m still digesting your =93magic thread=94 explana= tion.

 

Regards,

 

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: 9 July 2014 5:36 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpign= ata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

 

Mostly.

I've been defining things like this:

=B7  = ;       Service Function Domain as t= he logical area in which Service Function Chains are defined.  There a= re various names for them but basically all the architectures define an "ingress" and an "egress" node that anchors = a chain at each end - this is the space between them.

=B7  = ;       Service Function Chain as &q= uot;an ordered sequence of a finite number of functions"

=B7  = ;       Service Function Path as &qu= ot;an ordered sequence of particular instances of service functions within = a Service Function Chain". 

=B7  = ;       Service Function as an abstr= act thing - "URL Filter"

=B7  = ;       Service Function Node as the= physical piece of hardware that houses the Service Function - "this s= erver"

=B7  = ;       Service Function Instance as= a particular instance of a service function - "this URL Filter on thi= s Service Function Node" - and it can be a virtual machine, a container, or just an instance of software on the SFN.


This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there.  I may have incorrectly believed this to be a c= ase of settled meaning.

Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture.  It does exist, and by definition it exists b= ecause packets are moving along it.  In the most rudimentary case, you= are passing from node to node to some destination far away using only their default gateway; the SFI is the agglomeration of= their default gateways.  This easily evolves to IP Source Routes, MPL= S lable stacks, and other in-packet mechanisms, but it just as easily evolv= es to an orchestration system inserting policy routes into nodes in a "just in time" fashion or tying th= e client IP to a pre-existing policy that includes the next hop.  The = latter case is what my previous example showed.

You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service Function Path (and if you d= on't have that path defined, recurse through the id to find the Service Fun= ction Chain to make whatever evaluation is required by you to send me on my= way.)" or a orchestration system.  I confess to geekishly liking the idea of using the IPX+ address schema = for this. 

Example:

6 byte SFD:4 byte SFC:6 byte SFP
aabbccddeeff:0123:6e01e1f421d3 

(I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using existing mechanisms.)

You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. = ; This is perhaps too plainly stated, but it is easy and seems to be the path we are chartered to take.

So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met.  I think that is not what people are askin= g for.  What I think people are asking for is a method for channelizin= g services on packet switched networks, which I understand to mean that I should disaggregate flows at the boundary of a= SFD, and force them into channels according to some external policy, keep = them in their channel all the way through the domain, and then reaggregate = them on the other side.  And to give the people what they want, I think you do have to say something like,= "the path may vary but only amongst the SFIs that are defined by the = SFC and once an SFI is selected for use by a flow, it stays selected until = dismissed or it fails" which  to me implies that you MUST select the chain, and you MAY select as many instances withi= n that chain that the policy allows, but you MUST respect conditional eleme= nts of the chain and to do that you have to, in essence, select all the pos= sible instances implied by the chain.  (I don't know if calling it a Markov chain problem helps, but it is an apt= description in my mind.)

That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important.  Onc= e you evaluate the conditional requirements however, then the path is set a= nd it SHOULD remain fixed until an input to the conditional requirements changes.  I would expect that change = to come from four principal areas:  Failure, packet inspection, conten= t switching, or policy update.  There could be more, but those seem to= be the main archetypes.  Of those two, packet inspection results and content switching are clearly the kind of condition= al requirement that belong in a SFC definition, while there is a strong cas= e that node or network failures and policy updates will be orthogonal input= s the the whole system, not something that can be clearly identified and dealt with on the data plane.

Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Ser= vice Functions have discretionary rules that leave the next hop in the chai= n indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the= Service Function itself MUST be declared before we can select (by any mean= s) a Service Function Instance.  And once in the midst of evaluating t= he conditional requirement, we have a finite set of "next Service Functions".  I can define a com= pletely deterministic conditional statement, and we should permit such thin= gs and leave them to the implementers to restrict if they want, but my gut = says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluat= ion (eg. if this, then that, else that2) in which case the SPI is not indet= erminate (that is, entirely unknown until evaluation), merely uncertain (th= at is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is= the example from my first email in this thread.

How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread&= quot;.  If we don't what to get into that at all, then it is sufficien= t to say that a SFC definition MUST include a way to identify all potential SFI's for included SF's, and that implementation= s SHOULD resolve as many of the possible SFI's implied by a SFC before maki= ng an assignment and that if there are conditional rules in the SFC, then i= mplementations MUST resolv all of the possible SFI's and, by use of the magic thread, tell them all that the= y should be prepared to participate in SFI-x for client-A.

 

I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. 

Example:

show service-chain client 2001:db8:0::abc:123:def:456 all
service-chain 100 path da29c34de0af:0123:6e01e1f421d3

FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
url-filter      2001:db8:0:20::80.45.80  = ;   opaque
web-cache       2001:db8:0:21::80.224.80 = ;   carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_= on_the_anniv.php}
web-optimizer   2001:db8:0:22::80.137.80    condit= ional match
firewall        2001:db8:0:23::80.132 &n= bsp;     current-conns 3245 {3992,4503,3389}  &nbs= p;    

service-chain 109 path da29c34de0af:0134:6e01e1f421d3

FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
dns-filter      2001:db8:0:100::53:98.53  &nb= sp; passed
dns-cache       2001:db8:0:100::53:129.53 &nb= sp; miss
dns-switch      2001:db8:0:100::53:223.53   o= ff-net, icann tld
dns-server      2001:db8:0:99::53:23.53  = ;   SOA 2001:db8:fa99:e8b4:123:abcd:4567:ef01.53

Translation:  The client at 2001:db8:= 0::abc:123:def:456 currently has Service Function Paths active in two Servi= ce Function Chains - 100 and 109  - with the particular Service Function Instances listed in correspondence to the Service Function and an= y information reported by the SFI pertaining to the state of the SFP.

You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. 

From: Zar= ny, Myo [Myo.Zarny@gs.com]
Sent: Wednesday, July 09, 2014 3:46 PM
To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; '= Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Hi Ian,

 

Thanks for the write-up.

 

Just to confirm I get this right: You=92re saying the SFC is a collecti= on of abstracted desired service functions (your point 1) while the actual path a given application flow traverses is determined by the se= rvice functions themselves? E.g., your examples in points (2, 3, 4 and 5)?<= /span>

 

In your examples, the actual flows (say, TCP connections between the sa= me pair of endpoints) can traverse different SF paths=97nothing wrong with that=97even if they follow the same exact SF chain. This mean t= he SFP isn=92t predetermined (since it=92s the actual entities that decide = the next service function).

 

Do I get that right?

 

Myo

 

PS: Btw, no one has tackled my reverse path question.

 

 

mailto= :I.Smith@F5.com]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JFTUURguFad2BLAwa9xuBRNTyMM Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , Ron Parker , "mohamed.boucadair@orange.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 05:32:46 -0000 If I understand correctly, the dilemma is that=20 - on one hand there is no limit to what is meant by "load-balancing": It may be a deep application content changing function, or a simple NAT of V= IPs. - On the other a static architecture is too rigid to scale and make highly a= vailable. It may lead to too much "hair splitting" .=20 To take it to extreme, in a distributed overlay network with SFFs scattered= in enough locations, but not in every host, a single service-function hop can be: SFF - NVE - NVE - SLB - NVE - NVE - NF - NVE - NVE - SFF If implemented literally the latency-jitter and consequently utilization wil= l be quite bad. So a language that allows an SFF to work with balanced VNF pools, and that allows for multi-home SFF to VNF pooling can help.=20 --szb > On Jul 9, 2014, at 19:08, "Joel M. Halpern" wrote: >=20 > THere are multiple ways that the internal redundancy with the load balance= rs can be implemented. Any of them can be used with the service chaining ar= chitecture. > There may be some aspects which need to be covered in the solution work. > For example, I would expect solutions to have to discuss how we cope with S= FF failure. And with failure of the linkage between the SFF and the SF. >=20 > We could add text to the architecture indicating that solutions will need t= o be robust in dealing with failures of service chaining components and link= ages. But I think we should not spell out the detailed mechanisms for that r= obustness in this document. >=20 > Would adding a small section on robustness issues help? >=20 > Yours, > Joel >=20 >> On 7/9/14, 7:28 PM, Ron Parker wrote: >> Ken, >>=20 >> As I pointed out in my previous email, my concern is more about resilienc= y than elasticity. I understand the benefits of layered load balancing, bu= t what about when this is hierarchical? Maria spoke of 20 instances, and t= he prevailing thinking seems to be that the top-level behavior of the SFC sh= ouldn't care. But what if the front-end entity fails? What if its intern= al redundancy, if any, fails to perform when called upon? Might the networ= k designer choose to divide the 20 instances into 2 groupings of 10 and have= a front-end entity for each grouping? So now the top-level behavior of th= e SFC must choose amongst 2 rather than 20 for this particular logical servi= ce function. But a choice still needs to be made. Is this, too, outside t= he scope of SFC? If not, is the architecture going to explicitly address i= t, or leave it as an implementation issue? >>=20 >> Ron >>=20 >>=20 >> ________________________________________ >> From: Ken Gray (kegray) [kegray@cisco.com] >> Sent: Wednesday, July 09, 2014 6:39 PM >> To: Ron Parker; Jim Guichard (jguichar) >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H; s= fc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> The whole idea of dynamic elasticity control is to hide this detail from >> you and to make the instances ephemeral. >>=20 >> When you send a packet from your classifier to my elastic firewall, the >> component(s) that make it elastic are what you address =C5=A0 the elastic= >> control of my elastic firewall picks the instance based on it's own local= >> policy or higher level orchestration/policy control at an >> out-of-scope-above-the-line-for-sfc layer. >>=20 >> Yes, I can layer this abstraction to scale to a very, very large number o= f >> instances and still present a single addressable point of distribution. >>=20 >> The very scale problem you mention is what the scheme addresses, yet we >> seem to be wanting to peel that away. >>=20 >> As Jim stated, IF you want to separately address each instance (with >> either the explosion of paths or the huge feedback loop from orchestratio= n >> and control, central micro-flow control, volume of changes to your >> classifiers, etc.) - go for it. The architecture allows it. Has to. >> Some people might deploy that way. >>=20 >> The very basic point made in the original argument is "you don't have to >> do that". >>=20 >> This is readily demonstrable (I or a number of other vendors can send a >> sales guy to do a demo). >>=20 >> What I won't agree to here is that elasticity somehow creates an >> unknowable path element. It shouldn't unless you did it wrong. Maybe >> there's a better example that might justify substituting the chain for th= e >> path (and then dynamically resolving this in the background adding huge >> scale considerations) =C5=A0but it's not elasticity. >>=20 >>> On 7/9/14 6:00 PM, "Ron Parker" wrote:= >>>=20 >>> Jim, >>>=20 >>> Respectfully, I'm not comfortable with that. While it is easy to say >>> that this is a layered problem and that load balancing belongs at a lowe= r >>> level, it seems to me that load balancing of the service functions (not >>> load balancer as a service function) should be an explicit consideration= >>> of the SFC architecture. I say this not only from a scale perspective= , >>> but also with resiliency in mind. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 5:48 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> I would say that's implementation. >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>>> wrote: >>>>=20 >>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>> To: Ron Parker >>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> Well of course not; in that case you load balance up a level between >>>> those nodes and then locally. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>>>> wrote: >>>>>=20 >>>>> Jim, >>>>>=20 >>>>> There may not be a single node through which all of the instances can >>>>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>> (jguichar) >>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>> To: NAPIERALA, MARIA H >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> At the node through which the 20 instances are reachable. IOW you >>>>> don't have to individually address packets to each and every instance.= >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>>> wrote: >>>>>>=20 >>>>>> Hi Jim, >>>>>>=20 >>>>>> When you say "locally", where is it? >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>> To: NAPIERALA, MARIA H >>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>=20 >>>>>>> Hi Maria, >>>>>>>=20 >>>>>>> Absolutely and categorically no! If you have 20 instances at each >>>>>>> hop then you can choose to load balance among them locally >>>>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>>>> some very odd and certainly not recommended reason you want to >>>>>>> treat each instance separately then the architecture does not >>>>>>> prevent it. >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>>>> wrote: >>>>>>>=20 >>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>> separately, then the service chaining infrastructure would treat >>>>>>>>> them as such, and would use distinct service paths. >>>>>>>>=20 >>>>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>>>> then I have >>>>>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>>>>> have yet to see a solution that work this way and scales.. >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>> instances >>>>>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>>>>> which of those >>>>>>> 20 >>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>=20 >>>>>>>>>> Maria >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>> Halpern >>>>>>> Direct >>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>> sfc@ietf.org >>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>=20 >>>>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>>>> having the global decision that is directing the traffic. That >>>>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>>>=20 >>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>>>> that, and they can give the same external interface. >>>>>>>>>>>=20 >>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>>>> would be a misleading architectural description and might be >>>>>>>>>>> read to outlaw some solutions that fall within the goal the WG >>>>>>>>>>> wishes to meet. >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>>=20 >>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>>>> be >>>>>>>>> determined >>>>>>>>>>> in >>>>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>>>>> based >>>>>>>>> on >>>>>>>>>>> the >>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>> service function identifiers). This is more compliant with the= >>>>>>>>>>>>> LB constraints above: >>>>>>>>>>> deciding >>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>=20 >>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>=20 >>>>>>>>>>>> Maria >>>>>>>>>>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 23:29: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 74AF71A034F for ; Wed, 9 Jul 2014 23:29:01 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wEdUzL6TdIas for ; Wed, 9 Jul 2014 23:28:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9FA1A01E1 for ; Wed, 9 Jul 2014 23:28:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7091026447B; Thu, 10 Jul 2014 08:28:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4BF4A238048; Thu, 10 Jul 2014 08:28:57 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 08:28:57 +0200 From: To: "Joel M. Halpern" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8UxKjmuDn4BEiFVdMuQoKu35uXlPYAgACF5yD//+jEAIAABYCAgAAHGACAAMZiQA== Date: Thu, 10 Jul 2014 06:28:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002FF1F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> In-Reply-To: <53BDA558.1070701@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1FEafla1Sw2BM9BH0y_zJWook40 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 06:29:01 -0000 Joel, I'm afraid you are making some deployment assumptions.=20 How SF are deployed whether in separate physical nodes, as co-located virtu= al instances, separated virtual instances, ...or a mix of those is really d= eployment-specific. The point is that these SF instances are offering the s= ervice, as such they must be considered as bound to the same logical servic= e (identified by a single service function identifier). For a given chain, = when invoking a given SF is required, how the traffic will be directed to o= ne of available SF instances is also deployment-specific. It is up to the t= aste of each operator to decide how to proceed.=20 Furthermore, we should not mandate an operator how to structure its chains.= For example, we should not mandate that it must declare a cluster as a SF. The key information needed to forward traffic is the service chain itself (= that is characterized as an order list of service function identifiers). Th= e forwarding path will be the result of policies configured in a given SFC-= enabled domain. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: mercredi 9 juillet 2014 22:26 >=C0=A0: NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >I am saying that if the 20 virtual firewalls are deployed separately, >then the service chaining infrastructure would treat them as such, and >would use distinct service paths. >Alternative, if you as the operator choose to deploy them as a cluster, >with sutiable load balancing, such that they appear as a single place >for service chaining, then there would be one service path. > >And the operator could choose a hybrid, for exanmple, deploying two >clusters of 10 each, requiring two service paths. > >Typically, different clusters would be used to provide geographic >diversity or because there was a policy reason to distinguish them. >While clusters would typically be used to allow the scale-in and >scale-out to occur without affecting service chaining. > >The architecture is structured to allow this range. > >Yours, >Joel > >On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >> I had in mind singular instances, say, 20 virtual firewall instances >somewhere in the middle of a chain. Are you saying that you will decide >(make a load balancing decision) at the entry to the chain which of those >20 firewalls will be used by a particular flow? >> >> Maria >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direc= t >>> Sent: Wednesday, July 09, 2014 3:41 PM >>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> The archtiecture allows for this local decision, while still having the >>> global decision that is directing the traffic. That is, the global >>> decision directs the traffic to places in the network. Those places ma= y >>> be singular or clusters. If they are clusters, those clusters can use >>> any number of algorithms to distribute the traffic internally, without >>> any effect on service chaining. (And yes, this can be done in such a >>> way that return traffic, if delivered globally to the same place, can >>> then be delivered to the right internal state.) >>> >>> The definition of the service path is about how service chaining will >>> direct the traffic. it is not about how the internal load balancing is >>> doen, as there are MANY ways to do that, and they can give the same >>> external interface. >>> >>> We could write the architecture pretending that it always addresses >>> singular instances, but knowing that reality would allow load balanced >>> clusters at those locations. But that would be a misleading >>> architectural description and might be read to outlaw some solutions >>> that fall within the goal the WG wishes to meet. >>> >>> Yours, >>> Joel >>> >>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>> [Med] I still disagree that an ordered list of locators can be >determined >>> in >>>>> advance for all deployments. I suggest that SFC forwarding be based o= n >>> the >>>>> service chain itself (characterized as an order list of service >function >>>>> identifiers). This is more compliant with the LB constraints above: >>> deciding >>>>> which locator to use for a given flow will be a local decision not a >>>>> centralized one. >>>> >>>> Absolutely. I cannot imagine how else it can be done. >>>> >>>> Maria >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Wed Jul 9 23:33: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 8F3FF1A01E1 for ; Wed, 9 Jul 2014 23:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h0WGqRiNmrKI for ; Wed, 9 Jul 2014 23:33:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4D41A034F for ; Wed, 9 Jul 2014 23:33:21 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1463422C6BC; Thu, 10 Jul 2014 08:33:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DF85A238056; Thu, 10 Jul 2014 08:33:19 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 08:33:19 +0200 From: To: Ian Smith , "Zarny, Myo" , "'Nobo Akiya (nobo)'" , "'Carlos Pignataro (cpignata)'" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WxKjmuDn4BEiFVdMuQoKu35uXpbkAgABl84D//7ubUIAANNtA///6e4CAAA6wgIAAHlqAgAC3S/A= Date: Thu, 10 Jul 2014 06:33:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002FF35@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1BD195C8-CF1E-40CE-B9B2-05C553137BBF@cisco.com> , <419417C345CA5F48BF45F0A23955A0634A83AC69@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83AF92@SEAEMBX02.olympus.F5Net.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933002FF35OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oxQ_IXNHrhAvWrYRIlmeTLlcLjI Cc: "'Joel M. Halpern'" , "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 06:33:27 -0000 --_000_787AE7BB302AE849A7480A190F8B933002FF35OPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ian, I fully agree with the following: "Where the Service Function Path is defined is, in my mind, somewhat irrele= vant to the architecture. It does exist, and by definition it exists becau= se packets are moving along it. " Cheers, Med De : Ian Smith [mailto:I.Smith@F5.com] Envoy=E9 : mercredi 9 juillet 2014 23:36 =C0 : Zarny, Myo; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; BOUCA= DAIR Mohamed IMT/OLN Cc : 'Joel M. Halpern'; 'sfc@ietf.org' Objet : RE: [sfc] Service Chains, Paths, and Load Balancers Mostly. I've been defining things like this: * Service Function Domain as the logical area in which Service Function= Chains are defined. There are various names for them but basically all th= e architectures define an "ingress" and an "egress" node that anchors a cha= in at each end - this is the space between them. * Service Function Chain as "an ordered sequence of a finite number of = functions" * Service Function Path as "an ordered sequence of particular instances= of service functions within a Service Function Chain". * Service Function as an abstract thing - "URL Filter" * Service Function Node as the physical piece of hardware that houses t= he Service Function - "this server" * Service Function Instance as a particular instance of a service funct= ion - "this URL Filter on this Service Function Node" - and it can be a vir= tual machine, a container, or just an instance of software on the SFN. This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there. I may have incorrectly believed this to be a case o= f settled meaning. Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture. It does exist, and by definition it exists becaus= e packets are moving along it. In the most rudimentary case, you are passi= ng from node to node to some destination far away using only their default = gateway; the SFI is the agglomeration of their default gateways. This easi= ly evolves to IP Source Routes, MPLS lable stacks, and other in-packet mech= anisms, but it just as easily evolves to an orchestration system inserting = policy routes into nodes in a "just in time" fashion or tying the client IP= to a pre-existing policy that includes the next hop. The latter case is w= hat my previous example showed. You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service= Function Path (and if you don't have that path defined, recurse through th= e id to find the Service Function Chain to make whatever evaluation is requ= ired by you to send me on my way.)" or a orchestration system. I confess t= o geekishly liking the idea of using the IPX+ address schema for this. Example: 6 byte SFD:4 byte SFC:6 byte SFP aabbccddeeff:0123:6e01e1f421d3 (I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using ex= isting mechanisms.) You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. Thi= s is perhaps too plainly stated, but it is easy and seems to be the path we= are chartered to take. So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met. I think that is not what people are asking for= . What I think people are asking for is a method for channelizing services= on packet switched networks, which I understand to mean that I should disa= ggregate flows at the boundary of a SFD, and force them into channels accor= ding to some external policy, keep them in their channel all the way throug= h the domain, and then reaggregate them on the other side. And to give the= people what they want, I think you do have to say something like, "the pat= h may vary but only amongst the SFIs that are defined by the SFC and once a= n SFI is selected for use by a flow, it stays selected until dismissed or i= t fails" which to me implies that you MUST select the chain, and you MAY s= elect as many instances within that chain that the policy allows, but you M= UST respect conditional elements of the chain and to do that you have to, i= n essence, select all the possible instances implied by the chain. (I don'= t know if calling it a Markov chain problem helps, but it is an apt descrip= tion in my mind.) That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important. Once you= evaluate the conditional requirements however, then the path is set and it= SHOULD remain fixed until an input to the conditional requirements changes= . I would expect that change to come from four principal areas: Failure, = packet inspection, content switching, or policy update. There could be mor= e, but those seem to be the main archetypes. Of those two, packet inspecti= on results and content switching are clearly the kind of conditional requir= ement that belong in a SFC definition, while there is a strong case that no= de or network failures and policy updates will be orthogonal inputs the the= whole system, not something that can be clearly identified and dealt with = on the data plane. Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Service Funct= ions have discretionary rules that leave the next hop in the chain indeterm= inate until a packet presents itself to the Service Function Instance (most= ly because of middle-boxes), but the Service Function itself MUST be declar= ed before we can select (by any means) a Service Function Instance. And on= ce in the midst of evaluating the conditional requirement, we have a finite= set of "next Service Functions". I can define a completely deterministic = conditional statement, and we should permit such things and leave them to t= he implementers to restrict if they want, but my gut says that most of the = conditional rules will be of the sort where all the possible outcomes MAY b= e foreseen before evaluation (eg. if this, then that, else that2) in which = case the SPI is not indeterminate (that is, entirely unknown until evaluati= on), merely uncertain (that is, which of these possible outcomes is more li= kely), which is significantly easier to deal with. That is the example fro= m my first email in this thread. How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread". If= we don't what to get into that at all, then it is sufficient to say that a= SFC definition MUST include a way to identify all potential SFI's for incl= uded SF's, and that implementations SHOULD resolve as many of the possible = SFI's implied by a SFC before making an assignment and that if there are co= nditional rules in the SFC, then implementations MUST resolv all of the pos= sible SFI's and, by use of the magic thread, tell them all that they should= be prepared to participate in SFI-x for client-A. I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. Example: show service-chain client 2001:db8:0::abc:123:def:456 all service-chain 100 path da29c34de0af:0123:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION url-filter 2001:db8:0:20::80.45.80 opaque web-cache 2001:db8:0:21::80.224.80 carp {http://gothamist.com/2014= /07/09/cooler_weather_arrives_on_the_anniv.php} web-optimizer 2001:db8:0:22::80.137.80 conditional match firewall 2001:db8:0:23::80.132 current-conns 3245 {3992,4503,3= 389} service-chain 109 path da29c34de0af:0134:6e01e1f421d3 FUNCTION INSTANCE DESCRIPTION dns-filter 2001:db8:0:100::53:98.53 passed dns-cache 2001:db8:0:100::53:129.53 miss dns-switch 2001:db8:0:100::53:223.53 off-net, icann tld dns-server 2001:db8:0:99::53:23.53 SOA 2001:db8:fa99:e8b4:123:abcd= :4567:ef01.53 Translation: The client at 2001:db8:0::abc:123:def:456 currently has Servi= ce Function Paths active in two Service Function Chains - 100 and 109 - wi= th the particular Service Function Instances listed in correspondence to th= e Service Function and any information reported by the SFI pertaining to th= e state of the SFP. You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. ________________________________ From: Zarny, Myo [Myo.Zarny@gs.com] Sent: Wednesday, July 09, 2014 3:46 PM To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Bou= cadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hi Ian, Thanks for the write-up. Just to confirm I get this right: You're saying the SFC is a collection of = abstracted desired service functions (your point 1) while the actual path a= given application flow traverses is determined by the service functions th= emselves? E.g., your examples in points (2, 3, 4 and 5)? In your examples, the actual flows (say, TCP connections between the same p= air of endpoints) can traverse different SF paths-nothing wrong with that-e= ven if they follow the same exact SF chain. This mean the SFP isn't predete= rmined (since it's the actual entities that decide the next service functio= n). Do I get that right? Myo PS: Btw, no one has tackled my reverse path question. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: 9 July 2014 2:54 PM To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair' Cc: 'Joel M. Halpern'; 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers 1. You don't have to know the particular service function instances to defi= ne the service function chain. Example: service-chain 100 { 10 url-filter 20 web-cache 30 web-optimizer 40 firewall } Translation: send to instances of these 4 services in this order. 2. You don't have to know the ip address of a service function instance to = define that an instance does exist. Example: service-function url-filter { dns _http._tcp.url-filter.example.com fallback bypass } Translation: query DNS for the address and use it, if you can't resolve an= address, skip this function. 3. You may define a service function conditionally. Example: service-function web-optimizer { if { [class match [HTTP::url] eq optimizable-content] } { ip 2001:db8:0:22::137.80 } else { service-function firewall } } Translation: if the url is known to be optimizable, use this IP address, o= therwise skip this function and go directly to the firewall. 4. You may pre-select a load balancing decision at the time that the Servic= e Function Path is being selected. Example: service-function web-cache { lb carp [HTTP::url] @2001:db8:0:21::224.80 } Translation: instruct the load balancer at the given virtual address to mak= e a load balancing decision using the carp hash of the url and expect us to= send it traffic. 5. You may load balance directly in the path selection process. Example: service-function firewall { pool { least-connections {urn:oid:[Firewall.connections.active] || l= ocal:active_connections} ip 2001:db8:23::130 ip 2001:db8:23::131 ip 2001:db8:23::132 ip 2001:db8:23::133 } } Translation: using either the snmp query to the given oid, or our own inte= rnal counters, pick the ip address from this list that has the least amount= of current connections. 6. You may just declare that the service function is a complex of servers b= ehind a screening device (like a nat or load balancer). Example: service-function url-filter { opaque dns _http._tcp.url-filter.example.com } Translation: use dns to select the instance, but know that there will be a = hidden service function path segment inserted before the next link in the s= ervice function chain. --_000_787AE7BB302AE849A7480A190F8B933002FF35OPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ian,

 

I fully agree with the following:

 

“Where the Service Function Path is de= fined is, in my mind, somewhat irrelevant to the architecture.  It doe= s exist, and by definition it exists because packets are moving along it. ”

 

Cheers,

Med

 

De : Ian Smith [mailto:I.Smith@F5.com]
Envoy=E9 : mercredi 9 juillet 2014 23:36
=C0 : Zarny, Myo; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpign= ata)'; BOUCADAIR Mohamed IMT/OLN
Cc : 'Joel M. Halpern'; 'sfc@ietf.org'
Objet : RE: [sfc] Service Chains, Paths, and Load Balancers

 

Mostly.

I've been defining things like this:

  • Service Function Domain as the logical area in which Service Fu= nction Chains are defined.  There are various names for them but basic= ally all the architectures define an "ingress" and an "egres= s" node that anchors a chain at each end - this is the space between them.
  • Service Function Chain as "an ordered sequence of a finite= number of functions"
  • Service Function Path as "an ordered sequence of particula= r instances of service functions within a Service Function Chain".&nbs= p;
  • Service Function as an abstract thing - "URL Filter"<= o:p>
  • Service Function Node as the physical piece of hardware that ho= uses the Service Function - "this server"
    • <= li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto;mso-list:l0 level1 lfo1"> Service Function Instance as a particular instance of a service= function - "this URL Filter on this Service Function Node" - and= it can be a virtual machine, a container, or just an instance of software on the SFN.


This is consistent with material presented at IETF89 and it didn't seem a m= atter of debate there.  I may have incorrectly believed this to be a c= ase of settled meaning.

Where the Service Function Path is defined is, in my mind, somewhat irrelev= ant to the architecture.  It does exist, and by definition it exists b= ecause packets are moving along it.  In the most rudimentary case, you= are passing from node to node to some destination far away using only their default gateway; the SFI is the agglomeration of= their default gateways.  This easily evolves to IP Source Routes, MPL= S lable stacks, and other in-packet mechanisms, but it just as easily evolv= es to an orchestration system inserting policy routes into nodes in a "just in time" fashion or tying th= e client IP to a pre-existing policy that includes the next hop.  The = latter case is what my previous example showed.

You could enter each of those example config stanzas onto a single node (th= at might happen to be an NFVi platform), or you could enter them each on a = different piece of networking hardware and tie them together with some sort= of "magic thread" like an header field that says "I belong on this Service Function Path (and if you d= on't have that path defined, recurse through the id to find the Service Fun= ction Chain to make whatever evaluation is required by you to send me on my= way.)" or a orchestration system.  I confess to geekishly liking the idea of using the IPX+ address schema = for this. 

Example:

6 byte SFD:4 byte SFC:6 byte SFP
aabbccddeeff:0123:6e01e1f421d3 

(I concede it is too indulgent for most people, but it delivers massive amo= unts of address space with scale out in domains, chains, and paths while st= ill being human readable and relatively easy to shim into lots of places in= a packet or in control plane systems and make referential queries using existing mechanisms.)

You could assume that all of the metadata and orchestration stuff that the = WG is not covering will deal with how to propagate a policy, and that once = it is distributed and installed in the nodes, it takes care of itself. = ; This is perhaps too plainly stated, but it is easy and seems to be the path we are chartered to take.

So, you ask if the path can vary between SFIs and if that is ok as long as = the SFC requirement is met.  I think that is not what people are askin= g for.  What I think people are asking for is a method for channelizin= g services on packet switched networks, which I understand to mean that I should disaggregate flows at the boundary of a= SFD, and force them into channels according to some external policy, keep = them in their channel all the way through the domain, and then reaggregate = them on the other side.  And to give the people what they want, I think you do have to say something like,= "the path may vary but only amongst the SFIs that are defined by the = SFC and once an SFI is selected for use by a flow, it stays selected until = dismissed or it fails" which  to me implies that you MUST select the chain, and you MAY select as many instances withi= n that chain that the policy allows, but you MUST respect conditional eleme= nts of the chain and to do that you have to, in essence, select all the pos= sible instances implied by the chain.  (I don't know if calling it a Markov chain problem helps, but it is an apt= description in my mind.)

That, I hope, explains why my answer to your question about predeterminatio= n is that it is possible in the initial state, but not important.  Onc= e you evaluate the conditional requirements however, then the path is set a= nd it SHOULD remain fixed until an input to the conditional requirements changes.  I would expect that change = to come from four principal areas:  Failure, packet inspection, conten= t switching, or policy update.  There could be more, but those seem to= be the main archetypes.  Of those two, packet inspection results and content switching are clearly the kind of condition= al requirement that belong in a SFC definition, while there is a strong cas= e that node or network failures and policy updates will be orthogonal input= s the the whole system, not something that can be clearly identified and dealt with on the data plane.

Where I perceive confusion on the list is when the Service Function Chain i= s in some sense "To Be Determined" because one or more of the Ser= vice Functions have discretionary rules that leave the next hop in the chai= n indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the= Service Function itself MUST be declared before we can select (by any mean= s) a Service Function Instance.  And once in the midst of evaluating t= he conditional requirement, we have a finite set of "next Service Functions".  I can define a com= pletely deterministic conditional statement, and we should permit such thin= gs and leave them to the implementers to restrict if they want, but my gut = says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluat= ion (eg. if this, then that, else that2) in which case the SPI is not indet= erminate (that is, entirely unknown until evaluation), merely uncertain (th= at is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is= the example from my first email in this thread.

How we deal with them, as a matter of architecture, really has to do with h= ow much we want to talk about what I called earlier "the magic thread&= quot;.  If we don't what to get into that at all, then it is sufficien= t to say that a SFC definition MUST include a way to identify all potential SFI's for included SF's, and that implementation= s SHOULD resolve as many of the possible SFI's implied by a SFC before maki= ng an assignment and that if there are conditional rules in the SFC, then i= mplementations MUST resolv all of the possible SFI's and, by use of the magic thread, tell them all that the= y should be prepared to participate in SFI-x for client-A.

 

I'll follow up my earlier example with this example of how I might query fo= r the service function path from a network console that has a suitable omni= scient view to actually tell me the answer. 

Example:

show service-chain client 2001:db8:0::abc:123:def:456 all

service-chain 100 path da29c34de0af:0123:6e01e1f421d3

FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
url-filter      2001:db8:0:20::80.45.80  = ;   opaque
web-cache       2001:db8:0:21::80.224.80 = ;   carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_= on_the_anniv.php}
web-optimizer   2001:db8:0:22::80.137.80    condit= ional match
firewall        2001:db8:0:23::80.132 &n= bsp;     current-conns 3245 {3992,4503,3389}  &nbs= p;    

service-chain 109 path da29c34de0af:0134:6e01e1f421d3

FUNCTION        INSTANCE  &nbs= p;               &nb= sp; DESCRIPTION
dns-filter      2001:db8:0:100::53:98.53  &nb= sp; passed
dns-cache       2001:db8:0:100::53:129.53 &nb= sp; miss
dns-switch      2001:db8:0:100::53:223.53   o= ff-net, icann tld
dns-server      2001:db8:0:99::53:23.53  = ;   SOA 2001:db8:fa99:e8b4:123:abcd:4567:ef01.53

Translation:  The client at 2001:db8:0:= :abc:123:def:456 currently has Service Function Paths active in two Service= Function Chains - 100 and 109  - with the particular Service Function Instances listed in correspondence to the Service Function and an= y information reported by the SFI pertaining to the state of the SFP.

You could imagine that variations on the same command might yield all the c= lients using a particular chain, or all the chains where a particular insta= nce is present, or where a particular descriptor exists. 

From: Zarny, Myo [Myo.Zarny@gs.com= ]
Sent: Wednesday, July 09, 2014 3:46 PM
To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; '= Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Hi Ian,

 

Thanks for the write-up.

 

Just to confirm I get thi= s right: You’re saying the SFC is a collection of abstracted desired = service functions (your point 1) while the actual path a given application flow traverses is determined by the service functions themselv= es? E.g., your examples in points (2, 3, 4 and 5)?

 

In your examples, the act= ual flows (say, TCP connections between the same pair of endpoints) can tra= verse different SF paths—nothing wrong with that—even if they follow the same exact SF chain. This mean the SFP isn’t predete= rmined (since it’s the actual entities that decide the next service f= unction).

 

Do I get that right?

 

Myo

 

PS: Btw, no one has tackl= ed my reverse path question.

 

 

-----Original Message-----<= br> From: Ian Smith [mailto= :I.Smith@F5.com]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; = 'Med Boucadair'
Cc: 'Joel M. Halpern'; 'sfc@ietf.org'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

 

1. You don't have to know t= he particular service function instances to define the service function cha= in.  Example:

 

service-chain 100 {

    &nb= sp;     10 url-filter

    &nb= sp;     20 web-cache

    &nb= sp;     30 web-optimizer

    &nb= sp;     40 firewall

}

 

Translation:  send to = instances of these 4 services in this order.

 

2. You don't have to know t= he ip address of a service function instance to define that an instance doe= s exist.  Example:

 

service-function url-filter= {

    &nb= sp;    dns _http._tcp.url-filter.example.com

    &nb= sp;    fallback bypass

}

 

Translation:  query DN= S for the address and use it, if you can't resolve an address, skip this fu= nction.

 

3. You may define a service= function conditionally.  Example:

 

service-function web-optimi= zer {

    &nb= sp;    if { [class match [HTTP::url] eq optimizable-content]= } {

    &nb= sp;       ip 2001:db8:0:22::137.80=

    &nb= sp;    } else {

    &nb= sp;       service-function firewall

    &nb= sp;    }

}

 

Translation:  if the u= rl is known to be optimizable, use this IP address, otherwise skip this fun= ction and go directly to the firewall.

 

4. You may pre-select a loa= d balancing decision at the time that the Service Function Path is being se= lected.  Example:

 

service-function web-cache = {

    &nb= sp;    lb carp [HTTP::url] @2001:db8:0:21::224.80 } 

 

Translation: instruct the l= oad balancer at the given virtual address to make a load balancing decision= using the carp hash of the url and expect us to send it traffic.

 

5. You may load balance dir= ectly in the path selection process.  Example:

 

service-function firewall {=

    &nb= sp;    pool {

    &nb= sp;         least-connections {urn:= oid:[Firewall.connections.active] || local:active_connections}

    &nb= sp;         ip 2001:db8:23::130

    &nb= sp;         ip 2001:db8:23::131

    &nb= sp;         ip 2001:db8:23::132

    &nb= sp;         ip 2001:db8:23::133

    &nb= sp;    }        &nbs= p;    

}

 

Translation:  using ei= ther the snmp query to the given oid, or our own internal counters, pick th= e ip address from this list that has the least amount of current connections.

 

6. You may just declare tha= t the service function is a complex of servers behind a screening device (l= ike a nat or load balancer).  Example:

 

service-function url-filter= {

    &nb= sp;    opaque

    &nb= sp;    dns _http._tcp.url-filter.example.com }

 

Translation: use dns to sel= ect the instance, but know that there will be a hidden service function pat= h segment inserted before the next link in the service function chain.

 

 

 

--_000_787AE7BB302AE849A7480A190F8B933002FF35OPEXCLILM23corpor_-- From nobody Wed Jul 9 23:40: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 3C7B21B279E for ; Wed, 9 Jul 2014 23:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 hztA8HEbJIim for ; Wed, 9 Jul 2014 23:40:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6AA1B27AD for ; Wed, 9 Jul 2014 23:40:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGY96611; Thu, 10 Jul 2014 06:40:42 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 07:40:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 14:40:33 +0800 From: Qin Wu To: Ron Parker , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uWy8wAgABdzICAAbKAgA== Date: Thu, 10 Jul 2014 06:40:33 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/O3aCBlHdveVlWOpv-bS1XTmQx-0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 06:40:49 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10g5Luj6KGoIFJvbiBQYXJrZXINCuWPkemAgeaXtumXtDogMjAxNOW5tDfmnIg5 5pelIDIwOjQxDQrmlLbku7bkuro6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEpvZWwg TS4gSGFscGVybjsgc2ZjQGlldGYub3JnDQrkuLvpopg6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpXaGVuIEkgcmVhZCB0aGlzIGNvbW1lbnQ6 DQoNCglbTWVkXSBJIHN0aWxsIGRpc2FncmVlIHRoYXQgYW4gb3JkZXJlZCBsaXN0IG9mIGxvY2F0 b3JzIGNhbiBiZSBkZXRlcm1pbmVkIGluIGFkdmFuY2UgZm9yIGFsbCBkZXBsb3ltZW50cy4gSSBz dWdnZXN0IHRoYXQgU0ZDIGZvcndhcmRpbmcgYmUgYmFzZWQgb24gdGhlIHNlcnZpY2UgY2hhaW4g aXRzZWxmIChjaGFyYWN0ZXJpemVkIGFzIGFuIG9yZGVyIGxpc3Qgb2Ygc2VydmljZSBmdW5jdGlv biBpZGVudGlmaWVycykuIFRoaXMgaXMgbW9yZSBjb21wbGlhbnQgd2l0aCB0aGUgTEIgY29uc3Ry YWludHMgYWJvdmU6IGRlY2lkaW5nIHdoaWNoIGxvY2F0b3IgdG8gdXNlIGZvciBhIGdpdmVuIGZs b3cgd2lsbCBiZSBhIGxvY2FsIGRlY2lzaW9uIG5vdCBhIGNlbnRyYWxpemVkIG9uZS4NCg0KDQoi RE5TIiBwb3BwZWQgaW50byBteSBoZWFkLiAgICBXaGlsZSB0aGlzIG1heSBiZSBhbiBpbXBlcmZl Y3QgYW5hbG9neSwgYSBVUkwgaXMgbG9naWNhbCBsb2NhdGlvbiB0aGF0IHVzZXMgYW4gZXhwbGlj aXQgbWVjaGFuaXNtIHRvIGJpbmQgaXQgdG8gb25lIG9yIG1vcmUgYWN0dWFsIG5ldHdvcmsgbG9j YXRvcnMgKGkuZS4sIElQdjQgYW5kL29yIElQdjYpLiAgIEp1c3QgdGhpbmtpbmcgb3V0IGxvdWQg aGVyZSwgYnV0IGlzIHRoZXJlIGJlbmVmaXQgaW4gdXNpbmcgYSBzaW1pbGFyIHNjaGVtZT8gICBU aGF0IHRoZSBTRkMgaXMgdHJ1bHkgbG9naWNhbCB3aXRoIHNvbWUgc29ydCBvZiAiSnVzdC1pbi10 aW1lIiBiaW5kaW5nLCBhIGxhIEROUyAoa2VlcGluZyBpbiBtaW5kIHRoYXQgRE5TIGNsaWVudHMg d2lsbCBvZnRlbiBsb2NhbGx5IGNhY2hlIHNvIGFzIHRvIGRlY3JlYXNlIHRoZSBhbW91bnQgb2Yg RE5TIHF1ZXJpZXMpPyAgIFdvdWxkIHRoYXQgYXBwcm9hY2ggcHJvdmlkZSBzaW1wbGlmaWNhdGlv biBhbmQgcmVzaWxpZW5jeSB3aXRoIHJlc3BlY3QgdG8gdGhlIGxvYWQgYmFsYW5jaW5nIG9mIHNl cnZpY2UgZnVuY3Rpb25zIHByb2JsZW0gLS0gdGhlIG51bWJlciBvZiBuZXR3b3JrIGxvY2F0b3Jz IGZvciBhIGxvZ2ljYWwgc2VydmljZSBmdW5jdGlvbiBjYW4gY2hhbmdlIGF0IGFueSB0aW1lIGR1 ZSB0byBmYWlsdXJlcyBvciBkdWUgdG8gaW50ZW50aW9uYWwgc2NhbGUtaW4gb3Igc2NhbGUtb3V0 PyAgIEFsc28sIHRoaXMgd291bGRuJ3QgcHJlY2x1ZGUgdGhlIHNjZW5hcmlvIHdoZXJlIG9uZSBv ciBtb3JlIGxvY2F0ZWQgc2VydmljZSBmdW5jdGlvbnMgYXJlIGNsdXN0ZXJlZCwgc2luY2UgdGhl IGNsdXN0ZXIgYXBwZWFycyBhcyBhIHNpbmdsZSBuZXR3b3JrIGxvY2F0b3IgdG8gdGhlICJETlMt bGlrZSIgbWVjaGFuaXNtLg0KDQpbUWluXTogQW4gb3JkZXJlZCBsaXN0IG9mIGxvY2F0b3JzIGNh biBiZSBkZXRlcm1pbmVkIGJ5IFBDRSBvciBhbnkgb3RoZXIgcGF0aCBtYW5hZ2VtZW50IGNvbXBv bmVudCBpbiB0aGUgY29udHJvbCBwbGFuZSBhZnRlciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIHN0 cnVjdHVyZS4gDQpJZiBhbnkgbG9jYXRvciBmb3IgYSBsb2dpY2FsIHNlcnZpY2UgZnVuY3Rpb24g Y2hhbmdlcyAoZS5nLiwgdGhlIGZpcnN0IHNlcnZpY2UgZnVuY3Rpb24gZm9sbG93aW5nIGNsYXNz aWZpZXIgaGFzIG11bHRpcGxlIGluc3RhbmNlKSwgUENFIGNhbiBzZW5kIGFuIHVwZGF0ZWQgbG9j YXRvciBhc3NvY2lhdGVkIHdpdGggdGhpcyBsb2dpY2FsIHNlcnZpY2UgZnVuY3Rpb24gdG8gdGhl IGNsYXNzaWZpZXIuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwOSwgMjAxNCAz OjA1IEFNDQpUbzogSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpIaSBKb2Vs LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4tLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj5EZcKgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4gDQo+RW52b3nDqcKgOiBtZXJjcmVkaSA5IGp1 aWxsZXQgMjAxNCAwNDo0MCDDgMKgOiBzZmNAaWV0Zi5vcmcgT2JqZXTCoDogW3NmY10gDQo+U2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4NCj5JIGhhdmUgYmVlbiB0 cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2YgDQo+ Y29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVyZ2VkIGFy Y2h0aWVjdHVyZSANCj5kcmFmdC4gIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZyBncm91cCBh Z3JlZW1lbnQgb24gdGhlIGludGVudCwgd2UgDQo+d2lsbCB3b3JrIHRvIGltcHJvdmUgdGhlIHdv cmRpbmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCANCj5wYXJ0aWNpcGF0ZWQgaW4gdGhl IFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUgd29ya2luZyANCj5n cm91cCBpbnRlbmRzLg0KPg0KPkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gIEkgd2lsbCB0cnkgdG8g ZXhwbGFpbiBteSBwZXJzb25hbCB2aWV3LCBhbmQgc2VlIA0KPmlmIHRoYXQgaGVscHMuDQo+DQo+ SW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdCB3aGF0 IHdlIGFyZSANCj5kZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuICBXZSBh cmUgbm90IGF0dGVtcHRpbmcgdG8gDQo+ZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBl bnRpcmUgc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuDQo+VGhhdCB3b3VsZCBlbmNvbXBh c3MgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLCANCj52aXJ0 dWFsIG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMu DQoNCltNZWRdIE9TUy9CU1MgY29uc2lkZXJhdGlvbnMgYXJlIG91dCBvZiBzY29wZSBmb3Igc3Vy ZSwgYnV0IHRoZSBmdW5jdGlvbmFsIGVudGl0eShpZXMpIHJlc3BvbnNpYmxlIGZvciB0aGUgc3Ry dWN0dXJpbmcgb2YgY2hhaW5zIHNob3VsZCBiZSBpbiBzY29wZSBJTU8uIFRoZSB0aXRsZSBhbmQg dGhlIGFic3RyYWN0IG9mIHRoZSBtZXJnZWQgZHJhZnQgZG8gbm90IGV4Y2x1ZGUgdGhvc2U6DQoN CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3IgdGhlIHNwZWNp ZmljYXRpb24sDQogICBjcmVhdGlvbiwgYW5kIG9uZ29pbmcgbWFpbnRlbmFuY2Ugb2YgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbnMgKFNGQykgaW4NCiAgIGEgbmV0d29yay4gIEl0IGluY2x1ZGVzIGFy Y2hpdGVjdHVyYWwgY29uY2VwdHMsIHByaW5jaXBsZXMsIGFuZA0KICAgY29tcG9uZW50cyB1c2Vk IGluIHRoZSBjb25zdHJ1Y3Rpb24gb2YgY29tcG9zaXRlIHNlcnZpY2VzIHRocm91Z2gNCiAgIGRl cGxveW1lbnQgb2YgU0ZDcy4NCg0KPg0KPkFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5n cyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhpc3QgaW4gdGhlIA0KPmxhcmdlciBzeXN0ZW0sDQoN CltNZWRdIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5IHRoZSBsYXJnZSBzeXN0 ZW0uIA0KDQogYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFyZSBmdW5j dGlvbmluZywNCj5hbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBh cmUgZG9pbmcuDQo+DQo+SW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2Vydmlj ZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgDQo+SSBuZWVkIHRvIGZpcnN0IGRpc2N1c3Mg bG9hZCBiYWxhbmNpbmcuICBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUgDQo+ZGlmZmVyZW50IHdh eXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwgaW50ZXJhY3Qgd2l0aCBzZXJ2aWNl IA0KPmNoYWluaW5nLiAgVGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuICBUaGUgcG9pbnQgb2YgdGhl IGFyY2h0aWVjdHVyZSBpcyANCj50byBwZXJtaXQgYWxsIG9mIHRoZXNlLCBidXQgbm90IHRvIG1h bmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kIGJlIA0KPnVzZWQgaW4gYW55IHNvbHV0aW9u Lg0KDQpbTWVkXSBBZ3JlZS4gSG93IGxvYWQgYmFsYW5jaW5nIGlzIG1hbmFnZWQgd2l0aGluIGEg U0ZDLWVuYWJsZWQgZG9tYWluIGlzIHVwIHRvIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgYWRt aW5pc3RyYXRpdmUgZW50aXR5IG1hbmFnaW5nIHRoYXQgZG9tYWluLiBPbmUgb3IgYSBtaXggb2Yg dGhlc2UgZmxhdm9ycyBjYW4gY28tZXhpc3QuIA0KDQo+DQo+MSkgTG9hZCBiYWxhbmNpbmcgYXMg YSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4gIFRoaXMgaXMgYSANCj5zZXJ2aWNl IGZ1bmN0aW9uLiAgSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9kaWZpZXMgdGhlbSAo b3IgDQo+bWFya3MgdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vy dmljZSBpbnN0YW5jZSB0byANCj5yZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuICBUaGlzIGlzIGFu IGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGJlIA0KPmFibGUgdG8gaW5jbHVkZSBpbiBz ZXJ2aWNlIGNoYWluaW5nLiAgSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0IA0KPnJlcXVpcmVtZW50 cyBvbiBob3cgc2VydmljZSBjaGFpbmluZyBpcyBkb25lLiAgQnV0IGl0IGhhcyB2ZXJ5IGxpdHRs ZSANCj5pbXBhY3Qgb24gdGhlIGFyY2h0aWVjdHVyZS4gIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBw ZTNyc3BlY3RpdmUgaXQgaXMgDQo+c2ltcGx5IGEgc2VydmljZSBmdW5jdGlvbiB3aGljaCBtYXkg bW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4NCj4yKSBUaGVyZSBpcyBpbnRlcm5hbCBs b2FkIGJhbGFuY2luZy4gIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZSB3aGF0IA0KPmFwcGVhcnMgdG8g dGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9mIA0K PmNvbnRhY3QgZm9yIGEgc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5 IGRlbGl2ZXJlZCBieSBhIA0KPmNvbGxlY3Rpb24gb2YgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNo aW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvciANCj5zZXZlcmFsIGxvYWQgYmFsYW5jZXJz IChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UgdGVjaG5pcXVlcyB0byBzaGFyZSANCj5hIE1B Qw0KPmFkZHJlc3MuKSAgbW9zdGx5LCB0aGlzIGlzIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBj aGFpbmluZyBkYXRhIHBsYW5lIA0KPm1lY2hhbmlzbXMuICBJdCBpcyBsaWtlbHkgdGhhdCBpdCBp cyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbCANCj5tZWNoYW5pc21zLCBzdWNoIGFzIHRob3Nl IHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBhbmQgdm0gDQo+aW5zdGFudGlh dGlvbi4gIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFy Z2VseSANCj50aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBk b2VzIG5vdCBsZWFkIHJlYWRlcnMgDQo+dG8gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0K Pg0KPjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgc2VsZWN0aW5n IHBhY2tldCBwYXRocyBmb3IgDQo+dGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJh ZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiAgV2Ugd291bGQgDQo+bm90IHdhbnQgdG8gcmVxdWly ZSB0aGF0IGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgDQo+cGxh Y2UgaW4gdGhlIG5ldHdvcmsuDQo+DQo+SXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhl c2UgbWF5IGJlIGNvbWJpbmVkLiAgSSB0ZW5kIHRvIHJlZmVyIA0KPnRvIHRoZSBjb2xsZWN0aW9u IG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmcgYXMgYSANCj5zaW5n bGUgcG9pbnQgYXMgYSBjbHVzdGVyLiAgTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhIGdvb2QgdGVy bS4gIEJ1dCANCj5iZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuICBUaHVzLCB0aGUg cG9pbnQgb2YgdHlwZSAzIGxvYWQgDQo+YmFsYW5jaW5nIGlzIHRvIGRpcmVjdCBkaWZmZXJlbnQg c3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudCANCj5zaW5ndWxhciBvciBjbHVzdGVyZWQg c2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUgbmV0d29yay4NCj4N Cj5Ob3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0IHNl cnZpY2UgY2hhaW4gYW5kIA0KPnNlcnZpY2UgcGF0aC8gIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1 ZW5jZSBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSANCj5hcHBsaWVkIHRvIGEgc3Vic2V0IG9m IHBhY2tldHMuICBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgDQo+c3Vic2V0 IG9mIHRyYWZmaWMgaXMgdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwg YW5kIA0KPmZpcmV3YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3Rs eSB0byB0aGUgY2FjaGUgDQo+d2l0aG91dCB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5j dGlvbnMuDQo+DQo+VGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUg cGFja2V0cy4gDQoNCltNZWRdIEEgc2VydmljZSBjaGFpbiBjYW4gYWxzbyBiZSBkZWZpbmVkIGFz IGFuIG9yZGVyIGxpc3Qgb2Ygc2VydmljZSBmdW5jdGlvbiBpZGVudGlmaWVycy4gSSB1bmRlcnN0 YW5kIHRoZSBleGFtcGxlcyB5b3UgcHJvdmlkZSBhcyBsaWJlcmFsIGRlc2NyaXB0aW9uIG9mIHNl cnZpY2UgY2hhaW5zICh0aGF0IEkgdGhvdWdodCB5b3UgY29uc2lkZXJlZCBpdCBvdXQgb2Ygc2Nv cGUpLiBBIHNlcnZpY2UgZnVuY3Rpb24gaWRlbnRpZmllciBkb2VzIG5vdCBuZWNlc3NhcmlseSBo aW50IHRoZSBzZXJ2aWNlIG9mZmVyZWQgYnkgdGhhdCBTRjsgaXRzIHB1cnBvc2UgaXMgdG8gdW5p cXVlbHkgaWRlbnRpZnkgYSBTRiBhbW9uZyB0aG9zZSBwcmVzZW50IGluIGEgU0ZDLWVuYWJsZWQg ZG9tYWluLg0KDQogQSBzZXJ2aWNlIHBhdGgNCj5pcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVl bmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yay4NCg0KW01lZF0gc28sIHRoaXMgaXMgYW4g b3JkZXIgbGlzdCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGxvY2F0b3JzLiANCg0KICBUaG9zZQ0KPmxv Y2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRl bGl2ZXJ5IA0KPmxvY2F0aW9ucy4gIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBieSBJUCBhZGRyZXNz LiAgVGhleSBtYXkgYmUgYWRkcmVzc2VkIA0KPmFzIHBvcnRzIG9uIGFuIFNGRi4gIFRoZXJlIGFy ZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucyANCj5tYXkgYmUga25vd24g dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZSB0cmFuc3BvcnQu DQo+DQo+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91 cCwgd2UgbmVlZCB0byBiZSANCj5hYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJz dHJhY3Rpb24sIHRoZSBzZXJ2aWNlIGNoYWluLCB3aGljaCANCj5kcml2ZXMgdGhlIGZvcndhcmRp bmcuICBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIA0KPnBh Y2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLg0KPg0KPlNldmVyYWwgb2YgdGhlIGNvbW1l bnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUga25vd24gDQo+YXQg dGhlIGZyb250LiINCg0KW01lZF0gV2hpY2ggaXMgdHJ1ZS4gVGhlIGVudGl0eSByZXNwb25zaWJs ZSBmb3Igc3RydWN0dXJlIHRoZSBzZXJ2aWNlIGNoYWluIGNhbm5vdCBkZWNpZGUgaW4gYWR2YW5j ZSB0aGUgYWN0dWFsIHBhY2tldCBvZiBwYWNrZXRzIGJlY2F1c2Ugb2YgdmFyaW91cyBjb25zaWRl cmF0aW9ucyBzdWNoIFNGLXNwZWNpZmljIExCcywgYnV0IGFsc28gZm9yIG90aGVyIHRyYWZmaWMg ZW5naW5lZXJpbmcgcHVycG9zZXMgc3VjaCBhcyBkaXNwYXRjaGluZyB0aGUgdHJhZmZpYyBhbW9u ZyB0d28gc2VydmljZSBQb1BzIGhvc3RpbmcgdGhlIHNhbWUgc2V0IG9mIFNGcywgZXRjLg0KDQog IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4NCj5G aXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZCBiYWxhbmNlcnMgYWJvdmUsIHRoZXJl IGNhbiBiZSANCj5kZWNpc2lvbnMgYW5kIGJlaGF2aW9ycyB3aGljaCBhcmUgaW52aXNpYmxlIHRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIA0KPm1lY2hhbmlzbXMgKGluIG11Y2ggdGhlIHNhbWUgd2F5 IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkgDQo+aW52aXNpYmxlIHRvIHJv dXRpbmcgYmV0d2VlbiBMQU5zLikNCg0KW01lZF0gV2hpY2ggbWVhbnMgdGhhdCB5b3UgY2Fubm90 IGRldGVybWluZSBhIGxpc3Qgb2YgbG9jYXRvciBhIHByaW9yaSBnaXZlbiB0aGF0IHRoZSBkZWNp c2lvbiBvbiB3aGljaCBTRiBpbnN0YW5jZSB3aWxsIGJlIGludm9rZWQgaXMgdGhlIHJlc3BvbnNp YmlsaXR5IG9mIHRoYXQgTEIuDQoNCg0KICBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlIG1ha2UgaXMg dGhhdA0KPnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVj ZXNzYXJ5Lg0KDQpbTWVkXSBSZS1jbGFzc2lmaWNhdGlvbiBpcyBvcHRpb25hbCBhbmQgaXMgZGVw bG95bWVudC1zcGVjaWZpYy4gTWFuZGF0aW5nIHJlLWNsYXNzaWZpY2F0aW9uIHRvIGp1c3RpZnkg YSBkZXNpZ24gY2hvaWNlIGlzIG9kZC4gDQoNCiAgVGhhdCB3aWxsDQo+ZGlyZWN0IHBhY2tldHMg dG8gYSBuZXcgY2hhaW4uICBCYXNlZCBvbiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIA0K PnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KDQpbTWVkXSBUaGF0J3Mgbm90IG9wdGltYWwgZm9y IHNvbWUgZGVwbG95bWVudHMgdGhhdCBkbyBub3QgcmVxdWlyZSB0byBlbWJlZCBhIGNsYXNzaWZp Y2F0aW9uIGZ1bmN0aW9uIGluIHRoZXNlIHNlcnZpY2UgZnVuY3Rpb25zLiANCg0KPg0KPkkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gDQoNCltNZWRdIEkg c3RpbGwgZGlzYWdyZWUgdGhhdCBhbiBvcmRlcmVkIGxpc3Qgb2YgbG9jYXRvcnMgY2FuIGJlIGRl dGVybWluZWQgaW4gYWR2YW5jZSBmb3IgYWxsIGRlcGxveW1lbnRzLiBJIHN1Z2dlc3QgdGhhdCBT RkMgZm9yd2FyZGluZyBiZSBiYXNlZCBvbiB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGYgKGNoYXJh Y3Rlcml6ZWQgYXMgYW4gb3JkZXIgbGlzdCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGlkZW50aWZpZXJz KS4gVGhpcyBpcyBtb3JlIGNvbXBsaWFudCB3aXRoIHRoZSBMQiBjb25zdHJhaW50cyBhYm92ZTog ZGVjaWRpbmcgd2hpY2ggbG9jYXRvciB0byB1c2UgZm9yIGEgZ2l2ZW4gZmxvdyB3aWxsIGJlIGEg bG9jYWwgZGVjaXNpb24gbm90IGEgY2VudHJhbGl6ZWQgb25lLg0KDQoNCiBJZiBpdCBkb2VzLCBh bmQgaWYNCj50aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsIHdl IGNhbiBmaWd1cmUgb3V0IHdoYXQgDQo+YWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkIHRvIGNv bnZleSB0aGlzLg0KPklmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVu dCwgdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSANCj5hZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcg Z3JvdXAgYWdyZWVtZW50cy4NCj5JZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1 cmUgd2hhdCB0byB0cnkgbmV4dC4NCj4NCj5Zb3VycywNCj5Kb2VsDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+ c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBt YWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Wed Jul 9 23:47: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 824001B27A9 for ; Wed, 9 Jul 2014 23:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 VTzkyCX9rc_r for ; Wed, 9 Jul 2014 23:47:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262E31B27A5 for ; Wed, 9 Jul 2014 23:47:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU83689; Thu, 10 Jul 2014 06:47:38 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 07:47:36 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 14:47:31 +0800 From: Qin Wu To: "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uXpRMAgAE5vhA= Date: Thu, 10 Jul 2014 06:47:30 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84581270nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UBxVr3tyWgQhDgmHRbtR9WdrlFo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 06:47:44 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84581270nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBzZWNvbmQgcGFyYWdyYXBoIHJhaXNlcyBhIHZlcnkgZ29vZCBxdWVzdGlvbi4gQnV0IG15 IGludGVycHJldGF0aW9uIHRvIHlvdXIgbGFzdCBwYXJhZ3JhcGggaXMNClNGQyBhbmQgU0ZQIGFy ZSBib3RoIG5lZWRlZC4gQnV0IFNGQyBpcyBmaXJzdCBzdHJ1Y3R1cmVkIGFuZCB0aGVuIFNGQyBu ZWVkIHRvIGJlIHRyYW5zbGF0ZWQgaW50byBTRlAgc2luY2UgaW4gc29tZSBjYXNlcyAobWVudGlv bmVkIGluIHRoaXMgdGhyZWFkKSwgb25lIFNGQyBtYXkgYmUNCkNvcnJlc3BvbmRpbmcgdG8gbXVs dGlwbGUgU0ZQcy4NCg0KUmVnYXJkcyENCi1RaW4NCuWPkeS7tuS6ujogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBtaWtlYmlhbmNAYW9sLmNvbQ0K5Y+R6YCB5pe26Ze0 OiAyMDE05bm0N+aciDEw5pelIDQ6MDMNCuaUtuS7tuS6ujogam1oQGpvZWxoYWxwZXJuLmNvbTsg c2ZjQGlldGYub3JnDQrkuLvpopg6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KDQpJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gIE90aGVyIHRoYW4gY2xhcmlmeWlu ZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8gdGhvc2Ugbm90IGZhbWlsaWFy IHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGVzZSB0 ZXJtcy4NCg0KVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdo ZXRoZXIgaXQgaXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lm eSB3aGF0IHRoZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQgcmVmZXJlbmNlICh0aGUgY2hh aW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvIGxlYXZl IHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0ZSB0aGUgbWVj aGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hv aWNlIG9mIGNoYWluIG9yIHBhdGggdG8gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFu ZS4NCg0KSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2 ZSByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2Ugb25l IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUgdmVuZG9ycyBv bmx5IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4NCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGptaEBqb2VsaGFscGVy bi5jb208am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2pt aEBqb2VsaGFscGVybi5jb20+Pg0KVG86IHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDgsIDIw MTQNClN1YmplY3Q6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQoNCkkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFu c3dlciBhIG51bWJlciBvZg0KY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUg cHJvcG9zZWQgbWVyZ2VkIGFyY2h0aWVjdHVyZQ0KZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQg d29ya2luZyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2UNCndpbGwgd29yayB0byBp bXByb3ZlIHRoZSB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QNCnBhcnRpY2lw YXRlZCBpbiB0aGUgV0cgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZSB3 b3JraW5nDQpncm91cCBpbnRlbmRzLg0KDQpCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0 cnkgdG8gZXhwbGFpbiBteSBwZXJzb25hbCB2aWV3LCBhbmQgc2VlDQppZiB0aGF0IGhlbHBzLg0K DQpJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0IHdo YXQgd2UgYXJlDQpkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFy ZSBub3QgYXR0ZW1wdGluZyB0bw0KZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRp cmUgc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuDQpUaGF0IHdvdWxkIGVuY29tcGFzcyBP U1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQp2aXJ0dWFsIG1h Y2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMuDQoNCkFz IGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhp c3QgaW4gdGhlDQpsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGggYWJvdmUg d2hlcmUgd2UgYXJlIGZ1bmN0aW9uaW5nLA0KYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQg YnkgdGhlIHdvcmsgd2UgYXJlIGRvaW5nLg0KDQpJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBj aGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLA0KSSBuZWVkIHRvIGZp cnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZQ0KZGlm ZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwgaW50ZXJhY3Qgd2l0 aCBzZXJ2aWNlDQpjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBv ZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvDQpwZXJtaXQgYWxsIG9mIHRoZXNlLCBidXQgbm90IHRv IG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kIGJlIHVzZWQNCmluIGFueSBzb2x1dGlv bi4NCg0KMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQg dXNlci4gVGhpcyBpcyBhDQpzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tl dHMsIGFuZCBtb2RpZmllcyB0aGVtIChvciBtYXJrcw0KdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBj aG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZSB0byByZWNlaXZlDQp0aGUgdXNlcnMg cGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGJlIGFibGUg dG8NCmluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0 IHJlcXVpcmVtZW50cyBvbg0KaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4gQnV0IGl0IGhh cyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQphcmNodGllY3R1cmUuIEZyb20gYW4gYXJjaGl0 ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGEgc2VydmljZQ0KZnVuY3Rpb24gd2hp Y2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQoNCjIpIFRoZXJlIGlzIGludGVy bmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuIGhhdmUgd2hhdCBhcHBlYXJzDQp0 byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2Yg Y29udGFjdCBmb3IgYQ0Kc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5 IGRlbGl2ZXJlZCBieSBhIGNvbGxlY3Rpb24gb2YNCnZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGlu ZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3Igc2V2ZXJhbCBsb2FkDQpiYWxhbmNlcnMgKGZv ciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDDQphZGRy ZXNzLikgbW9zdGx5LCB0aGlzIGlzIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBk YXRhIHBsYW5lDQptZWNoYW5pc21zLiBJdCBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbA0KbWVjaGFuaXNtcywgc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBm b3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtDQppbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0 ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzIGlzIGxhcmdlbHkNCnRoYXQgd2UgbmVl ZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5IGRvZXMgbm90IGxlYWQgcmVhZGVy cyB0bw0KdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KDQozKSBUaGVyZSBjYW4gYWxzbyBi ZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZyBwYWNrZXQgcGF0aHMgZm9yDQp0aGUg c2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdCB0cmFmZmljIHRvIGRpZmZlcmVudCBwbGFjZXMu IFdlIHdvdWxkDQpub3Qgd2FudCB0byByZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0 aW9uIGFwcGVhciBhdCBvbmx5IG9uZQ0KcGxhY2UgaW4gdGhlIG5ldHdvcmsuDQoNCkl0IGlzIG9m IGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kIHRvIHJl ZmVyIHRvDQp0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNl IGNoYWluaW5nIGFzIGEgc2luZ2xlDQpwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNs dXN0ZXIgaXMgYSBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkNCmRvIG5vdCBoYXZlIGFub3RoZXIg b25lLiBUaHVzLCB0aGUgcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlzIHRvDQpkaXJl Y3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIgb3Ig Y2x1c3RlcmVkDQpzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZSBu ZXR3b3JrLg0KDQpOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxr IGFib3V0IHNlcnZpY2UgY2hhaW4gYW5kDQpzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMg YSBzZXF1ZW5jZSBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZQ0KYXBwbGllZCB0byBhIHN1YnNl dCBvZiBwYWNrZXRzLiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUNCnN1YnNl dCBvZiB0cmFmZmljIGlzIHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24s IGFuZA0KZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5 IHRvIHRoZSBjYWNoZSB3aXRob3V0DQp2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlv bnMuDQoNClRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tl dHMuIEEgc2VydmljZSBwYXRoDQppcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxv Y2F0aW9ucyBpbiB0aGUgbmV0d29yay4gVGhvc2UNCmxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFy IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5DQpsb2NhdGlvbnMuIFRoZXkg bWF5IGJlIGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQNCmFz IHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUg bG9jYXRpb25zDQptYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1 Y3R1cmUgYW5kIHRoZSB0cmFuc3BvcnQuDQoNCkZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhl IHdvcmsgb2YgdGhlIFNGQyBncm91cCwgd2UgbmVlZCB0byBiZSBhYmxlDQp0byB0YWxrIGFib3V0 IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2gNCmRy aXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFs IGRhdGEgcGF0aA0KcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlIG5ldHdvcmsuDQoNClNldmVyYWwg b2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUg a25vd24NCmF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBp c3N1ZSBpbiB0d28gd2F5cy4NCkZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBvbiBsb2FkIGJh bGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlDQpkZWNpc2lvbnMgYW5kIGJlaGF2aW9ycyB3aGlj aCBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nDQptZWNoYW5pc21zIChpbiBt dWNoIHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQpp bnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdl IG1ha2UgaXMgdGhhdA0KcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4g d2hlbiBuZWNlc3NhcnkuIFRoYXQgd2lsbA0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4u IEJhc2VkIG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUNCnJlLWNsYXNzaWZpY2F0aW9u IHBvaW50Lg0KDQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0 ZXIuIElmIGl0IGRvZXMsIGFuZCBpZg0KdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3 b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0DQphZGRpdGlvbmFsIHdvcmRzIGFy ZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuDQpJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3 aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UNCmFkanVzdCB0byBtYXRjaCB0 aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLg0KSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJ IGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5leHQuDQoNCllvdXJzLA0KSm9lbA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlz dA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_B8F9A780D330094D99AF023C5877DABA84581270nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4w cHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi 5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdXIgc2Vjb25kIHBhcmFn cmFwaCByYWlzZXMgYSB2ZXJ5IGdvb2QgcXVlc3Rpb24uIEJ1dCBteSBpbnRlcnByZXRhdGlvbiB0 byB5b3VyIGxhc3QgcGFyYWdyYXBoIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TRkMgYW5kIFNGUCBhcmUgYm90aCBuZWVkZWQuIEJ1dCBTRkMgaXMgZmlyc3Qg c3RydWN0dXJlZCBhbmQgdGhlbiBTRkMgbmVlZCB0byBiZSB0cmFuc2xhdGVkIGludG8gU0ZQIHNp bmNlIGluIHNvbWUgY2FzZXMgKG1lbnRpb25lZCBpbiB0aGlzIHRocmVhZCksDQogb25lIFNGQyBt YXkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvcnJlc3Bv bmRpbmcgdG8gbXVsdGlwbGUgU0ZQcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1R aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu2 5Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5taWtl YmlhbmNAYW9sLmNvbTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7m nIg8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiA0OjAz PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZzxicj4N Cjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5JcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gJm5ic3A7T3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRo ZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxpYXIgd2l0 aCB0aGUNCiBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24gdGhlc2UgdGVy bXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBtZSwgdGhlIG9uZSBwb2lu dCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRo aXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVh ZGVyIHNob3VsZCByZWZlcmVuY2UgKHRoZQ0KIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhp cyBkcmFmdCBzaW1wbHkgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcg b3RoZXIgZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFz ZWQgb24gY2hhaW4gb3IgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvciBwYXRoIHRvIGJl IG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJh ZnQgd291bGQgaGF2ZSByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQg KG9yIG1ha2Ugb25lIHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNv bWUgdmVuZG9ycw0KIG9ubHkgc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRp bmcgU0ZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9y OiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5j b20mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86IDwvYj48YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmcmbHQ7c2Zj QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+VHVlc2RheSwgSnVseSA4LCAyMDE0 PGJyPg0KPGI+U3ViamVjdDogPC9iPltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQg aG93IHRvIGNsZWFybHkgYW5zd2VyIGEgbnVtYmVyIG9mIDxicj4NCmNvbW1lbnRzIHRoYXQgaGF2 ZSBiZWVuIG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1lcmdlZCBhcmNodGllY3R1cmUgPGJyPg0K ZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZyBncm91cCBhZ3JlZW1lbnQgb24gdGhl IGludGVudCwgd2UgPGJyPg0Kd2lsbCB3b3JrIHRvIGltcHJvdmUgdGhlIHdvcmRpbmcgc28gdGhh dCByZWFkZXJzIHdobyBoYXZlIG5vdCA8YnI+DQpwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHIGRpc2N1 c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUgd29ya2luZyA8YnI+DQpncm91cCBp bnRlbmRzLjxicj4NCjxicj4NCkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBl eHBsYWluIG15IHBlcnNvbmFsIHZpZXcsIGFuZCBzZWUgPGJyPg0KaWYgdGhhdCBoZWxwcy48YnI+ DQo8YnI+DQpJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0 aGF0IHdoYXQgd2UgYXJlIDxicj4NCmRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVj dHVyZS4gV2UgYXJlIG5vdCBhdHRlbXB0aW5nIHRvIDxicj4NCmRlZmluZSB0aGUgYXJjaGl0ZWN0 dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiA8YnI+DQpU aGF0IHdvdWxkIGVuY29tcGFzcyBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBm dW5jdGlvbnMsIDxicj4NCnZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5k IG1hbnkgb3RoZXIgYXNwZWN0cy48YnI+DQo8YnI+DQpBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFu eSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZSA8YnI+DQpsYXJnZXIg c3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGggYWJvdmUgd2hlcmUgd2UgYXJlIGZ1bmN0 aW9uaW5nLCA8YnI+DQphbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3 ZSBhcmUgZG9pbmcuPGJyPg0KPGJyPg0KSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4g dnMgc2VydmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgPGJyPg0KSSBuZWVkIHRvIGZp cnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZSA8YnI+ DQpkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbCBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgPGJyPg0KY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiBU aGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byA8YnI+DQpwZXJtaXQgYWxsIG9mIHRo ZXNlLCBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kIGJlIHVzZWQg PGJyPg0KaW4gYW55IHNvbHV0aW9uLjxicj4NCjxicj4NCjEpIExvYWQgYmFsYW5jaW5nIGFzIGEg c2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMgaXMgYSA8YnI+DQpzZXJ2aWNl IGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZCBtb2RpZmllcyB0aGVtIChv ciBtYXJrcyA8YnI+DQp0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBz ZXJ2aWNlIGluc3RhbmNlIHRvIHJlY2VpdmUgPGJyPg0KdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBp cyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIDxicj4NCmluY2x1 ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVt ZW50cyBvbiA8YnI+DQpob3cgc2VydmljZSBjaGFpbmluZyBpcyBkb25lLiBCdXQgaXQgaGFzIHZl cnkgbGl0dGxlIGltcGFjdCBvbiB0aGUgPGJyPg0KYXJjaHRpZWN0dXJlLiBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2UgPGJyPg0KZnVuY3Rp b24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuPGJyPg0KPGJyPg0KMikg VGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZSB3 aGF0IGFwcGVhcnMgPGJyPg0KdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFz IGEgc2luZ2xlIHBvaW50IG9mIGNvbnRhY3QgZm9yIGEgPGJyPg0Kc3BlY2lmaWMgc2VydmljZSBm dW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhIGNvbGxlY3Rpb24gb2YgPGJy Pg0KdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBv ciBzZXZlcmFsIGxvYWQgPGJyPg0KYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxp a2UgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyA8YnI+DQphZGRyZXNzLikgbW9zdGx5LCB0aGlz IGlzIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIDxicj4NCm1l Y2hhbmlzbXMuIEl0IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250 cm9sIDxicj4NCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxl LWluLCBzY2FsZS1vdXQsIGFuZCB2bSA8YnI+DQppbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0 dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzIGlzIGxhcmdlbHkgPGJyPg0KdGhhdCB3ZSBu ZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVybWlub2xvZ3kgZG9lcyBub3QgbGVhZCByZWFk ZXJzIHRvIDxicj4NCnRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC48YnI+DQo8YnI+DQozKSBU aGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZyBwYWNrZXQg cGF0aHMgZm9yIDxicj4NCnRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMg dG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgPGJyPg0Kbm90IHdhbnQgdG8gcmVxdWlyZSB0 aGF0IGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgPGJyPg0KcGxh Y2UgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRo YXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQgdG8gcmVmZXIgdG8gPGJyPg0KdGhlIGNv bGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZyBhcyBh IHNpbmdsZSA8YnI+DQpwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMg YSBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgPGJyPg0KZG8gbm90IGhhdmUgYW5vdGhlciBvbmUu IFRodXMsIHRoZSBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcgaXMgdG8gPGJyPg0KZGly ZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9y IGNsdXN0ZXJlZCA8YnI+DQpzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGlu IHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCk5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1l YW4gd2hlbiBJIHRhbGsgYWJvdXQgc2VydmljZSBjaGFpbiBhbmQgPGJyPg0Kc2VydmljZSBwYXRo LyBTZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUg PGJyPg0KYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLiBJdCBpcyBlcXVpdmFsZW50IG9m IHNheWluZyB0aGF0IHNvbWUgPGJyPg0Kc3Vic2V0IG9mIHRyYWZmaWMgaXMgdG8gZ2V0IERQSSwg Y2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kIDxicj4NCmZpcmV3YWxsIHdoaWxlIGEg ZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUgd2l0aG91dCA8 YnI+DQp2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPg0KPGJyPg0KVGhh dCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQSBzZXJ2 aWNlIHBhdGggPGJyPg0KaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlv bnMgaW4gdGhlIG5ldHdvcmsuIFRob3NlIDxicj4NCmxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFy IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IDxicj4NCmxvY2F0aW9ucy4g VGhleSBtYXkgYmUgYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3Nl ZCA8YnI+DQphcyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlz IHRoYXQgdGhlIGxvY2F0aW9ucyA8YnI+DQptYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZSB0cmFuc3BvcnQuPGJyPg0KPGJyPg0KRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRv IGJlIGFibGUgPGJyPg0KdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwg dGhlIHNlcnZpY2UgY2hhaW4sIHdoaWNoIDxicj4NCmRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5k IHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCA8YnI+DQpwYWNrZXRz IHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgJnF1b3Q7YnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUga25vd24g PGJyPg0KYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRo YXQgaXNzdWUgaW4gdHdvIHdheXMuIDxicj4NCkZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBv biBsb2FkIGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIDxicj4NCmRlY2lzaW9ucyBhbmQg YmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgPGJy Pg0KbWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4g YSBMQU4gaXMgbGFyZ2VseSA8YnI+DQppbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMu KSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlIG1ha2UgaXMgdGhhdCA8YnI+DQpyZWNsYXNzaWZpY2F0 aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vzc2FyeS4gVGhhdCB3aWxsIDxi cj4NCmRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBpbmZvcm1hdGlvbiBh dmFpbGFibGUgYXQgdGhlIDxicj4NCnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Ljxicj4NCjxicj4N CkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQg ZG9lcywgYW5kIGlmIDxicj4NCnRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2lu ZyBncm91cCwgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCA8YnI+DQphZGRpdGlvbmFsIHdvcmRzIGFy ZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuPGJyPg0KSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdy ZWUgd2l0aCB0aGUgaW50ZW50LCB0aGVuIHdlIHdpbGwgb2YgY291cnNlIDxicj4NCmFkanVzdCB0 byBtYXRjaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLjxicj4NCklmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRyeSBuZXh0Ljxicj4NCjxicj4NCllv dXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA84581270nkgeml501mbschi_-- From nobody Wed Jul 9 23:55: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 CFCB31B27AB for ; Wed, 9 Jul 2014 23:55:35 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 R1wT97dtkfFN for ; Wed, 9 Jul 2014 23:55:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2371B27A5 for ; Wed, 9 Jul 2014 23:55:28 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 802343B46E7; Thu, 10 Jul 2014 08:55:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2199A35C070; Thu, 10 Jul 2014 08:55:25 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 08:55:25 +0200 From: To: "Ken Gray (kegray)" , "NAPIERALA, MARIA H" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8UxKjmuDn4BEiFVdMuQoKu35uXlPYAgACF5yD//+kcAIAA2aXg Date: Thu, 10 Jul 2014 06:55:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002FF7A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.10.22119 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zBQgZGIXiE3gCmWJMxI1tqzxzY0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 06:55:36 -0000 SGkgS2VuLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4tLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj5EZcKgOiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtl Z3JheUBjaXNjby5jb21dDQo+RW52b3nDqcKgOiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMTo0 Mg0KPsOAwqA6IE5BUElFUkFMQSwgTUFSSUEgSDsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsg Sm9lbCBNLiBIYWxwZXJuOw0KPnNmY0BpZXRmLm9yZw0KPk9iamV0wqA6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPg0KPkkgdGhpbmsgeW91IGhh dmUgdG8gZ28gYmFjayB0byBKb2VsJ3Mgb3JpZ2luYWwgZGVzY3JpcHRpb24gb2YgYSBjaGFpbiBh bmQNCj5hIHBhdGg6DQo+DQo+U2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxvZ2ljYWwg ZnVuY3Rpb25zIHRvIGJlDQo+YXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLg0KPg0KPg0K PlRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tldHMuDQoN CltNZWRdIFRoaXMgaXMgbm90IGEgdmFsaWQgYXJndW1lbnQuIFRoZSBjdXJyZW50IG1lcmdlZCBk cmFmdCBkb2VzIG5vdCBkZWZpbmUgd2hhdCBleGFjdCBzdGF0ZSBpbmZvcm1hdGlvbiBpcyBwcm92 aXNpb25lZC9tYWludGFpbmVkIGJ5IGFuIFNGIGJ1dCB5b3UgY2FuIGVhc2lseSBpbWFnaW5lIHRo YXQgYW4gU0ZGIGlzIGNvbmZpZ3VyZWQgd2l0aCBhIGxpc3Qgb2YgbG9jYXRvcnMgb2YgYWxsIG5l eHQgaG9wcyBvZiBjaGFpbnMgaXQgbXVzdCBwcm9jZXNzLiBJdCBpcyBub3QgdHJ1ZSB0aGF0IHRo ZSBvbmx5IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIGlzIHRvIG1hbmRhdGUgc29tZSBraW5kIG9m IHNvdXJjZSByb3V0aW5nLg0KDQogIEEgc2VydmljZSBwYXRoDQo+aXMsIGluIHNvbWUgZmFzaGlv biwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuDQo+DQo+DQo+xaB3aGlj aCBJIGZ1bGx5IGFncmVlIGlzIGEgcmVhc29uYWJsZSBkZWZpbml0aW9uLiAgWW91IGRvIG5lZWQg YSBsb2NhdG9yIHRvDQo+ZmluZCB0aGUgZGV2aWNlIGluIHRoZSBjaGFpbiBpbiB0aGUgbmV0d29y ayBhbmQgeW91IGJldHRlciBrbm93IHdoYXQgdGhhdA0KPmlzIHdoZW4geW91IGNsYXNzaWZ5IHRo ZSB0cmFmZmljLiAgVGhhdCBhcHBsaWVzIGV2ZW4gd2hlbiB0aGUgZGV2aWNlDQo+bG9jYXRvciBp cyBhbiBhYnN0cmFjdGlvbiBmb3IgdGhvdXNhbmRzIG9mIGRldmljZXMgdGhhdCBpdCBtYW5hZ2Vz IGxvY2FsbHkNCj5hcyAiZnVuY3Rpb24gWCIuICBXaGF0IEkgaGF2ZSBiZWVuIHNheWluZyBpcyB0 aGF0IHlvdSBkbyBOT1QgbmVlZCB0byBrbm93DQo+dGhlIGFkZHJlc3Mgb2Ygd2hhdGV2ZXIgaW5z dGFuY2UgWCBpcyBtYW5hZ2luZyBhcyBsb25nIGFzIHRoZSBuZXh0DQo+ZnVuY3Rpb24gaW4gdGhl IGNoYWluIGlzIG5vdCBhIGRpdmVyZ2VudCBsb2NhdG9yIGFmdGVyIHRoYXQgcG9pbnQgb2YNCj5h YnN0cmFjdGlvbiAoYmVjYXVzZSB0aGVuIHlvdSBkbyBoYXZlIGRpZmZlcmVudCBkaXNjcmV0ZSBj aGFpbnMgYW5kIHBhdGhzKS4NCj4NCj5JbiB0aGlzIHJlc3BlY3QsIEkgZG9uJ3QgdGhpbmsgTEIv QURDIGFwcGxpZXMgYXMgYW4gZXhhbXBsZSBvZiBub3Qga25vd2luZw0KPnRoZSBmdWxsIHBhdGgg YSBwcmlvcmkuDQo+DQo+T24gNy85LzE0IDM6MDYgUE0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxt bjE5MjFAYXR0LmNvbT4gd3JvdGU6DQo+DQo+Pj4gW01lZF0gSSBzdGlsbCBkaXNhZ3JlZSB0aGF0 IGFuIG9yZGVyZWQgbGlzdCBvZiBsb2NhdG9ycyBjYW4gYmUNCj4+PmRldGVybWluZWQgaW4NCj4+ PiBhZHZhbmNlIGZvciBhbGwgZGVwbG95bWVudHMuIEkgc3VnZ2VzdCB0aGF0IFNGQyBmb3J3YXJk aW5nIGJlIGJhc2VkIG9uDQo+Pj50aGUNCj4+PiBzZXJ2aWNlIGNoYWluIGl0c2VsZiAoY2hhcmFj dGVyaXplZCBhcyBhbiBvcmRlciBsaXN0IG9mIHNlcnZpY2UgZnVuY3Rpb24NCj4+PiBpZGVudGlm aWVycykuIFRoaXMgaXMgbW9yZSBjb21wbGlhbnQgd2l0aCB0aGUgTEIgY29uc3RyYWludHMgYWJv dmU6DQo+Pj5kZWNpZGluZw0KPj4+IHdoaWNoIGxvY2F0b3IgdG8gdXNlIGZvciBhIGdpdmVuIGZs b3cgd2lsbCBiZSBhIGxvY2FsIGRlY2lzaW9uIG5vdCBhDQo+Pj4gY2VudHJhbGl6ZWQgb25lLg0K Pj4NCj4+QWJzb2x1dGVseS4gSSBjYW5ub3QgaW1hZ2luZSBob3cgZWxzZSBpdCBjYW4gYmUgZG9u ZS4NCj4+DQo+Pk1hcmlhDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Thu Jul 10 00:05: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 6DCAF1A0B17 for ; Thu, 10 Jul 2014 00:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_29=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 h688atxjkZCk for ; Thu, 10 Jul 2014 00:05:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CBC1A035C for ; Thu, 10 Jul 2014 00:05:50 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 91F6BC00AA; Thu, 10 Jul 2014 09:05:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 6F2B9C8080; Thu, 10 Jul 2014 09:05:48 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 09:05:48 +0200 From: To: "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPm7C2xKjmuDn4BEiFVdMuQoKu35uY4UOw Date: Thu, 10 Jul 2014 07:05:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933002FF98OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.9.34819 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/624GlK0iQMfwaNtMVAPmNohQncw Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 07:05:53 -0000 --_000_787AE7BB302AE849A7480A190F8B933002FF98OPEXCLILM23corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBw YXRoIGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8gZGVyaXZl IGZvcndhcmRpbmcgYWN0aW9ucy4NCg0KUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRo ZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBhdmFpbGFibGUgU0ZDIGZvcndhcmRpbmcgcGF0aHMg d2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5v ciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQoNClNGQyBmb3J3YXJk aW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mIGluZm9ybWF0aW9uIHRoYXQg d2lsbCBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lIHJlcXVp cmVkIHRvIHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlz IHVzZWQgdG8gaW5mZXIgZm9yd2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3JpZW50ZWQg ZGlzY3Vzc2lvbi4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgbWlrZWJpYW5jQGFvbC5jb20NCkVudm95w6kgOiBt ZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMw0Kw4AgOiBqbWhAam9lbGhhbHBlcm4uY29tOyBz ZmNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQoNCklzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIFNGIENoYWluIGFuZCBTRiBQYXRoPyAgT3RoZXIgdGhhbiBjbGFyaWZ5aW5n IHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxpYXIg d2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uIHRoZXNlIHRl cm1zLg0KDQpUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hl dGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5 IHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVhZGVyIHNob3VsZCByZWZlcmVuY2UgKHRoZSBjaGFp biBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5IGludGVuZHMgdG8gbGVhdmUg dGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyIGRyYWZ0cyB0byBkaWN0YXRlIHRoZSBtZWNo YW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluIG9yIHBhdGggYW5kIHRoZSBjaG9p Y2Ugb2YgY2hhaW4gb3IgcGF0aCB0byBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5l Lg0KDQpJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZl IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZSBvbmUg cmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZSB2ZW5kb3JzIG9u bHkgc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogam1oQGpvZWxoYWxwZXJu LmNvbTxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbT4+DQpUbzogc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bHkgOCwgMjAx NA0KU3ViamVjdDogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5z d2VyIGEgbnVtYmVyIG9mDQpjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZSBw cm9wb3NlZCBtZXJnZWQgYXJjaHRpZWN0dXJlDQpkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3 b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZQ0Kd2lsbCB3b3JrIHRvIGlt cHJvdmUgdGhlIHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdA0KcGFydGljaXBh dGVkIGluIHRoZSBXRyBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdv cmtpbmcNCmdyb3VwIGludGVuZHMuDQoNCkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRy eSB0byBleHBsYWluIG15IHBlcnNvbmFsIHZpZXcsIGFuZCBzZWUNCmlmIHRoYXQgaGVscHMuDQoN CkluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hh dCB3ZSBhcmUNCmRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJl IG5vdCBhdHRlbXB0aW5nIHRvDQpkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGly ZSBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4NClRoYXQgd291bGQgZW5jb21wYXNzIE9T Uy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCnZpcnR1YWwgbWFj aGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIgYXNwZWN0cy4NCg0KQXMg YSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0byBleGlz dCBpbiB0aGUNCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3 aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsDQphbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBi eSB0aGUgd29yayB3ZSBhcmUgZG9pbmcuDQoNCkluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNo YWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0YW5kIHRoZW0sDQpJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlDQpkaWZm ZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbCBpbnRlcmFjdCB3aXRo IHNlcnZpY2UNCmNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS4gVGhlIHBvaW50IG9m IHRoZSBhcmNodGllY3R1cmUgaXMgdG8NCnBlcm1pdCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8g bWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQgYmUgdXNlZA0KaW4gYW55IHNvbHV0aW9u Lg0KDQoxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1 c2VyLiBUaGlzIGlzIGENCnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0 cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzDQp0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNo b29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlIGluc3RhbmNlIHRvIHJlY2VpdmUNCnRoZSB1c2VycyBw YWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50IHNlcnZpY2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0 bw0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2aW9yIG1heSBhZmZlY3Qg cmVxdWlyZW1lbnRzIG9uDQpob3cgc2VydmljZSBjaGFpbmluZyBpcyBkb25lLiBCdXQgaXQgaGFz IHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCmFyY2h0aWVjdHVyZS4gRnJvbSBhbiBhcmNoaXRl Y3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYSBzZXJ2aWNlDQpmdW5jdGlvbiB3aGlj aCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCg0KMikgVGhlcmUgaXMgaW50ZXJu YWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZSB3aGF0IGFwcGVhcnMNCnRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZiBj b250YWN0IGZvciBhDQpzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkg ZGVsaXZlcmVkIGJ5IGEgY29sbGVjdGlvbiBvZg0KdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5l cywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvciBzZXZlcmFsIGxvYWQNCmJhbGFuY2VycyAoZm9y IGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlIHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMNCmFkZHJl c3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRh dGEgcGxhbmUNCm1lY2hhbmlzbXMuIEl0IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8g dmFyaW91cyBjb250cm9sDQptZWNoYW5pc21zLCBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZv ciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBhbmQgdm0NCmluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRl Y3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2VseQ0KdGhhdCB3ZSBuZWVk IHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVybWlub2xvZ3kgZG9lcyBub3QgbGVhZCByZWFkZXJz IHRvDQp0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQoNCjMpIFRoZXJlIGNhbiBhbHNvIGJl IGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgc2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3INCnRoZSBz ZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMgdG8gZGlmZmVyZW50IHBsYWNlcy4g V2Ugd291bGQNCm5vdCB3YW50IHRvIHJlcXVpcmUgdGhhdCBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rp b24gYXBwZWFyIGF0IG9ubHkgb25lDQpwbGFjZSBpbiB0aGUgbmV0d29yay4NCg0KSXQgaXMgb2Yg Y291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQgdG8gcmVm ZXIgdG8NCnRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2Ug Y2hhaW5pbmcgYXMgYSBzaW5nbGUNCnBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1 c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSQ0KZG8gbm90IGhhdmUgYW5vdGhlciBv bmUuIFRodXMsIHRoZSBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcgaXMgdG8NCmRpcmVj dCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudCBzaW5ndWxhciBvciBj bHVzdGVyZWQNCnNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5l dHdvcmsuDQoNCk5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsg YWJvdXQgc2VydmljZSBjaGFpbiBhbmQNCnNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBh IHNlcXVlbmNlIG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlDQphcHBsaWVkIHRvIGEgc3Vic2V0 IG9mIHBhY2tldHMuIEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZQ0Kc3Vic2V0 IG9mIHRyYWZmaWMgaXMgdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwg YW5kDQpmaXJld2FsbCB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkg dG8gdGhlIGNhY2hlIHdpdGhvdXQNCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9u cy4NCg0KVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0 cy4gQSBzZXJ2aWNlIHBhdGgNCmlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9j YXRpb25zIGluIHRoZSBuZXR3b3JrLiBUaG9zZQ0KbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIg b3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkNCmxvY2F0aW9ucy4gVGhleSBt YXkgYmUgYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZA0KYXMg cG9ydHMgb24gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBs b2NhdGlvbnMNCm1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVj dHVyZSBhbmQgdGhlIHRyYW5zcG9ydC4NCg0KRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUg d29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRvIGJlIGFibGUNCnRvIHRhbGsgYWJvdXQg dGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlIGNoYWluLCB3aGljaA0KZHJp dmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwg ZGF0YSBwYXRoDQpwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay4NCg0KU2V2ZXJhbCBv ZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGggbWF5IG5vdCBiZSBr bm93bg0KYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aCB0aGF0IGlz c3VlIGluIHR3byB3YXlzLg0KRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFs YW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUNCmRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNo IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcNCm1lY2hhbmlzbXMgKGluIG11 Y2ggdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkNCmlu dmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2Ug bWFrZSBpcyB0aGF0DQpyZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3 aGVuIG5lY2Vzc2FyeS4gVGhhdCB3aWxsDQpkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4g QmFzZWQgb24gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZQ0KcmUtY2xhc3NpZmljYXRpb24g cG9pbnQuDQoNCkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRl ci4gSWYgaXQgZG9lcywgYW5kIGlmDQp0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdv cmtpbmcgZ3JvdXAsIHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQNCmFkZGl0aW9uYWwgd29yZHMgYXJl IG5lZWRlZCB0byBjb252ZXkgdGhpcy4NCklmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdp dGggdGhlIGludGVudCwgdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZQ0KYWRqdXN0IHRvIG1hdGNoIHRo ZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuDQpJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkg YW0gbm90IHN1cmUgd2hhdCB0byB0cnkgbmV4dC4NCg0KWW91cnMsDQpKb2VsDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_787AE7BB302AE849A7480A190F8B933002FF98OPEXCLILM23corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28t c3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBtZXJnZWQg ZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSBv YmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUgZm9yd2FyZGluZyBhY3Rpb25z Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0 byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBhdmFpbGFibGUgU0ZDIGZvcndhcmRp bmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVz dGlmaWVkIG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzDQogZGVwbG95bWVudCBjb250ZXh0cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5TRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCBy ZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmUgcHJlc2VudCBpbiBh bGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUgYSBz ZXJ2aWNlIGNoYWluLiBIb3cgdGhhdA0KIGluZm9ybWF0aW9uIGlzIHVzZWQgdG8gaW5mZXIgZm9y d2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBtaWtlYmlhbmNAYW9sLmNvbTxi cj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMzxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gam1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnPGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXMgYW55b25lIHN0aWxs IHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU0YgQ2hhaW4gYW5kIFNGIFBhdGg/ ICZuYnNwO090aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3Mg Y2xlYXIgdG8gdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcw0KIHRo YXQgZXZlcnlvbmUgYWdyZWVzIG9uIHRoZXNlIHRlcm1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvIG1lLCB0aGUgb25l IHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcyB3aGV0aGVyIGl0IGlzIHRoZSBpbnRlbnQg b2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUgSUQgb2YgdGhlIFNG QyBIZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZQ0KIHBhdGgpLCBvciBp ZiB0aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxv d2luZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGlu ZyBiYXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yIHBhdGgg dG8gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4gJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYg dGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2ZSByZXF1aXJl IHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2Ugb25lIHJlcXVpcmVk IGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUgdmVuZG9ycyBvbmx5IHN1cHBv cnRpbmcNCiBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ni43NXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9z aGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+RnJvbTog PC9iPjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJu LmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8 YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwv Yj5UdWVzZGF5LCBKdWx5IDgsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpJIGhhdmUgYmVl biB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2Yg PGJyPg0KY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVy Z2VkIGFyY2h0aWVjdHVyZSA8YnI+DQpkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5n IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSA8YnI+DQp3aWxsIHdvcmsgdG8gaW1w cm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IDxicj4NCnBhcnRp Y2lwYXRlZCBpbiB0aGUgV0cgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRo ZSB3b3JraW5nIDxicj4NCmdyb3VwIGludGVuZHMuPGJyPg0KPGJyPg0KQnV0IHdoYXQgZG8gd2Ug aW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZSA8 YnI+DQppZiB0aGF0IGhlbHBzLjxicj4NCjxicj4NCkluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBv cnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmUgPGJyPg0KZGVmaW5pbmcgaXMg dGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRpbmcgdG8gPGJy Pg0KZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRpb24gZm9yIHNl cnZpY2UgY2hhaW5pbmcuIDxicj4NClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlv dXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgPGJyPg0KdmlydHVhbCBtYWNoaW5lIGFu ZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLjxicj4NCjxicj4NCkFz IGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhp c3QgaW4gdGhlIDxicj4NCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBh Ym92ZSB3aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsIDxicj4NCmFuZCBhcmUgbm90IGRpcmVjdGx5 IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnI+DQo8YnI+DQpJbiBvcmRlciB0 byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJzdGFuZCB0 aGVtLCA8YnI+DQpJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUg YXJlIGF0IGxlYXN0IHRocmVlIDxicj4NCmRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNp bmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZSA8YnI+DQpjaGFpbmluZy4gVGhl cmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRv IDxicj4NCnBlcm1pdCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBw YXJ0aWN1bGFyIGtpbmQgYmUgdXNlZCA8YnI+DQppbiBhbnkgc29sdXRpb24uPGJyPg0KPGJyPg0K MSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4g VGhpcyBpcyBhIDxicj4NCnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0 cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzIDxicj4NCnRoZW0sIG9yIC4uLikgc28gYXMg dG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZSA8YnI+DQp0 aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRv IGJlIGFibGUgdG8gPGJyPg0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2 aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIDxicj4NCmhvdyBzZXJ2aWNlIGNoYWluaW5n IGlzIGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSA8YnI+DQphcmNo dGllY3R1cmUuIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5 IGEgc2VydmljZSA8YnI+DQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5n IHBhY2tldC48YnI+DQo8YnI+DQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4g VGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFycyA8YnI+DQp0byB0aGUgc2VydmljZSBj aGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YgY29udGFjdCBmb3IgYSA8 YnI+DQpzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVk IGJ5IGEgY29sbGVjdGlvbiBvZiA8YnI+DQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBw b3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZCA8YnI+DQpiYWxhbmNlcnMgKGZv ciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIDxicj4N CmFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIGRhdGEgcGxhbmUgPGJyPg0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQgaXQgaXMg dmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wgPGJyPg0KbWVjaGFuaXNtcywgc3VjaCBhcyB0aG9z ZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtIDxicj4NCmluc3Rh bnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMg bGFyZ2VseSA8YnI+DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5v bG9neSBkb2VzIG5vdCBsZWFkIHJlYWRlcnMgdG8gPGJyPg0KdGhpbmsgd2UgYXJlIHByb2hpYml0 aW5nIGl0Ljxicj4NCjxicj4NCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRv bmUgYnkgc2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3IgPGJyPg0KdGhlIHNlcnZpY2UgY2hhaW5p bmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCA8YnI+ DQpub3Qgd2FudCB0byByZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVh ciBhdCBvbmx5IG9uZSA8YnI+DQpwbGFjZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpJdCBp cyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZCB0 byByZWZlciB0byA8YnI+DQp0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0 byBzZXJ2aWNlIGNoYWluaW5nIGFzIGEgc2luZ2xlIDxicj4NCnBvaW50IGFzIGEgY2x1c3Rlci4g Tm90IGJlY2F1c2UgY2x1c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSA8YnI+DQpk byBub3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJh bGFuY2luZyBpcyB0byA8YnI+DQpkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0 byBkaWZmZXJlbnQgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIDxicj4NCnNlcnZpY2UgZnVuY3Rpb25z IGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KTm93IHdpdGgg dGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWlu IGFuZCA8YnI+DQpzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZSBvZiBs b2dpY2FsIGZ1bmN0aW9ucyB0byBiZSA8YnI+DQphcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tl dHMuIEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSA8YnI+DQpzdWJzZXQgb2Yg dHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQg PGJyPg0KZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5 IHRvIHRoZSBjYWNoZSB3aXRob3V0IDxicj4NCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1 bmN0aW9ucy48YnI+DQo8YnI+DQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGly ZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZpY2UgcGF0aCA8YnI+DQppcywgaW4gc29tZSBmYXNoaW9u LCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yay4gVGhvc2UgPGJyPg0KbG9j YXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVs aXZlcnkgPGJyPg0KbG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVz cy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIDxicj4NCmFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUg YXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zIDxicj4NCm1heSBiZSBr bm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIHRyYW5z cG9ydC48YnI+DQo8YnI+DQpGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJsZSA8YnI+DQp0byB0YWxrIGFib3V0IHRoZSBo aWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggPGJyPg0KZHJp dmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwg ZGF0YSBwYXRoIDxicj4NCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxi cj4NClNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdob2xl IHBhdGggbWF5IG5vdCBiZSBrbm93biA8YnI+DQphdCB0aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJj aGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gPGJyPg0KRmlyc3Qs IGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4g YmUgPGJyPg0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0 aGUgc2VydmljZSBjaGFpbmluZyA8YnI+DQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBzYW1lIHdh eSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5IDxicj4NCmludmlzaWJsZSB0 byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0 aGF0IDxicj4NCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4g bmVjZXNzYXJ5LiBUaGF0IHdpbGwgPGJyPg0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4u IEJhc2VkIG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgPGJyPg0KcmUtY2xhc3NpZmlj YXRpb24gcG9pbnQuPGJyPg0KPGJyPg0KSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdo YXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYgPGJyPg0KdGhlIGludGVudCBpcyBh Y2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IDxi cj4NCmFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy48YnI+DQpJZiB0 aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBv ZiBjb3Vyc2UgPGJyPg0KYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVu dHMuPGJyPg0KSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8g dHJ5IG5leHQuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933002FF98OPEXCLILM23corpor_-- From nobody Thu Jul 10 04:16: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 C66FE1B2883 for ; Thu, 10 Jul 2014 04:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 sAPL0vZ4y1wn for ; Thu, 10 Jul 2014 04:16:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F6A1B2884 for ; Thu, 10 Jul 2014 04:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16333; q=dns/txt; s=iport; t=1404990969; x=1406200569; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bZxa+wqFPFKjSnb54+KBaxeUo78rgOe0cXcEx4CAKno=; b=NMtNdr0dApiEaGgKiGNKwSTgMHy2K00qqT1Or0uALvLhYedj8CKgUjla +6SedXAexgl/SGWMKGprl5T/XHTN0oE+HoBsoUPedZ77fUcvnMg6ym/VG cHshPzhFqE/UgNyLUJMjFP2P2KtVEr/yN7W7ve6PWUSuQ9RLoI+sVQ/3M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABF1vlOtJV2S/2dsb2JhbABZgw5SWq5qkDgBCYdCAYEKFnWEAwEBAQQBAQFiCQsQAgEIEQEDAQEoBycLFAMGCAIEDgUbiBMDEQ3HchMEjRmCJwQGAYMtgRYFliBGhBqLY4gyg0OCMA X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208,217";a="339020134" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jul 2014 11:16:08 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6ABG3JH026570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 11:16:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 06:16:02 -0500 From: "Paul Quinn (paulq)" To: "mikebianc@aol.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuYfwEAgAD/XgA= Date: Thu, 10 Jul 2014 11:16:02 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: multipart/alternative; boundary="_000_EB80B38450214DC9B30CF407FF29C889ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BfFIVZiPcmRkVEj-Uxr4O23niFA Cc: "jmh@joelhalpern.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 11:16:08 -0000 --_000_EB80B38450214DC9B30CF407FF29C889ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 9, 2014, at 4:02 PM, mikebianc@aol.com wro= te: Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. Ultimately, somewhere, the chain must be resolved into a path and that path= must be identified for dataplane forwarding. Whether this resolution occu= rs locally, or not is an implementation choice. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_EB80B38450214DC9B30CF407FF29C889ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <90B8447253B8FE489946A5A2AE2F069E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Jul 9, 2014, at 4:02 PM, mikeb= ianc@aol.com wrote:

Is anyone still questioning the difference between SF Chain and SF Pat= h?  Other than clarifying the definition so that it's clear to those n= ot familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent= of this draft to ultimately specify what the ID of the SFC Header should r= eference (the chain or the path), or if this draft simply intends to leave = that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the ch= oice of chain or path to be negotiated in the control-plane.  

If the latter (ambiguous), then the draft would have require that both= SFP and SFC be supported (or make one required and the other optional) to = avoid some vendors only supporting SFP and others only supporting SFC.


Ultimately, somewhere, the chain must be resolved into a path and that= path must be identified for dataplane forwarding.  Whether this resol= ution occurs locally, or not is an implementation choice.



From: jmh@joelhalpern.com= <jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

--_000_EB80B38450214DC9B30CF407FF29C889ciscocom_-- From nobody Thu Jul 10 05:51: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 4B5391B28DA for ; Thu, 10 Jul 2014 05:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8D_ulE375-bG for ; Thu, 10 Jul 2014 05:50:59 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA32F1B28D3 for ; Thu, 10 Jul 2014 05:50:58 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 3CD3653E1D; Thu, 10 Jul 2014 05:49:10 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 05:49:10.216 -0700 x-echoworx-msg-id: 2d80878b-ffd3-4d80-9f5e-193cf36ae924 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 111; Thu, 10 Jul 2014 05:49:10 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 1F3C853E1D; Thu, 10 Jul 2014 05:49:10 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 05:50:58 -0700 From: Ron Parker To: Sharon , "Joel M. Halpern" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAyQAIAAjrDg Date: Thu, 10 Jul 2014 12:50:56 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <57E76B09-5982-40F0-992C-8C5604CC260C@gmail.com> In-Reply-To: <57E76B09-5982-40F0-992C-8C5604CC260C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1-OS4Oxx3ehEUnUMFGGbO2hDmsU Cc: "mohamed.boucadair@orange.com" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 12:51:01 -0000 Sharon, I agree with your point. Let's all be clear -- service function chaining = already exists. The charter of this WG is to improve upon it. Those imp= rovements are along the lines of simplicity, efficiency, scale, flexibility= , and last but not least availability. The architecture should allow for, but not require, discrete service funct= ion load balancer functions. If the existence of a service function load = balancer is an explicit and optional aspect of the architecture, it should = be identified as such. With or without service function load balancers, t= he architecture should explicitly account for any points of failure without= making simplifying assumptions like involved nodes are on the same L3 subn= et or on the same L2 domain. How specific (constraining) the architecture= needs to be wrt these failure domains is for further study, but the archit= ecture should call out the overall system behavior in the event of these in= evitable failures. All of this factors heavily into the centralized vs d= istributed aspects of the solution and the eventual control plane requireme= nts, if any. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sharon Sent: Wednesday, July 09, 2014 5:11 PM To: Joel M. Halpern Cc: mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers If we translate the draft standards literally to products this way we will = end up chaining a bunch of load balancers, that's it. These will in-turn need to figure what function to chain for this punt. Tha= t's not enough progress in most cases over stitching load balancers with vl= ans. Perhaps we need to draft an informational on how to build one distribu= ted - interoperable load balancer using the SFC spec ? --szb > On Jul 9, 2014, at 1:26 PM, "Joel M. Halpern" wrote= : >=20 > I am saying that if the 20 virtual firewalls are deployed separately, the= n the service chaining infrastructure would treat them as such, and would u= se distinct service paths. > Alternative, if you as the operator choose to deploy them as a cluster, w= ith sutiable load balancing, such that they appear as a single place for se= rvice chaining, then there would be one service path. >=20 > And the operator could choose a hybrid, for exanmple, deploying two clust= ers of 10 each, requiring two service paths. >=20 > Typically, different clusters would be used to provide geographic diversi= ty or because there was a policy reason to distinguish them. While clusters= would typically be used to allow the scale-in and scale-out to occur witho= ut affecting service chaining. >=20 > The architecture is structured to allow this range. >=20 > Yours, > Joel >=20 >> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >> I had in mind singular instances, say, 20 virtual firewall instances som= ewhere in the middle of a chain. Are you saying that you will decide (make = a load balancing decision) at the entry to the chain which of those 20 fire= walls will be used by a particular flow? >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern=20 >>> Direct >>> Sent: Wednesday, July 09, 2014 3:41 PM >>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> The archtiecture allows for this local decision, while still having=20 >>> the global decision that is directing the traffic. That is, the=20 >>> global decision directs the traffic to places in the network. Those=20 >>> places may be singular or clusters. If they are clusters, those=20 >>> clusters can use any number of algorithms to distribute the traffic=20 >>> internally, without any effect on service chaining. (And yes, this=20 >>> can be done in such a way that return traffic, if delivered globally=20 >>> to the same place, can then be delivered to the right internal=20 >>> state.) >>>=20 >>> The definition of the service path is about how service chaining=20 >>> will direct the traffic. it is not about how the internal load=20 >>> balancing is doen, as there are MANY ways to do that, and they can=20 >>> give the same external interface. >>>=20 >>> We could write the architecture pretending that it always addresses=20 >>> singular instances, but knowing that reality would allow load=20 >>> balanced clusters at those locations. But that would be a=20 >>> misleading architectural description and might be read to outlaw=20 >>> some solutions that fall within the goal the WG wishes to meet. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>> [Med] I still disagree that an ordered list of locators can be=20 >>>>> determined >>> in >>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>> based on >>> the >>>>> service chain itself (characterized as an order list of service=20 >>>>> function identifiers). This is more compliant with the LB constraints= above: >>> deciding >>>>> which locator to use for a given flow will be a local decision not=20 >>>>> a centralized one. >>>>=20 >>>> Absolutely. I cannot imagine how else it can be done. >>>>=20 >>>> Maria >>>=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 nobody Thu Jul 10 06:34: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 C49DB1B28FA for ; Thu, 10 Jul 2014 06:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 G-_afmRGlHeN for ; Thu, 10 Jul 2014 06:34:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8CB1A03B3 for ; Thu, 10 Jul 2014 06:34:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV28448; Thu, 10 Jul 2014 13:34:28 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 14:34:27 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 06:34:24 -0700 From: Lucy yong To: "Paul Quinn (paulq)" , "mikebianc@aol.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYoIgAgAD/PQD//69y4A== Date: Thu, 10 Jul 2014 13:34:23 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BE1BA@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.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: [10.47.146.67] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453BE1BAdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/R6RhoQZB0IFYK-9d4mk-DXA5MVM Cc: "jmh@joelhalpern.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 13:34:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453BE1BAdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Current definition is clear to me from architecture perspective. If some pr= oduct only supports SFP or SFC, it is clearly that another product is neede= d to support both SFP and SFC to make them work together. Architecture doc= . should not make any constraint on it. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 6:16 AM To: mikebianc@aol.com Cc: jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers On Jul 9, 2014, at 4:02 PM, mikebianc@aol.com wro= te: Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. Ultimately, somewhere, the chain must be resolved into a path and that path= must be identified for dataplane forwarding. Whether this resolution occu= rs locally, or not is an implementation choice. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_2691CE0099834E4A9C5044EEC662BB9D453BE1BAdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Current definition is cle= ar to me from architecture perspective. If some product only supports SFP o= r SFC, it is clearly that another product is needed to support both SFP and SFC to make them work together.  Architecture doc. shoul= d not make any constraint on it.

 <= /p>

Lucy

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 6:16 AM
To: mikebianc@aol.com
Cc: jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

 

On Jul 9, 2014, at 4:02 PM, mikebianc@aol.com wrote:



Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

Ultimately, somewhere, the chain must be resolved in= to a path and that path must be identified for dataplane forwarding.  = Whether this resolution occurs locally, or not is an implementation choice.=

 



 



From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

 

--_000_2691CE0099834E4A9C5044EEC662BB9D453BE1BAdfweml701chmchi_-- From nobody Thu Jul 10 06:57: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 36FE71A053B for ; Thu, 10 Jul 2014 06:57:47 -0700 (PDT) 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 vwVS9Es7iUyP for ; Thu, 10 Jul 2014 06:57:44 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCED1A0502 for ; Thu, 10 Jul 2014 06:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 9111E1C97871; Thu, 10 Jul 2014 06:57:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 2EA041C97873; Thu, 10 Jul 2014 06:57:43 -0700 (PDT) Message-ID: <53BE9BD6.6090507@joelhalpern.com> Date: Thu, 10 Jul 2014 09:57:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker , Sharon References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <57E76B09-5982-40F0-992C-8C5604CC260C@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mvI39dVBjMOL4g3zTjGwPAL5L8g Cc: "mohamed.boucadair@orange.com" , "NAPIERALA, MARIA H" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 13:57:47 -0000 I am happy to add text to the architecture pointing out failure points where the solutions must provide suitable robustness. That seems to be architectural in nature, valuable to the working group, and accurate. Where I get concerned is if the request is to describe in teh architecture how robustness and failover will be done. There are many alternatives. Some probably just won't work. Some will likely fall outside the solutions the WG adopts. And many others will interoperate and work with the solution(s) the working group adopts. So I would ask folks, and particularly Sharon and Ron, what level of specificity they feel belongs in this document. Yours, Joel On 7/10/14, 8:50 AM, Ron Parker wrote: > Sharon, > > I agree with your point. Let's all be clear -- service function > chaining already exists. The charter of this WG is to improve upon > it. Those improvements are along the lines of simplicity, > efficiency, scale, flexibility, and last but not least availability. > > The architecture should allow for, but not require, discrete service > function load balancer functions. If the existence of a service > function load balancer is an explicit and optional aspect of the > architecture, it should be identified as such. With or without > service function load balancers, the architecture should explicitly > account for any points of failure without making simplifying > assumptions like involved nodes are on the same L3 subnet or on the > same L2 domain. How specific (constraining) the architecture needs > to be wrt these failure domains is for further study, but the > architecture should call out the overall system behavior in the event > of these inevitable failures. All of this factors heavily into the > centralized vs distributed aspects of the solution and the eventual > control plane requirements, if any. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Sharon Sent: Wednesday, July 09, 2014 5:11 PM To: Joel M. > Halpern Cc: mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA, > MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > If we translate the draft standards literally to products this way we > will end up chaining a bunch of load balancers, that's it. These will > in-turn need to figure what function to chain for this punt. That's > not enough progress in most cases over stitching load balancers with > vlans. Perhaps we need to draft an informational on how to build one > distributed - interoperable load balancer using the SFC spec ? > > --szb > >> On Jul 9, 2014, at 1:26 PM, "Joel M. Halpern" >> wrote: >> >> I am saying that if the 20 virtual firewalls are deployed >> separately, then the service chaining infrastructure would treat >> them as such, and would use distinct service paths. Alternative, if >> you as the operator choose to deploy them as a cluster, with >> sutiable load balancing, such that they appear as a single place >> for service chaining, then there would be one service path. >> >> And the operator could choose a hybrid, for exanmple, deploying two >> clusters of 10 each, requiring two service paths. >> >> Typically, different clusters would be used to provide geographic >> diversity or because there was a policy reason to distinguish them. >> While clusters would typically be used to allow the scale-in and >> scale-out to occur without affecting service chaining. >> >> The architecture is structured to allow this range. >> >> Yours, Joel >> >>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: I had in mind >>> singular instances, say, 20 virtual firewall instances somewhere >>> in the middle of a chain. Are you saying that you will decide >>> (make a load balancing decision) at the entry to the chain which >>> of those 20 firewalls will be used by a particular flow? >>> >>> Maria >>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >>>> Sent: Wednesday, July 09, 2014 3:41 PM To: NAPIERALA, MARIA H; >>>> mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] >>>> Service Chains, Paths, and Load Balancers >>>> >>>> The archtiecture allows for this local decision, while still >>>> having the global decision that is directing the traffic. That >>>> is, the global decision directs the traffic to places in the >>>> network. Those places may be singular or clusters. If they >>>> are clusters, those clusters can use any number of algorithms >>>> to distribute the traffic internally, without any effect on >>>> service chaining. (And yes, this can be done in such a way >>>> that return traffic, if delivered globally to the same place, >>>> can then be delivered to the right internal state.) >>>> >>>> The definition of the service path is about how service >>>> chaining will direct the traffic. it is not about how the >>>> internal load balancing is doen, as there are MANY ways to do >>>> that, and they can give the same external interface. >>>> >>>> We could write the architecture pretending that it always >>>> addresses singular instances, but knowing that reality would >>>> allow load balanced clusters at those locations. But that >>>> would be a misleading architectural description and might be >>>> read to outlaw some solutions that fall within the goal the WG >>>> wishes to meet. >>>> >>>> Yours, Joel >>>> >>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>> [Med] I still disagree that an ordered list of locators can >>>>>> be determined >>>> in >>>>>> advance for all deployments. I suggest that SFC forwarding >>>>>> be based on >>>> the >>>>>> service chain itself (characterized as an order list of >>>>>> service function identifiers). This is more compliant with >>>>>> the LB constraints above: >>>> deciding >>>>>> which locator to use for a given flow will be a local >>>>>> decision not a centralized one. >>>>> >>>>> Absolutely. I cannot imagine how else it can be done. >>>>> >>>>> Maria >>>> >>>> _______________________________________________ sfc mailing >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ sfc mailing 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 Jul 10 07:02: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 E91671B2903 for ; Thu, 10 Jul 2014 07:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Aezo9hp3kgFc for ; Thu, 10 Jul 2014 07:02:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58981B290C for ; Thu, 10 Jul 2014 07:02:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGZ43469; Thu, 10 Jul 2014 14:02:05 +0000 (GMT) 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, 10 Jul 2014 15:02:04 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 07:01:59 -0700 From: Lucy yong To: "Joel M. Halpern" , Ron Parker , Sharon Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuXx0EAgACul/aAAAVvmIABPwEAgAASqAD//4wz4A== Date: Thu, 10 Jul 2014 14:01:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BE202@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <57E76B09-5982-40F0-992C-8C5604CC260C@gmail.com> <53BE9BD6.6090507@joelhalpern.com> In-Reply-To: <53BE9BD6.6090507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/khNYUCT830AYg_0JZBoLbI5gC-M Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 14:02:17 -0000 I am happy to add text to the architecture pointing out failure points wher= e the solutions must provide suitable robustness. That seems to be archite= ctural in nature, valuable to the working group, and accurate. [Lucy] agree. Where I get concerned is if the request is to describe in teh architecture = how robustness and failover will be done. There are many alternatives. So= me probably just won't work. Some will likely fall outside the solutions t= he WG adopts. And many others will interoperate and work with the solution= (s) the working group adopts. [Lucy] Agree too. So the arch doc should not describe implementation choice= and judge which works and which not. Lucy So I would ask folks, and particularly Sharon and Ron, what level of specif= icity they feel belongs in this document. Yours, Joel On 7/10/14, 8:50 AM, Ron Parker wrote: > Sharon, > > I agree with your point. Let's all be clear -- service function > chaining already exists. The charter of this WG is to improve upon > it. Those improvements are along the lines of simplicity, > efficiency, scale, flexibility, and last but not least availability. > > The architecture should allow for, but not require, discrete service > function load balancer functions. If the existence of a service > function load balancer is an explicit and optional aspect of the > architecture, it should be identified as such. With or without > service function load balancers, the architecture should explicitly=20 > account for any points of failure without making simplifying=20 > assumptions like involved nodes are on the same L3 subnet or on the > same L2 domain. How specific (constraining) the architecture needs > to be wrt these failure domains is for further study, but the=20 > architecture should call out the overall system behavior in the event > of these inevitable failures. All of this factors heavily into the > centralized vs distributed aspects of the solution and the eventual=20 > control plane requirements, if any. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Sharon Sent: Wednesday, July 09, 2014 5:11 PM To: Joel M. > Halpern Cc: mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA,=20 > MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > If we translate the draft standards literally to products this way we=20 > will end up chaining a bunch of load balancers, that's it. These will=20 > in-turn need to figure what function to chain for this punt. That's=20 > not enough progress in most cases over stitching load balancers with=20 > vlans. Perhaps we need to draft an informational on how to build one=20 > distributed - interoperable load balancer using the SFC spec ? > > --szb > >> On Jul 9, 2014, at 1:26 PM, "Joel M. Halpern" >> wrote: >> >> I am saying that if the 20 virtual firewalls are deployed separately,=20 >> then the service chaining infrastructure would treat them as such,=20 >> and would use distinct service paths. Alternative, if you as the=20 >> operator choose to deploy them as a cluster, with sutiable load=20 >> balancing, such that they appear as a single place for service=20 >> chaining, then there would be one service path. >> >> And the operator could choose a hybrid, for exanmple, deploying two=20 >> clusters of 10 each, requiring two service paths. >> >> Typically, different clusters would be used to provide geographic=20 >> diversity or because there was a policy reason to distinguish them. >> While clusters would typically be used to allow the scale-in and=20 >> scale-out to occur without affecting service chaining. >> >> The architecture is structured to allow this range. >> >> Yours, Joel >> >>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: I had in mind singular=20 >>> instances, say, 20 virtual firewall instances somewhere in the=20 >>> middle of a chain. Are you saying that you will decide (make a load=20 >>> balancing decision) at the entry to the chain which of those 20=20 >>> firewalls will be used by a particular flow? >>> >>> Maria >>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of Joel Halpern Direct >>>> Sent: Wednesday, July 09, 2014 3:41 PM To: NAPIERALA, MARIA H;=20 >>>> mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc]=20 >>>> Service Chains, Paths, and Load Balancers >>>> >>>> The archtiecture allows for this local decision, while still having=20 >>>> the global decision that is directing the traffic. That is, the=20 >>>> global decision directs the traffic to places in the network. =20 >>>> Those places may be singular or clusters. If they are clusters,=20 >>>> those clusters can use any number of algorithms to distribute the=20 >>>> traffic internally, without any effect on service chaining. (And=20 >>>> yes, this can be done in such a way that return traffic, if=20 >>>> delivered globally to the same place, can then be delivered to the=20 >>>> right internal state.) >>>> >>>> The definition of the service path is about how service chaining=20 >>>> will direct the traffic. it is not about how the internal load=20 >>>> balancing is doen, as there are MANY ways to do that, and they can=20 >>>> give the same external interface. >>>> >>>> We could write the architecture pretending that it always addresses=20 >>>> singular instances, but knowing that reality would allow load=20 >>>> balanced clusters at those locations. But that would be a=20 >>>> misleading architectural description and might be read to outlaw=20 >>>> some solutions that fall within the goal the WG wishes to meet. >>>> >>>> Yours, Joel >>>> >>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>> [Med] I still disagree that an ordered list of locators can be=20 >>>>>> determined >>>> in >>>>>> advance for all deployments. I suggest that SFC forwarding be=20 >>>>>> based on >>>> the >>>>>> service chain itself (characterized as an order list of service=20 >>>>>> function identifiers). This is more compliant with the LB=20 >>>>>> constraints above: >>>> deciding >>>>>> which locator to use for a given flow will be a local decision=20 >>>>>> not a centralized one. >>>>> >>>>> Absolutely. I cannot imagine how else it can be done. >>>>> >>>>> Maria >>>> >>>> _______________________________________________ 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 nobody Thu Jul 10 07:15: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 25BA61A05D1 for ; Thu, 10 Jul 2014 07:15:48 -0700 (PDT) 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 9l9KaLKCs229 for ; Thu, 10 Jul 2014 07:15:45 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754EA1B2906 for ; Thu, 10 Jul 2014 07:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 20B291C980A6; Thu, 10 Jul 2014 07:15:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id EC2AB1C980A1; Thu, 10 Jul 2014 07:15:41 -0700 (PDT) Message-ID: <53BEA00D.9030309@joelhalpern.com> Date: Thu, 10 Jul 2014 10:15:41 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sharon References: <53BCAB74.4060801@joelhalpern.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <53BDF58D.7070108@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XexHx6hjNVUziVf_CbZ4_cJuSoo Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , Ron Parker , "mohamed.boucadair@orange.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 14:15:48 -0000 There are things permitted by th architecture which would be a REALLY BAD IDEA in practice. As far as I can tell, all of the solutions people would like to use for this also have the property that there are ways to deploy them which would be REALLY BAD IDEAS. To take an extreme example, any architecture and any solution we define for service chaining will likely allow folks to expose a cominatorial explosion of instances if they insist in their deployment on moving all selection at all levels of granularity to whatever central point the solution has. Given that all solutions have some amount of central provisioning and control, all solutions allow such. I presume that none of them would mandate such. So observing that taken to an extreme and applied badly the archtiecture allows solutions with really bad properties will be true even when the wroking group finishes their work. Yours, Joel On 7/10/14, 1:32 AM, Sharon wrote: > > If I understand correctly, the dilemma is that > - on one hand there is no limit to what is meant by "load-balancing": > It may be a deep application content changing function, or a simple NAT of VIPs. > - On the other a static architecture is too rigid to scale and make highly available. > > It may lead to too much "hair splitting" . > To take it to extreme, in a distributed overlay network with SFFs scattered in enough locations, > but not in every host, a single service-function hop can be: > > SFF - NVE - NVE - SLB - NVE - NVE - NF - NVE - NVE - SFF > > If implemented literally the latency-jitter and consequently utilization will be quite bad. > > So a language that allows an SFF to work with balanced VNF pools, > and that allows for multi-home SFF to VNF pooling can help. > > > > --szb > >> On Jul 9, 2014, at 19:08, "Joel M. Halpern" wrote: >> >> THere are multiple ways that the internal redundancy with the load balancers can be implemented. Any of them can be used with the service chaining architecture. >> There may be some aspects which need to be covered in the solution work. >> For example, I would expect solutions to have to discuss how we cope with SFF failure. And with failure of the linkage between the SFF and the SF. >> >> We could add text to the architecture indicating that solutions will need to be robust in dealing with failures of service chaining components and linkages. But I think we should not spell out the detailed mechanisms for that robustness in this document. >> >> Would adding a small section on robustness issues help? >> >> Yours, >> Joel >> >>> On 7/9/14, 7:28 PM, Ron Parker wrote: >>> Ken, >>> >>> As I pointed out in my previous email, my concern is more about resiliency than elasticity. I understand the benefits of layered load balancing, but what about when this is hierarchical? Maria spoke of 20 instances, and the prevailing thinking seems to be that the top-level behavior of the SFC shouldn't care. But what if the front-end entity fails? What if its internal redundancy, if any, fails to perform when called upon? Might the network designer choose to divide the 20 instances into 2 groupings of 10 and have a front-end entity for each grouping? So now the top-level behavior of the SFC must choose amongst 2 rather than 20 for this particular logical service function. But a choice still needs to be made. Is this, too, outside the scope of SFC? If not, is the architecture going to explicitly address it, or leave it as an implementation issue? >>> >>> Ron >>> >>> >>> ________________________________________ >>> From: Ken Gray (kegray) [kegray@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:39 PM >>> To: Ron Parker; Jim Guichard (jguichar) >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> The whole idea of dynamic elasticity control is to hide this detail from >>> you and to make the instances ephemeral. >>> >>> When you send a packet from your classifier to my elastic firewall, the >>> component(s) that make it elastic are what you address Å  the elastic >>> control of my elastic firewall picks the instance based on it's own local >>> policy or higher level orchestration/policy control at an >>> out-of-scope-above-the-line-for-sfc layer. >>> >>> Yes, I can layer this abstraction to scale to a very, very large number of >>> instances and still present a single addressable point of distribution. >>> >>> The very scale problem you mention is what the scheme addresses, yet we >>> seem to be wanting to peel that away. >>> >>> As Jim stated, IF you want to separately address each instance (with >>> either the explosion of paths or the huge feedback loop from orchestration >>> and control, central micro-flow control, volume of changes to your >>> classifiers, etc.) - go for it. The architecture allows it. Has to. >>> Some people might deploy that way. >>> >>> The very basic point made in the original argument is "you don't have to >>> do that". >>> >>> This is readily demonstrable (I or a number of other vendors can send a >>> sales guy to do a demo). >>> >>> What I won't agree to here is that elasticity somehow creates an >>> unknowable path element. It shouldn't unless you did it wrong. Maybe >>> there's a better example that might justify substituting the chain for the >>> path (and then dynamically resolving this in the background adding huge >>> scale considerations) Å but it's not elasticity. >>> >>>> On 7/9/14 6:00 PM, "Ron Parker" wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say >>>> that this is a layered problem and that load balancing belongs at a lower >>>> level, it seems to me that load balancing of the service functions (not >>>> load balancer as a service function) should be an explicit consideration >>>> of the SFC architecture. I say this not only from a scale perspective, >>>> but also with resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>>>> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level between >>>>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>>>>> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the instances can >>>>>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW you >>>>>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>>>> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at each >>>>>>>> hop then you can choose to load balance among them locally >>>>>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>>>>> some very odd and certainly not recommended reason you want to >>>>>>>> treat each instance separately then the architecture does not >>>>>>>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would treat >>>>>>>>>> them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>>>>> then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? Well, we >>>>>>>> have yet to see a solution that work this way and scales.. >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you will >>>>>>>>>> decide (make a load balancing decision) at the entry to the chain >>>>>>>>>> which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>>>>> having the global decision that is directing the traffic. That >>>>>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>>>>> that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>>>>> would be a misleading architectural description and might be >>>>>>>>>>>> read to outlaw some solutions that fall within the goal the WG >>>>>>>>>>>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>>>>> be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be >>>>>>>>>>>>>> based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant with the >>>>>>>>>>>>>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing 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 Jul 10 07:20: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 29AFC1B2910 for ; Thu, 10 Jul 2014 07:20:49 -0700 (PDT) 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 vdmYMVSe0YcD for ; Thu, 10 Jul 2014 07:20:47 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8331B290A for ; Thu, 10 Jul 2014 07:20:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id C8F121C98197; Thu, 10 Jul 2014 07:20:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 95C5C1C98199; Thu, 10 Jul 2014 07:20:45 -0700 (PDT) Message-ID: <53BEA13C.5000206@joelhalpern.com> Date: Thu, 10 Jul 2014 10:20:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "NAPIERALA, MARIA H" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF1F@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002FF1F@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1gX2xQEfIEWfS27HIFv70ShBX3U Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 14:20:49 -0000 The question I was asekd was about the case with 20 virtual instances. The archtiecture allows for an arbitrary mixture of virtual and physical (and any other kind you care for) service function realizations. I have not assumed anything in particular about that. The architecture does not mandate how operators structure their service chains. It does not mandate how they deploy their services. You say that the key to forwarding is the service chain. But, as we have defined it in the document, the service chain does not have eough information for a packet forwarder to use it to forward. If you provision information in the network to use a service chain name of some kind to drive forwarding then you are creating a 1-1 relationship between the service chain identification and service path identification. The purpose of the separation is to allow for there to be multiple paths in the network for forwarding packets that are used to realize the service chains. The reason for calling out the service path identification in the packet is that if there are multiple such realizations, the packet forwarding needs information to be able to tell which such forwarding path this packet is using. Yours, Joel On 7/10/14, 2:28 AM, mohamed.boucadair@orange.com wrote: > Joel, > > I'm afraid you are making some deployment assumptions. > > How SF are deployed whether in separate physical nodes, as co-located > virtual instances, separated virtual instances, ...or a mix of those > is really deployment-specific. The point is that these SF instances > are offering the service, as such they must be considered as bound to > the same logical service (identified by a single service function > identifier). For a given chain, when invoking a given SF is required, > how the traffic will be directed to one of available SF instances is > also deployment-specific. It is up to the taste of each operator to > decide how to proceed. > > Furthermore, we should not mandate an operator how to structure its > chains. For example, we should not mandate that it must declare a > cluster as a SF. > > The key information needed to forward traffic is the service chain > itself (that is characterized as an order list of service function > identifiers). The forwarding path will be the result of policies > configured in a given SFC-enabled domain. > > Cheers, Med > >> -----Message d'origine----- De : Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Envoyé : mercredi 9 juillet 2014 >> 22:26 À : NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN; >> sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load >> Balancers >> >> I am saying that if the 20 virtual firewalls are deployed >> separately, then the service chaining infrastructure would treat >> them as such, and would use distinct service paths. Alternative, if >> you as the operator choose to deploy them as a cluster, with >> sutiable load balancing, such that they appear as a single place >> for service chaining, then there would be one service path. >> >> And the operator could choose a hybrid, for exanmple, deploying >> two clusters of 10 each, requiring two service paths. >> >> Typically, different clusters would be used to provide geographic >> diversity or because there was a policy reason to distinguish >> them. While clusters would typically be used to allow the scale-in >> and scale-out to occur without affecting service chaining. >> >> The architecture is structured to allow this range. >> >> Yours, Joel >> >> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>> I had in mind singular instances, say, 20 virtual firewall >>> instances >> somewhere in the middle of a chain. Are you saying that you will >> decide (make a load balancing decision) at the entry to the chain >> which of those 20 firewalls will be used by a particular flow? >>> >>> Maria >>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >>>> Sent: Wednesday, July 09, 2014 3:41 PM To: NAPIERALA, MARIA H; >>>> mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] >>>> Service Chains, Paths, and Load Balancers >>>> >>>> The archtiecture allows for this local decision, while still >>>> having the global decision that is directing the traffic. That >>>> is, the global decision directs the traffic to places in the >>>> network. Those places may be singular or clusters. If they >>>> are clusters, those clusters can use any number of algorithms >>>> to distribute the traffic internally, without any effect on >>>> service chaining. (And yes, this can be done in such a way >>>> that return traffic, if delivered globally to the same place, >>>> can then be delivered to the right internal state.) >>>> >>>> The definition of the service path is about how service >>>> chaining will direct the traffic. it is not about how the >>>> internal load balancing is doen, as there are MANY ways to do >>>> that, and they can give the same external interface. >>>> >>>> We could write the architecture pretending that it always >>>> addresses singular instances, but knowing that reality would >>>> allow load balanced clusters at those locations. But that >>>> would be a misleading architectural description and might be >>>> read to outlaw some solutions that fall within the goal the WG >>>> wishes to meet. >>>> >>>> Yours, Joel >>>> >>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>> [Med] I still disagree that an ordered list of locators can >>>>>> be >> determined >>>> in >>>>>> advance for all deployments. I suggest that SFC forwarding >>>>>> be based on >>>> the >>>>>> service chain itself (characterized as an order list of >>>>>> service >> function >>>>>> identifiers). This is more compliant with the LB >>>>>> constraints above: >>>> deciding >>>>>> which locator to use for a given flow will be a local >>>>>> decision not a centralized one. >>>>> >>>>> Absolutely. I cannot imagine how else it can be done. >>>>> >>>>> Maria >>>>> >>>> >>>> _______________________________________________ sfc mailing >>>> 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 Jul 10 08: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 7605E1A043D for ; Thu, 10 Jul 2014 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 wAbS2nPIJo30 for ; Thu, 10 Jul 2014 08:05:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA6F1A0944 for ; Thu, 10 Jul 2014 08:05:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV36127; Thu, 10 Jul 2014 15:05:00 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 16:04:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 08:04:56 -0700 From: Lucy yong To: "mohamed.boucadair@orange.com" , "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYoIgAgAC5UYCAABDHYA== Date: Thu, 10 Jul 2014 15:04:56 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.67] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453BE2F3dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/muS7W9rgiGE2ld7bxREi2Dmubu0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 15:05:11 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453BE2F3dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mIHRoZSBz ZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLg0K DQpMdWN5DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgMjowNiBBTQ0KVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBqbWhAam9lbGhhbHBlcm4u Y29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpSZS0sDQoNClRoZSBtZXJnZWQgZHJhZnQgY2FsbHMg b3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNl IHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUgZm9yd2FyZGluZyBhY3Rpb25zLg0KDQpSZXF1aXJp bmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IGF2YWls YWJsZSBTRkMgZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlz IG5vdCByZXF1aXJlZC9qdXN0aWZpZWQgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVu dCBjb250ZXh0cy4NCg0KU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUg cGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1l bnRzOiB0aGF0IGlzIHRoZSBvbmUgcmVxdWlyZWQgdG8gc3RydWN0dXJlIGEgc2VydmljZSBjaGFp bi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZlciBmb3J3YXJkaW5nIGFjdGlv bnMgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KDQpDaGVlcnMsDQpNZWQNCg0K RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBtaWtl YmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+DQpFbnZvecOpIDogbWVyY3Jl ZGkgOSBqdWlsbGV0IDIwMTQgMjI6MDMNCsOAIDogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCg0KSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g U0YgQ2hhaW4gYW5kIFNGIFBhdGg/ICBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRp b24gc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRob3NlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBkcmFm dCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24gdGhlc2UgdGVybXMuDQoNClRvIG1l LCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcyB3aGV0aGVyIGl0IGlzIHRo ZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUgSUQg b2YgdGhlIFNGQyBIZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRo KSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91 cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZv cndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3IgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBv ciBwYXRoIHRvIGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQoNCklmIHRoZSBs YXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgcmVxdWlyZSB0aGF0 IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQg dGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5n IFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNv bT4+DQpUbzogc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnJTNj c2ZjQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bHkgOCwgMjAxNA0KU3ViamVjdDogW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KSSBoYXZlIGJl ZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGEgbnVtYmVyIG9m DQpjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZCBtZXJnZWQg YXJjaHRpZWN0dXJlDQpkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nIGdyb3VwIGFn cmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZQ0Kd2lsbCB3b3JrIHRvIGltcHJvdmUgdGhlIHdvcmRp bmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdA0KcGFydGljaXBhdGVkIGluIHRoZSBXRyBk aXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdvcmtpbmcNCmdyb3VwIGlu dGVuZHMuDQoNCkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15 IHBlcnNvbmFsIHZpZXcsIGFuZCBzZWUNCmlmIHRoYXQgaGVscHMuDQoNCkluIHRoaXMgcmVnYXJk LCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmUNCmRlZmlu aW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlIG5vdCBhdHRlbXB0aW5n IHRvDQpkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZSBzb2x1dGlvbiBmb3Ig c2VydmljZSBjaGFpbmluZy4NClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMg Y29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCnZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2Ug bWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIgYXNwZWN0cy4NCg0KQXMgYSByZXN1bHQgdGhlcmUg YXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0byBleGlzdCBpbiB0aGUNCmxhcmdl ciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3aGVyZSB3ZSBhcmUgZnVu Y3Rpb25pbmcsDQphbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBh cmUgZG9pbmcuDQoNCkluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2Ug cGF0aCwgYXMgSSB1bmRlcnN0YW5kIHRoZW0sDQpJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2Fk IGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlDQpkaWZmZXJlbnQgd2F5cyB0aGF0 IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbCBpbnRlcmFjdCB3aXRoIHNlcnZpY2UNCmNoYWlu aW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1 cmUgaXMgdG8NCnBlcm1pdCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFu eSBwYXJ0aWN1bGFyIGtpbmQgYmUgdXNlZA0KaW4gYW55IHNvbHV0aW9uLg0KDQoxKSBMb2FkIGJh bGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLiBUaGlzIGlzIGEN CnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kIG1vZGlmaWVz IHRoZW0gKG9yIG1hcmtzDQp0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNl ciBzZXJ2aWNlIGluc3RhbmNlIHRvIHJlY2VpdmUNCnRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMg YW4gaW1wb3J0YW50IHNlcnZpY2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0bw0KaW5jbHVkZSBpbiBz ZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9u DQpob3cgc2VydmljZSBjaGFpbmluZyBpcyBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGlt cGFjdCBvbiB0aGUNCmFyY2h0aWVjdHVyZS4gRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVj dGl2ZSBpdCBpcyBzaW1wbHkgYSBzZXJ2aWNlDQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRo ZSB1bmRlcmx5aW5nIHBhY2tldC4NCg0KMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNp bmcuIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZSB3aGF0IGFwcGVhcnMNCnRvIHRoZSBzZXJ2aWNlIGNo YWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZiBjb250YWN0IGZvciBhDQpz cGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGEg Y29sbGVjdGlvbiBvZg0KdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5j bHVkaW5nIG9uZSBvciBzZXZlcmFsIGxvYWQNCmJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcg VlJSUC1saWtlIHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMNCmFkZHJlc3MuKSBtb3N0bHksIHRo aXMgaXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCm1lY2hh bmlzbXMuIEl0IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9s DQptZWNoYW5pc21zLCBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2Nh bGUtb3V0LCBhbmQgdm0NCmluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBv ZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2VseQ0KdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwg dGhhdCBvdXIgdGVybWlub2xvZ3kgZG9lcyBub3QgbGVhZCByZWFkZXJzIHRvDQp0aGluayB3ZSBh cmUgcHJvaGliaXRpbmcgaXQuDQoNCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5n IGRvbmUgYnkgc2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3INCnRoZSBzZXJ2aWNlIGNoYWluaW5n IHRoYXQgZGlyZWN0IHRyYWZmaWMgdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQNCm5vdCB3 YW50IHRvIHJlcXVpcmUgdGhhdCBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9u bHkgb25lDQpwbGFjZSBpbiB0aGUgbmV0d29yay4NCg0KSXQgaXMgb2YgY291cnNlIHRoZSBjYXNl IHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQgdG8gcmVmZXIgdG8NCnRoZSBjb2xs ZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmcgYXMgYSBz aW5nbGUNCnBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhIGdvb2Qg dGVybS4gQnV0IGJlY2F1c2UgSQ0KZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsIHRoZSBw b2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcgaXMgdG8NCmRpcmVjdCBkaWZmZXJlbnQgc3Vi c2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudCBzaW5ndWxhciBvciBjbHVzdGVyZWQNCnNlcnZp Y2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuDQoNCk5vdyB3 aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQgc2VydmljZSBj aGFpbiBhbmQNCnNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxv Z2ljYWwgZnVuY3Rpb25zIHRvIGJlDQphcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuIEl0 IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZQ0Kc3Vic2V0IG9mIHRyYWZmaWMgaXMg dG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kDQpmaXJld2FsbCB3 aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlIHdp dGhvdXQNCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCg0KVGhhdCBpcyBu b3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQSBzZXJ2aWNlIHBh dGgNCmlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zIGluIHRoZSBu ZXR3b3JrLiBUaG9zZQ0KbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNl cnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkNCmxvY2F0aW9ucy4gVGhleSBtYXkgYmUgYWRkcmVzc2Vk IGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZA0KYXMgcG9ydHMgb24gYW4gU0ZG LiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMNCm1heSBi ZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIHRy YW5zcG9ydC4NCg0KRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZD IGdyb3VwLCB3ZSBuZWVkIHRvIGJlIGFibGUNCnRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwg YWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlIGNoYWluLCB3aGljaA0KZHJpdmVzIHRoZSBmb3J3YXJk aW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoDQpwYWNr ZXRzIHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay4NCg0KU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMg aGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGggbWF5IG5vdCBiZSBrbm93bg0KYXQgdGhlIGZy b250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aCB0aGF0IGlzc3VlIGluIHR3byB3YXlz Lg0KRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0 aGVyZSBjYW4gYmUNCmRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2libGUg dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcNCm1lY2hhbmlzbXMgKGluIG11Y2ggdGhlIHNhbWUgd2F5 IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkNCmludmlzaWJsZSB0byByb3V0 aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0aGF0DQpy ZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vzc2FyeS4g VGhhdCB3aWxsDQpkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24gaW5mb3Jt YXRpb24gYXZhaWxhYmxlIGF0IHRoZQ0KcmUtY2xhc3NpZmljYXRpb24gcG9pbnQuDQoNCkkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQgZG9lcywg YW5kIGlmDQp0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsIHdl IGNhbiBmaWd1cmUgb3V0IHdoYXQNCmFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252 ZXkgdGhpcy4NCklmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVudCwg dGhlbiB3ZSB3aWxsIG9mIGNvdXJzZQ0KYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3Vw IGFncmVlbWVudHMuDQpJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUgd2hh dCB0byB0cnkgbmV4dC4NCg0KWW91cnMsDQpKb2VsDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D453BE2F3dfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K cC5UZXh0ZWRlYnVsbGVzLCBsaS5UZXh0ZWRlYnVsbGVzLCBkaXYuVGV4dGVkZWJ1bGxlcw0KCXtt c28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIjsNCgltc28tc3R5bGUtbGluazoiVGV4dGUg ZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVs bGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0 ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91 bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRv IGRyaXZlIHRoZSBmb3J3YXJkaW5nIGFjdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEp1bHkgMTAsIDIwMTQgMjowNiBBTTxicj4NCjxiPlRvOjwvYj4gbWlrZWJpYW5jQGFv bC5jb207IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5SZS0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG1lcmdl ZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyLiBJ IG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2ZSBmb3J3YXJkaW5nIGFjdGlv bnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJpbmcgYSBTRkMgc3lzdGVt IHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IGF2YWlsYWJsZSBTRkMgZm9yd2Fy ZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdCByZXF1aXJlZC9q dXN0aWZpZWQgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMNCiBkZXBsb3ltZW50IGNvbnRleHRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxk IHJlbHkgb24gdGhlIHBpZWNlIG9mIGluZm9ybWF0aW9uIHRoYXQgd2lsbCBiZSBwcmVzZW50IGlu IGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lIHJlcXVpcmVkIHRvIHN0cnVjdHVyZSBh IHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0DQogaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZlciBm b3J3YXJkaW5nIGFjdGlvbnMgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgWzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNv bSI+bWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNy ZWRpIDkganVpbGxldCAyMDE0IDIyOjAzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0 Jm5ic3A7OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmlu ZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIENoYWluIGFuZCBTRiBQYXRoPyAmbmJzcDtPdGhl ciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRo b3NlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMNCiB0aGF0IGV2ZXJ5b25l IGFncmVlcyBvbiB0aGVzZSB0ZXJtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0 IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZHJh ZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVhZGVyIHNo b3VsZCByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUNCiBwYXRoKSwgb3IgaWYgdGhpcyBkcmFm dCBzaW1wbHkgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIg ZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24g Y2hhaW4gb3IgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvciBwYXRoIHRvIGJlIG5lZ290 aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHRoZSBsYXR0ZXIg KGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgcmVxdWlyZSB0aGF0IGJvdGgg U0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90 aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5nDQogU0ZQ IGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t Ym90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hh ZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+ RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxo YWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tPC9h PiZndDs8YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNl bnQ6IDwvYj5UdWVzZGF5LCBKdWx5IDgsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpJIGhh dmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1i ZXIgb2YgPGJyPg0KY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9z ZWQgbWVyZ2VkIGFyY2h0aWVjdHVyZSA8YnI+DQpkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3 b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSA8YnI+DQp3aWxsIHdvcmsg dG8gaW1wcm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IDxicj4N CnBhcnRpY2lwYXRlZCBpbiB0aGUgV0cgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUg d2F5IHRoZSB3b3JraW5nIDxicj4NCmdyb3VwIGludGVuZHMuPGJyPg0KPGJyPg0KQnV0IHdoYXQg ZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5k IHNlZSA8YnI+DQppZiB0aGF0IGhlbHBzLjxicj4NCjxicj4NCkluIHRoaXMgcmVnYXJkLCBpdCBp cyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmUgPGJyPg0KZGVmaW5p bmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRpbmcg dG8gPGJyPg0KZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRpb24g Zm9yIHNlcnZpY2UgY2hhaW5pbmcuIDxicj4NClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1Ms IHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgPGJyPg0KdmlydHVhbCBtYWNo aW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLjxicj4NCjxi cj4NCkFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQg dG8gZXhpc3QgaW4gdGhlIDxicj4NCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQg d2l0aCBhYm92ZSB3aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsIDxicj4NCmFuZCBhcmUgbm90IGRp cmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnI+DQo8YnI+DQpJbiBv cmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJz dGFuZCB0aGVtLCA8YnI+DQpJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4g VGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIDxicj4NCmRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBi YWxhbmNpbmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZSA8YnI+DQpjaGFpbmlu Zy4gVGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJl IGlzIHRvIDxicj4NCnBlcm1pdCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0 IGFueSBwYXJ0aWN1bGFyIGtpbmQgYmUgdXNlZCA8YnI+DQppbiBhbnkgc29sdXRpb24uPGJyPg0K PGJyPg0KMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQg dXNlci4gVGhpcyBpcyBhIDxicj4NCnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIg cGFja2V0cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzIDxicj4NCnRoZW0sIG9yIC4uLikg c28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZSA8 YnI+DQp0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0 aW9uIHRvIGJlIGFibGUgdG8gPGJyPg0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdz IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIDxicj4NCmhvdyBzZXJ2aWNlIGNo YWluaW5nIGlzIGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSA8YnI+ DQphcmNodGllY3R1cmUuIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMg c2ltcGx5IGEgc2VydmljZSA8YnI+DQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRl cmx5aW5nIHBhY2tldC48YnI+DQo8YnI+DQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFu Y2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFycyA8YnI+DQp0byB0aGUgc2Vy dmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YgY29udGFjdCBm b3IgYSA8YnI+DQpzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVs aXZlcmVkIGJ5IGEgY29sbGVjdGlvbiBvZiA8YnI+DQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hp bmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZCA8YnI+DQpiYWxhbmNl cnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFD IDxicj4NCmFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nIGRhdGEgcGxhbmUgPGJyPg0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wgPGJyPg0KbWVjaGFuaXNtcywgc3VjaCBh cyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtIDxicj4N Cmluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRo aXMgaXMgbGFyZ2VseSA8YnI+DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0 ZXJtaW5vbG9neSBkb2VzIG5vdCBsZWFkIHJlYWRlcnMgdG8gPGJyPg0KdGhpbmsgd2UgYXJlIHBy b2hpYml0aW5nIGl0Ljxicj4NCjxicj4NCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5j aW5nIGRvbmUgYnkgc2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3IgPGJyPg0KdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3Vs ZCA8YnI+DQpub3Qgd2FudCB0byByZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9u IGFwcGVhciBhdCBvbmx5IG9uZSA8YnI+DQpwbGFjZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+ DQpJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkg dGVuZCB0byByZWZlciB0byA8YnI+DQp0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFw cGVhciB0byBzZXJ2aWNlIGNoYWluaW5nIGFzIGEgc2luZ2xlIDxicj4NCnBvaW50IGFzIGEgY2x1 c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSA8 YnI+DQpkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBs b2FkIGJhbGFuY2luZyBpcyB0byA8YnI+DQpkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJh ZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIDxicj4NCnNlcnZpY2UgZnVu Y3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KTm93 IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNl IGNoYWluIGFuZCA8YnI+DQpzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5j ZSBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSA8YnI+DQphcHBsaWVkIHRvIGEgc3Vic2V0IG9m IHBhY2tldHMuIEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSA8YnI+DQpzdWJz ZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9u LCBhbmQgPGJyPg0KZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRp cmVjdGx5IHRvIHRoZSBjYWNoZSB3aXRob3V0IDxicj4NCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2 aWNlIGZ1bmN0aW9ucy48YnI+DQo8YnI+DQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24g dG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZpY2UgcGF0aCA8YnI+DQppcywgaW4gc29tZSBm YXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yay4gVGhvc2UgPGJy Pg0KbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b24gZGVsaXZlcnkgPGJyPg0KbG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAg YWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIDxicj4NCmFzIHBvcnRzIG9uIGFuIFNGRi4g VGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zIDxicj4NCm1h eSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhl IHRyYW5zcG9ydC48YnI+DQo8YnI+DQpGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3Jr IG9mIHRoZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJsZSA8YnI+DQp0byB0YWxrIGFib3V0 IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggPGJy Pg0KZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBh Y3R1YWwgZGF0YSBwYXRoIDxicj4NCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxi cj4NCjxicj4NClNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhl IHdob2xlIHBhdGggbWF5IG5vdCBiZSBrbm93biA8YnI+DQphdCB0aGUgZnJvbnQuJnF1b3Q7IFRo aXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gPGJyPg0K Rmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVy ZSBjYW4gYmUgPGJyPg0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJs ZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyA8YnI+DQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBz YW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5IDxicj4NCmludmlz aWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFr ZSBpcyB0aGF0IDxicj4NCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWlu IHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdpbGwgPGJyPg0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcg Y2hhaW4uIEJhc2VkIG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgPGJyPg0KcmUtY2xh c3NpZmljYXRpb24gcG9pbnQuPGJyPg0KPGJyPg0KSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBs YWluIHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYgPGJyPg0KdGhlIGludGVu dCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3 aGF0IDxicj4NCmFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy48YnI+ DQpJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ug d2lsbCBvZiBjb3Vyc2UgPGJyPg0KYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFn cmVlbWVudHMuPGJyPg0KSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdo YXQgdG8gdHJ5IG5leHQuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2691CE0099834E4A9C5044EEC662BB9D453BE2F3dfweml701chmchi_-- From nobody Thu Jul 10 08:20: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 A4E9C1A0233 for ; Thu, 10 Jul 2014 08:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 6U21ac1X7xG3 for ; Thu, 10 Jul 2014 08:20:06 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954E21A05D1 for ; Thu, 10 Jul 2014 08:19:47 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 45E6F53E4A; Thu, 10 Jul 2014 08:19:46 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 08:19:46.186 -0700 x-echoworx-msg-id: e9215926-f7bd-4c44-8657-39dfa81dbd1b x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 232; Thu, 10 Jul 2014 08:19:46 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 1703453E4A; Thu, 10 Jul 2014 08:19:46 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 08:19:46 -0700 From: Ron Parker To: Lucy yong , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgD//4xGQA== Date: Thu, 10 Jul 2014 15:19:46 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@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] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B3BA9MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cNGFr5Y78NlrIzGmW_r9SMH3Zwo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 15:20:09 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B3BA9MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgYXJjaGl0ZWN0dXJhbGx5IHNpZ25pZmljYW50IHRvIGlkZW50aWZ5IHRoYXQgbXVsdGlw bGUgYWRkcmVzc2FibGUgaW5zdGFuY2VzIG9mIGEgc2VydmljZSBmdW5jdGlvbiBhcmUgZXhwbGlj aXRseSBhbGxvd2VkLiAgIFdoZXRoZXIgdGhvc2UgaW5zdGFuY2UgcGVyZm9ybSBzb21lIGZ1cnRo ZXIgbGV2ZWwgb2YgbG9hZCBiYWxhbmNpbmcgaXMgaXJyZWxldmFudCwgYXMgaGFzIGJlZW4gcG9p bnRlZCBvdXQgYnkgSm9lbC4gICAgSXQgaXMgYWxzbyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNh bnQgdG8gYXNzaWduIHJlc3BvbnNpYmlsaXR5IGZvciBpbnN0YW5jZSBzZWxlY3Rpb24uICAgIElu IHBhcnRpY3VsYXIsIGlzIHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gY2VudHJhbGl6ZWQsIGRpc3Ry aWJ1dGVkLCBvciBzb21lIGNvbWJpbmF0aW9uPyAgIFdoaWNoIGZ1bmN0aW9uYWwgZW50aXRpZXMg aW4gdGhlIGFyY2hpdGVjdHVyZSBoYXZlIHdoYXQgcmVzcG9uc2liaWxpdGllcyB0byBhY2hpZXZl IHRoaXM/ICAgSW4gTm92ZW1iZXIsIDIwMTMsIGFmdGVyIElFVEYgODgsIEkgc3VibWl0dGVkIHRo aXMgZHJhZnQsIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhcmtlci1zZmMtY2hh aW4tdG8tcGF0aC0wMCwgd2hpY2ggcHJvcG9zZWQgdGhhdCB0aGUgaW5zdGFuY2Ugc2VsZWN0aW9u IHdhcyBtYWRlIGhvcCBieSBob3AgYnkgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRoZW1zZWx2ZXMs IGluIGEgZnVsbHkgZGlzdHJpYnV0ZWQgbWFubmVyLiAgIFRoYXQgd2FzIGp1c3QgYSBwcm9wb3Nh bCBhbmQgSSBhbSBub3Qgd2VkZGVkIHRvIGl0LCBieSBhbnkgbWVhbnMuICAgIEpvZWwgYXNrZWQg YWJvdXQgc3BlY2lmaWNpdHkgYW5kIGl0IGlzIGF0IHRoaXMgbGV2ZWwgdGhhdCBJ4oCZZCBsaWtl IHRvIHNlZSB0aGUgYXJjaGl0ZWN0dXJlIGRlc2NyaWJlIHRoaW5ncy4gICBJdCBzaG91bGQgYmUg YWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCDigJxob3cgZG9lcyBtdWx0aS1pbnN0YW5jZSBz ZWxlY3Rpb24gd29yayBpbiBTRkM/4oCdIGluIGEgY29uY2lzZSBtYW5uZXIuICAgSWYgdGhlIGdy b3VwIGZlZWxzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG1vcmUgdGhhbiBvbmUgYW5zd2VyIHRvIHRo YXQgcXVlc3Rpb24sIHNvIGJlIGl0LCBidXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZGVzY3JpYmUg dGhlIGhpZ2ggbGV2ZWwgbWVjaGFuaXNtIGFuZCByYXRpb25hbGUgZm9yIGVhY2ggc3VjY2luY3Rs eS4gICAgT2YgY291cnNlLCB0aGF0IGlzIG1lcmVseSBvbmUgc3VjaCBxdWVzdGlvbiBhbmQgdGhl cmUgYXJlIG1hbnkgb3RoZXJzIHRoYXQgYW4gYXJjaGl0ZWN0dXJhbCBkb2N1bWVudCBzaG91bGQg YmUgYWJsZSB0byBkZXNjcmliZS4NCg0KICAgUm9uDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWN5IHlvbmcNClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0IDExOjA1IEFNDQpUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTsgbWlrZWJpYW5jQGFvbC5jb207IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQoNCkFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBv ZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcgYWN0 aW9ucy4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAyOjA2 IEFNDQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgam1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNClJlLSwNCg0KVGhlIG1lcmdlZCBkcmFmdCBj YWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyLiBJIG9iamVjdCB0 byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2ZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQoNClJl cXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkg YXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21h aW4gaXMgbm90IHJlcXVpcmVkL2p1c3RpZmllZCBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBs b3ltZW50IGNvbnRleHRzLg0KDQpTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9u IHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmUgcHJlc2VudCBpbiBhbGwgZGVw bG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUgYSBzZXJ2aWNl IGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmVyIGZvcndhcmRpbmcg YWN0aW9ucyBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCkVudm95w6kgOiBt ZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMw0Kw4AgOiBqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KDQpJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gIE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVm aW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8gdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggdGhl IGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGVzZSB0ZXJtcy4NCg0K VG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdoZXRoZXIgaXQg aXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRo ZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQgcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhl IHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1i aWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBm b3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNo YWluIG9yIHBhdGggdG8gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCg0KSWYg dGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2ZSByZXF1aXJl IHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2Ugb25lIHJlcXVpcmVk IGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUgdmVuZG9ycyBvbmx5IHN1cHBv cnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqbWhAam9lbGhhbHBlcm4uY29tPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBl cm4uY29tPj4NClRvOiBzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmclM2NzZmNAaWV0Zi5vcmc+Pg0KU2VudDogVHVlc2RheSwgSnVseSA4LCAyMDE0DQpTdWJqZWN0 OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJIGhh dmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1i ZXIgb2YNCmNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1l cmdlZCBhcmNodGllY3R1cmUNCmRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmcgZ3Jv dXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlDQp3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUg d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90DQpwYXJ0aWNpcGF0ZWQgaW4gdGhl IFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUgd29ya2luZw0KZ3Jv dXAgaW50ZW5kcy4NCg0KQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxh aW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZQ0KaWYgdGhhdCBoZWxwcy4NCg0KSW4gdGhpcyBy ZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdCB3aGF0IHdlIGFyZQ0K ZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVt cHRpbmcgdG8NCmRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9u IGZvciBzZXJ2aWNlIGNoYWluaW5nLg0KVGhhdCB3b3VsZCBlbmNvbXBhc3MgT1NTL0JTUywgdmFy aW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KdmlydHVhbCBtYWNoaW5lIGFuZCBp bWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLg0KDQpBcyBhIHJlc3VsdCB0 aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZQ0K bGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFy ZSBmdW5jdGlvbmluZywNCmFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3Jr IHdlIGFyZSBkb2luZy4NCg0KSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2Vy dmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwNCkkgbmVlZCB0byBmaXJzdCBkaXNjdXNz IGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUNCmRpZmZlcmVudCB3YXlz IHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZQ0K Y2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0 aWVjdHVyZSBpcyB0bw0KcGVybWl0IGFsbCBvZiB0aGVzZSwgYnV0IG5vdCB0byBtYW5kYXRlIHRo YXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2VkDQppbiBhbnkgc29sdXRpb24uDQoNCjEpIExv YWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMg aXMgYQ0Kc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9k aWZpZXMgdGhlbSAob3IgbWFya3MNCnRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVu ZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZQ0KdGhlIHVzZXJzIHBhY2tldC4gVGhp cyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBiZSBhYmxlIHRvDQppbmNsdWRl IGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVu dHMgb24NCmhvdyBzZXJ2aWNlIGNoYWluaW5nIGlzIGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0 bGUgaW1wYWN0IG9uIHRoZQ0KYXJjaHRpZWN0dXJlLiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUz cnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2UNCmZ1bmN0aW9uIHdoaWNoIG1heSBtb2Rp ZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KDQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJh bGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFycw0KdG8gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9mIGNvbnRhY3QgZm9y IGENCnNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQg YnkgYSBjb2xsZWN0aW9uIG9mDQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJs eSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZA0KYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1 c2luZyBWUlJQLWxpa2UgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQw0KYWRkcmVzcy4pIG1vc3Rs eSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0K bWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNv bnRyb2wNCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWlu LCBzY2FsZS1vdXQsIGFuZCB2bQ0KaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1w YWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJnZWx5DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2Fy ZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBkb2VzIG5vdCBsZWFkIHJlYWRlcnMgdG8NCnRoaW5r IHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCg0KMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxh bmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0IHBhdGhzIGZvcg0KdGhlIHNlcnZpY2UgY2hh aW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZA0K bm90IHdhbnQgdG8gcmVxdWlyZSB0aGF0IGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIg YXQgb25seSBvbmUNCnBsYWNlIGluIHRoZSBuZXR3b3JrLg0KDQpJdCBpcyBvZiBjb3Vyc2UgdGhl IGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZCB0byByZWZlciB0bw0KdGhl IGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZyBh cyBhIHNpbmdsZQ0KcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGEg Z29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJDQpkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywg dGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZyBpcyB0bw0KZGlyZWN0IGRpZmZlcmVu dCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9yIGNsdXN0ZXJlZA0K c2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUgbmV0d29yay4NCg0K Tm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2 aWNlIGNoYWluIGFuZA0Kc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ug b2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUNCmFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0 cy4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lDQpzdWJzZXQgb2YgdHJhZmZp YyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQNCmZpcmV3 YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2Fj aGUgd2l0aG91dA0KdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KDQpUaGF0 IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZp Y2UgcGF0aA0KaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4g dGhlIG5ldHdvcmsuIFRob3NlDQpsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvciBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeQ0KbG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRy ZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkDQphcyBwb3J0cyBvbiBh biBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0K bWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0 aGUgdHJhbnNwb3J0Lg0KDQpGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJsZQ0KdG8gdGFsayBhYm91dCB0aGUgaGlnaCBs ZXZlbCBhYnN0cmFjdGlvbiwgdGhlIHNlcnZpY2UgY2hhaW4sIHdoaWNoDQpkcml2ZXMgdGhlIGZv cndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvIHRhbGsgYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGgN CnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLg0KDQpTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUgcGF0aCBtYXkgbm90IGJlIGtub3duDQphdCB0 aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRoYXQgaXNzdWUgaW4gdHdv IHdheXMuDQpGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZCBiYWxhbmNlcnMgYWJv dmUsIHRoZXJlIGNhbiBiZQ0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlz aWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KbWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2Ft ZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KaW52aXNpYmxlIHRv IHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyIHByb3Zpc2lvbiB3ZSBtYWtlIGlzIHRo YXQNCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNz YXJ5LiBUaGF0IHdpbGwNCmRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBp bmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlDQpyZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCg0K SSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBk b2VzLCBhbmQgaWYNCnRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZyBncm91 cCwgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdA0KYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkIHRv IGNvbnZleSB0aGlzLg0KSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50 ZW50LCB0aGVuIHdlIHdpbGwgb2YgY291cnNlDQphZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcg Z3JvdXAgYWdyZWVtZW50cy4NCklmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3Vy ZSB3aGF0IHRvIHRyeSBuZXh0Lg0KDQpZb3VycywNCkpvZWwNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg== --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B3BA9MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMN Cgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgYXJjaGl0ZWN0dXJhbGx5IHNp Z25pZmljYW50IHRvIGlkZW50aWZ5IHRoYXQgbXVsdGlwbGUgYWRkcmVzc2FibGUgaW5zdGFuY2Vz IG9mIGEgc2VydmljZSBmdW5jdGlvbiBhcmUgZXhwbGljaXRseSBhbGxvd2VkLiZuYnNwOyZuYnNw OyBXaGV0aGVyIHRob3NlIGluc3RhbmNlIHBlcmZvcm0NCiBzb21lIGZ1cnRoZXIgbGV2ZWwgb2Yg bG9hZCBiYWxhbmNpbmcgaXMgaXJyZWxldmFudCwgYXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgYnkg Sm9lbC4mbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgYWxzbyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlm aWNhbnQgdG8gYXNzaWduIHJlc3BvbnNpYmlsaXR5IGZvciBpbnN0YW5jZSBzZWxlY3Rpb24uJm5i c3A7Jm5ic3A7Jm5ic3A7IEluIHBhcnRpY3VsYXIsIGlzIHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24g Y2VudHJhbGl6ZWQsIGRpc3RyaWJ1dGVkLCBvciBzb21lIGNvbWJpbmF0aW9uPw0KICZuYnNwOyZu YnNwO1doaWNoIGZ1bmN0aW9uYWwgZW50aXRpZXMgaW4gdGhlIGFyY2hpdGVjdHVyZSBoYXZlIHdo YXQgcmVzcG9uc2liaWxpdGllcyB0byBhY2hpZXZlIHRoaXM/Jm5ic3A7Jm5ic3A7IEluIE5vdmVt YmVyLCAyMDEzLCBhZnRlciBJRVRGIDg4LCBJIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0LA0KPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1w YXRoLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJrZXItc2ZjLWNoYWlu LXRvLXBhdGgtMDA8L2E+LCB3aGljaCBwcm9wb3NlZCB0aGF0IHRoZSBpbnN0YW5jZSBzZWxlY3Rp b24gd2FzIG1hZGUgaG9wIGJ5IGhvcCBieSB0aGUgc2VydmljZSBmdW5jdGlvbnMgdGhlbXNlbHZl cywgaW4gYSBmdWxseSBkaXN0cmlidXRlZA0KIG1hbm5lci4mbmJzcDsmbmJzcDsgVGhhdCB3YXMg anVzdCBhIHByb3Bvc2FsIGFuZCBJIGFtIG5vdCB3ZWRkZWQgdG8gaXQsIGJ5IGFueSBtZWFucy4g Jm5ic3A7Jm5ic3A7Jm5ic3A7Sm9lbCBhc2tlZCBhYm91dCBzcGVjaWZpY2l0eSBhbmQgaXQgaXMg YXQgdGhpcyBsZXZlbCB0aGF0IEnigJlkIGxpa2UgdG8gc2VlIHRoZSBhcmNoaXRlY3R1cmUgZGVz Y3JpYmUgdGhpbmdzLiZuYnNwOyZuYnNwOyBJdCBzaG91bGQgYmUgYWJsZSB0byBhbnN3ZXIgdGhl IHF1ZXN0aW9uLCDigJxob3cgZG9lcyBtdWx0aS1pbnN0YW5jZQ0KIHNlbGVjdGlvbiB3b3JrIGlu IFNGQz/igJ0gaW4gYSBjb25jaXNlIG1hbm5lci4mbmJzcDsmbmJzcDsgSWYgdGhlIGdyb3VwIGZl ZWxzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG1vcmUgdGhhbiBvbmUgYW5zd2VyIHRvIHRoYXQgcXVl c3Rpb24sIHNvIGJlIGl0LCBidXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZGVzY3JpYmUgdGhlIGhp Z2ggbGV2ZWwgbWVjaGFuaXNtIGFuZCByYXRpb25hbGUgZm9yIGVhY2ggc3VjY2luY3RseS4mbmJz cDsmbmJzcDsmbmJzcDsgT2YgY291cnNlLCB0aGF0IGlzIG1lcmVseQ0KIG9uZSBzdWNoIHF1ZXN0 aW9uIGFuZCB0aGVyZSBhcmUgbWFueSBvdGhlcnMgdGhhdCBhbiBhcmNoaXRlY3R1cmFsIGRvY3Vt ZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlc2NyaWJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFJv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5MdWN5IHlvbmc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMTE6 MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IG1pa2Vi aWFuY0Bhb2wuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlLiBUaGUgYXJjaC4g ZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcgYWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0IDI6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNA YW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZS0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG1lcmdlZCBkcmFmdCBjYWxs cyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1 c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2ZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhl IGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IGF2YWlsYWJsZSBTRkMgZm9yd2FyZGluZyBwYXRocyB3 aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdCByZXF1aXJlZC9qdXN0aWZpZWQgbm9y IHBvc3NpYmxlIGluIHZhcmlvdXMNCiBkZXBsb3ltZW50IGNvbnRleHRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhl IHBpZWNlIG9mIGluZm9ybWF0aW9uIHRoYXQgd2lsbCBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3lt ZW50czogdGhhdCBpcyB0aGUgb25lIHJlcXVpcmVkIHRvIHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hh aW4uIEhvdyB0aGF0DQogaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZlciBmb3J3YXJkaW5nIGFj dGlvbnMgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxh IHBhcnQgZGU8L2I+IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5j QGFvbC5jb208L2E+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDkganVpbGxl dCAyMDE0IDIyOjAzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4g UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPklzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIFNGIENoYWluIGFuZCBTRiBQYXRoPyAmbmJzcDtPdGhlciB0aGFuIGNsYXJp ZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRob3NlIG5vdCBmYW1p bGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMNCiB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0 aGVzZSB0ZXJtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVu Y2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1h dGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVhZGVyIHNob3VsZCByZWZlcmVu Y2UgKHRoZSBjaGFpbiBvciB0aGUNCiBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkgaW50 ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvIGRp Y3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3IgcGF0 aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvciBwYXRoIHRvIGJlIG5lZ290aWF0ZWQgaW4gdGhl IGNvbnRyb2wtcGxhbmUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyks IHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMg YmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFs KSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5nDQogU0ZQIGFuZCBvdGhlcnMg b25seSBzdXBwb3J0aW5nIFNGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVw dCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9 ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+RnJvbTogPC9iPjxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSI+ am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQo8 Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5UdWVz ZGF5LCBKdWx5IDgsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpJIGhhdmUgYmVlbiB0cnlp bmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2YgPGJyPg0K Y29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVyZ2VkIGFy Y2h0aWVjdHVyZSA8YnI+DQpkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nIGdyb3Vw IGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSA8YnI+DQp3aWxsIHdvcmsgdG8gaW1wcm92ZSB0 aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IDxicj4NCnBhcnRpY2lwYXRl ZCBpbiB0aGUgV0cgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZSB3b3Jr aW5nIDxicj4NCmdyb3VwIGludGVuZHMuPGJyPg0KPGJyPg0KQnV0IHdoYXQgZG8gd2UgaW50ZW5k PyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZSA8YnI+DQpp ZiB0aGF0IGhlbHBzLjxicj4NCjxicj4NCkluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQg dG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmUgPGJyPg0KZGVmaW5pbmcgaXMgdGhlIGRh dGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRpbmcgdG8gPGJyPg0KZGVm aW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRpb24gZm9yIHNlcnZpY2Ug Y2hhaW5pbmcuIDxicj4NClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMgY29u dHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgPGJyPg0KdmlydHVhbCBtYWNoaW5lIGFuZCBpbWFn ZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLjxicj4NCjxicj4NCkFzIGEgcmVz dWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhpc3QgaW4g dGhlIDxicj4NCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3 aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsIDxicj4NCmFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVp cmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnI+DQo8YnI+DQpJbiBvcmRlciB0byBnZXQg dG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLCA8 YnI+DQpJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0 IGxlYXN0IHRocmVlIDxicj4NCmRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2Fu IGFuZCB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZSA8YnI+DQpjaGFpbmluZy4gVGhlcmUgcHJv YmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIDxicj4N CnBlcm1pdCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1 bGFyIGtpbmQgYmUgdXNlZCA8YnI+DQppbiBhbnkgc29sdXRpb24uPGJyPg0KPGJyPg0KMSkgTG9h ZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4gVGhpcyBp cyBhIDxicj4NCnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5k IG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzIDxicj4NCnRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hv b3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZSA8YnI+DQp0aGUgdXNl cnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGJlIGFi bGUgdG8gPGJyPg0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2aW9yIG1h eSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIDxicj4NCmhvdyBzZXJ2aWNlIGNoYWluaW5nIGlzIGRv bmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSA8YnI+DQphcmNodGllY3R1 cmUuIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGEgc2Vy dmljZSA8YnI+DQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tl dC48YnI+DQo8YnI+DQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBp cywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFycyA8YnI+DQp0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YgY29udGFjdCBmb3IgYSA8YnI+DQpz cGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGEg Y29sbGVjdGlvbiBvZiA8YnI+DQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJs eSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZCA8YnI+DQpiYWxhbmNlcnMgKGZvciBleGFt cGxlIHVzaW5nIFZSUlAtbGlrZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIDxicj4NCmFkZHJl c3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRh dGEgcGxhbmUgPGJyPg0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJs ZSB0byB2YXJpb3VzIGNvbnRyb2wgPGJyPg0KbWVjaGFuaXNtcywgc3VjaCBhcyB0aG9zZSByZXNw b25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtIDxicj4NCmluc3RhbnRpYXRp b24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2Vs eSA8YnI+DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBk b2VzIG5vdCBsZWFkIHJlYWRlcnMgdG8gPGJyPg0KdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0 Ljxicj4NCjxicj4NCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkg c2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3IgPGJyPg0KdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhh dCBkaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCA8YnI+DQpub3Qg d2FudCB0byByZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBv bmx5IG9uZSA8YnI+DQpwbGFjZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpJdCBpcyBvZiBj b3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZCB0byByZWZl ciB0byA8YnI+DQp0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2 aWNlIGNoYWluaW5nIGFzIGEgc2luZ2xlIDxicj4NCnBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJl Y2F1c2UgY2x1c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSA8YnI+DQpkbyBub3Qg aGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2lu ZyBpcyB0byA8YnI+DQpkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZm ZXJlbnQgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIDxicj4NCnNlcnZpY2UgZnVuY3Rpb25zIGluIGRp ZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KTm93IHdpdGggdGhhdCBz YWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWluIGFuZCA8 YnI+DQpzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZSBvZiBsb2dpY2Fs IGZ1bmN0aW9ucyB0byBiZSA8YnI+DQphcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuIEl0 IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSA8YnI+DQpzdWJzZXQgb2YgdHJhZmZp YyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQgPGJyPg0K ZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRo ZSBjYWNoZSB3aXRob3V0IDxicj4NCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9u cy48YnI+DQo8YnI+DQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRo ZSBwYWNrZXRzLiBBIHNlcnZpY2UgcGF0aCA8YnI+DQppcywgaW4gc29tZSBmYXNoaW9uLCBhIHNl cXVlbmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yay4gVGhvc2UgPGJyPg0KbG9jYXRpb25z IHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkg PGJyPg0KbG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhl eSBtYXkgYmUgYWRkcmVzc2VkIDxicj4NCmFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUgYXJlIG1h bnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zIDxicj4NCm1heSBiZSBrbm93biB0 byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIHRyYW5zcG9ydC48 YnI+DQo8YnI+DQpGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMg Z3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJsZSA8YnI+DQp0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxl dmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggPGJyPg0KZHJpdmVzIHRo ZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwgZGF0YSBw YXRoIDxicj4NCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NClNl dmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdob2xlIHBhdGgg bWF5IG5vdCBiZSBrbm93biA8YnI+DQphdCB0aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJjaGl0ZWN0 dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gPGJyPg0KRmlyc3QsIGFzIG5v dGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgPGJy Pg0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyA8YnI+DQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0 IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5IDxicj4NCmludmlzaWJsZSB0byByb3V0 aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0aGF0IDxi cj4NCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNz YXJ5LiBUaGF0IHdpbGwgPGJyPg0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2Vk IG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgPGJyPg0KcmUtY2xhc3NpZmljYXRpb24g cG9pbnQuPGJyPg0KPGJyPg0KSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2Ug YXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYgPGJyPg0KdGhlIGludGVudCBpcyBhY2NlcHRh YmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IDxicj4NCmFk ZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy48YnI+DQpJZiB0aGUgd29y a2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBjb3Vy c2UgPGJyPg0KYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuPGJy Pg0KSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5l eHQuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B3BA9MBX021W3CA2exch_-- From nobody Thu Jul 10 09:03: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 422201A0601 for ; Thu, 10 Jul 2014 09:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k41dYKzC8KA for ; Thu, 10 Jul 2014 09:03:36 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABBC1A0653 for ; Thu, 10 Jul 2014 09:03:35 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 759beb35.2abffb244940.6130715.00-2436.16953468.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 16:03:35 +0000 (UTC) X-MXL-Hash: 53beb957399fcb79-43de4af88fea24716264aafd29f13a170a3df730 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 329beb35.0.6129813.00-2264.16950992.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 16:02:43 +0000 (UTC) X-MXL-Hash: 53beb92322ed872e-e180065211b696ac0e9ba56383d62dd53ce677a7 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AG2gIK002521; Thu, 10 Jul 2014 12:02:42 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AG2R3K002148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 12:02:37 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 16:02:11 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 12:02:07 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSggABL5AD//7770IAATBoA//+9cIAACIceAAAANQwAAABiy4AAABmigAAAkLAAAABxQAAAAJhKAAAcmPkg Date: Thu, 10 Jul 2014 16:02:07 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> In-Reply-To: <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=qN95wPeSAAAA:8 a=WzlZodoGsrq3ZJURhjUA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=JfD0Fch1gWkA:10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [paC5pjApGzsA:10 a=Hz7IrDYlS0cA:10 a=5yoQTMZIlKKUdv4O:21 a=] X-AnalysisOut: [hmKmm3kIuL2jANto:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/117YUbEwUtyqoz2mihkKU6H4Kck Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:03:38 -0000 One of the main problems in "service chains" is how to implement a service = that is conceptually one hop but scaled horizontally as 10 or 100 different= VMs. So, IMO, if we are not addressing this problem than what are we solving. Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, July 09, 2014 6:17 PM > To: Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA > H; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > I should clarify that my statement was made as a personal opinion and it = is > up to the WG to evaluate if there exists anything at the architectural le= vel > that is new and therefore needs to be addressed. >=20 > Sent from my iPhone >=20 > > On Jul 9, 2014, at 6:01 PM, "Ron Parker" > wrote: > > > > Jim, > > > > Respectfully, I'm not comfortable with that. While it is easy to say = that > this is a layered problem and that load balancing belongs at a lower leve= l, it > seems to me that load balancing of the service functions (not load balanc= er > as a service function) should be an explicit consideration of the SFC > architecture. I say this not only from a scale perspective, but also w= ith > resiliency in mind. > > > > Ron > > > > > > -----Original Message----- > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > Sent: Wednesday, July 09, 2014 5:48 PM > > To: Ron Parker > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; > NAPIERALA, MARIA H > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > I would say that's implementation. > > > > Sent from my iPhone > > > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" > wrote: > >> > >> Agreed. But is that in scope for SFC or out of scope for SFC? > >> > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Wednesday, July 09, 2014 5:29 PM > >> To: Ron Parker > >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; > mohamed.boucadair@orange.com; > >> sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> Well of course not; in that case you load balance up a level between > those nodes and then locally. > >> > >> Sent from my iPhone > >> > >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" > wrote: > >>> > >>> Jim, > >>> > >>> There may not be a single node through which all of the instances can > be reached (at some reasonable limit of L2 or L3 hops). > >>> > >>> Ron > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >>> (jguichar) > >>> Sent: Wednesday, July 09, 2014 5:12 PM > >>> To: NAPIERALA, MARIA H > >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> At the node through which the 20 instances are reachable. IOW you > don't have to individually address packets to each and every instance. > >>> > >>> Sent from my iPhone > >>> > >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" > wrote: > >>>> > >>>> Hi Jim, > >>>> > >>>> When you say "locally", where is it? > >>>> > >>>> Maria > >>>> > >>>>> -----Original Message----- > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>> Sent: Wednesday, July 09, 2014 5:06 PM > >>>>> To: NAPIERALA, MARIA H > >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> Hi Maria, > >>>>> > >>>>> Absolutely and categorically no! If you have 20 instances at each > >>>>> hop then you can choose to load balance among them locally > >>>>> resulting in exactly 4 paths. What Joel is saying is that if for > >>>>> some very odd and certainly not recommended reason you want to > >>>>> treat each instance separately then the architecture does not > prevent it. > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > > >>>>> wrote: > >>>>> > >>>>>>> I am saying that if the 20 virtual firewalls are deployed > >>>>>>> separately, then the service chaining infrastructure would treat > >>>>>>> them as such, and would use distinct service paths. > >>>>>> > >>>>>> If I have a 4 hop service chain with 20 instances at each hop, > >>>>>> then I have > >>>>> to globally manage 160,000 service paths (for one chain)? Well, we > >>>>> have yet to see a solution that work this way and scales.. > >>>>>> > >>>>>> Maria > >>>>>> > >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > >>>>>>>> I had in mind singular instances, say, 20 virtual firewall > >>>>>>>> instances > >>>>>>> somewhere in the middle of a chain. Are you saying that you will > >>>>>>> decide (make a load balancing decision) at the entry to the chain > >>>>>>> which of those > >>>>> 20 > >>>>>>> firewalls will be used by a particular flow? > >>>>>>>> > >>>>>>>> Maria > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel > >>>>>>>>> Halpern > >>>>> Direct > >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM > >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > >>>>>>> sfc@ietf.org > >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> The archtiecture allows for this local decision, while still > >>>>>>>>> having the global decision that is directing the traffic. That > >>>>>>>>> is, the global decision directs the traffic to places in the > >>>>>>>>> network. Those places may be singular or clusters. If they > >>>>>>>>> are clusters, those clusters can use any number of algorithms > >>>>>>>>> to distribute the traffic internally, without any effect on > >>>>>>>>> service chaining. (And yes, this can be done in such a way > >>>>>>>>> that return traffic, if delivered globally to the same place, > >>>>>>>>> can then be delivered to the right internal state.) > >>>>>>>>> > >>>>>>>>> The definition of the service path is about how service > >>>>>>>>> chaining will direct the traffic. it is not about how the > >>>>>>>>> internal load balancing is doen, as there are MANY ways to do > >>>>>>>>> that, and they can give the same external interface. > >>>>>>>>> > >>>>>>>>> We could write the architecture pretending that it always > >>>>>>>>> addresses singular instances, but knowing that reality would > >>>>>>>>> allow load balanced clusters at those locations. But that > >>>>>>>>> would be a misleading architectural description and might be > >>>>>>>>> read to outlaw some solutions that fall within the goal the WG > wishes to meet. > >>>>>>>>> > >>>>>>>>> Yours, > >>>>>>>>> Joel > >>>>>>>>> > >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>>> [Med] I still disagree that an ordered list of locators can > >>>>>>>>>>> be > >>>>>>> determined > >>>>>>>>> in > >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding be > >>>>>>>>>>> based > >>>>>>> on > >>>>>>>>> the > >>>>>>>>>>> service chain itself (characterized as an order list of > >>>>>>>>>>> service function identifiers). This is more compliant with th= e > LB constraints above: > >>>>>>>>> deciding > >>>>>>>>>>> which locator to use for a given flow will be a local > >>>>>>>>>>> decision not a centralized one. > >>>>>>>>>> > >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. > >>>>>>>>>> > >>>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sfc mailing list > >>>>>>>>> sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sfc mailing list > >>>>>>>> sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing 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 Jul 10 09:07:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F31A0AA3 for ; Thu, 10 Jul 2014 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[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 xkaj1v4lhYqm for ; Thu, 10 Jul 2014 09:07:49 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151BD1A0A8C for ; Thu, 10 Jul 2014 09:07:49 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ae-53be6596f3bd Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FD.35.25146.6956EB35; Thu, 10 Jul 2014 12:06:14 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 12:07:44 -0400 From: Eric Gray To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8UZCMEh16X6U6IZxiYl3h/CpuXlPYAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgQCAAAEnAIAAAakAgAADFoCAAADNgIAABIYAgAADigCAAATCAIABKX+A//+9qOA= Date: Thu, 10 Jul 2014 16:07:43 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonSnda6r5gg6ZPRhZL56lbfDz1hsli 4+Q2RovDb5+yW1x4OpXZ4smDrewObB4vrjxj9njZP4fRY8rvjaweS5b8ZPI4N+U7o0fLs5Ns AWxRXDYpqTmZZalF+nYJXBnbL35gKWjzqVj99SxTA+Mt2y5GTg4JAROJL2efMULYYhIX7q1n 62Lk4hASOMooca71KguEs5xRYuPhCewgVWwCGhLH7qxlBEmICHQySuzqOsMM4jALdDNK7H59 EWyWsICNxM1/V1hBbBEBW4mOHXOZITrmMUo8m98HNopFQFWisXENM4jNK+Ar8fPVY2aIfVc5 JL5f7gBLcApESTzuXgZmMwJd+P3UGiYQm1lAXOLWk/lMEJcLSCzZc54ZwhaVePn4HyuErSix r386O0S9jsSC3Z/YIGxtiWULX0MtFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW 5aYbGW5iBEbfMQk2xx2MCz5ZHmIU4GBU4uFVSNkXLMSaWFZcmXuIUZqDRUmcV7N6XrCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxu7zb5as43F4V7R7o+6096Lc/BvWh9tztn44FsNolVn4 9YdwX84f9YsX0paYff7AvLgrSbHxdWho6DF3rs/pxtIX7l0IiylcwMrue/KWptyiZUqzpgT8 qnh8epveXs7TcQJrlH8tviVnpzLx7lqpUvnJ99kMnDgblz/Xfi/75JbWtbhd2emrPZVYijMS DbWYi4oTAd5IElqfAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tSpvn4jJTAdhRhAEUf8lo1kbUFE Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:07:52 -0000 Maria, Load distribution is not the same as service function chaining and - while = there may be problems to solve in this area - why would we assume that SFC is supposed t= o solve them? I think SFC should be more concerned about ensuring that function chaining = solutions=20 do not preclude load distribution. -- Eric -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA H Sent: Thursday, July 10, 2014 12:02 PM To: Jim Guichard (jguichar); Ron Parker Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers One of the main problems in "service chains" is how to implement a service = that is conceptually one hop but scaled horizontally as 10 or 100 different= VMs. So, IMO, if we are not addressing this problem than what are we solving. Maria > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, July 09, 2014 6:17 PM > To: Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H;=20 > sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > I should clarify that my statement was made as a personal opinion and=20 > it is up to the WG to evaluate if there exists anything at the=20 > architectural level that is new and therefore needs to be addressed. >=20 > Sent from my iPhone >=20 > > On Jul 9, 2014, at 6:01 PM, "Ron Parker" > wrote: > > > > Jim, > > > > Respectfully, I'm not comfortable with that. While it is easy to say = that > this is a layered problem and that load balancing belongs at a lower=20 > level, it seems to me that load balancing of the service functions=20 > (not load balancer as a service function) should be an explicit considera= tion of the SFC > architecture. I say this not only from a scale perspective, but also w= ith > resiliency in mind. > > > > Ron > > > > > > -----Original Message----- > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > Sent: Wednesday, July 09, 2014 5:48 PM > > To: Ron Parker > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; > NAPIERALA, MARIA H > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > I would say that's implementation. > > > > Sent from my iPhone > > > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" > wrote: > >> > >> Agreed. But is that in scope for SFC or out of scope for SFC? > >> > >> -----Original Message----- > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Wednesday, July 09, 2014 5:29 PM > >> To: Ron Parker > >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; > mohamed.boucadair@orange.com; > >> sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> Well of course not; in that case you load balance up a level=20 > >> between > those nodes and then locally. > >> > >> Sent from my iPhone > >> > >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" > wrote: > >>> > >>> Jim, > >>> > >>> There may not be a single node through which all of the instances=20 > >>> can > be reached (at some reasonable limit of L2 or L3 hops). > >>> > >>> Ron > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >>> (jguichar) > >>> Sent: Wednesday, July 09, 2014 5:12 PM > >>> To: NAPIERALA, MARIA H > >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> At the node through which the 20 instances are reachable. IOW you > don't have to individually address packets to each and every instance. > >>> > >>> Sent from my iPhone > >>> > >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" > wrote: > >>>> > >>>> Hi Jim, > >>>> > >>>> When you say "locally", where is it? > >>>> > >>>> Maria > >>>> > >>>>> -----Original Message----- > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >>>>> Sent: Wednesday, July 09, 2014 5:06 PM > >>>>> To: NAPIERALA, MARIA H > >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> Hi Maria, > >>>>> > >>>>> Absolutely and categorically no! If you have 20 instances at=20 > >>>>> each hop then you can choose to load balance among them locally=20 > >>>>> resulting in exactly 4 paths. What Joel is saying is that if for=20 > >>>>> some very odd and certainly not recommended reason you want to=20 > >>>>> treat each instance separately then the architecture does not > prevent it. > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > > >>>>> wrote: > >>>>> > >>>>>>> I am saying that if the 20 virtual firewalls are deployed=20 > >>>>>>> separately, then the service chaining infrastructure would=20 > >>>>>>> treat them as such, and would use distinct service paths. > >>>>>> > >>>>>> If I have a 4 hop service chain with 20 instances at each hop,=20 > >>>>>> then I have > >>>>> to globally manage 160,000 service paths (for one chain)? Well,=20 > >>>>> we have yet to see a solution that work this way and scales.. > >>>>>> > >>>>>> Maria > >>>>>> > >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > >>>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 > >>>>>>>> instances > >>>>>>> somewhere in the middle of a chain. Are you saying that you=20 > >>>>>>> will decide (make a load balancing decision) at the entry to=20 > >>>>>>> the chain which of those > >>>>> 20 > >>>>>>> firewalls will be used by a particular flow? > >>>>>>>> > >>>>>>>> Maria > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 > >>>>>>>>> Halpern > >>>>> Direct > >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM > >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > >>>>>>> sfc@ietf.org > >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> The archtiecture allows for this local decision, while still=20 > >>>>>>>>> having the global decision that is directing the traffic. =20 > >>>>>>>>> That is, the global decision directs the traffic to places=20 > >>>>>>>>> in the network. Those places may be singular or clusters. =20 > >>>>>>>>> If they are clusters, those clusters can use any number of=20 > >>>>>>>>> algorithms to distribute the traffic internally, without any=20 > >>>>>>>>> effect on service chaining. (And yes, this can be done in=20 > >>>>>>>>> such a way that return traffic, if delivered globally to the=20 > >>>>>>>>> same place, can then be delivered to the right internal=20 > >>>>>>>>> state.) > >>>>>>>>> > >>>>>>>>> The definition of the service path is about how service=20 > >>>>>>>>> chaining will direct the traffic. it is not about how the=20 > >>>>>>>>> internal load balancing is doen, as there are MANY ways to=20 > >>>>>>>>> do that, and they can give the same external interface. > >>>>>>>>> > >>>>>>>>> We could write the architecture pretending that it always=20 > >>>>>>>>> addresses singular instances, but knowing that reality would=20 > >>>>>>>>> allow load balanced clusters at those locations. But that=20 > >>>>>>>>> would be a misleading architectural description and might be=20 > >>>>>>>>> read to outlaw some solutions that fall within the goal the=20 > >>>>>>>>> WG > wishes to meet. > >>>>>>>>> > >>>>>>>>> Yours, > >>>>>>>>> Joel > >>>>>>>>> > >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>>> [Med] I still disagree that an ordered list of locators=20 > >>>>>>>>>>> can be > >>>>>>> determined > >>>>>>>>> in > >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding=20 > >>>>>>>>>>> be based > >>>>>>> on > >>>>>>>>> the > >>>>>>>>>>> service chain itself (characterized as an order list of=20 > >>>>>>>>>>> service function identifiers). This is more compliant with=20 > >>>>>>>>>>> the > LB constraints above: > >>>>>>>>> deciding > >>>>>>>>>>> which locator to use for a given flow will be a local=20 > >>>>>>>>>>> decision not a centralized one. > >>>>>>>>>> > >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. > >>>>>>>>>> > >>>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sfc mailing list > >>>>>>>>> sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sfc mailing list > >>>>>>>> sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing 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 Jul 10 09:09: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 2126C1A0AA3 for ; Thu, 10 Jul 2014 09:09:00 -0700 (PDT) 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 WE-32BYZHOg7 for ; Thu, 10 Jul 2014 09:08:59 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEB41A0AAC for ; Thu, 10 Jul 2014 09:08:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id B60FD1C9A0CD; Thu, 10 Jul 2014 09:08:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 8AAED1C9A0C8; Thu, 10 Jul 2014 09:08:57 -0700 (PDT) Message-ID: <53BEBA98.3060301@joelhalpern.com> Date: Thu, 10 Jul 2014 12:08:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.co m> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_53Rk2tivl2g4D6AyK4ZjT67M3M Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:09:00 -0000 That is clearly an important problem in building a full solution to the service chaining needs of operators (e.g. you). However, I could equally observe that if you do not have OSS/BSS capable of provisioning service chains, or charging systems capable of turning them into revenue, you can't offer them. The SFC working group is tasked with one part of the whole service chain definition, construction, and deployment problem. As I read the charter, general load balancing issues are not part of our scope. Given the number of different ways there are of doing load balancing, it would strike me as very odd for the sfc working group to standardize a particular answer to the important and difficult problem you point to. The architecture (and I believe most of the solutions) is designed to provide tools that help with managing that scaling, while also allowing for the use of other tools. If the working group wants us to be more specific in the load balancing architecture, then if the chairs tell us to we will add more specific text. I would be surprised personally if we had agreement on such a goal, or agreement on how to fill such a goal. But Carlos and I will of course do what the chairs tell us the WG wants. Yours, Joel On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote: > One of the main problems in "service chains" is how to implement a service that is conceptually one hop but scaled horizontally as 10 or 100 different VMs. > So, IMO, if we are not addressing this problem than what are we solving. > > Maria > From nobody Thu Jul 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 52A1A1A0AD7 for ; Thu, 10 Jul 2014 09:10:27 -0700 (PDT) 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 0Yaly6UHreRJ for ; Thu, 10 Jul 2014 09:10:24 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2EC1A0AA3 for ; Thu, 10 Jul 2014 09:10:24 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id ft15so4289307pdb.28 for ; Thu, 10 Jul 2014 09:10:24 -0700 (PDT) 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=Ev+XDpcsQAKpdnE/NDc5NRQ/UN4x2lFjcQxXiUgBr9M=; b=sNF7n/mEKKfwUtlkwtrLl7H6TWv6rc6Etvtl0NYUIwAoFRTwLDA/1USM/vbwUXb7de 6LEAo4QhrZv9gdP03d5OwYNudJKleujnHhMQe/Kqx33mGDYkGL5Z453ajUZjTRx/YdIO +os0lc79jJhzkvjeV5MkPK6Ve3/DqPSnCzyJalFk1kJtJml4h6xQFwKyLIw6jkoHGA6K b+SvsWr9rgFukraVV7WYWQYm+0hPF5Li52n4bNjXaxal4tO2ISDwLyAiYCQNJZq/KWmc 2ujClUmzBOL4n8FSleP5Lq5DOfnT5Xj/T8oTpb3oMlGojfASfDq1LUjPl8w4ByprdU1y K5nA== X-Received: by 10.68.133.7 with SMTP id oy7mr48170701pbb.43.1405008622400; Thu, 10 Jul 2014 09:10:22 -0700 (PDT) Received: from ?IPv6:2600:1010:b009:a8e3:44f5:e69e:9c7d:a9a9? ([2600:1010:b009:a8e3:44f5:e69e:9c7d:a9a9]) by mx.google.com with ESMTPSA id s10sm33024023pdr.15.2014.07.10.09.10.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 09:10:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11D257) In-Reply-To: <53BEA00D.9030309@joelhalpern.com> Date: Thu, 10 Jul 2014 09:10:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53BCAB74.4060801@joelhalpern.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <53BDF58D.7070108@joelhalpern.com> <53BEA00D.9030309@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XLR1BMupRRDCJhR8oLXka9PcJO4 Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , Ron Parker , "mohamed.boucadair@orange.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:10:27 -0000 Joel I agree 100%. Unfortunately I do see both of these ("really bad") extremes in prominent in= dustry forums dealing with inline network functions. These extremes as you s= tated are 1) expecting a centralized system to orchestrate an explosive amou= nt of static permutations, truly an NP undertaking - good luck .. and 2) put= ting forth such fragmented solutions of vSwitches, ADC-VMs, and NF-VMs, that= grantee the network back-pressures and blocks application demand. I think t= his group/docs/forum can provide the better guidance. --szb > On Jul 10, 2014, at 7:15, "Joel M. Halpern" wrote: >=20 > There are things permitted by th architecture which would be a REALLY BAD I= DEA in practice. As far as I can tell, all of the solutions people would li= ke to use for this also have the property that there are ways to deploy them= which would be REALLY BAD IDEAS. >=20 > To take an extreme example, any architecture and any solution we define fo= r service chaining will likely allow folks to expose a cominatorial explosio= n of instances if they insist in their deployment on moving all selection at= all levels of granularity to whatever central point the solution has. Give= n that all solutions have some amount of central provisioning and control, a= ll solutions allow such. I presume that none of them would mandate such. >=20 > So observing that taken to an extreme and applied badly the archtiecture a= llows solutions with really bad properties will be true even when the wrokin= g group finishes their work. >=20 > Yours, > Joel >=20 >> On 7/10/14, 1:32 AM, Sharon wrote: >>=20 >> If I understand correctly, the dilemma is that >> - on one hand there is no limit to what is meant by "load-balancing": >> It may be a deep application content changing function, or a simple NAT o= f VIPs. >> - On the other a static architecture is too rigid to scale and make highl= y available. >>=20 >> It may lead to too much "hair splitting" . >> To take it to extreme, in a distributed overlay network with SFFs scatte= red in enough locations, >> but not in every host, a single service-function hop can be: >>=20 >> SFF - NVE - NVE - SLB - NVE - NVE - NF - NVE - NVE - SFF >>=20 >> If implemented literally the latency-jitter and consequently utilization w= ill be quite bad. >>=20 >> So a language that allows an SFF to work with balanced VNF pools, >> and that allows for multi-home SFF to VNF pooling can help. >>=20 >>=20 >>=20 >> --szb >>=20 >>> On Jul 9, 2014, at 19:08, "Joel M. Halpern" wrote:= >>>=20 >>> THere are multiple ways that the internal redundancy with the load balan= cers can be implemented. Any of them can be used with the service chaining a= rchitecture. >>> There may be some aspects which need to be covered in the solution work.= >>> For example, I would expect solutions to have to discuss how we cope wit= h SFF failure. And with failure of the linkage between the SFF and the SF. >>>=20 >>> We could add text to the architecture indicating that solutions will nee= d to be robust in dealing with failures of service chaining components and l= inkages. But I think we should not spell out the detailed mechanisms for th= at robustness in this document. >>>=20 >>> Would adding a small section on robustness issues help? >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 7/9/14, 7:28 PM, Ron Parker wrote: >>>> Ken, >>>>=20 >>>> As I pointed out in my previous email, my concern is more about resilie= ncy than elasticity. I understand the benefits of layered load balancing, b= ut what about when this is hierarchical? Maria spoke of 20 instances, and t= he prevailing thinking seems to be that the top-level behavior of the SFC sh= ouldn't care. But what if the front-end entity fails? What if its intern= al redundancy, if any, fails to perform when called upon? Might the networ= k designer choose to divide the 20 instances into 2 groupings of 10 and have= a front-end entity for each grouping? So now the top-level behavior of th= e SFC must choose amongst 2 rather than 20 for this particular logical servi= ce function. But a choice still needs to be made. Is this, too, outside t= he scope of SFC? If not, is the architecture going to explicitly address i= t, or leave it as an implementation issue? >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> ________________________________________ >>>> From: Ken Gray (kegray) [kegray@cisco.com] >>>> Sent: Wednesday, July 09, 2014 6:39 PM >>>> To: Ron Parker; Jim Guichard (jguichar) >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, MARIA H;= sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> The whole idea of dynamic elasticity control is to hide this detail fro= m >>>> you and to make the instances ephemeral. >>>>=20 >>>> When you send a packet from your classifier to my elastic firewall, the= >>>> component(s) that make it elastic are what you address =C5=A0 the elast= ic >>>> control of my elastic firewall picks the instance based on it's own loc= al >>>> policy or higher level orchestration/policy control at an >>>> out-of-scope-above-the-line-for-sfc layer. >>>>=20 >>>> Yes, I can layer this abstraction to scale to a very, very large number= of >>>> instances and still present a single addressable point of distribution.= >>>>=20 >>>> The very scale problem you mention is what the scheme addresses, yet we= >>>> seem to be wanting to peel that away. >>>>=20 >>>> As Jim stated, IF you want to separately address each instance (with >>>> either the explosion of paths or the huge feedback loop from orchestrat= ion >>>> and control, central micro-flow control, volume of changes to your >>>> classifiers, etc.) - go for it. The architecture allows it. Has to. >>>> Some people might deploy that way. >>>>=20 >>>> The very basic point made in the original argument is "you don't have t= o >>>> do that". >>>>=20 >>>> This is readily demonstrable (I or a number of other vendors can send a= >>>> sales guy to do a demo). >>>>=20 >>>> What I won't agree to here is that elasticity somehow creates an >>>> unknowable path element. It shouldn't unless you did it wrong. Maybe >>>> there's a better example that might justify substituting the chain for t= he >>>> path (and then dynamically resolving this in the background adding huge= >>>> scale considerations) =C5=A0but it's not elasticity. >>>>=20 >>>>> On 7/9/14 6:00 PM, "Ron Parker" wrot= e: >>>>>=20 >>>>> Jim, >>>>>=20 >>>>> Respectfully, I'm not comfortable with that. While it is easy to say= >>>>> that this is a layered problem and that load balancing belongs at a lo= wer >>>>> level, it seems to me that load balancing of the service functions (no= t >>>>> load balancer as a service function) should be an explicit considerati= on >>>>> of the SFC architecture. I say this not only from a scale perspecti= ve, >>>>> but also with resiliency in mind. >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>>> To: Ron Parker >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>>>> NAPIERALA, MARIA H >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> I would say that's implementation. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>>>>> wrote: >>>>>>=20 >>>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>>> To: Ron Parker >>>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com= ; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Well of course not; in that case you load balance up a level between >>>>>> those nodes and then locally. >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>>>>>> wrote: >>>>>>>=20 >>>>>>> Jim, >>>>>>>=20 >>>>>>> There may not be a single node through which all of the instances ca= n >>>>>>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>>>> (jguichar) >>>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>>> To: NAPIERALA, MARIA H >>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>=20 >>>>>>> At the node through which the 20 instances are reachable. IOW you >>>>>>> don't have to individually address packets to each and every instanc= e. >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi Jim, >>>>>>>>=20 >>>>>>>> When you say "locally", where is it? >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>=20 >>>>>>>>> Hi Maria, >>>>>>>>>=20 >>>>>>>>> Absolutely and categorically no! If you have 20 instances at each >>>>>>>>> hop then you can choose to load balance among them locally >>>>>>>>> resulting in exactly 4 paths. What Joel is saying is that if for >>>>>>>>> some very odd and certainly not recommended reason you want to >>>>>>>>> treat each instance separately then the architecture does not >>>>>>>>> prevent it. >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>>> separately, then the service chaining infrastructure would treat= >>>>>>>>>>> them as such, and would use distinct service paths. >>>>>>>>>>=20 >>>>>>>>>> If I have a 4 hop service chain with 20 instances at each hop, >>>>>>>>>> then I have >>>>>>>>> to globally manage 160,000 service paths (for one chain)? Well, we= >>>>>>>>> have yet to see a solution that work this way and scales.. >>>>>>>>>>=20 >>>>>>>>>> Maria >>>>>>>>>>=20 >>>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>>> instances >>>>>>>>>>> somewhere in the middle of a chain. Are you saying that you will= >>>>>>>>>>> decide (make a load balancing decision) at the entry to the chai= n >>>>>>>>>>> which of those >>>>>>>>> 20 >>>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>>>=20 >>>>>>>>>>>> Maria >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>>> Halpern >>>>>>>>> Direct >>>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The archtiecture allows for this local decision, while still >>>>>>>>>>>>> having the global decision that is directing the traffic. Tha= t >>>>>>>>>>>>> is, the global decision directs the traffic to places in the >>>>>>>>>>>>> network. Those places may be singular or clusters. If they >>>>>>>>>>>>> are clusters, those clusters can use any number of algorithms >>>>>>>>>>>>> to distribute the traffic internally, without any effect on >>>>>>>>>>>>> service chaining. (And yes, this can be done in such a way >>>>>>>>>>>>> that return traffic, if delivered globally to the same place, >>>>>>>>>>>>> can then be delivered to the right internal state.) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to do >>>>>>>>>>>>> that, and they can give the same external interface. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>>> addresses singular instances, but knowing that reality would >>>>>>>>>>>>> allow load balanced clusters at those locations. But that >>>>>>>>>>>>> would be a misleading architectural description and might be >>>>>>>>>>>>> read to outlaw some solutions that fall within the goal the WG= >>>>>>>>>>>>> wishes to meet. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators can >>>>>>>>>>>>>>> be >>>>>>>>>>> determined >>>>>>>>>>>>> in >>>>>>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding b= e >>>>>>>>>>>>>>> based >>>>>>>>>>> on >>>>>>>>>>>>> the >>>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>>> service function identifiers). This is more compliant with t= he >>>>>>>>>>>>>>> LB constraints above: >>>>>>>>>>>>> deciding >>>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Maria >>>>>>>>>>>>>=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 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 From nobody Thu Jul 10 09:29: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 C95C61A0ABA for ; Thu, 10 Jul 2014 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onLaTTuQfBSS for ; Thu, 10 Jul 2014 09:29:05 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC031A0A8D for ; Thu, 10 Jul 2014 09:29:05 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 15fbeb35.2b15ee00f940.8411278.00-2495.20070123.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 16:29:05 +0000 (UTC) X-MXL-Hash: 53bebf5124a779ea-e785029d4e5be8b5c6b7228d3ff2425d89a9d5bd Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e4fbeb35.0.8411249.00-2315.20070008.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 16:29:03 +0000 (UTC) X-MXL-Hash: 53bebf4f632cbeb2-904999b8d0d4e8298e24fb697d9f9af09fab149d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AGT1pK004992; Thu, 10 Jul 2014 12:29:02 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AGSoVt004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 12:28:57 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 16:28:46 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 12:28:46 -0400 From: "NAPIERALA, MARIA H" To: Eric Gray , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuXlPYAgACF5yCAAE1ZAP//wLSggABL5AD//7770IAATBoA//+9cIAACIceAAAANQwAAABiy4AAABmigAAAkLAAAABxQAAAAJhKAAAcmPkgAAjJAIAAB+HpoA== Date: Thu, 10 Jul 2014 16:28:46 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=AUd_NHdVAAAA:8 ] X-AnalysisOut: [a=qN95wPeSAAAA:8 a=lCVHcScF5pLyOQ2yAqcA:9 a=CjuIK1q_8ugA:1] X-AnalysisOut: [0 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=JfD0Fch1gWkA:10 a=] X-AnalysisOut: [paC5pjApGzsA:10 a=Hz7IrDYlS0cA:10 a=lsCL9cybL2aljsAU:21 a=] X-AnalysisOut: [JTwklScyLyBMkEt1:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/o3JEPUIoCt1OZKNJKBojj0oyCY0 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:29:07 -0000 Eric, > Load distribution is not the same as service function chaining and - whil= e > there may be > problems to solve in this area - why would we assume that SFC is supposed > to solve > them? Because this is the fundamental problem in service chaining in virtualized = environments. =20 I would be cautious to leave it just to implementation because if fundament= als are wrong implementation might not be able to help. > I think SFC should be more concerned about ensuring that function > chaining solutions > do not preclude load distribution. How would you ensure it? >=20 > -- > Eric >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA H > Sent: Thursday, July 10, 2014 12:02 PM > To: Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > One of the main problems in "service chains" is how to implement a servic= e > that is conceptually one hop but scaled horizontally as 10 or 100 differe= nt > VMs. > So, IMO, if we are not addressing this problem than what are we solving. >=20 > Maria >=20 > > -----Original Message----- > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > Sent: Wednesday, July 09, 2014 6:17 PM > > To: Ron Parker > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, > MARIA H; > > sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > I should clarify that my statement was made as a personal opinion and > > it is up to the WG to evaluate if there exists anything at the > > architectural level that is new and therefore needs to be addressed. > > > > Sent from my iPhone > > > > > On Jul 9, 2014, at 6:01 PM, "Ron Parker" > > wrote: > > > > > > Jim, > > > > > > Respectfully, I'm not comfortable with that. While it is easy to sa= y that > > this is a layered problem and that load balancing belongs at a lower > > level, it seems to me that load balancing of the service functions > > (not load balancer as a service function) should be an explicit > consideration of the SFC > > architecture. I say this not only from a scale perspective, but also= with > > resiliency in mind. > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > Sent: Wednesday, July 09, 2014 5:48 PM > > > To: Ron Parker > > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; > > NAPIERALA, MARIA H > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > I would say that's implementation. > > > > > > Sent from my iPhone > > > > > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" > > wrote: > > >> > > >> Agreed. But is that in scope for SFC or out of scope for SFC? > > >> > > >> -----Original Message----- > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >> Sent: Wednesday, July 09, 2014 5:29 PM > > >> To: Ron Parker > > >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; > > mohamed.boucadair@orange.com; > > >> sfc@ietf.org > > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >> > > >> Well of course not; in that case you load balance up a level > > >> between > > those nodes and then locally. > > >> > > >> Sent from my iPhone > > >> > > >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" > > wrote: > > >>> > > >>> Jim, > > >>> > > >>> There may not be a single node through which all of the instances > > >>> can > > be reached (at some reasonable limit of L2 or L3 hops). > > >>> > > >>> Ron > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > > >>> (jguichar) > > >>> Sent: Wednesday, July 09, 2014 5:12 PM > > >>> To: NAPIERALA, MARIA H > > >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >>> > > >>> At the node through which the 20 instances are reachable. IOW you > > don't have to individually address packets to each and every instance. > > >>> > > >>> Sent from my iPhone > > >>> > > >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" > > wrote: > > >>>> > > >>>> Hi Jim, > > >>>> > > >>>> When you say "locally", where is it? > > >>>> > > >>>> Maria > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >>>>> Sent: Wednesday, July 09, 2014 5:06 PM > > >>>>> To: NAPIERALA, MARIA H > > >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; > sfc@ietf.org > > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>>> > > >>>>> Hi Maria, > > >>>>> > > >>>>> Absolutely and categorically no! If you have 20 instances at > > >>>>> each hop then you can choose to load balance among them locally > > >>>>> resulting in exactly 4 paths. What Joel is saying is that if for > > >>>>> some very odd and certainly not recommended reason you want to > > >>>>> treat each instance separately then the architecture does not > > prevent it. > > >>>>> > > >>>>> Sent from my iPhone > > >>>>> > > >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > > > > >>>>> wrote: > > >>>>> > > >>>>>>> I am saying that if the 20 virtual firewalls are deployed > > >>>>>>> separately, then the service chaining infrastructure would > > >>>>>>> treat them as such, and would use distinct service paths. > > >>>>>> > > >>>>>> If I have a 4 hop service chain with 20 instances at each hop, > > >>>>>> then I have > > >>>>> to globally manage 160,000 service paths (for one chain)? Well, > > >>>>> we have yet to see a solution that work this way and scales.. > > >>>>>> > > >>>>>> Maria > > >>>>>> > > >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > > >>>>>>>> I had in mind singular instances, say, 20 virtual firewall > > >>>>>>>> instances > > >>>>>>> somewhere in the middle of a chain. Are you saying that you > > >>>>>>> will decide (make a load balancing decision) at the entry to > > >>>>>>> the chain which of those > > >>>>> 20 > > >>>>>>> firewalls will be used by a particular flow? > > >>>>>>>> > > >>>>>>>> Maria > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel > > >>>>>>>>> Halpern > > >>>>> Direct > > >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM > > >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > > >>>>>>> sfc@ietf.org > > >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>>>>>>> > > >>>>>>>>> The archtiecture allows for this local decision, while still > > >>>>>>>>> having the global decision that is directing the traffic. > > >>>>>>>>> That is, the global decision directs the traffic to places > > >>>>>>>>> in the network. Those places may be singular or clusters. > > >>>>>>>>> If they are clusters, those clusters can use any number of > > >>>>>>>>> algorithms to distribute the traffic internally, without any > > >>>>>>>>> effect on service chaining. (And yes, this can be done in > > >>>>>>>>> such a way that return traffic, if delivered globally to the > > >>>>>>>>> same place, can then be delivered to the right internal > > >>>>>>>>> state.) > > >>>>>>>>> > > >>>>>>>>> The definition of the service path is about how service > > >>>>>>>>> chaining will direct the traffic. it is not about how the > > >>>>>>>>> internal load balancing is doen, as there are MANY ways to > > >>>>>>>>> do that, and they can give the same external interface. > > >>>>>>>>> > > >>>>>>>>> We could write the architecture pretending that it always > > >>>>>>>>> addresses singular instances, but knowing that reality would > > >>>>>>>>> allow load balanced clusters at those locations. But that > > >>>>>>>>> would be a misleading architectural description and might be > > >>>>>>>>> read to outlaw some solutions that fall within the goal the > > >>>>>>>>> WG > > wishes to meet. > > >>>>>>>>> > > >>>>>>>>> Yours, > > >>>>>>>>> Joel > > >>>>>>>>> > > >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > > >>>>>>>>>>> [Med] I still disagree that an ordered list of locators > > >>>>>>>>>>> can be > > >>>>>>> determined > > >>>>>>>>> in > > >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding > > >>>>>>>>>>> be based > > >>>>>>> on > > >>>>>>>>> the > > >>>>>>>>>>> service chain itself (characterized as an order list of > > >>>>>>>>>>> service function identifiers). This is more compliant with > > >>>>>>>>>>> the > > LB constraints above: > > >>>>>>>>> deciding > > >>>>>>>>>>> which locator to use for a given flow will be a local > > >>>>>>>>>>> decision not a centralized one. > > >>>>>>>>>> > > >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. > > >>>>>>>>>> > > >>>>>>>>>> Maria > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> sfc mailing list > > >>>>>>>>> sfc@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> sfc mailing list > > >>>>>>>> sfc@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> sfc mailing list > > >>>>>> sfc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >> > > >> _______________________________________________ > > >> sfc mailing 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 From nobody Thu Jul 10 09: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 23CF61A0ABA for ; Thu, 10 Jul 2014 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 Toynz1kbZm79 for ; Thu, 10 Jul 2014 09:31:28 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4861A0A8D for ; Thu, 10 Jul 2014 09:31:27 -0700 (PDT) Received: from ideaPC ([12.139.169.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AGVG3b004655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jul 2014 12:31:17 -0400 From: "Changcheng Huang" To: "'Ron Parker'" , "'Lucy yong'" , , , , References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> In-Reply-To: Date: Thu, 10 Jul 2014 09:31:19 -0700 Message-ID: <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0780_01CF9C21.B5F1A4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPKnc9O86h9HhZKctqiuOXhtKs0QIhBMaJAdQSyHsCFnGOLQJbcE42m1cn9QA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/u0Yv7Xm5_1HWpKZZ4PbHASLgDNE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:31:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0780_01CF9C21.B5F1A4C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Ron=E2=80=99s comments. Service functions should make the = decision about which instances will be used. It can be different = hop-by-hop (e.g. in a tree topology). In order to do so, it is important = a physical network makes a service function chain aware of the available = instances. These is no need to identify each possible SFP by a physical = network. If a service function chain wants to use multiple SFPs, it = should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, = because a physical network need to support multiple tenants, it does = need to identify different tenants. Our recent contribution = (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-serv= ice/ ) has discussed this issue in a more general architecture. Hope it = can be helpful for this discussion. =20 Chang=20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; = jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 It is architecturally significant to identify that multiple addressable = instances of a service function are explicitly allowed. Whether those = instance perform some further level of load balancing is irrelevant, as = has been pointed out by Joel. It is also architecturally significant = to assign responsibility for instance selection. In particular, is = the instance selection centralized, distributed, or some combination? = Which functional entities in the architecture have what responsibilities = to achieve this? In November, 2013, after IETF 88, I submitted this = draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, = which proposed that the instance selection was made hop by hop by the = service functions themselves, in a fully distributed manner. That was = just a proposal and I am not wedded to it, by any means. Joel asked = about specificity and it is at this level that I=E2=80=99d like to see = the architecture describe things. It should be able to answer the = question, =E2=80=9Chow does multi-instance selection work in = SFC?=E2=80=9D in a concise manner. If the group feels that there = should be more than one answer to that question, so be it, but we should = be able to describe the high level mechanism and rationale for each = succinctly. Of course, that is merely one such question and there are = many others that an architectural document should be able to describe. =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mikebianc@aol.com; = jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Agree. The arch. doc should not mandate only use of the service path = identifier to drive the forwarding actions. =20 Lucy =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Re-, =20 The merged draft calls out explicitly a service path identifier. I = object to use that identifier to derive forwarding actions.=20 =20 Requiring a SFC system to have the full knowledge of every available SFC = forwarding paths within an SFC-enabled domain is not required/justified = nor possible in various deployment contexts. =20 SFC forwarding actions should rely on the piece of information that will = be present in all deployments: that is the one required to structure a = service chain. How that information is used to infer forwarding actions = is a solution-oriented discussion. =20 Cheers, Med =20 De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers =20 Is anyone still questioning the difference between SF Chain and SF Path? = Other than clarifying the definition so that it's clear to those not = familiar with the draft, it seems that everyone agrees on these terms. =20 To me, the one point that is still unclear is whether it is the intent = of this draft to ultimately specify what the ID of the SFC Header should = reference (the chain or the path), or if this draft simply intends to = leave that ambiguous, allowing other drafts to dictate the mechanisms = for forwarding based on chain or path and the choice of chain or path to = be negotiated in the control-plane. =20 =20 If the latter (ambiguous), then the draft would have require that both = SFP and SFC be supported (or make one required and the other optional) = to avoid some vendors only supporting SFP and others only supporting = SFC. =20 =20 =20 _____ =20 From: jmh@joelhalpern.com = To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. But what do we intend? I will try to explain my personal view, and see=20 if that helps. In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used = in any solution. 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to = think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without = visiting any other service functions. That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_NextPart_000_0780_01CF9C21.B5F1A4C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I agree with Ron=E2=80=99s comments. Service functions should make = the decision about which instances will be used. It can be different = hop-by-hop (e.g. in a tree topology). In order to do so, it is important = a physical network makes a service function chain aware of the available = instances. These is no need to identify each possible SFP by a physical = network. If a service function chain wants to use multiple SFPs, it = should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, = because a physical network need to support multiple tenants, it does = need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-re= cursive-service/ ) has discussed this issue in a more general = architecture. Hope it can be helpful for this = discussion.

 

Chang

 

From:= = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron = Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: = Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; = jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service = Chains, Paths, and Load Balancers

 

It is architecturally significant to identify that multiple = addressable instances of a service function are explicitly = allowed.   Whether those instance perform some further level = of load balancing is irrelevant, as has been pointed out by = Joel.    It is also architecturally significant to assign = responsibility for instance selection.    In particular, = is the instance selection centralized, distributed, or some combination? =   Which functional entities in the architecture have what = responsibilities to achieve this?   In November, 2013, after = IETF 88, I submitted this draft, htt= p://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which = proposed that the instance selection was made hop by hop by the service = functions themselves, in a fully distributed manner.   That = was just a proposal and I am not wedded to it, by any means. =    Joel asked about specificity and it is at this level = that I=E2=80=99d like to see the architecture describe = things.   It should be able to answer the question, = =E2=80=9Chow does multi-instance selection work in SFC?=E2=80=9D in a = concise manner.   If the group feels that there should be more = than one answer to that question, so be it, but we should be able to = describe the high level mechanism and rationale for each = succinctly.    Of course, that is merely one such = question and there are many others that an architectural document should = be able to describe.

 

   Ron

 

 

From: sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 = 11:05 AM
To: mohamed.boucadair@orange.com= ; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: = [sfc] Service Chains, Paths, and Load = Balancers

 

Agree. The arch. doc should not mandate only use of the service path = identifier to drive the forwarding actions.

 

Lucy

 

From:= = sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: = [sfc] Service Chains, Paths, and Load = Balancers

 

Re-,

 

The merged draft calls out explicitly a service path = identifier. I object to use that identifier to derive forwarding = actions.

 

Requiring a SFC system to have the full knowledge of = every available SFC forwarding paths within an SFC-enabled domain is not = required/justified nor possible in various deployment = contexts.

 

SFC forwarding actions should rely on the piece of = information that will be present in all deployments: that is the one = required to structure a service chain. How that information is used to = infer forwarding actions is a solution-oriented = discussion.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] = De la part de mikebianc@aol.com
Envoy=C3=A9=  : mercredi 9 juillet 2014 22:03
=C3=80 : jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: = [sfc] Service Chains, Paths, and Load = Balancers

 

Is anyone = still questioning the difference between SF Chain and SF Path? =  Other than clarifying the definition so that it's clear to those = not familiar with the draft, it seems that everyone agrees on these = terms.

 

To me, the = one point that is still unclear is whether it is the intent of this = draft to ultimately specify what the ID of the SFC Header should = reference (the chain or the path), or if this draft simply intends to = leave that ambiguous, allowing other drafts to dictate the mechanisms = for forwarding based on chain or path and the choice of chain or path to = be negotiated in the control-plane. =  

 

If the = latter (ambiguous), then the draft would have require that both SFP and = SFC be supported (or make one required and the other optional) to avoid = some vendors only supporting SFP and others only supporting = SFC.

 

 

 

From: jmh@joelhalpern= .com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org<= /a>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] = Service Chains, Paths, and Load Balancers

I have been trying to = figure out how to clearly answer a number of
comments that have been = made about the proposed merged archtiecture
draft. Assuming we can = get working group agreement on the intent, we
will work to improve = the wording so that readers who have not
participated in the WG = discussion will understnd it the way the working
group = intends.

But what do we intend? I will try to explain my personal = view, and see
if that helps.

In this regard, it is important = to keep in mind that what we are
defining is the data plane = architecture. We are not attempting to
define the architecture for = the entire solution for service chaining.
That would encompass = OSS/BSS, various control and policy functions,
virtual machine and = image management, and many other aspects.

As a result there are = many things which clearly need to exist in the
larger system, but = which are dealt with above where we are functioning,
and are not = directly required by the work we are doing.

In order to get to = service chain vs service path, as I understand them,
I need to first = discuss load balancing. There are at least three
different ways that = load balancing can and will interact with service
chaining. There = probably are more. The point of the archtiecture is to
permit all of = these, but not to mandate that any particular kind be used
in any = solution.

1) Load balancing as a service provided to the end = user. This is a
service function. It receives user packets, and = modifies them (or marks
them, or ...) so as to choose an end user = service instance to receive
the users packet. This is an important = service function to be able to
include in service chaining. It's = behavior may affect requirements on
how service chaining is done. = But it has very little impact on the
archtiecture. From an = architectural pe3rspective it is simply a service
function which may = modify the underlying packet.

2) There is internal load = balancing. That is, one can have what appears
to the service = chaining architecture as a single point of contact for a
specific = service function, but is actually delivered by a collection of =
virtual or physical machines, possibly including one or several load =
balancers (for example using VRRP-like techniques to share a MAC =
address.) mostly, this is invisible to the service chaining data = plane
mechanisms. It is likely that it is visible to various control =
mechanisms, such as those responsible for scale-in, scale-out, and = vm
instantiation. The architectural impact of permitting this is = largely
that we need to be careful that our terminology does not = lead readers to
think we are prohibiting it.

3) There can = also be load balancing done by selecting packet paths for
the = service chaining that direct traffic to different places. We would =
not want to require that a given service function appear at only one =
place in the network.

It is of course the case that these may = be combined. I tend to refer to
the collection of entities that = appear to service chaining as a single
point as a cluster. Not = because cluster is a good term. But because I
do not have another = one. Thus, the point of type 3 load balancing is to
direct different = subsets of traffic to different singular or clustered
service = functions in different places in the network.

Now with that said, = what do I mean when I talk about service chain and
service path/ = Service chain is a sequence of logical functions to be
applied to a = subset of packets. It is equivalent of saying that some
subset of = traffic is to get DPI, charging, content inspection, and
firewall = while a different subset is to go directly to the cache without =
visiting any other service functions.

That is not enough = information to direct the packets. A service path
is, in some = fashion, a sequence of locations in the network. Those
locations = will be singular or clustered service function delivery
locations. = They may be addressed by IP address. They may be addressed
as ports = on an SFF. There are many different ways that the locations
may be = known to the service chaining infrastructure and the = transport.

From the point of view of the work of the SFC group, = we need to be able
to talk about the high level abstraction, the = service chain, which
drives the forwarding. And we need to talk = about the actual data path
packets will take in the = network.

Several of the comments have said "but the whole = path may not be known
at the front." This architecture deals = with that issue in two ways.
First, as noted in item (2) on load = balancers above, there can be
decisions and behaviors which are = invisible to the service chaining
mechanisms (in much the same way = that bridging within a LAN is largely
invisible to routing between = LANs.) The other provision we make is that
reclassification can be = done in mid-chain when necessary. That will
direct packets to a new = chain. Based on information available at the
re-classification = point.

I hope that this helps explain what we are after. If it = does, and if
the intent is acceptable to the working group, we can = figure out what
additional words are needed to convey this.
If = the working group disagree with the intent, then we will of course =
adjust to match the working group agreements.
If this is still = unclear, I am not sure what to try = next.

Yours,
Joel

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/m= ailman/listinfo/sfc

------=_NextPart_000_0780_01CF9C21.B5F1A4C0-- From nobody Thu Jul 10 09:48: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 61AC21A0B14 for ; Thu, 10 Jul 2014 09:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 q7NqNRBTS_Tu for ; Thu, 10 Jul 2014 09:47:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923BB1A0AB4 for ; Thu, 10 Jul 2014 09:47:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGZ55142; Thu, 10 Jul 2014 16:47:57 +0000 (GMT) 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, 10 Jul 2014 17:47:55 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 09:47:53 -0700 From: Lucy yong To: Changcheng Huang , "'Ron Parker'" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYoIgAgAC5UYCAABDHYIAAeT4AgAAT/YD//44k0A== Date: Thu, 10 Jul 2014 16:47:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BE3BB@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> In-Reply-To: <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.67] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453BE3BBdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DekDPUcGgC1r-Tt1PfGuQPvIN3A Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:48:03 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453BE3BBdfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSBSb246IEl0IHNob3VsZCBiZSBhYmxlIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sIOKAnGhv dyBkb2VzIG11bHRpLWluc3RhbmNlIHNlbGVjdGlvbiB3b3JrIGluIFNGQz/igJ0gaW4gYSBjb25j aXNlIG1hbm5lci4NCg0KSG93IGFib3V0OiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBpbXBsZW1l bnRpbmcgc2luZ2xlIFNGUCBvciBtdWx0aXBsZSBTRlBzIHRvIHN1cHBvcnQgU0YgbXVsdGktaW5z dGFuY2VzIGluIFNGQy4gSW4gdGhlIGZpcnN0IGNhc2UsIGluc3RhbmNlIHNlbGVjdGlvbiBpcyBv cGFxdWUgdG8gdGhlIFNGUDsgaW4gbGF0dGVyIGNhc2UsIGluc3RhbmNlIHNlbGVjdGlvbiwgaW4g dHVybiwgYmVjb21lcyBTRlAgc2VsZWN0aW9uLg0KDQpMdWN5DQpGcm9tOiBDaGFuZ2NoZW5nIEh1 YW5nIFttYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhXQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgMTE6MzEgQU0NClRvOiAnUm9uIFBhcmtlcic7IEx1Y3kgeW9uZzsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgbWlrZWJpYW5jQGFvbC5jb207IGptaEBqb2VsaGFscGVybi5j b207IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkgYWdyZWUgd2l0aCBSb27igJlzIGNvbW1lbnRzLiBT ZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgbWFrZSB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggaW5z dGFuY2VzIHdpbGwgYmUgdXNlZC4gSXQgY2FuIGJlIGRpZmZlcmVudCBob3AtYnktaG9wIChlLmcu IGluIGEgdHJlZSB0b3BvbG9neSkuIEluIG9yZGVyIHRvIGRvIHNvLCBpdCBpcyBpbXBvcnRhbnQg YSBwaHlzaWNhbCBuZXR3b3JrIG1ha2VzIGEgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBhd2FyZSBv ZiB0aGUgYXZhaWxhYmxlIGluc3RhbmNlcy4gVGhlc2UgaXMgbm8gbmVlZCB0byBpZGVudGlmeSBl YWNoIHBvc3NpYmxlIFNGUCBieSBhIHBoeXNpY2FsIG5ldHdvcmsuIElmIGEgc2VydmljZSBmdW5j dGlvbiBjaGFpbiB3YW50cyB0byB1c2UgbXVsdGlwbGUgU0ZQcywgaXQgc2hvdWxkIHByb3ZpZGUg dGhlIGlkZW50aWZpZXIgZm9yIGVhY2ggZmxvdyB0aGF0IHVzZXMgYSBwYXJ0aWN1bGFyIFNGUCBh bmQgdGhlIGNvcnJlc3BvbmRpbmcgZm9yd2FyZGluZyBydWxlcyAoaS5lLiBuZXh0IGhvcCkuIE5l dmVydGhlbGVzcywgYmVjYXVzZSBhIHBoeXNpY2FsIG5ldHdvcmsgbmVlZCB0byBzdXBwb3J0IG11 bHRpcGxlIHRlbmFudHMsIGl0IGRvZXMgbmVlZCB0byBpZGVudGlmeSBkaWZmZXJlbnQgdGVuYW50 cy4gT3VyIHJlY2VudCBjb250cmlidXRpb24gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS8gKSBoYXMgZGlz Y3Vzc2VkIHRoaXMgaXNzdWUgaW4gYSBtb3JlIGdlbmVyYWwgYXJjaGl0ZWN0dXJlLiBIb3BlIGl0 IGNhbiBiZSBoZWxwZnVsIGZvciB0aGlzIGRpc2N1c3Npb24uDQoNCkNoYW5nDQoNCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0K U2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgODoyMCBBTQ0KVG86IEx1Y3kgeW9uZzsgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJdCBpcyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlm aWNhbnQgdG8gaWRlbnRpZnkgdGhhdCBtdWx0aXBsZSBhZGRyZXNzYWJsZSBpbnN0YW5jZXMgb2Yg YSBzZXJ2aWNlIGZ1bmN0aW9uIGFyZSBleHBsaWNpdGx5IGFsbG93ZWQuICAgV2hldGhlciB0aG9z ZSBpbnN0YW5jZSBwZXJmb3JtIHNvbWUgZnVydGhlciBsZXZlbCBvZiBsb2FkIGJhbGFuY2luZyBp cyBpcnJlbGV2YW50LCBhcyBoYXMgYmVlbiBwb2ludGVkIG91dCBieSBKb2VsLiAgICBJdCBpcyBh bHNvIGFyY2hpdGVjdHVyYWxseSBzaWduaWZpY2FudCB0byBhc3NpZ24gcmVzcG9uc2liaWxpdHkg Zm9yIGluc3RhbmNlIHNlbGVjdGlvbi4gICAgSW4gcGFydGljdWxhciwgaXMgdGhlIGluc3RhbmNl IHNlbGVjdGlvbiBjZW50cmFsaXplZCwgZGlzdHJpYnV0ZWQsIG9yIHNvbWUgY29tYmluYXRpb24/ ICAgV2hpY2ggZnVuY3Rpb25hbCBlbnRpdGllcyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGhhdmUgd2hh dCByZXNwb25zaWJpbGl0aWVzIHRvIGFjaGlldmUgdGhpcz8gICBJbiBOb3ZlbWJlciwgMjAxMywg YWZ0ZXIgSUVURiA4OCwgSSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCwgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1wYXRoLTAwLCB3aGljaCBwcm9wb3Nl ZCB0aGF0IHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gd2FzIG1hZGUgaG9wIGJ5IGhvcCBieSB0aGUg c2VydmljZSBmdW5jdGlvbnMgdGhlbXNlbHZlcywgaW4gYSBmdWxseSBkaXN0cmlidXRlZCBtYW5u ZXIuICAgVGhhdCB3YXMganVzdCBhIHByb3Bvc2FsIGFuZCBJIGFtIG5vdCB3ZWRkZWQgdG8gaXQs IGJ5IGFueSBtZWFucy4gICAgSm9lbCBhc2tlZCBhYm91dCBzcGVjaWZpY2l0eSBhbmQgaXQgaXMg YXQgdGhpcyBsZXZlbCB0aGF0IEnigJlkIGxpa2UgdG8gc2VlIHRoZSBhcmNoaXRlY3R1cmUgZGVz Y3JpYmUgdGhpbmdzLiAgIEl0IHNob3VsZCBiZSBhYmxlIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24s IOKAnGhvdyBkb2VzIG11bHRpLWluc3RhbmNlIHNlbGVjdGlvbiB3b3JrIGluIFNGQz/igJ0gaW4g YSBjb25jaXNlIG1hbm5lci4gICBJZiB0aGUgZ3JvdXAgZmVlbHMgdGhhdCB0aGVyZSBzaG91bGQg YmUgbW9yZSB0aGFuIG9uZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiwgc28gYmUgaXQsIGJ1dCB3 ZSBzaG91bGQgYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgaGlnaCBsZXZlbCBtZWNoYW5pc20gYW5k IHJhdGlvbmFsZSBmb3IgZWFjaCBzdWNjaW5jdGx5LiAgICBPZiBjb3Vyc2UsIHRoYXQgaXMgbWVy ZWx5IG9uZSBzdWNoIHF1ZXN0aW9uIGFuZCB0aGVyZSBhcmUgbWFueSBvdGhlcnMgdGhhdCBhbiBh cmNoaXRlY3R1cmFsIGRvY3VtZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlc2NyaWJlLg0KDQogICBS b24NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEx1Y3kgeW9uZw0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMTE6MDUgQU0NClRv OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPjsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsg am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkFncmVlLiBUaGUgYXJjaC4gZG9jIHNo b3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg dG8gZHJpdmUgdGhlIGZvcndhcmRpbmcgYWN0aW9ucy4NCg0KTHVjeQ0KDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCAyOjA2IEFNDQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoN ClJlLSwNCg0KVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2 ZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQoNClJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0 aGUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgYXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nIHBhdGhz IHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90IHJlcXVpcmVkL2p1c3RpZmllZCBu b3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KDQpTRkMgZm9yd2Fy ZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0 IHdpbGwgYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1 aXJlZCB0byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBp cyB1c2VkIHRvIGluZmVyIGZvcndhcmRpbmcgYWN0aW9ucyBpcyBhIHNvbHV0aW9uLW9yaWVudGVk IGRpc2N1c3Npb24uDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtl YmlhbmNAYW9sLmNvbT4NCkVudm95w6kgOiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMw0K w4AgOiBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJcyBhbnlvbmUgc3RpbGwgcXVl c3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gIE90 aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8g dGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25l IGFncmVlcyBvbiB0aGVzZSB0ZXJtcy4NCg0KVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBz dGlsbCB1bmNsZWFyIGlzIHdoZXRoZXIgaXQgaXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRv IHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQg cmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBs eSBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMg dG8gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBv ciBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yIHBhdGggdG8gYmUgbmVnb3RpYXRlZCBp biB0aGUgY29udHJvbC1wbGFuZS4NCg0KSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0 aGUgZHJhZnQgd291bGQgaGF2ZSByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBw b3J0ZWQgKG9yIG1ha2Ugb25lIHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2 b2lkIHNvbWUgdmVuZG9ycyBvbmx5IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBw b3J0aW5nIFNGQy4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NClRvOiBzZmNAaWV0Zi5vcmc8c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KU2VudDogVHVl c2RheSwgSnVseSA4LCAyMDE0DQpTdWJqZWN0OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBo b3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2YNCmNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVu IG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1lcmdlZCBhcmNodGllY3R1cmUNCmRyYWZ0LiBBc3N1 bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdl DQp3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhh dmUgbm90DQpwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQg aXQgdGhlIHdheSB0aGUgd29ya2luZw0KZ3JvdXAgaW50ZW5kcy4NCg0KQnV0IHdoYXQgZG8gd2Ug aW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZQ0K aWYgdGhhdCBoZWxwcy4NCg0KSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVw IGluIG1pbmQgdGhhdCB3aGF0IHdlIGFyZQ0KZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJj aGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRpbmcgdG8NCmRlZmluZSB0aGUgYXJjaGl0ZWN0 dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLg0KVGhhdCB3 b3VsZCBlbmNvbXBhc3MgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rp b25zLA0KdmlydHVhbCBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhl ciBhc3BlY3RzLg0KDQpBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xl YXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZQ0KbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBk ZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFyZSBmdW5jdGlvbmluZywNCmFuZCBhcmUgbm90IGRp cmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy4NCg0KSW4gb3JkZXIgdG8g Z2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhl bSwNCkkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQg bGVhc3QgdGhyZWUNCmRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3 aWxsIGludGVyYWN0IHdpdGggc2VydmljZQ0KY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBt b3JlLiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0bw0KcGVybWl0IGFsbCBvZiB0 aGVzZSwgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2Vk DQppbiBhbnkgc29sdXRpb24uDQoNCjEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92 aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMgaXMgYQ0Kc2VydmljZSBmdW5jdGlvbi4gSXQgcmVj ZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9kaWZpZXMgdGhlbSAob3IgbWFya3MNCnRoZW0sIG9y IC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVj ZWl2ZQ0KdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5j dGlvbiB0byBiZSBhYmxlIHRvDQppbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVo YXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24NCmhvdyBzZXJ2aWNlIGNoYWluaW5nIGlz IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KYXJjaHRpZWN0dXJl LiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZp Y2UNCmZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KDQoy KSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZl IHdoYXQgYXBwZWFycw0KdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEg c2luZ2xlIHBvaW50IG9mIGNvbnRhY3QgZm9yIGENCnNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQgYnkgYSBjb2xsZWN0aW9uIG9mDQp2aXJ0dWFsIG9y IHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9h ZA0KYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UgdGVjaG5pcXVlcyB0byBz aGFyZSBhIE1BQw0KYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhlIHNl cnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wNCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhv c2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KaW5zdGFudGlh dGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJn ZWx5DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBkb2Vz IG5vdCBsZWFkIHJlYWRlcnMgdG8NCnRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCg0KMykg VGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0 IHBhdGhzIGZvcg0KdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBk aWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZA0Kbm90IHdhbnQgdG8gcmVxdWlyZSB0aGF0IGEgZ2l2 ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUNCnBsYWNlIGluIHRoZSBuZXR3 b3JrLg0KDQpJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmlu ZWQuIEkgdGVuZCB0byByZWZlciB0bw0KdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBh cHBlYXIgdG8gc2VydmljZSBjaGFpbmluZyBhcyBhIHNpbmdsZQ0KcG9pbnQgYXMgYSBjbHVzdGVy LiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGEgZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJDQpkbyBu b3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFu Y2luZyBpcyB0bw0KZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVy ZW50IHNpbmd1bGFyIG9yIGNsdXN0ZXJlZA0Kc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50 IHBsYWNlcyBpbiB0aGUgbmV0d29yay4NCg0KTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkg bWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWluIGFuZA0Kc2VydmljZSBwYXRoLyBT ZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUNCmFw cGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcg dGhhdCBzb21lDQpzdWJzZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29u dGVudCBpbnNwZWN0aW9uLCBhbmQNCmZpcmV3YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBp cyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUgd2l0aG91dA0KdmlzaXRpbmcgYW55IG90aGVy IHNlcnZpY2UgZnVuY3Rpb25zLg0KDQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8g ZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZpY2UgcGF0aA0KaXMsIGluIHNvbWUgZmFzaGlvbiwg YSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuIFRob3NlDQpsb2NhdGlvbnMg d2lsbCBiZSBzaW5ndWxhciBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeQ0K bG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkg YmUgYWRkcmVzc2VkDQphcyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVu dCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0KbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNo YWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Lg0KDQpGcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJs ZQ0KdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlIHNlcnZpY2Ug Y2hhaW4sIHdoaWNoDQpkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvIHRhbGsg YWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGgNCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3 b3JrLg0KDQpTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUg cGF0aCBtYXkgbm90IGJlIGtub3duDQphdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVyZSBk ZWFscyB3aXRoIHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuDQpGaXJzdCwgYXMgbm90ZWQgaW4gaXRl bSAoMikgb24gbG9hZCBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZQ0KZGVjaXNpb25zIGFu ZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZw0K bWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBM QU4gaXMgbGFyZ2VseQ0KaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90 aGVyIHByb3Zpc2lvbiB3ZSBtYWtlIGlzIHRoYXQNCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRv bmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdpbGwNCmRpcmVjdCBwYWNrZXRz IHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlDQpy ZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCg0KSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWlu IHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYNCnRoZSBpbnRlbnQgaXMgYWNj ZXB0YWJsZSB0byB0aGUgd29ya2luZyBncm91cCwgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdA0KYWRk aXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkIHRvIGNvbnZleSB0aGlzLg0KSWYgdGhlIHdvcmtpbmcg Z3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50ZW50LCB0aGVuIHdlIHdpbGwgb2YgY291cnNlDQph ZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50cy4NCklmIHRoaXMgaXMg c3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRyeSBuZXh0Lg0KDQpZb3VycywN CkpvZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D453BE3BBdfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMg Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRl IGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuVGV4dGVk ZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxsZXMNCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkZyb20gUm9uOiBJdCBzaG91bGQgYmUgYWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9u LCDigJxob3cgZG9lcyBtdWx0aS1pbnN0YW5jZSBzZWxlY3Rpb24gd29yayBpbiBTRkM/4oCdIGlu IGEgY29uY2lzZSBtYW5uZXIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3cgYWJvdXQ6IFRoZSBhcmNoaXRl Y3R1cmUgYWxsb3dzIGltcGxlbWVudGluZyBzaW5nbGUgU0ZQIG9yIG11bHRpcGxlIFNGUHMgdG8g c3VwcG9ydCBTRiBtdWx0aS1pbnN0YW5jZXMgaW4gU0ZDLiBJbiB0aGUgZmlyc3QgY2FzZSwgaW5z dGFuY2Ugc2VsZWN0aW9uIGlzIG9wYXF1ZQ0KIHRvIHRoZSBTRlA7IGluIGxhdHRlciBjYXNlLCBp bnN0YW5jZSBzZWxlY3Rpb24sIGluIHR1cm4sIGJlY29tZXMgU0ZQIHNlbGVjdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkx1Y3k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2hhbmdjaGVuZyBIdWFu ZyBbbWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAxMCwgMjAxNCAxMTozMSBBTTxicj4NCjxiPlRvOjwvYj4gJ1JvbiBQYXJrZXIn OyBMdWN5IHlvbmc7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IG1pa2ViaWFuY0Bhb2wu Y29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBSb27igJlzIGNvbW1l bnRzLiBTZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgbWFrZSB0aGUgZGVjaXNpb24gYWJvdXQgd2hp Y2ggaW5zdGFuY2VzIHdpbGwgYmUgdXNlZC4gSXQgY2FuIGJlIGRpZmZlcmVudCBob3AtYnktaG9w IChlLmcuIGluIGEgdHJlZSB0b3BvbG9neSkuDQogSW4gb3JkZXIgdG8gZG8gc28sIGl0IGlzIGlt cG9ydGFudCBhIHBoeXNpY2FsIG5ldHdvcmsgbWFrZXMgYSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu IGF3YXJlIG9mIHRoZSBhdmFpbGFibGUgaW5zdGFuY2VzLiBUaGVzZSBpcyBubyBuZWVkIHRvIGlk ZW50aWZ5IGVhY2ggcG9zc2libGUgU0ZQIGJ5IGEgcGh5c2ljYWwgbmV0d29yay4gSWYgYSBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluIHdhbnRzIHRvIHVzZSBtdWx0aXBsZSBTRlBzLCBpdCBzaG91bGQg cHJvdmlkZQ0KIHRoZSBpZGVudGlmaWVyIGZvciBlYWNoIGZsb3cgdGhhdCB1c2VzIGEgcGFydGlj dWxhciBTRlAgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGZvcndhcmRpbmcgcnVsZXMgKGkuZS4gbmV4 dCBob3ApLiBOZXZlcnRoZWxlc3MsIGJlY2F1c2UgYSBwaHlzaWNhbCBuZXR3b3JrIG5lZWQgdG8g c3VwcG9ydCBtdWx0aXBsZSB0ZW5hbnRzLCBpdCBkb2VzIG5lZWQgdG8gaWRlbnRpZnkgZGlmZmVy ZW50IHRlbmFudHMuIE91ciByZWNlbnQgY29udHJpYnV0aW9uICg8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJzaXZl LXNlcnZpY2UvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1z ZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UvPC9hPg0KICkgaGFzIGRpc2N1c3NlZCB0aGlz IGlzc3VlIGluIGEgbW9yZSBnZW5lcmFsIGFyY2hpdGVjdHVyZS4gSG9wZSBpdCBjYW4gYmUgaGVs cGZ1bCBmb3IgdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hhbmcNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Sb24gUGFya2VyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0IDg6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1Y3kgeW9uZzsgPGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtl YmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj4N CmptaEBqb2VsaGFscGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JdCBpcyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNhbnQgdG8gaWRlbnRpZnkgdGhh dCBtdWx0aXBsZSBhZGRyZXNzYWJsZSBpbnN0YW5jZXMgb2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFy ZSBleHBsaWNpdGx5IGFsbG93ZWQuJm5ic3A7Jm5ic3A7IFdoZXRoZXIgdGhvc2UgaW5zdGFuY2Ug cGVyZm9ybQ0KIHNvbWUgZnVydGhlciBsZXZlbCBvZiBsb2FkIGJhbGFuY2luZyBpcyBpcnJlbGV2 YW50LCBhcyBoYXMgYmVlbiBwb2ludGVkIG91dCBieSBKb2VsLiZuYnNwOyZuYnNwOyZuYnNwOyBJ dCBpcyBhbHNvIGFyY2hpdGVjdHVyYWxseSBzaWduaWZpY2FudCB0byBhc3NpZ24gcmVzcG9uc2li aWxpdHkgZm9yIGluc3RhbmNlIHNlbGVjdGlvbi4mbmJzcDsmbmJzcDsmbmJzcDsgSW4gcGFydGlj dWxhciwgaXMgdGhlIGluc3RhbmNlIHNlbGVjdGlvbiBjZW50cmFsaXplZCwgZGlzdHJpYnV0ZWQs IG9yIHNvbWUgY29tYmluYXRpb24/DQogJm5ic3A7Jm5ic3A7V2hpY2ggZnVuY3Rpb25hbCBlbnRp dGllcyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGhhdmUgd2hhdCByZXNwb25zaWJpbGl0aWVzIHRvIGFj aGlldmUgdGhpcz8mbmJzcDsmbmJzcDsgSW4gTm92ZW1iZXIsIDIwMTMsIGFmdGVyIElFVEYgODgs IEkgc3VibWl0dGVkIHRoaXMgZHJhZnQsDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDAiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXBhcmtlci1zZmMtY2hhaW4tdG8tcGF0aC0wMDwvYT4sIHdoaWNoIHBy b3Bvc2VkIHRoYXQgdGhlIGluc3RhbmNlIHNlbGVjdGlvbiB3YXMgbWFkZSBob3AgYnkgaG9wIGJ5 IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGVtc2VsdmVzLCBpbiBhIGZ1bGx5IGRpc3RyaWJ1dGVk DQogbWFubmVyLiZuYnNwOyZuYnNwOyBUaGF0IHdhcyBqdXN0IGEgcHJvcG9zYWwgYW5kIEkgYW0g bm90IHdlZGRlZCB0byBpdCwgYnkgYW55IG1lYW5zLiAmbmJzcDsmbmJzcDsmbmJzcDtKb2VsIGFz a2VkIGFib3V0IHNwZWNpZmljaXR5IGFuZCBpdCBpcyBhdCB0aGlzIGxldmVsIHRoYXQgSeKAmWQg bGlrZSB0byBzZWUgdGhlIGFyY2hpdGVjdHVyZSBkZXNjcmliZSB0aGluZ3MuJm5ic3A7Jm5ic3A7 IEl0IHNob3VsZCBiZSBhYmxlIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sIOKAnGhvdyBkb2VzIG11 bHRpLWluc3RhbmNlDQogc2VsZWN0aW9uIHdvcmsgaW4gU0ZDP+KAnSBpbiBhIGNvbmNpc2UgbWFu bmVyLiZuYnNwOyZuYnNwOyBJZiB0aGUgZ3JvdXAgZmVlbHMgdGhhdCB0aGVyZSBzaG91bGQgYmUg bW9yZSB0aGFuIG9uZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiwgc28gYmUgaXQsIGJ1dCB3ZSBz aG91bGQgYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgaGlnaCBsZXZlbCBtZWNoYW5pc20gYW5kIHJh dGlvbmFsZSBmb3IgZWFjaCBzdWNjaW5jdGx5LiZuYnNwOyZuYnNwOyZuYnNwOyBPZiBjb3Vyc2Us IHRoYXQgaXMgbWVyZWx5DQogb25lIHN1Y2ggcXVlc3Rpb24gYW5kIHRoZXJlIGFyZSBtYW55IG90 aGVycyB0aGF0IGFuIGFyY2hpdGVjdHVyYWwgZG9jdW1lbnQgc2hvdWxkIGJlIGFibGUgdG8gZGVz Y3JpYmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkx1Y3kgeW9uZzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SnVseSAxMCwgMjAxNCAxMTowNSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj4NCmptaEBqb2VsaGFs cGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3Jl ZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nIGFjdGlvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5MdWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAxMCwgMjAxNCAyOjA2IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpvZWxoYWxwZXJuLmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBtZXJnZWQg ZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSBv YmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUgZm9yd2FyZGluZyBhY3Rpb25z Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3ds ZWRnZSBvZiBldmVyeSBhdmFpbGFibGUgU0ZDIGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNG Qy1lbmFibGVkIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5vciBwb3NzaWJsZQ0K IGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TRkMgZm9yd2FyZGluZyBh Y3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwg YmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0 byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLg0KIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVz ZWQgdG8gaW5mZXIgZm9yd2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlz Y3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiA8YSBo cmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMzxicj4N CjxiPsOAJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmpt aEBqb2VsaGFscGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNm Y0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5JcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBD aGFpbiBhbmQgU0YgUGF0aD8gJm5ic3A7T3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0 aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgZHJh ZnQsIGl0IHNlZW1zDQogdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24gdGhlc2UgdGVybXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdoZXRoZXIg aXQgaXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0 IHRoZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQgcmVmZXJlbmNlICh0aGUgY2hhaW4gb3Ig dGhlDQogcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5IGludGVuZHMgdG8gbGVhdmUgdGhh dCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyIGRyYWZ0cyB0byBkaWN0YXRlIHRoZSBtZWNoYW5p c21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluIG9yIHBhdGggYW5kIHRoZSBjaG9pY2Ug b2YgY2hhaW4gb3IgcGF0aCB0byBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3 b3VsZCBoYXZlIHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3Ig bWFrZSBvbmUgcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZSB2 ZW5kb3JzIG9ubHkgc3VwcG9ydGluZw0KIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBT RkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy IHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBh bGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxiPkZyb206IDwvYj48YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5j b20mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86IDwvYj48YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmcmbHQ7c2Zj QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+VHVlc2RheSwgSnVseSA4LCAyMDE0 PGJyPg0KPGI+U3ViamVjdDogPC9iPltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQg aG93IHRvIGNsZWFybHkgYW5zd2VyIGEgbnVtYmVyIG9mIDxicj4NCmNvbW1lbnRzIHRoYXQgaGF2 ZSBiZWVuIG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1lcmdlZCBhcmNodGllY3R1cmUgPGJyPg0K ZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZyBncm91cCBhZ3JlZW1lbnQgb24gdGhl IGludGVudCwgd2UgPGJyPg0Kd2lsbCB3b3JrIHRvIGltcHJvdmUgdGhlIHdvcmRpbmcgc28gdGhh dCByZWFkZXJzIHdobyBoYXZlIG5vdCA8YnI+DQpwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHIGRpc2N1 c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUgd29ya2luZyA8YnI+DQpncm91cCBp bnRlbmRzLjxicj4NCjxicj4NCkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBl eHBsYWluIG15IHBlcnNvbmFsIHZpZXcsIGFuZCBzZWUgPGJyPg0KaWYgdGhhdCBoZWxwcy48YnI+ DQo8YnI+DQpJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0 aGF0IHdoYXQgd2UgYXJlIDxicj4NCmRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVj dHVyZS4gV2UgYXJlIG5vdCBhdHRlbXB0aW5nIHRvIDxicj4NCmRlZmluZSB0aGUgYXJjaGl0ZWN0 dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiA8YnI+DQpU aGF0IHdvdWxkIGVuY29tcGFzcyBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBm dW5jdGlvbnMsIDxicj4NCnZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5k IG1hbnkgb3RoZXIgYXNwZWN0cy48YnI+DQo8YnI+DQpBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFu eSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZSA8YnI+DQpsYXJnZXIg c3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGggYWJvdmUgd2hlcmUgd2UgYXJlIGZ1bmN0 aW9uaW5nLCA8YnI+DQphbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3 ZSBhcmUgZG9pbmcuPGJyPg0KPGJyPg0KSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4g dnMgc2VydmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgPGJyPg0KSSBuZWVkIHRvIGZp cnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZSA8YnI+ DQpkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbCBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgPGJyPg0KY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiBU aGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byA8YnI+DQpwZXJtaXQgYWxsIG9mIHRo ZXNlLCBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kIGJlIHVzZWQg PGJyPg0KaW4gYW55IHNvbHV0aW9uLjxicj4NCjxicj4NCjEpIExvYWQgYmFsYW5jaW5nIGFzIGEg c2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMgaXMgYSA8YnI+DQpzZXJ2aWNl IGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZCBtb2RpZmllcyB0aGVtIChv ciBtYXJrcyA8YnI+DQp0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBz ZXJ2aWNlIGluc3RhbmNlIHRvIHJlY2VpdmUgPGJyPg0KdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBp cyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIDxicj4NCmluY2x1 ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVt ZW50cyBvbiA8YnI+DQpob3cgc2VydmljZSBjaGFpbmluZyBpcyBkb25lLiBCdXQgaXQgaGFzIHZl cnkgbGl0dGxlIGltcGFjdCBvbiB0aGUgPGJyPg0KYXJjaHRpZWN0dXJlLiBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2UgPGJyPg0KZnVuY3Rp b24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuPGJyPg0KPGJyPg0KMikg VGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZSB3 aGF0IGFwcGVhcnMgPGJyPg0KdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFz IGEgc2luZ2xlIHBvaW50IG9mIGNvbnRhY3QgZm9yIGEgPGJyPg0Kc3BlY2lmaWMgc2VydmljZSBm dW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhIGNvbGxlY3Rpb24gb2YgPGJy Pg0KdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBv ciBzZXZlcmFsIGxvYWQgPGJyPg0KYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxp a2UgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyA8YnI+DQphZGRyZXNzLikgbW9zdGx5LCB0aGlz IGlzIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIDxicj4NCm1l Y2hhbmlzbXMuIEl0IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250 cm9sIDxicj4NCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxl LWluLCBzY2FsZS1vdXQsIGFuZCB2bSA8YnI+DQppbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0 dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzIGlzIGxhcmdlbHkgPGJyPg0KdGhhdCB3ZSBu ZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVybWlub2xvZ3kgZG9lcyBub3QgbGVhZCByZWFk ZXJzIHRvIDxicj4NCnRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC48YnI+DQo8YnI+DQozKSBU aGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZyBwYWNrZXQg cGF0aHMgZm9yIDxicj4NCnRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMg dG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgPGJyPg0Kbm90IHdhbnQgdG8gcmVxdWlyZSB0 aGF0IGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgPGJyPg0KcGxh Y2UgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRo YXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQgdG8gcmVmZXIgdG8gPGJyPg0KdGhlIGNv bGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZyBhcyBh IHNpbmdsZSA8YnI+DQpwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMg YSBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgPGJyPg0KZG8gbm90IGhhdmUgYW5vdGhlciBvbmUu IFRodXMsIHRoZSBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcgaXMgdG8gPGJyPg0KZGly ZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9y IGNsdXN0ZXJlZCA8YnI+DQpzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGlu IHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCk5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1l YW4gd2hlbiBJIHRhbGsgYWJvdXQgc2VydmljZSBjaGFpbiBhbmQgPGJyPg0Kc2VydmljZSBwYXRo LyBTZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUg PGJyPg0KYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLiBJdCBpcyBlcXVpdmFsZW50IG9m IHNheWluZyB0aGF0IHNvbWUgPGJyPg0Kc3Vic2V0IG9mIHRyYWZmaWMgaXMgdG8gZ2V0IERQSSwg Y2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kIDxicj4NCmZpcmV3YWxsIHdoaWxlIGEg ZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUgd2l0aG91dCA8 YnI+DQp2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPg0KPGJyPg0KVGhh dCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQSBzZXJ2 aWNlIHBhdGggPGJyPg0KaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlv bnMgaW4gdGhlIG5ldHdvcmsuIFRob3NlIDxicj4NCmxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFy IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IDxicj4NCmxvY2F0aW9ucy4g VGhleSBtYXkgYmUgYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3Nl ZCA8YnI+DQphcyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlz IHRoYXQgdGhlIGxvY2F0aW9ucyA8YnI+DQptYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZSB0cmFuc3BvcnQuPGJyPg0KPGJyPg0KRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRv IGJlIGFibGUgPGJyPg0KdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwg dGhlIHNlcnZpY2UgY2hhaW4sIHdoaWNoIDxicj4NCmRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5k IHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCA8YnI+DQpwYWNrZXRz IHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgJnF1b3Q7YnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUga25vd24g PGJyPg0KYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRo YXQgaXNzdWUgaW4gdHdvIHdheXMuIDxicj4NCkZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBv biBsb2FkIGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIDxicj4NCmRlY2lzaW9ucyBhbmQg YmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgPGJy Pg0KbWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4g YSBMQU4gaXMgbGFyZ2VseSA8YnI+DQppbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMu KSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlIG1ha2UgaXMgdGhhdCA8YnI+DQpyZWNsYXNzaWZpY2F0 aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vzc2FyeS4gVGhhdCB3aWxsIDxi cj4NCmRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBpbmZvcm1hdGlvbiBh dmFpbGFibGUgYXQgdGhlIDxicj4NCnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Ljxicj4NCjxicj4N CkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQg ZG9lcywgYW5kIGlmIDxicj4NCnRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2lu ZyBncm91cCwgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCA8YnI+DQphZGRpdGlvbmFsIHdvcmRzIGFy ZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuPGJyPg0KSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdy ZWUgd2l0aCB0aGUgaW50ZW50LCB0aGVuIHdlIHdpbGwgb2YgY291cnNlIDxicj4NCmFkanVzdCB0 byBtYXRjaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLjxicj4NCklmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRyeSBuZXh0Ljxicj4NCjxicj4NCllv dXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D453BE3BBdfweml701chmchi_-- From nobody Thu Jul 10 09:51: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 951FF1A03B5 for ; Thu, 10 Jul 2014 09:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 AiPrgo9MKEvp for ; Thu, 10 Jul 2014 09:51:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E2E1A0AB4 for ; Thu, 10 Jul 2014 09:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1405011080; x=1406220680; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EZMSqhzEN+345XSHimdRQs721pckDgRaIWpoOj0XEmU=; b=Ol62SkuF30DaIqNH42QvwgDnXYp25LdpXPdD9laeC2SXo4oUx6OacpCM fSR4fMAU9JBI2XSEEAHKrX3RrgkQMtxgHz++auUvHLQ84giSIymvzWBMR Syb/hQBv6koZNQLgIns/Brg2OKPmLRN9fqexUzmwxPB+3hIhsbhtufkdg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMfDvlOtJV2c/2dsb2JhbABZgw5SWr8iCodCAYEOFnWEAwEBAQMBAQEBYgkLBQsCAQgSBi4nCxcOAgQOBRuIHwgNx0cTBI8RMweDLYEWBZZmhBqLY4gyg0OCMA X-IronPort-AV: E=Sophos;i="5.01,638,1400025600"; d="scan'208";a="339071583" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jul 2014 16:51:19 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6AGoxNP014181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 16:50:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 11:50:59 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuXpbkAgADJn4CAAAmiAIAABYCAgAAHFwCAAAZogIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigCAAATDAIABKX+AgAAB5wCAAAtOgA== Date: Thu, 10 Jul 2014 16:50:58 +0000 Message-ID: <4EA6CA1E-C82E-4380-B9B8-2DC989E8D1B0@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.co m> <53BEBA98.3060301@joelhalpern.com> In-Reply-To: <53BEBA98.3060301@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.101.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_ZC0i5hwQqoUjskWzvtc2f8w8lY Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" , "mohamed.boucadair@orange.com" , Ron Parker , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 16:51:03 -0000 Joel, I concur. The goal here is to address the issues associated with generic s= ervice function deployment and should enable localized decisions such as lo= ad balancing (perhaps more accurately load distribution). Clearly we sound= =92t codify how load distribution works. =20 In order to enable load distribution, for example, the right abstractions b= een to be clearly defined in the architecture, a key one bering the distinc= tion between path vs. chain. Paul On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote: > That is clearly an important problem in building a full solution to the s= ervice chaining needs of operators (e.g. you). However, I could equally ob= serve that if you do not have OSS/BSS capable of provisioning service chain= s, or charging systems capable of turning them into revenue, you can't offe= r them. >=20 > The SFC working group is tasked with one part of the whole service chain = definition, construction, and deployment problem. As I read the charter, g= eneral load balancing issues are not part of our scope. > Given the number of different ways there are of doing load balancing, it = would strike me as very odd for the sfc working group to standardize a part= icular answer to the important and difficult problem you point to. >=20 > The architecture (and I believe most of the solutions) is designed to pro= vide tools that help with managing that scaling, while also allowing for th= e use of other tools. > If the working group wants us to be more specific in the load balancing a= rchitecture, then if the chairs tell us to we will add more specific text. = I would be surprised personally if we had agreement on such a goal, or agr= eement on how to fill such a goal. But Carlos and I will of course do what= the chairs tell us the WG wants. >=20 > Yours, > Joel >=20 > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote: >> One of the main problems in "service chains" is how to implement a servi= ce that is conceptually one hop but scaled horizontally as 10 or 100 differ= ent VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >>=20 >> Maria >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jul 10 10:01: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 230881B2883 for ; Thu, 10 Jul 2014 10:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.051 X-Spam-Level: X-Spam-Status: No, score=-7.051 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 8usayv7PNjKQ for ; Thu, 10 Jul 2014 10:01:21 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FFC1A0ACA for ; Thu, 10 Jul 2014 10:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405011676; x=1436547676; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=L5ySvgDu2Dkur0qrcOx67OZjUJRmqHPtsyYft3WkIbQ=; b=ehI1quTEK1d96txn2aHRr0WyFyz10AOzFPVXLNpJ/2ez3Jey3GfyMv18 16M/ZbdYUDLzG9Cg9Pz8qfj4kutyGUB98PTbjwe/bZRsddw/SSsddQXSF DxF6MX/CYEVG6XU0G1jhlMrJ6GqXSSMNijAS7QN9bdhlHytY6o34meD/+ A=; X-IronPort-AV: E=Sophos;i="5.01,638,1400025600"; d="scan'208,217";a="121384540" X-IPAS-Result: ArMEAKjFvlPAqArr/2dsb2JhbABPCoJHgRlarmqOYoE+GAELh0ABgSR1hAMBAQEBAwEBARdLCRsCAQgRAQMBAQsWAQYHJwsUAwYIAgQBEggTiBMDHsdMF40ZgU8rJwYKAYMtgRYFhhuQBUaFYoobi3WCMA Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 17:01:14 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 10:01:12 -0700 From: Ian Smith To: Changcheng Huang , 'Ron Parker' , 'Lucy yong' , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" , "jmh@joelhalpern.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAABCUAgAAT/YD//4+pKA== Date: Thu, 10 Jul 2014 17:01:12 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> In-Reply-To: <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83C07BSEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ETGWXOVbZDzaGm0HZZ3BymuuZZM Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 17:01:30 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83C07BSEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >Service functions should make the decision about which instances will be u= sed I think it is sufficient for the architecture to say, "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." But you also say need to say, "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY m= ake the decision about which Service Function Instances will be used when s= electing the Service Function Path." and, "External orchestration frameworks MAY make the decision about which Servic= e Function Instances will be used when selecting the Service Function Path.= " All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural. IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two. ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.c= arleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.= com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I agree with Ron=92s comments. Service functions should make the decision a= bout which instances will be used. It can be different hop-by-hop (e.g. in = a tree topology). In order to do so, it is important a physical network mak= es a service function chain aware of the available instances. These is no n= eed to identify each possible SFP by a physical network. If a service funct= ion chain wants to use multiple SFPs, it should provide the identifier for = each flow that uses a particular SFP and the corresponding forwarding rules= (i.e. next hop). Nevertheless, because a physical network need to support = multiple tenants, it does need to identify different tenants. Our recent co= ntribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recur= sive-service/ ) has discussed this issue in a more general architecture. Ho= pe it can be helpful for this discussion. Chang From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhal= pern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers It is architecturally significant to identify that multiple addressable ins= tances of a service function are explicitly allowed. Whether those instan= ce perform some further level of load balancing is irrelevant, as has been = pointed out by Joel. It is also architecturally significant to assign re= sponsibility for instance selection. In particular, is the instance sele= ction centralized, distributed, or some combination? Which functional ent= ities in the architecture have what responsibilities to achieve this? In = November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.or= g/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance = selection was made hop by hop by the service functions themselves, in a ful= ly distributed manner. That was just a proposal and I am not wedded to it= , by any means. Joel asked about specificity and it is at this level tha= t I=92d like to see the architecture describe things. It should be able t= o answer the question, =93how does multi-instance selection work in SFC?=94= in a concise manner. If the group feels that there should be more than o= ne answer to that question, so be it, but we should be able to describe the= high level mechanism and rationale for each succinctly. Of course, that= is merely one such question and there are many others that an architectura= l document should be able to describe. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mike= bianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A83C07BSEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,
 
"Service Functions MAY make the decision about which Service Function = Instances will be used when selecting the Service Function Path."

But you also say need to say,

= "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the = decision about which Service Function Instances will be used when selecting= the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Functio= n Instances will be used when selecting the Service Function Path."
All three result in a Service Function Path being selected, and they aren't ne= cessarily exclusive of one another if you have rules for resolving conflict= s; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two.

 
From: sfc [sfc-bounces@ietf.org] on behal= f of Changcheng Huang [huang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebia= nc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I agree with Ron=92s co= mments. Service functions should make the decision about which instances wi= ll be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a s= ervice function chain aware of the available instances. These is no need to= identify each possible SFP by a physical network. If a service function ch= ain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, becau= se a physical network need to support multiple tenants, it does need to ide= ntify different tenants. Our recent contribution (https://datatracker.ietf.org= /doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this i= ssue in a more general architecture. Hope it can be helpful for this discussion.

 

Chang

 

From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@= joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

 

It is architecturally s= ignificant to identify that multiple addressable instances of a service fun= ction are explicitly allowed.   Whether those instance perform some further level of load balancing is irrelevant, as has been pointed ou= t by Joel.    It is also architecturally significant to assi= gn responsibility for instance selection.    In particular, = is the instance selection centralized, distributed, or some combination?   Which functional entities in the architecture have what respon= sibilities to achieve this?   In November, 2013, after IETF 88, I= submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which pro= posed that the instance selection was made hop by hop by the service functi= ons themselves, in a fully distributed manner.   That was just a = proposal and I am not wedded to it, by any means.    Joel asked about specificity and it is at this le= vel that I=92d like to see the architecture describe things.   It= should be able to answer the question, =93how does multi-instance selectio= n work in SFC?=94 in a concise manner.   If the group feels that there should be more than one answer to that question, so be it, but we sh= ould be able to describe the high level mechanism and rationale for each su= ccinctly.    Of course, that is merely one such question and= there are many others that an architectural document should be able to describe.

 

   Ron=

 

 

From: sfc = [mailto:sfc-bounc= es@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; = sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

 

Agree. The arch. doc sh= ould not mandate only use of the service path identifier to drive the forwa= rding actions.

 

Lucy

 

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces= @ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc= @aol.com; jmh@joelhalpern.co= m; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

 

Re-,

 

The merged draft calls out explicitly a se= rvice path identifier. I object to use that identifier to derive forwarding= actions.

 

Requiring a SFC system to have the full kn= owledge of every available SFC forwarding paths within an SFC-enabled domai= n is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the = piece of information that will be present in all deployments: that is the o= ne required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriente= d discussion.

 

Cheers,

Med

 

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=E9 : mercredi 9 juillet 2014 22:03
=C0 : = jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

 

Is anyone still questioning the differen= ce between SF Chain and SF Path?  Other than clarifying the definition= so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still uncle= ar is whether it is the intent of this draft to ultimately specify what the= ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draf= t would have require that both SFP and SFC be supported (or make one requir= ed and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh= @joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

--_000_419417C345CA5F48BF45F0A23955A0634A83C07BSEAEMBX02olympu_-- From nobody Thu Jul 10 11:16: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 E3CFE1A0406 for ; Thu, 10 Jul 2014 11:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGQ_6sIxUp3t for ; Thu, 10 Jul 2014 11:16:18 -0700 (PDT) Received: from mc34.lon.server.colt.net (mc34.lon.server.colt.net [212.74.77.114]) by ietfa.amsl.com (Postfix) with ESMTP id 15A2E1A08EC for ; Thu, 10 Jul 2014 11:16:17 -0700 (PDT) Received: from mc34.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A5FE41A8078 for ; Thu, 10 Jul 2014 18:15:45 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc34.lon.server.colt.net (Postfix) with ESMTP id 781021A8074 for ; Thu, 10 Jul 2014 18:15:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,639,1400018400"; d="scan'208,217";a="1129643" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.9]) by mx3.qosmos.com with ESMTP; 10 Jul 2014 20:15:45 +0200 Received: from CAROUBIER.jungle.qosmos.com ([169.254.1.52]) by LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4%14]) with mapi id 14.01.0438.000; Thu, 10 Jul 2014 20:16:21 +0200 From: Nicolas BOUTHORS To: "sfc@ietf.org" Thread-Topic: Metadata representation and transport Thread-Index: Ac+cag85+Q81qSP7RZyUzN5UZVrEHw== Date: Thu, 10 Jul 2014 18:15:59 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.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_76B41B8FACE1514795D30EC137FF391D453311CAROUBIERjungleqo_" MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1017-20810.001 X-TM-AS-Result: No--18.368-5.0-31-10 X-imss-scan-details: No--18.368-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1017-20810.001 X-TMASE-Result: 10--18.367700-5.000000 X-TMASE-MatchedRID: hr3zsyz74p3FvZkHJO4cDwRH1Nr7oERd7yWPaQc4INTZ7ve0lygT2OpU Olu1Vn8QgRgg7vnOVhcwn9g3uUMn08y8PuqczgdN8CORMyRE01SRmzp54Gcgze1UBD2D3s4ya0J xLB6uDiYFFy/kqfmozv//OIb3b85uzpFIpbxp7n2sMW2Z7ncq++mZcj95ms7Jn4PZYo/AFVxf8X X+hvLFJshAk4N3Mh3Mi0cVGfTwA7c0DiQ9cxdwEjNKWYiz0CE6hEIiqNvBrmMHUwyyrYK8qnCoA VDmH0M5agfIKH6Mz8L/2bsD6e1674XVLLOFXnezTVa+L3Zgqc4do1DHlpWEeVvym/gvSH4ihzNU Ku2Ue5px2QBeHxu1kfNFNnaq47M3FMmbsxtPvUvwt4yakzpUP6KaxHqGRwkCIbxYwbCxGTTA1/n 5ffsZhwACkeh0OGjBzmQ62M6i7HtAYPgN93B6/XGBmLio+mJgrxZQ031Z6Fo0FzNxdDrDEiTCwc JtMKH93wAUzW7g9YhiVR5v4/csaTCnU2UCF36y/jkwiY2tJnIMtgM5/AwIJthMNz5U8DsX3MOEc RunIond8K+w71+Yq24hflnSm7p8N9Tz++h3YyFwvkNIefmgt4VdLK46KrcfaHlOtIny1dvTvNpV kSD4M/c2hQ4hYCF6e3tqQ5/u7n3vnOSC+jk4DkdAWPMBu8kQO1K5iM8Q6KAgbNDlPT+rW/TYLJi /AavYuzRWMvu9Xhgd6r+uiHJaWAVnfa7xoeysaUe/i9AephMYXAQYNFfm7KaBTJJM60GF3Utpd7 Kbo6W+aLI0EBadBwwqHc/Ox96RUjrS/GZo2EqeAiCmPx4NwGmRqNBHmBvenFK7VE/xL0lFGCd0S 0NCslUq/0fpMEPUktxH2cCcAL9KaxNSZg9nT8iH15Nm4UApH8FerAT0dJY= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OC8xbddsVq0tWUXr2XqqveSFJOI Subject: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:16:26 -0000 --_000_76B41B8FACE1514795D30EC137FF391D453311CAROUBIERjungleqo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Metadata transport is a feature provided by SFC that needs some additional = thoughts as well. B Rijsman has done a great job showing various option for Metadata sharing.= Still there are 2 aspects that I would like to address further - Metadata representation - Metadata transport reliability We will probably post a draft on the subject, but this can be done after To= ronto has started. So for those interested to provide some feedback, here are some highlights. 1. Problem Space Metadata representation Metadata can be extremely varied in term of usage and content. It can repre= sent the result of Deep Packet Inspection (DPI) performed on the traffic fo= r example by the Classifier Service Function at the ingress of the Service = Function Chain. It can contain information collected about the end user suc= h as a policy identifier, a category or even represent an event related to = the end-user session. This information can be used by Service Functions on the chain, as well as = by monitoring entities responsible to track usage for example in the Networ= k Function Virtualization environment to feed a VNF manager or an Orchestra= tor. Metadata being information shared by many network entities needs some means= to be represented it in all of its dimensions: type definition, encoding a= nd scope. Metadata transport service As expected from service chain proposals, both NSH and SCH proposals define= some means to carry metadata between Service Functions in a Chain. They ca= n be classified as follow: Dataplane Metadata: are defined in the Service Function Chaining Problem Statement document. Th= ey are not considered to be part of the forwarding information of the SFC h= eader. However they are expected to carry the result of antecedent classifi= cation, allowing Service Functions to take local policy decisions based on = their values. As such, they could also be interpreted directly by Service Function Forwar= der to steer traffic to various Service Functions. Offline Metadata: Beyond Dataplane Metadata, Offline Metadata can be shared between Service F= unctions in a chain, using out of band, congruent or not, or hybrid models = described in [RIJSMAN] The hybrid model for example, defined in [RIJSMAN], utilizes the SFC header= to transport some key values for correlation purposes. These Correlation I= ds can be used by the Service Functions to recover the full associated cont= extual information. Metadata, directly or indirectly, are transported hop by hop along a chain,= in association to end-user traffic, the data payload of the SFC packets. How these metadata are transported over a chain matters. Passing metadata d= irectly or indirectly along packets is a service that must be analyzed from= a reliability point of view. Reliability requirements may vary depending on the nature of the metadata t= ransported. Past experience for example in Mobile Network and data center w= ith AAA Radius have shown that contextual information replication to variou= s service function was indeed sensitive to packet loss events, and that adh= oc solutions had to be implemented to detect them. End to end TCP retransmission of packet lost does not ensure that associate= d Metadata will be reinserted in retransmitted packet. In addition, Event t= riggered metadata may have to be sent immediately on a chain even though no= end-user traffic is being transmitted Not all metadata needs a reliable transport. Repeated inline metadata can b= e used to cover several use cases, and some metadata loss can be acceptable= . Still, a reliable transport service for Metadata in SFC is expected. To thi= s effect, an implementation is suggested in Section 3.3 2. Metadata representation Metadata definition is that it provides contextual information about the da= ta packets which traverse a Service Function Chain. This must be understood= broadly. Metadata can contain the result of traffic classification by Deep Packet In= spection (DPI). For example as an Application Id information which is tied = to a traffic flow. There could be multiple flows with different application= ids, in a chain. Metadata can also contain the result of DPI data extraction, such as identi= fy requested URL in HTTP. Such information can be passed to certain SF down= the chain such as a URL filtering function. Metadata can contain some punctual event information collected at the Ingre= ss point of the chain and expected to be passed to all elements in the chai= n. Here this information may be triggered externally and generated only onc= e, and be related to the tenant or the subscriber. Metadata representation involves the definition of a set of information ele= ments types and the encoding rules for their values. Metadata representation can sometimes be performed by a single individual f= ield with associated type and format. However, it is not always enough. * Metadata may need multiple fields transported together to represented= their values. * Some addition fields may be required to describe the scope of the met= adata itself. This can be any information element allowing to define the co= ntext of the associated metadata value. For example a throughput metadata f= ield can have a port number and a switch address as its Scope information. We explore these two axis: encoding and scope. We propose IPFIX as a preferred means to represent Metadata in Service Chai= n messages for Out-of-band, Congruent or not; Metadata sharing. 2.1. Metadata Representation Requirements Mandatatory Dataplane Metadata is always part of the SFC header, it is thus= reasonable to consider that its representation scheme will be implicit: ba= sed on what the SFC protocol will dictate, their position in the SFC header= is sufficient for the receiving end to infer their type and encoding schem= e. For example, Context Header Fields in NSH are 32 bit fields. However, it will not be the case for all metadata transported. Offline meta= data, including congruent out-of-band metadata still need to be represented= explicitly. This section addresses their specific case. 2.1.1. Metadata Encoding requirements These requirements are applicable to out-of-band metadata (Congruent or not= ). It could be applicable with SCH on optional in-line metadata fields. For interoperability purposes, metadata encoding MUST allow the receiving e= ntity to identify the type and value of the information received as metadat= a Metadata encoding MUST allow for encoding techniques supporting well known = types and fields as well as proprietary extensions. A receiving entity MUST be able to identify when incoming metadata type is = unknown and MUST have a defined default action to handle it. A piece of information may need multiple fields to be described. For exampl= e a tenant id and an ip address can be used to identify an server in a data= center uniquely. These groups of information have to be exchanged collectively, in a single = message. In this case, a sending entity MUST specify that it is sending a s= et of metadata in a message. This set of transported metadata elements MUST be specified under the form = of a metadata template document uniquely defined for the chain. A receiving entity MUST be able to detect if an incoming message contains i= ts expected set of metadata elements. 2.1.2. Metadata Scope requirement A piece of information may have to be qualified by some attributes allowing= to identify its particular scope. For example in a Gi environment, the rad= io type in use may be used as a scoping criteria for a jitter or latency me= asurement in a video traffic transported in a particular service chaing. Scope can apply to some individual metadata elements or to a set of metadat= a elements. How a scope applies to a set of transported metadata elements s= hould be defined by a specification under the form of a metadata template d= ocument uniquely identified for the chain. 2.2. IPFIX Metadata representation So far, unordered sequences of Type Length Value encoded fields have been p= roposed to transport metadata. It is not clear how structured types are sup= ported, and no distinction is done between the metadata values and their sc= oping values. Although the SCH proposal provides an optional 24-bit Organiz= ational Unique Identifier, there is no namespace mechanism allowing to sepa= rate type definition spaces per Tenants or per chain. We suggest to leverage the work done by IETF on similar subject. A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for tr= ansmitting Traffic Flow information over the network. In order to transmit = Traffic Flow information, it provides a common representation of flow data = and a standard means of communicating them. Metadata collected by Network Node and Service Node SHOULD be encoded in te= mplate following the principles described in IPFIX[RFC7011]. An IPFIX Message consisting of interleaved Template, Data, and Options Temp= late Sets, as shown in Figure 1. Here, Template and Options Template Sets ,= which are optional, are shown. +--------+--------------------------------------------------------+ | | +----------+ +---------+ +-----------+ +---------+ | |Message | | Template | | Data | | Options | | Data | | | Header | | Set | | Set | ... | Template | | Set | | | | | | | | | Set | | | | | | +----------+ +---------+ +-----------+ +---------+ | +--------+--------------------------------------------------------+ Figure 1: IPFIX Message Format The Template Set describes the data transmitted in the following Data Set. = It is an optional component of the message. The value of the metadata is en= coded in the first Data Set. This Data Set contains a template Id field as = a reference to its defining Template Set. The Options Template Set describes the data to be transmitted as scope info= rmation. It is an optional component of the message. The value of the scope= information is encoded in the second Data Set element. It no scope informa= tion is present, then only the first Data Set is present in the message. The Option Template Set and following Data Set are used to describe the sco= pe of the metadata transmitted. For example, the metadata collected is rele= vant to a PDP Context or a particular line card of a particular switch. 2.2.4.3. Example: The Metadata Exporting Process creates a Template Record with a few Informa= tion Elements: amongst other things, the Application Id. For example: - sourceIPv4Address (key field) - destinationIPv4Address (key field) - protocol (key field) - destinationTransportPort (key field) - applicationId (key field) - octetTotalCount (non key field) For example, a Flow Record corresponding to the above Template Record may contain: { sourceIPv4Address=3D192.0.2.1, destinationIPv4Address=3D192.0.2.2, protocol=3D17, destinationTransportPort=3D23, applicationId=3D'3..80', octetTotalCount=3D123456 } The Options Data Record associated with the examples above would contain th= e Scoping inforamtion: Scope: - servicePath, - serviceIndex, - applicationId, - applicationName - applicationDescription. For example: { servicePath=3D0x000b, serviceIndex=3D0x000c, applicationId=3D'13...10000', applicationName=3D"webex", applicationDescription=3D"Webex application" } Scope information is useful when sending metadata offline, as it can contai= n information related to the chain and possibly to the flow for which this = metadata record is relevant. Here servicePath and serviceIndex are thus inc= luded in the Template. 2.2.4.4. IPFIX encoding and template provisioning: IPFIX is a quite compact encoding For a template defined as followed and shared by the SF in a chain. IPFIX template record shared by SF: Note that an XML representation of IPFIX template record could be defined a= nd used to provision Service Functions. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 2 | Length =3D 28 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count =3D 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address =3D 8 | Field Length =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address =3D 12 | Field Length =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipNextHopIPv4Address =3D 15 | Field Length =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount =3D 2 | Field Length =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount =3D 1 | Field Length =3D 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IPFIX Metadata template Encoding An encoded IP fix transport message will be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID =3D 256 | Length =3D 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5009 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5344385 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IPFIX Metadata Encoding 3. Metadata transport service These different use cases for Metadata generate some requirements on the re= liability capabilities of the Metadata transport service they will rely on. De facto Service Function Chain proposals such as NSH and SCH define a mech= anism for sharing information along the Chains. It is thus important to def= ine this transport service in term of reliability. The primary focus of these proposal are the Metadata elements playing a rol= e in the Service Function Chain deployment to apply policies on incoming tr= affic at some relevant Service Functions. For example, Network Orchestration is expected to be a significant driver f= or deployment of Network Services. It relies on Service Level abstractions = such as Group Policies, Contracts and Services as an input for the orchestr= ation of Service Function Chains. Specific metadata attributes such as L4-L= 7 fields are used as classification elements or filters to funnel packets i= nto chains. Service Functions may have other needs for Metadata, for example Event Base= d Metadata tied to some subscriber related state changes. The complexity an= d length of these elements cannot be forseen as limited, neither can be how= critical it is that they are safely carried throughout a chain. In the fo= llowing Section we propose to take avantage of Congruent Metadata Transport= can be used, possibly reliably, to address these needs. 3.1. Proposed Metadata transport mechanisms . 3.1.3. Metadata transport analysis Both NSH and SCH proposals support both inbound and offline out-of-band met= adata transport. 1. In-band: the metadata can be included directly as a value in some of = the NSH Context Header Fields. It is the preferred transport model for SCH. In such case, when a particular field is always set to the same value for a= ll packets transported by the chain instance, then the metadata transport s= ervice is in effect reliable. Similarly, all the packet for a particular flow (defined by its 5 tupple), = could receive the same metadata value. The metadata transport service is al= so reliable, provided that the value is understood to be attached to a flow= . The general case however, occurs when the metadata varies from packet to pa= cket in a flow. The value is then tied to a specific packet. Here the trans= port service is not reliable. A retransmission of a particular packet would= not necessarily lead it to carry the same metadata value. 2. Out-of-band: a reference for some metadata is sent along a packet so = that it can be used via an interaction with a controller entity. It is the = preferred model for NSH, but could also be used by SCH. As for the in-band case, the metadata referred to indirectly can be transmi= tted reliably, when its value remains the same for a chain or a flow in a c= hain. a chain or a flow in a chain. If however, the correlation Id passed changes over time, or if the Metadata= itself cahanges then the correct Metadata may not be efficiently retrieved= by some Service Functions. We can see that NSH and SCH do not address the need for a reliable transpor= t service for metadata, independantly of the reliability characteristic of = the transport service used for the data packets. Conventions can be used as particular cases when some metadata pertains to = a specific chain or a flow in the chain, and when its value does not change= overtime. Such conventions however are weak. They would suppose that some mechanism e= xists to ensure/monitor that they are followed. And some exceptions mechani= sm would be required to deal with error cases. 3.2. Support for Congruent out-of-band transport service Congruent out-of-band metadata sharing can be required for some types of Me= tadata exchanges. It has the advantage of clearly tying the metadata to the= chain and not to a specific packet, and to avoid payload fragmentation iss= ues. Up to draft 2, NSH did not allow for long inline metadata transport. Four 3= 2 bits context fields are reserved for that purpose, and seem best suited f= or offline Metadata sharing, or to transport predefined policy identifiers. NSH (since draf 3) as well as SCH could allow for metadata transport, eithe= r tied to a packet or possibly tied to the chain, when used without payload= , as signaling messages. SCH however stipulates that in case the Path Identifier and SF Index fields= shall be set to zero for transmit and ignored upon receipt, when the SCH p= acket will contain only metadata. So congruent out-of-band metadata, transp= orting Metadata hop to hop to the various Service Function in the chain, do= es not seem to be supported. NSH supports inline variable size metadata. It does not mentions explicitly= that congruent out-of-band metadata can be used. 3.3. Reliable transport service Some metadata will need a reliable transport service to be shared inline, a= s well as offline. A protocol SCTP provides such a service and has the interesting characteris= tic to be packet based, as opposed to stream based like TCP. SCTP carries a sequence number and support retransmission and congestion co= ntrol. Figure 12 shows how SCTP is used hop by hop between SFF in a chain to trans= port Metadata reliably. |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | SF#1 | |SF#n | |SF#i1| |SF#im | | | | | | | | | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +-----------+ SCTP +--------+ SCTP +---------+ -- >| Chain | <---> | SFF | <---> | SFF | ----> |classifier | |Node-1 | | Node-i | +-----------+ +----+---+ +----+--+-+ \ | / \ | SFC Encapsulation / \ | / ,........................................ / \ / \ | Network | \ / \........................................./ Figure 12: SCTP for Reliable Metadata transport SCTP SHOULD be used in the context of Congruent out of band for reliable me= tadata sharing. For reliable Metadata transport, the SFF along the chain MUST route the met= adata received over SCTP to the next SF in the chain. For this SCTP MUST be= encapsulated in the SFC header. The SFF MUST make the received metadata available to its SF.ti --_000_76B41B8FACE1514795D30EC137FF391D453311CAROUBIERjungleqo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

Metadata transport is a feature provided by SFC that needs some additi= onal thoughts as well. 

B Rijsman has done a great job showing various option for Metadata sha= ring. Still there are 2 aspects that I would like to address further

- Metadata representation 

- Metadata transport reliability

We will probably post a draft on the subject, but this can be done aft= er Toronto has started. So for those
interested to provide some feedback, here are some highlights.

 
 Metadata representation
Metadata can be extreme= ly varied in term of usage and content. It can represent the result of Deep= Packet Inspection (DPI) performed on the traffic for example by the Classifier Service Function at the ingress of t= he Service Function Chain. It can contain information collected about the e= nd user such as a policy identifier, a category or even represent an event = related to the end-user session.
This information can be= used by Service Functions on the chain, as well as by monitoring entities = responsible to track usage for example in the Network Function Virtualization environment to feed a VNF manager or a= n Orchestrator.
Metadata being informat= ion shared by many network entities needs some means to be represented it i= n all of its dimensions: type definition, encoding and scope.
 Metadata transport service
As expected from servic= e chain proposals, both NSH and SCH proposals define some means to carry me= tadata between Service Functions in a Chain. They can be classified as follow:
 
Dataplane Metadata:
are = defined in the Service Function Chaining Problem Statement document. They a= re not considered to be part of the forwarding information of the SFC heade= r. However they are expected to carry the result of antecedent classification, allowing Service Functions to tak= e local policy decisions based on their values. 

As such, they could also be interpreted directly by Service Function Forwar= der to steer traffic to various Service Functions.
Offline Metadata:
Beyo= nd Dataplane Metadata, Offline Metadata can be shared between Service Funct= ions in a chain, using out of band, congruent or not, or hybrid models desc= ribed in [RIJSMAN] 

The hybrid model for example, defined in [RIJSMAN], utilizes th= e SFC header to transport some key values for correlation purposes. These C= orrelation Ids can be used by the Service Functions to recover the full ass= ociated contextual information.
 
Metadata, directly or i= ndirectly, are transported hop by hop along a chain, in association to end-= user traffic, the data payload of the SFC packets.
How these metadata are = transported over a chain matters. Passing metadata directly or indirectly a= long packets is a service that must be analyzed from a reliability point of view. 

Reliability requirements may vary depending on the nature of the metadata t= ransported. Past experience for example in Mobile Network and data center w= ith AAA Radius have shown that contextual information replication to variou= s service function was indeed sensitive to packet loss events, and that adhoc solutions had to be implemented to d= etect them.
End to end TCP retransm= ission of packet lost does not ensure that associated Metadata will be rein= serted in retransmitted packet. In addition, Event triggered metadata may have to be sent immediately on a chain even t= hough no end-user traffic is being transmitted
Not all metadata needs = a reliable transport. Repeated inline metadata can be used to cover several= use cases, and some metadata loss can be acceptable.
Still, a reliable trans= port service for Metadata in SFC is expected. To this effect, an implementa= tion is suggested in Section 3.3
Metadata definition is = that it provides contextual information about the data packets which traver= se a Service Function Chain. This must be understood broadly.
Metadata can contain th= e result of traffic classification by Deep Packet Inspection (DPI). For exa= mple as an Application Id information which is tied to a traffic flow. There could be multiple flows with different ap= plication ids, in a chain.
Metadata can also conta= in the result of DPI data extraction, such as identify requested URL in HTT= P. Such information can be passed to certain SF down the chain such as a URL filtering function.
Metadata can contain so= me punctual event information collected at the Ingress point of the chain a= nd expected to be passed to all elements in the chain. Here this information may be triggered externally and genera= ted only once, and be related to the tenant or the subscriber.
Metadata representation= involves the definition of a set of information elements types and the enc= oding rules for their values.
Metadata representation= can sometimes be performed by a single individual field with associated ty= pe and format. However, it is not always enough.
 
  • Metad= ata may need multiple fields transported together to represented their valu= es.
  • Some addition fields may be required to describe the scope of the metada= ta itself. This can be any information element allowing to define the conte= xt of the associated metadata value. For example a throughput metadata field can have a port number and a switch address as= its Scope information.
 
We explore these two ax= is: encoding and scope.
We propose IPFIX as a p= referred means to represent Metadata in Service Chain messages for Out-of-b= and, Congruent or not; Metadata sharing.
Mandatatory Dataplane M= etadata is always part of the SFC header, it is thus reasonable to consider= that its representation scheme will be implicit: based on what the SFC protocol will dictate, their position in t= he SFC header is sufficient for the receiving end to infer their type and e= ncoding scheme. For example, Context Header Fields in NSH are 32 bit fields= .
However, it will not be= the case for all metadata transported. Offline metadata, including congrue= nt out-of-band metadata still need to be represented explicitly. This section addresses their specific case.=
2.1.1. Metadata Encoding requir= ements
These requirements are = applicable to out-of-band metadata (Congruent or not). It could be applicab= le with SCH on optional in-line metadata fields.
For interoperability pu= rposes, metadata encoding MUST allow the receiving entity to identify the t= ype and value of the information received as metadata
Metadata encoding MUST = allow for encoding techniques supporting well known types and fields as wel= l as proprietary extensions.
A receiving entity MUST= be able to identify when incoming metadata type is unknown and MUST have a= defined default action to handle it.
A piece of information = may need multiple fields to be described. For example a tenant id and an ip= address can be used to identify an server in a data center uniquely.
These groups of informa= tion have to be exchanged collectively, in a single message. In this case, = a sending entity MUST specify that it is sending a set of metadata in a message.
This set of transported= metadata elements MUST be specified under the form of a metadata template = document uniquely defined for the chain.
A receiving entity MUST= be able to detect if an incoming message contains its expected set of meta= data elements.
2.1.2. Metadata Scope requireme= nt
A piece of information = may have to be qualified by some attributes allowing to identify its partic= ular scope. For example in a Gi environment, the radio type in use may be used as a scoping criteria for a jitter or la= tency measurement in a video traffic transported in a particular service ch= aing.
Scope can apply to some= individual metadata elements or to a set of metadata elements. How a scope= applies to a set of transported metadata elements should be defined by a specification under the form of a metadata= template document uniquely identified for the chain.
So far, unordered seque= nces of Type Length Value encoded fields have been proposed to transport me= tadata. It is not clear how structured types are supported, and no distinction is done between the metadata values and = their scoping values. Although the SCH proposal provides an optional 24-bit= Organizational Unique Identifier, there is no namespace mechanism allowing= to separate type definition spaces per Tenants or per chain.
We suggest to leverage = the work done by IETF on similar subject.
A natural candidate to = leverage is IPFIX [RFC7011]: IPFIX is a means for transmitting = Traffic Flow information over the network. In order to transmit Traffic Flow information, it provides a common represent= ation of flow data and a standard means of communicating them.
Metadata collected by N= etwork Node and Service Node SHOULD be encoded in template following the pr= inciples described in IPFIX[RFC7011].
An IPFIX Message consis= ting of interleaved Template, Data, and Options Template Sets, as shown in&= nbsp;Figure 1. Here, Template and Options Template Sets , which are optional, are shown.
 
 
   =0A=
   +--------+------------------------------------------------------=
--+=0A=
   |        | +----------+ +---------+     +-----------=
+ +---------+ |=0A=
   |Message | | Template | | Data    |     | Options   | | Data    | |=0A=
   | Header | | Set      | | Set     | ... | Template  | | Set     | |=0A=
   |        | |          | |         |     | Set       | |         | |=0A=
   |        | +----------+ +---------+     +-----------=
+ +---------+ |=0A=
   +--------+------------------------------------------------------=
--+=0A=
            =0A=
Figure 1: IPFIX = Message Format
The Template Set descri= bes the data transmitted in the following Data Set. It is an optional compo= nent of the message. The value of the metadata is encoded in the first Data Set. This Data Set contains a template Id fie= ld as a reference to its defining Template Set.
The Options Template Se= t describes the data to be transmitted as scope information. It is an optio= nal component of the message. The value of the scope information is encoded in the second Data Set element. It no = scope information is present, then only the first Data Set is present in th= e message.
The Option Template Set= and following Data Set are used to describe the scope of the metadata tran= smitted. For example, the metadata collected is relevant to a PDP Context or a particular line card of a particular swi= tch.

2.2.4.3. Example:
The Metadata Exporting = Process creates a Template Record with a few Information Elements: amongst = other things, the Application Id. For example:
 
        - sourceIPv4Add=
ress (key field)=0A=
        - destinationIPv4Address (key field)=0A=
        - protocol (key field)=0A=
        - destinationTransportPort (key field)=0A=
        - applicationId (key field)=0A=
        - octetTotalCount (non key field)=0A=
     =0A=
        For example, a Flow Record corresponding to the above=0A=
        Template Record may contain:=0A=
     =0A=
            { sourceIPv4Address=3D192.0.2.1,=0A=
              destinationIPv4Address=3D192.0.2.2,=0A=
              protocol=3D17,=0A=
              destinationTransportPort=3D23,=0A=
              applicationId=3D'3..80',=0A=
              octetTotalCount=3D123456 }=0A=
   =0A=
 
The Options Data Record= associated with the examples above would contain the Scoping inforamtion:<= /span>
 
     Scope: =0A=
             - servicePath,=0A=
             - serviceIndex,=0A=
             - applicationId,=0A=
             - applicationName=0A=
             - applicationDescription.=0A=
=0A=
      For example:=0A=
=0A=
            { =0A=
              servicePath=3D0x000b,=0A=
              serviceIndex=3D0x000c,=0A=
              applicationId=3D'13...10000',=0A=
              applicationName=3D"webex",=0A=
              applicationDescription=3D"Webex application" }=0A=
=0A=
 
Scope information is us= eful when sending metadata offline, as it can contain information related t= o the chain and possibly to the flow for which this metadata record is relevant. Here servicePath and serviceIndex = are thus included in the Template.
2.2.4.4. IPFIX encoding and tem= plate provisioning:
IPFIX is a quite compac= t encoding
For a template defined = as followed and shared by the SF in a chain.
IPFIX template record s= hared by SF:
Note that an XML repres= entation of IPFIX template record could be defined and used to provision Se= rvice Functions.
 
 
 0                   1 =
                  2                   3=0A=
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |         Set ID =3D 2            |      Length =3D 28 octets       |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |       Template ID 256         |       Field Count =3D 5         |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |0|    sourceIPv4Address =3D 8    |       Field Length =3D 4        |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |0| destinationIPv4Address =3D 12 |       Field Length =3D 4        |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |0|  ipNextHopIPv4Address =3D 15  |       Field Length =3D 4        |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |0|    packetDeltaCount =3D 2     |       Field Length =3D 4        |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |0|    octetDeltaCount =3D 1      |       Field Length =3D 4        |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
 
Figure 7: IPFIX = Metadata template Encoding
An encoded IP fix trans= port message will be:
 
 
      =0A=
   0                   1                   2                   3=0A=
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |       Version Number          |            Length             |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                           Export Time                         |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                       Sequence Number                         |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                    Observation Domain ID                      |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |          Set ID =3D 256         |          Length =3D 64          |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                          192.0.2.12                           |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                          192.0.2.254                          |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                          192.0.2.1                            |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                             5009                              |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
   |                            5344385                            |=0A=
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+=0A=
=0A=
 
Figure 8: IPFIX = Metadata Encoding
These different use cas= es for Metadata generate some requirements on the reliability capabilities = of the Metadata transport service they will rely on.
De facto Service Functi= on Chain proposals such as NSH and SCH define a mechanism for sharing infor= mation along the Chains. It is thus important to define this transport service in term of reliability. 
The primary focus of th= ese proposal are the Metadata elements playing a role in the Service Functi= on Chain deployment to apply policies on incoming traffic at some relevant Service Functions.
For example, Network Or= chestration is expected to be a significant driver for deployment of Networ= k Services. It relies on Service Level abstractions such as Group Policies, Contracts and Services as an input for the orchest= ration of Service Function Chains. Specific metadata attributes such as L4-= L7 fields are used as classification elements or filters to funnel packets = into chains.
Service Functions may h= ave other needs for Metadata, for example Event Based Metadata tied to some= subscriber related state changes. The complexity and length of these elements cannot be forseen as limited, neither can be = how critical it is that they are safely carried throughout a chain. In &nbs= p;the following Section we propose to take avantage of Con= gruent Metadata Transport can be used, possibly reliably, to address these needs.
.
3.1.3. Metadata transport analy= sis
Both NSH and SCH propos= als support both inbound and offline out-of-band metadata transport.=
 
  1. In-band: the metadata ca= n be included directly as a value in some of the NSH Context Header Fields.= It is the preferred transport model for SCH. 

    In such case, when a particular field is always set to the same value for a= ll packets transported by the chain instance, then the metadata transport s= ervice is in effect reliable. 

    Similarly, all the packet for a particular flow (defined by its 5 tupple), = could receive the same metadata value. The metadata transport service is al= so reliable, provided that the value is understood to be attached to a flow= . 

    The general case however, occurs when the metadata varies from packet to pa= cket in a flow. The value is then tied to a specific packet. Here the trans= port service is not reliable. A retransmission of a particular packet would= not necessarily lead it to carry the same metadata value.
  2. Out-of-band: a reference for some metadata is sent along a packet so = that it can be used via an interaction with a controller entity. It is the = preferred model for NSH, but could also be used by SCH. 

    As for the in-band case, the metadata referred to indirectly can be transmi= tted reliably, when its value remains the same for a chain or a flow in a c= hain. a chain or a flow in a chain. 

    If however, the correlation Id passed changes over time, or if the Metadata= itself cahanges then the correct Metadata may not be efficiently retrieved= by some Service Functions.
 
We can see that NSH and= SCH do not address the need for a reliable transport service for metadata,= independantly of the reliability characteristic of the transport service used for the data packets.
Conventions can be used= as particular cases when some metadata pertains to a specific chain or a f= low in the chain, and when its value does not change overtime.
Such conventions howeve= r are weak. They would suppose that some mechanism exists to ensure/monitor= that they are followed. And some exceptions mechanism would be required to deal with error cases.
Congruent out-of-band m= etadata sharing can be required for some types of Metadata exchanges. It ha= s the advantage of clearly tying the metadata to the chain and not to a specific packet, and to avoid payload fragmentat= ion issues.
Up to draft 2, NSH did = not allow for long inline metadata transport. Four 32 bits context fields a= re reserved for that purpose, and seem best suited for offline Metadata sharing, or to transport predefined policy ide= ntifiers.
NSH (since draf 3) as w= ell as SCH could allow for metadata transport, either tied to a packet or p= ossibly tied to the chain, when used without payload, as signaling messages.
SCH however stipulates = that in case the Path Identifier and SF Index fields shall be set to zero f= or transmit and ignored upon receipt, when the SCH packet will contain only metadata. So congruent out-of-band metada= ta, transporting Metadata hop to hop to the various Service Function in the= chain, does not seem to be supported.
NSH supports inline var= iable size metadata. It does not mentions explicitly that congruent out-of-= band metadata can be used.
Some metadata will need= a reliable transport service to be shared inline, as well as offline.
A protocol SCTP provide= s such a service and has the interesting characteristic to be packet based,= as opposed to stream based like TCP.
SCTP carries a sequence= number and support retransmission and congestion control.
Figure 12 s= hows how SCTP is used hop by hop between SFF in a chain to transport Metada= ta reliably.
 
 
                     |1=
  -----   |n        |21  ---- |2m=0A=
                   +---+---+   +---+---+   +-&#=
43;---+   +--+-----+=0A=
                   | SF#1  |   |SF#n   |   |SF#i1|   |SF#im   |=0A=
                   |       |   |       |   |     |   |        |=0A=
                   +---+---+   +---+---+   +--&=
#43;--+   +--+--+--+=0A=
                       :           :          :         :  :=0A=
                       :           :          :         :  :=0A=
                        \         /            \       /=0A=
    +-----------+ SCTP   +--------+    SCTP     +------=
---+=0A=
-- >| Chain     | <--->  | SFF    |    <--->    | SFF     | =
---->=0A=
    |classifier |        |Node-1  |             | Node-i  |=0A=
    +-----------+        +----+---+             +--=
--+--+-+=0A=
                  \           |                     / =0A=
                   \          | SFC Encapsulation  /=0A=
                    \         |                   /=0A=
                  ,........................................=0A=
                 /                                         \=0A=
                /                                           \=0A=
               |                      Network                |=0A=
                \                                           /=0A=
                 \........................................./=0A=
 =0A=
 
Figure 12: SCTP = for Reliable Metadata transport
SCTP SHOULD be used in = the context of Congruent out of band for reliable metadata sharing.<= /font>
For reliable Metadata t= ransport, the SFF along the chain MUST route the metadata received over SCT= P to the next SF in the chain. For this SCTP MUST be encapsulated in the SFC header.
    The SFF MUST make the received metadata available to = its SF.ti
--_000_76B41B8FACE1514795D30EC137FF391D453311CAROUBIERjungleqo_-- From nobody Thu Jul 10 11:22: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 B4BD71B2958 for ; Thu, 10 Jul 2014 11:22:48 -0700 (PDT) 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_22=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 MGb338Y_LfUk for ; Thu, 10 Jul 2014 11:22:46 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEE91A0B06 for ; Thu, 10 Jul 2014 11:22:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 126011C9CC1B; Thu, 10 Jul 2014 11:22:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id E34941C9CC26; Thu, 10 Jul 2014 11:22:43 -0700 (PDT) Message-ID: <53BED9F3.7070503@joelhalpern.com> Date: Thu, 10 Jul 2014 14:22:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nicolas BOUTHORS , "sfc@ietf.org" References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VxJzEZkCVRRjDG8K1hRPS9vB4XA Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:22:48 -0000 I look forward to seeing your draft. One of the reasons I like including the metadata with the underlying packet is that they then share fate. If the packet gets lost, the metadata disappears with it, which is frequently fine. And if the packet is probably delviered down the service path, then so is the metadata. Yours, Joel On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: > Hello, > > Metadata transport is a feature provided by SFC that needs some > additional thoughts as well. > > B Rijsman has done a great job showing various option for Metadata > sharing. Still there are 2 aspects that I would like to address further > > - Metadata representation > > - Metadata transport reliability > > We will probably post a draft on the subject, but this can be done after > Toronto has started. So for those > interested to provide some feedback, here are some highlights. > > *1. Problem Space* > * Metadata representation* > Metadata can be extremely varied in term of usage and content. It can > represent the result of Deep Packet Inspection (DPI) performed on the > traffic for example by the Classifier Service Function at the ingress of > the Service Function Chain. It can contain information collected about > the end user such as a policy identifier, a category or even represent > an event related to the end-user session. > This information can be used by Service Functions on the chain, as well > as by monitoring entities responsible to track usage for example in the > Network Function Virtualization environment to feed a VNF manager or an > Orchestrator. > Metadata being information shared by many network entities needs some > means to be represented it in all of its dimensions: type definition, > encoding and scope. > * Metadata transport service* > As expected from service chain proposals, both NSH and SCH proposals > define some means to carry metadata between Service Functions in a > Chain. They can be classified as follow: > Dataplane Metadata: > are defined in the Service Function Chaining Problem Statement document. > They are not considered to be part of the forwarding information of the > SFC header. However they are expected to carry the result of antecedent > classification, allowing Service Functions to take local policy > decisions based on their values. > > As such, they could also be interpreted directly by Service Function > Forwarder to steer traffic to various Service Functions. > Offline Metadata: > Beyond Dataplane Metadata, Offline Metadata can be shared between > Service Functions in a chain, using out of band, congruent or not, or > hybrid models described in [RIJSMAN] > > The hybrid model for example, defined in [RIJSMAN], utilizes the SFC > header to transport some key values for correlation purposes. These > Correlation Ids can be used by the Service Functions to recover the full > associated contextual information. > Metadata, directly or indirectly, are transported hop by hop along a > chain, in association to end-user traffic, the data payload of the SFC > packets. > How these metadata are transported over a chain matters. Passing > metadata directly or indirectly along packets is a service that must be > analyzed from a reliability point of view. > > Reliability requirements may vary depending on the nature of the > metadata transported. Past experience for example in Mobile Network and > data center with AAA Radius have shown that contextual information > replication to various service function was indeed sensitive to packet > loss events, and that adhoc solutions had to be implemented to detect them. > End to end TCP retransmission of packet lost does not ensure that > associated Metadata will be reinserted in retransmitted packet. In > addition, Event triggered metadata may have to be sent immediately on a > chain even though no end-user traffic is being transmitted > Not all metadata needs a reliable transport. Repeated inline metadata > can be used to cover several use cases, and some metadata loss can be > acceptable. > Still, a reliable transport service for Metadata in SFC is expected. To > this effect, an implementation is suggested in Section 3.3 > *2. Metadata representation* > Metadata definition is that it provides contextual information about the > data packets which traverse a Service Function Chain. This must be > understood broadly. > Metadata can contain the result of traffic classification by Deep Packet > Inspection (DPI). For example as an Application Id information which is > tied to a traffic flow. There could be multiple flows with different > application ids, in a chain. > Metadata can also contain the result of DPI data extraction, such as > identify requested URL in HTTP. Such information can be passed to > certain SF down the chain such as a URL filtering function. > Metadata can contain some punctual event information collected at the > Ingress point of the chain and expected to be passed to all elements in > the chain. Here this information may be triggered externally and > generated only once, and be related to the tenant or the subscriber. > Metadata representation involves the definition of a set of information > elements types and the encoding rules for their values. > Metadata representation can sometimes be performed by a single > individual field with associated type and format. However, it is not > always enough. > > * Metadata may need multiple fields transported together to > represented their values. > * Some addition fields may be required to describe the scope of the > metadata itself. This can be any information element allowing to > define the context of the associated metadata value. For example a > throughput metadata field can have a port number and a switch > address as its Scope information. > > We explore these two axis: encoding and scope. > We propose IPFIX as a preferred means to represent Metadata in Service > Chain messages for Out-of-band, Congruent or not; Metadata sharing. > *2.1. Metadata Representation Requirements* > Mandatatory Dataplane Metadata is always part of the SFC header, it is > thus reasonable to consider that its representation scheme will be > implicit: based on what the SFC protocol will dictate, their position in > the SFC header is sufficient for the receiving end to infer their type > and encoding scheme. For example, Context Header Fields in NSH are 32 > bit fields. > However, it will not be the case for all metadata transported. Offline > metadata, including congruent out-of-band metadata still need to be > represented explicitly. This section addresses their specific case. > *2.1.1. Metadata Encoding requirements* > These requirements are applicable to out-of-band metadata (Congruent or > not). It could be applicable with SCH on optional in-line metadata fields. > For interoperability purposes, metadata encoding MUST allow the > receiving entity to identify the type and value of the information > received as metadata > Metadata encoding MUST allow for encoding techniques supporting well > known types and fields as well as proprietary extensions. > A receiving entity MUST be able to identify when incoming metadata type > is unknown and MUST have a defined default action to handle it. > A piece of information may need multiple fields to be described. For > example a tenant id and an ip address can be used to identify an server > in a data center uniquely. > These groups of information have to be exchanged collectively, in a > single message. In this case, a sending entity MUST specify that it is > sending a set of metadata in a message. > This set of transported metadata elements MUST be specified under the > form of a metadata template document uniquely defined for the chain. > A receiving entity MUST be able to detect if an incoming message > contains its expected set of metadata elements. > *2.1.2. Metadata Scope requirement* > A piece of information may have to be qualified by some attributes > allowing to identify its particular scope. For example in a Gi > environment, the radio type in use may be used as a scoping criteria for > a jitter or latency measurement in a video traffic transported in a > particular service chaing. > Scope can apply to some individual metadata elements or to a set of > metadata elements. How a scope applies to a set of transported metadata > elements should be defined by a specification under the form of a > metadata template document uniquely identified for the chain. > *2.2. IPFIX Metadata representation* > So far, unordered sequences of Type Length Value encoded fields have > been proposed to transport metadata. It is not clear how structured > types are supported, and no distinction is done between the metadata > values and their scoping values. Although the SCH proposal provides an > optional 24-bit Organizational Unique Identifier, there is no namespace > mechanism allowing to separate type definition spaces per Tenants or per > chain. > We suggest to leverage the work done by IETF on similar subject. > A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for > transmitting Traffic Flow information over the network. In order to > transmit Traffic Flow information, it provides a common representation > of flow data and a standard means of communicating them. > Metadata collected by Network Node and Service Node SHOULD be encoded in > template following the principles described in IPFIX[RFC7011]. > An IPFIX Message consisting of interleaved Template, Data, and Options > Template Sets, as shown in Figure 1. Here, Template and Options Template > Sets , which are optional, are shown. > > > +--------+--------------------------------------------------------+ > | | +----------+ +---------+ +-----------+ +---------+ | > |Message | | Template | | Data | | Options | | Data | | > | Header | | Set | | Set | ... | Template | | Set | | > | | | | | | | Set | | | | > | | +----------+ +---------+ +-----------+ +---------+ | > +--------+--------------------------------------------------------+ > > > > Figure 1: IPFIX Message Format > The Template Set describes the data transmitted in the following Data > Set. It is an optional component of the message. The value of the > metadata is encoded in the first Data Set. This Data Set contains a > template Id field as a reference to its defining Template Set. > The Options Template Set describes the data to be transmitted as scope > information. It is an optional component of the message. The value of > the scope information is encoded in the second Data Set element. It no > scope information is present, then only the first Data Set is present in > the message. > The Option Template Set and following Data Set are used to describe the > scope of the metadata transmitted. For example, the metadata collected > is relevant to a PDP Context or a particular line card of a particular > switch. > * > * > *2.2.4.3. Example:* > The Metadata Exporting Process creates a Template Record with a few > Information Elements: amongst other things, the Application Id. For example: > > - sourceIPv4Address (key field) > - destinationIPv4Address (key field) > - protocol (key field) > - destinationTransportPort (key field) > - applicationId (key field) > - octetTotalCount (non key field) > > For example, a Flow Record corresponding to the above > Template Record may contain: > > { sourceIPv4Address=192.0.2.1, > destinationIPv4Address=192.0.2.2, > protocol=17, > destinationTransportPort=23, > applicationId='3..80', > octetTotalCount=123456 } > > > > The Options Data Record associated with the examples above would contain > the Scoping inforamtion: > > Scope: > - servicePath, > - serviceIndex, > - applicationId, > - applicationName > - applicationDescription. > > For example: > > { > servicePath=0x000b, > serviceIndex=0x000c, > applicationId='13...10000', > applicationName="webex", > applicationDescription="Webex application" } > > > > Scope information is useful when sending metadata offline, as it can > contain information related to the chain and possibly to the flow for > which this metadata record is relevant. Here servicePath and > serviceIndex are thus included in the Template. > *2.2.4.4. IPFIX encoding and template provisioning:* > IPFIX is a quite compact encoding > For a template defined as followed and shared by the SF in a chain. > IPFIX template record shared by SF: > Note that an XML representation of IPFIX template record could be > defined and used to provision Service Functions. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 28 octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count = 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ipNextHopIPv4Address = 15 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetDeltaCount = 2 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 7: IPFIX Metadata template Encoding > An encoded IP fix transport message will be: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 64 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.254 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5009 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5344385 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 8: IPFIX Metadata Encoding > *3. Metadata transport service* > These different use cases for Metadata generate some requirements on the > reliability capabilities of the Metadata transport service they will > rely on. > De facto Service Function Chain proposals such as NSH and SCH define a > mechanism for sharing information along the Chains. It is thus important > to define this transport service in term of reliability. > The primary focus of these proposal are the Metadata elements playing a > role in the Service Function Chain deployment to apply policies on > incoming traffic at some relevant Service Functions. > For example, Network Orchestration is expected to be a significant > driver for deployment of Network Services. It relies on Service Level > abstractions such as Group Policies, Contracts and Services as an input > for the orchestration of Service Function Chains. Specific metadata > attributes such as L4-L7 fields are used as classification elements or > filters to funnel packets into chains. > Service Functions may have other needs for Metadata, for example Event > Based Metadata tied to some subscriber related state changes. The > complexity and length of these elements cannot be forseen as limited, > neither can be how critical it is that they are safely carried > throughout a chain. In the following Section we propose to take > avantage of Congruent Metadata Transport can be used, possibly reliably, > to address these needs. > *3.1. Proposed Metadata transport mechanisms* > . > *3.1.3. Metadata transport analysis* > Both NSH and SCH proposals support both inbound and offline out-of-band > metadata transport. > > 1. In-band: the metadata can be included directly as a value in some of > the NSH Context Header Fields. It is the preferred transport model > for SCH. > > In such case, when a particular field is always set to the same > value for all packets transported by the chain instance, then the > metadata transport service is in effect reliable. > > Similarly, all the packet for a particular flow (defined by its 5 > tupple), could receive the same metadata value. The metadata > transport service is also reliable, provided that the value is > understood to be attached to a flow. > > The general case however, occurs when the metadata varies from > packet to packet in a flow. The value is then tied to a specific > packet. Here the transport service is not reliable. A retransmission > of a particular packet would not necessarily lead it to carry the > same metadata value. > 2. Out-of-band: a reference for some metadata is sent along a packet so > that it can be used via an interaction with a controller entity. It > is the preferred model for NSH, but could also be used by SCH. > > As for the in-band case, the metadata referred to indirectly can be > transmitted reliably, when its value remains the same for a chain or > a flow in a chain. a chain or a flow in a chain. > > If however, the correlation Id passed changes over time, or if the > Metadata itself cahanges then the correct Metadata may not be > efficiently retrieved by some Service Functions. > > We can see that NSH and SCH do not address the need for a reliable > transport service for metadata, independantly of the reliability > characteristic of the transport service used for the data packets. > Conventions can be used as particular cases when some metadata pertains > to a specific chain or a flow in the chain, and when its value does not > change overtime. > Such conventions however are weak. They would suppose that some > mechanism exists to ensure/monitor that they are followed. And some > exceptions mechanism would be required to deal with error cases. > *3.2. Support for Congruent out-of-band transport service* > Congruent out-of-band metadata sharing can be required for some types of > Metadata exchanges. It has the advantage of clearly tying the metadata > to the chain and not to a specific packet, and to avoid payload > fragmentation issues. > Up to draft 2, NSH did not allow for long inline metadata transport. > Four 32 bits context fields are reserved for that purpose, and seem best > suited for offline Metadata sharing, or to transport predefined policy > identifiers. > NSH (since draf 3) as well as SCH could allow for metadata transport, > either tied to a packet or possibly tied to the chain, when used without > payload, as signaling messages. > SCH however stipulates that in case the Path Identifier and SF Index > fields shall be set to zero for transmit and ignored upon receipt, when > the SCH packet will contain only metadata. So congruent out-of-band > metadata, transporting Metadata hop to hop to the various Service > Function in the chain, does not seem to be supported. > NSH supports inline variable size metadata. It does not mentions > explicitly that congruent out-of-band metadata can be used. > *3.3. Reliable transport service* > Some metadata will need a reliable transport service to be shared > inline, as well as offline. > A protocol SCTP provides such a service and has the interesting > characteristic to be packet based, as opposed to stream based like TCP. > SCTP carries a sequence number and support retransmission and congestion > control. > Figure 12 shows how SCTP is used hop by hop between SFF in a chain to > transport Metadata reliably. > > |1 ----- |n |21 ---- |2m > +---+---+ +---+---+ +-+---+ +--+-----+ > | SF#1 | |SF#n | |SF#i1| |SF#im | > | | | | | | | | > +---+---+ +---+---+ +--+--+ +--+--+--+ > : : : : : > : : : : : > \ / \ / > +-----------+ SCTP +--------+ SCTP +---------+ > -- >| Chain | <---> | SFF | <---> | SFF | ----> > |classifier | |Node-1 | | Node-i | > +-----------+ +----+---+ +----+--+-+ > \ | / > \ | SFC Encapsulation / > \ | / > ,........................................ > / \ > / \ > | Network | > \ / > \........................................./ > > > > Figure 12: SCTP for Reliable Metadata transport > SCTP SHOULD be used in the context of Congruent out of band for reliable > metadata sharing. > For reliable Metadata transport, the SFF along the chain MUST route the > metadata received over SCTP to the next SF in the chain. For this SCTP > MUST be encapsulated in the SFC header. > The SFF MUST make the received metadata available to its SF.ti > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Jul 10 11:34: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 6AFB31A0B06 for ; Thu, 10 Jul 2014 11:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 VzvOm6x3w74a for ; Thu, 10 Jul 2014 11:34:13 -0700 (PDT) Received: from omr-m02.mx.aol.com (omr-m02.mx.aol.com [64.12.143.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D741A0AFF for ; Thu, 10 Jul 2014 11:34:12 -0700 (PDT) Received: from mtaout-mbc01.mx.aol.com (mtaout-mbc01.mx.aol.com [172.26.221.141]) by omr-m02.mx.aol.com (Outbound Mail Relay) with ESMTP id 9E2FE702B5B49; Thu, 10 Jul 2014 14:34:11 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 590B838000087; Thu, 10 Jul 2014 14:34:11 -0400 (EDT) Date: Thu, 10 Jul 2014 14:34:10 -0400 From: "mikebianc@aol.com" To: I.Smith@F5.com, sfc@ietf.org Message-ID: <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1269_527602286.1405017250761" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405017251; bh=E3PzyeCrXqLad8jFvOkXht81gt+PkOMqnutLcXAaF3o=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=fWVXQce6MdfX/ouLBfLW1O+WiaIM9rzYPVR3prOz8dFMAlLSlAwDZPK4UqTquQ6Y/ zbe4Caa3WDMZtvObqxWQVrmIzDsrNzO73OrxULW83I6q3gCp8lFiKzeUfEwAJIiGGk vrytbo31m+Liu8h4o6PWaZLcVOpfholLSTfDNlm0= x-aol-sid: 3039ac1add8d53bedca3001e X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lLNkOk7C63GmQi5GU0z9Bu_In4g Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:34:17 -0000 ------=_Part_1269_527602286.1405017250761 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path."=C2=A0 Is it service function that makes that decision? or the service function in= stance? From: I.Smith@F5.com To: Changcheng Huang,'Ron Parker','Lucy yong',mohamed.boucadair@orange.c= om,mikebianc@aol.com,jmh@j= oelhalpern.com,sfc@ietf.org Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers P {margin-top:0;margin-bottom:0;} >Service functions should make the decision about which instances will be used I think it is sufficient for the architecture to say, =20 "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." But you also say need to say,=20 "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the = decision about which Service Function Instances will be used when selecting= the Service Function Path." and,=20 "External orchestration frameworks MAY make the decision about which Service Functio= n Instances will be used when selecting the Service Function Path." All three result in a Service Function Path being selected, and they aren't ne= cessarily exclusive of one another if you have rules for resolving conflict= s; the details of those rules are not architectural. IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two. =20 From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.c= arleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.= com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I agree with Ron=E2=80=99s comments. Service functions should make the deci= sion about which instances will be used. It can be different hop-by-hop (e.= g. in a tree topology). In order to do so, it is important a physical network makes a s= ervice function chain aware of the available instances. These is no need to= identify each possible SFP by a physical network. If a service function ch= ain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, becau= se a physical network need to support multiple tenants, it does need to ide= ntify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-re= cursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpful for this discussion. =20 Chang =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhal= pern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 It is architecturally significant to identify that multiple addressable ins= tances of a service function are explicitly allowed. Whether those instan= ce perform some further level of load balancing is irrelevant, as has been pointed ou= t by Joel. It is also architecturally significant to assign responsibili= ty for instance selection. In particular, is the instance selection cent= ralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities= to achieve this? In November, 2013, after IETF 88, I submitted this draf= t, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which propose= d that the instance selection was made hop by hop by the service functions = themselves, in a fully distributed manner. That was just a proposal and I= am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2= =80=99d like to see the architecture describe things. It should be able t= o answer the question, =E2=80=9Chow does multi-instance selection work in S= FC?=E2=80=9D in a concise manner. If the group feels that there should be more than one answer to that question, so be it, but we sh= ould be able to describe the high level mechanism and rationale for each su= ccinctly. Of course, that is merely one such question and there are many= others that an architectural document should be able to describe. =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mikebianc@aol.com;=20 jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. =20 Lucy =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com;=20 sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Re-, =20 The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. =20 Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. =20 SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solution-oriente= d discussion. =20 Cheers, Med =20 De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers =20 Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. =20 To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. =20 =20 If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. =20 =20 =20 From: jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. But what do we intend? I will try to explain my personal view, and see=20 if that helps. In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used=20 in any solution. 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to=20 think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without=20 visiting any other service functions. That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_1269_527602286.1405017250761 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
"Service Functions MAY make the de= cision about which Service Function Instances will be used when selecting t= he Service Function Path." 

Is it service function that makes that decision? or the servi= ce function instance?



From: I.Smith@F5.com<I.Smith@F5.com>
To: Chang= cheng Huang<huang@sce.carleton.ca>,'Ron Parker'<Ron_Parker@affirme= dnetworks.com>,'Lucy yong'<lucy.yong@huawei.com>,mohamed.boucadair= @orange.com<mohamed.boucadair@orange.com>,mikebianc@aol.com<mikebi= anc@aol.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,sfc@ietf.org= <sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject:= RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path."

But you also say need to say,

= "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the = decision about which Service Function Instances will be used when selecting= the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Functio= n Instances will be used when selecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't ne= cessarily exclusive of one another if you have rules for resolving conflict= s; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two.
From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Hu= ang [huang@sce.carleton.ca] Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@jo= elhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I agree with Ron=E2=80= =99s comments. Service functions should make the decision about which insta= nces will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a s= ervice function chain aware of the available instances. These is no need to= identify each possible SFP by a physical network. If a service function ch= ain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, becau= se a physical network need to support multiple tenants, it does need to ide= ntify different tenants. Our recent contribution (https://datatracker.ietf.org= /doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this i= ssue in a more general architecture. Hope it can be helpful for this discussion.

Chang

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; moham= ed.boucadair@orange.com; mikebianc= @aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

It is architecturally s= ignificant to identify that multiple addressable instances of a service fun= ction are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed ou= t by Joel. It is also architecturally significant to assign responsibili= ty for instance selection. In particular, is the instance selection cent= ralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities= to achieve this? In November, 2013, after IETF 88, I submitted this draf= t, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which pro= posed that the instance selection was made hop by hop by the service functi= ons themselves, in a fully distributed manner. That was just a proposal a= nd I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2= =80=99d like to see the architecture describe things. It should be able t= o answer the question, =E2=80=9Chow does multi-instance selection work in S= FC?=E2=80=9D in a concise manner. If the group feels that there should be more than one answer to that question, so be it, but we sh= ould be able to describe the high level mechanism and rationale for each su= ccinctly. Of course, that is merely one such question and there are many= others that an architectural document should be able to describe.

Ron

From: sfc = [mailto:sfc-bounc= es@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; = sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

Agree. The arch. doc sh= ould not mandate only use of the service path identifier to drive the forwa= rding actions.

Lucy

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces= @ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc= @aol.com; jmh@joelhalpern.co= m; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

Re-,

The merged draft calls out explicitly a se= rvice path identifier. I object to use that identifier to derive forwarding= actions.

Requiring a SFC system to have the full kn= owledge of every available SFC forwarding paths within an SFC-enabled domai= n is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the = piece of information that will be present in all deployments: that is the o= ne required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriente= d discussion.

Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=C3=A9 : mercredi 9 juillet 2014 22:03
=C3=80 : jm= h@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still questioning the differen= ce between SF Chain and SF Path? Other than clarifying the definition so t= hat it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still uncle= ar is whether it is the intent of this draft to ultimately specify what the= ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draf= t would have require that both SFP and SFC be supported (or make one requir= ed and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh= @joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

------=_Part_1269_527602286.1405017250761-- From nobody Thu Jul 10 11:37: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 C1E1A1B278C for ; Thu, 10 Jul 2014 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 Yzu-UNYB4la0 for ; Thu, 10 Jul 2014 11:36:53 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204181A0AFF for ; Thu, 10 Jul 2014 11:36:53 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 81AB853EB9; Thu, 10 Jul 2014 11:36:51 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 11:36:51.480 -0700 x-echoworx-msg-id: 8108adc8-bf69-49f9-939e-7391f458999e x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 572; Thu, 10 Jul 2014 11:36:51 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 5B24253F23; Thu, 10 Jul 2014 11:36:51 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 11:36:52 -0700 From: Ron Parker To: "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgD//4xGQIAAi9yAgAAIWgCAABn5AP//itUw Date: Thu, 10 Jul 2014 18:36:52 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4226MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Zev0JxRg50w-_WE2HekxGdNJjTY Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:36:56 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4226MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1pa2UuDQoNCkJldHdlZW4gc2VydmljZSBmdW5jdGlvbiBhbmQgc2VydmljZSBmdW5jdGlv biBpbnN0YW5jZSwgSSB0aGluayBpdCB3b3VsZCBoYXZlIHRvIGJlIHRoZSBpbnN0YW5jZSwgc2lu Y2UgdGhlIGZvcm1lciBpcyBjb25jZXB0dWFsLiAgICBCdXQsIGluIGEgZGlzdHJpYnV0ZWQgcGF0 aCBzZWxlY3Rpb24gYXBwcm9hY2gsIG1pZ2h0IGl0IG1ha2Ugc2Vuc2UgdG8gYXNzaWduIHRoaXMg ZHV0eSB0byB0aGUgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXIgKFNGRik/DQoNCiAgIFJvbg0K DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg bWlrZWJpYW5jQGFvbC5jb20NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MzQgUE0N ClRvOiBJLlNtaXRoQEY1LmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KDQoiU2VydmljZSBGdW5j dGlvbnMgTUFZIG1ha2UgdGhlIGRlY2lzaW9uIGFib3V0IHdoaWNoIFNlcnZpY2UgRnVuY3Rpb24g SW5zdGFuY2VzIHdpbGwgYmUgdXNlZCB3aGVuIHNlbGVjdGluZyB0aGUgU2VydmljZSBGdW5jdGlv biBQYXRoLiINCg0KSXMgaXQgc2VydmljZSBmdW5jdGlvbiB0aGF0IG1ha2VzIHRoYXQgZGVjaXNp b24/IG9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlPw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogSS5TbWl0aEBGNS5jb208SS5TbWl0aEBGNS5jb208bWFp bHRvOkkuU21pdGhARjUuY29tJTNjSS5TbWl0aEBGNS5jb20+Pg0KVG86IENoYW5nY2hlbmcgSHVh bmc8aHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Piwn Um9uIFBhcmtlcic8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LCdMdWN5IHlvbmcnPGx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4+LG1pa2ViaWFuY0Bhb2wuY29tPG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbT4+LGptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0K U3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQo+U2VydmljZSBmdW5jdGlvbnMgc2hvdWxkIG1ha2UgdGhlIGRlY2lzaW9uIGFib3V0IHdo aWNoIGluc3RhbmNlcyB3aWxsIGJlIHVzZWQNCg0KSSB0aGluayBpdCBpcyBzdWZmaWNpZW50IGZv ciB0aGUgYXJjaGl0ZWN0dXJlIHRvIHNheSwNCg0KIlNlcnZpY2UgRnVuY3Rpb25zIE1BWSBtYWtl IHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyB3aWxs IGJlIHVzZWQgd2hlbiBzZWxlY3RpbmcgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4iDQoNCkJ1 dCB5b3UgYWxzbyBzYXkgbmVlZCB0byBzYXksDQoNCiJTZXJ2aWNlIEZ1bmN0aW9uIENsYXNzaWZp ZXJzIChvciBTTkYncyBvciBTRkYncywgYXMgdGhlIGNhc2UgbWF5IGJlKSBNQVkgbWFrZSB0aGUg ZGVjaXNpb24gYWJvdXQgd2hpY2ggU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMgd2lsbCBiZSB1 c2VkIHdoZW4gc2VsZWN0aW5nIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguIg0KDQphbmQsDQoN CiJFeHRlcm5hbCBvcmNoZXN0cmF0aW9uIGZyYW1ld29ya3MgTUFZIG1ha2UgdGhlIGRlY2lzaW9u IGFib3V0IHdoaWNoIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwgYmUgdXNlZCB3aGVu IHNlbGVjdGluZyB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoLiINCg0KQWxsIHRocmVlIHJlc3Vs dCBpbiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCBiZWluZyBzZWxlY3RlZCwgYW5kIHRoZXkgYXJl bid0IG5lY2Vzc2FyaWx5IGV4Y2x1c2l2ZSBvZiBvbmUgYW5vdGhlciBpZiB5b3UgaGF2ZSBydWxl cyBmb3IgcmVzb2x2aW5nIGNvbmZsaWN0czsgdGhlIGRldGFpbHMgb2YgdGhvc2UgcnVsZXMgYXJl IG5vdCBhcmNoaXRlY3R1cmFsLg0KDQpJTU8sIHRoZSBhcmNoaXRlY3R1cmUgbmVlZHMgdG8gZXJy IG9uIHRoZSBzaWRlIG9mIGJlaW5nIGRlc2NyaXB0aXZlIG92ZXIgYmVpbmcgcHJvc2NyaXB0aXZl IHdoZW4gdGhlcmUgaXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSB0d28uDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHNmYyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIENoYW5nY2hlbmcgSHVh bmcgW2h1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPl0N ClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDEyOjMxIFBNDQpUbzogJ1JvbiBQYXJrZXIn OyAnTHVjeSB5b25nJzsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlh bmNAYW9sLmNvbT47IGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KSSBhZ3JlZSB3aXRo IFJvbuKAmXMgY29tbWVudHMuIFNlcnZpY2UgZnVuY3Rpb25zIHNob3VsZCBtYWtlIHRoZSBkZWNp c2lvbiBhYm91dCB3aGljaCBpbnN0YW5jZXMgd2lsbCBiZSB1c2VkLiBJdCBjYW4gYmUgZGlmZmVy ZW50IGhvcC1ieS1ob3AgKGUuZy4gaW4gYSB0cmVlIHRvcG9sb2d5KS4gSW4gb3JkZXIgdG8gZG8g c28sIGl0IGlzIGltcG9ydGFudCBhIHBoeXNpY2FsIG5ldHdvcmsgbWFrZXMgYSBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluIGF3YXJlIG9mIHRoZSBhdmFpbGFibGUgaW5zdGFuY2VzLiBUaGVzZSBpcyBu byBuZWVkIHRvIGlkZW50aWZ5IGVhY2ggcG9zc2libGUgU0ZQIGJ5IGEgcGh5c2ljYWwgbmV0d29y ay4gSWYgYSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIHdhbnRzIHRvIHVzZSBtdWx0aXBsZSBTRlBz LCBpdCBzaG91bGQgcHJvdmlkZSB0aGUgaWRlbnRpZmllciBmb3IgZWFjaCBmbG93IHRoYXQgdXNl cyBhIHBhcnRpY3VsYXIgU0ZQIGFuZCB0aGUgY29ycmVzcG9uZGluZyBmb3J3YXJkaW5nIHJ1bGVz IChpLmUuIG5leHQgaG9wKS4gTmV2ZXJ0aGVsZXNzLCBiZWNhdXNlIGEgcGh5c2ljYWwgbmV0d29y ayBuZWVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgdGVuYW50cywgaXQgZG9lcyBuZWVkIHRvIGlkZW50 aWZ5IGRpZmZlcmVudCB0ZW5hbnRzLiBPdXIgcmVjZW50IGNvbnRyaWJ1dGlvbiAoaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmctc2ZjLXVzZS1jYXNlLXJlY3Vyc2l2 ZS1zZXJ2aWNlLyApIGhhcyBkaXNjdXNzZWQgdGhpcyBpc3N1ZSBpbiBhIG1vcmUgZ2VuZXJhbCBh cmNoaXRlY3R1cmUuIEhvcGUgaXQgY2FuIGJlIGhlbHBmdWwgZm9yIHRoaXMgZGlzY3Vzc2lvbi4N CkNoYW5nDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFJvbiBQYXJrZXINClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDg6MjAgQU0NClRv OiBMdWN5IHlvbmc7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+OyBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCkl0IGlzIGFyY2hpdGVj dHVyYWxseSBzaWduaWZpY2FudCB0byBpZGVudGlmeSB0aGF0IG11bHRpcGxlIGFkZHJlc3NhYmxl IGluc3RhbmNlcyBvZiBhIHNlcnZpY2UgZnVuY3Rpb24gYXJlIGV4cGxpY2l0bHkgYWxsb3dlZC4g V2hldGhlciB0aG9zZSBpbnN0YW5jZSBwZXJmb3JtIHNvbWUgZnVydGhlciBsZXZlbCBvZiBsb2Fk IGJhbGFuY2luZyBpcyBpcnJlbGV2YW50LCBhcyBoYXMgYmVlbiBwb2ludGVkIG91dCBieSBKb2Vs LiBJdCBpcyBhbHNvIGFyY2hpdGVjdHVyYWxseSBzaWduaWZpY2FudCB0byBhc3NpZ24gcmVzcG9u c2liaWxpdHkgZm9yIGluc3RhbmNlIHNlbGVjdGlvbi4gSW4gcGFydGljdWxhciwgaXMgdGhlIGlu c3RhbmNlIHNlbGVjdGlvbiBjZW50cmFsaXplZCwgZGlzdHJpYnV0ZWQsIG9yIHNvbWUgY29tYmlu YXRpb24/IFdoaWNoIGZ1bmN0aW9uYWwgZW50aXRpZXMgaW4gdGhlIGFyY2hpdGVjdHVyZSBoYXZl IHdoYXQgcmVzcG9uc2liaWxpdGllcyB0byBhY2hpZXZlIHRoaXM/IEluIE5vdmVtYmVyLCAyMDEz LCBhZnRlciBJRVRGIDg4LCBJIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0LCBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDAsIHdoaWNoIHByb3Bv c2VkIHRoYXQgdGhlIGluc3RhbmNlIHNlbGVjdGlvbiB3YXMgbWFkZSBob3AgYnkgaG9wIGJ5IHRo ZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGVtc2VsdmVzLCBpbiBhIGZ1bGx5IGRpc3RyaWJ1dGVkIG1h bm5lci4gVGhhdCB3YXMganVzdCBhIHByb3Bvc2FsIGFuZCBJIGFtIG5vdCB3ZWRkZWQgdG8gaXQs IGJ5IGFueSBtZWFucy4gSm9lbCBhc2tlZCBhYm91dCBzcGVjaWZpY2l0eSBhbmQgaXQgaXMgYXQg dGhpcyBsZXZlbCB0aGF0IEnigJlkIGxpa2UgdG8gc2VlIHRoZSBhcmNoaXRlY3R1cmUgZGVzY3Jp YmUgdGhpbmdzLiBJdCBzaG91bGQgYmUgYWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCDigJxo b3cgZG9lcyBtdWx0aS1pbnN0YW5jZSBzZWxlY3Rpb24gd29yayBpbiBTRkM/4oCdIGluIGEgY29u Y2lzZSBtYW5uZXIuIElmIHRoZSBncm91cCBmZWVscyB0aGF0IHRoZXJlIHNob3VsZCBiZSBtb3Jl IHRoYW4gb25lIGFuc3dlciB0byB0aGF0IHF1ZXN0aW9uLCBzbyBiZSBpdCwgYnV0IHdlIHNob3Vs ZCBiZSBhYmxlIHRvIGRlc2NyaWJlIHRoZSBoaWdoIGxldmVsIG1lY2hhbmlzbSBhbmQgcmF0aW9u YWxlIGZvciBlYWNoIHN1Y2NpbmN0bHkuIE9mIGNvdXJzZSwgdGhhdCBpcyBtZXJlbHkgb25lIHN1 Y2ggcXVlc3Rpb24gYW5kIHRoZXJlIGFyZSBtYW55IG90aGVycyB0aGF0IGFuIGFyY2hpdGVjdHVy YWwgZG9jdW1lbnQgc2hvdWxkIGJlIGFibGUgdG8gZGVzY3JpYmUuDQpSb24NCkZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVjeSB5b25nDQpTZW50 OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAxMTowNSBBTQ0KVG86IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBtaWtlYmlh bmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCkFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5 IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRp bmcgYWN0aW9ucy4NCkx1Y3kNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6 MDYgQU0NClRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNClJlLSwNClRoZSBtZXJnZWQgZHJhZnQgY2Fs bHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSBvYmplY3QgdG8g dXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUgZm9yd2FyZGluZyBhY3Rpb25zLg0KUmVxdWly aW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBhdmFp bGFibGUgU0ZDIGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBp cyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1l bnQgY29udGV4dHMuDQpTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBw aWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVu dHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWlu LiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmVyIGZvcndhcmRpbmcgYWN0aW9u cyBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQpDaGVlcnMsDQpNZWQNCkRlIDog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgbWlrZWJpYW5j QGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KRW52b3nDqSA6IG1lcmNyZWRpIDkg anVpbGxldCAyMDE0IDIyOjAzDQrDgCA6IGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0 IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpJ cyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFp biBhbmQgU0YgUGF0aD8gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRo YXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNl ZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uIHRoZXNlIHRlcm1zLg0KVG8gbWUsIHRoZSBvbmUg cG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdoZXRoZXIgaXQgaXMgdGhlIGludGVudCBv ZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRCBvZiB0aGUgU0ZD IEhlYWRlciBzaG91bGQgcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0 aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2lu ZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBi YXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yIHBhdGggdG8g YmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCklmIHRoZSBsYXR0ZXIgKGFtYmln dW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFu ZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9w dGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5nIFNGUCBhbmQgb3Ro ZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbT4+DQpUbzogc2ZjQGlldGYu b3JnPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4NClNl bnQ6IFR1ZXNkYXksIEp1bHkgOCwgMjAxNA0KU3ViamVjdDogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3Vy ZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGEgbnVtYmVyIG9mDQpjb21tZW50cyB0aGF0IGhh dmUgYmVlbiBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZCBtZXJnZWQgYXJjaHRpZWN0dXJlDQpkcmFm dC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50 ZW50LCB3ZQ0Kd2lsbCB3b3JrIHRvIGltcHJvdmUgdGhlIHdvcmRpbmcgc28gdGhhdCByZWFkZXJz IHdobyBoYXZlIG5vdA0KcGFydGljaXBhdGVkIGluIHRoZSBXRyBkaXNjdXNzaW9uIHdpbGwgdW5k ZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdvcmtpbmcNCmdyb3VwIGludGVuZHMuDQoNCkJ1dCB3aGF0 IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15IHBlcnNvbmFsIHZpZXcsIGFu ZCBzZWUNCmlmIHRoYXQgaGVscHMuDQoNCkluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQg dG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmUNCmRlZmluaW5nIGlzIHRoZSBkYXRhIHBs YW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlIG5vdCBhdHRlbXB0aW5nIHRvDQpkZWZpbmUgdGhlIGFy Y2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZSBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4N ClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5 IGZ1bmN0aW9ucywNCnZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1h bnkgb3RoZXIgYXNwZWN0cy4NCg0KQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdo aWNoIGNsZWFybHkgbmVlZCB0byBleGlzdCBpbiB0aGUNCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGlj aCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsDQphbmQgYXJl IG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUgZG9pbmcuDQoNCkluIG9y ZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0 YW5kIHRoZW0sDQpJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUg YXJlIGF0IGxlYXN0IHRocmVlDQpkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNh biBhbmQgd2lsbCBpbnRlcmFjdCB3aXRoIHNlcnZpY2UNCmNoYWluaW5nLiBUaGVyZSBwcm9iYWJs eSBhcmUgbW9yZS4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8NCnBlcm1pdCBh bGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQg YmUgdXNlZA0KaW4gYW55IHNvbHV0aW9uLg0KDQoxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZp Y2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLiBUaGlzIGlzIGENCnNlcnZpY2UgZnVuY3Rpb24u IEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzDQp0 aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlIGluc3RhbmNl IHRvIHJlY2VpdmUNCnRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50IHNlcnZp Y2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0bw0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJ dCdzIGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uDQpob3cgc2VydmljZSBjaGFp bmluZyBpcyBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCmFyY2h0 aWVjdHVyZS4gRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkg YSBzZXJ2aWNlDQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tl dC4NCg0KMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZSBj YW4gaGF2ZSB3aGF0IGFwcGVhcnMNCnRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVy ZSBhcyBhIHNpbmdsZSBwb2ludCBvZiBjb250YWN0IGZvciBhDQpzcGVjaWZpYyBzZXJ2aWNlIGZ1 bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGEgY29sbGVjdGlvbiBvZg0Kdmly dHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvciBzZXZl cmFsIGxvYWQNCmJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlIHRlY2huaXF1 ZXMgdG8gc2hhcmUgYSBNQUMNCmFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxlIHRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCm1lY2hhbmlzbXMuIEl0IGlzIGxpa2Vs eSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sDQptZWNoYW5pc21zLCBzdWNo IGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBhbmQgdm0NCmlu c3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMg aXMgbGFyZ2VseQ0KdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVybWlub2xv Z3kgZG9lcyBub3QgbGVhZCByZWFkZXJzIHRvDQp0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQu DQoNCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgc2VsZWN0aW5n IHBhY2tldCBwYXRocyBmb3INCnRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZm aWMgdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQNCm5vdCB3YW50IHRvIHJlcXVpcmUgdGhh dCBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lDQpwbGFjZSBpbiB0 aGUgbmV0d29yay4NCg0KSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJl IGNvbWJpbmVkLiBJIHRlbmQgdG8gcmVmZXIgdG8NCnRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVz IHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmcgYXMgYSBzaW5nbGUNCnBvaW50IGFzIGEg Y2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2Ug SQ0KZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsIHRoZSBwb2ludCBvZiB0eXBlIDMgbG9h ZCBiYWxhbmNpbmcgaXMgdG8NCmRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRv IGRpZmZlcmVudCBzaW5ndWxhciBvciBjbHVzdGVyZWQNCnNlcnZpY2UgZnVuY3Rpb25zIGluIGRp ZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuDQoNCk5vdyB3aXRoIHRoYXQgc2FpZCwgd2hh dCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQgc2VydmljZSBjaGFpbiBhbmQNCnNlcnZpY2Ug cGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRv IGJlDQphcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuIEl0IGlzIGVxdWl2YWxlbnQgb2Yg c2F5aW5nIHRoYXQgc29tZQ0Kc3Vic2V0IG9mIHRyYWZmaWMgaXMgdG8gZ2V0IERQSSwgY2hhcmdp bmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kDQpmaXJld2FsbCB3aGlsZSBhIGRpZmZlcmVudCBz dWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlIHdpdGhvdXQNCnZpc2l0aW5nIGFu eSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCg0KVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0 aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQSBzZXJ2aWNlIHBhdGgNCmlzLCBpbiBzb21lIGZh c2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zIGluIHRoZSBuZXR3b3JrLiBUaG9zZQ0KbG9j YXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVs aXZlcnkNCmxvY2F0aW9ucy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRo ZXkgbWF5IGJlIGFkZHJlc3NlZA0KYXMgcG9ydHMgb24gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBk aWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMNCm1heSBiZSBrbm93biB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIHRyYW5zcG9ydC4NCg0KPkZyb20g dGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91cCwgd2UgbmVlZCB0 byBiZSBhYmxlDQp0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUg c2VydmljZSBjaGFpbiwgd2hpY2gNCmRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQg dG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aA0KcGFja2V0cyB3aWxsIHRha2UgaW4g dGhlIG5ldHdvcmsuDQoNClNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRo ZSB3aG9sZSBwYXRoIG1heSBub3QgYmUga25vd24NCmF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0 ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4NCkZpcnN0LCBhcyBub3Rl ZCBpbiBpdGVtICgyKSBvbiBsb2FkIGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlDQpkZWNp c2lvbnMgYW5kIGJlaGF2aW9ycyB3aGljaCBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNo YWluaW5nDQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdp dGhpbiBhIExBTiBpcyBsYXJnZWx5DQppbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMu KSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlIG1ha2UgaXMgdGhhdA0KcmVjbGFzc2lmaWNhdGlvbiBj YW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbiBuZWNlc3NhcnkuIFRoYXQgd2lsbA0KZGlyZWN0 IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBh dCB0aGUNCnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KDQpJIGhvcGUgdGhhdCB0aGlzIGhlbHBz IGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0IGRvZXMsIGFuZCBpZg0KdGhlIGludGVu dCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3 aGF0DQphZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuDQpJZiB0aGUg d29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBj b3Vyc2UNCmFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLg0KSWYg dGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5leHQuDQoN CllvdXJzLA0KSm9lbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4226MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIE1pa2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXR3ZWVuIHNlcnZpY2UgZnVuY3Rpb24gYW5kIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UsIEkg dGhpbmsgaXQgd291bGQgaGF2ZSB0byBiZSB0aGUgaW5zdGFuY2UsIHNpbmNlIHRoZSBmb3JtZXIg aXMgY29uY2VwdHVhbC4mbmJzcDsmbmJzcDsmbmJzcDsgQnV0LCBpbiBhIGRpc3RyaWJ1dGVkIHBh dGgNCiBzZWxlY3Rpb24gYXBwcm9hY2gsIG1pZ2h0IGl0IG1ha2Ugc2Vuc2UgdG8gYXNzaWduIHRo aXMgZHV0eSB0byB0aGUgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXIgKFNGRik/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+bWlrZWJpYW5jQGFvbC5j b208YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjozNCBQTTxicj4N CjxiPlRvOjwvYj4gSS5TbWl0aEBGNS5jb207IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+JnF1b3Q7U2VydmljZSBGdW5jdGlvbnMgTUFZIG1ha2UgdGhlIGRlY2lzaW9uIGFib3V0IHdo aWNoIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwgYmUgdXNlZCB3aGVuIHNlbGVjdGlu ZyB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoLiZxdW90OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklz IGl0IHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBtYWtlcyB0aGF0IGRlY2lzaW9uPyBvciB0aGUgc2Vy dmljZSBmdW5jdGlvbiBpbnN0YW5jZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMSIg d2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50 ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPkZyb206IDwvYj48YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20lM2NJLlNt aXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb20mbHQ7SS5TbWl0aEBGNS5jb208L2E+Jmd0Ozxicj4N CjxiPlRvOiA8L2I+Q2hhbmdjaGVuZyBIdWFuZyZsdDs8YSBocmVmPSJtYWlsdG86aHVhbmdAc2Nl LmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Jmd0OywnUm9uIFBhcmtlcicm bHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0OywnTHVjeSB5b25nJyZsdDs8YSBocmVm PSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29tPC9hPiZn dDssbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4m Z3Q7LG1pa2ViaWFuY0Bhb2wuY29tJmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNv bSI+bWlrZWJpYW5jQGFvbC5jb208L2E+Jmd0OyxqbWhAam9lbGhhbHBlcm4uY29tJmx0OzxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZn dDssc2ZjQGlldGYub3JnJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNlcnZpY2UgZnVuY3Rpb25zIHNob3VsZCBtYWtlIHRoZSBkZWNpc2lvbg0KIGFi b3V0IHdoaWNoIGluc3RhbmNlcyB3aWxsIGJlIHVzZWQ8YnI+DQo8YnI+DQpJIHRoaW5rIGl0IGlz IHN1ZmZpY2llbnQgZm9yIHRoZSBhcmNoaXRlY3R1cmUgdG8gc2F5LDxicj4NCjxicj4NCiZxdW90 O1NlcnZpY2UgRnVuY3Rpb25zIE1BWSBtYWtlIHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBTZXJ2 aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyB3aWxsIGJlIHVzZWQgd2hlbiBzZWxlY3RpbmcgdGhlIFNl cnZpY2UgRnVuY3Rpb24gUGF0aC4mcXVvdDsNCjxicj4NCjxicj4NCkJ1dCB5b3UgYWxzbyBzYXkg bmVlZCB0byBzYXksIDxicj4NCjxicj4NCiZxdW90O1NlcnZpY2UgRnVuY3Rpb24gQ2xhc3NpZmll cnMgKG9yIFNORidzIG9yIFNGRidzLCBhcyB0aGUgY2FzZSBtYXkgYmUpIE1BWSBtYWtlIHRoZSBk ZWNpc2lvbiBhYm91dCB3aGljaCBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyB3aWxsIGJlIHVz ZWQgd2hlbiBzZWxlY3RpbmcgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4mcXVvdDsNCjxicj4N Cjxicj4NCmFuZCwgPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZxdW90O0V4dGVybmFsIG9yY2hlc3RyYXRpb24gZnJhbWV3b3JrcyBNQVkgbWFrZSB0 aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMgd2lsbCBi ZSB1c2VkIHdoZW4gc2VsZWN0aW5nIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguJnF1b3Q7PGJy Pg0KPGJyPg0KQWxsIHRocmVlIHJlc3VsdCBpbiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCBiZWlu ZyBzZWxlY3RlZCwgYW5kIHRoZXkgYXJlbid0IG5lY2Vzc2FyaWx5IGV4Y2x1c2l2ZSBvZiBvbmUg YW5vdGhlciBpZiB5b3UgaGF2ZSBydWxlcyBmb3IgcmVzb2x2aW5nIGNvbmZsaWN0czsgdGhlIGRl dGFpbHMgb2YgdGhvc2UgcnVsZXMgYXJlIG5vdCBhcmNoaXRlY3R1cmFsLjxicj4NCjxicj4NCklN TywgdGhlIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBlcnIgb24gdGhlIHNpZGUgb2YgYmVpbmcgZGVz Y3JpcHRpdmUgb3ZlciBiZWluZyBwcm9zY3JpcHRpdmUgd2hlbiB0aGVyZSBpcyBhIGNvbmZsaWN0 IGJldHdlZW4gdGhlIHR3by48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjYuNzVwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0K PGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4N CjxkaXYgaWQ9ImRpdlJwRjI1Mjc4NyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBDaGFuZ2NoZW5nIEh1YW5nIFs8YSBocmVm PSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+ XTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAxMjozMSBQTTxicj4N CjxiPlRvOjwvYj4gJ1JvbiBQYXJrZXInOyAnTHVjeSB5b25nJzsgPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5j b208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFs cGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdy ZWUgd2l0aCBSb27igJlzIGNvbW1lbnRzLiBTZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgbWFrZSB0 aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggaW5zdGFuY2VzIHdpbGwNCiBiZSB1c2VkLiBJdCBjYW4g YmUgZGlmZmVyZW50IGhvcC1ieS1ob3AgKGUuZy4gaW4gYSB0cmVlIHRvcG9sb2d5KS4gSW4gb3Jk ZXIgdG8gZG8gc28sIGl0IGlzIGltcG9ydGFudCBhIHBoeXNpY2FsIG5ldHdvcmsgbWFrZXMgYSBz ZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGF3YXJlIG9mIHRoZSBhdmFpbGFibGUgaW5zdGFuY2VzLiBU aGVzZSBpcyBubyBuZWVkIHRvIGlkZW50aWZ5IGVhY2ggcG9zc2libGUgU0ZQIGJ5IGEgcGh5c2lj YWwgbmV0d29yay4NCiBJZiBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gd2FudHMgdG8gdXNlIG11 bHRpcGxlIFNGUHMsIGl0IHNob3VsZCBwcm92aWRlIHRoZSBpZGVudGlmaWVyIGZvciBlYWNoIGZs b3cgdGhhdCB1c2VzIGEgcGFydGljdWxhciBTRlAgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGZvcndh cmRpbmcgcnVsZXMgKGkuZS4gbmV4dCBob3ApLiBOZXZlcnRoZWxlc3MsIGJlY2F1c2UgYSBwaHlz aWNhbCBuZXR3b3JrIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSB0ZW5hbnRzLA0KIGl0IGRvZXMg bmVlZCB0byBpZGVudGlmeSBkaWZmZXJlbnQgdGVuYW50cy4gT3VyIHJlY2VudCBjb250cmlidXRp b24gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1YW5n LXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1zZmMtdXNlLWNhc2UtcmVjdXJz aXZlLXNlcnZpY2UvPC9hPiApIGhhcw0KIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGluIGEgbW9yZSBn ZW5lcmFsIGFyY2hpdGVjdHVyZS4gSG9wZSBpdCBjYW4gYmUgaGVscGZ1bCBmb3IgdGhpcyBkaXNj dXNzaW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNoYW5nDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjwvYT48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiBzZmMgWzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+Um9uIFBhcmtlcjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAxMCwgMjAxNCA4OjIwIEFNPGJyPg0KPGI+VG86PC9iPiBMdWN5IHlvbmc7IDxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+ bWlrZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SXQgaXMgYXJjaGl0ZWN0dXJhbGx5IHNpZ25pZmljYW50IHRvIGlkZW50aWZ5IHRoYXQgbXVs dGlwbGUgYWRkcmVzc2FibGUgaW5zdGFuY2VzIG9mIGEgc2VydmljZSBmdW5jdGlvbg0KIGFyZSBl eHBsaWNpdGx5IGFsbG93ZWQuIFdoZXRoZXIgdGhvc2UgaW5zdGFuY2UgcGVyZm9ybSBzb21lIGZ1 cnRoZXIgbGV2ZWwgb2YgbG9hZCBiYWxhbmNpbmcgaXMgaXJyZWxldmFudCwgYXMgaGFzIGJlZW4g cG9pbnRlZCBvdXQgYnkgSm9lbC4gSXQgaXMgYWxzbyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNh bnQgdG8gYXNzaWduIHJlc3BvbnNpYmlsaXR5IGZvciBpbnN0YW5jZSBzZWxlY3Rpb24uIEluIHBh cnRpY3VsYXIsIGlzIHRoZSBpbnN0YW5jZQ0KIHNlbGVjdGlvbiBjZW50cmFsaXplZCwgZGlzdHJp YnV0ZWQsIG9yIHNvbWUgY29tYmluYXRpb24/IFdoaWNoIGZ1bmN0aW9uYWwgZW50aXRpZXMgaW4g dGhlIGFyY2hpdGVjdHVyZSBoYXZlIHdoYXQgcmVzcG9uc2liaWxpdGllcyB0byBhY2hpZXZlIHRo aXM/IEluIE5vdmVtYmVyLCAyMDEzLCBhZnRlciBJRVRGIDg4LCBJIHN1Ym1pdHRlZCB0aGlzIGRy YWZ0LA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFya2VyLXNm Yy1jaGFpbi10by1wYXRoLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1wYXJrZXItc2ZjLWNoYWluLXRvLXBhdGgtMDA8L2E+LCB3aGljaCBwcm9w b3NlZCB0aGF0IHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gd2FzIG1hZGUgaG9wIGJ5IGhvcCBieSB0 aGUgc2VydmljZSBmdW5jdGlvbnMgdGhlbXNlbHZlcywgaW4gYSBmdWxseSBkaXN0cmlidXRlZCBt YW5uZXIuIFRoYXQgd2FzIGp1c3QgYSBwcm9wb3NhbCBhbmQgSSBhbSBub3Qgd2VkZGVkIHRvIGl0 LCBieSBhbnkgbWVhbnMuDQogSm9lbCBhc2tlZCBhYm91dCBzcGVjaWZpY2l0eSBhbmQgaXQgaXMg YXQgdGhpcyBsZXZlbCB0aGF0IEnigJlkIGxpa2UgdG8gc2VlIHRoZSBhcmNoaXRlY3R1cmUgZGVz Y3JpYmUgdGhpbmdzLiBJdCBzaG91bGQgYmUgYWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCDi gJxob3cgZG9lcyBtdWx0aS1pbnN0YW5jZSBzZWxlY3Rpb24gd29yayBpbiBTRkM/4oCdIGluIGEg Y29uY2lzZSBtYW5uZXIuIElmIHRoZSBncm91cCBmZWVscyB0aGF0IHRoZXJlIHNob3VsZA0KIGJl IG1vcmUgdGhhbiBvbmUgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24sIHNvIGJlIGl0LCBidXQgd2Ug c2hvdWxkIGJlIGFibGUgdG8gZGVzY3JpYmUgdGhlIGhpZ2ggbGV2ZWwgbWVjaGFuaXNtIGFuZCBy YXRpb25hbGUgZm9yIGVhY2ggc3VjY2luY3RseS4gT2YgY291cnNlLCB0aGF0IGlzIG1lcmVseSBv bmUgc3VjaCBxdWVzdGlvbiBhbmQgdGhlcmUgYXJlIG1hbnkgb3RoZXJzIHRoYXQgYW4gYXJjaGl0 ZWN0dXJhbCBkb2N1bWVudCBzaG91bGQgYmUNCiBhYmxlIHRvIGRlc2NyaWJlLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJv bjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNmYw0KIFs8YSBo cmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MdWN5IHlvbmc8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMTE6MDUgQU08YnI+DQo8 Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47DQo8YSBocmVm PSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtlYmlhbmNAYW9s LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9i bGFuayI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFu ZGF0ZSBvbmx5IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhl IGZvcndhcmRpbmcNCiBhY3Rpb25zLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4gc2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjowNiBBTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIiB0YXJnZXQ9Il9i bGFuayI+bWlrZWJpYW5jQGFvbC5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2ZjQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5SZS0sPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEg c2VydmljZSBwYXRoIGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIg dG8gZGVyaXZlDQogZm9yd2FyZGluZyBhY3Rpb25zLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUg ZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgYXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nIHBhdGhzIHdp dGhpbiBhbiBTRkMtZW5hYmxlZA0KIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5v ciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5TRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNo b3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmUgcHJlc2Vu dCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQNCiBpcyB0aGUgb25lIHJlcXVpcmVkIHRvIHN0cnVj dHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgdG8gaW5m ZXIgZm9yd2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lZDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkRlIDo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+DQogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+RGUgbGEgcGFydCBkZTwvYj4gPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KPGI+RW52b3nDqSA6PC9i PiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMzxicj4NCjxiPsOAIDo8L2I+IDxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0IDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5JcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBT RiBDaGFpbiBhbmQgU0YgUGF0aD8gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9u DQogc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRob3NlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBkcmFm dCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24gdGhlc2UgdGVybXMuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMg d2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVj aWZ5DQogd2hhdCB0aGUgSUQgb2YgdGhlIFNGQyBIZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhl IGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkgaW50ZW5kcyB0byBs ZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvIGRpY3RhdGUgdGhl IG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3IgcGF0aCBhbmQgdGhl IGNob2ljZSBvZiBjaGFpbiBvciBwYXRoIHRvIGJlIG5lZ290aWF0ZWQNCiBpbiB0aGUgY29udHJv bC1wbGFuZS4gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0 aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlIHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJl IHN1cHBvcnRlZCAob3IgbWFrZQ0KIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFs KSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9u bHkgc3VwcG9ydGluZyBTRkMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVw dCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0 aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb20mbHQ7am1oQGpvZWxoYWxwZXJu LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn JTNjc2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnJmx0O3NmY0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPlR1ZXNkYXksIEp1bHkgOCwgMjAxNDxicj4N CjxiPlN1YmplY3Q6IDwvYj5bc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vyczxicj4NCjxicj4NCkkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0 byBjbGVhcmx5IGFuc3dlciBhIG51bWJlciBvZiA8YnI+DQpjb21tZW50cyB0aGF0IGhhdmUgYmVl biBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZCBtZXJnZWQgYXJjaHRpZWN0dXJlIDxicj4NCmRyYWZ0 LiBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRl bnQsIHdlIDxicj4NCndpbGwgd29yayB0byBpbXByb3ZlIHRoZSB3b3JkaW5nIHNvIHRoYXQgcmVh ZGVycyB3aG8gaGF2ZSBub3QgPGJyPg0KcGFydGljaXBhdGVkIGluIHRoZSBXRyBkaXNjdXNzaW9u IHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdvcmtpbmcgPGJyPg0KZ3JvdXAgaW50ZW5k cy48YnI+DQo8YnI+DQpCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFp biBteSBwZXJzb25hbCB2aWV3LCBhbmQgc2VlIDxicj4NCmlmIHRoYXQgaGVscHMuPGJyPg0KPGJy Pg0KSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdCB3 aGF0IHdlIGFyZSA8YnI+DQpkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUu IFdlIGFyZSBub3QgYXR0ZW1wdGluZyB0byA8YnI+DQpkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBm b3IgdGhlIGVudGlyZSBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gPGJyPg0KVGhhdCB3 b3VsZCBlbmNvbXBhc3MgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rp b25zLCA8YnI+DQp2aXJ0dWFsIG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55 IG90aGVyIGFzcGVjdHMuPGJyPg0KPGJyPg0KQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhp bmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0byBleGlzdCBpbiB0aGUgPGJyPg0KbGFyZ2VyIHN5c3Rl bSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFyZSBmdW5jdGlvbmlu ZywgPGJyPg0KYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJl IGRvaW5nLjxicj4NCjxicj4NCkluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNl cnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0YW5kIHRoZW0sIDxicj4NCkkgbmVlZCB0byBmaXJzdCBk aXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUgPGJyPg0KZGlm ZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwgaW50ZXJhY3Qgd2l0 aCBzZXJ2aWNlIDxicj4NCmNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS4gVGhlIHBv aW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gPGJyPg0KcGVybWl0IGFsbCBvZiB0aGVzZSwg YnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2VkIDxicj4N CmluIGFueSBzb2x1dGlvbi48YnI+DQo8YnI+DQoxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZp Y2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLiBUaGlzIGlzIGEgPGJyPg0Kc2VydmljZSBmdW5j dGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9kaWZpZXMgdGhlbSAob3IgbWFy a3MgPGJyPg0KdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vydmlj ZSBpbnN0YW5jZSB0byByZWNlaXZlIDxicj4NCnRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4g aW1wb3J0YW50IHNlcnZpY2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0byA8YnI+DQppbmNsdWRlIGlu IHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMg b24gPGJyPg0KaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxp dHRsZSBpbXBhY3Qgb24gdGhlIDxicj4NCmFyY2h0aWVjdHVyZS4gRnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYSBzZXJ2aWNlIDxicj4NCmZ1bmN0aW9uIHdo aWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Ljxicj4NCjxicj4NCjIpIFRoZXJl IGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuIGhhdmUgd2hhdCBh cHBlYXJzIDxicj4NCnRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNp bmdsZSBwb2ludCBvZiBjb250YWN0IGZvciBhIDxicj4NCnNwZWNpZmljIHNlcnZpY2UgZnVuY3Rp b24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQgYnkgYSBjb2xsZWN0aW9uIG9mIDxicj4NCnZp cnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3Igc2V2 ZXJhbCBsb2FkIDxicj4NCmJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlIHRl Y2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgPGJyPg0KYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcyBp bnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZSA8YnI+DQptZWNoYW5p c21zLiBJdCBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbCA8 YnI+DQptZWNoYW5pc21zLCBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwg c2NhbGUtb3V0LCBhbmQgdm0gPGJyPg0KaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwg aW1wYWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJnZWx5IDxicj4NCnRoYXQgd2UgbmVlZCB0 byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5IGRvZXMgbm90IGxlYWQgcmVhZGVycyB0 byA8YnI+DQp0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuPGJyPg0KPGJyPg0KMykgVGhlcmUg Y2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0IHBhdGhz IGZvciA8YnI+DQp0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdCB0cmFmZmljIHRvIGRp ZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIDxicj4NCm5vdCB3YW50IHRvIHJlcXVpcmUgdGhhdCBh IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lIDxicj4NCnBsYWNlIGlu IHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCkl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRo ZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kIHRvIHJlZmVyIHRvIDxicj4NCnRoZSBjb2xsZWN0 aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmcgYXMgYSBzaW5n bGUgPGJyPg0KcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGEgZ29v ZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIDxicj4NCmRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVz LCB0aGUgcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlzIHRvIDxicj4NCmRpcmVjdCBk aWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudCBzaW5ndWxhciBvciBjbHVz dGVyZWQgPGJyPg0Kc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUg bmV0d29yay48YnI+DQo8YnI+DQpOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdo ZW4gSSB0YWxrIGFib3V0IHNlcnZpY2UgY2hhaW4gYW5kIDxicj4NCnNlcnZpY2UgcGF0aC8gU2Vy dmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIDxicj4N CmFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlp bmcgdGhhdCBzb21lIDxicj4NCnN1YnNldCBvZiB0cmFmZmljIGlzIHRvIGdldCBEUEksIGNoYXJn aW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnI+DQpmaXJld2FsbCB3aGlsZSBhIGRpZmZl cmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlIHdpdGhvdXQgPGJyPg0K dmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLjxicj4NCjxicj4NClRoYXQgaXMg bm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tldHMuIEEgc2VydmljZSBw YXRoIDxicj4NCmlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zIGlu IHRoZSBuZXR3b3JrLiBUaG9zZSA8YnI+DQpsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvciBj bHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSA8YnI+DQpsb2NhdGlvbnMuIFRoZXkg bWF5IGJlIGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgPGJy Pg0KYXMgcG9ydHMgb24gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0 IHRoZSBsb2NhdGlvbnMgPGJyPg0KbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5n IGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Ljxicj4NCjxicj4NCiZndDtGcm9tIHRo ZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3JvdXAsIHdlIG5lZWQgdG8g YmUgYWJsZSA8YnI+DQp0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0 aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggPGJyPg0KZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQg d2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIDxicj4NCnBhY2tldHMg d2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NClNldmVyYWwgb2YgdGhlIGNvbW1l bnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdob2xlIHBhdGggbWF5IG5vdCBiZSBrbm93biA8 YnI+DQphdCB0aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhh dCBpc3N1ZSBpbiB0d28gd2F5cy4gPGJyPg0KRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9u IGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgPGJyPg0KZGVjaXNpb25zIGFuZCBi ZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyA8YnI+ DQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBh IExBTiBpcyBsYXJnZWx5IDxicj4NCmludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4p IFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0aGF0IDxicj4NCnJlY2xhc3NpZmljYXRp b24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdpbGwgPGJy Pg0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uIGluZm9ybWF0aW9uIGF2 YWlsYWJsZSBhdCB0aGUgPGJyPg0KcmUtY2xhc3NpZmljYXRpb24gcG9pbnQuPGJyPg0KPGJyPg0K SSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBk b2VzLCBhbmQgaWYgPGJyPg0KdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5n IGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IDxicj4NCmFkZGl0aW9uYWwgd29yZHMgYXJl IG5lZWRlZCB0byBjb252ZXkgdGhpcy48YnI+DQpJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3Jl ZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgPGJyPg0KYWRqdXN0IHRv IG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuPGJyPg0KSWYgdGhpcyBpcyBzdGls bCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5leHQuPGJyPg0KPGJyPg0KWW91 cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4226MBX021W3CA2exch_-- From nobody Thu Jul 10 11: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 E615F1B294C for ; Thu, 10 Jul 2014 11:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.051 X-Spam-Level: X-Spam-Status: No, score=-7.051 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 evq9-S1oTX_7 for ; Thu, 10 Jul 2014 11:40:10 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18B11A0B12 for ; Thu, 10 Jul 2014 11:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405017610; x=1436553610; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=k2+3UoKWWBN3PbiQUXc8Irhelttd/lemOiVMXig0aKU=; b=pCgt026fJSLfzxDdcghRAPCdcqhCblOgTD6FS6o7gv0SARgTnvpqHM6G CkxBanSjmGw0LIQddJo5u6ZRpDeoAs/Kqj5qhZzOauinRSUsZguCcT0v3 +fIQqAX7k4q/LZ17xxuxLK1rSGDgz9WnD3ILacZxW2oitz2S0IRy9FGWd 8=; X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208,217";a="121401021" X-IPAS-Result: ArMEAB7dvlPAqArr/2dsb2JhbABPCoJHgRlarmqOYoE+GAELh0ABgSR1hAMBAQEBAwEBARdLCRsCAQgRAQMBAQsWAQYHJwsUAwYIAgQBEggTiBMDHsdaF40ZgU8lBicGCgECgyuBFgWGG5AFRoViihuLdYIw Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 18:40:08 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 11:40:07 -0700 From: Ian Smith To: "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAABCUAgAAT/YD//4+pKIAAkqoA//+KyJY= Date: Thu, 10 Jul 2014 18:40:07 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C268@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com>, <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83C268SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KkftS14kW4D-nJY-fOfMrbxGGxY Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:40:15 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83C268SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I personally think that the service function is an abstract idea - "url fil= ter" and the service function instance is the instantiation of that idea - = "this url-filter". But the OP I was responding to is part of a thread where Service Function w= as being used to mean that some functionality within the service function p= resents a common end-point and then distributes traffic to particular inst= ances in an opaque way that sounds like a load-balancer or ipv6 anycast end= -point. ________________________________ From: mikebianc@aol.com [mikebianc@aol.com] Sent: Thursday, July 10, 2014 2:34 PM To: Ian Smith; sfc@ietf.org Subject: RE: [sfc] Service Chains, Paths, and Load Balancers "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." Is it service function that makes that decision? or the service function in= stance? ________________________________ From: I.Smith@F5.com To: Changcheng Huang,'Ron Parker','Lucy yong',mohamed.boucadair@orange.c= om,mikebianc@aol.com,jmh@j= oelhalpern.com,sfc@ietf.org Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >Service functions should make the decision about which instances will be u= sed I think it is sufficient for the architecture to say, "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." But you also say need to say, "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY m= ake the decision about which Service Function Instances will be used when s= electing the Service Function Path." and, "External orchestration frameworks MAY make the decision about which Servic= e Function Instances will be used when selecting the Service Function Path.= " All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural. IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two. ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Changcheng Huang [huang@sce.carleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joe= lhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I agree with Ron=92s comments. Service functions should make the decision a= bout which instances will be used. It can be different hop-by-hop (e.g. in = a tree topology). In order to do so, it is important a physical network mak= es a service function chain aware of the available instances. These is no n= eed to identify each possible SFP by a physical network. If a service funct= ion chain wants to use multiple SFPs, it should provide the identifier for = each flow that uses a particular SFP and the corresponding forwarding rules= (i.e. next hop). Nevertheless, because a physical network need to support = multiple tenants, it does need to identify different tenants. Our recent co= ntribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recur= sive-service/ ) has discussed this issue in a more general architecture. Ho= pe it can be helpful for this discussion. Chang From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers It is architecturally significant to identify that multiple addressable ins= tances of a service function are explicitly allowed. Whether those instance= perform some further level of load balancing is irrelevant, as has been po= inted out by Joel. It is also architecturally significant to assign respons= ibility for instance selection. In particular, is the instance selection ce= ntralized, distributed, or some combination? Which functional entities in t= he architecture have what responsibilities to achieve this? In November, 20= 13, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft= -parker-sfc-chain-to-path-00, which proposed that the instance selection wa= s made hop by hop by the service functions themselves, in a fully distribut= ed manner. That was just a proposal and I am not wedded to it, by any means= . Joel asked about specificity and it is at this level that I=92d like to s= ee the architecture describe things. It should be able to answer the questi= on, =93how does multi-instance selection work in SFC?=94 in a concise manne= r. If the group feels that there should be more than one answer to that que= stion, so be it, but we should be able to describe the high level mechanism= and rationale for each succinctly. Of course, that is merely one such ques= tion and there are many others that an architectural document should be abl= e to describe. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mike= bianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A83C268SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I personally think that the service function is an abstract idea - &= quot;url filter" and the service function instance is the instantiatio= n of that idea - "this url-filter".

But the OP I was responding to is part of a thread where Service Function w= as being used to mean that some functionality within the service function p= resents a common end-point and then  distributes traffic to particular= instances in an opaque way that sounds like a load-balancer or ipv6 anycast end-point.


From: mikebianc@aol.com [mikebianc@aol.com= ]
Sent: Thursday, July 10, 2014 2:34 PM
To: Ian Smith; sfc@ietf.org
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers


"Service Functions MAY make the decision about which Se= rvice Function Instances will be used when selecting the Service Function P= ath." 

Is it service function that makes that decision? or the service functi= on instance?



From: I.Smith@F5.com<I.Smith@F5.com>
To: Changcheng Huang<huang@sce.carleton.ca>,'Ron Parker'<Ro= n_Parker@affirmednetworks.com>,'Lucy yong'<lucy.yong@huawei.com>,m= ohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,mikebianc@a= ol.com<mikebianc@aol.com>,jmh@joelhalpern.com<jmh@joelhalpern.com&= gt;,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function = Instances will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the = decision about which Service Function Instances will be used when selecting= the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Functio= n Instances will be used when selecting the Service Function Path."
All three result in a Service Function Path being selected, and they aren't ne= cessarily exclusive of one another if you have rules for resolving conflict= s; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two.
From: sfc [sfc-bounces@ietf.org] on behalf of= Changcheng Huang [huang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I agree with Ron=92s co= mments. Service functions should make the decision about which instances wi= ll be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a s= ervice function chain aware of the available instances. These is no need to= identify each possible SFP by a physical network. If a service function ch= ain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP = and the corresponding forwarding rules (i.e. next hop). Nevertheless, becau= se a physical network need to support multiple tenants, it does need to ide= ntify different tenants. Our recent contribution (https://datatracker.ietf.org= /doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this i= ssue in a more general architecture. Hope it can be helpful for this discussion.

Chang

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces= @ietf.org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

It is architecturally s= ignificant to identify that multiple addressable instances of a service fun= ction are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed ou= t by Joel. It is also architecturally significant to assign responsibility = for instance selection. In particular, is the instance selection centralize= d, distributed, or some combination? Which functional entities in the architecture have what responsibilities t= o achieve this? In November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which pro= posed that the instance selection was made hop by hop by the service functi= ons themselves, in a fully distributed manner. That was just a proposal and= I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=92d like to se= e the architecture describe things. It should be able to answer the questio= n, =93how does multi-instance selection work in SFC?=94 in a concise manner= . If the group feels that there should be more than one answer to that question, so be it, but we should be able = to describe the high level mechanism and rationale for each succinctly. Of = course, that is merely one such question and there are many others that an = architectural document should be able to describe.

Ron

From: sfc = [mailto:sfc-bounc= es@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; = sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

Agree. The arch. doc sh= ould not mandate only use of the service path identifier to drive the forwa= rding actions.

Lucy

From: sfc [<= a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces= @ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc= @aol.com; jmh@joelhalpern.co= m; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

Re-,

The merged draft calls out explicitly a se= rvice path identifier. I object to use that identifier to derive forwarding= actions.

Requiring a SFC system to have the full kn= owledge of every available SFC forwarding paths within an SFC-enabled domai= n is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the = piece of information that will be present in all deployments: that is the o= ne required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriente= d discussion.

Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=E9 : mercredi 9 juillet 2014 22:03
=C0 : jmh@j= oelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still questioning the differen= ce between SF Chain and SF Path? Other than clarifying the definition so th= at it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still uncle= ar is whether it is the intent of this draft to ultimately specify what the= ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draf= t would have require that both SFP and SFC be supported (or make one requir= ed and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh= @joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

--_000_419417C345CA5F48BF45F0A23955A0634A83C268SEAEMBX02olympu_-- From nobody Thu Jul 10 11:48: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 5C2761B296B for ; Thu, 10 Jul 2014 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 7LIA2lNzUOWM for ; Thu, 10 Jul 2014 11:48:06 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82CD1B294C for ; Thu, 10 Jul 2014 11:48:06 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AIm4Mg029920 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 10 Jul 2014 14:48:05 -0400 Message-ID: <53BEE126.7090906@sce.carleton.ca> Date: Thu, 10 Jul 2014 11:53:26 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sfc@ietf.org References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> In-Reply-To: <53BED9F3.7070503@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EL93gNIoDiIq6nzNNJ5HFkFxisE Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:48:10 -0000 I am concerned with the overhead metadata may create. Internet packet sizes tend to be bimodal where more than 50% of packets have very small packet sizes. Carrying large amounts of overhead will reduce throughput significantly. Making metadata optional may be a good choice. Regards, Chang On 07/10/2014 11:22 AM, Joel M. Halpern wrote: > I look forward to seeing your draft. > > One of the reasons I like including the metadata with the underlying > packet is that they then share fate. If the packet gets lost, the > metadata disappears with it, which is frequently fine. And if the > packet is probably delviered down the service path, then so is the > metadata. > > Yours, > Joel > > On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >> Hello, >> >> Metadata transport is a feature provided by SFC that needs some >> additional thoughts as well. >> >> B Rijsman has done a great job showing various option for Metadata >> sharing. Still there are 2 aspects that I would like to address further >> >> - Metadata representation >> >> - Metadata transport reliability >> >> We will probably post a draft on the subject, but this can be done after >> Toronto has started. So for those >> interested to provide some feedback, here are some highlights. >> >> *1. Problem Space* >> * Metadata representation* >> Metadata can be extremely varied in term of usage and content. It can >> represent the result of Deep Packet Inspection (DPI) performed on the >> traffic for example by the Classifier Service Function at the ingress of >> the Service Function Chain. It can contain information collected about >> the end user such as a policy identifier, a category or even represent >> an event related to the end-user session. >> This information can be used by Service Functions on the chain, as well >> as by monitoring entities responsible to track usage for example in the >> Network Function Virtualization environment to feed a VNF manager or an >> Orchestrator. >> Metadata being information shared by many network entities needs some >> means to be represented it in all of its dimensions: type definition, >> encoding and scope. >> * Metadata transport service* >> As expected from service chain proposals, both NSH and SCH proposals >> define some means to carry metadata between Service Functions in a >> Chain. They can be classified as follow: >> Dataplane Metadata: >> are defined in the Service Function Chaining Problem Statement document. >> They are not considered to be part of the forwarding information of the >> SFC header. However they are expected to carry the result of antecedent >> classification, allowing Service Functions to take local policy >> decisions based on their values. >> >> As such, they could also be interpreted directly by Service Function >> Forwarder to steer traffic to various Service Functions. >> Offline Metadata: >> Beyond Dataplane Metadata, Offline Metadata can be shared between >> Service Functions in a chain, using out of band, congruent or not, or >> hybrid models described in [RIJSMAN] >> >> The hybrid model for example, defined in [RIJSMAN], utilizes the SFC >> header to transport some key values for correlation purposes. These >> Correlation Ids can be used by the Service Functions to recover the full >> associated contextual information. >> Metadata, directly or indirectly, are transported hop by hop along a >> chain, in association to end-user traffic, the data payload of the SFC >> packets. >> How these metadata are transported over a chain matters. Passing >> metadata directly or indirectly along packets is a service that must be >> analyzed from a reliability point of view. >> >> Reliability requirements may vary depending on the nature of the >> metadata transported. Past experience for example in Mobile Network and >> data center with AAA Radius have shown that contextual information >> replication to various service function was indeed sensitive to packet >> loss events, and that adhoc solutions had to be implemented to detect >> them. >> End to end TCP retransmission of packet lost does not ensure that >> associated Metadata will be reinserted in retransmitted packet. In >> addition, Event triggered metadata may have to be sent immediately on a >> chain even though no end-user traffic is being transmitted >> Not all metadata needs a reliable transport. Repeated inline metadata >> can be used to cover several use cases, and some metadata loss can be >> acceptable. >> Still, a reliable transport service for Metadata in SFC is expected. To >> this effect, an implementation is suggested in Section 3.3 >> *2. Metadata representation* >> Metadata definition is that it provides contextual information about the >> data packets which traverse a Service Function Chain. This must be >> understood broadly. >> Metadata can contain the result of traffic classification by Deep Packet >> Inspection (DPI). For example as an Application Id information which is >> tied to a traffic flow. There could be multiple flows with different >> application ids, in a chain. >> Metadata can also contain the result of DPI data extraction, such as >> identify requested URL in HTTP. Such information can be passed to >> certain SF down the chain such as a URL filtering function. >> Metadata can contain some punctual event information collected at the >> Ingress point of the chain and expected to be passed to all elements in >> the chain. Here this information may be triggered externally and >> generated only once, and be related to the tenant or the subscriber. >> Metadata representation involves the definition of a set of information >> elements types and the encoding rules for their values. >> Metadata representation can sometimes be performed by a single >> individual field with associated type and format. However, it is not >> always enough. >> >> * Metadata may need multiple fields transported together to >> represented their values. >> * Some addition fields may be required to describe the scope of the >> metadata itself. This can be any information element allowing to >> define the context of the associated metadata value. For example a >> throughput metadata field can have a port number and a switch >> address as its Scope information. >> >> We explore these two axis: encoding and scope. >> We propose IPFIX as a preferred means to represent Metadata in Service >> Chain messages for Out-of-band, Congruent or not; Metadata sharing. >> *2.1. Metadata Representation Requirements* >> Mandatatory Dataplane Metadata is always part of the SFC header, it is >> thus reasonable to consider that its representation scheme will be >> implicit: based on what the SFC protocol will dictate, their position in >> the SFC header is sufficient for the receiving end to infer their type >> and encoding scheme. For example, Context Header Fields in NSH are 32 >> bit fields. >> However, it will not be the case for all metadata transported. Offline >> metadata, including congruent out-of-band metadata still need to be >> represented explicitly. This section addresses their specific case. >> *2.1.1. Metadata Encoding requirements* >> These requirements are applicable to out-of-band metadata (Congruent or >> not). It could be applicable with SCH on optional in-line metadata >> fields. >> For interoperability purposes, metadata encoding MUST allow the >> receiving entity to identify the type and value of the information >> received as metadata >> Metadata encoding MUST allow for encoding techniques supporting well >> known types and fields as well as proprietary extensions. >> A receiving entity MUST be able to identify when incoming metadata type >> is unknown and MUST have a defined default action to handle it. >> A piece of information may need multiple fields to be described. For >> example a tenant id and an ip address can be used to identify an server >> in a data center uniquely. >> These groups of information have to be exchanged collectively, in a >> single message. In this case, a sending entity MUST specify that it is >> sending a set of metadata in a message. >> This set of transported metadata elements MUST be specified under the >> form of a metadata template document uniquely defined for the chain. >> A receiving entity MUST be able to detect if an incoming message >> contains its expected set of metadata elements. >> *2.1.2. Metadata Scope requirement* >> A piece of information may have to be qualified by some attributes >> allowing to identify its particular scope. For example in a Gi >> environment, the radio type in use may be used as a scoping criteria for >> a jitter or latency measurement in a video traffic transported in a >> particular service chaing. >> Scope can apply to some individual metadata elements or to a set of >> metadata elements. How a scope applies to a set of transported metadata >> elements should be defined by a specification under the form of a >> metadata template document uniquely identified for the chain. >> *2.2. IPFIX Metadata representation* >> So far, unordered sequences of Type Length Value encoded fields have >> been proposed to transport metadata. It is not clear how structured >> types are supported, and no distinction is done between the metadata >> values and their scoping values. Although the SCH proposal provides an >> optional 24-bit Organizational Unique Identifier, there is no namespace >> mechanism allowing to separate type definition spaces per Tenants or per >> chain. >> We suggest to leverage the work done by IETF on similar subject. >> A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for >> transmitting Traffic Flow information over the network. In order to >> transmit Traffic Flow information, it provides a common representation >> of flow data and a standard means of communicating them. >> Metadata collected by Network Node and Service Node SHOULD be encoded in >> template following the principles described in IPFIX[RFC7011]. >> An IPFIX Message consisting of interleaved Template, Data, and Options >> Template Sets, as shown in Figure 1. Here, Template and Options Template >> Sets , which are optional, are shown. >> >> >> +--------+--------------------------------------------------------+ >> | | +----------+ +---------+ +-----------+ +---------+ | >> |Message | | Template | | Data | | Options | | Data | | >> | Header | | Set | | Set | ... | Template | | Set | | >> | | | | | | | Set | | | | >> | | +----------+ +---------+ +-----------+ +---------+ | >> +--------+--------------------------------------------------------+ >> >> >> >> Figure 1: IPFIX Message Format >> The Template Set describes the data transmitted in the following Data >> Set. It is an optional component of the message. The value of the >> metadata is encoded in the first Data Set. This Data Set contains a >> template Id field as a reference to its defining Template Set. >> The Options Template Set describes the data to be transmitted as scope >> information. It is an optional component of the message. The value of >> the scope information is encoded in the second Data Set element. It no >> scope information is present, then only the first Data Set is present in >> the message. >> The Option Template Set and following Data Set are used to describe the >> scope of the metadata transmitted. For example, the metadata collected >> is relevant to a PDP Context or a particular line card of a particular >> switch. >> * >> * >> *2.2.4.3. Example:* >> The Metadata Exporting Process creates a Template Record with a few >> Information Elements: amongst other things, the Application Id. For >> example: >> >> - sourceIPv4Address (key field) >> - destinationIPv4Address (key field) >> - protocol (key field) >> - destinationTransportPort (key field) >> - applicationId (key field) >> - octetTotalCount (non key field) >> >> For example, a Flow Record corresponding to the above >> Template Record may contain: >> >> { sourceIPv4Address=192.0.2.1, >> destinationIPv4Address=192.0.2.2, >> protocol=17, >> destinationTransportPort=23, >> applicationId='3..80', >> octetTotalCount=123456 } >> >> >> >> The Options Data Record associated with the examples above would contain >> the Scoping inforamtion: >> >> Scope: >> - servicePath, >> - serviceIndex, >> - applicationId, >> - applicationName >> - applicationDescription. >> >> For example: >> >> { >> servicePath=0x000b, >> serviceIndex=0x000c, >> applicationId='13...10000', >> applicationName="webex", >> applicationDescription="Webex application" } >> >> >> >> Scope information is useful when sending metadata offline, as it can >> contain information related to the chain and possibly to the flow for >> which this metadata record is relevant. Here servicePath and >> serviceIndex are thus included in the Template. >> *2.2.4.4. IPFIX encoding and template provisioning:* >> IPFIX is a quite compact encoding >> For a template defined as followed and shared by the SF in a chain. >> IPFIX template record shared by SF: >> Note that an XML representation of IPFIX template record could be >> defined and used to provision Service Functions. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 | Length = 28 octets | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID 256 | Field Count = 5 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| sourceIPv4Address = 8 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| destinationIPv4Address = 12 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| ipNextHopIPv4Address = 15 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| packetDeltaCount = 2 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| octetDeltaCount = 1 | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure 7: IPFIX Metadata template Encoding >> An encoded IP fix transport message will be: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version Number | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Export Time | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Observation Domain ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 256 | Length = 64 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 192.0.2.12 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 192.0.2.254 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 192.0.2.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 5009 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 5344385 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 8: IPFIX Metadata Encoding >> *3. Metadata transport service* >> These different use cases for Metadata generate some requirements on the >> reliability capabilities of the Metadata transport service they will >> rely on. >> De facto Service Function Chain proposals such as NSH and SCH define a >> mechanism for sharing information along the Chains. It is thus important >> to define this transport service in term of reliability. >> The primary focus of these proposal are the Metadata elements playing a >> role in the Service Function Chain deployment to apply policies on >> incoming traffic at some relevant Service Functions. >> For example, Network Orchestration is expected to be a significant >> driver for deployment of Network Services. It relies on Service Level >> abstractions such as Group Policies, Contracts and Services as an input >> for the orchestration of Service Function Chains. Specific metadata >> attributes such as L4-L7 fields are used as classification elements or >> filters to funnel packets into chains. >> Service Functions may have other needs for Metadata, for example Event >> Based Metadata tied to some subscriber related state changes. The >> complexity and length of these elements cannot be forseen as limited, >> neither can be how critical it is that they are safely carried >> throughout a chain. In the following Section we propose to take >> avantage of Congruent Metadata Transport can be used, possibly reliably, >> to address these needs. >> *3.1. Proposed Metadata transport mechanisms* >> . >> *3.1.3. Metadata transport analysis* >> Both NSH and SCH proposals support both inbound and offline out-of-band >> metadata transport. >> >> 1. In-band: the metadata can be included directly as a value in some of >> the NSH Context Header Fields. It is the preferred transport model >> for SCH. >> >> In such case, when a particular field is always set to the same >> value for all packets transported by the chain instance, then the >> metadata transport service is in effect reliable. >> >> Similarly, all the packet for a particular flow (defined by its 5 >> tupple), could receive the same metadata value. The metadata >> transport service is also reliable, provided that the value is >> understood to be attached to a flow. >> >> The general case however, occurs when the metadata varies from >> packet to packet in a flow. The value is then tied to a specific >> packet. Here the transport service is not reliable. A retransmission >> of a particular packet would not necessarily lead it to carry the >> same metadata value. >> 2. Out-of-band: a reference for some metadata is sent along a packet so >> that it can be used via an interaction with a controller entity. It >> is the preferred model for NSH, but could also be used by SCH. >> >> As for the in-band case, the metadata referred to indirectly can be >> transmitted reliably, when its value remains the same for a chain or >> a flow in a chain. a chain or a flow in a chain. >> >> If however, the correlation Id passed changes over time, or if the >> Metadata itself cahanges then the correct Metadata may not be >> efficiently retrieved by some Service Functions. >> >> We can see that NSH and SCH do not address the need for a reliable >> transport service for metadata, independantly of the reliability >> characteristic of the transport service used for the data packets. >> Conventions can be used as particular cases when some metadata pertains >> to a specific chain or a flow in the chain, and when its value does not >> change overtime. >> Such conventions however are weak. They would suppose that some >> mechanism exists to ensure/monitor that they are followed. And some >> exceptions mechanism would be required to deal with error cases. >> *3.2. Support for Congruent out-of-band transport service* >> Congruent out-of-band metadata sharing can be required for some types of >> Metadata exchanges. It has the advantage of clearly tying the metadata >> to the chain and not to a specific packet, and to avoid payload >> fragmentation issues. >> Up to draft 2, NSH did not allow for long inline metadata transport. >> Four 32 bits context fields are reserved for that purpose, and seem best >> suited for offline Metadata sharing, or to transport predefined policy >> identifiers. >> NSH (since draf 3) as well as SCH could allow for metadata transport, >> either tied to a packet or possibly tied to the chain, when used without >> payload, as signaling messages. >> SCH however stipulates that in case the Path Identifier and SF Index >> fields shall be set to zero for transmit and ignored upon receipt, when >> the SCH packet will contain only metadata. So congruent out-of-band >> metadata, transporting Metadata hop to hop to the various Service >> Function in the chain, does not seem to be supported. >> NSH supports inline variable size metadata. It does not mentions >> explicitly that congruent out-of-band metadata can be used. >> *3.3. Reliable transport service* >> Some metadata will need a reliable transport service to be shared >> inline, as well as offline. >> A protocol SCTP provides such a service and has the interesting >> characteristic to be packet based, as opposed to stream based like TCP. >> SCTP carries a sequence number and support retransmission and congestion >> control. >> Figure 12 shows how SCTP is used hop by hop between SFF in a chain to >> transport Metadata reliably. >> >> |1 ----- |n |21 ---- |2m >> +---+---+ +---+---+ +-+---+ +--+-----+ >> | SF#1 | |SF#n | |SF#i1| |SF#im | >> | | | | | | | | >> +---+---+ +---+---+ +--+--+ +--+--+--+ >> : : : : : >> : : : : : >> \ / \ / >> +-----------+ SCTP +--------+ SCTP +---------+ >> -- >| Chain | <---> | SFF | <---> | SFF | ----> >> |classifier | |Node-1 | | Node-i | >> +-----------+ +----+---+ +----+--+-+ >> \ | / >> \ | SFC Encapsulation / >> \ | / >> ,........................................ >> / \ >> / \ >> | Network | >> \ / >> \........................................./ >> >> >> >> Figure 12: SCTP for Reliable Metadata transport >> SCTP SHOULD be used in the context of Congruent out of band for reliable >> metadata sharing. >> For reliable Metadata transport, the SFF along the chain MUST route the >> metadata received over SCTP to the next SF in the chain. For this SCTP >> MUST be encapsulated in the SFC header. >> The SFF MUST make the received metadata available to its SF.ti >> >> >> _______________________________________________ >> sfc mailing 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 Jul 10 11:55: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 7F7C41B2973 for ; Thu, 10 Jul 2014 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 ijlqRnpBr0hn for ; Thu, 10 Jul 2014 11:55:22 -0700 (PDT) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB691B2971 for ; Thu, 10 Jul 2014 11:55:13 -0700 (PDT) Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id 93B51700544D0; Thu, 10 Jul 2014 14:55:12 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 44F183800009F; Thu, 10 Jul 2014 14:55:12 -0400 (EDT) Date: Thu, 10 Jul 2014 14:55:12 -0400 From: "mikebianc@aol.com" To: paulq@cisco.com Message-ID: <960550823.1312.1405018512061.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <4EA6CA1E-C82E-4380-B9B8-2DC989E8D1B0@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.co m> <53BEBA98.3060301@joelhalpern.com> <4EA6CA1E-C82E-4380-B9B8-2DC989E8D1B0@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1311_60912355.1405018512061" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405018512; bh=cZq1e/FoouVrsE4zrBlW33+5+MLYVkhW3RqWLMOfUg0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PnwMgucbmU6+XgV8da4N7KlyYUne8xaDQzY5YKQH8X0o5ws68p75/FtxWQ7qY+29e FbH+DvrN6xqaGWU85gk/0gWM+hE9MG0daZqlUYd01sDlInr3Ya+6ga7DuTkVSq9q8t fj0U/kTL5lrhZZrtP7lZl9gQ/gYOkJgN0ZiJGu+8= x-aol-sid: 3039ac1b022153bee1905af7 X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/08uhBqRREclbioRjV9z7wY9lUhc Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 18:55:24 -0000 ------=_Part_1311_60912355.1405018512061 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've stated before that I think we should differentiate between load balanc= ing and load distribution where load balancing refers to the standard servi= ce function that we all know and love (outside of SFC) and load distributio= n refers to the selection of an SFI (i.e. Chain -> Path mapping). =C2=A0Not= using different terms to distinguish between these leads to confusion. e.g. a SF Chain* might exist whose SFs consist only of load balancers. =C2= =A0But you might still want SFC* to distribute load to multiple load balanc= er instances. *trying to distinguish between SFC as "Service Function Chaining" and a sin= gle "Service Function Chain". From: paulq@cisco.com To: Joel M. Halpern cc: Jim Guichard (jguichar),sfc@ietf.org,= mohamed.boucadair@orange.com,Ron Parker,NAPIERALA, MARIA H Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Joel, I concur. The goal here is to address the issues associated with generic s= ervice function deployment and should enable localized decisions such as lo= ad balancing (perhaps more accurately load distribution). Clearly we sound= =E2=80=99t codify how load distribution works. =20 In order to enable load distribution, for example, the right abstractions b= een to be clearly defined in the architecture, a key one bering the distinc= tion between path vs. chain. Paul On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote:>= That is clearly an important problem in building a full solution to the se= rvice chaining needs of operators (e.g. you). However, I could equally obs= erve that if you do not have OSS/BSS capable of provisioning service chains= , or charging systems capable of turning them into revenue, you can't offer= them.> > The SFC working group is tasked with one part of the whole servic= e chain definition, construction, and deployment problem. As I read the ch= arter, general load balancing issues are not part of our scope.> Given the = number of different ways there are of doing load balancing, it would strike= me as very odd for the sfc working group to standardize a particular answe= r to the important and difficult problem you point to.> > The architecture = (and I believe most of the solutions) is designed to provide tools that hel= p with managing that scaling, while also allowing for the use of other tool= s.> If the working group wants us to be more specific in the load balancing= architecture, then if the chairs tell us to we will add more specific text= . I would be surprised personally if we had agreement on such a goal, or a= greement on how to fill such a goal. But Carlos and I will of course do wh= at the chairs tell us the WG wants.> > Yours,> Joel> > On 7/10/14, 12:02 PM= , NAPIERALA, MARIA H wrote:>> One of the main problems in "service chains" = is how to implement a service that is conceptually one hop but scaled horiz= ontally as 10 or 100 different VMs.>> So, IMO, if we are not addressing thi= s problem than what are we solving.>> >> Maria>> > > ______________________= _________________________> sfc mailing list> sfc@ietf.org> https://www.ietf= .org/mailman/listinfo/sfc_______________________________________________sfc= mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_1311_60912355.1405018512061 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I've stated bef= ore that I think we should differentiate between load balancing and load di= stribution where load balancing refers to the standard service function tha= t we all know and love (outside of SFC) and load distribution refers to the= selection of an SFI (i.e. Chain -> Path mapping).  Not using diffe= rent terms to distinguish between these leads to confusion.

<= /div>
e.g. a SF Chain* might exist whose SFs consist only of load balan= cers.  But you might still want SFC* to distribute load to multiple lo= ad balancer instances.

*trying to distinguish betw= een SFC as "Service Function Chaining" and a single "Service Function Chain= ".






From: paulq@cisco.com<paulq@cisco= .com>
To: Joel M. Halpern<jmh@joelhalpern.com>
cc:= Jim Guichard (jguichar)<jguichar@cisco.com>,sfc@ietf.org<sfc@= ietf.org>,mohamed.boucadair@orange.com<mohamed.boucadair@orange.com&g= t;,Ron Parker<Ron_Parker@affirmednetworks.com>,NAPIERALA, MARIA H<mn1921@att.com>
Sent: Thursday, July 10, 2014
<= b>Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

<= title>Joel,

I concur. The goal here is to address the issue= s associated with generic service function deployment and should enable loc= alized decisions such as load balancing (perhaps more accurately load distr= ibution). Clearly we sound=E2=80=99t codify how load distribution works. =

In order to enable load distribution, for example, the right abstra= ctions been to be clearly defined in the architecture, a key one bering the= distinction between path vs. chain.

Paul



= On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <jmh@joelhalpern.com> w= rote:

> That is clearly an important proble= m in building a full solution to the service chaining needs of operators (e= .g. you). However, I could equally observe that if you do not have OSS/BSS= capable of provisioning service chains, or charging systems capable of tur= ning them into revenue, you can't offer them.
>
> The SFC working group is tasked with one part of the whole servi= ce chain definition, construction, and deployment problem. As I read the c= harter, general load balancing issues are not part of our scope.
> Given the number of different ways there are of doing load balan= cing, it would strike me as very odd for the sfc working group to standardi= ze a particular answer to the important and difficult problem you point to.=
>
> The architecture (and I believe mos= t of the solutions) is designed to provide tools that help with managing th= at scaling, while also allowing for the use of other tools.
&= gt; If the working group wants us to be more specific in the load balancing= architecture, then if the chairs tell us to we will add more specific text= . I would be surprised personally if we had agreement on such a goal, or a= greement on how to fill such a goal. But Carlos and I will of course do wh= at the chairs tell us the WG wants.
>
> = Yours,
> Joel
>
> On 7/= 10/14, 12:02 PM, NAPIERALA, MARIA H wrote:
>> One of th= e main problems in "service chains" is how to implement a service that is c= onceptually one hop but scaled horizontally as 10 or 100 different VMs.
>> So, IMO, if we are not addressing this problem than wha= t are we solving.
>>
>> Maria
>>
>
> ________________= _______________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/li= stinfo/sfc

___________________________________= ____________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
------=_Part_1311_60912355.1405018512061-- From nobody Thu Jul 10 12: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 850D91B297D for ; Thu, 10 Jul 2014 12:00:57 -0700 (PDT) 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_22=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 zAtHXrLcS7oW for ; Thu, 10 Jul 2014 12:00:55 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71EF1B2971 for ; Thu, 10 Jul 2014 12:00:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 9B43C86082B; Thu, 10 Jul 2014 12:00:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 24810860827; Thu, 10 Jul 2014 12:00:47 -0700 (PDT) Message-ID: <53BEE2DE.7050102@joelhalpern.com> Date: Thu, 10 Jul 2014 15:00:46 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: huang@sce.carleton.ca, sfc@ietf.org References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> In-Reply-To: <53BEE126.7090906@sce.carleton.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fdeY0vujo2keaClilbOi2Aiji1A Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 19:00:57 -0000 I would hope that we will not be adding large amounts of metadata to packets. There are many reasons why that may cause complications. That is not the same as not carrying some metadata with packets. Yours, Joel On 7/10/14, 2:53 PM, Changcheng Huang wrote: > I am concerned with the overhead metadata may create. Internet packet > sizes tend to be bimodal where more than 50% of packets have very small > packet sizes. Carrying large amounts of overhead will reduce throughput > significantly. Making metadata optional may be a good choice. > > Regards, > > Chang > > On 07/10/2014 11:22 AM, Joel M. Halpern wrote: >> I look forward to seeing your draft. >> >> One of the reasons I like including the metadata with the underlying >> packet is that they then share fate. If the packet gets lost, the >> metadata disappears with it, which is frequently fine. And if the >> packet is probably delviered down the service path, then so is the >> metadata. >> >> Yours, >> Joel >> >> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >>> Hello, >>> >>> Metadata transport is a feature provided by SFC that needs some >>> additional thoughts as well. >>> >>> B Rijsman has done a great job showing various option for Metadata >>> sharing. Still there are 2 aspects that I would like to address further >>> >>> - Metadata representation >>> >>> - Metadata transport reliability >>> >>> We will probably post a draft on the subject, but this can be done after >>> Toronto has started. So for those >>> interested to provide some feedback, here are some highlights. >>> >>> *1. Problem Space* >>> * Metadata representation* >>> Metadata can be extremely varied in term of usage and content. It can >>> represent the result of Deep Packet Inspection (DPI) performed on the >>> traffic for example by the Classifier Service Function at the ingress of >>> the Service Function Chain. It can contain information collected about >>> the end user such as a policy identifier, a category or even represent >>> an event related to the end-user session. >>> This information can be used by Service Functions on the chain, as well >>> as by monitoring entities responsible to track usage for example in the >>> Network Function Virtualization environment to feed a VNF manager or an >>> Orchestrator. >>> Metadata being information shared by many network entities needs some >>> means to be represented it in all of its dimensions: type definition, >>> encoding and scope. >>> * Metadata transport service* >>> As expected from service chain proposals, both NSH and SCH proposals >>> define some means to carry metadata between Service Functions in a >>> Chain. They can be classified as follow: >>> Dataplane Metadata: >>> are defined in the Service Function Chaining Problem Statement document. >>> They are not considered to be part of the forwarding information of the >>> SFC header. However they are expected to carry the result of antecedent >>> classification, allowing Service Functions to take local policy >>> decisions based on their values. >>> >>> As such, they could also be interpreted directly by Service Function >>> Forwarder to steer traffic to various Service Functions. >>> Offline Metadata: >>> Beyond Dataplane Metadata, Offline Metadata can be shared between >>> Service Functions in a chain, using out of band, congruent or not, or >>> hybrid models described in [RIJSMAN] >>> >>> The hybrid model for example, defined in [RIJSMAN], utilizes the SFC >>> header to transport some key values for correlation purposes. These >>> Correlation Ids can be used by the Service Functions to recover the full >>> associated contextual information. >>> Metadata, directly or indirectly, are transported hop by hop along a >>> chain, in association to end-user traffic, the data payload of the SFC >>> packets. >>> How these metadata are transported over a chain matters. Passing >>> metadata directly or indirectly along packets is a service that must be >>> analyzed from a reliability point of view. >>> >>> Reliability requirements may vary depending on the nature of the >>> metadata transported. Past experience for example in Mobile Network and >>> data center with AAA Radius have shown that contextual information >>> replication to various service function was indeed sensitive to packet >>> loss events, and that adhoc solutions had to be implemented to detect >>> them. >>> End to end TCP retransmission of packet lost does not ensure that >>> associated Metadata will be reinserted in retransmitted packet. In >>> addition, Event triggered metadata may have to be sent immediately on a >>> chain even though no end-user traffic is being transmitted >>> Not all metadata needs a reliable transport. Repeated inline metadata >>> can be used to cover several use cases, and some metadata loss can be >>> acceptable. >>> Still, a reliable transport service for Metadata in SFC is expected. To >>> this effect, an implementation is suggested in Section 3.3 >>> *2. Metadata representation* >>> Metadata definition is that it provides contextual information about the >>> data packets which traverse a Service Function Chain. This must be >>> understood broadly. >>> Metadata can contain the result of traffic classification by Deep Packet >>> Inspection (DPI). For example as an Application Id information which is >>> tied to a traffic flow. There could be multiple flows with different >>> application ids, in a chain. >>> Metadata can also contain the result of DPI data extraction, such as >>> identify requested URL in HTTP. Such information can be passed to >>> certain SF down the chain such as a URL filtering function. >>> Metadata can contain some punctual event information collected at the >>> Ingress point of the chain and expected to be passed to all elements in >>> the chain. Here this information may be triggered externally and >>> generated only once, and be related to the tenant or the subscriber. >>> Metadata representation involves the definition of a set of information >>> elements types and the encoding rules for their values. >>> Metadata representation can sometimes be performed by a single >>> individual field with associated type and format. However, it is not >>> always enough. >>> >>> * Metadata may need multiple fields transported together to >>> represented their values. >>> * Some addition fields may be required to describe the scope of the >>> metadata itself. This can be any information element allowing to >>> define the context of the associated metadata value. For example a >>> throughput metadata field can have a port number and a switch >>> address as its Scope information. >>> >>> We explore these two axis: encoding and scope. >>> We propose IPFIX as a preferred means to represent Metadata in Service >>> Chain messages for Out-of-band, Congruent or not; Metadata sharing. >>> *2.1. Metadata Representation Requirements* >>> Mandatatory Dataplane Metadata is always part of the SFC header, it is >>> thus reasonable to consider that its representation scheme will be >>> implicit: based on what the SFC protocol will dictate, their position in >>> the SFC header is sufficient for the receiving end to infer their type >>> and encoding scheme. For example, Context Header Fields in NSH are 32 >>> bit fields. >>> However, it will not be the case for all metadata transported. Offline >>> metadata, including congruent out-of-band metadata still need to be >>> represented explicitly. This section addresses their specific case. >>> *2.1.1. Metadata Encoding requirements* >>> These requirements are applicable to out-of-band metadata (Congruent or >>> not). It could be applicable with SCH on optional in-line metadata >>> fields. >>> For interoperability purposes, metadata encoding MUST allow the >>> receiving entity to identify the type and value of the information >>> received as metadata >>> Metadata encoding MUST allow for encoding techniques supporting well >>> known types and fields as well as proprietary extensions. >>> A receiving entity MUST be able to identify when incoming metadata type >>> is unknown and MUST have a defined default action to handle it. >>> A piece of information may need multiple fields to be described. For >>> example a tenant id and an ip address can be used to identify an server >>> in a data center uniquely. >>> These groups of information have to be exchanged collectively, in a >>> single message. In this case, a sending entity MUST specify that it is >>> sending a set of metadata in a message. >>> This set of transported metadata elements MUST be specified under the >>> form of a metadata template document uniquely defined for the chain. >>> A receiving entity MUST be able to detect if an incoming message >>> contains its expected set of metadata elements. >>> *2.1.2. Metadata Scope requirement* >>> A piece of information may have to be qualified by some attributes >>> allowing to identify its particular scope. For example in a Gi >>> environment, the radio type in use may be used as a scoping criteria for >>> a jitter or latency measurement in a video traffic transported in a >>> particular service chaing. >>> Scope can apply to some individual metadata elements or to a set of >>> metadata elements. How a scope applies to a set of transported metadata >>> elements should be defined by a specification under the form of a >>> metadata template document uniquely identified for the chain. >>> *2.2. IPFIX Metadata representation* >>> So far, unordered sequences of Type Length Value encoded fields have >>> been proposed to transport metadata. It is not clear how structured >>> types are supported, and no distinction is done between the metadata >>> values and their scoping values. Although the SCH proposal provides an >>> optional 24-bit Organizational Unique Identifier, there is no namespace >>> mechanism allowing to separate type definition spaces per Tenants or per >>> chain. >>> We suggest to leverage the work done by IETF on similar subject. >>> A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for >>> transmitting Traffic Flow information over the network. In order to >>> transmit Traffic Flow information, it provides a common representation >>> of flow data and a standard means of communicating them. >>> Metadata collected by Network Node and Service Node SHOULD be encoded in >>> template following the principles described in IPFIX[RFC7011]. >>> An IPFIX Message consisting of interleaved Template, Data, and Options >>> Template Sets, as shown in Figure 1. Here, Template and Options Template >>> Sets , which are optional, are shown. >>> >>> >>> +--------+--------------------------------------------------------+ >>> | | +----------+ +---------+ +-----------+ +---------+ | >>> |Message | | Template | | Data | | Options | | Data | | >>> | Header | | Set | | Set | ... | Template | | Set | | >>> | | | | | | | Set | | | | >>> | | +----------+ +---------+ +-----------+ +---------+ | >>> +--------+--------------------------------------------------------+ >>> >>> >>> >>> Figure 1: IPFIX Message Format >>> The Template Set describes the data transmitted in the following Data >>> Set. It is an optional component of the message. The value of the >>> metadata is encoded in the first Data Set. This Data Set contains a >>> template Id field as a reference to its defining Template Set. >>> The Options Template Set describes the data to be transmitted as scope >>> information. It is an optional component of the message. The value of >>> the scope information is encoded in the second Data Set element. It no >>> scope information is present, then only the first Data Set is present in >>> the message. >>> The Option Template Set and following Data Set are used to describe the >>> scope of the metadata transmitted. For example, the metadata collected >>> is relevant to a PDP Context or a particular line card of a particular >>> switch. >>> * >>> * >>> *2.2.4.3. Example:* >>> The Metadata Exporting Process creates a Template Record with a few >>> Information Elements: amongst other things, the Application Id. For >>> example: >>> >>> - sourceIPv4Address (key field) >>> - destinationIPv4Address (key field) >>> - protocol (key field) >>> - destinationTransportPort (key field) >>> - applicationId (key field) >>> - octetTotalCount (non key field) >>> >>> For example, a Flow Record corresponding to the above >>> Template Record may contain: >>> >>> { sourceIPv4Address=192.0.2.1, >>> destinationIPv4Address=192.0.2.2, >>> protocol=17, >>> destinationTransportPort=23, >>> applicationId='3..80', >>> octetTotalCount=123456 } >>> >>> >>> >>> The Options Data Record associated with the examples above would contain >>> the Scoping inforamtion: >>> >>> Scope: >>> - servicePath, >>> - serviceIndex, >>> - applicationId, >>> - applicationName >>> - applicationDescription. >>> >>> For example: >>> >>> { >>> servicePath=0x000b, >>> serviceIndex=0x000c, >>> applicationId='13...10000', >>> applicationName="webex", >>> applicationDescription="Webex application" } >>> >>> >>> >>> Scope information is useful when sending metadata offline, as it can >>> contain information related to the chain and possibly to the flow for >>> which this metadata record is relevant. Here servicePath and >>> serviceIndex are thus included in the Template. >>> *2.2.4.4. IPFIX encoding and template provisioning:* >>> IPFIX is a quite compact encoding >>> For a template defined as followed and shared by the SF in a chain. >>> IPFIX template record shared by SF: >>> Note that an XML representation of IPFIX template record could be >>> defined and used to provision Service Functions. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 | Length = 28 octets | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID 256 | Field Count = 5 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| sourceIPv4Address = 8 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| destinationIPv4Address = 12 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| ipNextHopIPv4Address = 15 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| packetDeltaCount = 2 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| octetDeltaCount = 1 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Figure 7: IPFIX Metadata template Encoding >>> An encoded IP fix transport message will be: >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version Number | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Export Time | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence Number | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Observation Domain ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 256 | Length = 64 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.12 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.254 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5009 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5344385 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> Figure 8: IPFIX Metadata Encoding >>> *3. Metadata transport service* >>> These different use cases for Metadata generate some requirements on the >>> reliability capabilities of the Metadata transport service they will >>> rely on. >>> De facto Service Function Chain proposals such as NSH and SCH define a >>> mechanism for sharing information along the Chains. It is thus important >>> to define this transport service in term of reliability. >>> The primary focus of these proposal are the Metadata elements playing a >>> role in the Service Function Chain deployment to apply policies on >>> incoming traffic at some relevant Service Functions. >>> For example, Network Orchestration is expected to be a significant >>> driver for deployment of Network Services. It relies on Service Level >>> abstractions such as Group Policies, Contracts and Services as an input >>> for the orchestration of Service Function Chains. Specific metadata >>> attributes such as L4-L7 fields are used as classification elements or >>> filters to funnel packets into chains. >>> Service Functions may have other needs for Metadata, for example Event >>> Based Metadata tied to some subscriber related state changes. The >>> complexity and length of these elements cannot be forseen as limited, >>> neither can be how critical it is that they are safely carried >>> throughout a chain. In the following Section we propose to take >>> avantage of Congruent Metadata Transport can be used, possibly reliably, >>> to address these needs. >>> *3.1. Proposed Metadata transport mechanisms* >>> . >>> *3.1.3. Metadata transport analysis* >>> Both NSH and SCH proposals support both inbound and offline out-of-band >>> metadata transport. >>> >>> 1. In-band: the metadata can be included directly as a value in some of >>> the NSH Context Header Fields. It is the preferred transport model >>> for SCH. >>> >>> In such case, when a particular field is always set to the same >>> value for all packets transported by the chain instance, then the >>> metadata transport service is in effect reliable. >>> >>> Similarly, all the packet for a particular flow (defined by its 5 >>> tupple), could receive the same metadata value. The metadata >>> transport service is also reliable, provided that the value is >>> understood to be attached to a flow. >>> >>> The general case however, occurs when the metadata varies from >>> packet to packet in a flow. The value is then tied to a specific >>> packet. Here the transport service is not reliable. A retransmission >>> of a particular packet would not necessarily lead it to carry the >>> same metadata value. >>> 2. Out-of-band: a reference for some metadata is sent along a packet so >>> that it can be used via an interaction with a controller entity. It >>> is the preferred model for NSH, but could also be used by SCH. >>> >>> As for the in-band case, the metadata referred to indirectly can be >>> transmitted reliably, when its value remains the same for a chain or >>> a flow in a chain. a chain or a flow in a chain. >>> >>> If however, the correlation Id passed changes over time, or if the >>> Metadata itself cahanges then the correct Metadata may not be >>> efficiently retrieved by some Service Functions. >>> >>> We can see that NSH and SCH do not address the need for a reliable >>> transport service for metadata, independantly of the reliability >>> characteristic of the transport service used for the data packets. >>> Conventions can be used as particular cases when some metadata pertains >>> to a specific chain or a flow in the chain, and when its value does not >>> change overtime. >>> Such conventions however are weak. They would suppose that some >>> mechanism exists to ensure/monitor that they are followed. And some >>> exceptions mechanism would be required to deal with error cases. >>> *3.2. Support for Congruent out-of-band transport service* >>> Congruent out-of-band metadata sharing can be required for some types of >>> Metadata exchanges. It has the advantage of clearly tying the metadata >>> to the chain and not to a specific packet, and to avoid payload >>> fragmentation issues. >>> Up to draft 2, NSH did not allow for long inline metadata transport. >>> Four 32 bits context fields are reserved for that purpose, and seem best >>> suited for offline Metadata sharing, or to transport predefined policy >>> identifiers. >>> NSH (since draf 3) as well as SCH could allow for metadata transport, >>> either tied to a packet or possibly tied to the chain, when used without >>> payload, as signaling messages. >>> SCH however stipulates that in case the Path Identifier and SF Index >>> fields shall be set to zero for transmit and ignored upon receipt, when >>> the SCH packet will contain only metadata. So congruent out-of-band >>> metadata, transporting Metadata hop to hop to the various Service >>> Function in the chain, does not seem to be supported. >>> NSH supports inline variable size metadata. It does not mentions >>> explicitly that congruent out-of-band metadata can be used. >>> *3.3. Reliable transport service* >>> Some metadata will need a reliable transport service to be shared >>> inline, as well as offline. >>> A protocol SCTP provides such a service and has the interesting >>> characteristic to be packet based, as opposed to stream based like TCP. >>> SCTP carries a sequence number and support retransmission and congestion >>> control. >>> Figure 12 shows how SCTP is used hop by hop between SFF in a chain to >>> transport Metadata reliably. >>> >>> |1 ----- |n |21 ---- |2m >>> +---+---+ +---+---+ +-+---+ +--+-----+ >>> | SF#1 | |SF#n | |SF#i1| |SF#im | >>> | | | | | | | | >>> +---+---+ +---+---+ +--+--+ +--+--+--+ >>> : : : : : >>> : : : : : >>> \ / \ / >>> +-----------+ SCTP +--------+ SCTP +---------+ >>> -- >| Chain | <---> | SFF | <---> | SFF | ----> >>> |classifier | |Node-1 | | Node-i | >>> +-----------+ +----+---+ +----+--+-+ >>> \ | / >>> \ | SFC Encapsulation / >>> \ | / >>> ,........................................ >>> / \ >>> / \ >>> | Network | >>> \ / >>> \........................................./ >>> >>> >>> >>> Figure 12: SCTP for Reliable Metadata transport >>> SCTP SHOULD be used in the context of Congruent out of band for reliable >>> metadata sharing. >>> For reliable Metadata transport, the SFF along the chain MUST route the >>> metadata received over SCTP to the next SF in the chain. For this SCTP >>> MUST be encapsulated in the SFC header. >>> The SFF MUST make the received metadata available to its SF.ti >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 10 12:02: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 EE8F11B2972 for ; Thu, 10 Jul 2014 12:02:05 -0700 (PDT) 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 IckrlW78SIk0 for ; Thu, 10 Jul 2014 12:01:59 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8201A854D for ; Thu, 10 Jul 2014 12:01:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 01420860864; Thu, 10 Jul 2014 12:01:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 975D8860863; Thu, 10 Jul 2014 12:01:57 -0700 (PDT) Message-ID: <53BEE324.5070709@joelhalpern.com> Date: Thu, 10 Jul 2014 15:01:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , paulq@cisco.com References: <53BCAB74.4060801@joelhalpern.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.co m> <53BEBA98.3060301@joelhalpern.com> <4EA6CA1E-C82E-4380-B9B8-2DC989E8D1B0@cisco.com> <960550823.1312.1405018512061.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <960550823.1312.1405018512061.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yf0WMzsgZWCmK_6Y-KVCphELJxE Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 19:02:06 -0000 The term "load distribution" works for me. I agree that there is value in differentiating the functions, and using different words usually helps such differentiation. Yours, Joel On 7/10/14, 2:55 PM, mikebianc@aol.com wrote: > I've stated before that I think we should differentiate between load > balancing and load distribution where load balancing refers to the > standard service function that we all know and love (outside of SFC) and > load distribution refers to the selection of an SFI (i.e. Chain -> Path > mapping). Not using different terms to distinguish between these leads > to confusion. > > e.g. a SF Chain* might exist whose SFs consist only of load balancers. > But you might still want SFC* to distribute load to multiple load > balancer instances. > > *trying to distinguish between SFC as "Service Function Chaining" and a > single "Service Function Chain". > > > > > > > > ------------------------------------------------------------------------ > *From: *paulq@cisco.com > *To: *Joel M. Halpern > *cc: *Jim Guichard > (jguichar),sfc@ietf.org,mohamed.boucadair@orange.com,Ron > Parker,NAPIERALA, MARIA H > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Joel, > > I concur. The goal here is to address the issues associated with generic > service function deployment and should enable localized decisions such > as load balancing (perhaps more accurately load distribution). Clearly > we sound’t codify how load distribution works. > > In order to enable load distribution, for example, the right > abstractions been to be clearly defined in the architecture, a key one > bering the distinction between path vs. chain. > > Paul > > > > On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote: > > > That is clearly an important problem in building a full solution to > the service chaining needs of operators (e.g. you). However, I could > equally observe that if you do not have OSS/BSS capable of provisioning > service chains, or charging systems capable of turning them into > revenue, you can't offer them. > > > > The SFC working group is tasked with one part of the whole service > chain definition, construction, and deployment problem. As I read the > charter, general load balancing issues are not part of our scope. > > Given the number of different ways there are of doing load balancing, > it would strike me as very odd for the sfc working group to standardize > a particular answer to the important and difficult problem you point to. > > > > The architecture (and I believe most of the solutions) is designed to > provide tools that help with managing that scaling, while also allowing > for the use of other tools. > > If the working group wants us to be more specific in the load > balancing architecture, then if the chairs tell us to we will add more > specific text. I would be surprised personally if we had agreement on > such a goal, or agreement on how to fill such a goal. But Carlos and I > will of course do what the chairs tell us the WG wants. > > > > Yours, > > Joel > > > > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote: > >> One of the main problems in "service chains" is how to implement a > service that is conceptually one hop but scaled horizontally as 10 or > 100 different VMs. > >> So, IMO, if we are not addressing this problem than what are we solving. > >> > >> Maria > >> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing 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 Jul 10 12:03: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 713981B29AB for ; Thu, 10 Jul 2014 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MANGLED_NAIL=2.3, 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 6uCaboIV9R-z for ; Thu, 10 Jul 2014 12:02:47 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883171B297D for ; Thu, 10 Jul 2014 12:02:24 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hw13so10470qab.17 for ; Thu, 10 Jul 2014 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m23No6yt0O2MQxYS+cqUaRbCT0QO2uuaoUmHUayYWRw=; b=ZGSwWauNaRADt1Let+uQUgROFe3/3nBTVOGGHy8VWYd58nw28W3oUz3CnwtKShG6ou z9AVPuezGMcR7XAYIgqGZg6VMLDnOej6GDzvhwVTaDQ6625CyKP3pjwqYoQ5uGmRZRml gqA4CcQiOQ2tL1NU5DI6MGgTwLsMUPstA3FjeDZktmkMy1uHj/4jePFFmmF6RuVlYmU/ GSdCIpPorPAX2Vbszi4BhD9z3ixMs8I6xLEsQEx0k83Ll2wtEsy+1/53ZBWHw4wzbCmr H+ytaBigGoTm2tEh3hvtotk7jknsqQKymNPfl91l4XOoiSn+DRDBBZAOCi4SVzc5Nvtt xKEA== MIME-Version: 1.0 X-Received: by 10.140.48.75 with SMTP id n69mr17373355qga.107.1405018943622; Thu, 10 Jul 2014 12:02:23 -0700 (PDT) Received: by 10.96.70.106 with HTTP; Thu, 10 Jul 2014 12:02:23 -0700 (PDT) In-Reply-To: <53BEE126.7090906@sce.carleton.ca> References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> Date: Thu, 10 Jul 2014 12:02:23 -0700 Message-ID: From: Sam Aldrin To: huang@sce.carleton.ca Content-Type: multipart/alternative; boundary=001a11351db00994a004fddb7737 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lfd8QheNnFxke3vnjBPfu10XHdc Cc: "sfc@ietf.org" Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 19:02:52 -0000 --001a11351db00994a004fddb7737 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang wrote: > I am concerned with the overhead metadata may create. Internet packet > sizes tend to be bimodal where more than 50% of packets have very small > packet sizes. Carrying large amounts of overhead will reduce throughput > significantly. Making metadata optional may be a good choice. > Doesn't that depend only if the SFC spans across the internet? Otherwise it (overhead) should be limited to SFC's domain, which may not span across internet, no? cheers -sam > > Regards, > > Chang > > > On 07/10/2014 11:22 AM, Joel M. Halpern wrote: > >> I look forward to seeing your draft. >> >> One of the reasons I like including the metadata with the underlying >> packet is that they then share fate. If the packet gets lost, the metadata >> disappears with it, which is frequently fine. And if the packet is >> probably delviered down the service path, then so is the metadata. >> >> Yours, >> Joel >> >> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >> >>> Hello, >>> >>> Metadata transport is a feature provided by SFC that needs some >>> additional thoughts as well. >>> >>> B Rijsman has done a great job showing various option for Metadata >>> sharing. Still there are 2 aspects that I would like to address further >>> >>> - Metadata representation >>> >>> - Metadata transport reliability >>> >>> We will probably post a draft on the subject, but this can be done after >>> Toronto has started. So for those >>> interested to provide some feedback, here are some highlights. >>> >>> *1. Problem Space* >>> * Metadata representation* >>> Metadata can be extremely varied in term of usage and content. It can >>> represent the result of Deep Packet Inspection (DPI) performed on the >>> traffic for example by the Classifier Service Function at the ingress of >>> the Service Function Chain. It can contain information collected about >>> the end user such as a policy identifier, a category or even represent >>> an event related to the end-user session. >>> This information can be used by Service Functions on the chain, as well >>> as by monitoring entities responsible to track usage for example in the >>> Network Function Virtualization environment to feed a VNF manager or an >>> Orchestrator. >>> Metadata being information shared by many network entities needs some >>> means to be represented it in all of its dimensions: type definition, >>> encoding and scope. >>> * Metadata transport service* >>> As expected from service chain proposals, both NSH and SCH proposals >>> define some means to carry metadata between Service Functions in a >>> Chain. They can be classified as follow: >>> Dataplane Metadata: >>> are defined in the Service Function Chaining Problem Statement document. >>> They are not considered to be part of the forwarding information of the >>> SFC header. However they are expected to carry the result of antecedent >>> classification, allowing Service Functions to take local policy >>> decisions based on their values. >>> >>> As such, they could also be interpreted directly by Service Function >>> Forwarder to steer traffic to various Service Functions. >>> Offline Metadata: >>> Beyond Dataplane Metadata, Offline Metadata can be shared between >>> Service Functions in a chain, using out of band, congruent or not, or >>> hybrid models described in [RIJSMAN] >>> >>> The hybrid model for example, defined in [RIJSMAN], utilizes the SFC >>> header to transport some key values for correlation purposes. These >>> Correlation Ids can be used by the Service Functions to recover the full >>> associated contextual information. >>> Metadata, directly or indirectly, are transported hop by hop along a >>> chain, in association to end-user traffic, the data payload of the SFC >>> packets. >>> How these metadata are transported over a chain matters. Passing >>> metadata directly or indirectly along packets is a service that must be >>> analyzed from a reliability point of view. >>> >>> Reliability requirements may vary depending on the nature of the >>> metadata transported. Past experience for example in Mobile Network and >>> data center with AAA Radius have shown that contextual information >>> replication to various service function was indeed sensitive to packet >>> loss events, and that adhoc solutions had to be implemented to detect >>> them. >>> End to end TCP retransmission of packet lost does not ensure that >>> associated Metadata will be reinserted in retransmitted packet. In >>> addition, Event triggered metadata may have to be sent immediately on a >>> chain even though no end-user traffic is being transmitted >>> Not all metadata needs a reliable transport. Repeated inline metadata >>> can be used to cover several use cases, and some metadata loss can be >>> acceptable. >>> Still, a reliable transport service for Metadata in SFC is expected. To >>> this effect, an implementation is suggested in Section 3.3 >>> *2. Metadata representation* >>> Metadata definition is that it provides contextual information about the >>> data packets which traverse a Service Function Chain. This must be >>> understood broadly. >>> Metadata can contain the result of traffic classification by Deep Packet >>> Inspection (DPI). For example as an Application Id information which is >>> tied to a traffic flow. There could be multiple flows with different >>> application ids, in a chain. >>> Metadata can also contain the result of DPI data extraction, such as >>> identify requested URL in HTTP. Such information can be passed to >>> certain SF down the chain such as a URL filtering function. >>> Metadata can contain some punctual event information collected at the >>> Ingress point of the chain and expected to be passed to all elements in >>> the chain. Here this information may be triggered externally and >>> generated only once, and be related to the tenant or the subscriber. >>> Metadata representation involves the definition of a set of information >>> elements types and the encoding rules for their values. >>> Metadata representation can sometimes be performed by a single >>> individual field with associated type and format. However, it is not >>> always enough. >>> >>> * Metadata may need multiple fields transported together to >>> represented their values. >>> * Some addition fields may be required to describe the scope of the >>> metadata itself. This can be any information element allowing to >>> define the context of the associated metadata value. For example a >>> throughput metadata field can have a port number and a switch >>> address as its Scope information. >>> >>> We explore these two axis: encoding and scope. >>> We propose IPFIX as a preferred means to represent Metadata in Service >>> Chain messages for Out-of-band, Congruent or not; Metadata sharing. >>> *2.1. Metadata Representation Requirements* >>> Mandatatory Dataplane Metadata is always part of the SFC header, it is >>> thus reasonable to consider that its representation scheme will be >>> implicit: based on what the SFC protocol will dictate, their position in >>> the SFC header is sufficient for the receiving end to infer their type >>> and encoding scheme. For example, Context Header Fields in NSH are 32 >>> bit fields. >>> However, it will not be the case for all metadata transported. Offline >>> metadata, including congruent out-of-band metadata still need to be >>> represented explicitly. This section addresses their specific case. >>> *2.1.1. Metadata Encoding requirements* >>> These requirements are applicable to out-of-band metadata (Congruent or >>> not). It could be applicable with SCH on optional in-line metadata >>> fields. >>> For interoperability purposes, metadata encoding MUST allow the >>> receiving entity to identify the type and value of the information >>> received as metadata >>> Metadata encoding MUST allow for encoding techniques supporting well >>> known types and fields as well as proprietary extensions. >>> A receiving entity MUST be able to identify when incoming metadata type >>> is unknown and MUST have a defined default action to handle it. >>> A piece of information may need multiple fields to be described. For >>> example a tenant id and an ip address can be used to identify an server >>> in a data center uniquely. >>> These groups of information have to be exchanged collectively, in a >>> single message. In this case, a sending entity MUST specify that it is >>> sending a set of metadata in a message. >>> This set of transported metadata elements MUST be specified under the >>> form of a metadata template document uniquely defined for the chain. >>> A receiving entity MUST be able to detect if an incoming message >>> contains its expected set of metadata elements. >>> *2.1.2. Metadata Scope requirement* >>> A piece of information may have to be qualified by some attributes >>> allowing to identify its particular scope. For example in a Gi >>> environment, the radio type in use may be used as a scoping criteria for >>> a jitter or latency measurement in a video traffic transported in a >>> particular service chaing. >>> Scope can apply to some individual metadata elements or to a set of >>> metadata elements. How a scope applies to a set of transported metadata >>> elements should be defined by a specification under the form of a >>> metadata template document uniquely identified for the chain. >>> *2.2. IPFIX Metadata representation* >>> So far, unordered sequences of Type Length Value encoded fields have >>> been proposed to transport metadata. It is not clear how structured >>> types are supported, and no distinction is done between the metadata >>> values and their scoping values. Although the SCH proposal provides an >>> optional 24-bit Organizational Unique Identifier, there is no namespace >>> mechanism allowing to separate type definition spaces per Tenants or per >>> chain. >>> We suggest to leverage the work done by IETF on similar subject. >>> A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for >>> transmitting Traffic Flow information over the network. In order to >>> transmit Traffic Flow information, it provides a common representation >>> of flow data and a standard means of communicating them. >>> Metadata collected by Network Node and Service Node SHOULD be encoded in >>> template following the principles described in IPFIX[RFC7011]. >>> An IPFIX Message consisting of interleaved Template, Data, and Options >>> Template Sets, as shown in Figure 1. Here, Template and Options Template >>> Sets , which are optional, are shown. >>> >>> >>> +--------+--------------------------------------------------------+ >>> | | +----------+ +---------+ +-----------+ +---------+ | >>> |Message | | Template | | Data | | Options | | Data | | >>> | Header | | Set | | Set | ... | Template | | Set | | >>> | | | | | | | Set | | | | >>> | | +----------+ +---------+ +-----------+ +---------+ | >>> +--------+--------------------------------------------------------+ >>> >>> >>> >>> Figure 1: IPFIX Message Format >>> The Template Set describes the data transmitted in the following Data >>> Set. It is an optional component of the message. The value of the >>> metadata is encoded in the first Data Set. This Data Set contains a >>> template Id field as a reference to its defining Template Set. >>> The Options Template Set describes the data to be transmitted as scope >>> information. It is an optional component of the message. The value of >>> the scope information is encoded in the second Data Set element. It no >>> scope information is present, then only the first Data Set is present in >>> the message. >>> The Option Template Set and following Data Set are used to describe the >>> scope of the metadata transmitted. For example, the metadata collected >>> is relevant to a PDP Context or a particular line card of a particular >>> switch. >>> * >>> * >>> *2.2.4.3. Example:* >>> The Metadata Exporting Process creates a Template Record with a few >>> Information Elements: amongst other things, the Application Id. For >>> example: >>> >>> - sourceIPv4Address (key field) >>> - destinationIPv4Address (key field) >>> - protocol (key field) >>> - destinationTransportPort (key field) >>> - applicationId (key field) >>> - octetTotalCount (non key field) >>> >>> For example, a Flow Record corresponding to the above >>> Template Record may contain: >>> >>> { sourceIPv4Address=192.0.2.1, >>> destinationIPv4Address=192.0.2.2, >>> protocol=17, >>> destinationTransportPort=23, >>> applicationId='3..80', >>> octetTotalCount=123456 } >>> >>> >>> >>> The Options Data Record associated with the examples above would contain >>> the Scoping inforamtion: >>> >>> Scope: >>> - servicePath, >>> - serviceIndex, >>> - applicationId, >>> - applicationName >>> - applicationDescription. >>> >>> For example: >>> >>> { >>> servicePath=0x000b, >>> serviceIndex=0x000c, >>> applicationId='13...10000', >>> applicationName="webex", >>> applicationDescription="Webex application" } >>> >>> >>> >>> Scope information is useful when sending metadata offline, as it can >>> contain information related to the chain and possibly to the flow for >>> which this metadata record is relevant. Here servicePath and >>> serviceIndex are thus included in the Template. >>> *2.2.4.4. IPFIX encoding and template provisioning:* >>> IPFIX is a quite compact encoding >>> For a template defined as followed and shared by the SF in a chain. >>> IPFIX template record shared by SF: >>> Note that an XML representation of IPFIX template record could be >>> defined and used to provision Service Functions. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 | Length = 28 octets | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID 256 | Field Count = 5 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| sourceIPv4Address = 8 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| destinationIPv4Address = 12 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| ipNextHopIPv4Address = 15 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| packetDeltaCount = 2 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| octetDeltaCount = 1 | Field Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Figure 7: IPFIX Metadata template Encoding >>> An encoded IP fix transport message will be: >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version Number | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Export Time | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence Number | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Observation Domain ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 256 | Length = 64 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.12 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.254 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5009 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5344385 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> Figure 8: IPFIX Metadata Encoding >>> *3. Metadata transport service* >>> These different use cases for Metadata generate some requirements on the >>> reliability capabilities of the Metadata transport service they will >>> rely on. >>> De facto Service Function Chain proposals such as NSH and SCH define a >>> mechanism for sharing information along the Chains. It is thus important >>> to define this transport service in term of reliability. >>> The primary focus of these proposal are the Metadata elements playing a >>> role in the Service Function Chain deployment to apply policies on >>> incoming traffic at some relevant Service Functions. >>> For example, Network Orchestration is expected to be a significant >>> driver for deployment of Network Services. It relies on Service Level >>> abstractions such as Group Policies, Contracts and Services as an input >>> for the orchestration of Service Function Chains. Specific metadata >>> attributes such as L4-L7 fields are used as classification elements or >>> filters to funnel packets into chains. >>> Service Functions may have other needs for Metadata, for example Event >>> Based Metadata tied to some subscriber related state changes. The >>> complexity and length of these elements cannot be forseen as limited, >>> neither can be how critical it is that they are safely carried >>> throughout a chain. In the following Section we propose to take >>> avantage of Congruent Metadata Transport can be used, possibly reliably, >>> to address these needs. >>> *3.1. Proposed Metadata transport mechanisms* >>> . >>> *3.1.3. Metadata transport analysis* >>> Both NSH and SCH proposals support both inbound and offline out-of-band >>> metadata transport. >>> >>> 1. In-band: the metadata can be included directly as a value in some of >>> the NSH Context Header Fields. It is the preferred transport model >>> for SCH. >>> >>> In such case, when a particular field is always set to the same >>> value for all packets transported by the chain instance, then the >>> metadata transport service is in effect reliable. >>> >>> Similarly, all the packet for a particular flow (defined by its 5 >>> tupple), could receive the same metadata value. The metadata >>> transport service is also reliable, provided that the value is >>> understood to be attached to a flow. >>> >>> The general case however, occurs when the metadata varies from >>> packet to packet in a flow. The value is then tied to a specific >>> packet. Here the transport service is not reliable. A retransmission >>> of a particular packet would not necessarily lead it to carry the >>> same metadata value. >>> 2. Out-of-band: a reference for some metadata is sent along a packet so >>> that it can be used via an interaction with a controller entity. It >>> is the preferred model for NSH, but could also be used by SCH. >>> >>> As for the in-band case, the metadata referred to indirectly can be >>> transmitted reliably, when its value remains the same for a chain or >>> a flow in a chain. a chain or a flow in a chain. >>> >>> If however, the correlation Id passed changes over time, or if the >>> Metadata itself cahanges then the correct Metadata may not be >>> efficiently retrieved by some Service Functions. >>> >>> We can see that NSH and SCH do not address the need for a reliable >>> transport service for metadata, independantly of the reliability >>> characteristic of the transport service used for the data packets. >>> Conventions can be used as particular cases when some metadata pertains >>> to a specific chain or a flow in the chain, and when its value does not >>> change overtime. >>> Such conventions however are weak. They would suppose that some >>> mechanism exists to ensure/monitor that they are followed. And some >>> exceptions mechanism would be required to deal with error cases. >>> *3.2. Support for Congruent out-of-band transport service* >>> Congruent out-of-band metadata sharing can be required for some types of >>> Metadata exchanges. It has the advantage of clearly tying the metadata >>> to the chain and not to a specific packet, and to avoid payload >>> fragmentation issues. >>> Up to draft 2, NSH did not allow for long inline metadata transport. >>> Four 32 bits context fields are reserved for that purpose, and seem best >>> suited for offline Metadata sharing, or to transport predefined policy >>> identifiers. >>> NSH (since draf 3) as well as SCH could allow for metadata transport, >>> either tied to a packet or possibly tied to the chain, when used without >>> payload, as signaling messages. >>> SCH however stipulates that in case the Path Identifier and SF Index >>> fields shall be set to zero for transmit and ignored upon receipt, when >>> the SCH packet will contain only metadata. So congruent out-of-band >>> metadata, transporting Metadata hop to hop to the various Service >>> Function in the chain, does not seem to be supported. >>> NSH supports inline variable size metadata. It does not mentions >>> explicitly that congruent out-of-band metadata can be used. >>> *3.3. Reliable transport service* >>> Some metadata will need a reliable transport service to be shared >>> inline, as well as offline. >>> A protocol SCTP provides such a service and has the interesting >>> characteristic to be packet based, as opposed to stream based like TCP. >>> SCTP carries a sequence number and support retransmission and congestion >>> control. >>> Figure 12 shows how SCTP is used hop by hop between SFF in a chain to >>> transport Metadata reliably. >>> >>> |1 ----- |n |21 ---- |2m >>> +---+---+ +---+---+ +-+---+ +--+-----+ >>> | SF#1 | |SF#n | |SF#i1| |SF#im | >>> | | | | | | | | >>> +---+---+ +---+---+ +--+--+ +--+--+--+ >>> : : : : : >>> : : : : : >>> \ / \ / >>> +-----------+ SCTP +--------+ SCTP +---------+ >>> -- >| Chain | <---> | SFF | <---> | SFF | ----> >>> |classifier | |Node-1 | | Node-i | >>> +-----------+ +----+---+ +----+--+-+ >>> \ | / >>> \ | SFC Encapsulation / >>> \ | / >>> ,........................................ >>> / \ >>> / \ >>> | Network | >>> \ / >>> \........................................./ >>> >>> >>> >>> Figure 12: SCTP for Reliable Metadata transport >>> SCTP SHOULD be used in the context of Congruent out of band for reliable >>> metadata sharing. >>> For reliable Metadata transport, the SFF along the chain MUST route the >>> metadata received over SCTP to the next SF in the chain. For this SCTP >>> MUST be encapsulated in the SFC header. >>> The SFF MUST make the received metadata available to its SF.ti >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a11351db00994a004fddb7737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang &l= t;huang@sce.carl= eton.ca> wrote:
I am concerned with the overhead metadata ma= y create. Internet packet sizes tend to be bimodal where more than 50% of p= ackets have very small packet sizes. Carrying large amounts of overhead wil= l reduce throughput significantly. Making metadata optional may be a good c= hoice.
Doesn't that depend only if the SFC spans across the = internet? =C2=A0
Otherwise it (overhead) should be limited to SFC= 's domain, which may not span across internet, no?

=
cheers
-sam

Regards,

Chang


On 07/10/2014 11:22 AM, Joel M. Halpern wrote:
I look forward to seeing your draft.

One of the reasons I like including the metadata with the underlying packet= is that they then share fate. =C2=A0If the packet gets lost, the metadata = disappears with it, which is frequently fine. =C2=A0And if the packet is pr= obably delviered down the service path, then so is the metadata.

Yours,
Joel

On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote:
Hello,

Metadata transport is a feature provided by SFC that needs some
additional thoughts as well.

B Rijsman has done a great job showing various option for Metadata
sharing. Still there are 2 aspects that I would like to address further

- Metadata representation

- Metadata transport reliability

We will probably post a draft on the subject, but this can be done after Toronto has started. So for those
interested to provide some feedback, here are some highlights.

*1. Problem Space*
* Metadata representation*
Metadata can be extremely varied in term of usage and content. It can
represent the result of Deep Packet Inspection (DPI) performed on the
traffic for example by the Classifier Service Function at the ingress of the Service Function Chain. It can contain information collected about
the end user such as a policy identifier, a category or even represent
an event related to the end-user session.
This information can be used by Service Functions on the chain, as well
as by monitoring entities responsible to track usage for example in the
Network Function Virtualization environment to feed a VNF manager or an
Orchestrator.
Metadata being information shared by many network entities needs some
means to be represented it in all of its dimensions: type definition,
encoding and scope.
* Metadata transport service*
As expected from service chain proposals, both NSH and SCH proposals
define some means to carry metadata between Service Functions in a
Chain. They can be classified as follow:
Dataplane Metadata:
are defined in the Service Function Chaining Problem Statement document. They are not considered to be part of the forwarding information of the
SFC header. However they are expected to carry the result of antecedent
classification, allowing Service Functions to take local policy
decisions based on their values.

As such, they could also be interpreted directly by Service Function
Forwarder to steer traffic to various Service Functions.
Offline Metadata:
Beyond Dataplane Metadata, Offline Metadata can be shared between
Service Functions in a chain, using out of band, congruent or not, or
hybrid models described in [RIJSMAN]

The hybrid model for example, defined in [RIJSMAN], utilizes the SFC
header to transport some key values for correlation purposes. These
Correlation Ids can be used by the Service Functions to recover the full associated contextual information.
Metadata, directly or indirectly, are transported hop by hop along a
chain, in association to end-user traffic, the data payload of the SFC
packets.
How these metadata are transported over a chain matters. Passing
metadata directly or indirectly along packets is a service that must be
analyzed from a reliability point of view.

Reliability requirements may vary depending on the nature of the
metadata transported. Past experience for example in Mobile Network and
data center with AAA Radius have shown that contextual information
replication to various service function was indeed sensitive to packet
loss events, and that adhoc solutions had to be implemented to detect them.=
End to end TCP retransmission of packet lost does not ensure that
associated Metadata will be reinserted in retransmitted packet. In
addition, Event triggered metadata may have to be sent immediately on a
chain even though no end-user traffic is being transmitted
Not all metadata needs a reliable transport. Repeated inline metadata
can be used to cover several use cases, and some metadata loss can be
acceptable.
Still, a reliable transport service for Metadata in SFC is expected. To
this effect, an implementation is suggested in Section 3.3
*2. Metadata representation*
Metadata definition is that it provides contextual information about the data packets which traverse a Service Function Chain. This must be
understood broadly.
Metadata can contain the result of traffic classification by Deep Packet Inspection (DPI). For example as an Application Id information which is
tied to a traffic flow. There could be multiple flows with different
application ids, in a chain.
Metadata can also contain the result of DPI data extraction, such as
identify requested URL in HTTP. Such information can be passed to
certain SF down the chain such as a URL filtering function.
Metadata can contain some punctual event information collected at the
Ingress point of the chain and expected to be passed to all elements in
the chain. Here this information may be triggered externally and
generated only once, and be related to the tenant or the subscriber.
Metadata representation involves the definition of a set of information
elements types and the encoding rules for their values.
Metadata representation can sometimes be performed by a single
individual field with associated type and format. However, it is not
always enough.

=C2=A0 * Metadata may need multiple fields transported together to
=C2=A0 =C2=A0 represented their values.
=C2=A0 * Some addition fields may be required to describe the scope of the<= br> =C2=A0 =C2=A0 metadata itself. This can be any information element allowing= to
=C2=A0 =C2=A0 define the context of the associated metadata value. For exam= ple a
=C2=A0 =C2=A0 throughput metadata field can have a port number and a switch=
=C2=A0 =C2=A0 address as its Scope information.

We explore these two axis: encoding and scope.
We propose IPFIX as a preferred means to represent Metadata in Service
Chain messages for Out-of-band, Congruent or not; Metadata sharing.
*2.1. Metadata Representation Requirements*
Mandatatory Dataplane Metadata is always part of the SFC header, it is
thus reasonable to consider that its representation scheme will be
implicit: based on what the SFC protocol will dictate, their position in the SFC header is sufficient for the receiving end to infer their type
and encoding scheme. For example, Context Header Fields in NSH are 32
bit fields.
However, it will not be the case for all metadata transported. Offline
metadata, including congruent out-of-band metadata still need to be
represented explicitly. This section addresses their specific case.
*2.1.1. Metadata Encoding requirements*
These requirements are applicable to out-of-band metadata (Congruent or
not). It could be applicable with SCH on optional in-line metadata fields.<= br> For interoperability purposes, metadata encoding MUST allow the
receiving entity to identify the type and value of the information
received as metadata
Metadata encoding MUST allow for encoding techniques supporting well
known types and fields as well as proprietary extensions.
A receiving entity MUST be able to identify when incoming metadata type
is unknown and MUST have a defined default action to handle it.
A piece of information may need multiple fields to be described. For
example a tenant id and an ip address can be used to identify an server
in a data center uniquely.
These groups of information have to be exchanged collectively, in a
single message. In this case, a sending entity MUST specify that it is
sending a set of metadata in a message.
This set of transported metadata elements MUST be specified under the
form of a metadata template document uniquely defined for the chain.
A receiving entity MUST be able to detect if an incoming message
contains its expected set of metadata elements.
*2.1.2. Metadata Scope requirement*
A piece of information may have to be qualified by some attributes
allowing to identify its particular scope. For example in a Gi
environment, the radio type in use may be used as a scoping criteria for a jitter or latency measurement in a video traffic transported in a
particular service chaing.
Scope can apply to some individual metadata elements or to a set of
metadata elements. How a scope applies to a set of transported metadata
elements should be defined by a specification under the form of a
metadata template document uniquely identified for the chain.
*2.2. IPFIX Metadata representation*
So far, unordered sequences of Type Length Value encoded fields have
been proposed to transport metadata. It is not clear how structured
types are supported, and no distinction is done between the metadata
values and their scoping values. Although the SCH proposal provides an
optional 24-bit Organizational Unique Identifier, there is no namespace
mechanism allowing to separate type definition spaces per Tenants or per chain.
We suggest to leverage the work done by IETF on similar subject.
A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for transmitting Traffic Flow information over the network. In order to
transmit Traffic Flow information, it provides a common representation
of flow data and a standard means of communicating them.
Metadata collected by Network Node and Service Node SHOULD be encoded in template following the principles described in IPFIX[RFC7011].
An IPFIX Message consisting of interleaved Template, Data, and Options
Template Sets, as shown in Figure 1. Here, Template and Options Template Sets , which are optional, are shown.


+--------+---------------------------------------------------= -----+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| +----------+ +---------+ =C2= =A0 =C2=A0 +-----------+ +---------+ |
=C2=A0 =C2=A0 |Message | | Template | | Data =C2=A0 =C2=A0| =C2=A0 =C2=A0 |= Options =C2=A0 | | Data =C2=A0 =C2=A0| |
=C2=A0 =C2=A0 | Header | | Set =C2=A0 =C2=A0 =C2=A0| | Set =C2=A0 =C2=A0 | = ... | Template =C2=A0| | Set =C2=A0 =C2=A0 | |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | Set =C2=A0 =C2=A0 = =C2=A0 | | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| +----------+ +---------+ =C2= =A0 =C2=A0 +-----------+ +---------+ |
+--------+---------------------------------------------------= -----+



Figure 1: IPFIX Message Format
The Template Set describes the data transmitted in the following Data
Set. It is an optional component of the message. The value of the
metadata is encoded in the first Data Set. This Data Set contains a
template Id field as a reference to its defining Template Set.
The Options Template Set describes the data to be transmitted as scope
information. It is an optional component of the message. The value of
the scope information is encoded in the second Data Set element. It no
scope information is present, then only the first Data Set is present in the message.
The Option Template Set and following Data Set are used to describe the
scope of the metadata transmitted. For example, the metadata collected
is relevant to a PDP Context or a particular line card of a particular
switch.
*
*
*2.2.4.3. Example:*
The Metadata Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application Id. For example= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- sourceIPv4Address (key field)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- destinationIPv4Address (key field)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- protocol (key field)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- destinationTransportPort (key field) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- applicationId (key field)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- octetTotalCount (non key field)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, a Flow Record corresponding = to the above
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Template Record may contain:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{ sourceIPv4Address=3D192.0= .2.1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destinationIPv4Addre= ss=3D192.0.2.2,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol=3D17,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destinationTransport= Port=3D23,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicationId=3D'= ;3..80',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0octetTotalCount=3D12= 3456 }



The Options Data Record associated with the examples above would contain the Scoping inforamtion:

=C2=A0 =C2=A0 =C2=A0 Scope:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - servicePath,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - serviceIndex,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - applicationId,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - applicationName
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - applicationDescription.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0servicePath=3D0x000b= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0serviceIndex=3D0x000= c,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicationId=3D'= ;13...10000',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicationName=3D&q= uot;webex",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applicationDescripti= on=3D"Webex application" }



Scope information is useful when sending metadata offline, as it can
contain information related to the chain and possibly to the flow for
which this metadata record is relevant. Here servicePath and
serviceIndex are thus included in the Template.
*2.2.4.4. IPFIX encoding and template provisioning:*
IPFIX is a quite compact encoding
For a template defined as followed and shared by the SF in a chain.
IPFIX template record shared by SF:
Note that an XML representation of IPFIX template record could be
defined and used to provision Service Functions.

=C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7= 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set ID =3D 2 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0Length =3D 28 octets =C2=A0 = =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Template ID 256 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Field Count =3D 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 |0| =C2=A0 =C2=A0sourceIPv4Address =3D 8 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 Field Length =3D 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 |0| destinationIPv4Address =3D 12 | =C2=A0 =C2=A0 =C2=A0 Fiel= d Length =3D 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 |0| =C2=A0ipNextHopIPv4Address =3D 15 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 Field Length =3D 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 |0| =C2=A0 =C2=A0packetDeltaCount =3D 2 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 Field Length =3D 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 |0| =C2=A0 =C2=A0octetDeltaCount =3D 1 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 Field Length =3D 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+


Figure 7: IPFIX Metadata template Encoding
An encoded IP fix transport message will be:


=C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 3 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Version Number =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Export Time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sequence Number =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Observation Domain ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set ID =3D 256 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Length =3D 64 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | 192.0.2.12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | 192.0.2.254 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | 192.0.2.1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | 5009 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
=C2=A0 =C2=A0 | 5344385 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+



Figure 8: IPFIX Metadata Encoding
*3. Metadata transport service*
These different use cases for Metadata generate some requirements on the reliability capabilities of the Metadata transport service they will
rely on.
De facto Service Function Chain proposals such as NSH and SCH define a
mechanism for sharing information along the Chains. It is thus important to define this transport service in term of reliability.
The primary focus of these proposal are the Metadata elements playing a
role in the Service Function Chain deployment to apply policies on
incoming traffic at some relevant Service Functions.
For example, Network Orchestration is expected to be a significant
driver for deployment of Network Services. It relies on Service Level
abstractions such as Group Policies, Contracts and Services as an input
for the orchestration of Service Function Chains. Specific metadata
attributes such as L4-L7 fields are used as classification elements or
filters to funnel packets into chains.
Service Functions may have other needs for Metadata, for example Event
Based Metadata tied to some subscriber related state changes. The
complexity and length of these elements cannot be forseen as limited,
neither can be how critical it is that they are safely carried
throughout a chain. In =C2=A0the following Section we propose to take
avantage of Congruent Metadata Transport can be used, possibly reliably, to address these needs.
*3.1. Proposed Metadata transport mechanisms*
.
*3.1.3. Metadata transport analysis*
Both NSH and SCH proposals support both inbound and offline out-of-band
metadata transport.

=C2=A01. In-band: the metadata can be included directly as a value in some = of
=C2=A0 =C2=A0 the NSH Context Header Fields. It is the preferred transport = model
=C2=A0 =C2=A0 for SCH.

=C2=A0 =C2=A0 In such case, when a particular field is always set to the sa= me
=C2=A0 =C2=A0 value for all packets transported by the chain instance, then= the
=C2=A0 =C2=A0 metadata transport service is in effect reliable.

=C2=A0 =C2=A0 Similarly, all the packet for a particular flow (defined by i= ts 5
=C2=A0 =C2=A0 tupple), could receive the same metadata value. The metadata<= br> =C2=A0 =C2=A0 transport service is also reliable, provided that the value i= s
=C2=A0 =C2=A0 understood to be attached to a flow.

=C2=A0 =C2=A0 The general case however, occurs when the metadata varies fro= m
=C2=A0 =C2=A0 packet to packet in a flow. The value is then tied to a speci= fic
=C2=A0 =C2=A0 packet. Here the transport service is not reliable. A retrans= mission
=C2=A0 =C2=A0 of a particular packet would not necessarily lead it to carry= the
=C2=A0 =C2=A0 same metadata value.
=C2=A02. Out-of-band: a reference for some metadata is sent along a packet = so
=C2=A0 =C2=A0 that it can be used via an interaction with a controller enti= ty. It
=C2=A0 =C2=A0 is the preferred model for NSH, but could also be used by SCH= .

=C2=A0 =C2=A0 As for the in-band case, the metadata referred to indirectly = can be
=C2=A0 =C2=A0 transmitted reliably, when its value remains the same for a c= hain or
=C2=A0 =C2=A0 a flow in a chain. a chain or a flow in a chain.

=C2=A0 =C2=A0 If however, the correlation Id passed changes over time, or i= f the
=C2=A0 =C2=A0 Metadata itself cahanges then the correct Metadata may not be=
=C2=A0 =C2=A0 efficiently retrieved by some Service Functions.

We can see that NSH and SCH do not address the need for a reliable
transport service for metadata, independantly of the reliability
characteristic of the transport service used for the data packets.
Conventions can be used as particular cases when some metadata pertains
to a specific chain or a flow in the chain, and when its value does not
change overtime.
Such conventions however are weak. They would suppose that some
mechanism exists to ensure/monitor that they are followed. And some
exceptions mechanism would be required to deal with error cases.
*3.2. Support for Congruent out-of-band transport service*
Congruent out-of-band metadata sharing can be required for some types of Metadata exchanges. It has the advantage of clearly tying the metadata
to the chain and not to a specific packet, and to avoid payload
fragmentation issues.
Up to draft 2, NSH did not allow for long inline metadata transport.
Four 32 bits context fields are reserved for that purpose, and seem best suited for offline Metadata sharing, or to transport predefined policy
identifiers.
NSH (since draf 3) as well as SCH could allow for metadata transport,
either tied to a packet or possibly tied to the chain, when used without payload, as signaling messages.
SCH however stipulates that in case the Path Identifier and SF Index
fields shall be set to zero for transmit and ignored upon receipt, when
the SCH packet will contain only metadata. So congruent out-of-band
metadata, transporting Metadata hop to hop to the various Service
Function in the chain, does not seem to be supported.
NSH supports inline variable size metadata. It does not mentions
explicitly that congruent out-of-band metadata can be used.
*3.3. Reliable transport service*
Some metadata will need a reliable transport service to be shared
inline, as well as offline.
A protocol SCTP provides such a service and has the interesting
characteristic to be packet based, as opposed to stream based like TCP.
SCTP carries a sequence number and support retransmission and congestion control.
Figure 12 shows how SCTP is used hop by hop between SFF in a chain to
transport Metadata reliably.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |1 =C2=A0----- =C2=A0 |n =C2=A0 =C2=A0 =C2=A0 =C2=A0|21 =C2=A0---- |2m<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+= ---+ =C2=A0 +---+---+ =C2=A0 +-+---+ =C2=A0 +--+-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | SF#= 1 =C2=A0| =C2=A0 |SF#n =C2=A0 | =C2=A0 |SF#i1| =C2=A0 |SF#im =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 = | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---+= ---+ =C2=A0 +---+---+ =C2=A0 +--+--+ =C2=A0 +--+--+--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0+-----------+ SCTP =C2=A0 +--------+ =C2=A0 =C2=A0SCTP = =C2=A0 =C2=A0 +---------+
-- >| Chain =C2=A0 =C2=A0 | <---> =C2=A0| SFF =C2=A0 =C2=A0| =C2= =A0 =C2=A0<---> =C2=A0 =C2=A0| SFF =C2=A0 =C2=A0 | ---->
=C2=A0 =C2=A0 =C2=A0|classifier | =C2=A0 =C2=A0 =C2=A0 =C2=A0|Node-1 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Node-i =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-----------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+----+---+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----+--+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SFC Encapsulation =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0,.....= ...................................
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Network =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \...........= ............................../



Figure 12: SCTP for Reliable Metadata transport
SCTP SHOULD be used in the context of Congruent out of band for reliable metadata sharing.
For reliable Metadata transport, the SFF along the chain MUST route the
metadata received over SCTP to the next SF in the chain. For this SCTP
MUST be encapsulated in the SFC header.
=C2=A0 =C2=A0 =C2=A0The SFF MUST make the received metadata available to it= s SF.ti


_______________________________________________
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


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

--001a11351db00994a004fddb7737-- From nobody Thu Jul 10 12:03: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 3EFEB1B299A for ; Thu, 10 Jul 2014 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 w8IUfUQ0r95m for ; Thu, 10 Jul 2014 12:02:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFA91B29A4 for ; Thu, 10 Jul 2014 12:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32106; q=dns/txt; s=iport; t=1405018964; x=1406228564; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h8MBlW8B2ejSqs5aGUumbUgz7WT2qLVabZNZyVr7npA=; b=G7MBObBpXj9LHnwK3uzn1A71KpsW24se9L7LAUgCbDG61YTP6OXmX1FL aHT79Xt5+0fIHHfXp7QP+Pf2qX44SjL790/qejMCKb+5ra6p1sePZwj5y 8UN3qNFOznCcUu6XkZ/h/Z48Lp7hTI63Ev9zxd8IZsufu8HsWbfsOWqPR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAArivlOtJA2D/2dsb2JhbABPCoJHR1JarmuReAEJh0IBgQ4WdYQDAQEBBAEBAWIJCxACAQgRAQMBASEBBgcnCxQDBggCBA4FG4gTAxENx1YTBI0ZgU9SBgQGAYMtgRYFliBGhBqLY4gyg0OCMA X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208,217";a="339105942" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 10 Jul 2014 19:02:43 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6AJ2bg1008689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 19:02:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 14:02:37 -0500 From: "Paul Quinn (paulq)" To: Lucy yong Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuYfwEAgAC5UYCAAIXgAIAAQmiA Date: Thu, 10 Jul 2014 19:02:37 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@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.82.101.28] Content-Type: multipart/alternative; boundary="_000_AB80AC854BA1419E88D723F2F7141FBEciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/y_T6ZTzuWT5Hz0uQlA5QpMJa0f4 Cc: "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 19:03:03 -0000 --_000_AB80AC854BA1419E88D723F2F7141FBEciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make = the minor change: the path identifier can be used to derive the needed forw= arding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_AB80AC854BA1419E88D723F2F7141FBEciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <054A9E68A95659418DAB4799C88F494C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Lucy,

Overall I concur, as you say: a path ID drives the forwarding.  I= =92d make the minor change: the path identifier can be used to derive the n= eeded forwarding and associated transport.

It is _not_ the transport, but rather is used to simply identify the s= ervice path (or graph) that packets must traverse.  By having a path i= dentifier, the exact indirection that people seem to be asking for on this = thread can be simply be implemented.  The path identifier provides nothing more than a lookup, that lookup= can result in a one or more (equal or weighted) transport next hop(s). &nb= sp;

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:

Agree. The arch. doc should not mandate only use of the se= rvice path identifier to drive the forwarding actions.
 
Lucy
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; <= a href=3D"mailto:jmh@joelhalpern.com" style=3D"color: purple; text-decorati= on: underline;">jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers
 
Re-,
 
The merged draft calls out explicitly a service path identifier.= I object to use that identifier to derive forwarding actions.
 
Requiring a SFC system to have the full knowledge of every avail= able SFC forwarding paths within an SFC-enabled domain is not required/just= ified nor possible in various deployment contexts.
 
SFC forwarding actions should rely on the piece of information t= hat will be present in all deployments: that is the one required to structu= re a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
 
Cheers,
Med
 
De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=E9 : me= rcredi 9 juillet 2014 22:03
=C0 : jmh@joelhalpern.com;&nb= sp;sfc@ietf.org
Objet : Re: [= sfc] Service Chains, Paths, and Load Balancers
 
Is anyone = still questioning the difference between SF Chain and SF Path?  Other = than clarifying the definition so that it's clear to those not familiar wit= h the draft, it seems that everyone agrees on these terms.
 
To me, the= one point that is still unclear is whether it is the intent of this draft = to ultimately specify what the ID of the SFC Header should reference (the c= hain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate t= he mechanisms for forwarding based on chain or path and the choice of chain= or path to be negotiated in the control-plane.  
 
If the lat= ter (ambiguous), then the draft would have require that both SFP and SFC be= supported (or make one required and the other optional) to avoid some vend= ors only supporting SFP and others only supporting SFC.
 
 

 

From: jmh@joelhalpern.com<jmh@joelhalpern.com&g= t;
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able 
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

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

--_000_AB80AC854BA1419E88D723F2F7141FBEciscocom_-- From nobody Thu Jul 10 12:42: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 D381C1B29A4 for ; Thu, 10 Jul 2014 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 FLL8c_u-jSfT for ; Thu, 10 Jul 2014 12:41:56 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E061B297D for ; Thu, 10 Jul 2014 12:41:56 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AJfrRJ020831 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 10 Jul 2014 15:41:55 -0400 Message-ID: <53BEEDC3.6000305@sce.carleton.ca> Date: Thu, 10 Jul 2014 12:47:15 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sfc@ietf.org References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030003080300070204030301" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/P1NRuO3hyD9olV11eBkIZHV2PJY Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:42:02 -0000 This is a multi-part message in MIME format. --------------030003080300070204030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Even the SFC is limited to a specific domain (such as a datacenter), the packet sizes still follow the same distribution. The bandwidth within a datacenter is still a bottleneck part due to traffic patterns such as incast. Chang On 07/10/2014 12:02 PM, Sam Aldrin wrote: > > > On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang > > wrote: > > I am concerned with the overhead metadata may create. Internet > packet sizes tend to be bimodal where more than 50% of packets > have very small packet sizes. Carrying large amounts of overhead > will reduce throughput significantly. Making metadata optional may > be a good choice. > > Doesn't that depend only if the SFC spans across the internet? > Otherwise it (overhead) should be limited to SFC's domain, which may > not span across internet, no? > > cheers > -sam > > > Regards, > > Chang > > > On 07/10/2014 11:22 AM, Joel M. Halpern wrote: > > I look forward to seeing your draft. > > One of the reasons I like including the metadata with the > underlying packet is that they then share fate. If the packet > gets lost, the metadata disappears with it, which is > frequently fine. And if the packet is probably delviered down > the service path, then so is the metadata. > > Yours, > Joel > > On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: > > Hello, > > Metadata transport is a feature provided by SFC that needs > some > additional thoughts as well. > > B Rijsman has done a great job showing various option for > Metadata > sharing. Still there are 2 aspects that I would like to > address further > > - Metadata representation > > - Metadata transport reliability > > We will probably post a draft on the subject, but this can > be done after > Toronto has started. So for those > interested to provide some feedback, here are some highlights. > > *1. Problem Space* > * Metadata representation* > Metadata can be extremely varied in term of usage and > content. It can > represent the result of Deep Packet Inspection (DPI) > performed on the > traffic for example by the Classifier Service Function at > the ingress of > the Service Function Chain. It can contain information > collected about > the end user such as a policy identifier, a category or > even represent > an event related to the end-user session. > This information can be used by Service Functions on the > chain, as well > as by monitoring entities responsible to track usage for > example in the > Network Function Virtualization environment to feed a VNF > manager or an > Orchestrator. > Metadata being information shared by many network entities > needs some > means to be represented it in all of its dimensions: type > definition, > encoding and scope. > * Metadata transport service* > As expected from service chain proposals, both NSH and SCH > proposals > define some means to carry metadata between Service > Functions in a > Chain. They can be classified as follow: > Dataplane Metadata: > are defined in the Service Function Chaining Problem > Statement document. > They are not considered to be part of the forwarding > information of the > SFC header. However they are expected to carry the result > of antecedent > classification, allowing Service Functions to take local > policy > decisions based on their values. > > As such, they could also be interpreted directly by > Service Function > Forwarder to steer traffic to various Service Functions. > Offline Metadata: > Beyond Dataplane Metadata, Offline Metadata can be shared > between > Service Functions in a chain, using out of band, congruent > or not, or > hybrid models described in [RIJSMAN] > > The hybrid model for example, defined in [RIJSMAN], > utilizes the SFC > header to transport some key values for correlation > purposes. These > Correlation Ids can be used by the Service Functions to > recover the full > associated contextual information. > Metadata, directly or indirectly, are transported hop by > hop along a > chain, in association to end-user traffic, the data > payload of the SFC > packets. > How these metadata are transported over a chain matters. > Passing > metadata directly or indirectly along packets is a service > that must be > analyzed from a reliability point of view. > > Reliability requirements may vary depending on the nature > of the > metadata transported. Past experience for example in > Mobile Network and > data center with AAA Radius have shown that contextual > information > replication to various service function was indeed > sensitive to packet > loss events, and that adhoc solutions had to be > implemented to detect them. > End to end TCP retransmission of packet lost does not > ensure that > associated Metadata will be reinserted in retransmitted > packet. In > addition, Event triggered metadata may have to be sent > immediately on a > chain even though no end-user traffic is being transmitted > Not all metadata needs a reliable transport. Repeated > inline metadata > can be used to cover several use cases, and some metadata > loss can be > acceptable. > Still, a reliable transport service for Metadata in SFC is > expected. To > this effect, an implementation is suggested in Section 3.3 > *2. Metadata representation* > Metadata definition is that it provides contextual > information about the > data packets which traverse a Service Function Chain. This > must be > understood broadly. > Metadata can contain the result of traffic classification > by Deep Packet > Inspection (DPI). For example as an Application Id > information which is > tied to a traffic flow. There could be multiple flows with > different > application ids, in a chain. > Metadata can also contain the result of DPI data > extraction, such as > identify requested URL in HTTP. Such information can be > passed to > certain SF down the chain such as a URL filtering function. > Metadata can contain some punctual event information > collected at the > Ingress point of the chain and expected to be passed to > all elements in > the chain. Here this information may be triggered > externally and > generated only once, and be related to the tenant or the > subscriber. > Metadata representation involves the definition of a set > of information > elements types and the encoding rules for their values. > Metadata representation can sometimes be performed by a single > individual field with associated type and format. However, > it is not > always enough. > > * Metadata may need multiple fields transported together to > represented their values. > * Some addition fields may be required to describe the > scope of the > metadata itself. This can be any information element > allowing to > define the context of the associated metadata value. > For example a > throughput metadata field can have a port number and a > switch > address as its Scope information. > > We explore these two axis: encoding and scope. > We propose IPFIX as a preferred means to represent > Metadata in Service > Chain messages for Out-of-band, Congruent or not; Metadata > sharing. > *2.1. Metadata Representation Requirements* > Mandatatory Dataplane Metadata is always part of the SFC > header, it is > thus reasonable to consider that its representation scheme > will be > implicit: based on what the SFC protocol will dictate, > their position in > the SFC header is sufficient for the receiving end to > infer their type > and encoding scheme. For example, Context Header Fields in > NSH are 32 > bit fields. > However, it will not be the case for all metadata > transported. Offline > metadata, including congruent out-of-band metadata still > need to be > represented explicitly. This section addresses their > specific case. > *2.1.1. Metadata Encoding requirements* > These requirements are applicable to out-of-band metadata > (Congruent or > not). It could be applicable with SCH on optional in-line > metadata fields. > For interoperability purposes, metadata encoding MUST > allow the > receiving entity to identify the type and value of the > information > received as metadata > Metadata encoding MUST allow for encoding techniques > supporting well > known types and fields as well as proprietary extensions. > A receiving entity MUST be able to identify when incoming > metadata type > is unknown and MUST have a defined default action to > handle it. > A piece of information may need multiple fields to be > described. For > example a tenant id and an ip address can be used to > identify an server > in a data center uniquely. > These groups of information have to be exchanged > collectively, in a > single message. In this case, a sending entity MUST > specify that it is > sending a set of metadata in a message. > This set of transported metadata elements MUST be > specified under the > form of a metadata template document uniquely defined for > the chain. > A receiving entity MUST be able to detect if an incoming > message > contains its expected set of metadata elements. > *2.1.2. Metadata Scope requirement* > A piece of information may have to be qualified by some > attributes > allowing to identify its particular scope. For example in a Gi > environment, the radio type in use may be used as a > scoping criteria for > a jitter or latency measurement in a video traffic > transported in a > particular service chaing. > Scope can apply to some individual metadata elements or to > a set of > metadata elements. How a scope applies to a set of > transported metadata > elements should be defined by a specification under the > form of a > metadata template document uniquely identified for the chain. > *2.2. IPFIX Metadata representation* > So far, unordered sequences of Type Length Value encoded > fields have > been proposed to transport metadata. It is not clear how > structured > types are supported, and no distinction is done between > the metadata > values and their scoping values. Although the SCH proposal > provides an > optional 24-bit Organizational Unique Identifier, there is > no namespace > mechanism allowing to separate type definition spaces per > Tenants or per > chain. > We suggest to leverage the work done by IETF on similar > subject. > A natural candidate to leverage is IPFIX [RFC7011]: IPFIX > is a means for > transmitting Traffic Flow information over the network. In > order to > transmit Traffic Flow information, it provides a common > representation > of flow data and a standard means of communicating them. > Metadata collected by Network Node and Service Node SHOULD > be encoded in > template following the principles described in IPFIX[RFC7011]. > An IPFIX Message consisting of interleaved Template, Data, > and Options > Template Sets, as shown in Figure 1. Here, Template and > Options Template > Sets , which are optional, are shown. > > > +--------+--------------------------------------------------------+ > | | +----------+ +---------+ +-----------+ > +---------+ | > |Message | | Template | | Data | | Options | > | Data | | > | Header | | Set | | Set | ... | Template | > | Set | | > | | | | | | | Set | > | | | > | | +----------+ +---------+ +-----------+ > +---------+ | > +--------+--------------------------------------------------------+ > > > > Figure 1: IPFIX Message Format > The Template Set describes the data transmitted in the > following Data > Set. It is an optional component of the message. The value > of the > metadata is encoded in the first Data Set. This Data Set > contains a > template Id field as a reference to its defining Template Set. > The Options Template Set describes the data to be > transmitted as scope > information. It is an optional component of the message. > The value of > the scope information is encoded in the second Data Set > element. It no > scope information is present, then only the first Data Set > is present in > the message. > The Option Template Set and following Data Set are used to > describe the > scope of the metadata transmitted. For example, the > metadata collected > is relevant to a PDP Context or a particular line card of > a particular > switch. > * > * > *2.2.4.3. Example:* > The Metadata Exporting Process creates a Template Record > with a few > Information Elements: amongst other things, the > Application Id. For example: > > - sourceIPv4Address (key field) > - destinationIPv4Address (key field) > - protocol (key field) > - destinationTransportPort (key field) > - applicationId (key field) > - octetTotalCount (non key field) > > For example, a Flow Record corresponding to the above > Template Record may contain: > > { sourceIPv4Address=192.0.2.1, > destinationIPv4Address=192.0.2.2, > protocol=17, > destinationTransportPort=23, > applicationId='3..80', > octetTotalCount=123456 } > > > > The Options Data Record associated with the examples above > would contain > the Scoping inforamtion: > > Scope: > - servicePath, > - serviceIndex, > - applicationId, > - applicationName > - applicationDescription. > > For example: > > { > servicePath=0x000b, > serviceIndex=0x000c, > applicationId='13...10000', > applicationName="webex", > applicationDescription="Webex application" } > > > > Scope information is useful when sending metadata offline, > as it can > contain information related to the chain and possibly to > the flow for > which this metadata record is relevant. Here servicePath and > serviceIndex are thus included in the Template. > *2.2.4.4. IPFIX encoding and template provisioning:* > IPFIX is a quite compact encoding > For a template defined as followed and shared by the SF in > a chain. > IPFIX template record shared by SF: > Note that an XML representation of IPFIX template record > could be > defined and used to provision Service Functions. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 | Length = 28 > octets | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count = > 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| sourceIPv4Address = 8 | Field Length = > 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| destinationIPv4Address = 12 | Field Length = > 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ipNextHopIPv4Address = 15 | Field Length = > 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| packetDeltaCount = 2 | Field Length = > 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| octetDeltaCount = 1 | Field Length = > 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 7: IPFIX Metadata template Encoding > An encoded IP fix transport message will be: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 256 | Length = 64 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.254 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 192.0.2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5009 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5344385 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 8: IPFIX Metadata Encoding > *3. Metadata transport service* > These different use cases for Metadata generate some > requirements on the > reliability capabilities of the Metadata transport service > they will > rely on. > De facto Service Function Chain proposals such as NSH and > SCH define a > mechanism for sharing information along the Chains. It is > thus important > to define this transport service in term of reliability. > The primary focus of these proposal are the Metadata > elements playing a > role in the Service Function Chain deployment to apply > policies on > incoming traffic at some relevant Service Functions. > For example, Network Orchestration is expected to be a > significant > driver for deployment of Network Services. It relies on > Service Level > abstractions such as Group Policies, Contracts and > Services as an input > for the orchestration of Service Function Chains. Specific > metadata > attributes such as L4-L7 fields are used as classification > elements or > filters to funnel packets into chains. > Service Functions may have other needs for Metadata, for > example Event > Based Metadata tied to some subscriber related state > changes. The > complexity and length of these elements cannot be forseen > as limited, > neither can be how critical it is that they are safely carried > throughout a chain. In the following Section we propose > to take > avantage of Congruent Metadata Transport can be used, > possibly reliably, > to address these needs. > *3.1. Proposed Metadata transport mechanisms* > . > *3.1.3. Metadata transport analysis* > Both NSH and SCH proposals support both inbound and > offline out-of-band > metadata transport. > > 1. In-band: the metadata can be included directly as a > value in some of > the NSH Context Header Fields. It is the preferred > transport model > for SCH. > > In such case, when a particular field is always set to > the same > value for all packets transported by the chain > instance, then the > metadata transport service is in effect reliable. > > Similarly, all the packet for a particular flow > (defined by its 5 > tupple), could receive the same metadata value. The > metadata > transport service is also reliable, provided that the > value is > understood to be attached to a flow. > > The general case however, occurs when the metadata > varies from > packet to packet in a flow. The value is then tied to > a specific > packet. Here the transport service is not reliable. A > retransmission > of a particular packet would not necessarily lead it > to carry the > same metadata value. > 2. Out-of-band: a reference for some metadata is sent > along a packet so > that it can be used via an interaction with a > controller entity. It > is the preferred model for NSH, but could also be used > by SCH. > > As for the in-band case, the metadata referred to > indirectly can be > transmitted reliably, when its value remains the same > for a chain or > a flow in a chain. a chain or a flow in a chain. > > If however, the correlation Id passed changes over > time, or if the > Metadata itself cahanges then the correct Metadata may > not be > efficiently retrieved by some Service Functions. > > We can see that NSH and SCH do not address the need for a > reliable > transport service for metadata, independantly of the > reliability > characteristic of the transport service used for the data > packets. > Conventions can be used as particular cases when some > metadata pertains > to a specific chain or a flow in the chain, and when its > value does not > change overtime. > Such conventions however are weak. They would suppose that > some > mechanism exists to ensure/monitor that they are followed. > And some > exceptions mechanism would be required to deal with error > cases. > *3.2. Support for Congruent out-of-band transport service* > Congruent out-of-band metadata sharing can be required for > some types of > Metadata exchanges. It has the advantage of clearly tying > the metadata > to the chain and not to a specific packet, and to avoid > payload > fragmentation issues. > Up to draft 2, NSH did not allow for long inline metadata > transport. > Four 32 bits context fields are reserved for that purpose, > and seem best > suited for offline Metadata sharing, or to transport > predefined policy > identifiers. > NSH (since draf 3) as well as SCH could allow for metadata > transport, > either tied to a packet or possibly tied to the chain, > when used without > payload, as signaling messages. > SCH however stipulates that in case the Path Identifier > and SF Index > fields shall be set to zero for transmit and ignored upon > receipt, when > the SCH packet will contain only metadata. So congruent > out-of-band > metadata, transporting Metadata hop to hop to the various > Service > Function in the chain, does not seem to be supported. > NSH supports inline variable size metadata. It does not > mentions > explicitly that congruent out-of-band metadata can be used. > *3.3. Reliable transport service* > Some metadata will need a reliable transport service to be > shared > inline, as well as offline. > A protocol SCTP provides such a service and has the > interesting > characteristic to be packet based, as opposed to stream > based like TCP. > SCTP carries a sequence number and support retransmission > and congestion > control. > Figure 12 shows how SCTP is used hop by hop between SFF in > a chain to > transport Metadata reliably. > > |1 ----- |n |21 ---- |2m > +---+---+ +---+---+ +-+---+ +--+-----+ > | SF#1 | |SF#n | |SF#i1| |SF#im | > | | | | | | | | > +---+---+ +---+---+ +--+--+ +--+--+--+ > : : : : : > : : : : : > \ / \ / > +-----------+ SCTP +--------+ SCTP +---------+ > -- >| Chain | <---> | SFF | <---> | SFF | > ----> > |classifier | |Node-1 | | Node-i | > +-----------+ +----+---+ +----+--+-+ > \ | / > \ | SFC Encapsulation / > \ | / > ,........................................ > / \ > / \ > | Network | > \ / > \........................................./ > > > > Figure 12: SCTP for Reliable Metadata transport > SCTP SHOULD be used in the context of Congruent out of > band for reliable > metadata sharing. > For reliable Metadata transport, the SFF along the chain > MUST route the > metadata received over SCTP to the next SF in the chain. > For this SCTP > MUST be encapsulated in the SFC header. > The SFF MUST make the received metadata available to > its SF.ti > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --------------030003080300070204030301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Even the SFC is limited to a specific domain (such as a datacenter), the packet sizes still follow the same distribution. The bandwidth within a datacenter is still a bottleneck part due to traffic patterns such as incast.

Chang

On 07/10/2014 12:02 PM, Sam Aldrin wrote:


On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang <huang@sce.carleton.ca> wrote:
I am concerned with the overhead metadata may create. Internet packet sizes tend to be bimodal where more than 50% of packets have very small packet sizes. Carrying large amounts of overhead will reduce throughput significantly. Making metadata optional may be a good choice.
Doesn't that depend only if the SFC spans across the internet?  
Otherwise it (overhead) should be limited to SFC's domain, which may not span across internet, no?

cheers
-sam

Regards,

Chang


On 07/10/2014 11:22 AM, Joel M. Halpern wrote:
I look forward to seeing your draft.

One of the reasons I like including the metadata with the underlying packet is that they then share fate.  If the packet gets lost, the metadata disappears with it, which is frequently fine.  And if the packet is probably delviered down the service path, then so is the metadata.

Yours,
Joel

On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote:
Hello,

Metadata transport is a feature provided by SFC that needs some
additional thoughts as well.

B Rijsman has done a great job showing various option for Metadata
sharing. Still there are 2 aspects that I would like to address further

- Metadata representation

- Metadata transport reliability

We will probably post a draft on the subject, but this can be done after
Toronto has started. So for those
interested to provide some feedback, here are some highlights.

*1. Problem Space*
* Metadata representation*
Metadata can be extremely varied in term of usage and content. It can
represent the result of Deep Packet Inspection (DPI) performed on the
traffic for example by the Classifier Service Function at the ingress of
the Service Function Chain. It can contain information collected about
the end user such as a policy identifier, a category or even represent
an event related to the end-user session.
This information can be used by Service Functions on the chain, as well
as by monitoring entities responsible to track usage for example in the
Network Function Virtualization environment to feed a VNF manager or an
Orchestrator.
Metadata being information shared by many network entities needs some
means to be represented it in all of its dimensions: type definition,
encoding and scope.
* Metadata transport service*
As expected from service chain proposals, both NSH and SCH proposals
define some means to carry metadata between Service Functions in a
Chain. They can be classified as follow:
Dataplane Metadata:
are defined in the Service Function Chaining Problem Statement document.
They are not considered to be part of the forwarding information of the
SFC header. However they are expected to carry the result of antecedent
classification, allowing Service Functions to take local policy
decisions based on their values.

As such, they could also be interpreted directly by Service Function
Forwarder to steer traffic to various Service Functions.
Offline Metadata:
Beyond Dataplane Metadata, Offline Metadata can be shared between
Service Functions in a chain, using out of band, congruent or not, or
hybrid models described in [RIJSMAN]

The hybrid model for example, defined in [RIJSMAN], utilizes the SFC
header to transport some key values for correlation purposes. These
Correlation Ids can be used by the Service Functions to recover the full
associated contextual information.
Metadata, directly or indirectly, are transported hop by hop along a
chain, in association to end-user traffic, the data payload of the SFC
packets.
How these metadata are transported over a chain matters. Passing
metadata directly or indirectly along packets is a service that must be
analyzed from a reliability point of view.

Reliability requirements may vary depending on the nature of the
metadata transported. Past experience for example in Mobile Network and
data center with AAA Radius have shown that contextual information
replication to various service function was indeed sensitive to packet
loss events, and that adhoc solutions had to be implemented to detect them.
End to end TCP retransmission of packet lost does not ensure that
associated Metadata will be reinserted in retransmitted packet. In
addition, Event triggered metadata may have to be sent immediately on a
chain even though no end-user traffic is being transmitted
Not all metadata needs a reliable transport. Repeated inline metadata
can be used to cover several use cases, and some metadata loss can be
acceptable.
Still, a reliable transport service for Metadata in SFC is expected. To
this effect, an implementation is suggested in Section 3.3
*2. Metadata representation*
Metadata definition is that it provides contextual information about the
data packets which traverse a Service Function Chain. This must be
understood broadly.
Metadata can contain the result of traffic classification by Deep Packet
Inspection (DPI). For example as an Application Id information which is
tied to a traffic flow. There could be multiple flows with different
application ids, in a chain.
Metadata can also contain the result of DPI data extraction, such as
identify requested URL in HTTP. Such information can be passed to
certain SF down the chain such as a URL filtering function.
Metadata can contain some punctual event information collected at the
Ingress point of the chain and expected to be passed to all elements in
the chain. Here this information may be triggered externally and
generated only once, and be related to the tenant or the subscriber.
Metadata representation involves the definition of a set of information
elements types and the encoding rules for their values.
Metadata representation can sometimes be performed by a single
individual field with associated type and format. However, it is not
always enough.

  * Metadata may need multiple fields transported together to
    represented their values.
  * Some addition fields may be required to describe the scope of the
    metadata itself. This can be any information element allowing to
    define the context of the associated metadata value. For example a
    throughput metadata field can have a port number and a switch
    address as its Scope information.

We explore these two axis: encoding and scope.
We propose IPFIX as a preferred means to represent Metadata in Service
Chain messages for Out-of-band, Congruent or not; Metadata sharing.
*2.1. Metadata Representation Requirements*
Mandatatory Dataplane Metadata is always part of the SFC header, it is
thus reasonable to consider that its representation scheme will be
implicit: based on what the SFC protocol will dictate, their position in
the SFC header is sufficient for the receiving end to infer their type
and encoding scheme. For example, Context Header Fields in NSH are 32
bit fields.
However, it will not be the case for all metadata transported. Offline
metadata, including congruent out-of-band metadata still need to be
represented explicitly. This section addresses their specific case.
*2.1.1. Metadata Encoding requirements*
These requirements are applicable to out-of-band metadata (Congruent or
not). It could be applicable with SCH on optional in-line metadata fields.
For interoperability purposes, metadata encoding MUST allow the
receiving entity to identify the type and value of the information
received as metadata
Metadata encoding MUST allow for encoding techniques supporting well
known types and fields as well as proprietary extensions.
A receiving entity MUST be able to identify when incoming metadata type
is unknown and MUST have a defined default action to handle it.
A piece of information may need multiple fields to be described. For
example a tenant id and an ip address can be used to identify an server
in a data center uniquely.
These groups of information have to be exchanged collectively, in a
single message. In this case, a sending entity MUST specify that it is
sending a set of metadata in a message.
This set of transported metadata elements MUST be specified under the
form of a metadata template document uniquely defined for the chain.
A receiving entity MUST be able to detect if an incoming message
contains its expected set of metadata elements.
*2.1.2. Metadata Scope requirement*
A piece of information may have to be qualified by some attributes
allowing to identify its particular scope. For example in a Gi
environment, the radio type in use may be used as a scoping criteria for
a jitter or latency measurement in a video traffic transported in a
particular service chaing.
Scope can apply to some individual metadata elements or to a set of
metadata elements. How a scope applies to a set of transported metadata
elements should be defined by a specification under the form of a
metadata template document uniquely identified for the chain.
*2.2. IPFIX Metadata representation*
So far, unordered sequences of Type Length Value encoded fields have
been proposed to transport metadata. It is not clear how structured
types are supported, and no distinction is done between the metadata
values and their scoping values. Although the SCH proposal provides an
optional 24-bit Organizational Unique Identifier, there is no namespace
mechanism allowing to separate type definition spaces per Tenants or per
chain.
We suggest to leverage the work done by IETF on similar subject.
A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for
transmitting Traffic Flow information over the network. In order to
transmit Traffic Flow information, it provides a common representation
of flow data and a standard means of communicating them.
Metadata collected by Network Node and Service Node SHOULD be encoded in
template following the principles described in IPFIX[RFC7011].
An IPFIX Message consisting of interleaved Template, Data, and Options
Template Sets, as shown in Figure 1. Here, Template and Options Template
Sets , which are optional, are shown.


+--------+--------------------------------------------------------+
    |        | +----------+ +---------+     +-----------+ +---------+ |
    |Message | | Template | | Data    |     | Options   | | Data    | |
    | Header | | Set      | | Set     | ... | Template  | | Set     | |
    |        | |          | |         |     | Set       | |         | |
    |        | +----------+ +---------+     +-----------+ +---------+ |
+--------+--------------------------------------------------------+



Figure 1: IPFIX Message Format
The Template Set describes the data transmitted in the following Data
Set. It is an optional component of the message. The value of the
metadata is encoded in the first Data Set. This Data Set contains a
template Id field as a reference to its defining Template Set.
The Options Template Set describes the data to be transmitted as scope
information. It is an optional component of the message. The value of
the scope information is encoded in the second Data Set element. It no
scope information is present, then only the first Data Set is present in
the message.
The Option Template Set and following Data Set are used to describe the
scope of the metadata transmitted. For example, the metadata collected
is relevant to a PDP Context or a particular line card of a particular
switch.
*
*
*2.2.4.3. Example:*
The Metadata Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application Id. For example:

         - sourceIPv4Address (key field)
         - destinationIPv4Address (key field)
         - protocol (key field)
         - destinationTransportPort (key field)
         - applicationId (key field)
         - octetTotalCount (non key field)

         For example, a Flow Record corresponding to the above
         Template Record may contain:

             { sourceIPv4Address=192.0.2.1,
               destinationIPv4Address=192.0.2.2,
               protocol=17,
               destinationTransportPort=23,
               applicationId='3..80',
               octetTotalCount=123456 }



The Options Data Record associated with the examples above would contain
the Scoping inforamtion:

      Scope:
              - servicePath,
              - serviceIndex,
              - applicationId,
              - applicationName
              - applicationDescription.

       For example:

             {
               servicePath=0x000b,
               serviceIndex=0x000c,
               applicationId='13...10000',
               applicationName="webex",
               applicationDescription="Webex application" }



Scope information is useful when sending metadata offline, as it can
contain information related to the chain and possibly to the flow for
which this metadata record is relevant. Here servicePath and
serviceIndex are thus included in the Template.
*2.2.4.4. IPFIX encoding and template provisioning:*
IPFIX is a quite compact encoding
For a template defined as followed and shared by the SF in a chain.
IPFIX template record shared by SF:
Note that an XML representation of IPFIX template record could be
defined and used to provision Service Functions.

  0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Set ID = 2            |      Length = 28 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Template ID 256         |       Field Count = 5         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    packetDeltaCount = 2     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    octetDeltaCount = 1      |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 7: IPFIX Metadata template Encoding
An encoded IP fix transport message will be:


    0                   1                   2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Version Number          | Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Export Time                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Observation Domain ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Set ID = 256         |          Length = 64          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.12                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.254                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.1                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5009                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5344385                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Figure 8: IPFIX Metadata Encoding
*3. Metadata transport service*
These different use cases for Metadata generate some requirements on the
reliability capabilities of the Metadata transport service they will
rely on.
De facto Service Function Chain proposals such as NSH and SCH define a
mechanism for sharing information along the Chains. It is thus important
to define this transport service in term of reliability.
The primary focus of these proposal are the Metadata elements playing a
role in the Service Function Chain deployment to apply policies on
incoming traffic at some relevant Service Functions.
For example, Network Orchestration is expected to be a significant
driver for deployment of Network Services. It relies on Service Level
abstractions such as Group Policies, Contracts and Services as an input
for the orchestration of Service Function Chains. Specific metadata
attributes such as L4-L7 fields are used as classification elements or
filters to funnel packets into chains.
Service Functions may have other needs for Metadata, for example Event
Based Metadata tied to some subscriber related state changes. The
complexity and length of these elements cannot be forseen as limited,
neither can be how critical it is that they are safely carried
throughout a chain. In  the following Section we propose to take
avantage of Congruent Metadata Transport can be used, possibly reliably,
to address these needs.
*3.1. Proposed Metadata transport mechanisms*
.
*3.1.3. Metadata transport analysis*
Both NSH and SCH proposals support both inbound and offline out-of-band
metadata transport.

 1. In-band: the metadata can be included directly as a value in some of
    the NSH Context Header Fields. It is the preferred transport model
    for SCH.

    In such case, when a particular field is always set to the same
    value for all packets transported by the chain instance, then the
    metadata transport service is in effect reliable.

    Similarly, all the packet for a particular flow (defined by its 5
    tupple), could receive the same metadata value. The metadata
    transport service is also reliable, provided that the value is
    understood to be attached to a flow.

    The general case however, occurs when the metadata varies from
    packet to packet in a flow. The value is then tied to a specific
    packet. Here the transport service is not reliable. A retransmission
    of a particular packet would not necessarily lead it to carry the
    same metadata value.
 2. Out-of-band: a reference for some metadata is sent along a packet so
    that it can be used via an interaction with a controller entity. It
    is the preferred model for NSH, but could also be used by SCH.

    As for the in-band case, the metadata referred to indirectly can be
    transmitted reliably, when its value remains the same for a chain or
    a flow in a chain. a chain or a flow in a chain.

    If however, the correlation Id passed changes over time, or if the
    Metadata itself cahanges then the correct Metadata may not be
    efficiently retrieved by some Service Functions.

We can see that NSH and SCH do not address the need for a reliable
transport service for metadata, independantly of the reliability
characteristic of the transport service used for the data packets.
Conventions can be used as particular cases when some metadata pertains
to a specific chain or a flow in the chain, and when its value does not
change overtime.
Such conventions however are weak. They would suppose that some
mechanism exists to ensure/monitor that they are followed. And some
exceptions mechanism would be required to deal with error cases.
*3.2. Support for Congruent out-of-band transport service*
Congruent out-of-band metadata sharing can be required for some types of
Metadata exchanges. It has the advantage of clearly tying the metadata
to the chain and not to a specific packet, and to avoid payload
fragmentation issues.
Up to draft 2, NSH did not allow for long inline metadata transport.
Four 32 bits context fields are reserved for that purpose, and seem best
suited for offline Metadata sharing, or to transport predefined policy
identifiers.
NSH (since draf 3) as well as SCH could allow for metadata transport,
either tied to a packet or possibly tied to the chain, when used without
payload, as signaling messages.
SCH however stipulates that in case the Path Identifier and SF Index
fields shall be set to zero for transmit and ignored upon receipt, when
the SCH packet will contain only metadata. So congruent out-of-band
metadata, transporting Metadata hop to hop to the various Service
Function in the chain, does not seem to be supported.
NSH supports inline variable size metadata. It does not mentions
explicitly that congruent out-of-band metadata can be used.
*3.3. Reliable transport service*
Some metadata will need a reliable transport service to be shared
inline, as well as offline.
A protocol SCTP provides such a service and has the interesting
characteristic to be packet based, as opposed to stream based like TCP.
SCTP carries a sequence number and support retransmission and congestion
control.
Figure 12 shows how SCTP is used hop by hop between SFF in a chain to
transport Metadata reliably.

                      |1  -----   |n        |21  ---- |2m
                    +---+---+   +---+---+   +-+---+   +--+-----+
                    | SF#1  |   |SF#n   |   |SF#i1|   |SF#im   |
                    |       |   |       |   |     |   |        |
                    +---+---+   +---+---+   +--+--+   +--+--+--+
                        :           :          :         :  :
                        :           :          :         :  :
                         \         /            \       /
     +-----------+ SCTP   +--------+    SCTP     +---------+
-- >| Chain     | <--->  | SFF    |    <--->    | SFF     | ---->
     |classifier |        |Node-1  |             | Node-i  |
     +-----------+        +----+---+             +----+--+-+
                   \           |                     /
                    \          | SFC Encapsulation  /
                     \         |                   /
                   ,........................................
                  /                                         \
                 /                                           \
                |                      Network                |
                 \                                           /
                  \........................................./



Figure 12: SCTP for Reliable Metadata transport
SCTP SHOULD be used in the context of Congruent out of band for reliable
metadata sharing.
For reliable Metadata transport, the SFF along the chain MUST route the
metadata received over SCTP to the next SF in the chain. For this SCTP
MUST be encapsulated in the SFC header.
     The SFF MUST make the received metadata available to its SF.ti


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


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


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



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

--------------030003080300070204030301-- From nobody Thu Jul 10 12:50: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 977F01B29AB for ; Thu, 10 Jul 2014 12:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 v6qWo3C9TaRX for ; Thu, 10 Jul 2014 12:50:07 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF2E1B27AA for ; Thu, 10 Jul 2014 12:50:07 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AJo5Lh021785 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 10 Jul 2014 15:50:06 -0400 Message-ID: <53BEEFAE.6030301@sce.carleton.ca> Date: Thu, 10 Jul 2014 12:55:26 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030105010005000809040907" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LZweNsTbO4LvYYj3kCVgSU_uLD0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:50:14 -0000 This is a multi-part message in MIME format. --------------030105010005000809040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit As defined in the problem statement document, a service function is not a concept. Here is the quote from the document "A Service Function can be a virtual instance or be embedded in a physical network element." This means a service function is a virtual entity. A virtual machine (VM), for example, can decide which process to run first. Similarly a service function can decide how a packet being processed and forwarded to the next service function hop. Chang On 07/10/2014 11:36 AM, Ron Parker wrote: > > Hi, Mike. > > Between service function and service function instance, I think it > would have to be the instance, since the former is conceptual. But, > in a distributed path selection approach, might it make sense to > assign this duty to the service function forwarder (SFF)? > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *mikebianc@aol.com > *Sent:* Thursday, July 10, 2014 2:34 PM > *To:* I.Smith@F5.com; sfc@ietf.org > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > "Service Functions MAY make the decision about which Service Function > Instances will be used when selecting the Service Function Path." > > Is it service function that makes that decision? or the service > function instance? > > ------------------------------------------------------------------------ > > *From: *I.Smith@F5.com > > *To: *Changcheng Huang >,'Ron > Parker' >,'Lucy > yong' >,mohamed.boucadair@orange.com >,mikebianc@aol.com >,jmh@joelhalpern.com >,sfc@ietf.org > > *Sent: *Thursday, July 10, 2014 > *Subject: *RE: [sfc] Service Chains, Paths, and Load Balancers > > >Service functions should make the decision about which instances will > be used > > I think it is sufficient for the architecture to say, > > "Service Functions MAY make the decision about which Service Function > Instances will be used when selecting the Service Function Path." > > But you also say need to say, > > "Service Function Classifiers (or SNF's or SFF's, as the case may be) > MAY make the decision about which Service Function Instances will be > used when selecting the Service Function Path." > > and, > > "External orchestration frameworks MAY make the decision about which > Service Function Instances will be used when selecting the Service > Function Path." > > All three result in a Service Function Path being selected, and they > aren't necessarily exclusive of one another if you have rules for > resolving conflicts; the details of those rules are not architectural. > > IMO, the architecture needs to err on the side of being descriptive > over being proscriptive when there is a conflict between the two. > > > ------------------------------------------------------------------------ > > *From:*sfc [sfc-bounces@ietf.org ] on > behalf of Changcheng Huang [huang@sce.carleton.ca > ] > *Sent:* Thursday, July 10, 2014 12:31 PM > *To:* 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com > ; mikebianc@aol.com > ; jmh@joelhalpern.com > ; sfc@ietf.org > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > I agree with Ron's comments. Service functions should make the > decision about which instances will be used. It can be different > hop-by-hop (e.g. in a tree topology). In order to do so, it is > important a physical network makes a service function chain aware of > the available instances. These is no need to identify each possible > SFP by a physical network. If a service function chain wants to use > multiple SFPs, it should provide the identifier for each flow that > uses a particular SFP and the corresponding forwarding rules (i.e. > next hop). Nevertheless, because a physical network need to support > multiple tenants, it does need to identify different tenants. Our > recent contribution > (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ > ) has discussed this issue in a more general architecture. Hope it can > be helpful for this discussion. > > Chang > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > *Sent:* Thursday, July 10, 2014 8:20 AM > *To:* Lucy yong; mohamed.boucadair@orange.com > ; mikebianc@aol.com > ; jmh@joelhalpern.com > ; sfc@ietf.org > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > It is architecturally significant to identify that multiple > addressable instances of a service function are explicitly allowed. > Whether those instance perform some further level of load balancing is > irrelevant, as has been pointed out by Joel. It is also > architecturally significant to assign responsibility for instance > selection. In particular, is the instance selection centralized, > distributed, or some combination? Which functional entities in the > architecture have what responsibilities to achieve this? In November, > 2013, after IETF 88, I submitted this draft, > http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which > proposed that the instance selection was made hop by hop by the > service functions themselves, in a fully distributed manner. That was > just a proposal and I am not wedded to it, by any means. Joel asked > about specificity and it is at this level that I'd like to see the > architecture describe things. It should be able to answer the > question, "how does multi-instance selection work in SFC?" in a > concise manner. If the group feels that there should be more than one > answer to that question, so be it, but we should be able to describe > the high level mechanism and rationale for each succinctly. Of course, > that is merely one such question and there are many others that an > architectural document should be able to describe. > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Lucy yong > *Sent:* Thursday, July 10, 2014 11:05 AM > *To:* mohamed.boucadair@orange.com > ; mikebianc@aol.com > ; jmh@joelhalpern.com > ; sfc@ietf.org > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > Agree. The arch. doc should not mandate only use of the service path > identifier to drive the forwarding actions. > > Lucy > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > *mohamed.boucadair@orange.com > *Sent:* Thursday, July 10, 2014 2:06 AM > *To:* mikebianc@aol.com ; > jmh@joelhalpern.com ; sfc@ietf.org > > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > Re-, > > The merged draft calls out explicitly a service path identifier. I > object to use that identifier to derive forwarding actions. > > Requiring a SFC system to have the full knowledge of every available > SFC forwarding paths within an SFC-enabled domain is not > required/justified nor possible in various deployment contexts. > > SFC forwarding actions should rely on the piece of information that > will be present in all deployments: that is the one required to > structure a service chain. How that information is used to infer > forwarding actions is a solution-oriented discussion. > > Cheers, > > Med > > *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* > mikebianc@aol.com > *Envoyé :* mercredi 9 juillet 2014 22:03 > *À :* jmh@joelhalpern.com ; sfc@ietf.org > > *Objet :* Re: [sfc] Service Chains, Paths, and Load Balancers > > Is anyone still questioning the difference between SF Chain and SF > Path? Other than clarifying the definition so that it's clear to those > not familiar with the draft, it seems that everyone agrees on these terms. > > To me, the one point that is still unclear is whether it is the intent > of this draft to ultimately specify what the ID of the SFC Header > should reference (the chain or the path), or if this draft simply > intends to leave that ambiguous, allowing other drafts to dictate the > mechanisms for forwarding based on chain or path and the choice of > chain or path to be negotiated in the control-plane. > > If the latter (ambiguous), then the draft would have require that both > SFP and SFC be supported (or make one required and the other optional) > to avoid some vendors only supporting SFP and others only supporting SFC. > > ------------------------------------------------------------------------ > > *From: *jmh@joelhalpern.com > > *To: *sfc@ietf.org> > *Sent: *Tuesday, July 8, 2014 > *Subject: *[sfc] Service Chains, Paths, and Load Balancers > > I have been trying to figure out how to clearly answer a number of > comments that have been made about the proposed merged archtiecture > draft. Assuming we can get working group agreement on the intent, we > will work to improve the wording so that readers who have not > participated in the WG discussion will understnd it the way the working > group intends. > > But what do we intend? I will try to explain my personal view, and see > if that helps. > > In this regard, it is important to keep in mind that what we are > defining is the data plane architecture. We are not attempting to > define the architecture for the entire solution for service chaining. > That would encompass OSS/BSS, various control and policy functions, > virtual machine and image management, and many other aspects. > > As a result there are many things which clearly need to exist in the > larger system, but which are dealt with above where we are functioning, > and are not directly required by the work we are doing. > > In order to get to service chain vs service path, as I understand them, > I need to first discuss load balancing. There are at least three > different ways that load balancing can and will interact with service > chaining. There probably are more. The point of the archtiecture is to > permit all of these, but not to mandate that any particular kind be used > in any solution. > > 1) Load balancing as a service provided to the end user. This is a > service function. It receives user packets, and modifies them (or marks > them, or ...) so as to choose an end user service instance to receive > the users packet. This is an important service function to be able to > include in service chaining. It's behavior may affect requirements on > how service chaining is done. But it has very little impact on the > archtiecture. From an architectural pe3rspective it is simply a service > function which may modify the underlying packet. > > 2) There is internal load balancing. That is, one can have what appears > to the service chaining architecture as a single point of contact for a > specific service function, but is actually delivered by a collection of > virtual or physical machines, possibly including one or several load > balancers (for example using VRRP-like techniques to share a MAC > address.) mostly, this is invisible to the service chaining data plane > mechanisms. It is likely that it is visible to various control > mechanisms, such as those responsible for scale-in, scale-out, and vm > instantiation. The architectural impact of permitting this is largely > that we need to be careful that our terminology does not lead readers to > think we are prohibiting it. > > 3) There can also be load balancing done by selecting packet paths for > the service chaining that direct traffic to different places. We would > not want to require that a given service function appear at only one > place in the network. > > It is of course the case that these may be combined. I tend to refer to > the collection of entities that appear to service chaining as a single > point as a cluster. Not because cluster is a good term. But because I > do not have another one. Thus, the point of type 3 load balancing is to > direct different subsets of traffic to different singular or clustered > service functions in different places in the network. > > Now with that said, what do I mean when I talk about service chain and > service path/ Service chain is a sequence of logical functions to be > applied to a subset of packets. It is equivalent of saying that some > subset of traffic is to get DPI, charging, content inspection, and > firewall while a different subset is to go directly to the cache without > visiting any other service functions. > > That is not enough information to direct the packets. A service path > is, in some fashion, a sequence of locations in the network. Those > locations will be singular or clustered service function delivery > locations. They may be addressed by IP address. They may be addressed > as ports on an SFF. There are many different ways that the locations > may be known to the service chaining infrastructure and the transport. > > >From the point of view of the work of the SFC group, we need to be able > to talk about the high level abstraction, the service chain, which > drives the forwarding. And we need to talk about the actual data path > packets will take in the network. > > Several of the comments have said "but the whole path may not be known > at the front." This architecture deals with that issue in two ways. > First, as noted in item (2) on load balancers above, there can be > decisions and behaviors which are invisible to the service chaining > mechanisms (in much the same way that bridging within a LAN is largely > invisible to routing between LANs.) The other provision we make is that > reclassification can be done in mid-chain when necessary. That will > direct packets to a new chain. Based on information available at the > re-classification point. > > I hope that this helps explain what we are after. If it does, and if > the intent is acceptable to the working group, we can figure out what > additional words are needed to convey this. > If the working group disagree with the intent, then we will of course > adjust to match the working group agreements. > If this is still unclear, I am not sure what to try next. > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --------------030105010005000809040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As defined in the problem statement document, a service function is not a concept. Here is the quote from the document "A Service Function can be a virtual instance or be embedded in a physical network element." This means a service function is a virtual entity.

A virtual machine (VM), for example, can decide which process to run first. Similarly a service function can decide how a packet being processed and forwarded to the next service function hop.

Chang

On 07/10/2014 11:36 AM, Ron Parker wrote:

Hi, Mike.

 

Between service function and service function instance, I think it would have to be the instance, since the former is conceptual.    But, in a distributed path selection approach, might it make sense to assign this duty to the service function forwarder (SFF)?

 

   Ron

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: Thursday, July 10, 2014 2:34 PM
To: I.Smith@F5.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

 

"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path." 

 

Is it service function that makes that decision? or the service function instance?

 

From: I.Smith@F5.com<I.Smith@F5.com>
To: Changcheng Huang<huang@sce.carleton.ca>,'Ron Parker'<Ron_Parker@affirmednetworks.com>,'Lucy yong'<lucy.yong@huawei.com>,mohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,mikebianc@aol.com<mikebianc@aol.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't necessarily exclusive of one another if you have rules for resolving conflicts; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over being proscriptive when there is a conflict between the two.


From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I agree with Ron’s comments. Service functions should make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpful for this discussion.

Chang

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

It is architecturally significant to identify that multiple addressable instances of a service function are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed out by Joel. It is also architecturally significant to assign responsibility for instance selection. In particular, is the instance selection centralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities to achieve this? In November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner. That was just a proposal and I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I’d like to see the architecture describe things. It should be able to answer the question, “how does multi-instance selection work in SFC?” in a concise manner. If the group feels that there should be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly. Of course, that is merely one such question and there are many others that an architectural document should be able to describe.

Ron

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.

Lucy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.

Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.

Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoyé : mercredi 9 juillet 2014 22:03
À : jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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



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

--------------030105010005000809040907-- From nobody Thu Jul 10 12: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 9AFA11B29A8 for ; Thu, 10 Jul 2014 12:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 s49pj3D4W9e3 for ; Thu, 10 Jul 2014 12:54:24 -0700 (PDT) Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.143.75]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285491A0545 for ; Thu, 10 Jul 2014 12:54:24 -0700 (PDT) Received: from mtaout-mcc02.mx.aol.com (mtaout-mcc02.mx.aol.com [172.26.253.78]) by omr-m01.mx.aol.com (Outbound Mail Relay) with ESMTP id 1080D702AE1A4; Thu, 10 Jul 2014 15:54:23 -0400 (EDT) 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-mcc02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CADF838000093; Thu, 10 Jul 2014 15:54:22 -0400 (EDT) Date: Thu, 10 Jul 2014 15:54:22 -0400 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, I.Smith@F5.com, sfc@ietf.org Message-ID: <392080769.1482.1405022062609.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1481_765256836.1405022062608" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405022063; bh=Hu2MdjF1bmwBtY8mTsouXgzz5Vd3tsBt2PFrip4DItk=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=PdAdTv51mLWXAUzv5ADtMqKdIBrCEGjkB22614tQ2ybTrItzRKsws3xTjl55fElWd eF1pADbwAvWtG1bI18Hlz3etz1UlPvgpLsT5HGbUTQgeK2F1avg7xQ04iM+pi+Omy2 T9eAAxDwQIfFgtXqTguFTXKBi2ZH+IH6teztrrFs= x-aol-sid: 3039ac1afd4e53beef6e5e67 X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LYAns8JGDXliyW6Zrh20dvKKebA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 19:54:28 -0000 ------=_Part_1481_765256836.1405022062608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable agreed. =C2=A0Just wanted to verify. =C2=A0It might make sense for the SFF = to do the instance selection. =C2=A0The further toward the classifier you p= ush that decision, the less resilient you are to SFI failures, but the more= resources are required on the devices making that decision. =C2=A0In the c= ase of SFF, each SFF would need to know about all SFIs of all SFs. =C2=A0If= , however, the decision were made by the SFI (or proxy for SFC-unaware SFs)= , then each would only need to worry about all of the SFIs for each of the = SFs that are next in each chain for which it is a member. From: Ron_Parker@affirmednetworks.com To: mikebianc@aol.com,I.Smith@F5.com,sfc= @ietf.org Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hi, Mike. =20 Between service function and service function instance, I think it would ha= ve to be the instance, since the former is conceptual. But, in a distrib= uted path selection approach, might it make sense to assign this duty to the service= function forwarder (SFF)? =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: Thursday, July 10, 2014 2:34 PM To: I.Smith@F5.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path."=20 =20 Is it service function that makes that decision? or the service function in= stance? =20 From: I.Smith@F5.com To: Changcheng Huang,'Ron Parker','Lucy yong',mohamed.boucadair@orange.c= om,mikebianc@aol.com,jmh@j= oelhalpern.com,sfc@ietf.org Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >Service functions should make the decision about which instances will be used I think it is sufficient for the architecture to say, "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." But you also say need to say,=20 "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY m= ake the decision about which Service Function Instances will be used when s= electing the Service Function Path." and,=20 "External orchestration frameworks MAY make the decision about which Servic= e Function Instances will be used when selecting the Service Function Path.= " All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural. IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two. From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.carleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong';=20 mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com;=20 sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I agree with Ron=E2=80=99s comments. Service functions should make the deci= sion about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In orde= r to do so, it is important a physical network makes a service function cha= in aware of the available instances. These is no need to identify each poss= ible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide = the identifier for each flow that uses a particular SFP and the correspondi= ng forwarding rules (i.e. next hop). Nevertheless, because a physical netwo= rk need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https= ://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) h= as discussed this issue in a more general architecture. Hope it can be helpfu= l for this discussion. Chang From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com;=20 jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers It is architecturally significant to identify that multiple addressable ins= tances of a service function are explicitly allowed. Whether those instance perform some further level = of load balancing is irrelevant, as has been pointed out by Joel. It is als= o architecturally significant to assign responsibility for instance selecti= on. In particular, is the instance selection centralized, distributed, or some combination? Which functional = entities in the architecture have what responsibilities to achieve this? In= November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which propose= d that the instance selection was made hop by hop by the service functions = themselves, in a fully distributed manner. That was just a proposal and I a= m not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2=80=99d like= to see the architecture describe things. It should be able to answer the q= uestion, =E2=80=9Chow does multi-instance selection work in SFC?=E2=80=9D i= n a concise manner. If the group feels that there should be more than one answer to that question, so be it, but we should be able = to describe the high level mechanism and rationale for each succinctly. Of = course, that is merely one such question and there are many others that an = architectural document should be able to describe. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mikebianc@aol.com;=20 jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com;=20 sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions.=20 Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contex= ts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a service chain. How that information is = used to infer forwarding actions is a solution-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar with the draft, it seems that eve= ryone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or= if this draft simply intends to leave that ambiguous, allowing other draft= s to dictate the mechanisms for forwarding based on chain or path and the c= hoice of chain or path to be negotiated in the control-plane.=20 If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting= SFP and others only supporting SFC. From: jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. But what do we intend? I will try to explain my personal view, and see=20 if that helps. In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used=20 in any solution. 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to=20 think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without=20 visiting any other service functions. That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_1481_765256836.1405022062608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
agreed.  J= ust wanted to verify.  It might make sense for the SFF to do the insta= nce selection.  The further toward the classifier you push that decisi= on, the less resilient you are to SFI failures, but the more resources are = required on the devices making that decision.  In the case of SFF, eac= h SFF would need to know about all SFIs of all SFs.  If, however, the = decision were made by the SFI (or proxy for SFC-unaware SFs), then each wou= ld only need to worry about all of the SFIs for each of the SFs that are ne= xt in each chain for which it is a member.





From: Ron_P= arker@affirmednetworks.com<Ron_Parker@affirmednetworks.com>
To:= mikebianc@aol.com<mikebianc@aol.com>,I.Smith@F5.com<I.Smith@F= 5.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 1= 0, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balanc= ers

Hi, Mike.

Between service function = and service function instance, I think it would have to be the instance, si= nce the former is conceptual. But, in a distributed path selection approach, might it make sense to assign this duty to the service= function forwarder (SFF)?

Ron<= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com<= /a>
Sent: Thursday, July 10, 2014 2:34 PM
To: I.Smith@F5.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

"Service Functions MAY ma= ke the decision about which Service Function Instances will be used when se= lecting the Service Function Path."

Is it serv= ice function that makes that decision? or the service function instance?

From: I.Smith@F5.com<I.Smith@F5.co= m>
To: Changcheng Huang<hua= ng@sce.carleton.ca>,'Ron Parker'<Ron_Parker@affirmednetworks.com>,'Lucy yong'<<= a href=3D"mailto:lucy.yong@huawei.com">lucy.yong@huawei.com>,mohamed.boucadair@orange.com&l= t;mohamed.boucadair@orange.= com>,mikebianc@aol.com<<= a href=3D"mailto:mikebianc@aol.com">mikebianc@aol.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,sfc@ietf.org<sfc@ietf.org><= br> Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make the = decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY m= ake the decision about which Service Function Instances will be used when s= electing the Service Function Path."

and,

"External orchestration frameworks MAY ma= ke the decision about which Service Function Instances will be used when se= lecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two.


From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [hu= ang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mike= bianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

I agree with Ron=E2=80=99s comments. Se= rvice functions should make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In orde= r to do so, it is important a physical network makes a service function cha= in aware of the available instances. These is no need to identify each poss= ible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide = the identifier for each flow that uses a particular SFP and the correspondi= ng forwarding rules (i.e. next hop). Nevertheless, because a physical netwo= rk need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc= -use-case-recursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpfu= l for this discussion.=

Chang

It is architecturally significant to id= entify that multiple addressable instances of a service function are explicitly allowed. Whether those instance perform some further level = of load balancing is irrelevant, as has been pointed out by Joel. It is als= o architecturally significant to assign responsibility for instance selecti= on. In particular, is the instance selection centralized, distributed, or some combination? Which functional = entities in the architecture have what responsibilities to achieve this? In= November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which pro= posed that the instance selection was made hop by hop by the service functi= ons themselves, in a fully distributed manner. That was just a proposal and= I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2=80=99d like= to see the architecture describe things. It should be able to answer the q= uestion, =E2=80=9Chow does multi-instance selection work in SFC?=E2=80=9D i= n a concise manner. If the group feels that there should be more than one answer to that question, so be it, but we should be able = to describe the high level mechanism and rationale for each succinctly. Of = course, that is merely one such question and there are many others that an = architectural document should be able to describe.

Ron<= o:p>

From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; = sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Agree. The arch. doc should not mandate= only use of the service path identifier to drive the forwarding actions.

Lucy=

From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc= @aol.com; jmh@joelhalpern.co= m; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Re-,<= /p>

The merged draft calls out explicitly a service path ident= ifier. I object to use that identifier to derive forwarding actions. <= /p>

Requiring a SFC system to have the full knowledge of every= available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contex= ts.

SFC forwarding actions should rely on the piece of informa= tion that will be present in all deployments: that is the one required to structure a service chain. How that information is = used to infer forwarding actions is a solution-oriented discussion.<= span style=3D"color:black">

Cheers,

Med

De : sfc [mailto:sfc-= bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=C3=A9 : mercredi 9 juillet 2014 22:03
=C3=80 : jm= h@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still questioning the difference = between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that eve= ryone agrees on these terms.<= /span>

To me, the one point that is still unclear = is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or= if this draft simply intends to leave that ambiguous, allowing other draft= s to dictate the mechanisms for forwarding based on chain or path and the c= hoice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft w= ould have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting= SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joelh= alpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

------=_Part_1481_765256836.1405022062608-- From nobody Thu Jul 10 13:07: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 ACD5A1B29A4 for ; Thu, 10 Jul 2014 13:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWgIcVEyPS6U for ; Thu, 10 Jul 2014 13:07:20 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07B11B29AB for ; Thu, 10 Jul 2014 13:07:18 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 672feb35.2b15e4a00940.8553912.00-2424.20438877.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 20:07:18 +0000 (UTC) X-MXL-Hash: 53bef276786e2916-6f9c4605739870a98ff5fd8ae8d5248f320d68c0 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 562feb35.0.8553731.00-2396.20438361.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 20:07:01 +0000 (UTC) X-MXL-Hash: 53bef26515b02f0d-457103b4da754ba8bbab85e05146ff37ded61f9c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AK6xKJ017474; Thu, 10 Jul 2014 16:07:00 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AK6qOX017321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 16:06:55 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 20:06:37 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 16:06:18 -0400 From: "NAPIERALA, MARIA H" To: "Paul Quinn (paulq)" , Lucy yong Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xA= Date: Thu, 10 Jul 2014 20:06:18 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@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: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A632MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=3oc9M9_CAAAA:8 a] X-AnalysisOut: [=i0EeH86SAAAA:8 a=UhQ7tS4aFR-JZ9SPPWYA:9 a=wPNLvfGTeEIA:10] X-AnalysisOut: [ a=lZB815dzVvQA:10 a=chC_agHSu74A:10 a=oAXR_kdF8uMA:10 a=U] X-AnalysisOut: [8Ie8EnqySEA:10 a=hPjdaMEvmhQA:10 a=Tq5UBhJXjB3_7kyP:21 a=B] X-AnalysisOut: [cXaJsIER1XNSzGQ:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO] X-AnalysisOut: [2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuC] X-AnalysisOut: [g-hUA:10 a=UyHChYlokmGFU4Y9:21 a=xOrduB6rT_pbWSZb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KgrJnUsiUHyE6ZWA9rD4Tn5y2pU Cc: "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:07:25 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A632MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; mikebi= anc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I'd make th= e minor change: the path identifier can be used to derive the needed forwar= ding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A632MISOUT7MSGUSRCF_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Paul,

 <= /p>

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

 <= /p>

Maria

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org;= mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

Lucy,

 

Overall I concur, as you say: a path ID drives the f= orwarding.  I’d make the minor change: the path identifier can b= e used to derive the needed forwarding and associated transport.=

 

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse.  = By having a path identifier, the exact indirection that people seem to be a= sking for on this thread can be simply be implemented.  The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).  

 

Paul

 

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers

 

Re-,

 

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

 

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

 

Cheers,

Med

 

 

Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh@joelhalpern.= com<jmh@joelhalpern.com>
To: sfc@ietf.org&= lt;sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A632MISOUT7MSGUSRCF_-- From nobody Thu Jul 10 13:09: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 96FB61B29A8 for ; Thu, 10 Jul 2014 13:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 0fAaRd6SwHgv for ; Thu, 10 Jul 2014 13:08:55 -0700 (PDT) Received: from mxecd07.gs.com (mxe7.gs.com [204.4.178.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02131B27AA for ; Thu, 10 Jul 2014 13:08:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,639,1400040000"; d="scan'208";a="54037366" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxecd07.idz.gs.com with ESMTP; 10 Jul 2014 16:08:54 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp13ex.firmwide.corp.gs.com ([10.135.172.91]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 10 Jul 2014 16:08:54 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp13ex.firmwide.corp.gs.com ([10.135.172.91]) with mapi; Thu, 10 Jul 2014 16:08:54 -0400 To: "'jmh@joelhalpern.com'" , "'mikebianc@aol.com'" , "'paulq@cisco.com'" Date: Thu, 10 Jul 2014 16:08:54 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: Ac+ccXdba5mDdm/GSNidpYiHpu4nbwACU6ct Message-ID: In-Reply-To: <53BEE324.5070709@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-wiganss: 01000000010020gshccdp13ex.firmwide.corp.gs.com ID004D x-retentionstamp: Firmwide Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BljlSPV1edpPllY9ZHd4TglNxqo Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:08:58 -0000 VXNpbmcgdGhlIHRlcm0gbG9hZCBkaXN0cmlidXRpb24gdG8gcmVmZXIgdG8gbG9hZCBiYWxhbmNl ciBzZWxlY3Rpb24gd2lsbCBiZSBsb3N0IHRvIGEgbG90IG9mIHBlb3BsZS4gTWFueSBwZW9wbGUg Y2FsbCBpdCBnbG9iYWwgc2V2ZXIgbG9hZCBiYWxhbmNpbmcuDQoNClBsdXMsIHRoZXJlIGNvdWxk IGJlIG11bHRpcGxlIGxheWVycyBvZiAibG9hZCBkaXN0cmlidXRpb24iIC8gTEIgc2VsZWN0aW9u LiBOb3QganVzdCB0d28uIEZvciBleGFtcGxlLCBzZWxlY3QgYSByZWdpb24gZnJvbSBhIGdsb2Jh bCBwb29sOyBvbmNlIHRoZSByZWdpb24gaXMgc2VsZWN0ZWQsIHNlbGVjdCBhIGRhdGEgY2VudGVy IGluIHRoYXQgcmVnaW9uOyBpbiB0aGF0IERDLCB3aGljaCBEQyBMQiBpbnN0YW5jZSB0byBnbyB0 bzsgYW5kIHRoZW4gd2UgaGF2ZSB0aGUgdHJhZGl0aW9uYWwgTEIgd2hpY2ggc2VsZWN0cyB0aGUg ZW5kIHNlcnZlci4NCg0KSW4gc3VtLCAoMSkgcGF0aCBzZWxlY3Rpb24gY291bGQgaGFwcGVuIGF0 IG1vcmUgdGhhbiAyIGRpZmZlcmVudCB0aWVyczsgKDIpICJsb2FkIiBpc24ndCB0aGUgb25seSBj cml0ZXJpb24gaW4gdGhvc2Ugc2VsZWN0aW9ucy4gSSBzZWUgdGhlIHJhdGlvbmFsZSBmb3Igd2Fu dGluZyB0aGUgZGlmZmVyZW50aWF0aW9uIGJ1dCBpcyBsb2FkIGRpc3RyaWJ1dGlvbiB0aGUgYmVz dCB0ZXJtIGZvciBpdD8gDQoNClJlZ2FyZHMsDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t XQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMDM6MDEgUE0gRWFzdGVybiBTdGFuZGFy ZCBUaW1lClRvOiBtaWtlYmlhbmNAYW9sLmNvbSA8bWlrZWJpYW5jQGFvbC5jb20+OyBwYXVscUBj aXNjby5jb20gPHBhdWxxQGNpc2NvLmNvbT4NCkNjOiBzZmNAaWV0Zi5vcmcgPHNmY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KDQpUaGUgdGVybSAibG9hZCBkaXN0cmlidXRpb24iIHdvcmtzIGZvciBtZS4gIEkg YWdyZWUgdGhhdCB0aGVyZSBpcyB2YWx1ZSANCmluIGRpZmZlcmVudGlhdGluZyB0aGUgZnVuY3Rp b25zLCBhbmQgdXNpbmcgZGlmZmVyZW50IHdvcmRzIHVzdWFsbHkgDQpoZWxwcyBzdWNoIGRpZmZl cmVudGlhdGlvbi4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDcvMTAvMTQsIDI6NTUgUE0sIG1pa2Vi aWFuY0Bhb2wuY29tIHdyb3RlOg0KPiBJJ3ZlIHN0YXRlZCBiZWZvcmUgdGhhdCBJIHRoaW5rIHdl IHNob3VsZCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gbG9hZA0KPiBiYWxhbmNpbmcgYW5kIGxvYWQg ZGlzdHJpYnV0aW9uIHdoZXJlIGxvYWQgYmFsYW5jaW5nIHJlZmVycyB0byB0aGUNCj4gc3RhbmRh cmQgc2VydmljZSBmdW5jdGlvbiB0aGF0IHdlIGFsbCBrbm93IGFuZCBsb3ZlIChvdXRzaWRlIG9m IFNGQykgYW5kDQo+IGxvYWQgZGlzdHJpYnV0aW9uIHJlZmVycyB0byB0aGUgc2VsZWN0aW9uIG9m IGFuIFNGSSAoaS5lLiBDaGFpbiAtPiBQYXRoDQo+IG1hcHBpbmcpLiAgTm90IHVzaW5nIGRpZmZl cmVudCB0ZXJtcyB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZXNlIGxlYWRzDQo+IHRvIGNvbmZ1 c2lvbi4NCj4NCj4gZS5nLiBhIFNGIENoYWluKiBtaWdodCBleGlzdCB3aG9zZSBTRnMgY29uc2lz dCBvbmx5IG9mIGxvYWQgYmFsYW5jZXJzLg0KPiAgIEJ1dCB5b3UgbWlnaHQgc3RpbGwgd2FudCBT RkMqIHRvIGRpc3RyaWJ1dGUgbG9hZCB0byBtdWx0aXBsZSBsb2FkDQo+IGJhbGFuY2VyIGluc3Rh bmNlcy4NCj4NCj4gKnRyeWluZyB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIFNGQyBhcyAiU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbmluZyIgYW5kIGENCj4gc2luZ2xlICJTZXJ2aWNlIEZ1bmN0aW9uIENo YWluIi4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICpGcm9tOiAq cGF1bHFAY2lzY28uY29tPHBhdWxxQGNpc2NvLmNvbT4NCj4gKlRvOiAqSm9lbCBNLiBIYWxwZXJu PGptaEBqb2VsaGFscGVybi5jb20+DQo+ICpjYzogKkppbSBHdWljaGFyZA0KPiAoamd1aWNoYXIp PGpndWljaGFyQGNpc2NvLmNvbT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4sbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPixSb24NCj4g UGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+LE5BUElFUkFMQSwgTUFSSUEg SDxtbjE5MjFAYXR0LmNvbT4NCj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPiAq U3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPg0KPiBKb2VsLA0KPg0KPiBJIGNvbmN1ci4gVGhlIGdvYWwgaGVyZSBpcyB0byBhZGRy ZXNzIHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGdlbmVyaWMNCj4gc2VydmljZSBmdW5jdGlv biBkZXBsb3ltZW50IGFuZCBzaG91bGQgZW5hYmxlIGxvY2FsaXplZCBkZWNpc2lvbnMgc3VjaA0K PiBhcyBsb2FkIGJhbGFuY2luZyAocGVyaGFwcyBtb3JlIGFjY3VyYXRlbHkgbG9hZCBkaXN0cmli dXRpb24pLiBDbGVhcmx5DQo+IHdlIHNvdW5k4oCZdCBjb2RpZnkgaG93IGxvYWQgZGlzdHJpYnV0 aW9uIHdvcmtzLg0KPg0KPiBJbiBvcmRlciB0byBlbmFibGUgbG9hZCBkaXN0cmlidXRpb24sIGZv ciBleGFtcGxlLCB0aGUgcmlnaHQNCj4gYWJzdHJhY3Rpb25zIGJlZW4gdG8gYmUgY2xlYXJseSBk ZWZpbmVkIGluIHRoZSBhcmNoaXRlY3R1cmUsIGEga2V5IG9uZQ0KPiBiZXJpbmcgdGhlIGRpc3Rp bmN0aW9uIGJldHdlZW4gcGF0aCB2cy4gY2hhaW4uDQo+DQo+IFBhdWwNCj4NCj4NCj4NCj4gT24g SnVsIDEwLCAyMDE0LCBhdCAxMjowOCBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPiB3cm90ZToNCj4NCj4gID4gVGhhdCBpcyBjbGVhcmx5IGFuIGltcG9ydGFudCBwcm9i bGVtIGluIGJ1aWxkaW5nIGEgZnVsbCBzb2x1dGlvbiB0bw0KPiB0aGUgc2VydmljZSBjaGFpbmlu ZyBuZWVkcyBvZiBvcGVyYXRvcnMgKGUuZy4geW91KS4gSG93ZXZlciwgSSBjb3VsZA0KPiBlcXVh bGx5IG9ic2VydmUgdGhhdCBpZiB5b3UgZG8gbm90IGhhdmUgT1NTL0JTUyBjYXBhYmxlIG9mIHBy b3Zpc2lvbmluZw0KPiBzZXJ2aWNlIGNoYWlucywgb3IgY2hhcmdpbmcgc3lzdGVtcyBjYXBhYmxl IG9mIHR1cm5pbmcgdGhlbSBpbnRvDQo+IHJldmVudWUsIHlvdSBjYW4ndCBvZmZlciB0aGVtLg0K PiAgPg0KPiAgPiBUaGUgU0ZDIHdvcmtpbmcgZ3JvdXAgaXMgdGFza2VkIHdpdGggb25lIHBhcnQg b2YgdGhlIHdob2xlIHNlcnZpY2UNCj4gY2hhaW4gZGVmaW5pdGlvbiwgY29uc3RydWN0aW9uLCBh bmQgZGVwbG95bWVudCBwcm9ibGVtLiBBcyBJIHJlYWQgdGhlDQo+IGNoYXJ0ZXIsIGdlbmVyYWwg bG9hZCBiYWxhbmNpbmcgaXNzdWVzIGFyZSBub3QgcGFydCBvZiBvdXIgc2NvcGUuDQo+ICA+IEdp dmVuIHRoZSBudW1iZXIgb2YgZGlmZmVyZW50IHdheXMgdGhlcmUgYXJlIG9mIGRvaW5nIGxvYWQg YmFsYW5jaW5nLA0KPiBpdCB3b3VsZCBzdHJpa2UgbWUgYXMgdmVyeSBvZGQgZm9yIHRoZSBzZmMg d29ya2luZyBncm91cCB0byBzdGFuZGFyZGl6ZQ0KPiBhIHBhcnRpY3VsYXIgYW5zd2VyIHRvIHRo ZSBpbXBvcnRhbnQgYW5kIGRpZmZpY3VsdCBwcm9ibGVtIHlvdSBwb2ludCB0by4NCj4gID4NCj4g ID4gVGhlIGFyY2hpdGVjdHVyZSAoYW5kIEkgYmVsaWV2ZSBtb3N0IG9mIHRoZSBzb2x1dGlvbnMp IGlzIGRlc2lnbmVkIHRvDQo+IHByb3ZpZGUgdG9vbHMgdGhhdCBoZWxwIHdpdGggbWFuYWdpbmcg dGhhdCBzY2FsaW5nLCB3aGlsZSBhbHNvIGFsbG93aW5nDQo+IGZvciB0aGUgdXNlIG9mIG90aGVy IHRvb2xzLg0KPiAgPiBJZiB0aGUgd29ya2luZyBncm91cCB3YW50cyB1cyB0byBiZSBtb3JlIHNw ZWNpZmljIGluIHRoZSBsb2FkDQo+IGJhbGFuY2luZyBhcmNoaXRlY3R1cmUsIHRoZW4gaWYgdGhl IGNoYWlycyB0ZWxsIHVzIHRvIHdlIHdpbGwgYWRkIG1vcmUNCj4gc3BlY2lmaWMgdGV4dC4gSSB3 b3VsZCBiZSBzdXJwcmlzZWQgcGVyc29uYWxseSBpZiB3ZSBoYWQgYWdyZWVtZW50IG9uDQo+IHN1 Y2ggYSBnb2FsLCBvciBhZ3JlZW1lbnQgb24gaG93IHRvIGZpbGwgc3VjaCBhIGdvYWwuIEJ1dCBD YXJsb3MgYW5kIEkNCj4gd2lsbCBvZiBjb3Vyc2UgZG8gd2hhdCB0aGUgY2hhaXJzIHRlbGwgdXMg dGhlIFdHIHdhbnRzLg0KPiAgPg0KPiAgPiBZb3VycywNCj4gID4gSm9lbA0KPiAgPg0KPiAgPiBP biA3LzEwLzE0LCAxMjowMiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPiAgPj4gT25l IG9mIHRoZSBtYWluIHByb2JsZW1zIGluICJzZXJ2aWNlIGNoYWlucyIgaXMgaG93IHRvIGltcGxl bWVudCBhDQo+IHNlcnZpY2UgdGhhdCBpcyBjb25jZXB0dWFsbHkgb25lIGhvcCBidXQgc2NhbGVk IGhvcml6b250YWxseSBhcyAxMCBvcg0KPiAxMDAgZGlmZmVyZW50IFZNcy4NCj4gID4+IFNvLCBJ TU8sIGlmIHdlIGFyZSBub3QgYWRkcmVzc2luZyB0aGlzIHByb2JsZW0gdGhhbiB3aGF0IGFyZSB3 ZSBzb2x2aW5nLg0KPiAgPj4NCj4gID4+IE1hcmlhDQo+ICA+Pg0KPiAgPg0KPiAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPiBzZmMgbWFpbGlu ZyBsaXN0DQo+ICA+IHNmY0BpZXRmLm9yZw0KPiAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0 DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Thu Jul 10 13:14: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 A8DAE1A0409 for ; Thu, 10 Jul 2014 13:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 rQIE6DjPna44 for ; Thu, 10 Jul 2014 13:14:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A2C1A0416 for ; Thu, 10 Jul 2014 13:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35901; q=dns/txt; s=iport; t=1405023246; x=1406232846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jvQ66tkknooD8X6IY7kTgWMeA3eFF8F9OOkEkiz4ADE=; b=M9ltYMNqw0b/02GFZ3qTMuor6vT5HameZWx9MX3Giva8ZvH/lXCrNfaZ /7ilL1bFRi3Tf8RlylbhWSwQuZJnEwM9OYdy5gkyHOIHHot3WPm/A1RpS c3GCnxPpHgGD+8Jodn8qpOMuF4xUgYX4u2vCldxFnDq+4uN1M3oVoX6NQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAGHzvlOtJV2Z/2dsb2JhbABPCoJHR1KvRZF4AQmHQgGBDhZ1hAMBAQEEAQEBKjgJCxACAQgRAQMBASEBBgcnCxQDBggCBA4FG4gTAxENxngTBI0ZgU8vIwYEBgGDLYEWBZYgRoQai2OIMoND X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208,217";a="339174553" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jul 2014 20:13:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6AKDoEg005204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 20:13:50 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 15:13:49 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVg== Date: Thu, 10 Jul 2014 20:13:48 +0000 Message-ID: <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_479ABDBD55D94784A460E4BDBC6D5631ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TvIV1ocIPqhK_vYPq_aTtNkZyYg Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:14:10 -0000 --_000_479ABDBD55D94784A460E4BDBC6D5631ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make = the minor change: the path identifier can be used to derive the needed forw= arding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_479ABDBD55D94784A460E4BDBC6D5631ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

 <= /p>

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

 <= /p>

Maria

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

Lucy,

 

Overall I concur, as you say: a path ID drives the f= orwarding.  I=92d make the minor change: the path identifier can be us= ed to derive the needed forwarding and associated transport.

 

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse.  = By having a path identifier, the exact indirection that people seem to be a= sking for on this thread can be simply be implemented.  The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).  

 

Paul

 

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers

 

Re-,

 

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

 

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

 

Cheers,

Med

 

 

Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh@joelhalpern.= com<jmh@joelhalpern.com>
To: sfc@ietf.org&= lt;sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_479ABDBD55D94784A460E4BDBC6D5631ciscocom_-- From nobody Thu Jul 10 13: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 EE45F1A0409 for ; Thu, 10 Jul 2014 13:15:53 -0700 (PDT) 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_29=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 hKNKOahO7KWW for ; Thu, 10 Jul 2014 13:15:52 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EE41A02EF for ; Thu, 10 Jul 2014 13:15:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 4125B861461; Thu, 10 Jul 2014 13:15:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 8D2DC86145F; Thu, 10 Jul 2014 13:15:50 -0700 (PDT) Message-ID: <53BEF475.7050205@joelhalpern.com> Date: Thu, 10 Jul 2014 16:15:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Paul Quinn (paulq)" , Lucy yong References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Py1kxkfUze9crVg4s8_XHQ8dKzM Cc: "mohamed.boucadair@orange.com" , "sfc@ietf.org" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:15:54 -0000 The architecture allows a range of deployments, from 1 service path to 160000 service paths. I would hope that operators are prepared for the complexities if they choose to avoid any use of local load balancing and in stead provision 160,000 service paths. Yours, Joel On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > Paul, > > How many path identifiers there will be for a 4 hop service chain with > 20 instances at each hop? > > Maria > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq) > *Sent:* Thursday, July 10, 2014 3:03 PM > *To:* Lucy yong > *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; > mikebianc@aol.com > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > Lucy, > > Overall I concur, as you say: a path ID drives the forwarding. I’d make > the minor change: the path identifier can be used to derive the needed > forwarding and associated transport. > > It is _not_ the transport, but rather is used to simply identify the > service path (or graph) that packets must traverse. By having a path > identifier, the exact indirection that people seem to be asking for on > this thread can be simply be implemented. The path identifier provides > nothing more than a lookup, that lookup can result in a one or more > (equal or weighted) transport next hop(s). > > Paul > > On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: > > > > Agree. The arch. doc should not mandate only use of the service path > identifier to drive the forwarding actions. > > Lucy > > *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > Of*mohamed.boucadair@orange.com > *Sent:*Thursday, July 10, 2014 2:06 AM > *To:*mikebianc@aol.com ;jmh@joelhalpern.com > ;sfc@ietf.org > *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > > Re-, > > The merged draft calls out explicitly a service path identifier. I > object to use that identifier to derive forwarding actions. > > Requiring a SFC system to have the full knowledge of every available SFC > forwarding paths within an SFC-enabled domain is not required/justified > nor possible in various deployment contexts. > > SFC forwarding actions should rely on the piece of information that will > be present in all deployments: that is the one required to structure a > service chain. How that information is used to infer forwarding actions > is a solution-oriented discussion. > > Cheers, > > Med > > *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com > > *Envoyé :*mercredi 9 juillet 2014 22:03 > *À :*jmh@joelhalpern.com ;sfc@ietf.org > > *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > > Is anyone still questioning the difference between SF Chain and SF Path? > Other than clarifying the definition so that it's clear to those not > familiar with the draft, it seems that everyone agrees on these terms. > > To me, the one point that is still unclear is whether it is the intent > of this draft to ultimately specify what the ID of the SFC Header should > reference (the chain or the path), or if this draft simply intends to > leave that ambiguous, allowing other drafts to dictate the mechanisms > for forwarding based on chain or path and the choice of chain or path to > be negotiated in the control-plane. > > If the latter (ambiguous), then the draft would have require that both > SFP and SFC be supported (or make one required and the other optional) > to avoid some vendors only supporting SFP and others only supporting SFC. > > ------------------------------------------------------------------------ > > *From:*jmh@joelhalpern.com > > *To:*sfc@ietf.org> > *Sent:*Tuesday, July 8, 2014 > *Subject:*[sfc] Service Chains, Paths, and Load Balancers > > I have been trying to figure out how to clearly answer a number of > comments that have been made about the proposed merged archtiecture > draft. Assuming we can get working group agreement on the intent, we > will work to improve the wording so that readers who have not > participated in the WG discussion will understnd it the way the working > group intends. > > But what do we intend? I will try to explain my personal view, and see > if that helps. > > In this regard, it is important to keep in mind that what we are > defining is the data plane architecture. We are not attempting to > define the architecture for the entire solution for service chaining. > That would encompass OSS/BSS, various control and policy functions, > virtual machine and image management, and many other aspects. > > As a result there are many things which clearly need to exist in the > larger system, but which are dealt with above where we are functioning, > and are not directly required by the work we are doing. > > In order to get to service chain vs service path, as I understand them, > I need to first discuss load balancing. There are at least three > different ways that load balancing can and will interact with service > chaining. There probably are more. The point of the archtiecture is to > permit all of these, but not to mandate that any particular kind be used > in any solution. > > 1) Load balancing as a service provided to the end user. This is a > service function. It receives user packets, and modifies them (or marks > them, or ...) so as to choose an end user service instance to receive > the users packet. This is an important service function to be able to > include in service chaining. It's behavior may affect requirements on > how service chaining is done. But it has very little impact on the > archtiecture. From an architectural pe3rspective it is simply a service > function which may modify the underlying packet. > > 2) There is internal load balancing. That is, one can have what appears > to the service chaining architecture as a single point of contact for a > specific service function, but is actually delivered by a collection of > virtual or physical machines, possibly including one or several load > balancers (for example using VRRP-like techniques to share a MAC > address.) mostly, this is invisible to the service chaining data plane > mechanisms. It is likely that it is visible to various control > mechanisms, such as those responsible for scale-in, scale-out, and vm > instantiation. The architectural impact of permitting this is largely > that we need to be careful that our terminology does not lead readers to > think we are prohibiting it. > > 3) There can also be load balancing done by selecting packet paths for > the service chaining that direct traffic to different places. We would > not want to require that a given service function appear at only one > place in the network. > > It is of course the case that these may be combined. I tend to refer to > the collection of entities that appear to service chaining as a single > point as a cluster. Not because cluster is a good term. But because I > do not have another one. Thus, the point of type 3 load balancing is to > direct different subsets of traffic to different singular or clustered > service functions in different places in the network. > > Now with that said, what do I mean when I talk about service chain and > service path/ Service chain is a sequence of logical functions to be > applied to a subset of packets. It is equivalent of saying that some > subset of traffic is to get DPI, charging, content inspection, and > firewall while a different subset is to go directly to the cache without > visiting any other service functions. > > That is not enough information to direct the packets. A service path > is, in some fashion, a sequence of locations in the network. Those > locations will be singular or clustered service function delivery > locations. They may be addressed by IP address. They may be addressed > as ports on an SFF. There are many different ways that the locations > may be known to the service chaining infrastructure and the transport. > > >From the point of view of the work of the SFC group, we need to be able > to talk about the high level abstraction, the service chain, which > drives the forwarding. And we need to talk about the actual data path > packets will take in the network. > > Several of the comments have said "but the whole path may not be known > at the front." This architecture deals with that issue in two ways. > First, as noted in item (2) on load balancers above, there can be > decisions and behaviors which are invisible to the service chaining > mechanisms (in much the same way that bridging within a LAN is largely > invisible to routing between LANs.) The other provision we make is that > reclassification can be done in mid-chain when necessary. That will > direct packets to a new chain. Based on information available at the > re-classification point. > > I hope that this helps explain what we are after. If it does, and if > the intent is acceptable to the working group, we can figure out what > additional words are needed to convey this. > If the working group disagree with the intent, then we will of course > adjust to match the working group agreements. > If this is still unclear, I am not sure what to try next. > > Yours, > Joel > > _______________________________________________ > sfc mailing 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 Jul 10 13:18: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 63CE01B29A8 for ; Thu, 10 Jul 2014 13:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unJe5CzPLyMW for ; Thu, 10 Jul 2014 13:17:55 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737081ACD01 for ; Thu, 10 Jul 2014 13:17:54 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 2f4feb35.2abfd820c940.6300303.00-2485.17436458.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 20:17:54 +0000 (UTC) X-MXL-Hash: 53bef4f2063c29f8-8873c4bee2c6541b59f254b2973156f87de16aac Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id ee4feb35.0.6300253.00-2082.17436326.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 20:17:51 +0000 (UTC) X-MXL-Hash: 53bef4ef426ef9c0-d804d2e6932ac04f4ce5b0a62910ac295e559f9b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AKHo3B030051; Thu, 10 Jul 2014 16:17:50 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AKHftM029856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 16:17:44 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 20:17:34 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 16:17:34 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEYhAP//vVrw Date: Thu, 10 Jul 2014 20:17:33 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A68B@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> In-Reply-To: <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A68BMISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=AUd_NHdVA] X-AnalysisOut: [AAA:8 a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=UhQ7tS4aFR-JZ9SPPWYA:9 ] X-AnalysisOut: [a=wPNLvfGTeEIA:10 a=JfD0Fch1gWkA:10 a=chC_agHSu74A:10 a=oA] X-AnalysisOut: [XR_kdF8uMA:10 a=lZB815dzVvQA:10 a=U8Ie8EnqySEA:10 a=Hz7IrD] X-AnalysisOut: [YlS0cA:10 a=hPjdaMEvmhQA:10 a=nDvMGuRTSvtzK0E3:21 a=HoI1_v] X-AnalysisOut: [8_aNuLwGSM:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10 a=hokUKnOO6K74wHoG:21 a=d7ylvMho0H2wCbbV:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DvPCJmJU112zhEhBm9YYY7k9y2E Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:18:00 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A68BMISOUT7MSGUSRCF_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does it mean one path identifier? Maria From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, July 10, 2014 4:14 PM To: NAPIERALA, MARIA H Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@o= range.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I'd make th= e minor change: the path identifier can be used to derive the needed forwar= ding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A68BMISOUT7MSGUSRCF_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does it mean one path ide= ntifier?

 <= /p>

Maria

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Thursday, July 10, 2014 4:14 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.bouc= adair@orange.com; sfc@ietf.org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

1 assuming load is distributed among the 20 instance= s at each service hop.

Sent from my iPhone


On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

 <= /p>

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

 <= /p>

Maria

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= o:p>

 

Lucy,

 

Overall I concur, as you say: a path ID drives the f= orwarding.  I’d make the minor change: the path identifier can b= e used to derive the needed forwarding and associated transport.=

 

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse.  = By having a path identifier, the exact indirection that people seem to be a= sking for on this thread can be simply be implemented.  The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).  

 

Paul

 

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:




Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers

 

Re-,

 

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

 

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

 

Cheers,

Med

 

 

Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh@joelhalpern.= com<jmh@joelhalpern.com>
To: sfc@ietf.org&= lt;sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

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

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A68BMISOUT7MSGUSRCF_-- From nobody Thu Jul 10 13:23: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 E90E01B29B1 for ; Thu, 10 Jul 2014 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_22=0.6, 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 lO1k1gKDztKY for ; Thu, 10 Jul 2014 13:23:00 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228391B29AD for ; Thu, 10 Jul 2014 13:23:00 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so112844pde.40 for ; Thu, 10 Jul 2014 13:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=JdAhpTiMSJyr+UyNFjxd4FmxRrLNf5JE8v1BH059X2s=; b=BxRwJfh0YZx3JBipusjG2VzT0jRz1YRAXeISxhNN1Zsd9lSpMVGMR9ISipMeJ4sXPh VjMQvVuN+gg45UUlM20B0zLbTwWJOJJGvRHCmiPjInbCKBF6lAqTetv61oUjDjojhvIK p2uhpOpmxkHUBO4HWz/ugkQPZEg7gTXJ9hq/bWLc0Dx8cn/GRbLRLiPw2TXgNsP1tgiu +H+4ScuCG2D8Bt3cInVvthwata2W7IpilN7cVCWVitSQpk3WgjlTm5NK/yJNPer+ouwO WTJu7TDZKr7i9b1G+O/deopvMv7Up7UK6E+J+6FrACuK9bj4xaGqWdWai9EY/PSB+RVI Qkww== X-Received: by 10.68.57.144 with SMTP id i16mr680306pbq.48.1405023779702; Thu, 10 Jul 2014 13:22:59 -0700 (PDT) Received: from [192.168.1.6] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id mn2sm109314pbc.64.2014.07.10.13.22.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 13:22:58 -0700 (PDT) References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> <53BEEDC3.6000305@sce.carleton.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <53BEEDC3.6000305@sce.carleton.ca> Content-Type: multipart/alternative; boundary=Apple-Mail-24AB5023-04CB-4934-AF4F-90ABCDE683B9 Content-Transfer-Encoding: 7bit Message-Id: <5F9AFA04-5604-4E33-B0B1-09F8A24FA8B5@gmail.com> X-Mailer: iPad Mail (11D257) From: Sam Aldrin Date: Thu, 10 Jul 2014 13:22:56 -0700 To: "huang@sce.carleton.ca" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WniQojTt5EGgBKn-lfYL7_Z3GYA Cc: "sfc@ietf.org" Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:23:05 -0000 --Apple-Mail-24AB5023-04CB-4934-AF4F-90ABCDE683B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree . As SFC is established in a controlled domain, mitigating options a= re better than general internet. Again need to see how much of an overhead i= t really causes and it's side effects. Sam Sent from my iPad > On Jul 10, 2014, at 12:47 PM, Changcheng Huang wro= te: >=20 > Even the SFC is limited to a specific domain (such as a datacenter), the p= acket sizes still follow the same distribution. The bandwidth within a datac= enter is still a bottleneck part due to traffic patterns such as incast. >=20 > Chang >=20 >> On 07/10/2014 12:02 PM, Sam Aldrin wrote: >>=20 >>=20 >>> On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang wrote: >>> I am concerned with the overhead metadata may create. Internet packet si= zes tend to be bimodal where more than 50% of packets have very small packet= sizes. Carrying large amounts of overhead will reduce throughput significan= tly. Making metadata optional may be a good choice. >> Doesn't that depend only if the SFC spans across the internet? =20 >> Otherwise it (overhead) should be limited to SFC's domain, which may not s= pan across internet, no? >>=20 >> cheers >> -sam >>>=20 >>> Regards, >>>=20 >>> Chang >>>=20 >>>=20 >>>> On 07/10/2014 11:22 AM, Joel M. Halpern wrote: >>>> I look forward to seeing your draft. >>>>=20 >>>> One of the reasons I like including the metadata with the underlying pa= cket is that they then share fate. If the packet gets lost, the metadata di= sappears with it, which is frequently fine. And if the packet is probably d= elviered down the service path, then so is the metadata. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >>>>> Hello, >>>>>=20 >>>>> Metadata transport is a feature provided by SFC that needs some >>>>> additional thoughts as well. >>>>>=20 >>>>> B Rijsman has done a great job showing various option for Metadata >>>>> sharing. Still there are 2 aspects that I would like to address furthe= r >>>>>=20 >>>>> - Metadata representation >>>>>=20 >>>>> - Metadata transport reliability >>>>>=20 >>>>> We will probably post a draft on the subject, but this can be done aft= er >>>>> Toronto has started. So for those >>>>> interested to provide some feedback, here are some highlights. >>>>>=20 >>>>> *1. Problem Space* >>>>> * Metadata representation* >>>>> Metadata can be extremely varied in term of usage and content. It can >>>>> represent the result of Deep Packet Inspection (DPI) performed on the >>>>> traffic for example by the Classifier Service Function at the ingress o= f >>>>> the Service Function Chain. It can contain information collected about= >>>>> the end user such as a policy identifier, a category or even represent= >>>>> an event related to the end-user session. >>>>> This information can be used by Service Functions on the chain, as wel= l >>>>> as by monitoring entities responsible to track usage for example in th= e >>>>> Network Function Virtualization environment to feed a VNF manager or a= n >>>>> Orchestrator. >>>>> Metadata being information shared by many network entities needs some >>>>> means to be represented it in all of its dimensions: type definition, >>>>> encoding and scope. >>>>> * Metadata transport service* >>>>> As expected from service chain proposals, both NSH and SCH proposals >>>>> define some means to carry metadata between Service Functions in a >>>>> Chain. They can be classified as follow: >>>>> Dataplane Metadata: >>>>> are defined in the Service Function Chaining Problem Statement documen= t. >>>>> They are not considered to be part of the forwarding information of th= e >>>>> SFC header. However they are expected to carry the result of anteceden= t >>>>> classification, allowing Service Functions to take local policy >>>>> decisions based on their values. >>>>>=20 >>>>> As such, they could also be interpreted directly by Service Function >>>>> Forwarder to steer traffic to various Service Functions. >>>>> Offline Metadata: >>>>> Beyond Dataplane Metadata, Offline Metadata can be shared between >>>>> Service Functions in a chain, using out of band, congruent or not, or >>>>> hybrid models described in [RIJSMAN] >>>>>=20 >>>>> The hybrid model for example, defined in [RIJSMAN], utilizes the SFC >>>>> header to transport some key values for correlation purposes. These >>>>> Correlation Ids can be used by the Service Functions to recover the fu= ll >>>>> associated contextual information. >>>>> Metadata, directly or indirectly, are transported hop by hop along a >>>>> chain, in association to end-user traffic, the data payload of the SFC= >>>>> packets. >>>>> How these metadata are transported over a chain matters. Passing >>>>> metadata directly or indirectly along packets is a service that must b= e >>>>> analyzed from a reliability point of view. >>>>>=20 >>>>> Reliability requirements may vary depending on the nature of the >>>>> metadata transported. Past experience for example in Mobile Network an= d >>>>> data center with AAA Radius have shown that contextual information >>>>> replication to various service function was indeed sensitive to packet= >>>>> loss events, and that adhoc solutions had to be implemented to detect t= hem. >>>>> End to end TCP retransmission of packet lost does not ensure that >>>>> associated Metadata will be reinserted in retransmitted packet. In >>>>> addition, Event triggered metadata may have to be sent immediately on a= >>>>> chain even though no end-user traffic is being transmitted >>>>> Not all metadata needs a reliable transport. Repeated inline metadata >>>>> can be used to cover several use cases, and some metadata loss can be >>>>> acceptable. >>>>> Still, a reliable transport service for Metadata in SFC is expected. T= o >>>>> this effect, an implementation is suggested in Section 3.3 >>>>> *2. Metadata representation* >>>>> Metadata definition is that it provides contextual information about t= he >>>>> data packets which traverse a Service Function Chain. This must be >>>>> understood broadly. >>>>> Metadata can contain the result of traffic classification by Deep Pack= et >>>>> Inspection (DPI). For example as an Application Id information which i= s >>>>> tied to a traffic flow. There could be multiple flows with different >>>>> application ids, in a chain. >>>>> Metadata can also contain the result of DPI data extraction, such as >>>>> identify requested URL in HTTP. Such information can be passed to >>>>> certain SF down the chain such as a URL filtering function. >>>>> Metadata can contain some punctual event information collected at the >>>>> Ingress point of the chain and expected to be passed to all elements i= n >>>>> the chain. Here this information may be triggered externally and >>>>> generated only once, and be related to the tenant or the subscriber. >>>>> Metadata representation involves the definition of a set of informatio= n >>>>> elements types and the encoding rules for their values. >>>>> Metadata representation can sometimes be performed by a single >>>>> individual field with associated type and format. However, it is not >>>>> always enough. >>>>>=20 >>>>> * Metadata may need multiple fields transported together to >>>>> represented their values. >>>>> * Some addition fields may be required to describe the scope of the >>>>> metadata itself. This can be any information element allowing to >>>>> define the context of the associated metadata value. For example a= >>>>> throughput metadata field can have a port number and a switch >>>>> address as its Scope information. >>>>>=20 >>>>> We explore these two axis: encoding and scope. >>>>> We propose IPFIX as a preferred means to represent Metadata in Service= >>>>> Chain messages for Out-of-band, Congruent or not; Metadata sharing. >>>>> *2.1. Metadata Representation Requirements* >>>>> Mandatatory Dataplane Metadata is always part of the SFC header, it is= >>>>> thus reasonable to consider that its representation scheme will be >>>>> implicit: based on what the SFC protocol will dictate, their position i= n >>>>> the SFC header is sufficient for the receiving end to infer their type= >>>>> and encoding scheme. For example, Context Header Fields in NSH are 32 >>>>> bit fields. >>>>> However, it will not be the case for all metadata transported. Offline= >>>>> metadata, including congruent out-of-band metadata still need to be >>>>> represented explicitly. This section addresses their specific case. >>>>> *2.1.1. Metadata Encoding requirements* >>>>> These requirements are applicable to out-of-band metadata (Congruent o= r >>>>> not). It could be applicable with SCH on optional in-line metadata fie= lds. >>>>> For interoperability purposes, metadata encoding MUST allow the >>>>> receiving entity to identify the type and value of the information >>>>> received as metadata >>>>> Metadata encoding MUST allow for encoding techniques supporting well >>>>> known types and fields as well as proprietary extensions. >>>>> A receiving entity MUST be able to identify when incoming metadata typ= e >>>>> is unknown and MUST have a defined default action to handle it. >>>>> A piece of information may need multiple fields to be described. For >>>>> example a tenant id and an ip address can be used to identify an serve= r >>>>> in a data center uniquely. >>>>> These groups of information have to be exchanged collectively, in a >>>>> single message. In this case, a sending entity MUST specify that it is= >>>>> sending a set of metadata in a message. >>>>> This set of transported metadata elements MUST be specified under the >>>>> form of a metadata template document uniquely defined for the chain. >>>>> A receiving entity MUST be able to detect if an incoming message >>>>> contains its expected set of metadata elements. >>>>> *2.1.2. Metadata Scope requirement* >>>>> A piece of information may have to be qualified by some attributes >>>>> allowing to identify its particular scope. For example in a Gi >>>>> environment, the radio type in use may be used as a scoping criteria f= or >>>>> a jitter or latency measurement in a video traffic transported in a >>>>> particular service chaing. >>>>> Scope can apply to some individual metadata elements or to a set of >>>>> metadata elements. How a scope applies to a set of transported metadat= a >>>>> elements should be defined by a specification under the form of a >>>>> metadata template document uniquely identified for the chain. >>>>> *2.2. IPFIX Metadata representation* >>>>> So far, unordered sequences of Type Length Value encoded fields have >>>>> been proposed to transport metadata. It is not clear how structured >>>>> types are supported, and no distinction is done between the metadata >>>>> values and their scoping values. Although the SCH proposal provides an= >>>>> optional 24-bit Organizational Unique Identifier, there is no namespac= e >>>>> mechanism allowing to separate type definition spaces per Tenants or p= er >>>>> chain. >>>>> We suggest to leverage the work done by IETF on similar subject. >>>>> A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means f= or >>>>> transmitting Traffic Flow information over the network. In order to >>>>> transmit Traffic Flow information, it provides a common representation= >>>>> of flow data and a standard means of communicating them. >>>>> Metadata collected by Network Node and Service Node SHOULD be encoded i= n >>>>> template following the principles described in IPFIX[RFC7011]. >>>>> An IPFIX Message consisting of interleaved Template, Data, and Options= >>>>> Template Sets, as shown in Figure 1. Here, Template and Options Templa= te >>>>> Sets , which are optional, are shown. >>>>>=20 >>>>>=20 >>>>> +--------+--------------------------------------------------------+ >>>>> | | +----------+ +---------+ +-----------+ +---------+ |= >>>>> |Message | | Template | | Data | | Options | | Data | |= >>>>> | Header | | Set | | Set | ... | Template | | Set | |= >>>>> | | | | | | | Set | | | |= >>>>> | | +----------+ +---------+ +-----------+ +---------+ |= >>>>> +--------+--------------------------------------------------------+ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 1: IPFIX Message Format >>>>> The Template Set describes the data transmitted in the following Data >>>>> Set. It is an optional component of the message. The value of the >>>>> metadata is encoded in the first Data Set. This Data Set contains a >>>>> template Id field as a reference to its defining Template Set. >>>>> The Options Template Set describes the data to be transmitted as scope= >>>>> information. It is an optional component of the message. The value of >>>>> the scope information is encoded in the second Data Set element. It no= >>>>> scope information is present, then only the first Data Set is present i= n >>>>> the message. >>>>> The Option Template Set and following Data Set are used to describe th= e >>>>> scope of the metadata transmitted. For example, the metadata collected= >>>>> is relevant to a PDP Context or a particular line card of a particular= >>>>> switch. >>>>> * >>>>> * >>>>> *2.2.4.3. Example:* >>>>> The Metadata Exporting Process creates a Template Record with a few >>>>> Information Elements: amongst other things, the Application Id. For ex= ample: >>>>>=20 >>>>> - sourceIPv4Address (key field) >>>>> - destinationIPv4Address (key field) >>>>> - protocol (key field) >>>>> - destinationTransportPort (key field) >>>>> - applicationId (key field) >>>>> - octetTotalCount (non key field) >>>>>=20 >>>>> For example, a Flow Record corresponding to the above >>>>> Template Record may contain: >>>>>=20 >>>>> { sourceIPv4Address=3D192.0.2.1, >>>>> destinationIPv4Address=3D192.0.2.2, >>>>> protocol=3D17, >>>>> destinationTransportPort=3D23, >>>>> applicationId=3D'3..80', >>>>> octetTotalCount=3D123456 } >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The Options Data Record associated with the examples above would conta= in >>>>> the Scoping inforamtion: >>>>>=20 >>>>> Scope: >>>>> - servicePath, >>>>> - serviceIndex, >>>>> - applicationId, >>>>> - applicationName >>>>> - applicationDescription. >>>>>=20 >>>>> For example: >>>>>=20 >>>>> { >>>>> servicePath=3D0x000b, >>>>> serviceIndex=3D0x000c, >>>>> applicationId=3D'13...10000', >>>>> applicationName=3D"webex", >>>>> applicationDescription=3D"Webex application" } >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Scope information is useful when sending metadata offline, as it can >>>>> contain information related to the chain and possibly to the flow for >>>>> which this metadata record is relevant. Here servicePath and >>>>> serviceIndex are thus included in the Template. >>>>> *2.2.4.4. IPFIX encoding and template provisioning:* >>>>> IPFIX is a quite compact encoding >>>>> For a template defined as followed and shared by the SF in a chain. >>>>> IPFIX template record shared by SF: >>>>> Note that an XML representation of IPFIX template record could be >>>>> defined and used to provision Service Functions. >>>>>=20 >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Set ID =3D 2 | Length =3D 28 octets = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Template ID 256 | Field Count =3D 5 |= >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0| sourceIPv4Address =3D 8 | Field Length =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0| destinationIPv4Address =3D 12 | Field Length =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0| ipNextHopIPv4Address =3D 15 | Field Length =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0| packetDeltaCount =3D 2 | Field Length =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0| octetDeltaCount =3D 1 | Field Length =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>=20 >>>>>=20 >>>>> Figure 7: IPFIX Metadata template Encoding >>>>> An encoded IP fix transport message will be: >>>>>=20 >>>>>=20 >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Version Number | Length | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Export Time | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Sequence Number | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Observation Domain ID | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Set ID =3D 256 | Length =3D 64 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 192.0.2.12 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 192.0.2.254 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 192.0.2.1 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 5009 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 5344385 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 8: IPFIX Metadata Encoding >>>>> *3. Metadata transport service* >>>>> These different use cases for Metadata generate some requirements on t= he >>>>> reliability capabilities of the Metadata transport service they will >>>>> rely on. >>>>> De facto Service Function Chain proposals such as NSH and SCH define a= >>>>> mechanism for sharing information along the Chains. It is thus importa= nt >>>>> to define this transport service in term of reliability. >>>>> The primary focus of these proposal are the Metadata elements playing a= >>>>> role in the Service Function Chain deployment to apply policies on >>>>> incoming traffic at some relevant Service Functions. >>>>> For example, Network Orchestration is expected to be a significant >>>>> driver for deployment of Network Services. It relies on Service Level >>>>> abstractions such as Group Policies, Contracts and Services as an inpu= t >>>>> for the orchestration of Service Function Chains. Specific metadata >>>>> attributes such as L4-L7 fields are used as classification elements or= >>>>> filters to funnel packets into chains. >>>>> Service Functions may have other needs for Metadata, for example Event= >>>>> Based Metadata tied to some subscriber related state changes. The >>>>> complexity and length of these elements cannot be forseen as limited, >>>>> neither can be how critical it is that they are safely carried >>>>> throughout a chain. In the following Section we propose to take >>>>> avantage of Congruent Metadata Transport can be used, possibly reliabl= y, >>>>> to address these needs. >>>>> *3.1. Proposed Metadata transport mechanisms* >>>>> . >>>>> *3.1.3. Metadata transport analysis* >>>>> Both NSH and SCH proposals support both inbound and offline out-of-ban= d >>>>> metadata transport. >>>>>=20 >>>>> 1. In-band: the metadata can be included directly as a value in some o= f >>>>> the NSH Context Header Fields. It is the preferred transport model= >>>>> for SCH. >>>>>=20 >>>>> In such case, when a particular field is always set to the same >>>>> value for all packets transported by the chain instance, then the >>>>> metadata transport service is in effect reliable. >>>>>=20 >>>>> Similarly, all the packet for a particular flow (defined by its 5 >>>>> tupple), could receive the same metadata value. The metadata >>>>> transport service is also reliable, provided that the value is >>>>> understood to be attached to a flow. >>>>>=20 >>>>> The general case however, occurs when the metadata varies from >>>>> packet to packet in a flow. The value is then tied to a specific >>>>> packet. Here the transport service is not reliable. A retransmissi= on >>>>> of a particular packet would not necessarily lead it to carry the >>>>> same metadata value. >>>>> 2. Out-of-band: a reference for some metadata is sent along a packet s= o >>>>> that it can be used via an interaction with a controller entity. I= t >>>>> is the preferred model for NSH, but could also be used by SCH. >>>>>=20 >>>>> As for the in-band case, the metadata referred to indirectly can b= e >>>>> transmitted reliably, when its value remains the same for a chain o= r >>>>> a flow in a chain. a chain or a flow in a chain. >>>>>=20 >>>>> If however, the correlation Id passed changes over time, or if the= >>>>> Metadata itself cahanges then the correct Metadata may not be >>>>> efficiently retrieved by some Service Functions. >>>>>=20 >>>>> We can see that NSH and SCH do not address the need for a reliable >>>>> transport service for metadata, independantly of the reliability >>>>> characteristic of the transport service used for the data packets. >>>>> Conventions can be used as particular cases when some metadata pertain= s >>>>> to a specific chain or a flow in the chain, and when its value does no= t >>>>> change overtime. >>>>> Such conventions however are weak. They would suppose that some >>>>> mechanism exists to ensure/monitor that they are followed. And some >>>>> exceptions mechanism would be required to deal with error cases. >>>>> *3.2. Support for Congruent out-of-band transport service* >>>>> Congruent out-of-band metadata sharing can be required for some types o= f >>>>> Metadata exchanges. It has the advantage of clearly tying the metadata= >>>>> to the chain and not to a specific packet, and to avoid payload >>>>> fragmentation issues. >>>>> Up to draft 2, NSH did not allow for long inline metadata transport. >>>>> Four 32 bits context fields are reserved for that purpose, and seem be= st >>>>> suited for offline Metadata sharing, or to transport predefined policy= >>>>> identifiers. >>>>> NSH (since draf 3) as well as SCH could allow for metadata transport, >>>>> either tied to a packet or possibly tied to the chain, when used witho= ut >>>>> payload, as signaling messages. >>>>> SCH however stipulates that in case the Path Identifier and SF Index >>>>> fields shall be set to zero for transmit and ignored upon receipt, whe= n >>>>> the SCH packet will contain only metadata. So congruent out-of-band >>>>> metadata, transporting Metadata hop to hop to the various Service >>>>> Function in the chain, does not seem to be supported. >>>>> NSH supports inline variable size metadata. It does not mentions >>>>> explicitly that congruent out-of-band metadata can be used. >>>>> *3.3. Reliable transport service* >>>>> Some metadata will need a reliable transport service to be shared >>>>> inline, as well as offline. >>>>> A protocol SCTP provides such a service and has the interesting >>>>> characteristic to be packet based, as opposed to stream based like TCP= . >>>>> SCTP carries a sequence number and support retransmission and congesti= on >>>>> control. >>>>> Figure 12 shows how SCTP is used hop by hop between SFF in a chain to >>>>> transport Metadata reliably. >>>>>=20 >>>>> |1 ----- |n |21 ---- |2m >>>>> +---+---+ +---+---+ +-+---+ +--+-----+ >>>>> | SF#1 | |SF#n | |SF#i1| |SF#im | >>>>> | | | | | | | | >>>>> +---+---+ +---+---+ +--+--+ +--+--+--+ >>>>> : : : : : >>>>> : : : : : >>>>> \ / \ / >>>>> +-----------+ SCTP +--------+ SCTP +---------+ >>>>> -- >| Chain | <---> | SFF | <---> | SFF | ----> >>>>> |classifier | |Node-1 | | Node-i | >>>>> +-----------+ +----+---+ +----+--+-+ >>>>> \ | / >>>>> \ | SFC Encapsulation / >>>>> \ | / >>>>> ,........................................ >>>>> / \ >>>>> / \ >>>>> | Network | >>>>> \ / >>>>> \........................................./ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 12: SCTP for Reliable Metadata transport >>>>> SCTP SHOULD be used in the context of Congruent out of band for reliab= le >>>>> metadata sharing. >>>>> For reliable Metadata transport, the SFF along the chain MUST route th= e >>>>> metadata received over SCTP to the next SF in the chain. For this SCTP= >>>>> MUST be encapsulated in the SFC header. >>>>> The SFF MUST make the received metadata available to its SF.ti >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-24AB5023-04CB-4934-AF4F-90ABCDE683B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I agree . As SFC is established in a controlled domain, mitigating options are better than general internet. Again need to see how much of an overhead it really causes and it's side effects.

Sam

Sent from my iPad

On Jul 10, 2014, at 12:47 PM, Changcheng Huang <huang@sce.carleton.ca> wrote:

Even the SFC is limited to a specific domain (such as a datacenter), the packet sizes still follow the same distribution. The bandwidth within a datacenter is still a bottleneck part due to traffic patterns such as incast.

Chang

On 07/10/2014 12:02 PM, Sam Aldrin wrote:


On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang <huang@sce.carleton.ca> wrote:
I am concerned with the overhead metadata may create. Internet packet sizes tend to be bimodal where more than 50% of packets have very small packet sizes. Carrying large amounts of overhead will reduce throughput significantly. Making metadata optional may be a good choice.
Doesn't that depend only if the SFC spans across the internet?  
Otherwise it (overhead) should be limited to SFC's domain, which may not span across internet, no?

cheers
-sam

Regards,

Chang


On 07/10/2014 11:22 AM, Joel M. Halpern wrote:
I look forward to seeing your draft.

One of the reasons I like including the metadata with the underlying packet is that they then share fate.  If the packet gets lost, the metadata disappears with it, which is frequently fine.  And if the packet is probably delviered down the service path, then so is the metadata.

Yours,
Joel

On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote:
Hello,

Metadata transport is a feature provided by SFC that needs some
additional thoughts as well.

B Rijsman has done a great job showing various option for Metadata
sharing. Still there are 2 aspects that I would like to address further

- Metadata representation

- Metadata transport reliability

We will probably post a draft on the subject, but this can be done after
Toronto has started. So for those
interested to provide some feedback, here are some highlights.

*1. Problem Space*
* Metadata representation*
Metadata can be extremely varied in term of usage and content. It can
represent the result of Deep Packet Inspection (DPI) performed on the
traffic for example by the Classifier Service Function at the ingress of
the Service Function Chain. It can contain information collected about
the end user such as a policy identifier, a category or even represent
an event related to the end-user session.
This information can be used by Service Functions on the chain, as well
as by monitoring entities responsible to track usage for example in the
Network Function Virtualization environment to feed a VNF manager or an
Orchestrator.
Metadata being information shared by many network entities needs some
means to be represented it in all of its dimensions: type definition,
encoding and scope.
* Metadata transport service*
As expected from service chain proposals, both NSH and SCH proposals
define some means to carry metadata between Service Functions in a
Chain. They can be classified as follow:
Dataplane Metadata:
are defined in the Service Function Chaining Problem Statement document.
They are not considered to be part of the forwarding information of the
SFC header. However they are expected to carry the result of antecedent
classification, allowing Service Functions to take local policy
decisions based on their values.

As such, they could also be interpreted directly by Service Function
Forwarder to steer traffic to various Service Functions.
Offline Metadata:
Beyond Dataplane Metadata, Offline Metadata can be shared between
Service Functions in a chain, using out of band, congruent or not, or
hybrid models described in [RIJSMAN]

The hybrid model for example, defined in [RIJSMAN], utilizes the SFC
header to transport some key values for correlation purposes. These
Correlation Ids can be used by the Service Functions to recover the full
associated contextual information.
Metadata, directly or indirectly, are transported hop by hop along a
chain, in association to end-user traffic, the data payload of the SFC
packets.
How these metadata are transported over a chain matters. Passing
metadata directly or indirectly along packets is a service that must be
analyzed from a reliability point of view.

Reliability requirements may vary depending on the nature of the
metadata transported. Past experience for example in Mobile Network and
data center with AAA Radius have shown that contextual information
replication to various service function was indeed sensitive to packet
loss events, and that adhoc solutions had to be implemented to detect them.
End to end TCP retransmission of packet lost does not ensure that
associated Metadata will be reinserted in retransmitted packet. In
addition, Event triggered metadata may have to be sent immediately on a
chain even though no end-user traffic is being transmitted
Not all metadata needs a reliable transport. Repeated inline metadata
can be used to cover several use cases, and some metadata loss can be
acceptable.
Still, a reliable transport service for Metadata in SFC is expected. To
this effect, an implementation is suggested in Section 3.3
*2. Metadata representation*
Metadata definition is that it provides contextual information about the
data packets which traverse a Service Function Chain. This must be
understood broadly.
Metadata can contain the result of traffic classification by Deep Packet
Inspection (DPI). For example as an Application Id information which is
tied to a traffic flow. There could be multiple flows with different
application ids, in a chain.
Metadata can also contain the result of DPI data extraction, such as
identify requested URL in HTTP. Such information can be passed to
certain SF down the chain such as a URL filtering function.
Metadata can contain some punctual event information collected at the
Ingress point of the chain and expected to be passed to all elements in
the chain. Here this information may be triggered externally and
generated only once, and be related to the tenant or the subscriber.
Metadata representation involves the definition of a set of information
elements types and the encoding rules for their values.
Metadata representation can sometimes be performed by a single
individual field with associated type and format. However, it is not
always enough.

  * Metadata may need multiple fields transported together to
    represented their values.
  * Some addition fields may be required to describe the scope of the
    metadata itself. This can be any information element allowing to
    define the context of the associated metadata value. For example a
    throughput metadata field can have a port number and a switch
    address as its Scope information.

We explore these two axis: encoding and scope.
We propose IPFIX as a preferred means to represent Metadata in Service
Chain messages for Out-of-band, Congruent or not; Metadata sharing.
*2.1. Metadata Representation Requirements*
Mandatatory Dataplane Metadata is always part of the SFC header, it is
thus reasonable to consider that its representation scheme will be
implicit: based on what the SFC protocol will dictate, their position in
the SFC header is sufficient for the receiving end to infer their type
and encoding scheme. For example, Context Header Fields in NSH are 32
bit fields.
However, it will not be the case for all metadata transported. Offline
metadata, including congruent out-of-band metadata still need to be
represented explicitly. This section addresses their specific case.
*2.1.1. Metadata Encoding requirements*
These requirements are applicable to out-of-band metadata (Congruent or
not). It could be applicable with SCH on optional in-line metadata fields.
For interoperability purposes, metadata encoding MUST allow the
receiving entity to identify the type and value of the information
received as metadata
Metadata encoding MUST allow for encoding techniques supporting well
known types and fields as well as proprietary extensions.
A receiving entity MUST be able to identify when incoming metadata type
is unknown and MUST have a defined default action to handle it.
A piece of information may need multiple fields to be described. For
example a tenant id and an ip address can be used to identify an server
in a data center uniquely.
These groups of information have to be exchanged collectively, in a
single message. In this case, a sending entity MUST specify that it is
sending a set of metadata in a message.
This set of transported metadata elements MUST be specified under the
form of a metadata template document uniquely defined for the chain.
A receiving entity MUST be able to detect if an incoming message
contains its expected set of metadata elements.
*2.1.2. Metadata Scope requirement*
A piece of information may have to be qualified by some attributes
allowing to identify its particular scope. For example in a Gi
environment, the radio type in use may be used as a scoping criteria for
a jitter or latency measurement in a video traffic transported in a
particular service chaing.
Scope can apply to some individual metadata elements or to a set of
metadata elements. How a scope applies to a set of transported metadata
elements should be defined by a specification under the form of a
metadata template document uniquely identified for the chain.
*2.2. IPFIX Metadata representation*
So far, unordered sequences of Type Length Value encoded fields have
been proposed to transport metadata. It is not clear how structured
types are supported, and no distinction is done between the metadata
values and their scoping values. Although the SCH proposal provides an
optional 24-bit Organizational Unique Identifier, there is no namespace
mechanism allowing to separate type definition spaces per Tenants or per
chain.
We suggest to leverage the work done by IETF on similar subject.
A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for
transmitting Traffic Flow information over the network. In order to
transmit Traffic Flow information, it provides a common representation
of flow data and a standard means of communicating them.
Metadata collected by Network Node and Service Node SHOULD be encoded in
template following the principles described in IPFIX[RFC7011].
An IPFIX Message consisting of interleaved Template, Data, and Options
Template Sets, as shown in Figure 1. Here, Template and Options Template
Sets , which are optional, are shown.


+--------+--------------------------------------------------------+
    |        | +----------+ +---------+     +-----------+ +---------+ |
    |Message | | Template | | Data    |     | Options   | | Data    | |
    | Header | | Set      | | Set     | ... | Template  | | Set     | |
    |        | |          | |         |     | Set       | |         | |
    |        | +----------+ +---------+     +-----------+ +---------+ |
+--------+--------------------------------------------------------+



Figure 1: IPFIX Message Format
The Template Set describes the data transmitted in the following Data
Set. It is an optional component of the message. The value of the
metadata is encoded in the first Data Set. This Data Set contains a
template Id field as a reference to its defining Template Set.
The Options Template Set describes the data to be transmitted as scope
information. It is an optional component of the message. The value of
the scope information is encoded in the second Data Set element. It no
scope information is present, then only the first Data Set is present in
the message.
The Option Template Set and following Data Set are used to describe the
scope of the metadata transmitted. For example, the metadata collected
is relevant to a PDP Context or a particular line card of a particular
switch.
*
*
*2.2.4.3. Example:*
The Metadata Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application Id. For example:

         - sourceIPv4Address (key field)
         - destinationIPv4Address (key field)
         - protocol (key field)
         - destinationTransportPort (key field)
         - applicationId (key field)
         - octetTotalCount (non key field)

         For example, a Flow Record corresponding to the above
         Template Record may contain:

             { sourceIPv4Address=192.0.2.1,
               destinationIPv4Address=192.0.2.2,
               protocol=17,
               destinationTransportPort=23,
               applicationId='3..80',
               octetTotalCount=123456 }



The Options Data Record associated with the examples above would contain
the Scoping inforamtion:

      Scope:
              - servicePath,
              - serviceIndex,
              - applicationId,
              - applicationName
              - applicationDescription.

       For example:

             {
               servicePath=0x000b,
               serviceIndex=0x000c,
               applicationId='13...10000',
               applicationName="webex",
               applicationDescription="Webex application" }



Scope information is useful when sending metadata offline, as it can
contain information related to the chain and possibly to the flow for
which this metadata record is relevant. Here servicePath and
serviceIndex are thus included in the Template.
*2.2.4.4. IPFIX encoding and template provisioning:*
IPFIX is a quite compact encoding
For a template defined as followed and shared by the SF in a chain.
IPFIX template record shared by SF:
Note that an XML representation of IPFIX template record could be
defined and used to provision Service Functions.

  0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Set ID = 2            |      Length = 28 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Template ID 256         |       Field Count = 5         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    packetDeltaCount = 2     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    octetDeltaCount = 1      |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 7: IPFIX Metadata template Encoding
An encoded IP fix transport message will be:


    0                   1                   2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Version Number          | Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Export Time                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Observation Domain ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Set ID = 256         |          Length = 64          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.12                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.254                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.1                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5009                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5344385                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Figure 8: IPFIX Metadata Encoding
*3. Metadata transport service*
These different use cases for Metadata generate some requirements on the
reliability capabilities of the Metadata transport service they will
rely on.
De facto Service Function Chain proposals such as NSH and SCH define a
mechanism for sharing information along the Chains. It is thus important
to define this transport service in term of reliability.
The primary focus of these proposal are the Metadata elements playing a
role in the Service Function Chain deployment to apply policies on
incoming traffic at some relevant Service Functions.
For example, Network Orchestration is expected to be a significant
driver for deployment of Network Services. It relies on Service Level
abstractions such as Group Policies, Contracts and Services as an input
for the orchestration of Service Function Chains. Specific metadata
attributes such as L4-L7 fields are used as classification elements or
filters to funnel packets into chains.
Service Functions may have other needs for Metadata, for example Event
Based Metadata tied to some subscriber related state changes. The
complexity and length of these elements cannot be forseen as limited,
neither can be how critical it is that they are safely carried
throughout a chain. In  the following Section we propose to take
avantage of Congruent Metadata Transport can be used, possibly reliably,
to address these needs.
*3.1. Proposed Metadata transport mechanisms*
.
*3.1.3. Metadata transport analysis*
Both NSH and SCH proposals support both inbound and offline out-of-band
metadata transport.

 1. In-band: the metadata can be included directly as a value in some of
    the NSH Context Header Fields. It is the preferred transport model
    for SCH.

    In such case, when a particular field is always set to the same
    value for all packets transported by the chain instance, then the
    metadata transport service is in effect reliable.

    Similarly, all the packet for a particular flow (defined by its 5
    tupple), could receive the same metadata value. The metadata
    transport service is also reliable, provided that the value is
    understood to be attached to a flow.

    The general case however, occurs when the metadata varies from
    packet to packet in a flow. The value is then tied to a specific
    packet. Here the transport service is not reliable. A retransmission
    of a particular packet would not necessarily lead it to carry the
    same metadata value.
 2. Out-of-band: a reference for some metadata is sent along a packet so
    that it can be used via an interaction with a controller entity. It
    is the preferred model for NSH, but could also be used by SCH.

    As for the in-band case, the metadata referred to indirectly can be
    transmitted reliably, when its value remains the same for a chain or
    a flow in a chain. a chain or a flow in a chain.

    If however, the correlation Id passed changes over time, or if the
    Metadata itself cahanges then the correct Metadata may not be
    efficiently retrieved by some Service Functions.

We can see that NSH and SCH do not address the need for a reliable
transport service for metadata, independantly of the reliability
characteristic of the transport service used for the data packets.
Conventions can be used as particular cases when some metadata pertains
to a specific chain or a flow in the chain, and when its value does not
change overtime.
Such conventions however are weak. They would suppose that some
mechanism exists to ensure/monitor that they are followed. And some
exceptions mechanism would be required to deal with error cases.
*3.2. Support for Congruent out-of-band transport service*
Congruent out-of-band metadata sharing can be required for some types of
Metadata exchanges. It has the advantage of clearly tying the metadata
to the chain and not to a specific packet, and to avoid payload
fragmentation issues.
Up to draft 2, NSH did not allow for long inline metadata transport.
Four 32 bits context fields are reserved for that purpose, and seem best
suited for offline Metadata sharing, or to transport predefined policy
identifiers.
NSH (since draf 3) as well as SCH could allow for metadata transport,
either tied to a packet or possibly tied to the chain, when used without
payload, as signaling messages.
SCH however stipulates that in case the Path Identifier and SF Index
fields shall be set to zero for transmit and ignored upon receipt, when
the SCH packet will contain only metadata. So congruent out-of-band
metadata, transporting Metadata hop to hop to the various Service
Function in the chain, does not seem to be supported.
NSH supports inline variable size metadata. It does not mentions
explicitly that congruent out-of-band metadata can be used.
*3.3. Reliable transport service*
Some metadata will need a reliable transport service to be shared
inline, as well as offline.
A protocol SCTP provides such a service and has the interesting
characteristic to be packet based, as opposed to stream based like TCP.
SCTP carries a sequence number and support retransmission and congestion
control.
Figure 12 shows how SCTP is used hop by hop between SFF in a chain to
transport Metadata reliably.

                      |1  -----   |n        |21  ---- |2m
                    +---+---+   +---+---+   +-+---+   +--+-----+
                    | SF#1  |   |SF#n   |   |SF#i1|   |SF#im   |
                    |       |   |       |   |     |   |        |
                    +---+---+   +---+---+   +--+--+   +--+--+--+
                        :           :          :         :  :
                        :           :          :         :  :
                         \         /            \       /
     +-----------+ SCTP   +--------+    SCTP     +---------+
-- >| Chain     | <--->  | SFF    |    <--->    | SFF     | ---->
     |classifier |        |Node-1  |             | Node-i  |
     +-----------+        +----+---+             +----+--+-+
                   \           |                     /
                    \          | SFC Encapsulation  /
                     \         |                   /
                   ,........................................
                  /                                         \
                 /                                           \
                |                      Network                |
                 \                                           /
                  \........................................./



Figure 12: SCTP for Reliable Metadata transport
SCTP SHOULD be used in the context of Congruent out of band for reliable
metadata sharing.
For reliable Metadata transport, the SFF along the chain MUST route the
metadata received over SCTP to the next SF in the chain. For this SCTP
MUST be encapsulated in the SFC header.
     The SFF MUST make the received metadata available to its SF.ti


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


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


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



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

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--Apple-Mail-24AB5023-04CB-4934-AF4F-90ABCDE683B9-- From nobody Thu Jul 10 13:23: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 334881B29B1 for ; Thu, 10 Jul 2014 13:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 wvsTkp9pSsK0 for ; Thu, 10 Jul 2014 13:23:39 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED021B29A8 for ; Thu, 10 Jul 2014 13:23:39 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 5B9BE53FAE; Thu, 10 Jul 2014 13:21:49 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 13:21:49.349 -0700 x-echoworx-msg-id: 298dad9a-e90b-4e2d-93c2-1ff9361efc3d x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 28; Thu, 10 Jul 2014 13:21:49 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 3CE2D53FAE; Thu, 10 Jul 2014 13:21:49 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 13:23:38 -0700 From: Ron Parker To: "Joel M. Halpern" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgCAAEJogIAAEcsAgAACqYD//4zV7w== Date: Thu, 10 Jul 2014 20:23:37 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com>, <53BEF475.7050205@joelhalpern.com> In-Reply-To: <53BEF475.7050205@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-source-routing-agent: Processed Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/78IgjDwvjvRKDkbjka3kHr9ANoc Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:23:41 -0000 Let's take the case where front end load balancing does not occur. If you = assume that there needs to be a full end to end path identification before = the packet is progressed from the classifier, then there are indeed 160000 = permutations in this example. But, can't we question that assumption in ou= r architectural musings? Perhaps, in an alternate realization, the classi= fier had 2 distinct jobs -- select the abstract chain and then select one o= f 20 instances representing the first service function in the chain. The s= elected instance, once having completed its processing, knows the next abst= ract service function by way of the chain is and picks from one of the 20 i= nstances. And perhaps it was the SFF rather than the SFI that did this.=20 Ron > On Jul 10, 2014, at 4:16 PM, "Joel M. Halpern" wrot= e: >=20 > The architecture allows a range of deployments, from 1 service path to 16= 0000 service paths. I would hope that operators are prepared for the compl= exities if they choose to avoid any use of local load balancing and in stea= d provision 160,000 service paths. >=20 > Yours, > Joel >=20 >> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> Paul, >>=20 >> How many path identifiers there will be for a 4 hop service chain with >> 20 instances at each hop? >>=20 >> Maria >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paul= q) >> *Sent:* Thursday, July 10, 2014 3:03 PM >> *To:* Lucy yong >> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >> mikebianc@aol.com >> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Lucy, >>=20 >> Overall I concur, as you say: a path ID drives the forwarding. I=92d ma= ke >> the minor change: the path identifier can be used to derive the needed >> forwarding and associated transport. >>=20 >> It is _not_ the transport, but rather is used to simply identify the >> service path (or graph) that packets must traverse. By having a path >> identifier, the exact indirection that people seem to be asking for on >> this thread can be simply be implemented. The path identifier provides >> nothing more than a lookup, that lookup can result in a one or more >> (equal or weighted) transport next hop(s). >>=20 >> Paul >>=20 >> On Jul 10, 2014, at 11:04 AM, Lucy yong > > wrote: >>=20 >>=20 >>=20 >> Agree. The arch. doc should not mandate only use of the service path >> identifier to drive the forwarding actions. >>=20 >> Lucy >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> Of*mohamed.boucadair@orange.com >> *Sent:*Thursday, July 10, 2014 2:06 AM >> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >> ;sfc@ietf.org >> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Re-, >>=20 >> The merged draft calls out explicitly a service path identifier. I >> object to use that identifier to derive forwarding actions. >>=20 >> Requiring a SFC system to have the full knowledge of every available SFC >> forwarding paths within an SFC-enabled domain is not required/justified >> nor possible in various deployment contexts. >>=20 >> SFC forwarding actions should rely on the piece of information that will >> be present in all deployments: that is the one required to structure a >> service chain. How that information is used to infer forwarding actions >> is a solution-oriented discussion. >>=20 >> Cheers, >>=20 >> Med >>=20 >> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >> >> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 >> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.org >> >> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Is anyone still questioning the difference between SF Chain and SF Path? >> Other than clarifying the definition so that it's clear to those not >> familiar with the draft, it seems that everyone agrees on these terms. >>=20 >> To me, the one point that is still unclear is whether it is the intent >> of this draft to ultimately specify what the ID of the SFC Header should >> reference (the chain or the path), or if this draft simply intends to >> leave that ambiguous, allowing other drafts to dictate the mechanisms >> for forwarding based on chain or path and the choice of chain or path to >> be negotiated in the control-plane. >>=20 >> If the latter (ambiguous), then the draft would have require that both >> SFP and SFC be supported (or make one required and the other optional) >> to avoid some vendors only supporting SFP and others only supporting SFC= . >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:*jmh@joelhalpern.com> > >> *To:*sfc@ietf.org> >> *Sent:*Tuesday, July 8, 2014 >> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>=20 >> I have been trying to figure out how to clearly answer a number of >> comments that have been made about the proposed merged archtiecture >> draft. Assuming we can get working group agreement on the intent, we >> will work to improve the wording so that readers who have not >> participated in the WG discussion will understnd it the way the working >> group intends. >>=20 >> But what do we intend? I will try to explain my personal view, and see >> if that helps. >>=20 >> In this regard, it is important to keep in mind that what we are >> defining is the data plane architecture. We are not attempting to >> define the architecture for the entire solution for service chaining. >> That would encompass OSS/BSS, various control and policy functions, >> virtual machine and image management, and many other aspects. >>=20 >> As a result there are many things which clearly need to exist in the >> larger system, but which are dealt with above where we are functioning, >> and are not directly required by the work we are doing. >>=20 >> In order to get to service chain vs service path, as I understand them, >> I need to first discuss load balancing. There are at least three >> different ways that load balancing can and will interact with service >> chaining. There probably are more. The point of the archtiecture is to >> permit all of these, but not to mandate that any particular kind be used >> in any solution. >>=20 >> 1) Load balancing as a service provided to the end user. This is a >> service function. It receives user packets, and modifies them (or marks >> them, or ...) so as to choose an end user service instance to receive >> the users packet. This is an important service function to be able to >> include in service chaining. It's behavior may affect requirements on >> how service chaining is done. But it has very little impact on the >> archtiecture. From an architectural pe3rspective it is simply a service >> function which may modify the underlying packet. >>=20 >> 2) There is internal load balancing. That is, one can have what appears >> to the service chaining architecture as a single point of contact for a >> specific service function, but is actually delivered by a collection of >> virtual or physical machines, possibly including one or several load >> balancers (for example using VRRP-like techniques to share a MAC >> address.) mostly, this is invisible to the service chaining data plane >> mechanisms. It is likely that it is visible to various control >> mechanisms, such as those responsible for scale-in, scale-out, and vm >> instantiation. The architectural impact of permitting this is largely >> that we need to be careful that our terminology does not lead readers to >> think we are prohibiting it. >>=20 >> 3) There can also be load balancing done by selecting packet paths for >> the service chaining that direct traffic to different places. We would >> not want to require that a given service function appear at only one >> place in the network. >>=20 >> It is of course the case that these may be combined. I tend to refer to >> the collection of entities that appear to service chaining as a single >> point as a cluster. Not because cluster is a good term. But because I >> do not have another one. Thus, the point of type 3 load balancing is to >> direct different subsets of traffic to different singular or clustered >> service functions in different places in the network. >>=20 >> Now with that said, what do I mean when I talk about service chain and >> service path/ Service chain is a sequence of logical functions to be >> applied to a subset of packets. It is equivalent of saying that some >> subset of traffic is to get DPI, charging, content inspection, and >> firewall while a different subset is to go directly to the cache without >> visiting any other service functions. >>=20 >> That is not enough information to direct the packets. A service path >> is, in some fashion, a sequence of locations in the network. Those >> locations will be singular or clustered service function delivery >> locations. They may be addressed by IP address. They may be addressed >> as ports on an SFF. There are many different ways that the locations >> may be known to the service chaining infrastructure and the transport. >>=20 >> >From the point of view of the work of the SFC group, we need to be able >> to talk about the high level abstraction, the service chain, which >> drives the forwarding. And we need to talk about the actual data path >> packets will take in the network. >>=20 >> Several of the comments have said "but the whole path may not be known >> at the front." This architecture deals with that issue in two ways. >> First, as noted in item (2) on load balancers above, there can be >> decisions and behaviors which are invisible to the service chaining >> mechanisms (in much the same way that bridging within a LAN is largely >> invisible to routing between LANs.) The other provision we make is that >> reclassification can be done in mid-chain when necessary. That will >> direct packets to a new chain. Based on information available at the >> re-classification point. >>=20 >> I hope that this helps explain what we are after. If it does, and if >> the intent is acceptable to the working group, we can figure out what >> additional words are needed to convey this. >> If the working group disagree with the intent, then we will of course >> adjust to match the working group agreements. >> If this is still unclear, I am not sure what to try next. >>=20 >> Yours, >> Joel >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jul 10 13:26: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 F1EF31B29C4 for ; Thu, 10 Jul 2014 13:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Xjtg3EquD_mq for ; Thu, 10 Jul 2014 13:25:57 -0700 (PDT) Received: from omr-m07.mx.aol.com (omr-m07.mx.aol.com [64.12.143.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15171B29DF for ; Thu, 10 Jul 2014 13:25:37 -0700 (PDT) Received: from mtaout-mce01.mx.aol.com (mtaout-mce01.mx.aol.com [172.29.27.205]) by omr-m07.mx.aol.com (Outbound Mail Relay) with ESMTP id 77E5A70035479; Thu, 10 Jul 2014 16:25:36 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mce01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 0B0123800009D; Thu, 10 Jul 2014 16:25:36 -0400 (EDT) Date: Thu, 10 Jul 2014 16:25:35 -0400 From: "mikebianc@aol.com" To: huang@sce.carleton.ca, sfc@ietf.org Message-ID: <370437302.1567.1405023935852.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <53BEEFAE.6030301@sce.carleton.ca> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> <53BEEFAE.6030301@sce.carleton.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1566_1994050112.1405023935851" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405023936; bh=8vCp4m5ZdbJhiDf8ts1FLUXk/UsfPioc25mZH4qv4To=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=wWnpJv96NRcbJuvhhMn2a/bDlDjAKPK/+vkkjEamxzAI7lPGVk5Pd3uuCObC8TR/v AuwtVUi04MTKEj8hZCSSdJNa9xH9UfIwd4v24ENzahOm1HwrgJ0syKO55RiVSlMsme Po+fpFNJejHuVI5dagzjKlgeqUVQdrvgX1fBnCHs= x-aol-sid: 3039ac1d1bcd53bef6c06298 X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FKWZKse_5Y6DCxoKlZpr9udbksQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:26:03 -0000 ------=_Part_1566_1994050112.1405023935851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Perhaps we should reword that, then, to include a definition of Service Fun= ction Instance and make sure we are consistent when referring to these enti= ties.. =C2=A0Based on most of the comments I've seen, it seems to make a lo= t of sense to consider a Service Function more of an abstract entity that h= as one or more instances. =C2=A0An abstract Service Function with only a si= ngle instance might appear as overkill, however it would normalize much of = the conversation and allow for clearer discussions about what happens when = and where &c. >From the problem statement: > The term service function chaining is used to describe the definition and= instantiation of an ordered set of instances of such service functions, an= d the subsequent "steering" of traffic flows through those service function= s. seems to indicate that the instance is the thing that is being chained. =C2= =A0Of course, if the classifier only specifies chooses a chain ({SFn}) and = not a path ({SFIn}), relinquishing the decision of which instantiation to a= nother process, then there technically is never an actual completed "ordere= d set of instances" produced (because SFI(n) is only chosen sometime after = being delivered to SFI(n-1)) rendering the SFP an abstract-ish conceptual t= hing. Then again, it could be I've read too many of these today and my brain is n= ow full. From: huang@sce.carleton.ca To: Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 =20 As defined in the problem statement document, a service function is not a concept. Here is the quote from the document "A Service Function can be a virtual instance or be embedded in a physical network element." This means a service function is a virtual entity. =20 A virtual machine (VM), for example, can decide which process to run first. Similarly a service function can decide how a packet being processed and forwarded to the next service function hop. =20 Chang =20 =20 =20 On 07/10/2014 11:36 AM, Ron Parker wrote: =20 =20 =20 =20 =20 =20 =20 Hi, Mike. =20 Between service function and service function instance, I think it would have to be the instance, since the former is conceptual. But, in a distributed path selection approach, might it make sense to assign this duty to the service function forwarder (SFF)? =20 =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: Thursday, July 10, 2014 2:34 PM To: I.Smith@F5.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 =20 =20 =20 "Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."=20 =20 =20 =20 =20 =20 Is it service function that makes that decision? or the service function instance? =20 =20 =20 =20 =20 From: I.Smith@F5.com To: Changcheng Huang,'Ron Parker','Lucy yong',mohamed.boucadair@orange.com,mikebianc@aol.com,jmh@joelhalpern.= com,sfc@ietf.org Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers =20 >Service functions should make the decision about which instances will be used =20 I think it is sufficient for the architecture to say, =20 "Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path." =20 =20 But you also say need to say,=20 =20 "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path." =20 =20 and,=20 =20 "External orchestration frameworks MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path." =20 All three result in a Service Function Path being selected, and they aren't necessarily exclusive of one another if you have rules for resolving conflicts; the details of those rules are not architectural. =20 IMO, the architecture needs to err on the side of being descriptive over being proscriptive when there is a conflict between the two. =20 =20 =20 =20 =20 =20 =20 =20 =20 From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.carleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong';=20 mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; =20 sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 =20 I agree with Ron=E2=80=99s comments. Service functions sh= ould make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/d= oc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpful for this discussion. Chang =20 =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; =20 jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 It is architecturally significant to identify that multiple addressable instances of a service function are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed out by Joel. It is also architecturally significant to assign responsibility for instance selection. In particular, is the instance selection centralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities to achieve this? In November, 2013, after IETF 88, I submitted this draft, =20 http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner. That was just a proposal and I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2=80=99d li= ke to see the architecture describe things. It should be able to answer the question, =E2=80=9Chow does multi-instance selection work in SFC?=E2=80=9D in a con= cise manner. If the group feels that there should be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly. Of course, that is merely one such question and there are many others that an architectural document should be able to describe. Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mikebianc@aol.com;=20 jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions. Lucy =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com;=20 sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 Re-, The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.=20 Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion. Cheers, Med =20 =20 =20 De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers =20 =20 =20 Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms. =20 =20 To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.=20 =20 =20 If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC. =20 =20 =20 =20 =20 =20 From: jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers =20 I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. =20 But what do we intend? I will try to explain my personal view, and see=20 if that helps. =20 In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. =20 As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. =20 In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used=20 in any solution. =20 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. =20 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to=20 think we are prohibiting it. =20 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. =20 It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. =20 Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without=20 visiting any other service functions. =20 That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. =20 >From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. =20 Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. =20 I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. =20 Yours, Joel =20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 =20 =20 ------=_Part_1566_1994050112.1405023935851 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Perhaps we shou= ld reword that, then, to include a definition of Service Function Instance = and make sure we are consistent when referring to these entities..  Ba= sed on most of the comments I've seen, it seems to make a lot of sense to c= onsider a Service Function more of an abstract entity that has one or more = instances.  An abstract Service Function with only a single instance m= ight appear as overkill, however it would normalize much of the conversatio= n and allow for clearer discussions about what happens when and where &= c.
=
From the problem statement:
> The=
 term service function chaining is used to describe the definition and inst=
antiation of an ordered set of instances of such service functions, and the=
 subsequent "steering" of traffic flows through those service functions.
seems to indicate that the instance is the thing that is = being chained.  Of course, if the classifier only specifies chooses a = chain ({SFn}) and not a path ({SFIn}), relinquishing the decision of which = instantiation to another process, then there technically is never an actual= completed "ordered set of instances" produced (because SFI(n) is only chos= en sometime after being delivered to SFI(n-1)) rendering the SFP an abstrac= t-ish conceptual thing.

Then again, it could be I'= ve read too many of these today and my brain is now full.



From: hu= ang@sce.carleton.ca<huang@sce.carleton.ca>
To: <sfc@ietf= .org>
Sent: Thursday, July 10, 2014
Subject: Re: [sf= c] Service Chains, Paths, and Load Balancers

=20 =20 As defined in the problem statement document, a service function is not a concept. Here is the quote from the document "A Service Function can be a virtual instance or be embedded in a physical network element." This means a service function is a virtual entity.
A virtual machine (VM), for example, can decide which process to run first. Similarly a service function can decide how a packet being processed and forwarded to the next service function hop.

Chang

On 07/10/2014 11:36 AM, Ron Parker wrote:
=20

Hi, Mike.

Between service function and service function instance, I think it would have to be the instance, since the former is conceptual. But, in a distributed path selection approach, might it make sense to assign this duty to the service function forwarder (SFF)?

=20 Ron

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: Thursday, July 10, 2014 2:34 PM
To: I.Smith@F5.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

= Is it service function that makes that decision? or the service function instance?

<= /p>

From: = I.Smith@F5.com<I.Smith@F5.com>
To: Changcheng Huang<huang@sce.carleton.ca>,'Ron Parker'<Ron_Parker@affirmednetworks.com>,'Lucy yong'<lucy.yong@huawei.com>,mohamed.boucadair@orange.com<= /a><mohamed.boucadair@orange.com>,mikebianc@aol.com<mikebianc@aol.com>= ;,jmh@joelhalpern.com<jmh@joelhalpern.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't necessarily exclusive of one another if you have rules for resolving conflicts; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over being proscriptive when there is a conflict between the two.


From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I agree with Ron=E2=80=99s comments. Service functions sh= ould make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc= -use-case-recursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpful for this discussion.

Chang

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

It is architecturally significant to identify that multiple addressable instances of a service function are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed out by Joel. It is also architecturally significant to assign responsibility for instance selection. In particular, is the instance selection centralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities to achieve this? In November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner. That was just a proposal and I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=E2=80=99d li= ke to see the architecture describe things. It should be able to answer the question, =E2=80=9Chow does multi-instance selection work in SFC?=E2=80=9D in a con= cise manner. If the group feels that there should be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly. Of course, that is merely one such question and there are many others that an architectural document should be able to describe.

Ron

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange= .com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.<= /span>

Lucy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucada= ir@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.

Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.=

SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.

Cheers,

Med

De :<= /span> sfc [mailto:sfc-boun= ces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:0= 3
=C3=80 : jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.or= g>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/li= stinfo/sfc



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

=20 ------=_Part_1566_1994050112.1405023935851-- From nobody Thu Jul 10 13:28: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 304C21B29CE for ; Thu, 10 Jul 2014 13:28:44 -0700 (PDT) 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_29=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 frhMrrmn-Gsd for ; Thu, 10 Jul 2014 13:28:42 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5631B29C7 for ; Thu, 10 Jul 2014 13:28:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 47E57861549; Thu, 10 Jul 2014 13:28:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 79503861543; Thu, 10 Jul 2014 13:28:38 -0700 (PDT) Message-ID: <53BEF775.8040209@joelhalpern.com> Date: Thu, 10 Jul 2014 16:28:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com>, <53BEF475.7050205@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zDvrWCmK5xuoKpJkPxYjNwHns2w Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:28:44 -0000 Ron, I believe that the only difference in our descriptions is that you are drawing the service path as extending into the specific SFI that is selected by the local load balancing. This makes the description of the service path very confusing. Instead, the archtiecture document describes the service path as reaching to the SFF. The SFF delivers the packets to the instances. Those "instances", may be single instances, a load balanced set managed by the SFF in a fashion outside of our purview, or a (set of) load balancers and instances behind the SFF, again outside of our purview. The only requirement is tha tthe packet comes back to the service path cleanly, so the SFF can do its job (particularly if it is a proxy.) Thus, i believe we agree on what needs to be suppored, but not on the description for it. As I said in my previous note, this allows us to use 1 service path, with local load balancing. Or to couple that with global load distribution and multiple chains, either to subsets of those functions (giving 16 to 81 service paths) or absurdly fine grained global load distribution to 160,000 service paths. That is a deplyment call rather than an architecture call. Yours, Joel On 7/10/14, 4:23 PM, Ron Parker wrote: > Let's take the case where front end load balancing does not occur. If you assume that there needs to be a full end to end path identification before the packet is progressed from the classifier, then there are indeed 160000 permutations in this example. But, can't we question that assumption in our architectural musings? Perhaps, in an alternate realization, the classifier had 2 distinct jobs -- select the abstract chain and then select one of 20 instances representing the first service function in the chain. The selected instance, once having completed its processing, knows the next abstract service function by way of the chain is and picks from one of the 20 instances. And perhaps it was the SFF rather than the SFI that did this. > > Ron > > >> On Jul 10, 2014, at 4:16 PM, "Joel M. Halpern" wrote: >> >> The architecture allows a range of deployments, from 1 service path to 160000 service paths. I would hope that operators are prepared for the complexities if they choose to avoid any use of local load balancing and in stead provision 160,000 service paths. >> >> Yours, >> Joel >> >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>> Paul, >>> >>> How many path identifiers there will be for a 4 hop service chain with >>> 20 instances at each hop? >>> >>> Maria >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq) >>> *Sent:* Thursday, July 10, 2014 3:03 PM >>> *To:* Lucy yong >>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >>> mikebianc@aol.com >>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Lucy, >>> >>> Overall I concur, as you say: a path ID drives the forwarding. I’d make >>> the minor change: the path identifier can be used to derive the needed >>> forwarding and associated transport. >>> >>> It is _not_ the transport, but rather is used to simply identify the >>> service path (or graph) that packets must traverse. By having a path >>> identifier, the exact indirection that people seem to be asking for on >>> this thread can be simply be implemented. The path identifier provides >>> nothing more than a lookup, that lookup can result in a one or more >>> (equal or weighted) transport next hop(s). >>> >>> Paul >>> >>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> > wrote: >>> >>> >>> >>> Agree. The arch. doc should not mandate only use of the service path >>> identifier to drive the forwarding actions. >>> >>> Lucy >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>> Of*mohamed.boucadair@orange.com >>> *Sent:*Thursday, July 10, 2014 2:06 AM >>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >>> ;sfc@ietf.org >>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Re-, >>> >>> The merged draft calls out explicitly a service path identifier. I >>> object to use that identifier to derive forwarding actions. >>> >>> Requiring a SFC system to have the full knowledge of every available SFC >>> forwarding paths within an SFC-enabled domain is not required/justified >>> nor possible in various deployment contexts. >>> >>> SFC forwarding actions should rely on the piece of information that will >>> be present in all deployments: that is the one required to structure a >>> service chain. How that information is used to infer forwarding actions >>> is a solution-oriented discussion. >>> >>> Cheers, >>> >>> Med >>> >>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >>> >>> *Envoyé :*mercredi 9 juillet 2014 22:03 >>> *À :*jmh@joelhalpern.com ;sfc@ietf.org >>> >>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Is anyone still questioning the difference between SF Chain and SF Path? >>> Other than clarifying the definition so that it's clear to those not >>> familiar with the draft, it seems that everyone agrees on these terms. >>> >>> To me, the one point that is still unclear is whether it is the intent >>> of this draft to ultimately specify what the ID of the SFC Header should >>> reference (the chain or the path), or if this draft simply intends to >>> leave that ambiguous, allowing other drafts to dictate the mechanisms >>> for forwarding based on chain or path and the choice of chain or path to >>> be negotiated in the control-plane. >>> >>> If the latter (ambiguous), then the draft would have require that both >>> SFP and SFC be supported (or make one required and the other optional) >>> to avoid some vendors only supporting SFP and others only supporting SFC. >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*jmh@joelhalpern.com>> > >>> *To:*sfc@ietf.org> >>> *Sent:*Tuesday, July 8, 2014 >>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>> >>> I have been trying to figure out how to clearly answer a number of >>> comments that have been made about the proposed merged archtiecture >>> draft. Assuming we can get working group agreement on the intent, we >>> will work to improve the wording so that readers who have not >>> participated in the WG discussion will understnd it the way the working >>> group intends. >>> >>> But what do we intend? I will try to explain my personal view, and see >>> if that helps. >>> >>> In this regard, it is important to keep in mind that what we are >>> defining is the data plane architecture. We are not attempting to >>> define the architecture for the entire solution for service chaining. >>> That would encompass OSS/BSS, various control and policy functions, >>> virtual machine and image management, and many other aspects. >>> >>> As a result there are many things which clearly need to exist in the >>> larger system, but which are dealt with above where we are functioning, >>> and are not directly required by the work we are doing. >>> >>> In order to get to service chain vs service path, as I understand them, >>> I need to first discuss load balancing. There are at least three >>> different ways that load balancing can and will interact with service >>> chaining. There probably are more. The point of the archtiecture is to >>> permit all of these, but not to mandate that any particular kind be used >>> in any solution. >>> >>> 1) Load balancing as a service provided to the end user. This is a >>> service function. It receives user packets, and modifies them (or marks >>> them, or ...) so as to choose an end user service instance to receive >>> the users packet. This is an important service function to be able to >>> include in service chaining. It's behavior may affect requirements on >>> how service chaining is done. But it has very little impact on the >>> archtiecture. From an architectural pe3rspective it is simply a service >>> function which may modify the underlying packet. >>> >>> 2) There is internal load balancing. That is, one can have what appears >>> to the service chaining architecture as a single point of contact for a >>> specific service function, but is actually delivered by a collection of >>> virtual or physical machines, possibly including one or several load >>> balancers (for example using VRRP-like techniques to share a MAC >>> address.) mostly, this is invisible to the service chaining data plane >>> mechanisms. It is likely that it is visible to various control >>> mechanisms, such as those responsible for scale-in, scale-out, and vm >>> instantiation. The architectural impact of permitting this is largely >>> that we need to be careful that our terminology does not lead readers to >>> think we are prohibiting it. >>> >>> 3) There can also be load balancing done by selecting packet paths for >>> the service chaining that direct traffic to different places. We would >>> not want to require that a given service function appear at only one >>> place in the network. >>> >>> It is of course the case that these may be combined. I tend to refer to >>> the collection of entities that appear to service chaining as a single >>> point as a cluster. Not because cluster is a good term. But because I >>> do not have another one. Thus, the point of type 3 load balancing is to >>> direct different subsets of traffic to different singular or clustered >>> service functions in different places in the network. >>> >>> Now with that said, what do I mean when I talk about service chain and >>> service path/ Service chain is a sequence of logical functions to be >>> applied to a subset of packets. It is equivalent of saying that some >>> subset of traffic is to get DPI, charging, content inspection, and >>> firewall while a different subset is to go directly to the cache without >>> visiting any other service functions. >>> >>> That is not enough information to direct the packets. A service path >>> is, in some fashion, a sequence of locations in the network. Those >>> locations will be singular or clustered service function delivery >>> locations. They may be addressed by IP address. They may be addressed >>> as ports on an SFF. There are many different ways that the locations >>> may be known to the service chaining infrastructure and the transport. >>> >>> >From the point of view of the work of the SFC group, we need to be able >>> to talk about the high level abstraction, the service chain, which >>> drives the forwarding. And we need to talk about the actual data path >>> packets will take in the network. >>> >>> Several of the comments have said "but the whole path may not be known >>> at the front." This architecture deals with that issue in two ways. >>> First, as noted in item (2) on load balancers above, there can be >>> decisions and behaviors which are invisible to the service chaining >>> mechanisms (in much the same way that bridging within a LAN is largely >>> invisible to routing between LANs.) The other provision we make is that >>> reclassification can be done in mid-chain when necessary. That will >>> direct packets to a new chain. Based on information available at the >>> re-classification point. >>> >>> I hope that this helps explain what we are after. If it does, and if >>> the intent is acceptable to the working group, we can figure out what >>> additional words are needed to convey this. >>> If the working group disagree with the intent, then we will of course >>> adjust to match the working group agreements. >>> If this is still unclear, I am not sure what to try next. >>> >>> Yours, >>> Joel >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Jul 10 13:31: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 20F081B29E7 for ; Thu, 10 Jul 2014 13:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 kzC9HcApmjJn for ; Thu, 10 Jul 2014 13:31:44 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446F01B29E3 for ; Thu, 10 Jul 2014 13:31:41 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AKVc27015131 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 10 Jul 2014 16:31:40 -0400 Message-ID: <53BEF96A.4050808@sce.carleton.ca> Date: Thu, 10 Jul 2014 13:36:58 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> In-Reply-To: <53BEF475.7050205@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ec1p8-q_R6fPCDPbijs84yzQR4M Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:31:46 -0000 If you need to support 100 service chains, it will mean 16,000,000 paths. That is larger than the routing table of a core router. Chang On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > The architecture allows a range of deployments, from 1 service path to > 160000 service paths. I would hope that operators are prepared for > the complexities if they choose to avoid any use of local load > balancing and in stead provision 160,000 service paths. > > Yours, > Joel > > On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> Paul, >> >> How many path identifiers there will be for a 4 hop service chain with >> 20 instances at each hop? >> >> Maria >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >> (paulq) >> *Sent:* Thursday, July 10, 2014 3:03 PM >> *To:* Lucy yong >> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >> mikebianc@aol.com >> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Lucy, >> >> Overall I concur, as you say: a path ID drives the forwarding. I’d make >> the minor change: the path identifier can be used to derive the needed >> forwarding and associated transport. >> >> It is _not_ the transport, but rather is used to simply identify the >> service path (or graph) that packets must traverse. By having a path >> identifier, the exact indirection that people seem to be asking for on >> this thread can be simply be implemented. The path identifier provides >> nothing more than a lookup, that lookup can result in a one or more >> (equal or weighted) transport next hop(s). >> >> Paul >> >> On Jul 10, 2014, at 11:04 AM, Lucy yong > > wrote: >> >> >> >> Agree. The arch. doc should not mandate only use of the service path >> identifier to drive the forwarding actions. >> >> Lucy >> >> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> Of*mohamed.boucadair@orange.com >> *Sent:*Thursday, July 10, 2014 2:06 AM >> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >> ;sfc@ietf.org >> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Re-, >> >> The merged draft calls out explicitly a service path identifier. I >> object to use that identifier to derive forwarding actions. >> >> Requiring a SFC system to have the full knowledge of every available SFC >> forwarding paths within an SFC-enabled domain is not required/justified >> nor possible in various deployment contexts. >> >> SFC forwarding actions should rely on the piece of information that will >> be present in all deployments: that is the one required to structure a >> service chain. How that information is used to infer forwarding actions >> is a solution-oriented discussion. >> >> Cheers, >> >> Med >> >> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >> >> *Envoyé :*mercredi 9 juillet 2014 22:03 >> *À :*jmh@joelhalpern.com ;sfc@ietf.org >> >> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Is anyone still questioning the difference between SF Chain and SF Path? >> Other than clarifying the definition so that it's clear to those not >> familiar with the draft, it seems that everyone agrees on these terms. >> >> To me, the one point that is still unclear is whether it is the intent >> of this draft to ultimately specify what the ID of the SFC Header should >> reference (the chain or the path), or if this draft simply intends to >> leave that ambiguous, allowing other drafts to dictate the mechanisms >> for forwarding based on chain or path and the choice of chain or path to >> be negotiated in the control-plane. >> >> If the latter (ambiguous), then the draft would have require that both >> SFP and SFC be supported (or make one required and the other optional) >> to avoid some vendors only supporting SFP and others only supporting >> SFC. >> >> ------------------------------------------------------------------------ >> >> *From:*jmh@joelhalpern.com> > >> *To:*sfc@ietf.org> >> *Sent:*Tuesday, July 8, 2014 >> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >> >> I have been trying to figure out how to clearly answer a number of >> comments that have been made about the proposed merged archtiecture >> draft. Assuming we can get working group agreement on the intent, we >> will work to improve the wording so that readers who have not >> participated in the WG discussion will understnd it the way the working >> group intends. >> >> But what do we intend? I will try to explain my personal view, and see >> if that helps. >> >> In this regard, it is important to keep in mind that what we are >> defining is the data plane architecture. We are not attempting to >> define the architecture for the entire solution for service chaining. >> That would encompass OSS/BSS, various control and policy functions, >> virtual machine and image management, and many other aspects. >> >> As a result there are many things which clearly need to exist in the >> larger system, but which are dealt with above where we are functioning, >> and are not directly required by the work we are doing. >> >> In order to get to service chain vs service path, as I understand them, >> I need to first discuss load balancing. There are at least three >> different ways that load balancing can and will interact with service >> chaining. There probably are more. The point of the archtiecture is to >> permit all of these, but not to mandate that any particular kind be used >> in any solution. >> >> 1) Load balancing as a service provided to the end user. This is a >> service function. It receives user packets, and modifies them (or marks >> them, or ...) so as to choose an end user service instance to receive >> the users packet. This is an important service function to be able to >> include in service chaining. It's behavior may affect requirements on >> how service chaining is done. But it has very little impact on the >> archtiecture. From an architectural pe3rspective it is simply a service >> function which may modify the underlying packet. >> >> 2) There is internal load balancing. That is, one can have what appears >> to the service chaining architecture as a single point of contact for a >> specific service function, but is actually delivered by a collection of >> virtual or physical machines, possibly including one or several load >> balancers (for example using VRRP-like techniques to share a MAC >> address.) mostly, this is invisible to the service chaining data plane >> mechanisms. It is likely that it is visible to various control >> mechanisms, such as those responsible for scale-in, scale-out, and vm >> instantiation. The architectural impact of permitting this is largely >> that we need to be careful that our terminology does not lead readers to >> think we are prohibiting it. >> >> 3) There can also be load balancing done by selecting packet paths for >> the service chaining that direct traffic to different places. We would >> not want to require that a given service function appear at only one >> place in the network. >> >> It is of course the case that these may be combined. I tend to refer to >> the collection of entities that appear to service chaining as a single >> point as a cluster. Not because cluster is a good term. But because I >> do not have another one. Thus, the point of type 3 load balancing is to >> direct different subsets of traffic to different singular or clustered >> service functions in different places in the network. >> >> Now with that said, what do I mean when I talk about service chain and >> service path/ Service chain is a sequence of logical functions to be >> applied to a subset of packets. It is equivalent of saying that some >> subset of traffic is to get DPI, charging, content inspection, and >> firewall while a different subset is to go directly to the cache without >> visiting any other service functions. >> >> That is not enough information to direct the packets. A service path >> is, in some fashion, a sequence of locations in the network. Those >> locations will be singular or clustered service function delivery >> locations. They may be addressed by IP address. They may be addressed >> as ports on an SFF. There are many different ways that the locations >> may be known to the service chaining infrastructure and the transport. >> >> >From the point of view of the work of the SFC group, we need to be >> able >> to talk about the high level abstraction, the service chain, which >> drives the forwarding. And we need to talk about the actual data path >> packets will take in the network. >> >> Several of the comments have said "but the whole path may not be known >> at the front." This architecture deals with that issue in two ways. >> First, as noted in item (2) on load balancers above, there can be >> decisions and behaviors which are invisible to the service chaining >> mechanisms (in much the same way that bridging within a LAN is largely >> invisible to routing between LANs.) The other provision we make is that >> reclassification can be done in mid-chain when necessary. That will >> direct packets to a new chain. Based on information available at the >> re-classification point. >> >> I hope that this helps explain what we are after. If it does, and if >> the intent is acceptable to the working group, we can figure out what >> additional words are needed to convey this. >> If the working group disagree with the intent, then we will of course >> adjust to match the working group agreements. >> If this is still unclear, I am not sure what to try next. >> >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Jul 10 13:37: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 AD7D81B29E6 for ; Thu, 10 Jul 2014 13:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 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.651, 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 gGy5O_q0yNcP for ; Thu, 10 Jul 2014 13:37:09 -0700 (PDT) Received: from omr-d08.mx.aol.com (omr-d08.mx.aol.com [205.188.109.207]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6691A0343 for ; Thu, 10 Jul 2014 13:37:08 -0700 (PDT) Received: from mtaout-mba01.mx.aol.com (mtaout-mba01.mx.aol.com [172.26.133.109]) by omr-d08.mx.aol.com (Outbound Mail Relay) with ESMTP id F1256700028F6; Thu, 10 Jul 2014 16:37:07 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mba01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A7C76380000A2; Thu, 10 Jul 2014 16:37:07 -0400 (EDT) Date: Thu, 10 Jul 2014 16:37:07 -0400 From: "mikebianc@aol.com" To: Myo.Zarny@gs.com, jmh@joelhalpern.com, paulq@cisco.com Message-ID: <57502263.1561.1405024627090.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <53BEE324.5070709@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1560_1592951516.1405024627089" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405024627; bh=j/6JAVvZAm04iHTPXJc9xQFBOZgcRrp4C8lACXNBi5s=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ykis38fIUyKkLVaiZ22JSWRLQLgch8tQjY5v2iXEDxdeq/uH6lCHMQ21DnpVyEteL HsuHfirnu4G1Z0PXZlIxYWCU2Q0Q8o21ehzlTUWKsXXgQHorlNU5k2b68SJTYIGvXI 5DYuS8MtjfOQuNbnktIUeQe8lUzagLM1uTDugWt8= x-aol-sid: 3039ac1a856d53bef9734a1e X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gSJ2RpZ7PNbRZdAwZasYkSJ38sc Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:37:11 -0000 ------=_Part_1560_1592951516.1405024627089 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, Global Server Load Balancing is a very specific thing dealing with DN= S. =C2=A0That's why it's important to define the terms and then use them co= nsistently. I don't think that multiple tiers of load distribution changes anything ass= uming it all happens inside the SFC domain. =C2=A0 I was imagining that "lo= ad distribution" would be narrowly defined as the selection of an instance = of a service function. =C2=A0Anything outside of that definition would be l= oad balancing or whatever you feel like calling it and should be beyond the= scope of SFC. =C2=A0In the case of the chains of load balancers fronting s= ervice functions, the load balancer would be the SF in the chain and SFC wo= uld be unaware of what happens between that load balancer and the consuming= service. =C2=A0But that might be getting too much into use cases. From: Myo.Zarny@gs.com To: 'jmh@joelhalpern.com','mikebianc@aol.com','paulq@cisco.com' cc: 'sfc@ietf.org' Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Using the term load distribution to refer to load balancer selection will b= e lost to a lot of people. Many people call it global sever load balancing. Plus, there could be multiple layers of "load distribution" / LB selection.= Not just two. For example, select a region from a global pool; once the re= gion is selected, select a data center in that region; in that DC, which DC= LB instance to go to; and then we have the traditional LB which selects th= e end server. In sum, (1) path selection could happen at more than 2 different tiers; (2)= "load" isn't the only criterion in those selections. I see the rationale f= or wanting the differentiation but is load distribution the best term for i= t?=20 Regards, ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]Sent: Thursday, July 10, = 2014 03:01 PM Eastern Standard TimeTo: mikebianc@aol.com ; paulq@cisco.com Cc: sfc@ietf.org Subject:= Re: [sfc] Service Chains, Paths, and Load BalancersThe term "load distribu= tion" works for me. I agree that there is value in differentiating the fun= ctions, and using different words usually helps such differentiation.Yours,= JoelOn 7/10/14, 2:55 PM, mikebianc@aol.com wrote:> I've stated before that = I think we should differentiate between load> balancing and load distributi= on where load balancing refers to the> standard service function that we al= l know and love (outside of SFC) and> load distribution refers to the selec= tion of an SFI (i.e. Chain -> Path> mapping). Not using different terms to= distinguish between these leads> to confusion.>> e.g. a SF Chain* might ex= ist whose SFs consist only of load balancers.> =C2=A0 But you might still w= ant SFC* to distribute load to multiple load> balancer instances.>> *trying= to distinguish between SFC as "Service Function Chaining" and a> single "S= ervice Function Chain".>>>>>>>> -------------------------------------------= -----------------------------> *From: *paulq@cisco.com> *T= o: *Joel M. Halpern> *cc: *Jim Guichard> (jguichar),sfc@ietf.org,mohamed.boucadair@orange.com,Ron> Parker,N= APIERALA, MARIA H> *Sent: *Thursday, July 10, 2014> *Subjec= t: *Re: [sfc] Service Chains, Paths, and Load Balancers>> Joel,>> I concur.= The goal here is to address the issues associated with generic> service fu= nction deployment and should enable localized decisions such> as load balan= cing (perhaps more accurately load distribution). Clearly> we sound=E2=80= =99t codify how load distribution works.>> In order to enable load distribu= tion, for example, the right> abstractions been to be clearly defined in th= e architecture, a key one> bering the distinction between path vs. chain.>>= Paul>>>> On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote:>> > That is clearly an important problem in building a full solu= tion to> the service chaining needs of operators (e.g. you). However, I cou= ld> equally observe that if you do not have OSS/BSS capable of provisioning= > service chains, or charging systems capable of turning them into> revenue= , you can't offer them.> >> > The SFC working group is tasked with one pa= rt of the whole service> chain definition, construction, and deployment pro= blem. As I read the> charter, general load balancing issues are not part of= our scope.> > Given the number of different ways there are of doing load = balancing,> it would strike me as very odd for the sfc working group to sta= ndardize> a particular answer to the important and difficult problem you po= int to.> >> > The architecture (and I believe most of the solutions) is d= esigned to> provide tools that help with managing that scaling, while also = allowing> for the use of other tools.> > If the working group wants us to = be more specific in the load> balancing architecture, then if the chairs te= ll us to we will add more> specific text. I would be surprised personally i= f we had agreement on> such a goal, or agreement on how to fill such a goal= . But Carlos and I> will of course do what the chairs tell us the WG wants.= > >> > Yours,> > Joel> >> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H w= rote:> >> One of the main problems in "service chains" is how to implement= a> service that is conceptually one hop but scaled horizontally as 10 or> = 100 different VMs.> >> So, IMO, if we are not addressing this problem than= what are we solving.> >>> >> Maria> >>> >> > ________________________= _______________________> > sfc mailing list> > sfc@ietf.org> > https://w= ww.ietf.org/mailman/listinfo/sfc>> ________________________________________= _______> sfc mailing list> sfc@ietf.org> https://www.ietf.org/mailman/listi= nfo/sfc>>> _______________________________________________> sfc mailing lis= t> sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc>________________= _______________________________sfc mailing listsfc@ietf.orghttps://www.ietf= .org/mailman/listinfo/sfc ------=_Part_1560_1592951516.1405024627089 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Well, Global Se= rver Load Balancing is a very specific thing dealing with DNS.  That's= why it's important to define the terms and then use them consistently.

I don't think that multiple tiers of load distributio= n changes anything assuming it all happens inside the SFC domain.   I = was imagining that "load distribution" would be narrowly defined as the sel= ection of an instance of a service function.  Anything outside of that= definition would be load balancing or whatever you feel like calling it an= d should be beyond the scope of SFC.  In the case of the chains of loa= d balancers fronting service functions, the load balancer would be the SF i= n the chain and SFC would be unaware of what happens between that load bala= ncer and the consuming service.  But that might be getting too much in= to use cases.





From: Myo.Zarny@gs.com<Myo.Zarny@gs.c= om>
To: 'jmh@joelhalpern.com'<jmh@joelhalpern.com>,'mike= bianc@aol.com'<mikebianc@aol.com>,'paulq@cisco.com'<paulq@cisco.co= m>
cc: 'sfc@ietf.org'<sfc@ietf.org>
Sent: Thur= sday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and= Load Balancers

Using the term load distribution to r= efer to load balancer selection will be lost to a lot of people. Many peopl= e call it global sever load balancing.

Plus, there could be multiple= layers of "load distribution" / LB selection. Not just two. For example, s= elect a region from a global pool; once the region is selected, select a da= ta center in that region; in that DC, which DC LB instance to go to; and th= en we have the traditional LB which selects the end server.

In sum, = (1) path selection could happen at more than 2 different tiers; (2) "load" = isn't the only criterion in those selections. I see the rationale for wanti= ng the differentiation but is load distribution the best term for it?
<= br>Regards,



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


From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: T= hursday, July 10, 2014 03:01 PM Eastern Standard Time
To: mik= ebianc@aol.com <mikebianc@aol.com>; paulq@cisco.com <paulq@cisco.c= om>
Cc: sfc@ietf.org <sfc@ietf.org>
Su= bject: Re: [sfc] Service Chains, Paths, and Load Balancers
The term "load distribution" works for me. I agree that there= is value
in differentiating the functions, and using differ= ent words usually
helps such differentiation.
=
Yours,
Joel

On 7/= 10/14, 2:55 PM, mikebianc@aol.com wrote:
> I've stated bef= ore that I think we should differentiate between load
> ba= lancing and load distribution where load balancing refers to the
> standard service function that we all know and love (outside of = SFC) and
> load distribution refers to the selection of an= SFI (i.e. Chain -> Path
> mapping). Not using differe= nt terms to distinguish between these leads
> to confusion= .
>
> e.g. a SF Chain* might exist whose = SFs consist only of load balancers.
>   But you might= still want SFC* to distribute load to multiple load
> bal= ancer instances.
>
> *trying to distingui= sh between SFC as "Service Function Chaining" and a
> sing= le "Service Function Chain".
>
>
>
>
>
>
>
> --------------------------------------------= ----------------------------
> *From: *paulq@cisco.com<= paulq@cisco.com>
> *To: *Joel M. Halpern<jmh@joelhal= pern.com>
> *cc: *Jim Guichard
> (jgui= char)<jguichar@cisco.com>,sfc@ietf.org<sfc@ietf.org>,mohamed.bo= ucadair@orange.com<mohamed.boucadair@orange.com>,Ron
&g= t; Parker<Ron_Parker@affirmednetworks.com>,NAPIERALA, MARIA H<mn19= 21@att.com>
> *Sent: *Thursday, July 10, 2014
> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>
> Joel,
>
> I concur. The goal here is to address the issues associated with gene= ric
> service function deployment and should enable locali= zed decisions such
> as load balancing (perhaps more accur= ately load distribution). Clearly
> we sound=E2=80=99t cod= ify how load distribution works.
>
> In o= rder to enable load distribution, for example, the right
>= abstractions been to be clearly defined in the architecture, a key one
> bering the distinction between path vs. chain.
>
> Paul
>
>
>
> On Jul 10, 2014, at 12:08 PM, Joel M. Halpe= rn <jmh@joelhalpern.com> wrote:
>
>= > That is clearly an important problem in building a full solution to<= br class=3D"">> the service chaining needs of operators (e.g. you). Howe= ver, I could
> equally observe that if you do not have OSS= /BSS capable of provisioning
> service chains, or charging= systems capable of turning them into
> revenue, you can't= offer them.
> >
> > The SFC work= ing group is tasked with one part of the whole service
> c= hain definition, construction, and deployment problem. As I read the
> charter, general load balancing issues are not part of our sco= pe.
> > Given the number of different ways there are o= f doing load balancing,
> it would strike me as very odd f= or the sfc working group to standardize
> a particular ans= wer to the important and difficult problem you point to.
>= >
> > The architecture (and I believe most of the= solutions) is designed to
> provide tools that help with = managing that scaling, while also allowing
> for the use o= f other tools.
> > If the working group wants us to be= more specific in the load
> balancing architecture, then = if the chairs tell us to we will add more
> specific text.= I would be surprised personally if we had agreement on
> = such a goal, or agreement on how to fill such a goal. But Carlos and I
> will of course do what the chairs tell us the WG wants.
> >
> > Yours,
> &g= t; Joel
> >
> > On 7/10/14, 12:02= PM, NAPIERALA, MARIA H wrote:
> >> One of the main= problems in "service chains" is how to implement a
> serv= ice that is conceptually one hop but scaled horizontally as 10 or
> 100 different VMs.
> >> So, IMO, if we a= re not addressing this problem than what are we solving.
>= >>
> >> Maria
> >><= br class=3D"">> >
> > _________________________= ______________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org= /mailman/listinfo/sfc
>
> _______________= ________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/l= istinfo/sfc
>
>
> ______= _________________________________________
> sfc mailing li= st
> sfc@ietf.org
> https://www.ietf.org/= mailman/listinfo/sfc
>

______= _________________________________________
sfc mailing listsfc@ietf.org
https://www.ietf.org/mailman/listinf= o/sfc
------=_Part_1560_1592951516.1405024627089-- From nobody Thu Jul 10 13:39: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 3C78B1B29F4 for ; Thu, 10 Jul 2014 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 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.651, 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 kSZfGN3y-l3M for ; Thu, 10 Jul 2014 13:39:44 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEBA1B29E8 for ; Thu, 10 Jul 2014 13:39:43 -0700 (PDT) Received: from mtaout-aah01.mx.aol.com (mtaout-aah01.mx.aol.com [172.27.1.141]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id E68117029000A; Thu, 10 Jul 2014 16:39:42 -0400 (EDT) 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-aah01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9DD9D3800009D; Thu, 10 Jul 2014 16:39:42 -0400 (EDT) Date: Thu, 10 Jul 2014 16:39:42 -0400 From: "mikebianc@aol.com" To: Myo.Zarny@gs.com, jmh@joelhalpern.com, paulq@cisco.com Message-ID: <1916079416.1585.1405024782482.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: <53BEE324.5070709@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1584_523472904.1405024782481" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405024782; bh=fCXZr4JTQeN4GgBKGuBPAPhdlrljl+Ara9bnRqCfYXY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=QTY+MH0Jxa+/mlpsHUC54/CVKPkJ9FiEMhqFFJM2tQw+ZhkzO+PLb0wipJKyotUN7 cJ03Xrrpx6BdY4ZwQqzqVn8H7sVUNrQxgHqr9zmra/MSJGQDltYgTfM7vTPArKkY3i eeE947sV6wmmWPpidIpbehJfFqVLjdwJnsBXHee8= x-aol-sid: 3039ac1b018d53befa0e4379 X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DQ5BOARDIGaWmsq0Z0CiJaYf-bQ Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:39:47 -0000 ------=_Part_1584_523472904.1405024782481 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agree that maybe 'load distribution' isn't the best name. =C2=A0What is imp= ortant is that it is distinguished from load balancing (which is also a poo= r name). Maybe "Traffic Distribution' or 'Traffic Balancing' or do those names alrea= dy carry other significance? From: Myo.Zarny@gs.com To: 'jmh@joelhalpern.com','mikebianc@aol.com','paulq@cisco.com' cc: 'sfc@ietf.org' Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Using the term load distribution to refer to load balancer selection will b= e lost to a lot of people. Many people call it global sever load balancing. Plus, there could be multiple layers of "load distribution" / LB selection.= Not just two. For example, select a region from a global pool; once the re= gion is selected, select a data center in that region; in that DC, which DC= LB instance to go to; and then we have the traditional LB which selects th= e end server. In sum, (1) path selection could happen at more than 2 different tiers; (2)= "load" isn't the only criterion in those selections. I see the rationale f= or wanting the differentiation but is load distribution the best term for i= t?=20 Regards, ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]Sent: Thursday, July 10, = 2014 03:01 PM Eastern Standard TimeTo: mikebianc@aol.com ; paulq@cisco.com Cc: sfc@ietf.org Subject:= Re: [sfc] Service Chains, Paths, and Load BalancersThe term "load distribu= tion" works for me. I agree that there is value in differentiating the fun= ctions, and using different words usually helps such differentiation.Yours,= JoelOn 7/10/14, 2:55 PM, mikebianc@aol.com wrote:> I've stated before that = I think we should differentiate between load> balancing and load distributi= on where load balancing refers to the> standard service function that we al= l know and love (outside of SFC) and> load distribution refers to the selec= tion of an SFI (i.e. Chain -> Path> mapping). Not using different terms to= distinguish between these leads> to confusion.>> e.g. a SF Chain* might ex= ist whose SFs consist only of load balancers.> =C2=A0 But you might still w= ant SFC* to distribute load to multiple load> balancer instances.>> *trying= to distinguish between SFC as "Service Function Chaining" and a> single "S= ervice Function Chain".>>>>>>>> -------------------------------------------= -----------------------------> *From: *paulq@cisco.com> *T= o: *Joel M. Halpern> *cc: *Jim Guichard> (jguichar),sfc@ietf.org,mohamed.boucadair@orange.com,Ron> Parker,N= APIERALA, MARIA H> *Sent: *Thursday, July 10, 2014> *Subjec= t: *Re: [sfc] Service Chains, Paths, and Load Balancers>> Joel,>> I concur.= The goal here is to address the issues associated with generic> service fu= nction deployment and should enable localized decisions such> as load balan= cing (perhaps more accurately load distribution). Clearly> we sound=E2=80= =99t codify how load distribution works.>> In order to enable load distribu= tion, for example, the right> abstractions been to be clearly defined in th= e architecture, a key one> bering the distinction between path vs. chain.>>= Paul>>>> On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote:>> > That is clearly an important problem in building a full solu= tion to> the service chaining needs of operators (e.g. you). However, I cou= ld> equally observe that if you do not have OSS/BSS capable of provisioning= > service chains, or charging systems capable of turning them into> revenue= , you can't offer them.> >> > The SFC working group is tasked with one pa= rt of the whole service> chain definition, construction, and deployment pro= blem. As I read the> charter, general load balancing issues are not part of= our scope.> > Given the number of different ways there are of doing load = balancing,> it would strike me as very odd for the sfc working group to sta= ndardize> a particular answer to the important and difficult problem you po= int to.> >> > The architecture (and I believe most of the solutions) is d= esigned to> provide tools that help with managing that scaling, while also = allowing> for the use of other tools.> > If the working group wants us to = be more specific in the load> balancing architecture, then if the chairs te= ll us to we will add more> specific text. I would be surprised personally i= f we had agreement on> such a goal, or agreement on how to fill such a goal= . But Carlos and I> will of course do what the chairs tell us the WG wants.= > >> > Yours,> > Joel> >> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H w= rote:> >> One of the main problems in "service chains" is how to implement= a> service that is conceptually one hop but scaled horizontally as 10 or> = 100 different VMs.> >> So, IMO, if we are not addressing this problem than= what are we solving.> >>> >> Maria> >>> >> > ________________________= _______________________> > sfc mailing list> > sfc@ietf.org> > https://w= ww.ietf.org/mailman/listinfo/sfc>> ________________________________________= _______> sfc mailing list> sfc@ietf.org> https://www.ietf.org/mailman/listi= nfo/sfc>>> _______________________________________________> sfc mailing lis= t> sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc>________________= _______________________________sfc mailing listsfc@ietf.orghttps://www.ietf= .org/mailman/listinfo/sfc ------=_Part_1584_523472904.1405024782481 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agree that mayb= e 'load distribution' isn't the best name.  What is important is that = it is distinguished from load balancing (which is also a poor name).
<= div>
Maybe "Traffic Distribution' or 'Traffic Balancing' or d= o those names already carry other significance?





From: = Myo.Zarny@gs.com<Myo.Zarny@gs.com>
To: 'jmh@joelhalpern.com= '<jmh@joelhalpern.com>,'mikebianc@aol.com'<mikebianc@aol.com>,'= paulq@cisco.com'<paulq@cisco.com>
cc: 'sfc@ietf.org'<sfc= @ietf.org>
Sent: Thursday, July 10, 2014
Subject: Re= : [sfc] Service Chains, Paths, and Load Balancers

Usi= ng the term load distribution to refer to load balancer selection will be l= ost to a lot of people. Many people call it global sever load balancing.
Plus, there could be multiple layers of "load distribution" / LB selec= tion. Not just two. For example, select a region from a global pool; once t= he region is selected, select a data center in that region; in that DC, whi= ch DC LB instance to go to; and then we have the traditional LB which selec= ts the end server.

In sum, (1) path selection could happen at more t= han 2 different tiers; (2) "load" isn't the only criterion in those selecti= ons. I see the rationale for wanting the differentiation but is load distri= bution the best term for it?

Regards,



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


From: Joel M. Halpern [mailto:jmh@joel= halpern.com]
Sent: Thursday, July 10, 2014 03:01 PM Eastern S= tandard Time
To: mikebianc@aol.com <mikebianc@aol.com>;= paulq@cisco.com <paulq@cisco.com>
Cc: sfc@ietf.org <= ;sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, a= nd Load Balancers

The term "load distribution"= works for me. I agree that there is value
in differentiati= ng the functions, and using different words usually
helps su= ch differentiation.

Yours,
Joel<= br class=3D"">
On 7/10/14, 2:55 PM, mikebianc@aol.com wrote:<= br class=3D"">> I've stated before that I think we should differentiate = between load
> balancing and load distribution where load = balancing refers to the
> standard service function that w= e all know and love (outside of SFC) and
> load distributi= on refers to the selection of an SFI (i.e. Chain -> Path
&= gt; mapping). Not using different terms to distinguish between these leads=
> to confusion.
>
> e.g= . a SF Chain* might exist whose SFs consist only of load balancers.
>   But you might still want SFC* to distribute load to mult= iple load
> balancer instances.
>
> *trying to distinguish between SFC as "Service Function Chainin= g" and a
> single "Service Function Chain".
= >
>
>
>
>
>
>
> ------------= ------------------------------------------------------------
= > *From: *paulq@cisco.com<paulq@cisco.com>
> *To:= *Joel M. Halpern<jmh@joelhalpern.com>
> *cc: *Jim G= uichard
> (jguichar)<jguichar@cisco.com>,sfc@ietf.or= g<sfc@ietf.org>,mohamed.boucadair@orange.com<mohamed.boucadair@ora= nge.com>,Ron
> Parker<Ron_Parker@affirmednetworks.co= m>,NAPIERALA, MARIA H<mn1921@att.com>
> *Sent: *T= hursday, July 10, 2014
> *Subject: *Re: [sfc] Service Chai= ns, Paths, and Load Balancers
>
> Joel,>
> I concur. The goal here is to address = the issues associated with generic
> service function depl= oyment and should enable localized decisions such
> as loa= d balancing (perhaps more accurately load distribution). Clearly
> we sound=E2=80=99t codify how load distribution works.
>
> In order to enable load distribution, for exa= mple, the right
> abstractions been to be clearly defined = in the architecture, a key one
> bering the distinction be= tween path vs. chain.
>
> Paul
>
>
>
> On Jul = 10, 2014, at 12:08 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:>
> > That is clearly an important pro= blem in building a full solution to
> the service chaining= needs of operators (e.g. you). However, I could
> equally= observe that if you do not have OSS/BSS capable of provisioning
> service chains, or charging systems capable of turning them into=
> revenue, you can't offer them.
> >=
> > The SFC working group is tasked with one part of = the whole service
> chain definition, construction, and de= ployment problem. As I read the
> charter, general load ba= lancing issues are not part of our scope.
> > Given th= e number of different ways there are of doing load balancing,
> it would strike me as very odd for the sfc working group to standardi= ze
> a particular answer to the important and difficult pr= oblem you point to.
> >
> > The a= rchitecture (and I believe most of the solutions) is designed to
> provide tools that help with managing that scaling, while also a= llowing
> for the use of other tools.
> = > If the working group wants us to be more specific in the load
> balancing architecture, then if the chairs tell us to we will ad= d more
> specific text. I would be surprised personally if= we had agreement on
> such a goal, or agreement on how to= fill such a goal. But Carlos and I
> will of course do wh= at the chairs tell us the WG wants.
> >
= > > Yours,
> > Joel
> >> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote:
> >> One of the main problems in "service chains" is ho= w to implement a
> service that is conceptually one hop bu= t scaled horizontally as 10 or
> 100 different VMs.
> >> So, IMO, if we are not addressing this problem than = what are we solving.
> >>
> >&= gt; Maria
> >>
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
&g= t;
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>
> ____________________________________________= ___
> sfc mailing 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_1584_523472904.1405024782481-- From nobody Thu Jul 10 13:40: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 BC9EA1B29FE for ; Thu, 10 Jul 2014 13:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.051 X-Spam-Level: X-Spam-Status: No, score=-7.051 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 j8EvJ-h8cxoP for ; Thu, 10 Jul 2014 13:40:16 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C481B29F9 for ; Thu, 10 Jul 2014 13:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405024812; x=1436560812; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NGNE6x20IYvhGwt9lwu4CX2yLNzUFXqp5cuAR8WpIM4=; b=wJd+KyDLieT8+c/HidZOYmrKre6lTu6/Hje+yULxPhhU1Lze7f+A7ci4 f0DJRFQsUcxnVBlcqNVeKVaL5Om2WPK2BYDgrsw+soxUVGUuJYUGrPvCg JtkQmM56AX6vRfHbISnxo60YTKxjjPHLNiFmq4o74/60bsfbEqRR8eWEz s=; X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208,217";a="121417083" X-IPAS-Result: AhMFAHj5vlPAqArr/2dsb2JhbABPCoJHgRlarmuQIYE/GAELh0ABgSR1hAMBAQEBAgEBAQEXAUoJEAsCAQgRAQMBAQsWAQYHJwsUAwYIAgQBEggTiBMDCRXGQBeNGYFPJQYnBgoBAoMrgRYFhhuQBUaFYoobi3VsAYFD Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 20:40:10 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 13:40:10 -0700 From: Ian Smith To: "mikebianc@aol.com" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAABCUAgAAT/YD//4+pKIAAkqoAgAAAwgCAABXzAIAACG2A//+ObjY= Date: Thu, 10 Jul 2014 20:40:09 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C43F@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> <53BEEFAE.6030301@sce.carleton.ca>, <370437302.1567.1405023935852.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <370437302.1567.1405023935852.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83C43FSEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/syjs09lKxvPirS3bj_Bb_NMGlnk Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:40:25 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83C43FSEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable agreed. ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of mikebianc@aol.com [mikebianc@= aol.com] Sent: Thursday, July 10, 2014 4:25 PM To: huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Perhaps we should reword that, then, to include a definition of Service Fun= ction Instance and make sure we are consistent when referring to these enti= ties.. Based on most of the comments I've seen, it seems to make a lot of = sense to consider a Service Function more of an abstract entity that has on= e or more instances. An abstract Service Function with only a single insta= nce might appear as overkill, however it would normalize much of the conver= sation and allow for clearer discussions about what happens when and where = &c. >From the problem statement: > The term service function chaining is used to describe the definition and= instantiation of an ordered set of instances of such service functions, an= d the subsequent "steering" of traffic flows through those service function= s. seems to indicate that the instance is the thing that is being chained. Of= course, if the classifier only specifies chooses a chain ({SFn}) and not a= path ({SFIn}), relinquishing the decision of which instantiation to anothe= r process, then there technically is never an actual completed "ordered set= of instances" produced (because SFI(n) is only chosen sometime after being= delivered to SFI(n-1)) rendering the SFP an abstract-ish conceptual thing. Then again, it could be I've read too many of these today and my brain is n= ow full. ________________________________ From: huang@sce.carleton.ca To: Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers As defined in the problem statement document, a service function is not a c= oncept. Here is the quote from the document "A Service Function can be a vi= rtual instance or be embedded in a physical network element." This means a = service function is a virtual entity. A virtual machine (VM), for example, can decide which process to run first.= Similarly a service function can decide how a packet being processed and f= orwarded to the next service function hop. Chang On 07/10/2014 11:36 AM, Ron Parker wrote: Hi, Mike. Between service function and service function instance, I think it would ha= ve to be the instance, since the former is conceptual. But, in a distribute= d path selection approach, might it make sense to assign this duty to the s= ervice function forwarder (SFF)? Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: Thursday, July 10, 2014 2:34 PM To: I.Smith@F5.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." Is it service function that makes that decision? or the service function in= stance? ________________________________ From: I.Smith@F5.com= > To: Changcheng Huang>,'= Ron Parker'>,'Lucy yong'>,mo= hamed.boucadair@orange.com>,mikebianc@aol.com>,jmh@j= oelhalpern.com>,sfc@ietf.org> Sent: Thursday, July 10, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >Service functions should make the decision about which instances will be u= sed I think it is sufficient for the architecture to say, "Service Functions MAY make the decision about which Service Function Insta= nces will be used when selecting the Service Function Path." But you also say need to say, "Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY m= ake the decision about which Service Function Instances will be used when s= electing the Service Function Path." and, "External orchestration frameworks MAY make the decision about which Servic= e Function Instances will be used when selecting the Service Function Path.= " All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural. IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two. ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of = Changcheng Huang [huang@sce.carleton.ca] Sent: Thursday, July 10, 2014 12:31 PM To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joe= lhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I agree with Ron=92s comments. Service functions should make the decision a= bout which instances will be used. It can be different hop-by-hop (e.g. in = a tree topology). In order to do so, it is important a physical network mak= es a service function chain aware of the available instances. These is no n= eed to identify each possible SFP by a physical network. If a service funct= ion chain wants to use multiple SFPs, it should provide the identifier for = each flow that uses a particular SFP and the corresponding forwarding rules= (i.e. next hop). Nevertheless, because a physical network need to support = multiple tenants, it does need to identify different tenants. Our recent co= ntribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recur= sive-service/ ) has discussed this issue in a more general architecture. Ho= pe it can be helpful for this discussion. Chang From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, July 10, 2014 8:20 AM To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers It is architecturally significant to identify that multiple addressable ins= tances of a service function are explicitly allowed. Whether those instance= perform some further level of load balancing is irrelevant, as has been po= inted out by Joel. It is also architecturally significant to assign respons= ibility for instance selection. In particular, is the instance selection ce= ntralized, distributed, or some combination? Which functional entities in t= he architecture have what responsibilities to achieve this? In November, 20= 13, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft= -parker-sfc-chain-to-path-00, which proposed that the instance selection wa= s made hop by hop by the service functions themselves, in a fully distribut= ed manner. That was just a proposal and I am not wedded to it, by any means= . Joel asked about specificity and it is at this level that I=92d like to s= ee the architecture describe things. It should be able to answer the questi= on, =93how does multi-instance selection work in SFC?=94 in a concise manne= r. If the group feels that there should be more than one answer to that que= stion, so be it, but we should be able to describe the high level mechanism= and rationale for each succinctly. Of course, that is merely one such ques= tion and there are many others that an architectural document should be abl= e to describe. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Thursday, July 10, 2014 11:05 AM To: mohamed.boucadair@orange.com; mike= bianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A83C43FSEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
agreed.


From: sfc [sfc-bounces@ietf.org] on behalf= of mikebianc@aol.com [mikebianc@aol.com]
Sent: Thursday, July 10, 2014 4:25 PM
To: huang@sce.carleton.ca; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Perhaps we should reword that, then, to include a definition of Servic= e Function Instance and make sure we are consistent when referring to these= entities..  Based on most of the comments I've seen, it seems to make= a lot of sense to consider a Service Function more of an abstract entity that has one or more instances.  = An abstract Service Function with only a single instance might appear as ov= erkill, however it would normalize much of the conversation and allow for c= learer discussions about what happens when and where &c.

From the problem statement:
> The term service function chaining is used to describe the defi=
nition and instantiation of an ordered set of instances of such service fun=
ctions, and the subsequent "steering" of traffic flows through th=
ose service functions.

seems to indicate that the instance is the thing that is being chained= .  Of course, if the classifier only specifies chooses a chain ({SFn})= and not a path ({SFIn}), relinquishing the decision of which instantiation= to another process, then there technically is never an actual completed "ordered set of instances" produced= (because SFI(n) is only chosen sometime after being delivered to SFI(n-1))= rendering the SFP an abstract-ish conceptual thing.

Then again, it could be I've read too many of these today and my brain= is now full.



From: huang@sce.carleton.ca<huang@sce.carleton.ca>
To: <sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

As defined in the problem statement document, a service function is not a c= oncept. Here is the quote from the document "A Service Function can be= a virtual instance or be embedded in a physical network element." Thi= s means a service function is a virtual entity.

A virtual machine (VM), for example, can decide which process to run first.= Similarly a service function can decide how a packet being processed and f= orwarded to the next service function hop.

Chang

On 07/10/2014 11:36 AM, Ron Parker wrote:

Hi, Mike.

Between service functio= n and service function instance, I think it would have to be the instance, = since the former is conceptual. But, in a distributed path selection approach, might it make sense to assign this duty to the service= function forwarder (SFF)?

Ron

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: Thursday, July 10, 2014 2:34 PM
To: I.Smith@F5.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= /p>

"Service Functions= MAY make the decision about which Service Function Instances will be used = when selecting the Service Function Path."

Is it ser= vice function that makes that decision? or the service function instance?

From: I.Smith@F5.co= m<I.Smith@F5.com>
To: Changcheng Huang<huang@sce.carleton.ca>,'Ron Parker'<Ron_Parker@affirmedn= etworks.com>,'Lucy yong'<lucy.yong@huawei.com>,mo= hamed.boucadair@orange.com<mohamed.boucadair@orange.com>,mikebianc@aol.com<mikebianc@aol.com>,jmh@joelhalpern.com&l= t;jmh@joelhalpern.= com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

>Service functions should make = the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function = Instances will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) = MAY make the decision about which Service Function Instances will be used w= hen selecting the Service Function Path."

and,

"External orchestration frameworks= MAY make the decision about which Service Function Instances will be used = when selecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't= necessarily exclusive of one another if you have rules for resolving confl= icts; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over be= ing proscriptive when there is a conflict between the two.


From: sfc [sfc-bounces@ietf.org] on behalf of Changcheng Huang [huang@sce.carleton.ca]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

I agree with= Ron=92s comments. Service functions should make the decision about which i= nstances will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network= makes a service function chain aware of the available instances. These is = no need to identify each possible SFP by a physical network. If a service f= unction chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particula= r SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless,= because a physical network need to support multiple tenants, it does need = to identify different tenants. Our recent contribution (https://datatracker.i= etf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed= this issue in a more general architecture. Hope it can be helpful for this discussion.

Chang

From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

It is archit= ecturally significant to identify that multiple addressable instances of a = service function are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been po= inted out by Joel. It is also architecturally significant to assign respons= ibility for instance selection. In particular, is the instance selection ce= ntralized, distributed, or some combination? Which functional entities in the architecture have what respo= nsibilities to achieve this? In November, 2013, after IETF 88, I submitted = this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which pro= posed that the instance selection was made hop by hop by the service functi= ons themselves, in a fully distributed manner. That was just a proposal and= I am not wedded to it, by any means. Joel asked about specificity and it is at this level that I=92d like to se= e the architecture describe things. It should be able to answer the questio= n, =93how does multi-instance selection work in SFC?=94 in a concise manner= . If the group feels that there should be more than one answer to that question, so be it, but we should be able = to describe the high level mechanism and rationale for each succinctly. Of = course, that is merely one such question and there are many others that an = architectural document should be able to describe.

Ron

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: mohamed.boucadair@orange.com; mikebianc@aol.com; jmh@joelhalpern.com; = sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Agree. The a= rch. doc should not mandate only use of the service path identifier to driv= e the forwarding actions.

Lucy<= span style=3D"color:black">

From:= sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10, 2014 2:06 AM
To: mikebianc= @aol.com; jmh@joelhalpern.co= m; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Re-,

The merged draft calls o= ut explicitly a service path identifier. I object to use that identifier to= derive forwarding actions.

Requiring a SFC system t= o have the full knowledge of every available SFC forwarding paths within an= SFC-enabled domain is not required/justified nor possible in various deplo= yment contexts.

SFC forwarding actions s= hould rely on the piece of information that will be present in all deployme= nts: that is the one required to structure a service chain. How that inform= ation is used to infer forwarding actions is a solution-oriented discussion.

Cheers,

Med

= De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com
Envoy=E9 : mercredi 9 juillet 2014 22:03
=C0 : jmh@j= oelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Is anyone still = questioning the difference between SF Chain and SF Path? Other than clarify= ing the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one p= oint that is still unclear is whether it is the intent of this draft to ult= imately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that amb= iguous, allowing other drafts to dictate the mechanisms for forwarding base= d on chain or path and the choice of chain or path to be negotiated in the = control-plane.

If the latter (a= mbiguous), then the draft would have require that both SFP and SFC be suppo= rted (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joelh= alpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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



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

--_000_419417C345CA5F48BF45F0A23955A0634A83C43FSEAEMBX02olympu_-- From nobody Thu Jul 10 13:40: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 4D5E31B29E8 for ; Thu, 10 Jul 2014 13:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 2Zl18AZWLoZJ for ; Thu, 10 Jul 2014 13:40:44 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBC91B29FA for ; Thu, 10 Jul 2014 13:40:43 -0700 (PDT) Received: from [192.168.254.48] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s6AKefwm016413 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 10 Jul 2014 16:40:41 -0400 Message-ID: <53BEFB8A.7040800@sce.carleton.ca> Date: Thu, 10 Jul 2014 13:46:02 -0700 From: Changcheng Huang Organization: Carleton University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sam Aldrin References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> <53BEEDC3.6000305@sce.carleton.ca> <5F9AFA04-5604-4E33-B0B1-09F8A24FA8B5@gmail.com> In-Reply-To: <5F9AFA04-5604-4E33-B0B1-09F8A24FA8B5@gmail.com> Content-Type: multipart/alternative; boundary="------------020705030103080001000809" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZXBm3dbAEzEpgv3tboeZFjFava4 Cc: "sfc@ietf.org" Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:40:48 -0000 This is a multi-part message in MIME format. --------------020705030103080001000809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The most common small packets are TCP Ack packets which are around 64 bytes long including headers from various layers (MAC, IP, TCP) and some padded payloads to make it satisfy minimum packet size requirement. Adding metadata to this kind of packets does not make sense to me. Chang On 07/10/2014 01:22 PM, Sam Aldrin wrote: > I agree . As SFC is established in a controlled domain, mitigating > options are better than general internet. Again need to see how much > of an overhead it really causes and it's side effects. > > Sam > > Sent from my iPad > > On Jul 10, 2014, at 12:47 PM, Changcheng Huang > wrote: > >> Even the SFC is limited to a specific domain (such as a datacenter), >> the packet sizes still follow the same distribution. The bandwidth >> within a datacenter is still a bottleneck part due to traffic >> patterns such as incast. >> >> Chang >> >> On 07/10/2014 12:02 PM, Sam Aldrin wrote: >>> >>> >>> On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang >>> > wrote: >>> >>> I am concerned with the overhead metadata may create. Internet >>> packet sizes tend to be bimodal where more than 50% of packets >>> have very small packet sizes. Carrying large amounts of overhead >>> will reduce throughput significantly. Making metadata optional >>> may be a good choice. >>> >>> Doesn't that depend only if the SFC spans across the internet? >>> Otherwise it (overhead) should be limited to SFC's domain, which may >>> not span across internet, no? >>> >>> cheers >>> -sam >>> >>> >>> Regards, >>> >>> Chang >>> >>> >>> On 07/10/2014 11:22 AM, Joel M. Halpern wrote: >>> >>> I look forward to seeing your draft. >>> >>> One of the reasons I like including the metadata with the >>> underlying packet is that they then share fate. If the >>> packet gets lost, the metadata disappears with it, which is >>> frequently fine. And if the packet is probably delviered >>> down the service path, then so is the metadata. >>> >>> Yours, >>> Joel >>> >>> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >>> >>> Hello, >>> >>> Metadata transport is a feature provided by SFC that >>> needs some >>> additional thoughts as well. >>> >>> B Rijsman has done a great job showing various option >>> for Metadata >>> sharing. Still there are 2 aspects that I would like to >>> address further >>> >>> - Metadata representation >>> >>> - Metadata transport reliability >>> >>> We will probably post a draft on the subject, but this >>> can be done after >>> Toronto has started. So for those >>> interested to provide some feedback, here are some >>> highlights. >>> >>> *1. Problem Space* >>> * Metadata representation* >>> Metadata can be extremely varied in term of usage and >>> content. It can >>> represent the result of Deep Packet Inspection (DPI) >>> performed on the >>> traffic for example by the Classifier Service Function >>> at the ingress of >>> the Service Function Chain. It can contain information >>> collected about >>> the end user such as a policy identifier, a category or >>> even represent >>> an event related to the end-user session. >>> This information can be used by Service Functions on the >>> chain, as well >>> as by monitoring entities responsible to track usage for >>> example in the >>> Network Function Virtualization environment to feed a >>> VNF manager or an >>> Orchestrator. >>> Metadata being information shared by many network >>> entities needs some >>> means to be represented it in all of its dimensions: >>> type definition, >>> encoding and scope. >>> * Metadata transport service* >>> As expected from service chain proposals, both NSH and >>> SCH proposals >>> define some means to carry metadata between Service >>> Functions in a >>> Chain. They can be classified as follow: >>> Dataplane Metadata: >>> are defined in the Service Function Chaining Problem >>> Statement document. >>> They are not considered to be part of the forwarding >>> information of the >>> SFC header. However they are expected to carry the >>> result of antecedent >>> classification, allowing Service Functions to take local >>> policy >>> decisions based on their values. >>> >>> As such, they could also be interpreted directly by >>> Service Function >>> Forwarder to steer traffic to various Service Functions. >>> Offline Metadata: >>> Beyond Dataplane Metadata, Offline Metadata can be >>> shared between >>> Service Functions in a chain, using out of band, >>> congruent or not, or >>> hybrid models described in [RIJSMAN] >>> >>> The hybrid model for example, defined in [RIJSMAN], >>> utilizes the SFC >>> header to transport some key values for correlation >>> purposes. These >>> Correlation Ids can be used by the Service Functions to >>> recover the full >>> associated contextual information. >>> Metadata, directly or indirectly, are transported hop by >>> hop along a >>> chain, in association to end-user traffic, the data >>> payload of the SFC >>> packets. >>> How these metadata are transported over a chain matters. >>> Passing >>> metadata directly or indirectly along packets is a >>> service that must be >>> analyzed from a reliability point of view. >>> >>> Reliability requirements may vary depending on the >>> nature of the >>> metadata transported. Past experience for example in >>> Mobile Network and >>> data center with AAA Radius have shown that contextual >>> information >>> replication to various service function was indeed >>> sensitive to packet >>> loss events, and that adhoc solutions had to be >>> implemented to detect them. >>> End to end TCP retransmission of packet lost does not >>> ensure that >>> associated Metadata will be reinserted in retransmitted >>> packet. In >>> addition, Event triggered metadata may have to be sent >>> immediately on a >>> chain even though no end-user traffic is being transmitted >>> Not all metadata needs a reliable transport. Repeated >>> inline metadata >>> can be used to cover several use cases, and some >>> metadata loss can be >>> acceptable. >>> Still, a reliable transport service for Metadata in SFC >>> is expected. To >>> this effect, an implementation is suggested in Section 3.3 >>> *2. Metadata representation* >>> Metadata definition is that it provides contextual >>> information about the >>> data packets which traverse a Service Function Chain. >>> This must be >>> understood broadly. >>> Metadata can contain the result of traffic >>> classification by Deep Packet >>> Inspection (DPI). For example as an Application Id >>> information which is >>> tied to a traffic flow. There could be multiple flows >>> with different >>> application ids, in a chain. >>> Metadata can also contain the result of DPI data >>> extraction, such as >>> identify requested URL in HTTP. Such information can be >>> passed to >>> certain SF down the chain such as a URL filtering function. >>> Metadata can contain some punctual event information >>> collected at the >>> Ingress point of the chain and expected to be passed to >>> all elements in >>> the chain. Here this information may be triggered >>> externally and >>> generated only once, and be related to the tenant or the >>> subscriber. >>> Metadata representation involves the definition of a set >>> of information >>> elements types and the encoding rules for their values. >>> Metadata representation can sometimes be performed by a >>> single >>> individual field with associated type and format. >>> However, it is not >>> always enough. >>> >>> * Metadata may need multiple fields transported >>> together to >>> represented their values. >>> * Some addition fields may be required to describe the >>> scope of the >>> metadata itself. This can be any information element >>> allowing to >>> define the context of the associated metadata value. >>> For example a >>> throughput metadata field can have a port number and >>> a switch >>> address as its Scope information. >>> >>> We explore these two axis: encoding and scope. >>> We propose IPFIX as a preferred means to represent >>> Metadata in Service >>> Chain messages for Out-of-band, Congruent or not; >>> Metadata sharing. >>> *2.1. Metadata Representation Requirements* >>> Mandatatory Dataplane Metadata is always part of the SFC >>> header, it is >>> thus reasonable to consider that its representation >>> scheme will be >>> implicit: based on what the SFC protocol will dictate, >>> their position in >>> the SFC header is sufficient for the receiving end to >>> infer their type >>> and encoding scheme. For example, Context Header Fields >>> in NSH are 32 >>> bit fields. >>> However, it will not be the case for all metadata >>> transported. Offline >>> metadata, including congruent out-of-band metadata still >>> need to be >>> represented explicitly. This section addresses their >>> specific case. >>> *2.1.1. Metadata Encoding requirements* >>> These requirements are applicable to out-of-band >>> metadata (Congruent or >>> not). It could be applicable with SCH on optional >>> in-line metadata fields. >>> For interoperability purposes, metadata encoding MUST >>> allow the >>> receiving entity to identify the type and value of the >>> information >>> received as metadata >>> Metadata encoding MUST allow for encoding techniques >>> supporting well >>> known types and fields as well as proprietary extensions. >>> A receiving entity MUST be able to identify when >>> incoming metadata type >>> is unknown and MUST have a defined default action to >>> handle it. >>> A piece of information may need multiple fields to be >>> described. For >>> example a tenant id and an ip address can be used to >>> identify an server >>> in a data center uniquely. >>> These groups of information have to be exchanged >>> collectively, in a >>> single message. In this case, a sending entity MUST >>> specify that it is >>> sending a set of metadata in a message. >>> This set of transported metadata elements MUST be >>> specified under the >>> form of a metadata template document uniquely defined >>> for the chain. >>> A receiving entity MUST be able to detect if an incoming >>> message >>> contains its expected set of metadata elements. >>> *2.1.2. Metadata Scope requirement* >>> A piece of information may have to be qualified by some >>> attributes >>> allowing to identify its particular scope. For example >>> in a Gi >>> environment, the radio type in use may be used as a >>> scoping criteria for >>> a jitter or latency measurement in a video traffic >>> transported in a >>> particular service chaing. >>> Scope can apply to some individual metadata elements or >>> to a set of >>> metadata elements. How a scope applies to a set of >>> transported metadata >>> elements should be defined by a specification under the >>> form of a >>> metadata template document uniquely identified for the >>> chain. >>> *2.2. IPFIX Metadata representation* >>> So far, unordered sequences of Type Length Value encoded >>> fields have >>> been proposed to transport metadata. It is not clear how >>> structured >>> types are supported, and no distinction is done between >>> the metadata >>> values and their scoping values. Although the SCH >>> proposal provides an >>> optional 24-bit Organizational Unique Identifier, there >>> is no namespace >>> mechanism allowing to separate type definition spaces >>> per Tenants or per >>> chain. >>> We suggest to leverage the work done by IETF on similar >>> subject. >>> A natural candidate to leverage is IPFIX [RFC7011]: >>> IPFIX is a means for >>> transmitting Traffic Flow information over the network. >>> In order to >>> transmit Traffic Flow information, it provides a common >>> representation >>> of flow data and a standard means of communicating them. >>> Metadata collected by Network Node and Service Node >>> SHOULD be encoded in >>> template following the principles described in >>> IPFIX[RFC7011]. >>> An IPFIX Message consisting of interleaved Template, >>> Data, and Options >>> Template Sets, as shown in Figure 1. Here, Template and >>> Options Template >>> Sets , which are optional, are shown. >>> >>> >>> +--------+--------------------------------------------------------+ >>> | | +----------+ +---------+ +-----------+ >>> +---------+ | >>> |Message | | Template | | Data | | Options | | >>> Data | | >>> | Header | | Set | | Set | ... | Template >>> | | Set | | >>> | | | | | | | Set | | >>> | | >>> | | +----------+ +---------+ +-----------+ >>> +---------+ | >>> +--------+--------------------------------------------------------+ >>> >>> >>> >>> Figure 1: IPFIX Message Format >>> The Template Set describes the data transmitted in the >>> following Data >>> Set. It is an optional component of the message. The >>> value of the >>> metadata is encoded in the first Data Set. This Data Set >>> contains a >>> template Id field as a reference to its defining >>> Template Set. >>> The Options Template Set describes the data to be >>> transmitted as scope >>> information. It is an optional component of the message. >>> The value of >>> the scope information is encoded in the second Data Set >>> element. It no >>> scope information is present, then only the first Data >>> Set is present in >>> the message. >>> The Option Template Set and following Data Set are used >>> to describe the >>> scope of the metadata transmitted. For example, the >>> metadata collected >>> is relevant to a PDP Context or a particular line card >>> of a particular >>> switch. >>> * >>> * >>> *2.2.4.3. Example:* >>> The Metadata Exporting Process creates a Template Record >>> with a few >>> Information Elements: amongst other things, the >>> Application Id. For example: >>> >>> - sourceIPv4Address (key field) >>> - destinationIPv4Address (key field) >>> - protocol (key field) >>> - destinationTransportPort (key field) >>> - applicationId (key field) >>> - octetTotalCount (non key field) >>> >>> For example, a Flow Record corresponding to the >>> above >>> Template Record may contain: >>> >>> { sourceIPv4Address=192.0.2.1, >>> destinationIPv4Address=192.0.2.2, >>> protocol=17, >>> destinationTransportPort=23, >>> applicationId='3..80', >>> octetTotalCount=123456 } >>> >>> >>> >>> The Options Data Record associated with the examples >>> above would contain >>> the Scoping inforamtion: >>> >>> Scope: >>> - servicePath, >>> - serviceIndex, >>> - applicationId, >>> - applicationName >>> - applicationDescription. >>> >>> For example: >>> >>> { >>> servicePath=0x000b, >>> serviceIndex=0x000c, >>> applicationId='13...10000', >>> applicationName="webex", >>> applicationDescription="Webex application" } >>> >>> >>> >>> Scope information is useful when sending metadata >>> offline, as it can >>> contain information related to the chain and possibly to >>> the flow for >>> which this metadata record is relevant. Here servicePath and >>> serviceIndex are thus included in the Template. >>> *2.2.4.4. IPFIX encoding and template provisioning:* >>> IPFIX is a quite compact encoding >>> For a template defined as followed and shared by the SF >>> in a chain. >>> IPFIX template record shared by SF: >>> Note that an XML representation of IPFIX template record >>> could be >>> defined and used to provision Service Functions. >>> >>> 0 1 2 >>> 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 | Length = 28 >>> octets | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID 256 | Field Count = 5 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| sourceIPv4Address = 8 | Field Length = 4 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| destinationIPv4Address = 12 | Field Length = 4 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| ipNextHopIPv4Address = 15 | Field Length = 4 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| packetDeltaCount = 2 | Field Length = 4 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| octetDeltaCount = 1 | Field Length = 4 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Figure 7: IPFIX Metadata template Encoding >>> An encoded IP fix transport message will be: >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>> 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version Number | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Export Time >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence Number >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Observation Domain ID >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 256 | Length = 64 >>> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.12 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.254 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 192.0.2.1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5009 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 5344385 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> Figure 8: IPFIX Metadata Encoding >>> *3. Metadata transport service* >>> These different use cases for Metadata generate some >>> requirements on the >>> reliability capabilities of the Metadata transport >>> service they will >>> rely on. >>> De facto Service Function Chain proposals such as NSH >>> and SCH define a >>> mechanism for sharing information along the Chains. It >>> is thus important >>> to define this transport service in term of reliability. >>> The primary focus of these proposal are the Metadata >>> elements playing a >>> role in the Service Function Chain deployment to apply >>> policies on >>> incoming traffic at some relevant Service Functions. >>> For example, Network Orchestration is expected to be a >>> significant >>> driver for deployment of Network Services. It relies on >>> Service Level >>> abstractions such as Group Policies, Contracts and >>> Services as an input >>> for the orchestration of Service Function Chains. >>> Specific metadata >>> attributes such as L4-L7 fields are used as >>> classification elements or >>> filters to funnel packets into chains. >>> Service Functions may have other needs for Metadata, for >>> example Event >>> Based Metadata tied to some subscriber related state >>> changes. The >>> complexity and length of these elements cannot be >>> forseen as limited, >>> neither can be how critical it is that they are safely >>> carried >>> throughout a chain. In the following Section we propose >>> to take >>> avantage of Congruent Metadata Transport can be used, >>> possibly reliably, >>> to address these needs. >>> *3.1. Proposed Metadata transport mechanisms* >>> . >>> *3.1.3. Metadata transport analysis* >>> Both NSH and SCH proposals support both inbound and >>> offline out-of-band >>> metadata transport. >>> >>> 1. In-band: the metadata can be included directly as a >>> value in some of >>> the NSH Context Header Fields. It is the preferred >>> transport model >>> for SCH. >>> >>> In such case, when a particular field is always set >>> to the same >>> value for all packets transported by the chain >>> instance, then the >>> metadata transport service is in effect reliable. >>> >>> Similarly, all the packet for a particular flow >>> (defined by its 5 >>> tupple), could receive the same metadata value. The >>> metadata >>> transport service is also reliable, provided that >>> the value is >>> understood to be attached to a flow. >>> >>> The general case however, occurs when the metadata >>> varies from >>> packet to packet in a flow. The value is then tied >>> to a specific >>> packet. Here the transport service is not reliable. >>> A retransmission >>> of a particular packet would not necessarily lead it >>> to carry the >>> same metadata value. >>> 2. Out-of-band: a reference for some metadata is sent >>> along a packet so >>> that it can be used via an interaction with a >>> controller entity. It >>> is the preferred model for NSH, but could also be >>> used by SCH. >>> >>> As for the in-band case, the metadata referred to >>> indirectly can be >>> transmitted reliably, when its value remains the >>> same for a chain or >>> a flow in a chain. a chain or a flow in a chain. >>> >>> If however, the correlation Id passed changes over >>> time, or if the >>> Metadata itself cahanges then the correct Metadata >>> may not be >>> efficiently retrieved by some Service Functions. >>> >>> We can see that NSH and SCH do not address the need for >>> a reliable >>> transport service for metadata, independantly of the >>> reliability >>> characteristic of the transport service used for the >>> data packets. >>> Conventions can be used as particular cases when some >>> metadata pertains >>> to a specific chain or a flow in the chain, and when its >>> value does not >>> change overtime. >>> Such conventions however are weak. They would suppose >>> that some >>> mechanism exists to ensure/monitor that they are >>> followed. And some >>> exceptions mechanism would be required to deal with >>> error cases. >>> *3.2. Support for Congruent out-of-band transport service* >>> Congruent out-of-band metadata sharing can be required >>> for some types of >>> Metadata exchanges. It has the advantage of clearly >>> tying the metadata >>> to the chain and not to a specific packet, and to avoid >>> payload >>> fragmentation issues. >>> Up to draft 2, NSH did not allow for long inline >>> metadata transport. >>> Four 32 bits context fields are reserved for that >>> purpose, and seem best >>> suited for offline Metadata sharing, or to transport >>> predefined policy >>> identifiers. >>> NSH (since draf 3) as well as SCH could allow for >>> metadata transport, >>> either tied to a packet or possibly tied to the chain, >>> when used without >>> payload, as signaling messages. >>> SCH however stipulates that in case the Path Identifier >>> and SF Index >>> fields shall be set to zero for transmit and ignored >>> upon receipt, when >>> the SCH packet will contain only metadata. So congruent >>> out-of-band >>> metadata, transporting Metadata hop to hop to the >>> various Service >>> Function in the chain, does not seem to be supported. >>> NSH supports inline variable size metadata. It does not >>> mentions >>> explicitly that congruent out-of-band metadata can be used. >>> *3.3. Reliable transport service* >>> Some metadata will need a reliable transport service to >>> be shared >>> inline, as well as offline. >>> A protocol SCTP provides such a service and has the >>> interesting >>> characteristic to be packet based, as opposed to stream >>> based like TCP. >>> SCTP carries a sequence number and support >>> retransmission and congestion >>> control. >>> Figure 12 shows how SCTP is used hop by hop between SFF >>> in a chain to >>> transport Metadata reliably. >>> >>> |1 ----- |n |21 ---- |2m >>> +---+---+ +---+---+ +-+---+ >>> +--+-----+ >>> | SF#1 | |SF#n | |SF#i1| >>> |SF#im | >>> | | | | | | | >>> | >>> +---+---+ +---+---+ +--+--+ >>> +--+--+--+ >>> : : : : : >>> : : : : : >>> \ / \ / >>> +-----------+ SCTP +--------+ SCTP +---------+ >>> -- >| Chain | <---> | SFF | <---> | SFF >>> | ----> >>> |classifier | |Node-1 | | Node-i | >>> +-----------+ +----+---+ +----+--+-+ >>> \ | / >>> \ | SFC Encapsulation / >>> \ | / >>> ,........................................ >>> / \ >>> / \ >>> | Network | >>> \ / >>> \........................................./ >>> >>> >>> >>> Figure 12: SCTP for Reliable Metadata transport >>> SCTP SHOULD be used in the context of Congruent out of >>> band for reliable >>> metadata sharing. >>> For reliable Metadata transport, the SFF along the chain >>> MUST route the >>> metadata received over SCTP to the next SF in the chain. >>> For this SCTP >>> MUST be encapsulated in the SFC header. >>> The SFF MUST make the received metadata available >>> to its SF.ti >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc --------------020705030103080001000809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit The most common small packets are TCP Ack packets which are around 64 bytes long including headers from various layers (MAC, IP, TCP) and some padded payloads to make it satisfy minimum packet size requirement. Adding metadata to this kind of packets does not make sense to me.

Chang

On 07/10/2014 01:22 PM, Sam Aldrin wrote:
I agree . As SFC is established in a controlled domain, mitigating options are better than general internet. Again need to see how much of an overhead it really causes and it's side effects.

Sam

Sent from my iPad

On Jul 10, 2014, at 12:47 PM, Changcheng Huang <huang@sce.carleton.ca> wrote:

Even the SFC is limited to a specific domain (such as a datacenter), the packet sizes still follow the same distribution. The bandwidth within a datacenter is still a bottleneck part due to traffic patterns such as incast.

Chang

On 07/10/2014 12:02 PM, Sam Aldrin wrote:


On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang <huang@sce.carleton.ca> wrote:
I am concerned with the overhead metadata may create. Internet packet sizes tend to be bimodal where more than 50% of packets have very small packet sizes. Carrying large amounts of overhead will reduce throughput significantly. Making metadata optional may be a good choice.
Doesn't that depend only if the SFC spans across the internet?  
Otherwise it (overhead) should be limited to SFC's domain, which may not span across internet, no?

cheers
-sam

Regards,

Chang


On 07/10/2014 11:22 AM, Joel M. Halpern wrote:
I look forward to seeing your draft.

One of the reasons I like including the metadata with the underlying packet is that they then share fate.  If the packet gets lost, the metadata disappears with it, which is frequently fine.  And if the packet is probably delviered down the service path, then so is the metadata.

Yours,
Joel

On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote:
Hello,

Metadata transport is a feature provided by SFC that needs some
additional thoughts as well.

B Rijsman has done a great job showing various option for Metadata
sharing. Still there are 2 aspects that I would like to address further

- Metadata representation

- Metadata transport reliability

We will probably post a draft on the subject, but this can be done after
Toronto has started. So for those
interested to provide some feedback, here are some highlights.

*1. Problem Space*
* Metadata representation*
Metadata can be extremely varied in term of usage and content. It can
represent the result of Deep Packet Inspection (DPI) performed on the
traffic for example by the Classifier Service Function at the ingress of
the Service Function Chain. It can contain information collected about
the end user such as a policy identifier, a category or even represent
an event related to the end-user session.
This information can be used by Service Functions on the chain, as well
as by monitoring entities responsible to track usage for example in the
Network Function Virtualization environment to feed a VNF manager or an
Orchestrator.
Metadata being information shared by many network entities needs some
means to be represented it in all of its dimensions: type definition,
encoding and scope.
* Metadata transport service*
As expected from service chain proposals, both NSH and SCH proposals
define some means to carry metadata between Service Functions in a
Chain. They can be classified as follow:
Dataplane Metadata:
are defined in the Service Function Chaining Problem Statement document.
They are not considered to be part of the forwarding information of the
SFC header. However they are expected to carry the result of antecedent
classification, allowing Service Functions to take local policy
decisions based on their values.

As such, they could also be interpreted directly by Service Function
Forwarder to steer traffic to various Service Functions.
Offline Metadata:
Beyond Dataplane Metadata, Offline Metadata can be shared between
Service Functions in a chain, using out of band, congruent or not, or
hybrid models described in [RIJSMAN]

The hybrid model for example, defined in [RIJSMAN], utilizes the SFC
header to transport some key values for correlation purposes. These
Correlation Ids can be used by the Service Functions to recover the full
associated contextual information.
Metadata, directly or indirectly, are transported hop by hop along a
chain, in association to end-user traffic, the data payload of the SFC
packets.
How these metadata are transported over a chain matters. Passing
metadata directly or indirectly along packets is a service that must be
analyzed from a reliability point of view.

Reliability requirements may vary depending on the nature of the
metadata transported. Past experience for example in Mobile Network and
data center with AAA Radius have shown that contextual information
replication to various service function was indeed sensitive to packet
loss events, and that adhoc solutions had to be implemented to detect them.
End to end TCP retransmission of packet lost does not ensure that
associated Metadata will be reinserted in retransmitted packet. In
addition, Event triggered metadata may have to be sent immediately on a
chain even though no end-user traffic is being transmitted
Not all metadata needs a reliable transport. Repeated inline metadata
can be used to cover several use cases, and some metadata loss can be
acceptable.
Still, a reliable transport service for Metadata in SFC is expected. To
this effect, an implementation is suggested in Section 3.3
*2. Metadata representation*
Metadata definition is that it provides contextual information about the
data packets which traverse a Service Function Chain. This must be
understood broadly.
Metadata can contain the result of traffic classification by Deep Packet
Inspection (DPI). For example as an Application Id information which is
tied to a traffic flow. There could be multiple flows with different
application ids, in a chain.
Metadata can also contain the result of DPI data extraction, such as
identify requested URL in HTTP. Such information can be passed to
certain SF down the chain such as a URL filtering function.
Metadata can contain some punctual event information collected at the
Ingress point of the chain and expected to be passed to all elements in
the chain. Here this information may be triggered externally and
generated only once, and be related to the tenant or the subscriber.
Metadata representation involves the definition of a set of information
elements types and the encoding rules for their values.
Metadata representation can sometimes be performed by a single
individual field with associated type and format. However, it is not
always enough.

  * Metadata may need multiple fields transported together to
    represented their values.
  * Some addition fields may be required to describe the scope of the
    metadata itself. This can be any information element allowing to
    define the context of the associated metadata value. For example a
    throughput metadata field can have a port number and a switch
    address as its Scope information.

We explore these two axis: encoding and scope.
We propose IPFIX as a preferred means to represent Metadata in Service
Chain messages for Out-of-band, Congruent or not; Metadata sharing.
*2.1. Metadata Representation Requirements*
Mandatatory Dataplane Metadata is always part of the SFC header, it is
thus reasonable to consider that its representation scheme will be
implicit: based on what the SFC protocol will dictate, their position in
the SFC header is sufficient for the receiving end to infer their type
and encoding scheme. For example, Context Header Fields in NSH are 32
bit fields.
However, it will not be the case for all metadata transported. Offline
metadata, including congruent out-of-band metadata still need to be
represented explicitly. This section addresses their specific case.
*2.1.1. Metadata Encoding requirements*
These requirements are applicable to out-of-band metadata (Congruent or
not). It could be applicable with SCH on optional in-line metadata fields.
For interoperability purposes, metadata encoding MUST allow the
receiving entity to identify the type and value of the information
received as metadata
Metadata encoding MUST allow for encoding techniques supporting well
known types and fields as well as proprietary extensions.
A receiving entity MUST be able to identify when incoming metadata type
is unknown and MUST have a defined default action to handle it.
A piece of information may need multiple fields to be described. For
example a tenant id and an ip address can be used to identify an server
in a data center uniquely.
These groups of information have to be exchanged collectively, in a
single message. In this case, a sending entity MUST specify that it is
sending a set of metadata in a message.
This set of transported metadata elements MUST be specified under the
form of a metadata template document uniquely defined for the chain.
A receiving entity MUST be able to detect if an incoming message
contains its expected set of metadata elements.
*2.1.2. Metadata Scope requirement*
A piece of information may have to be qualified by some attributes
allowing to identify its particular scope. For example in a Gi
environment, the radio type in use may be used as a scoping criteria for
a jitter or latency measurement in a video traffic transported in a
particular service chaing.
Scope can apply to some individual metadata elements or to a set of
metadata elements. How a scope applies to a set of transported metadata
elements should be defined by a specification under the form of a
metadata template document uniquely identified for the chain.
*2.2. IPFIX Metadata representation*
So far, unordered sequences of Type Length Value encoded fields have
been proposed to transport metadata. It is not clear how structured
types are supported, and no distinction is done between the metadata
values and their scoping values. Although the SCH proposal provides an
optional 24-bit Organizational Unique Identifier, there is no namespace
mechanism allowing to separate type definition spaces per Tenants or per
chain.
We suggest to leverage the work done by IETF on similar subject.
A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for
transmitting Traffic Flow information over the network. In order to
transmit Traffic Flow information, it provides a common representation
of flow data and a standard means of communicating them.
Metadata collected by Network Node and Service Node SHOULD be encoded in
template following the principles described in IPFIX[RFC7011].
An IPFIX Message consisting of interleaved Template, Data, and Options
Template Sets, as shown in Figure 1. Here, Template and Options Template
Sets , which are optional, are shown.


+--------+--------------------------------------------------------+
    |        | +----------+ +---------+     +-----------+ +---------+ |
    |Message | | Template | | Data    |     | Options   | | Data    | |
    | Header | | Set      | | Set     | ... | Template  | | Set     | |
    |        | |          | |         |     | Set       | |         | |
    |        | +----------+ +---------+     +-----------+ +---------+ |
+--------+--------------------------------------------------------+



Figure 1: IPFIX Message Format
The Template Set describes the data transmitted in the following Data
Set. It is an optional component of the message. The value of the
metadata is encoded in the first Data Set. This Data Set contains a
template Id field as a reference to its defining Template Set.
The Options Template Set describes the data to be transmitted as scope
information. It is an optional component of the message. The value of
the scope information is encoded in the second Data Set element. It no
scope information is present, then only the first Data Set is present in
the message.
The Option Template Set and following Data Set are used to describe the
scope of the metadata transmitted. For example, the metadata collected
is relevant to a PDP Context or a particular line card of a particular
switch.
*
*
*2.2.4.3. Example:*
The Metadata Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application Id. For example:

         - sourceIPv4Address (key field)
         - destinationIPv4Address (key field)
         - protocol (key field)
         - destinationTransportPort (key field)
         - applicationId (key field)
         - octetTotalCount (non key field)

         For example, a Flow Record corresponding to the above
         Template Record may contain:

             { sourceIPv4Address=192.0.2.1,
               destinationIPv4Address=192.0.2.2,
               protocol=17,
               destinationTransportPort=23,
               applicationId='3..80',
               octetTotalCount=123456 }



The Options Data Record associated with the examples above would contain
the Scoping inforamtion:

      Scope:
              - servicePath,
              - serviceIndex,
              - applicationId,
              - applicationName
              - applicationDescription.

       For example:

             {
               servicePath=0x000b,
               serviceIndex=0x000c,
               applicationId='13...10000',
               applicationName="webex",
               applicationDescription="Webex application" }



Scope information is useful when sending metadata offline, as it can
contain information related to the chain and possibly to the flow for
which this metadata record is relevant. Here servicePath and
serviceIndex are thus included in the Template.
*2.2.4.4. IPFIX encoding and template provisioning:*
IPFIX is a quite compact encoding
For a template defined as followed and shared by the SF in a chain.
IPFIX template record shared by SF:
Note that an XML representation of IPFIX template record could be
defined and used to provision Service Functions.

  0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Set ID = 2            |      Length = 28 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Template ID 256         |       Field Count = 5         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    packetDeltaCount = 2     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    octetDeltaCount = 1      |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Figure 7: IPFIX Metadata template Encoding
An encoded IP fix transport message will be:


    0                   1                   2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Version Number          | Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Export Time                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Observation Domain ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Set ID = 256         |          Length = 64          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.12                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.254                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 192.0.2.1                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5009                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 5344385                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Figure 8: IPFIX Metadata Encoding
*3. Metadata transport service*
These different use cases for Metadata generate some requirements on the
reliability capabilities of the Metadata transport service they will
rely on.
De facto Service Function Chain proposals such as NSH and SCH define a
mechanism for sharing information along the Chains. It is thus important
to define this transport service in term of reliability.
The primary focus of these proposal are the Metadata elements playing a
role in the Service Function Chain deployment to apply policies on
incoming traffic at some relevant Service Functions.
For example, Network Orchestration is expected to be a significant
driver for deployment of Network Services. It relies on Service Level
abstractions such as Group Policies, Contracts and Services as an input
for the orchestration of Service Function Chains. Specific metadata
attributes such as L4-L7 fields are used as classification elements or
filters to funnel packets into chains.
Service Functions may have other needs for Metadata, for example Event
Based Metadata tied to some subscriber related state changes. The
complexity and length of these elements cannot be forseen as limited,
neither can be how critical it is that they are safely carried
throughout a chain. In  the following Section we propose to take
avantage of Congruent Metadata Transport can be used, possibly reliably,
to address these needs.
*3.1. Proposed Metadata transport mechanisms*
.
*3.1.3. Metadata transport analysis*
Both NSH and SCH proposals support both inbound and offline out-of-band
metadata transport.

 1. In-band: the metadata can be included directly as a value in some of
    the NSH Context Header Fields. It is the preferred transport model
    for SCH.

    In such case, when a particular field is always set to the same
    value for all packets transported by the chain instance, then the
    metadata transport service is in effect reliable.

    Similarly, all the packet for a particular flow (defined by its 5
    tupple), could receive the same metadata value. The metadata
    transport service is also reliable, provided that the value is
    understood to be attached to a flow.

    The general case however, occurs when the metadata varies from
    packet to packet in a flow. The value is then tied to a specific
    packet. Here the transport service is not reliable. A retransmission
    of a particular packet would not necessarily lead it to carry the
    same metadata value.
 2. Out-of-band: a reference for some metadata is sent along a packet so
    that it can be used via an interaction with a controller entity. It
    is the preferred model for NSH, but could also be used by SCH.

    As for the in-band case, the metadata referred to indirectly can be
    transmitted reliably, when its value remains the same for a chain or
    a flow in a chain. a chain or a flow in a chain.

    If however, the correlation Id passed changes over time, or if the
    Metadata itself cahanges then the correct Metadata may not be
    efficiently retrieved by some Service Functions.

We can see that NSH and SCH do not address the need for a reliable
transport service for metadata, independantly of the reliability
characteristic of the transport service used for the data packets.
Conventions can be used as particular cases when some metadata pertains
to a specific chain or a flow in the chain, and when its value does not
change overtime.
Such conventions however are weak. They would suppose that some
mechanism exists to ensure/monitor that they are followed. And some
exceptions mechanism would be required to deal with error cases.
*3.2. Support for Congruent out-of-band transport service*
Congruent out-of-band metadata sharing can be required for some types of
Metadata exchanges. It has the advantage of clearly tying the metadata
to the chain and not to a specific packet, and to avoid payload
fragmentation issues.
Up to draft 2, NSH did not allow for long inline metadata transport.
Four 32 bits context fields are reserved for that purpose, and seem best
suited for offline Metadata sharing, or to transport predefined policy
identifiers.
NSH (since draf 3) as well as SCH could allow for metadata transport,
either tied to a packet or possibly tied to the chain, when used without
payload, as signaling messages.
SCH however stipulates that in case the Path Identifier and SF Index
fields shall be set to zero for transmit and ignored upon receipt, when
the SCH packet will contain only metadata. So congruent out-of-band
metadata, transporting Metadata hop to hop to the various Service
Function in the chain, does not seem to be supported.
NSH supports inline variable size metadata. It does not mentions
explicitly that congruent out-of-band metadata can be used.
*3.3. Reliable transport service*
Some metadata will need a reliable transport service to be shared
inline, as well as offline.
A protocol SCTP provides such a service and has the interesting
characteristic to be packet based, as opposed to stream based like TCP.
SCTP carries a sequence number and support retransmission and congestion
control.
Figure 12 shows how SCTP is used hop by hop between SFF in a chain to
transport Metadata reliably.

                      |1  -----   |n        |21  ---- |2m
                    +---+---+   +---+---+   +-+---+   +--+-----+
                    | SF#1  |   |SF#n   |   |SF#i1|   |SF#im   |
                    |       |   |       |   |     |   |        |
                    +---+---+   +---+---+   +--+--+   +--+--+--+
                        :           :          :         :  :
                        :           :          :         :  :
                         \         /            \       /
     +-----------+ SCTP   +--------+    SCTP     +---------+
-- >| Chain     | <--->  | SFF    |    <--->    | SFF     | ---->
     |classifier |        |Node-1  |             | Node-i  |
     +-----------+        +----+---+             +----+--+-+
                   \           |                     /
                    \          | SFC Encapsulation  /
                     \         |                   /
                   ,........................................
                  /                                         \
                 /                                           \
                |                      Network                |
                 \                                           /
                  \........................................./



Figure 12: SCTP for Reliable Metadata transport
SCTP SHOULD be used in the context of Congruent out of band for reliable
metadata sharing.
For reliable Metadata transport, the SFF along the chain MUST route the
metadata received over SCTP to the next SF in the chain. For this SCTP
MUST be encapsulated in the SFC header.
     The SFF MUST make the received metadata available to its SF.ti


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


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


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



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

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

--------------020705030103080001000809-- From nobody Thu Jul 10 13:46: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 6C5371B29F8 for ; Thu, 10 Jul 2014 13:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 T8QpwFpuqsZE for ; Thu, 10 Jul 2014 13:46:44 -0700 (PDT) Received: from omr-d09.mx.aol.com (omr-d09.mx.aol.com [205.188.108.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139BD1B29F5 for ; Thu, 10 Jul 2014 13:46:44 -0700 (PDT) Received: from mtaout-mcb01.mx.aol.com (mtaout-mcb01.mx.aol.com [172.26.50.173]) by omr-d09.mx.aol.com (Outbound Mail Relay) with ESMTP id 3A7EB7028AE63; Thu, 10 Jul 2014 16:46:43 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mcb01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D8FBD380000A7; Thu, 10 Jul 2014 16:46:42 -0400 (EDT) Date: Thu, 10 Jul 2014 16:46:42 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com Message-ID: <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1582_1339533867.1405025202692" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405025203; bh=96Bc0Ht1/rZM5s38n/f0IVKbWaU7EgvQBKuGoexD1PI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=i3YSM2i9Od+VtjhB/h8Bcpjb6o99+f6W34wqCkr7FDtSvJVGPFMVgDRAoMtJzyLNQ Ydu+d+IKiip+9O30sZAHOR39vnHd/OPLgmZHnkZbbwNR76OpwtZxt7zQ99vXdaJgw7 ATh5DDKNeg5+aJCwnybZgdA98DnfTKTDPo2A6Tqg= x-aol-sid: 3039ac1a32ad53befbb265f5 X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/k2N31f4BuZrx-6Z_yVU-dsy4t3Y Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:46:48 -0000 ------=_Part_1582_1339533867.1405025202692 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jim,=C2=A0 Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? =C2=A0In this case, there wouldn't be any Path Identifier= at all. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. From: jguichar@cisco.com To: NAPIERALA, MARIA H cc: Paul Quinn (paulq),Lucy yong,jmh= @joelhalpern.com,mohamed.boucadair@orange.com,sfc@ietf.org,mikebianc@aol.com Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" wrote: Paul, =20 How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? =20 Maria =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com;=20 mohamed.boucadair@orange.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Lucy,=20 =20 Overall I concur, as you say: a path ID drives the forwarding. I=E2=80=99d= make the minor change: the path identifier can be used to derive the neede= d forwarding and associated transport. =20 It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than a lookup, = that lookup can result in a one or more (equal or weighted) transport next = hop(s). =20 =20 Paul =20 On Jul 10, 2014, at 11:04 AM, Lucy yong wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. =20 Lucy =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers =20 Re-, =20 The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. =20 Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. =20 SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion. =20 Cheers, Med =20 De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers =20 Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. =20 To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. =20 =20 If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. =20 =20 =20 From: jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of=20 comments that have been made about the proposed merged archtiecture=20 draft. Assuming we can get working group agreement on the intent, we=20 will work to improve the wording so that readers who have not=20 participated in the WG discussion will understnd it the way the working=20 group intends. But what do we intend? I will try to explain my personal view, and see=20 if that helps. In this regard, it is important to keep in mind that what we are=20 defining is the data plane architecture. We are not attempting to=20 define the architecture for the entire solution for service chaining.=20 That would encompass OSS/BSS, various control and policy functions,=20 virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the=20 larger system, but which are dealt with above where we are functioning,=20 and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them,=20 I need to first discuss load balancing. There are at least three=20 different ways that load balancing can and will interact with service=20 chaining. There probably are more. The point of the archtiecture is to=20 permit all of these, but not to mandate that any particular kind be used=20 in any solution. 1) Load balancing as a service provided to the end user. This is a=20 service function. It receives user packets, and modifies them (or marks=20 them, or ...) so as to choose an end user service instance to receive=20 the users packet. This is an important service function to be able to=20 include in service chaining. It's behavior may affect requirements on=20 how service chaining is done. But it has very little impact on the=20 archtiecture. From an architectural pe3rspective it is simply a service=20 function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears=20 to the service chaining architecture as a single point of contact for a=20 specific service function, but is actually delivered by a collection of=20 virtual or physical machines, possibly including one or several load=20 balancers (for example using VRRP-like techniques to share a MAC=20 address.) mostly, this is invisible to the service chaining data plane=20 mechanisms. It is likely that it is visible to various control=20 mechanisms, such as those responsible for scale-in, scale-out, and vm=20 instantiation. The architectural impact of permitting this is largely=20 that we need to be careful that our terminology does not lead readers to=20 think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for=20 the service chaining that direct traffic to different places. We would=20 not want to require that a given service function appear at only one=20 place in the network. It is of course the case that these may be combined. I tend to refer to=20 the collection of entities that appear to service chaining as a single=20 point as a cluster. Not because cluster is a good term. But because I=20 do not have another one. Thus, the point of type 3 load balancing is to=20 direct different subsets of traffic to different singular or clustered=20 service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and=20 service path/ Service chain is a sequence of logical functions to be=20 applied to a subset of packets. It is equivalent of saying that some=20 subset of traffic is to get DPI, charging, content inspection, and=20 firewall while a different subset is to go directly to the cache without=20 visiting any other service functions. That is not enough information to direct the packets. A service path=20 is, in some fashion, a sequence of locations in the network. Those=20 locations will be singular or clustered service function delivery=20 locations. They may be addressed by IP address. They may be addressed=20 as ports on an SFF. There are many different ways that the locations=20 may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able=20 to talk about the high level abstraction, the service chain, which=20 drives the forwarding. And we need to talk about the actual data path=20 packets will take in the network. Several of the comments have said "but the whole path may not be known=20 at the front." This architecture deals with that issue in two ways.=20 First, as noted in item (2) on load balancers above, there can be=20 decisions and behaviors which are invisible to the service chaining=20 mechanisms (in much the same way that bridging within a LAN is largely=20 invisible to routing between LANs.) The other provision we make is that=20 reclassification can be done in mid-chain when necessary. That will=20 direct packets to a new chain. Based on information available at the=20 re-classification point. I hope that this helps explain what we are after. If it does, and if=20 the intent is acceptable to the working group, we can figure out what=20 additional words are needed to convey this. If the working group disagree with the intent, then we will of course=20 adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing 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 ------=_Part_1582_1339533867.1405025202692 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Jim, <= /div>

Technically, wouldn't this be a Chain Identifier i= f the next instance is chosen at each hop?  In this case, there wouldn= 't be any Path Identifier at all.

But it is the di= fference between a classifier needing to track the health, etc of 20^4 SF P= aths for a single SF Chain, vs each of the 80 instances tracking 20 SFIs of= the next-hop for the chains of which they are members vs each SFF in the e= ntire domain tracking all 80 SFIs vs something else.




Fr= om: jguichar@cisco.com<jguichar@cisco.com>
To: NAPIERAL= A, MARIA H<mn1921@att.com>
cc: Paul Quinn (paulq)<paulq@= cisco.com>,Lucy yong<lucy.yong@huawei.com>,jmh@joelhalpern.com<= jmh@joelhalpern.com>,mohamed.boucadair@orange.com<mohamed.boucadair@o= range.com>,sfc@ietf.org<sfc@ietf.org>,mikebianc@aol.com<mikebia= nc@aol.com>
Sent: Thursday, July 10, 2014
Subject: R= e: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=E2=80=99d make the minor change: the path identifier can be u= sed to derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By ha= ving a path identifier, the exact indirection that people seem to be asking= for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, = that lookup can result in a one or more (equal or weighted) transport next = hop(s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

Lucy

From: sfc [mailto:sfc-bounces@ietf.org<= /a>] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com= ; sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org<= /a>] De la part de mikebianc@aol.com
Envoy=C3=A9 : mercredi = 9 juillet 2014 22:03
=C3=80 : jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the differenc= e between SF Chain and SF Path? Other than clarifying the definition so th= at it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

______________________________________= _________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
------=_Part_1582_1339533867.1405025202692-- From nobody Thu Jul 10 13:47: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 665BD1B29F8 for ; Thu, 10 Jul 2014 13:46:51 -0700 (PDT) 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_29=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 R7ku85NCaBHF for ; Thu, 10 Jul 2014 13:46:49 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803A21B29F5 for ; Thu, 10 Jul 2014 13:46:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2A4B8861541; Thu, 10 Jul 2014 13:46:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id CDC66861543; Thu, 10 Jul 2014 13:46:47 -0700 (PDT) Message-ID: <53BEFBB7.2010400@joelhalpern.com> Date: Thu, 10 Jul 2014 16:46:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: huang@sce.carleton.ca, sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> In-Reply-To: <53BEF96A.4050808@sce.carleton.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IyL5W09L5pNXaC2pF582tij9uMI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:46:51 -0000 No, it will mean that if someone tries to deploy the archtieture particularly badly, they will exceed the limits of their devices. The architecture does not require such absurd use of service paths. Since I can not figure out how to write architectural words to prohibit it, the architecture does permit such abuse. Please do not read my saying that the archtiecture permits something as saying it is either deisred or required by the work. It isn't. Yours, Joel On 7/10/14, 4:36 PM, Changcheng Huang wrote: > If you need to support 100 service chains, it will mean 16,000,000 > paths. That is larger than the routing table of a core router. > > Chang > > On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> The architecture allows a range of deployments, from 1 service path to >> 160000 service paths. I would hope that operators are prepared for >> the complexities if they choose to avoid any use of local load >> balancing and in stead provision 160,000 service paths. >> >> Yours, >> Joel >> >> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>> Paul, >>> >>> How many path identifiers there will be for a 4 hop service chain with >>> 20 instances at each hop? >>> >>> Maria >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>> (paulq) >>> *Sent:* Thursday, July 10, 2014 3:03 PM >>> *To:* Lucy yong >>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >>> mikebianc@aol.com >>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Lucy, >>> >>> Overall I concur, as you say: a path ID drives the forwarding. I’d make >>> the minor change: the path identifier can be used to derive the needed >>> forwarding and associated transport. >>> >>> It is _not_ the transport, but rather is used to simply identify the >>> service path (or graph) that packets must traverse. By having a path >>> identifier, the exact indirection that people seem to be asking for on >>> this thread can be simply be implemented. The path identifier provides >>> nothing more than a lookup, that lookup can result in a one or more >>> (equal or weighted) transport next hop(s). >>> >>> Paul >>> >>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> > wrote: >>> >>> >>> >>> Agree. The arch. doc should not mandate only use of the service path >>> identifier to drive the forwarding actions. >>> >>> Lucy >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>> Of*mohamed.boucadair@orange.com >>> *Sent:*Thursday, July 10, 2014 2:06 AM >>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >>> ;sfc@ietf.org >>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Re-, >>> >>> The merged draft calls out explicitly a service path identifier. I >>> object to use that identifier to derive forwarding actions. >>> >>> Requiring a SFC system to have the full knowledge of every available SFC >>> forwarding paths within an SFC-enabled domain is not required/justified >>> nor possible in various deployment contexts. >>> >>> SFC forwarding actions should rely on the piece of information that will >>> be present in all deployments: that is the one required to structure a >>> service chain. How that information is used to infer forwarding actions >>> is a solution-oriented discussion. >>> >>> Cheers, >>> >>> Med >>> >>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >>> >>> *Envoyé :*mercredi 9 juillet 2014 22:03 >>> *À :*jmh@joelhalpern.com ;sfc@ietf.org >>> >>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Is anyone still questioning the difference between SF Chain and SF Path? >>> Other than clarifying the definition so that it's clear to those not >>> familiar with the draft, it seems that everyone agrees on these terms. >>> >>> To me, the one point that is still unclear is whether it is the intent >>> of this draft to ultimately specify what the ID of the SFC Header should >>> reference (the chain or the path), or if this draft simply intends to >>> leave that ambiguous, allowing other drafts to dictate the mechanisms >>> for forwarding based on chain or path and the choice of chain or path to >>> be negotiated in the control-plane. >>> >>> If the latter (ambiguous), then the draft would have require that both >>> SFP and SFC be supported (or make one required and the other optional) >>> to avoid some vendors only supporting SFP and others only supporting >>> SFC. >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*jmh@joelhalpern.com>> > >>> *To:*sfc@ietf.org> >>> *Sent:*Tuesday, July 8, 2014 >>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>> >>> I have been trying to figure out how to clearly answer a number of >>> comments that have been made about the proposed merged archtiecture >>> draft. Assuming we can get working group agreement on the intent, we >>> will work to improve the wording so that readers who have not >>> participated in the WG discussion will understnd it the way the working >>> group intends. >>> >>> But what do we intend? I will try to explain my personal view, and see >>> if that helps. >>> >>> In this regard, it is important to keep in mind that what we are >>> defining is the data plane architecture. We are not attempting to >>> define the architecture for the entire solution for service chaining. >>> That would encompass OSS/BSS, various control and policy functions, >>> virtual machine and image management, and many other aspects. >>> >>> As a result there are many things which clearly need to exist in the >>> larger system, but which are dealt with above where we are functioning, >>> and are not directly required by the work we are doing. >>> >>> In order to get to service chain vs service path, as I understand them, >>> I need to first discuss load balancing. There are at least three >>> different ways that load balancing can and will interact with service >>> chaining. There probably are more. The point of the archtiecture is to >>> permit all of these, but not to mandate that any particular kind be used >>> in any solution. >>> >>> 1) Load balancing as a service provided to the end user. This is a >>> service function. It receives user packets, and modifies them (or marks >>> them, or ...) so as to choose an end user service instance to receive >>> the users packet. This is an important service function to be able to >>> include in service chaining. It's behavior may affect requirements on >>> how service chaining is done. But it has very little impact on the >>> archtiecture. From an architectural pe3rspective it is simply a service >>> function which may modify the underlying packet. >>> >>> 2) There is internal load balancing. That is, one can have what appears >>> to the service chaining architecture as a single point of contact for a >>> specific service function, but is actually delivered by a collection of >>> virtual or physical machines, possibly including one or several load >>> balancers (for example using VRRP-like techniques to share a MAC >>> address.) mostly, this is invisible to the service chaining data plane >>> mechanisms. It is likely that it is visible to various control >>> mechanisms, such as those responsible for scale-in, scale-out, and vm >>> instantiation. The architectural impact of permitting this is largely >>> that we need to be careful that our terminology does not lead readers to >>> think we are prohibiting it. >>> >>> 3) There can also be load balancing done by selecting packet paths for >>> the service chaining that direct traffic to different places. We would >>> not want to require that a given service function appear at only one >>> place in the network. >>> >>> It is of course the case that these may be combined. I tend to refer to >>> the collection of entities that appear to service chaining as a single >>> point as a cluster. Not because cluster is a good term. But because I >>> do not have another one. Thus, the point of type 3 load balancing is to >>> direct different subsets of traffic to different singular or clustered >>> service functions in different places in the network. >>> >>> Now with that said, what do I mean when I talk about service chain and >>> service path/ Service chain is a sequence of logical functions to be >>> applied to a subset of packets. It is equivalent of saying that some >>> subset of traffic is to get DPI, charging, content inspection, and >>> firewall while a different subset is to go directly to the cache without >>> visiting any other service functions. >>> >>> That is not enough information to direct the packets. A service path >>> is, in some fashion, a sequence of locations in the network. Those >>> locations will be singular or clustered service function delivery >>> locations. They may be addressed by IP address. They may be addressed >>> as ports on an SFF. There are many different ways that the locations >>> may be known to the service chaining infrastructure and the transport. >>> >>> >From the point of view of the work of the SFC group, we need to be >>> able >>> to talk about the high level abstraction, the service chain, which >>> drives the forwarding. And we need to talk about the actual data path >>> packets will take in the network. >>> >>> Several of the comments have said "but the whole path may not be known >>> at the front." This architecture deals with that issue in two ways. >>> First, as noted in item (2) on load balancers above, there can be >>> decisions and behaviors which are invisible to the service chaining >>> mechanisms (in much the same way that bridging within a LAN is largely >>> invisible to routing between LANs.) The other provision we make is that >>> reclassification can be done in mid-chain when necessary. That will >>> direct packets to a new chain. Based on information available at the >>> re-classification point. >>> >>> I hope that this helps explain what we are after. If it does, and if >>> the intent is acceptable to the working group, we can figure out what >>> additional words are needed to convey this. >>> If the working group disagree with the intent, then we will of course >>> adjust to match the working group agreements. >>> If this is still unclear, I am not sure what to try next. >>> >>> Yours, >>> Joel >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 10 13:50: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 7CA6C1B2A03 for ; Thu, 10 Jul 2014 13:50:10 -0700 (PDT) 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_22=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 Lo7i3vd7YPDc for ; Thu, 10 Jul 2014 13:50:07 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7301B2A00 for ; Thu, 10 Jul 2014 13:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 4AFAC861543; Thu, 10 Jul 2014 13:50:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 94DB4861541; Thu, 10 Jul 2014 13:50:03 -0700 (PDT) Message-ID: <53BEFC7B.2020106@joelhalpern.com> Date: Thu, 10 Jul 2014 16:50:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: huang@sce.carleton.ca, Sam Aldrin References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> <53BEEDC3.6000305@sce.carleton.ca> <5F9AFA04-5604-4E33-B0B1-09F8A24FA8B5@gmail.com> <53BEFB8A.7040800@sce.carleton.ca> In-Reply-To: <53BEFB8A.7040800@sce.carleton.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KNUqKkzelMRSf76TAu-9BIRh370 Cc: "sfc@ietf.org" Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:50:10 -0000 If the packet does not carry enough information to identify the subscriber, as has been described in several use casess, there appears to be no choice other than to attach some subscriber identifying aidditional information tothe packet. Sending it separately from the packet simply won't work. That is clearly metadata, and it seems clear to me that it needs to be attached to the packet. That does not mean that there are not other cases where out-of-band delivery of various sorts may also be useful. I am not against using that as well. Yours, Joel On 7/10/14, 4:46 PM, Changcheng Huang wrote: > The most common small packets are TCP Ack packets which are around 64 > bytes long including headers from various layers (MAC, IP, TCP) and some > padded payloads to make it satisfy minimum packet size requirement. > Adding metadata to this kind of packets does not make sense to me. > > Chang > > On 07/10/2014 01:22 PM, Sam Aldrin wrote: >> I agree . As SFC is established in a controlled domain, mitigating >> options are better than general internet. Again need to see how much >> of an overhead it really causes and it's side effects. >> >> Sam >> >> Sent from my iPad >> >> On Jul 10, 2014, at 12:47 PM, Changcheng Huang > > wrote: >> >>> Even the SFC is limited to a specific domain (such as a datacenter), >>> the packet sizes still follow the same distribution. The bandwidth >>> within a datacenter is still a bottleneck part due to traffic >>> patterns such as incast. >>> >>> Chang >>> >>> On 07/10/2014 12:02 PM, Sam Aldrin wrote: >>>> >>>> >>>> On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang >>>> > wrote: >>>> >>>> I am concerned with the overhead metadata may create. Internet >>>> packet sizes tend to be bimodal where more than 50% of packets >>>> have very small packet sizes. Carrying large amounts of overhead >>>> will reduce throughput significantly. Making metadata optional >>>> may be a good choice. >>>> >>>> Doesn't that depend only if the SFC spans across the internet? >>>> Otherwise it (overhead) should be limited to SFC's domain, which may >>>> not span across internet, no? >>>> >>>> cheers >>>> -sam >>>> >>>> >>>> Regards, >>>> >>>> Chang >>>> >>>> >>>> On 07/10/2014 11:22 AM, Joel M. Halpern wrote: >>>> >>>> I look forward to seeing your draft. >>>> >>>> One of the reasons I like including the metadata with the >>>> underlying packet is that they then share fate. If the >>>> packet gets lost, the metadata disappears with it, which is >>>> frequently fine. And if the packet is probably delviered >>>> down the service path, then so is the metadata. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >>>> >>>> Hello, >>>> >>>> Metadata transport is a feature provided by SFC that >>>> needs some >>>> additional thoughts as well. >>>> >>>> B Rijsman has done a great job showing various option >>>> for Metadata >>>> sharing. Still there are 2 aspects that I would like to >>>> address further >>>> >>>> - Metadata representation >>>> >>>> - Metadata transport reliability >>>> >>>> We will probably post a draft on the subject, but this >>>> can be done after >>>> Toronto has started. So for those >>>> interested to provide some feedback, here are some >>>> highlights. >>>> >>>> *1. Problem Space* >>>> * Metadata representation* >>>> Metadata can be extremely varied in term of usage and >>>> content. It can >>>> represent the result of Deep Packet Inspection (DPI) >>>> performed on the >>>> traffic for example by the Classifier Service Function >>>> at the ingress of >>>> the Service Function Chain. It can contain information >>>> collected about >>>> the end user such as a policy identifier, a category or >>>> even represent >>>> an event related to the end-user session. >>>> This information can be used by Service Functions on the >>>> chain, as well >>>> as by monitoring entities responsible to track usage for >>>> example in the >>>> Network Function Virtualization environment to feed a >>>> VNF manager or an >>>> Orchestrator. >>>> Metadata being information shared by many network >>>> entities needs some >>>> means to be represented it in all of its dimensions: >>>> type definition, >>>> encoding and scope. >>>> * Metadata transport service* >>>> As expected from service chain proposals, both NSH and >>>> SCH proposals >>>> define some means to carry metadata between Service >>>> Functions in a >>>> Chain. They can be classified as follow: >>>> Dataplane Metadata: >>>> are defined in the Service Function Chaining Problem >>>> Statement document. >>>> They are not considered to be part of the forwarding >>>> information of the >>>> SFC header. However they are expected to carry the >>>> result of antecedent >>>> classification, allowing Service Functions to take local >>>> policy >>>> decisions based on their values. >>>> >>>> As such, they could also be interpreted directly by >>>> Service Function >>>> Forwarder to steer traffic to various Service Functions. >>>> Offline Metadata: >>>> Beyond Dataplane Metadata, Offline Metadata can be >>>> shared between >>>> Service Functions in a chain, using out of band, >>>> congruent or not, or >>>> hybrid models described in [RIJSMAN] >>>> >>>> The hybrid model for example, defined in [RIJSMAN], >>>> utilizes the SFC >>>> header to transport some key values for correlation >>>> purposes. These >>>> Correlation Ids can be used by the Service Functions to >>>> recover the full >>>> associated contextual information. >>>> Metadata, directly or indirectly, are transported hop by >>>> hop along a >>>> chain, in association to end-user traffic, the data >>>> payload of the SFC >>>> packets. >>>> How these metadata are transported over a chain matters. >>>> Passing >>>> metadata directly or indirectly along packets is a >>>> service that must be >>>> analyzed from a reliability point of view. >>>> >>>> Reliability requirements may vary depending on the >>>> nature of the >>>> metadata transported. Past experience for example in >>>> Mobile Network and >>>> data center with AAA Radius have shown that contextual >>>> information >>>> replication to various service function was indeed >>>> sensitive to packet >>>> loss events, and that adhoc solutions had to be >>>> implemented to detect them. >>>> End to end TCP retransmission of packet lost does not >>>> ensure that >>>> associated Metadata will be reinserted in retransmitted >>>> packet. In >>>> addition, Event triggered metadata may have to be sent >>>> immediately on a >>>> chain even though no end-user traffic is being transmitted >>>> Not all metadata needs a reliable transport. Repeated >>>> inline metadata >>>> can be used to cover several use cases, and some >>>> metadata loss can be >>>> acceptable. >>>> Still, a reliable transport service for Metadata in SFC >>>> is expected. To >>>> this effect, an implementation is suggested in Section 3.3 >>>> *2. Metadata representation* >>>> Metadata definition is that it provides contextual >>>> information about the >>>> data packets which traverse a Service Function Chain. >>>> This must be >>>> understood broadly. >>>> Metadata can contain the result of traffic >>>> classification by Deep Packet >>>> Inspection (DPI). For example as an Application Id >>>> information which is >>>> tied to a traffic flow. There could be multiple flows >>>> with different >>>> application ids, in a chain. >>>> Metadata can also contain the result of DPI data >>>> extraction, such as >>>> identify requested URL in HTTP. Such information can be >>>> passed to >>>> certain SF down the chain such as a URL filtering function. >>>> Metadata can contain some punctual event information >>>> collected at the >>>> Ingress point of the chain and expected to be passed to >>>> all elements in >>>> the chain. Here this information may be triggered >>>> externally and >>>> generated only once, and be related to the tenant or the >>>> subscriber. >>>> Metadata representation involves the definition of a set >>>> of information >>>> elements types and the encoding rules for their values. >>>> Metadata representation can sometimes be performed by a >>>> single >>>> individual field with associated type and format. >>>> However, it is not >>>> always enough. >>>> >>>> * Metadata may need multiple fields transported >>>> together to >>>> represented their values. >>>> * Some addition fields may be required to describe the >>>> scope of the >>>> metadata itself. This can be any information element >>>> allowing to >>>> define the context of the associated metadata value. >>>> For example a >>>> throughput metadata field can have a port number and >>>> a switch >>>> address as its Scope information. >>>> >>>> We explore these two axis: encoding and scope. >>>> We propose IPFIX as a preferred means to represent >>>> Metadata in Service >>>> Chain messages for Out-of-band, Congruent or not; >>>> Metadata sharing. >>>> *2.1. Metadata Representation Requirements* >>>> Mandatatory Dataplane Metadata is always part of the SFC >>>> header, it is >>>> thus reasonable to consider that its representation >>>> scheme will be >>>> implicit: based on what the SFC protocol will dictate, >>>> their position in >>>> the SFC header is sufficient for the receiving end to >>>> infer their type >>>> and encoding scheme. For example, Context Header Fields >>>> in NSH are 32 >>>> bit fields. >>>> However, it will not be the case for all metadata >>>> transported. Offline >>>> metadata, including congruent out-of-band metadata still >>>> need to be >>>> represented explicitly. This section addresses their >>>> specific case. >>>> *2.1.1. Metadata Encoding requirements* >>>> These requirements are applicable to out-of-band >>>> metadata (Congruent or >>>> not). It could be applicable with SCH on optional >>>> in-line metadata fields. >>>> For interoperability purposes, metadata encoding MUST >>>> allow the >>>> receiving entity to identify the type and value of the >>>> information >>>> received as metadata >>>> Metadata encoding MUST allow for encoding techniques >>>> supporting well >>>> known types and fields as well as proprietary extensions. >>>> A receiving entity MUST be able to identify when >>>> incoming metadata type >>>> is unknown and MUST have a defined default action to >>>> handle it. >>>> A piece of information may need multiple fields to be >>>> described. For >>>> example a tenant id and an ip address can be used to >>>> identify an server >>>> in a data center uniquely. >>>> These groups of information have to be exchanged >>>> collectively, in a >>>> single message. In this case, a sending entity MUST >>>> specify that it is >>>> sending a set of metadata in a message. >>>> This set of transported metadata elements MUST be >>>> specified under the >>>> form of a metadata template document uniquely defined >>>> for the chain. >>>> A receiving entity MUST be able to detect if an incoming >>>> message >>>> contains its expected set of metadata elements. >>>> *2.1.2. Metadata Scope requirement* >>>> A piece of information may have to be qualified by some >>>> attributes >>>> allowing to identify its particular scope. For example >>>> in a Gi >>>> environment, the radio type in use may be used as a >>>> scoping criteria for >>>> a jitter or latency measurement in a video traffic >>>> transported in a >>>> particular service chaing. >>>> Scope can apply to some individual metadata elements or >>>> to a set of >>>> metadata elements. How a scope applies to a set of >>>> transported metadata >>>> elements should be defined by a specification under the >>>> form of a >>>> metadata template document uniquely identified for the >>>> chain. >>>> *2.2. IPFIX Metadata representation* >>>> So far, unordered sequences of Type Length Value encoded >>>> fields have >>>> been proposed to transport metadata. It is not clear how >>>> structured >>>> types are supported, and no distinction is done between >>>> the metadata >>>> values and their scoping values. Although the SCH >>>> proposal provides an >>>> optional 24-bit Organizational Unique Identifier, there >>>> is no namespace >>>> mechanism allowing to separate type definition spaces >>>> per Tenants or per >>>> chain. >>>> We suggest to leverage the work done by IETF on similar >>>> subject. >>>> A natural candidate to leverage is IPFIX [RFC7011]: >>>> IPFIX is a means for >>>> transmitting Traffic Flow information over the network. >>>> In order to >>>> transmit Traffic Flow information, it provides a common >>>> representation >>>> of flow data and a standard means of communicating them. >>>> Metadata collected by Network Node and Service Node >>>> SHOULD be encoded in >>>> template following the principles described in >>>> IPFIX[RFC7011]. >>>> An IPFIX Message consisting of interleaved Template, >>>> Data, and Options >>>> Template Sets, as shown in Figure 1. Here, Template and >>>> Options Template >>>> Sets , which are optional, are shown. >>>> >>>> >>>> +--------+--------------------------------------------------------+ >>>> | | +----------+ +---------+ +-----------+ >>>> +---------+ | >>>> |Message | | Template | | Data | | Options | | >>>> Data | | >>>> | Header | | Set | | Set | ... | Template >>>> | | Set | | >>>> | | | | | | | Set | | >>>> | | >>>> | | +----------+ +---------+ +-----------+ >>>> +---------+ | >>>> +--------+--------------------------------------------------------+ >>>> >>>> >>>> >>>> Figure 1: IPFIX Message Format >>>> The Template Set describes the data transmitted in the >>>> following Data >>>> Set. It is an optional component of the message. The >>>> value of the >>>> metadata is encoded in the first Data Set. This Data Set >>>> contains a >>>> template Id field as a reference to its defining >>>> Template Set. >>>> The Options Template Set describes the data to be >>>> transmitted as scope >>>> information. It is an optional component of the message. >>>> The value of >>>> the scope information is encoded in the second Data Set >>>> element. It no >>>> scope information is present, then only the first Data >>>> Set is present in >>>> the message. >>>> The Option Template Set and following Data Set are used >>>> to describe the >>>> scope of the metadata transmitted. For example, the >>>> metadata collected >>>> is relevant to a PDP Context or a particular line card >>>> of a particular >>>> switch. >>>> * >>>> * >>>> *2.2.4.3. Example:* >>>> The Metadata Exporting Process creates a Template Record >>>> with a few >>>> Information Elements: amongst other things, the >>>> Application Id. For example: >>>> >>>> - sourceIPv4Address (key field) >>>> - destinationIPv4Address (key field) >>>> - protocol (key field) >>>> - destinationTransportPort (key field) >>>> - applicationId (key field) >>>> - octetTotalCount (non key field) >>>> >>>> For example, a Flow Record corresponding to the >>>> above >>>> Template Record may contain: >>>> >>>> { sourceIPv4Address=192.0.2.1, >>>> destinationIPv4Address=192.0.2.2, >>>> protocol=17, >>>> destinationTransportPort=23, >>>> applicationId='3..80', >>>> octetTotalCount=123456 } >>>> >>>> >>>> >>>> The Options Data Record associated with the examples >>>> above would contain >>>> the Scoping inforamtion: >>>> >>>> Scope: >>>> - servicePath, >>>> - serviceIndex, >>>> - applicationId, >>>> - applicationName >>>> - applicationDescription. >>>> >>>> For example: >>>> >>>> { >>>> servicePath=0x000b, >>>> serviceIndex=0x000c, >>>> applicationId='13...10000', >>>> applicationName="webex", >>>> applicationDescription="Webex application" } >>>> >>>> >>>> >>>> Scope information is useful when sending metadata >>>> offline, as it can >>>> contain information related to the chain and possibly to >>>> the flow for >>>> which this metadata record is relevant. Here servicePath and >>>> serviceIndex are thus included in the Template. >>>> *2.2.4.4. IPFIX encoding and template provisioning:* >>>> IPFIX is a quite compact encoding >>>> For a template defined as followed and shared by the SF >>>> in a chain. >>>> IPFIX template record shared by SF: >>>> Note that an XML representation of IPFIX template record >>>> could be >>>> defined and used to provision Service Functions. >>>> >>>> 0 1 2 >>>> 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>> 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Set ID = 2 | Length = 28 >>>> octets | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Template ID 256 | Field Count = 5 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |0| sourceIPv4Address = 8 | Field Length = 4 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |0| destinationIPv4Address = 12 | Field Length = 4 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |0| ipNextHopIPv4Address = 15 | Field Length = 4 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |0| packetDeltaCount = 2 | Field Length = 4 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |0| octetDeltaCount = 1 | Field Length = 4 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> Figure 7: IPFIX Metadata template Encoding >>>> An encoded IP fix transport message will be: >>>> >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>> 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Version Number | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Export Time >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Sequence Number >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Observation Domain ID >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Set ID = 256 | Length = 64 >>>> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 192.0.2.12 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 192.0.2.254 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 192.0.2.1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 5009 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 5344385 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> >>>> Figure 8: IPFIX Metadata Encoding >>>> *3. Metadata transport service* >>>> These different use cases for Metadata generate some >>>> requirements on the >>>> reliability capabilities of the Metadata transport >>>> service they will >>>> rely on. >>>> De facto Service Function Chain proposals such as NSH >>>> and SCH define a >>>> mechanism for sharing information along the Chains. It >>>> is thus important >>>> to define this transport service in term of reliability. >>>> The primary focus of these proposal are the Metadata >>>> elements playing a >>>> role in the Service Function Chain deployment to apply >>>> policies on >>>> incoming traffic at some relevant Service Functions. >>>> For example, Network Orchestration is expected to be a >>>> significant >>>> driver for deployment of Network Services. It relies on >>>> Service Level >>>> abstractions such as Group Policies, Contracts and >>>> Services as an input >>>> for the orchestration of Service Function Chains. >>>> Specific metadata >>>> attributes such as L4-L7 fields are used as >>>> classification elements or >>>> filters to funnel packets into chains. >>>> Service Functions may have other needs for Metadata, for >>>> example Event >>>> Based Metadata tied to some subscriber related state >>>> changes. The >>>> complexity and length of these elements cannot be >>>> forseen as limited, >>>> neither can be how critical it is that they are safely >>>> carried >>>> throughout a chain. In the following Section we propose >>>> to take >>>> avantage of Congruent Metadata Transport can be used, >>>> possibly reliably, >>>> to address these needs. >>>> *3.1. Proposed Metadata transport mechanisms* >>>> . >>>> *3.1.3. Metadata transport analysis* >>>> Both NSH and SCH proposals support both inbound and >>>> offline out-of-band >>>> metadata transport. >>>> >>>> 1. In-band: the metadata can be included directly as a >>>> value in some of >>>> the NSH Context Header Fields. It is the preferred >>>> transport model >>>> for SCH. >>>> >>>> In such case, when a particular field is always set >>>> to the same >>>> value for all packets transported by the chain >>>> instance, then the >>>> metadata transport service is in effect reliable. >>>> >>>> Similarly, all the packet for a particular flow >>>> (defined by its 5 >>>> tupple), could receive the same metadata value. The >>>> metadata >>>> transport service is also reliable, provided that >>>> the value is >>>> understood to be attached to a flow. >>>> >>>> The general case however, occurs when the metadata >>>> varies from >>>> packet to packet in a flow. The value is then tied >>>> to a specific >>>> packet. Here the transport service is not reliable. >>>> A retransmission >>>> of a particular packet would not necessarily lead it >>>> to carry the >>>> same metadata value. >>>> 2. Out-of-band: a reference for some metadata is sent >>>> along a packet so >>>> that it can be used via an interaction with a >>>> controller entity. It >>>> is the preferred model for NSH, but could also be >>>> used by SCH. >>>> >>>> As for the in-band case, the metadata referred to >>>> indirectly can be >>>> transmitted reliably, when its value remains the >>>> same for a chain or >>>> a flow in a chain. a chain or a flow in a chain. >>>> >>>> If however, the correlation Id passed changes over >>>> time, or if the >>>> Metadata itself cahanges then the correct Metadata >>>> may not be >>>> efficiently retrieved by some Service Functions. >>>> >>>> We can see that NSH and SCH do not address the need for >>>> a reliable >>>> transport service for metadata, independantly of the >>>> reliability >>>> characteristic of the transport service used for the >>>> data packets. >>>> Conventions can be used as particular cases when some >>>> metadata pertains >>>> to a specific chain or a flow in the chain, and when its >>>> value does not >>>> change overtime. >>>> Such conventions however are weak. They would suppose >>>> that some >>>> mechanism exists to ensure/monitor that they are >>>> followed. And some >>>> exceptions mechanism would be required to deal with >>>> error cases. >>>> *3.2. Support for Congruent out-of-band transport service* >>>> Congruent out-of-band metadata sharing can be required >>>> for some types of >>>> Metadata exchanges. It has the advantage of clearly >>>> tying the metadata >>>> to the chain and not to a specific packet, and to avoid >>>> payload >>>> fragmentation issues. >>>> Up to draft 2, NSH did not allow for long inline >>>> metadata transport. >>>> Four 32 bits context fields are reserved for that >>>> purpose, and seem best >>>> suited for offline Metadata sharing, or to transport >>>> predefined policy >>>> identifiers. >>>> NSH (since draf 3) as well as SCH could allow for >>>> metadata transport, >>>> either tied to a packet or possibly tied to the chain, >>>> when used without >>>> payload, as signaling messages. >>>> SCH however stipulates that in case the Path Identifier >>>> and SF Index >>>> fields shall be set to zero for transmit and ignored >>>> upon receipt, when >>>> the SCH packet will contain only metadata. So congruent >>>> out-of-band >>>> metadata, transporting Metadata hop to hop to the >>>> various Service >>>> Function in the chain, does not seem to be supported. >>>> NSH supports inline variable size metadata. It does not >>>> mentions >>>> explicitly that congruent out-of-band metadata can be used. >>>> *3.3. Reliable transport service* >>>> Some metadata will need a reliable transport service to >>>> be shared >>>> inline, as well as offline. >>>> A protocol SCTP provides such a service and has the >>>> interesting >>>> characteristic to be packet based, as opposed to stream >>>> based like TCP. >>>> SCTP carries a sequence number and support >>>> retransmission and congestion >>>> control. >>>> Figure 12 shows how SCTP is used hop by hop between SFF >>>> in a chain to >>>> transport Metadata reliably. >>>> >>>> |1 ----- |n |21 ---- |2m >>>> +---+---+ +---+---+ +-+---+ >>>> +--+-----+ >>>> | SF#1 | |SF#n | |SF#i1| >>>> |SF#im | >>>> | | | | | | | >>>> | >>>> +---+---+ +---+---+ +--+--+ >>>> +--+--+--+ >>>> : : : : : >>>> : : : : : >>>> \ / \ / >>>> +-----------+ SCTP +--------+ SCTP +---------+ >>>> -- >| Chain | <---> | SFF | <---> | SFF >>>> | ----> >>>> |classifier | |Node-1 | | Node-i | >>>> +-----------+ +----+---+ +----+--+-+ >>>> \ | / >>>> \ | SFC Encapsulation / >>>> \ | / >>>> ,........................................ >>>> / \ >>>> / \ >>>> | Network | >>>> \ / >>>> \........................................./ >>>> >>>> >>>> >>>> Figure 12: SCTP for Reliable Metadata transport >>>> SCTP SHOULD be used in the context of Congruent out of >>>> band for reliable >>>> metadata sharing. >>>> For reliable Metadata transport, the SFF along the chain >>>> MUST route the >>>> metadata received over SCTP to the next SF in the chain. >>>> For this SCTP >>>> MUST be encapsulated in the SFC header. >>>> The SFF MUST make the received metadata available >>>> to its SF.ti >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing 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 Jul 10 13:57: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 643061B29FA for ; Thu, 10 Jul 2014 13:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 f_VeVJojeiAf for ; Thu, 10 Jul 2014 13:57:44 -0700 (PDT) Received: from omr-d07.mx.aol.com (omr-d07.mx.aol.com [205.188.109.204]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACB71B29F8 for ; Thu, 10 Jul 2014 13:57:43 -0700 (PDT) Received: from mtaout-mbd01.mx.aol.com (mtaout-mbd01.mx.aol.com [172.26.252.13]) by omr-d07.mx.aol.com (Outbound Mail Relay) with ESMTP id 00D857029DFE1; Thu, 10 Jul 2014 16:57:43 -0400 (EDT) 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-mbd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B4F9A38000090; Thu, 10 Jul 2014 16:57:42 -0400 (EDT) Date: Thu, 10 Jul 2014 16:57:42 -0400 From: "mikebianc@aol.com" To: jmh@joelhalpern.com, huang@sce.carleton.ca, sfc@ietf.org Message-ID: <1136706129.1640.1405025862623.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <53BEFBB7.2010400@joelhalpern.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1639_725563685.1405025862622" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405025862; bh=muAZxwAFT7Drh8cWmSEMHOYOdpUo0Vk/alv5j6ogoqY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=h8j2YxldaChMmbmglY3kzRRDTS7GG5Y0NgvqMK6O5RbY2NQaNG4u3psok8KMTeEqb nPHLVUkKOWhPC5zRAFo2RpA5OsGMKfxBvse47N269Deiq/S2MGGi9Y3qOMn0LNlyVo 8pQlY0GxjIgIiIs9AYWCu2DEQ6/ffWv5SxeEVFr8= x-aol-sid: 3039ac1afc0d53befe467400 X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/n1EEIQ3KvBHLIemU7B6s86wbmNU Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 20:57:47 -0000 ------=_Part_1639_725563685.1405025862622 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. =C2=A0Many protocols allow you to do stupid things, but don't prohibit= them as they may make sense in smaller deployments. =C2=A0 e.g. I could build a global 2000 node OSPF network all in area 0, redistrib= uting all links as external LSAs, and still not violate the standard. From: jmh@joelhalpern.com To: , Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers No, it will mean that if someone tries to deploy the archtieture=20 particularly badly, they will exceed the limits of their devices. The architecture does not require such absurd use of service paths. Since I can not figure out how to write architectural words to prohibit=20 it, the architecture does permit such abuse. Please do not read my saying that the archtiecture permits something as=20 saying it is either deisred or required by the work. It isn't. Yours, Joel On 7/10/14, 4:36 PM, Changcheng Huang wrote: > If you need to support 100 service chains, it will mean 16,000,000> paths= . That is larger than the routing table of a core router.>> Chang>> On 07/1= 0/2014 01:15 PM, Joel M. Halpern wrote:>> The architecture allows a range o= f deployments, from 1 service path to>> 160000 service paths. I would hope= that operators are prepared for>> the complexities if they choose to avoid= any use of local load>> balancing and in stead provision 160,000 service p= aths.>>>> Yours,>> Joel>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>= >> Paul,>>>>>> How many path identifiers there will be for a 4 hop service = chain with>>> 20 instances at each hop?>>>>>> Maria>>>>>> *From:*sfc [mailt= o:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn>>> (paulq)>>> *Sent:* Thu= rsday, July 10, 2014 3:03 PM>>> *To:* Lucy yong>>> *Cc:* jmh@joelhalpern.co= m; mohamed.boucadair@orange.com; sfc@ietf.org;>>> mikebianc@aol.com>>> *Sub= ject:* Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>> Lucy,>>>>>= > Overall I concur, as you say: a path ID drives the forwarding. I=E2=80=99= d make>>> the minor change: the path identifier can be used to derive the n= eeded>>> forwarding and associated transport.>>>>>> It is _not_ the transpo= rt, but rather is used to simply identify the>>> service path (or graph) th= at packets must traverse. By having a path>>> identifier, the exact indire= ction that people seem to be asking for on>>> this thread can be simply be = implemented. The path identifier provides>>> nothing more than a lookup, t= hat lookup can result in a one or more>>> (equal or weighted) transport nex= t hop(s).>>>>>> Paul>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> > wrote:>>>>>>>>>>>> Agree. T= he arch. doc should not mandate only use of the service path>>> identifier = to drive the forwarding actions.>>>>>> Lucy>>>>>> *From:*sfc [mailto:sfc-bo= unces@ietf.org]*On Behalf>>> Of*mohamed.boucadair@orange.com >>> *Sent:*Thursday, July 10, 2014 2:06 AM>>> *To:*m= ikebianc@aol.com ;jmh@joelhalpern.com>>> ;sfc@ietf.org >>> *Subject:*Re: [s= fc] Service Chains, Paths, and Load Balancers>>>>>> Re-,>>>>>> The merged d= raft calls out explicitly a service path identifier. I>>> object to use tha= t identifier to derive forwarding actions.>>>>>> Requiring a SFC system to = have the full knowledge of every available SFC>>> forwarding paths within a= n SFC-enabled domain is not required/justified>>> nor possible in various d= eployment contexts.>>>>>> SFC forwarding actions should rely on the piece o= f information that will>>> be present in all deployments: that is the one r= equired to structure a>>> service chain. How that information is used to in= fer forwarding actions>>> is a solution-oriented discussion.>>>>>> Cheers,>= >>>>> Med>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikeb= ianc@aol.com>>> >>> *Envoy=C3=A9 :*mercredi 9 jui= llet 2014 22:03>>> *=C3=80 :*jmh@joelhalpern.com ;sfc@ietf.org>>> >>> *Objet :*Re: [sfc] Service Chai= ns, Paths, and Load Balancers>>>>>> Is anyone still questioning the differe= nce between SF Chain and SF Path?>>> =C2=A0 Other than clarifying the defin= ition so that it's clear to those not>>> familiar with the draft, it seems = that everyone agrees on these terms.>>>>>> To me, the one point that is sti= ll unclear is whether it is the intent>>> of this draft to ultimately speci= fy what the ID of the SFC Header should>>> reference (the chain or the path= ), or if this draft simply intends to>>> leave that ambiguous, allowing oth= er drafts to dictate the mechanisms>>> for forwarding based on chain or pat= h and the choice of chain or path to>>> be negotiated in the control-plane.= >>>>>> If the latter (ambiguous), then the draft would have require that bo= th>>> SFP and SFC be supported (or make one required and the other optional= )>>> to avoid some vendors only supporting SFP and others only supporting>>= > SFC.>>>>>> --------------------------------------------------------------= ---------->>>>>> *From:*jmh@joelhalpern.com>> >>>> *To:*sfc@ietf.org>>>> *Sent:*Tuesday, July 8, 2014>>>= *Subject:*[sfc] Service Chains, Paths, and Load Balancers>>>>>> I have bee= n trying to figure out how to clearly answer a number of>>> comments that h= ave been made about the proposed merged archtiecture>>> draft. Assuming we = can get working group agreement on the intent, we>>> will work to improve t= he wording so that readers who have not>>> participated in the WG discussio= n will understnd it the way the working>>> group intends.>>>>>> But what do= we intend? I will try to explain my personal view, and see>>> if that help= s.>>>>>> In this regard, it is important to keep in mind that what we are>>= > defining is the data plane architecture. We are not attempting to>>> defi= ne the architecture for the entire solution for service chaining.>>> That w= ould encompass OSS/BSS, various control and policy functions,>>> virtual ma= chine and image management, and many other aspects.>>>>>> As a result there= are many things which clearly need to exist in the>>> larger system, but w= hich are dealt with above where we are functioning,>>> and are not directly= required by the work we are doing.>>>>>> In order to get to service chain = vs service path, as I understand them,>>> I need to first discuss load bala= ncing. There are at least three>>> different ways that load balancing can a= nd will interact with service>>> chaining. There probably are more. The poi= nt of the archtiecture is to>>> permit all of these, but not to mandate tha= t any particular kind be used>>> in any solution.>>>>>> 1) Load balancing a= s a service provided to the end user. This is a>>> service function. It rec= eives user packets, and modifies them (or marks>>> them, or ...) so as to c= hoose an end user service instance to receive>>> the users packet. This is = an important service function to be able to>>> include in service chaining.= It's behavior may affect requirements on>>> how service chaining is done. = But it has very little impact on the>>> archtiecture. From an architectural= pe3rspective it is simply a service>>> function which may modify the under= lying packet.>>>>>> 2) There is internal load balancing. That is, one can h= ave what appears>>> to the service chaining architecture as a single point = of contact for a>>> specific service function, but is actually delivered by= a collection of>>> virtual or physical machines, possibly including one or= several load>>> balancers (for example using VRRP-like techniques to share= a MAC>>> address.) mostly, this is invisible to the service chaining data = plane>>> mechanisms. It is likely that it is visible to various control>>> = mechanisms, such as those responsible for scale-in, scale-out, and vm>>> in= stantiation. The architectural impact of permitting this is largely>>> that= we need to be careful that our terminology does not lead readers to>>> thi= nk we are prohibiting it.>>>>>> 3) There can also be load balancing done by= selecting packet paths for>>> the service chaining that direct traffic to = different places. We would>>> not want to require that a given service func= tion appear at only one>>> place in the network.>>>>>> It is of course the = case that these may be combined. I tend to refer to>>> the collection of en= tities that appear to service chaining as a single>>> point as a cluster. N= ot because cluster is a good term. But because I>>> do not have another one= . Thus, the point of type 3 load balancing is to>>> direct different subset= s of traffic to different singular or clustered>>> service functions in dif= ferent places in the network.>>>>>> Now with that said, what do I mean when= I talk about service chain and>>> service path/ Service chain is a sequenc= e of logical functions to be>>> applied to a subset of packets. It is equiv= alent of saying that some>>> subset of traffic is to get DPI, charging, con= tent inspection, and>>> firewall while a different subset is to go directly= to the cache without>>> visiting any other service functions.>>>>>> That i= s not enough information to direct the packets. A service path>>> is, in so= me fashion, a sequence of locations in the network. Those>>> locations will= be singular or clustered service function delivery>>> locations. They may = be addressed by IP address. They may be addressed>>> as ports on an SFF. Th= ere are many different ways that the locations>>> may be known to the servi= ce chaining infrastructure and the transport.>>>>>> >From the point of vie= w of the work of the SFC group, we need to be>>> able>>> to talk about the = high level abstraction, the service chain, which>>> drives the forwarding. = And we need to talk about the actual data path>>> packets will take in the = network.>>>>>> Several of the comments have said "but the whole path may no= t be known>>> at the front." This architecture deals with that issue in two= ways.>>> First, as noted in item (2) on load balancers above, there can be= >>> decisions and behaviors which are invisible to the service chaining>>> = mechanisms (in much the same way that bridging within a LAN is largely>>> i= nvisible to routing between LANs.) The other provision we make is that>>> r= eclassification can be done in mid-chain when necessary. That will>>> direc= t packets to a new chain. Based on information available at the>>> re-class= ification point.>>>>>> I hope that this helps explain what we are after. If= it does, and if>>> the intent is acceptable to the working group, we can f= igure out what>>> additional words are needed to convey this.>>> If the wor= king group disagree with the intent, then we will of course>>> adjust to ma= tch the working group agreements.>>> If this is still unclear, I am not sur= e what to try next.>>>>>> Yours,>>> Joel>>>>>> ____________________________= ___________________>>> sfc mailing list>>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc>>>>>> _____________________= __________________________>>> sfc mailing list>>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc>>>>>>> _____________= __________________________________>> sfc mailing list>> sfc@ietf.org>> http= s://www.ietf.org/mailman/listinfo/sfc>>>> _________________________________= ______________> sfc mailing list> sfc@ietf.org> https://www.ietf.org/mailma= n/listinfo/sfc>_______________________________________________sfc mailing l= istsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_1639_725563685.1405025862622 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes.  Many= protocols allow you to do stupid things, but don't prohibit them as they m= ay make sense in smaller deployments.  

e.g. = I could build a global 2000 node OSPF network all in area 0, redistributing= all links as external LSAs, and still not violate the standard.




From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: <= /b><huang@sce.carleton.ca>,<sfc@ietf.org>
Sent: Thurs= day, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and = Load Balancers

No, it will mean that if someone tries= to deploy the archtieture
particularly badly, they will exceed the lim= its of their devices.
The architecture does not require such absurd use = of service paths.
Since I can not figure out how to write architectural = words to prohibit
it, the architecture does permit such abuse.

P= lease do not read my saying that the archtiecture permits something as
= saying it is either deisred or required by the work. It isn't.

Your= s,
Joel

On 7/10/14, 4:36 PM, Changcheng Huang wrote:


> If you need to support 100 service chains, it will mean 16,0= 00,000
> paths. That is larger than the routing table of a= core router.
>
> Chang
>= ;
> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:
>> The architecture allows a range of deployments, from 1 serv= ice path to
>> 160000 service paths. I would hope that= operators are prepared for
>> the complexities if they= choose to avoid any use of local load
>> balancing and= in stead provision 160,000 service paths.
>>
>> Yours,
>> Joel
>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
>>> Paul,
>>>
>>= > How many path identifiers there will be for a 4 hop service chain with=
>>> 20 instances at each hop?
>>= ;>
>>> Maria
>>>
>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *= Paul Quinn
>>> (paulq)
>>> *S= ent:* Thursday, July 10, 2014 3:03 PM
>>> *To:* Lucy= yong
>>> *Cc:* jmh@joelhalpern.com; mohamed.boucada= ir@orange.com; sfc@ietf.org;
>>> mikebianc@aol.com>>> *Subject:* Re: [sfc] Service Chains, Paths, and L= oad Balancers
>>>
>>> Lucy,>>>
>>> Overall I concur, as y= ou say: a path ID drives the forwarding. I=E2=80=99d make
>= ;>> the minor change: the path identifier can be used to derive the n= eeded
>>> forwarding and associated transport.
>>>
>>> It is _not_ the transport,= but rather is used to simply identify the
>>> servi= ce path (or graph) that packets must traverse. By having a path
>>> identifier, the exact indirection that people seem to be= asking for on
>>> this thread can be simply be impl= emented. The path identifier provides
>>> nothing m= ore than a lookup, that lookup can result in a one or more
&g= t;>> (equal or weighted) transport next hop(s).
>>= ;>
>>> Paul
>>>
>>> On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@hu= awei.com
>>> <mailto:lucy.yong@huawei.com>>= wrote:
>>>
>>>
>>>
>>> Agree. The arch. doc should not ma= ndate only use of the service path
>>> identifier to= drive the forwarding actions.
>>>
>= ;>> Lucy
>>>
>>> *From:= *sfc [mailto:sfc-bounces@ietf.org]*On Behalf
>>> Of*= mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>>> *Sent:*Thursday, July 10, 2014 2:06 AM
>>> *To:*mikebianc@aol.com <mailto:mikebianc@aol.com>;jmh= @joelhalpern.com
>>> <mailto:jmh@joelhalpern.com&= gt;;sfc@ietf.org <mailto:sfc@ietf.org>
>>> *Su= bject:*Re: [sfc] Service Chains, Paths, and Load Balancers
&g= t;>>
>>> Re-,
>>>
>>> The merged draft calls out explicitly a service path = identifier. I
>>> object to use that identifier to d= erive forwarding actions.
>>>
>>= > Requiring a SFC system to have the full knowledge of every available S= FC
>>> forwarding paths within an SFC-enabled domain= is not required/justified
>>> nor possible in vario= us deployment contexts.
>>>
>>&g= t; SFC forwarding actions should rely on the piece of information that will=
>>> be present in all deployments: that is the one = required to structure a
>>> service chain. How that = information is used to infer forwarding actions
>>> = is a solution-oriented discussion.
>>>
>>> Cheers,
>>>
>>>= Med
>>>
>>> *De :*sfc [mailt= o:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com
>&= gt;> <mailto:mikebianc@aol.com>
>>> *Envoy= =C3=A9 :*mercredi 9 juillet 2014 22:03
>>> *=C3=80 := *jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>>> <mailto:sfc@ietf.org>
>>>= *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers
>>>
>>> Is anyone still questioning the di= fference between SF Chain and SF Path?
>>>   Ot= her than clarifying the definition so that it's clear to those not
>>> familiar with the draft, it seems that everyone agrees o= n these terms.
>>>
>>> To me,= the one point that is still unclear is whether it is the intent
>>> of this draft to ultimately specify what the ID of the S= FC Header should
>>> reference (the chain or the pat= h), or if this draft simply intends to
>>> leave tha= t ambiguous, allowing other drafts to dictate the mechanisms
= >>> for forwarding based on chain or path and the choice of chain = or path to
>>> be negotiated in the control-plane.>>>
>>> If the latter (ambiguo= us), then the draft would have require that both
>>>= SFP and SFC be supported (or make one required and the other optional)
>>> to avoid some vendors only supporting SFP and other= s only supporting
>>> SFC.
>>>= ;
>>> ----------------------------------------------= --------------------------
>>>
>>= ;> *From:*jmh@joelhalpern.com<jmh@joelhalpern.com
>&= gt;> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>>
>>> *To:*sfc@ietf.org<sfc@ietf.org <mailto:sfc@ietf.= org%3csfc@ietf.org>>
>>> *Sent:*Tuesday, July = 8, 2014
>>> *Subject:*[sfc] Service Chains, Paths, a= nd Load Balancers
>>>
>>> I h= ave been trying to figure out how to clearly answer a number of
>>> comments that have been made about the proposed merged arch= tiecture
>>> draft. Assuming we can get working grou= p agreement on the intent, we
>>> will work to impro= ve the wording so that readers who have not
>>> part= icipated in the WG discussion will understnd it the way the working
>>> group intends.
>>>
>>> But what do we intend? I will try to explain my personal view= , and see
>>> if that helps.
>>&= gt;
>>> In this regard, it is important to keep in m= ind that what we are
>>> defining is the data plane = architecture. We are not attempting to
>>> define th= e architecture for the entire solution for service chaining.
= >>> That would encompass OSS/BSS, various control and policy funct= ions,
>>> virtual machine and image management, and = many other aspects.
>>>
>>> A= s a result there are many things which clearly need to exist in the
>>> larger system, but which are dealt with above where we = are functioning,
>>> and are not directly required b= y the work we are doing.
>>>
>>&= gt; In order to get to service chain vs service path, as I understand them,=
>>> I need to first discuss load balancing. There a= re at least three
>>> different ways that load balan= cing can and will interact with service
>>> chaining= . There probably are more. The point of the archtiecture is to
>>> permit all of these, but not to mandate that any particular = kind be used
>>> in any solution.
>= >>
>>> 1) Load balancing as a service provided= to the end user. This is a
>>> service function. It= receives user packets, and modifies them (or marks
>>&= gt; them, or ...) so as to choose an end user service instance to receive>>> the users packet. This is an important service fu= nction to be able to
>>> include in service chaining= . It's behavior may affect requirements on
>>> how s= ervice chaining is done. But it has very little impact on the
>>> archtiecture. From an architectural pe3rspective it is simply= a service
>>> function which may modify the underly= ing packet.
>>>
>>> 2) There = is internal load balancing. That is, one can have what appears
>>> to the service chaining architecture as a single point of co= ntact for a
>>> specific service function, but is ac= tually delivered by a collection of
>>> virtual or p= hysical machines, possibly including one or several load
>= >> balancers (for example using VRRP-like techniques to share a MAC>>> address.) mostly, this is invisible to the servic= e chaining data plane
>>> mechanisms. It is likely t= hat it is visible to various control
>>> mechanisms,= such as those responsible for scale-in, scale-out, and vm
&g= t;>> instantiation. The architectural impact of permitting this is la= rgely
>>> that we need to be careful that our termin= ology does not lead readers to
>>> think we are proh= ibiting it.
>>>
>>> 3) There = can also be load balancing done by selecting packet paths for
>>> the service chaining that direct traffic to different places.= We would
>>> not want to require that a given servi= ce function appear at only one
>>> place in the netw= ork.
>>>
>>> It is of course = the case that these may be combined. I tend to refer to
>&= gt;> the collection of entities that appear to service chaining as a sin= gle
>>> point as a cluster. Not because cluster is a= good term. But because I
>>> do not have another on= e. Thus, the point of type 3 load balancing is to
>>>= ; direct different subsets of traffic to different singular or clustered>>> service functions in different places in the netwo= rk.
>>>
>>> Now with that sai= d, what do I mean when I talk about service chain and
>>= ;> service path/ Service chain is a sequence of logical functions to be<= br class=3D"">>>> applied to a subset of packets. It is equivalent= of saying that some
>>> subset of traffic is to get= DPI, charging, content inspection, and
>>> firewall= while a different subset is to go directly to the cache without
>>> visiting any other service functions.
>= >>
>>> That is not enough information to direc= t the packets. A service path
>>> is, in some fashio= n, a sequence of locations in the network. Those
>>>= locations will be singular or clustered service function delivery
>>> locations. They may be addressed by IP address. They may= be addressed
>>> as ports on an SFF. There are many= different ways that the locations
>>> may be known = to the service chaining infrastructure and the transport.
>= ;>>
>>> >From the point of view of the wor= k of the SFC group, we need to be
>>> able
>>> to talk about the high level abstraction, the service ch= ain, which
>>> drives the forwarding. And we need to= talk about the actual data path
>>> packets will ta= ke in the network.
>>>
>>> Se= veral of the comments have said "but the whole path may not be known
>>> at the front." This architecture deals with that issue= in two ways.
>>> First, as noted in item (2) on loa= d balancers above, there can be
>>> decisions and be= haviors which are invisible to the service chaining
>>&= gt; mechanisms (in much the same way that bridging within a LAN is largely<= br class=3D"">>>> invisible to routing between LANs.) The other pr= ovision we make is that
>>> reclassification can be = done in mid-chain when necessary. That will
>>> dire= ct packets to a new chain. Based on information available at the
>>> re-classification point.
>>>
>>> I hope that this helps explain what we are after. If= it does, and if
>>> the intent is acceptable to the= working group, we can figure out what
>>> additiona= l words are needed to convey this.
>>> If the workin= g group disagree with the intent, then we will of course
>= >> adjust to match the working group agreements.
>&g= t;> If this is still unclear, I am not sure what to try next.
>>>
>>> Yours,
>>= > Joel
>>>
>>> ___________= ____________________________________
>>> sfc mailing= list
>>> sfc@ietf.org <mailto:sfc@ietf.org>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> ____________________________= ___________________
>>> sfc mailing list
>>> sfc@ietf.org <mailto:sfc@ietf.org>
>= >> https://www.ietf.org/mailman/listinfo/sfc
>>&g= t;
>>
>> __________________________= _____________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/= listinfo/sfc
>>
>
> _= ______________________________________________
> sfc maili= ng list
> sfc@ietf.org
> https://www.ietf= .org/mailman/listinfo/sfc
>

_= ______________________________________________
sfc mailing li= st
sfc@ietf.org
https://www.ietf.org/mailman/li= stinfo/sfc
------=_Part_1639_725563685.1405025862622-- From nobody Thu Jul 10 14:01: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 19F801B2A04 for ; Thu, 10 Jul 2014 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 FiL8quXsIBKl for ; Thu, 10 Jul 2014 14:01:07 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9BF1B29FE for ; Thu, 10 Jul 2014 14:01:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="121300516" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABPCoNBV60VjycihzWBN3SCJQEBAQECAQEBAWIJGwIBCBEBAwEBAQodBycLFAMGCAIEARIIE4dNAwkVzBATBIxTgT0rOIMkgRQElC1EjmGKfoIr Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 10 Jul 2014 21:01:06 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:01:05 -0700 From: Ian Smith To: "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNA== Date: Thu, 10 Jul 2014 21:01:05 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> In-Reply-To: <53BEFBB7.2010400@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/n78GEkO3qkgC_Vuu8tGr_hK_SfQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:01:10 -0000 I disagree. =0A= =0A= We routinely have stateful devices that manage tens of millions of concurre= nt flows in both access network and data center environments today. You ca= n't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of t= omorrow you are only going to have small numbers of service chains with equ= ally small numbers of active service paths? =0A= =0A= Your sounds too much like "no one will ever need more than 64K" for comfort= .=0A= =0A= =0A= ________________________________________=0A= From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalp= ern.com]=0A= Sent: Thursday, July 10, 2014 4:46 PM=0A= To: huang@sce.carleton.ca; sfc@ietf.org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= No, it will mean that if someone tries to deploy the archtieture=0A= particularly badly, they will exceed the limits of their devices.=0A= The architecture does not require such absurd use of service paths.=0A= Since I can not figure out how to write architectural words to prohibit=0A= it, the architecture does permit such abuse.=0A= =0A= Please do not read my saying that the archtiecture permits something as=0A= saying it is either deisred or required by the work. It isn't.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > If you need to support 100 service chains, it will mean 16,000,000=0A= > paths. That is larger than the routing table of a core router.=0A= >=0A= > Chang=0A= >=0A= > On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= >> The architecture allows a range of deployments, from 1 service path to= =0A= >> 160000 service paths. I would hope that operators are prepared for=0A= >> the complexities if they choose to avoid any use of local load=0A= >> balancing and in stead provision 160,000 service paths.=0A= >>=0A= >> Yours,=0A= >> Joel=0A= >>=0A= >> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= >>> Paul,=0A= >>>=0A= >>> How many path identifiers there will be for a 4 hop service chain with= =0A= >>> 20 instances at each hop?=0A= >>>=0A= >>> Maria=0A= >>>=0A= >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn=0A= >>> (paulq)=0A= >>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= >>> *To:* Lucy yong=0A= >>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org;= =0A= >>> mikebianc@aol.com=0A= >>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> Lucy,=0A= >>>=0A= >>> Overall I concur, as you say: a path ID drives the forwarding. I=92d ma= ke=0A= >>> the minor change: the path identifier can be used to derive the needed= =0A= >>> forwarding and associated transport.=0A= >>>=0A= >>> It is _not_ the transport, but rather is used to simply identify the=0A= >>> service path (or graph) that packets must traverse. By having a path= =0A= >>> identifier, the exact indirection that people seem to be asking for on= =0A= >>> this thread can be simply be implemented. The path identifier provides= =0A= >>> nothing more than a lookup, that lookup can result in a one or more=0A= >>> (equal or weighted) transport next hop(s).=0A= >>>=0A= >>> Paul=0A= >>>=0A= >>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> > wrote:=0A= >>>=0A= >>>=0A= >>>=0A= >>> Agree. The arch. doc should not mandate only use of the service path=0A= >>> identifier to drive the forwarding actions.=0A= >>>=0A= >>> Lucy=0A= >>>=0A= >>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= >>> Of*mohamed.boucadair@orange.com = =0A= >>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= >>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com= =0A= >>> ;sfc@ietf.org =0A= >>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> Re-,=0A= >>>=0A= >>> The merged draft calls out explicitly a service path identifier. I=0A= >>> object to use that identifier to derive forwarding actions.=0A= >>>=0A= >>> Requiring a SFC system to have the full knowledge of every available SF= C=0A= >>> forwarding paths within an SFC-enabled domain is not required/justified= =0A= >>> nor possible in various deployment contexts.=0A= >>>=0A= >>> SFC forwarding actions should rely on the piece of information that wil= l=0A= >>> be present in all deployments: that is the one required to structure a= =0A= >>> service chain. How that information is used to infer forwarding actions= =0A= >>> is a solution-oriented discussion.=0A= >>>=0A= >>> Cheers,=0A= >>>=0A= >>> Med=0A= >>>=0A= >>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com= =0A= >>> =0A= >>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= >>> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.org=0A= >>> =0A= >>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> Is anyone still questioning the difference between SF Chain and SF Path= ?=0A= >>> Other than clarifying the definition so that it's clear to those not= =0A= >>> familiar with the draft, it seems that everyone agrees on these terms.= =0A= >>>=0A= >>> To me, the one point that is still unclear is whether it is the intent= =0A= >>> of this draft to ultimately specify what the ID of the SFC Header shoul= d=0A= >>> reference (the chain or the path), or if this draft simply intends to= =0A= >>> leave that ambiguous, allowing other drafts to dictate the mechanisms= =0A= >>> for forwarding based on chain or path and the choice of chain or path t= o=0A= >>> be negotiated in the control-plane.=0A= >>>=0A= >>> If the latter (ambiguous), then the draft would have require that both= =0A= >>> SFP and SFC be supported (or make one required and the other optional)= =0A= >>> to avoid some vendors only supporting SFP and others only supporting=0A= >>> SFC.=0A= >>>=0A= >>> -----------------------------------------------------------------------= -=0A= >>>=0A= >>> *From:*jmh@joelhalpern.com>> >=0A= >>> *To:*sfc@ietf.org>=0A= >>> *Sent:*Tuesday, July 8, 2014=0A= >>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> I have been trying to figure out how to clearly answer a number of=0A= >>> comments that have been made about the proposed merged archtiecture=0A= >>> draft. Assuming we can get working group agreement on the intent, we=0A= >>> will work to improve the wording so that readers who have not=0A= >>> participated in the WG discussion will understnd it the way the working= =0A= >>> group intends.=0A= >>>=0A= >>> But what do we intend? I will try to explain my personal view, and see= =0A= >>> if that helps.=0A= >>>=0A= >>> In this regard, it is important to keep in mind that what we are=0A= >>> defining is the data plane architecture. We are not attempting to=0A= >>> define the architecture for the entire solution for service chaining.= =0A= >>> That would encompass OSS/BSS, various control and policy functions,=0A= >>> virtual machine and image management, and many other aspects.=0A= >>>=0A= >>> As a result there are many things which clearly need to exist in the=0A= >>> larger system, but which are dealt with above where we are functioning,= =0A= >>> and are not directly required by the work we are doing.=0A= >>>=0A= >>> In order to get to service chain vs service path, as I understand them,= =0A= >>> I need to first discuss load balancing. There are at least three=0A= >>> different ways that load balancing can and will interact with service= =0A= >>> chaining. There probably are more. The point of the archtiecture is to= =0A= >>> permit all of these, but not to mandate that any particular kind be use= d=0A= >>> in any solution.=0A= >>>=0A= >>> 1) Load balancing as a service provided to the end user. This is a=0A= >>> service function. It receives user packets, and modifies them (or marks= =0A= >>> them, or ...) so as to choose an end user service instance to receive= =0A= >>> the users packet. This is an important service function to be able to= =0A= >>> include in service chaining. It's behavior may affect requirements on= =0A= >>> how service chaining is done. But it has very little impact on the=0A= >>> archtiecture. From an architectural pe3rspective it is simply a service= =0A= >>> function which may modify the underlying packet.=0A= >>>=0A= >>> 2) There is internal load balancing. That is, one can have what appears= =0A= >>> to the service chaining architecture as a single point of contact for a= =0A= >>> specific service function, but is actually delivered by a collection of= =0A= >>> virtual or physical machines, possibly including one or several load=0A= >>> balancers (for example using VRRP-like techniques to share a MAC=0A= >>> address.) mostly, this is invisible to the service chaining data plane= =0A= >>> mechanisms. It is likely that it is visible to various control=0A= >>> mechanisms, such as those responsible for scale-in, scale-out, and vm= =0A= >>> instantiation. The architectural impact of permitting this is largely= =0A= >>> that we need to be careful that our terminology does not lead readers t= o=0A= >>> think we are prohibiting it.=0A= >>>=0A= >>> 3) There can also be load balancing done by selecting packet paths for= =0A= >>> the service chaining that direct traffic to different places. We would= =0A= >>> not want to require that a given service function appear at only one=0A= >>> place in the network.=0A= >>>=0A= >>> It is of course the case that these may be combined. I tend to refer to= =0A= >>> the collection of entities that appear to service chaining as a single= =0A= >>> point as a cluster. Not because cluster is a good term. But because I= =0A= >>> do not have another one. Thus, the point of type 3 load balancing is to= =0A= >>> direct different subsets of traffic to different singular or clustered= =0A= >>> service functions in different places in the network.=0A= >>>=0A= >>> Now with that said, what do I mean when I talk about service chain and= =0A= >>> service path/ Service chain is a sequence of logical functions to be=0A= >>> applied to a subset of packets. It is equivalent of saying that some=0A= >>> subset of traffic is to get DPI, charging, content inspection, and=0A= >>> firewall while a different subset is to go directly to the cache withou= t=0A= >>> visiting any other service functions.=0A= >>>=0A= >>> That is not enough information to direct the packets. A service path=0A= >>> is, in some fashion, a sequence of locations in the network. Those=0A= >>> locations will be singular or clustered service function delivery=0A= >>> locations. They may be addressed by IP address. They may be addressed= =0A= >>> as ports on an SFF. There are many different ways that the locations=0A= >>> may be known to the service chaining infrastructure and the transport.= =0A= >>>=0A= >>> >From the point of view of the work of the SFC group, we need to be=0A= >>> able=0A= >>> to talk about the high level abstraction, the service chain, which=0A= >>> drives the forwarding. And we need to talk about the actual data path= =0A= >>> packets will take in the network.=0A= >>>=0A= >>> Several of the comments have said "but the whole path may not be known= =0A= >>> at the front." This architecture deals with that issue in two ways.=0A= >>> First, as noted in item (2) on load balancers above, there can be=0A= >>> decisions and behaviors which are invisible to the service chaining=0A= >>> mechanisms (in much the same way that bridging within a LAN is largely= =0A= >>> invisible to routing between LANs.) The other provision we make is that= =0A= >>> reclassification can be done in mid-chain when necessary. That will=0A= >>> direct packets to a new chain. Based on information available at the=0A= >>> re-classification point.=0A= >>>=0A= >>> I hope that this helps explain what we are after. If it does, and if=0A= >>> the intent is acceptable to the working group, we can figure out what= =0A= >>> additional words are needed to convey this.=0A= >>> If the working group disagree with the intent, then we will of course= =0A= >>> adjust to match the working group agreements.=0A= >>> If this is still unclear, I am not sure what to try next.=0A= >>>=0A= >>> Yours,=0A= >>> Joel=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= > _______________________________________________=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= From nobody Thu Jul 10 14:04: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 5A16C1B2A03 for ; Thu, 10 Jul 2014 14:04:16 -0700 (PDT) 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_29=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 xq8EHEN3trtm for ; Thu, 10 Jul 2014 14:04:14 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD741B29FE for ; Thu, 10 Jul 2014 14:04:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 1BA22861546; Thu, 10 Jul 2014 14:04:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 2931B861543; Thu, 10 Jul 2014 14:04:11 -0700 (PDT) Message-ID: <53BEFFCA.9070308@joelhalpern.com> Date: Thu, 10 Jul 2014 17:04:10 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M8KjAqhL5YJFA5cxANs3emBfN_M Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:04:16 -0000 Ian, I don't think you disagree with me at all in this regard. I am not requesting the the architecture or the solution prohibit deployments in the specific fashion. I am objecting to Huang's reading of my note as saying that such deployments are required they by the archtiecture. As I have said repeatedly, I am not trying to prohibit such things. Whether they are a good idea or not depends upon many factors outside of the scope of the WG. I happen to think that they are usually a bad idea. But the archtiecture si carefully avoiding attempting to know what is and is not eployable. Yours, Joel On 7/10/14, 5:01 PM, Ian Smith wrote: > I disagree. > > We routinely have stateful devices that manage tens of millions of concurrent flows in both access network and data center environments today. You can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to have small numbers of service chains with equally small numbers of active service paths? > > Your sounds too much like "no one will ever need more than 64K" for comfort. > > > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalpern.com] > Sent: Thursday, July 10, 2014 4:46 PM > To: huang@sce.carleton.ca; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > No, it will mean that if someone tries to deploy the archtieture > particularly badly, they will exceed the limits of their devices. > The architecture does not require such absurd use of service paths. > Since I can not figure out how to write architectural words to prohibit > it, the architecture does permit such abuse. > > Please do not read my saying that the archtiecture permits something as > saying it is either deisred or required by the work. It isn't. > > Yours, > Joel > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> If you need to support 100 service chains, it will mean 16,000,000 >> paths. That is larger than the routing table of a core router. >> >> Chang >> >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>> The architecture allows a range of deployments, from 1 service path to >>> 160000 service paths. I would hope that operators are prepared for >>> the complexities if they choose to avoid any use of local load >>> balancing and in stead provision 160,000 service paths. >>> >>> Yours, >>> Joel >>> >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>> Paul, >>>> >>>> How many path identifiers there will be for a 4 hop service chain with >>>> 20 instances at each hop? >>>> >>>> Maria >>>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>>> (paulq) >>>> *Sent:* Thursday, July 10, 2014 3:03 PM >>>> *To:* Lucy yong >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >>>> mikebianc@aol.com >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Lucy, >>>> >>>> Overall I concur, as you say: a path ID drives the forwarding. I’d make >>>> the minor change: the path identifier can be used to derive the needed >>>> forwarding and associated transport. >>>> >>>> It is _not_ the transport, but rather is used to simply identify the >>>> service path (or graph) that packets must traverse. By having a path >>>> identifier, the exact indirection that people seem to be asking for on >>>> this thread can be simply be implemented. The path identifier provides >>>> nothing more than a lookup, that lookup can result in a one or more >>>> (equal or weighted) transport next hop(s). >>>> >>>> Paul >>>> >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>> > wrote: >>>> >>>> >>>> >>>> Agree. The arch. doc should not mandate only use of the service path >>>> identifier to drive the forwarding actions. >>>> >>>> Lucy >>>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>> Of*mohamed.boucadair@orange.com >>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >>>> ;sfc@ietf.org >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Re-, >>>> >>>> The merged draft calls out explicitly a service path identifier. I >>>> object to use that identifier to derive forwarding actions. >>>> >>>> Requiring a SFC system to have the full knowledge of every available SFC >>>> forwarding paths within an SFC-enabled domain is not required/justified >>>> nor possible in various deployment contexts. >>>> >>>> SFC forwarding actions should rely on the piece of information that will >>>> be present in all deployments: that is the one required to structure a >>>> service chain. How that information is used to infer forwarding actions >>>> is a solution-oriented discussion. >>>> >>>> Cheers, >>>> >>>> Med >>>> >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >>>> >>>> *Envoyé :*mercredi 9 juillet 2014 22:03 >>>> *À :*jmh@joelhalpern.com ;sfc@ietf.org >>>> >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Is anyone still questioning the difference between SF Chain and SF Path? >>>> Other than clarifying the definition so that it's clear to those not >>>> familiar with the draft, it seems that everyone agrees on these terms. >>>> >>>> To me, the one point that is still unclear is whether it is the intent >>>> of this draft to ultimately specify what the ID of the SFC Header should >>>> reference (the chain or the path), or if this draft simply intends to >>>> leave that ambiguous, allowing other drafts to dictate the mechanisms >>>> for forwarding based on chain or path and the choice of chain or path to >>>> be negotiated in the control-plane. >>>> >>>> If the latter (ambiguous), then the draft would have require that both >>>> SFP and SFC be supported (or make one required and the other optional) >>>> to avoid some vendors only supporting SFP and others only supporting >>>> SFC. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:*jmh@joelhalpern.com>>> > >>>> *To:*sfc@ietf.org> >>>> *Sent:*Tuesday, July 8, 2014 >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I have been trying to figure out how to clearly answer a number of >>>> comments that have been made about the proposed merged archtiecture >>>> draft. Assuming we can get working group agreement on the intent, we >>>> will work to improve the wording so that readers who have not >>>> participated in the WG discussion will understnd it the way the working >>>> group intends. >>>> >>>> But what do we intend? I will try to explain my personal view, and see >>>> if that helps. >>>> >>>> In this regard, it is important to keep in mind that what we are >>>> defining is the data plane architecture. We are not attempting to >>>> define the architecture for the entire solution for service chaining. >>>> That would encompass OSS/BSS, various control and policy functions, >>>> virtual machine and image management, and many other aspects. >>>> >>>> As a result there are many things which clearly need to exist in the >>>> larger system, but which are dealt with above where we are functioning, >>>> and are not directly required by the work we are doing. >>>> >>>> In order to get to service chain vs service path, as I understand them, >>>> I need to first discuss load balancing. There are at least three >>>> different ways that load balancing can and will interact with service >>>> chaining. There probably are more. The point of the archtiecture is to >>>> permit all of these, but not to mandate that any particular kind be used >>>> in any solution. >>>> >>>> 1) Load balancing as a service provided to the end user. This is a >>>> service function. It receives user packets, and modifies them (or marks >>>> them, or ...) so as to choose an end user service instance to receive >>>> the users packet. This is an important service function to be able to >>>> include in service chaining. It's behavior may affect requirements on >>>> how service chaining is done. But it has very little impact on the >>>> archtiecture. From an architectural pe3rspective it is simply a service >>>> function which may modify the underlying packet. >>>> >>>> 2) There is internal load balancing. That is, one can have what appears >>>> to the service chaining architecture as a single point of contact for a >>>> specific service function, but is actually delivered by a collection of >>>> virtual or physical machines, possibly including one or several load >>>> balancers (for example using VRRP-like techniques to share a MAC >>>> address.) mostly, this is invisible to the service chaining data plane >>>> mechanisms. It is likely that it is visible to various control >>>> mechanisms, such as those responsible for scale-in, scale-out, and vm >>>> instantiation. The architectural impact of permitting this is largely >>>> that we need to be careful that our terminology does not lead readers to >>>> think we are prohibiting it. >>>> >>>> 3) There can also be load balancing done by selecting packet paths for >>>> the service chaining that direct traffic to different places. We would >>>> not want to require that a given service function appear at only one >>>> place in the network. >>>> >>>> It is of course the case that these may be combined. I tend to refer to >>>> the collection of entities that appear to service chaining as a single >>>> point as a cluster. Not because cluster is a good term. But because I >>>> do not have another one. Thus, the point of type 3 load balancing is to >>>> direct different subsets of traffic to different singular or clustered >>>> service functions in different places in the network. >>>> >>>> Now with that said, what do I mean when I talk about service chain and >>>> service path/ Service chain is a sequence of logical functions to be >>>> applied to a subset of packets. It is equivalent of saying that some >>>> subset of traffic is to get DPI, charging, content inspection, and >>>> firewall while a different subset is to go directly to the cache without >>>> visiting any other service functions. >>>> >>>> That is not enough information to direct the packets. A service path >>>> is, in some fashion, a sequence of locations in the network. Those >>>> locations will be singular or clustered service function delivery >>>> locations. They may be addressed by IP address. They may be addressed >>>> as ports on an SFF. There are many different ways that the locations >>>> may be known to the service chaining infrastructure and the transport. >>>> >>>> >From the point of view of the work of the SFC group, we need to be >>>> able >>>> to talk about the high level abstraction, the service chain, which >>>> drives the forwarding. And we need to talk about the actual data path >>>> packets will take in the network. >>>> >>>> Several of the comments have said "but the whole path may not be known >>>> at the front." This architecture deals with that issue in two ways. >>>> First, as noted in item (2) on load balancers above, there can be >>>> decisions and behaviors which are invisible to the service chaining >>>> mechanisms (in much the same way that bridging within a LAN is largely >>>> invisible to routing between LANs.) The other provision we make is that >>>> reclassification can be done in mid-chain when necessary. That will >>>> direct packets to a new chain. Based on information available at the >>>> re-classification point. >>>> >>>> I hope that this helps explain what we are after. If it does, and if >>>> the intent is acceptable to the working group, we can figure out what >>>> additional words are needed to convey this. >>>> If the working group disagree with the intent, then we will of course >>>> adjust to match the working group agreements. >>>> If this is still unclear, I am not sure what to try next. >>>> >>>> Yours, >>>> Joel >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 10 14:07: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 62D4C1B2A17 for ; Thu, 10 Jul 2014 14:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 Y4B0IW4cDsJt for ; Thu, 10 Jul 2014 14:07:32 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02C21B2A09 for ; Thu, 10 Jul 2014 14:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38782; q=dns/txt; s=iport; t=1405026472; x=1406236072; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OfoYfVi6ZFwKEMqnAm6+oYTsfQT1+ZbBDVmCuRUUqmY=; b=AkScdSTM2v7yOtyoC6nZyicezOEo1eZLgyf6rVRfv7NtPNow4gTXQWPM GY70tLYPWQ1kR+MRlnpWwDpVihM//5E3Lg6k0H8JBvfMeefDAdOSdAri+ hixbyMv35eYQgalti+4uQ2owEYseGpQ4mEzpHFDbpNvqxDiFnZ26vYT4J U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAF7/vlOtJA2B/2dsb2JhbABPCoJHR1KvRZF4AQmHQgGBDhZ1hAMBAQEEAQEBKjgJCxACAQgRAQMBASEBBgcnCxQDBggCBA4FG4gTAxENxiwTBI0ZgU8vIwYEBgGDLYEWBZYgRoQai2OIMoND X-IronPort-AV: E=Sophos; i="5.01,639,1400025600"; d="scan'208,217"; a="59843076" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 10 Jul 2014 21:07:49 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6AL7SDH005809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 21:07:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 16:07:28 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAVN2A//+6IHE= Date: Thu, 10 Jul 2014 21:07:27 +0000 Message-ID: <53F1048C-C06A-45C6-8727-2FA69AAB9C14@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A68B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A68B@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_53F1048CC06A45C687272FA69AAB9C14ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WJLcwPROQkdnCR18yNW133S2TwY Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:07:35 -0000 --_000_53F1048CC06A45C687272FA69AAB9C14ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. Sent from my iPhone On Jul 10, 2014, at 4:18 PM, "NAPIERALA, MARIA H" > wrote: Does it mean one path identifier? Maria From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, July 10, 2014 4:14 PM To: NAPIERALA, MARIA H Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@orange.com;= sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make = the minor change: the path identifier can be used to derive the needed forw= arding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_53F1048CC06A45C687272FA69AAB9C14ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes.

Sent from my iPhone

On Jul 10, 2014, at 4:18 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Does it mean one path ide= ntifier?

 <= /p>

Maria

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisc= o.com]
Sent: Thursday, July 10, 2014 4:14 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@orange.co= m; sfc@ietf.org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

1 assuming load is distributed among the 20 instance= s at each service hop.

Sent from my iPhone

Paul,

 <= /p>

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

 <= /p>

Maria

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= o:p>

 

Lucy,

 

Overall I concur, as you say: a path ID drives the f= orwarding.  I=92d make the minor change: the path identifier can be us= ed to derive the needed forwarding and associated transport.

 

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse.  = By having a path identifier, the exact indirection that people seem to be a= sking for on this thread can be simply be implemented.  The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).  

 

Paul

 

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:




Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers

 

Re-,

 

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

 

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

 

Cheers,

Med

 

 

Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh@joelhalpern.= com<jmh@joelhalpern.com>
To: sfc@ietf.org&= lt;sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

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

--_000_53F1048CC06A45C687272FA69AAB9C14ciscocom_-- From nobody Thu Jul 10 14: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 BC82C1B2A23 for ; Thu, 10 Jul 2014 14:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kejmSQM21c4p for ; Thu, 10 Jul 2014 14:07:33 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086571B2A1A for ; Thu, 10 Jul 2014 14:07:32 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 5900fb35.2abff8a40940.6332399.00-2432.17526352.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:07:33 +0000 (UTC) X-MXL-Hash: 53bf00952b432889-dcb1e0df920d3704afa053a91db261af6ac6b7ca Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d800fb35.0.6332319.00-2067.17526102.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:07:26 +0000 (UTC) X-MXL-Hash: 53bf008e0c95caa0-ea87e1254748ace0d118b88d93c7d2c1bff8b0ef Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AL7Ohe028880; Thu, 10 Jul 2014 17:07:25 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AL7EHC028748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 17:07:21 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 21:06:57 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 17:04:33 -0400 From: "NAPIERALA, MARIA H" To: "mikebianc@aol.com" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYbj0AgAC5UoCAAIXfAIAABCUAgAAT/oCAAAhZAP//7DrrgABM4YD//8ej8A== Date: Thu, 10 Jul 2014 21:04:32 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A783@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <077f01cf9c5c$624420b0$26cc6210$@sce.carleton.ca> <419417C345CA5F48BF45F0A23955A0634A83C07B@SEAEMBX02.olympus.F5Net.com> <451642339.1270.1405017250762.JavaMail.tomcat@mgs-aad01.mail.aol.com> <53BEEFAE.6030301@sce.carleton.ca> <370437302.1567.1405023935852.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <370437302.1567.1405023935852.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A783MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=qN95wPeSAAAA:8 a] X-AnalysisOut: [=i0EeH86SAAAA:8 a=z9tbli-vAAAA:8 a=ABeY7kuGAAAA:8 a=vSVd6k] X-AnalysisOut: [iSqMPKL09rxswA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=U8I] X-AnalysisOut: [e8EnqySEA:10 a=3XJ037QrwtgA:10 a=paC5pjApGzsA:10 a=hPjdaME] X-AnalysisOut: [vmhQA:10 a=oAXR_kdF8uMA:10 a=chC_agHSu74A:10 a=kGGkqyZSVZc] X-AnalysisOut: [A:10 a=4C9GzPnNuxkMOhAW:21 a=V_2fBYYVOoOzcKHL:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=N3IS1aDxq5gtPAV9mRwA:9 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-h] X-AnalysisOut: [UA:10 a=tXsnliwV7b4A:10 a=xkD_RAWOYAilOA-P:21 a=7-eDnkT6hw] X-AnalysisOut: [1b7Eg_:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/248U02SsrcOmN4KmO_m8ZNOjqzg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:07:39 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A783MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBjYXRjaC4NCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgbWlrZWJpYW5jQGFvbC5jb20NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0IDQ6MjYgUE0NClRvOiBodWFuZ0BzY2UuY2FybGV0b24uY2E7IHNmY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQoNClBlcmhhcHMgd2Ugc2hvdWxkIHJld29yZCB0aGF0LCB0aGVuLCB0byBpbmNsdWRlIGEg ZGVmaW5pdGlvbiBvZiBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlIGFuZCBtYWtlIHN1cmUgd2Ug YXJlIGNvbnNpc3RlbnQgd2hlbiByZWZlcnJpbmcgdG8gdGhlc2UgZW50aXRpZXMuLiAgQmFzZWQg b24gbW9zdCBvZiB0aGUgY29tbWVudHMgSSd2ZSBzZWVuLCBpdCBzZWVtcyB0byBtYWtlIGEgbG90 IG9mIHNlbnNlIHRvIGNvbnNpZGVyIGEgU2VydmljZSBGdW5jdGlvbiBtb3JlIG9mIGFuIGFic3Ry YWN0IGVudGl0eSB0aGF0IGhhcyBvbmUgb3IgbW9yZSBpbnN0YW5jZXMuICBBbiBhYnN0cmFjdCBT ZXJ2aWNlIEZ1bmN0aW9uIHdpdGggb25seSBhIHNpbmdsZSBpbnN0YW5jZSBtaWdodCBhcHBlYXIg YXMgb3ZlcmtpbGwsIGhvd2V2ZXIgaXQgd291bGQgbm9ybWFsaXplIG11Y2ggb2YgdGhlIGNvbnZl cnNhdGlvbiBhbmQgYWxsb3cgZm9yIGNsZWFyZXIgZGlzY3Vzc2lvbnMgYWJvdXQgd2hhdCBoYXBw ZW5zIHdoZW4gYW5kIHdoZXJlICZjLg0KDQpGcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudDoNCg0K PiBUaGUgdGVybSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHVzZWQgdG8gZGVzY3JpYmUg dGhlIGRlZmluaXRpb24gYW5kIGluc3RhbnRpYXRpb24gb2YgYW4gb3JkZXJlZCBzZXQgb2YgaW5z dGFuY2VzIG9mIHN1Y2ggc2VydmljZSBmdW5jdGlvbnMsIGFuZCB0aGUgc3Vic2VxdWVudCAic3Rl ZXJpbmciIG9mIHRyYWZmaWMgZmxvd3MgdGhyb3VnaCB0aG9zZSBzZXJ2aWNlIGZ1bmN0aW9ucy4N Cg0Kc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgaW5zdGFuY2UgaXMgdGhlIHRoaW5nIHRoYXQg aXMgYmVpbmcgY2hhaW5lZC4gIE9mIGNvdXJzZSwgaWYgdGhlIGNsYXNzaWZpZXIgb25seSBzcGVj aWZpZXMgY2hvb3NlcyBhIGNoYWluICh7U0ZufSkgYW5kIG5vdCBhIHBhdGggKHtTRklufSksIHJl bGlucXVpc2hpbmcgdGhlIGRlY2lzaW9uIG9mIHdoaWNoIGluc3RhbnRpYXRpb24gdG8gYW5vdGhl ciBwcm9jZXNzLCB0aGVuIHRoZXJlIHRlY2huaWNhbGx5IGlzIG5ldmVyIGFuIGFjdHVhbCBjb21w bGV0ZWQgIm9yZGVyZWQgc2V0IG9mIGluc3RhbmNlcyIgcHJvZHVjZWQgKGJlY2F1c2UgU0ZJKG4p IGlzIG9ubHkgY2hvc2VuIHNvbWV0aW1lIGFmdGVyIGJlaW5nIGRlbGl2ZXJlZCB0byBTRkkobi0x KSkgcmVuZGVyaW5nIHRoZSBTRlAgYW4gYWJzdHJhY3QtaXNoIGNvbmNlcHR1YWwgdGhpbmcuDQoN ClRoZW4gYWdhaW4sIGl0IGNvdWxkIGJlIEkndmUgcmVhZCB0b28gbWFueSBvZiB0aGVzZSB0b2Rh eSBhbmQgbXkgYnJhaW4gaXMgbm93IGZ1bGwuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0BzY2UuY2FybGV0b24u Y2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSUzY2h1YW5nQHNjZS5jYXJsZXRvbi5jYT4+ DQpUbzogPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KQXMgZGVmaW5lZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQgZG9jdW1lbnQsIGEgc2VydmljZSBmdW5jdGlvbiBpcyBub3QgYSBjb25jZXB0LiBIZXJlIGlz IHRoZSBxdW90ZSBmcm9tIHRoZSBkb2N1bWVudCAiQSBTZXJ2aWNlIEZ1bmN0aW9uIGNhbiBiZSBh IHZpcnR1YWwgaW5zdGFuY2Ugb3IgYmUgZW1iZWRkZWQgaW4gYSBwaHlzaWNhbCBuZXR3b3JrIGVs ZW1lbnQuIiBUaGlzIG1lYW5zIGEgc2VydmljZSBmdW5jdGlvbiBpcyBhIHZpcnR1YWwgZW50aXR5 Lg0KDQpBIHZpcnR1YWwgbWFjaGluZSAoVk0pLCBmb3IgZXhhbXBsZSwgY2FuIGRlY2lkZSB3aGlj aCBwcm9jZXNzIHRvIHJ1biBmaXJzdC4gU2ltaWxhcmx5IGEgc2VydmljZSBmdW5jdGlvbiBjYW4g ZGVjaWRlIGhvdyBhIHBhY2tldCBiZWluZyBwcm9jZXNzZWQgYW5kIGZvcndhcmRlZCB0byB0aGUg bmV4dCBzZXJ2aWNlIGZ1bmN0aW9uIGhvcC4NCg0KQ2hhbmcNCk9uIDA3LzEwLzIwMTQgMTE6MzYg QU0sIFJvbiBQYXJrZXIgd3JvdGU6DQpIaSwgTWlrZS4NCkJldHdlZW4gc2VydmljZSBmdW5jdGlv biBhbmQgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSwgSSB0aGluayBpdCB3b3VsZCBoYXZlIHRv IGJlIHRoZSBpbnN0YW5jZSwgc2luY2UgdGhlIGZvcm1lciBpcyBjb25jZXB0dWFsLiBCdXQsIGlu IGEgZGlzdHJpYnV0ZWQgcGF0aCBzZWxlY3Rpb24gYXBwcm9hY2gsIG1pZ2h0IGl0IG1ha2Ugc2Vu c2UgdG8gYXNzaWduIHRoaXMgZHV0eSB0byB0aGUgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXIg KFNGRik/DQpSb24NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjozNCBQTQ0KVG86IEkuU21pdGhARjUuY29tPG1h aWx0bzpJLlNtaXRoQEY1LmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQoiU2VydmljZSBGdW5jdGlvbnMgTUFZIG1ha2UgdGhlIGRlY2lzaW9uIGFib3V0IHdoaWNo IFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwgYmUgdXNlZCB3aGVuIHNlbGVjdGluZyB0 aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoLiINCklzIGl0IHNlcnZpY2UgZnVuY3Rpb24gdGhhdCBt YWtlcyB0aGF0IGRlY2lzaW9uPyBvciB0aGUgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZT8NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBJLlNtaXRoQEY1LmNvbTxJLlNt aXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20lM2NJLlNtaXRoQEY1LmNvbT4+DQpUbzog Q2hhbmdjaGVuZyBIdWFuZzxodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5j YXJsZXRvbi5jYT4+LCdSb24gUGFya2VyJzxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t PG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sJ0x1Y3kgeW9uZyc8bHVj eS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT48 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4+LG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT48bWlr ZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4sam1oQGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50OiBUaHVyc2RheSwgSnVs eSAxMCwgMjAxNA0KU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+U2VydmljZSBmdW5jdGlvbnMgc2hvdWxkIG1ha2UgdGhlIGRlY2lz aW9uIGFib3V0IHdoaWNoIGluc3RhbmNlcyB3aWxsIGJlIHVzZWQNCg0KSSB0aGluayBpdCBpcyBz dWZmaWNpZW50IGZvciB0aGUgYXJjaGl0ZWN0dXJlIHRvIHNheSwNCg0KIlNlcnZpY2UgRnVuY3Rp b25zIE1BWSBtYWtlIHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBTZXJ2aWNlIEZ1bmN0aW9uIElu c3RhbmNlcyB3aWxsIGJlIHVzZWQgd2hlbiBzZWxlY3RpbmcgdGhlIFNlcnZpY2UgRnVuY3Rpb24g UGF0aC4iDQoNCkJ1dCB5b3UgYWxzbyBzYXkgbmVlZCB0byBzYXksDQoNCiJTZXJ2aWNlIEZ1bmN0 aW9uIENsYXNzaWZpZXJzIChvciBTTkYncyBvciBTRkYncywgYXMgdGhlIGNhc2UgbWF5IGJlKSBN QVkgbWFrZSB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggU2VydmljZSBGdW5jdGlvbiBJbnN0YW5j ZXMgd2lsbCBiZSB1c2VkIHdoZW4gc2VsZWN0aW5nIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGgu Ig0KDQphbmQsDQoNCiJFeHRlcm5hbCBvcmNoZXN0cmF0aW9uIGZyYW1ld29ya3MgTUFZIG1ha2Ug dGhlIGRlY2lzaW9uIGFib3V0IHdoaWNoIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwg YmUgdXNlZCB3aGVuIHNlbGVjdGluZyB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoLiINCg0KQWxs IHRocmVlIHJlc3VsdCBpbiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCBiZWluZyBzZWxlY3RlZCwg YW5kIHRoZXkgYXJlbid0IG5lY2Vzc2FyaWx5IGV4Y2x1c2l2ZSBvZiBvbmUgYW5vdGhlciBpZiB5 b3UgaGF2ZSBydWxlcyBmb3IgcmVzb2x2aW5nIGNvbmZsaWN0czsgdGhlIGRldGFpbHMgb2YgdGhv c2UgcnVsZXMgYXJlIG5vdCBhcmNoaXRlY3R1cmFsLg0KDQpJTU8sIHRoZSBhcmNoaXRlY3R1cmUg bmVlZHMgdG8gZXJyIG9uIHRoZSBzaWRlIG9mIGJlaW5nIGRlc2NyaXB0aXZlIG92ZXIgYmVpbmcg cHJvc2NyaXB0aXZlIHdoZW4gdGhlcmUgaXMgYSBjb25mbGljdCBiZXR3ZWVuIHRoZSB0d28uDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzZmMgW3NmYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBDaGFu Z2NoZW5nIEh1YW5nIFtodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJs ZXRvbi5jYT5dDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAxMjozMSBQTQ0KVG86ICdS b24gUGFya2VyJzsgJ0x1Y3kgeW9uZyc7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBtaWtlYmlhbmNAYW9sLmNvbTxtYWls dG86bWlrZWJpYW5jQGFvbC5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCkkg YWdyZWUgd2l0aCBSb27igJlzIGNvbW1lbnRzLiBTZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgbWFr ZSB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggaW5zdGFuY2VzIHdpbGwgYmUgdXNlZC4gSXQgY2Fu IGJlIGRpZmZlcmVudCBob3AtYnktaG9wIChlLmcuIGluIGEgdHJlZSB0b3BvbG9neSkuIEluIG9y ZGVyIHRvIGRvIHNvLCBpdCBpcyBpbXBvcnRhbnQgYSBwaHlzaWNhbCBuZXR3b3JrIG1ha2VzIGEg c2VydmljZSBmdW5jdGlvbiBjaGFpbiBhd2FyZSBvZiB0aGUgYXZhaWxhYmxlIGluc3RhbmNlcy4g VGhlc2UgaXMgbm8gbmVlZCB0byBpZGVudGlmeSBlYWNoIHBvc3NpYmxlIFNGUCBieSBhIHBoeXNp Y2FsIG5ldHdvcmsuIElmIGEgc2VydmljZSBmdW5jdGlvbiBjaGFpbiB3YW50cyB0byB1c2UgbXVs dGlwbGUgU0ZQcywgaXQgc2hvdWxkIHByb3ZpZGUgdGhlIGlkZW50aWZpZXIgZm9yIGVhY2ggZmxv dyB0aGF0IHVzZXMgYSBwYXJ0aWN1bGFyIFNGUCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgZm9yd2Fy ZGluZyBydWxlcyAoaS5lLiBuZXh0IGhvcCkuIE5ldmVydGhlbGVzcywgYmVjYXVzZSBhIHBoeXNp Y2FsIG5ldHdvcmsgbmVlZCB0byBzdXBwb3J0IG11bHRpcGxlIHRlbmFudHMsIGl0IGRvZXMgbmVl ZCB0byBpZGVudGlmeSBkaWZmZXJlbnQgdGVuYW50cy4gT3VyIHJlY2VudCBjb250cmlidXRpb24g KGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1YW5nLXNmYy11c2UtY2Fz ZS1yZWN1cnNpdmUtc2VydmljZS8gKSBoYXMgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgaW4gYSBtb3Jl IGdlbmVyYWwgYXJjaGl0ZWN0dXJlLiBIb3BlIGl0IGNhbiBiZSBoZWxwZnVsIGZvciB0aGlzIGRp c2N1c3Npb24uDQpDaGFuZw0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA4 OjIwIEFNDQpUbzogTHVjeSB5b25nOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPjsgam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpJdCBp cyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNhbnQgdG8gaWRlbnRpZnkgdGhhdCBtdWx0aXBsZSBh ZGRyZXNzYWJsZSBpbnN0YW5jZXMgb2YgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFyZSBleHBsaWNpdGx5 IGFsbG93ZWQuIFdoZXRoZXIgdGhvc2UgaW5zdGFuY2UgcGVyZm9ybSBzb21lIGZ1cnRoZXIgbGV2 ZWwgb2YgbG9hZCBiYWxhbmNpbmcgaXMgaXJyZWxldmFudCwgYXMgaGFzIGJlZW4gcG9pbnRlZCBv dXQgYnkgSm9lbC4gSXQgaXMgYWxzbyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNhbnQgdG8gYXNz aWduIHJlc3BvbnNpYmlsaXR5IGZvciBpbnN0YW5jZSBzZWxlY3Rpb24uIEluIHBhcnRpY3VsYXIs IGlzIHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gY2VudHJhbGl6ZWQsIGRpc3RyaWJ1dGVkLCBvciBz b21lIGNvbWJpbmF0aW9uPyBXaGljaCBmdW5jdGlvbmFsIGVudGl0aWVzIGluIHRoZSBhcmNoaXRl Y3R1cmUgaGF2ZSB3aGF0IHJlc3BvbnNpYmlsaXRpZXMgdG8gYWNoaWV2ZSB0aGlzPyBJbiBOb3Zl bWJlciwgMjAxMywgYWZ0ZXIgSUVURiA4OCwgSSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCwgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1wYXRoLTAwLCB3 aGljaCBwcm9wb3NlZCB0aGF0IHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gd2FzIG1hZGUgaG9wIGJ5 IGhvcCBieSB0aGUgc2VydmljZSBmdW5jdGlvbnMgdGhlbXNlbHZlcywgaW4gYSBmdWxseSBkaXN0 cmlidXRlZCBtYW5uZXIuIFRoYXQgd2FzIGp1c3QgYSBwcm9wb3NhbCBhbmQgSSBhbSBub3Qgd2Vk ZGVkIHRvIGl0LCBieSBhbnkgbWVhbnMuIEpvZWwgYXNrZWQgYWJvdXQgc3BlY2lmaWNpdHkgYW5k IGl0IGlzIGF0IHRoaXMgbGV2ZWwgdGhhdCBJ4oCZZCBsaWtlIHRvIHNlZSB0aGUgYXJjaGl0ZWN0 dXJlIGRlc2NyaWJlIHRoaW5ncy4gSXQgc2hvdWxkIGJlIGFibGUgdG8gYW5zd2VyIHRoZSBxdWVz dGlvbiwg4oCcaG93IGRvZXMgbXVsdGktaW5zdGFuY2Ugc2VsZWN0aW9uIHdvcmsgaW4gU0ZDP+KA nSBpbiBhIGNvbmNpc2UgbWFubmVyLiBJZiB0aGUgZ3JvdXAgZmVlbHMgdGhhdCB0aGVyZSBzaG91 bGQgYmUgbW9yZSB0aGFuIG9uZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiwgc28gYmUgaXQsIGJ1 dCB3ZSBzaG91bGQgYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgaGlnaCBsZXZlbCBtZWNoYW5pc20g YW5kIHJhdGlvbmFsZSBmb3IgZWFjaCBzdWNjaW5jdGx5LiBPZiBjb3Vyc2UsIHRoYXQgaXMgbWVy ZWx5IG9uZSBzdWNoIHF1ZXN0aW9uIGFuZCB0aGVyZSBhcmUgbWFueSBvdGhlcnMgdGhhdCBhbiBh cmNoaXRlY3R1cmFsIGRvY3VtZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlc2NyaWJlLg0KUm9uDQpG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kg eW9uZw0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMTE6MDUgQU0NClRvOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PjsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgam1oQGpvZWxo YWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQpBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1h bmRhdGUgb25seSB1c2Ugb2YgdGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRo ZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQpMdWN5DQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpTZW50OiBUaHVyc2RheSwgSnVseSAx MCwgMjAxNCAyOjA2IEFNDQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPjsgam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpSZS0sDQpUaGUgbWVyZ2Vk IGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIuIEkg b2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8gZGVyaXZlIGZvcndhcmRpbmcgYWN0aW9u cy4NClJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2Yg ZXZlcnkgYXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxl ZCBkb21haW4gaXMgbm90IHJlcXVpcmVkL2p1c3RpZmllZCBub3IgcG9zc2libGUgaW4gdmFyaW91 cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVs eSBvbiB0aGUgcGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGJlIHByZXNlbnQgaW4gYWxs IGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUgcmVxdWlyZWQgdG8gc3RydWN0dXJlIGEgc2Vy dmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCB0byBpbmZlciBmb3J3YXJk aW5nIGFjdGlvbnMgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KQ2hlZXJzLA0K TWVkDQpEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCkVudm95w6kgOiBt ZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMw0Kw4AgOiBqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gU0YgQ2hhaW4gYW5kIFNGIFBhdGg/IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5p dGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8gdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggdGhlIGRy YWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGVzZSB0ZXJtcy4NClRvIG1l LCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcyB3aGV0aGVyIGl0IGlzIHRo ZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUgSUQg b2YgdGhlIFNGQyBIZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRo KSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91 cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZv cndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3IgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBv ciBwYXRoIHRvIGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQpJZiB0aGUgbGF0 dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlIHJlcXVpcmUgdGhhdCBi b3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZSBvbmUgcmVxdWlyZWQgYW5kIHRo ZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZSB2ZW5kb3JzIG9ubHkgc3VwcG9ydGluZyBT RlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IGptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KVG86 IHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRm Lm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDgsIDIwMTQNClN1YmplY3Q6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkgaGF2ZSBiZWVuIHRyeWlu ZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFuc3dlciBhIG51bWJlciBvZg0KY29tbWVu dHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVyZ2VkIGFyY2h0aWVj dHVyZQ0KZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZyBncm91cCBhZ3JlZW1lbnQg b24gdGhlIGludGVudCwgd2UNCndpbGwgd29yayB0byBpbXByb3ZlIHRoZSB3b3JkaW5nIHNvIHRo YXQgcmVhZGVycyB3aG8gaGF2ZSBub3QNCnBhcnRpY2lwYXRlZCBpbiB0aGUgV0cgZGlzY3Vzc2lv biB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZSB3b3JraW5nDQpncm91cCBpbnRlbmRzLg0K DQpCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteSBwZXJzb25h bCB2aWV3LCBhbmQgc2VlDQppZiB0aGF0IGhlbHBzLg0KDQpJbiB0aGlzIHJlZ2FyZCwgaXQgaXMg aW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0IHdoYXQgd2UgYXJlDQpkZWZpbmluZyBpcyB0 aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFyZSBub3QgYXR0ZW1wdGluZyB0bw0KZGVm aW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRpb24gZm9yIHNlcnZpY2Ug Y2hhaW5pbmcuDQpUaGF0IHdvdWxkIGVuY29tcGFzcyBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wg YW5kIHBvbGljeSBmdW5jdGlvbnMsDQp2aXJ0dWFsIG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1l bnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMuDQoNCkFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55 IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhpc3QgaW4gdGhlDQpsYXJnZXIgc3lzdGVt LCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGggYWJvdmUgd2hlcmUgd2UgYXJlIGZ1bmN0aW9uaW5n LA0KYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlIGRvaW5n Lg0KDQpJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFz IEkgdW5kZXJzdGFuZCB0aGVtLA0KSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNp bmcuIFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZQ0KZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJh bGFuY2luZyBjYW4gYW5kIHdpbGwgaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlDQpjaGFpbmluZy4gVGhl cmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRv DQpwZXJtaXQgYWxsIG9mIHRoZXNlLCBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGlj dWxhciBraW5kIGJlIHVzZWQNCmluIGFueSBzb2x1dGlvbi4NCg0KMSkgTG9hZCBiYWxhbmNpbmcg YXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4gVGhpcyBpcyBhDQpzZXJ2aWNl IGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZCBtb2RpZmllcyB0aGVtIChv ciBtYXJrcw0KdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vydmlj ZSBpbnN0YW5jZSB0byByZWNlaXZlDQp0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9y dGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8NCmluY2x1ZGUgaW4gc2VydmljZSBj aGFpbmluZy4gSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbg0KaG93IHNl cnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24g dGhlDQphcmNodGllY3R1cmUuIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQg aXMgc2ltcGx5IGEgc2VydmljZQ0KZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJs eWluZyBwYWNrZXQuDQoNCjIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0 IGlzLCBvbmUgY2FuIGhhdmUgd2hhdCBhcHBlYXJzDQp0byB0aGUgc2VydmljZSBjaGFpbmluZyBh cmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YgY29udGFjdCBmb3IgYQ0Kc3BlY2lmaWMg c2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhIGNvbGxlY3Rp b24gb2YNCnZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBv bmUgb3Igc2V2ZXJhbCBsb2FkDQpiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlr ZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDDQphZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzIGlu dmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQptZWNoYW5pc21zLiBJ dCBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KbWVjaGFu aXNtcywgc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwg YW5kIHZtDQppbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0 dGluZyB0aGlzIGlzIGxhcmdlbHkNCnRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3Vy IHRlcm1pbm9sb2d5IGRvZXMgbm90IGxlYWQgcmVhZGVycyB0bw0KdGhpbmsgd2UgYXJlIHByb2hp Yml0aW5nIGl0Lg0KDQozKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5 IHNlbGVjdGluZyBwYWNrZXQgcGF0aHMgZm9yDQp0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRp cmVjdCB0cmFmZmljIHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkDQpub3Qgd2FudCB0byBy ZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZQ0K cGxhY2UgaW4gdGhlIG5ldHdvcmsuDQoNCkl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRo ZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kIHRvIHJlZmVyIHRvDQp0aGUgY29sbGVjdGlvbiBv ZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlIGNoYWluaW5nIGFzIGEgc2luZ2xlDQpw b2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMgYSBnb29kIHRlcm0uIEJ1 dCBiZWNhdXNlIEkNCmRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLCB0aGUgcG9pbnQgb2Yg dHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlzIHRvDQpkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2Yg dHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIgb3IgY2x1c3RlcmVkDQpzZXJ2aWNlIGZ1bmN0 aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZSBuZXR3b3JrLg0KDQpOb3cgd2l0aCB0aGF0 IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0IHNlcnZpY2UgY2hhaW4gYW5k DQpzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZSBvZiBsb2dpY2FsIGZ1 bmN0aW9ucyB0byBiZQ0KYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLiBJdCBpcyBlcXVp dmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUNCnN1YnNldCBvZiB0cmFmZmljIGlzIHRvIGdldCBE UEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KZmlyZXdhbGwgd2hpbGUgYSBk aWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRoZSBjYWNoZSB3aXRob3V0DQp2 aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQoNClRoYXQgaXMgbm90IGVub3Vn aCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tldHMuIEEgc2VydmljZSBwYXRoDQppcywg aW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yay4g VGhvc2UNCmxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1 bmN0aW9uIGRlbGl2ZXJ5DQpsb2NhdGlvbnMuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBieSBJUCBh ZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQNCmFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUg YXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zDQptYXkgYmUga25vd24g dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZSB0cmFuc3BvcnQu DQoNCj5Gcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3JvdXAs IHdlIG5lZWQgdG8gYmUgYWJsZQ0KdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFj dGlvbiwgdGhlIHNlcnZpY2UgY2hhaW4sIHdoaWNoDQpkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFu ZCB3ZSBuZWVkIHRvIHRhbGsgYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGgNCnBhY2tldHMgd2ls bCB0YWtlIGluIHRoZSBuZXR3b3JrLg0KDQpTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNh aWQgImJ1dCB0aGUgd2hvbGUgcGF0aCBtYXkgbm90IGJlIGtub3duDQphdCB0aGUgZnJvbnQuIiBU aGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuDQpGaXJz dCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZCBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNh biBiZQ0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0aGUg c2VydmljZSBjaGFpbmluZw0KbWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCBi cmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0 d2VlbiBMQU5zLikgVGhlIG90aGVyIHByb3Zpc2lvbiB3ZSBtYWtlIGlzIHRoYXQNCnJlY2xhc3Np ZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdp bGwNCmRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBpbmZvcm1hdGlvbiBh dmFpbGFibGUgYXQgdGhlDQpyZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCg0KSSBob3BlIHRoYXQg dGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYN CnRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZyBncm91cCwgd2UgY2FuIGZp Z3VyZSBvdXQgd2hhdA0KYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkIHRvIGNvbnZleSB0aGlz Lg0KSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50ZW50LCB0aGVuIHdl IHdpbGwgb2YgY291cnNlDQphZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVt ZW50cy4NCklmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRy eSBuZXh0Lg0KDQpZb3VycywNCkpvZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0Kc2ZjIG1haWxpbmcgbGlzdA0KDQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A783MISOUT7MSGUSRCF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyBcO2NvbG9yXDpcIzFGNDk3RCI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAw IDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R29vZCBj YXRjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+bWlrZWJpYW5jQGFvbC5jb208YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgNDoyNiBQTTxicj4NCjxiPlRvOjwvYj4gaHVhbmdAc2NlLmNhcmxldG9uLmNh OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBl cmhhcHMgd2Ugc2hvdWxkIHJld29yZCB0aGF0LCB0aGVuLCB0byBpbmNsdWRlIGEgZGVmaW5pdGlv biBvZiBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlIGFuZCBtYWtlIHN1cmUgd2UgYXJlIGNvbnNp c3RlbnQgd2hlbiByZWZlcnJpbmcgdG8gdGhlc2UgZW50aXRpZXMuLiAmbmJzcDtCYXNlZCBvbiBt b3N0DQogb2YgdGhlIGNvbW1lbnRzIEkndmUgc2VlbiwgaXQgc2VlbXMgdG8gbWFrZSBhIGxvdCBv ZiBzZW5zZSB0byBjb25zaWRlciBhIFNlcnZpY2UgRnVuY3Rpb24gbW9yZSBvZiBhbiBhYnN0cmFj dCBlbnRpdHkgdGhhdCBoYXMgb25lIG9yIG1vcmUgaW5zdGFuY2VzLiAmbmJzcDtBbiBhYnN0cmFj dCBTZXJ2aWNlIEZ1bmN0aW9uIHdpdGggb25seSBhIHNpbmdsZSBpbnN0YW5jZSBtaWdodCBhcHBl YXIgYXMgb3ZlcmtpbGwsIGhvd2V2ZXIgaXQgd291bGQgbm9ybWFsaXplDQogbXVjaCBvZiB0aGUg Y29udmVyc2F0aW9uIGFuZCBhbGxvdyBmb3IgY2xlYXJlciBkaXNjdXNzaW9ucyBhYm91dCB3aGF0 IGhhcHBlbnMgd2hlbiBhbmQgd2hlcmUgJmFtcDtjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb20gdGhlIHByb2JsZW0g c3RhdGVtZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IFRoZSB0ZXJtIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW5pbmcgaXMgdXNlZCB0byBkZXNjcmliZSB0aGUgZGVmaW5pdGlvbiBhbmQgaW5zdGFudGlhdGlv biBvZiBhbiBvcmRlcmVkIHNldCBvZiBpbnN0YW5jZXMgb2Ygc3VjaCBzZXJ2aWNlIGZ1bmN0aW9u cywgYW5kIHRoZSBzdWJzZXF1ZW50ICZxdW90O3N0ZWVyaW5nJnF1b3Q7IG9mIHRyYWZmaWMgZmxv d3MgdGhyb3VnaCB0aG9zZSBzZXJ2aWNlIGZ1bmN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhl IGluc3RhbmNlIGlzIHRoZSB0aGluZyB0aGF0IGlzIGJlaW5nIGNoYWluZWQuICZuYnNwO09mIGNv dXJzZSwgaWYgdGhlIGNsYXNzaWZpZXIgb25seSBzcGVjaWZpZXMgY2hvb3NlcyBhIGNoYWluICh7 U0ZufSkgYW5kIG5vdCBhIHBhdGggKHtTRklufSksIHJlbGlucXVpc2hpbmcNCiB0aGUgZGVjaXNp b24gb2Ygd2hpY2ggaW5zdGFudGlhdGlvbiB0byBhbm90aGVyIHByb2Nlc3MsIHRoZW4gdGhlcmUg dGVjaG5pY2FsbHkgaXMgbmV2ZXIgYW4gYWN0dWFsIGNvbXBsZXRlZCAmcXVvdDtvcmRlcmVkIHNl dCBvZiBpbnN0YW5jZXMmcXVvdDsgcHJvZHVjZWQgKGJlY2F1c2UgU0ZJKG4pIGlzIG9ubHkgY2hv c2VuIHNvbWV0aW1lIGFmdGVyIGJlaW5nIGRlbGl2ZXJlZCB0byBTRkkobi0xKSkgcmVuZGVyaW5n IHRoZSBTRlAgYW4gYWJzdHJhY3QtaXNoIGNvbmNlcHR1YWwNCiB0aGluZy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGVu IGFnYWluLCBpdCBjb3VsZCBiZSBJJ3ZlIHJlYWQgdG9vIG1hbnkgb2YgdGhlc2UgdG9kYXkgYW5k IG15IGJyYWluIGlzIG5vdyBmdWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXpl PSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0 b24uY2ElM2NodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYSZsdDto dWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+Jmx0OzxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDog PC9iPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCjxicj4NCkFz IGRlZmluZWQgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50LCBhIHNlcnZpY2UgZnVu Y3Rpb24gaXMgbm90IGEgY29uY2VwdC4gSGVyZSBpcyB0aGUgcXVvdGUgZnJvbSB0aGUgZG9jdW1l bnQgJnF1b3Q7QSBTZXJ2aWNlIEZ1bmN0aW9uIGNhbiBiZSBhIHZpcnR1YWwgaW5zdGFuY2Ugb3Ig YmUgZW1iZWRkZWQgaW4gYSBwaHlzaWNhbCBuZXR3b3JrIGVsZW1lbnQuJnF1b3Q7IFRoaXMgbWVh bnMgYSBzZXJ2aWNlIGZ1bmN0aW9uIGlzIGEgdmlydHVhbCBlbnRpdHkuPGJyPg0KPGJyPg0KQSB2 aXJ0dWFsIG1hY2hpbmUgKFZNKSwgZm9yIGV4YW1wbGUsIGNhbiBkZWNpZGUgd2hpY2ggcHJvY2Vz cyB0byBydW4gZmlyc3QuIFNpbWlsYXJseSBhIHNlcnZpY2UgZnVuY3Rpb24gY2FuIGRlY2lkZSBo b3cgYSBwYWNrZXQgYmVpbmcgcHJvY2Vzc2VkIGFuZCBmb3J3YXJkZWQgdG8gdGhlIG5leHQgc2Vy dmljZSBmdW5jdGlvbiBob3AuPGJyPg0KPGJyPg0KQ2hhbmc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPk9uIDA3 LzEwLzIwMTQgMTE6MzYgQU0sIFJvbiBQYXJrZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLCBNaWtlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJldHdlZW4gc2VydmljZSBmdW5jdGlvbiBhbmQgc2VydmljZSBmdW5jdGlvbiBpbnN0 YW5jZSwgSSB0aGluayBpdCB3b3VsZCBoYXZlIHRvIGJlIHRoZSBpbnN0YW5jZSwNCiBzaW5jZSB0 aGUgZm9ybWVyIGlzIGNvbmNlcHR1YWwuIEJ1dCwgaW4gYSBkaXN0cmlidXRlZCBwYXRoIHNlbGVj dGlvbiBhcHByb2FjaCwgbWlnaHQgaXQgbWFrZSBzZW5zZSB0byBhc3NpZ24gdGhpcyBkdXR5IHRv IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGZvcndhcmRlciAoU0ZGKT88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Sb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAyOjM0 IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPkkuU21p dGhARjUuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mcXVvdDtTZXJ2aWNlIEZ1bmN0aW9ucyBNQVkgbWFrZSB0aGUgZGVjaXNpb24gYWJvdXQg d2hpY2ggU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMgd2lsbCBiZSB1c2VkIHdoZW4NCiBzZWxl Y3RpbmcgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4mcXVvdDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JcyBpdCBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgbWFrZXMgdGhhdCBkZWNpc2lvbj8g b3IgdGhlIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIg c2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFs aWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+RnJvbToN CjwvYj48YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20lM2NJLlNtaXRoQEY1LmNvbSI+SS5T bWl0aEBGNS5jb20mbHQ7SS5TbWl0aEBGNS5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+Q2hh bmdjaGVuZyBIdWFuZyZsdDs8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5o dWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Jmd0OywnUm9uIFBhcmtlcicmbHQ7PGEgaHJlZj0ibWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb208L2E+Jmd0OywnTHVjeSB5b25nJyZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55 b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29tPC9hPiZndDssPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOm1p a2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZsdDs8YSBo cmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4m Z3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T ZW50OiA8L2I+VGh1cnNkYXksIEp1bHkgMTAsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+U2VydmljZSBmdW5jdGlvbnMNCiBzaG91bGQgbWFrZSB0aGUgZGVjaXNpb24g YWJvdXQgd2hpY2ggaW5zdGFuY2VzIHdpbGwgYmUgdXNlZDxicj4NCjxicj4NCkkgdGhpbmsgaXQg aXMgc3VmZmljaWVudCBmb3IgdGhlIGFyY2hpdGVjdHVyZSB0byBzYXksPGJyPg0KPGJyPg0KJnF1 b3Q7U2VydmljZSBGdW5jdGlvbnMgTUFZIG1ha2UgdGhlIGRlY2lzaW9uIGFib3V0IHdoaWNoIFNl cnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwgYmUgdXNlZCB3aGVuIHNlbGVjdGluZyB0aGUg U2VydmljZSBGdW5jdGlvbiBQYXRoLiZxdW90Ow0KPGJyPg0KPGJyPg0KQnV0IHlvdSBhbHNvIHNh eSBuZWVkIHRvIHNheSwgPGJyPg0KPGJyPg0KJnF1b3Q7U2VydmljZSBGdW5jdGlvbiBDbGFzc2lm aWVycyAob3IgU05GJ3Mgb3IgU0ZGJ3MsIGFzIHRoZSBjYXNlIG1heSBiZSkgTUFZIG1ha2UgdGhl IGRlY2lzaW9uIGFib3V0IHdoaWNoIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIHdpbGwgYmUg dXNlZCB3aGVuIHNlbGVjdGluZyB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoLiZxdW90Ow0KPGJy Pg0KPGJyPg0KYW5kLCA8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+JnF1b3Q7RXh0ZXJuYWwgb3JjaGVzdHJhdGlvbiBmcmFtZXdvcmtzIE1BWSBtYWtl IHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBTZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlcyB3aWxs IGJlIHVzZWQgd2hlbiBzZWxlY3RpbmcgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4mcXVvdDs8 YnI+DQo8YnI+DQpBbGwgdGhyZWUgcmVzdWx0IGluIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIGJl aW5nIHNlbGVjdGVkLCBhbmQgdGhleSBhcmVuJ3QgbmVjZXNzYXJpbHkgZXhjbHVzaXZlIG9mIG9u ZSBhbm90aGVyIGlmIHlvdSBoYXZlIHJ1bGVzIGZvciByZXNvbHZpbmcgY29uZmxpY3RzOyB0aGUg ZGV0YWlscyBvZiB0aG9zZSBydWxlcyBhcmUgbm90IGFyY2hpdGVjdHVyYWwuPGJyPg0KPGJyPg0K SU1PLCB0aGUgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGVyciBvbiB0aGUgc2lkZSBvZiBiZWluZyBk ZXNjcmlwdGl2ZSBvdmVyIGJlaW5nIHByb3NjcmlwdGl2ZSB3aGVuIHRoZXJlIGlzIGEgY29uZmxp Y3QgYmV0d2VlbiB0aGUgdHdvLjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwRjI1Mjc4NyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBz ZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBDaGFuZ2NoZW5nIEh1YW5nIFs8YSBocmVmPSJtYWls dG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+XTxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAxMjozMSBQTTxicj4NCjxiPlRv OjwvYj4gJ1JvbiBQYXJrZXInOyAnTHVjeSB5b25nJzsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47 IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5j b208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBSb27igJlzIGNvbW1lbnRzLiBTZXJ2aWNlIGZ1bmN0 aW9ucyBzaG91bGQgbWFrZSB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggaW5zdGFuY2VzIHdpbGwN CiBiZSB1c2VkLiBJdCBjYW4gYmUgZGlmZmVyZW50IGhvcC1ieS1ob3AgKGUuZy4gaW4gYSB0cmVl IHRvcG9sb2d5KS4gSW4gb3JkZXIgdG8gZG8gc28sIGl0IGlzIGltcG9ydGFudCBhIHBoeXNpY2Fs IG5ldHdvcmsgbWFrZXMgYSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGF3YXJlIG9mIHRoZSBhdmFp bGFibGUgaW5zdGFuY2VzLiBUaGVzZSBpcyBubyBuZWVkIHRvIGlkZW50aWZ5IGVhY2ggcG9zc2li bGUgU0ZQIGJ5IGEgcGh5c2ljYWwgbmV0d29yay4NCiBJZiBhIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4gd2FudHMgdG8gdXNlIG11bHRpcGxlIFNGUHMsIGl0IHNob3VsZCBwcm92aWRlIHRoZSBpZGVu dGlmaWVyIGZvciBlYWNoIGZsb3cgdGhhdCB1c2VzIGEgcGFydGljdWxhciBTRlAgYW5kIHRoZSBj b3JyZXNwb25kaW5nIGZvcndhcmRpbmcgcnVsZXMgKGkuZS4gbmV4dCBob3ApLiBOZXZlcnRoZWxl c3MsIGJlY2F1c2UgYSBwaHlzaWNhbCBuZXR3b3JrIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSB0 ZW5hbnRzLA0KIGl0IGRvZXMgbmVlZCB0byBpZGVudGlmeSBkaWZmZXJlbnQgdGVuYW50cy4gT3Vy IHJlY2VudCBjb250cmlidXRpb24gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWh1YW5nLXNmYy11c2UtY2FzZS1yZWN1cnNpdmUtc2VydmljZS8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1z ZmMtdXNlLWNhc2UtcmVjdXJzaXZlLXNlcnZpY2UvPC9hPiApIGhhcw0KIGRpc2N1c3NlZCB0aGlz IGlzc3VlIGluIGEgbW9yZSBnZW5lcmFsIGFyY2hpdGVjdHVyZS4gSG9wZSBpdCBjYW4gYmUgaGVs cGZ1bCBmb3IgdGhpcyBkaXNjdXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNoYW5nDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiBzZmMgWzxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+Um9uIFBhcmtlcjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA4OjIwIEFNPGJyPg0KPGI+VG86PC9iPiBMdWN5 IHlvbmc7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNA YW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgYXJjaGl0ZWN0dXJhbGx5 IHNpZ25pZmljYW50IHRvIGlkZW50aWZ5IHRoYXQgbXVsdGlwbGUgYWRkcmVzc2FibGUgaW5zdGFu Y2VzIG9mIGEgc2VydmljZSBmdW5jdGlvbg0KIGFyZSBleHBsaWNpdGx5IGFsbG93ZWQuIFdoZXRo ZXIgdGhvc2UgaW5zdGFuY2UgcGVyZm9ybSBzb21lIGZ1cnRoZXIgbGV2ZWwgb2YgbG9hZCBiYWxh bmNpbmcgaXMgaXJyZWxldmFudCwgYXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgYnkgSm9lbC4gSXQg aXMgYWxzbyBhcmNoaXRlY3R1cmFsbHkgc2lnbmlmaWNhbnQgdG8gYXNzaWduIHJlc3BvbnNpYmls aXR5IGZvciBpbnN0YW5jZSBzZWxlY3Rpb24uIEluIHBhcnRpY3VsYXIsIGlzIHRoZSBpbnN0YW5j ZQ0KIHNlbGVjdGlvbiBjZW50cmFsaXplZCwgZGlzdHJpYnV0ZWQsIG9yIHNvbWUgY29tYmluYXRp b24/IFdoaWNoIGZ1bmN0aW9uYWwgZW50aXRpZXMgaW4gdGhlIGFyY2hpdGVjdHVyZSBoYXZlIHdo YXQgcmVzcG9uc2liaWxpdGllcyB0byBhY2hpZXZlIHRoaXM/IEluIE5vdmVtYmVyLCAyMDEzLCBh ZnRlciBJRVRGIDg4LCBJIHN1Ym1pdHRlZCB0aGlzIGRyYWZ0LA0KPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFya2VyLXNmYy1jaGFpbi10by1wYXRoLTAwIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXJrZXItc2Zj LWNoYWluLXRvLXBhdGgtMDA8L2E+LCB3aGljaCBwcm9wb3NlZCB0aGF0IHRoZSBpbnN0YW5jZSBz ZWxlY3Rpb24gd2FzIG1hZGUgaG9wIGJ5IGhvcCBieSB0aGUgc2VydmljZSBmdW5jdGlvbnMgdGhl bXNlbHZlcywgaW4gYSBmdWxseSBkaXN0cmlidXRlZCBtYW5uZXIuIFRoYXQgd2FzIGp1c3QgYSBw cm9wb3NhbCBhbmQgSSBhbSBub3Qgd2VkZGVkIHRvIGl0LCBieSBhbnkgbWVhbnMuDQogSm9lbCBh c2tlZCBhYm91dCBzcGVjaWZpY2l0eSBhbmQgaXQgaXMgYXQgdGhpcyBsZXZlbCB0aGF0IEnigJlk IGxpa2UgdG8gc2VlIHRoZSBhcmNoaXRlY3R1cmUgZGVzY3JpYmUgdGhpbmdzLiBJdCBzaG91bGQg YmUgYWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCDigJxob3cgZG9lcyBtdWx0aS1pbnN0YW5j ZSBzZWxlY3Rpb24gd29yayBpbiBTRkM/4oCdIGluIGEgY29uY2lzZSBtYW5uZXIuIElmIHRoZSBn cm91cCBmZWVscyB0aGF0IHRoZXJlIHNob3VsZA0KIGJlIG1vcmUgdGhhbiBvbmUgYW5zd2VyIHRv IHRoYXQgcXVlc3Rpb24sIHNvIGJlIGl0LCBidXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZGVzY3Jp YmUgdGhlIGhpZ2ggbGV2ZWwgbWVjaGFuaXNtIGFuZCByYXRpb25hbGUgZm9yIGVhY2ggc3VjY2lu Y3RseS4gT2YgY291cnNlLCB0aGF0IGlzIG1lcmVseSBvbmUgc3VjaCBxdWVzdGlvbiBhbmQgdGhl cmUgYXJlIG1hbnkgb3RoZXJzIHRoYXQgYW4gYXJjaGl0ZWN0dXJhbCBkb2N1bWVudCBzaG91bGQg YmUNCiBhYmxlIHRvIGRlc2NyaWJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+IHNmYw0KIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5MdWN5IHlvbmc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgMTE6MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5 IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRp bmcNCiBhY3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4gc2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjowNiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlrZWJpYW5jQGFv bC5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0i X2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyA7Y29sb3I6IzFGNDk3RCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UmUtLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxRjQ5 N0QmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4 cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQg aWRlbnRpZmllcg0KIHRvIGRlcml2ZSBmb3J3YXJkaW5nIGFjdGlvbnMuIDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxRjQ5N0QmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPlJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVs bCBrbm93bGVkZ2Ugb2YgZXZlcnkgYXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhp bg0KIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5vciBw b3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFGNDk3RCZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+U0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUg cGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1l bnRzOg0KIHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNo YWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvIGluZmVyIGZvcndhcmRpbmcgYWN0 aW9ucyBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFGNDk3RCZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxRjQ5N0QmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk1l ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlIDo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQog c2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4g PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlrZWJp YW5jQGFvbC5jb208L2E+PGJyPg0KPGI+RW52b3nDqSA6PC9iPiBtZXJjcmVkaSA5IGp1aWxsZXQg MjAxNCAyMjowMzxicj4NCjxiPsOAIDo8L2I+IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT47DQo8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCjxiPk9iamV0IDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5JcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0 aW9uDQogc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRob3NlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBk cmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24gdGhlc2UgdGVybXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UbyBtZSwgdGhlIG9uZSBwb2lu dCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRo aXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5DQogd2hhdCB0aGUgSUQgb2YgdGhlIFNGQyBI ZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhp cyBkcmFmdCBzaW1wbHkgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcg b3RoZXIgZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFz ZWQgb24gY2hhaW4gb3IgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvciBwYXRoIHRvIGJl IG5lZ290aWF0ZWQNCiBpbiB0aGUgY29udHJvbC1wbGFuZS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRo ZSBkcmFmdCB3b3VsZCBoYXZlIHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBv cnRlZCAob3IgbWFrZQ0KIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBh dm9pZCBzb21lIHZlbmRvcnMgb25seSBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3Vw cG9ydGluZyBTRkMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4N CjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5 OSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjYuNzVw dCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNj am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb20m bHQ7am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGll dGYub3JnJmx0O3NmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPlR1ZXNkYXks IEp1bHkgOCwgMjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCjxicj4NCkkgaGF2ZSBiZWVuIHRyeWluZyB0 byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFuc3dlciBhIG51bWJlciBvZiA8YnI+DQpjb21t ZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZCBtZXJnZWQgYXJjaHRp ZWN0dXJlIDxicj4NCmRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmcgZ3JvdXAgYWdy ZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIDxicj4NCndpbGwgd29yayB0byBpbXByb3ZlIHRoZSB3 b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgPGJyPg0KcGFydGljaXBhdGVkIGlu IHRoZSBXRyBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdvcmtpbmcg PGJyPg0KZ3JvdXAgaW50ZW5kcy48YnI+DQo8YnI+DQpCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkg d2lsbCB0cnkgdG8gZXhwbGFpbiBteSBwZXJzb25hbCB2aWV3LCBhbmQgc2VlIDxicj4NCmlmIHRo YXQgaGVscHMuPGJyPg0KPGJyPg0KSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBr ZWVwIGluIG1pbmQgdGhhdCB3aGF0IHdlIGFyZSA8YnI+DQpkZWZpbmluZyBpcyB0aGUgZGF0YSBw bGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFyZSBub3QgYXR0ZW1wdGluZyB0byA8YnI+DQpkZWZpbmUg dGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZSBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFp bmluZy4gPGJyPg0KVGhhdCB3b3VsZCBlbmNvbXBhc3MgT1NTL0JTUywgdmFyaW91cyBjb250cm9s IGFuZCBwb2xpY3kgZnVuY3Rpb25zLCA8YnI+DQp2aXJ0dWFsIG1hY2hpbmUgYW5kIGltYWdlIG1h bmFnZW1lbnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMuPGJyPg0KPGJyPg0KQXMgYSByZXN1bHQg dGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0byBleGlzdCBpbiB0aGUg PGJyPg0KbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlIHdoZXJl IHdlIGFyZSBmdW5jdGlvbmluZywgPGJyPg0KYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQg YnkgdGhlIHdvcmsgd2UgYXJlIGRvaW5nLjxicj4NCjxicj4NCkluIG9yZGVyIHRvIGdldCB0byBz ZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0YW5kIHRoZW0sIDxicj4N CkkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVh c3QgdGhyZWUgPGJyPg0KZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5k IHdpbGwgaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIDxicj4NCmNoYWluaW5nLiBUaGVyZSBwcm9iYWJs eSBhcmUgbW9yZS4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gPGJyPg0KcGVy bWl0IGFsbCBvZiB0aGVzZSwgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIg a2luZCBiZSB1c2VkIDxicj4NCmluIGFueSBzb2x1dGlvbi48YnI+DQo8YnI+DQoxKSBMb2FkIGJh bGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLiBUaGlzIGlzIGEg PGJyPg0Kc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9k aWZpZXMgdGhlbSAob3IgbWFya3MgPGJyPg0KdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2Ug YW4gZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZSB0byByZWNlaXZlIDxicj4NCnRoZSB1c2VycyBw YWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50IHNlcnZpY2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0 byA8YnI+DQppbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVoYXZpb3IgbWF5IGFm ZmVjdCByZXF1aXJlbWVudHMgb24gPGJyPg0KaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4g QnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlIDxicj4NCmFyY2h0aWVjdHVyZS4g RnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYSBzZXJ2aWNl IDxicj4NCmZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Ljxi cj4NCjxicj4NCjIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBv bmUgY2FuIGhhdmUgd2hhdCBhcHBlYXJzIDxicj4NCnRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFy Y2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZiBjb250YWN0IGZvciBhIDxicj4NCnNwZWNp ZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQgYnkgYSBjb2xs ZWN0aW9uIG9mIDxicj4NCnZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGlu Y2x1ZGluZyBvbmUgb3Igc2V2ZXJhbCBsb2FkIDxicj4NCmJhbGFuY2VycyAoZm9yIGV4YW1wbGUg dXNpbmcgVlJSUC1saWtlIHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgPGJyPg0KYWRkcmVzcy4p IG1vc3RseSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBw bGFuZSA8YnI+DQptZWNoYW5pc21zLiBJdCBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbCA8YnI+DQptZWNoYW5pc21zLCBzdWNoIGFzIHRob3NlIHJlc3BvbnNp YmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBhbmQgdm0gPGJyPg0KaW5zdGFudGlhdGlvbi4g VGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJnZWx5IDxi cj4NCnRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5IGRvZXMg bm90IGxlYWQgcmVhZGVycyB0byA8YnI+DQp0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuPGJy Pg0KPGJyPg0KMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxl Y3RpbmcgcGFja2V0IHBhdGhzIGZvciA8YnI+DQp0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRp cmVjdCB0cmFmZmljIHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIDxicj4NCm5vdCB3YW50 IHRvIHJlcXVpcmUgdGhhdCBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkg b25lIDxicj4NCnBsYWNlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCkl0IGlzIG9mIGNvdXJz ZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kIHRvIHJlZmVyIHRv IDxicj4NCnRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2Ug Y2hhaW5pbmcgYXMgYSBzaW5nbGUgPGJyPg0KcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVz ZSBjbHVzdGVyIGlzIGEgZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIDxicj4NCmRvIG5vdCBoYXZl IGFub3RoZXIgb25lLiBUaHVzLCB0aGUgcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlz IHRvIDxicj4NCmRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVu dCBzaW5ndWxhciBvciBjbHVzdGVyZWQgPGJyPg0Kc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVy ZW50IHBsYWNlcyBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpOb3cgd2l0aCB0aGF0IHNhaWQs IHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0IHNlcnZpY2UgY2hhaW4gYW5kIDxicj4N CnNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxvZ2ljYWwgZnVu Y3Rpb25zIHRvIGJlIDxicj4NCmFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4gSXQgaXMg ZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIDxicj4NCnN1YnNldCBvZiB0cmFmZmljIGlz IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnI+DQpmaXJl d2FsbCB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNh Y2hlIHdpdGhvdXQgPGJyPg0KdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLjxi cj4NCjxicj4NClRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBh Y2tldHMuIEEgc2VydmljZSBwYXRoIDxicj4NCmlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVu Y2Ugb2YgbG9jYXRpb25zIGluIHRoZSBuZXR3b3JrLiBUaG9zZSA8YnI+DQpsb2NhdGlvbnMgd2ls bCBiZSBzaW5ndWxhciBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSA8YnI+ DQpsb2NhdGlvbnMuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1h eSBiZSBhZGRyZXNzZWQgPGJyPg0KYXMgcG9ydHMgb24gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBk aWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMgPGJyPg0KbWF5IGJlIGtub3duIHRvIHRo ZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Ljxicj4N Cjxicj4NCiZndDtGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMg Z3JvdXAsIHdlIG5lZWQgdG8gYmUgYWJsZSA8YnI+DQp0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxl dmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgd2hpY2ggPGJyPg0KZHJpdmVzIHRo ZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1YWwgZGF0YSBw YXRoIDxicj4NCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NClNl dmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdob2xlIHBhdGgg bWF5IG5vdCBiZSBrbm93biA8YnI+DQphdCB0aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJjaGl0ZWN0 dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gPGJyPg0KRmlyc3QsIGFzIG5v dGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgPGJy Pg0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2ggYXJlIGludmlzaWJsZSB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyA8YnI+DQptZWNoYW5pc21zIChpbiBtdWNoIHRoZSBzYW1lIHdheSB0aGF0 IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5IDxicj4NCmludmlzaWJsZSB0byByb3V0 aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0aGF0IDxi cj4NCnJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNz YXJ5LiBUaGF0IHdpbGwgPGJyPg0KZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2Vk IG9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgPGJyPg0KcmUtY2xhc3NpZmljYXRpb24g cG9pbnQuPGJyPg0KPGJyPg0KSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2Ug YXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYgPGJyPg0KdGhlIGludGVudCBpcyBhY2NlcHRh YmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IDxicj4NCmFk ZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy48YnI+DQpJZiB0aGUgd29y a2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsIHRoZW4gd2Ugd2lsbCBvZiBjb3Vy c2UgPGJyPg0KYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuPGJy Pg0KSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5l eHQuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZmMgbWFpbGlu ZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A783MISOUT7MSGUSRCF_-- From nobody Thu Jul 10 14:15: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 21EA01B2A21 for ; Thu, 10 Jul 2014 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 egZdUvzqc7Lb for ; Thu, 10 Jul 2014 14:15:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3B31B29FA for ; Thu, 10 Jul 2014 14:15:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="121301853" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABPCoNBV60VjycihzWBN3SCJQEBAQEDAQEBYgkCGQIBCBEBAwEBAQodBycLFAMGCAIEARIIE4dNAx7MEBMEjFOBPQUmOIMkgRQElC1EjmGKfoFqQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 10 Jul 2014 21:14:59 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:14:58 -0700 From: Ian Smith To: Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXc= Date: Thu, 10 Jul 2014 21:14:58 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> In-Reply-To: <53BEFFCA.9070308@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kVAKwNhEnvVM8hGH-VAhYAehVUk Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:15:03 -0000 Actually, I think I am disagreeing.=0A= =0A= If the possibility of medium-scale deployments (and that is what 16 million= flows is in my world) of service chains is preconceived as an absurd idea,= then the architecture burdened with that preconception. =0A= =0A= There has to be some point of aim, some degree of aspiration to scale that = is appropriate for the lifespan of the architecture - you don't have to kno= w what it is, but by saying that an arbitrary number is "too far", you're c= reating - even if it isn't intentional - a limit that influences decisions = that have lasting impacts regarding scale-out, failure mitigation, elastici= ty, address space... all kinds of things. That is a problem I'm not partic= ularly eager to deal with.=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= Sent: Thursday, July 10, 2014 5:04 PM=0A= To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= Ian, I don't think you disagree with me at all in this regard.=0A= I am not requesting the the architecture or the solution prohibit=0A= deployments in the specific fashion.=0A= I am objecting to Huang's reading of my note as saying that such=0A= deployments are required they by the archtiecture.=0A= =0A= As I have said repeatedly, I am not trying to prohibit such things.=0A= Whether they are a good idea or not depends upon many factors outside of=0A= the scope of the WG. I happen to think that they are usually a bad idea.= =0A= =0A= But the archtiecture si carefully avoiding attempting to know what is=0A= and is not eployable.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > I disagree.=0A= >=0A= > We routinely have stateful devices that manage tens of millions of concur= rent flows in both access network and data center environments today. You = can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of= tomorrow you are only going to have small numbers of service chains with e= qually small numbers of active service paths?=0A= >=0A= > Your sounds too much like "no one will ever need more than 64K" for comfo= rt.=0A= >=0A= >=0A= > ________________________________________=0A= > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelha= lpern.com]=0A= > Sent: Thursday, July 10, 2014 4:46 PM=0A= > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > No, it will mean that if someone tries to deploy the archtieture=0A= > particularly badly, they will exceed the limits of their devices.=0A= > The architecture does not require such absurd use of service paths.=0A= > Since I can not figure out how to write architectural words to prohibit= =0A= > it, the architecture does permit such abuse.=0A= >=0A= > Please do not read my saying that the archtiecture permits something as= =0A= > saying it is either deisred or required by the work. It isn't.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= >> If you need to support 100 service chains, it will mean 16,000,000=0A= >> paths. That is larger than the routing table of a core router.=0A= >>=0A= >> Chang=0A= >>=0A= >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= >>> The architecture allows a range of deployments, from 1 service path to= =0A= >>> 160000 service paths. I would hope that operators are prepared for=0A= >>> the complexities if they choose to avoid any use of local load=0A= >>> balancing and in stead provision 160,000 service paths.=0A= >>>=0A= >>> Yours,=0A= >>> Joel=0A= >>>=0A= >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= >>>> Paul,=0A= >>>>=0A= >>>> How many path identifiers there will be for a 4 hop service chain with= =0A= >>>> 20 instances at each hop?=0A= >>>>=0A= >>>> Maria=0A= >>>>=0A= >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn=0A= >>>> (paulq)=0A= >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= >>>> *To:* Lucy yong=0A= >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org;= =0A= >>>> mikebianc@aol.com=0A= >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>=0A= >>>> Lucy,=0A= >>>>=0A= >>>> Overall I concur, as you say: a path ID drives the forwarding. I=92d m= ake=0A= >>>> the minor change: the path identifier can be used to derive the needed= =0A= >>>> forwarding and associated transport.=0A= >>>>=0A= >>>> It is _not_ the transport, but rather is used to simply identify the= =0A= >>>> service path (or graph) that packets must traverse. By having a path= =0A= >>>> identifier, the exact indirection that people seem to be asking for on= =0A= >>>> this thread can be simply be implemented. The path identifier provide= s=0A= >>>> nothing more than a lookup, that lookup can result in a one or more=0A= >>>> (equal or weighted) transport next hop(s).=0A= >>>>=0A= >>>> Paul=0A= >>>>=0A= >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>> > wrote:=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> Agree. The arch. doc should not mandate only use of the service path= =0A= >>>> identifier to drive the forwarding actions.=0A= >>>>=0A= >>>> Lucy=0A= >>>>=0A= >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= >>>> Of*mohamed.boucadair@orange.com = =0A= >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= >>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com= =0A= >>>> ;sfc@ietf.org =0A= >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>=0A= >>>> Re-,=0A= >>>>=0A= >>>> The merged draft calls out explicitly a service path identifier. I=0A= >>>> object to use that identifier to derive forwarding actions.=0A= >>>>=0A= >>>> Requiring a SFC system to have the full knowledge of every available S= FC=0A= >>>> forwarding paths within an SFC-enabled domain is not required/justifie= d=0A= >>>> nor possible in various deployment contexts.=0A= >>>>=0A= >>>> SFC forwarding actions should rely on the piece of information that wi= ll=0A= >>>> be present in all deployments: that is the one required to structure a= =0A= >>>> service chain. How that information is used to infer forwarding action= s=0A= >>>> is a solution-oriented discussion.=0A= >>>>=0A= >>>> Cheers,=0A= >>>>=0A= >>>> Med=0A= >>>>=0A= >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.co= m=0A= >>>> =0A= >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= >>>> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.org= =0A= >>>> =0A= >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>=0A= >>>> Is anyone still questioning the difference between SF Chain and SF Pat= h?=0A= >>>> Other than clarifying the definition so that it's clear to those no= t=0A= >>>> familiar with the draft, it seems that everyone agrees on these terms.= =0A= >>>>=0A= >>>> To me, the one point that is still unclear is whether it is the intent= =0A= >>>> of this draft to ultimately specify what the ID of the SFC Header shou= ld=0A= >>>> reference (the chain or the path), or if this draft simply intends to= =0A= >>>> leave that ambiguous, allowing other drafts to dictate the mechanisms= =0A= >>>> for forwarding based on chain or path and the choice of chain or path = to=0A= >>>> be negotiated in the control-plane.=0A= >>>>=0A= >>>> If the latter (ambiguous), then the draft would have require that both= =0A= >>>> SFP and SFC be supported (or make one required and the other optional)= =0A= >>>> to avoid some vendors only supporting SFP and others only supporting= =0A= >>>> SFC.=0A= >>>>=0A= >>>> ----------------------------------------------------------------------= --=0A= >>>>=0A= >>>> *From:*jmh@joelhalpern.com>>> >=0A= >>>> *To:*sfc@ietf.org>= =0A= >>>> *Sent:*Tuesday, July 8, 2014=0A= >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= >>>>=0A= >>>> I have been trying to figure out how to clearly answer a number of=0A= >>>> comments that have been made about the proposed merged archtiecture=0A= >>>> draft. Assuming we can get working group agreement on the intent, we= =0A= >>>> will work to improve the wording so that readers who have not=0A= >>>> participated in the WG discussion will understnd it the way the workin= g=0A= >>>> group intends.=0A= >>>>=0A= >>>> But what do we intend? I will try to explain my personal view, and see= =0A= >>>> if that helps.=0A= >>>>=0A= >>>> In this regard, it is important to keep in mind that what we are=0A= >>>> defining is the data plane architecture. We are not attempting to=0A= >>>> define the architecture for the entire solution for service chaining.= =0A= >>>> That would encompass OSS/BSS, various control and policy functions,=0A= >>>> virtual machine and image management, and many other aspects.=0A= >>>>=0A= >>>> As a result there are many things which clearly need to exist in the= =0A= >>>> larger system, but which are dealt with above where we are functioning= ,=0A= >>>> and are not directly required by the work we are doing.=0A= >>>>=0A= >>>> In order to get to service chain vs service path, as I understand them= ,=0A= >>>> I need to first discuss load balancing. There are at least three=0A= >>>> different ways that load balancing can and will interact with service= =0A= >>>> chaining. There probably are more. The point of the archtiecture is to= =0A= >>>> permit all of these, but not to mandate that any particular kind be us= ed=0A= >>>> in any solution.=0A= >>>>=0A= >>>> 1) Load balancing as a service provided to the end user. This is a=0A= >>>> service function. It receives user packets, and modifies them (or mark= s=0A= >>>> them, or ...) so as to choose an end user service instance to receive= =0A= >>>> the users packet. This is an important service function to be able to= =0A= >>>> include in service chaining. It's behavior may affect requirements on= =0A= >>>> how service chaining is done. But it has very little impact on the=0A= >>>> archtiecture. From an architectural pe3rspective it is simply a servic= e=0A= >>>> function which may modify the underlying packet.=0A= >>>>=0A= >>>> 2) There is internal load balancing. That is, one can have what appear= s=0A= >>>> to the service chaining architecture as a single point of contact for = a=0A= >>>> specific service function, but is actually delivered by a collection o= f=0A= >>>> virtual or physical machines, possibly including one or several load= =0A= >>>> balancers (for example using VRRP-like techniques to share a MAC=0A= >>>> address.) mostly, this is invisible to the service chaining data plane= =0A= >>>> mechanisms. It is likely that it is visible to various control=0A= >>>> mechanisms, such as those responsible for scale-in, scale-out, and vm= =0A= >>>> instantiation. The architectural impact of permitting this is largely= =0A= >>>> that we need to be careful that our terminology does not lead readers = to=0A= >>>> think we are prohibiting it.=0A= >>>>=0A= >>>> 3) There can also be load balancing done by selecting packet paths for= =0A= >>>> the service chaining that direct traffic to different places. We would= =0A= >>>> not want to require that a given service function appear at only one= =0A= >>>> place in the network.=0A= >>>>=0A= >>>> It is of course the case that these may be combined. I tend to refer t= o=0A= >>>> the collection of entities that appear to service chaining as a single= =0A= >>>> point as a cluster. Not because cluster is a good term. But because I= =0A= >>>> do not have another one. Thus, the point of type 3 load balancing is t= o=0A= >>>> direct different subsets of traffic to different singular or clustered= =0A= >>>> service functions in different places in the network.=0A= >>>>=0A= >>>> Now with that said, what do I mean when I talk about service chain and= =0A= >>>> service path/ Service chain is a sequence of logical functions to be= =0A= >>>> applied to a subset of packets. It is equivalent of saying that some= =0A= >>>> subset of traffic is to get DPI, charging, content inspection, and=0A= >>>> firewall while a different subset is to go directly to the cache witho= ut=0A= >>>> visiting any other service functions.=0A= >>>>=0A= >>>> That is not enough information to direct the packets. A service path= =0A= >>>> is, in some fashion, a sequence of locations in the network. Those=0A= >>>> locations will be singular or clustered service function delivery=0A= >>>> locations. They may be addressed by IP address. They may be addressed= =0A= >>>> as ports on an SFF. There are many different ways that the locations= =0A= >>>> may be known to the service chaining infrastructure and the transport.= =0A= >>>>=0A= >>>> >From the point of view of the work of the SFC group, we need to be= =0A= >>>> able=0A= >>>> to talk about the high level abstraction, the service chain, which=0A= >>>> drives the forwarding. And we need to talk about the actual data path= =0A= >>>> packets will take in the network.=0A= >>>>=0A= >>>> Several of the comments have said "but the whole path may not be known= =0A= >>>> at the front." This architecture deals with that issue in two ways.=0A= >>>> First, as noted in item (2) on load balancers above, there can be=0A= >>>> decisions and behaviors which are invisible to the service chaining=0A= >>>> mechanisms (in much the same way that bridging within a LAN is largely= =0A= >>>> invisible to routing between LANs.) The other provision we make is tha= t=0A= >>>> reclassification can be done in mid-chain when necessary. That will=0A= >>>> direct packets to a new chain. Based on information available at the= =0A= >>>> re-classification point.=0A= >>>>=0A= >>>> I hope that this helps explain what we are after. If it does, and if= =0A= >>>> the intent is acceptable to the working group, we can figure out what= =0A= >>>> additional words are needed to convey this.=0A= >>>> If the working group disagree with the intent, then we will of course= =0A= >>>> adjust to match the working group agreements.=0A= >>>> If this is still unclear, I am not sure what to try next.=0A= >>>>=0A= >>>> Yours,=0A= >>>> Joel=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= >> _______________________________________________=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= From nobody Thu Jul 10 14:33: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 02E0C1B2A47 for ; Thu, 10 Jul 2014 14:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASSDQR8QjbSn for ; Thu, 10 Jul 2014 14:33:46 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D591B2A4F for ; Thu, 10 Jul 2014 14:33:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id ab60fb35.2b9900833940.4296335.00-2495.11907089.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:33:46 +0000 (UTC) X-MXL-Hash: 53bf06ba590c9f50-eccc04d324edd48cc7c8ac048119d97dea62c079 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 7b60fb35.0.4296305.00-2020.11907017.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:33:43 +0000 (UTC) X-MXL-Hash: 53bf06b709d53794-f3af29af8d87defaa3d67b38c83eadf0947f5987 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALXg46030267; Thu, 10 Jul 2014 17:33:42 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALXWW3030123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 17:33:38 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 21:33:20 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 17:33:20 -0400 From: "NAPIERALA, MARIA H" To: Ian Smith , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBAD//8BhIA== Date: Thu, 10 Jul 2014 21:33:19 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=btoz6Ug-bgiWnEkvYG0A:9] X-AnalysisOut: [ a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=chC_agHSu74A:10 a=o] X-AnalysisOut: [AXR_kdF8uMA:10 a=U8Ie8EnqySEA:10 a=hPjdaMEvmhQA:10 a=1FaWO] X-AnalysisOut: [KirvmGStZ1_:21 a=0hFSNzSNEdg6LuII:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/x24p7VFY0zJVYP__bfk5nN_glf4 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:33:49 -0000 Managing millions of 5-tuple flows in a single appliance is not the same as= managing (globally) millions of service paths which are essentially logica= l networks. And 16 million was an arbitrary number for just 100 service cha= ins. 100 service chains is very little. Image this number be two or more or= ders of magnitude higher... > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith > Sent: Thursday, July 10, 2014 5:15 PM > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca; > sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Actually, I think I am disagreeing. >=20 > If the possibility of medium-scale deployments (and that is what 16 milli= on > flows is in my world) of service chains is preconceived as an absurd idea= , > then the architecture burdened with that preconception. >=20 > There has to be some point of aim, some degree of aspiration to scale tha= t > is appropriate for the lifespan of the architecture - you don't have to k= now > what it is, but by saying that an arbitrary number is "too far", you're > creating - even if it isn't intentional - a limit that influences decisio= ns that > have lasting impacts regarding scale-out, failure mitigation, elasticity, > address space... all kinds of things. That is a problem I'm not particul= arly > eager to deal with. >=20 >=20 >=20 >=20 > ________________________________________ > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > Sent: Thursday, July 10, 2014 5:04 PM > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Ian, I don't think you disagree with me at all in this regard. > I am not requesting the the architecture or the solution prohibit > deployments in the specific fashion. > I am objecting to Huang's reading of my note as saying that such > deployments are required they by the archtiecture. >=20 > As I have said repeatedly, I am not trying to prohibit such things. > Whether they are a good idea or not depends upon many factors outside of > the scope of the WG. I happen to think that they are usually a bad idea. >=20 > But the archtiecture si carefully avoiding attempting to know what is > and is not eployable. >=20 > Yours, > Joel >=20 > On 7/10/14, 5:01 PM, Ian Smith wrote: > > I disagree. > > > > We routinely have stateful devices that manage tens of millions of > concurrent flows in both access network and data center environments > today. You can't seriously believe that in the > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to > have small numbers of service chains with equally small numbers of active > service paths? > > > > Your sounds too much like "no one will ever need more than 64K" for > comfort. > > > > > > ________________________________________ > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > [jmh@joelhalpern.com] > > Sent: Thursday, July 10, 2014 4:46 PM > > To: huang@sce.carleton.ca; sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > No, it will mean that if someone tries to deploy the archtieture > > particularly badly, they will exceed the limits of their devices. > > The architecture does not require such absurd use of service paths. > > Since I can not figure out how to write architectural words to prohibit > > it, the architecture does permit such abuse. > > > > Please do not read my saying that the archtiecture permits something as > > saying it is either deisred or required by the work. It isn't. > > > > Yours, > > Joel > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> If you need to support 100 service chains, it will mean 16,000,000 > >> paths. That is larger than the routing table of a core router. > >> > >> Chang > >> > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>> The architecture allows a range of deployments, from 1 service path t= o > >>> 160000 service paths. I would hope that operators are prepared for > >>> the complexities if they choose to avoid any use of local load > >>> balancing and in stead provision 160,000 service paths. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>> Paul, > >>>> > >>>> How many path identifiers there will be for a 4 hop service chain wi= th > >>>> 20 instances at each hop? > >>>> > >>>> Maria > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn > >>>> (paulq) > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > >>>> *To:* Lucy yong > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; > sfc@ietf.org; > >>>> mikebianc@aol.com > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Lucy, > >>>> > >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd m= ake > >>>> the minor change: the path identifier can be used to derive the > needed > >>>> forwarding and associated transport. > >>>> > >>>> It is _not_ the transport, but rather is used to simply identify the > >>>> service path (or graph) that packets must traverse. By having a pat= h > >>>> identifier, the exact indirection that people seem to be asking for = on > >>>> this thread can be simply be implemented. The path identifier > provides > >>>> nothing more than a lookup, that lookup can result in a one or more > >>>> (equal or weighted) transport next hop(s). > >>>> > >>>> Paul > >>>> > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote: > >>>> > >>>> > >>>> > >>>> Agree. The arch. doc should not mandate only use of the service path > >>>> identifier to drive the forwarding actions. > >>>> > >>>> Lucy > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>> Of*mohamed.boucadair@orange.com > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > >>>> *To:*mikebianc@aol.com > ;jmh@joelhalpern.com > >>>> ;sfc@ietf.org > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Re-, > >>>> > >>>> The merged draft calls out explicitly a service path identifier. I > >>>> object to use that identifier to derive forwarding actions. > >>>> > >>>> Requiring a SFC system to have the full knowledge of every available > SFC > >>>> forwarding paths within an SFC-enabled domain is not > required/justified > >>>> nor possible in various deployment contexts. > >>>> > >>>> SFC forwarding actions should rely on the piece of information that > will > >>>> be present in all deployments: that is the one required to structure= a > >>>> service chain. How that information is used to infer forwarding acti= ons > >>>> is a solution-oriented discussion. > >>>> > >>>> Cheers, > >>>> > >>>> Med > >>>> > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > de*mikebianc@aol.com > >>>> > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 > >>>> *=C0 :*jmh@joelhalpern.com > ;sfc@ietf.org > >>>> > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Is anyone still questioning the difference between SF Chain and SF > Path? > >>>> Other than clarifying the definition so that it's clear to those = not > >>>> familiar with the draft, it seems that everyone agrees on these term= s. > >>>> > >>>> To me, the one point that is still unclear is whether it is the inte= nt > >>>> of this draft to ultimately specify what the ID of the SFC Header > should > >>>> reference (the chain or the path), or if this draft simply intends t= o > >>>> leave that ambiguous, allowing other drafts to dictate the > mechanisms > >>>> for forwarding based on chain or path and the choice of chain or pat= h > to > >>>> be negotiated in the control-plane. > >>>> > >>>> If the latter (ambiguous), then the draft would have require that bo= th > >>>> SFP and SFC be supported (or make one required and the other > optional) > >>>> to avoid some vendors only supporting SFP and others only > supporting > >>>> SFC. > >>>> > >>>> --------------------------------------------------------------------= ---- > >>>> > >>>> *From:*jmh@joelhalpern.com >>>> > > >>>> *To:*sfc@ietf.org> > >>>> *Sent:*Tuesday, July 8, 2014 > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> I have been trying to figure out how to clearly answer a number of > >>>> comments that have been made about the proposed merged > archtiecture > >>>> draft. Assuming we can get working group agreement on the intent, > we > >>>> will work to improve the wording so that readers who have not > >>>> participated in the WG discussion will understnd it the way the > working > >>>> group intends. > >>>> > >>>> But what do we intend? I will try to explain my personal view, and s= ee > >>>> if that helps. > >>>> > >>>> In this regard, it is important to keep in mind that what we are > >>>> defining is the data plane architecture. We are not attempting to > >>>> define the architecture for the entire solution for service chaining= . > >>>> That would encompass OSS/BSS, various control and policy functions, > >>>> virtual machine and image management, and many other aspects. > >>>> > >>>> As a result there are many things which clearly need to exist in the > >>>> larger system, but which are dealt with above where we are > functioning, > >>>> and are not directly required by the work we are doing. > >>>> > >>>> In order to get to service chain vs service path, as I understand th= em, > >>>> I need to first discuss load balancing. There are at least three > >>>> different ways that load balancing can and will interact with servic= e > >>>> chaining. There probably are more. The point of the archtiecture is = to > >>>> permit all of these, but not to mandate that any particular kind be > used > >>>> in any solution. > >>>> > >>>> 1) Load balancing as a service provided to the end user. This is a > >>>> service function. It receives user packets, and modifies them (or ma= rks > >>>> them, or ...) so as to choose an end user service instance to receiv= e > >>>> the users packet. This is an important service function to be able t= o > >>>> include in service chaining. It's behavior may affect requirements o= n > >>>> how service chaining is done. But it has very little impact on the > >>>> archtiecture. From an architectural pe3rspective it is simply a serv= ice > >>>> function which may modify the underlying packet. > >>>> > >>>> 2) There is internal load balancing. That is, one can have what appe= ars > >>>> to the service chaining architecture as a single point of contact fo= r a > >>>> specific service function, but is actually delivered by a collection= of > >>>> virtual or physical machines, possibly including one or several load > >>>> balancers (for example using VRRP-like techniques to share a MAC > >>>> address.) mostly, this is invisible to the service chaining data pla= ne > >>>> mechanisms. It is likely that it is visible to various control > >>>> mechanisms, such as those responsible for scale-in, scale-out, and v= m > >>>> instantiation. The architectural impact of permitting this is largel= y > >>>> that we need to be careful that our terminology does not lead reader= s > to > >>>> think we are prohibiting it. > >>>> > >>>> 3) There can also be load balancing done by selecting packet paths f= or > >>>> the service chaining that direct traffic to different places. We wou= ld > >>>> not want to require that a given service function appear at only one > >>>> place in the network. > >>>> > >>>> It is of course the case that these may be combined. I tend to refer= to > >>>> the collection of entities that appear to service chaining as a sing= le > >>>> point as a cluster. Not because cluster is a good term. But because = I > >>>> do not have another one. Thus, the point of type 3 load balancing is > to > >>>> direct different subsets of traffic to different singular or cluster= ed > >>>> service functions in different places in the network. > >>>> > >>>> Now with that said, what do I mean when I talk about service chain > and > >>>> service path/ Service chain is a sequence of logical functions to be > >>>> applied to a subset of packets. It is equivalent of saying that some > >>>> subset of traffic is to get DPI, charging, content inspection, and > >>>> firewall while a different subset is to go directly to the cache wit= hout > >>>> visiting any other service functions. > >>>> > >>>> That is not enough information to direct the packets. A service path > >>>> is, in some fashion, a sequence of locations in the network. Those > >>>> locations will be singular or clustered service function delivery > >>>> locations. They may be addressed by IP address. They may be > addressed > >>>> as ports on an SFF. There are many different ways that the locations > >>>> may be known to the service chaining infrastructure and the > transport. > >>>> > >>>> >From the point of view of the work of the SFC group, we need to b= e > >>>> able > >>>> to talk about the high level abstraction, the service chain, which > >>>> drives the forwarding. And we need to talk about the actual data pat= h > >>>> packets will take in the network. > >>>> > >>>> Several of the comments have said "but the whole path may not be > known > >>>> at the front." This architecture deals with that issue in two ways. > >>>> First, as noted in item (2) on load balancers above, there can be > >>>> decisions and behaviors which are invisible to the service chaining > >>>> mechanisms (in much the same way that bridging within a LAN is > largely > >>>> invisible to routing between LANs.) The other provision we make is > that > >>>> reclassification can be done in mid-chain when necessary. That will > >>>> direct packets to a new chain. Based on information available at the > >>>> re-classification point. > >>>> > >>>> I hope that this helps explain what we are after. If it does, and if > >>>> the intent is acceptable to the working group, we can figure out wha= t > >>>> additional words are needed to convey this. > >>>> If the working group disagree with the intent, then we will of cours= e > >>>> adjust to match the working group agreements. > >>>> If this is still unclear, I am not sure what to try next. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Thu Jul 10 14:35: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 AF9DB1B2A4F for ; Thu, 10 Jul 2014 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LYR-LIIy2C9 for ; Thu, 10 Jul 2014 14:35:36 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882291B2A47 for ; Thu, 10 Jul 2014 14:35:35 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 7270fb35.2abff583b940.6350654.00-2435.17577146.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:35:35 +0000 (UTC) X-MXL-Hash: 53bf07273c9ace1a-67516015a2832e42e954ad831c9012650275376a Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 5270fb35.0.6350636.00-2249.17577069.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:35:34 +0000 (UTC) X-MXL-Hash: 53bf07266bf1d479-6f75f907ddb28387c9731615498002f464eedd1a Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALZWJQ032065; Thu, 10 Jul 2014 17:35:33 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALZMlG031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 17:35:27 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 21:35:06 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 17:35:06 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEYhAP//vVrwgABRo4D//8TEcA== Date: Thu, 10 Jul 2014 21:35:06 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A806@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A68B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53F1048C-C06A-45C6-8727-2FA69AAB9C14@cisco.com> In-Reply-To: <53F1048C-C06A-45C6-8727-2FA69AAB9C14@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A806MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=AUd_NHdVA] X-AnalysisOut: [AAA:8 a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=VCJxY1cV_xXKoCqmSlwA:9 ] X-AnalysisOut: [a=wPNLvfGTeEIA:10 a=JfD0Fch1gWkA:10 a=chC_agHSu74A:10 a=oA] X-AnalysisOut: [XR_kdF8uMA:10 a=lZB815dzVvQA:10 a=U8Ie8EnqySEA:10 a=Hz7IrD] X-AnalysisOut: [YlS0cA:10 a=hPjdaMEvmhQA:10 a=ON57wHizFU8JFbKf:21 a=Oaz0JT] X-AnalysisOut: [eKgriM5eIq:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10 a=c-IBglrmfIMmpVXm:21 a=wTK_4N8lrncN0SD2:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/I_CQFgStAKUq2dsONO3FTQbB_vk Cc: "sfc@ietf.org" , Lucy yong , "Paul Quinn \(paulq\)" , "jmh@joelhalpern.com" , "mohamed.boucadair@orange.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:35:41 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A806MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good! From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, July 10, 2014 5:07 PM To: NAPIERALA, MARIA H Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@o= range.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Yes. Sent from my iPhone On Jul 10, 2014, at 4:18 PM, "NAPIERALA, MARIA H" > wrote: Does it mean one path identifier? Maria From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, July 10, 2014 4:14 PM To: NAPIERALA, MARIA H Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@orange.com;= sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I'd make th= e minor change: the path identifier can be used to derive the needed forwar= ding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A806MISOUT7MSGUSRCF_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good!

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Thursday, July 10, 2014 5:07 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.bouc= adair@orange.com; sfc@ietf.org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

Yes.

Sent from my iPhone


On Jul 10, 2014, at 4:18 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Does it mean one path ide= ntifier?

 <= /p>

Maria

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisc= o.com]
Sent: Thursday, July 10, 2014 4:14 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; jmh@joelhalpern.com; mohamed.boucadair@orange.co= m; sfc@ietf.org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= o:p>

 

1 assuming load is distributed among the 20 instance= s at each service hop.

Sent from my iPhone

Paul,

 <= /p>

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

 <= /p>

Maria

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= o:p>

 

Lucy,

 

Overall I concur, as you say: a path ID drives the f= orwarding.  I’d make the minor change: the path identifier can b= e used to derive the needed forwarding and associated transport.=

 

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse.  = By having a path identifier, the exact indirection that people seem to be a= sking for on this thread can be simply be implemented.  The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).  

 

Paul

 

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:





Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

 <= /p>

Lucy

 <= /p>

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers

 

Re-,

 

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

 

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

 

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

 

Cheers,

Med

 

 

Is anyone still questioning the differenc= e between SF Chain and SF Path?  Other than clarifying the definition = so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

 

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane. &nb= sp;

 

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

 

 

 

From: jmh@joelhalpern.= com<jmh@joelhalpern.com>
To: sfc@ietf.org&= lt;sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

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

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4A806MISOUT7MSGUSRCF_-- From nobody Thu Jul 10 14:36: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 848771B2A4F for ; Thu, 10 Jul 2014 14:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 mcgR6lx1JPaO for ; Thu, 10 Jul 2014 14:36:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0458C1B2A53 for ; Thu, 10 Jul 2014 14:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40208; q=dns/txt; s=iport; t=1405028185; x=1406237785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E+0AHBrPskRHA+WDvRXPIk2SrnZHTxAjDrq5jhTm/dA=; b=S9VwVuFnVGuDN0RLjeo9eoBec92506YN8EV866ycxsPzbmfezirJh7iu 77fN1Tntx+74tG8SlEgav/FxAC6tFtsRphU8Z9qK9Hzy6DFVRSfmHlWL1 fKQjDjNyJYqJDZcQ4FBvw9hwTfr6HujuGiH/gJRhnkuex/n6mhoMV1AeL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFANIGv1OtJA2I/2dsb2JhbABPCoJHR1JarmuReAEJh0IBgQ4WdYQDAQEBBAEBAWIJCxACAQgRAQMBASEBBgcnCxQDBggCBA4FG4gTAxENxi4TBI0ZgU9SBgQGAYMtgRYFliBGhBqLY4gyg0OCMA X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208,217";a="339186938" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jul 2014 21:36:24 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6ALaNvS013077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 21:36:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 16:36:23 -0500 From: "Paul Quinn (paulq)" To: "NAPIERALA, MARIA H" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAABkpgA== Date: Thu, 10 Jul 2014 21:36:23 +0000 Message-ID: <755B3825-7925-4917-99E0-DF9BE9FA3E2C@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: multipart/alternative; boundary="_000_755B38257925491799E0DF9BE9FA3E2Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qAXrh4zGNOGs4Q3iCk851IKFeaM Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:36:28 -0000 --_000_755B38257925491799E0DF9BE9FA3E2Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Maria, Assuming that for each SF, all instance are to be viewed as equal, then 1 S= FC encap service path identifier. At each SFF, a local decision will be ma= de about how to distribute the load to the attached SFs. Paul On Jul 10, 2014, at 4:06 PM, NAPIERALA, MARIA H > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make = the minor change: the path identifier can be used to derive the needed forw= arding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier,= the exact indirection that people seem to be asking for on this thread can= be simply be implemented. The path identifier provides nothing more than = a lookup, that lookup can result in a one or more (equal or weighted) trans= port next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? O= ther than clarifying the definition so that it's clear to those not familia= r with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_755B38257925491799E0DF9BE9FA3E2Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Maria,

Assuming that for each SF, all instance are to be viewed as equal, the= n 1 SFC encap service path identifier.  At each SFF, a local decision = will be made about how to distribute the load to the attached SFs.

Paul

On Jul 10, 2014, at 4:06 PM, NAPIERALA, MARIA H <mn1921@att.com> wrote:

Paul,
 
How many path identifiers there will be for a 4 hop servic= e chain with 20 instances at each hop?
 
Maria
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Paul Quinn= (paulq)
Sent: Thursday, Ju= ly 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; mikebianc@aol.com=
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers
 
Lucy,
 
Overall I concur, as you say: a path ID drives the forwarding.  I=92d = make the minor change: the path identifier can be used to derive the needed= forwarding and associated transport.
 
It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse.  By having a path identi= fier, the exact indirection that people seem to be asking for on this threa= d can be simply be implemented.  The path identifier provides nothing more than a lookup, that lookup can resul= t in a one or more (equal or weighted) transport next hop(s).  
 
Paul
 
On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@hua= wei.com> wrote:


Agree. The arch. doc should not mandate only use of the se= rvice path identifier to drive the forwarding actions.
 
Lucy
 
From:<= /span> sfc [mailto:sfc-bounces@ietf.= org] On Beh= alf Of mohamed.boucadair@orange.com
Sent: Thursday, Ju= ly 10, 2014 2:06 AM
To: mikebianc@aol.com; jmh@joelhalpern.com; sfc@ietf.org
Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers
 
Re-,
 
The merged draft calls out explicitly a service path identifier.= I object to use that identifier to derive forwarding actions.<= /o:p>
 
Requiring a SFC system to have the full knowledge of every avail= able SFC forwarding paths within an SFC-enabled domain is not required/just= ified nor possible in various deployment contexts.
 
SFC forwarding actions should rely on the piece of information t= hat will be present in all deployments: that is the one required to structu= re a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
 
Cheers,
Med
 
De : <= /span>sfc [mailto:sfc-bounces@ietf.= org] De la = part de mikebianc@aol.com
Envoy=E9 : me= rcredi 9 juillet 2014 22:03
=C0 : jmh@joelhalpern.com; sfc@ietf.org
Objet : Re: [= sfc] Service Chains, Paths, and Load Balancers
 
Is anyone = still questioning the difference between SF Chain and SF Path?  Other = than clarifying the definition so that it's clear to those not familiar wit= h the draft, it seems that everyone agrees on these terms.
 
To me, the= one point that is still unclear is whether it is the intent of this draft = to ultimately specify what the ID of the SFC Header should reference (the c= hain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate t= he mechanisms for forwarding based on chain or path and the choice of chain= or path to be negotiated in the control-plane.  
 
If the lat= ter (ambiguous), then the draft would have require that both SFP and SFC be= supported (or make one required and the other optional) to avoid some vend= ors only supporting SFP and others only supporting SFC.
 
 

 

From: jmh@joelhalpern.c= om<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, Jul= y 8, 2014
Subject: [sfc] Ser= vice Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft. Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend? I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture. We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing. There are at least three 
different ways that load balancing can and will interact with service 
chaining. There probably are more. The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user. This is a 
service function. It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet. This is an important service function to be able to 
include in service chaining. It's behavior may affect requirements on 
how service chaining is done. But it has very little impact on the 
archtiecture. From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.) mostly, this is invisible to the service chaining data plane 
mechanisms. It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation. The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places. We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined. I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster. Not because cluster is a good term. But because I 
do not have another one. Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/ Service chain is a sequence of logical functions to be 
applied to a subset of packets. It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets. A service path 
is, in some fashion, a sequence of locations in the network. Those 
locations will be singular or clustered service function delivery 
locations. They may be addressed by IP address. They may be addressed 
as ports on an SFF. There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=  
to talk about the high level abstraction, the service chain, which 
drives the forwarding. And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known=  
at the front." This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.) The other provision we make is that 
reclassification can be done in mid-chain when necessary. That will 
direct packets to a new chain. Based on information available at the 
re-classification point.

I hope that this helps explain what we are after. If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

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

--_000_755B38257925491799E0DF9BE9FA3E2Cciscocom_-- From nobody Thu Jul 10 14:38: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 357271B2A53 for ; Thu, 10 Jul 2014 14:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 sBiDhRdYRuXt for ; Thu, 10 Jul 2014 14:37:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27171B2A4F for ; Thu, 10 Jul 2014 14:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405028275; x=1436564275; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CqkqNaeA7VhsWlu5cGaXUMPowrhkFZnGZJ5PlDtl8Bw=; b=Qvg0Lu/dapKDP2tDsUHShWggUYy/hvabC17nfxR/PzYyIvVqV3P2HEtJ Voj7Ibmmrir9f9bdSdow8nFe7zhbPbFTfQF4zhI996QUFMkTpXSGHEk/N 4s9f5z91UQfDpqGJd+m441ib536qpC+39cvHqHEPdjgjYb4uTV6kYDPIS g=; X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208";a="121423671" X-IPAS-Result: AqgEABQHv1PAqArr/2dsb2JhbABPCoNgWq5rkVggCodCAYEkdYQDAQEBAQMBAQFiCQIVBAIBCBEBAwEBAQodBycLFAMGCAIEARIIE4gTAx7GLhMEjRmBTwUmOAaDJ4EWBYoejAJGj32LdYFvQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 21:37:54 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:37:53 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH0MgP//ixO3 Date: Thu, 10 Jul 2014 21:37:53 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] 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/R6wUMH8Pkf-AmPNsRUh31c8HiTc Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:37:58 -0000 A service path isn't a logical network; it is - quite literally - a path _= though_ a network. =0A= =0A= =0A= =0A= ________________________________________=0A= From: NAPIERALA, MARIA H [mn1921@att.com]=0A= Sent: Thursday, July 10, 2014 5:33 PM=0A= To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;= sfc@ietf.org=0A= Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= Managing millions of 5-tuple flows in a single appliance is not the same as= managing (globally) millions of service paths which are essentially logica= l networks. And 16 million was an arbitrary number for just 100 service cha= ins. 100 service chains is very little. Image this number be two or more or= ders of magnitude higher...=0A= =0A= > -----Original Message-----=0A= > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=0A= > Sent: Thursday, July 10, 2014 5:15 PM=0A= > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;=0A= > sfc@ietf.org=0A= > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > Actually, I think I am disagreeing.=0A= >=0A= > If the possibility of medium-scale deployments (and that is what 16 milli= on=0A= > flows is in my world) of service chains is preconceived as an absurd idea= ,=0A= > then the architecture burdened with that preconception.=0A= >=0A= > There has to be some point of aim, some degree of aspiration to scale tha= t=0A= > is appropriate for the lifespan of the architecture - you don't have to k= now=0A= > what it is, but by saying that an arbitrary number is "too far", you're= =0A= > creating - even if it isn't intentional - a limit that influences decisio= ns that=0A= > have lasting impacts regarding scale-out, failure mitigation, elasticity,= =0A= > address space... all kinds of things. That is a problem I'm not particul= arly=0A= > eager to deal with.=0A= >=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > Sent: Thursday, July 10, 2014 5:04 PM=0A= > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org=0A= > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > Ian, I don't think you disagree with me at all in this regard.=0A= > I am not requesting the the architecture or the solution prohibit=0A= > deployments in the specific fashion.=0A= > I am objecting to Huang's reading of my note as saying that such=0A= > deployments are required they by the archtiecture.=0A= >=0A= > As I have said repeatedly, I am not trying to prohibit such things.=0A= > Whether they are a good idea or not depends upon many factors outside of= =0A= > the scope of the WG. I happen to think that they are usually a bad idea.= =0A= >=0A= > But the archtiecture si carefully avoiding attempting to know what is=0A= > and is not eployable.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > > I disagree.=0A= > >=0A= > > We routinely have stateful devices that manage tens of millions of=0A= > concurrent flows in both access network and data center environments=0A= > today. You can't seriously believe that in the=0A= > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to=0A= > have small numbers of service chains with equally small numbers of active= =0A= > service paths?=0A= > >=0A= > > Your sounds too much like "no one will ever need more than 64K" for=0A= > comfort.=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > [jmh@joelhalpern.com]=0A= > > Sent: Thursday, July 10, 2014 4:46 PM=0A= > > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > No, it will mean that if someone tries to deploy the archtieture=0A= > > particularly badly, they will exceed the limits of their devices.=0A= > > The architecture does not require such absurd use of service paths.=0A= > > Since I can not figure out how to write architectural words to prohibit= =0A= > > it, the architecture does permit such abuse.=0A= > >=0A= > > Please do not read my saying that the archtiecture permits something as= =0A= > > saying it is either deisred or required by the work. It isn't.=0A= > >=0A= > > Yours,=0A= > > Joel=0A= > >=0A= > > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > >> If you need to support 100 service chains, it will mean 16,000,000=0A= > >> paths. That is larger than the routing table of a core router.=0A= > >>=0A= > >> Chang=0A= > >>=0A= > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= > >>> The architecture allows a range of deployments, from 1 service path t= o=0A= > >>> 160000 service paths. I would hope that operators are prepared for= =0A= > >>> the complexities if they choose to avoid any use of local load=0A= > >>> balancing and in stead provision 160,000 service paths.=0A= > >>>=0A= > >>> Yours,=0A= > >>> Joel=0A= > >>>=0A= > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= > >>>> Paul,=0A= > >>>>=0A= > >>>> How many path identifiers there will be for a 4 hop service chain wi= th=0A= > >>>> 20 instances at each hop?=0A= > >>>>=0A= > >>>> Maria=0A= > >>>>=0A= > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn= =0A= > >>>> (paulq)=0A= > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= > >>>> *To:* Lucy yong=0A= > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com;=0A= > sfc@ietf.org;=0A= > >>>> mikebianc@aol.com=0A= > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >>>>=0A= > >>>> Lucy,=0A= > >>>>=0A= > >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd m= ake=0A= > >>>> the minor change: the path identifier can be used to derive the=0A= > needed=0A= > >>>> forwarding and associated transport.=0A= > >>>>=0A= > >>>> It is _not_ the transport, but rather is used to simply identify the= =0A= > >>>> service path (or graph) that packets must traverse. By having a pat= h=0A= > >>>> identifier, the exact indirection that people seem to be asking for = on=0A= > >>>> this thread can be simply be implemented. The path identifier=0A= > provides=0A= > >>>> nothing more than a lookup, that lookup can result in a one or more= =0A= > >>>> (equal or weighted) transport next hop(s).=0A= > >>>>=0A= > >>>> Paul=0A= > >>>>=0A= > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote:=0A= > >>>>=0A= > >>>>=0A= > >>>>=0A= > >>>> Agree. The arch. doc should not mandate only use of the service path= =0A= > >>>> identifier to drive the forwarding actions.=0A= > >>>>=0A= > >>>> Lucy=0A= > >>>>=0A= > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= > >>>> Of*mohamed.boucadair@orange.com=0A= > =0A= > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= > >>>> *To:*mikebianc@aol.com=0A= > ;jmh@joelhalpern.com=0A= > >>>> ;sfc@ietf.org =0A= > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >>>>=0A= > >>>> Re-,=0A= > >>>>=0A= > >>>> The merged draft calls out explicitly a service path identifier. I= =0A= > >>>> object to use that identifier to derive forwarding actions.=0A= > >>>>=0A= > >>>> Requiring a SFC system to have the full knowledge of every available= =0A= > SFC=0A= > >>>> forwarding paths within an SFC-enabled domain is not=0A= > required/justified=0A= > >>>> nor possible in various deployment contexts.=0A= > >>>>=0A= > >>>> SFC forwarding actions should rely on the piece of information that= =0A= > will=0A= > >>>> be present in all deployments: that is the one required to structure= a=0A= > >>>> service chain. How that information is used to infer forwarding acti= ons=0A= > >>>> is a solution-oriented discussion.=0A= > >>>>=0A= > >>>> Cheers,=0A= > >>>>=0A= > >>>> Med=0A= > >>>>=0A= > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= > de*mikebianc@aol.com=0A= > >>>> =0A= > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= > >>>> *=C0 :*jmh@joelhalpern.com=0A= > ;sfc@ietf.org=0A= > >>>> =0A= > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >>>>=0A= > >>>> Is anyone still questioning the difference between SF Chain and SF= =0A= > Path?=0A= > >>>> Other than clarifying the definition so that it's clear to those = not=0A= > >>>> familiar with the draft, it seems that everyone agrees on these term= s.=0A= > >>>>=0A= > >>>> To me, the one point that is still unclear is whether it is the inte= nt=0A= > >>>> of this draft to ultimately specify what the ID of the SFC Header=0A= > should=0A= > >>>> reference (the chain or the path), or if this draft simply intends t= o=0A= > >>>> leave that ambiguous, allowing other drafts to dictate the=0A= > mechanisms=0A= > >>>> for forwarding based on chain or path and the choice of chain or pat= h=0A= > to=0A= > >>>> be negotiated in the control-plane.=0A= > >>>>=0A= > >>>> If the latter (ambiguous), then the draft would have require that bo= th=0A= > >>>> SFP and SFC be supported (or make one required and the other=0A= > optional)=0A= > >>>> to avoid some vendors only supporting SFP and others only=0A= > supporting=0A= > >>>> SFC.=0A= > >>>>=0A= > >>>> --------------------------------------------------------------------= ----=0A= > >>>>=0A= > >>>> *From:*jmh@joelhalpern.com >>>> >=0A= > >>>> *To:*sfc@ietf.org>= =0A= > >>>> *Sent:*Tuesday, July 8, 2014=0A= > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= > >>>>=0A= > >>>> I have been trying to figure out how to clearly answer a number of= =0A= > >>>> comments that have been made about the proposed merged=0A= > archtiecture=0A= > >>>> draft. Assuming we can get working group agreement on the intent,=0A= > we=0A= > >>>> will work to improve the wording so that readers who have not=0A= > >>>> participated in the WG discussion will understnd it the way the=0A= > working=0A= > >>>> group intends.=0A= > >>>>=0A= > >>>> But what do we intend? I will try to explain my personal view, and s= ee=0A= > >>>> if that helps.=0A= > >>>>=0A= > >>>> In this regard, it is important to keep in mind that what we are=0A= > >>>> defining is the data plane architecture. We are not attempting to=0A= > >>>> define the architecture for the entire solution for service chaining= .=0A= > >>>> That would encompass OSS/BSS, various control and policy functions,= =0A= > >>>> virtual machine and image management, and many other aspects.=0A= > >>>>=0A= > >>>> As a result there are many things which clearly need to exist in the= =0A= > >>>> larger system, but which are dealt with above where we are=0A= > functioning,=0A= > >>>> and are not directly required by the work we are doing.=0A= > >>>>=0A= > >>>> In order to get to service chain vs service path, as I understand th= em,=0A= > >>>> I need to first discuss load balancing. There are at least three=0A= > >>>> different ways that load balancing can and will interact with servic= e=0A= > >>>> chaining. There probably are more. The point of the archtiecture is = to=0A= > >>>> permit all of these, but not to mandate that any particular kind be= =0A= > used=0A= > >>>> in any solution.=0A= > >>>>=0A= > >>>> 1) Load balancing as a service provided to the end user. This is a= =0A= > >>>> service function. It receives user packets, and modifies them (or ma= rks=0A= > >>>> them, or ...) so as to choose an end user service instance to receiv= e=0A= > >>>> the users packet. This is an important service function to be able t= o=0A= > >>>> include in service chaining. It's behavior may affect requirements o= n=0A= > >>>> how service chaining is done. But it has very little impact on the= =0A= > >>>> archtiecture. From an architectural pe3rspective it is simply a serv= ice=0A= > >>>> function which may modify the underlying packet.=0A= > >>>>=0A= > >>>> 2) There is internal load balancing. That is, one can have what appe= ars=0A= > >>>> to the service chaining architecture as a single point of contact fo= r a=0A= > >>>> specific service function, but is actually delivered by a collection= of=0A= > >>>> virtual or physical machines, possibly including one or several load= =0A= > >>>> balancers (for example using VRRP-like techniques to share a MAC=0A= > >>>> address.) mostly, this is invisible to the service chaining data pla= ne=0A= > >>>> mechanisms. It is likely that it is visible to various control=0A= > >>>> mechanisms, such as those responsible for scale-in, scale-out, and v= m=0A= > >>>> instantiation. The architectural impact of permitting this is largel= y=0A= > >>>> that we need to be careful that our terminology does not lead reader= s=0A= > to=0A= > >>>> think we are prohibiting it.=0A= > >>>>=0A= > >>>> 3) There can also be load balancing done by selecting packet paths f= or=0A= > >>>> the service chaining that direct traffic to different places. We wou= ld=0A= > >>>> not want to require that a given service function appear at only one= =0A= > >>>> place in the network.=0A= > >>>>=0A= > >>>> It is of course the case that these may be combined. I tend to refer= to=0A= > >>>> the collection of entities that appear to service chaining as a sing= le=0A= > >>>> point as a cluster. Not because cluster is a good term. But because = I=0A= > >>>> do not have another one. Thus, the point of type 3 load balancing is= =0A= > to=0A= > >>>> direct different subsets of traffic to different singular or cluster= ed=0A= > >>>> service functions in different places in the network.=0A= > >>>>=0A= > >>>> Now with that said, what do I mean when I talk about service chain= =0A= > and=0A= > >>>> service path/ Service chain is a sequence of logical functions to be= =0A= > >>>> applied to a subset of packets. It is equivalent of saying that some= =0A= > >>>> subset of traffic is to get DPI, charging, content inspection, and= =0A= > >>>> firewall while a different subset is to go directly to the cache wit= hout=0A= > >>>> visiting any other service functions.=0A= > >>>>=0A= > >>>> That is not enough information to direct the packets. A service path= =0A= > >>>> is, in some fashion, a sequence of locations in the network. Those= =0A= > >>>> locations will be singular or clustered service function delivery=0A= > >>>> locations. They may be addressed by IP address. They may be=0A= > addressed=0A= > >>>> as ports on an SFF. There are many different ways that the locations= =0A= > >>>> may be known to the service chaining infrastructure and the=0A= > transport.=0A= > >>>>=0A= > >>>> >From the point of view of the work of the SFC group, we need to b= e=0A= > >>>> able=0A= > >>>> to talk about the high level abstraction, the service chain, which= =0A= > >>>> drives the forwarding. And we need to talk about the actual data pat= h=0A= > >>>> packets will take in the network.=0A= > >>>>=0A= > >>>> Several of the comments have said "but the whole path may not be=0A= > known=0A= > >>>> at the front." This architecture deals with that issue in two ways.= =0A= > >>>> First, as noted in item (2) on load balancers above, there can be=0A= > >>>> decisions and behaviors which are invisible to the service chaining= =0A= > >>>> mechanisms (in much the same way that bridging within a LAN is=0A= > largely=0A= > >>>> invisible to routing between LANs.) The other provision we make is= =0A= > that=0A= > >>>> reclassification can be done in mid-chain when necessary. That will= =0A= > >>>> direct packets to a new chain. Based on information available at the= =0A= > >>>> re-classification point.=0A= > >>>>=0A= > >>>> I hope that this helps explain what we are after. If it does, and if= =0A= > >>>> the intent is acceptable to the working group, we can figure out wha= t=0A= > >>>> additional words are needed to convey this.=0A= > >>>> If the working group disagree with the intent, then we will of cours= e=0A= > >>>> adjust to match the working group agreements.=0A= > >>>> If this is still unclear, I am not sure what to try next.=0A= > >>>>=0A= > >>>> Yours,=0A= > >>>> Joel=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= > >> _______________________________________________=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= > _______________________________________________=0A= > sfc mailing list=0A= > sfc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Jul 10 14:43: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 03C701B2A6C for ; Thu, 10 Jul 2014 14:43:41 -0700 (PDT) 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_29=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 AwQPXQF81sAe for ; Thu, 10 Jul 2014 14:43:39 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0506A1B2A73 for ; Thu, 10 Jul 2014 14:43:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 953D0861543; Thu, 10 Jul 2014 14:43:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id E685C861545; Thu, 10 Jul 2014 14:43:36 -0700 (PDT) Message-ID: <53BF0908.7030109@joelhalpern.com> Date: Thu, 10 Jul 2014 17:43:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith , "huang@sce.carleton.ca" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8X-Jb807qOqwcZDLXXZxX8mXr0c Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:43:41 -0000 First, sorry, I should not have put words in your mouth. You said you disagreed. My point is that the archtiecture takes no stance on whether the right level of multiplicity at the Service path level for handling multiple instantiations is one path, O(100) paths, or O(1,000,000) paths. We each have biasis about what we think is reasonable for supporting each service combination that the operator is offering. Maria has clearly said that she wants to deploy with O(1). Fine, the archtiecture allows that. I expect that the solution will as well. You have said that you consider a much larger number of service paths for the same service chain to be reasonable. The architecture permits that. While I have biases in this regard, I hope that the architecture does not. Given the range of possible deployments, and as you alude to the potential changes in technology to support them) I hope we are allowing the range, while stillhaving a useful architecture. Yours, Joel On 7/10/14, 5:14 PM, Ian Smith wrote: > Actually, I think I am disagreeing. > > If the possibility of medium-scale deployments (and that is what 16 million flows is in my world) of service chains is preconceived as an absurd idea, then the architecture burdened with that preconception. > > There has to be some point of aim, some degree of aspiration to scale that is appropriate for the lifespan of the architecture - you don't have to know what it is, but by saying that an arbitrary number is "too far", you're creating - even if it isn't intentional - a limit that influences decisions that have lasting impacts regarding scale-out, failure mitigation, elasticity, address space... all kinds of things. That is a problem I'm not particularly eager to deal with. > > > > > ________________________________________ > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > Sent: Thursday, July 10, 2014 5:04 PM > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > Ian, I don't think you disagree with me at all in this regard. > I am not requesting the the architecture or the solution prohibit > deployments in the specific fashion. > I am objecting to Huang's reading of my note as saying that such > deployments are required they by the archtiecture. > > As I have said repeatedly, I am not trying to prohibit such things. > Whether they are a good idea or not depends upon many factors outside of > the scope of the WG. I happen to think that they are usually a bad idea. > > But the archtiecture si carefully avoiding attempting to know what is > and is not eployable. > > Yours, > Joel > > On 7/10/14, 5:01 PM, Ian Smith wrote: >> I disagree. >> >> We routinely have stateful devices that manage tens of millions of concurrent flows in both access network and data center environments today. You can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to have small numbers of service chains with equally small numbers of active service paths? >> >> Your sounds too much like "no one will ever need more than 64K" for comfort. >> >> >> ________________________________________ >> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelhalpern.com] >> Sent: Thursday, July 10, 2014 4:46 PM >> To: huang@sce.carleton.ca; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> No, it will mean that if someone tries to deploy the archtieture >> particularly badly, they will exceed the limits of their devices. >> The architecture does not require such absurd use of service paths. >> Since I can not figure out how to write architectural words to prohibit >> it, the architecture does permit such abuse. >> >> Please do not read my saying that the archtiecture permits something as >> saying it is either deisred or required by the work. It isn't. >> >> Yours, >> Joel >> >> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>> If you need to support 100 service chains, it will mean 16,000,000 >>> paths. That is larger than the routing table of a core router. >>> >>> Chang >>> >>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>> The architecture allows a range of deployments, from 1 service path to >>>> 160000 service paths. I would hope that operators are prepared for >>>> the complexities if they choose to avoid any use of local load >>>> balancing and in stead provision 160,000 service paths. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>> Paul, >>>>> >>>>> How many path identifiers there will be for a 4 hop service chain with >>>>> 20 instances at each hop? >>>>> >>>>> Maria >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>>>> (paulq) >>>>> *Sent:* Thursday, July 10, 2014 3:03 PM >>>>> *To:* Lucy yong >>>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; >>>>> mikebianc@aol.com >>>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Lucy, >>>>> >>>>> Overall I concur, as you say: a path ID drives the forwarding. I’d make >>>>> the minor change: the path identifier can be used to derive the needed >>>>> forwarding and associated transport. >>>>> >>>>> It is _not_ the transport, but rather is used to simply identify the >>>>> service path (or graph) that packets must traverse. By having a path >>>>> identifier, the exact indirection that people seem to be asking for on >>>>> this thread can be simply be implemented. The path identifier provides >>>>> nothing more than a lookup, that lookup can result in a one or more >>>>> (equal or weighted) transport next hop(s). >>>>> >>>>> Paul >>>>> >>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Agree. The arch. doc should not mandate only use of the service path >>>>> identifier to drive the forwarding actions. >>>>> >>>>> Lucy >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>> Of*mohamed.boucadair@orange.com >>>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com >>>>> ;sfc@ietf.org >>>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Re-, >>>>> >>>>> The merged draft calls out explicitly a service path identifier. I >>>>> object to use that identifier to derive forwarding actions. >>>>> >>>>> Requiring a SFC system to have the full knowledge of every available SFC >>>>> forwarding paths within an SFC-enabled domain is not required/justified >>>>> nor possible in various deployment contexts. >>>>> >>>>> SFC forwarding actions should rely on the piece of information that will >>>>> be present in all deployments: that is the one required to structure a >>>>> service chain. How that information is used to infer forwarding actions >>>>> is a solution-oriented discussion. >>>>> >>>>> Cheers, >>>>> >>>>> Med >>>>> >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com >>>>> >>>>> *Envoyé :*mercredi 9 juillet 2014 22:03 >>>>> *À :*jmh@joelhalpern.com ;sfc@ietf.org >>>>> >>>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Is anyone still questioning the difference between SF Chain and SF Path? >>>>> Other than clarifying the definition so that it's clear to those not >>>>> familiar with the draft, it seems that everyone agrees on these terms. >>>>> >>>>> To me, the one point that is still unclear is whether it is the intent >>>>> of this draft to ultimately specify what the ID of the SFC Header should >>>>> reference (the chain or the path), or if this draft simply intends to >>>>> leave that ambiguous, allowing other drafts to dictate the mechanisms >>>>> for forwarding based on chain or path and the choice of chain or path to >>>>> be negotiated in the control-plane. >>>>> >>>>> If the latter (ambiguous), then the draft would have require that both >>>>> SFP and SFC be supported (or make one required and the other optional) >>>>> to avoid some vendors only supporting SFP and others only supporting >>>>> SFC. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:*jmh@joelhalpern.com>>>> > >>>>> *To:*sfc@ietf.org> >>>>> *Sent:*Tuesday, July 8, 2014 >>>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> I have been trying to figure out how to clearly answer a number of >>>>> comments that have been made about the proposed merged archtiecture >>>>> draft. Assuming we can get working group agreement on the intent, we >>>>> will work to improve the wording so that readers who have not >>>>> participated in the WG discussion will understnd it the way the working >>>>> group intends. >>>>> >>>>> But what do we intend? I will try to explain my personal view, and see >>>>> if that helps. >>>>> >>>>> In this regard, it is important to keep in mind that what we are >>>>> defining is the data plane architecture. We are not attempting to >>>>> define the architecture for the entire solution for service chaining. >>>>> That would encompass OSS/BSS, various control and policy functions, >>>>> virtual machine and image management, and many other aspects. >>>>> >>>>> As a result there are many things which clearly need to exist in the >>>>> larger system, but which are dealt with above where we are functioning, >>>>> and are not directly required by the work we are doing. >>>>> >>>>> In order to get to service chain vs service path, as I understand them, >>>>> I need to first discuss load balancing. There are at least three >>>>> different ways that load balancing can and will interact with service >>>>> chaining. There probably are more. The point of the archtiecture is to >>>>> permit all of these, but not to mandate that any particular kind be used >>>>> in any solution. >>>>> >>>>> 1) Load balancing as a service provided to the end user. This is a >>>>> service function. It receives user packets, and modifies them (or marks >>>>> them, or ...) so as to choose an end user service instance to receive >>>>> the users packet. This is an important service function to be able to >>>>> include in service chaining. It's behavior may affect requirements on >>>>> how service chaining is done. But it has very little impact on the >>>>> archtiecture. From an architectural pe3rspective it is simply a service >>>>> function which may modify the underlying packet. >>>>> >>>>> 2) There is internal load balancing. That is, one can have what appears >>>>> to the service chaining architecture as a single point of contact for a >>>>> specific service function, but is actually delivered by a collection of >>>>> virtual or physical machines, possibly including one or several load >>>>> balancers (for example using VRRP-like techniques to share a MAC >>>>> address.) mostly, this is invisible to the service chaining data plane >>>>> mechanisms. It is likely that it is visible to various control >>>>> mechanisms, such as those responsible for scale-in, scale-out, and vm >>>>> instantiation. The architectural impact of permitting this is largely >>>>> that we need to be careful that our terminology does not lead readers to >>>>> think we are prohibiting it. >>>>> >>>>> 3) There can also be load balancing done by selecting packet paths for >>>>> the service chaining that direct traffic to different places. We would >>>>> not want to require that a given service function appear at only one >>>>> place in the network. >>>>> >>>>> It is of course the case that these may be combined. I tend to refer to >>>>> the collection of entities that appear to service chaining as a single >>>>> point as a cluster. Not because cluster is a good term. But because I >>>>> do not have another one. Thus, the point of type 3 load balancing is to >>>>> direct different subsets of traffic to different singular or clustered >>>>> service functions in different places in the network. >>>>> >>>>> Now with that said, what do I mean when I talk about service chain and >>>>> service path/ Service chain is a sequence of logical functions to be >>>>> applied to a subset of packets. It is equivalent of saying that some >>>>> subset of traffic is to get DPI, charging, content inspection, and >>>>> firewall while a different subset is to go directly to the cache without >>>>> visiting any other service functions. >>>>> >>>>> That is not enough information to direct the packets. A service path >>>>> is, in some fashion, a sequence of locations in the network. Those >>>>> locations will be singular or clustered service function delivery >>>>> locations. They may be addressed by IP address. They may be addressed >>>>> as ports on an SFF. There are many different ways that the locations >>>>> may be known to the service chaining infrastructure and the transport. >>>>> >>>>> >From the point of view of the work of the SFC group, we need to be >>>>> able >>>>> to talk about the high level abstraction, the service chain, which >>>>> drives the forwarding. And we need to talk about the actual data path >>>>> packets will take in the network. >>>>> >>>>> Several of the comments have said "but the whole path may not be known >>>>> at the front." This architecture deals with that issue in two ways. >>>>> First, as noted in item (2) on load balancers above, there can be >>>>> decisions and behaviors which are invisible to the service chaining >>>>> mechanisms (in much the same way that bridging within a LAN is largely >>>>> invisible to routing between LANs.) The other provision we make is that >>>>> reclassification can be done in mid-chain when necessary. That will >>>>> direct packets to a new chain. Based on information available at the >>>>> re-classification point. >>>>> >>>>> I hope that this helps explain what we are after. If it does, and if >>>>> the intent is acceptable to the working group, we can figure out what >>>>> additional words are needed to convey this. >>>>> If the working group disagree with the intent, then we will of course >>>>> adjust to match the working group agreements. >>>>> If this is still unclear, I am not sure what to try next. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing 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 Jul 10 14:44: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 B57891B2A7C for ; Thu, 10 Jul 2014 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uChBZyY-Hb6Q for ; Thu, 10 Jul 2014 14:44:31 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAA11B2A71 for ; Thu, 10 Jul 2014 14:44:31 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id f390fb35.2b15dc606940.8611290.00-2406.20589471.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:44:31 +0000 (UTC) X-MXL-Hash: 53bf093f0ddfb301-9dac94e6ca1eb101b55d1d4e2fc98244fd1c1f25 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d390fb35.0.8611283.00-2396.20589429.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 21:44:29 +0000 (UTC) X-MXL-Hash: 53bf093d403c05e2-7823ca13a3584d427e917bc3d3cb7cb007af6747 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALiSVo007511; Thu, 10 Jul 2014 17:44:29 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6ALiMpM007450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 17:44:23 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 21:44:10 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 17:44:10 -0400 From: "NAPIERALA, MARIA H" To: Ian Smith , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBAD//8BhIIAARgaA//++G6A= Date: Thu, 10 Jul 2014 21:44:10 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=n2LCcfabAAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=z9tbli-vAAAA:8 a=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=bNKbP] X-AnalysisOut: [cU9kSafna8qw9EA:9 a=wPNLvfGTeEIA:10 a=3XJ037QrwtgA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=chC_agHSu74A:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=U8Ie8EnqySEA:10 a=hPjdaMEvmhQA:10 a=oYphLmRZrf] X-AnalysisOut: [tswGjs:21 a=cuogfz3SORmXRClg:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rVlidzhj7E81JZSWwMixXCQw4xs Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:44:34 -0000 For me it is a logical or virtual network over a common physical network. H= owever you view it is not something that stays within a single device. > -----Original Message----- > From: Ian Smith [mailto:I.Smith@f5.com] > Sent: Thursday, July 10, 2014 5:38 PM > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; > huang@sce.carleton.ca; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >=20 > A service path isn't a logical network; it is - quite literally - a path= _though_ > a network. >=20 >=20 >=20 > ________________________________________ > From: NAPIERALA, MARIA H [mn1921@att.com] > Sent: Thursday, July 10, 2014 5:33 PM > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a; > sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >=20 > Managing millions of 5-tuple flows in a single appliance is not the same = as > managing (globally) millions of service paths which are essentially logic= al > networks. And 16 million was an arbitrary number for just 100 service > chains. 100 service chains is very little. Image this number be two or mo= re > orders of magnitude higher... >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith > > Sent: Thursday, July 10, 2014 5:15 PM > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca; > > sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > Actually, I think I am disagreeing. > > > > If the possibility of medium-scale deployments (and that is what 16 > million > > flows is in my world) of service chains is preconceived as an absurd id= ea, > > then the architecture burdened with that preconception. > > > > There has to be some point of aim, some degree of aspiration to scale > that > > is appropriate for the lifespan of the architecture - you don't have to > know > > what it is, but by saying that an arbitrary number is "too far", you're > > creating - even if it isn't intentional - a limit that influences decis= ions that > > have lasting impacts regarding scale-out, failure mitigation, elasticit= y, > > address space... all kinds of things. That is a problem I'm not partic= ularly > > eager to deal with. > > > > > > > > > > ________________________________________ > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > > Sent: Thursday, July 10, 2014 5:04 PM > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > Ian, I don't think you disagree with me at all in this regard. > > I am not requesting the the architecture or the solution prohibit > > deployments in the specific fashion. > > I am objecting to Huang's reading of my note as saying that such > > deployments are required they by the archtiecture. > > > > As I have said repeatedly, I am not trying to prohibit such things. > > Whether they are a good idea or not depends upon many factors outside > of > > the scope of the WG. I happen to think that they are usually a bad ide= a. > > > > But the archtiecture si carefully avoiding attempting to know what is > > and is not eployable. > > > > Yours, > > Joel > > > > On 7/10/14, 5:01 PM, Ian Smith wrote: > > > I disagree. > > > > > > We routinely have stateful devices that manage tens of millions of > > concurrent flows in both access network and data center environments > > today. You can't seriously believe that in the > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to > > have small numbers of service chains with equally small numbers of acti= ve > > service paths? > > > > > > Your sounds too much like "no one will ever need more than 64K" for > > comfort. > > > > > > > > > ________________________________________ > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > > [jmh@joelhalpern.com] > > > Sent: Thursday, July 10, 2014 4:46 PM > > > To: huang@sce.carleton.ca; sfc@ietf.org > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > No, it will mean that if someone tries to deploy the archtieture > > > particularly badly, they will exceed the limits of their devices. > > > The architecture does not require such absurd use of service paths. > > > Since I can not figure out how to write architectural words to prohib= it > > > it, the architecture does permit such abuse. > > > > > > Please do not read my saying that the archtiecture permits something > as > > > saying it is either deisred or required by the work. It isn't. > > > > > > Yours, > > > Joel > > > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > > >> If you need to support 100 service chains, it will mean 16,000,000 > > >> paths. That is larger than the routing table of a core router. > > >> > > >> Chang > > >> > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > > >>> The architecture allows a range of deployments, from 1 service path > to > > >>> 160000 service paths. I would hope that operators are prepared for > > >>> the complexities if they choose to avoid any use of local load > > >>> balancing and in stead provision 160,000 service paths. > > >>> > > >>> Yours, > > >>> Joel > > >>> > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > > >>>> Paul, > > >>>> > > >>>> How many path identifiers there will be for a 4 hop service chain > with > > >>>> 20 instances at each hop? > > >>>> > > >>>> Maria > > >>>> > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn > > >>>> (paulq) > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > > >>>> *To:* Lucy yong > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; > > sfc@ietf.org; > > >>>> mikebianc@aol.com > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>> > > >>>> Lucy, > > >>>> > > >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd= make > > >>>> the minor change: the path identifier can be used to derive the > > needed > > >>>> forwarding and associated transport. > > >>>> > > >>>> It is _not_ the transport, but rather is used to simply identify t= he > > >>>> service path (or graph) that packets must traverse. By having a p= ath > > >>>> identifier, the exact indirection that people seem to be asking fo= r on > > >>>> this thread can be simply be implemented. The path identifier > > provides > > >>>> nothing more than a lookup, that lookup can result in a one or mor= e > > >>>> (equal or weighted) transport next hop(s). > > >>>> > > >>>> Paul > > >>>> > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>> > wrote: > > >>>> > > >>>> > > >>>> > > >>>> Agree. The arch. doc should not mandate only use of the service > path > > >>>> identifier to drive the forwarding actions. > > >>>> > > >>>> Lucy > > >>>> > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > > >>>> Of*mohamed.boucadair@orange.com > > > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > > >>>> *To:*mikebianc@aol.com > > ;jmh@joelhalpern.com > > >>>> ;sfc@ietf.org > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>> > > >>>> Re-, > > >>>> > > >>>> The merged draft calls out explicitly a service path identifier. I > > >>>> object to use that identifier to derive forwarding actions. > > >>>> > > >>>> Requiring a SFC system to have the full knowledge of every availab= le > > SFC > > >>>> forwarding paths within an SFC-enabled domain is not > > required/justified > > >>>> nor possible in various deployment contexts. > > >>>> > > >>>> SFC forwarding actions should rely on the piece of information tha= t > > will > > >>>> be present in all deployments: that is the one required to structu= re > a > > >>>> service chain. How that information is used to infer forwarding > actions > > >>>> is a solution-oriented discussion. > > >>>> > > >>>> Cheers, > > >>>> > > >>>> Med > > >>>> > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > > de*mikebianc@aol.com > > >>>> > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 > > >>>> *=C0 :*jmh@joelhalpern.com > > ;sfc@ietf.org > > >>>> > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>> > > >>>> Is anyone still questioning the difference between SF Chain and SF > > Path? > > >>>> Other than clarifying the definition so that it's clear to thos= e not > > >>>> familiar with the draft, it seems that everyone agrees on these > terms. > > >>>> > > >>>> To me, the one point that is still unclear is whether it is the in= tent > > >>>> of this draft to ultimately specify what the ID of the SFC Header > > should > > >>>> reference (the chain or the path), or if this draft simply intends= to > > >>>> leave that ambiguous, allowing other drafts to dictate the > > mechanisms > > >>>> for forwarding based on chain or path and the choice of chain or > path > > to > > >>>> be negotiated in the control-plane. > > >>>> > > >>>> If the latter (ambiguous), then the draft would have require that > both > > >>>> SFP and SFC be supported (or make one required and the other > > optional) > > >>>> to avoid some vendors only supporting SFP and others only > > supporting > > >>>> SFC. > > >>>> > > >>>> ------------------------------------------------------------------= ------ > > >>>> > > >>>> *From:*jmh@joelhalpern.com > >>>> > > > >>>> *To:*sfc@ietf.org > > > >>>> *Sent:*Tuesday, July 8, 2014 > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > > >>>> > > >>>> I have been trying to figure out how to clearly answer a number of > > >>>> comments that have been made about the proposed merged > > archtiecture > > >>>> draft. Assuming we can get working group agreement on the intent, > > we > > >>>> will work to improve the wording so that readers who have not > > >>>> participated in the WG discussion will understnd it the way the > > working > > >>>> group intends. > > >>>> > > >>>> But what do we intend? I will try to explain my personal view, and > see > > >>>> if that helps. > > >>>> > > >>>> In this regard, it is important to keep in mind that what we are > > >>>> defining is the data plane architecture. We are not attempting to > > >>>> define the architecture for the entire solution for service chaini= ng. > > >>>> That would encompass OSS/BSS, various control and policy > functions, > > >>>> virtual machine and image management, and many other aspects. > > >>>> > > >>>> As a result there are many things which clearly need to exist in t= he > > >>>> larger system, but which are dealt with above where we are > > functioning, > > >>>> and are not directly required by the work we are doing. > > >>>> > > >>>> In order to get to service chain vs service path, as I understand > them, > > >>>> I need to first discuss load balancing. There are at least three > > >>>> different ways that load balancing can and will interact with serv= ice > > >>>> chaining. There probably are more. The point of the archtiecture i= s > to > > >>>> permit all of these, but not to mandate that any particular kind b= e > > used > > >>>> in any solution. > > >>>> > > >>>> 1) Load balancing as a service provided to the end user. This is a > > >>>> service function. It receives user packets, and modifies them (or > marks > > >>>> them, or ...) so as to choose an end user service instance to rece= ive > > >>>> the users packet. This is an important service function to be able= to > > >>>> include in service chaining. It's behavior may affect requirements= on > > >>>> how service chaining is done. But it has very little impact on the > > >>>> archtiecture. From an architectural pe3rspective it is simply a se= rvice > > >>>> function which may modify the underlying packet. > > >>>> > > >>>> 2) There is internal load balancing. That is, one can have what > appears > > >>>> to the service chaining architecture as a single point of contact = for a > > >>>> specific service function, but is actually delivered by a collecti= on of > > >>>> virtual or physical machines, possibly including one or several lo= ad > > >>>> balancers (for example using VRRP-like techniques to share a MAC > > >>>> address.) mostly, this is invisible to the service chaining data p= lane > > >>>> mechanisms. It is likely that it is visible to various control > > >>>> mechanisms, such as those responsible for scale-in, scale-out, and > vm > > >>>> instantiation. The architectural impact of permitting this is larg= ely > > >>>> that we need to be careful that our terminology does not lead > readers > > to > > >>>> think we are prohibiting it. > > >>>> > > >>>> 3) There can also be load balancing done by selecting packet paths > for > > >>>> the service chaining that direct traffic to different places. We w= ould > > >>>> not want to require that a given service function appear at only o= ne > > >>>> place in the network. > > >>>> > > >>>> It is of course the case that these may be combined. I tend to ref= er > to > > >>>> the collection of entities that appear to service chaining as a si= ngle > > >>>> point as a cluster. Not because cluster is a good term. But becaus= e I > > >>>> do not have another one. Thus, the point of type 3 load balancing = is > > to > > >>>> direct different subsets of traffic to different singular or clust= ered > > >>>> service functions in different places in the network. > > >>>> > > >>>> Now with that said, what do I mean when I talk about service chain > > and > > >>>> service path/ Service chain is a sequence of logical functions to = be > > >>>> applied to a subset of packets. It is equivalent of saying that so= me > > >>>> subset of traffic is to get DPI, charging, content inspection, and > > >>>> firewall while a different subset is to go directly to the cache w= ithout > > >>>> visiting any other service functions. > > >>>> > > >>>> That is not enough information to direct the packets. A service pa= th > > >>>> is, in some fashion, a sequence of locations in the network. Those > > >>>> locations will be singular or clustered service function delivery > > >>>> locations. They may be addressed by IP address. They may be > > addressed > > >>>> as ports on an SFF. There are many different ways that the locatio= ns > > >>>> may be known to the service chaining infrastructure and the > > transport. > > >>>> > > >>>> >From the point of view of the work of the SFC group, we need to > be > > >>>> able > > >>>> to talk about the high level abstraction, the service chain, which > > >>>> drives the forwarding. And we need to talk about the actual data > path > > >>>> packets will take in the network. > > >>>> > > >>>> Several of the comments have said "but the whole path may not be > > known > > >>>> at the front." This architecture deals with that issue in two ways= . > > >>>> First, as noted in item (2) on load balancers above, there can be > > >>>> decisions and behaviors which are invisible to the service chainin= g > > >>>> mechanisms (in much the same way that bridging within a LAN is > > largely > > >>>> invisible to routing between LANs.) The other provision we make is > > that > > >>>> reclassification can be done in mid-chain when necessary. That wil= l > > >>>> direct packets to a new chain. Based on information available at t= he > > >>>> re-classification point. > > >>>> > > >>>> I hope that this helps explain what we are after. If it does, and = if > > >>>> the intent is acceptable to the working group, we can figure out > what > > >>>> additional words are needed to convey this. > > >>>> If the working group disagree with the intent, then we will of cou= rse > > >>>> adjust to match the working group agreements. > > >>>> If this is still unclear, I am not sure what to try next. > > >>>> > > >>>> Yours, > > >>>> Joel > > >>>> > > >>>> _______________________________________________ > > >>>> sfc mailing list > > >>>> sfc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>> > > >>>> _______________________________________________ > > >>>> sfc mailing list > > >>>> sfc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>> > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > >> > > > > > > _______________________________________________ > > > sfc mailing 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 Jul 10 14:50: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 346EB1B2A80 for ; Thu, 10 Jul 2014 14:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 4g-dvfFv6m6B for ; Thu, 10 Jul 2014 14:50:28 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CB31B2A53 for ; Thu, 10 Jul 2014 14:50:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="121305398" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABPCoNBV60VjyofhzWBN3SCJQEBAQECAQEBAWIJAg4HBAIBCBEBAwEBAQodBycLFAMGCAIEARIIE4dNAwkVzBATBIxTgT0FJjgGgx6BFASJI4sKRI5hin6BakE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 10 Jul 2014 21:50:27 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:50:26 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH0MgP//ixO3AA7+twD//4rdBA== Date: Thu, 10 Jul 2014 21:50:26 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] 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/yKQDIpEJn3Q_1gRjp4w5rzjCYhE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:50:32 -0000 > However you view it is not something that stays within a single device.= =0A= =0A= Agreed. But I'm not asserting that it does. What I am asserting is that t= he scale of what a single device can do today matters when thinking about h= ow to do almost exactly what that device does in a distributed manner.=0A= =0A= Picking channelized paths through packet switched networks is making the ne= twork stateful, so if you can, for example be stateful to the order of 50 o= r 100 million flows in an existing single node, then you should _at the ver= y least_ expect to have 50 to 100 million flows in the distributed system t= hat takes its place. =0A= =0A= ________________________________________=0A= From: NAPIERALA, MARIA H [mn1921@att.com]=0A= Sent: Thursday, July 10, 2014 5:44 PM=0A= To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;= sfc@ietf.org=0A= Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= For me it is a logical or virtual network over a common physical network. H= owever you view it is not something that stays within a single device.=0A= =0A= > -----Original Message-----=0A= > From: Ian Smith [mailto:I.Smith@f5.com]=0A= > Sent: Thursday, July 10, 2014 5:38 PM=0A= > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern;=0A= > huang@sce.carleton.ca; sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > A service path isn't a logical network; it is - quite literally - a path= _though_=0A= > a network.=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > Sent: Thursday, July 10, 2014 5:33 PM=0A= > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a;=0A= > sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > Managing millions of 5-tuple flows in a single appliance is not the same = as=0A= > managing (globally) millions of service paths which are essentially logic= al=0A= > networks. And 16 million was an arbitrary number for just 100 service=0A= > chains. 100 service chains is very little. Image this number be two or mo= re=0A= > orders of magnitude higher...=0A= >=0A= > > -----Original Message-----=0A= > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=0A= > > Sent: Thursday, July 10, 2014 5:15 PM=0A= > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;=0A= > > sfc@ietf.org=0A= > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > Actually, I think I am disagreeing.=0A= > >=0A= > > If the possibility of medium-scale deployments (and that is what 16=0A= > million=0A= > > flows is in my world) of service chains is preconceived as an absurd id= ea,=0A= > > then the architecture burdened with that preconception.=0A= > >=0A= > > There has to be some point of aim, some degree of aspiration to scale= =0A= > that=0A= > > is appropriate for the lifespan of the architecture - you don't have to= =0A= > know=0A= > > what it is, but by saying that an arbitrary number is "too far", you're= =0A= > > creating - even if it isn't intentional - a limit that influences decis= ions that=0A= > > have lasting impacts regarding scale-out, failure mitigation, elasticit= y,=0A= > > address space... all kinds of things. That is a problem I'm not partic= ularly=0A= > > eager to deal with.=0A= > >=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > > Sent: Thursday, July 10, 2014 5:04 PM=0A= > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org=0A= > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > Ian, I don't think you disagree with me at all in this regard.=0A= > > I am not requesting the the architecture or the solution prohibit=0A= > > deployments in the specific fashion.=0A= > > I am objecting to Huang's reading of my note as saying that such=0A= > > deployments are required they by the archtiecture.=0A= > >=0A= > > As I have said repeatedly, I am not trying to prohibit such things.=0A= > > Whether they are a good idea or not depends upon many factors outside= =0A= > of=0A= > > the scope of the WG. I happen to think that they are usually a bad ide= a.=0A= > >=0A= > > But the archtiecture si carefully avoiding attempting to know what is= =0A= > > and is not eployable.=0A= > >=0A= > > Yours,=0A= > > Joel=0A= > >=0A= > > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > > > I disagree.=0A= > > >=0A= > > > We routinely have stateful devices that manage tens of millions of=0A= > > concurrent flows in both access network and data center environments=0A= > > today. You can't seriously believe that in the=0A= > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to= =0A= > > have small numbers of service chains with equally small numbers of acti= ve=0A= > > service paths?=0A= > > >=0A= > > > Your sounds too much like "no one will ever need more than 64K" for= =0A= > > comfort.=0A= > > >=0A= > > >=0A= > > > ________________________________________=0A= > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > > [jmh@joelhalpern.com]=0A= > > > Sent: Thursday, July 10, 2014 4:46 PM=0A= > > > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > No, it will mean that if someone tries to deploy the archtieture=0A= > > > particularly badly, they will exceed the limits of their devices.=0A= > > > The architecture does not require such absurd use of service paths.= =0A= > > > Since I can not figure out how to write architectural words to prohib= it=0A= > > > it, the architecture does permit such abuse.=0A= > > >=0A= > > > Please do not read my saying that the archtiecture permits something= =0A= > as=0A= > > > saying it is either deisred or required by the work. It isn't.=0A= > > >=0A= > > > Yours,=0A= > > > Joel=0A= > > >=0A= > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > > >> If you need to support 100 service chains, it will mean 16,000,000= =0A= > > >> paths. That is larger than the routing table of a core router.=0A= > > >>=0A= > > >> Chang=0A= > > >>=0A= > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= > > >>> The architecture allows a range of deployments, from 1 service path= =0A= > to=0A= > > >>> 160000 service paths. I would hope that operators are prepared for= =0A= > > >>> the complexities if they choose to avoid any use of local load=0A= > > >>> balancing and in stead provision 160,000 service paths.=0A= > > >>>=0A= > > >>> Yours,=0A= > > >>> Joel=0A= > > >>>=0A= > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= > > >>>> Paul,=0A= > > >>>>=0A= > > >>>> How many path identifiers there will be for a 4 hop service chain= =0A= > with=0A= > > >>>> 20 instances at each hop?=0A= > > >>>>=0A= > > >>>> Maria=0A= > > >>>>=0A= > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn= =0A= > > >>>> (paulq)=0A= > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= > > >>>> *To:* Lucy yong=0A= > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com;=0A= > > sfc@ietf.org;=0A= > > >>>> mikebianc@aol.com=0A= > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Lucy,=0A= > > >>>>=0A= > > >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd= make=0A= > > >>>> the minor change: the path identifier can be used to derive the=0A= > > needed=0A= > > >>>> forwarding and associated transport.=0A= > > >>>>=0A= > > >>>> It is _not_ the transport, but rather is used to simply identify t= he=0A= > > >>>> service path (or graph) that packets must traverse. By having a p= ath=0A= > > >>>> identifier, the exact indirection that people seem to be asking fo= r on=0A= > > >>>> this thread can be simply be implemented. The path identifier=0A= > > provides=0A= > > >>>> nothing more than a lookup, that lookup can result in a one or mor= e=0A= > > >>>> (equal or weighted) transport next hop(s).=0A= > > >>>>=0A= > > >>>> Paul=0A= > > >>>>=0A= > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>> > wrote:=0A= > > >>>>=0A= > > >>>>=0A= > > >>>>=0A= > > >>>> Agree. The arch. doc should not mandate only use of the service=0A= > path=0A= > > >>>> identifier to drive the forwarding actions.=0A= > > >>>>=0A= > > >>>> Lucy=0A= > > >>>>=0A= > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= > > >>>> Of*mohamed.boucadair@orange.com=0A= > > =0A= > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= > > >>>> *To:*mikebianc@aol.com=0A= > > ;jmh@joelhalpern.com=0A= > > >>>> ;sfc@ietf.org =0A= > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Re-,=0A= > > >>>>=0A= > > >>>> The merged draft calls out explicitly a service path identifier. I= =0A= > > >>>> object to use that identifier to derive forwarding actions.=0A= > > >>>>=0A= > > >>>> Requiring a SFC system to have the full knowledge of every availab= le=0A= > > SFC=0A= > > >>>> forwarding paths within an SFC-enabled domain is not=0A= > > required/justified=0A= > > >>>> nor possible in various deployment contexts.=0A= > > >>>>=0A= > > >>>> SFC forwarding actions should rely on the piece of information tha= t=0A= > > will=0A= > > >>>> be present in all deployments: that is the one required to structu= re=0A= > a=0A= > > >>>> service chain. How that information is used to infer forwarding=0A= > actions=0A= > > >>>> is a solution-oriented discussion.=0A= > > >>>>=0A= > > >>>> Cheers,=0A= > > >>>>=0A= > > >>>> Med=0A= > > >>>>=0A= > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= > > de*mikebianc@aol.com=0A= > > >>>> =0A= > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= > > >>>> *=C0 :*jmh@joelhalpern.com=0A= > > ;sfc@ietf.org=0A= > > >>>> =0A= > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Is anyone still questioning the difference between SF Chain and SF= =0A= > > Path?=0A= > > >>>> Other than clarifying the definition so that it's clear to thos= e not=0A= > > >>>> familiar with the draft, it seems that everyone agrees on these=0A= > terms.=0A= > > >>>>=0A= > > >>>> To me, the one point that is still unclear is whether it is the in= tent=0A= > > >>>> of this draft to ultimately specify what the ID of the SFC Header= =0A= > > should=0A= > > >>>> reference (the chain or the path), or if this draft simply intends= to=0A= > > >>>> leave that ambiguous, allowing other drafts to dictate the=0A= > > mechanisms=0A= > > >>>> for forwarding based on chain or path and the choice of chain or= =0A= > path=0A= > > to=0A= > > >>>> be negotiated in the control-plane.=0A= > > >>>>=0A= > > >>>> If the latter (ambiguous), then the draft would have require that= =0A= > both=0A= > > >>>> SFP and SFC be supported (or make one required and the other=0A= > > optional)=0A= > > >>>> to avoid some vendors only supporting SFP and others only=0A= > > supporting=0A= > > >>>> SFC.=0A= > > >>>>=0A= > > >>>> ------------------------------------------------------------------= ------=0A= > > >>>>=0A= > > >>>> *From:*jmh@joelhalpern.com > >>>> >=0A= > > >>>> *To:*sfc@ietf.org >=0A= > > >>>> *Sent:*Tuesday, July 8, 2014=0A= > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> I have been trying to figure out how to clearly answer a number of= =0A= > > >>>> comments that have been made about the proposed merged=0A= > > archtiecture=0A= > > >>>> draft. Assuming we can get working group agreement on the intent,= =0A= > > we=0A= > > >>>> will work to improve the wording so that readers who have not=0A= > > >>>> participated in the WG discussion will understnd it the way the=0A= > > working=0A= > > >>>> group intends.=0A= > > >>>>=0A= > > >>>> But what do we intend? I will try to explain my personal view, and= =0A= > see=0A= > > >>>> if that helps.=0A= > > >>>>=0A= > > >>>> In this regard, it is important to keep in mind that what we are= =0A= > > >>>> defining is the data plane architecture. We are not attempting to= =0A= > > >>>> define the architecture for the entire solution for service chaini= ng.=0A= > > >>>> That would encompass OSS/BSS, various control and policy=0A= > functions,=0A= > > >>>> virtual machine and image management, and many other aspects.=0A= > > >>>>=0A= > > >>>> As a result there are many things which clearly need to exist in t= he=0A= > > >>>> larger system, but which are dealt with above where we are=0A= > > functioning,=0A= > > >>>> and are not directly required by the work we are doing.=0A= > > >>>>=0A= > > >>>> In order to get to service chain vs service path, as I understand= =0A= > them,=0A= > > >>>> I need to first discuss load balancing. There are at least three= =0A= > > >>>> different ways that load balancing can and will interact with serv= ice=0A= > > >>>> chaining. There probably are more. The point of the archtiecture i= s=0A= > to=0A= > > >>>> permit all of these, but not to mandate that any particular kind b= e=0A= > > used=0A= > > >>>> in any solution.=0A= > > >>>>=0A= > > >>>> 1) Load balancing as a service provided to the end user. This is a= =0A= > > >>>> service function. It receives user packets, and modifies them (or= =0A= > marks=0A= > > >>>> them, or ...) so as to choose an end user service instance to rece= ive=0A= > > >>>> the users packet. This is an important service function to be able= to=0A= > > >>>> include in service chaining. It's behavior may affect requirements= on=0A= > > >>>> how service chaining is done. But it has very little impact on the= =0A= > > >>>> archtiecture. From an architectural pe3rspective it is simply a se= rvice=0A= > > >>>> function which may modify the underlying packet.=0A= > > >>>>=0A= > > >>>> 2) There is internal load balancing. That is, one can have what=0A= > appears=0A= > > >>>> to the service chaining architecture as a single point of contact = for a=0A= > > >>>> specific service function, but is actually delivered by a collecti= on of=0A= > > >>>> virtual or physical machines, possibly including one or several lo= ad=0A= > > >>>> balancers (for example using VRRP-like techniques to share a MAC= =0A= > > >>>> address.) mostly, this is invisible to the service chaining data p= lane=0A= > > >>>> mechanisms. It is likely that it is visible to various control=0A= > > >>>> mechanisms, such as those responsible for scale-in, scale-out, and= =0A= > vm=0A= > > >>>> instantiation. The architectural impact of permitting this is larg= ely=0A= > > >>>> that we need to be careful that our terminology does not lead=0A= > readers=0A= > > to=0A= > > >>>> think we are prohibiting it.=0A= > > >>>>=0A= > > >>>> 3) There can also be load balancing done by selecting packet paths= =0A= > for=0A= > > >>>> the service chaining that direct traffic to different places. We w= ould=0A= > > >>>> not want to require that a given service function appear at only o= ne=0A= > > >>>> place in the network.=0A= > > >>>>=0A= > > >>>> It is of course the case that these may be combined. I tend to ref= er=0A= > to=0A= > > >>>> the collection of entities that appear to service chaining as a si= ngle=0A= > > >>>> point as a cluster. Not because cluster is a good term. But becaus= e I=0A= > > >>>> do not have another one. Thus, the point of type 3 load balancing = is=0A= > > to=0A= > > >>>> direct different subsets of traffic to different singular or clust= ered=0A= > > >>>> service functions in different places in the network.=0A= > > >>>>=0A= > > >>>> Now with that said, what do I mean when I talk about service chain= =0A= > > and=0A= > > >>>> service path/ Service chain is a sequence of logical functions to = be=0A= > > >>>> applied to a subset of packets. It is equivalent of saying that so= me=0A= > > >>>> subset of traffic is to get DPI, charging, content inspection, and= =0A= > > >>>> firewall while a different subset is to go directly to the cache w= ithout=0A= > > >>>> visiting any other service functions.=0A= > > >>>>=0A= > > >>>> That is not enough information to direct the packets. A service pa= th=0A= > > >>>> is, in some fashion, a sequence of locations in the network. Those= =0A= > > >>>> locations will be singular or clustered service function delivery= =0A= > > >>>> locations. They may be addressed by IP address. They may be=0A= > > addressed=0A= > > >>>> as ports on an SFF. There are many different ways that the locatio= ns=0A= > > >>>> may be known to the service chaining infrastructure and the=0A= > > transport.=0A= > > >>>>=0A= > > >>>> >From the point of view of the work of the SFC group, we need to= =0A= > be=0A= > > >>>> able=0A= > > >>>> to talk about the high level abstraction, the service chain, which= =0A= > > >>>> drives the forwarding. And we need to talk about the actual data= =0A= > path=0A= > > >>>> packets will take in the network.=0A= > > >>>>=0A= > > >>>> Several of the comments have said "but the whole path may not be= =0A= > > known=0A= > > >>>> at the front." This architecture deals with that issue in two ways= .=0A= > > >>>> First, as noted in item (2) on load balancers above, there can be= =0A= > > >>>> decisions and behaviors which are invisible to the service chainin= g=0A= > > >>>> mechanisms (in much the same way that bridging within a LAN is=0A= > > largely=0A= > > >>>> invisible to routing between LANs.) The other provision we make is= =0A= > > that=0A= > > >>>> reclassification can be done in mid-chain when necessary. That wil= l=0A= > > >>>> direct packets to a new chain. Based on information available at t= he=0A= > > >>>> re-classification point.=0A= > > >>>>=0A= > > >>>> I hope that this helps explain what we are after. If it does, and = if=0A= > > >>>> the intent is acceptable to the working group, we can figure out= =0A= > what=0A= > > >>>> additional words are needed to convey this.=0A= > > >>>> If the working group disagree with the intent, then we will of cou= rse=0A= > > >>>> adjust to match the working group agreements.=0A= > > >>>> If this is still unclear, I am not sure what to try next.=0A= > > >>>>=0A= > > >>>> Yours,=0A= > > >>>> Joel=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= > > >> _______________________________________________=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= > > _______________________________________________=0A= > > sfc mailing list=0A= > > sfc@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Jul 10 14:52: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 B27BB1B2A84 for ; Thu, 10 Jul 2014 14:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 9hgSUJJwxU8m for ; Thu, 10 Jul 2014 14:52:42 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673841B2814 for ; Thu, 10 Jul 2014 14:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405029162; x=1436565162; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IUVkbf8Df6HAMRp6AZ4aXaPdTxsXyy8ZLhFyAADjZ3w=; b=tBvBm3iydo4NSmy8qz9opTu/XHJeFHxWg80tguoE6kUdSjhAaSE+7TSk l3nJqzPqb3RH2w15OjatnvDcWu+bGdEaXHI7RHkTj4j1yf+jxpcO4QJoH yXFrzcbHEAdb/nxBibH+TahPeCJLJQxtL2n8BHxLdZyKdvZJqtqIA9gNS E=; X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208";a="121424798" X-IPAS-Result: AqgEAOkJv1PAqArr/2dsb2JhbABPCoNgWq5rkVggCodCAYEkdYQDAQEBAQMBAQFiCQIVBAIBCBEBAwEBAQodBycLFAMGCAIEARIIE4gTAx7GJRMEjRmBTwUmOAaDJ4EWBYoejAJGj32LdYFvQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 21:52:41 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:52:40 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH0MgP//ixO3AA7+twD//4yRrg== Date: Thu, 10 Jul 2014 21:52:40 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C696@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] 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/w1jTGEHstlXuHHxLeXuc5wqij2U Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:52:45 -0000 I think that what you just defined is the Service Function Chain.=0A= =0A= ________________________________________=0A= From: NAPIERALA, MARIA H [mn1921@att.com]=0A= Sent: Thursday, July 10, 2014 5:44 PM=0A= To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;= sfc@ietf.org=0A= Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= For me it is a logical or virtual network over a common physical network. H= owever you view it is not something that stays within a single device.=0A= =0A= > -----Original Message-----=0A= > From: Ian Smith [mailto:I.Smith@f5.com]=0A= > Sent: Thursday, July 10, 2014 5:38 PM=0A= > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern;=0A= > huang@sce.carleton.ca; sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > A service path isn't a logical network; it is - quite literally - a path= _though_=0A= > a network.=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > Sent: Thursday, July 10, 2014 5:33 PM=0A= > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a;=0A= > sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > Managing millions of 5-tuple flows in a single appliance is not the same = as=0A= > managing (globally) millions of service paths which are essentially logic= al=0A= > networks. And 16 million was an arbitrary number for just 100 service=0A= > chains. 100 service chains is very little. Image this number be two or mo= re=0A= > orders of magnitude higher...=0A= >=0A= > > -----Original Message-----=0A= > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=0A= > > Sent: Thursday, July 10, 2014 5:15 PM=0A= > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;=0A= > > sfc@ietf.org=0A= > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > Actually, I think I am disagreeing.=0A= > >=0A= > > If the possibility of medium-scale deployments (and that is what 16=0A= > million=0A= > > flows is in my world) of service chains is preconceived as an absurd id= ea,=0A= > > then the architecture burdened with that preconception.=0A= > >=0A= > > There has to be some point of aim, some degree of aspiration to scale= =0A= > that=0A= > > is appropriate for the lifespan of the architecture - you don't have to= =0A= > know=0A= > > what it is, but by saying that an arbitrary number is "too far", you're= =0A= > > creating - even if it isn't intentional - a limit that influences decis= ions that=0A= > > have lasting impacts regarding scale-out, failure mitigation, elasticit= y,=0A= > > address space... all kinds of things. That is a problem I'm not partic= ularly=0A= > > eager to deal with.=0A= > >=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > > Sent: Thursday, July 10, 2014 5:04 PM=0A= > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org=0A= > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > Ian, I don't think you disagree with me at all in this regard.=0A= > > I am not requesting the the architecture or the solution prohibit=0A= > > deployments in the specific fashion.=0A= > > I am objecting to Huang's reading of my note as saying that such=0A= > > deployments are required they by the archtiecture.=0A= > >=0A= > > As I have said repeatedly, I am not trying to prohibit such things.=0A= > > Whether they are a good idea or not depends upon many factors outside= =0A= > of=0A= > > the scope of the WG. I happen to think that they are usually a bad ide= a.=0A= > >=0A= > > But the archtiecture si carefully avoiding attempting to know what is= =0A= > > and is not eployable.=0A= > >=0A= > > Yours,=0A= > > Joel=0A= > >=0A= > > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > > > I disagree.=0A= > > >=0A= > > > We routinely have stateful devices that manage tens of millions of=0A= > > concurrent flows in both access network and data center environments=0A= > > today. You can't seriously believe that in the=0A= > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to= =0A= > > have small numbers of service chains with equally small numbers of acti= ve=0A= > > service paths?=0A= > > >=0A= > > > Your sounds too much like "no one will ever need more than 64K" for= =0A= > > comfort.=0A= > > >=0A= > > >=0A= > > > ________________________________________=0A= > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > > [jmh@joelhalpern.com]=0A= > > > Sent: Thursday, July 10, 2014 4:46 PM=0A= > > > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > No, it will mean that if someone tries to deploy the archtieture=0A= > > > particularly badly, they will exceed the limits of their devices.=0A= > > > The architecture does not require such absurd use of service paths.= =0A= > > > Since I can not figure out how to write architectural words to prohib= it=0A= > > > it, the architecture does permit such abuse.=0A= > > >=0A= > > > Please do not read my saying that the archtiecture permits something= =0A= > as=0A= > > > saying it is either deisred or required by the work. It isn't.=0A= > > >=0A= > > > Yours,=0A= > > > Joel=0A= > > >=0A= > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > > >> If you need to support 100 service chains, it will mean 16,000,000= =0A= > > >> paths. That is larger than the routing table of a core router.=0A= > > >>=0A= > > >> Chang=0A= > > >>=0A= > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= > > >>> The architecture allows a range of deployments, from 1 service path= =0A= > to=0A= > > >>> 160000 service paths. I would hope that operators are prepared for= =0A= > > >>> the complexities if they choose to avoid any use of local load=0A= > > >>> balancing and in stead provision 160,000 service paths.=0A= > > >>>=0A= > > >>> Yours,=0A= > > >>> Joel=0A= > > >>>=0A= > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= > > >>>> Paul,=0A= > > >>>>=0A= > > >>>> How many path identifiers there will be for a 4 hop service chain= =0A= > with=0A= > > >>>> 20 instances at each hop?=0A= > > >>>>=0A= > > >>>> Maria=0A= > > >>>>=0A= > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn= =0A= > > >>>> (paulq)=0A= > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= > > >>>> *To:* Lucy yong=0A= > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com;=0A= > > sfc@ietf.org;=0A= > > >>>> mikebianc@aol.com=0A= > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Lucy,=0A= > > >>>>=0A= > > >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd= make=0A= > > >>>> the minor change: the path identifier can be used to derive the=0A= > > needed=0A= > > >>>> forwarding and associated transport.=0A= > > >>>>=0A= > > >>>> It is _not_ the transport, but rather is used to simply identify t= he=0A= > > >>>> service path (or graph) that packets must traverse. By having a p= ath=0A= > > >>>> identifier, the exact indirection that people seem to be asking fo= r on=0A= > > >>>> this thread can be simply be implemented. The path identifier=0A= > > provides=0A= > > >>>> nothing more than a lookup, that lookup can result in a one or mor= e=0A= > > >>>> (equal or weighted) transport next hop(s).=0A= > > >>>>=0A= > > >>>> Paul=0A= > > >>>>=0A= > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>> > wrote:=0A= > > >>>>=0A= > > >>>>=0A= > > >>>>=0A= > > >>>> Agree. The arch. doc should not mandate only use of the service=0A= > path=0A= > > >>>> identifier to drive the forwarding actions.=0A= > > >>>>=0A= > > >>>> Lucy=0A= > > >>>>=0A= > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= > > >>>> Of*mohamed.boucadair@orange.com=0A= > > =0A= > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= > > >>>> *To:*mikebianc@aol.com=0A= > > ;jmh@joelhalpern.com=0A= > > >>>> ;sfc@ietf.org =0A= > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Re-,=0A= > > >>>>=0A= > > >>>> The merged draft calls out explicitly a service path identifier. I= =0A= > > >>>> object to use that identifier to derive forwarding actions.=0A= > > >>>>=0A= > > >>>> Requiring a SFC system to have the full knowledge of every availab= le=0A= > > SFC=0A= > > >>>> forwarding paths within an SFC-enabled domain is not=0A= > > required/justified=0A= > > >>>> nor possible in various deployment contexts.=0A= > > >>>>=0A= > > >>>> SFC forwarding actions should rely on the piece of information tha= t=0A= > > will=0A= > > >>>> be present in all deployments: that is the one required to structu= re=0A= > a=0A= > > >>>> service chain. How that information is used to infer forwarding=0A= > actions=0A= > > >>>> is a solution-oriented discussion.=0A= > > >>>>=0A= > > >>>> Cheers,=0A= > > >>>>=0A= > > >>>> Med=0A= > > >>>>=0A= > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= > > de*mikebianc@aol.com=0A= > > >>>> =0A= > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= > > >>>> *=C0 :*jmh@joelhalpern.com=0A= > > ;sfc@ietf.org=0A= > > >>>> =0A= > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> Is anyone still questioning the difference between SF Chain and SF= =0A= > > Path?=0A= > > >>>> Other than clarifying the definition so that it's clear to thos= e not=0A= > > >>>> familiar with the draft, it seems that everyone agrees on these=0A= > terms.=0A= > > >>>>=0A= > > >>>> To me, the one point that is still unclear is whether it is the in= tent=0A= > > >>>> of this draft to ultimately specify what the ID of the SFC Header= =0A= > > should=0A= > > >>>> reference (the chain or the path), or if this draft simply intends= to=0A= > > >>>> leave that ambiguous, allowing other drafts to dictate the=0A= > > mechanisms=0A= > > >>>> for forwarding based on chain or path and the choice of chain or= =0A= > path=0A= > > to=0A= > > >>>> be negotiated in the control-plane.=0A= > > >>>>=0A= > > >>>> If the latter (ambiguous), then the draft would have require that= =0A= > both=0A= > > >>>> SFP and SFC be supported (or make one required and the other=0A= > > optional)=0A= > > >>>> to avoid some vendors only supporting SFP and others only=0A= > > supporting=0A= > > >>>> SFC.=0A= > > >>>>=0A= > > >>>> ------------------------------------------------------------------= ------=0A= > > >>>>=0A= > > >>>> *From:*jmh@joelhalpern.com > >>>> >=0A= > > >>>> *To:*sfc@ietf.org >=0A= > > >>>> *Sent:*Tuesday, July 8, 2014=0A= > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= > > >>>>=0A= > > >>>> I have been trying to figure out how to clearly answer a number of= =0A= > > >>>> comments that have been made about the proposed merged=0A= > > archtiecture=0A= > > >>>> draft. Assuming we can get working group agreement on the intent,= =0A= > > we=0A= > > >>>> will work to improve the wording so that readers who have not=0A= > > >>>> participated in the WG discussion will understnd it the way the=0A= > > working=0A= > > >>>> group intends.=0A= > > >>>>=0A= > > >>>> But what do we intend? I will try to explain my personal view, and= =0A= > see=0A= > > >>>> if that helps.=0A= > > >>>>=0A= > > >>>> In this regard, it is important to keep in mind that what we are= =0A= > > >>>> defining is the data plane architecture. We are not attempting to= =0A= > > >>>> define the architecture for the entire solution for service chaini= ng.=0A= > > >>>> That would encompass OSS/BSS, various control and policy=0A= > functions,=0A= > > >>>> virtual machine and image management, and many other aspects.=0A= > > >>>>=0A= > > >>>> As a result there are many things which clearly need to exist in t= he=0A= > > >>>> larger system, but which are dealt with above where we are=0A= > > functioning,=0A= > > >>>> and are not directly required by the work we are doing.=0A= > > >>>>=0A= > > >>>> In order to get to service chain vs service path, as I understand= =0A= > them,=0A= > > >>>> I need to first discuss load balancing. There are at least three= =0A= > > >>>> different ways that load balancing can and will interact with serv= ice=0A= > > >>>> chaining. There probably are more. The point of the archtiecture i= s=0A= > to=0A= > > >>>> permit all of these, but not to mandate that any particular kind b= e=0A= > > used=0A= > > >>>> in any solution.=0A= > > >>>>=0A= > > >>>> 1) Load balancing as a service provided to the end user. This is a= =0A= > > >>>> service function. It receives user packets, and modifies them (or= =0A= > marks=0A= > > >>>> them, or ...) so as to choose an end user service instance to rece= ive=0A= > > >>>> the users packet. This is an important service function to be able= to=0A= > > >>>> include in service chaining. It's behavior may affect requirements= on=0A= > > >>>> how service chaining is done. But it has very little impact on the= =0A= > > >>>> archtiecture. From an architectural pe3rspective it is simply a se= rvice=0A= > > >>>> function which may modify the underlying packet.=0A= > > >>>>=0A= > > >>>> 2) There is internal load balancing. That is, one can have what=0A= > appears=0A= > > >>>> to the service chaining architecture as a single point of contact = for a=0A= > > >>>> specific service function, but is actually delivered by a collecti= on of=0A= > > >>>> virtual or physical machines, possibly including one or several lo= ad=0A= > > >>>> balancers (for example using VRRP-like techniques to share a MAC= =0A= > > >>>> address.) mostly, this is invisible to the service chaining data p= lane=0A= > > >>>> mechanisms. It is likely that it is visible to various control=0A= > > >>>> mechanisms, such as those responsible for scale-in, scale-out, and= =0A= > vm=0A= > > >>>> instantiation. The architectural impact of permitting this is larg= ely=0A= > > >>>> that we need to be careful that our terminology does not lead=0A= > readers=0A= > > to=0A= > > >>>> think we are prohibiting it.=0A= > > >>>>=0A= > > >>>> 3) There can also be load balancing done by selecting packet paths= =0A= > for=0A= > > >>>> the service chaining that direct traffic to different places. We w= ould=0A= > > >>>> not want to require that a given service function appear at only o= ne=0A= > > >>>> place in the network.=0A= > > >>>>=0A= > > >>>> It is of course the case that these may be combined. I tend to ref= er=0A= > to=0A= > > >>>> the collection of entities that appear to service chaining as a si= ngle=0A= > > >>>> point as a cluster. Not because cluster is a good term. But becaus= e I=0A= > > >>>> do not have another one. Thus, the point of type 3 load balancing = is=0A= > > to=0A= > > >>>> direct different subsets of traffic to different singular or clust= ered=0A= > > >>>> service functions in different places in the network.=0A= > > >>>>=0A= > > >>>> Now with that said, what do I mean when I talk about service chain= =0A= > > and=0A= > > >>>> service path/ Service chain is a sequence of logical functions to = be=0A= > > >>>> applied to a subset of packets. It is equivalent of saying that so= me=0A= > > >>>> subset of traffic is to get DPI, charging, content inspection, and= =0A= > > >>>> firewall while a different subset is to go directly to the cache w= ithout=0A= > > >>>> visiting any other service functions.=0A= > > >>>>=0A= > > >>>> That is not enough information to direct the packets. A service pa= th=0A= > > >>>> is, in some fashion, a sequence of locations in the network. Those= =0A= > > >>>> locations will be singular or clustered service function delivery= =0A= > > >>>> locations. They may be addressed by IP address. They may be=0A= > > addressed=0A= > > >>>> as ports on an SFF. There are many different ways that the locatio= ns=0A= > > >>>> may be known to the service chaining infrastructure and the=0A= > > transport.=0A= > > >>>>=0A= > > >>>> >From the point of view of the work of the SFC group, we need to= =0A= > be=0A= > > >>>> able=0A= > > >>>> to talk about the high level abstraction, the service chain, which= =0A= > > >>>> drives the forwarding. And we need to talk about the actual data= =0A= > path=0A= > > >>>> packets will take in the network.=0A= > > >>>>=0A= > > >>>> Several of the comments have said "but the whole path may not be= =0A= > > known=0A= > > >>>> at the front." This architecture deals with that issue in two ways= .=0A= > > >>>> First, as noted in item (2) on load balancers above, there can be= =0A= > > >>>> decisions and behaviors which are invisible to the service chainin= g=0A= > > >>>> mechanisms (in much the same way that bridging within a LAN is=0A= > > largely=0A= > > >>>> invisible to routing between LANs.) The other provision we make is= =0A= > > that=0A= > > >>>> reclassification can be done in mid-chain when necessary. That wil= l=0A= > > >>>> direct packets to a new chain. Based on information available at t= he=0A= > > >>>> re-classification point.=0A= > > >>>>=0A= > > >>>> I hope that this helps explain what we are after. If it does, and = if=0A= > > >>>> the intent is acceptable to the working group, we can figure out= =0A= > what=0A= > > >>>> additional words are needed to convey this.=0A= > > >>>> If the working group disagree with the intent, then we will of cou= rse=0A= > > >>>> adjust to match the working group agreements.=0A= > > >>>> If this is still unclear, I am not sure what to try next.=0A= > > >>>>=0A= > > >>>> Yours,=0A= > > >>>> Joel=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= > > >> _______________________________________________=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= > > _______________________________________________=0A= > > sfc mailing list=0A= > > sfc@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Jul 10 14:54: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 626EB1B2A83 for ; Thu, 10 Jul 2014 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 9U3YwVdiqN60 for ; Thu, 10 Jul 2014 14:54:48 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B5A1B2814 for ; Thu, 10 Jul 2014 14:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405029288; x=1436565288; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CcEgdogYgCA/ccOJv0hlA7JzWwZEv9mI3WecToxhB1o=; b=NGIowrsOPfO7s5NpRcuGZUKvoAo5qseXT44mDum4PtmhddDA7TCFh7AC f5SgQxJTUm1HqKSu0v7O0OWDL+yuA/zfHtsubrkzeB7I6rsBiDZUshyZR icRWoepmJphnFItDx5+BhVkRnixCbwdXbl5K4x7BWofysMBrAowlI5x2+ o=; X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208";a="121424947" X-IPAS-Result: AqcEAA0Lv1PAqArr/2dsb2JhbABPCoNgWq5rkVggCodCAYEldYQDAQEBAQMBAQFiCQIZAgEIEQEDAQEBCh0HJwsUAwYIAgQBEggTiBMDHsYhEwSNGYFPBSY4gy2BFgWWIEaPfYt1gW9B Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 21:54:47 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 14:54:46 -0700 From: Ian Smith To: "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH/sAP//jZqZ Date: Thu, 10 Jul 2014 21:54:45 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C6A5@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <53BF0908.7030109@joelhalpern.com> In-Reply-To: <53BF0908.7030109@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DHdcyp6F6_OIaPKELftPzH-eco8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 21:54:51 -0000 Thanks.=0A= =0A= I'm relieved.=0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Thursday, July 10, 2014 5:43 PM=0A= To: Ian Smith; huang@sce.carleton.ca; sfc@ietf.org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= First, sorry, I should not have put words in your mouth. You said you=0A= disagreed.=0A= =0A= My point is that the archtiecture takes no stance on whether the right=0A= level of multiplicity at the Service path level for handling multiple=0A= instantiations is one path, O(100) paths, or O(1,000,000) paths. We=0A= each have biasis about what we think is reasonable for supporting each=0A= service combination that the operator is offering.=0A= =0A= Maria has clearly said that she wants to deploy with O(1). Fine, the=0A= archtiecture allows that. I expect that the solution will as well.=0A= =0A= You have said that you consider a much larger number of service paths=0A= for the same service chain to be reasonable. The architecture permits=0A= that. While I have biases in this regard, I hope that the architecture=0A= does not. Given the range of possible deployments, and as you alude to=0A= the potential changes in technology to support them) I hope we are=0A= allowing the range, while stillhaving a useful architecture.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 7/10/14, 5:14 PM, Ian Smith wrote:=0A= > Actually, I think I am disagreeing.=0A= >=0A= > If the possibility of medium-scale deployments (and that is what 16 milli= on flows is in my world) of service chains is preconceived as an absurd ide= a, then the architecture burdened with that preconception.=0A= >=0A= > There has to be some point of aim, some degree of aspiration to scale tha= t is appropriate for the lifespan of the architecture - you don't have to k= now what it is, but by saying that an arbitrary number is "too far", you're= creating - even if it isn't intentional - a limit that influences decision= s that have lasting impacts regarding scale-out, failure mitigation, elasti= city, address space... all kinds of things. That is a problem I'm not part= icularly eager to deal with.=0A= >=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > Sent: Thursday, July 10, 2014 5:04 PM=0A= > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org=0A= > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > Ian, I don't think you disagree with me at all in this regard.=0A= > I am not requesting the the architecture or the solution prohibit=0A= > deployments in the specific fashion.=0A= > I am objecting to Huang's reading of my note as saying that such=0A= > deployments are required they by the archtiecture.=0A= >=0A= > As I have said repeatedly, I am not trying to prohibit such things.=0A= > Whether they are a good idea or not depends upon many factors outside of= =0A= > the scope of the WG. I happen to think that they are usually a bad idea.= =0A= >=0A= > But the archtiecture si carefully avoiding attempting to know what is=0A= > and is not eployable.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= >> I disagree.=0A= >>=0A= >> We routinely have stateful devices that manage tens of millions of concu= rrent flows in both access network and data center environments today. You= can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world o= f tomorrow you are only going to have small numbers of service chains with = equally small numbers of active service paths?=0A= >>=0A= >> Your sounds too much like "no one will ever need more than 64K" for comf= ort.=0A= >>=0A= >>=0A= >> ________________________________________=0A= >> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern [jmh@joelh= alpern.com]=0A= >> Sent: Thursday, July 10, 2014 4:46 PM=0A= >> To: huang@sce.carleton.ca; sfc@ietf.org=0A= >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>=0A= >> No, it will mean that if someone tries to deploy the archtieture=0A= >> particularly badly, they will exceed the limits of their devices.=0A= >> The architecture does not require such absurd use of service paths.=0A= >> Since I can not figure out how to write architectural words to prohibit= =0A= >> it, the architecture does permit such abuse.=0A= >>=0A= >> Please do not read my saying that the archtiecture permits something as= =0A= >> saying it is either deisred or required by the work. It isn't.=0A= >>=0A= >> Yours,=0A= >> Joel=0A= >>=0A= >> On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= >>> If you need to support 100 service chains, it will mean 16,000,000=0A= >>> paths. That is larger than the routing table of a core router.=0A= >>>=0A= >>> Chang=0A= >>>=0A= >>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= >>>> The architecture allows a range of deployments, from 1 service path to= =0A= >>>> 160000 service paths. I would hope that operators are prepared for=0A= >>>> the complexities if they choose to avoid any use of local load=0A= >>>> balancing and in stead provision 160,000 service paths.=0A= >>>>=0A= >>>> Yours,=0A= >>>> Joel=0A= >>>>=0A= >>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= >>>>> Paul,=0A= >>>>>=0A= >>>>> How many path identifiers there will be for a 4 hop service chain wit= h=0A= >>>>> 20 instances at each hop?=0A= >>>>>=0A= >>>>> Maria=0A= >>>>>=0A= >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn=0A= >>>>> (paulq)=0A= >>>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= >>>>> *To:* Lucy yong=0A= >>>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org= ;=0A= >>>>> mikebianc@aol.com=0A= >>>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>=0A= >>>>> Lucy,=0A= >>>>>=0A= >>>>> Overall I concur, as you say: a path ID drives the forwarding. I=92d = make=0A= >>>>> the minor change: the path identifier can be used to derive the neede= d=0A= >>>>> forwarding and associated transport.=0A= >>>>>=0A= >>>>> It is _not_ the transport, but rather is used to simply identify the= =0A= >>>>> service path (or graph) that packets must traverse. By having a path= =0A= >>>>> identifier, the exact indirection that people seem to be asking for o= n=0A= >>>>> this thread can be simply be implemented. The path identifier provid= es=0A= >>>>> nothing more than a lookup, that lookup can result in a one or more= =0A= >>>>> (equal or weighted) transport next hop(s).=0A= >>>>>=0A= >>>>> Paul=0A= >>>>>=0A= >>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote:=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> Agree. The arch. doc should not mandate only use of the service path= =0A= >>>>> identifier to drive the forwarding actions.=0A= >>>>>=0A= >>>>> Lucy=0A= >>>>>=0A= >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= >>>>> Of*mohamed.boucadair@orange.com = =0A= >>>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= >>>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com= =0A= >>>>> ;sfc@ietf.org =0A= >>>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>=0A= >>>>> Re-,=0A= >>>>>=0A= >>>>> The merged draft calls out explicitly a service path identifier. I=0A= >>>>> object to use that identifier to derive forwarding actions.=0A= >>>>>=0A= >>>>> Requiring a SFC system to have the full knowledge of every available = SFC=0A= >>>>> forwarding paths within an SFC-enabled domain is not required/justifi= ed=0A= >>>>> nor possible in various deployment contexts.=0A= >>>>>=0A= >>>>> SFC forwarding actions should rely on the piece of information that w= ill=0A= >>>>> be present in all deployments: that is the one required to structure = a=0A= >>>>> service chain. How that information is used to infer forwarding actio= ns=0A= >>>>> is a solution-oriented discussion.=0A= >>>>>=0A= >>>>> Cheers,=0A= >>>>>=0A= >>>>> Med=0A= >>>>>=0A= >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.c= om=0A= >>>>> =0A= >>>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= >>>>> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.org= =0A= >>>>> =0A= >>>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>=0A= >>>>> Is anyone still questioning the difference between SF Chain and SF Pa= th?=0A= >>>>> Other than clarifying the definition so that it's clear to those = not=0A= >>>>> familiar with the draft, it seems that everyone agrees on these terms= .=0A= >>>>>=0A= >>>>> To me, the one point that is still unclear is whether it is the inten= t=0A= >>>>> of this draft to ultimately specify what the ID of the SFC Header sho= uld=0A= >>>>> reference (the chain or the path), or if this draft simply intends to= =0A= >>>>> leave that ambiguous, allowing other drafts to dictate the mechanisms= =0A= >>>>> for forwarding based on chain or path and the choice of chain or path= to=0A= >>>>> be negotiated in the control-plane.=0A= >>>>>=0A= >>>>> If the latter (ambiguous), then the draft would have require that bot= h=0A= >>>>> SFP and SFC be supported (or make one required and the other optional= )=0A= >>>>> to avoid some vendors only supporting SFP and others only supporting= =0A= >>>>> SFC.=0A= >>>>>=0A= >>>>> ---------------------------------------------------------------------= ---=0A= >>>>>=0A= >>>>> *From:*jmh@joelhalpern.com>>>> >=0A= >>>>> *To:*sfc@ietf.org>= =0A= >>>>> *Sent:*Tuesday, July 8, 2014=0A= >>>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>=0A= >>>>> I have been trying to figure out how to clearly answer a number of=0A= >>>>> comments that have been made about the proposed merged archtiecture= =0A= >>>>> draft. Assuming we can get working group agreement on the intent, we= =0A= >>>>> will work to improve the wording so that readers who have not=0A= >>>>> participated in the WG discussion will understnd it the way the worki= ng=0A= >>>>> group intends.=0A= >>>>>=0A= >>>>> But what do we intend? I will try to explain my personal view, and se= e=0A= >>>>> if that helps.=0A= >>>>>=0A= >>>>> In this regard, it is important to keep in mind that what we are=0A= >>>>> defining is the data plane architecture. We are not attempting to=0A= >>>>> define the architecture for the entire solution for service chaining.= =0A= >>>>> That would encompass OSS/BSS, various control and policy functions,= =0A= >>>>> virtual machine and image management, and many other aspects.=0A= >>>>>=0A= >>>>> As a result there are many things which clearly need to exist in the= =0A= >>>>> larger system, but which are dealt with above where we are functionin= g,=0A= >>>>> and are not directly required by the work we are doing.=0A= >>>>>=0A= >>>>> In order to get to service chain vs service path, as I understand the= m,=0A= >>>>> I need to first discuss load balancing. There are at least three=0A= >>>>> different ways that load balancing can and will interact with service= =0A= >>>>> chaining. There probably are more. The point of the archtiecture is t= o=0A= >>>>> permit all of these, but not to mandate that any particular kind be u= sed=0A= >>>>> in any solution.=0A= >>>>>=0A= >>>>> 1) Load balancing as a service provided to the end user. This is a=0A= >>>>> service function. It receives user packets, and modifies them (or mar= ks=0A= >>>>> them, or ...) so as to choose an end user service instance to receive= =0A= >>>>> the users packet. This is an important service function to be able to= =0A= >>>>> include in service chaining. It's behavior may affect requirements on= =0A= >>>>> how service chaining is done. But it has very little impact on the=0A= >>>>> archtiecture. From an architectural pe3rspective it is simply a servi= ce=0A= >>>>> function which may modify the underlying packet.=0A= >>>>>=0A= >>>>> 2) There is internal load balancing. That is, one can have what appea= rs=0A= >>>>> to the service chaining architecture as a single point of contact for= a=0A= >>>>> specific service function, but is actually delivered by a collection = of=0A= >>>>> virtual or physical machines, possibly including one or several load= =0A= >>>>> balancers (for example using VRRP-like techniques to share a MAC=0A= >>>>> address.) mostly, this is invisible to the service chaining data plan= e=0A= >>>>> mechanisms. It is likely that it is visible to various control=0A= >>>>> mechanisms, such as those responsible for scale-in, scale-out, and vm= =0A= >>>>> instantiation. The architectural impact of permitting this is largely= =0A= >>>>> that we need to be careful that our terminology does not lead readers= to=0A= >>>>> think we are prohibiting it.=0A= >>>>>=0A= >>>>> 3) There can also be load balancing done by selecting packet paths fo= r=0A= >>>>> the service chaining that direct traffic to different places. We woul= d=0A= >>>>> not want to require that a given service function appear at only one= =0A= >>>>> place in the network.=0A= >>>>>=0A= >>>>> It is of course the case that these may be combined. I tend to refer = to=0A= >>>>> the collection of entities that appear to service chaining as a singl= e=0A= >>>>> point as a cluster. Not because cluster is a good term. But because I= =0A= >>>>> do not have another one. Thus, the point of type 3 load balancing is = to=0A= >>>>> direct different subsets of traffic to different singular or clustere= d=0A= >>>>> service functions in different places in the network.=0A= >>>>>=0A= >>>>> Now with that said, what do I mean when I talk about service chain an= d=0A= >>>>> service path/ Service chain is a sequence of logical functions to be= =0A= >>>>> applied to a subset of packets. It is equivalent of saying that some= =0A= >>>>> subset of traffic is to get DPI, charging, content inspection, and=0A= >>>>> firewall while a different subset is to go directly to the cache with= out=0A= >>>>> visiting any other service functions.=0A= >>>>>=0A= >>>>> That is not enough information to direct the packets. A service path= =0A= >>>>> is, in some fashion, a sequence of locations in the network. Those=0A= >>>>> locations will be singular or clustered service function delivery=0A= >>>>> locations. They may be addressed by IP address. They may be addressed= =0A= >>>>> as ports on an SFF. There are many different ways that the locations= =0A= >>>>> may be known to the service chaining infrastructure and the transport= .=0A= >>>>>=0A= >>>>> >From the point of view of the work of the SFC group, we need to b= e=0A= >>>>> able=0A= >>>>> to talk about the high level abstraction, the service chain, which=0A= >>>>> drives the forwarding. And we need to talk about the actual data path= =0A= >>>>> packets will take in the network.=0A= >>>>>=0A= >>>>> Several of the comments have said "but the whole path may not be know= n=0A= >>>>> at the front." This architecture deals with that issue in two ways.= =0A= >>>>> First, as noted in item (2) on load balancers above, there can be=0A= >>>>> decisions and behaviors which are invisible to the service chaining= =0A= >>>>> mechanisms (in much the same way that bridging within a LAN is largel= y=0A= >>>>> invisible to routing between LANs.) The other provision we make is th= at=0A= >>>>> reclassification can be done in mid-chain when necessary. That will= =0A= >>>>> direct packets to a new chain. Based on information available at the= =0A= >>>>> re-classification point.=0A= >>>>>=0A= >>>>> I hope that this helps explain what we are after. If it does, and if= =0A= >>>>> the intent is acceptable to the working group, we can figure out what= =0A= >>>>> additional words are needed to convey this.=0A= >>>>> If the working group disagree with the intent, then we will of course= =0A= >>>>> adjust to match the working group agreements.=0A= >>>>> If this is still unclear, I am not sure what to try next.=0A= >>>>>=0A= >>>>> Yours,=0A= >>>>> Joel=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= >>> _______________________________________________=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= From nobody Thu Jul 10 15:11: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 986611B2807 for ; Thu, 10 Jul 2014 15:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 zgPbw4w8HXxW for ; Thu, 10 Jul 2014 15:10:54 -0700 (PDT) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DD91B27F3 for ; Thu, 10 Jul 2014 15:10:53 -0700 (PDT) Received: from mtaout-aah02.mx.aol.com (mtaout-aah02.mx.aol.com [172.27.1.142]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id E37B7700544C9; Thu, 10 Jul 2014 18:10:52 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aah02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A392E3800008D; Thu, 10 Jul 2014 18:10:52 -0400 (EDT) Date: Thu, 10 Jul 2014 18:10:49 -0400 From: "mikebianc@aol.com" To: I.Smith@F5.com, jmh.direct@joelhalpern.com, sfc@ietf.org Message-ID: <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1774_1651746847.1405030249478" X-Originating-IP: 10.181.180.81, 10.181.180.81 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405030252; bh=GoH8o+A3tj2AU07e9fexmbxhLRWlIKTwtrMDhkkKbV8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=YzVxn1NVH/o2Kw2wXjPIxDP+E9nNLU4Avu/cAFn+rglLkUn8ncKz3F9gcSEiI5ljE 82egge34T2keN0R6bxNtkWI4v63DW4w5kGoZaOmZOb363wg+xuG8ngHTZvtNHlhRMB /bS64ZayQg2+W8zqllWRChhbmUpbgbCquBQL6rsw= x-aol-sid: 3039ac1b018e53bf0f6c05a5 X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0qKUgoIqGWEvUogqqPf2HQXeewA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:11:00 -0000 X-List-Received-Date: Thu, 10 Jul 2014 22:11:00 -0000 ------=_Part_1774_1651746847.1405030249478 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't see anything in the arch draft that suggests any sort of limit. =C2= =A0However, it does seem to indicate that the entire path (all SFIs) must b= e chosen at SFC instantiation. =C2=A0I believe this means either at the cla= ssifier or maybe the classifier chooses a SF Chain and the NF or at the lat= est the first SFF. =C2=A0In any case, the language does seem to prohibit a = more dynamic SFP where SFI(n) is determined at the SFI(n-1) hop. =C2=A0Acco= rding to the draft, this behavior would be considered "branching" to a new = SFP as opposed to choosing and then forwarding to the selected instance of = the next-hop of the current SFC. draft-merged-sfc-architecture-00:> =C2=A0When an SFC is instantiated into t= he network it is necessary to > =C2=A0select the specific instances of SFs that will be used, and to crea= te > =C2=A0the service topology for that SFC using SF's network locator. =C2= =A0Thus, > =C2=A0instantiation of the SFC results in the creation of a Service > =C2=A0Function Path (SFP) and is used for forwarding packets through the > =C2=A0SFC. In other words, an SFP is the instantiation of the defined SFC= . > > =C2=A0The SFC architecture supports reclassification (or non-initial > =C2=A0classification) as well. =C2=A0As packets traverse an SFP, > =C2=A0reclassification may occur - typically performed by a classificatio= n > =C2=A0function co-resident with a service function. =C2=A0Reclassificatio= n may > =C2=A0result in the selection of a new SFP, an update of the associated > =C2=A0metadata, or both. =C2=A0This is referred to as "branching". From: I.Smith@F5.com To: Joel Halpern Direct,Joel M. Halpern,huang@sce.carleton.ca,sfc@ietf.org Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Actually, I think I am disagreeing. If the possibility of medium-scale deployments (and that is what 16 million= flows is in my world) of service chains is preconceived as an absurd idea,= then the architecture burdened with that preconception.=20 There has to be some point of aim, some degree of aspiration to scale that = is appropriate for the lifespan of the architecture - you don't have to kno= w what it is, but by saying that an arbitrary number is "too far", you're c= reating - even if it isn't intentional - a limit that influences decisions = that have lasting impacts regarding scale-out, failure mitigation, elastici= ty, address space... all kinds of things. That is a problem I'm not partic= ularly eager to deal with. ________________________________________ From: Joel Halpern Direct [jmh.direct@joelhalpern.com]Sent: Thursday, July = 10, 2014 5:04 PMTo: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@= ietf.orgSubject: Re: [sfc] Service Chains, Paths, and Load BalancersIan, I = don't think you disagree with me at all in this regard.I am not requesting = the the architecture or the solution prohibitdeployments in the specific fa= shion.I am objecting to Huang's reading of my note as saying that suchdeplo= yments are required they by the archtiecture.As I have said repeatedly, I a= m not trying to prohibit such things.Whether they are a good idea or not de= pends upon many factors outside ofthe scope of the WG. I happen to think t= hat they are usually a bad idea.But the archtiecture si carefully avoiding = attempting to know what isand is not eployable.Yours,JoelOn 7/10/14, 5:01 P= M, Ian Smith wrote:> I disagree.>> We routinely have stateful devices that = manage tens of millions of concurrent flows in both access network and data= center environments today. You can't seriously believe that in the Cloud/= IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to have small= numbers of service chains with equally small numbers of active service pat= hs?>> Your sounds too much like "no one will ever need more than 64K" for c= omfort.>>> ________________________________________> From: sfc [sfc-bounces= @ietf.org] on behalf of Joel M. Halpern [jmh@joelhalpern.com]> Sent: Thursd= ay, July 10, 2014 4:46 PM> To: huang@sce.carleton.ca; sfc@ietf.org> Subject= : Re: [sfc] Service Chains, Paths, and Load Balancers>> No, it will mean th= at if someone tries to deploy the archtieture> particularly badly, they wil= l exceed the limits of their devices.> The architecture does not require su= ch absurd use of service paths.> Since I can not figure out how to write ar= chitectural words to prohibit> it, the architecture does permit such abuse.= >> Please do not read my saying that the archtiecture permits something as>= saying it is either deisred or required by the work. It isn't.>> Yours,> = Joel>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>> If you need to suppor= t 100 service chains, it will mean 16,000,000>> paths. That is larger than = the routing table of a core router.>>>> Chang>>>> On 07/10/2014 01:15 PM, J= oel M. Halpern wrote:>>> The architecture allows a range of deployments, fr= om 1 service path to>>> 160000 service paths. I would hope that operators = are prepared for>>> the complexities if they choose to avoid any use of loc= al load>>> balancing and in stead provision 160,000 service paths.>>>>>> Yo= urs,>>> Joel>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>>>> Paul,= >>>>>>>> How many path identifiers there will be for a 4 hop service chain = with>>>> 20 instances at each hop?>>>>>>>> Maria>>>>>>>> *From:*sfc [mailto= :sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn>>>> (paulq)>>>> *Sent:* Th= ursday, July 10, 2014 3:03 PM>>>> *To:* Lucy yong>>>> *Cc:* jmh@joelhalpern= .com; mohamed.boucadair@orange.com; sfc@ietf.org;>>>> mikebianc@aol.com>>>>= *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>> Luc= y,>>>>>>>> Overall I concur, as you say: a path ID drives the forwarding. I= =E2=80=99d make>>>> the minor change: the path identifier can be used to de= rive the needed>>>> forwarding and associated transport.>>>>>>>> It is _not= _ the transport, but rather is used to simply identify the>>>> service path= (or graph) that packets must traverse. By having a path>>>> identifier, t= he exact indirection that people seem to be asking for on>>>> this thread c= an be simply be implemented. The path identifier provides>>>> nothing more= than a lookup, that lookup can result in a one or more>>>> (equal or weigh= ted) transport next hop(s).>>>>>>>> Paul>>>>>>>> On Jul 10, 2014, at 11:04 = AM, Lucy yong >>> > wrot= e:>>>>>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the = service path>>>> identifier to drive the forwarding actions.>>>>>>>> Lucy>>= >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf>>>> Of*mohamed.bo= ucadair@orange.com >>>> *Sent:*Thursda= y, July 10, 2014 2:06 AM>>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com>>>> ;sfc@ietf.org >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Ba= lancers>>>>>>>> Re-,>>>>>>>> The merged draft calls out explicitly a servic= e path identifier. I>>>> object to use that identifier to derive forwarding= actions.>>>>>>>> Requiring a SFC system to have the full knowledge of ever= y available SFC>>>> forwarding paths within an SFC-enabled domain is not re= quired/justified>>>> nor possible in various deployment contexts.>>>>>>>> S= FC forwarding actions should rely on the piece of information that will>>>>= be present in all deployments: that is the one required to structure a>>>>= service chain. How that information is used to infer forwarding actions>>>= > is a solution-oriented discussion.>>>>>>>> Cheers,>>>>>>>> Med>>>>>>>> *D= e :*sfc [mailto:sfc-bounces@ietf.org]*De la part de*mikebianc@aol.com>>>> <= mailto:mikebianc@aol.com>>>>> *Envoy=C3=A9 :*mercredi 9 juillet 2014 22:03>= >>> *=C3=80 :*jmh@joelhalpern.com ;sfc@ietf.org= >>>> >>>> *Objet :*Re: [sfc] Service Chains, Paths, an= d Load Balancers>>>>>>>> Is anyone still questioning the difference between= SF Chain and SF Path?>>>> =C2=A0=C2=A0 Other than clarifying the definitio= n so that it's clear to those not>>>> familiar with the draft, it seems tha= t everyone agrees on these terms.>>>>>>>> To me, the one point that is stil= l unclear is whether it is the intent>>>> of this draft to ultimately speci= fy what the ID of the SFC Header should>>>> reference (the chain or the pat= h), or if this draft simply intends to>>>> leave that ambiguous, allowing o= ther drafts to dictate the mechanisms>>>> for forwarding based on chain or = path and the choice of chain or path to>>>> be negotiated in the control-pl= ane.>>>>>>>> If the latter (ambiguous), then the draft would have require t= hat both>>>> SFP and SFC be supported (or make one required and the other o= ptional)>>>> to avoid some vendors only supporting SFP and others only supp= orting>>>> SFC.>>>>>>>> ---------------------------------------------------= --------------------->>>>>>>> *From:*jmh@joelhalpern.com>>> >>>>> *To:*sfc@ietf= .org>>>>> *Sent:*Tuesday,= July 8, 2014>>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers= >>>>>>>> I have been trying to figure out how to clearly answer a number of= >>>> comments that have been made about the proposed merged archtiecture>>>= > draft. Assuming we can get working group agreement on the intent, we>>>> = will work to improve the wording so that readers who have not>>>> participa= ted in the WG discussion will understnd it the way the working>>>> group in= tends.>>>>>>>> But what do we intend? I will try to explain my personal vie= w, and see>>>> if that helps.>>>>>>>> In this regard, it is important to ke= ep in mind that what we are>>>> defining is the data plane architecture. We= are not attempting to>>>> define the architecture for the entire solution = for service chaining.>>>> That would encompass OSS/BSS, various control and= policy functions,>>>> virtual machine and image management, and many other= aspects.>>>>>>>> As a result there are many things which clearly need to e= xist in the>>>> larger system, but which are dealt with above where we are = functioning,>>>> and are not directly required by the work we are doing.>>>= >>>>> In order to get to service chain vs service path, as I understand the= m,>>>> I need to first discuss load balancing. There are at least three>>>>= different ways that load balancing can and will interact with service>>>> = chaining. There probably are more. The point of the archtiecture is to>>>> = permit all of these, but not to mandate that any particular kind be used>>>= > in any solution.>>>>>>>> 1) Load balancing as a service provided to the e= nd user. This is a>>>> service function. It receives user packets, and modi= fies them (or marks>>>> them, or ...) so as to choose an end user service i= nstance to receive>>>> the users packet. This is an important service funct= ion to be able to>>>> include in service chaining. It's behavior may affect= requirements on>>>> how service chaining is done. But it has very little i= mpact on the>>>> archtiecture. From an architectural pe3rspective it is sim= ply a service>>>> function which may modify the underlying packet.>>>>>>>> = 2) There is internal load balancing. That is, one can have what appears>>>>= to the service chaining architecture as a single point of contact for a>>>= > specific service function, but is actually delivered by a collection of>>= >> virtual or physical machines, possibly including one or several load>>>>= balancers (for example using VRRP-like techniques to share a MAC>>>> addre= ss.) mostly, this is invisible to the service chaining data plane>>>> mecha= nisms. It is likely that it is visible to various control>>>> mechanisms, s= uch as those responsible for scale-in, scale-out, and vm>>>> instantiation.= The architectural impact of permitting this is largely>>>> that we need to= be careful that our terminology does not lead readers to>>>> think we are = prohibiting it.>>>>>>>> 3) There can also be load balancing done by selecti= ng packet paths for>>>> the service chaining that direct traffic to differe= nt places. We would>>>> not want to require that a given service function a= ppear at only one>>>> place in the network.>>>>>>>> It is of course the cas= e that these may be combined. I tend to refer to>>>> the collection of enti= ties that appear to service chaining as a single>>>> point as a cluster. No= t because cluster is a good term. But because I>>>> do not have another one= . Thus, the point of type 3 load balancing is to>>>> direct different subse= ts of traffic to different singular or clustered>>>> service functions in d= ifferent places in the network.>>>>>>>> Now with that said, what do I mean = when I talk about service chain and>>>> service path/ Service chain is a se= quence of logical functions to be>>>> applied to a subset of packets. It is= equivalent of saying that some>>>> subset of traffic is to get DPI, chargi= ng, content inspection, and>>>> firewall while a different subset is to go = directly to the cache without>>>> visiting any other service functions.>>>>= >>>> That is not enough information to direct the packets. A service path>>= >> is, in some fashion, a sequence of locations in the network. Those>>>> l= ocations will be singular or clustered service function delivery>>>> locati= ons. They may be addressed by IP address. They may be addressed>>>> as port= s on an SFF. There are many different ways that the locations>>>> may be kn= own to the service chaining infrastructure and the transport.>>>>>>>> =C2= =A0 >From the point of view of the work of the SFC group, we need to be>>>>= able>>>> to talk about the high level abstraction, the service chain, whic= h>>>> drives the forwarding. And we need to talk about the actual data path= >>>> packets will take in the network.>>>>>>>> Several of the comments have= said "but the whole path may not be known>>>> at the front." This architec= ture deals with that issue in two ways.>>>> First, as noted in item (2) on = load balancers above, there can be>>>> decisions and behaviors which are in= visible to the service chaining>>>> mechanisms (in much the same way that b= ridging within a LAN is largely>>>> invisible to routing between LANs.) The= other provision we make is that>>>> reclassification can be done in mid-ch= ain when necessary. That will>>>> direct packets to a new chain. Based on i= nformation available at the>>>> re-classification point.>>>>>>>> I hope tha= t this helps explain what we are after. If it does, and if>>>> the intent i= s acceptable to the working group, we can figure out what>>>> additional wo= rds are needed to convey this.>>>> If the working group disagree with the i= ntent, then we will of course>>>> adjust to match the working group agreeme= nts.>>>> If this is still unclear, I am not sure what to try next.>>>>>>>> = Yours,>>>> Joel>>>>>>>> _______________________________________________>>>>= sfc mailing list>>>> sfc@ietf.org >>>> https://www.ie= tf.org/mailman/listinfo/sfc>>>>>>>> _______________________________________= ________>>>> sfc mailing list>>>> sfc@ietf.org >>>> ht= tps://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>> _________________________= ______________________>>> sfc mailing list>>> sfc@ietf.org>>> https://www.i= etf.org/mailman/listinfo/sfc>>>>>>> _______________________________________= ________>> sfc mailing list>> sfc@ietf.org>> https://www.ietf.org/mailman/l= istinfo/sfc>>>> _______________________________________________> sfc mailin= g list> sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc>___________= ____________________________________sfc mailing listsfc@ietf.orghttps://www= .ietf.org/mailman/listinfo/sfc ------=_Part_1774_1651746847.1405030249478 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't see anything in the arch draft that suggests any sort of limit. &n= bsp;However, it does seem to indicate that the entire path (all SFIs) must = be chosen at SFC instantiation.  I believe this means either at the cl= assifier or maybe the classifier chooses a SF Chain and the NF or at the la= test the first SFF.  In any case, the language does seem to prohibit a= more dynamic SFP where SFI(n) is determined at the SFI(n-1) hop.  Acc= ording to the draft, this behavior would be considered "branching" to a new= SFP as opposed to choosing and then forwarding to the selected instance of= the next-hop of the current SFC.

draft-merged-sfc-archite= cture-00:
>  When an SFC is instantiated into the network it is = necessary to
> &n= bsp;select the specific instances of SFs that will be used, and to create
>  the servic= e topology for that SFC using SF's network locator.  Thus,
>  instantiation of the= SFC results in the creation of a Service
>  Function Path (SFP) and is used for forwar= ding packets through the
>  SFC. In other words, an SFP is the instantiation of the def= ined SFC.
>
>  The SFC archit= ecture supports reclassification (or non-initial
>  classification) as well.  As p= ackets traverse an SFP,
>  reclassification may occur - typically performed by a classi= fication
>  = function co-resident with a service function.  Reclassification may
>  result in t= he selection of a new SFP, an update of the associated
>  metadata, or both.  This= is referred to as "branching".



From: I.Smith@F5.com<I.Smith@F5.com&g= t;
To: Joel Halpern Direct<jmh.direct@joelhalpern.com>,Joel= M. Halpern<jmh@joelhalpern.com>,huang@sce.carleton.ca<huang@sce.c= arleton.ca>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, J= uly 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load B= alancers

Actually, I think I am disagreeing.

I= f the possibility of medium-scale deployments (and that is what 16 million = flows is in my world) of service chains is preconceived as an absurd idea, = then the architecture burdened with that preconception.

There has t= o be some point of aim, some degree of aspiration to scale that is appropri= ate for the lifespan of the architecture - you don't have to know what it i= s, but by saying that an arbitrary number is "too far", you're creating - e= ven if it isn't intentional - a limit that influences decisions that have l= asting impacts regarding scale-out, failure mitigation, elasticity, address= space... all kinds of things. That is a problem I'm not particularly eage= r to deal with.




________________________________________=


From: Joel Halpern Direct [jmh.direct@joelhalpern.co= m]
Sent: Thursday, July 10, 2014 5:04 PM
To: Ia= n Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Ian, I don't think you disagree with me at all in this rega= rd.
I am not requesting the the architecture or the solution = prohibit
deployments in the specific fashion.
I= am objecting to Huang's reading of my note as saying that such
deployments are required they by the archtiecture.

As I have said repeatedly, I am not trying to prohibit such things.=
Whether they are a good idea or not depends upon many factor= s outside of
the scope of the WG. I happen to think that the= y are usually a bad idea.

But the archtiecture= si carefully avoiding attempting to know what is
and is not = eployable.

Yours,
Joel

On 7/10/14, 5:01 PM, Ian Smith wrote:
&g= t; I disagree.
>
> We routinely have stat= eful devices that manage tens of millions of concurrent flows in both acces= s network and data center environments today. You can't seriously believe = that in the Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only g= oing to have small numbers of service chains with equally small numbers of = active service paths?
>
> Your sounds too= much like "no one will ever need more than 64K" for comfort.
>
>
> _______________________________= _________
> From: sfc [sfc-bounces@ietf.org] on behalf of = Joel M. Halpern [jmh@joelhalpern.com]
> Sent: Thursday, Ju= ly 10, 2014 4:46 PM
> To: huang@sce.carleton.ca; sfc@ietf.= org
> Subject: Re: [sfc] Service Chains, Paths, and Load B= alancers
>
> No, it will mean that if som= eone tries to deploy the archtieture
> particularly badly,= they will exceed the limits of their devices.
> The archi= tecture does not require such absurd use of service paths.
&g= t; Since I can not figure out how to write architectural words to prohibit<= br class=3D"">> it, the architecture does permit such abuse.
>
> Please do not read my saying that the archtiectu= re permits something as
> saying it is either deisred or r= equired by the work. It isn't.
>
> Yours= ,
> Joel
>
> On 7/10/14,= 4:36 PM, Changcheng Huang wrote:
>> If you need to sup= port 100 service chains, it will mean 16,000,000
>> pat= hs. That is larger than the routing table of a core router.
&= gt;>
>> Chang
>>
&= gt;> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:
>&g= t;> The architecture allows a range of deployments, from 1 service path = to
>>> 160000 service paths. I would hope that oper= ators are prepared for
>>> the complexities if they = choose to avoid any use of local load
>>> balancing = and in stead provision 160,000 service paths.
>>>>>> Yours,
>>> Joel
>>>
>>> On 7/10/14, 4:06 PM, NAPIERALA, = MARIA H wrote:
>>>> Paul,
>>&= gt;>
>>>> How many path identifiers there will= be for a 4 hop service chain with
>>>> 20 instan= ces at each hop?
>>>>
>>>&= gt; Maria
>>>>
>>>> *Fr= om:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn
>>>> (paulq)
>>>> *Sent:* Thursday= , July 10, 2014 3:03 PM
>>>> *To:* Lucy yong
>>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@ora= nge.com; sfc@ietf.org;
>>>> mikebianc@aol.com
>>>> *Subject:* Re: [sfc] Service Chains, Paths, and= Load Balancers
>>>>
>>>&g= t; Lucy,
>>>>
>>>> Over= all I concur, as you say: a path ID drives the forwarding. I=E2=80=99d make=
>>>> the minor change: the path identifier can b= e used to derive the needed
>>>> forwarding and a= ssociated transport.
>>>>
>>&= gt;> It is _not_ the transport, but rather is used to simply identify th= e
>>>> service path (or graph) that packets must = traverse. By having a path
>>>> identifier, the = exact indirection that people seem to be asking for on
>&g= t;>> this thread can be simply be implemented. The path identifier p= rovides
>>>> nothing more than a lookup, that loo= kup can result in a one or more
>>>> (equal or we= ighted) transport next hop(s).
>>>>
>>>> Paul
>>>>
>>= ;>> On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com<= br class=3D"">>>>> <mailto:lucy.yong@huawei.com>> wrot= e:
>>>>
>>>>
>>>>
>>>> Agree. The arch. doc = should not mandate only use of the service path
>>>&= gt; identifier to drive the forwarding actions.
>>>&= gt;
>>>> Lucy
>>>>
>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Beha= lf
>>>> Of*mohamed.boucadair@orange.com <mailt= o:mohamed.boucadair@orange.com>
>>>> *Sent:*Th= ursday, July 10, 2014 2:06 AM
>>>> *To:*mikebianc= @aol.com <mailto:mikebianc@aol.com>;jmh@joelhalpern.com
>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org <mailt= o:sfc@ietf.org>
>>>> *Subject:*Re: [sfc] Servi= ce Chains, Paths, and Load Balancers
>>>>
>>>> Re-,
>>>>
&= gt;>>> The merged draft calls out explicitly a service path identi= fier. I
>>>> object to use that identifier to der= ive forwarding actions.
>>>>
>&g= t;>> Requiring a SFC system to have the full knowledge of every avail= able SFC
>>>> forwarding paths within an SFC-enab= led domain is not required/justified
>>>> nor pos= sible in various deployment contexts.
>>>>
>>>> SFC forwarding actions should rely on the piece of= information that will
>>>> be present in all dep= loyments: that is the one required to structure a
>>>= ;> service chain. How that information is used to infer forwarding actio= ns
>>>> is a solution-oriented discussion.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>&g= t;>>
>>>> *De :*sfc [mailto:sfc-bounces@iet= f.org]*De la part de*mikebianc@aol.com
>>>> <m= ailto:mikebianc@aol.com>
>>>> *Envoy=C3=A9 :*m= ercredi 9 juillet 2014 22:03
>>>> *=C3=80 :*jmh@j= oelhalpern.com <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>>>> <mailto:sfc@ietf.org>
>>>&g= t; *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers
>>>>
>>>> Is anyone still question= ing the difference between SF Chain and SF Path?
>>>= >    Other than clarifying the definition so that it's clear t= o those not
>>>> familiar with the draft, it seem= s that everyone agrees on these terms.
>>>>
>>>> To me, the one point that is still unclear is whe= ther it is the intent
>>>> of this draft to ultim= ately specify what the ID of the SFC Header should
>>&g= t;> reference (the chain or the path), or if this draft simply intends t= o
>>>> leave that ambiguous, allowing other draft= s to dictate the mechanisms
>>>> for forwarding b= ased on chain or path and the choice of chain or path to
>= >>> be negotiated in the control-plane.
>>>= >
>>>> If the latter (ambiguous), then the dra= ft would have require that both
>>>> SFP and SFC = be supported (or make one required and the other optional)
&g= t;>>> to avoid some vendors only supporting SFP and others only su= pporting
>>>> SFC.
>>>>=
>>>> -------------------------------------------= -----------------------------
>>>>
= >>>> *From:*jmh@joelhalpern.com<jmh@joelhalpern.com
>>>> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com= >>
>>>> *To:*sfc@ietf.org<sfc@ietf.org &= lt;mailto:sfc@ietf.org%3csfc@ietf.org>>
>>>>= ; *Sent:*Tuesday, July 8, 2014
>>>> *Subject:*[sf= c] Service Chains, Paths, and Load Balancers
>>>>=
>>>> I have been trying to figure out how to cle= arly answer a number of
>>>> comments that have b= een made about the proposed merged archtiecture
>>>&= gt; draft. Assuming we can get working group agreement on the intent, we>>>> will work to improve the wording so that reade= rs who have not
>>>> participated in the WG discu= ssion will understnd it the way the working
>>>> = group intends.
>>>>
>>>>= ; But what do we intend? I will try to explain my personal view, and see>>>> if that helps.
>>>><= br class=3D"">>>>> In this regard, it is important to keep in m= ind that what we are
>>>> defining is the data pl= ane architecture. We are not attempting to
>>>> d= efine the architecture for the entire solution for service chaining.
>>>> That would encompass OSS/BSS, various control and = policy functions,
>>>> virtual machine and image = management, and many other aspects.
>>>>
>>>> As a result there are many things which clearly need= to exist in the
>>>> larger system, but which ar= e dealt with above where we are functioning,
>>>>= and are not directly required by the work we are doing.
>= >>>
>>>> In order to get to service chai= n vs service path, as I understand them,
>>>> I n= eed to first discuss load balancing. There are at least three
>>>> different ways that load balancing can and will interact = with service
>>>> chaining. There probably are mo= re. The point of the archtiecture is to
>>>> perm= it all of these, but not to mandate that any particular kind be used
>>>> in any solution.
>>>>>>>> 1) Load balancing as a service provided to the= end user. This is a
>>>> service function. It re= ceives user packets, and modifies them (or marks
>>>= > them, or ...) so as to choose an end user service instance to receive<= br class=3D"">>>>> the users packet. This is an important servi= ce function to be able to
>>>> include in service= chaining. It's behavior may affect requirements on
>>&= gt;> how service chaining is done. But it has very little impact on the<= br class=3D"">>>>> archtiecture. From an architectural pe3rspec= tive it is simply a service
>>>> function which m= ay modify the underlying packet.
>>>>
>>>> 2) There is internal load balancing. That is, one can h= ave what appears
>>>> to the service chaining arc= hitecture as a single point of contact for a
>>>>= specific service function, but is actually delivered by a collection of>>>> virtual or physical machines, possibly includi= ng one or several load
>>>> balancers (for exampl= e using VRRP-like techniques to share a MAC
>>>> = address.) mostly, this is invisible to the service chaining data plane
>>>> mechanisms. It is likely that it is visible to v= arious control
>>>> mechanisms, such as those res= ponsible for scale-in, scale-out, and vm
>>>> ins= tantiation. The architectural impact of permitting this is largely
>>>> that we need to be careful that our terminology does= not lead readers to
>>>> think we are prohibitin= g it.
>>>>
>>>> 3) Ther= e can also be load balancing done by selecting packet paths for
>>>> the service chaining that direct traffic to different p= laces. We would
>>>> not want to require that a g= iven service function appear at only one
>>>> pla= ce in the network.
>>>>
>>>= ;> It is of course the case that these may be combined. I tend to refer = to
>>>> the collection of entities that appear to= service chaining as a single
>>>> point as a clu= ster. Not because cluster is a good term. But because I
>&= gt;>> do not have another one. Thus, the point of type 3 load balanci= ng is to
>>>> direct different subsets of traffic= to different singular or clustered
>>>> service = functions in different places in the network.
>>>>= ;
>>>> Now with that said, what do I mean when I = talk about service chain and
>>>> service path/ S= ervice chain is a sequence of logical functions to be
>>= ;>> applied to a subset of packets. It is equivalent of saying that s= ome
>>>> subset of traffic is to get DPI, chargin= g, content inspection, and
>>>> firewall while a = different subset is to go directly to the cache without
>&= gt;>> visiting any other service functions.
>>>= ;>
>>>> That is not enough information to dire= ct the packets. A service path
>>>> is, in some f= ashion, a sequence of locations in the network. Those
>>= ;>> locations will be singular or clustered service function delivery=
>>>> locations. They may be addressed by IP addr= ess. They may be addressed
>>>> as ports on an SF= F. There are many different ways that the locations
>>&= gt;> may be known to the service chaining infrastructure and the transpo= rt.
>>>>
>>>>   &g= t;From the point of view of the work of the SFC group, we need to be
>>>> able
>>>> to talk about = the high level abstraction, the service chain, which
>>= >> drives the forwarding. And we need to talk about the actual data p= ath
>>>> packets will take in the network.
>>>>
>>>> Several of the comm= ents have said "but the whole path may not be known
>>&= gt;> at the front." This architecture deals with that issue in two ways.=
>>>> First, as noted in item (2) on load balance= rs above, there can be
>>>> decisions and behavio= rs which are invisible to the service chaining
>>>&g= t; mechanisms (in much the same way that bridging within a LAN is largely>>>> invisible to routing between LANs.) The other= provision we make is that
>>>> reclassification = can be done in mid-chain when necessary. That will
>>&g= t;> direct packets to a new chain. Based on information available at the=
>>>> re-classification point.
>= >>>
>>>> I hope that this helps explain = what we are after. If it does, and if
>>>> the in= tent is acceptable to the working group, we can figure out what
>>>> additional words are needed to convey this.
>>>> If the working group disagree with the intent, then we = will of course
>>>> adjust to match the working g= roup agreements.
>>>> If this is still unclear, I= am not sure what to try next.
>>>>
>>>> Yours,
>>>> Joel
= >>>>
>>>> ___________________________= ____________________
>>>> sfc mailing list
>>>> sfc@ietf.org <mailto:sfc@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _____________________= __________________________
>>>> sfc mailing list<= br class=3D"">>>>> sfc@ietf.org <mailto: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/mai= lman/listinfo/sfc
>>
>
&= gt; _______________________________________________
> sfc = mailing list
> sfc@ietf.org
> https://www= .ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mai= ling list
sfc@ietf.org
https://www.ietf.org/mai= lman/listinfo/sfc
------=_Part_1774_1651746847.1405030249478-- From nobody Thu Jul 10 15:15: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 08DDF1A0047 for ; Thu, 10 Jul 2014 15:15:46 -0700 (PDT) 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_29=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 MKC3wmHJo9Mh for ; Thu, 10 Jul 2014 15:15:44 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248AE1A0041 for ; Thu, 10 Jul 2014 15:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 98C128409D2; Thu, 10 Jul 2014 15:15:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id B22CB8409D0; Thu, 10 Jul 2014 15:15:41 -0700 (PDT) Message-ID: <53BF108D.4090509@joelhalpern.com> Date: Thu, 10 Jul 2014 18:15:41 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , I.Smith@F5.com, sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7ntq9SSv_X5r0Ob1soxmK4Waj_0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:15:46 -0000 The way the architecture models the case of SF1 needing to influence the chain is that one would do reclassification at the exit from SF1. Part of the goal is to keep the different functions logically separate so that solutions can clearly describe how they choose to compose them for "service" delivery. Yours, Joel On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > I don't see anything in the arch draft that suggests any sort of limit. > However, it does seem to indicate that the entire path (all SFIs) must > be chosen at SFC instantiation. I believe this means either at the > classifier or maybe the classifier chooses a SF Chain and the NF or at > the latest the first SFF. In any case, the language does seem to > prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1) > hop. According to the draft, this behavior would be considered > "branching" to a new SFP as opposed to choosing and then forwarding to > the selected instance of the next-hop of the current SFC. > > draft-merged-sfc-architecture-00: >> When an SFC is instantiated into the network it is necessary to > > select the specific instances of SFs that will be used, and to create > > the service topology for that SFC using SF's network locator. Thus, > > instantiation of the SFC results in the creation of a Service > > Function Path (SFP) and is used for forwarding packets through the > > SFC. In other words, an SFP is the instantiation of the defined SFC. > > > > The SFC architecture supports reclassification (or non-initial > > classification) as well. As packets traverse an SFP, > > reclassification may occur - typically performed by a classification > > function co-resident with a service function. Reclassification may > > result in the selection of a new SFP, an update of the associated > > metadata, or both. This is referred to as "branching". > > > > ------------------------------------------------------------------------ > *From: *I.Smith@F5.com > *To: *Joel Halpern Direct,Joel M. > Halpern,huang@sce.carleton.ca,sfc@ietf.org > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Actually, I think I am disagreeing. > > If the possibility of medium-scale deployments (and that is what 16 > million flows is in my world) of service chains is preconceived as an > absurd idea, then the architecture burdened with that preconception. > > There has to be some point of aim, some degree of aspiration to scale > that is appropriate for the lifespan of the architecture - you don't > have to know what it is, but by saying that an arbitrary number is "too > far", you're creating - even if it isn't intentional - a limit that > influences decisions that have lasting impacts regarding scale-out, > failure mitigation, elasticity, address space... all kinds of things. > That is a problem I'm not particularly eager to deal with. > > > > > ________________________________________ > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > Sent: Thursday, July 10, 2014 5:04 PM > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > Ian, I don't think you disagree with me at all in this regard. > I am not requesting the the architecture or the solution prohibit > deployments in the specific fashion. > I am objecting to Huang's reading of my note as saying that such > deployments are required they by the archtiecture. > > As I have said repeatedly, I am not trying to prohibit such things. > Whether they are a good idea or not depends upon many factors outside of > the scope of the WG. I happen to think that they are usually a bad idea. > > But the archtiecture si carefully avoiding attempting to know what is > and is not eployable. > > Yours, > Joel > > On 7/10/14, 5:01 PM, Ian Smith wrote: > > I disagree. > > > > We routinely have stateful devices that manage tens of millions of > concurrent flows in both access network and data center environments > today. You can't seriously believe that in the > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to > have small numbers of service chains with equally small numbers of > active service paths? > > > > Your sounds too much like "no one will ever need more than 64K" for > comfort. > > > > > > ________________________________________ > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > [jmh@joelhalpern.com] > > Sent: Thursday, July 10, 2014 4:46 PM > > To: huang@sce.carleton.ca; sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > No, it will mean that if someone tries to deploy the archtieture > > particularly badly, they will exceed the limits of their devices. > > The architecture does not require such absurd use of service paths. > > Since I can not figure out how to write architectural words to prohibit > > it, the architecture does permit such abuse. > > > > Please do not read my saying that the archtiecture permits something as > > saying it is either deisred or required by the work. It isn't. > > > > Yours, > > Joel > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> If you need to support 100 service chains, it will mean 16,000,000 > >> paths. That is larger than the routing table of a core router. > >> > >> Chang > >> > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>> The architecture allows a range of deployments, from 1 service path to > >>> 160000 service paths. I would hope that operators are prepared for > >>> the complexities if they choose to avoid any use of local load > >>> balancing and in stead provision 160,000 service paths. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>> Paul, > >>>> > >>>> How many path identifiers there will be for a 4 hop service chain with > >>>> 20 instances at each hop? > >>>> > >>>> Maria > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn > >>>> (paulq) > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > >>>> *To:* Lucy yong > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.org; > >>>> mikebianc@aol.com > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Lucy, > >>>> > >>>> Overall I concur, as you say: a path ID drives the forwarding. I’d > make > >>>> the minor change: the path identifier can be used to derive the needed > >>>> forwarding and associated transport. > >>>> > >>>> It is _not_ the transport, but rather is used to simply identify the > >>>> service path (or graph) that packets must traverse. By having a path > >>>> identifier, the exact indirection that people seem to be asking for on > >>>> this thread can be simply be implemented. The path identifier provides > >>>> nothing more than a lookup, that lookup can result in a one or more > >>>> (equal or weighted) transport next hop(s). > >>>> > >>>> Paul > >>>> > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote: > >>>> > >>>> > >>>> > >>>> Agree. The arch. doc should not mandate only use of the service path > >>>> identifier to drive the forwarding actions. > >>>> > >>>> Lucy > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>> Of*mohamed.boucadair@orange.com > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > >>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.com > >>>> ;sfc@ietf.org > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Re-, > >>>> > >>>> The merged draft calls out explicitly a service path identifier. I > >>>> object to use that identifier to derive forwarding actions. > >>>> > >>>> Requiring a SFC system to have the full knowledge of every > available SFC > >>>> forwarding paths within an SFC-enabled domain is not > required/justified > >>>> nor possible in various deployment contexts. > >>>> > >>>> SFC forwarding actions should rely on the piece of information > that will > >>>> be present in all deployments: that is the one required to structure a > >>>> service chain. How that information is used to infer forwarding > actions > >>>> is a solution-oriented discussion. > >>>> > >>>> Cheers, > >>>> > >>>> Med > >>>> > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > de*mikebianc@aol.com > >>>> > >>>> *Envoyé :*mercredi 9 juillet 2014 22:03 > >>>> *À :*jmh@joelhalpern.com ;sfc@ietf.org > >>>> > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Is anyone still questioning the difference between SF Chain and SF > Path? > >>>> Other than clarifying the definition so that it's clear to > those not > >>>> familiar with the draft, it seems that everyone agrees on these terms. > >>>> > >>>> To me, the one point that is still unclear is whether it is the intent > >>>> of this draft to ultimately specify what the ID of the SFC Header > should > >>>> reference (the chain or the path), or if this draft simply intends to > >>>> leave that ambiguous, allowing other drafts to dictate the mechanisms > >>>> for forwarding based on chain or path and the choice of chain or > path to > >>>> be negotiated in the control-plane. > >>>> > >>>> If the latter (ambiguous), then the draft would have require that both > >>>> SFP and SFC be supported (or make one required and the other optional) > >>>> to avoid some vendors only supporting SFP and others only supporting > >>>> SFC. > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> *From:*jmh@joelhalpern.com >>>> > > >>>> *To:*sfc@ietf.org> > >>>> *Sent:*Tuesday, July 8, 2014 > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> I have been trying to figure out how to clearly answer a number of > >>>> comments that have been made about the proposed merged archtiecture > >>>> draft. Assuming we can get working group agreement on the intent, we > >>>> will work to improve the wording so that readers who have not > >>>> participated in the WG discussion will understnd it the way the > working > >>>> group intends. > >>>> > >>>> But what do we intend? I will try to explain my personal view, and see > >>>> if that helps. > >>>> > >>>> In this regard, it is important to keep in mind that what we are > >>>> defining is the data plane architecture. We are not attempting to > >>>> define the architecture for the entire solution for service chaining. > >>>> That would encompass OSS/BSS, various control and policy functions, > >>>> virtual machine and image management, and many other aspects. > >>>> > >>>> As a result there are many things which clearly need to exist in the > >>>> larger system, but which are dealt with above where we are > functioning, > >>>> and are not directly required by the work we are doing. > >>>> > >>>> In order to get to service chain vs service path, as I understand > them, > >>>> I need to first discuss load balancing. There are at least three > >>>> different ways that load balancing can and will interact with service > >>>> chaining. There probably are more. The point of the archtiecture is to > >>>> permit all of these, but not to mandate that any particular kind > be used > >>>> in any solution. > >>>> > >>>> 1) Load balancing as a service provided to the end user. This is a > >>>> service function. It receives user packets, and modifies them (or > marks > >>>> them, or ...) so as to choose an end user service instance to receive > >>>> the users packet. This is an important service function to be able to > >>>> include in service chaining. It's behavior may affect requirements on > >>>> how service chaining is done. But it has very little impact on the > >>>> archtiecture. From an architectural pe3rspective it is simply a > service > >>>> function which may modify the underlying packet. > >>>> > >>>> 2) There is internal load balancing. That is, one can have what > appears > >>>> to the service chaining architecture as a single point of contact > for a > >>>> specific service function, but is actually delivered by a > collection of > >>>> virtual or physical machines, possibly including one or several load > >>>> balancers (for example using VRRP-like techniques to share a MAC > >>>> address.) mostly, this is invisible to the service chaining data plane > >>>> mechanisms. It is likely that it is visible to various control > >>>> mechanisms, such as those responsible for scale-in, scale-out, and vm > >>>> instantiation. The architectural impact of permitting this is largely > >>>> that we need to be careful that our terminology does not lead > readers to > >>>> think we are prohibiting it. > >>>> > >>>> 3) There can also be load balancing done by selecting packet paths for > >>>> the service chaining that direct traffic to different places. We would > >>>> not want to require that a given service function appear at only one > >>>> place in the network. > >>>> > >>>> It is of course the case that these may be combined. I tend to > refer to > >>>> the collection of entities that appear to service chaining as a single > >>>> point as a cluster. Not because cluster is a good term. But because I > >>>> do not have another one. Thus, the point of type 3 load balancing > is to > >>>> direct different subsets of traffic to different singular or clustered > >>>> service functions in different places in the network. > >>>> > >>>> Now with that said, what do I mean when I talk about service chain and > >>>> service path/ Service chain is a sequence of logical functions to be > >>>> applied to a subset of packets. It is equivalent of saying that some > >>>> subset of traffic is to get DPI, charging, content inspection, and > >>>> firewall while a different subset is to go directly to the cache > without > >>>> visiting any other service functions. > >>>> > >>>> That is not enough information to direct the packets. A service path > >>>> is, in some fashion, a sequence of locations in the network. Those > >>>> locations will be singular or clustered service function delivery > >>>> locations. They may be addressed by IP address. They may be addressed > >>>> as ports on an SFF. There are many different ways that the locations > >>>> may be known to the service chaining infrastructure and the transport. > >>>> > >>>> >From the point of view of the work of the SFC group, we need to be > >>>> able > >>>> to talk about the high level abstraction, the service chain, which > >>>> drives the forwarding. And we need to talk about the actual data path > >>>> packets will take in the network. > >>>> > >>>> Several of the comments have said "but the whole path may not be known > >>>> at the front." This architecture deals with that issue in two ways. > >>>> First, as noted in item (2) on load balancers above, there can be > >>>> decisions and behaviors which are invisible to the service chaining > >>>> mechanisms (in much the same way that bridging within a LAN is largely > >>>> invisible to routing between LANs.) The other provision we make is > that > >>>> reclassification can be done in mid-chain when necessary. That will > >>>> direct packets to a new chain. Based on information available at the > >>>> re-classification point. > >>>> > >>>> I hope that this helps explain what we are after. If it does, and if > >>>> the intent is acceptable to the working group, we can figure out what > >>>> additional words are needed to convey this. > >>>> If the working group disagree with the intent, then we will of course > >>>> adjust to match the working group agreements. > >>>> If this is still unclear, I am not sure what to try next. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > >> > > > > _______________________________________________ > > sfc mailing 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 Jul 10 15:16: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 5B8E61A0047 for ; Thu, 10 Jul 2014 15:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIYniHUNUpqN for ; Thu, 10 Jul 2014 15:16:21 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD1B1A0041 for ; Thu, 10 Jul 2014 15:16:20 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 5b01fb35.2ac02807f940.6370314.00-2470.17632603.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:16:21 +0000 (UTC) X-MXL-Hash: 53bf10b57ebc5c93-18daf46035688c7419e1d2c6e5272f0057a39279 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 2b01fb35.0.6370298.00-1991.17632550.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:16:19 +0000 (UTC) X-MXL-Hash: 53bf10b33889b096-e5770a848d1619ce1021871628de5fd2069703b8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMGIXi008308; Thu, 10 Jul 2014 18:16:18 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMG4LH008070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 18:16:11 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 22:15:41 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:11:49 -0400 From: "NAPIERALA, MARIA H" To: Ian Smith , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBAD//8BhIIAARgaA//++G6AACKzrAAAH3blg Date: Thu, 10 Jul 2014 22:11:49 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A89A@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=n2LCcfabAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=z9tbli-vAAAA:8 a=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=XAiyB] X-AnalysisOut: [LPX3vnN846mDJYA:9 a=wPNLvfGTeEIA:10 a=Hz7IrDYlS0cA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=3XJ037QrwtgA:10 a=chC_agHSu74A:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=U8Ie8EnqySEA:10 a=hPjdaMEvmhQA:10 a=u4WDN6HZEU] X-AnalysisOut: [9RAZOD:21 a=U6xDFbpITWpYx_C2:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ti2kFiGkKPNVpIL3mzCY923I8f0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:16:27 -0000 > > However you view it is not something that stays within a single device. >=20 > Agreed. But I'm not asserting that it does. What I am asserting is that= the > scale of what a single device can do today matters when thinking about > how to do almost exactly what that device does in a distributed manner. > Picking channelized paths through packet switched networks is making the > network stateful, so if you can, for example be stateful to the order of = 50 or > 100 million flows in an existing single node, then you should _at the ver= y > least_ expect to have 50 to 100 million flows in the distributed system t= hat > takes its place. I wonder what scale we would have achieved if we were managing TCP/IP flows= in Internet core network routers. > ________________________________________ > From: NAPIERALA, MARIA H [mn1921@att.com] > Sent: Thursday, July 10, 2014 5:44 PM > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a; > sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >=20 > For me it is a logical or virtual network over a common physical network. > However you view it is not something that stays within a single device. >=20 > > -----Original Message----- > > From: Ian Smith [mailto:I.Smith@f5.com] > > Sent: Thursday, July 10, 2014 5:38 PM > > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; > > huang@sce.carleton.ca; sfc@ietf.org > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > > > > A service path isn't a logical network; it is - quite literally - a pa= th > _though_ > > a network. > > > > > > > > ________________________________________ > > From: NAPIERALA, MARIA H [mn1921@att.com] > > Sent: Thursday, July 10, 2014 5:33 PM > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; > huang@sce.carleton.ca; > > sfc@ietf.org > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > > > > Managing millions of 5-tuple flows in a single appliance is not the sam= e as > > managing (globally) millions of service paths which are essentially log= ical > > networks. And 16 million was an arbitrary number for just 100 service > > chains. 100 service chains is very little. Image this number be two or = more > > orders of magnitude higher... > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith > > > Sent: Thursday, July 10, 2014 5:15 PM > > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca; > > > sfc@ietf.org > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > Actually, I think I am disagreeing. > > > > > > If the possibility of medium-scale deployments (and that is what 16 > > million > > > flows is in my world) of service chains is preconceived as an absurd = idea, > > > then the architecture burdened with that preconception. > > > > > > There has to be some point of aim, some degree of aspiration to scale > > that > > > is appropriate for the lifespan of the architecture - you don't have = to > > know > > > what it is, but by saying that an arbitrary number is "too far", you'= re > > > creating - even if it isn't intentional - a limit that influences dec= isions > that > > > have lasting impacts regarding scale-out, failure mitigation, elastic= ity, > > > address space... all kinds of things. That is a problem I'm not > particularly > > > eager to deal with. > > > > > > > > > > > > > > > ________________________________________ > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > > > Sent: Thursday, July 10, 2014 5:04 PM > > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > Ian, I don't think you disagree with me at all in this regard. > > > I am not requesting the the architecture or the solution prohibit > > > deployments in the specific fashion. > > > I am objecting to Huang's reading of my note as saying that such > > > deployments are required they by the archtiecture. > > > > > > As I have said repeatedly, I am not trying to prohibit such things. > > > Whether they are a good idea or not depends upon many factors > outside > > of > > > the scope of the WG. I happen to think that they are usually a bad > idea. > > > > > > But the archtiecture si carefully avoiding attempting to know what is > > > and is not eployable. > > > > > > Yours, > > > Joel > > > > > > On 7/10/14, 5:01 PM, Ian Smith wrote: > > > > I disagree. > > > > > > > > We routinely have stateful devices that manage tens of millions of > > > concurrent flows in both access network and data center environments > > > today. You can't seriously believe that in the > > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going > to > > > have small numbers of service chains with equally small numbers of > active > > > service paths? > > > > > > > > Your sounds too much like "no one will ever need more than 64K" for > > > comfort. > > > > > > > > > > > > ________________________________________ > > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > > > [jmh@joelhalpern.com] > > > > Sent: Thursday, July 10, 2014 4:46 PM > > > > To: huang@sce.carleton.ca; sfc@ietf.org > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > > > No, it will mean that if someone tries to deploy the archtieture > > > > particularly badly, they will exceed the limits of their devices. > > > > The architecture does not require such absurd use of service paths. > > > > Since I can not figure out how to write architectural words to proh= ibit > > > > it, the architecture does permit such abuse. > > > > > > > > Please do not read my saying that the archtiecture permits somethin= g > > as > > > > saying it is either deisred or required by the work. It isn't. > > > > > > > > Yours, > > > > Joel > > > > > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > > > >> If you need to support 100 service chains, it will mean 16,000,000 > > > >> paths. That is larger than the routing table of a core router. > > > >> > > > >> Chang > > > >> > > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > > > >>> The architecture allows a range of deployments, from 1 service pa= th > > to > > > >>> 160000 service paths. I would hope that operators are prepared f= or > > > >>> the complexities if they choose to avoid any use of local load > > > >>> balancing and in stead provision 160,000 service paths. > > > >>> > > > >>> Yours, > > > >>> Joel > > > >>> > > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > > > >>>> Paul, > > > >>>> > > > >>>> How many path identifiers there will be for a 4 hop service chai= n > > with > > > >>>> 20 instances at each hop? > > > >>>> > > > >>>> Maria > > > >>>> > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul > Quinn > > > >>>> (paulq) > > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > > > >>>> *To:* Lucy yong > > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; > > > sfc@ietf.org; > > > >>>> mikebianc@aol.com > > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > > >>>> > > > >>>> Lucy, > > > >>>> > > > >>>> Overall I concur, as you say: a path ID drives the forwarding. I= 'd > make > > > >>>> the minor change: the path identifier can be used to derive the > > > needed > > > >>>> forwarding and associated transport. > > > >>>> > > > >>>> It is _not_ the transport, but rather is used to simply identify= the > > > >>>> service path (or graph) that packets must traverse. By having a > path > > > >>>> identifier, the exact indirection that people seem to be asking = for > on > > > >>>> this thread can be simply be implemented. The path identifier > > > provides > > > >>>> nothing more than a lookup, that lookup can result in a one or > more > > > >>>> (equal or weighted) transport next hop(s). > > > >>>> > > > >>>> Paul > > > >>>> > > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > > >>>> > wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>> Agree. The arch. doc should not mandate only use of the service > > path > > > >>>> identifier to drive the forwarding actions. > > > >>>> > > > >>>> Lucy > > > >>>> > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > > > >>>> Of*mohamed.boucadair@orange.com > > > > > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > > > >>>> *To:*mikebianc@aol.com > > > ;jmh@joelhalpern.com > > > >>>> ;sfc@ietf.org > > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > > > >>>> > > > >>>> Re-, > > > >>>> > > > >>>> The merged draft calls out explicitly a service path identifier.= I > > > >>>> object to use that identifier to derive forwarding actions. > > > >>>> > > > >>>> Requiring a SFC system to have the full knowledge of every > available > > > SFC > > > >>>> forwarding paths within an SFC-enabled domain is not > > > required/justified > > > >>>> nor possible in various deployment contexts. > > > >>>> > > > >>>> SFC forwarding actions should rely on the piece of information > that > > > will > > > >>>> be present in all deployments: that is the one required to > structure > > a > > > >>>> service chain. How that information is used to infer forwarding > > actions > > > >>>> is a solution-oriented discussion. > > > >>>> > > > >>>> Cheers, > > > >>>> > > > >>>> Med > > > >>>> > > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > > > de*mikebianc@aol.com > > > >>>> > > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 > > > >>>> *=C0 :*jmh@joelhalpern.com > > > ;sfc@ietf.org > > > >>>> > > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > > > >>>> > > > >>>> Is anyone still questioning the difference between SF Chain and = SF > > > Path? > > > >>>> Other than clarifying the definition so that it's clear to th= ose not > > > >>>> familiar with the draft, it seems that everyone agrees on these > > terms. > > > >>>> > > > >>>> To me, the one point that is still unclear is whether it is the = intent > > > >>>> of this draft to ultimately specify what the ID of the SFC Heade= r > > > should > > > >>>> reference (the chain or the path), or if this draft simply inten= ds to > > > >>>> leave that ambiguous, allowing other drafts to dictate the > > > mechanisms > > > >>>> for forwarding based on chain or path and the choice of chain or > > path > > > to > > > >>>> be negotiated in the control-plane. > > > >>>> > > > >>>> If the latter (ambiguous), then the draft would have require tha= t > > both > > > >>>> SFP and SFC be supported (or make one required and the other > > > optional) > > > >>>> to avoid some vendors only supporting SFP and others only > > > supporting > > > >>>> SFC. > > > >>>> > > > >>>> ----------------------------------------------------------------= -------- > > > >>>> > > > >>>> *From:*jmh@joelhalpern.com > > >>>> > > > > >>>> *To:*sfc@ietf.org > > > > > >>>> *Sent:*Tuesday, July 8, 2014 > > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > > > >>>> > > > >>>> I have been trying to figure out how to clearly answer a number = of > > > >>>> comments that have been made about the proposed merged > > > archtiecture > > > >>>> draft. Assuming we can get working group agreement on the > intent, > > > we > > > >>>> will work to improve the wording so that readers who have not > > > >>>> participated in the WG discussion will understnd it the way the > > > working > > > >>>> group intends. > > > >>>> > > > >>>> But what do we intend? I will try to explain my personal view, a= nd > > see > > > >>>> if that helps. > > > >>>> > > > >>>> In this regard, it is important to keep in mind that what we are > > > >>>> defining is the data plane architecture. We are not attempting t= o > > > >>>> define the architecture for the entire solution for service chai= ning. > > > >>>> That would encompass OSS/BSS, various control and policy > > functions, > > > >>>> virtual machine and image management, and many other aspects. > > > >>>> > > > >>>> As a result there are many things which clearly need to exist in= the > > > >>>> larger system, but which are dealt with above where we are > > > functioning, > > > >>>> and are not directly required by the work we are doing. > > > >>>> > > > >>>> In order to get to service chain vs service path, as I understan= d > > them, > > > >>>> I need to first discuss load balancing. There are at least three > > > >>>> different ways that load balancing can and will interact with > service > > > >>>> chaining. There probably are more. The point of the archtiecture= is > > to > > > >>>> permit all of these, but not to mandate that any particular kind= be > > > used > > > >>>> in any solution. > > > >>>> > > > >>>> 1) Load balancing as a service provided to the end user. This is= a > > > >>>> service function. It receives user packets, and modifies them (o= r > > marks > > > >>>> them, or ...) so as to choose an end user service instance to re= ceive > > > >>>> the users packet. This is an important service function to be ab= le > to > > > >>>> include in service chaining. It's behavior may affect requiremen= ts > on > > > >>>> how service chaining is done. But it has very little impact on t= he > > > >>>> archtiecture. From an architectural pe3rspective it is simply a > service > > > >>>> function which may modify the underlying packet. > > > >>>> > > > >>>> 2) There is internal load balancing. That is, one can have what > > appears > > > >>>> to the service chaining architecture as a single point of contac= t for > a > > > >>>> specific service function, but is actually delivered by a collec= tion of > > > >>>> virtual or physical machines, possibly including one or several = load > > > >>>> balancers (for example using VRRP-like techniques to share a MAC > > > >>>> address.) mostly, this is invisible to the service chaining data= plane > > > >>>> mechanisms. It is likely that it is visible to various control > > > >>>> mechanisms, such as those responsible for scale-in, scale-out, a= nd > > vm > > > >>>> instantiation. The architectural impact of permitting this is la= rgely > > > >>>> that we need to be careful that our terminology does not lead > > readers > > > to > > > >>>> think we are prohibiting it. > > > >>>> > > > >>>> 3) There can also be load balancing done by selecting packet pat= hs > > for > > > >>>> the service chaining that direct traffic to different places. We > would > > > >>>> not want to require that a given service function appear at only > one > > > >>>> place in the network. > > > >>>> > > > >>>> It is of course the case that these may be combined. I tend to r= efer > > to > > > >>>> the collection of entities that appear to service chaining as a = single > > > >>>> point as a cluster. Not because cluster is a good term. But beca= use > I > > > >>>> do not have another one. Thus, the point of type 3 load balancin= g > is > > > to > > > >>>> direct different subsets of traffic to different singular or clu= stered > > > >>>> service functions in different places in the network. > > > >>>> > > > >>>> Now with that said, what do I mean when I talk about service > chain > > > and > > > >>>> service path/ Service chain is a sequence of logical functions t= o be > > > >>>> applied to a subset of packets. It is equivalent of saying that = some > > > >>>> subset of traffic is to get DPI, charging, content inspection, a= nd > > > >>>> firewall while a different subset is to go directly to the cache > without > > > >>>> visiting any other service functions. > > > >>>> > > > >>>> That is not enough information to direct the packets. A service > path > > > >>>> is, in some fashion, a sequence of locations in the network. Tho= se > > > >>>> locations will be singular or clustered service function deliver= y > > > >>>> locations. They may be addressed by IP address. They may be > > > addressed > > > >>>> as ports on an SFF. There are many different ways that the > locations > > > >>>> may be known to the service chaining infrastructure and the > > > transport. > > > >>>> > > > >>>> >From the point of view of the work of the SFC group, we need = to > > be > > > >>>> able > > > >>>> to talk about the high level abstraction, the service chain, whi= ch > > > >>>> drives the forwarding. And we need to talk about the actual data > > path > > > >>>> packets will take in the network. > > > >>>> > > > >>>> Several of the comments have said "but the whole path may not > be > > > known > > > >>>> at the front." This architecture deals with that issue in two wa= ys. > > > >>>> First, as noted in item (2) on load balancers above, there can b= e > > > >>>> decisions and behaviors which are invisible to the service chain= ing > > > >>>> mechanisms (in much the same way that bridging within a LAN is > > > largely > > > >>>> invisible to routing between LANs.) The other provision we make = is > > > that > > > >>>> reclassification can be done in mid-chain when necessary. That w= ill > > > >>>> direct packets to a new chain. Based on information available at > the > > > >>>> re-classification point. > > > >>>> > > > >>>> I hope that this helps explain what we are after. If it does, an= d if > > > >>>> the intent is acceptable to the working group, we can figure out > > what > > > >>>> additional words are needed to convey this. > > > >>>> If the working group disagree with the intent, then we will of > course > > > >>>> adjust to match the working group agreements. > > > >>>> If this is still unclear, I am not sure what to try next. > > > >>>> > > > >>>> Yours, > > > >>>> Joel > > > >>>> > > > >>>> _______________________________________________ > > > >>>> sfc mailing list > > > >>>> sfc@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > > >>>> > > > >>>> _______________________________________________ > > > >>>> sfc mailing list > > > >>>> sfc@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> sfc mailing list > > > >>> sfc@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/sfc > > > >>> > > > >> > > > >> _______________________________________________ > > > >> sfc mailing list > > > >> sfc@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sfc > > > >> > > > > > > > > _______________________________________________ > > > > sfc mailing 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 Jul 10 15:22: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 702211A004E for ; Thu, 10 Jul 2014 15:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 7SrQBFF3jlIB for ; Thu, 10 Jul 2014 15:22:09 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D43F1A0041 for ; Thu, 10 Jul 2014 15:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405030929; x=1436566929; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c3YF7J9tzEWSzeXonJ1FBLktd+/lEB36VBhlbTzwFV8=; b=Xa0wrXp9cCb7LKWdGRAFW1TXd4zuC7DrBWMg+oWzImXCgWlPW8LPxBMO 9nV9+Sm0mj60aQZcAgvPwhzXtVLXwjyHoSQlt3GHKoE2CggOHvvpCd9M4 YzH5rFUJb8fgH7JiDwuoJRsyIowzcLrN4Gty5qSnqc3PYH3bwjVaUa8x/ I=; X-IronPort-AV: E=Sophos;i="5.01,640,1400025600"; d="scan'208";a="121428053" X-IPAS-Result: AqgEAOsQv1PAqArr/2dsb2JhbABPCoNgWq5rkVggCodCAYEgdYQDAQEBAQIBAQEBYgkCDgcEAgEIEQEDAQEBCh0HJwsUAwYIAgQBEggTiBMDCRXGIBMEjRmBTwUmOAaDJ4EWBYoejAJGj32LdYFvQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Jul 2014 22:22:07 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 15:22:06 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH0MgP//ixO3AA7+twD//4rdBIAAfNyA//+MEhE= Date: Thu, 10 Jul 2014 22:22:06 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C74C@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A89A@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A89A@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] 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/hyYDz5eXtEI3g4_U2SfkUQ75eCo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:22:12 -0000 I'm not saying creating stateful service channels on packet networks is a g= ood thing, but it is what people are asking for, and if we are going to do = it we should do it right.=0A= =0A= If you want stateless service chains, you would do it with IP source routin= g=0A= =0A= =0A= ________________________________________=0A= From: NAPIERALA, MARIA H [mn1921@att.com]=0A= Sent: Thursday, July 10, 2014 6:11 PM=0A= To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;= sfc@ietf.org=0A= Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= > > However you view it is not something that stays within a single device.= =0A= >=0A= > Agreed. But I'm not asserting that it does. What I am asserting is that= the=0A= > scale of what a single device can do today matters when thinking about=0A= > how to do almost exactly what that device does in a distributed manner.= =0A= =0A= > Picking channelized paths through packet switched networks is making the= =0A= > network stateful, so if you can, for example be stateful to the order of = 50 or=0A= > 100 million flows in an existing single node, then you should _at the ver= y=0A= > least_ expect to have 50 to 100 million flows in the distributed system t= hat=0A= > takes its place.=0A= =0A= I wonder what scale we would have achieved if we were managing TCP/IP flows= in Internet core network routers.=0A= =0A= > ________________________________________=0A= > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > Sent: Thursday, July 10, 2014 5:44 PM=0A= > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a;=0A= > sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > For me it is a logical or virtual network over a common physical network.= =0A= > However you view it is not something that stays within a single device.= =0A= >=0A= > > -----Original Message-----=0A= > > From: Ian Smith [mailto:I.Smith@f5.com]=0A= > > Sent: Thursday, July 10, 2014 5:38 PM=0A= > > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern;=0A= > > huang@sce.carleton.ca; sfc@ietf.org=0A= > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > A service path isn't a logical network; it is - quite literally - a pa= th=0A= > _though_=0A= > > a network.=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > > Sent: Thursday, July 10, 2014 5:33 PM=0A= > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern;=0A= > huang@sce.carleton.ca;=0A= > > sfc@ietf.org=0A= > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > Managing millions of 5-tuple flows in a single appliance is not the sam= e as=0A= > > managing (globally) millions of service paths which are essentially log= ical=0A= > > networks. And 16 million was an arbitrary number for just 100 service= =0A= > > chains. 100 service chains is very little. Image this number be two or = more=0A= > > orders of magnitude higher...=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=0A= > > > Sent: Thursday, July 10, 2014 5:15 PM=0A= > > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;=0A= > > > sfc@ietf.org=0A= > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > Actually, I think I am disagreeing.=0A= > > >=0A= > > > If the possibility of medium-scale deployments (and that is what 16= =0A= > > million=0A= > > > flows is in my world) of service chains is preconceived as an absurd = idea,=0A= > > > then the architecture burdened with that preconception.=0A= > > >=0A= > > > There has to be some point of aim, some degree of aspiration to scale= =0A= > > that=0A= > > > is appropriate for the lifespan of the architecture - you don't have = to=0A= > > know=0A= > > > what it is, but by saying that an arbitrary number is "too far", you'= re=0A= > > > creating - even if it isn't intentional - a limit that influences dec= isions=0A= > that=0A= > > > have lasting impacts regarding scale-out, failure mitigation, elastic= ity,=0A= > > > address space... all kinds of things. That is a problem I'm not=0A= > particularly=0A= > > > eager to deal with.=0A= > > >=0A= > > >=0A= > > >=0A= > > >=0A= > > > ________________________________________=0A= > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > > > Sent: Thursday, July 10, 2014 5:04 PM=0A= > > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org= =0A= > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > Ian, I don't think you disagree with me at all in this regard.=0A= > > > I am not requesting the the architecture or the solution prohibit=0A= > > > deployments in the specific fashion.=0A= > > > I am objecting to Huang's reading of my note as saying that such=0A= > > > deployments are required they by the archtiecture.=0A= > > >=0A= > > > As I have said repeatedly, I am not trying to prohibit such things.= =0A= > > > Whether they are a good idea or not depends upon many factors=0A= > outside=0A= > > of=0A= > > > the scope of the WG. I happen to think that they are usually a bad= =0A= > idea.=0A= > > >=0A= > > > But the archtiecture si carefully avoiding attempting to know what is= =0A= > > > and is not eployable.=0A= > > >=0A= > > > Yours,=0A= > > > Joel=0A= > > >=0A= > > > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > > > > I disagree.=0A= > > > >=0A= > > > > We routinely have stateful devices that manage tens of millions of= =0A= > > > concurrent flows in both access network and data center environments= =0A= > > > today. You can't seriously believe that in the=0A= > > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going= =0A= > to=0A= > > > have small numbers of service chains with equally small numbers of=0A= > active=0A= > > > service paths?=0A= > > > >=0A= > > > > Your sounds too much like "no one will ever need more than 64K" for= =0A= > > > comfort.=0A= > > > >=0A= > > > >=0A= > > > > ________________________________________=0A= > > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > > > [jmh@joelhalpern.com]=0A= > > > > Sent: Thursday, July 10, 2014 4:46 PM=0A= > > > > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > >=0A= > > > > No, it will mean that if someone tries to deploy the archtieture=0A= > > > > particularly badly, they will exceed the limits of their devices.= =0A= > > > > The architecture does not require such absurd use of service paths.= =0A= > > > > Since I can not figure out how to write architectural words to proh= ibit=0A= > > > > it, the architecture does permit such abuse.=0A= > > > >=0A= > > > > Please do not read my saying that the archtiecture permits somethin= g=0A= > > as=0A= > > > > saying it is either deisred or required by the work. It isn't.=0A= > > > >=0A= > > > > Yours,=0A= > > > > Joel=0A= > > > >=0A= > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > > > >> If you need to support 100 service chains, it will mean 16,000,000= =0A= > > > >> paths. That is larger than the routing table of a core router.=0A= > > > >>=0A= > > > >> Chang=0A= > > > >>=0A= > > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= > > > >>> The architecture allows a range of deployments, from 1 service pa= th=0A= > > to=0A= > > > >>> 160000 service paths. I would hope that operators are prepared f= or=0A= > > > >>> the complexities if they choose to avoid any use of local load=0A= > > > >>> balancing and in stead provision 160,000 service paths.=0A= > > > >>>=0A= > > > >>> Yours,=0A= > > > >>> Joel=0A= > > > >>>=0A= > > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= > > > >>>> Paul,=0A= > > > >>>>=0A= > > > >>>> How many path identifiers there will be for a 4 hop service chai= n=0A= > > with=0A= > > > >>>> 20 instances at each hop?=0A= > > > >>>>=0A= > > > >>>> Maria=0A= > > > >>>>=0A= > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul=0A= > Quinn=0A= > > > >>>> (paulq)=0A= > > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= > > > >>>> *To:* Lucy yong=0A= > > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com;=0A= > > > sfc@ietf.org;=0A= > > > >>>> mikebianc@aol.com=0A= > > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers= =0A= > > > >>>>=0A= > > > >>>> Lucy,=0A= > > > >>>>=0A= > > > >>>> Overall I concur, as you say: a path ID drives the forwarding. I= 'd=0A= > make=0A= > > > >>>> the minor change: the path identifier can be used to derive the= =0A= > > > needed=0A= > > > >>>> forwarding and associated transport.=0A= > > > >>>>=0A= > > > >>>> It is _not_ the transport, but rather is used to simply identify= the=0A= > > > >>>> service path (or graph) that packets must traverse. By having a= =0A= > path=0A= > > > >>>> identifier, the exact indirection that people seem to be asking = for=0A= > on=0A= > > > >>>> this thread can be simply be implemented. The path identifier= =0A= > > > provides=0A= > > > >>>> nothing more than a lookup, that lookup can result in a one or= =0A= > more=0A= > > > >>>> (equal or weighted) transport next hop(s).=0A= > > > >>>>=0A= > > > >>>> Paul=0A= > > > >>>>=0A= > > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > > >>>> > wrote:=0A= > > > >>>>=0A= > > > >>>>=0A= > > > >>>>=0A= > > > >>>> Agree. The arch. doc should not mandate only use of the service= =0A= > > path=0A= > > > >>>> identifier to drive the forwarding actions.=0A= > > > >>>>=0A= > > > >>>> Lucy=0A= > > > >>>>=0A= > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= > > > >>>> Of*mohamed.boucadair@orange.com=0A= > > > =0A= > > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= > > > >>>> *To:*mikebianc@aol.com=0A= > > > ;jmh@joelhalpern.com=0A= > > > >>>> ;sfc@ietf.org = =0A= > > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > >>>>=0A= > > > >>>> Re-,=0A= > > > >>>>=0A= > > > >>>> The merged draft calls out explicitly a service path identifier.= I=0A= > > > >>>> object to use that identifier to derive forwarding actions.=0A= > > > >>>>=0A= > > > >>>> Requiring a SFC system to have the full knowledge of every=0A= > available=0A= > > > SFC=0A= > > > >>>> forwarding paths within an SFC-enabled domain is not=0A= > > > required/justified=0A= > > > >>>> nor possible in various deployment contexts.=0A= > > > >>>>=0A= > > > >>>> SFC forwarding actions should rely on the piece of information= =0A= > that=0A= > > > will=0A= > > > >>>> be present in all deployments: that is the one required to=0A= > structure=0A= > > a=0A= > > > >>>> service chain. How that information is used to infer forwarding= =0A= > > actions=0A= > > > >>>> is a solution-oriented discussion.=0A= > > > >>>>=0A= > > > >>>> Cheers,=0A= > > > >>>>=0A= > > > >>>> Med=0A= > > > >>>>=0A= > > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= > > > de*mikebianc@aol.com=0A= > > > >>>> =0A= > > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= > > > >>>> *=C0 :*jmh@joelhalpern.com=0A= > > > ;sfc@ietf.org=0A= > > > >>>> =0A= > > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > >>>>=0A= > > > >>>> Is anyone still questioning the difference between SF Chain and = SF=0A= > > > Path?=0A= > > > >>>> Other than clarifying the definition so that it's clear to th= ose not=0A= > > > >>>> familiar with the draft, it seems that everyone agrees on these= =0A= > > terms.=0A= > > > >>>>=0A= > > > >>>> To me, the one point that is still unclear is whether it is the = intent=0A= > > > >>>> of this draft to ultimately specify what the ID of the SFC Heade= r=0A= > > > should=0A= > > > >>>> reference (the chain or the path), or if this draft simply inten= ds to=0A= > > > >>>> leave that ambiguous, allowing other drafts to dictate the=0A= > > > mechanisms=0A= > > > >>>> for forwarding based on chain or path and the choice of chain or= =0A= > > path=0A= > > > to=0A= > > > >>>> be negotiated in the control-plane.=0A= > > > >>>>=0A= > > > >>>> If the latter (ambiguous), then the draft would have require tha= t=0A= > > both=0A= > > > >>>> SFP and SFC be supported (or make one required and the other=0A= > > > optional)=0A= > > > >>>> to avoid some vendors only supporting SFP and others only=0A= > > > supporting=0A= > > > >>>> SFC.=0A= > > > >>>>=0A= > > > >>>> ----------------------------------------------------------------= --------=0A= > > > >>>>=0A= > > > >>>> *From:*jmh@joelhalpern.com > > >>>> >=0A= > > > >>>> *To:*sfc@ietf.org > >=0A= > > > >>>> *Sent:*Tuesday, July 8, 2014=0A= > > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= > > > >>>>=0A= > > > >>>> I have been trying to figure out how to clearly answer a number = of=0A= > > > >>>> comments that have been made about the proposed merged=0A= > > > archtiecture=0A= > > > >>>> draft. Assuming we can get working group agreement on the=0A= > intent,=0A= > > > we=0A= > > > >>>> will work to improve the wording so that readers who have not=0A= > > > >>>> participated in the WG discussion will understnd it the way the= =0A= > > > working=0A= > > > >>>> group intends.=0A= > > > >>>>=0A= > > > >>>> But what do we intend? I will try to explain my personal view, a= nd=0A= > > see=0A= > > > >>>> if that helps.=0A= > > > >>>>=0A= > > > >>>> In this regard, it is important to keep in mind that what we are= =0A= > > > >>>> defining is the data plane architecture. We are not attempting t= o=0A= > > > >>>> define the architecture for the entire solution for service chai= ning.=0A= > > > >>>> That would encompass OSS/BSS, various control and policy=0A= > > functions,=0A= > > > >>>> virtual machine and image management, and many other aspects.=0A= > > > >>>>=0A= > > > >>>> As a result there are many things which clearly need to exist in= the=0A= > > > >>>> larger system, but which are dealt with above where we are=0A= > > > functioning,=0A= > > > >>>> and are not directly required by the work we are doing.=0A= > > > >>>>=0A= > > > >>>> In order to get to service chain vs service path, as I understan= d=0A= > > them,=0A= > > > >>>> I need to first discuss load balancing. There are at least three= =0A= > > > >>>> different ways that load balancing can and will interact with=0A= > service=0A= > > > >>>> chaining. There probably are more. The point of the archtiecture= is=0A= > > to=0A= > > > >>>> permit all of these, but not to mandate that any particular kind= be=0A= > > > used=0A= > > > >>>> in any solution.=0A= > > > >>>>=0A= > > > >>>> 1) Load balancing as a service provided to the end user. This is= a=0A= > > > >>>> service function. It receives user packets, and modifies them (o= r=0A= > > marks=0A= > > > >>>> them, or ...) so as to choose an end user service instance to re= ceive=0A= > > > >>>> the users packet. This is an important service function to be ab= le=0A= > to=0A= > > > >>>> include in service chaining. It's behavior may affect requiremen= ts=0A= > on=0A= > > > >>>> how service chaining is done. But it has very little impact on t= he=0A= > > > >>>> archtiecture. From an architectural pe3rspective it is simply a= =0A= > service=0A= > > > >>>> function which may modify the underlying packet.=0A= > > > >>>>=0A= > > > >>>> 2) There is internal load balancing. That is, one can have what= =0A= > > appears=0A= > > > >>>> to the service chaining architecture as a single point of contac= t for=0A= > a=0A= > > > >>>> specific service function, but is actually delivered by a collec= tion of=0A= > > > >>>> virtual or physical machines, possibly including one or several = load=0A= > > > >>>> balancers (for example using VRRP-like techniques to share a MAC= =0A= > > > >>>> address.) mostly, this is invisible to the service chaining data= plane=0A= > > > >>>> mechanisms. It is likely that it is visible to various control= =0A= > > > >>>> mechanisms, such as those responsible for scale-in, scale-out, a= nd=0A= > > vm=0A= > > > >>>> instantiation. The architectural impact of permitting this is la= rgely=0A= > > > >>>> that we need to be careful that our terminology does not lead=0A= > > readers=0A= > > > to=0A= > > > >>>> think we are prohibiting it.=0A= > > > >>>>=0A= > > > >>>> 3) There can also be load balancing done by selecting packet pat= hs=0A= > > for=0A= > > > >>>> the service chaining that direct traffic to different places. We= =0A= > would=0A= > > > >>>> not want to require that a given service function appear at only= =0A= > one=0A= > > > >>>> place in the network.=0A= > > > >>>>=0A= > > > >>>> It is of course the case that these may be combined. I tend to r= efer=0A= > > to=0A= > > > >>>> the collection of entities that appear to service chaining as a = single=0A= > > > >>>> point as a cluster. Not because cluster is a good term. But beca= use=0A= > I=0A= > > > >>>> do not have another one. Thus, the point of type 3 load balancin= g=0A= > is=0A= > > > to=0A= > > > >>>> direct different subsets of traffic to different singular or clu= stered=0A= > > > >>>> service functions in different places in the network.=0A= > > > >>>>=0A= > > > >>>> Now with that said, what do I mean when I talk about service=0A= > chain=0A= > > > and=0A= > > > >>>> service path/ Service chain is a sequence of logical functions t= o be=0A= > > > >>>> applied to a subset of packets. It is equivalent of saying that = some=0A= > > > >>>> subset of traffic is to get DPI, charging, content inspection, a= nd=0A= > > > >>>> firewall while a different subset is to go directly to the cache= =0A= > without=0A= > > > >>>> visiting any other service functions.=0A= > > > >>>>=0A= > > > >>>> That is not enough information to direct the packets. A service= =0A= > path=0A= > > > >>>> is, in some fashion, a sequence of locations in the network. Tho= se=0A= > > > >>>> locations will be singular or clustered service function deliver= y=0A= > > > >>>> locations. They may be addressed by IP address. They may be=0A= > > > addressed=0A= > > > >>>> as ports on an SFF. There are many different ways that the=0A= > locations=0A= > > > >>>> may be known to the service chaining infrastructure and the=0A= > > > transport.=0A= > > > >>>>=0A= > > > >>>> >From the point of view of the work of the SFC group, we need = to=0A= > > be=0A= > > > >>>> able=0A= > > > >>>> to talk about the high level abstraction, the service chain, whi= ch=0A= > > > >>>> drives the forwarding. And we need to talk about the actual data= =0A= > > path=0A= > > > >>>> packets will take in the network.=0A= > > > >>>>=0A= > > > >>>> Several of the comments have said "but the whole path may not=0A= > be=0A= > > > known=0A= > > > >>>> at the front." This architecture deals with that issue in two wa= ys.=0A= > > > >>>> First, as noted in item (2) on load balancers above, there can b= e=0A= > > > >>>> decisions and behaviors which are invisible to the service chain= ing=0A= > > > >>>> mechanisms (in much the same way that bridging within a LAN is= =0A= > > > largely=0A= > > > >>>> invisible to routing between LANs.) The other provision we make = is=0A= > > > that=0A= > > > >>>> reclassification can be done in mid-chain when necessary. That w= ill=0A= > > > >>>> direct packets to a new chain. Based on information available at= =0A= > the=0A= > > > >>>> re-classification point.=0A= > > > >>>>=0A= > > > >>>> I hope that this helps explain what we are after. If it does, an= d if=0A= > > > >>>> the intent is acceptable to the working group, we can figure out= =0A= > > what=0A= > > > >>>> additional words are needed to convey this.=0A= > > > >>>> If the working group disagree with the intent, then we will of= =0A= > course=0A= > > > >>>> adjust to match the working group agreements.=0A= > > > >>>> If this is still unclear, I am not sure what to try next.=0A= > > > >>>>=0A= > > > >>>> Yours,=0A= > > > >>>> Joel=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= > > > >> _______________________________________________=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= > > > _______________________________________________=0A= > > > sfc mailing list=0A= > > > sfc@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Jul 10 15:25: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 9D32E1A004E for ; Thu, 10 Jul 2014 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48G6cuxbfyjP for ; Thu, 10 Jul 2014 15:25:38 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B161A006F for ; Thu, 10 Jul 2014 15:25:36 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 0e21fb35.2b15e4a00940.8630510.00-2414.20640900.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:25:36 +0000 (UTC) X-MXL-Hash: 53bf12e02f8b5f6c-cae0a601dc76d955f6a8485e5c9b15b269fcd996 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 7d21fb35.0.8630469.00-2285.20640775.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:25:28 +0000 (UTC) X-MXL-Hash: 53bf12d8250e78d3-3173dd664dd915a19a0af97e79bf9a77117280b7 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMPQ4a014448; Thu, 10 Jul 2014 18:25:27 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMPHKA014333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 18:25:19 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 22:25:05 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:25:05 -0400 From: "NAPIERALA, MARIA H" To: Ian Smith , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBAD//8BhIIAARgaA//++G6AACKzrAAAH3blg///J6wCAAEJuUA== Date: Thu, 10 Jul 2014 22:25:05 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A8D1@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A89A@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C74C@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83C74C@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=n2LCcfabAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=z9tbli-vAAAA:8 a=3oc9M9_CAAAA:8 a=i0EeH86SAAAA:8 a=S6XvB] X-AnalysisOut: [ZzYnLKEHsKqzksA:9 a=wPNLvfGTeEIA:10 a=Hz7IrDYlS0cA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=3XJ037QrwtgA:10 a=chC_agHSu74A:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=U8Ie8EnqySEA:10 a=hPjdaMEvmhQA:10 a=NLX92qeght] X-AnalysisOut: [P0S5sP:21 a=wQ6smU69d7QpUknu:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/w8UFPEjtX5RgWYsIlZYlwMv9kg8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:25:41 -0000 =20 > I'm not saying creating stateful service channels on packet networks is a > good thing, but it is what people are asking for, and if we are going to = do it > we should do it right. Who is asking?=20 > If you want stateless service chains, you would do it with IP source rout= ing Why source routing? Is this is the only choice?=20 =20 > ________________________________________ > From: NAPIERALA, MARIA H [mn1921@att.com] > Sent: Thursday, July 10, 2014 6:11 PM > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a; > sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >=20 > > > However you view it is not something that stays within a single devic= e. > > > > Agreed. But I'm not asserting that it does. What I am asserting is th= at the > > scale of what a single device can do today matters when thinking about > > how to do almost exactly what that device does in a distributed manner. >=20 > > Picking channelized paths through packet switched networks is making > the > > network stateful, so if you can, for example be stateful to the order o= f 50 > or > > 100 million flows in an existing single node, then you should _at the v= ery > > least_ expect to have 50 to 100 million flows in the distributed system > that > > takes its place. >=20 > I wonder what scale we would have achieved if we were managing TCP/IP > flows in Internet core network routers. >=20 > > ________________________________________ > > From: NAPIERALA, MARIA H [mn1921@att.com] > > Sent: Thursday, July 10, 2014 5:44 PM > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; > huang@sce.carleton.ca; > > sfc@ietf.org > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > > > > For me it is a logical or virtual network over a common physical networ= k. > > However you view it is not something that stays within a single device. > > > > > -----Original Message----- > > > From: Ian Smith [mailto:I.Smith@f5.com] > > > Sent: Thursday, July 10, 2014 5:38 PM > > > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; > > > huang@sce.carleton.ca; sfc@ietf.org > > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > > > > > > A service path isn't a logical network; it is - quite literally - a = path > > _though_ > > > a network. > > > > > > > > > > > > ________________________________________ > > > From: NAPIERALA, MARIA H [mn1921@att.com] > > > Sent: Thursday, July 10, 2014 5:33 PM > > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; > > huang@sce.carleton.ca; > > > sfc@ietf.org > > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > > > > > > Managing millions of 5-tuple flows in a single appliance is not the s= ame > as > > > managing (globally) millions of service paths which are essentially l= ogical > > > networks. And 16 million was an arbitrary number for just 100 service > > > chains. 100 service chains is very little. Image this number be two o= r > more > > > orders of magnitude higher... > > > > > > > -----Original Message----- > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith > > > > Sent: Thursday, July 10, 2014 5:15 PM > > > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca; > > > > sfc@ietf.org > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > > > Actually, I think I am disagreeing. > > > > > > > > If the possibility of medium-scale deployments (and that is what 16 > > > million > > > > flows is in my world) of service chains is preconceived as an absur= d > idea, > > > > then the architecture burdened with that preconception. > > > > > > > > There has to be some point of aim, some degree of aspiration to sca= le > > > that > > > > is appropriate for the lifespan of the architecture - you don't hav= e to > > > know > > > > what it is, but by saying that an arbitrary number is "too far", yo= u're > > > > creating - even if it isn't intentional - a limit that influences d= ecisions > > that > > > > have lasting impacts regarding scale-out, failure mitigation, elast= icity, > > > > address space... all kinds of things. That is a problem I'm not > > particularly > > > > eager to deal with. > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > > > > Sent: Thursday, July 10, 2014 5:04 PM > > > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > > > Ian, I don't think you disagree with me at all in this regard. > > > > I am not requesting the the architecture or the solution prohibit > > > > deployments in the specific fashion. > > > > I am objecting to Huang's reading of my note as saying that such > > > > deployments are required they by the archtiecture. > > > > > > > > As I have said repeatedly, I am not trying to prohibit such things. > > > > Whether they are a good idea or not depends upon many factors > > outside > > > of > > > > the scope of the WG. I happen to think that they are usually a bad > > idea. > > > > > > > > But the archtiecture si carefully avoiding attempting to know what = is > > > > and is not eployable. > > > > > > > > Yours, > > > > Joel > > > > > > > > On 7/10/14, 5:01 PM, Ian Smith wrote: > > > > > I disagree. > > > > > > > > > > We routinely have stateful devices that manage tens of millions o= f > > > > concurrent flows in both access network and data center > environments > > > > today. You can't seriously believe that in the > > > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > going > > to > > > > have small numbers of service chains with equally small numbers of > > active > > > > service paths? > > > > > > > > > > Your sounds too much like "no one will ever need more than 64K" > for > > > > comfort. > > > > > > > > > > > > > > > ________________________________________ > > > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > > > > [jmh@joelhalpern.com] > > > > > Sent: Thursday, July 10, 2014 4:46 PM > > > > > To: huang@sce.carleton.ca; sfc@ietf.org > > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > > > > > No, it will mean that if someone tries to deploy the archtieture > > > > > particularly badly, they will exceed the limits of their devices. > > > > > The architecture does not require such absurd use of service path= s. > > > > > Since I can not figure out how to write architectural words to > prohibit > > > > > it, the architecture does permit such abuse. > > > > > > > > > > Please do not read my saying that the archtiecture permits > something > > > as > > > > > saying it is either deisred or required by the work. It isn't. > > > > > > > > > > Yours, > > > > > Joel > > > > > > > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > > > > >> If you need to support 100 service chains, it will mean 16,000,0= 00 > > > > >> paths. That is larger than the routing table of a core router. > > > > >> > > > > >> Chang > > > > >> > > > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > > > > >>> The architecture allows a range of deployments, from 1 service > path > > > to > > > > >>> 160000 service paths. I would hope that operators are prepared > for > > > > >>> the complexities if they choose to avoid any use of local load > > > > >>> balancing and in stead provision 160,000 service paths. > > > > >>> > > > > >>> Yours, > > > > >>> Joel > > > > >>> > > > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > > > > >>>> Paul, > > > > >>>> > > > > >>>> How many path identifiers there will be for a 4 hop service ch= ain > > > with > > > > >>>> 20 instances at each hop? > > > > >>>> > > > > >>>> Maria > > > > >>>> > > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul > > Quinn > > > > >>>> (paulq) > > > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > > > > >>>> *To:* Lucy yong > > > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; > > > > sfc@ietf.org; > > > > >>>> mikebianc@aol.com > > > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > > > >>>> > > > > >>>> Lucy, > > > > >>>> > > > > >>>> Overall I concur, as you say: a path ID drives the forwarding.= I'd > > make > > > > >>>> the minor change: the path identifier can be used to derive th= e > > > > needed > > > > >>>> forwarding and associated transport. > > > > >>>> > > > > >>>> It is _not_ the transport, but rather is used to simply identi= fy the > > > > >>>> service path (or graph) that packets must traverse. By having= a > > path > > > > >>>> identifier, the exact indirection that people seem to be askin= g for > > on > > > > >>>> this thread can be simply be implemented. The path identifier > > > > provides > > > > >>>> nothing more than a lookup, that lookup can result in a one or > > more > > > > >>>> (equal or weighted) transport next hop(s). > > > > >>>> > > > > >>>> Paul > > > > >>>> > > > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > > > >>>> > wrote: > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Agree. The arch. doc should not mandate only use of the servic= e > > > path > > > > >>>> identifier to drive the forwarding actions. > > > > >>>> > > > > >>>> Lucy > > > > >>>> > > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > > > > >>>> Of*mohamed.boucadair@orange.com > > > > > > > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > > > > >>>> *To:*mikebianc@aol.com > > > > ;jmh@joelhalpern.com > > > > >>>> ;sfc@ietf.org > > > > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > > > > >>>> > > > > >>>> Re-, > > > > >>>> > > > > >>>> The merged draft calls out explicitly a service path identifie= r. I > > > > >>>> object to use that identifier to derive forwarding actions. > > > > >>>> > > > > >>>> Requiring a SFC system to have the full knowledge of every > > available > > > > SFC > > > > >>>> forwarding paths within an SFC-enabled domain is not > > > > required/justified > > > > >>>> nor possible in various deployment contexts. > > > > >>>> > > > > >>>> SFC forwarding actions should rely on the piece of information > > that > > > > will > > > > >>>> be present in all deployments: that is the one required to > > structure > > > a > > > > >>>> service chain. How that information is used to infer forwardin= g > > > actions > > > > >>>> is a solution-oriented discussion. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> > > > > >>>> Med > > > > >>>> > > > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > > > > de*mikebianc@aol.com > > > > >>>> > > > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 > > > > >>>> *=C0 :*jmh@joelhalpern.com > > > > ;sfc@ietf.org > > > > >>>> > > > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > > > > >>>> > > > > >>>> Is anyone still questioning the difference between SF Chain an= d > SF > > > > Path? > > > > >>>> Other than clarifying the definition so that it's clear to = those > not > > > > >>>> familiar with the draft, it seems that everyone agrees on thes= e > > > terms. > > > > >>>> > > > > >>>> To me, the one point that is still unclear is whether it is th= e > intent > > > > >>>> of this draft to ultimately specify what the ID of the SFC Hea= der > > > > should > > > > >>>> reference (the chain or the path), or if this draft simply int= ends > to > > > > >>>> leave that ambiguous, allowing other drafts to dictate the > > > > mechanisms > > > > >>>> for forwarding based on chain or path and the choice of chain = or > > > path > > > > to > > > > >>>> be negotiated in the control-plane. > > > > >>>> > > > > >>>> If the latter (ambiguous), then the draft would have require t= hat > > > both > > > > >>>> SFP and SFC be supported (or make one required and the other > > > > optional) > > > > >>>> to avoid some vendors only supporting SFP and others only > > > > supporting > > > > >>>> SFC. > > > > >>>> > > > > >>>> --------------------------------------------------------------= ---------- > > > > >>>> > > > > >>>> *From:*jmh@joelhalpern.com > > > >>>> > > > > > >>>> *To:*sfc@ietf.org > > > > > > > >>>> *Sent:*Tuesday, July 8, 2014 > > > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > > > > >>>> > > > > >>>> I have been trying to figure out how to clearly answer a numbe= r > of > > > > >>>> comments that have been made about the proposed merged > > > > archtiecture > > > > >>>> draft. Assuming we can get working group agreement on the > > intent, > > > > we > > > > >>>> will work to improve the wording so that readers who have not > > > > >>>> participated in the WG discussion will understnd it the way th= e > > > > working > > > > >>>> group intends. > > > > >>>> > > > > >>>> But what do we intend? I will try to explain my personal view, > and > > > see > > > > >>>> if that helps. > > > > >>>> > > > > >>>> In this regard, it is important to keep in mind that what we a= re > > > > >>>> defining is the data plane architecture. We are not attempting= to > > > > >>>> define the architecture for the entire solution for service > chaining. > > > > >>>> That would encompass OSS/BSS, various control and policy > > > functions, > > > > >>>> virtual machine and image management, and many other > aspects. > > > > >>>> > > > > >>>> As a result there are many things which clearly need to exist = in > the > > > > >>>> larger system, but which are dealt with above where we are > > > > functioning, > > > > >>>> and are not directly required by the work we are doing. > > > > >>>> > > > > >>>> In order to get to service chain vs service path, as I underst= and > > > them, > > > > >>>> I need to first discuss load balancing. There are at least thr= ee > > > > >>>> different ways that load balancing can and will interact with > > service > > > > >>>> chaining. There probably are more. The point of the archtiectu= re > is > > > to > > > > >>>> permit all of these, but not to mandate that any particular ki= nd > be > > > > used > > > > >>>> in any solution. > > > > >>>> > > > > >>>> 1) Load balancing as a service provided to the end user. This = is a > > > > >>>> service function. It receives user packets, and modifies them = (or > > > marks > > > > >>>> them, or ...) so as to choose an end user service instance to > receive > > > > >>>> the users packet. This is an important service function to be = able > > to > > > > >>>> include in service chaining. It's behavior may affect requirem= ents > > on > > > > >>>> how service chaining is done. But it has very little impact on= the > > > > >>>> archtiecture. From an architectural pe3rspective it is simply = a > > service > > > > >>>> function which may modify the underlying packet. > > > > >>>> > > > > >>>> 2) There is internal load balancing. That is, one can have wha= t > > > appears > > > > >>>> to the service chaining architecture as a single point of cont= act > for > > a > > > > >>>> specific service function, but is actually delivered by a coll= ection > of > > > > >>>> virtual or physical machines, possibly including one or severa= l > load > > > > >>>> balancers (for example using VRRP-like techniques to share a > MAC > > > > >>>> address.) mostly, this is invisible to the service chaining da= ta > plane > > > > >>>> mechanisms. It is likely that it is visible to various control > > > > >>>> mechanisms, such as those responsible for scale-in, scale-out, > and > > > vm > > > > >>>> instantiation. The architectural impact of permitting this is > largely > > > > >>>> that we need to be careful that our terminology does not lead > > > readers > > > > to > > > > >>>> think we are prohibiting it. > > > > >>>> > > > > >>>> 3) There can also be load balancing done by selecting packet > paths > > > for > > > > >>>> the service chaining that direct traffic to different places. = We > > would > > > > >>>> not want to require that a given service function appear at on= ly > > one > > > > >>>> place in the network. > > > > >>>> > > > > >>>> It is of course the case that these may be combined. I tend to > refer > > > to > > > > >>>> the collection of entities that appear to service chaining as = a > single > > > > >>>> point as a cluster. Not because cluster is a good term. But > because > > I > > > > >>>> do not have another one. Thus, the point of type 3 load > balancing > > is > > > > to > > > > >>>> direct different subsets of traffic to different singular or c= lustered > > > > >>>> service functions in different places in the network. > > > > >>>> > > > > >>>> Now with that said, what do I mean when I talk about service > > chain > > > > and > > > > >>>> service path/ Service chain is a sequence of logical functions= to > be > > > > >>>> applied to a subset of packets. It is equivalent of saying tha= t > some > > > > >>>> subset of traffic is to get DPI, charging, content inspection,= and > > > > >>>> firewall while a different subset is to go directly to the cac= he > > without > > > > >>>> visiting any other service functions. > > > > >>>> > > > > >>>> That is not enough information to direct the packets. A servic= e > > path > > > > >>>> is, in some fashion, a sequence of locations in the network. > Those > > > > >>>> locations will be singular or clustered service function deliv= ery > > > > >>>> locations. They may be addressed by IP address. They may be > > > > addressed > > > > >>>> as ports on an SFF. There are many different ways that the > > locations > > > > >>>> may be known to the service chaining infrastructure and the > > > > transport. > > > > >>>> > > > > >>>> >From the point of view of the work of the SFC group, we nee= d > to > > > be > > > > >>>> able > > > > >>>> to talk about the high level abstraction, the service chain, w= hich > > > > >>>> drives the forwarding. And we need to talk about the actual da= ta > > > path > > > > >>>> packets will take in the network. > > > > >>>> > > > > >>>> Several of the comments have said "but the whole path may not > > be > > > > known > > > > >>>> at the front." This architecture deals with that issue in two = ways. > > > > >>>> First, as noted in item (2) on load balancers above, there can= be > > > > >>>> decisions and behaviors which are invisible to the service > chaining > > > > >>>> mechanisms (in much the same way that bridging within a LAN is > > > > largely > > > > >>>> invisible to routing between LANs.) The other provision we mak= e > is > > > > that > > > > >>>> reclassification can be done in mid-chain when necessary. That > will > > > > >>>> direct packets to a new chain. Based on information available = at > > the > > > > >>>> re-classification point. > > > > >>>> > > > > >>>> I hope that this helps explain what we are after. If it does, = and if > > > > >>>> the intent is acceptable to the working group, we can figure o= ut > > > what > > > > >>>> additional words are needed to convey this. > > > > >>>> If the working group disagree with the intent, then we will of > > course > > > > >>>> adjust to match the working group agreements. > > > > >>>> If this is still unclear, I am not sure what to try next. > > > > >>>> > > > > >>>> Yours, > > > > >>>> Joel > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> sfc mailing list > > > > >>>> sfc@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> sfc mailing list > > > > >>>> sfc@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > > > >>>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> sfc mailing list > > > > >>> sfc@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/sfc > > > > >>> > > > > >> > > > > >> _______________________________________________ > > > > >> sfc mailing list > > > > >> sfc@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/sfc > > > > >> > > > > > > > > > > _______________________________________________ > > > > > sfc mailing 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 Jul 10 15:33: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 6EEF41A006D for ; Thu, 10 Jul 2014 15:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.051 X-Spam-Level: X-Spam-Status: No, score=-7.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 GqgAl1kHQ44q for ; Thu, 10 Jul 2014 15:33:14 -0700 (PDT) Received: from mxebdp03ex-public.idz.gs.com (mxe6.gs.com [207.17.33.102]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467481A004E for ; Thu, 10 Jul 2014 15:33:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,640,1400040000"; d="scan'208";a="126176972" Received: from unknown (HELO mxpbd02-public.ny.fw.gs.com) ([148.86.115.129]) by mxebdp03ex.idz.gs.com with ESMTP; 10 Jul 2014 18:33:13 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp15ex.firmwide.corp.gs.com ([10.135.172.24]) by mxpbd02.ny.fw.gs.com with ESMTP; 10 Jul 2014 18:33:12 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp15ex.firmwide.corp.gs.com ([10.135.172.24]) with mapi; Thu, 10 Jul 2014 18:33:12 -0400 To: "'mikebianc@aol.com'" , "'jmh@joelhalpern.com'" , "'paulq@cisco.com'" Date: Thu, 10 Jul 2014 18:33:12 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: Ac+cfxW6WxPM4mwGRUiKl2OnoKpFqgAD9ix2 Message-ID: In-Reply-To: <1916079416.1585.1405024782482.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-wiganss: 01000000010020gshcbdp15ex.firmwide.corp.gs.com ID004D x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708E0030AGSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eqOxNla8Qd1bR2vqk7MS_F7iByU Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:33:17 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708E0030AGSCMAMP19EXfi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBicm91Z2h0IHVwIEdTTEIgb25seSB0byBpbGx1c3RyYXRlIHRoYXQgbmV4dC1ob3Agc2VsZWN0 aW9uIGNhbiBiZSBkb25lIGluIHNvbWUgb3RoZXIgd2F5LiBCdXQgSSB0aGluayB5b3UgZ2V0IG15 IHBvaW50Lg0KDQpUbyBtZSwgInRyYWZmaWMgZGlzdHJpYnV0aW9uIiBpcyBhbiBpbXByb3ZlbWVu dCBvdmVyICJsb2FkIGRpc3RyaWJ1dGlvbiIgb25seSBiZWNhdXNlIGl0J3Mgbm90IHRvbyBjbG9z ZSB0byBsb2FkIGJhbGFuY2luZy4gQnV0IEknbSBub3Qgd2VkZGVkIHRvIGl0LiBJJ2xsIGJlIGZp bmUgd2l0aCBhbnkgdGVybSB0aGF0IGlzIGxlc3MgbG9hZGVkIGFuZCBsZXNzIGxpa2VseSB0byBj YXVzZSBjb25mdXNpb24uDQoNCk15bw0KDQoNCg0KRnJvbTogbWlrZWJpYW5jQGFvbC5jb20gW21h aWx0bzptaWtlYmlhbmNAYW9sLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDA0 OjM5IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFphcm55LCBNeW8gW1RlY2hdOyBqbWhA am9lbGhhbHBlcm4uY29tIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgcGF1bHFAY2lzY28uY29tIDxw YXVscUBjaXNjby5jb20+DQpDYzogc2ZjQGlldGYub3JnIDxzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0K QWdyZWUgdGhhdCBtYXliZSAnbG9hZCBkaXN0cmlidXRpb24nIGlzbid0IHRoZSBiZXN0IG5hbWUu ICBXaGF0IGlzIGltcG9ydGFudCBpcyB0aGF0IGl0IGlzIGRpc3Rpbmd1aXNoZWQgZnJvbSBsb2Fk IGJhbGFuY2luZyAod2hpY2ggaXMgYWxzbyBhIHBvb3IgbmFtZSkuDQoNCk1heWJlICJUcmFmZmlj IERpc3RyaWJ1dGlvbicgb3IgJ1RyYWZmaWMgQmFsYW5jaW5nJyBvciBkbyB0aG9zZSBuYW1lcyBh bHJlYWR5IGNhcnJ5IG90aGVyIHNpZ25pZmljYW5jZT8NCg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogTXlvLlphcm55QGdzLmNvbTxNeW8uWmFybnlAZ3Mu Y29tPg0KVG86ICdqbWhAam9lbGhhbHBlcm4uY29tJzxqbWhAam9lbGhhbHBlcm4uY29tPiwnbWlr ZWJpYW5jQGFvbC5jb20nPG1pa2ViaWFuY0Bhb2wuY29tPiwncGF1bHFAY2lzY28uY29tJzxwYXVs cUBjaXNjby5jb20+DQpjYzogJ3NmY0BpZXRmLm9yZyc8c2ZjQGlldGYub3JnPg0KU2VudDogVGh1 cnNkYXksIEp1bHkgMTAsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpVc2luZyB0aGUgdGVybSBsb2FkIGRpc3RyaWJ1 dGlvbiB0byByZWZlciB0byBsb2FkIGJhbGFuY2VyIHNlbGVjdGlvbiB3aWxsIGJlIGxvc3QgdG8g YSBsb3Qgb2YgcGVvcGxlLiBNYW55IHBlb3BsZSBjYWxsIGl0IGdsb2JhbCBzZXZlciBsb2FkIGJh bGFuY2luZy4NCg0KUGx1cywgdGhlcmUgY291bGQgYmUgbXVsdGlwbGUgbGF5ZXJzIG9mICJsb2Fk IGRpc3RyaWJ1dGlvbiIgLyBMQiBzZWxlY3Rpb24uIE5vdCBqdXN0IHR3by4gRm9yIGV4YW1wbGUs IHNlbGVjdCBhIHJlZ2lvbiBmcm9tIGEgZ2xvYmFsIHBvb2w7IG9uY2UgdGhlIHJlZ2lvbiBpcyBz ZWxlY3RlZCwgc2VsZWN0IGEgZGF0YSBjZW50ZXIgaW4gdGhhdCByZWdpb247IGluIHRoYXQgREMs IHdoaWNoIERDIExCIGluc3RhbmNlIHRvIGdvIHRvOyBhbmQgdGhlbiB3ZSBoYXZlIHRoZSB0cmFk aXRpb25hbCBMQiB3aGljaCBzZWxlY3RzIHRoZSBlbmQgc2VydmVyLg0KDQpJbiBzdW0sICgxKSBw YXRoIHNlbGVjdGlvbiBjb3VsZCBoYXBwZW4gYXQgbW9yZSB0aGFuIDIgZGlmZmVyZW50IHRpZXJz OyAoMikgImxvYWQiIGlzbid0IHRoZSBvbmx5IGNyaXRlcmlvbiBpbiB0aG9zZSBzZWxlY3Rpb25z LiBJIHNlZSB0aGUgcmF0aW9uYWxlIGZvciB3YW50aW5nIHRoZSBkaWZmZXJlbnRpYXRpb24gYnV0 IGlzIGxvYWQgZGlzdHJpYnV0aW9uIHRoZSBiZXN0IHRlcm0gZm9yIGl0Pw0KDQpSZWdhcmRzLA0K DQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KDQoNCkZyb206IEpvZWwgTS4gSGFs cGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAx MCwgMjAxNCAwMzowMSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBtaWtlYmlhbmNAYW9s LmNvbSA8bWlrZWJpYW5jQGFvbC5jb20+OyBwYXVscUBjaXNjby5jb20gPHBhdWxxQGNpc2NvLmNv bT4NCkNjOiBzZmNAaWV0Zi5vcmcgPHNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpUaGUgdGVybSAibG9h ZCBkaXN0cmlidXRpb24iIHdvcmtzIGZvciBtZS4gSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIHZhbHVl DQppbiBkaWZmZXJlbnRpYXRpbmcgdGhlIGZ1bmN0aW9ucywgYW5kIHVzaW5nIGRpZmZlcmVudCB3 b3JkcyB1c3VhbGx5DQpoZWxwcyBzdWNoIGRpZmZlcmVudGlhdGlvbi4NCg0KWW91cnMsDQpKb2Vs DQoNCk9uIDcvMTAvMTQsIDI6NTUgUE0sIG1pa2ViaWFuY0Bhb2wuY29tIHdyb3RlOg0KPiBJJ3Zl IHN0YXRlZCBiZWZvcmUgdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gbG9hZA0KPiBiYWxhbmNpbmcgYW5kIGxvYWQgZGlzdHJpYnV0aW9uIHdoZXJlIGxvYWQgYmFs YW5jaW5nIHJlZmVycyB0byB0aGUNCj4gc3RhbmRhcmQgc2VydmljZSBmdW5jdGlvbiB0aGF0IHdl IGFsbCBrbm93IGFuZCBsb3ZlIChvdXRzaWRlIG9mIFNGQykgYW5kDQo+IGxvYWQgZGlzdHJpYnV0 aW9uIHJlZmVycyB0byB0aGUgc2VsZWN0aW9uIG9mIGFuIFNGSSAoaS5lLiBDaGFpbiAtPiBQYXRo DQo+IG1hcHBpbmcpLiBOb3QgdXNpbmcgZGlmZmVyZW50IHRlcm1zIHRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gdGhlc2UgbGVhZHMNCj4gdG8gY29uZnVzaW9uLg0KPg0KPiBlLmcuIGEgU0YgQ2hhaW4q IG1pZ2h0IGV4aXN0IHdob3NlIFNGcyBjb25zaXN0IG9ubHkgb2YgbG9hZCBiYWxhbmNlcnMuDQo+ ICAgQnV0IHlvdSBtaWdodCBzdGlsbCB3YW50IFNGQyogdG8gZGlzdHJpYnV0ZSBsb2FkIHRvIG11 bHRpcGxlIGxvYWQNCj4gYmFsYW5jZXIgaW5zdGFuY2VzLg0KPg0KPiAqdHJ5aW5nIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gU0ZDIGFzICJTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIiBhbmQgYQ0K PiBzaW5nbGUgIlNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4iLg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gKkZyb206ICpwYXVscUBjaXNjby5jb208cGF1bHFAY2lzY28u Y29tPg0KPiAqVG86ICpKb2VsIE0uIEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gKmNj OiAqSmltIEd1aWNoYXJkDQo+IChqZ3VpY2hhcik8amd1aWNoYXJAY2lzY28uY29tPixzZmNAaWV0 Zi5vcmc8c2ZjQGlldGYub3JnPixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+LFJvbg0KPiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbT4sTkFQSUVSQUxBLCBNQVJJQSBIPG1uMTkyMUBhdHQuY29tPg0KPiAqU2VudDog KlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+DQo+IEpvZWwsDQo+DQo+IEkgY29u Y3VyLiBUaGUgZ29hbCBoZXJlIGlzIHRvIGFkZHJlc3MgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdp dGggZ2VuZXJpYw0KPiBzZXJ2aWNlIGZ1bmN0aW9uIGRlcGxveW1lbnQgYW5kIHNob3VsZCBlbmFi bGUgbG9jYWxpemVkIGRlY2lzaW9ucyBzdWNoDQo+IGFzIGxvYWQgYmFsYW5jaW5nIChwZXJoYXBz IG1vcmUgYWNjdXJhdGVseSBsb2FkIGRpc3RyaWJ1dGlvbikuIENsZWFybHkNCj4gd2Ugc291bmTi gJl0IGNvZGlmeSBob3cgbG9hZCBkaXN0cmlidXRpb24gd29ya3MuDQo+DQo+IEluIG9yZGVyIHRv IGVuYWJsZSBsb2FkIGRpc3RyaWJ1dGlvbiwgZm9yIGV4YW1wbGUsIHRoZSByaWdodA0KPiBhYnN0 cmFjdGlvbnMgYmVlbiB0byBiZSBjbGVhcmx5IGRlZmluZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSwg YSBrZXkgb25lDQo+IGJlcmluZyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwYXRoIHZzLiBjaGFp bi4NCj4NCj4gUGF1bA0KPg0KPg0KPg0KPiBPbiBKdWwgMTAsIDIwMTQsIGF0IDEyOjA4IFBNLCBK b2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPg0KPiA+IFRoYXQg aXMgY2xlYXJseSBhbiBpbXBvcnRhbnQgcHJvYmxlbSBpbiBidWlsZGluZyBhIGZ1bGwgc29sdXRp b24gdG8NCj4gdGhlIHNlcnZpY2UgY2hhaW5pbmcgbmVlZHMgb2Ygb3BlcmF0b3JzIChlLmcuIHlv dSkuIEhvd2V2ZXIsIEkgY291bGQNCj4gZXF1YWxseSBvYnNlcnZlIHRoYXQgaWYgeW91IGRvIG5v dCBoYXZlIE9TUy9CU1MgY2FwYWJsZSBvZiBwcm92aXNpb25pbmcNCj4gc2VydmljZSBjaGFpbnMs IG9yIGNoYXJnaW5nIHN5c3RlbXMgY2FwYWJsZSBvZiB0dXJuaW5nIHRoZW0gaW50bw0KPiByZXZl bnVlLCB5b3UgY2FuJ3Qgb2ZmZXIgdGhlbS4NCj4gPg0KPiA+IFRoZSBTRkMgd29ya2luZyBncm91 cCBpcyB0YXNrZWQgd2l0aCBvbmUgcGFydCBvZiB0aGUgd2hvbGUgc2VydmljZQ0KPiBjaGFpbiBk ZWZpbml0aW9uLCBjb25zdHJ1Y3Rpb24sIGFuZCBkZXBsb3ltZW50IHByb2JsZW0uIEFzIEkgcmVh ZCB0aGUNCj4gY2hhcnRlciwgZ2VuZXJhbCBsb2FkIGJhbGFuY2luZyBpc3N1ZXMgYXJlIG5vdCBw YXJ0IG9mIG91ciBzY29wZS4NCj4gPiBHaXZlbiB0aGUgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlz IHRoZXJlIGFyZSBvZiBkb2luZyBsb2FkIGJhbGFuY2luZywNCj4gaXQgd291bGQgc3RyaWtlIG1l IGFzIHZlcnkgb2RkIGZvciB0aGUgc2ZjIHdvcmtpbmcgZ3JvdXAgdG8gc3RhbmRhcmRpemUNCj4g YSBwYXJ0aWN1bGFyIGFuc3dlciB0byB0aGUgaW1wb3J0YW50IGFuZCBkaWZmaWN1bHQgcHJvYmxl bSB5b3UgcG9pbnQgdG8uDQo+ID4NCj4gPiBUaGUgYXJjaGl0ZWN0dXJlIChhbmQgSSBiZWxpZXZl IG1vc3Qgb2YgdGhlIHNvbHV0aW9ucykgaXMgZGVzaWduZWQgdG8NCj4gcHJvdmlkZSB0b29scyB0 aGF0IGhlbHAgd2l0aCBtYW5hZ2luZyB0aGF0IHNjYWxpbmcsIHdoaWxlIGFsc28gYWxsb3dpbmcN Cj4gZm9yIHRoZSB1c2Ugb2Ygb3RoZXIgdG9vbHMuDQo+ID4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAg d2FudHMgdXMgdG8gYmUgbW9yZSBzcGVjaWZpYyBpbiB0aGUgbG9hZA0KPiBiYWxhbmNpbmcgYXJj aGl0ZWN0dXJlLCB0aGVuIGlmIHRoZSBjaGFpcnMgdGVsbCB1cyB0byB3ZSB3aWxsIGFkZCBtb3Jl DQo+IHNwZWNpZmljIHRleHQuIEkgd291bGQgYmUgc3VycHJpc2VkIHBlcnNvbmFsbHkgaWYgd2Ug aGFkIGFncmVlbWVudCBvbg0KPiBzdWNoIGEgZ29hbCwgb3IgYWdyZWVtZW50IG9uIGhvdyB0byBm aWxsIHN1Y2ggYSBnb2FsLiBCdXQgQ2FybG9zIGFuZCBJDQo+IHdpbGwgb2YgY291cnNlIGRvIHdo YXQgdGhlIGNoYWlycyB0ZWxsIHVzIHRoZSBXRyB3YW50cy4NCj4gPg0KPiA+IFlvdXJzLA0KPiA+ IEpvZWwNCj4gPg0KPiA+IE9uIDcvMTAvMTQsIDEyOjAyIFBNLCBOQVBJRVJBTEEsIE1BUklBIEgg d3JvdGU6DQo+ID4+IE9uZSBvZiB0aGUgbWFpbiBwcm9ibGVtcyBpbiAic2VydmljZSBjaGFpbnMi IGlzIGhvdyB0byBpbXBsZW1lbnQgYQ0KPiBzZXJ2aWNlIHRoYXQgaXMgY29uY2VwdHVhbGx5IG9u ZSBob3AgYnV0IHNjYWxlZCBob3Jpem9udGFsbHkgYXMgMTAgb3INCj4gMTAwIGRpZmZlcmVudCBW TXMuDQo+ID4+IFNvLCBJTU8sIGlmIHdlIGFyZSBub3QgYWRkcmVzc2luZyB0aGlzIHByb2JsZW0g dGhhbiB3aGF0IGFyZSB3ZSBzb2x2aW5nLg0KPiA+Pg0KPiA+PiBNYXJpYQ0KPiA+Pg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBz ZmMgbWFpbGluZyBsaXN0DQo+ID4gc2ZjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxp bmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_A3233753A4B65F43BCA1B64DA99A9C230708E0030AGSCMAMP19EXfi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSSBicm91Z2h0IHVw IEdTTEIgb25seSB0byBpbGx1c3RyYXRlIHRoYXQgbmV4dC1ob3Agc2VsZWN0aW9uIGNhbiBiZSBk b25lIGluIHNvbWUgb3RoZXIgd2F5LiBCdXQgSSB0aGluayB5b3UgZ2V0IG15IHBvaW50Ljxicj48 YnI+VG8gbWUsICZxdW90O3RyYWZmaWMgZGlzdHJpYnV0aW9uJnF1b3Q7IGlzIGFuIGltcHJvdmVt ZW50IG92ZXIgJnF1b3Q7bG9hZCBkaXN0cmlidXRpb24mcXVvdDsgb25seSBiZWNhdXNlIGl0J3Mg bm90IHRvbyBjbG9zZSB0byBsb2FkIGJhbGFuY2luZy4gQnV0IEknbSBub3Qgd2VkZGVkIHRvIGl0 LiBJJ2xsIGJlIGZpbmUgd2l0aCBhbnkgdGVybSB0aGF0IGlzIGxlc3MgbG9hZGVkIGFuZCBsZXNz IGxpa2VseSB0byBjYXVzZSBjb25mdXNpb24uPGJyPjxicj5NeW88YnI+PGJyPjwvZm9udD48YnI+ Jm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KPGI+RnJvbTwvYj46IG1pa2ViaWFuY0Bhb2wuY29tIFttYWlsdG86bWlrZWJp YW5jQGFvbC5jb21dDTxicj48Yj5TZW50PC9iPjogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMDQ6 MzkgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lPGJyPjxiPlRvPC9iPjogWmFybnksIE15byBbVGVj aF07IGptaEBqb2VsaGFscGVybi5jb20gJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7OyBwYXVs cUBjaXNjby5jb20gJmx0O3BhdWxxQGNpc2NvLmNvbSZndDsNPGJyPjxiPkNjPC9iPjogc2ZjQGll dGYub3JnICZsdDtzZmNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDTxicj48L2ZvbnQ+Jm5i c3A7PGJyPjwvZGl2Pg0KPGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiIg c2l6ZT0iMiI+PGRpdj5BZ3JlZSB0aGF0IG1heWJlICdsb2FkIGRpc3RyaWJ1dGlvbicgaXNuJ3Qg dGhlIGJlc3QgbmFtZS4gJm5ic3A7V2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCBpdCBpcyBkaXN0 aW5ndWlzaGVkIGZyb20gbG9hZCBiYWxhbmNpbmcgKHdoaWNoIGlzIGFsc28gYSBwb29yIG5hbWUp LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TWF5YmUgIlRyYWZmaWMgRGlzdHJpYnV0aW9uJyBv ciAnVHJhZmZpYyBCYWxhbmNpbmcnIG9yIGRvIHRob3NlIG5hbWVzIGFscmVhZHkgY2Fycnkgb3Ro ZXIgc2lnbmlmaWNhbmNlPzxicj48YnI+PGJyPjwvZGl2PjwvZm9udD48ZGl2IGNsYXNzPSIiPjwv ZGl2Pjxicj48YnI+PGJyPjxociBzdHlsZT0iYm9yZGVyOjA7aGVpZ2h0OjFweDtjb2xvcjojOTk5 O2JhY2tncm91bmQtY29sb3I6Izk5OTt3aWR0aDoxMDAlO21hcmdpbjowIDAgOXB4IDA7cGFkZGlu ZzowOyI+PGI+RnJvbTogPC9iPk15by5aYXJueUBncy5jb20mbHQ7TXlvLlphcm55QGdzLmNvbSZn dDs8YnI+PGI+VG86IDwvYj4nam1oQGpvZWxoYWxwZXJuLmNvbScmbHQ7am1oQGpvZWxoYWxwZXJu LmNvbSZndDssJ21pa2ViaWFuY0Bhb2wuY29tJyZsdDttaWtlYmlhbmNAYW9sLmNvbSZndDssJ3Bh dWxxQGNpc2NvLmNvbScmbHQ7cGF1bHFAY2lzY28uY29tJmd0Ozxicj48Yj5jYzogPC9iPidzZmNA aWV0Zi5vcmcnJmx0O3NmY0BpZXRmLm9yZyZndDs8YnI+PGI+U2VudDogPC9iPlRodXJzZGF5LCBK dWx5IDEwLCAyMDE0PGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+PGJyPjx0aXRsZT48L3RpdGxlPlVzaW5nIHRo ZSB0ZXJtIGxvYWQgZGlzdHJpYnV0aW9uIHRvIHJlZmVyIHRvIGxvYWQgYmFsYW5jZXIgc2VsZWN0 aW9uIHdpbGwgYmUgbG9zdCB0byBhIGxvdCBvZiBwZW9wbGUuIE1hbnkgcGVvcGxlIGNhbGwgaXQg Z2xvYmFsIHNldmVyIGxvYWQgYmFsYW5jaW5nLjxicj48YnI+UGx1cywgdGhlcmUgY291bGQgYmUg bXVsdGlwbGUgbGF5ZXJzIG9mICJsb2FkIGRpc3RyaWJ1dGlvbiIgLyBMQiBzZWxlY3Rpb24uIE5v dCBqdXN0IHR3by4gRm9yIGV4YW1wbGUsIHNlbGVjdCBhIHJlZ2lvbiBmcm9tIGEgZ2xvYmFsIHBv b2w7IG9uY2UgdGhlIHJlZ2lvbiBpcyBzZWxlY3RlZCwgc2VsZWN0IGEgZGF0YSBjZW50ZXIgaW4g dGhhdCByZWdpb247IGluIHRoYXQgREMsIHdoaWNoIERDIExCIGluc3RhbmNlIHRvIGdvIHRvOyBh bmQgdGhlbiB3ZSBoYXZlIHRoZSB0cmFkaXRpb25hbCBMQiB3aGljaCBzZWxlY3RzIHRoZSBlbmQg c2VydmVyLjxicj48YnI+SW4gc3VtLCAoMSkgcGF0aCBzZWxlY3Rpb24gY291bGQgaGFwcGVuIGF0 IG1vcmUgdGhhbiAyIGRpZmZlcmVudCB0aWVyczsgKDIpICJsb2FkIiBpc24ndCB0aGUgb25seSBj cml0ZXJpb24gaW4gdGhvc2Ugc2VsZWN0aW9ucy4gSSBzZWUgdGhlIHJhdGlvbmFsZSBmb3Igd2Fu dGluZyB0aGUgZGlmZmVyZW50aWF0aW9uIGJ1dCBpcyBsb2FkIGRpc3RyaWJ1dGlvbiB0aGUgYmVz dCB0ZXJtIGZvciBpdD8gPGJyPjxicj5SZWdhcmRzLDxicj48YnI+PGJyPjxicj4tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tPGJyPjxicj48YnIgY2xhc3M9IiI+RnJvbTogSm9lbCBNLiBIYWxw ZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV08YnIgY2xhc3M9IiI+U2VudDogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQgMDM6MDEgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lPGJyIGNsYXNz PSIiPlRvOiBtaWtlYmlhbmNAYW9sLmNvbSAmbHQ7bWlrZWJpYW5jQGFvbC5jb20mZ3Q7OyBwYXVs cUBjaXNjby5jb20gJmx0O3BhdWxxQGNpc2NvLmNvbSZndDs8YnIgY2xhc3M9IiI+Q2M6IHNmY0Bp ZXRmLm9yZyAmbHQ7c2ZjQGlldGYub3JnJmd0OzxiciBjbGFzcz0iIj5TdWJqZWN0OiBSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPlRoZSB0ZXJtICJsb2FkIGRpc3RyaWJ1dGlvbiIgd29ya3MgZm9yIG1lLiAg SSBhZ3JlZSB0aGF0IHRoZXJlIGlzIHZhbHVlIDxiciBjbGFzcz0iIj5pbiBkaWZmZXJlbnRpYXRp bmcgdGhlIGZ1bmN0aW9ucywgYW5kIHVzaW5nIGRpZmZlcmVudCB3b3JkcyB1c3VhbGx5IDxiciBj bGFzcz0iIj5oZWxwcyBzdWNoIGRpZmZlcmVudGlhdGlvbi48YnIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPllvdXJzLDxiciBjbGFzcz0iIj5Kb2VsPGJyIGNsYXNzPSIiPjxiciBjbGFzcz0iIj5PbiA3 LzEwLzE0LCAyOjU1IFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZTo8YnIgY2xhc3M9IiI+Jmd0 OyBJJ3ZlIHN0YXRlZCBiZWZvcmUgdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBkaWZmZXJlbnRpYXRl IGJldHdlZW4gbG9hZDxiciBjbGFzcz0iIj4mZ3Q7IGJhbGFuY2luZyBhbmQgbG9hZCBkaXN0cmli dXRpb24gd2hlcmUgbG9hZCBiYWxhbmNpbmcgcmVmZXJzIHRvIHRoZTxiciBjbGFzcz0iIj4mZ3Q7 IHN0YW5kYXJkIHNlcnZpY2UgZnVuY3Rpb24gdGhhdCB3ZSBhbGwga25vdyBhbmQgbG92ZSAob3V0 c2lkZSBvZiBTRkMpIGFuZDxiciBjbGFzcz0iIj4mZ3Q7IGxvYWQgZGlzdHJpYnV0aW9uIHJlZmVy cyB0byB0aGUgc2VsZWN0aW9uIG9mIGFuIFNGSSAoaS5lLiBDaGFpbiAtJmd0OyBQYXRoPGJyIGNs YXNzPSIiPiZndDsgbWFwcGluZykuICBOb3QgdXNpbmcgZGlmZmVyZW50IHRlcm1zIHRvIGRpc3Rp bmd1aXNoIGJldHdlZW4gdGhlc2UgbGVhZHM8YnIgY2xhc3M9IiI+Jmd0OyB0byBjb25mdXNpb24u PGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OyBlLmcuIGEgU0YgQ2hhaW4qIG1pZ2h0 IGV4aXN0IHdob3NlIFNGcyBjb25zaXN0IG9ubHkgb2YgbG9hZCBiYWxhbmNlcnMuPGJyIGNsYXNz PSIiPiZndDsgJm5ic3A7IEJ1dCB5b3UgbWlnaHQgc3RpbGwgd2FudCBTRkMqIHRvIGRpc3RyaWJ1 dGUgbG9hZCB0byBtdWx0aXBsZSBsb2FkPGJyIGNsYXNzPSIiPiZndDsgYmFsYW5jZXIgaW5zdGFu Y2VzLjxiciBjbGFzcz0iIj4mZ3Q7PGJyIGNsYXNzPSIiPiZndDsgKnRyeWluZyB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIFNGQyBhcyAiU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyIgYW5kIGE8YnIg Y2xhc3M9IiI+Jmd0OyBzaW5nbGUgIlNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4iLjxiciBjbGFzcz0i Ij4mZ3Q7PGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj4mZ3Q7 PGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj4mZ3Q7PGJyIGNs YXNzPSIiPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPiZndDsgKkZyb206ICpwYXVs cUBjaXNjby5jb20mbHQ7cGF1bHFAY2lzY28uY29tJmd0OzxiciBjbGFzcz0iIj4mZ3Q7ICpUbzog KkpvZWwgTS4gSGFscGVybiZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OzxiciBjbGFzcz0iIj4m Z3Q7ICpjYzogKkppbSBHdWljaGFyZDxiciBjbGFzcz0iIj4mZ3Q7IChqZ3VpY2hhcikmbHQ7amd1 aWNoYXJAY2lzY28uY29tJmd0OyxzZmNAaWV0Zi5vcmcmbHQ7c2ZjQGlldGYub3JnJmd0Oyxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20m Z3Q7LFJvbjxiciBjbGFzcz0iIj4mZ3Q7IFBhcmtlciZsdDtSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tJmd0OyxOQVBJRVJBTEEsIE1BUklBIEgmbHQ7bW4xOTIxQGF0dC5jb20mZ3Q7PGJy IGNsYXNzPSIiPiZndDsgKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxiciBjbGFzcz0i Ij4mZ3Q7ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OyBKb2VsLDxiciBj bGFzcz0iIj4mZ3Q7PGJyIGNsYXNzPSIiPiZndDsgSSBjb25jdXIuIFRoZSBnb2FsIGhlcmUgaXMg dG8gYWRkcmVzcyB0aGUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBnZW5lcmljPGJyIGNsYXNzPSIi PiZndDsgc2VydmljZSBmdW5jdGlvbiBkZXBsb3ltZW50IGFuZCBzaG91bGQgZW5hYmxlIGxvY2Fs aXplZCBkZWNpc2lvbnMgc3VjaDxiciBjbGFzcz0iIj4mZ3Q7IGFzIGxvYWQgYmFsYW5jaW5nIChw ZXJoYXBzIG1vcmUgYWNjdXJhdGVseSBsb2FkIGRpc3RyaWJ1dGlvbikuIENsZWFybHk8YnIgY2xh c3M9IiI+Jmd0OyB3ZSBzb3VuZOKAmXQgY29kaWZ5IGhvdyBsb2FkIGRpc3RyaWJ1dGlvbiB3b3Jr cy48YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj4mZ3Q7IEluIG9yZGVyIHRvIGVuYWJsZSBs b2FkIGRpc3RyaWJ1dGlvbiwgZm9yIGV4YW1wbGUsIHRoZSByaWdodDxiciBjbGFzcz0iIj4mZ3Q7 IGFic3RyYWN0aW9ucyBiZWVuIHRvIGJlIGNsZWFybHkgZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0 dXJlLCBhIGtleSBvbmU8YnIgY2xhc3M9IiI+Jmd0OyBiZXJpbmcgdGhlIGRpc3RpbmN0aW9uIGJl dHdlZW4gcGF0aCB2cy4gY2hhaW4uPGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OyBQ YXVsPGJyIGNsYXNzPSIiPiZndDs8YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj4mZ3Q7PGJy IGNsYXNzPSIiPiZndDsgT24gSnVsIDEwLCAyMDE0LCBhdCAxMjowOCBQTSwgSm9lbCBNLiBIYWxw ZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+Jmd0Ozxi ciBjbGFzcz0iIj4mZ3Q7ICAmZ3Q7IFRoYXQgaXMgY2xlYXJseSBhbiBpbXBvcnRhbnQgcHJvYmxl bSBpbiBidWlsZGluZyBhIGZ1bGwgc29sdXRpb24gdG88YnIgY2xhc3M9IiI+Jmd0OyB0aGUgc2Vy dmljZSBjaGFpbmluZyBuZWVkcyBvZiBvcGVyYXRvcnMgKGUuZy4geW91KS4gSG93ZXZlciwgSSBj b3VsZDxiciBjbGFzcz0iIj4mZ3Q7IGVxdWFsbHkgb2JzZXJ2ZSB0aGF0IGlmIHlvdSBkbyBub3Qg aGF2ZSBPU1MvQlNTIGNhcGFibGUgb2YgcHJvdmlzaW9uaW5nPGJyIGNsYXNzPSIiPiZndDsgc2Vy dmljZSBjaGFpbnMsIG9yIGNoYXJnaW5nIHN5c3RlbXMgY2FwYWJsZSBvZiB0dXJuaW5nIHRoZW0g aW50bzxiciBjbGFzcz0iIj4mZ3Q7IHJldmVudWUsIHlvdSBjYW4ndCBvZmZlciB0aGVtLjxiciBj bGFzcz0iIj4mZ3Q7ICAmZ3Q7PGJyIGNsYXNzPSIiPiZndDsgICZndDsgVGhlIFNGQyB3b3JraW5n IGdyb3VwIGlzIHRhc2tlZCB3aXRoIG9uZSBwYXJ0IG9mIHRoZSB3aG9sZSBzZXJ2aWNlPGJyIGNs YXNzPSIiPiZndDsgY2hhaW4gZGVmaW5pdGlvbiwgY29uc3RydWN0aW9uLCBhbmQgZGVwbG95bWVu dCBwcm9ibGVtLiBBcyBJIHJlYWQgdGhlPGJyIGNsYXNzPSIiPiZndDsgY2hhcnRlciwgZ2VuZXJh bCBsb2FkIGJhbGFuY2luZyBpc3N1ZXMgYXJlIG5vdCBwYXJ0IG9mIG91ciBzY29wZS48YnIgY2xh c3M9IiI+Jmd0OyAgJmd0OyBHaXZlbiB0aGUgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlzIHRoZXJl IGFyZSBvZiBkb2luZyBsb2FkIGJhbGFuY2luZyw8YnIgY2xhc3M9IiI+Jmd0OyBpdCB3b3VsZCBz dHJpa2UgbWUgYXMgdmVyeSBvZGQgZm9yIHRoZSBzZmMgd29ya2luZyBncm91cCB0byBzdGFuZGFy ZGl6ZTxiciBjbGFzcz0iIj4mZ3Q7IGEgcGFydGljdWxhciBhbnN3ZXIgdG8gdGhlIGltcG9ydGFu dCBhbmQgZGlmZmljdWx0IHByb2JsZW0geW91IHBvaW50IHRvLjxiciBjbGFzcz0iIj4mZ3Q7ICAm Z3Q7PGJyIGNsYXNzPSIiPiZndDsgICZndDsgVGhlIGFyY2hpdGVjdHVyZSAoYW5kIEkgYmVsaWV2 ZSBtb3N0IG9mIHRoZSBzb2x1dGlvbnMpIGlzIGRlc2lnbmVkIHRvPGJyIGNsYXNzPSIiPiZndDsg cHJvdmlkZSB0b29scyB0aGF0IGhlbHAgd2l0aCBtYW5hZ2luZyB0aGF0IHNjYWxpbmcsIHdoaWxl IGFsc28gYWxsb3dpbmc8YnIgY2xhc3M9IiI+Jmd0OyBmb3IgdGhlIHVzZSBvZiBvdGhlciB0b29s cy48YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyBJZiB0aGUgd29ya2luZyBncm91cCB3YW50cyB1cyB0 byBiZSBtb3JlIHNwZWNpZmljIGluIHRoZSBsb2FkPGJyIGNsYXNzPSIiPiZndDsgYmFsYW5jaW5n IGFyY2hpdGVjdHVyZSwgdGhlbiBpZiB0aGUgY2hhaXJzIHRlbGwgdXMgdG8gd2Ugd2lsbCBhZGQg bW9yZTxiciBjbGFzcz0iIj4mZ3Q7IHNwZWNpZmljIHRleHQuIEkgd291bGQgYmUgc3VycHJpc2Vk IHBlcnNvbmFsbHkgaWYgd2UgaGFkIGFncmVlbWVudCBvbjxiciBjbGFzcz0iIj4mZ3Q7IHN1Y2gg YSBnb2FsLCBvciBhZ3JlZW1lbnQgb24gaG93IHRvIGZpbGwgc3VjaCBhIGdvYWwuIEJ1dCBDYXJs b3MgYW5kIEk8YnIgY2xhc3M9IiI+Jmd0OyB3aWxsIG9mIGNvdXJzZSBkbyB3aGF0IHRoZSBjaGFp cnMgdGVsbCB1cyB0aGUgV0cgd2FudHMuPGJyIGNsYXNzPSIiPiZndDsgICZndDs8YnIgY2xhc3M9 IiI+Jmd0OyAgJmd0OyBZb3Vycyw8YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyBKb2VsPGJyIGNsYXNz PSIiPiZndDsgICZndDs8YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyBPbiA3LzEwLzE0LCAxMjowMiBQ TSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOjxiciBjbGFzcz0iIj4mZ3Q7ICAmZ3Q7Jmd0OyBP bmUgb2YgdGhlIG1haW4gcHJvYmxlbXMgaW4gInNlcnZpY2UgY2hhaW5zIiBpcyBob3cgdG8gaW1w bGVtZW50IGE8YnIgY2xhc3M9IiI+Jmd0OyBzZXJ2aWNlIHRoYXQgaXMgY29uY2VwdHVhbGx5IG9u ZSBob3AgYnV0IHNjYWxlZCBob3Jpem9udGFsbHkgYXMgMTAgb3I8YnIgY2xhc3M9IiI+Jmd0OyAx MDAgZGlmZmVyZW50IFZNcy48YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyZndDsgU28sIElNTywgaWYg d2UgYXJlIG5vdCBhZGRyZXNzaW5nIHRoaXMgcHJvYmxlbSB0aGFuIHdoYXQgYXJlIHdlIHNvbHZp bmcuPGJyIGNsYXNzPSIiPiZndDsgICZndDsmZ3Q7PGJyIGNsYXNzPSIiPiZndDsgICZndDsmZ3Q7 IE1hcmlhPGJyIGNsYXNzPSIiPiZndDsgICZndDsmZ3Q7PGJyIGNsYXNzPSIiPiZndDsgICZndDs8 YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4mZ3Q7ICAmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+Jmd0OyAgJmd0OyBzZmNAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+Jmd0OyAgJmd0OyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxiciBjbGFzcz0iIj4mZ3Q7 PGJyIGNsYXNzPSIiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPiZn dDsgc2ZjQGlldGYub3JnPGJyIGNsYXNzPSIiPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj4mZ3Q7PGJyIGNs YXNzPSIiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPiZndDsgc2Zj QGlldGYub3JnPGJyIGNsYXNzPSIiPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM8YnIgY2xhc3M9IiI+Jmd0OzxiciBjbGFzcz0iIj48YnIgY2xhc3M9IiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+ c2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnIgY2xhc3M9IiI+ --_000_A3233753A4B65F43BCA1B64DA99A9C230708E0030AGSCMAMP19EXfi_-- From nobody Thu Jul 10 15:56: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 ED7591A007F for ; Thu, 10 Jul 2014 15:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 qp6gmclylId2 for ; Thu, 10 Jul 2014 15:56:02 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC1C1A0078 for ; Thu, 10 Jul 2014 15:56:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="121311714" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABPCoNBV60VjzIXhzWBN3SCJQEBAQECAQEBARdLCQIOBwQCAQgRAQMBAQEKHQcnCxQDBggCBAESCBOHTQMJFcwQEwSMU4EsEQUmOAaDHoEUBIkjiwpEjmGKfoFqQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 10 Jul 2014 22:55:59 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 15:55:59 -0700 From: Ian Smith To: "NAPIERALA, MARIA H" , Joel Halpern Direct , "Joel M. Halpern" , "huang@sce.carleton.ca" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAH0MgP//ixO3AA7+twD//4rdBIAAfNyA//+MEhGAAHejgP//i2o7 Date: Thu, 10 Jul 2014 22:55:58 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83C817@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>,<53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A7EB@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C60F@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A848@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C684@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A89A@MISOUT7MSGUSRCF.ITServices.sbc.com> <419417C345CA5F48BF45F0A23955A0634A83C74C@SEAEMBX02.olympus.F5Net.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4A8D1@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A8D1@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] 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/VR3w_w2rYOnXffy1HKwz9Rr_NB0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:56:06 -0000 > Who is asking?=0A= There have been large rooms packed with people at IETF87, IETF88, and IETF8= 9 asking for it.=0A= =0A= > Why source routing? =0A= =0A= Other than IP source routes are by definition solving the same problem as S= ervice Function Chains and are already part of a standard? No reason.=0A= Unfortunately router companies have optimized their chips and os for destin= ation routing and it is easily spoofed if you don't use AH, so it's gotten = a bum rap. In our collective wisdom, we actually deprecated the IPv6 Type = 0 Routing Header in 2007 (rfc5095) and then created a whole new one from sc= ratch in 2012 for the IoT (rfc6554) when we realized we actually needed it.= =0A= =0A= > Is this is the only choice?=0A= =0A= No. You could use MPLSoIP. If there was good MPLS networking in the Linux = kernel, I suppose you could use MPLSoE (servers have to be able to talk to = the network). Or you could use an elastic infrastructure to just provision= instances of services that have the next link in the chain as their next-h= op gateway (technically that is moving the state out of the data plane, alt= hough I probably wouldn't call it stateless). Anything that either takes t= he next hop decision away by making it the default or carrying it along wit= h the packet that doesn't also require distributing a referential policy ha= s a strong case for statelessness.=0A= =0A= The early drafts of the problem statement had a section where these kinds o= f solutions were ruled out as having too many barriers to implementation (I= IRC), so we are doing circuit switching over packet networks. =0A= =0A= =0A= ________________________________________=0A= From: NAPIERALA, MARIA H [mn1921@att.com]=0A= Sent: Thursday, July 10, 2014 6:25 PM=0A= To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;= sfc@ietf.org=0A= Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= > I'm not saying creating stateful service channels on packet networks is a= =0A= > good thing, but it is what people are asking for, and if we are going to = do it=0A= > we should do it right.=0A= =0A= Who is asking?=0A= =0A= > If you want stateless service chains, you would do it with IP source rout= ing=0A= =0A= Why source routing? Is this is the only choice?=0A= =0A= > ________________________________________=0A= > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > Sent: Thursday, July 10, 2014 6:11 PM=0A= > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.c= a;=0A= > sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > > > However you view it is not something that stays within a single devic= e.=0A= > >=0A= > > Agreed. But I'm not asserting that it does. What I am asserting is th= at the=0A= > > scale of what a single device can do today matters when thinking about= =0A= > > how to do almost exactly what that device does in a distributed manner.= =0A= >=0A= > > Picking channelized paths through packet switched networks is making=0A= > the=0A= > > network stateful, so if you can, for example be stateful to the order o= f 50=0A= > or=0A= > > 100 million flows in an existing single node, then you should _at the v= ery=0A= > > least_ expect to have 50 to 100 million flows in the distributed system= =0A= > that=0A= > > takes its place.=0A= >=0A= > I wonder what scale we would have achieved if we were managing TCP/IP=0A= > flows in Internet core network routers.=0A= >=0A= > > ________________________________________=0A= > > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > > Sent: Thursday, July 10, 2014 5:44 PM=0A= > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern;=0A= > huang@sce.carleton.ca;=0A= > > sfc@ietf.org=0A= > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > >=0A= > > For me it is a logical or virtual network over a common physical networ= k.=0A= > > However you view it is not something that stays within a single device.= =0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Ian Smith [mailto:I.Smith@f5.com]=0A= > > > Sent: Thursday, July 10, 2014 5:38 PM=0A= > > > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern;=0A= > > > huang@sce.carleton.ca; sfc@ietf.org=0A= > > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > A service path isn't a logical network; it is - quite literally - a = path=0A= > > _though_=0A= > > > a network.=0A= > > >=0A= > > >=0A= > > >=0A= > > > ________________________________________=0A= > > > From: NAPIERALA, MARIA H [mn1921@att.com]=0A= > > > Sent: Thursday, July 10, 2014 5:33 PM=0A= > > > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern;=0A= > > huang@sce.carleton.ca;=0A= > > > sfc@ietf.org=0A= > > > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > > >=0A= > > > Managing millions of 5-tuple flows in a single appliance is not the s= ame=0A= > as=0A= > > > managing (globally) millions of service paths which are essentially l= ogical=0A= > > > networks. And 16 million was an arbitrary number for just 100 service= =0A= > > > chains. 100 service chains is very little. Image this number be two o= r=0A= > more=0A= > > > orders of magnitude higher...=0A= > > >=0A= > > > > -----Original Message-----=0A= > > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=0A= > > > > Sent: Thursday, July 10, 2014 5:15 PM=0A= > > > > To: Joel Halpern Direct; Joel M. Halpern; huang@sce.carleton.ca;=0A= > > > > sfc@ietf.org=0A= > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > >=0A= > > > > Actually, I think I am disagreeing.=0A= > > > >=0A= > > > > If the possibility of medium-scale deployments (and that is what 16= =0A= > > > million=0A= > > > > flows is in my world) of service chains is preconceived as an absur= d=0A= > idea,=0A= > > > > then the architecture burdened with that preconception.=0A= > > > >=0A= > > > > There has to be some point of aim, some degree of aspiration to sca= le=0A= > > > that=0A= > > > > is appropriate for the lifespan of the architecture - you don't hav= e to=0A= > > > know=0A= > > > > what it is, but by saying that an arbitrary number is "too far", yo= u're=0A= > > > > creating - even if it isn't intentional - a limit that influences d= ecisions=0A= > > that=0A= > > > > have lasting impacts regarding scale-out, failure mitigation, elast= icity,=0A= > > > > address space... all kinds of things. That is a problem I'm not=0A= > > particularly=0A= > > > > eager to deal with.=0A= > > > >=0A= > > > >=0A= > > > >=0A= > > > >=0A= > > > > ________________________________________=0A= > > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com]=0A= > > > > Sent: Thursday, July 10, 2014 5:04 PM=0A= > > > > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org= =0A= > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > >=0A= > > > > Ian, I don't think you disagree with me at all in this regard.=0A= > > > > I am not requesting the the architecture or the solution prohibit= =0A= > > > > deployments in the specific fashion.=0A= > > > > I am objecting to Huang's reading of my note as saying that such=0A= > > > > deployments are required they by the archtiecture.=0A= > > > >=0A= > > > > As I have said repeatedly, I am not trying to prohibit such things.= =0A= > > > > Whether they are a good idea or not depends upon many factors=0A= > > outside=0A= > > > of=0A= > > > > the scope of the WG. I happen to think that they are usually a bad= =0A= > > idea.=0A= > > > >=0A= > > > > But the archtiecture si carefully avoiding attempting to know what = is=0A= > > > > and is not eployable.=0A= > > > >=0A= > > > > Yours,=0A= > > > > Joel=0A= > > > >=0A= > > > > On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= > > > > > I disagree.=0A= > > > > >=0A= > > > > > We routinely have stateful devices that manage tens of millions o= f=0A= > > > > concurrent flows in both access network and data center=0A= > environments=0A= > > > > today. You can't seriously believe that in the=0A= > > > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only=0A= > going=0A= > > to=0A= > > > > have small numbers of service chains with equally small numbers of= =0A= > > active=0A= > > > > service paths?=0A= > > > > >=0A= > > > > > Your sounds too much like "no one will ever need more than 64K"= =0A= > for=0A= > > > > comfort.=0A= > > > > >=0A= > > > > >=0A= > > > > > ________________________________________=0A= > > > > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= > > > > [jmh@joelhalpern.com]=0A= > > > > > Sent: Thursday, July 10, 2014 4:46 PM=0A= > > > > > To: huang@sce.carleton.ca; sfc@ietf.org=0A= > > > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= > > > > >=0A= > > > > > No, it will mean that if someone tries to deploy the archtieture= =0A= > > > > > particularly badly, they will exceed the limits of their devices.= =0A= > > > > > The architecture does not require such absurd use of service path= s.=0A= > > > > > Since I can not figure out how to write architectural words to=0A= > prohibit=0A= > > > > > it, the architecture does permit such abuse.=0A= > > > > >=0A= > > > > > Please do not read my saying that the archtiecture permits=0A= > something=0A= > > > as=0A= > > > > > saying it is either deisred or required by the work. It isn't.= =0A= > > > > >=0A= > > > > > Yours,=0A= > > > > > Joel=0A= > > > > >=0A= > > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= > > > > >> If you need to support 100 service chains, it will mean 16,000,0= 00=0A= > > > > >> paths. That is larger than the routing table of a core router.= =0A= > > > > >>=0A= > > > > >> Chang=0A= > > > > >>=0A= > > > > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= > > > > >>> The architecture allows a range of deployments, from 1 service= =0A= > path=0A= > > > to=0A= > > > > >>> 160000 service paths. I would hope that operators are prepared= =0A= > for=0A= > > > > >>> the complexities if they choose to avoid any use of local load= =0A= > > > > >>> balancing and in stead provision 160,000 service paths.=0A= > > > > >>>=0A= > > > > >>> Yours,=0A= > > > > >>> Joel=0A= > > > > >>>=0A= > > > > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= > > > > >>>> Paul,=0A= > > > > >>>>=0A= > > > > >>>> How many path identifiers there will be for a 4 hop service ch= ain=0A= > > > with=0A= > > > > >>>> 20 instances at each hop?=0A= > > > > >>>>=0A= > > > > >>>> Maria=0A= > > > > >>>>=0A= > > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul= =0A= > > Quinn=0A= > > > > >>>> (paulq)=0A= > > > > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM=0A= > > > > >>>> *To:* Lucy yong=0A= > > > > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com;=0A= > > > > sfc@ietf.org;=0A= > > > > >>>> mikebianc@aol.com=0A= > > > > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers= =0A= > > > > >>>>=0A= > > > > >>>> Lucy,=0A= > > > > >>>>=0A= > > > > >>>> Overall I concur, as you say: a path ID drives the forwarding.= I'd=0A= > > make=0A= > > > > >>>> the minor change: the path identifier can be used to derive th= e=0A= > > > > needed=0A= > > > > >>>> forwarding and associated transport.=0A= > > > > >>>>=0A= > > > > >>>> It is _not_ the transport, but rather is used to simply identi= fy the=0A= > > > > >>>> service path (or graph) that packets must traverse. By having= a=0A= > > path=0A= > > > > >>>> identifier, the exact indirection that people seem to be askin= g for=0A= > > on=0A= > > > > >>>> this thread can be simply be implemented. The path identifier= =0A= > > > > provides=0A= > > > > >>>> nothing more than a lookup, that lookup can result in a one or= =0A= > > more=0A= > > > > >>>> (equal or weighted) transport next hop(s).=0A= > > > > >>>>=0A= > > > > >>>> Paul=0A= > > > > >>>>=0A= > > > > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > > > >>>> > wrote:=0A= > > > > >>>>=0A= > > > > >>>>=0A= > > > > >>>>=0A= > > > > >>>> Agree. The arch. doc should not mandate only use of the servic= e=0A= > > > path=0A= > > > > >>>> identifier to drive the forwarding actions.=0A= > > > > >>>>=0A= > > > > >>>> Lucy=0A= > > > > >>>>=0A= > > > > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= > > > > >>>> Of*mohamed.boucadair@orange.com=0A= > > > > =0A= > > > > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM=0A= > > > > >>>> *To:*mikebianc@aol.com=0A= > > > > ;jmh@joelhalpern.com=0A= > > > > >>>> ;sfc@ietf.org=0A= > =0A= > > > > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers= =0A= > > > > >>>>=0A= > > > > >>>> Re-,=0A= > > > > >>>>=0A= > > > > >>>> The merged draft calls out explicitly a service path identifie= r. I=0A= > > > > >>>> object to use that identifier to derive forwarding actions.=0A= > > > > >>>>=0A= > > > > >>>> Requiring a SFC system to have the full knowledge of every=0A= > > available=0A= > > > > SFC=0A= > > > > >>>> forwarding paths within an SFC-enabled domain is not=0A= > > > > required/justified=0A= > > > > >>>> nor possible in various deployment contexts.=0A= > > > > >>>>=0A= > > > > >>>> SFC forwarding actions should rely on the piece of information= =0A= > > that=0A= > > > > will=0A= > > > > >>>> be present in all deployments: that is the one required to=0A= > > structure=0A= > > > a=0A= > > > > >>>> service chain. How that information is used to infer forwardin= g=0A= > > > actions=0A= > > > > >>>> is a solution-oriented discussion.=0A= > > > > >>>>=0A= > > > > >>>> Cheers,=0A= > > > > >>>>=0A= > > > > >>>> Med=0A= > > > > >>>>=0A= > > > > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= > > > > de*mikebianc@aol.com=0A= > > > > >>>> =0A= > > > > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03=0A= > > > > >>>> *=C0 :*jmh@joelhalpern.com=0A= > > > > ;sfc@ietf.org=0A= > > > > >>>> =0A= > > > > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers= =0A= > > > > >>>>=0A= > > > > >>>> Is anyone still questioning the difference between SF Chain an= d=0A= > SF=0A= > > > > Path?=0A= > > > > >>>> Other than clarifying the definition so that it's clear to = those=0A= > not=0A= > > > > >>>> familiar with the draft, it seems that everyone agrees on thes= e=0A= > > > terms.=0A= > > > > >>>>=0A= > > > > >>>> To me, the one point that is still unclear is whether it is th= e=0A= > intent=0A= > > > > >>>> of this draft to ultimately specify what the ID of the SFC Hea= der=0A= > > > > should=0A= > > > > >>>> reference (the chain or the path), or if this draft simply int= ends=0A= > to=0A= > > > > >>>> leave that ambiguous, allowing other drafts to dictate the=0A= > > > > mechanisms=0A= > > > > >>>> for forwarding based on chain or path and the choice of chain = or=0A= > > > path=0A= > > > > to=0A= > > > > >>>> be negotiated in the control-plane.=0A= > > > > >>>>=0A= > > > > >>>> If the latter (ambiguous), then the draft would have require t= hat=0A= > > > both=0A= > > > > >>>> SFP and SFC be supported (or make one required and the other= =0A= > > > > optional)=0A= > > > > >>>> to avoid some vendors only supporting SFP and others only=0A= > > > > supporting=0A= > > > > >>>> SFC.=0A= > > > > >>>>=0A= > > > > >>>> --------------------------------------------------------------= ----------=0A= > > > > >>>>=0A= > > > > >>>> *From:*jmh@joelhalpern.com > > > >>>> >=0A= > > > > >>>> *To:*sfc@ietf.org > > >=0A= > > > > >>>> *Sent:*Tuesday, July 8, 2014=0A= > > > > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers=0A= > > > > >>>>=0A= > > > > >>>> I have been trying to figure out how to clearly answer a numbe= r=0A= > of=0A= > > > > >>>> comments that have been made about the proposed merged=0A= > > > > archtiecture=0A= > > > > >>>> draft. Assuming we can get working group agreement on the=0A= > > intent,=0A= > > > > we=0A= > > > > >>>> will work to improve the wording so that readers who have not= =0A= > > > > >>>> participated in the WG discussion will understnd it the way th= e=0A= > > > > working=0A= > > > > >>>> group intends.=0A= > > > > >>>>=0A= > > > > >>>> But what do we intend? I will try to explain my personal view,= =0A= > and=0A= > > > see=0A= > > > > >>>> if that helps.=0A= > > > > >>>>=0A= > > > > >>>> In this regard, it is important to keep in mind that what we a= re=0A= > > > > >>>> defining is the data plane architecture. We are not attempting= to=0A= > > > > >>>> define the architecture for the entire solution for service=0A= > chaining.=0A= > > > > >>>> That would encompass OSS/BSS, various control and policy=0A= > > > functions,=0A= > > > > >>>> virtual machine and image management, and many other=0A= > aspects.=0A= > > > > >>>>=0A= > > > > >>>> As a result there are many things which clearly need to exist = in=0A= > the=0A= > > > > >>>> larger system, but which are dealt with above where we are=0A= > > > > functioning,=0A= > > > > >>>> and are not directly required by the work we are doing.=0A= > > > > >>>>=0A= > > > > >>>> In order to get to service chain vs service path, as I underst= and=0A= > > > them,=0A= > > > > >>>> I need to first discuss load balancing. There are at least thr= ee=0A= > > > > >>>> different ways that load balancing can and will interact with= =0A= > > service=0A= > > > > >>>> chaining. There probably are more. The point of the archtiectu= re=0A= > is=0A= > > > to=0A= > > > > >>>> permit all of these, but not to mandate that any particular ki= nd=0A= > be=0A= > > > > used=0A= > > > > >>>> in any solution.=0A= > > > > >>>>=0A= > > > > >>>> 1) Load balancing as a service provided to the end user. This = is a=0A= > > > > >>>> service function. It receives user packets, and modifies them = (or=0A= > > > marks=0A= > > > > >>>> them, or ...) so as to choose an end user service instance to= =0A= > receive=0A= > > > > >>>> the users packet. This is an important service function to be = able=0A= > > to=0A= > > > > >>>> include in service chaining. It's behavior may affect requirem= ents=0A= > > on=0A= > > > > >>>> how service chaining is done. But it has very little impact on= the=0A= > > > > >>>> archtiecture. From an architectural pe3rspective it is simply = a=0A= > > service=0A= > > > > >>>> function which may modify the underlying packet.=0A= > > > > >>>>=0A= > > > > >>>> 2) There is internal load balancing. That is, one can have wha= t=0A= > > > appears=0A= > > > > >>>> to the service chaining architecture as a single point of cont= act=0A= > for=0A= > > a=0A= > > > > >>>> specific service function, but is actually delivered by a coll= ection=0A= > of=0A= > > > > >>>> virtual or physical machines, possibly including one or severa= l=0A= > load=0A= > > > > >>>> balancers (for example using VRRP-like techniques to share a= =0A= > MAC=0A= > > > > >>>> address.) mostly, this is invisible to the service chaining da= ta=0A= > plane=0A= > > > > >>>> mechanisms. It is likely that it is visible to various control= =0A= > > > > >>>> mechanisms, such as those responsible for scale-in, scale-out,= =0A= > and=0A= > > > vm=0A= > > > > >>>> instantiation. The architectural impact of permitting this is= =0A= > largely=0A= > > > > >>>> that we need to be careful that our terminology does not lead= =0A= > > > readers=0A= > > > > to=0A= > > > > >>>> think we are prohibiting it.=0A= > > > > >>>>=0A= > > > > >>>> 3) There can also be load balancing done by selecting packet= =0A= > paths=0A= > > > for=0A= > > > > >>>> the service chaining that direct traffic to different places. = We=0A= > > would=0A= > > > > >>>> not want to require that a given service function appear at on= ly=0A= > > one=0A= > > > > >>>> place in the network.=0A= > > > > >>>>=0A= > > > > >>>> It is of course the case that these may be combined. I tend to= =0A= > refer=0A= > > > to=0A= > > > > >>>> the collection of entities that appear to service chaining as = a=0A= > single=0A= > > > > >>>> point as a cluster. Not because cluster is a good term. But=0A= > because=0A= > > I=0A= > > > > >>>> do not have another one. Thus, the point of type 3 load=0A= > balancing=0A= > > is=0A= > > > > to=0A= > > > > >>>> direct different subsets of traffic to different singular or c= lustered=0A= > > > > >>>> service functions in different places in the network.=0A= > > > > >>>>=0A= > > > > >>>> Now with that said, what do I mean when I talk about service= =0A= > > chain=0A= > > > > and=0A= > > > > >>>> service path/ Service chain is a sequence of logical functions= to=0A= > be=0A= > > > > >>>> applied to a subset of packets. It is equivalent of saying tha= t=0A= > some=0A= > > > > >>>> subset of traffic is to get DPI, charging, content inspection,= and=0A= > > > > >>>> firewall while a different subset is to go directly to the cac= he=0A= > > without=0A= > > > > >>>> visiting any other service functions.=0A= > > > > >>>>=0A= > > > > >>>> That is not enough information to direct the packets. A servic= e=0A= > > path=0A= > > > > >>>> is, in some fashion, a sequence of locations in the network.= =0A= > Those=0A= > > > > >>>> locations will be singular or clustered service function deliv= ery=0A= > > > > >>>> locations. They may be addressed by IP address. They may be=0A= > > > > addressed=0A= > > > > >>>> as ports on an SFF. There are many different ways that the=0A= > > locations=0A= > > > > >>>> may be known to the service chaining infrastructure and the=0A= > > > > transport.=0A= > > > > >>>>=0A= > > > > >>>> >From the point of view of the work of the SFC group, we nee= d=0A= > to=0A= > > > be=0A= > > > > >>>> able=0A= > > > > >>>> to talk about the high level abstraction, the service chain, w= hich=0A= > > > > >>>> drives the forwarding. And we need to talk about the actual da= ta=0A= > > > path=0A= > > > > >>>> packets will take in the network.=0A= > > > > >>>>=0A= > > > > >>>> Several of the comments have said "but the whole path may not= =0A= > > be=0A= > > > > known=0A= > > > > >>>> at the front." This architecture deals with that issue in two = ways.=0A= > > > > >>>> First, as noted in item (2) on load balancers above, there can= be=0A= > > > > >>>> decisions and behaviors which are invisible to the service=0A= > chaining=0A= > > > > >>>> mechanisms (in much the same way that bridging within a LAN is= =0A= > > > > largely=0A= > > > > >>>> invisible to routing between LANs.) The other provision we mak= e=0A= > is=0A= > > > > that=0A= > > > > >>>> reclassification can be done in mid-chain when necessary. That= =0A= > will=0A= > > > > >>>> direct packets to a new chain. Based on information available = at=0A= > > the=0A= > > > > >>>> re-classification point.=0A= > > > > >>>>=0A= > > > > >>>> I hope that this helps explain what we are after. If it does, = and if=0A= > > > > >>>> the intent is acceptable to the working group, we can figure o= ut=0A= > > > what=0A= > > > > >>>> additional words are needed to convey this.=0A= > > > > >>>> If the working group disagree with the intent, then we will of= =0A= > > course=0A= > > > > >>>> adjust to match the working group agreements.=0A= > > > > >>>> If this is still unclear, I am not sure what to try next.=0A= > > > > >>>>=0A= > > > > >>>> Yours,=0A= > > > > >>>> Joel=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= > > > > >> _______________________________________________=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= > > > > _______________________________________________=0A= > > > > sfc mailing list=0A= > > > > sfc@ietf.org=0A= > > > > https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Thu Jul 10 15:58: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 3505E1A0080 for ; Thu, 10 Jul 2014 15:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGoCU_w-_6MR for ; Thu, 10 Jul 2014 15:58:45 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319021A007F for ; Thu, 10 Jul 2014 15:58:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 5aa1fb35.2b15e5401940.8643407.00-2456.20675213.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:58:45 +0000 (UTC) X-MXL-Hash: 53bf1aa54c81fcde-0fe46758c0a7f9542c238bc9e67b965731d740ea Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id a9a1fb35.0.8643352.00-2300.20675061.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 10 Jul 2014 22:58:35 +0000 (UTC) X-MXL-Hash: 53bf1a9b28e2b9d3-20db225736b9045cc1dd3662c057f01f5ebfb265 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMwYv3006462; Thu, 10 Jul 2014 18:58:34 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6AMwPhj006377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2014 18:58:30 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Jul 2014 22:58:12 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:58:11 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyA///FqNA= Date: Thu, 10 Jul 2014 22:58:11 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A90B@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> In-Reply-To: <53BF108D.4090509@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=i0EeH86SAAAA:8 a=1p97v] X-AnalysisOut: [ixHYpC_ZisWFt4A:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=U8] X-AnalysisOut: [Ie8EnqySEA:10 a=3XJ037QrwtgA:10 a=chC_agHSu74A:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=hPjdaMEvmhQA:10 a=wTwRrW1FrQmopXet:21 a=P7_vLt] X-AnalysisOut: [gzum80Phsb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/86b_p-LCbS-xZkeNizp6uZ2HTUg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 22:58:49 -0000 SWYgdGhpcyBpcyBpbmRlZWQgdGhlIGNhc2UgKGFzIE1pa2UgcG9pbnRlZCBvdXQpIHRoYXQgaW4g dGhlIHByb3Bvc2VkIGFyY2hpdGVjdHVyZSB0aGUgU0ZJKG4pIGNhbm5vdCBiZSBkZXRlcm1pbmVk IGF0IHRoZSBTRkkobi0xKSBob3AgKGV4Y2VwdCBieSBjaGFuZ2luZyB0aGUgc2VydmljZSBwYXRo KSB0aGVuIGNsZWFybHkgdGhlIGNob2ljZSBvZiwgc2F5LCB3aGljaCBvbmUgb2YgMjAgc2Vydmlj ZSBpbnN0YW5jZXMgb2Ygb25lIHNlcnZpY2UgaG9wIGhhcyB0byBiZSBkb25lIGF0IHRoZSBlbnRy eSB0byB0aGUgY2hhaW4uICBXZSBoYXZlIGp1c3QgZGlzY3Vzc2VkIGl0LCBhbmQgaXQgd2FzIHN0 YXRlZCB0aGF0IGl0IGlzIG5vdCB0aGUgY2FzZS4gQ2FuIHRoZSBhdXRob3JzIGNsYXJpZnk/DQoN Ck1hcmlhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIEhhbHBlcm4gRGlyZWN0 DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDY6MTYgUE0NCj4gVG86IG1pa2ViaWFu Y0Bhb2wuY29tOyBJLlNtaXRoQEY1LmNvbTsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiANCj4gVGhl IHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0byBp bmZsdWVuY2UgdGhlDQo+IGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRp b24gYXQgdGhlIGV4aXQgZnJvbSBTRjEuDQo+IA0KPiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtl ZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMgbG9naWNhbGx5IHNlcGFyYXRlDQo+IHNvIHRoYXQg c29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5IGNob29zZSB0byBjb21wb3Nl IHRoZW0NCj4gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+ IA0KPiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4gPiBJ IGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueSBz b3J0IG9mIGxpbWl0Lg0KPiA+ICAgSG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRo YXQgdGhlIGVudGlyZSBwYXRoIChhbGwgU0ZJcykgbXVzdA0KPiA+IGJlIGNob3NlbiBhdCBTRkMg aW5zdGFudGlhdGlvbi4gIEkgYmVsaWV2ZSB0aGlzIG1lYW5zIGVpdGhlciBhdCB0aGUNCj4gPiBj bGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyIGNob29zZXMgYSBTRiBDaGFpbiBhbmQg dGhlIE5GIG9yIGF0DQo+ID4gdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiAgSW4gYW55IGNhc2Us IHRoZSBsYW5ndWFnZSBkb2VzIHNlZW0gdG8NCj4gPiBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBT RlAgd2hlcmUgU0ZJKG4pIGlzIGRldGVybWluZWQgYXQgdGhlIFNGSShuLTEpDQo+ID4gaG9wLiAg QWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwgdGhpcyBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVk DQo+ID4gImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQIGFzIG9wcG9zZWQgdG8gY2hvb3NpbmcgYW5k IHRoZW4gZm9yd2FyZGluZyB0bw0KPiA+IHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZiB0aGUgbmV4 dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPiA+DQo+ID4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNo aXRlY3R1cmUtMDA6DQo+ID4+ICBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUg bmV0d29yayBpdCBpcyBuZWNlc3NhcnkgdG8NCj4gPiAgPiAgc2VsZWN0IHRoZSBzcGVjaWZpYyBp bnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLCBhbmQgdG8gY3JlYXRlDQo+ID4gID4g IHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcmsgbG9j YXRvci4gIFRodXMsDQo+ID4gID4gIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGlu IHRoZSBjcmVhdGlvbiBvZiBhIFNlcnZpY2UNCj4gPiAgPiAgRnVuY3Rpb24gUGF0aCAoU0ZQKSBh bmQgaXMgdXNlZCBmb3IgZm9yd2FyZGluZyBwYWNrZXRzIHRocm91Z2ggdGhlDQo+ID4gID4gIFNG Qy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVm aW5lZCBTRkMuDQo+ID4gID4NCj4gPiAgPiAgVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMg cmVjbGFzc2lmaWNhdGlvbiAob3Igbm9uLWluaXRpYWwNCj4gPiAgPiAgY2xhc3NpZmljYXRpb24p IGFzIHdlbGwuICBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4gPiAgPiAgcmVjbGFzc2lm aWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGEgY2xhc3NpZmljYXRp b24NCj4gPiAgPiAgZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24u ICBSZWNsYXNzaWZpY2F0aW9uIG1heQ0KPiA+ICA+ICByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBv ZiBhIG5ldyBTRlAsIGFuIHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZA0KPiA+ICA+ICBtZXRhZGF0 YSwgb3IgYm90aC4gIFRoaXMgaXMgcmVmZXJyZWQgdG8gYXMgImJyYW5jaGluZyIuDQo+ID4NCj4g Pg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gKkZyb206ICpJLlNtaXRoQEY1LmNvbTxJ LlNtaXRoQEY1LmNvbT4NCj4gPiAqVG86ICpKb2VsIEhhbHBlcm4gRGlyZWN0PGptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tPixKb2VsIE0uDQo+ID4NCj4gSGFscGVybjxqbWhAam9lbGhhbHBlcm4u Y29tPixodWFuZ0BzY2UuY2FybGV0b24uY2E8aHVhbmdAc2NlLmNhcmxldA0KPiBvbi5jYT4sc2Zj QGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4gPiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAy MDE0DQo+ID4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4gPg0KPiA+IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVp bmcuDQo+ID4NCj4gPiBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1l bnRzIChhbmQgdGhhdCBpcyB3aGF0IDE2DQo+ID4gbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3Js ZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMgcHJlY29uY2VpdmVkIGFzIGFuDQo+ID4gYWJzdXJkIGlk ZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoIHRoYXQgcHJlY29uY2VwdGlv bi4NCj4gPg0KPiA+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdy ZWUgb2YgYXNwaXJhdGlvbiB0byBzY2FsZQ0KPiA+IHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRo ZSBsaWZlc3BhbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIC0geW91IGRvbid0DQo+ID4gaGF2ZSB0byBr bm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbiBhcmJpdHJhcnkgbnVtYmVyIGlz ICJ0b28NCj4gPiBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0IGludGVu dGlvbmFsIC0gYSBsaW1pdCB0aGF0DQo+ID4gaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZl IGxhc3RpbmcgaW1wYWN0cyByZWdhcmRpbmcgc2NhbGUtb3V0LA0KPiA+IGZhaWx1cmUgbWl0aWdh dGlvbiwgZWxhc3RpY2l0eSwgYWRkcmVzcyBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLg0K PiA+IFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3QgcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwg d2l0aC4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPg0KPiA+DQo+ID4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBb am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNTowNCBQTQ0KPiA+IFRvOiBJYW4gU21pdGg7IEpvZWwgTS4gSGFscGVybjsgaHVhbmdA c2NlLmNhcmxldG9uLmNhOyBzZmNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPg0KPiA+IElhbiwgSSBk b24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcyByZWdhcmQuDQo+ ID4gSSBhbSBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRp b24gcHJvaGliaXQNCj4gPiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4NCj4g PiBJIGFtIG9iamVjdGluZyB0byBIdWFuZydzIHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcg dGhhdCBzdWNoDQo+ID4gZGVwbG95bWVudHMgYXJlIHJlcXVpcmVkIHRoZXkgYnkgdGhlIGFyY2h0 aWVjdHVyZS4NCj4gPg0KPiA+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRy eWluZyB0byBwcm9oaWJpdCBzdWNoIHRoaW5ncy4NCj4gPiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29v ZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueSBmYWN0b3JzIG91dHNpZGUNCj4gb2YNCj4g PiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0byB0aGluayB0aGF0IHRoZXkgYXJlIHVz dWFsbHkgYSBiYWQgaWRlYS4NCj4gPg0KPiA+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVm dWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvIGtub3cgd2hhdCBpcw0KPiA+IGFuZCBpcyBub3Qg ZXBsb3lhYmxlLg0KPiA+DQo+ID4gWW91cnMsDQo+ID4gSm9lbA0KPiA+DQo+ID4gT24gNy8xMC8x NCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPiA+ICA+IEkgZGlzYWdyZWUuDQo+ID4gID4N Cj4gPiAgPiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRl bnMgb2YgbWlsbGlvbnMgb2YNCj4gPiBjb25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNzIG5l dHdvcmsgYW5kIGRhdGEgY2VudGVyIGVudmlyb25tZW50cw0KPiA+IHRvZGF5LiBZb3UgY2FuJ3Qg c2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbiB0aGUNCj4gPiBDbG91ZC9JUHY2L01vYmlsaXR5L1dl YjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91IGFyZSBvbmx5IGdvaW5nIHRvDQo+ID4gaGF2 ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseSBzbWFsbCBudW1i ZXJzIG9mDQo+ID4gYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+ID4gID4NCj4gPiAgPiBZb3VyIHNv dW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBldmVyIG5lZWQgbW9yZSB0aGFuIDY0SyIg Zm9yDQo+ID4gY29tZm9ydC4NCj4gPiAgPg0KPiA+ICA+DQo+ID4gID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICA+IEZyb206IHNmYyBbc2ZjLWJvdW5jZXNA aWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4gPiBbam1oQGpvZWxoYWxw ZXJuLmNvbV0NCj4gPiAgPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNDQo+ ID4gID4gVG86IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3JnDQo+ID4gID4gU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+ID4gID4NCj4gPiAgPiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0 byBkZXBsb3kgdGhlIGFyY2h0aWV0dXJlDQo+ID4gID4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5 IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YgdGhlaXIgZGV2aWNlcy4NCj4gPiAgPiBUaGUgYXJj aGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQgdXNlIG9mIHNlcnZpY2UgcGF0 aHMuDQo+ID4gID4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlIGFyY2hp dGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQNCj4gPiAgPiBpdCwgdGhlIGFyY2hpdGVjdHVyZSBk b2VzIHBlcm1pdCBzdWNoIGFidXNlLg0KPiA+ICA+DQo+ID4gID4gUGxlYXNlIGRvIG5vdCByZWFk IG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUgcGVybWl0cyBzb21ldGhpbmcNCj4gYXMN Cj4gPiAgPiBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkgdGhlIHdv cmsuIEl0IGlzbid0Lg0KPiA+ICA+DQo+ID4gID4gWW91cnMsDQo+ID4gID4gSm9lbA0KPiA+ICA+ DQo+ID4gID4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZToNCj4g PiAgPj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGwg bWVhbiAxNiwwMDAsMDAwDQo+ID4gID4+IHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSBy b3V0aW5nIHRhYmxlIG9mIGEgY29yZSByb3V0ZXIuDQo+ID4gID4+DQo+ID4gID4+IENoYW5nDQo+ ID4gID4+DQo+ID4gID4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4gPiAgPj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95 bWVudHMsIGZyb20gMSBzZXJ2aWNlIHBhdGgNCj4gdG8NCj4gPiAgPj4+IDE2MDAwMCBzZXJ2aWNl IHBhdGhzLiBJIHdvdWxkIGhvcGUgdGhhdCBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvcg0KPiA+ ICA+Pj4gdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5IGNob29zZSB0byBhdm9pZCBhbnkgdXNlIG9m IGxvY2FsIGxvYWQNCj4gPiAgPj4+IGJhbGFuY2luZyBhbmQgaW4gc3RlYWQgcHJvdmlzaW9uIDE2 MCwwMDAgc2VydmljZSBwYXRocy4NCj4gPiAgPj4+DQo+ID4gID4+PiBZb3VycywNCj4gPiAgPj4+ IEpvZWwNCj4gPiAgPj4+DQo+ID4gID4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEs IE1BUklBIEggd3JvdGU6DQo+ID4gID4+Pj4gUGF1bCwNCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IEhv dyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcCBzZXJ2aWNl IGNoYWluDQo+IHdpdGgNCj4gPiAgPj4+PiAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+ID4g ID4+Pj4NCj4gPiAgPj4+PiBNYXJpYQ0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gKkZyb206KnNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpQYXVsIFF1aW5uDQo+ ID4gID4+Pj4gKHBhdWxxKQ0KPiA+ICA+Pj4+ICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQgMzowMyBQTQ0KPiA+ICA+Pj4+ICpUbzoqIEx1Y3kgeW9uZw0KPiA+ICA+Pj4+ICpDYzoqIGpt aEBqb2VsaGFscGVybi5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+IHNmY0Bp ZXRmLm9yZzsNCj4gPiAgPj4+PiBtaWtlYmlhbmNAYW9sLmNvbQ0KPiA+ICA+Pj4+ICpTdWJqZWN0 OiogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ ID4gID4+Pj4NCj4gPiAgPj4+PiBMdWN5LA0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gT3ZlcmFsbCBJ IGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gSeKA mWQNCj4gPiBtYWtlDQo+ID4gID4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRp ZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUgdGhlDQo+IG5lZWRlZA0KPiA+ICA+Pj4+IGZvcndh cmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gSXQg aXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvIHNpbXBseSBpZGVu dGlmeSB0aGUNCj4gPiAgPj4+PiBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMg bXVzdCB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aA0KPiA+ICA+Pj4+IGlkZW50aWZpZXIsIHRo ZSBleGFjdCBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3INCj4g b24NCj4gPiAgPj4+PiB0aGlzIHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBU aGUgcGF0aCBpZGVudGlmaWVyDQo+IHByb3ZpZGVzDQo+ID4gID4+Pj4gbm90aGluZyBtb3JlIHRo YW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbiByZXN1bHQgaW4gYSBvbmUgb3INCj4gbW9yZQ0K PiA+ICA+Pj4+IChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQgaG9wKHMpLg0KPiA+ ICA+Pj4+DQo+ID4gID4+Pj4gUGF1bA0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gT24gSnVsIDEwLCAy MDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbQ0KPiA+ICA+ Pj4+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4gPiAgPj4+Pg0KPiA+ ICA+Pj4+DQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQg bm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlIHNlcnZpY2UNCj4gcGF0aA0KPiA+ICA+Pj4+IGlk ZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcgYWN0aW9ucy4NCj4gPiAgPj4+Pg0KPiA+ ICA+Pj4+IEx1Y3kNCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxmDQo+ID4gID4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ ID4gID4+Pj4gKlNlbnQ6KlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MDYgQU0NCj4gPiAgPj4+ PiAqVG86Km1pa2ViaWFuY0Bhb2wuY29tDQo+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+O2pt aEBqb2VsaGFscGVybi5jb20NCj4gPiAgPj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ O3NmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPiAgPj4+PiAqU3ViamVjdDoq UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4g ID4+Pj4NCj4gPiAgPj4+PiBSZS0sDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBUaGUgbWVyZ2VkIGRy YWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIuIEkNCj4g PiAgPj4+PiBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUgZm9yd2FyZGlu ZyBhY3Rpb25zLg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0 byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeQ0KPiA+IGF2YWlsYWJsZSBTRkMNCj4g PiAgPj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMg bm90DQo+ID4gcmVxdWlyZWQvanVzdGlmaWVkDQo+ID4gID4+Pj4gbm9yIHBvc3NpYmxlIGluIHZh cmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy4NCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IFNGQyBmb3J3 YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mIGluZm9ybWF0aW9uDQo+ ID4gdGhhdCB3aWxsDQo+ID4gID4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRo YXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUNCj4gYQ0KPiA+ICA+Pj4+IHNlcnZp Y2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgdG8gaW5mZXIgZm9yd2FyZGlu Zw0KPiA+IGFjdGlvbnMNCj4gPiAgPj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Np b24uDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBDaGVlcnMsDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBN ZWQNCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSpEZSBsYSBwYXJ0DQo+ID4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4gPiAgPj4+PiA8 bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KPiA+ICA+Pj4+ICpFbnZvecOpIDoqbWVyY3JlZGkg OSBqdWlsbGV0IDIwMTQgMjI6MDMNCj4gPiAgPj4+PiAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29t DQo+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4gID4+Pj4g PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4gID4+Pj4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4gID4+Pj4NCj4gPiAgPj4+ PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBD aGFpbiBhbmQgU0YNCj4gPiBQYXRoPw0KPiA+ICA+Pj4+ICAgIE90aGVyIHRoYW4gY2xhcmlmeWlu ZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8NCj4gPiB0aG9zZSBub3QNCj4g PiAgPj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBh Z3JlZXMgb24gdGhlc2UNCj4gdGVybXMuDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBUbyBtZSwgdGhl IG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50 ZW50DQo+ID4gID4+Pj4gb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0 aGUgSUQgb2YgdGhlIFNGQyBIZWFkZXINCj4gPiBzaG91bGQNCj4gPiAgPj4+PiByZWZlcmVuY2Ug KHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5IGludGVuZHMg dG8NCj4gPiAgPj4+PiBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRz IHRvIGRpY3RhdGUgdGhlDQo+IG1lY2hhbmlzbXMNCj4gPiAgPj4+PiBmb3IgZm9yd2FyZGluZyBi YXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+ID4gcGF0 aCB0bw0KPiA+ICA+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+ID4g ID4+Pj4NCj4gPiAgPj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFm dCB3b3VsZCBoYXZlIHJlcXVpcmUgdGhhdA0KPiBib3RoDQo+ID4gID4+Pj4gU0ZQIGFuZCBTRkMg YmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQgdGhlIG90aGVyDQo+IG9wdGlv bmFsKQ0KPiA+ICA+Pj4+IHRvIGF2b2lkIHNvbWUgdmVuZG9ycyBvbmx5IHN1cHBvcnRpbmcgU0ZQ IGFuZCBvdGhlcnMgb25seQ0KPiBzdXBwb3J0aW5nDQo+ID4gID4+Pj4gU0ZDLg0KPiA+ICA+Pj4+ DQo+ID4gID4+Pj4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+ICpG cm9tOipqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb20NCj4gPiAgPj4+PiA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gPiAg Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4gPG1haWx0bzpzZmNAaWV0Zi5v cmclM2NzZmNAaWV0Zi5vcmc+Pg0KPiA+ICA+Pj4+ICpTZW50OipUdWVzZGF5LCBKdWx5IDgsIDIw MTQNCj4gPiAgPj4+PiAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0 byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFuc3dlciBhIG51bWJlciBvZg0KPiA+ICA+Pj4+ IGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1lcmdlZA0K PiBhcmNodGllY3R1cmUNCj4gPiAgPj4+PiBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3Jr aW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LA0KPiB3ZQ0KPiA+ICA+Pj4+IHdpbGwg d29yayB0byBpbXByb3ZlIHRoZSB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QN Cj4gPiAgPj4+PiBwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0 bmQgaXQgdGhlIHdheSB0aGUNCj4gPiB3b3JraW5nDQo+ID4gID4+Pj4gZ3JvdXAgaW50ZW5kcy4N Cj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0 byBleHBsYWluIG15IHBlcnNvbmFsIHZpZXcsIGFuZA0KPiBzZWUNCj4gPiAgPj4+PiBpZiB0aGF0 IGhlbHBzLg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9y dGFudCB0byBrZWVwIGluIG1pbmQgdGhhdCB3aGF0IHdlIGFyZQ0KPiA+ICA+Pj4+IGRlZmluaW5n IGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlIG5vdCBhdHRlbXB0aW5nIHRv DQo+ID4gID4+Pj4gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRp b24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuDQo+ID4gID4+Pj4gVGhhdCB3b3VsZCBlbmNvbXBhc3Mg T1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kNCj4gZnVuY3Rpb25zLA0KPiA+ICA+ Pj4+IHZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIg YXNwZWN0cy4NCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55 IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8gZXhpc3QgaW4gdGhlDQo+ID4gID4+Pj4gbGFy Z2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFyZQ0K PiA+IGZ1bmN0aW9uaW5nLA0KPiA+ICA+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVk IGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy4NCj4gPiAgPj4+Pg0KPiA+ICA+Pj4+IEluIG9yZGVy IHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSSB1bmRlcnN0YW5k DQo+ID4gdGhlbSwNCj4gPiAgPj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFu Y2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlDQo+ID4gID4+Pj4gZGlmZmVyZW50IHdheXMg dGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwgaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlDQo+ ID4gID4+Pj4gY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiBUaGUgcG9pbnQgb2Yg dGhlIGFyY2h0aWVjdHVyZSBpcw0KPiB0bw0KPiA+ICA+Pj4+IHBlcm1pdCBhbGwgb2YgdGhlc2Us IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4gPiBiZSB1c2Vk DQo+ID4gID4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gMSkgTG9h ZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4gVGhpcyBp cyBhDQo+ID4gID4+Pj4gc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRz LCBhbmQgbW9kaWZpZXMgdGhlbSAob3INCj4gPiBtYXJrcw0KPiA+ICA+Pj4+IHRoZW0sIG9yIC4u Likgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2 ZQ0KPiA+ICA+Pj4+IHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50IHNlcnZp Y2UgZnVuY3Rpb24gdG8gYmUgYWJsZSB0bw0KPiA+ICA+Pj4+IGluY2x1ZGUgaW4gc2VydmljZSBj aGFpbmluZy4gSXQncyBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbg0KPiA+ICA+ Pj4+IGhvdyBzZXJ2aWNlIGNoYWluaW5nIGlzIGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUg aW1wYWN0IG9uIHRoZQ0KPiA+ICA+Pj4+IGFyY2h0aWVjdHVyZS4gRnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPiA+IHNlcnZpY2UNCj4gPiAgPj4+PiBm dW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4gPiAgPj4+ Pg0KPiA+ICA+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlz LCBvbmUgY2FuIGhhdmUgd2hhdA0KPiA+IGFwcGVhcnMNCj4gPiAgPj4+PiB0byB0aGUgc2Vydmlj ZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YgY29udGFjdA0KPiA+ IGZvciBhDQo+ID4gID4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVh bGx5IGRlbGl2ZXJlZCBieSBhDQo+ID4gY29sbGVjdGlvbiBvZg0KPiA+ICA+Pj4+IHZpcnR1YWwg b3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3Igc2V2ZXJhbCBs b2FkDQo+ID4gID4+Pj4gYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UgdGVj aG5pcXVlcyB0byBzaGFyZSBhIE1BQw0KPiA+ICA+Pj4+IGFkZHJlc3MuKSBtb3N0bHksIHRoaXMg aXMgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCj4gPiAgPj4+ PiBtZWNoYW5pc21zLiBJdCBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMg Y29udHJvbA0KPiA+ICA+Pj4+IG1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUg Zm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZA0KPiB2bQ0KPiA+ICA+Pj4+IGluc3RhbnRpYXRp b24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2Vs eQ0KPiA+ICA+Pj4+IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9s b2d5IGRvZXMgbm90IGxlYWQNCj4gPiByZWFkZXJzIHRvDQo+ID4gID4+Pj4gdGhpbmsgd2UgYXJl IHByb2hpYml0aW5nIGl0Lg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gMykgVGhlcmUgY2FuIGFsc28g YmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0IHBhdGhzDQo+IGZvcg0K PiA+ICA+Pj4+IHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMgdG8gZGlm ZmVyZW50IHBsYWNlcy4gV2Ugd291bGQNCj4gPiAgPj4+PiBub3Qgd2FudCB0byByZXF1aXJlIHRo YXQgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZQ0KPiA+ICA+Pj4+ IHBsYWNlIGluIHRoZSBuZXR3b3JrLg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gSXQgaXMgb2YgY291 cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQgdG8NCj4gPiBy ZWZlciB0bw0KPiA+ICA+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFy IHRvIHNlcnZpY2UgY2hhaW5pbmcgYXMgYSBzaW5nbGUNCj4gPiAgPj4+PiBwb2ludCBhcyBhIGNs dXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMgYSBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkN Cj4gPiAgPj4+PiBkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5 cGUgMyBsb2FkIGJhbGFuY2luZw0KPiA+IGlzIHRvDQo+ID4gID4+Pj4gZGlyZWN0IGRpZmZlcmVu dCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9yIGNsdXN0ZXJlZA0K PiA+ICA+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5l dHdvcmsuDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8g SSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0IHNlcnZpY2UgY2hhaW4NCj4gYW5kDQo+ID4gID4+Pj4g c2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5j dGlvbnMgdG8gYmUNCj4gPiAgPj4+PiBhcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuIEl0 IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZQ0KPiA+ICA+Pj4+IHN1YnNldCBvZiB0 cmFmZmljIGlzIHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0K PiA+ICA+Pj4+IGZpcmV3YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJl Y3RseSB0byB0aGUgY2FjaGUNCj4gPiB3aXRob3V0DQo+ID4gID4+Pj4gdmlzaXRpbmcgYW55IG90 aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gVGhhdCBpcyBub3Qg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQSBzZXJ2aWNlIHBhdGgN Cj4gPiAgPj4+PiBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucyBp biB0aGUgbmV0d29yay4gVGhvc2UNCj4gPiAgPj4+PiBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxh ciBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeQ0KPiA+ICA+Pj4+IGxvY2F0 aW9ucy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlDQo+ IGFkZHJlc3NlZA0KPiA+ICA+Pj4+IGFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkg ZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zDQo+ID4gID4+Pj4gbWF5IGJlIGtub3du IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUNCj4gdHJhbnNw b3J0Lg0KPiA+ICA+Pj4+DQo+ID4gID4+Pj4gICA+RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0 aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRvDQo+IGJlDQo+ID4gID4+Pj4gYWJs ZQ0KPiA+ICA+Pj4+IHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRo ZSBzZXJ2aWNlIGNoYWluLCB3aGljaA0KPiA+ICA+Pj4+IGRyaXZlcyB0aGUgZm9yd2FyZGluZy4g QW5kIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGENCj4gcGF0aA0KPiA+ICA+ Pj4+IHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLg0KPiA+ICA+Pj4+DQo+ID4gID4+ Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGgg bWF5IG5vdCBiZQ0KPiBrbm93bg0KPiA+ICA+Pj4+IGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0 ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4NCj4gPiAgPj4+PiBGaXJz dCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZCBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNh biBiZQ0KPiA+ICA+Pj4+IGRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2li bGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcNCj4gPiAgPj4+PiBtZWNoYW5pc21zIChpbiBtdWNo IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcw0KPiBsYXJnZWx5DQo+ ID4gID4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyIHBy b3Zpc2lvbiB3ZSBtYWtlIGlzDQo+ID4gdGhhdA0KPiA+ICA+Pj4+IHJlY2xhc3NpZmljYXRpb24g Y2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdpbGwNCj4gPiAg Pj4+PiBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24gaW5mb3JtYXRpb24g YXZhaWxhYmxlIGF0IHRoZQ0KPiA+ICA+Pj4+IHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KPiA+ ICA+Pj4+DQo+ID4gID4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2Ug YXJlIGFmdGVyLiBJZiBpdCBkb2VzLCBhbmQgaWYNCj4gPiAgPj4+PiB0aGUgaW50ZW50IGlzIGFj Y2VwdGFibGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsIHdlIGNhbiBmaWd1cmUgb3V0DQo+IHdoYXQN Cj4gPiAgPj4+PiBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuDQo+ ID4gID4+Pj4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50ZW50LCB0 aGVuIHdlIHdpbGwgb2YgY291cnNlDQo+ID4gID4+Pj4gYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3Jr aW5nIGdyb3VwIGFncmVlbWVudHMuDQo+ID4gID4+Pj4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFy LCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8gdHJ5IG5leHQuDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBZ b3VycywNCj4gPiAgPj4+PiBKb2VsDQo+ID4gID4+Pj4NCj4gPiAgPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICA+Pj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4gPiAgPj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4g ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPiAgPj4+ Pg0KPiA+ICA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gID4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+ICA+Pj4+IHNmY0BpZXRmLm9yZyA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPiAgPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPiA+ICA+Pj4+DQo+ID4gID4+Pg0KPiA+ICA+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgPj4+IHNmYyBtYWls aW5nIGxpc3QNCj4gPiAgPj4+IHNmY0BpZXRmLm9yZw0KPiA+ICA+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPiAgPj4+DQo+ID4gID4+DQo+ID4gID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gID4+IHNm YyBtYWlsaW5nIGxpc3QNCj4gPiAgPj4gc2ZjQGlldGYub3JnDQo+ID4gID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4gID4+DQo+ID4gID4NCj4gPiAgPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICA+IHNm YyBtYWlsaW5nIGxpc3QNCj4gPiAgPiBzZmNAaWV0Zi5vcmcNCj4gPiAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ICA+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNmYyBtYWlsaW5nIGxp c3QNCj4gPiBzZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Thu Jul 10 16:08: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 A60D51A008A for ; Thu, 10 Jul 2014 16:08:10 -0700 (PDT) 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_29=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 ZYfuTbcbLvNu for ; Thu, 10 Jul 2014 16:08:08 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BBD1A0080 for ; Thu, 10 Jul 2014 16:08:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id D8364841419; Thu, 10 Jul 2014 16:08:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 828FA841417; Thu, 10 Jul 2014 16:08:05 -0700 (PDT) Message-ID: <53BF1CD4.4070006@joelhalpern.com> Date: Thu, 10 Jul 2014 19:08:04 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A90B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A90B@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BW14eCQICyxkp25e7T_zrXCM30g Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jul 2014 23:08:10 -0000 The choice of which instance of SF-X is to be used for a given packet on Service Path Y is made either at or behind thee SFF serving SF-X. The Service Path determines which SFF the packet will get to. If there are multiple instances behind that SFF, then either the SFF includes a load balancer, or it talks to a (or a redundant pair of) load balancers. It is the load balancer function which selects the actual instance to receive the packet. Thus, there is one service path, directing packets to a sequence of SFF which are tasked with delivering the packets to specific service functions. Each SFF may be delivering to a single Service Function, a redundant pair, a load balanced cluster, or any other service delivery architecture. Whether the load balancing is stateful, lightly stateful (whatever that happens to mean) or stateless depends upon what is deployed and what is needed by the service function instances. It is not determined by the SFC architecture, and I don't expect the SFC solution to mandate a particular answer either. Yours, Joel On 7/10/14, 6:58 PM, NAPIERALA, MARIA H wrote: > If this is indeed the case (as Mike pointed out) that in the proposed architecture the SFI(n) cannot be determined at the SFI(n-1) hop (except by changing the service path) then clearly the choice of, say, which one of 20 service instances of one service hop has to be done at the entry to the chain. We have just discussed it, and it was stated that it is not the case. Can the authors clarify? > > Maria > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >> Sent: Thursday, July 10, 2014 6:16 PM >> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> The way the architecture models the case of SF1 needing to influence the >> chain is that one would do reclassification at the exit from SF1. >> >> Part of the goal is to keep the different functions logically separate >> so that solutions can clearly describe how they choose to compose them >> for "service" delivery. >> >> Yours, >> Joel >> >> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>> I don't see anything in the arch draft that suggests any sort of limit. >>> However, it does seem to indicate that the entire path (all SFIs) must >>> be chosen at SFC instantiation. I believe this means either at the >>> classifier or maybe the classifier chooses a SF Chain and the NF or at >>> the latest the first SFF. In any case, the language does seem to >>> prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1) >>> hop. According to the draft, this behavior would be considered >>> "branching" to a new SFP as opposed to choosing and then forwarding to >>> the selected instance of the next-hop of the current SFC. >>> >>> draft-merged-sfc-architecture-00: >>>> When an SFC is instantiated into the network it is necessary to >>> > select the specific instances of SFs that will be used, and to create >>> > the service topology for that SFC using SF's network locator. Thus, >>> > instantiation of the SFC results in the creation of a Service >>> > Function Path (SFP) and is used for forwarding packets through the >>> > SFC. In other words, an SFP is the instantiation of the defined SFC. >>> > >>> > The SFC architecture supports reclassification (or non-initial >>> > classification) as well. As packets traverse an SFP, >>> > reclassification may occur - typically performed by a classification >>> > function co-resident with a service function. Reclassification may >>> > result in the selection of a new SFP, an update of the associated >>> > metadata, or both. This is referred to as "branching". >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From: *I.Smith@F5.com >>> *To: *Joel Halpern Direct,Joel M. >>> >> Halpern,huang@sce.carleton.ca> on.ca>,sfc@ietf.org >>> *Sent: *Thursday, July 10, 2014 >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Actually, I think I am disagreeing. >>> >>> If the possibility of medium-scale deployments (and that is what 16 >>> million flows is in my world) of service chains is preconceived as an >>> absurd idea, then the architecture burdened with that preconception. >>> >>> There has to be some point of aim, some degree of aspiration to scale >>> that is appropriate for the lifespan of the architecture - you don't >>> have to know what it is, but by saying that an arbitrary number is "too >>> far", you're creating - even if it isn't intentional - a limit that >>> influences decisions that have lasting impacts regarding scale-out, >>> failure mitigation, elasticity, address space... all kinds of things. >>> That is a problem I'm not particularly eager to deal with. >>> >>> >>> >>> >>> ________________________________________ >>> >>> >>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 5:04 PM >>> To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Ian, I don't think you disagree with me at all in this regard. >>> I am not requesting the the architecture or the solution prohibit >>> deployments in the specific fashion. >>> I am objecting to Huang's reading of my note as saying that such >>> deployments are required they by the archtiecture. >>> >>> As I have said repeatedly, I am not trying to prohibit such things. >>> Whether they are a good idea or not depends upon many factors outside >> of >>> the scope of the WG. I happen to think that they are usually a bad idea. >>> >>> But the archtiecture si carefully avoiding attempting to know what is >>> and is not eployable. >>> >>> Yours, >>> Joel >>> >>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> > I disagree. >>> > >>> > We routinely have stateful devices that manage tens of millions of >>> concurrent flows in both access network and data center environments >>> today. You can't seriously believe that in the >>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to >>> have small numbers of service chains with equally small numbers of >>> active service paths? >>> > >>> > Your sounds too much like "no one will ever need more than 64K" for >>> comfort. >>> > >>> > >>> > ________________________________________ >>> > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>> [jmh@joelhalpern.com] >>> > Sent: Thursday, July 10, 2014 4:46 PM >>> > To: huang@sce.carleton.ca; sfc@ietf.org >>> > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> > >>> > No, it will mean that if someone tries to deploy the archtieture >>> > particularly badly, they will exceed the limits of their devices. >>> > The architecture does not require such absurd use of service paths. >>> > Since I can not figure out how to write architectural words to prohibit >>> > it, the architecture does permit such abuse. >>> > >>> > Please do not read my saying that the archtiecture permits something >> as >>> > saying it is either deisred or required by the work. It isn't. >>> > >>> > Yours, >>> > Joel >>> > >>> > On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>> >> If you need to support 100 service chains, it will mean 16,000,000 >>> >> paths. That is larger than the routing table of a core router. >>> >> >>> >> Chang >>> >> >>> >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>> >>> The architecture allows a range of deployments, from 1 service path >> to >>> >>> 160000 service paths. I would hope that operators are prepared for >>> >>> the complexities if they choose to avoid any use of local load >>> >>> balancing and in stead provision 160,000 service paths. >>> >>> >>> >>> Yours, >>> >>> Joel >>> >>> >>> >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>> >>>> Paul, >>> >>>> >>> >>>> How many path identifiers there will be for a 4 hop service chain >> with >>> >>>> 20 instances at each hop? >>> >>>> >>> >>>> Maria >>> >>>> >>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>> >>>> (paulq) >>> >>>> *Sent:* Thursday, July 10, 2014 3:03 PM >>> >>>> *To:* Lucy yong >>> >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; >> sfc@ietf.org; >>> >>>> mikebianc@aol.com >>> >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>>> >>> >>>> Lucy, >>> >>>> >>> >>>> Overall I concur, as you say: a path ID drives the forwarding. I’d >>> make >>> >>>> the minor change: the path identifier can be used to derive the >> needed >>> >>>> forwarding and associated transport. >>> >>>> >>> >>>> It is _not_ the transport, but rather is used to simply identify the >>> >>>> service path (or graph) that packets must traverse. By having a path >>> >>>> identifier, the exact indirection that people seem to be asking for >> on >>> >>>> this thread can be simply be implemented. The path identifier >> provides >>> >>>> nothing more than a lookup, that lookup can result in a one or >> more >>> >>>> (equal or weighted) transport next hop(s). >>> >>>> >>> >>>> Paul >>> >>>> >>> >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >>>> > wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Agree. The arch. doc should not mandate only use of the service >> path >>> >>>> identifier to drive the forwarding actions. >>> >>>> >>> >>>> Lucy >>> >>>> >>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>> >>>> Of*mohamed.boucadair@orange.com >> >>> >>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>> >>>> *To:*mikebianc@aol.com >> ;jmh@joelhalpern.com >>> >>>> ;sfc@ietf.org >>> >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>>> >>> >>>> Re-, >>> >>>> >>> >>>> The merged draft calls out explicitly a service path identifier. I >>> >>>> object to use that identifier to derive forwarding actions. >>> >>>> >>> >>>> Requiring a SFC system to have the full knowledge of every >>> available SFC >>> >>>> forwarding paths within an SFC-enabled domain is not >>> required/justified >>> >>>> nor possible in various deployment contexts. >>> >>>> >>> >>>> SFC forwarding actions should rely on the piece of information >>> that will >>> >>>> be present in all deployments: that is the one required to structure >> a >>> >>>> service chain. How that information is used to infer forwarding >>> actions >>> >>>> is a solution-oriented discussion. >>> >>>> >>> >>>> Cheers, >>> >>>> >>> >>>> Med >>> >>>> >>> >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>> de*mikebianc@aol.com >>> >>>> >>> >>>> *Envoyé :*mercredi 9 juillet 2014 22:03 >>> >>>> *À :*jmh@joelhalpern.com >> ;sfc@ietf.org >>> >>>> >>> >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>>> >>> >>>> Is anyone still questioning the difference between SF Chain and SF >>> Path? >>> >>>> Other than clarifying the definition so that it's clear to >>> those not >>> >>>> familiar with the draft, it seems that everyone agrees on these >> terms. >>> >>>> >>> >>>> To me, the one point that is still unclear is whether it is the intent >>> >>>> of this draft to ultimately specify what the ID of the SFC Header >>> should >>> >>>> reference (the chain or the path), or if this draft simply intends to >>> >>>> leave that ambiguous, allowing other drafts to dictate the >> mechanisms >>> >>>> for forwarding based on chain or path and the choice of chain or >>> path to >>> >>>> be negotiated in the control-plane. >>> >>>> >>> >>>> If the latter (ambiguous), then the draft would have require that >> both >>> >>>> SFP and SFC be supported (or make one required and the other >> optional) >>> >>>> to avoid some vendors only supporting SFP and others only >> supporting >>> >>>> SFC. >>> >>>> >>> >>>> >>> ------------------------------------------------------------------------ >>> >>>> >>> >>>> *From:*jmh@joelhalpern.com>> >>>> > >>> >>>> *To:*sfc@ietf.org> > >>> >>>> *Sent:*Tuesday, July 8, 2014 >>> >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>> >>>> >>> >>>> I have been trying to figure out how to clearly answer a number of >>> >>>> comments that have been made about the proposed merged >> archtiecture >>> >>>> draft. Assuming we can get working group agreement on the intent, >> we >>> >>>> will work to improve the wording so that readers who have not >>> >>>> participated in the WG discussion will understnd it the way the >>> working >>> >>>> group intends. >>> >>>> >>> >>>> But what do we intend? I will try to explain my personal view, and >> see >>> >>>> if that helps. >>> >>>> >>> >>>> In this regard, it is important to keep in mind that what we are >>> >>>> defining is the data plane architecture. We are not attempting to >>> >>>> define the architecture for the entire solution for service chaining. >>> >>>> That would encompass OSS/BSS, various control and policy >> functions, >>> >>>> virtual machine and image management, and many other aspects. >>> >>>> >>> >>>> As a result there are many things which clearly need to exist in the >>> >>>> larger system, but which are dealt with above where we are >>> functioning, >>> >>>> and are not directly required by the work we are doing. >>> >>>> >>> >>>> In order to get to service chain vs service path, as I understand >>> them, >>> >>>> I need to first discuss load balancing. There are at least three >>> >>>> different ways that load balancing can and will interact with service >>> >>>> chaining. There probably are more. The point of the archtiecture is >> to >>> >>>> permit all of these, but not to mandate that any particular kind >>> be used >>> >>>> in any solution. >>> >>>> >>> >>>> 1) Load balancing as a service provided to the end user. This is a >>> >>>> service function. It receives user packets, and modifies them (or >>> marks >>> >>>> them, or ...) so as to choose an end user service instance to receive >>> >>>> the users packet. This is an important service function to be able to >>> >>>> include in service chaining. It's behavior may affect requirements on >>> >>>> how service chaining is done. But it has very little impact on the >>> >>>> archtiecture. From an architectural pe3rspective it is simply a >>> service >>> >>>> function which may modify the underlying packet. >>> >>>> >>> >>>> 2) There is internal load balancing. That is, one can have what >>> appears >>> >>>> to the service chaining architecture as a single point of contact >>> for a >>> >>>> specific service function, but is actually delivered by a >>> collection of >>> >>>> virtual or physical machines, possibly including one or several load >>> >>>> balancers (for example using VRRP-like techniques to share a MAC >>> >>>> address.) mostly, this is invisible to the service chaining data plane >>> >>>> mechanisms. It is likely that it is visible to various control >>> >>>> mechanisms, such as those responsible for scale-in, scale-out, and >> vm >>> >>>> instantiation. The architectural impact of permitting this is largely >>> >>>> that we need to be careful that our terminology does not lead >>> readers to >>> >>>> think we are prohibiting it. >>> >>>> >>> >>>> 3) There can also be load balancing done by selecting packet paths >> for >>> >>>> the service chaining that direct traffic to different places. We would >>> >>>> not want to require that a given service function appear at only one >>> >>>> place in the network. >>> >>>> >>> >>>> It is of course the case that these may be combined. I tend to >>> refer to >>> >>>> the collection of entities that appear to service chaining as a single >>> >>>> point as a cluster. Not because cluster is a good term. But because I >>> >>>> do not have another one. Thus, the point of type 3 load balancing >>> is to >>> >>>> direct different subsets of traffic to different singular or clustered >>> >>>> service functions in different places in the network. >>> >>>> >>> >>>> Now with that said, what do I mean when I talk about service chain >> and >>> >>>> service path/ Service chain is a sequence of logical functions to be >>> >>>> applied to a subset of packets. It is equivalent of saying that some >>> >>>> subset of traffic is to get DPI, charging, content inspection, and >>> >>>> firewall while a different subset is to go directly to the cache >>> without >>> >>>> visiting any other service functions. >>> >>>> >>> >>>> That is not enough information to direct the packets. A service path >>> >>>> is, in some fashion, a sequence of locations in the network. Those >>> >>>> locations will be singular or clustered service function delivery >>> >>>> locations. They may be addressed by IP address. They may be >> addressed >>> >>>> as ports on an SFF. There are many different ways that the locations >>> >>>> may be known to the service chaining infrastructure and the >> transport. >>> >>>> >>> >>>> >From the point of view of the work of the SFC group, we need to >> be >>> >>>> able >>> >>>> to talk about the high level abstraction, the service chain, which >>> >>>> drives the forwarding. And we need to talk about the actual data >> path >>> >>>> packets will take in the network. >>> >>>> >>> >>>> Several of the comments have said "but the whole path may not be >> known >>> >>>> at the front." This architecture deals with that issue in two ways. >>> >>>> First, as noted in item (2) on load balancers above, there can be >>> >>>> decisions and behaviors which are invisible to the service chaining >>> >>>> mechanisms (in much the same way that bridging within a LAN is >> largely >>> >>>> invisible to routing between LANs.) The other provision we make is >>> that >>> >>>> reclassification can be done in mid-chain when necessary. That will >>> >>>> direct packets to a new chain. Based on information available at the >>> >>>> re-classification point. >>> >>>> >>> >>>> I hope that this helps explain what we are after. If it does, and if >>> >>>> the intent is acceptable to the working group, we can figure out >> what >>> >>>> additional words are needed to convey this. >>> >>>> If the working group disagree with the intent, then we will of course >>> >>>> adjust to match the working group agreements. >>> >>>> If this is still unclear, I am not sure what to try next. >>> >>>> >>> >>>> Yours, >>> >>>> Joel >>> >>>> >>> >>>> _______________________________________________ >>> >>>> sfc mailing list >>> >>>> sfc@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>> >>> >>>> _______________________________________________ >>> >>>> sfc mailing list >>> >>>> sfc@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>>> >>> >>> >>> >>> _______________________________________________ >>> >>> sfc mailing list >>> >>> sfc@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >> >>> >> _______________________________________________ >>> >> sfc mailing list >>> >> sfc@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> > >>> > _______________________________________________ >>> > sfc mailing list >>> > sfc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/sfc >>> > >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Jul 10 18:38: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 8745E1B2816 for ; Thu, 10 Jul 2014 18:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 oWeHUZxvNFAt for ; Thu, 10 Jul 2014 18:38:44 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42431A063C for ; Thu, 10 Jul 2014 18:38:44 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 2DC8353E00; Thu, 10 Jul 2014 18:38:42 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 18:38:42.145 -0700 x-echoworx-msg-id: b5cb5d15-d5b3-40b4-9507-b58d5f9b416d x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 637; Thu, 10 Jul 2014 18:38:42 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 06C4053E00; Thu, 10 Jul 2014 18:38:42 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:38:43 -0700 From: Ron Parker To: Joel Halpern Direct , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgCAAEJogIAAEcsAgAACqYCAAAXpAIAAAr6AgAAD/4CAAADcAIAAAwUAgAAPmoCAAAFcgP//wGdr Date: Fri, 11 Jul 2014 01:38:43 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> In-Reply-To: <53BF108D.4090509@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ktUtiBGFnga_52SavOllGjRLjv0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 01:38:47 -0000 This is the crux of my issue. Is the end to end selection of (top-level) = instances performed centrally (perhaps by the classifier) or hop-by-hop (pe= rhaps by the classifier and subsequently the SFFs)? Such selection is not= equivalent to reclassification. And surely, this is an architectural iss= ue and not relegated to "implementation". =20 My own view is to favor the distributed approach even though a greater amou= nt of data (chain definitions and perhaps local selection policy) is requir= ed at those distributed decision points. This approach does not require a= n end-to-end path id at all. My rationale for favoring this approach is = primarily driven by increased resiliency over the global path id approach. = With a global path id approach, consider failure of an instance and needi= ng to alter the global path ID table for each and every affected end-to-end= path. Ron ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct [jmh.dire= ct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The way the architecture models the case of SF1 needing to influence the chain is that one would do reclassification at the exit from SF1. Part of the goal is to keep the different functions logically separate so that solutions can clearly describe how they choose to compose them for "service" delivery. Yours, Joel On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > I don't see anything in the arch draft that suggests any sort of limit. > However, it does seem to indicate that the entire path (all SFIs) must > be chosen at SFC instantiation. I believe this means either at the > classifier or maybe the classifier chooses a SF Chain and the NF or at > the latest the first SFF. In any case, the language does seem to > prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1) > hop. According to the draft, this behavior would be considered > "branching" to a new SFP as opposed to choosing and then forwarding to > the selected instance of the next-hop of the current SFC. > > draft-merged-sfc-architecture-00: >> When an SFC is instantiated into the network it is necessary to > > select the specific instances of SFs that will be used, and to create > > the service topology for that SFC using SF's network locator. Thus, > > instantiation of the SFC results in the creation of a Service > > Function Path (SFP) and is used for forwarding packets through the > > SFC. In other words, an SFP is the instantiation of the defined SFC. > > > > The SFC architecture supports reclassification (or non-initial > > classification) as well. As packets traverse an SFP, > > reclassification may occur - typically performed by a classification > > function co-resident with a service function. Reclassification may > > result in the selection of a new SFP, an update of the associated > > metadata, or both. This is referred to as "branching". > > > > ------------------------------------------------------------------------ > *From: *I.Smith@F5.com > *To: *Joel Halpern Direct,Joel M. > Halpern,huang@sce.carleton.ca= ,sfc@ietf.org > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Actually, I think I am disagreeing. > > If the possibility of medium-scale deployments (and that is what 16 > million flows is in my world) of service chains is preconceived as an > absurd idea, then the architecture burdened with that preconception. > > There has to be some point of aim, some degree of aspiration to scale > that is appropriate for the lifespan of the architecture - you don't > have to know what it is, but by saying that an arbitrary number is "too > far", you're creating - even if it isn't intentional - a limit that > influences decisions that have lasting impacts regarding scale-out, > failure mitigation, elasticity, address space... all kinds of things. > That is a problem I'm not particularly eager to deal with. > > > > > ________________________________________ > > > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] > Sent: Thursday, July 10, 2014 5:04 PM > To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > Ian, I don't think you disagree with me at all in this regard. > I am not requesting the the architecture or the solution prohibit > deployments in the specific fashion. > I am objecting to Huang's reading of my note as saying that such > deployments are required they by the archtiecture. > > As I have said repeatedly, I am not trying to prohibit such things. > Whether they are a good idea or not depends upon many factors outside of > the scope of the WG. I happen to think that they are usually a bad idea. > > But the archtiecture si carefully avoiding attempting to know what is > and is not eployable. > > Yours, > Joel > > On 7/10/14, 5:01 PM, Ian Smith wrote: > > I disagree. > > > > We routinely have stateful devices that manage tens of millions of > concurrent flows in both access network and data center environments > today. You can't seriously believe that in the > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to > have small numbers of service chains with equally small numbers of > active service paths? > > > > Your sounds too much like "no one will ever need more than 64K" for > comfort. > > > > > > ________________________________________ > > From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > [jmh@joelhalpern.com] > > Sent: Thursday, July 10, 2014 4:46 PM > > To: huang@sce.carleton.ca; sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > No, it will mean that if someone tries to deploy the archtieture > > particularly badly, they will exceed the limits of their devices. > > The architecture does not require such absurd use of service paths. > > Since I can not figure out how to write architectural words to prohibi= t > > it, the architecture does permit such abuse. > > > > Please do not read my saying that the archtiecture permits something a= s > > saying it is either deisred or required by the work. It isn't. > > > > Yours, > > Joel > > > > On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> If you need to support 100 service chains, it will mean 16,000,000 > >> paths. That is larger than the routing table of a core router. > >> > >> Chang > >> > >> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>> The architecture allows a range of deployments, from 1 service path = to > >>> 160000 service paths. I would hope that operators are prepared for > >>> the complexities if they choose to avoid any use of local load > >>> balancing and in stead provision 160,000 service paths. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>> Paul, > >>>> > >>>> How many path identifiers there will be for a 4 hop service chain w= ith > >>>> 20 instances at each hop? > >>>> > >>>> Maria > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn > >>>> (paulq) > >>>> *Sent:* Thursday, July 10, 2014 3:03 PM > >>>> *To:* Lucy yong > >>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.o= rg; > >>>> mikebianc@aol.com > >>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Lucy, > >>>> > >>>> Overall I concur, as you say: a path ID drives the forwarding. I=92= d > make > >>>> the minor change: the path identifier can be used to derive the nee= ded > >>>> forwarding and associated transport. > >>>> > >>>> It is _not_ the transport, but rather is used to simply identify th= e > >>>> service path (or graph) that packets must traverse. By having a pat= h > >>>> identifier, the exact indirection that people seem to be asking for= on > >>>> this thread can be simply be implemented. The path identifier provi= des > >>>> nothing more than a lookup, that lookup can result in a one or more > >>>> (equal or weighted) transport next hop(s). > >>>> > >>>> Paul > >>>> > >>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>> > wrote: > >>>> > >>>> > >>>> > >>>> Agree. The arch. doc should not mandate only use of the service pat= h > >>>> identifier to drive the forwarding actions. > >>>> > >>>> Lucy > >>>> > >>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>> Of*mohamed.boucadair@orange.com > >>>> *Sent:*Thursday, July 10, 2014 2:06 AM > >>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.c= om > >>>> ;sfc@ietf.org > >>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Re-, > >>>> > >>>> The merged draft calls out explicitly a service path identifier. I > >>>> object to use that identifier to derive forwarding actions. > >>>> > >>>> Requiring a SFC system to have the full knowledge of every > available SFC > >>>> forwarding paths within an SFC-enabled domain is not > required/justified > >>>> nor possible in various deployment contexts. > >>>> > >>>> SFC forwarding actions should rely on the piece of information > that will > >>>> be present in all deployments: that is the one required to structur= e a > >>>> service chain. How that information is used to infer forwarding > actions > >>>> is a solution-oriented discussion. > >>>> > >>>> Cheers, > >>>> > >>>> Med > >>>> > >>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > de*mikebianc@aol.com > >>>> > >>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 > >>>> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.or= g > >>>> > >>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Is anyone still questioning the difference between SF Chain and SF > Path? > >>>> Other than clarifying the definition so that it's clear to > those not > >>>> familiar with the draft, it seems that everyone agrees on these ter= ms. > >>>> > >>>> To me, the one point that is still unclear is whether it is the int= ent > >>>> of this draft to ultimately specify what the ID of the SFC Header > should > >>>> reference (the chain or the path), or if this draft simply intends = to > >>>> leave that ambiguous, allowing other drafts to dictate the mechanis= ms > >>>> for forwarding based on chain or path and the choice of chain or > path to > >>>> be negotiated in the control-plane. > >>>> > >>>> If the latter (ambiguous), then the draft would have require that b= oth > >>>> SFP and SFC be supported (or make one required and the other option= al) > >>>> to avoid some vendors only supporting SFP and others only supportin= g > >>>> SFC. > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> *From:*jmh@joelhalpern.com >>>> > > >>>> *To:*sfc@ietf.org= > > >>>> *Sent:*Tuesday, July 8, 2014 > >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> I have been trying to figure out how to clearly answer a number of > >>>> comments that have been made about the proposed merged archtiecture > >>>> draft. Assuming we can get working group agreement on the intent, w= e > >>>> will work to improve the wording so that readers who have not > >>>> participated in the WG discussion will understnd it the way the > working > >>>> group intends. > >>>> > >>>> But what do we intend? I will try to explain my personal view, and = see > >>>> if that helps. > >>>> > >>>> In this regard, it is important to keep in mind that what we are > >>>> defining is the data plane architecture. We are not attempting to > >>>> define the architecture for the entire solution for service chainin= g. > >>>> That would encompass OSS/BSS, various control and policy functions, > >>>> virtual machine and image management, and many other aspects. > >>>> > >>>> As a result there are many things which clearly need to exist in th= e > >>>> larger system, but which are dealt with above where we are > functioning, > >>>> and are not directly required by the work we are doing. > >>>> > >>>> In order to get to service chain vs service path, as I understand > them, > >>>> I need to first discuss load balancing. There are at least three > >>>> different ways that load balancing can and will interact with servi= ce > >>>> chaining. There probably are more. The point of the archtiecture is= to > >>>> permit all of these, but not to mandate that any particular kind > be used > >>>> in any solution. > >>>> > >>>> 1) Load balancing as a service provided to the end user. This is a > >>>> service function. It receives user packets, and modifies them (or > marks > >>>> them, or ...) so as to choose an end user service instance to recei= ve > >>>> the users packet. This is an important service function to be able = to > >>>> include in service chaining. It's behavior may affect requirements = on > >>>> how service chaining is done. But it has very little impact on the > >>>> archtiecture. From an architectural pe3rspective it is simply a > service > >>>> function which may modify the underlying packet. > >>>> > >>>> 2) There is internal load balancing. That is, one can have what > appears > >>>> to the service chaining architecture as a single point of contact > for a > >>>> specific service function, but is actually delivered by a > collection of > >>>> virtual or physical machines, possibly including one or several loa= d > >>>> balancers (for example using VRRP-like techniques to share a MAC > >>>> address.) mostly, this is invisible to the service chaining data pl= ane > >>>> mechanisms. It is likely that it is visible to various control > >>>> mechanisms, such as those responsible for scale-in, scale-out, and = vm > >>>> instantiation. The architectural impact of permitting this is large= ly > >>>> that we need to be careful that our terminology does not lead > readers to > >>>> think we are prohibiting it. > >>>> > >>>> 3) There can also be load balancing done by selecting packet paths = for > >>>> the service chaining that direct traffic to different places. We wo= uld > >>>> not want to require that a given service function appear at only on= e > >>>> place in the network. > >>>> > >>>> It is of course the case that these may be combined. I tend to > refer to > >>>> the collection of entities that appear to service chaining as a sin= gle > >>>> point as a cluster. Not because cluster is a good term. But because= I > >>>> do not have another one. Thus, the point of type 3 load balancing > is to > >>>> direct different subsets of traffic to different singular or cluste= red > >>>> service functions in different places in the network. > >>>> > >>>> Now with that said, what do I mean when I talk about service chain = and > >>>> service path/ Service chain is a sequence of logical functions to b= e > >>>> applied to a subset of packets. It is equivalent of saying that som= e > >>>> subset of traffic is to get DPI, charging, content inspection, and > >>>> firewall while a different subset is to go directly to the cache > without > >>>> visiting any other service functions. > >>>> > >>>> That is not enough information to direct the packets. A service pat= h > >>>> is, in some fashion, a sequence of locations in the network. Those > >>>> locations will be singular or clustered service function delivery > >>>> locations. They may be addressed by IP address. They may be address= ed > >>>> as ports on an SFF. There are many different ways that the location= s > >>>> may be known to the service chaining infrastructure and the transpo= rt. > >>>> > >>>> >From the point of view of the work of the SFC group, we need to = be > >>>> able > >>>> to talk about the high level abstraction, the service chain, which > >>>> drives the forwarding. And we need to talk about the actual data pa= th > >>>> packets will take in the network. > >>>> > >>>> Several of the comments have said "but the whole path may not be kn= own > >>>> at the front." This architecture deals with that issue in two ways. > >>>> First, as noted in item (2) on load balancers above, there can be > >>>> decisions and behaviors which are invisible to the service chaining > >>>> mechanisms (in much the same way that bridging within a LAN is larg= ely > >>>> invisible to routing between LANs.) The other provision we make is > that > >>>> reclassification can be done in mid-chain when necessary. That will > >>>> direct packets to a new chain. Based on information available at th= e > >>>> re-classification point. > >>>> > >>>> I hope that this helps explain what we are after. If it does, and i= f > >>>> the intent is acceptable to the working group, we can figure out wh= at > >>>> additional words are needed to convey this. > >>>> If the working group disagree with the intent, then we will of cour= se > >>>> adjust to match the working group agreements. > >>>> If this is still unclear, I am not sure what to try next. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > >> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing 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 Jul 10 18:40: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 6AF121B2818 for ; Thu, 10 Jul 2014 18:40:06 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 oD0Oz2TSz-Wr for ; Thu, 10 Jul 2014 18:40:03 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68F91A063C for ; Thu, 10 Jul 2014 18:40:03 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 5A01053E05; Thu, 10 Jul 2014 18:40:01 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 18:40:01.327 -0700 x-echoworx-msg-id: b667747b-2955-4a13-a9b9-e09070de1e24 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 764; Thu, 10 Jul 2014 18:40:01 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 3932C53E05; Thu, 10 Jul 2014 18:40:01 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:40:02 -0700 From: Ron Parker To: "Zarny, Myo" , "'mikebianc@aol.com'" , "'jmh@joelhalpern.com'" , "'paulq@cisco.com'" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKYCAgAAB5wCAAAu/AIAAIrUAgAAB4gCAABK2AIAACJsAgAAftgD//76qMA== Date: Fri, 11 Jul 2014 01:40:02 +0000 Message-ID: References: <1916079416.1585.1405024782482.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: [98.229.164.153] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C1CMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dsR6PFYbhZuUo9gquqgDC3rgsOY Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 01:40:06 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C1CMBX021W3CA2exch_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "next-service-hop selection" ? ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Zarny, Myo [Myo.Zarny@gs.com] Sent: Thursday, July 10, 2014 6:33 PM To: 'mikebianc@aol.com'; 'jmh@joelhalpern.com'; 'paulq@cisco.com' Cc: 'sfc@ietf.org' Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I brought up GSLB only to illustrate that next-hop selection can be done in= some other way. But I think you get my point. To me, "traffic distribution" is an improvement over "load distribution" on= ly because it's not too close to load balancing. But I'm not wedded to it. = I'll be fine with any term that is less loaded and less likely to cause con= fusion. Myo From: mikebianc@aol.com [mailto:mikebianc@aol.com] Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard Time To: Zarny, Myo [Tech]; jmh@joelhalpern.com ; paulq@cis= co.com Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree that maybe 'load distribution' isn't the best name. What is importan= t is that it is distinguished from load balancing (which is also a poor nam= e). Maybe "Traffic Distribution' or 'Traffic Balancing' or do those names alrea= dy carry other significance? ________________________________ From: Myo.Zarny@gs.com To: 'jmh@joelhalpern.com','mikebianc@aol.com','paulq@cisco.com' cc: 'sfc@ietf.org' Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Using the term load distribution to refer to load balancer selection will b= e lost to a lot of people. Many people call it global sever load balancing. Plus, there could be multiple layers of "load distribution" / LB selection.= Not just two. For example, select a region from a global pool; once the re= gion is selected, select a data center in that region; in that DC, which DC= LB instance to go to; and then we have the traditional LB which selects th= e end server. In sum, (1) path selection could happen at more than 2 different tiers; (2)= "load" isn't the only criterion in those selections. I see the rationale f= or wanting the differentiation but is load distribution the best term for i= t? Regards, ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time To: mikebianc@aol.com ; paulq@cisco.com Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The term "load distribution" works for me. I agree that there is value in differentiating the functions, and using different words usually helps such differentiation. Yours, Joel On 7/10/14, 2:55 PM, mikebianc@aol.com wrote: > I've stated before that I think we should differentiate between load > balancing and load distribution where load balancing refers to the > standard service function that we all know and love (outside of SFC) and > load distribution refers to the selection of an SFI (i.e. Chain -> Path > mapping). Not using different terms to distinguish between these leads > to confusion. > > e.g. a SF Chain* might exist whose SFs consist only of load balancers. > But you might still want SFC* to distribute load to multiple load > balancer instances. > > *trying to distinguish between SFC as "Service Function Chaining" and a > single "Service Function Chain". > > > > > > > > ------------------------------------------------------------------------ > *From: *paulq@cisco.com > *To: *Joel M. Halpern > *cc: *Jim Guichard > (jguichar),sfc@ietf.org,mohamed.boucada= ir@orange.com,Ron > Parker,NAPIERALA, MARIA H > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Joel, > > I concur. The goal here is to address the issues associated with generic > service function deployment and should enable localized decisions such > as load balancing (perhaps more accurately load distribution). Clearly > we sound=92t codify how load distribution works. > > In order to enable load distribution, for example, the right > abstractions been to be clearly defined in the architecture, a key one > bering the distinction between path vs. chain. > > Paul > > > > On Jul 10, 2014, at 12:08 PM, Joel M. Halpern wrote= : > > > That is clearly an important problem in building a full solution to > the service chaining needs of operators (e.g. you). However, I could > equally observe that if you do not have OSS/BSS capable of provisioning > service chains, or charging systems capable of turning them into > revenue, you can't offer them. > > > > The SFC working group is tasked with one part of the whole service > chain definition, construction, and deployment problem. As I read the > charter, general load balancing issues are not part of our scope. > > Given the number of different ways there are of doing load balancing, > it would strike me as very odd for the sfc working group to standardize > a particular answer to the important and difficult problem you point to. > > > > The architecture (and I believe most of the solutions) is designed to > provide tools that help with managing that scaling, while also allowing > for the use of other tools. > > If the working group wants us to be more specific in the load > balancing architecture, then if the chairs tell us to we will add more > specific text. I would be surprised personally if we had agreement on > such a goal, or agreement on how to fill such a goal. But Carlos and I > will of course do what the chairs tell us the WG wants. > > > > Yours, > > Joel > > > > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote: > >> One of the main problems in "service chains" is how to implement a > service that is conceptually one hop but scaled horizontally as 10 or > 100 different VMs. > >> So, IMO, if we are not addressing this problem than what are we solvin= g. > >> > >> Maria > >> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C1CMBX021W3CA2exch_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
"next-service-hop selection" ?

From: sfc [sfc-bounces@ietf.org] on behal= f of Zarny, Myo [Myo.Zarny@gs.com]
Sent: Thursday, July 10, 2014 6:33 PM
To: 'mikebianc@aol.com'; 'jmh@joelhalpern.com'; 'paulq@cisco.com' Cc: 'sfc@ietf.org'
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I brought up GSLB only to illustrate that= next-hop selection can be done in some other way. But I think you get my p= oint.

To me, "traffic distribution" is an improvement over "load d= istribution" only because it's not too close to load balancing. But I'= m not wedded to it. I'll be fine with any term that is less loaded and less= likely to cause confusion.

Myo


 
From: mikebianc@aol.com [mailto:mikebianc@aol.com]
Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard Time
To: Zarny, Myo [Tech]; jmh@joelhalpern.com <jmh@joelhalpern.com&g= t;; paulq@cisco.com <paulq@cisco.com>
Cc: sfc@ietf.org <sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
 
Agree that maybe 'load distribution' isn't the best name.  What i= s important is that it is distinguished from load balancing (which is also = a poor name).

Maybe "Traffic Distribution' or 'Traffic Balancing' or do those n= ames already carry other significance?



From: Myo.Zarny@gs.com<Myo.Zarny@gs.com>
To: 'jmh@joelhalpern.com'<jmh@joelhalpern.com>,'mikebianc@aol.= com'<mikebianc@aol.com>,'paulq@cisco.com'<paulq@cisco.com>
cc: 'sfc@ietf.org'<sfc@ietf.org>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Using the term load distribution to refer to load balancer selection will b= e lost to a lot of people. Many people call it global sever load balancing.=

Plus, there could be multiple layers of "load distribution" / LB = selection. Not just two. For example, select a region from a global pool; o= nce the region is selected, select a data center in that region; in that DC= , which DC LB instance to go to; and then we have the traditional LB which selects the end server.

In sum, (1) path selection could happen at more than 2 different tiers; (2)= "load" isn't the only criterion in those selections. I see the r= ationale for wanting the differentiation but is load distribution the best = term for it?

Regards,



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


From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time
To: mikebianc@aol.com <mikebianc@aol.com>; paulq@cisco.com <paulq@= cisco.com>
Cc: sfc@ietf.org <sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

The term "load distribution" works for me. I agree that there is = value
in differentiating the functions, and using different words usually
helps such differentiation.

Yours,
Joel

On 7/10/14, 2:55 PM, mikebianc@aol.com wrote:
> I've stated before that I think we should differentiate between load > balancing and load distribution where load balancing refers to the
> standard service function that we all know and love (outside of SFC) a= nd
> load distribution refers to the selection of an SFI (i.e. Chain -> = Path
> mapping). Not using different terms to distinguish between these leads=
> to confusion.
>
> e.g. a SF Chain* might exist whose SFs consist only of load balancers.=
>   But you might still want SFC* to distribute load to multiple lo= ad
> balancer instances.
>
> *trying to distinguish between SFC as "Service Function Chaining&= quot; and a
> single "Service Function Chain".
>
>
>
>
>
>
>
> ----------------------------------------------------------------------= --
> *From: *paulq@cisco.com<paulq@cisco.com>
> *To: *Joel M. Halpern<jmh@joelhalpern.com>
> *cc: *Jim Guichard
> (jguichar)<jguichar@cisco.com>,sfc@ietf.org<sfc@ietf.org>,= mohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,Ron
> Parker<Ron_Parker@affirmednetworks.com>,NAPIERALA, MARIA H<mn= 1921@att.com>
> *Sent: *Thursday, July 10, 2014
> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Joel,
>
> I concur. The goal here is to address the issues associated with gener= ic
> service function deployment and should enable localized decisions such=
> as load balancing (perhaps more accurately load distribution). Clearly=
> we sound=92t codify how load distribution works.
>
> In order to enable load distribution, for example, the right
> abstractions been to be clearly defined in the architecture, a key one=
> bering the distinction between path vs. chain.
>
> Paul
>
>
>
> On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <jmh@joelhalpern.com&= gt; wrote:
>
> > That is clearly an important problem in building a full solution = to
> the service chaining needs of operators (e.g. you). However, I could > equally observe that if you do not have OSS/BSS capable of provisionin= g
> service chains, or charging systems capable of turning them into
> revenue, you can't offer them.
> >
> > The SFC working group is tasked with one part of the whole servic= e
> chain definition, construction, and deployment problem. As I read the<= br class=3D""> > charter, general load balancing issues are not part of our scope.
> > Given the number of different ways there are of doing load balanc= ing,
> it would strike me as very odd for the sfc working group to standardiz= e
> a particular answer to the important and difficult problem you point t= o.
> >
> > The architecture (and I believe most of the solutions) is designe= d to
> provide tools that help with managing that scaling, while also allowin= g
> for the use of other tools.
> > If the working group wants us to be more specific in the load
> balancing architecture, then if the chairs tell us to we will add more=
> specific text. I would be surprised personally if we had agreement on<= br class=3D""> > such a goal, or agreement on how to fill such a goal. But Carlos and I=
> will of course do what the chairs tell us the WG wants.
> >
> > Yours,
> > Joel
> >
> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote:
> >> One of the main problems in "service chains" is how= to implement a
> service that is conceptually one hop but scaled horizontally as 10 or<= br class=3D""> > 100 different VMs.
> >> So, IMO, if we are not addressing this problem than what are = we solving.
> >>
> >> Maria
> >>
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C1CMBX021W3CA2exch_-- From nobody Thu Jul 10 18:45: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 D737F1B290F for ; Thu, 10 Jul 2014 18:45:30 -0700 (PDT) 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_29=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 jl_gpWPS-DV8 for ; Thu, 10 Jul 2014 18:45:27 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BC31A063C for ; Thu, 10 Jul 2014 18:45:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id A3DA98427EE; Thu, 10 Jul 2014 18:45:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 5575B8427F0; Thu, 10 Jul 2014 18:45:25 -0700 (PDT) Message-ID: <53BF41B4.3080107@joelhalpern.com> Date: Thu, 10 Jul 2014 21:45:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker , Joel Halpern Direct , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_bD665iXInwOn9sTcPqQr0CzJnU Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 01:45:31 -0000 This is an architectural issue. And one that I would prefer we actually decide, rather than trying to allow all possible implementations. Because it does have a major effect on the control requirements and the functionality of SFFs. For me, the amount of information about service instances that needs to be widely distributed and maintained, potentially even across data centers within an administrative scope, is large enough and complex enough that trying to get that into each SFF seems like a difficult architecture to realize. Yours, Joel But it is a fair question. On 7/10/14, 9:38 PM, Ron Parker wrote: > This is the crux of my issue. Is the end to end selection of > (top-level) instances performed centrally (perhaps by the classifier) > or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? > Such selection is not equivalent to reclassification. And surely, > this is an architectural issue and not relegated to > "implementation". > > My own view is to favor the distributed approach even though a > greater amount of data (chain definitions and perhaps local selection > policy) is required at those distributed decision points. This > approach does not require an end-to-end path id at all. My > rationale for favoring this approach is primarily driven by increased > resiliency over the global path id approach. With a global path id > approach, consider failure of an instance and needing to alter the > global path ID table for each and every affected end-to-end path. > > Ron > > ________________________________________ From: sfc > [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > [sfc] Service Chains, Paths, and Load Balancers > > The way the architecture models the case of SF1 needing to influence > the chain is that one would do reclassification at the exit from > SF1. > > Part of the goal is to keep the different functions logically > separate so that solutions can clearly describe how they choose to > compose them for "service" delivery. > > Yours, Joel > > On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> I don't see anything in the arch draft that suggests any sort of >> limit. However, it does seem to indicate that the entire path (all >> SFIs) must be chosen at SFC instantiation. I believe this means >> either at the classifier or maybe the classifier chooses a SF Chain >> and the NF or at the latest the first SFF. In any case, the >> language does seem to prohibit a more dynamic SFP where SFI(n) is >> determined at the SFI(n-1) hop. According to the draft, this >> behavior would be considered "branching" to a new SFP as opposed to >> choosing and then forwarding to the selected instance of the >> next-hop of the current SFC. >> >> draft-merged-sfc-architecture-00: >>> When an SFC is instantiated into the network it is necessary to >>> select the specific instances of SFs that will be used, and to >>> create the service topology for that SFC using SF's network >>> locator. Thus, instantiation of the SFC results in the creation >>> of a Service Function Path (SFP) and is used for forwarding >>> packets through the SFC. In other words, an SFP is the >>> instantiation of the defined SFC. >>> >>> The SFC architecture supports reclassification (or non-initial >>> classification) as well. As packets traverse an SFP, >>> reclassification may occur - typically performed by a >>> classification function co-resident with a service function. >>> Reclassification may result in the selection of a new SFP, an >>> update of the associated metadata, or both. This is referred to >>> as "branching". >> >> >> >> ------------------------------------------------------------------------ >> >> *From: *I.Smith@F5.com >> *To: *Joel Halpern Direct,Joel M. >> Halpern,huang@sce.carleton.ca,sfc@ietf.org >> >> *Sent: *Thursday, July 10, 2014 >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Actually, I think I am disagreeing. >> >> If the possibility of medium-scale deployments (and that is what >> 16 million flows is in my world) of service chains is preconceived >> as an absurd idea, then the architecture burdened with that >> preconception. >> >> There has to be some point of aim, some degree of aspiration to >> scale that is appropriate for the lifespan of the architecture - >> you don't have to know what it is, but by saying that an arbitrary >> number is "too far", you're creating - even if it isn't intentional >> - a limit that influences decisions that have lasting impacts >> regarding scale-out, failure mitigation, elasticity, address >> space... all kinds of things. That is a problem I'm not >> particularly eager to deal with. >> >> >> >> >> ________________________________________ >> >> >> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >> Chains, Paths, and Load Balancers >> >> Ian, I don't think you disagree with me at all in this regard. I am >> not requesting the the architecture or the solution prohibit >> deployments in the specific fashion. I am objecting to Huang's >> reading of my note as saying that such deployments are required >> they by the archtiecture. >> >> As I have said repeatedly, I am not trying to prohibit such >> things. Whether they are a good idea or not depends upon many >> factors outside of the scope of the WG. I happen to think that they >> are usually a bad idea. >> >> But the archtiecture si carefully avoiding attempting to know what >> is and is not eployable. >> >> Yours, Joel >> >> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> I disagree. >>> >>> We routinely have stateful devices that manage tens of millions >>> of >> concurrent flows in both access network and data center >> environments today. You can't seriously believe that in the >> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >> to have small numbers of service chains with equally small numbers >> of active service paths? >>> >>> Your sounds too much like "no one will ever need more than 64K" >>> for >> comfort. >>> >>> >>> ________________________________________ From: sfc >>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> [jmh@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>> Balancers >>> >>> No, it will mean that if someone tries to deploy the archtieture >>> particularly badly, they will exceed the limits of their >>> devices. The architecture does not require such absurd use of >>> service paths. Since I can not figure out how to write >>> architectural words to prohibit it, the architecture does permit >>> such abuse. >>> >>> Please do not read my saying that the archtiecture permits >>> something as saying it is either deisred or required by the work. >>> It isn't. >>> >>> Yours, Joel >>> >>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>> If you need to support 100 service chains, it will mean >>>> 16,000,000 paths. That is larger than the routing table of a >>>> core router. >>>> >>>> Chang >>>> >>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>> The architecture allows a range of deployments, from 1 >>>>> service path to 160000 service paths. I would hope that >>>>> operators are prepared for the complexities if they choose to >>>>> avoid any use of local load balancing and in stead provision >>>>> 160,000 service paths. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>> Paul, >>>>>> >>>>>> How many path identifiers there will be for a 4 hop service >>>>>> chain with 20 instances at each hop? >>>>>> >>>>>> Maria >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Lucy, >>>>>> >>>>>> Overall I concur, as you say: a path ID drives the >>>>>> forwarding. I’d >> make >>>>>> the minor change: the path identifier can be used to derive >>>>>> the needed forwarding and associated transport. >>>>>> >>>>>> It is _not_ the transport, but rather is used to simply >>>>>> identify the service path (or graph) that packets must >>>>>> traverse. By having a path identifier, the exact >>>>>> indirection that people seem to be asking for on this >>>>>> thread can be simply be implemented. The path identifier >>>>>> provides nothing more than a lookup, that lookup can result >>>>>> in a one or more (equal or weighted) transport next >>>>>> hop(s). >>>>>> >>>>>> Paul >>>>>> >>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Agree. The arch. doc should not mandate only use of the >>>>>> service path identifier to drive the forwarding actions. >>>>>> >>>>>> Lucy >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>> Of*mohamed.boucadair@orange.com >>>>>> *Sent:*Thursday, July >>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>> ;jmh@joelhalpern.com >>>>>> ;sfc@ietf.org >>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Re-, >>>>>> >>>>>> The merged draft calls out explicitly a service path >>>>>> identifier. I object to use that identifier to derive >>>>>> forwarding actions. >>>>>> >>>>>> Requiring a SFC system to have the full knowledge of every >> available SFC >>>>>> forwarding paths within an SFC-enabled domain is not >> required/justified >>>>>> nor possible in various deployment contexts. >>>>>> >>>>>> SFC forwarding actions should rely on the piece of >>>>>> information >> that will >>>>>> be present in all deployments: that is the one required to >>>>>> structure a service chain. How that information is used to >>>>>> infer forwarding >> actions >>>>>> is a solution-oriented discussion. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> de*mikebianc@aol.com >>>>>> *Envoyé :*mercredi 9 juillet >>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>> ;sfc@ietf.org >>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Is anyone still questioning the difference between SF Chain >>>>>> and SF >> Path? >>>>>> Other than clarifying the definition so that it's clear to >> those not >>>>>> familiar with the draft, it seems that everyone agrees on >>>>>> these terms. >>>>>> >>>>>> To me, the one point that is still unclear is whether it is >>>>>> the intent of this draft to ultimately specify what the ID >>>>>> of the SFC Header >> should >>>>>> reference (the chain or the path), or if this draft simply >>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>> dictate the mechanisms for forwarding based on chain or >>>>>> path and the choice of chain or >> path to >>>>>> be negotiated in the control-plane. >>>>>> >>>>>> If the latter (ambiguous), then the draft would have >>>>>> require that both SFP and SFC be supported (or make one >>>>>> required and the other optional) to avoid some vendors only >>>>>> supporting SFP and others only supporting SFC. >>>>>> >>>>>> >> ------------------------------------------------------------------------ >> >> >>>> >>>>>> *From:*jmh@joelhalpern.com>>>>> > >>>>>> *To:*sfc@ietf.org>>>>> > *Sent:*Tuesday, July >>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>> Balancers >>>>>> >>>>>> I have been trying to figure out how to clearly answer a >>>>>> number of comments that have been made about the proposed >>>>>> merged archtiecture draft. Assuming we can get working >>>>>> group agreement on the intent, we will work to improve the >>>>>> wording so that readers who have not participated in the WG >>>>>> discussion will understnd it the way the >> working >>>>>> group intends. >>>>>> >>>>>> But what do we intend? I will try to explain my personal >>>>>> view, and see if that helps. >>>>>> >>>>>> In this regard, it is important to keep in mind that what >>>>>> we are defining is the data plane architecture. We are not >>>>>> attempting to define the architecture for the entire >>>>>> solution for service chaining. That would encompass >>>>>> OSS/BSS, various control and policy functions, virtual >>>>>> machine and image management, and many other aspects. >>>>>> >>>>>> As a result there are many things which clearly need to >>>>>> exist in the larger system, but which are dealt with above >>>>>> where we are >> functioning, >>>>>> and are not directly required by the work we are doing. >>>>>> >>>>>> In order to get to service chain vs service path, as I >>>>>> understand >> them, >>>>>> I need to first discuss load balancing. There are at least >>>>>> three different ways that load balancing can and will >>>>>> interact with service chaining. There probably are more. >>>>>> The point of the archtiecture is to permit all of these, >>>>>> but not to mandate that any particular kind >> be used >>>>>> in any solution. >>>>>> >>>>>> 1) Load balancing as a service provided to the end user. >>>>>> This is a service function. It receives user packets, and >>>>>> modifies them (or >> marks >>>>>> them, or ...) so as to choose an end user service instance >>>>>> to receive the users packet. This is an important service >>>>>> function to be able to include in service chaining. It's >>>>>> behavior may affect requirements on how service chaining is >>>>>> done. But it has very little impact on the archtiecture. >>>>>> From an architectural pe3rspective it is simply a >> service >>>>>> function which may modify the underlying packet. >>>>>> >>>>>> 2) There is internal load balancing. That is, one can have >>>>>> what >> appears >>>>>> to the service chaining architecture as a single point of >>>>>> contact >> for a >>>>>> specific service function, but is actually delivered by a >> collection of >>>>>> virtual or physical machines, possibly including one or >>>>>> several load balancers (for example using VRRP-like >>>>>> techniques to share a MAC address.) mostly, this is >>>>>> invisible to the service chaining data plane mechanisms. It >>>>>> is likely that it is visible to various control mechanisms, >>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>> instantiation. The architectural impact of permitting this >>>>>> is largely that we need to be careful that our terminology >>>>>> does not lead >> readers to >>>>>> think we are prohibiting it. >>>>>> >>>>>> 3) There can also be load balancing done by selecting >>>>>> packet paths for the service chaining that direct traffic >>>>>> to different places. We would not want to require that a >>>>>> given service function appear at only one place in the >>>>>> network. >>>>>> >>>>>> It is of course the case that these may be combined. I tend >>>>>> to >> refer to >>>>>> the collection of entities that appear to service chaining >>>>>> as a single point as a cluster. Not because cluster is a >>>>>> good term. But because I do not have another one. Thus, the >>>>>> point of type 3 load balancing >> is to >>>>>> direct different subsets of traffic to different singular >>>>>> or clustered service functions in different places in the >>>>>> network. >>>>>> >>>>>> Now with that said, what do I mean when I talk about >>>>>> service chain and service path/ Service chain is a sequence >>>>>> of logical functions to be applied to a subset of packets. >>>>>> It is equivalent of saying that some subset of traffic is >>>>>> to get DPI, charging, content inspection, and firewall >>>>>> while a different subset is to go directly to the cache >> without >>>>>> visiting any other service functions. >>>>>> >>>>>> That is not enough information to direct the packets. A >>>>>> service path is, in some fashion, a sequence of locations >>>>>> in the network. Those locations will be singular or >>>>>> clustered service function delivery locations. They may be >>>>>> addressed by IP address. They may be addressed as ports on >>>>>> an SFF. There are many different ways that the locations >>>>>> may be known to the service chaining infrastructure and the >>>>>> transport. >>>>>> >>>>>>> From the point of view of the work of the SFC group, we >>>>>>> need to be >>>>>> able to talk about the high level abstraction, the service >>>>>> chain, which drives the forwarding. And we need to talk >>>>>> about the actual data path packets will take in the >>>>>> network. >>>>>> >>>>>> Several of the comments have said "but the whole path may >>>>>> not be known at the front." This architecture deals with >>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>> balancers above, there can be decisions and behaviors which >>>>>> are invisible to the service chaining mechanisms (in much >>>>>> the same way that bridging within a LAN is largely >>>>>> invisible to routing between LANs.) The other provision we >>>>>> make is >> that >>>>>> reclassification can be done in mid-chain when necessary. >>>>>> That will direct packets to a new chain. Based on >>>>>> information available at the re-classification point. >>>>>> >>>>>> I hope that this helps explain what we are after. If it >>>>>> does, and if the intent is acceptable to the working group, >>>>>> we can figure out what additional words are needed to >>>>>> convey this. If the working group disagree with the intent, >>>>>> then we will of course adjust to match the working group >>>>>> agreements. If this is still unclear, I am not sure what to >>>>>> try next. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ sfc mailing >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ sfc mailing list >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing 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 Jul 10 18:57: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 73D661B290E for ; Thu, 10 Jul 2014 18:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 m4-hb0M_-MMD for ; Thu, 10 Jul 2014 18:56:58 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC441B2816 for ; Thu, 10 Jul 2014 18:56:57 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 6D1C853DFD; Thu, 10 Jul 2014 18:56:55 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 10 Jul 2014 18:56:55.357 -0700 x-echoworx-msg-id: f2140360-e537-495d-810e-fdf8871867a3 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 289; Thu, 10 Jul 2014 18:56:55 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 400AF53DFD; Thu, 10 Jul 2014 18:56:55 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Thu, 10 Jul 2014 18:56:57 -0700 From: Ron Parker To: "Joel M. Halpern" , Joel Halpern Direct , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgCAAEJogIAAEcsAgAACqYCAAAXpAIAAAr6AgAAD/4CAAADcAIAAAwUAgAAPmoCAAAFcgP//wGdrgAB6MgD//40T1g== Date: Fri, 11 Jul 2014 01:56:56 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> In-Reply-To: <53BF41B4.3080107@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nHaUUinOkC_TmN19LOTvVsvLq8E Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 01:57:00 -0000 Joel, The administrative scope issue is common to both the centralized and distri= buted next-service-hop approaches in terms of difficulty in gathering the r= equired data. Once acquired, distribution of that data to fewer entities = (ingress nodes) or more entities (ingress nodes plus SFFs) does not seem to= be a deal breaker. Especially since SFF is a construct of our invention = with responsibilities determined at our whim. Ron From: Joel M. Halpern [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; I.Smith@F5.com; sfc= @ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers This is an architectural issue. And one that I would prefer we actually decide, rather than trying to allow all possible implementations. Because it does have a major effect on the control requirements and the functionality of SFFs. For me, the amount of information about service instances that needs to be widely distributed and maintained, potentially even across data centers within an administrative scope, is large enough and complex enough that trying to get that into each SFF seems like a difficult architecture to realize. Yours, Joel But it is a fair question. On 7/10/14, 9:38 PM, Ron Parker wrote: > This is the crux of my issue. Is the end to end selection of > (top-level) instances performed centrally (perhaps by the classifier) > or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? > Such selection is not equivalent to reclassification. And surely, > this is an architectural issue and not relegated to > "implementation". > > My own view is to favor the distributed approach even though a > greater amount of data (chain definitions and perhaps local selection > policy) is required at those distributed decision points. This > approach does not require an end-to-end path id at all. My > rationale for favoring this approach is primarily driven by increased > resiliency over the global path id approach. With a global path id > approach, consider failure of an instance and needing to alter the > global path ID table for each and every affected end-to-end path. > > Ron > > ________________________________________ From: sfc > [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > [sfc] Service Chains, Paths, and Load Balancers > > The way the architecture models the case of SF1 needing to influence > the chain is that one would do reclassification at the exit from > SF1. > > Part of the goal is to keep the different functions logically > separate so that solutions can clearly describe how they choose to > compose them for "service" delivery. > > Yours, Joel > > On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> I don't see anything in the arch draft that suggests any sort of >> limit. However, it does seem to indicate that the entire path (all >> SFIs) must be chosen at SFC instantiation. I believe this means >> either at the classifier or maybe the classifier chooses a SF Chain >> and the NF or at the latest the first SFF. In any case, the >> language does seem to prohibit a more dynamic SFP where SFI(n) is >> determined at the SFI(n-1) hop. According to the draft, this >> behavior would be considered "branching" to a new SFP as opposed to >> choosing and then forwarding to the selected instance of the >> next-hop of the current SFC. >> >> draft-merged-sfc-architecture-00: >>> When an SFC is instantiated into the network it is necessary to >>> select the specific instances of SFs that will be used, and to >>> create the service topology for that SFC using SF's network >>> locator. Thus, instantiation of the SFC results in the creation >>> of a Service Function Path (SFP) and is used for forwarding >>> packets through the SFC. In other words, an SFP is the >>> instantiation of the defined SFC. >>> >>> The SFC architecture supports reclassification (or non-initial >>> classification) as well. As packets traverse an SFP, >>> reclassification may occur - typically performed by a >>> classification function co-resident with a service function. >>> Reclassification may result in the selection of a new SFP, an >>> update of the associated metadata, or both. This is referred to >>> as "branching". >> >> >> >> ------------------------------------------------------------------------ >> >> *From: *I.Smith@F5.com >> *To: *Joel Halpern Direct,Joel M. >> Halpern,huang@sce.carleton.ca,sfc@ietf.org >> >> *Sent: *Thursday, July 10, 2014 >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Actually, I think I am disagreeing. >> >> If the possibility of medium-scale deployments (and that is what >> 16 million flows is in my world) of service chains is preconceived >> as an absurd idea, then the architecture burdened with that >> preconception. >> >> There has to be some point of aim, some degree of aspiration to >> scale that is appropriate for the lifespan of the architecture - >> you don't have to know what it is, but by saying that an arbitrary >> number is "too far", you're creating - even if it isn't intentional >> - a limit that influences decisions that have lasting impacts >> regarding scale-out, failure mitigation, elasticity, address >> space... all kinds of things. That is a problem I'm not >> particularly eager to deal with. >> >> >> >> >> ________________________________________ >> >> >> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >> Chains, Paths, and Load Balancers >> >> Ian, I don't think you disagree with me at all in this regard. I am >> not requesting the the architecture or the solution prohibit >> deployments in the specific fashion. I am objecting to Huang's >> reading of my note as saying that such deployments are required >> they by the archtiecture. >> >> As I have said repeatedly, I am not trying to prohibit such >> things. Whether they are a good idea or not depends upon many >> factors outside of the scope of the WG. I happen to think that they >> are usually a bad idea. >> >> But the archtiecture si carefully avoiding attempting to know what >> is and is not eployable. >> >> Yours, Joel >> >> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> I disagree. >>> >>> We routinely have stateful devices that manage tens of millions >>> of >> concurrent flows in both access network and data center >> environments today. You can't seriously believe that in the >> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >> to have small numbers of service chains with equally small numbers >> of active service paths? >>> >>> Your sounds too much like "no one will ever need more than 64K" >>> for >> comfort. >>> >>> >>> ________________________________________ From: sfc >>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> [jmh@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>> Balancers >>> >>> No, it will mean that if someone tries to deploy the archtieture >>> particularly badly, they will exceed the limits of their >>> devices. The architecture does not require such absurd use of >>> service paths. Since I can not figure out how to write >>> architectural words to prohibit it, the architecture does permit >>> such abuse. >>> >>> Please do not read my saying that the archtiecture permits >>> something as saying it is either deisred or required by the work. >>> It isn't. >>> >>> Yours, Joel >>> >>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>> If you need to support 100 service chains, it will mean >>>> 16,000,000 paths. That is larger than the routing table of a >>>> core router. >>>> >>>> Chang >>>> >>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>> The architecture allows a range of deployments, from 1 >>>>> service path to 160000 service paths. I would hope that >>>>> operators are prepared for the complexities if they choose to >>>>> avoid any use of local load balancing and in stead provision >>>>> 160,000 service paths. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>> Paul, >>>>>> >>>>>> How many path identifiers there will be for a 4 hop service >>>>>> chain with 20 instances at each hop? >>>>>> >>>>>> Maria >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Lucy, >>>>>> >>>>>> Overall I concur, as you say: a path ID drives the >>>>>> forwarding. I=92d >> make >>>>>> the minor change: the path identifier can be used to derive >>>>>> the needed forwarding and associated transport. >>>>>> >>>>>> It is _not_ the transport, but rather is used to simply >>>>>> identify the service path (or graph) that packets must >>>>>> traverse. By having a path identifier, the exact >>>>>> indirection that people seem to be asking for on this >>>>>> thread can be simply be implemented. The path identifier >>>>>> provides nothing more than a lookup, that lookup can result >>>>>> in a one or more (equal or weighted) transport next >>>>>> hop(s). >>>>>> >>>>>> Paul >>>>>> >>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Agree. The arch. doc should not mandate only use of the >>>>>> service path identifier to drive the forwarding actions. >>>>>> >>>>>> Lucy >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>> Of*mohamed.boucadair@orange.com >>>>>> *Sent:*Thursday, July >>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>> ;jmh@joelhalpern.com >>>>>> ;sfc@ietf.org >>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Re-, >>>>>> >>>>>> The merged draft calls out explicitly a service path >>>>>> identifier. I object to use that identifier to derive >>>>>> forwarding actions. >>>>>> >>>>>> Requiring a SFC system to have the full knowledge of every >> available SFC >>>>>> forwarding paths within an SFC-enabled domain is not >> required/justified >>>>>> nor possible in various deployment contexts. >>>>>> >>>>>> SFC forwarding actions should rely on the piece of >>>>>> information >> that will >>>>>> be present in all deployments: that is the one required to >>>>>> structure a service chain. How that information is used to >>>>>> infer forwarding >> actions >>>>>> is a solution-oriented discussion. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> de*mikebianc@aol.com >>>>>> *Envoy=E9 :*mercredi 9 juillet >>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >>>>>> ;sfc@ietf.org >>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>> Paths, and Load Balancers >>>>>> >>>>>> Is anyone still questioning the difference between SF Chain >>>>>> and SF >> Path? >>>>>> Other than clarifying the definition so that it's clear to >> those not >>>>>> familiar with the draft, it seems that everyone agrees on >>>>>> these terms. >>>>>> >>>>>> To me, the one point that is still unclear is whether it is >>>>>> the intent of this draft to ultimately specify what the ID >>>>>> of the SFC Header >> should >>>>>> reference (the chain or the path), or if this draft simply >>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>> dictate the mechanisms for forwarding based on chain or >>>>>> path and the choice of chain or >> path to >>>>>> be negotiated in the control-plane. >>>>>> >>>>>> If the latter (ambiguous), then the draft would have >>>>>> require that both SFP and SFC be supported (or make one >>>>>> required and the other optional) to avoid some vendors only >>>>>> supporting SFP and others only supporting SFC. >>>>>> >>>>>> >> ------------------------------------------------------------------------ >> >> >>>> >>>>>> *From:*jmh@joelhalpern.com>>>>> > >>>>>> *To:*sfc@ietf.org>>>>> > *Sent:*Tuesday, July >>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>> Balancers >>>>>> >>>>>> I have been trying to figure out how to clearly answer a >>>>>> number of comments that have been made about the proposed >>>>>> merged archtiecture draft. Assuming we can get working >>>>>> group agreement on the intent, we will work to improve the >>>>>> wording so that readers who have not participated in the WG >>>>>> discussion will understnd it the way the >> working >>>>>> group intends. >>>>>> >>>>>> But what do we intend? I will try to explain my personal >>>>>> view, and see if that helps. >>>>>> >>>>>> In this regard, it is important to keep in mind that what >>>>>> we are defining is the data plane architecture. We are not >>>>>> attempting to define the architecture for the entire >>>>>> solution for service chaining. That would encompass >>>>>> OSS/BSS, various control and policy functions, virtual >>>>>> machine and image management, and many other aspects. >>>>>> >>>>>> As a result there are many things which clearly need to >>>>>> exist in the larger system, but which are dealt with above >>>>>> where we are >> functioning, >>>>>> and are not directly required by the work we are doing. >>>>>> >>>>>> In order to get to service chain vs service path, as I >>>>>> understand >> them, >>>>>> I need to first discuss load balancing. There are at least >>>>>> three different ways that load balancing can and will >>>>>> interact with service chaining. There probably are more. >>>>>> The point of the archtiecture is to permit all of these, >>>>>> but not to mandate that any particular kind >> be used >>>>>> in any solution. >>>>>> >>>>>> 1) Load balancing as a service provided to the end user. >>>>>> This is a service function. It receives user packets, and >>>>>> modifies them (or >> marks >>>>>> them, or ...) so as to choose an end user service instance >>>>>> to receive the users packet. This is an important service >>>>>> function to be able to include in service chaining. It's >>>>>> behavior may affect requirements on how service chaining is >>>>>> done. But it has very little impact on the archtiecture. >>>>>> From an architectural pe3rspective it is simply a >> service >>>>>> function which may modify the underlying packet. >>>>>> >>>>>> 2) There is internal load balancing. That is, one can have >>>>>> what >> appears >>>>>> to the service chaining architecture as a single point of >>>>>> contact >> for a >>>>>> specific service function, but is actually delivered by a >> collection of >>>>>> virtual or physical machines, possibly including one or >>>>>> several load balancers (for example using VRRP-like >>>>>> techniques to share a MAC address.) mostly, this is >>>>>> invisible to the service chaining data plane mechanisms. It >>>>>> is likely that it is visible to various control mechanisms, >>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>> instantiation. The architectural impact of permitting this >>>>>> is largely that we need to be careful that our terminology >>>>>> does not lead >> readers to >>>>>> think we are prohibiting it. >>>>>> >>>>>> 3) There can also be load balancing done by selecting >>>>>> packet paths for the service chaining that direct traffic >>>>>> to different places. We would not want to require that a >>>>>> given service function appear at only one place in the >>>>>> network. >>>>>> >>>>>> It is of course the case that these may be combined. I tend >>>>>> to >> refer to >>>>>> the collection of entities that appear to service chaining >>>>>> as a single point as a cluster. Not because cluster is a >>>>>> good term. But because I do not have another one. Thus, the >>>>>> point of type 3 load balancing >> is to >>>>>> direct different subsets of traffic to different singular >>>>>> or clustered service functions in different places in the >>>>>> network. >>>>>> >>>>>> Now with that said, what do I mean when I talk about >>>>>> service chain and service path/ Service chain is a sequence >>>>>> of logical functions to be applied to a subset of packets. >>>>>> It is equivalent of saying that some subset of traffic is >>>>>> to get DPI, charging, content inspection, and firewall >>>>>> while a different subset is to go directly to the cache >> without >>>>>> visiting any other service functions. >>>>>> >>>>>> That is not enough information to direct the packets. A >>>>>> service path is, in some fashion, a sequence of locations >>>>>> in the network. Those locations will be singular or >>>>>> clustered service function delivery locations. They may be >>>>>> addressed by IP address. They may be addressed as ports on >>>>>> an SFF. There are many different ways that the locations >>>>>> may be known to the service chaining infrastructure and the >>>>>> transport. >>>>>> >>>>>>> From the point of view of the work of the SFC group, we >>>>>>> need to be >>>>>> able to talk about the high level abstraction, the service >>>>>> chain, which drives the forwarding. And we need to talk >>>>>> about the actual data path packets will take in the >>>>>> network. >>>>>> >>>>>> Several of the comments have said "but the whole path may >>>>>> not be known at the front." This architecture deals with >>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>> balancers above, there can be decisions and behaviors which >>>>>> are invisible to the service chaining mechanisms (in much >>>>>> the same way that bridging within a LAN is largely >>>>>> invisible to routing between LANs.) The other provision we >>>>>> make is >> that >>>>>> reclassification can be done in mid-chain when necessary. >>>>>> That will direct packets to a new chain. Based on >>>>>> information available at the re-classification point. >>>>>> >>>>>> I hope that this helps explain what we are after. If it >>>>>> does, and if the intent is acceptable to the working group, >>>>>> we can figure out what additional words are needed to >>>>>> convey this. If the working group disagree with the intent, >>>>>> then we will of course adjust to match the working group >>>>>> agreements. If this is still unclear, I am not sure what to >>>>>> try next. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ sfc mailing >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ sfc mailing list >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ sfc mailing 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 Jul 10 18:58: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 773CA1B290E for ; Thu, 10 Jul 2014 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.052 X-Spam-Level: X-Spam-Status: No, score=-7.052 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 J5XUDHqXLawI for ; Thu, 10 Jul 2014 18:58:28 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860741B2816 for ; Thu, 10 Jul 2014 18:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405043908; x=1436579908; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RQq1TrqrZYCjbFW4VP+vyDLmSoACDbUlvzzeODg5uks=; b=IvgQancYH+pPOFpXds3IkkotlnRX1E3Kphk1Ggmy4HVyboFq3sL8ZNFJ MlLOdoq9b9/IDplfEkNS0gy5JRZK9glKSWuoh+hF8EVHzChEpoj/8UjnM fR7TmVc5wM7bU1CIHcqFkFL9gXZ1wFG7MF8OT8i8e0wBpmdRFMd8KXNy7 c=; X-IronPort-AV: E=Sophos;i="5.01,641,1400025600"; d="scan'208";a="121444402" X-IPAS-Result: AqYEAEtEv1PAqArr/2dsb2JhbABPCoNgWq5tkXgKh0IBgSF1hAMBAQEBAwEBAWIJAhkCAQgRAQMBAQEKHQcnCxQDBggCBAESCBOIEwMexhoTBI0ZgU8FJjgCgyuBFgWWIEaPfYt1gW9B Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 11 Jul 2014 01:58:27 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 18:58:26 -0700 From: Ian Smith To: "Joel M. Halpern" , Ron Parker , Joel Halpern Direct , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAIeGgIAAAVyAgAA4u4CAAAHeAP//jZBD Date: Fri, 11 Jul 2014 01:58:25 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> In-Reply-To: <53BF41B4.3080107@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.167] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4IGAWQijSsbZ4Vqx5cvQBlhf0Fk Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 01:58:32 -0000 >For me, the amount of information about service instances that needs to=0A= >be widely distributed and maintained, potentially even across data=0A= >centers within an administrative scope, is large enough and complex=0A= >enough that trying to get that into each SFF seems like a difficult=0A= >architecture to realize.=0A= =0A= I'm curious as to why that is more complicated than dynamic routing, hyper-= scale data center orchestration, or DNS, all of which are bigger problems t= hat have been profitably and stably implemented?=0A= =0A= It also seems that if it really is more complicated, that is a good sign th= at it is too complicated.=0A= =0A= ________________________________________=0A= From: Joel M. Halpern [jmh@joelhalpern.com]=0A= Sent: Thursday, July 10, 2014 9:45 PM=0A= To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; sfc@ietf= .org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= This is an architectural issue. And one that I would prefer we actually=0A= decide, rather than trying to allow all possible implementations.=0A= Because it does have a major effect on the control requirements and the=0A= functionality of SFFs.=0A= =0A= For me, the amount of information about service instances that needs to=0A= be widely distributed and maintained, potentially even across data=0A= centers within an administrative scope, is large enough and complex=0A= enough that trying to get that into each SFF seems like a difficult=0A= architecture to realize.=0A= =0A= Yours,=0A= Joel=0A= =0A= But it is a fair question.=0A= =0A= On 7/10/14, 9:38 PM, Ron Parker wrote:=0A= > This is the crux of my issue. Is the end to end selection of=0A= > (top-level) instances performed centrally (perhaps by the classifier)=0A= > or hop-by-hop (perhaps by the classifier and subsequently the SFFs)?=0A= > Such selection is not equivalent to reclassification. And surely,=0A= > this is an architectural issue and not relegated to=0A= > "implementation".=0A= >=0A= > My own view is to favor the distributed approach even though a=0A= > greater amount of data (chain definitions and perhaps local selection=0A= > policy) is required at those distributed decision points. This=0A= > approach does not require an end-to-end path id at all. My=0A= > rationale for favoring this approach is primarily driven by increased=0A= > resiliency over the global path id approach. With a global path id=0A= > approach, consider failure of an instance and needing to alter the=0A= > global path ID table for each and every affected end-to-end path.=0A= >=0A= > Ron=0A= >=0A= > ________________________________________ From: sfc=0A= > [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct=0A= > [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM=0A= > To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:=0A= > [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > The way the architecture models the case of SF1 needing to influence=0A= > the chain is that one would do reclassification at the exit from=0A= > SF1.=0A= >=0A= > Part of the goal is to keep the different functions logically=0A= > separate so that solutions can clearly describe how they choose to=0A= > compose them for "service" delivery.=0A= >=0A= > Yours, Joel=0A= >=0A= > On 7/10/14, 6:10 PM, mikebianc@aol.com wrote:=0A= >> I don't see anything in the arch draft that suggests any sort of=0A= >> limit. However, it does seem to indicate that the entire path (all=0A= >> SFIs) must be chosen at SFC instantiation. I believe this means=0A= >> either at the classifier or maybe the classifier chooses a SF Chain=0A= >> and the NF or at the latest the first SFF. In any case, the=0A= >> language does seem to prohibit a more dynamic SFP where SFI(n) is=0A= >> determined at the SFI(n-1) hop. According to the draft, this=0A= >> behavior would be considered "branching" to a new SFP as opposed to=0A= >> choosing and then forwarding to the selected instance of the=0A= >> next-hop of the current SFC.=0A= >>=0A= >> draft-merged-sfc-architecture-00:=0A= >>> When an SFC is instantiated into the network it is necessary to=0A= >>> select the specific instances of SFs that will be used, and to=0A= >>> create the service topology for that SFC using SF's network=0A= >>> locator. Thus, instantiation of the SFC results in the creation=0A= >>> of a Service Function Path (SFP) and is used for forwarding=0A= >>> packets through the SFC. In other words, an SFP is the=0A= >>> instantiation of the defined SFC.=0A= >>>=0A= >>> The SFC architecture supports reclassification (or non-initial=0A= >>> classification) as well. As packets traverse an SFP,=0A= >>> reclassification may occur - typically performed by a=0A= >>> classification function co-resident with a service function.=0A= >>> Reclassification may result in the selection of a new SFP, an=0A= >>> update of the associated metadata, or both. This is referred to=0A= >>> as "branching".=0A= >>=0A= >>=0A= >>=0A= >> ------------------------------------------------------------------------= =0A= >>=0A= >>=0A= *From: *I.Smith@F5.com=0A= >> *To: *Joel Halpern Direct,Joel M.=0A= >> Halpern,huang@sce.carleton.ca,sfc@ietf.org=0A= >>=0A= >>=0A= *Sent: *Thursday, July 10, 2014=0A= >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>=0A= >> Actually, I think I am disagreeing.=0A= >>=0A= >> If the possibility of medium-scale deployments (and that is what=0A= >> 16 million flows is in my world) of service chains is preconceived=0A= >> as an absurd idea, then the architecture burdened with that=0A= >> preconception.=0A= >>=0A= >> There has to be some point of aim, some degree of aspiration to=0A= >> scale that is appropriate for the lifespan of the architecture -=0A= >> you don't have to know what it is, but by saying that an arbitrary=0A= >> number is "too far", you're creating - even if it isn't intentional=0A= >> - a limit that influences decisions that have lasting impacts=0A= >> regarding scale-out, failure mitigation, elasticity, address=0A= >> space... all kinds of things. That is a problem I'm not=0A= >> particularly eager to deal with.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> ________________________________________=0A= >>=0A= >>=0A= >> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent:=0A= >> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;=0A= >> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service=0A= >> Chains, Paths, and Load Balancers=0A= >>=0A= >> Ian, I don't think you disagree with me at all in this regard. I am=0A= >> not requesting the the architecture or the solution prohibit=0A= >> deployments in the specific fashion. I am objecting to Huang's=0A= >> reading of my note as saying that such deployments are required=0A= >> they by the archtiecture.=0A= >>=0A= >> As I have said repeatedly, I am not trying to prohibit such=0A= >> things. Whether they are a good idea or not depends upon many=0A= >> factors outside of the scope of the WG. I happen to think that they=0A= >> are usually a bad idea.=0A= >>=0A= >> But the archtiecture si carefully avoiding attempting to know what=0A= >> is and is not eployable.=0A= >>=0A= >> Yours, Joel=0A= >>=0A= >> On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= >>> I disagree.=0A= >>>=0A= >>> We routinely have stateful devices that manage tens of millions=0A= >>> of=0A= >> concurrent flows in both access network and data center=0A= >> environments today. You can't seriously believe that in the=0A= >> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going=0A= >> to have small numbers of service chains with equally small numbers=0A= >> of active service paths?=0A= >>>=0A= >>> Your sounds too much like "no one will ever need more than 64K"=0A= >>> for=0A= >> comfort.=0A= >>>=0A= >>>=0A= >>> ________________________________________ From: sfc=0A= >>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= >> [jmh@joelhalpern.com]=0A= >>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca;=0A= >>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load=0A= >>> Balancers=0A= >>>=0A= >>> No, it will mean that if someone tries to deploy the archtieture=0A= >>> particularly badly, they will exceed the limits of their=0A= >>> devices. The architecture does not require such absurd use of=0A= >>> service paths. Since I can not figure out how to write=0A= >>> architectural words to prohibit it, the architecture does permit=0A= >>> such abuse.=0A= >>>=0A= >>> Please do not read my saying that the archtiecture permits=0A= >>> something as saying it is either deisred or required by the work.=0A= >>> It isn't.=0A= >>>=0A= >>> Yours, Joel=0A= >>>=0A= >>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= >>>> If you need to support 100 service chains, it will mean=0A= >>>> 16,000,000 paths. That is larger than the routing table of a=0A= >>>> core router.=0A= >>>>=0A= >>>> Chang=0A= >>>>=0A= >>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= >>>>> The architecture allows a range of deployments, from 1=0A= >>>>> service path to 160000 service paths. I would hope that=0A= >>>>> operators are prepared for the complexities if they choose to=0A= >>>>> avoid any use of local load balancing and in stead provision=0A= >>>>> 160,000 service paths.=0A= >>>>>=0A= >>>>> Yours, Joel=0A= >>>>>=0A= >>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= >>>>>> Paul,=0A= >>>>>>=0A= >>>>>> How many path identifiers there will be for a 4 hop service=0A= >>>>>> chain with 20 instances at each hop?=0A= >>>>>>=0A= >>>>>> Maria=0A= >>>>>>=0A= >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of=0A= >>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03=0A= >>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;=0A= >>>>>> mohamed.boucadair@orange.com; sfc@ietf.org;=0A= >>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains,=0A= >>>>>> Paths, and Load Balancers=0A= >>>>>>=0A= >>>>>> Lucy,=0A= >>>>>>=0A= >>>>>> Overall I concur, as you say: a path ID drives the=0A= >>>>>> forwarding. I=92d=0A= >> make=0A= >>>>>> the minor change: the path identifier can be used to derive=0A= >>>>>> the needed forwarding and associated transport.=0A= >>>>>>=0A= >>>>>> It is _not_ the transport, but rather is used to simply=0A= >>>>>> identify the service path (or graph) that packets must=0A= >>>>>> traverse. By having a path identifier, the exact=0A= >>>>>> indirection that people seem to be asking for on this=0A= >>>>>> thread can be simply be implemented. The path identifier=0A= >>>>>> provides nothing more than a lookup, that lookup can result=0A= >>>>>> in a one or more (equal or weighted) transport next=0A= >>>>>> hop(s).=0A= >>>>>>=0A= >>>>>> Paul=0A= >>>>>>=0A= >>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong=0A= >>>>>> >=0A= >>>>>> wrote:=0A= >>>>>>=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> Agree. The arch. doc should not mandate only use of the=0A= >>>>>> service path identifier to drive the forwarding actions.=0A= >>>>>>=0A= >>>>>> Lucy=0A= >>>>>>=0A= >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= >>>>>> Of*mohamed.boucadair@orange.com=0A= >>>>>> *Sent:*Thursday, July=0A= >>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com=0A= >>>>>> ;jmh@joelhalpern.com=0A= >>>>>> ;sfc@ietf.org=0A= >>>>>> *Subject:*Re: [sfc] Service Chains,=0A= >>>>>> Paths, and Load Balancers=0A= >>>>>>=0A= >>>>>> Re-,=0A= >>>>>>=0A= >>>>>> The merged draft calls out explicitly a service path=0A= >>>>>> identifier. I object to use that identifier to derive=0A= >>>>>> forwarding actions.=0A= >>>>>>=0A= >>>>>> Requiring a SFC system to have the full knowledge of every=0A= >> available SFC=0A= >>>>>> forwarding paths within an SFC-enabled domain is not=0A= >> required/justified=0A= >>>>>> nor possible in various deployment contexts.=0A= >>>>>>=0A= >>>>>> SFC forwarding actions should rely on the piece of=0A= >>>>>> information=0A= >> that will=0A= >>>>>> be present in all deployments: that is the one required to=0A= >>>>>> structure a service chain. How that information is used to=0A= >>>>>> infer forwarding=0A= >> actions=0A= >>>>>> is a solution-oriented discussion.=0A= >>>>>>=0A= >>>>>> Cheers,=0A= >>>>>>=0A= >>>>>> Med=0A= >>>>>>=0A= >>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= >> de*mikebianc@aol.com=0A= >>>>>> *Envoy=E9 :*mercredi 9 juillet=0A= >>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com=0A= >>>>>> ;sfc@ietf.org=0A= >>>>>> *Objet :*Re: [sfc] Service Chains,=0A= >>>>>> Paths, and Load Balancers=0A= >>>>>>=0A= >>>>>> Is anyone still questioning the difference between SF Chain=0A= >>>>>> and SF=0A= >> Path?=0A= >>>>>> Other than clarifying the definition so that it's clear to=0A= >> those not=0A= >>>>>> familiar with the draft, it seems that everyone agrees on=0A= >>>>>> these terms.=0A= >>>>>>=0A= >>>>>> To me, the one point that is still unclear is whether it is=0A= >>>>>> the intent of this draft to ultimately specify what the ID=0A= >>>>>> of the SFC Header=0A= >> should=0A= >>>>>> reference (the chain or the path), or if this draft simply=0A= >>>>>> intends to leave that ambiguous, allowing other drafts to=0A= >>>>>> dictate the mechanisms for forwarding based on chain or=0A= >>>>>> path and the choice of chain or=0A= >> path to=0A= >>>>>> be negotiated in the control-plane.=0A= >>>>>>=0A= >>>>>> If the latter (ambiguous), then the draft would have=0A= >>>>>> require that both SFP and SFC be supported (or make one=0A= >>>>>> required and the other optional) to avoid some vendors only=0A= >>>>>> supporting SFP and others only supporting SFC.=0A= >>>>>>=0A= >>>>>>=0A= >> ------------------------------------------------------------------------= =0A= >>=0A= >>=0A= >>>>=0A= >>>>>> *From:*jmh@joelhalpern.com>>>>> >=0A= >>>>>> *To:*sfc@ietf.org>>>>> > *Sent:*Tuesday, July=0A= >>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load=0A= >>>>>> Balancers=0A= >>>>>>=0A= >>>>>> I have been trying to figure out how to clearly answer a=0A= >>>>>> number of comments that have been made about the proposed=0A= >>>>>> merged archtiecture draft. Assuming we can get working=0A= >>>>>> group agreement on the intent, we will work to improve the=0A= >>>>>> wording so that readers who have not participated in the WG=0A= >>>>>> discussion will understnd it the way the=0A= >> working=0A= >>>>>> group intends.=0A= >>>>>>=0A= >>>>>> But what do we intend? I will try to explain my personal=0A= >>>>>> view, and see if that helps.=0A= >>>>>>=0A= >>>>>> In this regard, it is important to keep in mind that what=0A= >>>>>> we are defining is the data plane architecture. We are not=0A= >>>>>> attempting to define the architecture for the entire=0A= >>>>>> solution for service chaining. That would encompass=0A= >>>>>> OSS/BSS, various control and policy functions, virtual=0A= >>>>>> machine and image management, and many other aspects.=0A= >>>>>>=0A= >>>>>> As a result there are many things which clearly need to=0A= >>>>>> exist in the larger system, but which are dealt with above=0A= >>>>>> where we are=0A= >> functioning,=0A= >>>>>> and are not directly required by the work we are doing.=0A= >>>>>>=0A= >>>>>> In order to get to service chain vs service path, as I=0A= >>>>>> understand=0A= >> them,=0A= >>>>>> I need to first discuss load balancing. There are at least=0A= >>>>>> three different ways that load balancing can and will=0A= >>>>>> interact with service chaining. There probably are more.=0A= >>>>>> The point of the archtiecture is to permit all of these,=0A= >>>>>> but not to mandate that any particular kind=0A= >> be used=0A= >>>>>> in any solution.=0A= >>>>>>=0A= >>>>>> 1) Load balancing as a service provided to the end user.=0A= >>>>>> This is a service function. It receives user packets, and=0A= >>>>>> modifies them (or=0A= >> marks=0A= >>>>>> them, or ...) so as to choose an end user service instance=0A= >>>>>> to receive the users packet. This is an important service=0A= >>>>>> function to be able to include in service chaining. It's=0A= >>>>>> behavior may affect requirements on how service chaining is=0A= >>>>>> done. But it has very little impact on the archtiecture.=0A= >>>>>> From an architectural pe3rspective it is simply a=0A= >> service=0A= >>>>>> function which may modify the underlying packet.=0A= >>>>>>=0A= >>>>>> 2) There is internal load balancing. That is, one can have=0A= >>>>>> what=0A= >> appears=0A= >>>>>> to the service chaining architecture as a single point of=0A= >>>>>> contact=0A= >> for a=0A= >>>>>> specific service function, but is actually delivered by a=0A= >> collection of=0A= >>>>>> virtual or physical machines, possibly including one or=0A= >>>>>> several load balancers (for example using VRRP-like=0A= >>>>>> techniques to share a MAC address.) mostly, this is=0A= >>>>>> invisible to the service chaining data plane mechanisms. It=0A= >>>>>> is likely that it is visible to various control mechanisms,=0A= >>>>>> such as those responsible for scale-in, scale-out, and vm=0A= >>>>>> instantiation. The architectural impact of permitting this=0A= >>>>>> is largely that we need to be careful that our terminology=0A= >>>>>> does not lead=0A= >> readers to=0A= >>>>>> think we are prohibiting it.=0A= >>>>>>=0A= >>>>>> 3) There can also be load balancing done by selecting=0A= >>>>>> packet paths for the service chaining that direct traffic=0A= >>>>>> to different places. We would not want to require that a=0A= >>>>>> given service function appear at only one place in the=0A= >>>>>> network.=0A= >>>>>>=0A= >>>>>> It is of course the case that these may be combined. I tend=0A= >>>>>> to=0A= >> refer to=0A= >>>>>> the collection of entities that appear to service chaining=0A= >>>>>> as a single point as a cluster. Not because cluster is a=0A= >>>>>> good term. But because I do not have another one. Thus, the=0A= >>>>>> point of type 3 load balancing=0A= >> is to=0A= >>>>>> direct different subsets of traffic to different singular=0A= >>>>>> or clustered service functions in different places in the=0A= >>>>>> network.=0A= >>>>>>=0A= >>>>>> Now with that said, what do I mean when I talk about=0A= >>>>>> service chain and service path/ Service chain is a sequence=0A= >>>>>> of logical functions to be applied to a subset of packets.=0A= >>>>>> It is equivalent of saying that some subset of traffic is=0A= >>>>>> to get DPI, charging, content inspection, and firewall=0A= >>>>>> while a different subset is to go directly to the cache=0A= >> without=0A= >>>>>> visiting any other service functions.=0A= >>>>>>=0A= >>>>>> That is not enough information to direct the packets. A=0A= >>>>>> service path is, in some fashion, a sequence of locations=0A= >>>>>> in the network. Those locations will be singular or=0A= >>>>>> clustered service function delivery locations. They may be=0A= >>>>>> addressed by IP address. They may be addressed as ports on=0A= >>>>>> an SFF. There are many different ways that the locations=0A= >>>>>> may be known to the service chaining infrastructure and the=0A= >>>>>> transport.=0A= >>>>>>=0A= >>>>>>> From the point of view of the work of the SFC group, we=0A= >>>>>>> need to be=0A= >>>>>> able to talk about the high level abstraction, the service=0A= >>>>>> chain, which drives the forwarding. And we need to talk=0A= >>>>>> about the actual data path packets will take in the=0A= >>>>>> network.=0A= >>>>>>=0A= >>>>>> Several of the comments have said "but the whole path may=0A= >>>>>> not be known at the front." This architecture deals with=0A= >>>>>> that issue in two ways. First, as noted in item (2) on load=0A= >>>>>> balancers above, there can be decisions and behaviors which=0A= >>>>>> are invisible to the service chaining mechanisms (in much=0A= >>>>>> the same way that bridging within a LAN is largely=0A= >>>>>> invisible to routing between LANs.) The other provision we=0A= >>>>>> make is=0A= >> that=0A= >>>>>> reclassification can be done in mid-chain when necessary.=0A= >>>>>> That will direct packets to a new chain. Based on=0A= >>>>>> information available at the re-classification point.=0A= >>>>>>=0A= >>>>>> I hope that this helps explain what we are after. If it=0A= >>>>>> does, and if the intent is acceptable to the working group,=0A= >>>>>> we can figure out what additional words are needed to=0A= >>>>>> convey this. If the working group disagree with the intent,=0A= >>>>>> then we will of course adjust to match the working group=0A= >>>>>> agreements. If this is still unclear, I am not sure what to=0A= >>>>>> try next.=0A= >>>>>>=0A= >>>>>> Yours, Joel=0A= >>>>>>=0A= >>>>>> _______________________________________________ sfc mailing=0A= >>>>>> list sfc@ietf.org =0A= >>>>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>>=0A= >>>>>> _______________________________________________ sfc mailing=0A= >>>>>> list sfc@ietf.org =0A= >>>>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>>=0A= >>>>>=0A= >>>>> _______________________________________________ sfc mailing=0A= >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>=0A= >>>>=0A= >>>> _______________________________________________ sfc mailing=0A= >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>=0A= >>>=0A= >>> _______________________________________________ sfc mailing list=0A= >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>=0A= >> _______________________________________________ sfc mailing list=0A= >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= > _______________________________________________ sfc mailing list=0A= > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= > _______________________________________________ sfc mailing list=0A= > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= From nobody Thu Jul 10 19:06: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 833461B2816 for ; Thu, 10 Jul 2014 19:06:27 -0700 (PDT) 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_29=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 5dGfCud6lYA3 for ; Thu, 10 Jul 2014 19:06:25 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FB61B281E for ; Thu, 10 Jul 2014 19:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 111088428FB; Thu, 10 Jul 2014 19:06:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 8F6668428FA; Thu, 10 Jul 2014 19:06:22 -0700 (PDT) Message-ID: <53BF469E.9010108@joelhalpern.com> Date: Thu, 10 Jul 2014 22:06:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TGoVRcf3Z2ghXNrM0sC3Hg9xC_I Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 02:06:27 -0000 Part of my personal view is that I am trying to make this work sensibly in a more orchestrated environment. I expect that the service functions, and over time probably the SFF capabilities, will be orchestrated and installed. I expect the service chains to be driven by BSS tools that define offerings to clients, and enable self-selection from these. I expect service paths to be heavily policy drive. I can see how to make all of that work in an archtiecture driven by initial classification to described service paths. It is harder to see how to make it work (but it can be done) when we allow more dynamicity in the network behavior. Having said that, most of that perspective I described is outside of the scope of the working group. it is not something we are tasked to agree on. So I do not claim that vision means we have to do it a certain way. it is just the perspective that drives my preferences. Yours, Joel On 7/10/14, 9:58 PM, Ian Smith wrote: >> For me, the amount of information about service instances that needs to >> be widely distributed and maintained, potentially even across data >> centers within an administrative scope, is large enough and complex >> enough that trying to get that into each SFF seems like a difficult >> architecture to realize. > > I'm curious as to why that is more complicated than dynamic routing, hyper-scale data center orchestration, or DNS, all of which are bigger problems that have been profitably and stably implemented? > > It also seems that if it really is more complicated, that is a good sign that it is too complicated. > > ________________________________________ > From: Joel M. Halpern [jmh@joelhalpern.com] > Sent: Thursday, July 10, 2014 9:45 PM > To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > This is an architectural issue. And one that I would prefer we actually > decide, rather than trying to allow all possible implementations. > Because it does have a major effect on the control requirements and the > functionality of SFFs. > > For me, the amount of information about service instances that needs to > be widely distributed and maintained, potentially even across data > centers within an administrative scope, is large enough and complex > enough that trying to get that into each SFF seems like a difficult > architecture to realize. > > Yours, > Joel > > But it is a fair question. > > On 7/10/14, 9:38 PM, Ron Parker wrote: >> This is the crux of my issue. Is the end to end selection of >> (top-level) instances performed centrally (perhaps by the classifier) >> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >> Such selection is not equivalent to reclassification. And surely, >> this is an architectural issue and not relegated to >> "implementation". >> >> My own view is to favor the distributed approach even though a >> greater amount of data (chain definitions and perhaps local selection >> policy) is required at those distributed decision points. This >> approach does not require an end-to-end path id at all. My >> rationale for favoring this approach is primarily driven by increased >> resiliency over the global path id approach. With a global path id >> approach, consider failure of an instance and needing to alter the >> global path ID table for each and every affected end-to-end path. >> >> Ron >> >> ________________________________________ From: sfc >> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >> [sfc] Service Chains, Paths, and Load Balancers >> >> The way the architecture models the case of SF1 needing to influence >> the chain is that one would do reclassification at the exit from >> SF1. >> >> Part of the goal is to keep the different functions logically >> separate so that solutions can clearly describe how they choose to >> compose them for "service" delivery. >> >> Yours, Joel >> >> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>> I don't see anything in the arch draft that suggests any sort of >>> limit. However, it does seem to indicate that the entire path (all >>> SFIs) must be chosen at SFC instantiation. I believe this means >>> either at the classifier or maybe the classifier chooses a SF Chain >>> and the NF or at the latest the first SFF. In any case, the >>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>> determined at the SFI(n-1) hop. According to the draft, this >>> behavior would be considered "branching" to a new SFP as opposed to >>> choosing and then forwarding to the selected instance of the >>> next-hop of the current SFC. >>> >>> draft-merged-sfc-architecture-00: >>>> When an SFC is instantiated into the network it is necessary to >>>> select the specific instances of SFs that will be used, and to >>>> create the service topology for that SFC using SF's network >>>> locator. Thus, instantiation of the SFC results in the creation >>>> of a Service Function Path (SFP) and is used for forwarding >>>> packets through the SFC. In other words, an SFP is the >>>> instantiation of the defined SFC. >>>> >>>> The SFC architecture supports reclassification (or non-initial >>>> classification) as well. As packets traverse an SFP, >>>> reclassification may occur - typically performed by a >>>> classification function co-resident with a service function. >>>> Reclassification may result in the selection of a new SFP, an >>>> update of the associated metadata, or both. This is referred to >>>> as "branching". >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> > *From: *I.Smith@F5.com >>> *To: *Joel Halpern Direct,Joel M. >>> Halpern,huang@sce.carleton.ca,sfc@ietf.org >>> >>> > *Sent: *Thursday, July 10, 2014 >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Actually, I think I am disagreeing. >>> >>> If the possibility of medium-scale deployments (and that is what >>> 16 million flows is in my world) of service chains is preconceived >>> as an absurd idea, then the architecture burdened with that >>> preconception. >>> >>> There has to be some point of aim, some degree of aspiration to >>> scale that is appropriate for the lifespan of the architecture - >>> you don't have to know what it is, but by saying that an arbitrary >>> number is "too far", you're creating - even if it isn't intentional >>> - a limit that influences decisions that have lasting impacts >>> regarding scale-out, failure mitigation, elasticity, address >>> space... all kinds of things. That is a problem I'm not >>> particularly eager to deal with. >>> >>> >>> >>> >>> ________________________________________ >>> >>> >>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>> Chains, Paths, and Load Balancers >>> >>> Ian, I don't think you disagree with me at all in this regard. I am >>> not requesting the the architecture or the solution prohibit >>> deployments in the specific fashion. I am objecting to Huang's >>> reading of my note as saying that such deployments are required >>> they by the archtiecture. >>> >>> As I have said repeatedly, I am not trying to prohibit such >>> things. Whether they are a good idea or not depends upon many >>> factors outside of the scope of the WG. I happen to think that they >>> are usually a bad idea. >>> >>> But the archtiecture si carefully avoiding attempting to know what >>> is and is not eployable. >>> >>> Yours, Joel >>> >>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>> I disagree. >>>> >>>> We routinely have stateful devices that manage tens of millions >>>> of >>> concurrent flows in both access network and data center >>> environments today. You can't seriously believe that in the >>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>> to have small numbers of service chains with equally small numbers >>> of active service paths? >>>> >>>> Your sounds too much like "no one will ever need more than 64K" >>>> for >>> comfort. >>>> >>>> >>>> ________________________________________ From: sfc >>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>> [jmh@joelhalpern.com] >>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>> Balancers >>>> >>>> No, it will mean that if someone tries to deploy the archtieture >>>> particularly badly, they will exceed the limits of their >>>> devices. The architecture does not require such absurd use of >>>> service paths. Since I can not figure out how to write >>>> architectural words to prohibit it, the architecture does permit >>>> such abuse. >>>> >>>> Please do not read my saying that the archtiecture permits >>>> something as saying it is either deisred or required by the work. >>>> It isn't. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>> If you need to support 100 service chains, it will mean >>>>> 16,000,000 paths. That is larger than the routing table of a >>>>> core router. >>>>> >>>>> Chang >>>>> >>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>> The architecture allows a range of deployments, from 1 >>>>>> service path to 160000 service paths. I would hope that >>>>>> operators are prepared for the complexities if they choose to >>>>>> avoid any use of local load balancing and in stead provision >>>>>> 160,000 service paths. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>> Paul, >>>>>>> >>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>> chain with 20 instances at each hop? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>> Paths, and Load Balancers >>>>>>> >>>>>>> Lucy, >>>>>>> >>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>> forwarding. I’d >>> make >>>>>>> the minor change: the path identifier can be used to derive >>>>>>> the needed forwarding and associated transport. >>>>>>> >>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>> identify the service path (or graph) that packets must >>>>>>> traverse. By having a path identifier, the exact >>>>>>> indirection that people seem to be asking for on this >>>>>>> thread can be simply be implemented. The path identifier >>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>> in a one or more (equal or weighted) transport next >>>>>>> hop(s). >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>> service path identifier to drive the forwarding actions. >>>>>>> >>>>>>> Lucy >>>>>>> >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>> Of*mohamed.boucadair@orange.com >>>>>>> *Sent:*Thursday, July >>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>> ;jmh@joelhalpern.com >>>>>>> ;sfc@ietf.org >>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>> Paths, and Load Balancers >>>>>>> >>>>>>> Re-, >>>>>>> >>>>>>> The merged draft calls out explicitly a service path >>>>>>> identifier. I object to use that identifier to derive >>>>>>> forwarding actions. >>>>>>> >>>>>>> Requiring a SFC system to have the full knowledge of every >>> available SFC >>>>>>> forwarding paths within an SFC-enabled domain is not >>> required/justified >>>>>>> nor possible in various deployment contexts. >>>>>>> >>>>>>> SFC forwarding actions should rely on the piece of >>>>>>> information >>> that will >>>>>>> be present in all deployments: that is the one required to >>>>>>> structure a service chain. How that information is used to >>>>>>> infer forwarding >>> actions >>>>>>> is a solution-oriented discussion. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Med >>>>>>> >>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>> de*mikebianc@aol.com >>>>>>> *Envoyé :*mercredi 9 juillet >>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>> ;sfc@ietf.org >>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>> Paths, and Load Balancers >>>>>>> >>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>> and SF >>> Path? >>>>>>> Other than clarifying the definition so that it's clear to >>> those not >>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>> these terms. >>>>>>> >>>>>>> To me, the one point that is still unclear is whether it is >>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>> of the SFC Header >>> should >>>>>>> reference (the chain or the path), or if this draft simply >>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>> path and the choice of chain or >>> path to >>>>>>> be negotiated in the control-plane. >>>>>>> >>>>>>> If the latter (ambiguous), then the draft would have >>>>>>> require that both SFP and SFC be supported (or make one >>>>>>> required and the other optional) to avoid some vendors only >>>>>>> supporting SFP and others only supporting SFC. >>>>>>> >>>>>>> >>> ------------------------------------------------------------------------ >>> >>> >>>>> >>>>>>> *From:*jmh@joelhalpern.com>>>>>> > >>>>>>> *To:*sfc@ietf.org>>>>>> > *Sent:*Tuesday, July >>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>> Balancers >>>>>>> >>>>>>> I have been trying to figure out how to clearly answer a >>>>>>> number of comments that have been made about the proposed >>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>> group agreement on the intent, we will work to improve the >>>>>>> wording so that readers who have not participated in the WG >>>>>>> discussion will understnd it the way the >>> working >>>>>>> group intends. >>>>>>> >>>>>>> But what do we intend? I will try to explain my personal >>>>>>> view, and see if that helps. >>>>>>> >>>>>>> In this regard, it is important to keep in mind that what >>>>>>> we are defining is the data plane architecture. We are not >>>>>>> attempting to define the architecture for the entire >>>>>>> solution for service chaining. That would encompass >>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>> machine and image management, and many other aspects. >>>>>>> >>>>>>> As a result there are many things which clearly need to >>>>>>> exist in the larger system, but which are dealt with above >>>>>>> where we are >>> functioning, >>>>>>> and are not directly required by the work we are doing. >>>>>>> >>>>>>> In order to get to service chain vs service path, as I >>>>>>> understand >>> them, >>>>>>> I need to first discuss load balancing. There are at least >>>>>>> three different ways that load balancing can and will >>>>>>> interact with service chaining. There probably are more. >>>>>>> The point of the archtiecture is to permit all of these, >>>>>>> but not to mandate that any particular kind >>> be used >>>>>>> in any solution. >>>>>>> >>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>> This is a service function. It receives user packets, and >>>>>>> modifies them (or >>> marks >>>>>>> them, or ...) so as to choose an end user service instance >>>>>>> to receive the users packet. This is an important service >>>>>>> function to be able to include in service chaining. It's >>>>>>> behavior may affect requirements on how service chaining is >>>>>>> done. But it has very little impact on the archtiecture. >>>>>>> From an architectural pe3rspective it is simply a >>> service >>>>>>> function which may modify the underlying packet. >>>>>>> >>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>> what >>> appears >>>>>>> to the service chaining architecture as a single point of >>>>>>> contact >>> for a >>>>>>> specific service function, but is actually delivered by a >>> collection of >>>>>>> virtual or physical machines, possibly including one or >>>>>>> several load balancers (for example using VRRP-like >>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>> is likely that it is visible to various control mechanisms, >>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>> instantiation. The architectural impact of permitting this >>>>>>> is largely that we need to be careful that our terminology >>>>>>> does not lead >>> readers to >>>>>>> think we are prohibiting it. >>>>>>> >>>>>>> 3) There can also be load balancing done by selecting >>>>>>> packet paths for the service chaining that direct traffic >>>>>>> to different places. We would not want to require that a >>>>>>> given service function appear at only one place in the >>>>>>> network. >>>>>>> >>>>>>> It is of course the case that these may be combined. I tend >>>>>>> to >>> refer to >>>>>>> the collection of entities that appear to service chaining >>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>> good term. But because I do not have another one. Thus, the >>>>>>> point of type 3 load balancing >>> is to >>>>>>> direct different subsets of traffic to different singular >>>>>>> or clustered service functions in different places in the >>>>>>> network. >>>>>>> >>>>>>> Now with that said, what do I mean when I talk about >>>>>>> service chain and service path/ Service chain is a sequence >>>>>>> of logical functions to be applied to a subset of packets. >>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>> while a different subset is to go directly to the cache >>> without >>>>>>> visiting any other service functions. >>>>>>> >>>>>>> That is not enough information to direct the packets. A >>>>>>> service path is, in some fashion, a sequence of locations >>>>>>> in the network. Those locations will be singular or >>>>>>> clustered service function delivery locations. They may be >>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>> an SFF. There are many different ways that the locations >>>>>>> may be known to the service chaining infrastructure and the >>>>>>> transport. >>>>>>> >>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>> need to be >>>>>>> able to talk about the high level abstraction, the service >>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>> about the actual data path packets will take in the >>>>>>> network. >>>>>>> >>>>>>> Several of the comments have said "but the whole path may >>>>>>> not be known at the front." This architecture deals with >>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>> balancers above, there can be decisions and behaviors which >>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>> the same way that bridging within a LAN is largely >>>>>>> invisible to routing between LANs.) The other provision we >>>>>>> make is >>> that >>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>> That will direct packets to a new chain. Based on >>>>>>> information available at the re-classification point. >>>>>>> >>>>>>> I hope that this helps explain what we are after. If it >>>>>>> does, and if the intent is acceptable to the working group, >>>>>>> we can figure out what additional words are needed to >>>>>>> convey this. If the working group disagree with the intent, >>>>>>> then we will of course adjust to match the working group >>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>> try next. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ sfc mailing 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 Jul 10 19:24: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 03A161B2A89 for ; Thu, 10 Jul 2014 19:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 6NORbEyQKOAR for ; Thu, 10 Jul 2014 19:24:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1211A0218 for ; Thu, 10 Jul 2014 19:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19737; q=dns/txt; s=iport; t=1405045489; x=1406255089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rMOt1ChJ9xt7MI+WzIcR/boSt4TnDsoYyZxNJrqiswM=; b=mzaCiGhzB9kZN4yLrVQMlEQTAGSJwIJ5LEfc7nXAodqbS14TdYN5DWTo fxudNZ0ESRNq2z/HHiicWWCKnOpdcSG53yEqXbXprzY1rMLGDtEFih390 pEEFH/7tIQtI2cj8dUHib0NIoo2ou6R1w6JWMgCRkdRDz51tOxTvPA7BO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwNAONJv1OtJV2U/2dsb2JhbABPCoFsBoEcUq9IkXgKh0IBgQsWdYQDAQEBAwEBAQFiCQIJBQsCAQgRAQMBAQEdCgcnCxQDBggCBA4FG4gTAwkIDcYlEwSNGYFADwUkMwcCgyuBFgWWIEaEGotjiDKDQ4Fv X-IronPort-AV: E=Sophos;i="5.01,641,1400025600"; d="scan'208";a="59953632" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 11 Jul 2014 02:24:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6B2OjqR000909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 02:24:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 21:24:45 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoD//7kLeQ== Date: Fri, 11 Jul 2014 02:24:44 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/oEjyhxJc7fMUi4kRPWYRreasSkE Cc: Joel Halpern Direct , "sfc@ietf.org" , "I.Smith@F5.com" , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 02:24:54 -0000 Inline Sent from my iPhone > On Jul 10, 2014, at 9:38 PM, "Ron Parker" wrote: >=20 > This is the crux of my issue. Is the end to end selection of (top-level= ) instances performed centrally (perhaps by the classifier) or hop-by-hop (= perhaps by the classifier and subsequently the SFFs)? Such selection is n= ot equivalent to reclassification. And surely, this is an architectural i= ssue and not relegated to "implementation". =20 >=20 > My own view is to favor the distributed approach even though a greater am= ount of data (chain definitions and perhaps local selection policy) is requ= ired at those distributed decision points. This approach does not require= an end-to-end path id at all. My rationale for favoring this approach i= s primarily driven by increased resiliency over the global path id approach= . With a global path id approach, consider failure of an instance and nee= ding to alter the global path ID table for each and every affected end-to-e= nd path. Jim> not at all necessary and any designer worth their salt would design re= siliency into their deployment; for example no reason that a backup next-ho= p SF could not be specified as part of the forwarding logic. >=20 > Ron >=20 > ________________________________________ > From: sfc [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct [jmh.di= rect@joelhalpern.com] > Sent: Thursday, July 10, 2014 6:15 PM > To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > The way the architecture models the case of SF1 needing to influence the > chain is that one would do reclassification at the exit from SF1. >=20 > Part of the goal is to keep the different functions logically separate > so that solutions can clearly describe how they choose to compose them > for "service" delivery. >=20 > Yours, > Joel >=20 >> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> I don't see anything in the arch draft that suggests any sort of limit. >> However, it does seem to indicate that the entire path (all SFIs) must >> be chosen at SFC instantiation. I believe this means either at the >> classifier or maybe the classifier chooses a SF Chain and the NF or at >> the latest the first SFF. In any case, the language does seem to >> prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1) >> hop. According to the draft, this behavior would be considered >> "branching" to a new SFP as opposed to choosing and then forwarding to >> the selected instance of the next-hop of the current SFC. >>=20 >> draft-merged-sfc-architecture-00: >>> When an SFC is instantiated into the network it is necessary to >>> select the specific instances of SFs that will be used, and to create >>> the service topology for that SFC using SF's network locator. Thus, >>> instantiation of the SFC results in the creation of a Service >>> Function Path (SFP) and is used for forwarding packets through the >>> SFC. In other words, an SFP is the instantiation of the defined SFC. >>>=20 >>> The SFC architecture supports reclassification (or non-initial >>> classification) as well. As packets traverse an SFP, >>> reclassification may occur - typically performed by a classification >>> function co-resident with a service function. Reclassification may >>> result in the selection of a new SFP, an update of the associated >>> metadata, or both. This is referred to as "branching". >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >> *From: *I.Smith@F5.com >> *To: *Joel Halpern Direct,Joel M. >> Halpern,huang@sce.carleton.ca,sfc@ietf.org >> *Sent: *Thursday, July 10, 2014 >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Actually, I think I am disagreeing. >>=20 >> If the possibility of medium-scale deployments (and that is what 16 >> million flows is in my world) of service chains is preconceived as an >> absurd idea, then the architecture burdened with that preconception. >>=20 >> There has to be some point of aim, some degree of aspiration to scale >> that is appropriate for the lifespan of the architecture - you don't >> have to know what it is, but by saying that an arbitrary number is "too >> far", you're creating - even if it isn't intentional - a limit that >> influences decisions that have lasting impacts regarding scale-out, >> failure mitigation, elasticity, address space... all kinds of things. >> That is a problem I'm not particularly eager to deal with. >>=20 >>=20 >>=20 >>=20 >> ________________________________________ >>=20 >>=20 >> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] >> Sent: Thursday, July 10, 2014 5:04 PM >> To: Ian Smith; Joel M. Halpern; huang@sce.carleton.ca; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Ian, I don't think you disagree with me at all in this regard. >> I am not requesting the the architecture or the solution prohibit >> deployments in the specific fashion. >> I am objecting to Huang's reading of my note as saying that such >> deployments are required they by the archtiecture. >>=20 >> As I have said repeatedly, I am not trying to prohibit such things. >> Whether they are a good idea or not depends upon many factors outside of >> the scope of the WG. I happen to think that they are usually a bad idea. >>=20 >> But the archtiecture si carefully avoiding attempting to know what is >> and is not eployable. >>=20 >> Yours, >> Joel >>=20 >>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> I disagree. >>>=20 >>> We routinely have stateful devices that manage tens of millions of >> concurrent flows in both access network and data center environments >> today. You can't seriously believe that in the >> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to >> have small numbers of service chains with equally small numbers of >> active service paths? >>>=20 >>> Your sounds too much like "no one will ever need more than 64K" for >> comfort. >>>=20 >>>=20 >>> ________________________________________ >>> From: sfc [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> [jmh@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 4:46 PM >>> To: huang@sce.carleton.ca; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> No, it will mean that if someone tries to deploy the archtieture >>> particularly badly, they will exceed the limits of their devices. >>> The architecture does not require such absurd use of service paths. >>> Since I can not figure out how to write architectural words to prohibit >>> it, the architecture does permit such abuse. >>>=20 >>> Please do not read my saying that the archtiecture permits something as >>> saying it is either deisred or required by the work. It isn't. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>> If you need to support 100 service chains, it will mean 16,000,000 >>>> paths. That is larger than the routing table of a core router. >>>>=20 >>>> Chang >>>>=20 >>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>> The architecture allows a range of deployments, from 1 service path t= o >>>>> 160000 service paths. I would hope that operators are prepared for >>>>> the complexities if they choose to avoid any use of local load >>>>> balancing and in stead provision 160,000 service paths. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>> Paul, >>>>>>=20 >>>>>> How many path identifiers there will be for a 4 hop service chain wi= th >>>>>> 20 instances at each hop? >>>>>>=20 >>>>>> Maria >>>>>>=20 >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>>>>> (paulq) >>>>>> *Sent:* Thursday, July 10, 2014 3:03 PM >>>>>> *To:* Lucy yong >>>>>> *Cc:* jmh@joelhalpern.com; mohamed.boucadair@orange.com; sfc@ietf.or= g; >>>>>> mikebianc@aol.com >>>>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Lucy, >>>>>>=20 >>>>>> Overall I concur, as you say: a path ID drives the forwarding. I=92d >> make >>>>>> the minor change: the path identifier can be used to derive the need= ed >>>>>> forwarding and associated transport. >>>>>>=20 >>>>>> It is _not_ the transport, but rather is used to simply identify the >>>>>> service path (or graph) that packets must traverse. By having a path >>>>>> identifier, the exact indirection that people seem to be asking for = on >>>>>> this thread can be simply be implemented. The path identifier provid= es >>>>>> nothing more than a lookup, that lookup can result in a one or more >>>>>> (equal or weighted) transport next hop(s). >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>> > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Agree. The arch. doc should not mandate only use of the service path >>>>>> identifier to drive the forwarding actions. >>>>>>=20 >>>>>> Lucy >>>>>>=20 >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>> Of*mohamed.boucadair@orange.com >>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>>>> *To:*mikebianc@aol.com ;jmh@joelhalpern.co= m >>>>>> ;sfc@ietf.org >>>>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Re-, >>>>>>=20 >>>>>> The merged draft calls out explicitly a service path identifier. I >>>>>> object to use that identifier to derive forwarding actions. >>>>>>=20 >>>>>> Requiring a SFC system to have the full knowledge of every >> available SFC >>>>>> forwarding paths within an SFC-enabled domain is not >> required/justified >>>>>> nor possible in various deployment contexts. >>>>>>=20 >>>>>> SFC forwarding actions should rely on the piece of information >> that will >>>>>> be present in all deployments: that is the one required to structure= a >>>>>> service chain. How that information is used to infer forwarding >> actions >>>>>> is a solution-oriented discussion. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Med >>>>>>=20 >>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> de*mikebianc@aol.com >>>>>> >>>>>> *Envoy=E9 :*mercredi 9 juillet 2014 22:03 >>>>>> *=C0 :*jmh@joelhalpern.com ;sfc@ietf.org >>>>>> >>>>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Is anyone still questioning the difference between SF Chain and SF >> Path? >>>>>> Other than clarifying the definition so that it's clear to >> those not >>>>>> familiar with the draft, it seems that everyone agrees on these term= s. >>>>>>=20 >>>>>> To me, the one point that is still unclear is whether it is the inte= nt >>>>>> of this draft to ultimately specify what the ID of the SFC Header >> should >>>>>> reference (the chain or the path), or if this draft simply intends t= o >>>>>> leave that ambiguous, allowing other drafts to dictate the mechanism= s >>>>>> for forwarding based on chain or path and the choice of chain or >> path to >>>>>> be negotiated in the control-plane. >>>>>>=20 >>>>>> If the latter (ambiguous), then the draft would have require that bo= th >>>>>> SFP and SFC be supported (or make one required and the other optiona= l) >>>>>> to avoid some vendors only supporting SFP and others only supporting >>>>>> SFC. >> ------------------------------------------------------------------------ >>>>>>=20 >>>>>> *From:*jmh@joelhalpern.com>>>>> > >>>>>> *To:*sfc@ietf.org> >>>>>> *Sent:*Tuesday, July 8, 2014 >>>>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> I have been trying to figure out how to clearly answer a number of >>>>>> comments that have been made about the proposed merged archtiecture >>>>>> draft. Assuming we can get working group agreement on the intent, we >>>>>> will work to improve the wording so that readers who have not >>>>>> participated in the WG discussion will understnd it the way the >> working >>>>>> group intends. >>>>>>=20 >>>>>> But what do we intend? I will try to explain my personal view, and s= ee >>>>>> if that helps. >>>>>>=20 >>>>>> In this regard, it is important to keep in mind that what we are >>>>>> defining is the data plane architecture. We are not attempting to >>>>>> define the architecture for the entire solution for service chaining= . >>>>>> That would encompass OSS/BSS, various control and policy functions, >>>>>> virtual machine and image management, and many other aspects. >>>>>>=20 >>>>>> As a result there are many things which clearly need to exist in the >>>>>> larger system, but which are dealt with above where we are >> functioning, >>>>>> and are not directly required by the work we are doing. >>>>>>=20 >>>>>> In order to get to service chain vs service path, as I understand >> them, >>>>>> I need to first discuss load balancing. There are at least three >>>>>> different ways that load balancing can and will interact with servic= e >>>>>> chaining. There probably are more. The point of the archtiecture is = to >>>>>> permit all of these, but not to mandate that any particular kind >> be used >>>>>> in any solution. >>>>>>=20 >>>>>> 1) Load balancing as a service provided to the end user. This is a >>>>>> service function. It receives user packets, and modifies them (or >> marks >>>>>> them, or ...) so as to choose an end user service instance to receiv= e >>>>>> the users packet. This is an important service function to be able t= o >>>>>> include in service chaining. It's behavior may affect requirements o= n >>>>>> how service chaining is done. But it has very little impact on the >>>>>> archtiecture. From an architectural pe3rspective it is simply a >> service >>>>>> function which may modify the underlying packet. >>>>>>=20 >>>>>> 2) There is internal load balancing. That is, one can have what >> appears >>>>>> to the service chaining architecture as a single point of contact >> for a >>>>>> specific service function, but is actually delivered by a >> collection of >>>>>> virtual or physical machines, possibly including one or several load >>>>>> balancers (for example using VRRP-like techniques to share a MAC >>>>>> address.) mostly, this is invisible to the service chaining data pla= ne >>>>>> mechanisms. It is likely that it is visible to various control >>>>>> mechanisms, such as those responsible for scale-in, scale-out, and v= m >>>>>> instantiation. The architectural impact of permitting this is largel= y >>>>>> that we need to be careful that our terminology does not lead >> readers to >>>>>> think we are prohibiting it. >>>>>>=20 >>>>>> 3) There can also be load balancing done by selecting packet paths f= or >>>>>> the service chaining that direct traffic to different places. We wou= ld >>>>>> not want to require that a given service function appear at only one >>>>>> place in the network. >>>>>>=20 >>>>>> It is of course the case that these may be combined. I tend to >> refer to >>>>>> the collection of entities that appear to service chaining as a sing= le >>>>>> point as a cluster. Not because cluster is a good term. But because = I >>>>>> do not have another one. Thus, the point of type 3 load balancing >> is to >>>>>> direct different subsets of traffic to different singular or cluster= ed >>>>>> service functions in different places in the network. >>>>>>=20 >>>>>> Now with that said, what do I mean when I talk about service chain a= nd >>>>>> service path/ Service chain is a sequence of logical functions to be >>>>>> applied to a subset of packets. It is equivalent of saying that some >>>>>> subset of traffic is to get DPI, charging, content inspection, and >>>>>> firewall while a different subset is to go directly to the cache >> without >>>>>> visiting any other service functions. >>>>>>=20 >>>>>> That is not enough information to direct the packets. A service path >>>>>> is, in some fashion, a sequence of locations in the network. Those >>>>>> locations will be singular or clustered service function delivery >>>>>> locations. They may be addressed by IP address. They may be addresse= d >>>>>> as ports on an SFF. There are many different ways that the locations >>>>>> may be known to the service chaining infrastructure and the transpor= t. >>>>>>=20 >>>>>>> From the point of view of the work of the SFC group, we need to be >>>>>> able >>>>>> to talk about the high level abstraction, the service chain, which >>>>>> drives the forwarding. And we need to talk about the actual data pat= h >>>>>> packets will take in the network. >>>>>>=20 >>>>>> Several of the comments have said "but the whole path may not be kno= wn >>>>>> at the front." This architecture deals with that issue in two ways. >>>>>> First, as noted in item (2) on load balancers above, there can be >>>>>> decisions and behaviors which are invisible to the service chaining >>>>>> mechanisms (in much the same way that bridging within a LAN is large= ly >>>>>> invisible to routing between LANs.) The other provision we make is >> that >>>>>> reclassification can be done in mid-chain when necessary. That will >>>>>> direct packets to a new chain. Based on information available at the >>>>>> re-classification point. >>>>>>=20 >>>>>> I hope that this helps explain what we are after. If it does, and if >>>>>> the intent is acceptable to the working group, we can figure out wha= t >>>>>> additional words are needed to convey this. >>>>>> If the working group disagree with the intent, then we will of cours= e >>>>>> adjust to match the working group agreements. >>>>>> If this is still unclear, I am not sure what to try next. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=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 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jul 10 19:31: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 F02351B2A91 for ; Thu, 10 Jul 2014 19:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 3v9syjmFXszu for ; Thu, 10 Jul 2014 19:31:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FE11B2A84 for ; Thu, 10 Jul 2014 19:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38961; q=dns/txt; s=iport; t=1405045944; x=1406255544; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GSAC3mxabiCZBmeKoWhwFGuW1P0u1mHAkG3Y5qUU3A0=; b=BQchLtf7Ag3j1Sfm5DTx2L/Y0MH22CJ5M6UD8oPlU5OkwuXk5PV/6ba3 zTgYi+8Ct7eDeObYdMFgAzGYL+sKaYL8STyKuayg/XzaSSZZtCJiWZRvp sjn9qlmLg308TkgeU7GieLQ6RAJx6qlkIOEqoLR1Ii0YjoRMU1R39xgJe g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAE1Lv1OtJA2H/2dsb2JhbABPCoJHR1KoQIcJkXgBCYdCAYELFnWEAwEBAQQBAQEXPg0JCxACAQgRAQMBAR4DAQYHJwsUAwYIAgQOBRuIEwMRDcYkEwSNGYFPUgYEBgGDLYEWBZYgRoQai2OIMoND X-IronPort-AV: E=Sophos;i="5.01,641,1400025600"; d="scan'208,217";a="336123017" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2014 02:32:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6B2Vlqw011219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 02:31:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 21:31:47 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAXQIAgAAMmNE= Date: Fri, 11 Jul 2014 02:31:46 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com>, <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FAC29904F5AF48639211C738AF613B51ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mAQr_XgZuPa2bhIpLAQS0-juqYg Cc: "sfc@ietf.org" , "mn1921@att.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 02:31:53 -0000 --_000_FAC29904F5AF48639211C738AF613B51ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mike, No as the SPI would be used along with the index to identify which SF needs= to be applied and then the SFF would make a local decision as to which of = the 20 instances should retrieve the traffic for a given flow received from= the SFP. Sent from my iPhone On Jul 10, 2014, at 4:46 PM, "mikebianc@aol.com" = > wrote: Jim, Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at a= ll. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. ________________________________ From: jguichar@cisco.com> To: NAPIERALA, MARIA H> cc: Paul Quinn (paulq)>,Lucy yong>,jmh@joelhalpern.com>,moh= amed.boucadair@orange.com>,sfc@ietf.org>,mikebianc@aol.com> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make t= he minor change: the path identifier can be used to derive the needed forwa= rding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a = lookup, that lookup can result in a one or more (equal or weighted) transpo= rt next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Beh= alf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;= jmh@joelhalpern.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la p= art de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com; sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From: jmh@joelhalpern.co= m> To: sfc@ietf.org<= sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_FAC29904F5AF48639211C738AF613B51ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mike,
No as the SPI would be used along with the index to identify which SF = needs to be applied and then the SFF would make a local decision as to whic= h of the 20 instances should retrieve the traffic for a given flow received= from the SFP. 

Sent from my iPhone

Jim, 

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop?  In this case, there wouldn't be any Path Ident= ifier at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers= there will be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=92d make the minor change: the path identifier can be used to = derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc shou= ld not mandate only use of the service path identifier to drive the forward= ing actions.

Lucy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of <= /span>mohamed.boucadair= @orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com; = jmh@joelhalpern.com;<= span class=3D"apple-converted-space"> = sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a serv= ice path identifier. I object to use that identifier to derive forwarding a= ctions.

Requiring a SFC system to have the full know= ledge of every available SFC forwarding paths within an SFC-enabled domain = is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the pi= ece of information that will be present in all deployments: that is the one= required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented dis= cussion.

Cheers,

Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de = mikebianc@aol.com
Envoy=E9 : mercredi 9 j= uillet 2014 22:03
=C0 : jmh@joelhalpern.com; = sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the differenc= e between SF Chain and SF Path? Other than clarifying the definition so tha= t it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclea= r is whether it is the intent of this draft to ultimately specify what the = ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing o= ther drafts to dictate the mechanisms for forwarding based on chain or path= and the choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft= would have require that both SFP and SFC be supported (or make one require= d and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: jmh@joelhalpern.com<jmh@joel= halpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

______________________________________= _________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_FAC29904F5AF48639211C738AF613B51ciscocom_-- From nobody Thu Jul 10 19:47: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 341A01A01AD for ; Thu, 10 Jul 2014 19:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 uvJBYdT1YV3t for ; Thu, 10 Jul 2014 19:47:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8601A01A0 for ; Thu, 10 Jul 2014 19:47:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGZ81615; Fri, 11 Jul 2014 02:47:06 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 03:47:04 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 10:46:59 +0800 From: Qin Wu To: "mikebianc@aol.com" , "jguichar@cisco.com" , "mn1921@att.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uXpRMAgAC5UYCAAIXgAIAAQmiAgAARywCAAAIZAIAACTEAgADoRMA= Date: Fri, 11 Jul 2014 02:46:59 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> , <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84581BBCnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/t1R4Ra2eAmv_w5TkdlPKtKK3J7Q Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 02:47:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84581BBCnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgb25lIHNlcnZpY2UgY2hhaW4gY2FuIGNvcnJlc3BvbmRpbmcgdG8gbXVsdGlwbGUgc2Vydmlj ZSBmdW5jdGlvbiBwYXRocyxlIC5nLiwgaW4gY2FzZSBvZiBhbGwgYWN0aXZlIHJlZHVuY3ksDQpJ IHRoaW5rIHVzaW5nIGNoYWluIGlkZW50aWZpZXIgaXMgbW9yZSByZWFzb25hYmxlIGNob2ljZSBz aW5jZSBwYXRoIGlkIGlzIG5vdCB1bmlxdWUgaW4gdGhpcyBjYXNlLg0KDQpSZWdhcmRzIQ0KLVFp bg0K5Y+R5Lu25Lq6OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIG1p a2ViaWFuY0Bhb2wuY29tDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMTHml6UgNDo0Nw0K5pS2 5Lu25Lq6OiBqZ3VpY2hhckBjaXNjby5jb207IG1uMTkyMUBhdHQuY29tDQrmioTpgIE6IHNmY0Bp ZXRmLm9yZw0K5Li76aKYOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCg0KDQpKaW0sDQoNClRlY2huaWNhbGx5LCB3b3VsZG4ndCB0aGlzIGJlIGEg Q2hhaW4gSWRlbnRpZmllciBpZiB0aGUgbmV4dCBpbnN0YW5jZSBpcyBjaG9zZW4gYXQgZWFjaCBo b3A/ICBJbiB0aGlzIGNhc2UsIHRoZXJlIHdvdWxkbid0IGJlIGFueSBQYXRoIElkZW50aWZpZXIg YXQgYWxsLg0KDQpCdXQgaXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGNsYXNzaWZpZXIg bmVlZGluZyB0byB0cmFjayB0aGUgaGVhbHRoLCBldGMgb2YgMjBeNCBTRiBQYXRocyBmb3IgYSBz aW5nbGUgU0YgQ2hhaW4sIHZzIGVhY2ggb2YgdGhlIDgwIGluc3RhbmNlcyB0cmFja2luZyAyMCBT RklzIG9mIHRoZSBuZXh0LWhvcCBmb3IgdGhlIGNoYWlucyBvZiB3aGljaCB0aGV5IGFyZSBtZW1i ZXJzIHZzIGVhY2ggU0ZGIGluIHRoZSBlbnRpcmUgZG9tYWluIHRyYWNraW5nIGFsbCA4MCBTRklz IHZzIHNvbWV0aGluZyBlbHNlLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IGpndWljaGFyQGNpc2NvLmNvbTxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbT4+DQpUbzogTkFQSUVSQUxBLCBN QVJJQSBIPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQpjYzogUGF1bCBR dWlubiAocGF1bHEpPHBhdWxxQGNpc2NvLmNvbTxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4sTHVj eSB5b25nPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+ LGptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT4+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LHNmY0Bp ZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+LG1pa2ViaWFuY0Bhb2wu Y29tPG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQpTZW50OiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNA0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoxIGFzc3VtaW5nIGxvYWQgaXMgZGlzdHJpYnV0 ZWQgYW1vbmcgdGhlIDIwIGluc3RhbmNlcyBhdCBlYWNoIHNlcnZpY2UgaG9wLg0KDQpTZW50IGZy b20gbXkgaVBob25lDQoNCk9uIEp1bCAxMCwgMjAxNCwgYXQgNDowNyBQTSwgIk5BUElFUkFMQSwg TUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0K UGF1bCwNCkhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhv cCBzZXJ2aWNlIGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KTWFyaWENCkZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBR dWlubiAocGF1bHEpDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzIFBNDQpUbzog THVjeSB5b25nDQpDYzogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47IG1pa2Vi aWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NClN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KTHVjeSwNCk92ZXJh bGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhlIGZvcndhcmRpbmcu IEnigJlkIG1ha2UgdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUg dXNlZCB0byBkZXJpdmUgdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5z cG9ydC4NCkl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0byBz aW1wbHkgaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cyBt dXN0IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdCBpbmRp cmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb24gdGhpcyB0aHJlYWQg Y2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGggaWRlbnRpZmllciBwcm92aWRl cyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuIHJlc3VsdCBpbiBh IG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQgaG9wKHMpLg0K UGF1bA0KT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nIDxsdWN5LnlvbmdA aHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KQWdyZWUu IFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mIHRoZSBzZXJ2aWNl IHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLg0KTHVjeQ0K RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjowNiBBTQ0KVG86IG1pa2ViaWFu Y0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IGptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KUmUtLA0KVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBh IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVy IHRvIGRlcml2ZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQpSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRv IGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IGF2YWlsYWJsZSBTRkMgZm9yd2FyZGlu ZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdCByZXF1aXJlZC9qdXN0 aWZpZWQgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy4NClNGQyBm b3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mIGluZm9ybWF0aW9u IHRoYXQgd2lsbCBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25l IHJlcXVpcmVkIHRvIHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0 aW9uIGlzIHVzZWQgdG8gaW5mZXIgZm9yd2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3Jp ZW50ZWQgZGlzY3Vzc2lvbi4NCkNoZWVycywNCk1lZA0KRGUgOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+DQpFbnZvecOpIDogbWVyY3JlZGkgOSBqdWlsbGV0IDIwMTQgMjI6MDMN CsOAIDogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCklzIGFueW9uZSBzdGlsbCBxdWVz dGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIENoYWluIGFuZCBTRiBQYXRoPyBPdGhl ciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzIGNsZWFyIHRvIHRo b3NlIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBh Z3JlZXMgb24gdGhlc2UgdGVybXMuDQpUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxs IHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0 aW1hdGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVhZGVyIHNob3VsZCByZWZl cmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5IGlu dGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyIGRyYWZ0cyB0byBk aWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluIG9yIHBh dGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3IgcGF0aCB0byBiZSBuZWdvdGlhdGVkIGluIHRo ZSBjb250cm9sLXBsYW5lLg0KSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJh ZnQgd291bGQgaGF2ZSByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQg KG9yIG1ha2Ugb25lIHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNv bWUgdmVuZG9ycyBvbmx5IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5n IFNGQy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogVHVl c2RheSwgSnVseSA4LCAyMDE0DQpTdWJqZWN0OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBo b3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2YNCmNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVu IG1hZGUgYWJvdXQgdGhlIHByb3Bvc2VkIG1lcmdlZCBhcmNodGllY3R1cmUNCmRyYWZ0LiBBc3N1 bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdl DQp3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhh dmUgbm90DQpwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQg aXQgdGhlIHdheSB0aGUgd29ya2luZw0KZ3JvdXAgaW50ZW5kcy4NCg0KQnV0IHdoYXQgZG8gd2Ug aW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZQ0K aWYgdGhhdCBoZWxwcy4NCg0KSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVw IGluIG1pbmQgdGhhdCB3aGF0IHdlIGFyZQ0KZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJj aGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRpbmcgdG8NCmRlZmluZSB0aGUgYXJjaGl0ZWN0 dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLg0KVGhhdCB3 b3VsZCBlbmNvbXBhc3MgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rp b25zLA0KdmlydHVhbCBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhl ciBhc3BlY3RzLg0KDQpBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xl YXJseSBuZWVkIHRvIGV4aXN0IGluIHRoZQ0KbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBk ZWFsdCB3aXRoIGFib3ZlIHdoZXJlIHdlIGFyZSBmdW5jdGlvbmluZywNCmFuZCBhcmUgbm90IGRp cmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy4NCg0KSW4gb3JkZXIgdG8g Z2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhl bSwNCkkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQg bGVhc3QgdGhyZWUNCmRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3 aWxsIGludGVyYWN0IHdpdGggc2VydmljZQ0KY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBt b3JlLiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0bw0KcGVybWl0IGFsbCBvZiB0 aGVzZSwgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2Vk DQppbiBhbnkgc29sdXRpb24uDQoNCjEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92 aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMgaXMgYQ0Kc2VydmljZSBmdW5jdGlvbi4gSXQgcmVj ZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQgbW9kaWZpZXMgdGhlbSAob3IgbWFya3MNCnRoZW0sIG9y IC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVj ZWl2ZQ0KdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5j dGlvbiB0byBiZSBhYmxlIHRvDQppbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVo YXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24NCmhvdyBzZXJ2aWNlIGNoYWluaW5nIGlz IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KYXJjaHRpZWN0dXJl LiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZp Y2UNCmZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KDQoy KSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZl IHdoYXQgYXBwZWFycw0KdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEg c2luZ2xlIHBvaW50IG9mIGNvbnRhY3QgZm9yIGENCnNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQgYnkgYSBjb2xsZWN0aW9uIG9mDQp2aXJ0dWFsIG9y IHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9h ZA0KYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UgdGVjaG5pcXVlcyB0byBz aGFyZSBhIE1BQw0KYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhlIHNl cnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wNCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhv c2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KaW5zdGFudGlh dGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJn ZWx5DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBkb2Vz IG5vdCBsZWFkIHJlYWRlcnMgdG8NCnRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCg0KMykg VGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0 IHBhdGhzIGZvcg0KdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBk aWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZA0Kbm90IHdhbnQgdG8gcmVxdWlyZSB0aGF0IGEgZ2l2 ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUNCnBsYWNlIGluIHRoZSBuZXR3 b3JrLg0KDQpJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmlu ZWQuIEkgdGVuZCB0byByZWZlciB0bw0KdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBh cHBlYXIgdG8gc2VydmljZSBjaGFpbmluZyBhcyBhIHNpbmdsZQ0KcG9pbnQgYXMgYSBjbHVzdGVy LiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGEgZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJDQpkbyBu b3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFu Y2luZyBpcyB0bw0KZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVy ZW50IHNpbmd1bGFyIG9yIGNsdXN0ZXJlZA0Kc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50 IHBsYWNlcyBpbiB0aGUgbmV0d29yay4NCg0KTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkg bWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWluIGFuZA0Kc2VydmljZSBwYXRoLyBT ZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUNCmFw cGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcg dGhhdCBzb21lDQpzdWJzZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29u dGVudCBpbnNwZWN0aW9uLCBhbmQNCmZpcmV3YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBp cyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUgd2l0aG91dA0KdmlzaXRpbmcgYW55IG90aGVy IHNlcnZpY2UgZnVuY3Rpb25zLg0KDQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8g ZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZpY2UgcGF0aA0KaXMsIGluIHNvbWUgZmFzaGlvbiwg YSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuIFRob3NlDQpsb2NhdGlvbnMg d2lsbCBiZSBzaW5ndWxhciBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeQ0K bG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkg YmUgYWRkcmVzc2VkDQphcyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVu dCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0KbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNo YWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Lg0KDQo+RnJvbSB0aGUgcG9p bnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRvIGJlIGFi bGUNCnRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNl IGNoYWluLCB3aGljaA0KZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxr IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoDQpwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUgbmV0 d29yay4NCg0KU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xl IHBhdGggbWF5IG5vdCBiZSBrbm93bg0KYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUg ZGVhbHMgd2l0aCB0aGF0IGlzc3VlIGluIHR3byB3YXlzLg0KRmlyc3QsIGFzIG5vdGVkIGluIGl0 ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUNCmRlY2lzaW9ucyBh bmQgYmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcN Cm1lY2hhbmlzbXMgKGluIG11Y2ggdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEg TEFOIGlzIGxhcmdlbHkNCmludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBv dGhlciBwcm92aXNpb24gd2UgbWFrZSBpcyB0aGF0DQpyZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBk b25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vzc2FyeS4gVGhhdCB3aWxsDQpkaXJlY3QgcGFja2V0 cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZQ0K cmUtY2xhc3NpZmljYXRpb24gcG9pbnQuDQoNCkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFp biB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQgZG9lcywgYW5kIGlmDQp0aGUgaW50ZW50IGlzIGFj Y2VwdGFibGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsIHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQNCmFk ZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy4NCklmIHRoZSB3b3JraW5n IGdyb3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVudCwgdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZQ0K YWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuDQpJZiB0aGlzIGlz IHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUgd2hhdCB0byB0cnkgbmV4dC4NCg0KWW91cnMs DQpKb2VsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_B8F9A780D330094D99AF023C5877DABA84581BBCnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG 5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1D TiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBvbmUgc2VydmljZSBjaGFpbiBjYW4gY29ycmVzcG9u ZGluZyB0byBtdWx0aXBsZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzLGUgLmcuLCBpbiBjYXNlIG9m IGFsbCBhY3RpdmUgcmVkdW5jeSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgdGhpbmsgdXNpbmcgY2hhaW4gaWRlbnRpZmllciBpcyBtb3JlIHJlYXNvbmFibGUg Y2hvaWNlIHNpbmNlIHBhdGggaWQgaXMgbm90IHVuaXF1ZSBpbiB0aGlzIGNhc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+bWlrZWJpYW5jQGFvbC5jb208YnI+DQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4gMjAxNDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNw YW4gbGFuZz0iRU4tVVMiPjc8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjExPC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4gNDo0Nzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBqZ3VpY2hhckBjaXNj by5jb207IG1uMTkyMUBhdHQuY29tPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNmY0BpZXRmLm9yZzxicj4NCjwv c3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48YnI+DQpKaW0sJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UZWNobmljYWxseSwgd291bGRuJ3QgdGhpcyBiZSBhIENoYWluIElkZW50aWZpZXIgaWYgdGhl IG5leHQgaW5zdGFuY2UgaXMgY2hvc2VuIGF0IGVhY2ggaG9wPyAmbmJzcDtJbiB0aGlzIGNhc2Us IHRoZXJlIHdvdWxkbid0IGJlIGFueSBQYXRoIElkZW50aWZpZXIgYXQgYWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnV0IGl0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g YSBjbGFzc2lmaWVyIG5lZWRpbmcgdG8gdHJhY2sgdGhlIGhlYWx0aCwgZXRjIG9mIDIwXjQgU0Yg UGF0aHMgZm9yIGEgc2luZ2xlIFNGIENoYWluLCB2cyBlYWNoIG9mIHRoZSA4MCBpbnN0YW5jZXMg dHJhY2tpbmcgMjANCiBTRklzIG9mIHRoZSBuZXh0LWhvcCBmb3IgdGhlIGNoYWlucyBvZiB3aGlj aCB0aGV5IGFyZSBtZW1iZXJzIHZzIGVhY2ggU0ZGIGluIHRoZSBlbnRpcmUgZG9tYWluIHRyYWNr aW5nIGFsbCA4MCBTRklzIHZzIHNvbWV0aGluZyBlbHNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0 O3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXplPSIxIiB3 aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3Vp Y2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbSZsdDtqZ3VpY2hhckBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+TkFQSUVSQUxBLCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1h aWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Ozxicj4NCjxiPmNjOiA8 L2I+UGF1bCBRdWlubiAocGF1bHEpJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVscUBjaXNjby5jb20i PnBhdWxxQGNpc2NvLmNvbTwvYT4mZ3Q7LEx1Y3kgeW9uZyZsdDs8YSBocmVmPSJtYWlsdG86bHVj eS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29tPC9hPiZndDssam1oQGpvZWxo YWxwZXJuLmNvbSZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mbHQ7PGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+Jmd0OyxzZmNAaWV0Zi5vcmcmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDssbWlrZWJpYW5jQGFvbC5jb20mbHQ7PGEg aHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+U2VudDogPC9iPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4xIGFzc3VtaW5nIGxv YWQgaXMgZGlzdHJpYnV0ZWQgYW1vbmcgdGhlIDIwIGluc3RhbmNlcyBhdCBlYWNoIHNlcnZpY2Ug aG9wLjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiBKdWwgMTAsIDIwMTQsIGF0IDQ6 MDcgUE0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5QYXVsLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3 aWxsIGJlIGZvciBhIDQgaG9wIHNlcnZpY2UgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMNCiBhdCBl YWNoIGhvcD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXJpYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYw0KIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxi Pk9uIEJlaGFsZiBPZg0KPC9iPlBhdWwgUXVpbm4gKHBhdWxxKTxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBMdWN5IHlvbmc8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5MdWN5LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPk92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2 ZXMgdGhlIGZvcndhcmRpbmcuIEnigJlkIG1ha2UgdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGgg aWRlbnRpZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUgdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFu ZA0KIGFzc29jaWF0ZWQgdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIF9u b3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0byBzaW1wbHkgaWRlbnRpZnkg dGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cyBtdXN0IHRyYXZlcnNlLiBC eSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KIGluZGlyZWN0aW9uIHRoYXQg cGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzIHRocmVhZCBjYW4gYmUgc2ltcGx5 IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aCBpZGVudGlmaWVyIHByb3ZpZGVzIG5vdGhpbmcgbW9y ZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4gcmVzdWx0IGluIGEgb25lIG9yIG1vcmUg KGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dCBob3AocykuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBK dWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0 ZSBvbmx5IHVzZSBvZiB0aGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUNCiB0aGUg Zm9yd2FyZGluZyBhY3Rpb25zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bh bj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4gPC9z cGFuPjwvYj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4gPC9zcGFuPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDI6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+UmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlLSw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRp Zmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllcg0KIHRvIGRlcml2ZSBmb3J3YXJk aW5nIGFjdGlvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhl IGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IGF2YWlsYWJsZSBTRkMgZm9yd2FyZGluZyBwYXRocyB3 aXRoaW4NCiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90IHJlcXVpcmVkL2p1c3RpZmllZCBu b3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U0ZD IGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2YgaW5mb3JtYXRp b24gdGhhdCB3aWxsIGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOg0KIHRoYXQgaXMgdGhl IG9uZSByZXF1aXJlZCB0byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZv cm1hdGlvbiBpcyB1c2VkIHRvIGluZmVyIGZvcndhcmRpbmcgYWN0aW9ucyBpcyBhIHNvbHV0aW9u LW9yaWVudGVkIGRpc2N1c3Npb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkRlIDo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2ZjIFs8YSBocmVmPSJt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4NCjwvc3Bhbj48Yj5EZSBsYSBwYXJ0IGRlPC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Ij5taWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQo8Yj5FbnZvecOpIDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+IDwvc3Bhbj5tZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAy MjowMzxicj4NCjxiPsOAIDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPk9i amV0IDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+IDwvc3Bhbj5SZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PklzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIENo YWluIGFuZCBTRiBQYXRoPyBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24NCiBz byB0aGF0IGl0J3MgY2xlYXIgdG8gdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBp dCBzZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGVzZSB0ZXJtcy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVh ciBpcyB3aGV0aGVyIGl0IGlzIHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5 IHNwZWNpZnkNCiB3aGF0IHRoZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQgcmVmZXJlbmNl ICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRz IHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0 ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvciBwYXRoIGFu ZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yIHBhdGggdG8gYmUgbmVnb3RpYXRlZA0KIGluIHRoZSBj b250cm9sLXBsYW5lLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHRoZSBsYXR0ZXIg KGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgcmVxdWlyZSB0aGF0IGJvdGgg U0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvcg0KIG1ha2Ugb25lIHJlcXVpcmVkIGFuZCB0aGUg b3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUgdmVuZG9ycyBvbmx5IHN1cHBvcnRpbmcgU0ZQ IGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9 IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3Bh biBsYW5nPSJFTi1VUyI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4N Cjwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4N CjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+PC9iPjxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50Ojxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+PC9iPlR1ZXNkYXksIEp1 bHkgOCwgMjAxNDxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+IDwvc3Bhbj48L2I+W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnM8YnI+DQo8YnI+DQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cg dG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0 IHRoZSBwcm9wb3NlZCBtZXJnZWQgYXJjaHRpZWN0dXJlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29y a2luZyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2U8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQp3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUg d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KcGFydGljaXBhdGVkIGluIHRoZSBXRyBkaXNj dXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlIHdvcmtpbmc8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpncm91cCBpbnRlbmRzLjxicj4N Cjxicj4NCkJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15IHBl cnNvbmFsIHZpZXcsIGFuZCBzZWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4N Cjwvc3Bhbj48YnI+DQppZiB0aGF0IGhlbHBzLjxicj4NCjxicj4NCkluIHRoaXMgcmVnYXJkLCBp dCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3ZSBhcmU8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpkZWZpbmluZyBpcyB0aGUg ZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFyZSBub3QgYXR0ZW1wdGluZyB0bzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCmRlZmluZSB0aGUgYXJj aGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NClRoYXQgd291 bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9u cyw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQp2aXJ0 dWFsIG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMu PGJyPg0KPGJyPg0KQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFy bHkgbmVlZCB0byBleGlzdCBpbiB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4NCjwvc3Bhbj48YnI+DQpsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgg YWJvdmUgd2hlcmUgd2UgYXJlIGZ1bmN0aW9uaW5nLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCmFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5 IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnI+DQo8YnI+DQpJbiBvcmRlciB0byBnZXQgdG8gc2Vy dmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLDxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCkkgbmVlZCB0byBmaXJz dCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWU8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpkaWZmZXJlbnQgd2F5 cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbCBpbnRlcmFjdCB3aXRoIHNlcnZpY2U8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpjaGFpbmlu Zy4gVGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJl IGlzIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0K cGVybWl0IGFsbCBvZiB0aGVzZSwgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3Vs YXIga2luZCBiZSB1c2VkPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3Nw YW4+PGJyPg0KaW4gYW55IHNvbHV0aW9uLjxicj4NCjxicj4NCjEpIExvYWQgYmFsYW5jaW5nIGFz IGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuIFRoaXMgaXMgYTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnNlcnZpY2UgZnVuY3Rpb24u IEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KdGhlbSwgb3Ig Li4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZSB0byByZWNl aXZlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KdGhl IHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBi ZSBhYmxlIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJy Pg0KaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2aW9yIG1heSBhZmZlY3Qg cmVxdWlyZW1lbnRzIG9uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3Nw YW4+PGJyPg0KaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxp dHRsZSBpbXBhY3Qgb24gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8 L3NwYW4+PGJyPg0KYXJjaHRpZWN0dXJlLiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0 aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2U8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4NCjwvc3Bhbj48YnI+DQpmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5 aW5nIHBhY2tldC48YnI+DQo8YnI+DQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2lu Zy4gVGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFyczxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFy Y2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZiBjb250YWN0IGZvciBhPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0Kc3BlY2lmaWMgc2VydmljZSBm dW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhIGNvbGxlY3Rpb24gb2Y8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQp2aXJ0dWFsIG9y IHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9h ZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCmJhbGFu Y2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlIHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBN QUM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQphZGRy ZXNzLikgbW9zdGx5LCB0aGlzIGlzIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBk YXRhIHBsYW5lPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJy Pg0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3Vz IGNvbnRyb2w8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+ DQptZWNoYW5pc21zLCBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2Nh bGUtb3V0LCBhbmQgdm08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bh bj48YnI+DQppbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0 dGluZyB0aGlzIGlzIGxhcmdlbHk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4N Cjwvc3Bhbj48YnI+DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5v bG9neSBkb2VzIG5vdCBsZWFkIHJlYWRlcnMgdG88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4NCjwvc3Bhbj48YnI+DQp0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuPGJyPg0K PGJyPg0KMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3Rp bmcgcGFja2V0IHBhdGhzIGZvcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0K PC9zcGFuPjxicj4NCnRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMgdG8g ZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4NCjwvc3Bhbj48YnI+DQpub3Qgd2FudCB0byByZXF1aXJlIHRoYXQgYSBnaXZlbiBzZXJ2 aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnBsYWNlIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4N Ckl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0 ZW5kIHRvIHJlZmVyIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3Nw YW4+PGJyPg0KdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2Vydmlj ZSBjaGFpbmluZyBhcyBhIHNpbmdsZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui Pg0KPC9zcGFuPjxicj4NCnBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBp cyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPg0KPC9zcGFuPjxicj4NCmRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLCB0aGUg cG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlzIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9m IHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9yIGNsdXN0ZXJlZDxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnNlcnZpY2UgZnVuY3Rpb25zIGlu IGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KTm93IHdpdGggdGhh dCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWluIGFu ZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnNlcnZp Y2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlIG9mIGxvZ2ljYWwgZnVuY3Rpb25z IHRvIGJlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0K YXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWlu ZyB0aGF0IHNvbWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48 YnI+DQpzdWJzZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBp bnNwZWN0aW9uLCBhbmQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bh bj48YnI+DQpmaXJld2FsbCB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0 bHkgdG8gdGhlIGNhY2hlIHdpdGhvdXQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4NCjwvc3Bhbj48YnI+DQp2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJy Pg0KPGJyPg0KVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFj a2V0cy4gQSBzZXJ2aWNlIHBhdGg8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4N Cjwvc3Bhbj48YnI+DQppcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9u cyBpbiB0aGUgbmV0d29yay4gVGhvc2U8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4NCjwvc3Bhbj48YnI+DQpsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvciBjbHVzdGVyZWQg c2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPg0KPC9zcGFuPjxicj4NCmxvY2F0aW9ucy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGJ5IElQ IGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCmFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUgYXJlIG1h bnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUgbG9jYXRpb25zPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Ljxicj4NCjxicj4NCiZn dDtGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3JvdXAsIHdl IG5lZWQgdG8gYmUgYWJsZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9z cGFuPjxicj4NCnRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBz ZXJ2aWNlIGNoYWluLCB3aGljaDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0K PC9zcGFuPjxicj4NCmRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsayBh Ym91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPg0KPC9zcGFuPjxicj4NCnBhY2tldHMgd2lsbCB0YWtlIGluIHRoZSBuZXR3b3JrLjxicj4N Cjxicj4NClNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdo b2xlIHBhdGggbWF5IG5vdCBiZSBrbm93bjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPg0KPC9zcGFuPjxicj4NCmF0IHRoZSBmcm9udC4mcXVvdDsgVGhpcyBhcmNoaXRlY3R1cmUg ZGVhbHMgd2l0aCB0aGF0IGlzc3VlIGluIHR3byB3YXlzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCkZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBv biBsb2FkIGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hp Y2ggYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCm1lY2hhbmlzbXMgKGluIG11Y2ggdGhl IHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQppbnZpc2libGUgdG8gcm91 dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlIG1ha2UgaXMgdGhhdDxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCnJlY2xhc3Np ZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5LiBUaGF0IHdp bGw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4NCjwvc3Bhbj48YnI+DQpkaXJl Y3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24gaW5mb3JtYXRpb24gYXZhaWxhYmxl IGF0IHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4N CnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Ljxicj4NCjxicj4NCkkgaG9wZSB0aGF0IHRoaXMgaGVs cHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQgZG9lcywgYW5kIGlmPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KdGhlIGludGVudCBpcyBh Y2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gZmlndXJlIG91dCB3aGF0PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+DQo8L3NwYW4+PGJyPg0KYWRkaXRpb25h bCB3b3JkcyBhcmUgbmVlZGVkIHRvIGNvbnZleSB0aGlzLjxicj4NCklmIHRoZSB3b3JraW5nIGdy b3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVudCwgdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjxicj4NCmFkanVzdCB0byBt YXRjaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLjxicj4NCklmIHRoaXMgaXMgc3RpbGwg dW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRyeSBuZXh0Ljxicj4NCjxicj4NCllvdXJz LDxicj4NCkpvZWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpz ZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B8F9A780D330094D99AF023C5877DABA84581BBCnkgeml501mbschi_-- From nobody Thu Jul 10 20:14: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 D5BC21A01A0 for ; Thu, 10 Jul 2014 20:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 oN3mTAV2jMzs for ; Thu, 10 Jul 2014 20:14:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169741A0195 for ; Thu, 10 Jul 2014 20:14:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJV72610; Fri, 11 Jul 2014 03:14:22 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 04:14:19 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 11:14:14 +0800 From: Qin Wu To: Ron Parker , Joel Halpern Direct , "mikebianc@aol.com" , "I.Smith@F5.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uXpRMAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAJzqcA== Date: Fri, 11 Jul 2014 03:14:13 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/VnweTSyoJjxFt1cBsDbt8ihG3GA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 03:14:47 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10g5Luj6KGoIFJvbiBQYXJrZXINCuWPkemAgeaXtumXtDogMjAxNOW5tDfmnIgx MeaXpSA5OjM5DQrmlLbku7bkuro6IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1pa2ViaWFuY0Bhb2wu Y29tOyBJLlNtaXRoQEY1LmNvbTsgc2ZjQGlldGYub3JnDQrkuLvpopg6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpUaGlzIGlzIHRoZSBjcnV4 IG9mIG15IGlzc3VlLiAgIElzIHRoZSBlbmQgdG8gZW5kIHNlbGVjdGlvbiBvZiAodG9wLWxldmVs KSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmll cikgb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVu dGx5IHRoZSBTRkZzKT8gICBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNs YXNzaWZpY2F0aW9uLiAgIEFuZCBzdXJlbHksIHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1 ZSBhbmQgbm90IHJlbGVnYXRlZCB0byAiaW1wbGVtZW50YXRpb24iLiAgIA0KDQpNeSBvd24gdmll dyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbiB0aG91Z2ggYSBncmVh dGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwcyBsb2NhbCBz ZWxlY3Rpb24gcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lv biBwb2ludHMuICAgVGhpcyBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQg cGF0aCBpZCBhdCBhbGwuICAgIE15IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2Fj aCBpcyBwcmltYXJpbHkgZHJpdmVuIGJ5IGluY3JlYXNlZCByZXNpbGllbmN5IG92ZXIgdGhlIGds b2JhbCBwYXRoIGlkIGFwcHJvYWNoLiAgIFdpdGggYSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaCwg Y29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0byBhbHRlciB0aGUg Z2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkIGVuZC10by1l bmQgcGF0aC4NCg0KW1Fpbl06IElmIFNGQyBpcyBkZWZpbmVkIGFzIGFuIG9yZGVyZWQgbGlzdCBv ZiBzZXJ2aWNlIGZ1bmN0aW9uIGlkZW50aWZpZXJzIHdoaWxlIFNGUCBpcyBkZWZpbmVkIGFzIGFu IG9yZGVyZWQgbGlzdCBvZiBsb2NhdG9ycyBvZg0KICAgZWFjaCBzZXJ2aWNlIGZ1bmN0aW9uIHRo YXQgYmVsb25ncyB0byBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4uICBUaGVuIHRoZSBzZXJ2aWNl IGZ1bmN0aW9uIHBhdGggY2FuIGJlIHN0YXRpYyBvciBwcmUtZGV0ZXJtaW5lZA0KICAgdXNpbmcg c3BlY2lmaWMgU0YgaW5zdGFuY2VzLCBvciBkeW5hbWljIC0gY2hvb3NpbmcgdGhlIGxvY2F0b3Jz IG9mIHNlcnZpY2UgZXhwbGljaXQgU0YgaW5zdGFuY2VzIGF0IHRoZSB0aW1lIG9mIGRlbGl2ZXJp bmcgdHJhZmZpYyB0bw0KICAgdGhlIFNGLiBJdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIGl0IGlz IGNlbnRyYWxpemVkIGFwcHJvYWNoIG9yIGRpc3RyaWJ1dGVkIGFwcHJvYWNoZWQuIENlbnRyYWxp emVkIGFwcHJvYWNoIGNhbiBiZSB1c2VkIGZvciBiZXR0ZXIgdHJhZmZpYyBlbmdpbmVlcmluZyBy ZWFzb24uDQogICBJbiBhZGRpdGlvbiwgd2hlbiBvbmUgU0ZDIGNhbiBiZSB0cmFuc2xhdGVkIGlu dG8gbXVsdGlwbGUgU0ZQcyBpbiBzb21lIGNhc2VzLCB3aGF0IHdlIG1vcmUgbmVlZCBpcyBnbG9i YWwgY2hhaW4gSUQgaW5zdGVhZCBvZiBwYXRoIElEIHNpbmNlIHBhdGggY2FuIGJlDQogICBJZGVu dGlmaWVkIGJ5IGEgc2V0IG9mIGxvY2F0b3JzIGFsbG9jYXRlZCB0byBlYWNoIHNlcnZpY2UgZnVu Y3Rpb24gaW5zdGFuY2UgdGhhdCBpcyBpbnZva2VkIGZvciBhIGdpdmVuIGNoYWluLg0KDQogICBS b24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2Zj IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3Qg W2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQgNjoxNSBQTQ0KVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBJLlNtaXRoQEY1LmNvbTsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCg0KVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBv ZiBTRjEgbmVlZGluZyB0byBpbmZsdWVuY2UgdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRv IHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4aXQgZnJvbSBTRjEuDQoNClBhcnQgb2YgdGhlIGdv YWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkgc2VwYXJhdGUg c28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkgY2hvb3NlIHRv IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KDQpZb3VycywNCkpvZWwNCg0K T24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20gd3JvdGU6DQo+IEkgZG9uJ3Qg c2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55IHNvcnQgb2Yg bGltaXQuDQo+ICAgSG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVu dGlyZSBwYXRoIChhbGwgU0ZJcykgDQo+IG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0 aW9uLiAgSSBiZWxpZXZlIHRoaXMgbWVhbnMgZWl0aGVyIGF0IA0KPiB0aGUgY2xhc3NpZmllciBv ciBtYXliZSB0aGUgY2xhc3NpZmllciBjaG9vc2VzIGEgU0YgQ2hhaW4gYW5kIHRoZSBORiANCj4g b3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiAgSW4gYW55IGNhc2UsIHRoZSBsYW5ndWFn ZSBkb2VzIHNlZW0gDQo+IHRvIHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNGUCB3aGVyZSBTRkko bikgaXMgZGV0ZXJtaW5lZCBhdCB0aGUgDQo+IFNGSShuLTEpIGhvcC4gIEFjY29yZGluZyB0byB0 aGUgZHJhZnQsIHRoaXMgYmVoYXZpb3Igd291bGQgYmUgDQo+IGNvbnNpZGVyZWQgImJyYW5jaGlu ZyIgdG8gYSBuZXcgU0ZQIGFzIG9wcG9zZWQgdG8gY2hvb3NpbmcgYW5kIHRoZW4gDQo+IGZvcndh cmRpbmcgdG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlIG9mIHRoZSBuZXh0LWhvcCBvZiB0aGUgY3Vy cmVudCBTRkMuDQo+DQo+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0KPj4gIFdo ZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzIG5lY2Vzc2Fy eSB0bw0KPiAgPiAgc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2ls bCBiZSB1c2VkLCBhbmQgdG8gDQo+IGNyZWF0ZSAgPiAgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9y IHRoYXQgU0ZDIHVzaW5nIFNGJ3MgbmV0d29yayANCj4gbG9jYXRvci4gIFRodXMsICA+ICBpbnN0 YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUgY3JlYXRpb24gDQo+IG9mIGEgU2Vy dmljZSAgPiAgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3IgZm9yd2FyZGluZyAN Cj4gcGFja2V0cyB0aHJvdWdoIHRoZSAgPiAgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlz IHRoZSBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4gID4NCj4gID4gIFRoZSBT RkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yIG5vbi1pbml0aWFs ICA+ICANCj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuICBBcyBwYWNrZXRzIHRyYXZlcnNlIGFu IFNGUCwgID4gIA0KPiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJm b3JtZWQgYnkgYSBjbGFzc2lmaWNhdGlvbiAgDQo+ID4gIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdp dGggYSBzZXJ2aWNlIGZ1bmN0aW9uLiAgUmVjbGFzc2lmaWNhdGlvbiBtYXkgIA0KPiA+ICByZXN1 bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldyBTRlAsIGFuIHVwZGF0ZSBvZiB0aGUgYXNzb2Np YXRlZCAgDQo+ID4gIG1ldGFkYXRhLCBvciBib3RoLiAgVGhpcyBpcyByZWZlcnJlZCB0byBhcyAi YnJhbmNoaW5nIi4NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiAqRnJvbTogKkku U21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPiAqVG86ICpKb2VsIEhhbHBlcm4gRGlyZWN0 PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPixKb2VsIE0uDQo+IEhhbHBlcm48am1oQGpvZWxo YWxwZXJuLmNvbT4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5nQHNjZS5jYXJsZXRvbi4NCj4g Y2E+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc+DQo+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQNCj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4NCj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWlu Zy4NCj4NCj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAo YW5kIHRoYXQgaXMgd2hhdCAxNiANCj4gbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Yg c2VydmljZSBjaGFpbnMgaXMgcHJlY29uY2VpdmVkIGFzIGFuIA0KPiBhYnN1cmQgaWRlYSwgdGhl biB0aGUgYXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGggdGhhdCBwcmVjb25jZXB0aW9uLg0KPg0K PiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mIGFzcGly YXRpb24gdG8gc2NhbGUgDQo+IHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBv ZiB0aGUgYXJjaGl0ZWN0dXJlIC0geW91IGRvbid0IA0KPiBoYXZlIHRvIGtub3cgd2hhdCBpdCBp cywgYnV0IGJ5IHNheWluZyB0aGF0IGFuIGFyYml0cmFyeSBudW1iZXIgaXMgDQo+ICJ0b28gZmFy IiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndCBpbnRlbnRpb25hbCAtIGEgbGlt aXQgDQo+IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3RpbmcgaW1wYWN0 cyByZWdhcmRpbmcgDQo+IHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5 LCBhZGRyZXNzIHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuDQo+IFRoYXQgaXMgYSBwcm9i bGVtIEknbSBub3QgcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4NCj4NCj4NCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPg0KPiBGcm9t OiBKb2VsIEhhbHBlcm4gRGlyZWN0IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTQ0KPiBUbzogSWFuIFNtaXRoOyBKb2Vs IE0uIEhhbHBlcm47IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K Pg0KPiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRo aXMgcmVnYXJkLg0KPiBJIGFtIG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9y IHRoZSBzb2x1dGlvbiBwcm9oaWJpdCANCj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZh c2hpb24uDQo+IEkgYW0gb2JqZWN0aW5nIHRvIEh1YW5nJ3MgcmVhZGluZyBvZiBteSBub3RlIGFz IHNheWluZyB0aGF0IHN1Y2ggDQo+IGRlcGxveW1lbnRzIGFyZSByZXF1aXJlZCB0aGV5IGJ5IHRo ZSBhcmNodGllY3R1cmUuDQo+DQo+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90 IHRyeWluZyB0byBwcm9oaWJpdCBzdWNoIHRoaW5ncy4NCj4gV2hldGhlciB0aGV5IGFyZSBhIGdv b2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uIG1hbnkgZmFjdG9ycyBvdXRzaWRlIA0KPiBvZiB0 aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0byB0aGluayB0aGF0IHRoZXkgYXJlIHVzdWFs bHkgYSBiYWQgaWRlYS4NCj4NCj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2 b2lkaW5nIGF0dGVtcHRpbmcgdG8ga25vdyB3aGF0IGlzIA0KPiBhbmQgaXMgbm90IGVwbG95YWJs ZS4NCj4NCj4gWW91cnMsDQo+IEpvZWwNCj4NCj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNt aXRoIHdyb3RlOg0KPiAgPiBJIGRpc2FncmVlLg0KPiAgPg0KPiAgPiBXZSByb3V0aW5lbHkgaGF2 ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YgbWlsbGlvbnMgb2YgDQo+IGNv bmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXIgZW52 aXJvbm1lbnRzIA0KPiB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4g dGhlIA0KPiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cg eW91IGFyZSBvbmx5IGdvaW5nIHRvIA0KPiBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBj aGFpbnMgd2l0aCBlcXVhbGx5IHNtYWxsIG51bWJlcnMgb2YgDQo+IGFjdGl2ZSBzZXJ2aWNlIHBh dGhzPw0KPiAgPg0KPiAgPiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBl dmVyIG5lZWQgbW9yZSB0aGFuIDY0SyIgZm9yIA0KPiBjb21mb3J0Lg0KPiAgPg0KPiAgPg0KPiAg PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+IEZyb206IHNm YyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4gDQo+ IFtqbWhAam9lbGhhbHBlcm4uY29tXSAgPiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0 OjQ2IFBNICA+IFRvOiANCj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhOyBzZmNAaWV0Zi5vcmcgID4g U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgDQo+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2VycyAgPiAgPiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgDQo+IHNvbWVvbmUgdHJpZXMg dG8gZGVwbG95IHRoZSBhcmNodGlldHVyZSAgPiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgDQo+ IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YgdGhlaXIgZGV2aWNlcy4NCj4gID4gVGhlIGFyY2hp dGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkIHVzZSBvZiBzZXJ2aWNlIHBhdGhz Lg0KPiAgPiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUgYXJjaGl0ZWN0 dXJhbCB3b3JkcyB0byANCj4gcHJvaGliaXQgID4gaXQsIHRoZSBhcmNoaXRlY3R1cmUgZG9lcyBw ZXJtaXQgc3VjaCBhYnVzZS4NCj4gID4NCj4gID4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWlu ZyB0aGF0IHRoZSBhcmNodGllY3R1cmUgcGVybWl0cyANCj4gc29tZXRoaW5nIGFzICA+IHNheWlu ZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieSB0aGUgd29yay4gSXQgaXNuJ3Qu DQo+ICA+DQo+ICA+IFlvdXJzLA0KPiAgPiBKb2VsDQo+ICA+DQo+ICA+IE9uIDcvMTAvMTQsIDQ6 MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+ICA+PiBJZiB5b3UgbmVlZCB0byBzdXBw b3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbCBtZWFuIDE2LDAwMCwwMDAgIA0KPiA+PiBw YXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZyB0YWJsZSBvZiBhIGNvcmUgcm91 dGVyLg0KPiAgPj4NCj4gID4+IENoYW5nDQo+ICA+Pg0KPiAgPj4gT24gMDcvMTAvMjAxNCAwMTox NSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiAgPj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxs b3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20gMSBzZXJ2aWNlIA0KPiBwYXRoIHRvICA+ Pj4gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZSB0aGF0IG9wZXJhdG9ycyBhcmUg DQo+IHByZXBhcmVkIGZvciAgPj4+IHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleSBjaG9vc2UgdG8g YXZvaWQgYW55IHVzZSBvZiANCj4gbG9jYWwgbG9hZCAgPj4+IGJhbGFuY2luZyBhbmQgaW4gc3Rl YWQgcHJvdmlzaW9uIDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4gID4+Pg0KPiAgPj4+IFlvdXJz LA0KPiAgPj4+IEpvZWwNCj4gID4+Pg0KPiAgPj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElF UkFMQSwgTUFSSUEgSCB3cm90ZToNCj4gID4+Pj4gUGF1bCwNCj4gID4+Pj4NCj4gID4+Pj4gSG93 IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgaG9wIHNlcnZpY2Ug DQo+IGNoYWluIHdpdGggID4+Pj4gMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPiAgPj4+Pg0K PiAgPj4+PiBNYXJpYQ0KPiAgPj4+Pg0KPiAgPj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKlBhdWwgDQo+IFF1aW5uICA+Pj4+IChwYXVs cSkgID4+Pj4gKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzIFBNICANCj4gPj4+ PiAqVG86KiBMdWN5IHlvbmcgID4+Pj4gKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbTsgDQo+IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZzsgID4+Pj4gbWlrZWJpYW5j QGFvbC5jb20gIA0KPiA+Pj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzICANCj4gPj4+PiAgPj4+PiBMdWN5LCAgPj4+PiAgPj4+ PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgDQo+IGRyaXZlcyB0aGUg Zm9yd2FyZGluZy4gSeKAmWQgbWFrZSAgPj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCAN Cj4gaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUgdGhlIG5lZWRlZCAgPj4+PiBmb3J3 YXJkaW5nIGFuZCANCj4gYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+ICA+Pj4+DQo+ICA+Pj4+IEl0 IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0byBzaW1wbHkgaWRl bnRpZnkgDQo+IHRoZSAgPj4+PiBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMg bXVzdCB0cmF2ZXJzZS4gQnkgDQo+IGhhdmluZyBhIHBhdGggID4+Pj4gaWRlbnRpZmllciwgdGhl IGV4YWN0IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gDQo+IHRvIGJlIGFza2luZyBmb3Ig b24gID4+Pj4gdGhpcyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gDQo+IFRo ZSBwYXRoIGlkZW50aWZpZXIgcHJvdmlkZXMgID4+Pj4gbm90aGluZyBtb3JlIHRoYW4gYSBsb29r dXAsIHRoYXQgDQo+IGxvb2t1cCBjYW4gcmVzdWx0IGluIGEgb25lIG9yIG1vcmUgID4+Pj4gKGVx dWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dCBob3AocykuDQo+ICA+Pj4+DQo+ICA+Pj4+ IFBhdWwNCj4gID4+Pj4NCj4gID4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVj eSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbSAgDQo+ID4+Pj4gPG1haWx0bzpsdWN5LnlvbmdA aHVhd2VpLmNvbT4+IHdyb3RlOg0KPiAgPj4+Pg0KPiAgPj4+Pg0KPiAgPj4+Pg0KPiAgPj4+PiBB Z3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlIHNl cnZpY2UgDQo+IHBhdGggID4+Pj4gaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBh Y3Rpb25zLg0KPiAgPj4+Pg0KPiAgPj4+PiBMdWN5DQo+ICA+Pj4+DQo+ICA+Pj4+ICpGcm9tOipz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxmICA+Pj4+IA0KPiBPZipt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4NCj4gID4+Pj4gKlNlbnQ6KlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MDYgQU0g ID4+Pj4gDQo+ICpUbzoqbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgPj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+O3NmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gIA0KPiA+Pj4+ICpTdWJqZWN0 OipSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMgIA0K PiA+Pj4+ICA+Pj4+IFJlLSwgID4+Pj4gID4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQg ZXhwbGljaXRseSBhIA0KPiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllci4gSSAgPj4+PiBvYmplY3Qg dG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byANCj4gZGVyaXZlIGZvcndhcmRpbmcgYWN0aW9ucy4N Cj4gID4+Pj4NCj4gID4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxs IGtub3dsZWRnZSBvZiBldmVyeSANCj4gYXZhaWxhYmxlIFNGQyAgPj4+PiBmb3J3YXJkaW5nIHBh dGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgDQo+IG5vdCByZXF1aXJlZC9qdXN0 aWZpZWQgID4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCANCj4gY29udGV4 dHMuDQo+ICA+Pj4+DQo+ICA+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkg b24gdGhlIHBpZWNlIG9mIGluZm9ybWF0aW9uIA0KPiB0aGF0IHdpbGwgID4+Pj4gYmUgcHJlc2Vu dCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSANCj4gcmVxdWlyZWQgdG8gc3Ry dWN0dXJlIGEgID4+Pj4gc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMgDQo+ IHVzZWQgdG8gaW5mZXIgZm9yd2FyZGluZyBhY3Rpb25zICA+Pj4+IGlzIGEgc29sdXRpb24tb3Jp ZW50ZWQgDQo+IGRpc2N1c3Npb24uDQo+ICA+Pj4+DQo+ICA+Pj4+IENoZWVycywNCj4gID4+Pj4N Cj4gID4+Pj4gTWVkDQo+ICA+Pj4+DQo+ICA+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0IA0KPiBkZSptaWtlYmlhbmNAYW9sLmNvbSAgPj4+PiA8 bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAgPj4+PiAqRW52b3nDqSANCj4gOiptZXJjcmVkaSA5 IGp1aWxsZXQgMjAxNCAyMjowMyAgPj4+PiAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tIA0KPiA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPiAgPj4+PiA8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCj4gID4+Pj4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzICANCj4gPj4+PiAgPj4+PiBJcyBhbnlvbmUgc3Rp bGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFpbiANCj4gYW5kIFNG IFBhdGg/DQo+ICA+Pj4+ICAgIE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBz byB0aGF0IGl0J3MgY2xlYXIgdG8NCj4gdGhvc2Ugbm90DQo+ICA+Pj4+IGZhbWlsaWFyIHdpdGgg dGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGVzZSB0ZXJtcy4N Cj4gID4+Pj4NCj4gID4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNs ZWFyIGlzIHdoZXRoZXIgaXQgaXMgdGhlIA0KPiBpbnRlbnQgID4+Pj4gb2YgdGhpcyBkcmFmdCB0 byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUgSUQgb2YgdGhlIA0KPiBTRkMgSGVhZGVyIHNo b3VsZCAgPj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMg DQo+IGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvICA+Pj4+IGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBh bGxvd2luZyBvdGhlciANCj4gZHJhZnRzIHRvIGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgID4+Pj4g Zm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4gDQo+IG9yIHBhdGggYW5kIHRoZSBjaG9pY2Ug b2YgY2hhaW4gb3IgcGF0aCB0byAgPj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSANCj4gY29udHJv bC1wbGFuZS4NCj4gID4+Pj4NCj4gID4+Pj4gSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhl biB0aGUgZHJhZnQgd291bGQgaGF2ZSByZXF1aXJlIA0KPiB0aGF0IGJvdGggID4+Pj4gU0ZQIGFu ZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSByZXF1aXJlZCBhbmQgdGhlIA0KPiBvdGhl ciBvcHRpb25hbCkgID4+Pj4gdG8gYXZvaWQgc29tZSB2ZW5kb3JzIG9ubHkgc3VwcG9ydGluZyBT RlAgYW5kIA0KPiBvdGhlcnMgb25seSBzdXBwb3J0aW5nICA+Pj4+IFNGQy4NCj4gID4+Pj4NCj4g ID4+Pj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiAgPj4+Pg0KPiAgPj4+PiAqRnJvbToqam1o QGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tDQo+ICA+Pj4+IDxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPiAgPj4+PiAqVG86KnNm Y0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcgDQo+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGll dGYub3JnPj4NCj4gID4+Pj4gKlNlbnQ6KlR1ZXNkYXksIEp1bHkgOCwgMjAxNA0KPiAgPj4+PiAq U3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMg ID4+Pj4gIA0KPiA+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBj bGVhcmx5IGFuc3dlciBhIG51bWJlciANCj4gb2YgID4+Pj4gY29tbWVudHMgdGhhdCBoYXZlIGJl ZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVyZ2VkIA0KPiBhcmNodGllY3R1cmUgID4+Pj4g ZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZyBncm91cCBhZ3JlZW1lbnQgDQo+IG9u IHRoZSBpbnRlbnQsIHdlICA+Pj4+IHdpbGwgd29yayB0byBpbXByb3ZlIHRoZSB3b3JkaW5nIHNv IHRoYXQgDQo+IHJlYWRlcnMgd2hvIGhhdmUgbm90ICA+Pj4+IHBhcnRpY2lwYXRlZCBpbiB0aGUg V0cgZGlzY3Vzc2lvbiB3aWxsIA0KPiB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUgd29ya2luZyAg Pj4+PiBncm91cCBpbnRlbmRzLg0KPiAgPj4+Pg0KPiAgPj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRl bmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteSBwZXJzb25hbCB2aWV3LCANCj4gYW5kIHNlZSAg Pj4+PiBpZiB0aGF0IGhlbHBzLg0KPiAgPj4+Pg0KPiAgPj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQg aXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0IHdoYXQgd2UgYXJlICANCj4gPj4+PiBk ZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFyZSBub3QgYXR0ZW1w dGluZyB0byAgDQo+ID4+Pj4gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUg c29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuDQo+ICA+Pj4+IFRoYXQgd291bGQgZW5jb21w YXNzIE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IA0KPiBmdW5jdGlvbnMsICA+ Pj4+IHZpcnR1YWwgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIg YXNwZWN0cy4NCj4gID4+Pj4NCj4gID4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhp bmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0byBleGlzdCBpbiANCj4gdGhlICA+Pj4+IGxhcmdlciBz eXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZSB3aGVyZSB3ZSBhcmUgDQo+IGZ1 bmN0aW9uaW5nLCAgPj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29y ayB3ZSBhcmUgDQo+IGRvaW5nLg0KPiAgPj4+Pg0KPiAgPj4+PiBJbiBvcmRlciB0byBnZXQgdG8g c2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgDQo+IHVuZGVyc3RhbmQgdGhlbSwg ID4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIA0KPiBh cmUgYXQgbGVhc3QgdGhyZWUgID4+Pj4gZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2lu ZyBjYW4gYW5kIA0KPiB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZSAgPj4+PiBjaGFpbmluZy4g VGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuIA0KPiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVy ZSBpcyB0byAgPj4+PiBwZXJtaXQgYWxsIG9mIHRoZXNlLCBidXQgbm90IA0KPiB0byBtYW5kYXRl IHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2VkICA+Pj4+IGluIGFueSBzb2x1dGlvbi4N Cj4gID4+Pj4NCj4gID4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVk IHRvIHRoZSBlbmQgdXNlci4gVGhpcyBpcyANCj4gYSAgPj4+PiBzZXJ2aWNlIGZ1bmN0aW9uLiBJ dCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZCBtb2RpZmllcyB0aGVtIA0KPiAob3IgbWFya3Mg ID4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZSAN Cj4gaW5zdGFuY2UgdG8gcmVjZWl2ZSAgPj4+PiB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFu IGltcG9ydGFudCANCj4gc2VydmljZSBmdW5jdGlvbiB0byBiZSBhYmxlIHRvICA+Pj4+IGluY2x1 ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncyANCj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1 aXJlbWVudHMgb24gID4+Pj4gaG93IHNlcnZpY2UgY2hhaW5pbmcgaXMgDQo+IGRvbmUuIEJ1dCBp dCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSAgPj4+PiBhcmNodGllY3R1cmUuIEZyb20g YW4gDQo+IGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2Ug ID4+Pj4gZnVuY3Rpb24gd2hpY2ggDQo+IG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0 Lg0KPiAgPj4+Pg0KPiAgPj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4g VGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgDQo+IGFwcGVhcnMgID4+Pj4gdG8gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IA0KPiBvZiBjb250YWN0 IGZvciBhICA+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSAN Cj4gZGVsaXZlcmVkIGJ5IGEgY29sbGVjdGlvbiBvZiAgPj4+PiB2aXJ0dWFsIG9yIHBoeXNpY2Fs IG1hY2hpbmVzLCANCj4gcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvciBzZXZlcmFsIGxvYWQgID4+ Pj4gYmFsYW5jZXJzIChmb3IgZXhhbXBsZSANCj4gdXNpbmcgVlJSUC1saWtlIHRlY2huaXF1ZXMg dG8gc2hhcmUgYSBNQUMgID4+Pj4gYWRkcmVzcy4pIG1vc3RseSwgdGhpcyANCj4gaXMgaW52aXNp YmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUgID4+Pj4gbWVjaGFuaXNtcy4g SXQgDQo+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sICA+ Pj4+IG1lY2hhbmlzbXMsIHN1Y2ggDQo+IGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1p biwgc2NhbGUtb3V0LCBhbmQgdm0gID4+Pj4gDQo+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRl Y3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2VseSAgDQo+ID4+Pj4gdGhh dCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVybWlub2xvZ3kgZG9lcyBub3QgbGVh ZCANCj4gcmVhZGVycyB0byAgPj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+ICA+ Pj4+DQo+ICA+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkg c2VsZWN0aW5nIHBhY2tldCANCj4gcGF0aHMgZm9yICA+Pj4+IHRoZSBzZXJ2aWNlIGNoYWluaW5n IHRoYXQgZGlyZWN0IHRyYWZmaWMgdG8gZGlmZmVyZW50IA0KPiBwbGFjZXMuIFdlIHdvdWxkICA+ Pj4+IG5vdCB3YW50IHRvIHJlcXVpcmUgdGhhdCBhIGdpdmVuIHNlcnZpY2UgDQo+IGZ1bmN0aW9u IGFwcGVhciBhdCBvbmx5IG9uZSAgPj4+PiBwbGFjZSBpbiB0aGUgbmV0d29yay4NCj4gID4+Pj4N Cj4gID4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJp bmVkLiBJIHRlbmQgdG8gDQo+IHJlZmVyIHRvICA+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0 aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgDQo+IGNoYWluaW5nIGFzIGEgc2luZ2xlICA+Pj4+ IHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyANCj4gYSBnb29kIHRl cm0uIEJ1dCBiZWNhdXNlIEkgID4+Pj4gZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsIHRo ZSANCj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nIGlzIHRvICA+Pj4+IGRpcmVjdCBk aWZmZXJlbnQgc3Vic2V0cyBvZiANCj4gdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIgb3Ig Y2x1c3RlcmVkICA+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGluIA0KPiBkaWZmZXJlbnQgcGxhY2Vz IGluIHRoZSBuZXR3b3JrLg0KPiAgPj4+Pg0KPiAgPj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdo YXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0IHNlcnZpY2UgDQo+IGNoYWluIGFuZCAgPj4+ PiBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZSBvZiBsb2dpY2FsIA0K PiBmdW5jdGlvbnMgdG8gYmUgID4+Pj4gYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLiBJ dCBpcyBlcXVpdmFsZW50IA0KPiBvZiBzYXlpbmcgdGhhdCBzb21lICA+Pj4+IHN1YnNldCBvZiB0 cmFmZmljIGlzIHRvIGdldCBEUEksIGNoYXJnaW5nLCANCj4gY29udGVudCBpbnNwZWN0aW9uLCBh bmQgID4+Pj4gZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIA0KPiBnbyBk aXJlY3RseSB0byB0aGUgY2FjaGUgd2l0aG91dCAgPj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2Vy dmljZSANCj4gZnVuY3Rpb25zLg0KPiAgPj4+Pg0KPiAgPj4+PiBUaGF0IGlzIG5vdCBlbm91Z2gg aW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNlcnZpY2UgDQo+IHBhdGggID4+ Pj4gaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZiBsb2NhdGlvbnMgaW4gdGhlIA0K PiBuZXR3b3JrLiBUaG9zZSAgPj4+PiBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvciBjbHVz dGVyZWQgc2VydmljZSANCj4gZnVuY3Rpb24gZGVsaXZlcnkgID4+Pj4gbG9jYXRpb25zLiBUaGV5 IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgDQo+IGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3Nl ZCAgPj4+PiBhcyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSANCj4gbWFueSBkaWZmZXJlbnQg d2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMgID4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Lg0KPiAgPj4+Pg0KPiAg Pj4+PiAgID5Gcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3Jv dXAsIHdlIG5lZWQgdG8gYmUNCj4gID4+Pj4gYWJsZQ0KPiAgPj4+PiB0byB0YWxrIGFib3V0IHRo ZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZSBjaGFpbiwgDQo+IHdoaWNoICA+ Pj4+IGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUg DQo+IGFjdHVhbCBkYXRhIHBhdGggID4+Pj4gcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlIG5ldHdv cmsuDQo+ICA+Pj4+DQo+ICA+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAi YnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUgDQo+IGtub3duICA+Pj4+IGF0IHRoZSBmcm9u dC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGggdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4N Cj4gID4+Pj4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQgYmFsYW5jZXJzIGFi b3ZlLCB0aGVyZSBjYW4gDQo+IGJlICA+Pj4+IGRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNo IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgDQo+IGNoYWluaW5nICA+Pj4+IG1lY2hhbmlz bXMgKGluIG11Y2ggdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgDQo+IExBTiBp cyBsYXJnZWx5ICA+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBv dGhlciANCj4gcHJvdmlzaW9uIHdlIG1ha2UgaXMgdGhhdCAgPj4+PiByZWNsYXNzaWZpY2F0aW9u IGNhbiBiZSBkb25lIGluIA0KPiBtaWQtY2hhaW4gd2hlbiBuZWNlc3NhcnkuIFRoYXQgd2lsbCAg Pj4+PiBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyANCj4gY2hhaW4uIEJhc2VkIG9uIGluZm9ybWF0 aW9uIGF2YWlsYWJsZSBhdCB0aGUgID4+Pj4gcmUtY2xhc3NpZmljYXRpb24gDQo+IHBvaW50Lg0K PiAgPj4+Pg0KPiAgPj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBh cmUgYWZ0ZXIuIElmIGl0IGRvZXMsIA0KPiBhbmQgaWYgID4+Pj4gdGhlIGludGVudCBpcyBhY2Nl cHRhYmxlIHRvIHRoZSB3b3JraW5nIGdyb3VwLCB3ZSBjYW4gDQo+IGZpZ3VyZSBvdXQgd2hhdCAg Pj4+PiBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuDQo+ICA+Pj4+ IElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVudCwgdGhlbiB3ZSB3 aWxsIG9mIA0KPiBjb3Vyc2UgID4+Pj4gYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3Vw IGFncmVlbWVudHMuDQo+ICA+Pj4+IElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qg c3VyZSB3aGF0IHRvIHRyeSBuZXh0Lg0KPiAgPj4+Pg0KPiAgPj4+PiBZb3VycywNCj4gID4+Pj4g Sm9lbA0KPiAgPj4+Pg0KPiAgPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiAgPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+ICA+Pj4+IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gID4+Pj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+Pj4+DQo+ICA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+Pj4+IHNmYyBtYWlsaW5nIGxpc3QN Cj4gID4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiAgPj4+PiANCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gID4+Pj4NCj4gID4+Pg0K PiAgPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ICA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4+IHNmY0BpZXRmLm9yZw0KPiAgPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+Pj4NCj4gID4+DQo+ICA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4g c2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4gc2ZjQGlldGYub3JnDQo+ICA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAgPj4NCj4gID4NCj4gID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4gc2ZjIG1haWxpbmcg bGlzdA0KPiAgPiBzZmNAaWV0Zi5vcmcNCj4gID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4gID4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNm Y0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg== From nobody Thu Jul 10 20:42: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 C946C1A0403 for ; Thu, 10 Jul 2014 20:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 ncuzeviuiako for ; Thu, 10 Jul 2014 20:41:59 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E971A02EC for ; Thu, 10 Jul 2014 20:41:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="121331550" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABPCoNBV60VjzIXhzWBN3SCJQEBAQEDAQEBF0sJAhkCAQgRAQMBAQEKHQcnCxQDBggCBAESCBOHTQMezBATBIxTgT0FJjgCgyKBFASULUSOYYp+gWpB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 11 Jul 2014 03:41:59 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 10 Jul 2014 20:41:57 -0700 From: Ian Smith To: "Joel M. Halpern" , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuYoIgAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoD//4sNNIAAec4A//+LGXeAAIeGgIAAAVyAgAA4u4CAAAHeAP//jZBDAA8JeAD//4yktg== Date: Fri, 11 Jul 2014 03:41:56 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83CD00@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com>, <53BF469E.9010108@joelhalpern.com> In-Reply-To: <53BF469E.9010108@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.167] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/au42BwgkeZIUj2C2tM0GZOXyNuA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 03:42:05 -0000 That is the same way I'm looking at it.=0A= =0A= I do see a possible way to make conditional service function paths that don= 't need to rely on SNF or SFF. And I see away possible way to make composi= te or federated SFI assignments to a service function path from multiple po= licy agencies to support things like roaming or tenant controlled service f= unction domains within .=0A= =0A= I don't think that we need to be proscriptive about how the inputs to the s= ervice function path selection get there, because that is going to vary. N= o matter how this is provisioned, we know a few things:=0A= =0A= If something triggers a service function chain selection (how a selection i= s triggered doesn't matter):=0A= - A service function chain must be selected (how is an implementation deta= il). =0A= - A service function instance in position 1 in the service function path m= ust be selected to arrive at the initial state (how is an implementation de= tail).=0A= - To move from position 1 to position 2 the location of position 2 must be = identified (how is an implementation detail).=0A= =0A= Therefore, we can say that in general, to move from position n to position = n+1 the location of position n+2 must be identified. If position n+1 cann= ot be identified, then position n executes it's fallback contingency.=0A= =0A= That is enough architecture to build a sophisticated system if we are ignor= ing the policy and orchestration plane. =0A= =0A= ________________________________________ =0A= From: Joel M. Halpern [jmh@joelhalpern.com=0A= Sent: Thursday, July 10, 2014 10:06 PM=0A= To: Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= Part of my personal view is that I am trying to make this work sensibly=0A= in a more orchestrated environment. I expect that the service=0A= functions, and over time probably the SFF capabilities, will be=0A= orchestrated and installed. I expect the service chains to be driven by=0A= BSS tools that define offerings to clients, and enable self-selection=0A= from these. I expect service paths to be heavily policy drive.=0A= =0A= I can see how to make all of that work in an archtiecture driven by=0A= initial classification to described service paths. It is harder to see=0A= how to make it work (but it can be done) when we allow more dynamicity=0A= in the network behavior.=0A= =0A= Having said that, most of that perspective I described is outside of the=0A= scope of the working group. it is not something we are tasked to agree=0A= on.=0A= So I do not claim that vision means we have to do it a certain way. it=0A= is just the perspective that drives my preferences.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 7/10/14, 9:58 PM, Ian Smith wrote:=0A= >> For me, the amount of information about service instances that needs to= =0A= >> be widely distributed and maintained, potentially even across data=0A= >> centers within an administrative scope, is large enough and complex=0A= >> enough that trying to get that into each SFF seems like a difficult=0A= >> architecture to realize.=0A= >=0A= > I'm curious as to why that is more complicated than dynamic routing, hype= r-scale data center orchestration, or DNS, all of which are bigger problems= that have been profitably and stably implemented?=0A= >=0A= > It also seems that if it really is more complicated, that is a good sign = that it is too complicated.=0A= >=0A= > ________________________________________=0A= > From: Joel M. Halpern [jmh@joelhalpern.com]=0A= > Sent: Thursday, July 10, 2014 9:45 PM=0A= > To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; sfc@ie= tf.org=0A= > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >=0A= > This is an architectural issue. And one that I would prefer we actually= =0A= > decide, rather than trying to allow all possible implementations.=0A= > Because it does have a major effect on the control requirements and the= =0A= > functionality of SFFs.=0A= >=0A= > For me, the amount of information about service instances that needs to= =0A= > be widely distributed and maintained, potentially even across data=0A= > centers within an administrative scope, is large enough and complex=0A= > enough that trying to get that into each SFF seems like a difficult=0A= > architecture to realize.=0A= >=0A= > Yours,=0A= > Joel=0A= >=0A= > But it is a fair question.=0A= >=0A= > On 7/10/14, 9:38 PM, Ron Parker wrote:=0A= >> This is the crux of my issue. Is the end to end selection of=0A= >> (top-level) instances performed centrally (perhaps by the classifier)=0A= >> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)?=0A= >> Such selection is not equivalent to reclassification. And surely,=0A= >> this is an architectural issue and not relegated to=0A= >> "implementation".=0A= >>=0A= >> My own view is to favor the distributed approach even though a=0A= >> greater amount of data (chain definitions and perhaps local selection=0A= >> policy) is required at those distributed decision points. This=0A= >> approach does not require an end-to-end path id at all. My=0A= >> rationale for favoring this approach is primarily driven by increased=0A= >> resiliency over the global path id approach. With a global path id=0A= >> approach, consider failure of an instance and needing to alter the=0A= >> global path ID table for each and every affected end-to-end path.=0A= >>=0A= >> Ron=0A= >>=0A= >> ________________________________________ From: sfc=0A= >> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct=0A= >> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM=0A= >> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:=0A= >> [sfc] Service Chains, Paths, and Load Balancers=0A= >>=0A= >> The way the architecture models the case of SF1 needing to influence=0A= >> the chain is that one would do reclassification at the exit from=0A= >> SF1.=0A= >>=0A= >> Part of the goal is to keep the different functions logically=0A= >> separate so that solutions can clearly describe how they choose to=0A= >> compose them for "service" delivery.=0A= >>=0A= >> Yours, Joel=0A= >>=0A= >> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote:=0A= >>> I don't see anything in the arch draft that suggests any sort of=0A= >>> limit. However, it does seem to indicate that the entire path (all=0A= >>> SFIs) must be chosen at SFC instantiation. I believe this means=0A= >>> either at the classifier or maybe the classifier chooses a SF Chain=0A= >>> and the NF or at the latest the first SFF. In any case, the=0A= >>> language does seem to prohibit a more dynamic SFP where SFI(n) is=0A= >>> determined at the SFI(n-1) hop. According to the draft, this=0A= >>> behavior would be considered "branching" to a new SFP as opposed to=0A= >>> choosing and then forwarding to the selected instance of the=0A= >>> next-hop of the current SFC.=0A= >>>=0A= >>> draft-merged-sfc-architecture-00:=0A= >>>> When an SFC is instantiated into the network it is necessary to=0A= >>>> select the specific instances of SFs that will be used, and to=0A= >>>> create the service topology for that SFC using SF's network=0A= >>>> locator. Thus, instantiation of the SFC results in the creation=0A= >>>> of a Service Function Path (SFP) and is used for forwarding=0A= >>>> packets through the SFC. In other words, an SFP is the=0A= >>>> instantiation of the defined SFC.=0A= >>>>=0A= >>>> The SFC architecture supports reclassification (or non-initial=0A= >>>> classification) as well. As packets traverse an SFP,=0A= >>>> reclassification may occur - typically performed by a=0A= >>>> classification function co-resident with a service function.=0A= >>>> Reclassification may result in the selection of a new SFP, an=0A= >>>> update of the associated metadata, or both. This is referred to=0A= >>>> as "branching".=0A= >>>=0A= >>>=0A= >>>=0A= >>> -----------------------------------------------------------------------= -=0A= >>>=0A= >>>=0A= > *From: *I.Smith@F5.com=0A= >>> *To: *Joel Halpern Direct,Joel M.=0A= >>> Halpern,huang@sce.carleton.ca,sfc@ietf.org=0A= >>>=0A= >>>=0A= > *Sent: *Thursday, July 10, 2014=0A= >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> Actually, I think I am disagreeing.=0A= >>>=0A= >>> If the possibility of medium-scale deployments (and that is what=0A= >>> 16 million flows is in my world) of service chains is preconceived=0A= >>> as an absurd idea, then the architecture burdened with that=0A= >>> preconception.=0A= >>>=0A= >>> There has to be some point of aim, some degree of aspiration to=0A= >>> scale that is appropriate for the lifespan of the architecture -=0A= >>> you don't have to know what it is, but by saying that an arbitrary=0A= >>> number is "too far", you're creating - even if it isn't intentional=0A= >>> - a limit that influences decisions that have lasting impacts=0A= >>> regarding scale-out, failure mitigation, elasticity, address=0A= >>> space... all kinds of things. That is a problem I'm not=0A= >>> particularly eager to deal with.=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> ________________________________________=0A= >>>=0A= >>>=0A= >>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent:=0A= >>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;=0A= >>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service=0A= >>> Chains, Paths, and Load Balancers=0A= >>>=0A= >>> Ian, I don't think you disagree with me at all in this regard. I am=0A= >>> not requesting the the architecture or the solution prohibit=0A= >>> deployments in the specific fashion. I am objecting to Huang's=0A= >>> reading of my note as saying that such deployments are required=0A= >>> they by the archtiecture.=0A= >>>=0A= >>> As I have said repeatedly, I am not trying to prohibit such=0A= >>> things. Whether they are a good idea or not depends upon many=0A= >>> factors outside of the scope of the WG. I happen to think that they=0A= >>> are usually a bad idea.=0A= >>>=0A= >>> But the archtiecture si carefully avoiding attempting to know what=0A= >>> is and is not eployable.=0A= >>>=0A= >>> Yours, Joel=0A= >>>=0A= >>> On 7/10/14, 5:01 PM, Ian Smith wrote:=0A= >>>> I disagree.=0A= >>>>=0A= >>>> We routinely have stateful devices that manage tens of millions=0A= >>>> of=0A= >>> concurrent flows in both access network and data center=0A= >>> environments today. You can't seriously believe that in the=0A= >>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going=0A= >>> to have small numbers of service chains with equally small numbers=0A= >>> of active service paths?=0A= >>>>=0A= >>>> Your sounds too much like "no one will ever need more than 64K"=0A= >>>> for=0A= >>> comfort.=0A= >>>>=0A= >>>>=0A= >>>> ________________________________________ From: sfc=0A= >>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern=0A= >>> [jmh@joelhalpern.com]=0A= >>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca;=0A= >>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load=0A= >>>> Balancers=0A= >>>>=0A= >>>> No, it will mean that if someone tries to deploy the archtieture=0A= >>>> particularly badly, they will exceed the limits of their=0A= >>>> devices. The architecture does not require such absurd use of=0A= >>>> service paths. Since I can not figure out how to write=0A= >>>> architectural words to prohibit it, the architecture does permit=0A= >>>> such abuse.=0A= >>>>=0A= >>>> Please do not read my saying that the archtiecture permits=0A= >>>> something as saying it is either deisred or required by the work.=0A= >>>> It isn't.=0A= >>>>=0A= >>>> Yours, Joel=0A= >>>>=0A= >>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:=0A= >>>>> If you need to support 100 service chains, it will mean=0A= >>>>> 16,000,000 paths. That is larger than the routing table of a=0A= >>>>> core router.=0A= >>>>>=0A= >>>>> Chang=0A= >>>>>=0A= >>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:=0A= >>>>>> The architecture allows a range of deployments, from 1=0A= >>>>>> service path to 160000 service paths. I would hope that=0A= >>>>>> operators are prepared for the complexities if they choose to=0A= >>>>>> avoid any use of local load balancing and in stead provision=0A= >>>>>> 160,000 service paths.=0A= >>>>>>=0A= >>>>>> Yours, Joel=0A= >>>>>>=0A= >>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:=0A= >>>>>>> Paul,=0A= >>>>>>>=0A= >>>>>>> How many path identifiers there will be for a 4 hop service=0A= >>>>>>> chain with 20 instances at each hop?=0A= >>>>>>>=0A= >>>>>>> Maria=0A= >>>>>>>=0A= >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of=0A= >>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03=0A= >>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;=0A= >>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org;=0A= >>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains,=0A= >>>>>>> Paths, and Load Balancers=0A= >>>>>>>=0A= >>>>>>> Lucy,=0A= >>>>>>>=0A= >>>>>>> Overall I concur, as you say: a path ID drives the=0A= >>>>>>> forwarding. I=92d=0A= >>> make=0A= >>>>>>> the minor change: the path identifier can be used to derive=0A= >>>>>>> the needed forwarding and associated transport.=0A= >>>>>>>=0A= >>>>>>> It is _not_ the transport, but rather is used to simply=0A= >>>>>>> identify the service path (or graph) that packets must=0A= >>>>>>> traverse. By having a path identifier, the exact=0A= >>>>>>> indirection that people seem to be asking for on this=0A= >>>>>>> thread can be simply be implemented. The path identifier=0A= >>>>>>> provides nothing more than a lookup, that lookup can result=0A= >>>>>>> in a one or more (equal or weighted) transport next=0A= >>>>>>> hop(s).=0A= >>>>>>>=0A= >>>>>>> Paul=0A= >>>>>>>=0A= >>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong=0A= >>>>>>> >=0A= >>>>>>> wrote:=0A= >>>>>>>=0A= >>>>>>>=0A= >>>>>>>=0A= >>>>>>> Agree. The arch. doc should not mandate only use of the=0A= >>>>>>> service path identifier to drive the forwarding actions.=0A= >>>>>>>=0A= >>>>>>> Lucy=0A= >>>>>>>=0A= >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=0A= >>>>>>> Of*mohamed.boucadair@orange.com=0A= >>>>>>> *Sent:*Thursday, July=0A= >>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com=0A= >>>>>>> ;jmh@joelhalpern.com=0A= >>>>>>> ;sfc@ietf.org=0A= >>>>>>> *Subject:*Re: [sfc] Service Chains,=0A= >>>>>>> Paths, and Load Balancers=0A= >>>>>>>=0A= >>>>>>> Re-,=0A= >>>>>>>=0A= >>>>>>> The merged draft calls out explicitly a service path=0A= >>>>>>> identifier. I object to use that identifier to derive=0A= >>>>>>> forwarding actions.=0A= >>>>>>>=0A= >>>>>>> Requiring a SFC system to have the full knowledge of every=0A= >>> available SFC=0A= >>>>>>> forwarding paths within an SFC-enabled domain is not=0A= >>> required/justified=0A= >>>>>>> nor possible in various deployment contexts.=0A= >>>>>>>=0A= >>>>>>> SFC forwarding actions should rely on the piece of=0A= >>>>>>> information=0A= >>> that will=0A= >>>>>>> be present in all deployments: that is the one required to=0A= >>>>>>> structure a service chain. How that information is used to=0A= >>>>>>> infer forwarding=0A= >>> actions=0A= >>>>>>> is a solution-oriented discussion.=0A= >>>>>>>=0A= >>>>>>> Cheers,=0A= >>>>>>>=0A= >>>>>>> Med=0A= >>>>>>>=0A= >>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part=0A= >>> de*mikebianc@aol.com=0A= >>>>>>> *Envoy=E9 :*mercredi 9 juillet=0A= >>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com=0A= >>>>>>> ;sfc@ietf.org=0A= >>>>>>> *Objet :*Re: [sfc] Service Chains,=0A= >>>>>>> Paths, and Load Balancers=0A= >>>>>>>=0A= >>>>>>> Is anyone still questioning the difference between SF Chain=0A= >>>>>>> and SF=0A= >>> Path?=0A= >>>>>>> Other than clarifying the definition so that it's clear to=0A= >>> those not=0A= >>>>>>> familiar with the draft, it seems that everyone agrees on=0A= >>>>>>> these terms.=0A= >>>>>>>=0A= >>>>>>> To me, the one point that is still unclear is whether it is=0A= >>>>>>> the intent of this draft to ultimately specify what the ID=0A= >>>>>>> of the SFC Header=0A= >>> should=0A= >>>>>>> reference (the chain or the path), or if this draft simply=0A= >>>>>>> intends to leave that ambiguous, allowing other drafts to=0A= >>>>>>> dictate the mechanisms for forwarding based on chain or=0A= >>>>>>> path and the choice of chain or=0A= >>> path to=0A= >>>>>>> be negotiated in the control-plane.=0A= >>>>>>>=0A= >>>>>>> If the latter (ambiguous), then the draft would have=0A= >>>>>>> require that both SFP and SFC be supported (or make one=0A= >>>>>>> required and the other optional) to avoid some vendors only=0A= >>>>>>> supporting SFP and others only supporting SFC.=0A= >>>>>>>=0A= >>>>>>>=0A= >>> -----------------------------------------------------------------------= -=0A= >>>=0A= >>>=0A= >>>>>=0A= >>>>>>> *From:*jmh@joelhalpern.com>>>>>> >=0A= >>>>>>> *To:*sfc@ietf.org>>>>>> > *Sent:*Tuesday, July=0A= >>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load=0A= >>>>>>> Balancers=0A= >>>>>>>=0A= >>>>>>> I have been trying to figure out how to clearly answer a=0A= >>>>>>> number of comments that have been made about the proposed=0A= >>>>>>> merged archtiecture draft. Assuming we can get working=0A= >>>>>>> group agreement on the intent, we will work to improve the=0A= >>>>>>> wording so that readers who have not participated in the WG=0A= >>>>>>> discussion will understnd it the way the=0A= >>> working=0A= >>>>>>> group intends.=0A= >>>>>>>=0A= >>>>>>> But what do we intend? I will try to explain my personal=0A= >>>>>>> view, and see if that helps.=0A= >>>>>>>=0A= >>>>>>> In this regard, it is important to keep in mind that what=0A= >>>>>>> we are defining is the data plane architecture. We are not=0A= >>>>>>> attempting to define the architecture for the entire=0A= >>>>>>> solution for service chaining. That would encompass=0A= >>>>>>> OSS/BSS, various control and policy functions, virtual=0A= >>>>>>> machine and image management, and many other aspects.=0A= >>>>>>>=0A= >>>>>>> As a result there are many things which clearly need to=0A= >>>>>>> exist in the larger system, but which are dealt with above=0A= >>>>>>> where we are=0A= >>> functioning,=0A= >>>>>>> and are not directly required by the work we are doing.=0A= >>>>>>>=0A= >>>>>>> In order to get to service chain vs service path, as I=0A= >>>>>>> understand=0A= >>> them,=0A= >>>>>>> I need to first discuss load balancing. There are at least=0A= >>>>>>> three different ways that load balancing can and will=0A= >>>>>>> interact with service chaining. There probably are more.=0A= >>>>>>> The point of the archtiecture is to permit all of these,=0A= >>>>>>> but not to mandate that any particular kind=0A= >>> be used=0A= >>>>>>> in any solution.=0A= >>>>>>>=0A= >>>>>>> 1) Load balancing as a service provided to the end user.=0A= >>>>>>> This is a service function. It receives user packets, and=0A= >>>>>>> modifies them (or=0A= >>> marks=0A= >>>>>>> them, or ...) so as to choose an end user service instance=0A= >>>>>>> to receive the users packet. This is an important service=0A= >>>>>>> function to be able to include in service chaining. It's=0A= >>>>>>> behavior may affect requirements on how service chaining is=0A= >>>>>>> done. But it has very little impact on the archtiecture.=0A= >>>>>>> From an architectural pe3rspective it is simply a=0A= >>> service=0A= >>>>>>> function which may modify the underlying packet.=0A= >>>>>>>=0A= >>>>>>> 2) There is internal load balancing. That is, one can have=0A= >>>>>>> what=0A= >>> appears=0A= >>>>>>> to the service chaining architecture as a single point of=0A= >>>>>>> contact=0A= >>> for a=0A= >>>>>>> specific service function, but is actually delivered by a=0A= >>> collection of=0A= >>>>>>> virtual or physical machines, possibly including one or=0A= >>>>>>> several load balancers (for example using VRRP-like=0A= >>>>>>> techniques to share a MAC address.) mostly, this is=0A= >>>>>>> invisible to the service chaining data plane mechanisms. It=0A= >>>>>>> is likely that it is visible to various control mechanisms,=0A= >>>>>>> such as those responsible for scale-in, scale-out, and vm=0A= >>>>>>> instantiation. The architectural impact of permitting this=0A= >>>>>>> is largely that we need to be careful that our terminology=0A= >>>>>>> does not lead=0A= >>> readers to=0A= >>>>>>> think we are prohibiting it.=0A= >>>>>>>=0A= >>>>>>> 3) There can also be load balancing done by selecting=0A= >>>>>>> packet paths for the service chaining that direct traffic=0A= >>>>>>> to different places. We would not want to require that a=0A= >>>>>>> given service function appear at only one place in the=0A= >>>>>>> network.=0A= >>>>>>>=0A= >>>>>>> It is of course the case that these may be combined. I tend=0A= >>>>>>> to=0A= >>> refer to=0A= >>>>>>> the collection of entities that appear to service chaining=0A= >>>>>>> as a single point as a cluster. Not because cluster is a=0A= >>>>>>> good term. But because I do not have another one. Thus, the=0A= >>>>>>> point of type 3 load balancing=0A= >>> is to=0A= >>>>>>> direct different subsets of traffic to different singular=0A= >>>>>>> or clustered service functions in different places in the=0A= >>>>>>> network.=0A= >>>>>>>=0A= >>>>>>> Now with that said, what do I mean when I talk about=0A= >>>>>>> service chain and service path/ Service chain is a sequence=0A= >>>>>>> of logical functions to be applied to a subset of packets.=0A= >>>>>>> It is equivalent of saying that some subset of traffic is=0A= >>>>>>> to get DPI, charging, content inspection, and firewall=0A= >>>>>>> while a different subset is to go directly to the cache=0A= >>> without=0A= >>>>>>> visiting any other service functions.=0A= >>>>>>>=0A= >>>>>>> That is not enough information to direct the packets. A=0A= >>>>>>> service path is, in some fashion, a sequence of locations=0A= >>>>>>> in the network. Those locations will be singular or=0A= >>>>>>> clustered service function delivery locations. They may be=0A= >>>>>>> addressed by IP address. They may be addressed as ports on=0A= >>>>>>> an SFF. There are many different ways that the locations=0A= >>>>>>> may be known to the service chaining infrastructure and the=0A= >>>>>>> transport.=0A= >>>>>>>=0A= >>>>>>>> From the point of view of the work of the SFC group, we=0A= >>>>>>>> need to be=0A= >>>>>>> able to talk about the high level abstraction, the service=0A= >>>>>>> chain, which drives the forwarding. And we need to talk=0A= >>>>>>> about the actual data path packets will take in the=0A= >>>>>>> network.=0A= >>>>>>>=0A= >>>>>>> Several of the comments have said "but the whole path may=0A= >>>>>>> not be known at the front." This architecture deals with=0A= >>>>>>> that issue in two ways. First, as noted in item (2) on load=0A= >>>>>>> balancers above, there can be decisions and behaviors which=0A= >>>>>>> are invisible to the service chaining mechanisms (in much=0A= >>>>>>> the same way that bridging within a LAN is largely=0A= >>>>>>> invisible to routing between LANs.) The other provision we=0A= >>>>>>> make is=0A= >>> that=0A= >>>>>>> reclassification can be done in mid-chain when necessary.=0A= >>>>>>> That will direct packets to a new chain. Based on=0A= >>>>>>> information available at the re-classification point.=0A= >>>>>>>=0A= >>>>>>> I hope that this helps explain what we are after. If it=0A= >>>>>>> does, and if the intent is acceptable to the working group,=0A= >>>>>>> we can figure out what additional words are needed to=0A= >>>>>>> convey this. If the working group disagree with the intent,=0A= >>>>>>> then we will of course adjust to match the working group=0A= >>>>>>> agreements. If this is still unclear, I am not sure what to=0A= >>>>>>> try next.=0A= >>>>>>>=0A= >>>>>>> Yours, Joel=0A= >>>>>>>=0A= >>>>>>> _______________________________________________ sfc mailing=0A= >>>>>>> list sfc@ietf.org =0A= >>>>>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>>>=0A= >>>>>>> _______________________________________________ sfc mailing=0A= >>>>>>> list sfc@ietf.org =0A= >>>>>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>>>=0A= >>>>>>=0A= >>>>>> _______________________________________________ sfc mailing=0A= >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>>=0A= >>>>>=0A= >>>>> _______________________________________________ sfc mailing=0A= >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>>=0A= >>>>=0A= >>>> _______________________________________________ sfc mailing list=0A= >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>=0A= >>>=0A= >>> _______________________________________________ sfc mailing list=0A= >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >> _______________________________________________ sfc mailing list=0A= >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >> _______________________________________________ sfc mailing list=0A= >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >=0A= From nobody Thu Jul 10 20:53: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 0DA821A0439 for ; Thu, 10 Jul 2014 20:53:31 -0700 (PDT) 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_29=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 vMGIhmQ3J3e7 for ; Thu, 10 Jul 2014 20:53:28 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5FF1A0275 for ; Thu, 10 Jul 2014 20:53:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 34CF0842DD9; Thu, 10 Jul 2014 20:53:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id CD0DC842DD8; Thu, 10 Jul 2014 20:53:25 -0700 (PDT) Message-ID: <53BF5FB5.6020906@joelhalpern.com> Date: Thu, 10 Jul 2014 23:53:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> In-Reply-To: <53BF469E.9010108@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pEOr0wO_o--IpiJxQEoSRg2SEFA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 03:53:31 -0000 Ron, thinking about this, I realized another major problem with the your proposal as I understand it. (And I readily admit I may not understand it.) The proposal has each SFF serve as the load balancer for the next service function that follows it (not the one it delivers to), in every service chain that goes through it. Since it has to be able to work with all services, that means that every SFF would have to be a full, flow sensitive and stateful load balancer. I ahve no problem if some SFF are flow sensitive, and / or stateful. But having the architecture require that every SFF be a full, flow sensitive, stateful, load balancer seems to me to be an acceptable imposition. Yours, Joel On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > Part of my personal view is that I am trying to make this work sensibly > in a more orchestrated environment. I expect that the service > functions, and over time probably the SFF capabilities, will be > orchestrated and installed. I expect the service chains to be driven by > BSS tools that define offerings to clients, and enable self-selection > from these. I expect service paths to be heavily policy drive. > > I can see how to make all of that work in an archtiecture driven by > initial classification to described service paths. It is harder to see > how to make it work (but it can be done) when we allow more dynamicity > in the network behavior. > > Having said that, most of that perspective I described is outside of the > scope of the working group. it is not something we are tasked to agree on. > So I do not claim that vision means we have to do it a certain way. it > is just the perspective that drives my preferences. > > Yours, > Joel > > On 7/10/14, 9:58 PM, Ian Smith wrote: >>> For me, the amount of information about service instances that needs to >>> be widely distributed and maintained, potentially even across data >>> centers within an administrative scope, is large enough and complex >>> enough that trying to get that into each SFF seems like a difficult >>> architecture to realize. >> >> I'm curious as to why that is more complicated than dynamic routing, >> hyper-scale data center orchestration, or DNS, all of which are bigger >> problems that have been profitably and stably implemented? >> >> It also seems that if it really is more complicated, that is a good >> sign that it is too complicated. >> >> ________________________________________ >> From: Joel M. Halpern [jmh@joelhalpern.com] >> Sent: Thursday, July 10, 2014 9:45 PM >> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >> sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> This is an architectural issue. And one that I would prefer we actually >> decide, rather than trying to allow all possible implementations. >> Because it does have a major effect on the control requirements and the >> functionality of SFFs. >> >> For me, the amount of information about service instances that needs to >> be widely distributed and maintained, potentially even across data >> centers within an administrative scope, is large enough and complex >> enough that trying to get that into each SFF seems like a difficult >> architecture to realize. >> >> Yours, >> Joel >> >> But it is a fair question. >> >> On 7/10/14, 9:38 PM, Ron Parker wrote: >>> This is the crux of my issue. Is the end to end selection of >>> (top-level) instances performed centrally (perhaps by the classifier) >>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>> Such selection is not equivalent to reclassification. And surely, >>> this is an architectural issue and not relegated to >>> "implementation". >>> >>> My own view is to favor the distributed approach even though a >>> greater amount of data (chain definitions and perhaps local selection >>> policy) is required at those distributed decision points. This >>> approach does not require an end-to-end path id at all. My >>> rationale for favoring this approach is primarily driven by increased >>> resiliency over the global path id approach. With a global path id >>> approach, consider failure of an instance and needing to alter the >>> global path ID table for each and every affected end-to-end path. >>> >>> Ron >>> >>> ________________________________________ From: sfc >>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>> [sfc] Service Chains, Paths, and Load Balancers >>> >>> The way the architecture models the case of SF1 needing to influence >>> the chain is that one would do reclassification at the exit from >>> SF1. >>> >>> Part of the goal is to keep the different functions logically >>> separate so that solutions can clearly describe how they choose to >>> compose them for "service" delivery. >>> >>> Yours, Joel >>> >>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>> I don't see anything in the arch draft that suggests any sort of >>>> limit. However, it does seem to indicate that the entire path (all >>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>> either at the classifier or maybe the classifier chooses a SF Chain >>>> and the NF or at the latest the first SFF. In any case, the >>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>> determined at the SFI(n-1) hop. According to the draft, this >>>> behavior would be considered "branching" to a new SFP as opposed to >>>> choosing and then forwarding to the selected instance of the >>>> next-hop of the current SFC. >>>> >>>> draft-merged-sfc-architecture-00: >>>>> When an SFC is instantiated into the network it is necessary to >>>>> select the specific instances of SFs that will be used, and to >>>>> create the service topology for that SFC using SF's network >>>>> locator. Thus, instantiation of the SFC results in the creation >>>>> of a Service Function Path (SFP) and is used for forwarding >>>>> packets through the SFC. In other words, an SFP is the >>>>> instantiation of the defined SFC. >>>>> >>>>> The SFC architecture supports reclassification (or non-initial >>>>> classification) as well. As packets traverse an SFP, >>>>> reclassification may occur - typically performed by a >>>>> classification function co-resident with a service function. >>>>> Reclassification may result in the selection of a new SFP, an >>>>> update of the associated metadata, or both. This is referred to >>>>> as "branching". >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >> *From: *I.Smith@F5.com >>>> *To: *Joel Halpern Direct,Joel M. >>>> Halpern,huang@sce.carleton.ca,sfc@ietf.org >>>> >>>> >>>> >> *Sent: *Thursday, July 10, 2014 >>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Actually, I think I am disagreeing. >>>> >>>> If the possibility of medium-scale deployments (and that is what >>>> 16 million flows is in my world) of service chains is preconceived >>>> as an absurd idea, then the architecture burdened with that >>>> preconception. >>>> >>>> There has to be some point of aim, some degree of aspiration to >>>> scale that is appropriate for the lifespan of the architecture - >>>> you don't have to know what it is, but by saying that an arbitrary >>>> number is "too far", you're creating - even if it isn't intentional >>>> - a limit that influences decisions that have lasting impacts >>>> regarding scale-out, failure mitigation, elasticity, address >>>> space... all kinds of things. That is a problem I'm not >>>> particularly eager to deal with. >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> >>>> >>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>> Chains, Paths, and Load Balancers >>>> >>>> Ian, I don't think you disagree with me at all in this regard. I am >>>> not requesting the the architecture or the solution prohibit >>>> deployments in the specific fashion. I am objecting to Huang's >>>> reading of my note as saying that such deployments are required >>>> they by the archtiecture. >>>> >>>> As I have said repeatedly, I am not trying to prohibit such >>>> things. Whether they are a good idea or not depends upon many >>>> factors outside of the scope of the WG. I happen to think that they >>>> are usually a bad idea. >>>> >>>> But the archtiecture si carefully avoiding attempting to know what >>>> is and is not eployable. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>> I disagree. >>>>> >>>>> We routinely have stateful devices that manage tens of millions >>>>> of >>>> concurrent flows in both access network and data center >>>> environments today. You can't seriously believe that in the >>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>> to have small numbers of service chains with equally small numbers >>>> of active service paths? >>>>> >>>>> Your sounds too much like "no one will ever need more than 64K" >>>>> for >>>> comfort. >>>>> >>>>> >>>>> ________________________________________ From: sfc >>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>> [jmh@joelhalpern.com] >>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>> Balancers >>>>> >>>>> No, it will mean that if someone tries to deploy the archtieture >>>>> particularly badly, they will exceed the limits of their >>>>> devices. The architecture does not require such absurd use of >>>>> service paths. Since I can not figure out how to write >>>>> architectural words to prohibit it, the architecture does permit >>>>> such abuse. >>>>> >>>>> Please do not read my saying that the archtiecture permits >>>>> something as saying it is either deisred or required by the work. >>>>> It isn't. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>> If you need to support 100 service chains, it will mean >>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>> core router. >>>>>> >>>>>> Chang >>>>>> >>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>> The architecture allows a range of deployments, from 1 >>>>>>> service path to 160000 service paths. I would hope that >>>>>>> operators are prepared for the complexities if they choose to >>>>>>> avoid any use of local load balancing and in stead provision >>>>>>> 160,000 service paths. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>> chain with 20 instances at each hop? >>>>>>>> >>>>>>>> Maria >>>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Lucy, >>>>>>>> >>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>> forwarding. I’d >>>> make >>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>> the needed forwarding and associated transport. >>>>>>>> >>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>> identify the service path (or graph) that packets must >>>>>>>> traverse. By having a path identifier, the exact >>>>>>>> indirection that people seem to be asking for on this >>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>> hop(s). >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>> >>>>>>>> Lucy >>>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>> *Sent:*Thursday, July >>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>> ;jmh@joelhalpern.com >>>>>>>> ;sfc@ietf.org >>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Re-, >>>>>>>> >>>>>>>> The merged draft calls out explicitly a service path >>>>>>>> identifier. I object to use that identifier to derive >>>>>>>> forwarding actions. >>>>>>>> >>>>>>>> Requiring a SFC system to have the full knowledge of every >>>> available SFC >>>>>>>> forwarding paths within an SFC-enabled domain is not >>>> required/justified >>>>>>>> nor possible in various deployment contexts. >>>>>>>> >>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>> information >>>> that will >>>>>>>> be present in all deployments: that is the one required to >>>>>>>> structure a service chain. How that information is used to >>>>>>>> infer forwarding >>>> actions >>>>>>>> is a solution-oriented discussion. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Med >>>>>>>> >>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>> de*mikebianc@aol.com >>>>>>>> *Envoyé :*mercredi 9 juillet >>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>> ;sfc@ietf.org >>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>> and SF >>>> Path? >>>>>>>> Other than clarifying the definition so that it's clear to >>>> those not >>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>> these terms. >>>>>>>> >>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>> of the SFC Header >>>> should >>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>> path and the choice of chain or >>>> path to >>>>>>>> be negotiated in the control-plane. >>>>>>>> >>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>> >>>>>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>>>> >>>>>>>> *From:*jmh@joelhalpern.com>>>>>>> > >>>>>>>> *To:*sfc@ietf.org>>>>>>> > *Sent:*Tuesday, July >>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>> Balancers >>>>>>>> >>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>> number of comments that have been made about the proposed >>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>> wording so that readers who have not participated in the WG >>>>>>>> discussion will understnd it the way the >>>> working >>>>>>>> group intends. >>>>>>>> >>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>> view, and see if that helps. >>>>>>>> >>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>> attempting to define the architecture for the entire >>>>>>>> solution for service chaining. That would encompass >>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>> machine and image management, and many other aspects. >>>>>>>> >>>>>>>> As a result there are many things which clearly need to >>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>> where we are >>>> functioning, >>>>>>>> and are not directly required by the work we are doing. >>>>>>>> >>>>>>>> In order to get to service chain vs service path, as I >>>>>>>> understand >>>> them, >>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>> three different ways that load balancing can and will >>>>>>>> interact with service chaining. There probably are more. >>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>> but not to mandate that any particular kind >>>> be used >>>>>>>> in any solution. >>>>>>>> >>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>> This is a service function. It receives user packets, and >>>>>>>> modifies them (or >>>> marks >>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>> to receive the users packet. This is an important service >>>>>>>> function to be able to include in service chaining. It's >>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>> From an architectural pe3rspective it is simply a >>>> service >>>>>>>> function which may modify the underlying packet. >>>>>>>> >>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>> what >>>> appears >>>>>>>> to the service chaining architecture as a single point of >>>>>>>> contact >>>> for a >>>>>>>> specific service function, but is actually delivered by a >>>> collection of >>>>>>>> virtual or physical machines, possibly including one or >>>>>>>> several load balancers (for example using VRRP-like >>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>> is largely that we need to be careful that our terminology >>>>>>>> does not lead >>>> readers to >>>>>>>> think we are prohibiting it. >>>>>>>> >>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>> to different places. We would not want to require that a >>>>>>>> given service function appear at only one place in the >>>>>>>> network. >>>>>>>> >>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>> to >>>> refer to >>>>>>>> the collection of entities that appear to service chaining >>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>> point of type 3 load balancing >>>> is to >>>>>>>> direct different subsets of traffic to different singular >>>>>>>> or clustered service functions in different places in the >>>>>>>> network. >>>>>>>> >>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>> while a different subset is to go directly to the cache >>>> without >>>>>>>> visiting any other service functions. >>>>>>>> >>>>>>>> That is not enough information to direct the packets. A >>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>> in the network. Those locations will be singular or >>>>>>>> clustered service function delivery locations. They may be >>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>> an SFF. There are many different ways that the locations >>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>> transport. >>>>>>>> >>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>> need to be >>>>>>>> able to talk about the high level abstraction, the service >>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>> about the actual data path packets will take in the >>>>>>>> network. >>>>>>>> >>>>>>>> Several of the comments have said "but the whole path may >>>>>>>> not be known at the front." This architecture deals with >>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>> the same way that bridging within a LAN is largely >>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>> make is >>>> that >>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>> That will direct packets to a new chain. Based on >>>>>>>> information available at the re-classification point. >>>>>>>> >>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>> we can figure out what additional words are needed to >>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>> then we will of course adjust to match the working group >>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>> try next. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing 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 Jul 11 00:49: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 A33C71B2AA9 for ; Fri, 11 Jul 2014 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=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 qQV_NuHGBgx1 for ; Fri, 11 Jul 2014 00:49:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8231B2AAC for ; Fri, 11 Jul 2014 00:49:52 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3B04A18C572; Fri, 11 Jul 2014 09:49:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 15BC8238056; Fri, 11 Jul 2014 09:49:50 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 09:49:49 +0200 From: To: "Joel M. Halpern" , Ian Smith , "Ron Parker" , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYoIgAgAC5UYCAABDHYIAAIKGAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOACAAHFOMA== Date: Fri, 11 Jul 2014 07:49:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> In-Reply-To: <53BF469E.9010108@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.11.70019 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4VJMOIhuxbSjI_YmhUCRM-dHW-w Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 07:49:56 -0000 Hi Joel, This is one possible approach, but what several of us are trying to clarify= is this is one approach among others, not possible in some contexts, more = complex to ensure resiliency, etc. Below some of my concerns about your ap= proach: (1) Having an entity that maintains a large set of service paths in a given= domain is more like creating circuits...I thought distributed routing has = shown its efficiency.=20 (2) Policies are everywhere in the network , not only at the SFC structurin= g system. (3) Path selection is dynamic by nature because it depends on various heuri= stics and policies that are distributed in the network (including those of = SFs and others). (4) Having a stateful function that maintains the full list of available pa= ths may not be that resilient. This must assess frequently (very short cycl= e) valid and serviceable paths among available ones. Ensuring the same lev= el of resilience would require additional features to be supported by to th= at entity maintaining the full set of path, and also SFs. (5) Load-balancing at a centralized entity is deployment-specific; as such = it is not required nor possible in those contexts. Deciding the forwarding = path a priori contradicts LB requirements. I know your answer about re-clas= sification, but IMHO the architecture should not mandate an optional featur= e only because of some design choices. Re-classification should be avoided = as much for the same of performance and also because this one of the comple= xity vector for this work.=20 (6) There are a bunch of solutions that achieve differentiated forwarding w= ithout requiring a pre-computation/pre-determination of a path: think about= ToS-based routing, multi-topology routing, etc.=20 I could live with an optional capability that a path can be pre-determined,= but this must not be the rule.=20 Forwarding within an SFC-enabled domain is primarily inferred by the servic= e function chain itself. How this information is used to drive forwarding a= ctions is all about details.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: vendredi 11 juillet 2014 04:06 >=C0=A0: Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >Part of my personal view is that I am trying to make this work sensibly >in a more orchestrated environment. I expect that the service >functions, and over time probably the SFF capabilities, will be >orchestrated and installed. I expect the service chains to be driven by >BSS tools that define offerings to clients, and enable self-selection >from these. I expect service paths to be heavily policy drive. > >I can see how to make all of that work in an archtiecture driven by >initial classification to described service paths. It is harder to see >how to make it work (but it can be done) when we allow more dynamicity >in the network behavior. > >Having said that, most of that perspective I described is outside of the >scope of the working group. it is not something we are tasked to agree >on. >So I do not claim that vision means we have to do it a certain way. it >is just the perspective that drives my preferences. > >Yours, >Joel > >On 7/10/14, 9:58 PM, Ian Smith wrote: >>> For me, the amount of information about service instances that needs to >>> be widely distributed and maintained, potentially even across data >>> centers within an administrative scope, is large enough and complex >>> enough that trying to get that into each SFF seems like a difficult >>> architecture to realize. >> >> I'm curious as to why that is more complicated than dynamic routing, >hyper-scale data center orchestration, or DNS, all of which are bigger >problems that have been profitably and stably implemented? >> >> It also seems that if it really is more complicated, that is a good sign >that it is too complicated. >> >> ________________________________________ >> From: Joel M. Halpern [jmh@joelhalpern.com] >> Sent: Thursday, July 10, 2014 9:45 PM >> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> This is an architectural issue. And one that I would prefer we actually >> decide, rather than trying to allow all possible implementations. >> Because it does have a major effect on the control requirements and the >> functionality of SFFs. >> >> For me, the amount of information about service instances that needs to >> be widely distributed and maintained, potentially even across data >> centers within an administrative scope, is large enough and complex >> enough that trying to get that into each SFF seems like a difficult >> architecture to realize. >> >> Yours, >> Joel >> >> But it is a fair question. >> >> On 7/10/14, 9:38 PM, Ron Parker wrote: >>> This is the crux of my issue. Is the end to end selection of >>> (top-level) instances performed centrally (perhaps by the classifier) >>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>> Such selection is not equivalent to reclassification. And surely, >>> this is an architectural issue and not relegated to >>> "implementation". >>> >>> My own view is to favor the distributed approach even though a >>> greater amount of data (chain definitions and perhaps local selection >>> policy) is required at those distributed decision points. This >>> approach does not require an end-to-end path id at all. My >>> rationale for favoring this approach is primarily driven by increased >>> resiliency over the global path id approach. With a global path id >>> approach, consider failure of an instance and needing to alter the >>> global path ID table for each and every affected end-to-end path. >>> >>> Ron >>> >>> ________________________________________ From: sfc >>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>> [sfc] Service Chains, Paths, and Load Balancers >>> >>> The way the architecture models the case of SF1 needing to influence >>> the chain is that one would do reclassification at the exit from >>> SF1. >>> >>> Part of the goal is to keep the different functions logically >>> separate so that solutions can clearly describe how they choose to >>> compose them for "service" delivery. >>> >>> Yours, Joel >>> >>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>> I don't see anything in the arch draft that suggests any sort of >>>> limit. However, it does seem to indicate that the entire path (all >>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>> either at the classifier or maybe the classifier chooses a SF Chain >>>> and the NF or at the latest the first SFF. In any case, the >>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>> determined at the SFI(n-1) hop. According to the draft, this >>>> behavior would be considered "branching" to a new SFP as opposed to >>>> choosing and then forwarding to the selected instance of the >>>> next-hop of the current SFC. >>>> >>>> draft-merged-sfc-architecture-00: >>>>> When an SFC is instantiated into the network it is necessary to >>>>> select the specific instances of SFs that will be used, and to >>>>> create the service topology for that SFC using SF's network >>>>> locator. Thus, instantiation of the SFC results in the creation >>>>> of a Service Function Path (SFP) and is used for forwarding >>>>> packets through the SFC. In other words, an SFP is the >>>>> instantiation of the defined SFC. >>>>> >>>>> The SFC architecture supports reclassification (or non-initial >>>>> classification) as well. As packets traverse an SFP, >>>>> reclassification may occur - typically performed by a >>>>> classification function co-resident with a service function. >>>>> Reclassification may result in the selection of a new SFP, an >>>>> update of the associated metadata, or both. This is referred to >>>>> as "branching". >>>> >>>> >>>> >>>> ----------------------------------------------------------------------= - >- >>>> >>>> >> *From: *I.Smith@F5.com >>>> *To: *Joel Halpern Direct,Joel M. >>>> >Halpern,huang@sce.carleton.ca,= s >fc@ietf.org >>>> >>>> >> *Sent: *Thursday, July 10, 2014 >>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Actually, I think I am disagreeing. >>>> >>>> If the possibility of medium-scale deployments (and that is what >>>> 16 million flows is in my world) of service chains is preconceived >>>> as an absurd idea, then the architecture burdened with that >>>> preconception. >>>> >>>> There has to be some point of aim, some degree of aspiration to >>>> scale that is appropriate for the lifespan of the architecture - >>>> you don't have to know what it is, but by saying that an arbitrary >>>> number is "too far", you're creating - even if it isn't intentional >>>> - a limit that influences decisions that have lasting impacts >>>> regarding scale-out, failure mitigation, elasticity, address >>>> space... all kinds of things. That is a problem I'm not >>>> particularly eager to deal with. >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> >>>> >>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>> Chains, Paths, and Load Balancers >>>> >>>> Ian, I don't think you disagree with me at all in this regard. I am >>>> not requesting the the architecture or the solution prohibit >>>> deployments in the specific fashion. I am objecting to Huang's >>>> reading of my note as saying that such deployments are required >>>> they by the archtiecture. >>>> >>>> As I have said repeatedly, I am not trying to prohibit such >>>> things. Whether they are a good idea or not depends upon many >>>> factors outside of the scope of the WG. I happen to think that they >>>> are usually a bad idea. >>>> >>>> But the archtiecture si carefully avoiding attempting to know what >>>> is and is not eployable. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>> I disagree. >>>>> >>>>> We routinely have stateful devices that manage tens of millions >>>>> of >>>> concurrent flows in both access network and data center >>>> environments today. You can't seriously believe that in the >>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>> to have small numbers of service chains with equally small numbers >>>> of active service paths? >>>>> >>>>> Your sounds too much like "no one will ever need more than 64K" >>>>> for >>>> comfort. >>>>> >>>>> >>>>> ________________________________________ From: sfc >>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>> [jmh@joelhalpern.com] >>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>> Balancers >>>>> >>>>> No, it will mean that if someone tries to deploy the archtieture >>>>> particularly badly, they will exceed the limits of their >>>>> devices. The architecture does not require such absurd use of >>>>> service paths. Since I can not figure out how to write >>>>> architectural words to prohibit it, the architecture does permit >>>>> such abuse. >>>>> >>>>> Please do not read my saying that the archtiecture permits >>>>> something as saying it is either deisred or required by the work. >>>>> It isn't. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>> If you need to support 100 service chains, it will mean >>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>> core router. >>>>>> >>>>>> Chang >>>>>> >>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>> The architecture allows a range of deployments, from 1 >>>>>>> service path to 160000 service paths. I would hope that >>>>>>> operators are prepared for the complexities if they choose to >>>>>>> avoid any use of local load balancing and in stead provision >>>>>>> 160,000 service paths. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>> chain with 20 instances at each hop? >>>>>>>> >>>>>>>> Maria >>>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Lucy, >>>>>>>> >>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>> forwarding. I'd >>>> make >>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>> the needed forwarding and associated transport. >>>>>>>> >>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>> identify the service path (or graph) that packets must >>>>>>>> traverse. By having a path identifier, the exact >>>>>>>> indirection that people seem to be asking for on this >>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>> hop(s). >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>> >>>>>>>> Lucy >>>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>> *Sent:*Thursday, July >>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>> ;jmh@joelhalpern.com >>>>>>>> ;sfc@ietf.org >>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Re-, >>>>>>>> >>>>>>>> The merged draft calls out explicitly a service path >>>>>>>> identifier. I object to use that identifier to derive >>>>>>>> forwarding actions. >>>>>>>> >>>>>>>> Requiring a SFC system to have the full knowledge of every >>>> available SFC >>>>>>>> forwarding paths within an SFC-enabled domain is not >>>> required/justified >>>>>>>> nor possible in various deployment contexts. >>>>>>>> >>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>> information >>>> that will >>>>>>>> be present in all deployments: that is the one required to >>>>>>>> structure a service chain. How that information is used to >>>>>>>> infer forwarding >>>> actions >>>>>>>> is a solution-oriented discussion. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Med >>>>>>>> >>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>> de*mikebianc@aol.com >>>>>>>> *Envoy=E9 :*mercredi 9 juillet >>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >>>>>>>> ;sfc@ietf.org >>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>> Paths, and Load Balancers >>>>>>>> >>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>> and SF >>>> Path? >>>>>>>> Other than clarifying the definition so that it's clear to >>>> those not >>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>> these terms. >>>>>>>> >>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>> of the SFC Header >>>> should >>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>> path and the choice of chain or >>>> path to >>>>>>>> be negotiated in the control-plane. >>>>>>>> >>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>> >>>>>>>> >>>> ----------------------------------------------------------------------= - >- >>>> >>>> >>>>>> >>>>>>>> *From:*jmh@joelhalpern.com>>>>>>> > >>>>>>>> *To:*sfc@ietf.org>>>>>>> > *Sent:*Tuesday, July >>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>> Balancers >>>>>>>> >>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>> number of comments that have been made about the proposed >>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>> wording so that readers who have not participated in the WG >>>>>>>> discussion will understnd it the way the >>>> working >>>>>>>> group intends. >>>>>>>> >>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>> view, and see if that helps. >>>>>>>> >>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>> attempting to define the architecture for the entire >>>>>>>> solution for service chaining. That would encompass >>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>> machine and image management, and many other aspects. >>>>>>>> >>>>>>>> As a result there are many things which clearly need to >>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>> where we are >>>> functioning, >>>>>>>> and are not directly required by the work we are doing. >>>>>>>> >>>>>>>> In order to get to service chain vs service path, as I >>>>>>>> understand >>>> them, >>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>> three different ways that load balancing can and will >>>>>>>> interact with service chaining. There probably are more. >>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>> but not to mandate that any particular kind >>>> be used >>>>>>>> in any solution. >>>>>>>> >>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>> This is a service function. It receives user packets, and >>>>>>>> modifies them (or >>>> marks >>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>> to receive the users packet. This is an important service >>>>>>>> function to be able to include in service chaining. It's >>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>> From an architectural pe3rspective it is simply a >>>> service >>>>>>>> function which may modify the underlying packet. >>>>>>>> >>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>> what >>>> appears >>>>>>>> to the service chaining architecture as a single point of >>>>>>>> contact >>>> for a >>>>>>>> specific service function, but is actually delivered by a >>>> collection of >>>>>>>> virtual or physical machines, possibly including one or >>>>>>>> several load balancers (for example using VRRP-like >>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>> is largely that we need to be careful that our terminology >>>>>>>> does not lead >>>> readers to >>>>>>>> think we are prohibiting it. >>>>>>>> >>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>> to different places. We would not want to require that a >>>>>>>> given service function appear at only one place in the >>>>>>>> network. >>>>>>>> >>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>> to >>>> refer to >>>>>>>> the collection of entities that appear to service chaining >>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>> point of type 3 load balancing >>>> is to >>>>>>>> direct different subsets of traffic to different singular >>>>>>>> or clustered service functions in different places in the >>>>>>>> network. >>>>>>>> >>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>> while a different subset is to go directly to the cache >>>> without >>>>>>>> visiting any other service functions. >>>>>>>> >>>>>>>> That is not enough information to direct the packets. A >>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>> in the network. Those locations will be singular or >>>>>>>> clustered service function delivery locations. They may be >>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>> an SFF. There are many different ways that the locations >>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>> transport. >>>>>>>> >>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>> need to be >>>>>>>> able to talk about the high level abstraction, the service >>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>> about the actual data path packets will take in the >>>>>>>> network. >>>>>>>> >>>>>>>> Several of the comments have said "but the whole path may >>>>>>>> not be known at the front." This architecture deals with >>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>> the same way that bridging within a LAN is largely >>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>> make is >>>> that >>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>> That will direct packets to a new chain. Based on >>>>>>>> information available at the re-classification point. >>>>>>>> >>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>> we can figure out what additional words are needed to >>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>> then we will of course adjust to match the working group >>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>> try next. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing 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 Jul 11 01:24: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 1093B1B2AAD for ; Fri, 11 Jul 2014 01:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tJjsnliaVSNq for ; Fri, 11 Jul 2014 01:24:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629CF1B2AC7 for ; Fri, 11 Jul 2014 01:23:21 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0541B2DC4FB for ; Fri, 11 Jul 2014 10:23:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DB27B35C068 for ; Fri, 11 Jul 2014 10:23:19 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 10:23:20 +0200 From: To: "sfc@ietf.org" Thread-Topic: Load-balancing requirements Thread-Index: Ac+c4V1XLtNTBYE2QyCkGp7aYyFGCw== Date: Fri, 11 Jul 2014 08:23:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300311E9@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300311E9OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.11.63919 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hGjFNQypm7_VP-t6Gm2K9OrVtoU Subject: [sfc] Load-balancing requirements X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 08:24:13 -0000 --_000_787AE7BB302AE849A7480A190F8B93300311E9OPEXCLILM23corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The requirements in (http://tools.ietf.org/html/draft-boucadair-sfc-require= ments-04) includes the following items: REQ#25: The solution MUST allow for load-balancing. A. Load-balancing may be provided by legacy technologies or protocols (e.g., make use of load-balancers) B. Load-balancing may be part of the Service Function itself. C. Load-balancer may be considered as a Service Function element. D. Because of the possible complications, load balancing SHOULD NOT be driven by the SFC Classifier. Given the ongoing discussion in the list, it will really useful to adjust t= his text accordingly. Comments to tweak this text, update it, etc, are more than welcome. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300311E9OPEXCLILM23corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The requirements in (http://tools.ietf.org/html/draft-bouc= adair-sfc-requirements-04) includes the following items:

 
   REQ#25:  The solution MUST allow for load-balancing.=

 
            A.&=
nbsp; Load-balancing may be provided by legacy technologies or

           &nbs=
p;    protocols (e.g., make use of load-balancers)


 


            B.&=
nbsp; Load-balancing may be part of the Service Function


           &nbs=
p;    itself.


 


            C.&=
nbsp; Load-balancer may be considered as a Service Function

           &nbs=
p;    element.


 


            D.&=
nbsp; Because of the possible complications, load balancing

           &nbs=
p;    SHOULD NOT be driven by the SFC Classifier.=



 


Given the ongoing discussion in the list, it will really u=
seful to adjust this text accordingly.



 


Comments to tweak this text, update it, etc, are more than=
 welcome.



 


Cheers,


Med
--_000_787AE7BB302AE849A7480A190F8B93300311E9OPEXCLILM23corpor_-- From nobody Fri Jul 11 02:07: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 136CE1B2AE0 for ; Fri, 11 Jul 2014 02:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 LD5I2LLgUlfT for ; Fri, 11 Jul 2014 02:07:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052321A0B17 for ; Fri, 11 Jul 2014 02:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37214; q=dns/txt; s=iport; t=1405069673; x=1406279273; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZcI6OXMlK6VD2F4EsiYZj5rdVlgagU8FLj1pjniZe/Y=; b=KMUto0GvAmwDX3KIz/NB1pd5wAlb0fDViCn0+pPNi1dRUEk4kqWHThip X/4T/Z1VWbycUXpSxKSKgLtv5YgX2KUCTcFnb6qG4mecLkj3hOU3wohQj PeWafIK/jBG+5E1Mc+W97C7tPg1/lEheyUOjSKrT6K38ew1mupGxqqnVu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAFCov1OtJA2B/2dsb2JhbABPCoMOUlqtFZNTCodCAYELFnWEAwEBAQMBAQEBFw0TLQcLBQsCAQgYHgkHJwsUEQIEDgUbiB8IDcZREwSJfIRuBCUuBQeDLYEWBZZrhBqUG4NEgW5C X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="339248714" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2014 09:07:51 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6B97VUi003025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 09:07:31 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 04:07:30 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Metadata representation and transport Thread-Index: Ac+cag85+Q81qSP7RZyUzN5UZVrEHwAK8pGAAAESoQAAAFAFgAABkSOAAAE/CQAAAM6IAAAAI+mAABnBBQA= Date: Fri, 11 Jul 2014 09:07:30 +0000 Message-ID: <3377D3C8-31C8-4E96-AC60-2E0A001B8AAE@cisco.com> References: <76B41B8FACE1514795D30EC137FF391D453311@CAROUBIER.jungle.qosmos.com> <53BED9F3.7070503@joelhalpern.com> <53BEE126.7090906@sce.carleton.ca> <53BEEDC3.6000305@sce.carleton.ca> <5F9AFA04-5604-4E33-B0B1-09F8A24FA8B5@gmail.com> <53BEFB8A.7040800@sce.carleton.ca> <53BEFC7B.2020106@joelhalpern.com> In-Reply-To: <53BEFC7B.2020106@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E2B62BF0ABF3B48ABA8EE67B1C6DA22@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/F8rQX4MK1AyiyuxYu3V4_LIYm3U Cc: Sam Aldrin , "sfc@ietf.org" , "huang@sce.carleton.ca" Subject: Re: [sfc] Metadata representation and transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 09:07:37 -0000 On Jul 10, 2014, at 4:50 PM, Joel M. Halpern wrote: > If the packet does not carry enough information to identify the subscribe= r, as has been described in several use casess, there appears to be no choi= ce other than to attach some subscriber identifying aidditional information= tothe packet. Sending it separately from the packet simply won't work. > That is clearly metadata, and it seems clear to me that it needs to be at= tached to the packet. >=20 > That does not mean that there are not other cases where out-of-band deliv= ery of various sorts may also be useful. I am not against using that as we= ll. >=20 Right, carrying metadata per packet and having out of band information are = not mutually exclusive. > Yours, > Joel >=20 > On 7/10/14, 4:46 PM, Changcheng Huang wrote: >> The most common small packets are TCP Ack packets which are around 64 >> bytes long including headers from various layers (MAC, IP, TCP) and some >> padded payloads to make it satisfy minimum packet size requirement. >> Adding metadata to this kind of packets does not make sense to me. >>=20 >> Chang >>=20 >> On 07/10/2014 01:22 PM, Sam Aldrin wrote: >>> I agree . As SFC is established in a controlled domain, mitigating >>> options are better than general internet. Again need to see how much >>> of an overhead it really causes and it's side effects. >>>=20 >>> Sam >>>=20 >>> Sent from my iPad >>>=20 >>> On Jul 10, 2014, at 12:47 PM, Changcheng Huang >> > wrote: >>>=20 >>>> Even the SFC is limited to a specific domain (such as a datacenter), >>>> the packet sizes still follow the same distribution. The bandwidth >>>> within a datacenter is still a bottleneck part due to traffic >>>> patterns such as incast. >>>>=20 >>>> Chang >>>>=20 >>>> On 07/10/2014 12:02 PM, Sam Aldrin wrote: >>>>>=20 >>>>>=20 >>>>> On Thu, Jul 10, 2014 at 11:53 AM, Changcheng Huang >>>>> > wrote: >>>>>=20 >>>>> I am concerned with the overhead metadata may create. Internet >>>>> packet sizes tend to be bimodal where more than 50% of packets >>>>> have very small packet sizes. Carrying large amounts of overhead >>>>> will reduce throughput significantly. Making metadata optional >>>>> may be a good choice. >>>>>=20 >>>>> Doesn't that depend only if the SFC spans across the internet? >>>>> Otherwise it (overhead) should be limited to SFC's domain, which may >>>>> not span across internet, no? >>>>>=20 >>>>> cheers >>>>> -sam >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Chang >>>>>=20 >>>>>=20 >>>>> On 07/10/2014 11:22 AM, Joel M. Halpern wrote: >>>>>=20 >>>>> I look forward to seeing your draft. >>>>>=20 >>>>> One of the reasons I like including the metadata with the >>>>> underlying packet is that they then share fate. If the >>>>> packet gets lost, the metadata disappears with it, which is >>>>> frequently fine. And if the packet is probably delviered >>>>> down the service path, then so is the metadata. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 7/10/14, 2:15 PM, Nicolas BOUTHORS wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> Metadata transport is a feature provided by SFC that >>>>> needs some >>>>> additional thoughts as well. >>>>>=20 >>>>> B Rijsman has done a great job showing various option >>>>> for Metadata >>>>> sharing. Still there are 2 aspects that I would like to >>>>> address further >>>>>=20 >>>>> - Metadata representation >>>>>=20 >>>>> - Metadata transport reliability >>>>>=20 >>>>> We will probably post a draft on the subject, but this >>>>> can be done after >>>>> Toronto has started. So for those >>>>> interested to provide some feedback, here are some >>>>> highlights. >>>>>=20 >>>>> *1. Problem Space* >>>>> * Metadata representation* >>>>> Metadata can be extremely varied in term of usage and >>>>> content. It can >>>>> represent the result of Deep Packet Inspection (DPI) >>>>> performed on the >>>>> traffic for example by the Classifier Service Function >>>>> at the ingress of >>>>> the Service Function Chain. It can contain information >>>>> collected about >>>>> the end user such as a policy identifier, a category or >>>>> even represent >>>>> an event related to the end-user session. >>>>> This information can be used by Service Functions on the >>>>> chain, as well >>>>> as by monitoring entities responsible to track usage for >>>>> example in the >>>>> Network Function Virtualization environment to feed a >>>>> VNF manager or an >>>>> Orchestrator. >>>>> Metadata being information shared by many network >>>>> entities needs some >>>>> means to be represented it in all of its dimensions: >>>>> type definition, >>>>> encoding and scope. >>>>> * Metadata transport service* >>>>> As expected from service chain proposals, both NSH and >>>>> SCH proposals >>>>> define some means to carry metadata between Service >>>>> Functions in a >>>>> Chain. They can be classified as follow: >>>>> Dataplane Metadata: >>>>> are defined in the Service Function Chaining Problem >>>>> Statement document. >>>>> They are not considered to be part of the forwarding >>>>> information of the >>>>> SFC header. However they are expected to carry the >>>>> result of antecedent >>>>> classification, allowing Service Functions to take local >>>>> policy >>>>> decisions based on their values. >>>>>=20 >>>>> As such, they could also be interpreted directly by >>>>> Service Function >>>>> Forwarder to steer traffic to various Service Functions. >>>>> Offline Metadata: >>>>> Beyond Dataplane Metadata, Offline Metadata can be >>>>> shared between >>>>> Service Functions in a chain, using out of band, >>>>> congruent or not, or >>>>> hybrid models described in [RIJSMAN] >>>>>=20 >>>>> The hybrid model for example, defined in [RIJSMAN], >>>>> utilizes the SFC >>>>> header to transport some key values for correlation >>>>> purposes. These >>>>> Correlation Ids can be used by the Service Functions to >>>>> recover the full >>>>> associated contextual information. >>>>> Metadata, directly or indirectly, are transported hop by >>>>> hop along a >>>>> chain, in association to end-user traffic, the data >>>>> payload of the SFC >>>>> packets. >>>>> How these metadata are transported over a chain matters. >>>>> Passing >>>>> metadata directly or indirectly along packets is a >>>>> service that must be >>>>> analyzed from a reliability point of view. >>>>>=20 >>>>> Reliability requirements may vary depending on the >>>>> nature of the >>>>> metadata transported. Past experience for example in >>>>> Mobile Network and >>>>> data center with AAA Radius have shown that contextual >>>>> information >>>>> replication to various service function was indeed >>>>> sensitive to packet >>>>> loss events, and that adhoc solutions had to be >>>>> implemented to detect them. >>>>> End to end TCP retransmission of packet lost does not >>>>> ensure that >>>>> associated Metadata will be reinserted in retransmitted >>>>> packet. In >>>>> addition, Event triggered metadata may have to be sent >>>>> immediately on a >>>>> chain even though no end-user traffic is being transmitted >>>>> Not all metadata needs a reliable transport. Repeated >>>>> inline metadata >>>>> can be used to cover several use cases, and some >>>>> metadata loss can be >>>>> acceptable. >>>>> Still, a reliable transport service for Metadata in SFC >>>>> is expected. To >>>>> this effect, an implementation is suggested in Section 3.3 >>>>> *2. Metadata representation* >>>>> Metadata definition is that it provides contextual >>>>> information about the >>>>> data packets which traverse a Service Function Chain. >>>>> This must be >>>>> understood broadly. >>>>> Metadata can contain the result of traffic >>>>> classification by Deep Packet >>>>> Inspection (DPI). For example as an Application Id >>>>> information which is >>>>> tied to a traffic flow. There could be multiple flows >>>>> with different >>>>> application ids, in a chain. >>>>> Metadata can also contain the result of DPI data >>>>> extraction, such as >>>>> identify requested URL in HTTP. Such information can be >>>>> passed to >>>>> certain SF down the chain such as a URL filtering function= . >>>>> Metadata can contain some punctual event information >>>>> collected at the >>>>> Ingress point of the chain and expected to be passed to >>>>> all elements in >>>>> the chain. Here this information may be triggered >>>>> externally and >>>>> generated only once, and be related to the tenant or the >>>>> subscriber. >>>>> Metadata representation involves the definition of a set >>>>> of information >>>>> elements types and the encoding rules for their values. >>>>> Metadata representation can sometimes be performed by a >>>>> single >>>>> individual field with associated type and format. >>>>> However, it is not >>>>> always enough. >>>>>=20 >>>>> * Metadata may need multiple fields transported >>>>> together to >>>>> represented their values. >>>>> * Some addition fields may be required to describe the >>>>> scope of the >>>>> metadata itself. This can be any information element >>>>> allowing to >>>>> define the context of the associated metadata value. >>>>> For example a >>>>> throughput metadata field can have a port number and >>>>> a switch >>>>> address as its Scope information. >>>>>=20 >>>>> We explore these two axis: encoding and scope. >>>>> We propose IPFIX as a preferred means to represent >>>>> Metadata in Service >>>>> Chain messages for Out-of-band, Congruent or not; >>>>> Metadata sharing. >>>>> *2.1. Metadata Representation Requirements* >>>>> Mandatatory Dataplane Metadata is always part of the SFC >>>>> header, it is >>>>> thus reasonable to consider that its representation >>>>> scheme will be >>>>> implicit: based on what the SFC protocol will dictate, >>>>> their position in >>>>> the SFC header is sufficient for the receiving end to >>>>> infer their type >>>>> and encoding scheme. For example, Context Header Fields >>>>> in NSH are 32 >>>>> bit fields. >>>>> However, it will not be the case for all metadata >>>>> transported. Offline >>>>> metadata, including congruent out-of-band metadata still >>>>> need to be >>>>> represented explicitly. This section addresses their >>>>> specific case. >>>>> *2.1.1. Metadata Encoding requirements* >>>>> These requirements are applicable to out-of-band >>>>> metadata (Congruent or >>>>> not). It could be applicable with SCH on optional >>>>> in-line metadata fields. >>>>> For interoperability purposes, metadata encoding MUST >>>>> allow the >>>>> receiving entity to identify the type and value of the >>>>> information >>>>> received as metadata >>>>> Metadata encoding MUST allow for encoding techniques >>>>> supporting well >>>>> known types and fields as well as proprietary extensions. >>>>> A receiving entity MUST be able to identify when >>>>> incoming metadata type >>>>> is unknown and MUST have a defined default action to >>>>> handle it. >>>>> A piece of information may need multiple fields to be >>>>> described. For >>>>> example a tenant id and an ip address can be used to >>>>> identify an server >>>>> in a data center uniquely. >>>>> These groups of information have to be exchanged >>>>> collectively, in a >>>>> single message. In this case, a sending entity MUST >>>>> specify that it is >>>>> sending a set of metadata in a message. >>>>> This set of transported metadata elements MUST be >>>>> specified under the >>>>> form of a metadata template document uniquely defined >>>>> for the chain. >>>>> A receiving entity MUST be able to detect if an incoming >>>>> message >>>>> contains its expected set of metadata elements. >>>>> *2.1.2. Metadata Scope requirement* >>>>> A piece of information may have to be qualified by some >>>>> attributes >>>>> allowing to identify its particular scope. For example >>>>> in a Gi >>>>> environment, the radio type in use may be used as a >>>>> scoping criteria for >>>>> a jitter or latency measurement in a video traffic >>>>> transported in a >>>>> particular service chaing. >>>>> Scope can apply to some individual metadata elements or >>>>> to a set of >>>>> metadata elements. How a scope applies to a set of >>>>> transported metadata >>>>> elements should be defined by a specification under the >>>>> form of a >>>>> metadata template document uniquely identified for the >>>>> chain. >>>>> *2.2. IPFIX Metadata representation* >>>>> So far, unordered sequences of Type Length Value encoded >>>>> fields have >>>>> been proposed to transport metadata. It is not clear how >>>>> structured >>>>> types are supported, and no distinction is done between >>>>> the metadata >>>>> values and their scoping values. Although the SCH >>>>> proposal provides an >>>>> optional 24-bit Organizational Unique Identifier, there >>>>> is no namespace >>>>> mechanism allowing to separate type definition spaces >>>>> per Tenants or per >>>>> chain. >>>>> We suggest to leverage the work done by IETF on similar >>>>> subject. >>>>> A natural candidate to leverage is IPFIX [RFC7011]: >>>>> IPFIX is a means for >>>>> transmitting Traffic Flow information over the network. >>>>> In order to >>>>> transmit Traffic Flow information, it provides a common >>>>> representation >>>>> of flow data and a standard means of communicating them. >>>>> Metadata collected by Network Node and Service Node >>>>> SHOULD be encoded in >>>>> template following the principles described in >>>>> IPFIX[RFC7011]. >>>>> An IPFIX Message consisting of interleaved Template, >>>>> Data, and Options >>>>> Template Sets, as shown in Figure 1. Here, Template and >>>>> Options Template >>>>> Sets , which are optional, are shown. >>>>>=20 >>>>>=20 >>>>> +--------+------------------------------------------------= --------+ >>>>> | | +----------+ +---------+ +-----------+ >>>>> +---------+ | >>>>> |Message | | Template | | Data | | Options | | >>>>> Data | | >>>>> | Header | | Set | | Set | ... | Template >>>>> | | Set | | >>>>> | | | | | | | Set | | >>>>> | | >>>>> | | +----------+ +---------+ +-----------+ >>>>> +---------+ | >>>>> +--------+------------------------------------------------= --------+ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 1: IPFIX Message Format >>>>> The Template Set describes the data transmitted in the >>>>> following Data >>>>> Set. It is an optional component of the message. The >>>>> value of the >>>>> metadata is encoded in the first Data Set. This Data Set >>>>> contains a >>>>> template Id field as a reference to its defining >>>>> Template Set. >>>>> The Options Template Set describes the data to be >>>>> transmitted as scope >>>>> information. It is an optional component of the message. >>>>> The value of >>>>> the scope information is encoded in the second Data Set >>>>> element. It no >>>>> scope information is present, then only the first Data >>>>> Set is present in >>>>> the message. >>>>> The Option Template Set and following Data Set are used >>>>> to describe the >>>>> scope of the metadata transmitted. For example, the >>>>> metadata collected >>>>> is relevant to a PDP Context or a particular line card >>>>> of a particular >>>>> switch. >>>>> * >>>>> * >>>>> *2.2.4.3. Example:* >>>>> The Metadata Exporting Process creates a Template Record >>>>> with a few >>>>> Information Elements: amongst other things, the >>>>> Application Id. For example: >>>>>=20 >>>>> - sourceIPv4Address (key field) >>>>> - destinationIPv4Address (key field) >>>>> - protocol (key field) >>>>> - destinationTransportPort (key field) >>>>> - applicationId (key field) >>>>> - octetTotalCount (non key field) >>>>>=20 >>>>> For example, a Flow Record corresponding to the >>>>> above >>>>> Template Record may contain: >>>>>=20 >>>>> { sourceIPv4Address=3D192.0.2.1, >>>>> destinationIPv4Address=3D192.0.2.2, >>>>> protocol=3D17, >>>>> destinationTransportPort=3D23, >>>>> applicationId=3D'3..80', >>>>> octetTotalCount=3D123456 } >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The Options Data Record associated with the examples >>>>> above would contain >>>>> the Scoping inforamtion: >>>>>=20 >>>>> Scope: >>>>> - servicePath, >>>>> - serviceIndex, >>>>> - applicationId, >>>>> - applicationName >>>>> - applicationDescription. >>>>>=20 >>>>> For example: >>>>>=20 >>>>> { >>>>> servicePath=3D0x000b, >>>>> serviceIndex=3D0x000c, >>>>> applicationId=3D'13...10000', >>>>> applicationName=3D"webex", >>>>> applicationDescription=3D"Webex application= " } >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Scope information is useful when sending metadata >>>>> offline, as it can >>>>> contain information related to the chain and possibly to >>>>> the flow for >>>>> which this metadata record is relevant. Here servicePath a= nd >>>>> serviceIndex are thus included in the Template. >>>>> *2.2.4.4. IPFIX encoding and template provisioning:* >>>>> IPFIX is a quite compact encoding >>>>> For a template defined as followed and shared by the SF >>>>> in a chain. >>>>> IPFIX template record shared by SF: >>>>> Note that an XML representation of IPFIX template record >>>>> could be >>>>> defined and used to provision Service Functions. >>>>>=20 >>>>> 0 1 2 >>>>> 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>>> 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Set ID =3D 2 | Length =3D 28 >>>>> octets | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Template ID 256 | Field Count =3D 5 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> |0| sourceIPv4Address =3D 8 | Field Length =3D 4 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> |0| destinationIPv4Address =3D 12 | Field Length =3D 4 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> |0| ipNextHopIPv4Address =3D 15 | Field Length =3D 4 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> |0| packetDeltaCount =3D 2 | Field Length =3D 4 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> |0| octetDeltaCount =3D 1 | Field Length =3D 4 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>>=20 >>>>>=20 >>>>> Figure 7: IPFIX Metadata template Encoding >>>>> An encoded IP fix transport message will be: >>>>>=20 >>>>>=20 >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >>>>> 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Version Number | Length | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Export Time >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Sequence Number >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Observation Domain ID >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | Set ID =3D 256 | Length =3D 64 >>>>> | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | 192.0.2.12 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | 192.0.2.254 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | 192.0.2.1 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | 5009 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>> | 5344385 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 8: IPFIX Metadata Encoding >>>>> *3. Metadata transport service* >>>>> These different use cases for Metadata generate some >>>>> requirements on the >>>>> reliability capabilities of the Metadata transport >>>>> service they will >>>>> rely on. >>>>> De facto Service Function Chain proposals such as NSH >>>>> and SCH define a >>>>> mechanism for sharing information along the Chains. It >>>>> is thus important >>>>> to define this transport service in term of reliability. >>>>> The primary focus of these proposal are the Metadata >>>>> elements playing a >>>>> role in the Service Function Chain deployment to apply >>>>> policies on >>>>> incoming traffic at some relevant Service Functions. >>>>> For example, Network Orchestration is expected to be a >>>>> significant >>>>> driver for deployment of Network Services. It relies on >>>>> Service Level >>>>> abstractions such as Group Policies, Contracts and >>>>> Services as an input >>>>> for the orchestration of Service Function Chains. >>>>> Specific metadata >>>>> attributes such as L4-L7 fields are used as >>>>> classification elements or >>>>> filters to funnel packets into chains. >>>>> Service Functions may have other needs for Metadata, for >>>>> example Event >>>>> Based Metadata tied to some subscriber related state >>>>> changes. The >>>>> complexity and length of these elements cannot be >>>>> forseen as limited, >>>>> neither can be how critical it is that they are safely >>>>> carried >>>>> throughout a chain. In the following Section we propose >>>>> to take >>>>> avantage of Congruent Metadata Transport can be used, >>>>> possibly reliably, >>>>> to address these needs. >>>>> *3.1. Proposed Metadata transport mechanisms* >>>>> . >>>>> *3.1.3. Metadata transport analysis* >>>>> Both NSH and SCH proposals support both inbound and >>>>> offline out-of-band >>>>> metadata transport. >>>>>=20 >>>>> 1. In-band: the metadata can be included directly as a >>>>> value in some of >>>>> the NSH Context Header Fields. It is the preferred >>>>> transport model >>>>> for SCH. >>>>>=20 >>>>> In such case, when a particular field is always set >>>>> to the same >>>>> value for all packets transported by the chain >>>>> instance, then the >>>>> metadata transport service is in effect reliable. >>>>>=20 >>>>> Similarly, all the packet for a particular flow >>>>> (defined by its 5 >>>>> tupple), could receive the same metadata value. The >>>>> metadata >>>>> transport service is also reliable, provided that >>>>> the value is >>>>> understood to be attached to a flow. >>>>>=20 >>>>> The general case however, occurs when the metadata >>>>> varies from >>>>> packet to packet in a flow. The value is then tied >>>>> to a specific >>>>> packet. Here the transport service is not reliable. >>>>> A retransmission >>>>> of a particular packet would not necessarily lead it >>>>> to carry the >>>>> same metadata value. >>>>> 2. Out-of-band: a reference for some metadata is sent >>>>> along a packet so >>>>> that it can be used via an interaction with a >>>>> controller entity. It >>>>> is the preferred model for NSH, but could also be >>>>> used by SCH. >>>>>=20 >>>>> As for the in-band case, the metadata referred to >>>>> indirectly can be >>>>> transmitted reliably, when its value remains the >>>>> same for a chain or >>>>> a flow in a chain. a chain or a flow in a chain. >>>>>=20 >>>>> If however, the correlation Id passed changes over >>>>> time, or if the >>>>> Metadata itself cahanges then the correct Metadata >>>>> may not be >>>>> efficiently retrieved by some Service Functions. >>>>>=20 >>>>> We can see that NSH and SCH do not address the need for >>>>> a reliable >>>>> transport service for metadata, independantly of the >>>>> reliability >>>>> characteristic of the transport service used for the >>>>> data packets. >>>>> Conventions can be used as particular cases when some >>>>> metadata pertains >>>>> to a specific chain or a flow in the chain, and when its >>>>> value does not >>>>> change overtime. >>>>> Such conventions however are weak. They would suppose >>>>> that some >>>>> mechanism exists to ensure/monitor that they are >>>>> followed. And some >>>>> exceptions mechanism would be required to deal with >>>>> error cases. >>>>> *3.2. Support for Congruent out-of-band transport service* >>>>> Congruent out-of-band metadata sharing can be required >>>>> for some types of >>>>> Metadata exchanges. It has the advantage of clearly >>>>> tying the metadata >>>>> to the chain and not to a specific packet, and to avoid >>>>> payload >>>>> fragmentation issues. >>>>> Up to draft 2, NSH did not allow for long inline >>>>> metadata transport. >>>>> Four 32 bits context fields are reserved for that >>>>> purpose, and seem best >>>>> suited for offline Metadata sharing, or to transport >>>>> predefined policy >>>>> identifiers. >>>>> NSH (since draf 3) as well as SCH could allow for >>>>> metadata transport, >>>>> either tied to a packet or possibly tied to the chain, >>>>> when used without >>>>> payload, as signaling messages. >>>>> SCH however stipulates that in case the Path Identifier >>>>> and SF Index >>>>> fields shall be set to zero for transmit and ignored >>>>> upon receipt, when >>>>> the SCH packet will contain only metadata. So congruent >>>>> out-of-band >>>>> metadata, transporting Metadata hop to hop to the >>>>> various Service >>>>> Function in the chain, does not seem to be supported. >>>>> NSH supports inline variable size metadata. It does not >>>>> mentions >>>>> explicitly that congruent out-of-band metadata can be used= . >>>>> *3.3. Reliable transport service* >>>>> Some metadata will need a reliable transport service to >>>>> be shared >>>>> inline, as well as offline. >>>>> A protocol SCTP provides such a service and has the >>>>> interesting >>>>> characteristic to be packet based, as opposed to stream >>>>> based like TCP. >>>>> SCTP carries a sequence number and support >>>>> retransmission and congestion >>>>> control. >>>>> Figure 12 shows how SCTP is used hop by hop between SFF >>>>> in a chain to >>>>> transport Metadata reliably. >>>>>=20 >>>>> |1 ----- |n |21 ---- |2m >>>>> +---+---+ +---+---+ +-+---+ >>>>> +--+-----+ >>>>> | SF#1 | |SF#n | |SF#i1| >>>>> |SF#im | >>>>> | | | | | | | >>>>> | >>>>> +---+---+ +---+---+ +--+--+ >>>>> +--+--+--+ >>>>> : : : : : >>>>> : : : : : >>>>> \ / \ / >>>>> +-----------+ SCTP +--------+ SCTP +--------= -+ >>>>> -- >| Chain | <---> | SFF | <---> | SFF >>>>> | ----> >>>>> |classifier | |Node-1 | | Node-i | >>>>> +-----------+ +----+---+ +----+--+-+ >>>>> \ | / >>>>> \ | SFC Encapsulation / >>>>> \ | / >>>>> ,........................................ >>>>> / \ >>>>> / \ >>>>> | Network | >>>>> \ / >>>>> \........................................./ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Figure 12: SCTP for Reliable Metadata transport >>>>> SCTP SHOULD be used in the context of Congruent out of >>>>> band for reliable >>>>> metadata sharing. >>>>> For reliable Metadata transport, the SFF along the chain >>>>> MUST route the >>>>> metadata received over SCTP to the next SF in the chain. >>>>> For this SCTP >>>>> MUST be encapsulated in the SFC header. >>>>> The SFF MUST make the received metadata available >>>>> to its SF.ti >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=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 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 02:23: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 259F81B27CC; Fri, 11 Jul 2014 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 gKE9Lymb3h_d; Fri, 11 Jul 2014 02:23:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5F96B1A0453; Fri, 11 Jul 2014 02:23:26 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6B6831263A66; Fri, 11 Jul 2014 17:23:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s6B9N2ml076218; Fri, 11 Jul 2014 17:23:02 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300311E9@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Fri, 11 Jul 2014 17:23:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-11 17:22:53, Serialize complete at 2014-07-11 17:22:53 Content-Type: multipart/alternative; boundary="=_alternative 00339F3F48257D12_=" X-MAIL: mse01.zte.com.cn s6B9N2ml076218 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GIrYJxj6ZdC6C9Mz3ov6LC2T-CI Cc: sfc , "sfc@ietf.org" Subject: Re: [sfc] Load-balancing requirements X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 09:23:30 -0000 This is a multipart message in MIME format. --=_alternative 00339F3F48257D12_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWVkLA0KDQogICAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNClRoYW5rcywNCldlaQ0KDQoic2Zj IiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+ICAyMDE0LzA3LzExIDE2OjIzOjE5Og0KDQo+IEhpIGFs bCwNCj4gDQo+IFRoZSByZXF1aXJlbWVudHMgaW4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJvdWNhZGFpci1zZmMtDQo+IHJlcXVpcmVtZW50cy0wNCkgaW5jbHVkZXMgdGhlIGZv bGxvd2luZyBpdGVtczoNCj4gDQo+ICAgIFJFUSMyNTogIFRoZSBzb2x1dGlvbiBNVVNUIGFsbG93 IGZvciBsb2FkLWJhbGFuY2luZy4NCj4gDQo+ICAgICAgICAgICAgIEEuICBMb2FkLWJhbGFuY2lu ZyBtYXkgYmUgcHJvdmlkZWQgYnkgbGVnYWN5IHRlY2hub2xvZ2llcyBvcg0KPiAgICAgICAgICAg ICAgICAgcHJvdG9jb2xzIChlLmcuLCBtYWtlIHVzZSBvZiBsb2FkLWJhbGFuY2VycykNCj4gDQo+ ICAgICAgICAgICAgIEIuICBMb2FkLWJhbGFuY2luZyBtYXkgYmUgcGFydCBvZiB0aGUgU2Vydmlj ZSBGdW5jdGlvbg0KPiAgICAgICAgICAgICAgICAgaXRzZWxmLg0KPiANCj4gICAgICAgICAgICAg Qy4gIExvYWQtYmFsYW5jZXIgbWF5IGJlIGNvbnNpZGVyZWQgYXMgYSBTZXJ2aWNlIEZ1bmN0aW9u DQo+ICAgICAgICAgICAgICAgICBlbGVtZW50Lg0KPiANCj4gICAgICAgICAgICAgRC4gIEJlY2F1 c2Ugb2YgdGhlIHBvc3NpYmxlIGNvbXBsaWNhdGlvbnMsIGxvYWQgYmFsYW5jaW5nDQo+ICAgICAg ICAgICAgICAgICBTSE9VTEQgTk9UIGJlIGRyaXZlbiBieSB0aGUgU0ZDIENsYXNzaWZpZXIuDQoN CltXZWldIDogSm9lbCBtZW50aW9uZWQgYXMgZm9sbG93IHRoYXQgdGhlcmUgYXJlIDMgZGlmZmVy ZXQgd2F5cyB0aGF0IGxvYWQgDQpiYWxhbmNpbmcgY2FuIGFuZCANCndpbGwgaW50ZXJhY3Qgd2l0 aCBzZXJ2aWNlIGNoYWluaW5nLg0KIjEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92 aWRlZCB0byB0aGUgZW5kIHVzZXIuoa2hrQ0KMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxh bmNpbmcuoa2hrSANCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkg c2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3IgdGhlIA0Kc2VydmljZSBjaGFpbmluZyB0aGF0DQpk aXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byBy ZXF1aXJlIHRoYXQgYSANCmdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIA0KYXQgb25seSBv bmUgcGxhY2UgaW4gdGhlIG5ldHdvcmsuICINCg0KU28gSSBkb24ndCB0aGluayB0aGVzZSByZXF1 aXJlbWVudHMgaXMgc3VmZmljaWVudCBmb3IgYWxsIGtpbmQgb2YgTEJzLiBPciANCndlIHNob3Vs ZCByZWRlZmluZSANCndoYXQgTG9hZCBiYWxhbmNpbmcgaXMuIEJlY2F1c2UgSU1PLCBpdGVtIDEg aXMgYW4gZXh0ZXJuYWwgTEIgc2VydmljZSANCmZ1bmN0aW9uIGZvciBjaG9vc2luZyANCmVuZCB1 c2VyczsgSXRlbSAyIGlzIGFuIGludGVybmFsIG1lY2hhbmlzbSB0byBiYWxhbmNlIHBhY2tldHMg YW1vbmcgU0ZzIA0Kd2hpY2ggYWNoaWV2ZSB0aGUNCnNhbWUgZnVuY3Rpb247IGl0ZW0gMyBsb29r cyBsaWtlIGFjaGlldmluZyBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkgbGlrZSBURS4gDQpJIGNhbm5v dCBzZWUgdGhlc2UgcmVxdWlyZW1lbnRzIGNvbnRhaW4gaXRlbSAxJjMgaWYgSSBjYXB0dXJlIHlv dXIgDQptZWFuaW5nLg0KIA0KQlRXLCBmb3IgaXRlbSAyLCB3ZSBjYW4gY2FsbCBpdCBwYWNrZXQg ZGlzdHJpYnV0aW9uIGluc3RlYWQgb2YgbG9hZCANCmJhbGFuY2luZy4NCldoeSB0aGlzIGtpbmQg b2YgbG9hZCBiYWxhbmNpbmcgQ0FOTk9UIGJlIGRyaXZlbiBieSB0aGUgU0ZDIENsYXNzaWZpZXI/ DQoNCg0KDQo+IA0KPiBHaXZlbiB0aGUgb25nb2luZyBkaXNjdXNzaW9uIGluIHRoZSBsaXN0LCBp dCB3aWxsIHJlYWxseSB1c2VmdWwgdG8gDQo+IGFkanVzdCB0aGlzIHRleHQgYWNjb3JkaW5nbHku IA0KPiANCj4gQ29tbWVudHMgdG8gdHdlYWsgdGhpcyB0ZXh0LCB1cGRhdGUgaXQsIGV0YywgYXJl IG1vcmUgdGhhbiB3ZWxjb21lLiANCj4gDQo+IENoZWVycywNCj4gTWVkX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBz ZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0K --=_alternative 00339F3F48257D12_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1lZCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgUGxlYXNl IHNlZSBpbmxpbmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5X ZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mcXVvdDtzZmMmcXVvdDsgJmx0 O3NmYy1ib3VuY2VzQGlldGYub3JnJmd0OyAmbmJzcDsyMDE0LzA3LzExDQoxNjoyMzoxOTo8YnI+ DQo8YnI+DQomZ3Q7IEhpIGFsbCw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZn dDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRoZSByZXF1 aXJlbWVudHMgaW4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1z ZmMtPGJyPg0KJmd0OyByZXF1aXJlbWVudHMtMDQpIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgaXRl bXM6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7UkVRIzI1OiAmbmJz cDtUaGUgc29sdXRpb24gTVVTVA0KYWxsb3cgZm9yIGxvYWQtYmFsYW5jaW5nLjwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQS4NCiZuYnNwO0xvYWQtYmFsYW5jaW5nIG1heSBiZSBwcm92aWRlZCBieSBsZWdhY3kgdGVj aG5vbG9naWVzIG9yPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IHByb3Rv Y29scyAoZS5nLiwgbWFrZSB1c2Ugb2YgbG9hZC1iYWxhbmNlcnMpPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCLg0K Jm5ic3A7TG9hZC1iYWxhbmNpbmcgbWF5IGJlIHBhcnQgb2YgdGhlIFNlcnZpY2UgRnVuY3Rpb248 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgaXRzZWxmLjwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQy4NCiZuYnNwO0xvYWQtYmFsYW5jZXIgbWF5IGJlIGNvbnNpZGVyZWQgYXMgYSBTZXJ2aWNl IEZ1bmN0aW9uPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IGVsZW1lbnQu PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBELg0KJm5ic3A7QmVjYXVzZSBvZiB0aGUgcG9zc2libGUgY29tcGxpY2F0 aW9ucywgbG9hZCBiYWxhbmNpbmc8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgU0hPVUxEIE5PVCBiZSBkcml2ZW4gYnkgdGhlIFNGQyBDbGFzc2lmaWVyLjwvdHQ+PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W1dlaV0gOiBKb2VsIG1lbnRpb25lZCBhcyBm b2xsb3cgdGhhdCB0aGVyZSBhcmUgMw0KZGlmZmVyZXQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5n IGNhbiBhbmQgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD53aWxsIGludGVyYWN0 IHdpdGggc2VydmljZSBjaGFpbmluZy48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZxdW90OzEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUNCmVu ZCB1c2VyLqGtoa08L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PjIpIFRoZXJlIGlz IGludGVybmFsIGxvYWQgYmFsYW5jaW5nLqGtoa0gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD4zKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVj dGluZw0KcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0PC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5kaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxh Y2VzLiBXZSB3b3VsZCBub3Qgd2FudA0KdG8gcmVxdWlyZSB0aGF0IGEgZ2l2ZW4gc2VydmljZSBm dW5jdGlvbiBhcHBlYXIgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5hdCBvbmx5 IG9uZSBwbGFjZSBpbiB0aGUgbmV0d29yay4gJnF1b3Q7PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5TbyBJIGRvbid0IHRoaW5rIHRoZXNlIHJlcXVpcmVtZW50cyBpcyBz dWZmaWNpZW50DQpmb3IgYWxsIGtpbmQgb2YgTEJzLiA8L3R0PjwvZm9udD48Zm9udCBzaXplPTI+ T3Igd2Ugc2hvdWxkIHJlZGVmaW5lIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+d2hhdCBMb2Fk IGJhbGFuY2luZyBpcy48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD4gQmVjYXVzZQ0KSU1PLCBpdGVt IDEgaXMgYW4gZXh0ZXJuYWwgTEIgc2VydmljZSBmdW5jdGlvbiBmb3IgY2hvb3NpbmcgPC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5lbmQgdXNlcnM7IEl0ZW0gMiBpcyBhbiBpbnRl cm5hbCBtZWNoYW5pc20gdG8gYmFsYW5jZQ0KcGFja2V0cyBhbW9uZyBTRnMgd2hpY2ggYWNoaWV2 ZSB0aGU8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PnNhbWUgZnVuY3Rpb247IGl0 ZW0gMyBsb29rcyBsaWtlIGFjaGlldmluZyBzaW1pbGFyDQpmdW5jdGlvbmFsaXR5IGxpa2UgVEUu ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SSBjYW5ub3Qgc2VlIHRo ZXNlIHJlcXVpcmVtZW50cyBjb250YWluIGl0ZW0gMSZhbXA7Mw0KaWYgSSBjYXB0dXJlIHlvdXIg bWVhbmluZy48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZuYnNwOzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QlRXLCBmb3IgaXRlbSAyLCB3ZSBjYW4gY2FsbCBp dCBwYWNrZXQgZGlzdHJpYnV0aW9uDQppbnN0ZWFkIG9mIGxvYWQgYmFsYW5jaW5nLjwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+V2h5IHRoaXMga2luZCBvZiBsb2FkIGJhbGFuY2lu ZyBDQU5OT1QgYmUgZHJpdmVuIGJ5DQp0aGUgU0ZDIENsYXNzaWZpZXI/PC90dD48L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBHaXZlbiB0aGUgb25nb2luZyBkaXNjdXNz aW9uIGluIHRoZSBsaXN0LCBpdA0Kd2lsbCByZWFsbHkgdXNlZnVsIHRvIDxicj4NCiZndDsgYWRq dXN0IHRoaXMgdGV4dCBhY2NvcmRpbmdseS4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBD b21tZW50cyB0byB0d2VhayB0aGlzIHRleHQsIHVwZGF0ZSBpdCwgZXRjLA0KYXJlIG1vcmUgdGhh biB3ZWxjb21lLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7 PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IENoZWVycyw8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgTWVkX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM8YnI+DQo8L3R0PjwvZm9udD4NCg== --=_alternative 00339F3F48257D12_=-- From nobody Fri Jul 11 03:56: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 94F211B284A for ; Fri, 11 Jul 2014 03:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgxr7Fg3lGLn for ; Fri, 11 Jul 2014 03:56:30 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272801B284B for ; Fri, 11 Jul 2014 03:56:29 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:52621 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1X5YV8-0002VX-UG; Fri, 11 Jul 2014 10:56:27 +0000 From: "Russ White" To: "'Eric Gray'" , "'NAPIERALA, MARIA H'" , "'Jim Guichard \(jguichar\)'" , "'Ron Parker'" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com > <1D70D757A2C 9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> Date: Fri, 11 Jul 2014 06:56:17 -0400 Message-ID: <016501cf9cf6$be8ea120$3babe360$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHPKnc9O86h9HhZKctqiuOXhtKs0QBmuVbOAeYhX2wB+L4pVgIIuL/AAa+W/LQBtUbB1gKan2F5AlQtRWkC08gyAwIBT8l4AgG3R3YBueeLtQI25HR9AoqBxM8CdDWKZgJadg5RA1jaSdWaerrwsA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5N-ufijvltJiayUMClJO0l7KaFk Cc: "'Joel M. Halpern'" , mohamed.boucadair@orange.com, sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 10:56:31 -0000 > I think SFC should be more concerned about ensuring that function chaining > solutions do not preclude load distribution. Correct -- SFC cannot ensure load is distributed properly, as that is (should be) a local policy. All we can do in SFC is to make certain the tools are place to allow service chains to be built to multiple instances of the same service, and let the policy mechanisms decide which flows should be routed to which instances of which services where. :-) Russ From nobody Fri Jul 11 05:07: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 527D71B287E for ; Fri, 11 Jul 2014 05:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, 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 weUkX5sgoPCG for ; Fri, 11 Jul 2014 05:07:46 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768801B288A for ; Fri, 11 Jul 2014 05:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 50B4524066E; Fri, 11 Jul 2014 05:07:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-8.clppva.east.verizon.net [70.106.134.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 40CC3240380; Fri, 11 Jul 2014 05:07:42 -0700 (PDT) Message-ID: <53BFD38E.2080102@joelhalpern.com> Date: Fri, 11 Jul 2014 08:07:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> In-Reply-To: <53BF5FB5.6020906@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AQEKsEt6qfqQLcRB-KMYgs2vrIg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:07:50 -0000 And it was pointed out to me that I made a two letter major typo. I was trying to say that I felt that such a requirement on all SFF would be an UNacceptable imposition. Yours, Joel On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > Ron, thinking about this, I realized another major problem with the your > proposal as I understand it. (And I readily admit I may not understand > it.) > > The proposal has each SFF serve as the load balancer for the next > service function that follows it (not the one it delivers to), in every > service chain that goes through it. > > Since it has to be able to work with all services, that means that every > SFF would have to be a full, flow sensitive and stateful load balancer. > I ahve no problem if some SFF are flow sensitive, and / or stateful. But > having the architecture require that every SFF be a full, flow > sensitive, stateful, load balancer seems to me to be an acceptable > imposition. > > Yours, > Joel > > On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> Part of my personal view is that I am trying to make this work sensibly >> in a more orchestrated environment. I expect that the service >> functions, and over time probably the SFF capabilities, will be >> orchestrated and installed. I expect the service chains to be driven by >> BSS tools that define offerings to clients, and enable self-selection >> from these. I expect service paths to be heavily policy drive. >> >> I can see how to make all of that work in an archtiecture driven by >> initial classification to described service paths. It is harder to see >> how to make it work (but it can be done) when we allow more dynamicity >> in the network behavior. >> >> Having said that, most of that perspective I described is outside of the >> scope of the working group. it is not something we are tasked to >> agree on. >> So I do not claim that vision means we have to do it a certain way. it >> is just the perspective that drives my preferences. >> >> Yours, >> Joel >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>> For me, the amount of information about service instances that needs to >>>> be widely distributed and maintained, potentially even across data >>>> centers within an administrative scope, is large enough and complex >>>> enough that trying to get that into each SFF seems like a difficult >>>> architecture to realize. >>> >>> I'm curious as to why that is more complicated than dynamic routing, >>> hyper-scale data center orchestration, or DNS, all of which are bigger >>> problems that have been profitably and stably implemented? >>> >>> It also seems that if it really is more complicated, that is a good >>> sign that it is too complicated. >>> >>> ________________________________________ >>> From: Joel M. Halpern [jmh@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 9:45 PM >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> This is an architectural issue. And one that I would prefer we actually >>> decide, rather than trying to allow all possible implementations. >>> Because it does have a major effect on the control requirements and the >>> functionality of SFFs. >>> >>> For me, the amount of information about service instances that needs to >>> be widely distributed and maintained, potentially even across data >>> centers within an administrative scope, is large enough and complex >>> enough that trying to get that into each SFF seems like a difficult >>> architecture to realize. >>> >>> Yours, >>> Joel >>> >>> But it is a fair question. >>> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>> This is the crux of my issue. Is the end to end selection of >>>> (top-level) instances performed centrally (perhaps by the classifier) >>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>>> Such selection is not equivalent to reclassification. And surely, >>>> this is an architectural issue and not relegated to >>>> "implementation". >>>> >>>> My own view is to favor the distributed approach even though a >>>> greater amount of data (chain definitions and perhaps local selection >>>> policy) is required at those distributed decision points. This >>>> approach does not require an end-to-end path id at all. My >>>> rationale for favoring this approach is primarily driven by increased >>>> resiliency over the global path id approach. With a global path id >>>> approach, consider failure of an instance and needing to alter the >>>> global path ID table for each and every affected end-to-end path. >>>> >>>> Ron >>>> >>>> ________________________________________ From: sfc >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>>> [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> The way the architecture models the case of SF1 needing to influence >>>> the chain is that one would do reclassification at the exit from >>>> SF1. >>>> >>>> Part of the goal is to keep the different functions logically >>>> separate so that solutions can clearly describe how they choose to >>>> compose them for "service" delivery. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>> I don't see anything in the arch draft that suggests any sort of >>>>> limit. However, it does seem to indicate that the entire path (all >>>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>>> either at the classifier or maybe the classifier chooses a SF Chain >>>>> and the NF or at the latest the first SFF. In any case, the >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>>> determined at the SFI(n-1) hop. According to the draft, this >>>>> behavior would be considered "branching" to a new SFP as opposed to >>>>> choosing and then forwarding to the selected instance of the >>>>> next-hop of the current SFC. >>>>> >>>>> draft-merged-sfc-architecture-00: >>>>>> When an SFC is instantiated into the network it is necessary to >>>>>> select the specific instances of SFs that will be used, and to >>>>>> create the service topology for that SFC using SF's network >>>>>> locator. Thus, instantiation of the SFC results in the creation >>>>>> of a Service Function Path (SFP) and is used for forwarding >>>>>> packets through the SFC. In other words, an SFP is the >>>>>> instantiation of the defined SFC. >>>>>> >>>>>> The SFC architecture supports reclassification (or non-initial >>>>>> classification) as well. As packets traverse an SFP, >>>>>> reclassification may occur - typically performed by a >>>>>> classification function co-resident with a service function. >>>>>> Reclassification may result in the selection of a new SFP, an >>>>>> update of the associated metadata, or both. This is referred to >>>>>> as "branching". >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>> *From: *I.Smith@F5.com >>>>> *To: *Joel Halpern Direct,Joel M. >>>>> Halpern,huang@sce.carleton.ca,sfc@ietf.org >>>>> >>>>> >>>>> >>>>> >>> *Sent: *Thursday, July 10, 2014 >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Actually, I think I am disagreeing. >>>>> >>>>> If the possibility of medium-scale deployments (and that is what >>>>> 16 million flows is in my world) of service chains is preconceived >>>>> as an absurd idea, then the architecture burdened with that >>>>> preconception. >>>>> >>>>> There has to be some point of aim, some degree of aspiration to >>>>> scale that is appropriate for the lifespan of the architecture - >>>>> you don't have to know what it is, but by saying that an arbitrary >>>>> number is "too far", you're creating - even if it isn't intentional >>>>> - a limit that influences decisions that have lasting impacts >>>>> regarding scale-out, failure mitigation, elasticity, address >>>>> space... all kinds of things. That is a problem I'm not >>>>> particularly eager to deal with. >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> >>>>> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>>> Chains, Paths, and Load Balancers >>>>> >>>>> Ian, I don't think you disagree with me at all in this regard. I am >>>>> not requesting the the architecture or the solution prohibit >>>>> deployments in the specific fashion. I am objecting to Huang's >>>>> reading of my note as saying that such deployments are required >>>>> they by the archtiecture. >>>>> >>>>> As I have said repeatedly, I am not trying to prohibit such >>>>> things. Whether they are a good idea or not depends upon many >>>>> factors outside of the scope of the WG. I happen to think that they >>>>> are usually a bad idea. >>>>> >>>>> But the archtiecture si carefully avoiding attempting to know what >>>>> is and is not eployable. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>> I disagree. >>>>>> >>>>>> We routinely have stateful devices that manage tens of millions >>>>>> of >>>>> concurrent flows in both access network and data center >>>>> environments today. You can't seriously believe that in the >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>>> to have small numbers of service chains with equally small numbers >>>>> of active service paths? >>>>>> >>>>>> Your sounds too much like "no one will ever need more than 64K" >>>>>> for >>>>> comfort. >>>>>> >>>>>> >>>>>> ________________________________________ From: sfc >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>> [jmh@joelhalpern.com] >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>> Balancers >>>>>> >>>>>> No, it will mean that if someone tries to deploy the archtieture >>>>>> particularly badly, they will exceed the limits of their >>>>>> devices. The architecture does not require such absurd use of >>>>>> service paths. Since I can not figure out how to write >>>>>> architectural words to prohibit it, the architecture does permit >>>>>> such abuse. >>>>>> >>>>>> Please do not read my saying that the archtiecture permits >>>>>> something as saying it is either deisred or required by the work. >>>>>> It isn't. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>> If you need to support 100 service chains, it will mean >>>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>>> core router. >>>>>>> >>>>>>> Chang >>>>>>> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>> operators are prepared for the complexities if they choose to >>>>>>>> avoid any use of local load balancing and in stead provision >>>>>>>> 160,000 service paths. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>>> chain with 20 instances at each hop? >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Lucy, >>>>>>>>> >>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>> forwarding. I’d >>>>> make >>>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>>> the needed forwarding and associated transport. >>>>>>>>> >>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>> hop(s). >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>>> >>>>>>>>> Lucy >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>> *Sent:*Thursday, July >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Re-, >>>>>>>>> >>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>> forwarding actions. >>>>>>>>> >>>>>>>>> Requiring a SFC system to have the full knowledge of every >>>>> available SFC >>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>> required/justified >>>>>>>>> nor possible in various deployment contexts. >>>>>>>>> >>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>> information >>>>> that will >>>>>>>>> be present in all deployments: that is the one required to >>>>>>>>> structure a service chain. How that information is used to >>>>>>>>> infer forwarding >>>>> actions >>>>>>>>> is a solution-oriented discussion. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Med >>>>>>>>> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>> de*mikebianc@aol.com >>>>>>>>> *Envoyé :*mercredi 9 juillet >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>>> and SF >>>>> Path? >>>>>>>>> Other than clarifying the definition so that it's clear to >>>>> those not >>>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>>> these terms. >>>>>>>>> >>>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>>> of the SFC Header >>>>> should >>>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>>> path and the choice of chain or >>>>> path to >>>>>>>>> be negotiated in the control-plane. >>>>>>>>> >>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>> >>>>>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>>>> >>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>> > >>>>>>>>> *To:*sfc@ietf.org>>>>>>>> > *Sent:*Tuesday, July >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>> Balancers >>>>>>>>> >>>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>>> number of comments that have been made about the proposed >>>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>>> wording so that readers who have not participated in the WG >>>>>>>>> discussion will understnd it the way the >>>>> working >>>>>>>>> group intends. >>>>>>>>> >>>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>>> view, and see if that helps. >>>>>>>>> >>>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>>> attempting to define the architecture for the entire >>>>>>>>> solution for service chaining. That would encompass >>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>> machine and image management, and many other aspects. >>>>>>>>> >>>>>>>>> As a result there are many things which clearly need to >>>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>>> where we are >>>>> functioning, >>>>>>>>> and are not directly required by the work we are doing. >>>>>>>>> >>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>> understand >>>>> them, >>>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>>> three different ways that load balancing can and will >>>>>>>>> interact with service chaining. There probably are more. >>>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>>> but not to mandate that any particular kind >>>>> be used >>>>>>>>> in any solution. >>>>>>>>> >>>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>>> This is a service function. It receives user packets, and >>>>>>>>> modifies them (or >>>>> marks >>>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>>> to receive the users packet. This is an important service >>>>>>>>> function to be able to include in service chaining. It's >>>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>>> From an architectural pe3rspective it is simply a >>>>> service >>>>>>>>> function which may modify the underlying packet. >>>>>>>>> >>>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>>> what >>>>> appears >>>>>>>>> to the service chaining architecture as a single point of >>>>>>>>> contact >>>>> for a >>>>>>>>> specific service function, but is actually delivered by a >>>>> collection of >>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>>> is largely that we need to be careful that our terminology >>>>>>>>> does not lead >>>>> readers to >>>>>>>>> think we are prohibiting it. >>>>>>>>> >>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>>> to different places. We would not want to require that a >>>>>>>>> given service function appear at only one place in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>>> to >>>>> refer to >>>>>>>>> the collection of entities that appear to service chaining >>>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>>> point of type 3 load balancing >>>>> is to >>>>>>>>> direct different subsets of traffic to different singular >>>>>>>>> or clustered service functions in different places in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>> while a different subset is to go directly to the cache >>>>> without >>>>>>>>> visiting any other service functions. >>>>>>>>> >>>>>>>>> That is not enough information to direct the packets. A >>>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>>> in the network. Those locations will be singular or >>>>>>>>> clustered service function delivery locations. They may be >>>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>>> an SFF. There are many different ways that the locations >>>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>>> transport. >>>>>>>>> >>>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>>> need to be >>>>>>>>> able to talk about the high level abstraction, the service >>>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>>> about the actual data path packets will take in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> Several of the comments have said "but the whole path may >>>>>>>>> not be known at the front." This architecture deals with >>>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>>> make is >>>>> that >>>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>> information available at the re-classification point. >>>>>>>>> >>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>>> we can figure out what additional words are needed to >>>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>>> then we will of course adjust to match the working group >>>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>>> try next. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 11 05:31: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 1E3011B2890 for ; Fri, 11 Jul 2014 05:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j1m7HARL1GY for ; Fri, 11 Jul 2014 05:31:09 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B331B2817 for ; Fri, 11 Jul 2014 05:31:09 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id d09dfb35.2b15f621c940.8849165.00-2404.21219665.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:31:09 +0000 (UTC) X-MXL-Hash: 53bfd90d12ecaeaa-9b59065138a8adc2d9698c410a79f7782f2326df Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 409dfb35.0.8849067.00-2325.21219447.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:31:01 +0000 (UTC) X-MXL-Hash: 53bfd905412a2423-269fae31a7fe13db04c43f1ec6b507ecf62171d2 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCUxLY004299; Fri, 11 Jul 2014 08:30:59 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCUnkJ004116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 08:30:57 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 12:30:34 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 08:30:33 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAihoA///BssA= Date: Fri, 11 Jul 2014 12:30:33 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AB2A@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> In-Reply-To: <53BFD38E.2080102@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 ] X-AnalysisOut: [a=n2LCcfabAAAA:8 a=z9tbli-vAAAA:8 a=i0EeH86SAAAA:8 a=cQipz] X-AnalysisOut: [yA5o-1Gn_yH3FQA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=ch] X-AnalysisOut: [C_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037QrwtgA:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=hPjdaMEvmhQA:10 a=2G0yj1D3oV5Q8H1Q:21 a=42EHSQ] X-AnalysisOut: [nfG36-KsBi:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/syy1D0cuwtDU4h9fgjt4lUE_fok Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:31:13 -0000 Disagree. And "requiring" that SFC central system does all of it is "accept= able", let me add, "achievable"? As many of us pointed out already "distribution" is the only way to make i= t work. Med in one his recent e-mail pointed the difficulties in doing it c= entrally.=20 Maria=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, July 11, 2014 8:08 AM > To: Ron Parker; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > And it was pointed out to me that I made a two letter major typo. >=20 > I was trying to say that I felt that such a requirement on all SFF would > be an UNacceptable imposition. >=20 > Yours, > Joel >=20 > On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > > Ron, thinking about this, I realized another major problem with the you= r > > proposal as I understand it. (And I readily admit I may not understand > > it.) > > > > The proposal has each SFF serve as the load balancer for the next > > service function that follows it (not the one it delivers to), in every > > service chain that goes through it. > > > > Since it has to be able to work with all services, that means that ever= y > > SFF would have to be a full, flow sensitive and stateful load balancer. > > I ahve no problem if some SFF are flow sensitive, and / or stateful. Bu= t > > having the architecture require that every SFF be a full, flow > > sensitive, stateful, load balancer seems to me to be an acceptable > > imposition. > > > > Yours, > > Joel > > > > On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >> Part of my personal view is that I am trying to make this work sensibl= y > >> in a more orchestrated environment. I expect that the service > >> functions, and over time probably the SFF capabilities, will be > >> orchestrated and installed. I expect the service chains to be driven = by > >> BSS tools that define offerings to clients, and enable self-selection > >> from these. I expect service paths to be heavily policy drive. > >> > >> I can see how to make all of that work in an archtiecture driven by > >> initial classification to described service paths. It is harder to se= e > >> how to make it work (but it can be done) when we allow more > dynamicity > >> in the network behavior. > >> > >> Having said that, most of that perspective I described is outside of t= he > >> scope of the working group. it is not something we are tasked to > >> agree on. > >> So I do not claim that vision means we have to do it a certain way. i= t > >> is just the perspective that drives my preferences. > >> > >> Yours, > >> Joel > >> > >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>> For me, the amount of information about service instances that needs > to > >>>> be widely distributed and maintained, potentially even across data > >>>> centers within an administrative scope, is large enough and complex > >>>> enough that trying to get that into each SFF seems like a difficult > >>>> architecture to realize. > >>> > >>> I'm curious as to why that is more complicated than dynamic routing, > >>> hyper-scale data center orchestration, or DNS, all of which are bigge= r > >>> problems that have been profitably and stably implemented? > >>> > >>> It also seems that if it really is more complicated, that is a good > >>> sign that it is too complicated. > >>> > >>> ________________________________________ > >>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>> Sent: Thursday, July 10, 2014 9:45 PM > >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >>> sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> This is an architectural issue. And one that I would prefer we actua= lly > >>> decide, rather than trying to allow all possible implementations. > >>> Because it does have a major effect on the control requirements and > the > >>> functionality of SFFs. > >>> > >>> For me, the amount of information about service instances that needs > to > >>> be widely distributed and maintained, potentially even across data > >>> centers within an administrative scope, is large enough and complex > >>> enough that trying to get that into each SFF seems like a difficult > >>> architecture to realize. > >>> > >>> Yours, > >>> Joel > >>> > >>> But it is a fair question. > >>> > >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>> This is the crux of my issue. Is the end to end selection of > >>>> (top-level) instances performed centrally (perhaps by the classifier= ) > >>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? > >>>> Such selection is not equivalent to reclassification. And surely, > >>>> this is an architectural issue and not relegated to > >>>> "implementation". > >>>> > >>>> My own view is to favor the distributed approach even though a > >>>> greater amount of data (chain definitions and perhaps local selectio= n > >>>> policy) is required at those distributed decision points. This > >>>> approach does not require an end-to-end path id at all. My > >>>> rationale for favoring this approach is primarily driven by increase= d > >>>> resiliency over the global path id approach. With a global path id > >>>> approach, consider failure of an instance and needing to alter the > >>>> global path ID table for each and every affected end-to-end path. > >>>> > >>>> Ron > >>>> > >>>> ________________________________________ From: sfc > >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > >>>> [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> The way the architecture models the case of SF1 needing to influence > >>>> the chain is that one would do reclassification at the exit from > >>>> SF1. > >>>> > >>>> Part of the goal is to keep the different functions logically > >>>> separate so that solutions can clearly describe how they choose to > >>>> compose them for "service" delivery. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>> I don't see anything in the arch draft that suggests any sort of > >>>>> limit. However, it does seem to indicate that the entire path (all > >>>>> SFIs) must be chosen at SFC instantiation. I believe this means > >>>>> either at the classifier or maybe the classifier chooses a SF Chain > >>>>> and the NF or at the latest the first SFF. In any case, the > >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is > >>>>> determined at the SFI(n-1) hop. According to the draft, this > >>>>> behavior would be considered "branching" to a new SFP as opposed > to > >>>>> choosing and then forwarding to the selected instance of the > >>>>> next-hop of the current SFC. > >>>>> > >>>>> draft-merged-sfc-architecture-00: > >>>>>> When an SFC is instantiated into the network it is necessary to > >>>>>> select the specific instances of SFs that will be used, and to > >>>>>> create the service topology for that SFC using SF's network > >>>>>> locator. Thus, instantiation of the SFC results in the creation > >>>>>> of a Service Function Path (SFP) and is used for forwarding > >>>>>> packets through the SFC. In other words, an SFP is the > >>>>>> instantiation of the defined SFC. > >>>>>> > >>>>>> The SFC architecture supports reclassification (or non-initial > >>>>>> classification) as well. As packets traverse an SFP, > >>>>>> reclassification may occur - typically performed by a > >>>>>> classification function co-resident with a service function. > >>>>>> Reclassification may result in the selection of a new SFP, an > >>>>>> update of the associated metadata, or both. This is referred to > >>>>>> as "branching". > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------= ----- > >>>>> > >>>>> > >>>>> > >>>>> > >>> *From: *I.Smith@F5.com > >>>>> *To: *Joel Halpern Direct,Joel M. > >>>>> > Halpern,huang@sce.carleton.ca on.ca>,sfc@ietf.org > >>>>> > >>>>> > >>>>> > >>>>> > >>> *Sent: *Thursday, July 10, 2014 > >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> Actually, I think I am disagreeing. > >>>>> > >>>>> If the possibility of medium-scale deployments (and that is what > >>>>> 16 million flows is in my world) of service chains is preconceived > >>>>> as an absurd idea, then the architecture burdened with that > >>>>> preconception. > >>>>> > >>>>> There has to be some point of aim, some degree of aspiration to > >>>>> scale that is appropriate for the lifespan of the architecture - > >>>>> you don't have to know what it is, but by saying that an arbitrary > >>>>> number is "too far", you're creating - even if it isn't intentional > >>>>> - a limit that influences decisions that have lasting impacts > >>>>> regarding scale-out, failure mitigation, elasticity, address > >>>>> space... all kinds of things. That is a problem I'm not > >>>>> particularly eager to deal with. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>>>> Chains, Paths, and Load Balancers > >>>>> > >>>>> Ian, I don't think you disagree with me at all in this regard. I am > >>>>> not requesting the the architecture or the solution prohibit > >>>>> deployments in the specific fashion. I am objecting to Huang's > >>>>> reading of my note as saying that such deployments are required > >>>>> they by the archtiecture. > >>>>> > >>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>> things. Whether they are a good idea or not depends upon many > >>>>> factors outside of the scope of the WG. I happen to think that they > >>>>> are usually a bad idea. > >>>>> > >>>>> But the archtiecture si carefully avoiding attempting to know what > >>>>> is and is not eployable. > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>> I disagree. > >>>>>> > >>>>>> We routinely have stateful devices that manage tens of millions > >>>>>> of > >>>>> concurrent flows in both access network and data center > >>>>> environments today. You can't seriously believe that in the > >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > going > >>>>> to have small numbers of service chains with equally small numbers > >>>>> of active service paths? > >>>>>> > >>>>>> Your sounds too much like "no one will ever need more than 64K" > >>>>>> for > >>>>> comfort. > >>>>>> > >>>>>> > >>>>>> ________________________________________ From: sfc > >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>> [jmh@joelhalpern.com] > >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; > >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load > >>>>>> Balancers > >>>>>> > >>>>>> No, it will mean that if someone tries to deploy the archtieture > >>>>>> particularly badly, they will exceed the limits of their > >>>>>> devices. The architecture does not require such absurd use of > >>>>>> service paths. Since I can not figure out how to write > >>>>>> architectural words to prohibit it, the architecture does permit > >>>>>> such abuse. > >>>>>> > >>>>>> Please do not read my saying that the archtiecture permits > >>>>>> something as saying it is either deisred or required by the work. > >>>>>> It isn't. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>> If you need to support 100 service chains, it will mean > >>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>>>>>> core router. > >>>>>>> > >>>>>>> Chang > >>>>>>> > >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>> service path to 160000 service paths. I would hope that > >>>>>>>> operators are prepared for the complexities if they choose to > >>>>>>>> avoid any use of local load balancing and in stead provision > >>>>>>>> 160,000 service paths. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>> Paul, > >>>>>>>>> > >>>>>>>>> How many path identifiers there will be for a 4 hop service > >>>>>>>>> chain with 20 instances at each hop? > >>>>>>>>> > >>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Lucy, > >>>>>>>>> > >>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>> forwarding. I'd > >>>>> make > >>>>>>>>> the minor change: the path identifier can be used to derive > >>>>>>>>> the needed forwarding and associated transport. > >>>>>>>>> > >>>>>>>>> It is _not_ the transport, but rather is used to simply > >>>>>>>>> identify the service path (or graph) that packets must > >>>>>>>>> traverse. By having a path identifier, the exact > >>>>>>>>> indirection that people seem to be asking for on this > >>>>>>>>> thread can be simply be implemented. The path identifier > >>>>>>>>> provides nothing more than a lookup, that lookup can result > >>>>>>>>> in a one or more (equal or weighted) transport next > >>>>>>>>> hop(s). > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>> > > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>>>>>>>> service path identifier to drive the forwarding actions. > >>>>>>>>> > >>>>>>>>> Lucy > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>> *Sent:*Thursday, > July > >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Re-, > >>>>>>>>> > >>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>> identifier. I object to use that identifier to derive > >>>>>>>>> forwarding actions. > >>>>>>>>> > >>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>>>> available SFC > >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>> required/justified > >>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>> > >>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>> information > >>>>> that will > >>>>>>>>> be present in all deployments: that is the one required to > >>>>>>>>> structure a service chain. How that information is used to > >>>>>>>>> infer forwarding > >>>>> actions > >>>>>>>>> is a solution-oriented discussion. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Med > >>>>>>>>> > >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>> de*mikebianc@aol.com > >>>>>>>>> *Envoy=E9 :*mercredi 9 juillet > >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Is anyone still questioning the difference between SF Chain > >>>>>>>>> and SF > >>>>> Path? > >>>>>>>>> Other than clarifying the definition so that it's clear to > >>>>> those not > >>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>>>>>>>> these terms. > >>>>>>>>> > >>>>>>>>> To me, the one point that is still unclear is whether it is > >>>>>>>>> the intent of this draft to ultimately specify what the ID > >>>>>>>>> of the SFC Header > >>>>> should > >>>>>>>>> reference (the chain or the path), or if this draft simply > >>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>>>>>>>> path and the choice of chain or > >>>>> path to > >>>>>>>>> be negotiated in the control-plane. > >>>>>>>>> > >>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>> require that both SFP and SFC be supported (or make one > >>>>>>>>> required and the other optional) to avoid some vendors only > >>>>>>>>> supporting SFP and others only supporting SFC. > >>>>>>>>> > >>>>>>>>> > >>>>> -------------------------------------------------------------------= ----- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> > >>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>> > > >>>>>>>>> *To:*sfc@ietf.org >>>>>>>>> > *Sent:*Tuesday, July > >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>>>>>>>> Balancers > >>>>>>>>> > >>>>>>>>> I have been trying to figure out how to clearly answer a > >>>>>>>>> number of comments that have been made about the proposed > >>>>>>>>> merged archtiecture draft. Assuming we can get working > >>>>>>>>> group agreement on the intent, we will work to improve the > >>>>>>>>> wording so that readers who have not participated in the WG > >>>>>>>>> discussion will understnd it the way the > >>>>> working > >>>>>>>>> group intends. > >>>>>>>>> > >>>>>>>>> But what do we intend? I will try to explain my personal > >>>>>>>>> view, and see if that helps. > >>>>>>>>> > >>>>>>>>> In this regard, it is important to keep in mind that what > >>>>>>>>> we are defining is the data plane architecture. We are not > >>>>>>>>> attempting to define the architecture for the entire > >>>>>>>>> solution for service chaining. That would encompass > >>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>>>>>>>> machine and image management, and many other aspects. > >>>>>>>>> > >>>>>>>>> As a result there are many things which clearly need to > >>>>>>>>> exist in the larger system, but which are dealt with above > >>>>>>>>> where we are > >>>>> functioning, > >>>>>>>>> and are not directly required by the work we are doing. > >>>>>>>>> > >>>>>>>>> In order to get to service chain vs service path, as I > >>>>>>>>> understand > >>>>> them, > >>>>>>>>> I need to first discuss load balancing. There are at least > >>>>>>>>> three different ways that load balancing can and will > >>>>>>>>> interact with service chaining. There probably are more. > >>>>>>>>> The point of the archtiecture is to permit all of these, > >>>>>>>>> but not to mandate that any particular kind > >>>>> be used > >>>>>>>>> in any solution. > >>>>>>>>> > >>>>>>>>> 1) Load balancing as a service provided to the end user. > >>>>>>>>> This is a service function. It receives user packets, and > >>>>>>>>> modifies them (or > >>>>> marks > >>>>>>>>> them, or ...) so as to choose an end user service instance > >>>>>>>>> to receive the users packet. This is an important service > >>>>>>>>> function to be able to include in service chaining. It's > >>>>>>>>> behavior may affect requirements on how service chaining is > >>>>>>>>> done. But it has very little impact on the archtiecture. > >>>>>>>>> From an architectural pe3rspective it is simply a > >>>>> service > >>>>>>>>> function which may modify the underlying packet. > >>>>>>>>> > >>>>>>>>> 2) There is internal load balancing. That is, one can have > >>>>>>>>> what > >>>>> appears > >>>>>>>>> to the service chaining architecture as a single point of > >>>>>>>>> contact > >>>>> for a > >>>>>>>>> specific service function, but is actually delivered by a > >>>>> collection of > >>>>>>>>> virtual or physical machines, possibly including one or > >>>>>>>>> several load balancers (for example using VRRP-like > >>>>>>>>> techniques to share a MAC address.) mostly, this is > >>>>>>>>> invisible to the service chaining data plane mechanisms. It > >>>>>>>>> is likely that it is visible to various control mechanisms, > >>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>>>>>>>> instantiation. The architectural impact of permitting this > >>>>>>>>> is largely that we need to be careful that our terminology > >>>>>>>>> does not lead > >>>>> readers to > >>>>>>>>> think we are prohibiting it. > >>>>>>>>> > >>>>>>>>> 3) There can also be load balancing done by selecting > >>>>>>>>> packet paths for the service chaining that direct traffic > >>>>>>>>> to different places. We would not want to require that a > >>>>>>>>> given service function appear at only one place in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> It is of course the case that these may be combined. I tend > >>>>>>>>> to > >>>>> refer to > >>>>>>>>> the collection of entities that appear to service chaining > >>>>>>>>> as a single point as a cluster. Not because cluster is a > >>>>>>>>> good term. But because I do not have another one. Thus, the > >>>>>>>>> point of type 3 load balancing > >>>>> is to > >>>>>>>>> direct different subsets of traffic to different singular > >>>>>>>>> or clustered service functions in different places in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>> service chain and service path/ Service chain is a sequence > >>>>>>>>> of logical functions to be applied to a subset of packets. > >>>>>>>>> It is equivalent of saying that some subset of traffic is > >>>>>>>>> to get DPI, charging, content inspection, and firewall > >>>>>>>>> while a different subset is to go directly to the cache > >>>>> without > >>>>>>>>> visiting any other service functions. > >>>>>>>>> > >>>>>>>>> That is not enough information to direct the packets. A > >>>>>>>>> service path is, in some fashion, a sequence of locations > >>>>>>>>> in the network. Those locations will be singular or > >>>>>>>>> clustered service function delivery locations. They may be > >>>>>>>>> addressed by IP address. They may be addressed as ports on > >>>>>>>>> an SFF. There are many different ways that the locations > >>>>>>>>> may be known to the service chaining infrastructure and the > >>>>>>>>> transport. > >>>>>>>>> > >>>>>>>>>> From the point of view of the work of the SFC group, we > >>>>>>>>>> need to be > >>>>>>>>> able to talk about the high level abstraction, the service > >>>>>>>>> chain, which drives the forwarding. And we need to talk > >>>>>>>>> about the actual data path packets will take in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> Several of the comments have said "but the whole path may > >>>>>>>>> not be known at the front." This architecture deals with > >>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >>>>>>>>> balancers above, there can be decisions and behaviors which > >>>>>>>>> are invisible to the service chaining mechanisms (in much > >>>>>>>>> the same way that bridging within a LAN is largely > >>>>>>>>> invisible to routing between LANs.) The other provision we > >>>>>>>>> make is > >>>>> that > >>>>>>>>> reclassification can be done in mid-chain when necessary. > >>>>>>>>> That will direct packets to a new chain. Based on > >>>>>>>>> information available at the re-classification point. > >>>>>>>>> > >>>>>>>>> I hope that this helps explain what we are after. If it > >>>>>>>>> does, and if the intent is acceptable to the working group, > >>>>>>>>> we can figure out what additional words are needed to > >>>>>>>>> convey this. If the working group disagree with the intent, > >>>>>>>>> then we will of course adjust to match the working group > >>>>>>>>> agreements. If this is still unclear, I am not sure what to > >>>>>>>>> try next. > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > mailing > >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ sfc mailing > list > >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>>> _______________________________________________ sfc mailing > list > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > list > >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > list > >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Fri Jul 11 05:37: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 7F7931A0AAE for ; Fri, 11 Jul 2014 05:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=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 IGLG6k9GGbBP for ; Fri, 11 Jul 2014 05:37:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC3E1A0080 for ; Fri, 11 Jul 2014 05:37:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6D39E240914; Fri, 11 Jul 2014 05:37:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-174.clppva.east.verizon.net [70.106.134.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8E15024066E; Fri, 11 Jul 2014 05:37:10 -0700 (PDT) Message-ID: <53BFDA76.302@joelhalpern.com> Date: Fri, 11 Jul 2014 08:37:10 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Joel M. Halpern" , Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B_TMilA3IlobhvZV3uAi3H6-rI0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:37:17 -0000 Med, several of your points are well-taken, and already allowed for in the proposed architecture. However, I disagree with a couple of them in important ways. Path selection is not, from what I have seen, dynamic in nature. There has been expressed repeatedly a requirement that all the packets of a given flow go through the same service instances. Dynamic routing simply does not do that. More importantly, one of the goals of the archtiecture is to separate service function concerns from the network service chaining concerns. As such, service chaining policy is not the puriew of servie functions. There are various ways that service functions can indicate that a given set of packets (usually flow, but maybe subscriber, ...) should get tied to a different service chain. But that is not the same as an SF having policy about how the network delivers service chaining or where it delivers packets to do that. And as has been said repeatedly, the archtiecture proposed does not require that load balancing be done entirely at the central point. As far as I can tell any solution compliant with the proposed archtiecture allows for both centralized control of some traffic distribution, and local load balancing within that. I would expect most deployments would use both. Yours, Joel On 7/11/14, 3:49 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > This is one possible approach, but what several of us are trying to > clarify is this is one approach among others, not possible in some > contexts, more complex to ensure resiliency, etc. Below some of my > concerns about your approach: > > (1) Having an entity that maintains a large set of service paths in a > given domain is more like creating circuits...I thought distributed > routing has shown its efficiency. (2) Policies are everywhere in the > network , not only at the SFC structuring system. (3) Path selection > is dynamic by nature because it depends on various heuristics and > policies that are distributed in the network (including those of SFs > and others). (4) Having a stateful function that maintains the full > list of available paths may not be that resilient. This must assess > frequently (very short cycle) valid and serviceable paths among > available ones. Ensuring the same level of resilience would require > additional features to be supported by to that entity maintaining the > full set of path, and also SFs. (5) Load-balancing at a centralized > entity is deployment-specific; as such it is not required nor > possible in those contexts. Deciding the forwarding path a priori > contradicts LB requirements. I know your answer about > re-classification, but IMHO the architecture should not mandate an > optional feature only because of some design choices. > Re-classification should be avoided as much for the same of > performance and also because this one of the complexity vector for > this work. (6) There are a bunch of solutions that achieve > differentiated forwarding without requiring a > pre-computation/pre-determination of a path: think about ToS-based > routing, multi-topology routing, etc. > > I could live with an optional capability that a path can be > pre-determined, but this must not be the rule. > > Forwarding within an SFC-enabled domain is primarily inferred by the > service function chain itself. How this information is used to drive > forwarding actions is all about details. > > Cheers, Med > >> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >> De la part de Joel M. Halpern Envoyé : vendredi 11 juillet 2014 >> 04:06 À : Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org >> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Part of my personal view is that I am trying to make this work >> sensibly in a more orchestrated environment. I expect that the >> service functions, and over time probably the SFF capabilities, >> will be orchestrated and installed. I expect the service chains to >> be driven by BSS tools that define offerings to clients, and enable >> self-selection from these. I expect service paths to be heavily >> policy drive. >> >> I can see how to make all of that work in an archtiecture driven >> by initial classification to described service paths. It is harder >> to see how to make it work (but it can be done) when we allow more >> dynamicity in the network behavior. >> >> Having said that, most of that perspective I described is outside >> of the scope of the working group. it is not something we are >> tasked to agree on. So I do not claim that vision means we have to >> do it a certain way. it is just the perspective that drives my >> preferences. >> >> Yours, Joel >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>> For me, the amount of information about service instances that >>>> needs to be widely distributed and maintained, potentially even >>>> across data centers within an administrative scope, is large >>>> enough and complex enough that trying to get that into each SFF >>>> seems like a difficult architecture to realize. >>> >>> I'm curious as to why that is more complicated than dynamic >>> routing, >> hyper-scale data center orchestration, or DNS, all of which are >> bigger problems that have been profitably and stably implemented? >>> >>> It also seems that if it really is more complicated, that is a >>> good sign >> that it is too complicated. >>> >>> ________________________________________ From: Joel M. Halpern >>> [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: >>> Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> This is an architectural issue. And one that I would prefer we >>> actually decide, rather than trying to allow all possible >>> implementations. Because it does have a major effect on the >>> control requirements and the functionality of SFFs. >>> >>> For me, the amount of information about service instances that >>> needs to be widely distributed and maintained, potentially even >>> across data centers within an administrative scope, is large >>> enough and complex enough that trying to get that into each SFF >>> seems like a difficult architecture to realize. >>> >>> Yours, Joel >>> >>> But it is a fair question. >>> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>> This is the crux of my issue. Is the end to end selection of >>>> (top-level) instances performed centrally (perhaps by the >>>> classifier) or hop-by-hop (perhaps by the classifier and >>>> subsequently the SFFs)? Such selection is not equivalent to >>>> reclassification. And surely, this is an architectural issue >>>> and not relegated to "implementation". >>>> >>>> My own view is to favor the distributed approach even though a >>>> greater amount of data (chain definitions and perhaps local >>>> selection policy) is required at those distributed decision >>>> points. This approach does not require an end-to-end path id >>>> at all. My rationale for favoring this approach is primarily >>>> driven by increased resiliency over the global path id >>>> approach. With a global path id approach, consider failure of >>>> an instance and needing to alter the global path ID table for >>>> each and every affected end-to-end path. >>>> >>>> Ron >>>> >>>> ________________________________________ From: sfc >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 >>>> PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: >>>> Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> The way the architecture models the case of SF1 needing to >>>> influence the chain is that one would do reclassification at >>>> the exit from SF1. >>>> >>>> Part of the goal is to keep the different functions logically >>>> separate so that solutions can clearly describe how they choose >>>> to compose them for "service" delivery. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>> I don't see anything in the arch draft that suggests any sort >>>>> of limit. However, it does seem to indicate that the entire >>>>> path (all SFIs) must be chosen at SFC instantiation. I >>>>> believe this means either at the classifier or maybe the >>>>> classifier chooses a SF Chain and the NF or at the latest the >>>>> first SFF. In any case, the language does seem to prohibit a >>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1) >>>>> hop. According to the draft, this behavior would be >>>>> considered "branching" to a new SFP as opposed to choosing >>>>> and then forwarding to the selected instance of the next-hop >>>>> of the current SFC. >>>>> >>>>> draft-merged-sfc-architecture-00: >>>>>> When an SFC is instantiated into the network it is >>>>>> necessary to select the specific instances of SFs that will >>>>>> be used, and to create the service topology for that SFC >>>>>> using SF's network locator. Thus, instantiation of the SFC >>>>>> results in the creation of a Service Function Path (SFP) >>>>>> and is used for forwarding packets through the SFC. In >>>>>> other words, an SFP is the instantiation of the defined >>>>>> SFC. >>>>>> >>>>>> The SFC architecture supports reclassification (or >>>>>> non-initial classification) as well. As packets traverse >>>>>> an SFP, reclassification may occur - typically performed by >>>>>> a classification function co-resident with a service >>>>>> function. Reclassification may result in the selection of a >>>>>> new SFP, an update of the associated metadata, or both. >>>>>> This is referred to as "branching". >>>>> >>>>> >>>>> >>>>> ----------------------------------------------------------------------- >> >>>>> - >>>>> >>>>> >>> *From: *I.Smith@F5.com >>>>> *To: *Joel Halpern Direct,Joel >>>>> M. >>>>> >> Halpern,huang@sce.carleton.ca,s >> >> fc@ietf.org >>>>> >>>>> >>> *Sent: *Thursday, July 10, 2014 >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>>>> Balancers >>>>> >>>>> Actually, I think I am disagreeing. >>>>> >>>>> If the possibility of medium-scale deployments (and that is >>>>> what 16 million flows is in my world) of service chains is >>>>> preconceived as an absurd idea, then the architecture >>>>> burdened with that preconception. >>>>> >>>>> There has to be some point of aim, some degree of aspiration >>>>> to scale that is appropriate for the lifespan of the >>>>> architecture - you don't have to know what it is, but by >>>>> saying that an arbitrary number is "too far", you're creating >>>>> - even if it isn't intentional - a limit that influences >>>>> decisions that have lasting impacts regarding scale-out, >>>>> failure mitigation, elasticity, address space... all kinds of >>>>> things. That is a problem I'm not particularly eager to deal >>>>> with. >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> >>>>> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>>>> Halpern; huang@sce.carleton.ca; sfc@ietf.org Subject: Re: >>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Ian, I don't think you disagree with me at all in this >>>>> regard. I am not requesting the the architecture or the >>>>> solution prohibit deployments in the specific fashion. I am >>>>> objecting to Huang's reading of my note as saying that such >>>>> deployments are required they by the archtiecture. >>>>> >>>>> As I have said repeatedly, I am not trying to prohibit such >>>>> things. Whether they are a good idea or not depends upon >>>>> many factors outside of the scope of the WG. I happen to >>>>> think that they are usually a bad idea. >>>>> >>>>> But the archtiecture si carefully avoiding attempting to know >>>>> what is and is not eployable. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>> I disagree. >>>>>> >>>>>> We routinely have stateful devices that manage tens of >>>>>> millions of >>>>> concurrent flows in both access network and data center >>>>> environments today. You can't seriously believe that in the >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >>>>> going to have small numbers of service chains with equally >>>>> small numbers of active service paths? >>>>>> >>>>>> Your sounds too much like "no one will ever need more than >>>>>> 64K" for >>>>> comfort. >>>>>> >>>>>> >>>>>> ________________________________________ From: sfc >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>> [jmh@joelhalpern.com] >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >>>>>> Service Chains, Paths, and Load Balancers >>>>>> >>>>>> No, it will mean that if someone tries to deploy the >>>>>> archtieture particularly badly, they will exceed the limits >>>>>> of their devices. The architecture does not require such >>>>>> absurd use of service paths. Since I can not figure out how >>>>>> to write architectural words to prohibit it, the >>>>>> architecture does permit such abuse. >>>>>> >>>>>> Please do not read my saying that the archtiecture permits >>>>>> something as saying it is either deisred or required by the >>>>>> work. It isn't. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>> If you need to support 100 service chains, it will mean >>>>>>> 16,000,000 paths. That is larger than the routing table >>>>>>> of a core router. >>>>>>> >>>>>>> Chang >>>>>>> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>> service path to 160000 service paths. I would hope >>>>>>>> that operators are prepared for the complexities if >>>>>>>> they choose to avoid any use of local load balancing >>>>>>>> and in stead provision 160,000 service paths. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> How many path identifiers there will be for a 4 hop >>>>>>>>> service chain with 20 instances at each hop? >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10, >>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:* >>>>>>>>> jmh@joelhalpern.com; mohamed.boucadair@orange.com; >>>>>>>>> sfc@ietf.org; mikebianc@aol.com *Subject:* Re: [sfc] >>>>>>>>> Service Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Lucy, >>>>>>>>> >>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>> forwarding. I'd >>>>> make >>>>>>>>> the minor change: the path identifier can be used to >>>>>>>>> derive the needed forwarding and associated >>>>>>>>> transport. >>>>>>>>> >>>>>>>>> It is _not_ the transport, but rather is used to >>>>>>>>> simply identify the service path (or graph) that >>>>>>>>> packets must traverse. By having a path identifier, >>>>>>>>> the exact indirection that people seem to be asking >>>>>>>>> for on this thread can be simply be implemented. The >>>>>>>>> path identifier provides nothing more than a lookup, >>>>>>>>> that lookup can result in a one or more (equal or >>>>>>>>> weighted) transport next hop(s). >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Agree. The arch. doc should not mandate only use of >>>>>>>>> the service path identifier to drive the forwarding >>>>>>>>> actions. >>>>>>>>> >>>>>>>>> Lucy >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>> >>>>>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>>>>>>> *To:*mikebianc@aol.com >>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Subject:*Re: [sfc] Service >>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Re-, >>>>>>>>> >>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>> identifier. I object to use that identifier to >>>>>>>>> derive forwarding actions. >>>>>>>>> >>>>>>>>> Requiring a SFC system to have the full knowledge of >>>>>>>>> every >>>>> available SFC >>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>> required/justified >>>>>>>>> nor possible in various deployment contexts. >>>>>>>>> >>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>> information >>>>> that will >>>>>>>>> be present in all deployments: that is the one >>>>>>>>> required to structure a service chain. How that >>>>>>>>> information is used to infer forwarding >>>>> actions >>>>>>>>> is a solution-oriented discussion. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Med >>>>>>>>> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>> de*mikebianc@aol.com >>>>>>>>> *Envoyé :*mercredi 9 >>>>>>>>> juillet 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Objet :*Re: [sfc] Service >>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Is anyone still questioning the difference between SF >>>>>>>>> Chain and SF >>>>> Path? >>>>>>>>> Other than clarifying the definition so that it's >>>>>>>>> clear to >>>>> those not >>>>>>>>> familiar with the draft, it seems that everyone >>>>>>>>> agrees on these terms. >>>>>>>>> >>>>>>>>> To me, the one point that is still unclear is whether >>>>>>>>> it is the intent of this draft to ultimately specify >>>>>>>>> what the ID of the SFC Header >>>>> should >>>>>>>>> reference (the chain or the path), or if this draft >>>>>>>>> simply intends to leave that ambiguous, allowing >>>>>>>>> other drafts to dictate the mechanisms for forwarding >>>>>>>>> based on chain or path and the choice of chain or >>>>> path to >>>>>>>>> be negotiated in the control-plane. >>>>>>>>> >>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>> require that both SFP and SFC be supported (or make >>>>>>>>> one required and the other optional) to avoid some >>>>>>>>> vendors only supporting SFP and others only >>>>>>>>> supporting SFC. >>>>>>>>> >>>>>>>>> >>>>> ----------------------------------------------------------------------- >> >>>>> - >>>>> >>>>> >>>>>>> >>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>> > >>>>>>>>> *To:*sfc@ietf.org>>>>>>>> > *Sent:*Tuesday, >>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths, >>>>>>>>> and Load Balancers >>>>>>>>> >>>>>>>>> I have been trying to figure out how to clearly >>>>>>>>> answer a number of comments that have been made about >>>>>>>>> the proposed merged archtiecture draft. Assuming we >>>>>>>>> can get working group agreement on the intent, we >>>>>>>>> will work to improve the wording so that readers who >>>>>>>>> have not participated in the WG discussion will >>>>>>>>> understnd it the way the >>>>> working >>>>>>>>> group intends. >>>>>>>>> >>>>>>>>> But what do we intend? I will try to explain my >>>>>>>>> personal view, and see if that helps. >>>>>>>>> >>>>>>>>> In this regard, it is important to keep in mind that >>>>>>>>> what we are defining is the data plane architecture. >>>>>>>>> We are not attempting to define the architecture for >>>>>>>>> the entire solution for service chaining. That would >>>>>>>>> encompass OSS/BSS, various control and policy >>>>>>>>> functions, virtual machine and image management, and >>>>>>>>> many other aspects. >>>>>>>>> >>>>>>>>> As a result there are many things which clearly need >>>>>>>>> to exist in the larger system, but which are dealt >>>>>>>>> with above where we are >>>>> functioning, >>>>>>>>> and are not directly required by the work we are >>>>>>>>> doing. >>>>>>>>> >>>>>>>>> In order to get to service chain vs service path, as >>>>>>>>> I understand >>>>> them, >>>>>>>>> I need to first discuss load balancing. There are at >>>>>>>>> least three different ways that load balancing can >>>>>>>>> and will interact with service chaining. There >>>>>>>>> probably are more. The point of the archtiecture is >>>>>>>>> to permit all of these, but not to mandate that any >>>>>>>>> particular kind >>>>> be used >>>>>>>>> in any solution. >>>>>>>>> >>>>>>>>> 1) Load balancing as a service provided to the end >>>>>>>>> user. This is a service function. It receives user >>>>>>>>> packets, and modifies them (or >>>>> marks >>>>>>>>> them, or ...) so as to choose an end user service >>>>>>>>> instance to receive the users packet. This is an >>>>>>>>> important service function to be able to include in >>>>>>>>> service chaining. It's behavior may affect >>>>>>>>> requirements on how service chaining is done. But it >>>>>>>>> has very little impact on the archtiecture. From an >>>>>>>>> architectural pe3rspective it is simply a >>>>> service >>>>>>>>> function which may modify the underlying packet. >>>>>>>>> >>>>>>>>> 2) There is internal load balancing. That is, one can >>>>>>>>> have what >>>>> appears >>>>>>>>> to the service chaining architecture as a single >>>>>>>>> point of contact >>>>> for a >>>>>>>>> specific service function, but is actually delivered >>>>>>>>> by a >>>>> collection of >>>>>>>>> virtual or physical machines, possibly including one >>>>>>>>> or several load balancers (for example using >>>>>>>>> VRRP-like techniques to share a MAC address.) mostly, >>>>>>>>> this is invisible to the service chaining data plane >>>>>>>>> mechanisms. It is likely that it is visible to >>>>>>>>> various control mechanisms, such as those responsible >>>>>>>>> for scale-in, scale-out, and vm instantiation. The >>>>>>>>> architectural impact of permitting this is largely >>>>>>>>> that we need to be careful that our terminology does >>>>>>>>> not lead >>>>> readers to >>>>>>>>> think we are prohibiting it. >>>>>>>>> >>>>>>>>> 3) There can also be load balancing done by >>>>>>>>> selecting packet paths for the service chaining that >>>>>>>>> direct traffic to different places. We would not want >>>>>>>>> to require that a given service function appear at >>>>>>>>> only one place in the network. >>>>>>>>> >>>>>>>>> It is of course the case that these may be combined. >>>>>>>>> I tend to >>>>> refer to >>>>>>>>> the collection of entities that appear to service >>>>>>>>> chaining as a single point as a cluster. Not because >>>>>>>>> cluster is a good term. But because I do not have >>>>>>>>> another one. Thus, the point of type 3 load >>>>>>>>> balancing >>>>> is to >>>>>>>>> direct different subsets of traffic to different >>>>>>>>> singular or clustered service functions in different >>>>>>>>> places in the network. >>>>>>>>> >>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>> service chain and service path/ Service chain is a >>>>>>>>> sequence of logical functions to be applied to a >>>>>>>>> subset of packets. It is equivalent of saying that >>>>>>>>> some subset of traffic is to get DPI, charging, >>>>>>>>> content inspection, and firewall while a different >>>>>>>>> subset is to go directly to the cache >>>>> without >>>>>>>>> visiting any other service functions. >>>>>>>>> >>>>>>>>> That is not enough information to direct the packets. >>>>>>>>> A service path is, in some fashion, a sequence of >>>>>>>>> locations in the network. Those locations will be >>>>>>>>> singular or clustered service function delivery >>>>>>>>> locations. They may be addressed by IP address. They >>>>>>>>> may be addressed as ports on an SFF. There are many >>>>>>>>> different ways that the locations may be known to the >>>>>>>>> service chaining infrastructure and the transport. >>>>>>>>> >>>>>>>>>> From the point of view of the work of the SFC >>>>>>>>>> group, we need to be >>>>>>>>> able to talk about the high level abstraction, the >>>>>>>>> service chain, which drives the forwarding. And we >>>>>>>>> need to talk about the actual data path packets will >>>>>>>>> take in the network. >>>>>>>>> >>>>>>>>> Several of the comments have said "but the whole path >>>>>>>>> may not be known at the front." This architecture >>>>>>>>> deals with that issue in two ways. First, as noted in >>>>>>>>> item (2) on load balancers above, there can be >>>>>>>>> decisions and behaviors which are invisible to the >>>>>>>>> service chaining mechanisms (in much the same way >>>>>>>>> that bridging within a LAN is largely invisible to >>>>>>>>> routing between LANs.) The other provision we make >>>>>>>>> is >>>>> that >>>>>>>>> reclassification can be done in mid-chain when >>>>>>>>> necessary. That will direct packets to a new chain. >>>>>>>>> Based on information available at the >>>>>>>>> re-classification point. >>>>>>>>> >>>>>>>>> I hope that this helps explain what we are after. If >>>>>>>>> it does, and if the intent is acceptable to the >>>>>>>>> working group, we can figure out what additional >>>>>>>>> words are needed to convey this. If the working group >>>>>>>>> disagree with the intent, then we will of course >>>>>>>>> adjust to match the working group agreements. If this >>>>>>>>> is still unclear, I am not sure what to try next. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing >>>> 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 Jul 11 05:40: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 3C1E11A0080 for ; Fri, 11 Jul 2014 05:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K8_UccGI9J0V for ; Fri, 11 Jul 2014 05:40:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684441B2817 for ; Fri, 11 Jul 2014 05:40:30 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 3C2783B4CB2; Fri, 11 Jul 2014 14:40:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1BAA1384049; Fri, 11 Jul 2014 14:40:28 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 14:40:27 +0200 From: To: "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPnQC3tSqAftugz0CPuFwsDNNeGpuazuow Date: Fri, 11 Jul 2014 12:40:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> In-Reply-To: <53BFD38E.2080102@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.11.103319 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XCrRFYN3fZolTrEMxqFPM_0sXJI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:40:36 -0000 Joel, The architecture has to make NO assumptions on the actual configuration/beh= avior of SFFs (whether none, some, or all of them are stateful, flow-aware = co-located with LBs/etc.). This is deployment-specific. Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: vendredi 11 juillet 2014 14:08 >=C0=A0: Ron Parker; sfc@ietf.org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >And it was pointed out to me that I made a two letter major typo. > >I was trying to say that I felt that such a requirement on all SFF would >be an UNacceptable imposition. > >Yours, >Joel > >On 7/10/14, 11:53 PM, Joel M. Halpern wrote: >> Ron, thinking about this, I realized another major problem with the your >> proposal as I understand it. (And I readily admit I may not understand >> it.) >> >> The proposal has each SFF serve as the load balancer for the next >> service function that follows it (not the one it delivers to), in every >> service chain that goes through it. >> >> Since it has to be able to work with all services, that means that every >> SFF would have to be a full, flow sensitive and stateful load balancer. >> I ahve no problem if some SFF are flow sensitive, and / or stateful. But >> having the architecture require that every SFF be a full, flow >> sensitive, stateful, load balancer seems to me to be an acceptable >> imposition. >> >> Yours, >> Joel >> >> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>> Part of my personal view is that I am trying to make this work sensibly >>> in a more orchestrated environment. I expect that the service >>> functions, and over time probably the SFF capabilities, will be >>> orchestrated and installed. I expect the service chains to be driven b= y >>> BSS tools that define offerings to clients, and enable self-selection >>> from these. I expect service paths to be heavily policy drive. >>> >>> I can see how to make all of that work in an archtiecture driven by >>> initial classification to described service paths. It is harder to see >>> how to make it work (but it can be done) when we allow more dynamicity >>> in the network behavior. >>> >>> Having said that, most of that perspective I described is outside of th= e >>> scope of the working group. it is not something we are tasked to >>> agree on. >>> So I do not claim that vision means we have to do it a certain way. it >>> is just the perspective that drives my preferences. >>> >>> Yours, >>> Joel >>> >>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>> For me, the amount of information about service instances that needs >to >>>>> be widely distributed and maintained, potentially even across data >>>>> centers within an administrative scope, is large enough and complex >>>>> enough that trying to get that into each SFF seems like a difficult >>>>> architecture to realize. >>>> >>>> I'm curious as to why that is more complicated than dynamic routing, >>>> hyper-scale data center orchestration, or DNS, all of which are bigger >>>> problems that have been profitably and stably implemented? >>>> >>>> It also seems that if it really is more complicated, that is a good >>>> sign that it is too complicated. >>>> >>>> ________________________________________ >>>> From: Joel M. Halpern [jmh@joelhalpern.com] >>>> Sent: Thursday, July 10, 2014 9:45 PM >>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> This is an architectural issue. And one that I would prefer we >actually >>>> decide, rather than trying to allow all possible implementations. >>>> Because it does have a major effect on the control requirements and th= e >>>> functionality of SFFs. >>>> >>>> For me, the amount of information about service instances that needs t= o >>>> be widely distributed and maintained, potentially even across data >>>> centers within an administrative scope, is large enough and complex >>>> enough that trying to get that into each SFF seems like a difficult >>>> architecture to realize. >>>> >>>> Yours, >>>> Joel >>>> >>>> But it is a fair question. >>>> >>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>> This is the crux of my issue. Is the end to end selection of >>>>> (top-level) instances performed centrally (perhaps by the classifier) >>>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>>>> Such selection is not equivalent to reclassification. And surely, >>>>> this is an architectural issue and not relegated to >>>>> "implementation". >>>>> >>>>> My own view is to favor the distributed approach even though a >>>>> greater amount of data (chain definitions and perhaps local selection >>>>> policy) is required at those distributed decision points. This >>>>> approach does not require an end-to-end path id at all. My >>>>> rationale for favoring this approach is primarily driven by increased >>>>> resiliency over the global path id approach. With a global path id >>>>> approach, consider failure of an instance and needing to alter the >>>>> global path ID table for each and every affected end-to-end path. >>>>> >>>>> Ron >>>>> >>>>> ________________________________________ From: sfc >>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> The way the architecture models the case of SF1 needing to influence >>>>> the chain is that one would do reclassification at the exit from >>>>> SF1. >>>>> >>>>> Part of the goal is to keep the different functions logically >>>>> separate so that solutions can clearly describe how they choose to >>>>> compose them for "service" delivery. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>> I don't see anything in the arch draft that suggests any sort of >>>>>> limit. However, it does seem to indicate that the entire path (all >>>>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>>>> either at the classifier or maybe the classifier chooses a SF Chain >>>>>> and the NF or at the latest the first SFF. In any case, the >>>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>>>> determined at the SFI(n-1) hop. According to the draft, this >>>>>> behavior would be considered "branching" to a new SFP as opposed to >>>>>> choosing and then forwarding to the selected instance of the >>>>>> next-hop of the current SFC. >>>>>> >>>>>> draft-merged-sfc-architecture-00: >>>>>>> When an SFC is instantiated into the network it is necessary to >>>>>>> select the specific instances of SFs that will be used, and to >>>>>>> create the service topology for that SFC using SF's network >>>>>>> locator. Thus, instantiation of the SFC results in the creation >>>>>>> of a Service Function Path (SFP) and is used for forwarding >>>>>>> packets through the SFC. In other words, an SFP is the >>>>>>> instantiation of the defined SFC. >>>>>>> >>>>>>> The SFC architecture supports reclassification (or non-initial >>>>>>> classification) as well. As packets traverse an SFP, >>>>>>> reclassification may occur - typically performed by a >>>>>>> classification function co-resident with a service function. >>>>>>> Reclassification may result in the selection of a new SFP, an >>>>>>> update of the associated metadata, or both. This is referred to >>>>>>> as "branching". >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------= - >--- >>>>>> >>>>>> >>>>>> >>>>>> >>>> *From: *I.Smith@F5.com >>>>>> *To: *Joel Halpern Direct,Joel M. >>>>>> >Halpern,huang@sce.carleton.ca,= s >fc@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> >>>> *Sent: *Thursday, July 10, 2014 >>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> Actually, I think I am disagreeing. >>>>>> >>>>>> If the possibility of medium-scale deployments (and that is what >>>>>> 16 million flows is in my world) of service chains is preconceived >>>>>> as an absurd idea, then the architecture burdened with that >>>>>> preconception. >>>>>> >>>>>> There has to be some point of aim, some degree of aspiration to >>>>>> scale that is appropriate for the lifespan of the architecture - >>>>>> you don't have to know what it is, but by saying that an arbitrary >>>>>> number is "too far", you're creating - even if it isn't intentional >>>>>> - a limit that influences decisions that have lasting impacts >>>>>> regarding scale-out, failure mitigation, elasticity, address >>>>>> space... all kinds of things. That is a problem I'm not >>>>>> particularly eager to deal with. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> >>>>>> >>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>>>> Chains, Paths, and Load Balancers >>>>>> >>>>>> Ian, I don't think you disagree with me at all in this regard. I am >>>>>> not requesting the the architecture or the solution prohibit >>>>>> deployments in the specific fashion. I am objecting to Huang's >>>>>> reading of my note as saying that such deployments are required >>>>>> they by the archtiecture. >>>>>> >>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>> things. Whether they are a good idea or not depends upon many >>>>>> factors outside of the scope of the WG. I happen to think that they >>>>>> are usually a bad idea. >>>>>> >>>>>> But the archtiecture si carefully avoiding attempting to know what >>>>>> is and is not eployable. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>> I disagree. >>>>>>> >>>>>>> We routinely have stateful devices that manage tens of millions >>>>>>> of >>>>>> concurrent flows in both access network and data center >>>>>> environments today. You can't seriously believe that in the >>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>>>> to have small numbers of service chains with equally small numbers >>>>>> of active service paths? >>>>>>> >>>>>>> Your sounds too much like "no one will ever need more than 64K" >>>>>>> for >>>>>> comfort. >>>>>>> >>>>>>> >>>>>>> ________________________________________ From: sfc >>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>> [jmh@joelhalpern.com] >>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>> Balancers >>>>>>> >>>>>>> No, it will mean that if someone tries to deploy the archtieture >>>>>>> particularly badly, they will exceed the limits of their >>>>>>> devices. The architecture does not require such absurd use of >>>>>>> service paths. Since I can not figure out how to write >>>>>>> architectural words to prohibit it, the architecture does permit >>>>>>> such abuse. >>>>>>> >>>>>>> Please do not read my saying that the archtiecture permits >>>>>>> something as saying it is either deisred or required by the work. >>>>>>> It isn't. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>>>> core router. >>>>>>>> >>>>>>>> Chang >>>>>>>> >>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>>> operators are prepared for the complexities if they choose to >>>>>>>>> avoid any use of local load balancing and in stead provision >>>>>>>>> 160,000 service paths. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> Paul, >>>>>>>>>> >>>>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>>>> chain with 20 instances at each hop? >>>>>>>>>> >>>>>>>>>> Maria >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>>>> Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Lucy, >>>>>>>>>> >>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>> forwarding. I'd >>>>>> make >>>>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>>>> the needed forwarding and associated transport. >>>>>>>>>> >>>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>>> hop(s). >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>>>> >>>>>>>>>> Lucy >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>> *Sent:*Thursday, July >>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>> ;sfc@ietf.org >>>>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>>>> Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Re-, >>>>>>>>>> >>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>>> forwarding actions. >>>>>>>>>> >>>>>>>>>> Requiring a SFC system to have the full knowledge of every >>>>>> available SFC >>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>> required/justified >>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>> >>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>> information >>>>>> that will >>>>>>>>>> be present in all deployments: that is the one required to >>>>>>>>>> structure a service chain. How that information is used to >>>>>>>>>> infer forwarding >>>>>> actions >>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Med >>>>>>>>>> >>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>> de*mikebianc@aol.com >>>>>>>>>> *Envoy=E9 :*mercredi 9 juillet >>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >>>>>>>>>> ;sfc@ietf.org >>>>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>>>> Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>>>> and SF >>>>>> Path? >>>>>>>>>> Other than clarifying the definition so that it's clear to >>>>>> those not >>>>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>>>> these terms. >>>>>>>>>> >>>>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>>>> of the SFC Header >>>>>> should >>>>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>>>> path and the choice of chain or >>>>>> path to >>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>> >>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>>> >>>>>>>>>> >>>>>> --------------------------------------------------------------------= - >--- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>> > >>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>> > *Sent:*Tuesday, July >>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>>> Balancers >>>>>>>>>> >>>>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>>>> number of comments that have been made about the proposed >>>>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>>>> wording so that readers who have not participated in the WG >>>>>>>>>> discussion will understnd it the way the >>>>>> working >>>>>>>>>> group intends. >>>>>>>>>> >>>>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>>>> view, and see if that helps. >>>>>>>>>> >>>>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>>>> attempting to define the architecture for the entire >>>>>>>>>> solution for service chaining. That would encompass >>>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>>> machine and image management, and many other aspects. >>>>>>>>>> >>>>>>>>>> As a result there are many things which clearly need to >>>>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>>>> where we are >>>>>> functioning, >>>>>>>>>> and are not directly required by the work we are doing. >>>>>>>>>> >>>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>>> understand >>>>>> them, >>>>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>>>> three different ways that load balancing can and will >>>>>>>>>> interact with service chaining. There probably are more. >>>>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>>>> but not to mandate that any particular kind >>>>>> be used >>>>>>>>>> in any solution. >>>>>>>>>> >>>>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>>>> This is a service function. It receives user packets, and >>>>>>>>>> modifies them (or >>>>>> marks >>>>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>>>> to receive the users packet. This is an important service >>>>>>>>>> function to be able to include in service chaining. It's >>>>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>>>> From an architectural pe3rspective it is simply a >>>>>> service >>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>> >>>>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>>>> what >>>>>> appears >>>>>>>>>> to the service chaining architecture as a single point of >>>>>>>>>> contact >>>>>> for a >>>>>>>>>> specific service function, but is actually delivered by a >>>>>> collection of >>>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>>>> is largely that we need to be careful that our terminology >>>>>>>>>> does not lead >>>>>> readers to >>>>>>>>>> think we are prohibiting it. >>>>>>>>>> >>>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>>>> to different places. We would not want to require that a >>>>>>>>>> given service function appear at only one place in the >>>>>>>>>> network. >>>>>>>>>> >>>>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>>>> to >>>>>> refer to >>>>>>>>>> the collection of entities that appear to service chaining >>>>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>>>> point of type 3 load balancing >>>>>> is to >>>>>>>>>> direct different subsets of traffic to different singular >>>>>>>>>> or clustered service functions in different places in the >>>>>>>>>> network. >>>>>>>>>> >>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>>> while a different subset is to go directly to the cache >>>>>> without >>>>>>>>>> visiting any other service functions. >>>>>>>>>> >>>>>>>>>> That is not enough information to direct the packets. A >>>>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>>>> in the network. Those locations will be singular or >>>>>>>>>> clustered service function delivery locations. They may be >>>>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>>>> an SFF. There are many different ways that the locations >>>>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>>>> transport. >>>>>>>>>> >>>>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>>>> need to be >>>>>>>>>> able to talk about the high level abstraction, the service >>>>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>>>> about the actual data path packets will take in the >>>>>>>>>> network. >>>>>>>>>> >>>>>>>>>> Several of the comments have said "but the whole path may >>>>>>>>>> not be known at the front." This architecture deals with >>>>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>>>> make is >>>>>> that >>>>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>>> information available at the re-classification point. >>>>>>>>>> >>>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>>>> we can figure out what additional words are needed to >>>>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>>>> then we will of course adjust to match the working group >>>>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>>>> try next. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing list >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 11 05:42: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 AF74A1A0AAE for ; Fri, 11 Jul 2014 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnkOB9MOvbsW for ; Fri, 11 Jul 2014 05:42:19 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0431A0080 for ; Fri, 11 Jul 2014 05:42:18 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id aabdfb35.2b9942c9d940.4549002.00-2451.12602874.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:42:18 +0000 (UTC) X-MXL-Hash: 53bfdbaa552b95a7-c85e05b0b10c14a4e3ea10963815442210d4607b Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 7abdfb35.0.4548974.00-2206.12602791.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:42:16 +0000 (UTC) X-MXL-Hash: 53bfdba8100b9449-f297442648927f7d63ffd5ebc28d5d9e1b8dc2db Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCgETR013730; Fri, 11 Jul 2014 08:42:14 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCg6Zm013632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 08:42:08 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 12:41:54 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 08:41:54 -0400 From: "NAPIERALA, MARIA H" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAihoAgAAJJ4D//71DIA== Date: Fri, 11 Jul 2014 12:41:54 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AB79@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=EbcUL] X-AnalysisOut: [6zdT0JMlHM-XXYA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oA] X-AnalysisOut: [XR_kdF8uMA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=1qBuAwTLMjCSAPCM:21 a=71CNHS3mUkggkUcw:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yBsh0oaqdjXqqYQjudeCwsEAth8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:42:24 -0000 Absolutely correct. Maria > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Friday, July 11, 2014 8:40 AM > To: Joel M. Halpern; Ron Parker; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Joel, >=20 > The architecture has to make NO assumptions on the actual > configuration/behavior of SFFs (whether none, some, or all of them are > stateful, flow-aware co-located with LBs/etc.). This is deployment-specif= ic. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >Envoy=E9=A0: vendredi 11 juillet 2014 14:08 > >=C0=A0: Ron Parker; sfc@ietf.org > >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > > > >And it was pointed out to me that I made a two letter major typo. > > > >I was trying to say that I felt that such a requirement on all SFF would > >be an UNacceptable imposition. > > > >Yours, > >Joel > > > >On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > >> Ron, thinking about this, I realized another major problem with the yo= ur > >> proposal as I understand it. (And I readily admit I may not understan= d > >> it.) > >> > >> The proposal has each SFF serve as the load balancer for the next > >> service function that follows it (not the one it delivers to), in ever= y > >> service chain that goes through it. > >> > >> Since it has to be able to work with all services, that means that eve= ry > >> SFF would have to be a full, flow sensitive and stateful load balancer= . > >> I ahve no problem if some SFF are flow sensitive, and / or stateful. B= ut > >> having the architecture require that every SFF be a full, flow > >> sensitive, stateful, load balancer seems to me to be an acceptable > >> imposition. > >> > >> Yours, > >> Joel > >> > >> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >>> Part of my personal view is that I am trying to make this work sensib= ly > >>> in a more orchestrated environment. I expect that the service > >>> functions, and over time probably the SFF capabilities, will be > >>> orchestrated and installed. I expect the service chains to be driven= by > >>> BSS tools that define offerings to clients, and enable self-selection > >>> from these. I expect service paths to be heavily policy drive. > >>> > >>> I can see how to make all of that work in an archtiecture driven by > >>> initial classification to described service paths. It is harder to s= ee > >>> how to make it work (but it can be done) when we allow more > dynamicity > >>> in the network behavior. > >>> > >>> Having said that, most of that perspective I described is outside of = the > >>> scope of the working group. it is not something we are tasked to > >>> agree on. > >>> So I do not claim that vision means we have to do it a certain way. = it > >>> is just the perspective that drives my preferences. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>>> For me, the amount of information about service instances that > needs > >to > >>>>> be widely distributed and maintained, potentially even across data > >>>>> centers within an administrative scope, is large enough and complex > >>>>> enough that trying to get that into each SFF seems like a difficult > >>>>> architecture to realize. > >>>> > >>>> I'm curious as to why that is more complicated than dynamic routing, > >>>> hyper-scale data center orchestration, or DNS, all of which are bigg= er > >>>> problems that have been profitably and stably implemented? > >>>> > >>>> It also seems that if it really is more complicated, that is a good > >>>> sign that it is too complicated. > >>>> > >>>> ________________________________________ > >>>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>>> Sent: Thursday, July 10, 2014 9:45 PM > >>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >>>> sfc@ietf.org > >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> This is an architectural issue. And one that I would prefer we > >actually > >>>> decide, rather than trying to allow all possible implementations. > >>>> Because it does have a major effect on the control requirements and > the > >>>> functionality of SFFs. > >>>> > >>>> For me, the amount of information about service instances that needs > to > >>>> be widely distributed and maintained, potentially even across data > >>>> centers within an administrative scope, is large enough and complex > >>>> enough that trying to get that into each SFF seems like a difficult > >>>> architecture to realize. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> But it is a fair question. > >>>> > >>>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>>> This is the crux of my issue. Is the end to end selection of > >>>>> (top-level) instances performed centrally (perhaps by the classifie= r) > >>>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)= ? > >>>>> Such selection is not equivalent to reclassification. And surely, > >>>>> this is an architectural issue and not relegated to > >>>>> "implementation". > >>>>> > >>>>> My own view is to favor the distributed approach even though a > >>>>> greater amount of data (chain definitions and perhaps local selecti= on > >>>>> policy) is required at those distributed decision points. This > >>>>> approach does not require an end-to-end path id at all. My > >>>>> rationale for favoring this approach is primarily driven by increas= ed > >>>>> resiliency over the global path id approach. With a global path i= d > >>>>> approach, consider failure of an instance and needing to alter the > >>>>> global path ID table for each and every affected end-to-end path. > >>>>> > >>>>> Ron > >>>>> > >>>>> ________________________________________ From: sfc > >>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > >>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > >>>>> [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> The way the architecture models the case of SF1 needing to influenc= e > >>>>> the chain is that one would do reclassification at the exit from > >>>>> SF1. > >>>>> > >>>>> Part of the goal is to keep the different functions logically > >>>>> separate so that solutions can clearly describe how they choose to > >>>>> compose them for "service" delivery. > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>>> I don't see anything in the arch draft that suggests any sort of > >>>>>> limit. However, it does seem to indicate that the entire path (all > >>>>>> SFIs) must be chosen at SFC instantiation. I believe this means > >>>>>> either at the classifier or maybe the classifier chooses a SF Chai= n > >>>>>> and the NF or at the latest the first SFF. In any case, the > >>>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is > >>>>>> determined at the SFI(n-1) hop. According to the draft, this > >>>>>> behavior would be considered "branching" to a new SFP as opposed > to > >>>>>> choosing and then forwarding to the selected instance of the > >>>>>> next-hop of the current SFC. > >>>>>> > >>>>>> draft-merged-sfc-architecture-00: > >>>>>>> When an SFC is instantiated into the network it is necessary to > >>>>>>> select the specific instances of SFs that will be used, and to > >>>>>>> create the service topology for that SFC using SF's network > >>>>>>> locator. Thus, instantiation of the SFC results in the creation > >>>>>>> of a Service Function Path (SFP) and is used for forwarding > >>>>>>> packets through the SFC. In other words, an SFP is the > >>>>>>> instantiation of the defined SFC. > >>>>>>> > >>>>>>> The SFC architecture supports reclassification (or non-initial > >>>>>>> classification) as well. As packets traverse an SFP, > >>>>>>> reclassification may occur - typically performed by a > >>>>>>> classification function co-resident with a service function. > >>>>>>> Reclassification may result in the selection of a new SFP, an > >>>>>>> update of the associated metadata, or both. This is referred to > >>>>>>> as "branching". > >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------= --- > >--- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> *From: *I.Smith@F5.com > >>>>>> *To: *Joel Halpern Direct,Joel M. > >>>>>> > >Halpern,huang@sce.carleton.ca ton.ca>,s > >fc@ietf.org > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> *Sent: *Thursday, July 10, 2014 > >>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>> > >>>>>> Actually, I think I am disagreeing. > >>>>>> > >>>>>> If the possibility of medium-scale deployments (and that is what > >>>>>> 16 million flows is in my world) of service chains is preconceived > >>>>>> as an absurd idea, then the architecture burdened with that > >>>>>> preconception. > >>>>>> > >>>>>> There has to be some point of aim, some degree of aspiration to > >>>>>> scale that is appropriate for the lifespan of the architecture - > >>>>>> you don't have to know what it is, but by saying that an arbitrary > >>>>>> number is "too far", you're creating - even if it isn't intentiona= l > >>>>>> - a limit that influences decisions that have lasting impacts > >>>>>> regarding scale-out, failure mitigation, elasticity, address > >>>>>> space... all kinds of things. That is a problem I'm not > >>>>>> particularly eager to deal with. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ________________________________________ > >>>>>> > >>>>>> > >>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>>>>> Chains, Paths, and Load Balancers > >>>>>> > >>>>>> Ian, I don't think you disagree with me at all in this regard. I a= m > >>>>>> not requesting the the architecture or the solution prohibit > >>>>>> deployments in the specific fashion. I am objecting to Huang's > >>>>>> reading of my note as saying that such deployments are required > >>>>>> they by the archtiecture. > >>>>>> > >>>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>>> things. Whether they are a good idea or not depends upon many > >>>>>> factors outside of the scope of the WG. I happen to think that the= y > >>>>>> are usually a bad idea. > >>>>>> > >>>>>> But the archtiecture si carefully avoiding attempting to know what > >>>>>> is and is not eployable. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>>> I disagree. > >>>>>>> > >>>>>>> We routinely have stateful devices that manage tens of millions > >>>>>>> of > >>>>>> concurrent flows in both access network and data center > >>>>>> environments today. You can't seriously believe that in the > >>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > going > >>>>>> to have small numbers of service chains with equally small numbers > >>>>>> of active service paths? > >>>>>>> > >>>>>>> Your sounds too much like "no one will ever need more than 64K" > >>>>>>> for > >>>>>> comfort. > >>>>>>> > >>>>>>> > >>>>>>> ________________________________________ From: sfc > >>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>>> [jmh@joelhalpern.com] > >>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; > >>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load > >>>>>>> Balancers > >>>>>>> > >>>>>>> No, it will mean that if someone tries to deploy the archtieture > >>>>>>> particularly badly, they will exceed the limits of their > >>>>>>> devices. The architecture does not require such absurd use of > >>>>>>> service paths. Since I can not figure out how to write > >>>>>>> architectural words to prohibit it, the architecture does permit > >>>>>>> such abuse. > >>>>>>> > >>>>>>> Please do not read my saying that the archtiecture permits > >>>>>>> something as saying it is either deisred or required by the work. > >>>>>>> It isn't. > >>>>>>> > >>>>>>> Yours, Joel > >>>>>>> > >>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>>> If you need to support 100 service chains, it will mean > >>>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>>>>>>> core router. > >>>>>>>> > >>>>>>>> Chang > >>>>>>>> > >>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>>> service path to 160000 service paths. I would hope that > >>>>>>>>> operators are prepared for the complexities if they choose to > >>>>>>>>> avoid any use of local load balancing and in stead provision > >>>>>>>>> 160,000 service paths. > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>> Paul, > >>>>>>>>>> > >>>>>>>>>> How many path identifiers there will be for a 4 hop service > >>>>>>>>>> chain with 20 instances at each hop? > >>>>>>>>>> > >>>>>>>>>> Maria > >>>>>>>>>> > >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>> > >>>>>>>>>> Lucy, > >>>>>>>>>> > >>>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>>> forwarding. I'd > >>>>>> make > >>>>>>>>>> the minor change: the path identifier can be used to derive > >>>>>>>>>> the needed forwarding and associated transport. > >>>>>>>>>> > >>>>>>>>>> It is _not_ the transport, but rather is used to simply > >>>>>>>>>> identify the service path (or graph) that packets must > >>>>>>>>>> traverse. By having a path identifier, the exact > >>>>>>>>>> indirection that people seem to be asking for on this > >>>>>>>>>> thread can be simply be implemented. The path identifier > >>>>>>>>>> provides nothing more than a lookup, that lookup can result > >>>>>>>>>> in a one or more (equal or weighted) transport next > >>>>>>>>>> hop(s). > >>>>>>>>>> > >>>>>>>>>> Paul > >>>>>>>>>> > >>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>>> > > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>>>>>>>>> service path identifier to drive the forwarding actions. > >>>>>>>>>> > >>>>>>>>>> Lucy > >>>>>>>>>> > >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>>> *Sent:*Thursday, > July > >>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>> > >>>>>>>>>> Re-, > >>>>>>>>>> > >>>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>>> identifier. I object to use that identifier to derive > >>>>>>>>>> forwarding actions. > >>>>>>>>>> > >>>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>>>>> available SFC > >>>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>>> required/justified > >>>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>>> > >>>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>>> information > >>>>>> that will > >>>>>>>>>> be present in all deployments: that is the one required to > >>>>>>>>>> structure a service chain. How that information is used to > >>>>>>>>>> infer forwarding > >>>>>> actions > >>>>>>>>>> is a solution-oriented discussion. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> > >>>>>>>>>> Med > >>>>>>>>>> > >>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>>> de*mikebianc@aol.com > >>>>>>>>>> *Envoy=E9 :*mercredi 9 juillet > >>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>> > >>>>>>>>>> Is anyone still questioning the difference between SF Chain > >>>>>>>>>> and SF > >>>>>> Path? > >>>>>>>>>> Other than clarifying the definition so that it's clear to > >>>>>> those not > >>>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>>>>>>>>> these terms. > >>>>>>>>>> > >>>>>>>>>> To me, the one point that is still unclear is whether it is > >>>>>>>>>> the intent of this draft to ultimately specify what the ID > >>>>>>>>>> of the SFC Header > >>>>>> should > >>>>>>>>>> reference (the chain or the path), or if this draft simply > >>>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>>>>>>>>> path and the choice of chain or > >>>>>> path to > >>>>>>>>>> be negotiated in the control-plane. > >>>>>>>>>> > >>>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>>> require that both SFP and SFC be supported (or make one > >>>>>>>>>> required and the other optional) to avoid some vendors only > >>>>>>>>>> supporting SFP and others only supporting SFC. > >>>>>>>>>> > >>>>>>>>>> > >>>>>> ------------------------------------------------------------------= --- > >--- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> > >>>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>>> > > >>>>>>>>>> *To:*sfc@ietf.org >>>>>>>>>> > *Sent:*Tuesday, July > >>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>>>>>>>>> Balancers > >>>>>>>>>> > >>>>>>>>>> I have been trying to figure out how to clearly answer a > >>>>>>>>>> number of comments that have been made about the > proposed > >>>>>>>>>> merged archtiecture draft. Assuming we can get working > >>>>>>>>>> group agreement on the intent, we will work to improve the > >>>>>>>>>> wording so that readers who have not participated in the WG > >>>>>>>>>> discussion will understnd it the way the > >>>>>> working > >>>>>>>>>> group intends. > >>>>>>>>>> > >>>>>>>>>> But what do we intend? I will try to explain my personal > >>>>>>>>>> view, and see if that helps. > >>>>>>>>>> > >>>>>>>>>> In this regard, it is important to keep in mind that what > >>>>>>>>>> we are defining is the data plane architecture. We are not > >>>>>>>>>> attempting to define the architecture for the entire > >>>>>>>>>> solution for service chaining. That would encompass > >>>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>>>>>>>>> machine and image management, and many other aspects. > >>>>>>>>>> > >>>>>>>>>> As a result there are many things which clearly need to > >>>>>>>>>> exist in the larger system, but which are dealt with above > >>>>>>>>>> where we are > >>>>>> functioning, > >>>>>>>>>> and are not directly required by the work we are doing. > >>>>>>>>>> > >>>>>>>>>> In order to get to service chain vs service path, as I > >>>>>>>>>> understand > >>>>>> them, > >>>>>>>>>> I need to first discuss load balancing. There are at least > >>>>>>>>>> three different ways that load balancing can and will > >>>>>>>>>> interact with service chaining. There probably are more. > >>>>>>>>>> The point of the archtiecture is to permit all of these, > >>>>>>>>>> but not to mandate that any particular kind > >>>>>> be used > >>>>>>>>>> in any solution. > >>>>>>>>>> > >>>>>>>>>> 1) Load balancing as a service provided to the end user. > >>>>>>>>>> This is a service function. It receives user packets, and > >>>>>>>>>> modifies them (or > >>>>>> marks > >>>>>>>>>> them, or ...) so as to choose an end user service instance > >>>>>>>>>> to receive the users packet. This is an important service > >>>>>>>>>> function to be able to include in service chaining. It's > >>>>>>>>>> behavior may affect requirements on how service chaining is > >>>>>>>>>> done. But it has very little impact on the archtiecture. > >>>>>>>>>> From an architectural pe3rspective it is simply a > >>>>>> service > >>>>>>>>>> function which may modify the underlying packet. > >>>>>>>>>> > >>>>>>>>>> 2) There is internal load balancing. That is, one can have > >>>>>>>>>> what > >>>>>> appears > >>>>>>>>>> to the service chaining architecture as a single point of > >>>>>>>>>> contact > >>>>>> for a > >>>>>>>>>> specific service function, but is actually delivered by a > >>>>>> collection of > >>>>>>>>>> virtual or physical machines, possibly including one or > >>>>>>>>>> several load balancers (for example using VRRP-like > >>>>>>>>>> techniques to share a MAC address.) mostly, this is > >>>>>>>>>> invisible to the service chaining data plane mechanisms. It > >>>>>>>>>> is likely that it is visible to various control mechanisms, > >>>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>>>>>>>>> instantiation. The architectural impact of permitting this > >>>>>>>>>> is largely that we need to be careful that our terminology > >>>>>>>>>> does not lead > >>>>>> readers to > >>>>>>>>>> think we are prohibiting it. > >>>>>>>>>> > >>>>>>>>>> 3) There can also be load balancing done by selecting > >>>>>>>>>> packet paths for the service chaining that direct traffic > >>>>>>>>>> to different places. We would not want to require that a > >>>>>>>>>> given service function appear at only one place in the > >>>>>>>>>> network. > >>>>>>>>>> > >>>>>>>>>> It is of course the case that these may be combined. I tend > >>>>>>>>>> to > >>>>>> refer to > >>>>>>>>>> the collection of entities that appear to service chaining > >>>>>>>>>> as a single point as a cluster. Not because cluster is a > >>>>>>>>>> good term. But because I do not have another one. Thus, the > >>>>>>>>>> point of type 3 load balancing > >>>>>> is to > >>>>>>>>>> direct different subsets of traffic to different singular > >>>>>>>>>> or clustered service functions in different places in the > >>>>>>>>>> network. > >>>>>>>>>> > >>>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>>> service chain and service path/ Service chain is a sequence > >>>>>>>>>> of logical functions to be applied to a subset of packets. > >>>>>>>>>> It is equivalent of saying that some subset of traffic is > >>>>>>>>>> to get DPI, charging, content inspection, and firewall > >>>>>>>>>> while a different subset is to go directly to the cache > >>>>>> without > >>>>>>>>>> visiting any other service functions. > >>>>>>>>>> > >>>>>>>>>> That is not enough information to direct the packets. A > >>>>>>>>>> service path is, in some fashion, a sequence of locations > >>>>>>>>>> in the network. Those locations will be singular or > >>>>>>>>>> clustered service function delivery locations. They may be > >>>>>>>>>> addressed by IP address. They may be addressed as ports on > >>>>>>>>>> an SFF. There are many different ways that the locations > >>>>>>>>>> may be known to the service chaining infrastructure and the > >>>>>>>>>> transport. > >>>>>>>>>> > >>>>>>>>>>> From the point of view of the work of the SFC group, we > >>>>>>>>>>> need to be > >>>>>>>>>> able to talk about the high level abstraction, the service > >>>>>>>>>> chain, which drives the forwarding. And we need to talk > >>>>>>>>>> about the actual data path packets will take in the > >>>>>>>>>> network. > >>>>>>>>>> > >>>>>>>>>> Several of the comments have said "but the whole path may > >>>>>>>>>> not be known at the front." This architecture deals with > >>>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >>>>>>>>>> balancers above, there can be decisions and behaviors which > >>>>>>>>>> are invisible to the service chaining mechanisms (in much > >>>>>>>>>> the same way that bridging within a LAN is largely > >>>>>>>>>> invisible to routing between LANs.) The other provision we > >>>>>>>>>> make is > >>>>>> that > >>>>>>>>>> reclassification can be done in mid-chain when necessary. > >>>>>>>>>> That will direct packets to a new chain. Based on > >>>>>>>>>> information available at the re-classification point. > >>>>>>>>>> > >>>>>>>>>> I hope that this helps explain what we are after. If it > >>>>>>>>>> does, and if the intent is acceptable to the working group, > >>>>>>>>>> we can figure out what additional words are needed to > >>>>>>>>>> convey this. If the working group disagree with the intent, > >>>>>>>>>> then we will of course adjust to match the working group > >>>>>>>>>> agreements. If this is still unclear, I am not sure what to > >>>>>>>>>> try next. > >>>>>>>>>> > >>>>>>>>>> Yours, Joel > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>>> list sfc@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>>> list sfc@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > mailing list > >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ sfc mailing > list > >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ sfc mailing > list > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ sfc mailing > list > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Fri Jul 11 05:53: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 9CD0F1B2817 for ; Fri, 11 Jul 2014 05:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=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 8KHFgqaQtNJy for ; Fri, 11 Jul 2014 05:53:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2B21B288E for ; Fri, 11 Jul 2014 05:53:10 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1DC3218C974; Fri, 11 Jul 2014 14:53:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E9B0235C07E; Fri, 11 Jul 2014 14:53:08 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 14:53:04 +0200 From: To: Joel Halpern Direct , "Joel M. Halpern" , Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPnQTVtSqAftugz0CPuFwsDNNeGpua0ddQ Date: Fri, 11 Jul 2014 12:53:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330031500@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDA76.302@joelhalpern.com> In-Reply-To: <53BFDA76.302@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1kKZWQoLCw72YAnsv1F_c7iSxdU Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:53:14 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >Envoy=E9=A0: vendredi 11 juillet 2014 14:37 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Ian Smith; Ron Parker; >mikebianc@aol.com; sfc@ietf.org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >Med, several of your points are well-taken, and already allowed for in >the proposed architecture. > >However, I disagree with a couple of them in important ways. > >Path selection is not, from what I have seen, dynamic in nature. [Med] Really?! Given we are talking in this thread about path selection, I = will provide an example with it. A load balancing heuristic that dispatch t= he traffic among several instances that may not be reachable with the same = IP address is not more than a dynamic forwarding. When you put all these he= uristic that can be invoked in a forwarding path, you have a dynamic path s= election. Of course, these heuristics allows to same instance for subsequen= t flows matching the same criteria.=20 There >has been expressed repeatedly a requirement that all the packets of a >given flow go through the same service instances. Dynamic routing >simply does not do that. [Med] This is why I used in my initial message "dynamic path selection" and= not dynamic routing! > >More importantly, one of the goals of the archtiecture is to separate >service function concerns from the network service chaining concerns. >As such, service chaining policy is not the puriew of servie functions. > There are various ways that service functions can indicate that a >given set of packets (usually flow, but maybe subscriber, ...) should >get tied to a different service chain. But that is not the same as an >SF having policy about how the network delivers service chaining or >where it delivers packets to do that. > >And as has been said repeatedly, the archtiecture proposed does not >require that load balancing be done entirely at the central point. As >far as I can tell any solution compliant with the proposed archtiecture >allows for both centralized control of some traffic distribution, and >local load balancing within that. I would expect most deployments would >use both. [Med] It seems we are not reading the same document. I won't repeat what I = have mentioned in other messages. > >Yours, >Joel > > >On 7/11/14, 3:49 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >> >> This is one possible approach, but what several of us are trying to >> clarify is this is one approach among others, not possible in some >> contexts, more complex to ensure resiliency, etc. Below some of my >> concerns about your approach: >> >> (1) Having an entity that maintains a large set of service paths in a >> given domain is more like creating circuits...I thought distributed >> routing has shown its efficiency. (2) Policies are everywhere in the >> network , not only at the SFC structuring system. (3) Path selection >> is dynamic by nature because it depends on various heuristics and >> policies that are distributed in the network (including those of SFs >> and others). (4) Having a stateful function that maintains the full >> list of available paths may not be that resilient. This must assess >> frequently (very short cycle) valid and serviceable paths among >> available ones. Ensuring the same level of resilience would require >> additional features to be supported by to that entity maintaining the >> full set of path, and also SFs. (5) Load-balancing at a centralized >> entity is deployment-specific; as such it is not required nor >> possible in those contexts. Deciding the forwarding path a priori >> contradicts LB requirements. I know your answer about >> re-classification, but IMHO the architecture should not mandate an >> optional feature only because of some design choices. >> Re-classification should be avoided as much for the same of >> performance and also because this one of the complexity vector for >> this work. (6) There are a bunch of solutions that achieve >> differentiated forwarding without requiring a >> pre-computation/pre-determination of a path: think about ToS-based >> routing, multi-topology routing, etc. >> >> I could live with an optional capability that a path can be >> pre-determined, but this must not be the rule. >> >> Forwarding within an SFC-enabled domain is primarily inferred by the >> service function chain itself. How this information is used to drive >> forwarding actions is all about details. >> >> Cheers, Med >> >>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >>> De la part de Joel M. Halpern Envoy=E9 : vendredi 11 juillet 2014 >>> 04:06 =C0 : Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org >>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Part of my personal view is that I am trying to make this work >>> sensibly in a more orchestrated environment. I expect that the >>> service functions, and over time probably the SFF capabilities, >>> will be orchestrated and installed. I expect the service chains to >>> be driven by BSS tools that define offerings to clients, and enable >>> self-selection from these. I expect service paths to be heavily >>> policy drive. >>> >>> I can see how to make all of that work in an archtiecture driven >>> by initial classification to described service paths. It is harder >>> to see how to make it work (but it can be done) when we allow more >>> dynamicity in the network behavior. >>> >>> Having said that, most of that perspective I described is outside >>> of the scope of the working group. it is not something we are >>> tasked to agree on. So I do not claim that vision means we have to >>> do it a certain way. it is just the perspective that drives my >>> preferences. >>> >>> Yours, Joel >>> >>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>> For me, the amount of information about service instances that >>>>> needs to be widely distributed and maintained, potentially even >>>>> across data centers within an administrative scope, is large >>>>> enough and complex enough that trying to get that into each SFF >>>>> seems like a difficult architecture to realize. >>>> >>>> I'm curious as to why that is more complicated than dynamic >>>> routing, >>> hyper-scale data center orchestration, or DNS, all of which are >>> bigger problems that have been profitably and stably implemented? >>>> >>>> It also seems that if it really is more complicated, that is a >>>> good sign >>> that it is too complicated. >>>> >>>> ________________________________________ From: Joel M. Halpern >>>> [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: >>>> Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>> sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> This is an architectural issue. And one that I would prefer we >>>> actually decide, rather than trying to allow all possible >>>> implementations. Because it does have a major effect on the >>>> control requirements and the functionality of SFFs. >>>> >>>> For me, the amount of information about service instances that >>>> needs to be widely distributed and maintained, potentially even >>>> across data centers within an administrative scope, is large >>>> enough and complex enough that trying to get that into each SFF >>>> seems like a difficult architecture to realize. >>>> >>>> Yours, Joel >>>> >>>> But it is a fair question. >>>> >>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>> This is the crux of my issue. Is the end to end selection of >>>>> (top-level) instances performed centrally (perhaps by the >>>>> classifier) or hop-by-hop (perhaps by the classifier and >>>>> subsequently the SFFs)? Such selection is not equivalent to >>>>> reclassification. And surely, this is an architectural issue >>>>> and not relegated to "implementation". >>>>> >>>>> My own view is to favor the distributed approach even though a >>>>> greater amount of data (chain definitions and perhaps local >>>>> selection policy) is required at those distributed decision >>>>> points. This approach does not require an end-to-end path id >>>>> at all. My rationale for favoring this approach is primarily >>>>> driven by increased resiliency over the global path id >>>>> approach. With a global path id approach, consider failure of >>>>> an instance and needing to alter the global path ID table for >>>>> each and every affected end-to-end path. >>>>> >>>>> Ron >>>>> >>>>> ________________________________________ From: sfc >>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 >>>>> PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: >>>>> Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> The way the architecture models the case of SF1 needing to >>>>> influence the chain is that one would do reclassification at >>>>> the exit from SF1. >>>>> >>>>> Part of the goal is to keep the different functions logically >>>>> separate so that solutions can clearly describe how they choose >>>>> to compose them for "service" delivery. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>> I don't see anything in the arch draft that suggests any sort >>>>>> of limit. However, it does seem to indicate that the entire >>>>>> path (all SFIs) must be chosen at SFC instantiation. I >>>>>> believe this means either at the classifier or maybe the >>>>>> classifier chooses a SF Chain and the NF or at the latest the >>>>>> first SFF. In any case, the language does seem to prohibit a >>>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1) >>>>>> hop. According to the draft, this behavior would be >>>>>> considered "branching" to a new SFP as opposed to choosing >>>>>> and then forwarding to the selected instance of the next-hop >>>>>> of the current SFC. >>>>>> >>>>>> draft-merged-sfc-architecture-00: >>>>>>> When an SFC is instantiated into the network it is >>>>>>> necessary to select the specific instances of SFs that will >>>>>>> be used, and to create the service topology for that SFC >>>>>>> using SF's network locator. Thus, instantiation of the SFC >>>>>>> results in the creation of a Service Function Path (SFP) >>>>>>> and is used for forwarding packets through the SFC. In >>>>>>> other words, an SFP is the instantiation of the defined >>>>>>> SFC. >>>>>>> >>>>>>> The SFC architecture supports reclassification (or >>>>>>> non-initial classification) as well. As packets traverse >>>>>>> an SFP, reclassification may occur - typically performed by >>>>>>> a classification function co-resident with a service >>>>>>> function. Reclassification may result in the selection of a >>>>>>> new SFP, an update of the associated metadata, or both. >>>>>>> This is referred to as "branching". >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------= - >-- >>> >>>>>> >- >>>>>> >>>>>> >>>> *From: *I.Smith@F5.com >>>>>> *To: *Joel Halpern Direct,Joel >>>>>> M. >>>>>> >>> >Halpern,huang@sce.carleton.ca,= s >>> >>> >fc@ietf.org >>>>>> >>>>>> >>>> *Sent: *Thursday, July 10, 2014 >>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>>>>> Balancers >>>>>> >>>>>> Actually, I think I am disagreeing. >>>>>> >>>>>> If the possibility of medium-scale deployments (and that is >>>>>> what 16 million flows is in my world) of service chains is >>>>>> preconceived as an absurd idea, then the architecture >>>>>> burdened with that preconception. >>>>>> >>>>>> There has to be some point of aim, some degree of aspiration >>>>>> to scale that is appropriate for the lifespan of the >>>>>> architecture - you don't have to know what it is, but by >>>>>> saying that an arbitrary number is "too far", you're creating >>>>>> - even if it isn't intentional - a limit that influences >>>>>> decisions that have lasting impacts regarding scale-out, >>>>>> failure mitigation, elasticity, address space... all kinds of >>>>>> things. That is a problem I'm not particularly eager to deal >>>>>> with. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> >>>>>> >>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>>>>> Halpern; huang@sce.carleton.ca; sfc@ietf.org Subject: Re: >>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> Ian, I don't think you disagree with me at all in this >>>>>> regard. I am not requesting the the architecture or the >>>>>> solution prohibit deployments in the specific fashion. I am >>>>>> objecting to Huang's reading of my note as saying that such >>>>>> deployments are required they by the archtiecture. >>>>>> >>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>> things. Whether they are a good idea or not depends upon >>>>>> many factors outside of the scope of the WG. I happen to >>>>>> think that they are usually a bad idea. >>>>>> >>>>>> But the archtiecture si carefully avoiding attempting to know >>>>>> what is and is not eployable. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>> I disagree. >>>>>>> >>>>>>> We routinely have stateful devices that manage tens of >>>>>>> millions of >>>>>> concurrent flows in both access network and data center >>>>>> environments today. You can't seriously believe that in the >>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >>>>>> going to have small numbers of service chains with equally >>>>>> small numbers of active service paths? >>>>>>> >>>>>>> Your sounds too much like "no one will ever need more than >>>>>>> 64K" for >>>>>> comfort. >>>>>>> >>>>>>> >>>>>>> ________________________________________ From: sfc >>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>> [jmh@joelhalpern.com] >>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >>>>>>> Service Chains, Paths, and Load Balancers >>>>>>> >>>>>>> No, it will mean that if someone tries to deploy the >>>>>>> archtieture particularly badly, they will exceed the limits >>>>>>> of their devices. The architecture does not require such >>>>>>> absurd use of service paths. Since I can not figure out how >>>>>>> to write architectural words to prohibit it, the >>>>>>> architecture does permit such abuse. >>>>>>> >>>>>>> Please do not read my saying that the archtiecture permits >>>>>>> something as saying it is either deisred or required by the >>>>>>> work. It isn't. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>> 16,000,000 paths. That is larger than the routing table >>>>>>>> of a core router. >>>>>>>> >>>>>>>> Chang >>>>>>>> >>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>> service path to 160000 service paths. I would hope >>>>>>>>> that operators are prepared for the complexities if >>>>>>>>> they choose to avoid any use of local load balancing >>>>>>>>> and in stead provision 160,000 service paths. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>> Paul, >>>>>>>>>> >>>>>>>>>> How many path identifiers there will be for a 4 hop >>>>>>>>>> service chain with 20 instances at each hop? >>>>>>>>>> >>>>>>>>>> Maria >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10, >>>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:* >>>>>>>>>> jmh@joelhalpern.com; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org; mikebianc@aol.com *Subject:* Re: [sfc] >>>>>>>>>> Service Chains, Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Lucy, >>>>>>>>>> >>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>> forwarding. I'd >>>>>> make >>>>>>>>>> the minor change: the path identifier can be used to >>>>>>>>>> derive the needed forwarding and associated >>>>>>>>>> transport. >>>>>>>>>> >>>>>>>>>> It is _not_ the transport, but rather is used to >>>>>>>>>> simply identify the service path (or graph) that >>>>>>>>>> packets must traverse. By having a path identifier, >>>>>>>>>> the exact indirection that people seem to be asking >>>>>>>>>> for on this thread can be simply be implemented. The >>>>>>>>>> path identifier provides nothing more than a lookup, >>>>>>>>>> that lookup can result in a one or more (equal or >>>>>>>>>> weighted) transport next hop(s). >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Agree. The arch. doc should not mandate only use of >>>>>>>>>> the service path identifier to drive the forwarding >>>>>>>>>> actions. >>>>>>>>>> >>>>>>>>>> Lucy >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>> >>>>>>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>>>>>>>> *To:*mikebianc@aol.com >>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>> ;sfc@ietf.org >>>>>>>>>> *Subject:*Re: [sfc] Service >>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Re-, >>>>>>>>>> >>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>> identifier. I object to use that identifier to >>>>>>>>>> derive forwarding actions. >>>>>>>>>> >>>>>>>>>> Requiring a SFC system to have the full knowledge of >>>>>>>>>> every >>>>>> available SFC >>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>> required/justified >>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>> >>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>> information >>>>>> that will >>>>>>>>>> be present in all deployments: that is the one >>>>>>>>>> required to structure a service chain. How that >>>>>>>>>> information is used to infer forwarding >>>>>> actions >>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Med >>>>>>>>>> >>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>> de*mikebianc@aol.com >>>>>>>>>> *Envoy=E9 :*mercredi 9 >>>>>>>>>> juillet 2014 22:03 *=C0 :*jmh@joelhalpern.com >>>>>>>>>> ;sfc@ietf.org >>>>>>>>>> *Objet :*Re: [sfc] Service >>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>> >>>>>>>>>> Is anyone still questioning the difference between SF >>>>>>>>>> Chain and SF >>>>>> Path? >>>>>>>>>> Other than clarifying the definition so that it's >>>>>>>>>> clear to >>>>>> those not >>>>>>>>>> familiar with the draft, it seems that everyone >>>>>>>>>> agrees on these terms. >>>>>>>>>> >>>>>>>>>> To me, the one point that is still unclear is whether >>>>>>>>>> it is the intent of this draft to ultimately specify >>>>>>>>>> what the ID of the SFC Header >>>>>> should >>>>>>>>>> reference (the chain or the path), or if this draft >>>>>>>>>> simply intends to leave that ambiguous, allowing >>>>>>>>>> other drafts to dictate the mechanisms for forwarding >>>>>>>>>> based on chain or path and the choice of chain or >>>>>> path to >>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>> >>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>> require that both SFP and SFC be supported (or make >>>>>>>>>> one required and the other optional) to avoid some >>>>>>>>>> vendors only supporting SFP and others only >>>>>>>>>> supporting SFC. >>>>>>>>>> >>>>>>>>>> >>>>>> --------------------------------------------------------------------= - >-- >>> >>>>>> >- >>>>>> >>>>>> >>>>>>>> >>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>> > >>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>> > *Sent:*Tuesday, >>>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths, >>>>>>>>>> and Load Balancers >>>>>>>>>> >>>>>>>>>> I have been trying to figure out how to clearly >>>>>>>>>> answer a number of comments that have been made about >>>>>>>>>> the proposed merged archtiecture draft. Assuming we >>>>>>>>>> can get working group agreement on the intent, we >>>>>>>>>> will work to improve the wording so that readers who >>>>>>>>>> have not participated in the WG discussion will >>>>>>>>>> understnd it the way the >>>>>> working >>>>>>>>>> group intends. >>>>>>>>>> >>>>>>>>>> But what do we intend? I will try to explain my >>>>>>>>>> personal view, and see if that helps. >>>>>>>>>> >>>>>>>>>> In this regard, it is important to keep in mind that >>>>>>>>>> what we are defining is the data plane architecture. >>>>>>>>>> We are not attempting to define the architecture for >>>>>>>>>> the entire solution for service chaining. That would >>>>>>>>>> encompass OSS/BSS, various control and policy >>>>>>>>>> functions, virtual machine and image management, and >>>>>>>>>> many other aspects. >>>>>>>>>> >>>>>>>>>> As a result there are many things which clearly need >>>>>>>>>> to exist in the larger system, but which are dealt >>>>>>>>>> with above where we are >>>>>> functioning, >>>>>>>>>> and are not directly required by the work we are >>>>>>>>>> doing. >>>>>>>>>> >>>>>>>>>> In order to get to service chain vs service path, as >>>>>>>>>> I understand >>>>>> them, >>>>>>>>>> I need to first discuss load balancing. There are at >>>>>>>>>> least three different ways that load balancing can >>>>>>>>>> and will interact with service chaining. There >>>>>>>>>> probably are more. The point of the archtiecture is >>>>>>>>>> to permit all of these, but not to mandate that any >>>>>>>>>> particular kind >>>>>> be used >>>>>>>>>> in any solution. >>>>>>>>>> >>>>>>>>>> 1) Load balancing as a service provided to the end >>>>>>>>>> user. This is a service function. It receives user >>>>>>>>>> packets, and modifies them (or >>>>>> marks >>>>>>>>>> them, or ...) so as to choose an end user service >>>>>>>>>> instance to receive the users packet. This is an >>>>>>>>>> important service function to be able to include in >>>>>>>>>> service chaining. It's behavior may affect >>>>>>>>>> requirements on how service chaining is done. But it >>>>>>>>>> has very little impact on the archtiecture. From an >>>>>>>>>> architectural pe3rspective it is simply a >>>>>> service >>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>> >>>>>>>>>> 2) There is internal load balancing. That is, one can >>>>>>>>>> have what >>>>>> appears >>>>>>>>>> to the service chaining architecture as a single >>>>>>>>>> point of contact >>>>>> for a >>>>>>>>>> specific service function, but is actually delivered >>>>>>>>>> by a >>>>>> collection of >>>>>>>>>> virtual or physical machines, possibly including one >>>>>>>>>> or several load balancers (for example using >>>>>>>>>> VRRP-like techniques to share a MAC address.) mostly, >>>>>>>>>> this is invisible to the service chaining data plane >>>>>>>>>> mechanisms. It is likely that it is visible to >>>>>>>>>> various control mechanisms, such as those responsible >>>>>>>>>> for scale-in, scale-out, and vm instantiation. The >>>>>>>>>> architectural impact of permitting this is largely >>>>>>>>>> that we need to be careful that our terminology does >>>>>>>>>> not lead >>>>>> readers to >>>>>>>>>> think we are prohibiting it. >>>>>>>>>> >>>>>>>>>> 3) There can also be load balancing done by >>>>>>>>>> selecting packet paths for the service chaining that >>>>>>>>>> direct traffic to different places. We would not want >>>>>>>>>> to require that a given service function appear at >>>>>>>>>> only one place in the network. >>>>>>>>>> >>>>>>>>>> It is of course the case that these may be combined. >>>>>>>>>> I tend to >>>>>> refer to >>>>>>>>>> the collection of entities that appear to service >>>>>>>>>> chaining as a single point as a cluster. Not because >>>>>>>>>> cluster is a good term. But because I do not have >>>>>>>>>> another one. Thus, the point of type 3 load >>>>>>>>>> balancing >>>>>> is to >>>>>>>>>> direct different subsets of traffic to different >>>>>>>>>> singular or clustered service functions in different >>>>>>>>>> places in the network. >>>>>>>>>> >>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>> service chain and service path/ Service chain is a >>>>>>>>>> sequence of logical functions to be applied to a >>>>>>>>>> subset of packets. It is equivalent of saying that >>>>>>>>>> some subset of traffic is to get DPI, charging, >>>>>>>>>> content inspection, and firewall while a different >>>>>>>>>> subset is to go directly to the cache >>>>>> without >>>>>>>>>> visiting any other service functions. >>>>>>>>>> >>>>>>>>>> That is not enough information to direct the packets. >>>>>>>>>> A service path is, in some fashion, a sequence of >>>>>>>>>> locations in the network. Those locations will be >>>>>>>>>> singular or clustered service function delivery >>>>>>>>>> locations. They may be addressed by IP address. They >>>>>>>>>> may be addressed as ports on an SFF. There are many >>>>>>>>>> different ways that the locations may be known to the >>>>>>>>>> service chaining infrastructure and the transport. >>>>>>>>>> >>>>>>>>>>> From the point of view of the work of the SFC >>>>>>>>>>> group, we need to be >>>>>>>>>> able to talk about the high level abstraction, the >>>>>>>>>> service chain, which drives the forwarding. And we >>>>>>>>>> need to talk about the actual data path packets will >>>>>>>>>> take in the network. >>>>>>>>>> >>>>>>>>>> Several of the comments have said "but the whole path >>>>>>>>>> may not be known at the front." This architecture >>>>>>>>>> deals with that issue in two ways. First, as noted in >>>>>>>>>> item (2) on load balancers above, there can be >>>>>>>>>> decisions and behaviors which are invisible to the >>>>>>>>>> service chaining mechanisms (in much the same way >>>>>>>>>> that bridging within a LAN is largely invisible to >>>>>>>>>> routing between LANs.) The other provision we make >>>>>>>>>> is >>>>>> that >>>>>>>>>> reclassification can be done in mid-chain when >>>>>>>>>> necessary. That will direct packets to a new chain. >>>>>>>>>> Based on information available at the >>>>>>>>>> re-classification point. >>>>>>>>>> >>>>>>>>>> I hope that this helps explain what we are after. If >>>>>>>>>> it does, and if the intent is acceptable to the >>>>>>>>>> working group, we can figure out what additional >>>>>>>>>> words are needed to convey this. If the working group >>>>>>>>>> disagree with the intent, then we will of course >>>>>>>>>> adjust to match the working group agreements. If this >>>>>>>>>> is still unclear, I am not sure what to try next. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing >>>>> 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 Jul 11 05:56: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 725371B28BF for ; Fri, 11 Jul 2014 05:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct9fQ6V3HKaF for ; Fri, 11 Jul 2014 05:56:01 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2EF1A02EE for ; Fri, 11 Jul 2014 05:56:01 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 1eedfb35.2ac04b0b7940.6609539.00-2466.18290277.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:56:01 +0000 (UTC) X-MXL-Hash: 53bfdee13d58ff2f-4d098a20d4ebf81145db522c54f382b65f9a31bd Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 1cedfb35.0.6609336.00-2057.18289644.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 12:55:32 +0000 (UTC) X-MXL-Hash: 53bfdec44c1a1492-b2180e92dc3441f06c82375ec21cf485299ef591 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCtSMg026134; Fri, 11 Jul 2014 08:55:29 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BCtJlK025961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 08:55:24 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 12:55:01 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 08:53:55 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAF/1gIAAUEkA//++Z1A= Date: Fri, 11 Jul 2014 12:53:55 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABA3@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDA76.302@joelhalpern.com> In-Reply-To: <53BFDA76.302@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=3oc9M9_CAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=8t97H] X-AnalysisOut: [j2Qh7_6kro4bs4A:9 a=wPNLvfGTeEIA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=U8Ie8EnqySEA:10 a=chC_agHSu74A:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=hPjdaMEvmhQA:10 a=NQadpwcLbUBwCjtB:21 a=qCeKmK] X-AnalysisOut: [QF1dDv9n-T:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/y_Huhgc313iKPENB2VCKnjmN7dE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:56:07 -0000 =20 > Path selection is not, from what I have seen, dynamic in nature. There > has been expressed repeatedly a requirement that all the packets of a > given flow go through the same service instances. Dynamic routing > simply does not do that. And you believe it is possible and scalable to ensure it centrally but not = in a distributed manner? =20 > And as has been said repeatedly, the archtiecture proposed does not > require that load balancing be done entirely at the central point. As > far as I can tell any solution compliant with the proposed archtiecture > allows for both centralized control of some traffic distribution, and > local load balancing within that. I would expect most deployments would > use both. >=20 Well, it was just discussed that the wording in architecture document precl= udes a hop at SFI(n-1) to determine SFI(n).=20 Which means that SFC system determines SFI(n) centrally, which, in turn, me= ans that load balancing is done centrally. Maria Maria >=20 > On 7/11/14, 3:49 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, > > > > This is one possible approach, but what several of us are trying to > > clarify is this is one approach among others, not possible in some > > contexts, more complex to ensure resiliency, etc. Below some of my > > concerns about your approach: > > > > (1) Having an entity that maintains a large set of service paths in a > > given domain is more like creating circuits...I thought distributed > > routing has shown its efficiency. (2) Policies are everywhere in the > > network , not only at the SFC structuring system. (3) Path selection > > is dynamic by nature because it depends on various heuristics and > > policies that are distributed in the network (including those of SFs > > and others). (4) Having a stateful function that maintains the full > > list of available paths may not be that resilient. This must assess > > frequently (very short cycle) valid and serviceable paths among > > available ones. Ensuring the same level of resilience would require > > additional features to be supported by to that entity maintaining the > > full set of path, and also SFs. (5) Load-balancing at a centralized > > entity is deployment-specific; as such it is not required nor > > possible in those contexts. Deciding the forwarding path a priori > > contradicts LB requirements. I know your answer about > > re-classification, but IMHO the architecture should not mandate an > > optional feature only because of some design choices. > > Re-classification should be avoided as much for the same of > > performance and also because this one of the complexity vector for > > this work. (6) There are a bunch of solutions that achieve > > differentiated forwarding without requiring a > > pre-computation/pre-determination of a path: think about ToS-based > > routing, multi-topology routing, etc. > > > > I could live with an optional capability that a path can be > > pre-determined, but this must not be the rule. > > > > Forwarding within an SFC-enabled domain is primarily inferred by the > > service function chain itself. How this information is used to drive > > forwarding actions is all about details. > > > > Cheers, Med > > > >> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] > >> De la part de Joel M. Halpern Envoy=E9 : vendredi 11 juillet 2014 > >> 04:06 =C0 : Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org > >> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> Part of my personal view is that I am trying to make this work > >> sensibly in a more orchestrated environment. I expect that the > >> service functions, and over time probably the SFF capabilities, > >> will be orchestrated and installed. I expect the service chains to > >> be driven by BSS tools that define offerings to clients, and enable > >> self-selection from these. I expect service paths to be heavily > >> policy drive. > >> > >> I can see how to make all of that work in an archtiecture driven > >> by initial classification to described service paths. It is harder > >> to see how to make it work (but it can be done) when we allow more > >> dynamicity in the network behavior. > >> > >> Having said that, most of that perspective I described is outside > >> of the scope of the working group. it is not something we are > >> tasked to agree on. So I do not claim that vision means we have to > >> do it a certain way. it is just the perspective that drives my > >> preferences. > >> > >> Yours, Joel > >> > >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>> For me, the amount of information about service instances that > >>>> needs to be widely distributed and maintained, potentially even > >>>> across data centers within an administrative scope, is large > >>>> enough and complex enough that trying to get that into each SFF > >>>> seems like a difficult architecture to realize. > >>> > >>> I'm curious as to why that is more complicated than dynamic > >>> routing, > >> hyper-scale data center orchestration, or DNS, all of which are > >> bigger problems that have been profitably and stably implemented? > >>> > >>> It also seems that if it really is more complicated, that is a > >>> good sign > >> that it is too complicated. > >>> > >>> ________________________________________ From: Joel M. Halpern > >>> [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: > >>> Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >> sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> This is an architectural issue. And one that I would prefer we > >>> actually decide, rather than trying to allow all possible > >>> implementations. Because it does have a major effect on the > >>> control requirements and the functionality of SFFs. > >>> > >>> For me, the amount of information about service instances that > >>> needs to be widely distributed and maintained, potentially even > >>> across data centers within an administrative scope, is large > >>> enough and complex enough that trying to get that into each SFF > >>> seems like a difficult architecture to realize. > >>> > >>> Yours, Joel > >>> > >>> But it is a fair question. > >>> > >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>> This is the crux of my issue. Is the end to end selection of > >>>> (top-level) instances performed centrally (perhaps by the > >>>> classifier) or hop-by-hop (perhaps by the classifier and > >>>> subsequently the SFFs)? Such selection is not equivalent to > >>>> reclassification. And surely, this is an architectural issue > >>>> and not relegated to "implementation". > >>>> > >>>> My own view is to favor the distributed approach even though a > >>>> greater amount of data (chain definitions and perhaps local > >>>> selection policy) is required at those distributed decision > >>>> points. This approach does not require an end-to-end path id > >>>> at all. My rationale for favoring this approach is primarily > >>>> driven by increased resiliency over the global path id > >>>> approach. With a global path id approach, consider failure of > >>>> an instance and needing to alter the global path ID table for > >>>> each and every affected end-to-end path. > >>>> > >>>> Ron > >>>> > >>>> ________________________________________ From: sfc > >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 > >>>> PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: > >>>> Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> The way the architecture models the case of SF1 needing to > >>>> influence the chain is that one would do reclassification at > >>>> the exit from SF1. > >>>> > >>>> Part of the goal is to keep the different functions logically > >>>> separate so that solutions can clearly describe how they choose > >>>> to compose them for "service" delivery. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>> I don't see anything in the arch draft that suggests any sort > >>>>> of limit. However, it does seem to indicate that the entire > >>>>> path (all SFIs) must be chosen at SFC instantiation. I > >>>>> believe this means either at the classifier or maybe the > >>>>> classifier chooses a SF Chain and the NF or at the latest the > >>>>> first SFF. In any case, the language does seem to prohibit a > >>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1) > >>>>> hop. According to the draft, this behavior would be > >>>>> considered "branching" to a new SFP as opposed to choosing > >>>>> and then forwarding to the selected instance of the next-hop > >>>>> of the current SFC. > >>>>> > >>>>> draft-merged-sfc-architecture-00: > >>>>>> When an SFC is instantiated into the network it is > >>>>>> necessary to select the specific instances of SFs that will > >>>>>> be used, and to create the service topology for that SFC > >>>>>> using SF's network locator. Thus, instantiation of the SFC > >>>>>> results in the creation of a Service Function Path (SFP) > >>>>>> and is used for forwarding packets through the SFC. In > >>>>>> other words, an SFP is the instantiation of the defined > >>>>>> SFC. > >>>>>> > >>>>>> The SFC architecture supports reclassification (or > >>>>>> non-initial classification) as well. As packets traverse > >>>>>> an SFP, reclassification may occur - typically performed by > >>>>>> a classification function co-resident with a service > >>>>>> function. Reclassification may result in the selection of a > >>>>>> new SFP, an update of the associated metadata, or both. > >>>>>> This is referred to as "branching". > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------= ---- > >> > >>>>> > - > >>>>> > >>>>> > >>> *From: *I.Smith@F5.com > >>>>> *To: *Joel Halpern Direct,Joel > >>>>> M. > >>>>> > >> > Halpern,huang@sce.carleton.ca on.ca>,s > >> > >> > fc@ietf.org > >>>>> > >>>>> > >>> *Sent: *Thursday, July 10, 2014 > >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load > >>>>> Balancers > >>>>> > >>>>> Actually, I think I am disagreeing. > >>>>> > >>>>> If the possibility of medium-scale deployments (and that is > >>>>> what 16 million flows is in my world) of service chains is > >>>>> preconceived as an absurd idea, then the architecture > >>>>> burdened with that preconception. > >>>>> > >>>>> There has to be some point of aim, some degree of aspiration > >>>>> to scale that is appropriate for the lifespan of the > >>>>> architecture - you don't have to know what it is, but by > >>>>> saying that an arbitrary number is "too far", you're creating > >>>>> - even if it isn't intentional - a limit that influences > >>>>> decisions that have lasting impacts regarding scale-out, > >>>>> failure mitigation, elasticity, address space... all kinds of > >>>>> things. That is a problem I'm not particularly eager to deal > >>>>> with. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. > >>>>> Halpern; huang@sce.carleton.ca; sfc@ietf.org Subject: Re: > >>>>> [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> Ian, I don't think you disagree with me at all in this > >>>>> regard. I am not requesting the the architecture or the > >>>>> solution prohibit deployments in the specific fashion. I am > >>>>> objecting to Huang's reading of my note as saying that such > >>>>> deployments are required they by the archtiecture. > >>>>> > >>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>> things. Whether they are a good idea or not depends upon > >>>>> many factors outside of the scope of the WG. I happen to > >>>>> think that they are usually a bad idea. > >>>>> > >>>>> But the archtiecture si carefully avoiding attempting to know > >>>>> what is and is not eployable. > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>> I disagree. > >>>>>> > >>>>>> We routinely have stateful devices that manage tens of > >>>>>> millions of > >>>>> concurrent flows in both access network and data center > >>>>> environments today. You can't seriously believe that in the > >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > >>>>> going to have small numbers of service chains with equally > >>>>> small numbers of active service paths? > >>>>>> > >>>>>> Your sounds too much like "no one will ever need more than > >>>>>> 64K" for > >>>>> comfort. > >>>>>> > >>>>>> > >>>>>> ________________________________________ From: sfc > >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>> [jmh@joelhalpern.com] > >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > >>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] > >>>>>> Service Chains, Paths, and Load Balancers > >>>>>> > >>>>>> No, it will mean that if someone tries to deploy the > >>>>>> archtieture particularly badly, they will exceed the limits > >>>>>> of their devices. The architecture does not require such > >>>>>> absurd use of service paths. Since I can not figure out how > >>>>>> to write architectural words to prohibit it, the > >>>>>> architecture does permit such abuse. > >>>>>> > >>>>>> Please do not read my saying that the archtiecture permits > >>>>>> something as saying it is either deisred or required by the > >>>>>> work. It isn't. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>> If you need to support 100 service chains, it will mean > >>>>>>> 16,000,000 paths. That is larger than the routing table > >>>>>>> of a core router. > >>>>>>> > >>>>>>> Chang > >>>>>>> > >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>> service path to 160000 service paths. I would hope > >>>>>>>> that operators are prepared for the complexities if > >>>>>>>> they choose to avoid any use of local load balancing > >>>>>>>> and in stead provision 160,000 service paths. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>> Paul, > >>>>>>>>> > >>>>>>>>> How many path identifiers there will be for a 4 hop > >>>>>>>>> service chain with 20 instances at each hop? > >>>>>>>>> > >>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf > >>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10, > >>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:* > >>>>>>>>> jmh@joelhalpern.com; mohamed.boucadair@orange.com; > >>>>>>>>> sfc@ietf.org; mikebianc@aol.com *Subject:* Re: [sfc] > >>>>>>>>> Service Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Lucy, > >>>>>>>>> > >>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>> forwarding. I'd > >>>>> make > >>>>>>>>> the minor change: the path identifier can be used to > >>>>>>>>> derive the needed forwarding and associated > >>>>>>>>> transport. > >>>>>>>>> > >>>>>>>>> It is _not_ the transport, but rather is used to > >>>>>>>>> simply identify the service path (or graph) that > >>>>>>>>> packets must traverse. By having a path identifier, > >>>>>>>>> the exact indirection that people seem to be asking > >>>>>>>>> for on this thread can be simply be implemented. The > >>>>>>>>> path identifier provides nothing more than a lookup, > >>>>>>>>> that lookup can result in a one or more (equal or > >>>>>>>>> weighted) transport next hop(s). > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>> > > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Agree. The arch. doc should not mandate only use of > >>>>>>>>> the service path identifier to drive the forwarding > >>>>>>>>> actions. > >>>>>>>>> > >>>>>>>>> Lucy > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>> > >>>>>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM > >>>>>>>>> *To:*mikebianc@aol.com > >>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Subject:*Re: [sfc] Service > >>>>>>>>> Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Re-, > >>>>>>>>> > >>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>> identifier. I object to use that identifier to > >>>>>>>>> derive forwarding actions. > >>>>>>>>> > >>>>>>>>> Requiring a SFC system to have the full knowledge of > >>>>>>>>> every > >>>>> available SFC > >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>> required/justified > >>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>> > >>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>> information > >>>>> that will > >>>>>>>>> be present in all deployments: that is the one > >>>>>>>>> required to structure a service chain. How that > >>>>>>>>> information is used to infer forwarding > >>>>> actions > >>>>>>>>> is a solution-oriented discussion. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Med > >>>>>>>>> > >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>> de*mikebianc@aol.com > >>>>>>>>> *Envoy=E9 :*mercredi 9 > >>>>>>>>> juillet 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Objet :*Re: [sfc] Service > >>>>>>>>> Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Is anyone still questioning the difference between SF > >>>>>>>>> Chain and SF > >>>>> Path? > >>>>>>>>> Other than clarifying the definition so that it's > >>>>>>>>> clear to > >>>>> those not > >>>>>>>>> familiar with the draft, it seems that everyone > >>>>>>>>> agrees on these terms. > >>>>>>>>> > >>>>>>>>> To me, the one point that is still unclear is whether > >>>>>>>>> it is the intent of this draft to ultimately specify > >>>>>>>>> what the ID of the SFC Header > >>>>> should > >>>>>>>>> reference (the chain or the path), or if this draft > >>>>>>>>> simply intends to leave that ambiguous, allowing > >>>>>>>>> other drafts to dictate the mechanisms for forwarding > >>>>>>>>> based on chain or path and the choice of chain or > >>>>> path to > >>>>>>>>> be negotiated in the control-plane. > >>>>>>>>> > >>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>> require that both SFP and SFC be supported (or make > >>>>>>>>> one required and the other optional) to avoid some > >>>>>>>>> vendors only supporting SFP and others only > >>>>>>>>> supporting SFC. > >>>>>>>>> > >>>>>>>>> > >>>>> -------------------------------------------------------------------= ---- > >> > >>>>> > - > >>>>> > >>>>> > >>>>>>> > >>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>> > > >>>>>>>>> *To:*sfc@ietf.org >>>>>>>>> > *Sent:*Tuesday, > >>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths, > >>>>>>>>> and Load Balancers > >>>>>>>>> > >>>>>>>>> I have been trying to figure out how to clearly > >>>>>>>>> answer a number of comments that have been made about > >>>>>>>>> the proposed merged archtiecture draft. Assuming we > >>>>>>>>> can get working group agreement on the intent, we > >>>>>>>>> will work to improve the wording so that readers who > >>>>>>>>> have not participated in the WG discussion will > >>>>>>>>> understnd it the way the > >>>>> working > >>>>>>>>> group intends. > >>>>>>>>> > >>>>>>>>> But what do we intend? I will try to explain my > >>>>>>>>> personal view, and see if that helps. > >>>>>>>>> > >>>>>>>>> In this regard, it is important to keep in mind that > >>>>>>>>> what we are defining is the data plane architecture. > >>>>>>>>> We are not attempting to define the architecture for > >>>>>>>>> the entire solution for service chaining. That would > >>>>>>>>> encompass OSS/BSS, various control and policy > >>>>>>>>> functions, virtual machine and image management, and > >>>>>>>>> many other aspects. > >>>>>>>>> > >>>>>>>>> As a result there are many things which clearly need > >>>>>>>>> to exist in the larger system, but which are dealt > >>>>>>>>> with above where we are > >>>>> functioning, > >>>>>>>>> and are not directly required by the work we are > >>>>>>>>> doing. > >>>>>>>>> > >>>>>>>>> In order to get to service chain vs service path, as > >>>>>>>>> I understand > >>>>> them, > >>>>>>>>> I need to first discuss load balancing. There are at > >>>>>>>>> least three different ways that load balancing can > >>>>>>>>> and will interact with service chaining. There > >>>>>>>>> probably are more. The point of the archtiecture is > >>>>>>>>> to permit all of these, but not to mandate that any > >>>>>>>>> particular kind > >>>>> be used > >>>>>>>>> in any solution. > >>>>>>>>> > >>>>>>>>> 1) Load balancing as a service provided to the end > >>>>>>>>> user. This is a service function. It receives user > >>>>>>>>> packets, and modifies them (or > >>>>> marks > >>>>>>>>> them, or ...) so as to choose an end user service > >>>>>>>>> instance to receive the users packet. This is an > >>>>>>>>> important service function to be able to include in > >>>>>>>>> service chaining. It's behavior may affect > >>>>>>>>> requirements on how service chaining is done. But it > >>>>>>>>> has very little impact on the archtiecture. From an > >>>>>>>>> architectural pe3rspective it is simply a > >>>>> service > >>>>>>>>> function which may modify the underlying packet. > >>>>>>>>> > >>>>>>>>> 2) There is internal load balancing. That is, one can > >>>>>>>>> have what > >>>>> appears > >>>>>>>>> to the service chaining architecture as a single > >>>>>>>>> point of contact > >>>>> for a > >>>>>>>>> specific service function, but is actually delivered > >>>>>>>>> by a > >>>>> collection of > >>>>>>>>> virtual or physical machines, possibly including one > >>>>>>>>> or several load balancers (for example using > >>>>>>>>> VRRP-like techniques to share a MAC address.) mostly, > >>>>>>>>> this is invisible to the service chaining data plane > >>>>>>>>> mechanisms. It is likely that it is visible to > >>>>>>>>> various control mechanisms, such as those responsible > >>>>>>>>> for scale-in, scale-out, and vm instantiation. The > >>>>>>>>> architectural impact of permitting this is largely > >>>>>>>>> that we need to be careful that our terminology does > >>>>>>>>> not lead > >>>>> readers to > >>>>>>>>> think we are prohibiting it. > >>>>>>>>> > >>>>>>>>> 3) There can also be load balancing done by > >>>>>>>>> selecting packet paths for the service chaining that > >>>>>>>>> direct traffic to different places. We would not want > >>>>>>>>> to require that a given service function appear at > >>>>>>>>> only one place in the network. > >>>>>>>>> > >>>>>>>>> It is of course the case that these may be combined. > >>>>>>>>> I tend to > >>>>> refer to > >>>>>>>>> the collection of entities that appear to service > >>>>>>>>> chaining as a single point as a cluster. Not because > >>>>>>>>> cluster is a good term. But because I do not have > >>>>>>>>> another one. Thus, the point of type 3 load > >>>>>>>>> balancing > >>>>> is to > >>>>>>>>> direct different subsets of traffic to different > >>>>>>>>> singular or clustered service functions in different > >>>>>>>>> places in the network. > >>>>>>>>> > >>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>> service chain and service path/ Service chain is a > >>>>>>>>> sequence of logical functions to be applied to a > >>>>>>>>> subset of packets. It is equivalent of saying that > >>>>>>>>> some subset of traffic is to get DPI, charging, > >>>>>>>>> content inspection, and firewall while a different > >>>>>>>>> subset is to go directly to the cache > >>>>> without > >>>>>>>>> visiting any other service functions. > >>>>>>>>> > >>>>>>>>> That is not enough information to direct the packets. > >>>>>>>>> A service path is, in some fashion, a sequence of > >>>>>>>>> locations in the network. Those locations will be > >>>>>>>>> singular or clustered service function delivery > >>>>>>>>> locations. They may be addressed by IP address. They > >>>>>>>>> may be addressed as ports on an SFF. There are many > >>>>>>>>> different ways that the locations may be known to the > >>>>>>>>> service chaining infrastructure and the transport. > >>>>>>>>> > >>>>>>>>>> From the point of view of the work of the SFC > >>>>>>>>>> group, we need to be > >>>>>>>>> able to talk about the high level abstraction, the > >>>>>>>>> service chain, which drives the forwarding. And we > >>>>>>>>> need to talk about the actual data path packets will > >>>>>>>>> take in the network. > >>>>>>>>> > >>>>>>>>> Several of the comments have said "but the whole path > >>>>>>>>> may not be known at the front." This architecture > >>>>>>>>> deals with that issue in two ways. First, as noted in > >>>>>>>>> item (2) on load balancers above, there can be > >>>>>>>>> decisions and behaviors which are invisible to the > >>>>>>>>> service chaining mechanisms (in much the same way > >>>>>>>>> that bridging within a LAN is largely invisible to > >>>>>>>>> routing between LANs.) The other provision we make > >>>>>>>>> is > >>>>> that > >>>>>>>>> reclassification can be done in mid-chain when > >>>>>>>>> necessary. That will direct packets to a new chain. > >>>>>>>>> Based on information available at the > >>>>>>>>> re-classification point. > >>>>>>>>> > >>>>>>>>> I hope that this helps explain what we are after. If > >>>>>>>>> it does, and if the intent is acceptable to the > >>>>>>>>> working group, we can figure out what additional > >>>>>>>>> words are needed to convey this. If the working group > >>>>>>>>> disagree with the intent, then we will of course > >>>>>>>>> adjust to match the working group agreements. If this > >>>>>>>>> is still unclear, I am not sure what to try next. > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > >>>>>>>> mailing list sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > >>>>>>> mailing list sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ sfc mailing > >>>>>> list sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>>> _______________________________________________ sfc mailing > >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > >>>> 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 From nobody Fri Jul 11 05:58: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 2F4971A02EE for ; Fri, 11 Jul 2014 05:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, 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 UfM3kGgmOAk0 for ; Fri, 11 Jul 2014 05:58:35 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7821B288E for ; Fri, 11 Jul 2014 05:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AB9F72412C2; Fri, 11 Jul 2014 05:58:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 94DB6240A31; Fri, 11 Jul 2014 05:58:30 -0700 (PDT) Message-ID: <53BFDF76.7050202@joelhalpern.com> Date: Fri, 11 Jul 2014 08:58:30 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zEdRLm6YU7jl_j05ri199BhpCpE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 12:58:40 -0000 And that is exactly what it does Med. It permits but does not require load balancers inside or adjacent to the SFF. The problem is that the behavior Ron described would require that every SFF were a full, stateful, load balancer. I agree with you that such a requirement is unacceptable. So let me say again: the curent archtiecture proposal meets the requirement you state. It allows for, but does not require central laod balancing. It allows for, but does not require, local load balancing of various kinds at or with the SFF. Yours, Joel On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: > Joel, > > The architecture has to make NO assumptions on the actual configuration/behavior of SFFs (whether none, some, or all of them are stateful, flow-aware co-located with LBs/etc.). This is deployment-specific. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoyé : vendredi 11 juillet 2014 14:08 >> À : Ron Parker; sfc@ietf.org >> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >> And it was pointed out to me that I made a two letter major typo. >> >> I was trying to say that I felt that such a requirement on all SFF would >> be an UNacceptable imposition. >> >> Yours, >> Joel >> >> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: >>> Ron, thinking about this, I realized another major problem with the your >>> proposal as I understand it. (And I readily admit I may not understand >>> it.) >>> >>> The proposal has each SFF serve as the load balancer for the next >>> service function that follows it (not the one it delivers to), in every >>> service chain that goes through it. >>> >>> Since it has to be able to work with all services, that means that every >>> SFF would have to be a full, flow sensitive and stateful load balancer. >>> I ahve no problem if some SFF are flow sensitive, and / or stateful. But >>> having the architecture require that every SFF be a full, flow >>> sensitive, stateful, load balancer seems to me to be an acceptable >>> imposition. >>> >>> Yours, >>> Joel >>> >>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>>> Part of my personal view is that I am trying to make this work sensibly >>>> in a more orchestrated environment. I expect that the service >>>> functions, and over time probably the SFF capabilities, will be >>>> orchestrated and installed. I expect the service chains to be driven by >>>> BSS tools that define offerings to clients, and enable self-selection >>>> from these. I expect service paths to be heavily policy drive. >>>> >>>> I can see how to make all of that work in an archtiecture driven by >>>> initial classification to described service paths. It is harder to see >>>> how to make it work (but it can be done) when we allow more dynamicity >>>> in the network behavior. >>>> >>>> Having said that, most of that perspective I described is outside of the >>>> scope of the working group. it is not something we are tasked to >>>> agree on. >>>> So I do not claim that vision means we have to do it a certain way. it >>>> is just the perspective that drives my preferences. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>> For me, the amount of information about service instances that needs >> to >>>>>> be widely distributed and maintained, potentially even across data >>>>>> centers within an administrative scope, is large enough and complex >>>>>> enough that trying to get that into each SFF seems like a difficult >>>>>> architecture to realize. >>>>> >>>>> I'm curious as to why that is more complicated than dynamic routing, >>>>> hyper-scale data center orchestration, or DNS, all of which are bigger >>>>> problems that have been profitably and stably implemented? >>>>> >>>>> It also seems that if it really is more complicated, that is a good >>>>> sign that it is too complicated. >>>>> >>>>> ________________________________________ >>>>> From: Joel M. Halpern [jmh@joelhalpern.com] >>>>> Sent: Thursday, July 10, 2014 9:45 PM >>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> This is an architectural issue. And one that I would prefer we >> actually >>>>> decide, rather than trying to allow all possible implementations. >>>>> Because it does have a major effect on the control requirements and the >>>>> functionality of SFFs. >>>>> >>>>> For me, the amount of information about service instances that needs to >>>>> be widely distributed and maintained, potentially even across data >>>>> centers within an administrative scope, is large enough and complex >>>>> enough that trying to get that into each SFF seems like a difficult >>>>> architecture to realize. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> But it is a fair question. >>>>> >>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>>> This is the crux of my issue. Is the end to end selection of >>>>>> (top-level) instances performed centrally (perhaps by the classifier) >>>>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>>>>> Such selection is not equivalent to reclassification. And surely, >>>>>> this is an architectural issue and not relegated to >>>>>> "implementation". >>>>>> >>>>>> My own view is to favor the distributed approach even though a >>>>>> greater amount of data (chain definitions and perhaps local selection >>>>>> policy) is required at those distributed decision points. This >>>>>> approach does not require an end-to-end path id at all. My >>>>>> rationale for favoring this approach is primarily driven by increased >>>>>> resiliency over the global path id approach. With a global path id >>>>>> approach, consider failure of an instance and needing to alter the >>>>>> global path ID table for each and every affected end-to-end path. >>>>>> >>>>>> Ron >>>>>> >>>>>> ________________________________________ From: sfc >>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> The way the architecture models the case of SF1 needing to influence >>>>>> the chain is that one would do reclassification at the exit from >>>>>> SF1. >>>>>> >>>>>> Part of the goal is to keep the different functions logically >>>>>> separate so that solutions can clearly describe how they choose to >>>>>> compose them for "service" delivery. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>>> I don't see anything in the arch draft that suggests any sort of >>>>>>> limit. However, it does seem to indicate that the entire path (all >>>>>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>>>>> either at the classifier or maybe the classifier chooses a SF Chain >>>>>>> and the NF or at the latest the first SFF. In any case, the >>>>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>>>>> determined at the SFI(n-1) hop. According to the draft, this >>>>>>> behavior would be considered "branching" to a new SFP as opposed to >>>>>>> choosing and then forwarding to the selected instance of the >>>>>>> next-hop of the current SFC. >>>>>>> >>>>>>> draft-merged-sfc-architecture-00: >>>>>>>> When an SFC is instantiated into the network it is necessary to >>>>>>>> select the specific instances of SFs that will be used, and to >>>>>>>> create the service topology for that SFC using SF's network >>>>>>>> locator. Thus, instantiation of the SFC results in the creation >>>>>>>> of a Service Function Path (SFP) and is used for forwarding >>>>>>>> packets through the SFC. In other words, an SFP is the >>>>>>>> instantiation of the defined SFC. >>>>>>>> >>>>>>>> The SFC architecture supports reclassification (or non-initial >>>>>>>> classification) as well. As packets traverse an SFP, >>>>>>>> reclassification may occur - typically performed by a >>>>>>>> classification function co-resident with a service function. >>>>>>>> Reclassification may result in the selection of a new SFP, an >>>>>>>> update of the associated metadata, or both. This is referred to >>>>>>>> as "branching". >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >> --- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> *From: *I.Smith@F5.com >>>>>>> *To: *Joel Halpern Direct,Joel M. >>>>>>> >> Halpern,huang@sce.carleton.ca,s >> fc@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> *Sent: *Thursday, July 10, 2014 >>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>> >>>>>>> Actually, I think I am disagreeing. >>>>>>> >>>>>>> If the possibility of medium-scale deployments (and that is what >>>>>>> 16 million flows is in my world) of service chains is preconceived >>>>>>> as an absurd idea, then the architecture burdened with that >>>>>>> preconception. >>>>>>> >>>>>>> There has to be some point of aim, some degree of aspiration to >>>>>>> scale that is appropriate for the lifespan of the architecture - >>>>>>> you don't have to know what it is, but by saying that an arbitrary >>>>>>> number is "too far", you're creating - even if it isn't intentional >>>>>>> - a limit that influences decisions that have lasting impacts >>>>>>> regarding scale-out, failure mitigation, elasticity, address >>>>>>> space... all kinds of things. That is a problem I'm not >>>>>>> particularly eager to deal with. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>>>>> Chains, Paths, and Load Balancers >>>>>>> >>>>>>> Ian, I don't think you disagree with me at all in this regard. I am >>>>>>> not requesting the the architecture or the solution prohibit >>>>>>> deployments in the specific fashion. I am objecting to Huang's >>>>>>> reading of my note as saying that such deployments are required >>>>>>> they by the archtiecture. >>>>>>> >>>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>>> things. Whether they are a good idea or not depends upon many >>>>>>> factors outside of the scope of the WG. I happen to think that they >>>>>>> are usually a bad idea. >>>>>>> >>>>>>> But the archtiecture si carefully avoiding attempting to know what >>>>>>> is and is not eployable. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>>> I disagree. >>>>>>>> >>>>>>>> We routinely have stateful devices that manage tens of millions >>>>>>>> of >>>>>>> concurrent flows in both access network and data center >>>>>>> environments today. You can't seriously believe that in the >>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>>>>> to have small numbers of service chains with equally small numbers >>>>>>> of active service paths? >>>>>>>> >>>>>>>> Your sounds too much like "no one will ever need more than 64K" >>>>>>>> for >>>>>>> comfort. >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________ From: sfc >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>>> [jmh@joelhalpern.com] >>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>> Balancers >>>>>>>> >>>>>>>> No, it will mean that if someone tries to deploy the archtieture >>>>>>>> particularly badly, they will exceed the limits of their >>>>>>>> devices. The architecture does not require such absurd use of >>>>>>>> service paths. Since I can not figure out how to write >>>>>>>> architectural words to prohibit it, the architecture does permit >>>>>>>> such abuse. >>>>>>>> >>>>>>>> Please do not read my saying that the archtiecture permits >>>>>>>> something as saying it is either deisred or required by the work. >>>>>>>> It isn't. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>>>>> core router. >>>>>>>>> >>>>>>>>> Chang >>>>>>>>> >>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>>>> operators are prepared for the complexities if they choose to >>>>>>>>>> avoid any use of local load balancing and in stead provision >>>>>>>>>> 160,000 service paths. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> Paul, >>>>>>>>>>> >>>>>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>>>>> chain with 20 instances at each hop? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Lucy, >>>>>>>>>>> >>>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>>> forwarding. I'd >>>>>>> make >>>>>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>>>>> the needed forwarding and associated transport. >>>>>>>>>>> >>>>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>>>> hop(s). >>>>>>>>>>> >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>>>>> >>>>>>>>>>> Lucy >>>>>>>>>>> >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>>> *Sent:*Thursday, July >>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Re-, >>>>>>>>>>> >>>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>>>> forwarding actions. >>>>>>>>>>> >>>>>>>>>>> Requiring a SFC system to have the full knowledge of every >>>>>>> available SFC >>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>>> required/justified >>>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>>> >>>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>>> information >>>>>>> that will >>>>>>>>>>> be present in all deployments: that is the one required to >>>>>>>>>>> structure a service chain. How that information is used to >>>>>>>>>>> infer forwarding >>>>>>> actions >>>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Med >>>>>>>>>>> >>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>>> de*mikebianc@aol.com >>>>>>>>>>> *Envoyé :*mercredi 9 juillet >>>>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>>>>> and SF >>>>>>> Path? >>>>>>>>>>> Other than clarifying the definition so that it's clear to >>>>>>> those not >>>>>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>>>>> these terms. >>>>>>>>>>> >>>>>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>>>>> of the SFC Header >>>>>>> should >>>>>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>>>>> path and the choice of chain or >>>>>>> path to >>>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>>> >>>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>>>> >>>>>>>>>>> >>>>>>> --------------------------------------------------------------------- >> --- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>>> > >>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>> > *Sent:*Tuesday, July >>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>>>> Balancers >>>>>>>>>>> >>>>>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>>>>> number of comments that have been made about the proposed >>>>>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>>>>> wording so that readers who have not participated in the WG >>>>>>>>>>> discussion will understnd it the way the >>>>>>> working >>>>>>>>>>> group intends. >>>>>>>>>>> >>>>>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>>>>> view, and see if that helps. >>>>>>>>>>> >>>>>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>>>>> attempting to define the architecture for the entire >>>>>>>>>>> solution for service chaining. That would encompass >>>>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>>>> machine and image management, and many other aspects. >>>>>>>>>>> >>>>>>>>>>> As a result there are many things which clearly need to >>>>>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>>>>> where we are >>>>>>> functioning, >>>>>>>>>>> and are not directly required by the work we are doing. >>>>>>>>>>> >>>>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>>>> understand >>>>>>> them, >>>>>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>>>>> three different ways that load balancing can and will >>>>>>>>>>> interact with service chaining. There probably are more. >>>>>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>>>>> but not to mandate that any particular kind >>>>>>> be used >>>>>>>>>>> in any solution. >>>>>>>>>>> >>>>>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>>>>> This is a service function. It receives user packets, and >>>>>>>>>>> modifies them (or >>>>>>> marks >>>>>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>>>>> to receive the users packet. This is an important service >>>>>>>>>>> function to be able to include in service chaining. It's >>>>>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>>>>> From an architectural pe3rspective it is simply a >>>>>>> service >>>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>>> >>>>>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>>>>> what >>>>>>> appears >>>>>>>>>>> to the service chaining architecture as a single point of >>>>>>>>>>> contact >>>>>>> for a >>>>>>>>>>> specific service function, but is actually delivered by a >>>>>>> collection of >>>>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>>>>> is largely that we need to be careful that our terminology >>>>>>>>>>> does not lead >>>>>>> readers to >>>>>>>>>>> think we are prohibiting it. >>>>>>>>>>> >>>>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>>>>> to different places. We would not want to require that a >>>>>>>>>>> given service function appear at only one place in the >>>>>>>>>>> network. >>>>>>>>>>> >>>>>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>>>>> to >>>>>>> refer to >>>>>>>>>>> the collection of entities that appear to service chaining >>>>>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>>>>> point of type 3 load balancing >>>>>>> is to >>>>>>>>>>> direct different subsets of traffic to different singular >>>>>>>>>>> or clustered service functions in different places in the >>>>>>>>>>> network. >>>>>>>>>>> >>>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>>>> while a different subset is to go directly to the cache >>>>>>> without >>>>>>>>>>> visiting any other service functions. >>>>>>>>>>> >>>>>>>>>>> That is not enough information to direct the packets. A >>>>>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>>>>> in the network. Those locations will be singular or >>>>>>>>>>> clustered service function delivery locations. They may be >>>>>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>>>>> an SFF. There are many different ways that the locations >>>>>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>>>>> transport. >>>>>>>>>>> >>>>>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>>>>> need to be >>>>>>>>>>> able to talk about the high level abstraction, the service >>>>>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>>>>> about the actual data path packets will take in the >>>>>>>>>>> network. >>>>>>>>>>> >>>>>>>>>>> Several of the comments have said "but the whole path may >>>>>>>>>>> not be known at the front." This architecture deals with >>>>>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>>>>> make is >>>>>>> that >>>>>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>>>> information available at the re-classification point. >>>>>>>>>>> >>>>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>>>>> we can figure out what additional words are needed to >>>>>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>>>>> then we will of course adjust to match the working group >>>>>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>>>>> try next. >>>>>>>>>>> >>>>>>>>>>> Yours, Joel >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing list >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing list >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing 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 Jul 11 06:08: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 A71981B2ADC for ; Fri, 11 Jul 2014 06:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 nnYZR07rOQpK for ; Fri, 11 Jul 2014 06:07:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672071B282E for ; Fri, 11 Jul 2014 06:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88155; q=dns/txt; s=iport; t=1405084096; x=1406293696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iKwcfyi7JpAi9Trya/XD5yp3CSxViwix3mMshLeNw+A=; b=FFApMpQ0u4VCFp+az/5aenKKpFrd/T38OZRb7WDjAurVcIOcYujejEuP sqTvGYxgKBiUOVHXauhBATHBfBBu3/mPJcmDKrMsLK//vgajRPiocxFDH RQER5p2GEWkbpNk5279StAh6bf59gEqVZeIoROfW96c/HEBK83WDJkia2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAA/hv1OtJA2F/2dsb2JhbABPCoJHR1Jap2iHCZF4AQmGb1MBgQoWdYQDAQEBBAEBARcNBisNAgcLEAIBCBEBAgEBASEBBgcnCxQDBggCBAENBRuIEwMRDcZNEwSNGoFQLxwHBgQGAYRDBZYiSYQai2eININEgjA X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208,217";a="339338631" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2014 13:08:12 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6BD7spv019790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:07:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 08:07:54 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAXQIAgADO1gA= Date: Fri, 11 Jul 2014 13:07:54 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE54EBD2D05Bjguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NmCcCkpw-NqctZEynmbw3HxdixE Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:08:10 -0000 --_000_CFE54EBD2D05Bjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation wil= l contain a path identifier as described within our charter which says =933= . Generic SFC encapsulation: This document will describe a single service-l= evel data plane encapsulation format that indicates the sequence of service= functions that make up the Service Function Chain; specifies the Service F= unction Path=94. The wording here is very important and shows that the inte= nt is that the sequence of SF=92s be indicated within the SFC encapsulation= e.g. not carried =96 this is not source routing, and specifies the SFP, h= ence the path identifier. For my example let=92s assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1=94 It is possible that each of those SF=92s be directly addressable (i.e. prov= ide SFF functionality) or reachable through some other network device that = provides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF=92= s; let=92s call them SF1-loc1, SF2-loc2, and SF3-loc3. When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier =93100=94. This information is di= stributed to the relevant network devices basically saying =93if you receiv= e an SFC encapsulated packet with path identifier =93100=94 then use the pa= th identifier and index to perform a lookup in a data structure that will t= ell you which SF to forward the traffic to and how to get there=94. So traffic flows through the SFP with path identifier =93100=94, via a netw= ork transport (the path identifier is encapsulated). It reaches SF1-loc1 wh= ich uses the path identifier to determine that it is in fact the SF that sh= ould be applied. It applies SF1 SF and then uses the path identifier to det= ermine that SF2 is the next service and its reachable at next-hop SF2-loc2.= The needed transport (for example VXLAN) is imposed for network forwarding= . Traffic reaches SF2-loc2. It uses the path identifier to determine that S= F2 should be applied. It uses a local decision to determine which of the 20= instances of SF2 it should forward the traffic to. It forwards the traffic= to the selected instance. SF2 is applied and then another lookup occurs on= the path identifier, which results in the needed transport being imposed t= o reach the next service hop SF3-loc3 .. And so on and so forth. So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From: "mikebianc@aol.com" > Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim, Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at a= ll. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. ________________________________ From: jguichar@cisco.com> To: NAPIERALA, MARIA H> cc: Paul Quinn (paulq)>,Lucy yong>,jmh@joelhalpern.com>,moh= amed.boucadair@orange.com>,sfc@ietf.org>,mikebianc@aol.com> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make t= he minor change: the path identifier can be used to derive the needed forwa= rding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a = lookup, that lookup can result in a one or more (equal or weighted) transpo= rt next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behal= f Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;= jmh@joelhalpern.com= ;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la par= t de mikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From:jmh@joelhalpern.com<= mailto:jmh@joelhalpern.com>= > To: sfc@ietf.org<= sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CFE54EBD2D05Bjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mike,

There still seems to be some confusion around this topic so let me try= to provide a more detailed explanation as to how I believe this should wor= k and why what I explained earlier is in fact a path identifier and not a c= hain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =933. Generic SFC encapsulation: This do= cument will describe a single service-level data plane encapsulation format= that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path=94. The wording here is very imp= ortant and shows that the intent is that the sequence of SF=92s be indicate= d within the SFC encapsulation e.g. not carried =96 this is not source routing, and = ; specifies the SFP, hence the path identifier.

For my example let=92s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1= =94

It is possible that each of those SF=92s be directly addressable (i.e.= provide SFF functionality) or reachable through some other network device = that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 = relies on a connected switch to provide the needed SFF functionality. Conne= cted to that SFF are 20 instances of the SF2 SF. In this case you have exac= tly 3 network locators from which to choose in order to reach the required SF=92s; let=92s call them SF1-loc= 1, SF2-loc2, and SF3-loc3. 

When an operator instantiates SFC-1 into the network, specific locator= s are selected to construct the path, and a path identifier is allocated. I= n this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> = SF2-loc2 -> SF3-loc3 and it has a path identifier =93100=94. This information is distributed to the relevant netw= ork devices basically saying =93if you receive an SFC encapsulated packet w= ith path identifier =93100=94 then use the path identifier and index to per= form a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=94.

So traffic flows through the SFP with path identifier =93100=94, via a= network transport (the path identifier is encapsulated). It reaches SF1-lo= c1 which uses the path identifier to determine that it is in fact the SF th= at should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth. 

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).


Date: Thursday, July 10, 2014 at 4:= 46 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers


Jim, 

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop?  In this case, there wouldn't be any Path Ident= ifier at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there wil= l be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=92d make the minor change: the path identifier can be used to = derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc should not man= date only use of the service path identifier to drive the forwarding action= s.

Lucy

From:sfc [mailto:sfc-bounces@ietf.org<= /a>]On Behalf Of moh= amed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com;jmh@joelhalpern.com<= /a>;sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a s= ervice path identifier. I object to use that identifier to derive forwardin= g actions.

Requiring a SFC system to have the full k= nowledge of every available SFC forwarding paths within an SFC-enabled doma= in is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the= piece of information that will be present in all deployments: that is the = one required to structure a service chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion.

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org<= /a>]De la part de mikebianc@aol.com
Envoy=E9 : mercredi 9 j= uillet 2014 22:03
=C0 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain an= d SF Path? Other than clarifying the definition so that it's clear to those= not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is th= e intent of this draft to ultimately specify what the ID of the SFC Header = should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require t= hat both SFP and SFC be supported (or make one required and the other optio= nal) to avoid some vendors only supporting SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
 --_000_CFE54EBD2D05Bjguicharciscocom_-- From nobody Fri Jul 11 06:08: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 174C71B2ADC for ; Fri, 11 Jul 2014 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=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 2sjBzWMQTWVy for ; Fri, 11 Jul 2014 06:08:28 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7C61B2AE1 for ; Fri, 11 Jul 2014 06:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ACE8F24050B; Fri, 11 Jul 2014 06:08:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A48AF240380; Fri, 11 Jul 2014 06:08:13 -0700 (PDT) Message-ID: <53BFE1BD.3000507@joelhalpern.com> Date: Fri, 11 Jul 2014 09:08:13 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDA76.302@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABA3@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABA3@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cl6qYALe0Vkc9SBhxLU0rqgm5Vg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:08:32 -0000 There is a VERY large difference both architecturally and in terms of solutions and implementations between saying that the SFI does not make decisions about next SFI and saying that there is no local load balancing. Yes, the archteicture states that the service functions themselves do not direct the forwarding. That is a matter of separation of concerns. It also says that the SFF is responsible for delivery to the SF. That explicitly allows for the SFF to perform laod balancing to its local Service Functions, or to be delivering to local load balancers, or likely other methods that have not occurred to any of us. What the architecture prohbits in this regard is having SFF make global decisions about how service paths are realized, and in particular how load is delivered to instances supported by other SFF. For example, depending upon the transport and the solution specifics, it is consonant with the archtiecture for the SFF to be a distributed computation engine so that delivery to it is always a nearby tranfer from the previous SFF, and then the SFF does stateful load balancing, using shared computation within itself, to deliver packets to the correct software image. That is permitted by the architecture, but not required. Having SFI make decisions about next SFI means that we have coupled network forwarding with the actual service functions. That complicates construction of service functions, and requires them to deliver additional functionality. If a service function developer wants to include an SFF in what he delivers, that is permitted by the architecture. We are describing logical components, not the package developers or vendors choose to use. Yours, Joel On 7/11/14, 8:53 AM, NAPIERALA, MARIA H wrote: > >> Path selection is not, from what I have seen, dynamic in nature. There >> has been expressed repeatedly a requirement that all the packets of a >> given flow go through the same service instances. Dynamic routing >> simply does not do that. > > And you believe it is possible and scalable to ensure it centrally but not in a distributed manner? > >> And as has been said repeatedly, the archtiecture proposed does not >> require that load balancing be done entirely at the central point. As >> far as I can tell any solution compliant with the proposed archtiecture >> allows for both centralized control of some traffic distribution, and >> local load balancing within that. I would expect most deployments would >> use both. >> > > Well, it was just discussed that the wording in architecture document precludes a hop at SFI(n-1) to determine SFI(n). > Which means that SFC system determines SFI(n) centrally, which, in turn, means that load balancing is done centrally. > > Maria > > > > Maria >> >> On 7/11/14, 3:49 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, >>> >>> This is one possible approach, but what several of us are trying to >>> clarify is this is one approach among others, not possible in some >>> contexts, more complex to ensure resiliency, etc. Below some of my >>> concerns about your approach: >>> >>> (1) Having an entity that maintains a large set of service paths in a >>> given domain is more like creating circuits...I thought distributed >>> routing has shown its efficiency. (2) Policies are everywhere in the >>> network , not only at the SFC structuring system. (3) Path selection >>> is dynamic by nature because it depends on various heuristics and >>> policies that are distributed in the network (including those of SFs >>> and others). (4) Having a stateful function that maintains the full >>> list of available paths may not be that resilient. This must assess >>> frequently (very short cycle) valid and serviceable paths among >>> available ones. Ensuring the same level of resilience would require >>> additional features to be supported by to that entity maintaining the >>> full set of path, and also SFs. (5) Load-balancing at a centralized >>> entity is deployment-specific; as such it is not required nor >>> possible in those contexts. Deciding the forwarding path a priori >>> contradicts LB requirements. I know your answer about >>> re-classification, but IMHO the architecture should not mandate an >>> optional feature only because of some design choices. >>> Re-classification should be avoided as much for the same of >>> performance and also because this one of the complexity vector for >>> this work. (6) There are a bunch of solutions that achieve >>> differentiated forwarding without requiring a >>> pre-computation/pre-determination of a path: think about ToS-based >>> routing, multi-topology routing, etc. >>> >>> I could live with an optional capability that a path can be >>> pre-determined, but this must not be the rule. >>> >>> Forwarding within an SFC-enabled domain is primarily inferred by the >>> service function chain itself. How this information is used to drive >>> forwarding actions is all about details. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >>>> De la part de Joel M. Halpern Envoyé : vendredi 11 juillet 2014 >>>> 04:06 À : Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Part of my personal view is that I am trying to make this work >>>> sensibly in a more orchestrated environment. I expect that the >>>> service functions, and over time probably the SFF capabilities, >>>> will be orchestrated and installed. I expect the service chains to >>>> be driven by BSS tools that define offerings to clients, and enable >>>> self-selection from these. I expect service paths to be heavily >>>> policy drive. >>>> >>>> I can see how to make all of that work in an archtiecture driven >>>> by initial classification to described service paths. It is harder >>>> to see how to make it work (but it can be done) when we allow more >>>> dynamicity in the network behavior. >>>> >>>> Having said that, most of that perspective I described is outside >>>> of the scope of the working group. it is not something we are >>>> tasked to agree on. So I do not claim that vision means we have to >>>> do it a certain way. it is just the perspective that drives my >>>> preferences. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>> For me, the amount of information about service instances that >>>>>> needs to be widely distributed and maintained, potentially even >>>>>> across data centers within an administrative scope, is large >>>>>> enough and complex enough that trying to get that into each SFF >>>>>> seems like a difficult architecture to realize. >>>>> >>>>> I'm curious as to why that is more complicated than dynamic >>>>> routing, >>>> hyper-scale data center orchestration, or DNS, all of which are >>>> bigger problems that have been profitably and stably implemented? >>>>> >>>>> It also seems that if it really is more complicated, that is a >>>>> good sign >>>> that it is too complicated. >>>>> >>>>> ________________________________________ From: Joel M. Halpern >>>>> [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: >>>>> Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> This is an architectural issue. And one that I would prefer we >>>>> actually decide, rather than trying to allow all possible >>>>> implementations. Because it does have a major effect on the >>>>> control requirements and the functionality of SFFs. >>>>> >>>>> For me, the amount of information about service instances that >>>>> needs to be widely distributed and maintained, potentially even >>>>> across data centers within an administrative scope, is large >>>>> enough and complex enough that trying to get that into each SFF >>>>> seems like a difficult architecture to realize. >>>>> >>>>> Yours, Joel >>>>> >>>>> But it is a fair question. >>>>> >>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>>> This is the crux of my issue. Is the end to end selection of >>>>>> (top-level) instances performed centrally (perhaps by the >>>>>> classifier) or hop-by-hop (perhaps by the classifier and >>>>>> subsequently the SFFs)? Such selection is not equivalent to >>>>>> reclassification. And surely, this is an architectural issue >>>>>> and not relegated to "implementation". >>>>>> >>>>>> My own view is to favor the distributed approach even though a >>>>>> greater amount of data (chain definitions and perhaps local >>>>>> selection policy) is required at those distributed decision >>>>>> points. This approach does not require an end-to-end path id >>>>>> at all. My rationale for favoring this approach is primarily >>>>>> driven by increased resiliency over the global path id >>>>>> approach. With a global path id approach, consider failure of >>>>>> an instance and needing to alter the global path ID table for >>>>>> each and every affected end-to-end path. >>>>>> >>>>>> Ron >>>>>> >>>>>> ________________________________________ From: sfc >>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 >>>>>> PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: >>>>>> Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> The way the architecture models the case of SF1 needing to >>>>>> influence the chain is that one would do reclassification at >>>>>> the exit from SF1. >>>>>> >>>>>> Part of the goal is to keep the different functions logically >>>>>> separate so that solutions can clearly describe how they choose >>>>>> to compose them for "service" delivery. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>>> I don't see anything in the arch draft that suggests any sort >>>>>>> of limit. However, it does seem to indicate that the entire >>>>>>> path (all SFIs) must be chosen at SFC instantiation. I >>>>>>> believe this means either at the classifier or maybe the >>>>>>> classifier chooses a SF Chain and the NF or at the latest the >>>>>>> first SFF. In any case, the language does seem to prohibit a >>>>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1) >>>>>>> hop. According to the draft, this behavior would be >>>>>>> considered "branching" to a new SFP as opposed to choosing >>>>>>> and then forwarding to the selected instance of the next-hop >>>>>>> of the current SFC. >>>>>>> >>>>>>> draft-merged-sfc-architecture-00: >>>>>>>> When an SFC is instantiated into the network it is >>>>>>>> necessary to select the specific instances of SFs that will >>>>>>>> be used, and to create the service topology for that SFC >>>>>>>> using SF's network locator. Thus, instantiation of the SFC >>>>>>>> results in the creation of a Service Function Path (SFP) >>>>>>>> and is used for forwarding packets through the SFC. In >>>>>>>> other words, an SFP is the instantiation of the defined >>>>>>>> SFC. >>>>>>>> >>>>>>>> The SFC architecture supports reclassification (or >>>>>>>> non-initial classification) as well. As packets traverse >>>>>>>> an SFP, reclassification may occur - typically performed by >>>>>>>> a classification function co-resident with a service >>>>>>>> function. Reclassification may result in the selection of a >>>>>>>> new SFP, an update of the associated metadata, or both. >>>>>>>> This is referred to as "branching". >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------------------------- >>>> >>>>>>> >> - >>>>>>> >>>>>>> >>>>> *From: *I.Smith@F5.com >>>>>>> *To: *Joel Halpern Direct,Joel >>>>>>> M. >>>>>>> >>>> >> Halpern,huang@sce.carleton.ca> on.ca>,s >>>> >>>> >> fc@ietf.org >>>>>>> >>>>>>> >>>>> *Sent: *Thursday, July 10, 2014 >>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>>>>>> Balancers >>>>>>> >>>>>>> Actually, I think I am disagreeing. >>>>>>> >>>>>>> If the possibility of medium-scale deployments (and that is >>>>>>> what 16 million flows is in my world) of service chains is >>>>>>> preconceived as an absurd idea, then the architecture >>>>>>> burdened with that preconception. >>>>>>> >>>>>>> There has to be some point of aim, some degree of aspiration >>>>>>> to scale that is appropriate for the lifespan of the >>>>>>> architecture - you don't have to know what it is, but by >>>>>>> saying that an arbitrary number is "too far", you're creating >>>>>>> - even if it isn't intentional - a limit that influences >>>>>>> decisions that have lasting impacts regarding scale-out, >>>>>>> failure mitigation, elasticity, address space... all kinds of >>>>>>> things. That is a problem I'm not particularly eager to deal >>>>>>> with. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> >>>>>>> >>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>>>>>> Halpern; huang@sce.carleton.ca; sfc@ietf.org Subject: Re: >>>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>>> >>>>>>> Ian, I don't think you disagree with me at all in this >>>>>>> regard. I am not requesting the the architecture or the >>>>>>> solution prohibit deployments in the specific fashion. I am >>>>>>> objecting to Huang's reading of my note as saying that such >>>>>>> deployments are required they by the archtiecture. >>>>>>> >>>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>>> things. Whether they are a good idea or not depends upon >>>>>>> many factors outside of the scope of the WG. I happen to >>>>>>> think that they are usually a bad idea. >>>>>>> >>>>>>> But the archtiecture si carefully avoiding attempting to know >>>>>>> what is and is not eployable. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>>> I disagree. >>>>>>>> >>>>>>>> We routinely have stateful devices that manage tens of >>>>>>>> millions of >>>>>>> concurrent flows in both access network and data center >>>>>>> environments today. You can't seriously believe that in the >>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >>>>>>> going to have small numbers of service chains with equally >>>>>>> small numbers of active service paths? >>>>>>>> >>>>>>>> Your sounds too much like "no one will ever need more than >>>>>>>> 64K" for >>>>>>> comfort. >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________ From: sfc >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>>> [jmh@joelhalpern.com] >>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >>>>>>>> Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> No, it will mean that if someone tries to deploy the >>>>>>>> archtieture particularly badly, they will exceed the limits >>>>>>>> of their devices. The architecture does not require such >>>>>>>> absurd use of service paths. Since I can not figure out how >>>>>>>> to write architectural words to prohibit it, the >>>>>>>> architecture does permit such abuse. >>>>>>>> >>>>>>>> Please do not read my saying that the archtiecture permits >>>>>>>> something as saying it is either deisred or required by the >>>>>>>> work. It isn't. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>>> 16,000,000 paths. That is larger than the routing table >>>>>>>>> of a core router. >>>>>>>>> >>>>>>>>> Chang >>>>>>>>> >>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>>> service path to 160000 service paths. I would hope >>>>>>>>>> that operators are prepared for the complexities if >>>>>>>>>> they choose to avoid any use of local load balancing >>>>>>>>>> and in stead provision 160,000 service paths. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> Paul, >>>>>>>>>>> >>>>>>>>>>> How many path identifiers there will be for a 4 hop >>>>>>>>>>> service chain with 20 instances at each hop? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>>>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10, >>>>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:* >>>>>>>>>>> jmh@joelhalpern.com; mohamed.boucadair@orange.com; >>>>>>>>>>> sfc@ietf.org; mikebianc@aol.com *Subject:* Re: [sfc] >>>>>>>>>>> Service Chains, Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Lucy, >>>>>>>>>>> >>>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>>> forwarding. I'd >>>>>>> make >>>>>>>>>>> the minor change: the path identifier can be used to >>>>>>>>>>> derive the needed forwarding and associated >>>>>>>>>>> transport. >>>>>>>>>>> >>>>>>>>>>> It is _not_ the transport, but rather is used to >>>>>>>>>>> simply identify the service path (or graph) that >>>>>>>>>>> packets must traverse. By having a path identifier, >>>>>>>>>>> the exact indirection that people seem to be asking >>>>>>>>>>> for on this thread can be simply be implemented. The >>>>>>>>>>> path identifier provides nothing more than a lookup, >>>>>>>>>>> that lookup can result in a one or more (equal or >>>>>>>>>>> weighted) transport next hop(s). >>>>>>>>>>> >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Agree. The arch. doc should not mandate only use of >>>>>>>>>>> the service path identifier to drive the forwarding >>>>>>>>>>> actions. >>>>>>>>>>> >>>>>>>>>>> Lucy >>>>>>>>>>> >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>>> >>>>>>>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM >>>>>>>>>>> *To:*mikebianc@aol.com >>>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>> *Subject:*Re: [sfc] Service >>>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Re-, >>>>>>>>>>> >>>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>>> identifier. I object to use that identifier to >>>>>>>>>>> derive forwarding actions. >>>>>>>>>>> >>>>>>>>>>> Requiring a SFC system to have the full knowledge of >>>>>>>>>>> every >>>>>>> available SFC >>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>>> required/justified >>>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>>> >>>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>>> information >>>>>>> that will >>>>>>>>>>> be present in all deployments: that is the one >>>>>>>>>>> required to structure a service chain. How that >>>>>>>>>>> information is used to infer forwarding >>>>>>> actions >>>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Med >>>>>>>>>>> >>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>>> de*mikebianc@aol.com >>>>>>>>>>> *Envoyé :*mercredi 9 >>>>>>>>>>> juillet 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>> *Objet :*Re: [sfc] Service >>>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>>> >>>>>>>>>>> Is anyone still questioning the difference between SF >>>>>>>>>>> Chain and SF >>>>>>> Path? >>>>>>>>>>> Other than clarifying the definition so that it's >>>>>>>>>>> clear to >>>>>>> those not >>>>>>>>>>> familiar with the draft, it seems that everyone >>>>>>>>>>> agrees on these terms. >>>>>>>>>>> >>>>>>>>>>> To me, the one point that is still unclear is whether >>>>>>>>>>> it is the intent of this draft to ultimately specify >>>>>>>>>>> what the ID of the SFC Header >>>>>>> should >>>>>>>>>>> reference (the chain or the path), or if this draft >>>>>>>>>>> simply intends to leave that ambiguous, allowing >>>>>>>>>>> other drafts to dictate the mechanisms for forwarding >>>>>>>>>>> based on chain or path and the choice of chain or >>>>>>> path to >>>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>>> >>>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>>> require that both SFP and SFC be supported (or make >>>>>>>>>>> one required and the other optional) to avoid some >>>>>>>>>>> vendors only supporting SFP and others only >>>>>>>>>>> supporting SFC. >>>>>>>>>>> >>>>>>>>>>> >>>>>>> ----------------------------------------------------------------------- >>>> >>>>>>> >> - >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>>> > >>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>> > *Sent:*Tuesday, >>>>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths, >>>>>>>>>>> and Load Balancers >>>>>>>>>>> >>>>>>>>>>> I have been trying to figure out how to clearly >>>>>>>>>>> answer a number of comments that have been made about >>>>>>>>>>> the proposed merged archtiecture draft. Assuming we >>>>>>>>>>> can get working group agreement on the intent, we >>>>>>>>>>> will work to improve the wording so that readers who >>>>>>>>>>> have not participated in the WG discussion will >>>>>>>>>>> understnd it the way the >>>>>>> working >>>>>>>>>>> group intends. >>>>>>>>>>> >>>>>>>>>>> But what do we intend? I will try to explain my >>>>>>>>>>> personal view, and see if that helps. >>>>>>>>>>> >>>>>>>>>>> In this regard, it is important to keep in mind that >>>>>>>>>>> what we are defining is the data plane architecture. >>>>>>>>>>> We are not attempting to define the architecture for >>>>>>>>>>> the entire solution for service chaining. That would >>>>>>>>>>> encompass OSS/BSS, various control and policy >>>>>>>>>>> functions, virtual machine and image management, and >>>>>>>>>>> many other aspects. >>>>>>>>>>> >>>>>>>>>>> As a result there are many things which clearly need >>>>>>>>>>> to exist in the larger system, but which are dealt >>>>>>>>>>> with above where we are >>>>>>> functioning, >>>>>>>>>>> and are not directly required by the work we are >>>>>>>>>>> doing. >>>>>>>>>>> >>>>>>>>>>> In order to get to service chain vs service path, as >>>>>>>>>>> I understand >>>>>>> them, >>>>>>>>>>> I need to first discuss load balancing. There are at >>>>>>>>>>> least three different ways that load balancing can >>>>>>>>>>> and will interact with service chaining. There >>>>>>>>>>> probably are more. The point of the archtiecture is >>>>>>>>>>> to permit all of these, but not to mandate that any >>>>>>>>>>> particular kind >>>>>>> be used >>>>>>>>>>> in any solution. >>>>>>>>>>> >>>>>>>>>>> 1) Load balancing as a service provided to the end >>>>>>>>>>> user. This is a service function. It receives user >>>>>>>>>>> packets, and modifies them (or >>>>>>> marks >>>>>>>>>>> them, or ...) so as to choose an end user service >>>>>>>>>>> instance to receive the users packet. This is an >>>>>>>>>>> important service function to be able to include in >>>>>>>>>>> service chaining. It's behavior may affect >>>>>>>>>>> requirements on how service chaining is done. But it >>>>>>>>>>> has very little impact on the archtiecture. From an >>>>>>>>>>> architectural pe3rspective it is simply a >>>>>>> service >>>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>>> >>>>>>>>>>> 2) There is internal load balancing. That is, one can >>>>>>>>>>> have what >>>>>>> appears >>>>>>>>>>> to the service chaining architecture as a single >>>>>>>>>>> point of contact >>>>>>> for a >>>>>>>>>>> specific service function, but is actually delivered >>>>>>>>>>> by a >>>>>>> collection of >>>>>>>>>>> virtual or physical machines, possibly including one >>>>>>>>>>> or several load balancers (for example using >>>>>>>>>>> VRRP-like techniques to share a MAC address.) mostly, >>>>>>>>>>> this is invisible to the service chaining data plane >>>>>>>>>>> mechanisms. It is likely that it is visible to >>>>>>>>>>> various control mechanisms, such as those responsible >>>>>>>>>>> for scale-in, scale-out, and vm instantiation. The >>>>>>>>>>> architectural impact of permitting this is largely >>>>>>>>>>> that we need to be careful that our terminology does >>>>>>>>>>> not lead >>>>>>> readers to >>>>>>>>>>> think we are prohibiting it. >>>>>>>>>>> >>>>>>>>>>> 3) There can also be load balancing done by >>>>>>>>>>> selecting packet paths for the service chaining that >>>>>>>>>>> direct traffic to different places. We would not want >>>>>>>>>>> to require that a given service function appear at >>>>>>>>>>> only one place in the network. >>>>>>>>>>> >>>>>>>>>>> It is of course the case that these may be combined. >>>>>>>>>>> I tend to >>>>>>> refer to >>>>>>>>>>> the collection of entities that appear to service >>>>>>>>>>> chaining as a single point as a cluster. Not because >>>>>>>>>>> cluster is a good term. But because I do not have >>>>>>>>>>> another one. Thus, the point of type 3 load >>>>>>>>>>> balancing >>>>>>> is to >>>>>>>>>>> direct different subsets of traffic to different >>>>>>>>>>> singular or clustered service functions in different >>>>>>>>>>> places in the network. >>>>>>>>>>> >>>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>>> service chain and service path/ Service chain is a >>>>>>>>>>> sequence of logical functions to be applied to a >>>>>>>>>>> subset of packets. It is equivalent of saying that >>>>>>>>>>> some subset of traffic is to get DPI, charging, >>>>>>>>>>> content inspection, and firewall while a different >>>>>>>>>>> subset is to go directly to the cache >>>>>>> without >>>>>>>>>>> visiting any other service functions. >>>>>>>>>>> >>>>>>>>>>> That is not enough information to direct the packets. >>>>>>>>>>> A service path is, in some fashion, a sequence of >>>>>>>>>>> locations in the network. Those locations will be >>>>>>>>>>> singular or clustered service function delivery >>>>>>>>>>> locations. They may be addressed by IP address. They >>>>>>>>>>> may be addressed as ports on an SFF. There are many >>>>>>>>>>> different ways that the locations may be known to the >>>>>>>>>>> service chaining infrastructure and the transport. >>>>>>>>>>> >>>>>>>>>>>> From the point of view of the work of the SFC >>>>>>>>>>>> group, we need to be >>>>>>>>>>> able to talk about the high level abstraction, the >>>>>>>>>>> service chain, which drives the forwarding. And we >>>>>>>>>>> need to talk about the actual data path packets will >>>>>>>>>>> take in the network. >>>>>>>>>>> >>>>>>>>>>> Several of the comments have said "but the whole path >>>>>>>>>>> may not be known at the front." This architecture >>>>>>>>>>> deals with that issue in two ways. First, as noted in >>>>>>>>>>> item (2) on load balancers above, there can be >>>>>>>>>>> decisions and behaviors which are invisible to the >>>>>>>>>>> service chaining mechanisms (in much the same way >>>>>>>>>>> that bridging within a LAN is largely invisible to >>>>>>>>>>> routing between LANs.) The other provision we make >>>>>>>>>>> is >>>>>>> that >>>>>>>>>>> reclassification can be done in mid-chain when >>>>>>>>>>> necessary. That will direct packets to a new chain. >>>>>>>>>>> Based on information available at the >>>>>>>>>>> re-classification point. >>>>>>>>>>> >>>>>>>>>>> I hope that this helps explain what we are after. If >>>>>>>>>>> it does, and if the intent is acceptable to the >>>>>>>>>>> working group, we can figure out what additional >>>>>>>>>>> words are needed to convey this. If the working group >>>>>>>>>>> disagree with the intent, then we will of course >>>>>>>>>>> adjust to match the working group agreements. If this >>>>>>>>>>> is still unclear, I am not sure what to try next. >>>>>>>>>>> >>>>>>>>>>> Yours, Joel >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc >>>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc >>>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>> >>>> _______________________________________________ sfc mailing 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 Jul 11 06:11: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 8C7E81B282E for ; Fri, 11 Jul 2014 06:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.951 X-Spam-Level: X-Spam-Status: No, score=-13.951 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_29=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 hwgS5Y0j3o3A for ; Fri, 11 Jul 2014 06:11:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C155B1B27AB for ; Fri, 11 Jul 2014 06:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58757; q=dns/txt; s=iport; t=1405084270; x=1406293870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fKkjAHZ8UClTxhb0Pwqdo69D+BFQYOD8LDPT16u+d3o=; b=Hlpd7ILF40UbCpfBSb9EzlW/UYFgF+/cD8cbW9r6hlu+Sd8hei3s427U 1MIxwCmTJZv0BxYwPpmfoLW5BtD3igTFqg2nOjEqn0PesGtW/ZYHTPwbi pkEcN1ni+gHmho5L3L7gDHnaOR/rN9X0UYwGUSNsfCT9YvoPmfP5F+7Gw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAL/hv1OtJA2D/2dsb2JhbABPCoJHR1JagnGsAJF4AQmHQgEZcRZ1hAMBAQEEAQEBFwkKOAkLEAIBBgIOAwECAQEBIQEGAwICAiULFAMGCAIEAQ0FG4gTAxENkSCcJ5kIEwSNGoFQSwcGBAYBgneBTAWWIkmEGotniDSDRIIw X-IronPort-AV: E=Sophos; i="5.01,643,1400025600"; d="scan'208,217"; a="60072223" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 11 Jul 2014 13:11:09 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6BDB9bE001415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:11:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 08:11:09 -0500 From: "Jim Guichard (jguichar)" To: Qin Wu , "mikebianc@aol.com" , "mn1921@att.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAXQIAgABkqYCAAGsUAA== Date: Fri, 11 Jul 2014 13:11:08 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE559FB2D187jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/v-wPJVLwcRKdXi5NKz2ea_Eqx2s Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:11:19 -0000 --_000_CFE559FB2D187jguicharciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UWluLA0KDQpXaGljaCBpcyBwcmVjaXNlbHkgd2hhdCBvbmUgd2FudHMgYXMgdGhlIG11bHRpcGxl IFNGUOKAmXMgYWxsb3cgdHJhZmZpYyB0byBiZSBkaXN0cmlidXRlZCB0aHJvdWdoIHRoZSBuZXR3 b3JrIHNvIHRoYXQgdGhlIHNhbWUgYWJzdHJhY3RlZCBjaGFpbiBjYW4gYmUgc2VydmVkIHdpdGhv dXQgdHJhZmZpYyBmb3IgdGhhdCBjaGFpbiB0YWtpbmcgdGhlIGV4YWN0IHNhbWUgcGF0aCB0aHJv dWdoIHRoZSBuZXR3b3JrIGZvciBtdWx0aXBsZSBmbG93cy4NCg0KRnJvbTogUWluIFd1IDxiaWxs Lnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+DQpEYXRlOiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCBhdCAxMDo0NiBQTQ0KVG86ICJtaWtlYmlhbmNAYW9sLmNvbTxtYWls dG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPj4sIEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4i IDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KQ2M6ICJzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCg0KSWYgb25lIHNlcnZpY2UgY2hhaW4gY2FuIGNvcnJlc3BvbmRpbmcgdG8gbXVs dGlwbGUgc2VydmljZSBmdW5jdGlvbiBwYXRocyxlIC5nLiwgaW4gY2FzZSBvZiBhbGwgYWN0aXZl IHJlZHVuY3ksDQpJIHRoaW5rIHVzaW5nIGNoYWluIGlkZW50aWZpZXIgaXMgbW9yZSByZWFzb25h YmxlIGNob2ljZSBzaW5jZSBwYXRoIGlkIGlzIG5vdCB1bmlxdWUgaW4gdGhpcyBjYXNlLg0KDQpS ZWdhcmRzIQ0KLVFpbg0K5Y+R5Lu25Lq6OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCuWP kemAgeaXtumXtDogMjAxNOW5tDfmnIgxMeaXpSA0OjQ3DQrmlLbku7bkuro6IGpndWljaGFyQGNp c2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgbW4xOTIxQGF0dC5jb208bWFpbHRv Om1uMTkyMUBhdHQuY29tPg0K5oqE6YCBOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCuS4u+mimDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQoNCg0KSmltLA0KDQpUZWNobmljYWxseSwgd291bGRuJ3QgdGhpcyBiZSBhIENoYWlu IElkZW50aWZpZXIgaWYgdGhlIG5leHQgaW5zdGFuY2UgaXMgY2hvc2VuIGF0IGVhY2ggaG9wPyAg SW4gdGhpcyBjYXNlLCB0aGVyZSB3b3VsZG4ndCBiZSBhbnkgUGF0aCBJZGVudGlmaWVyIGF0IGFs bC4NCg0KQnV0IGl0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBjbGFzc2lmaWVyIG5lZWRp bmcgdG8gdHJhY2sgdGhlIGhlYWx0aCwgZXRjIG9mIDIwXjQgU0YgUGF0aHMgZm9yIGEgc2luZ2xl IFNGIENoYWluLCB2cyBlYWNoIG9mIHRoZSA4MCBpbnN0YW5jZXMgdHJhY2tpbmcgMjAgU0ZJcyBv ZiB0aGUgbmV4dC1ob3AgZm9yIHRoZSBjaGFpbnMgb2Ygd2hpY2ggdGhleSBhcmUgbWVtYmVycyB2 cyBlYWNoIFNGRiBpbiB0aGUgZW50aXJlIGRvbWFpbiB0cmFja2luZyBhbGwgODAgU0ZJcyB2cyBz b21ldGhpbmcgZWxzZS4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEg SDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KY2M6IFBhdWwgUXVpbm4g KHBhdWxxKTxwYXVscUBjaXNjby5jb208bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+LEx1Y3kgeW9u ZzxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PixqbWhA am9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT48bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4+LG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT48bWlr ZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4NClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCjEgYXNzdW1pbmcgbG9hZCBpcyBkaXN0cmlidXRlZCBhbW9u ZyB0aGUgMjAgaW5zdGFuY2VzIGF0IGVhY2ggc2VydmljZSBob3AuDQoNClNlbnQgZnJvbSBteSBp UGhvbmUNCg0KT24gSnVsIDEwLCAyMDE0LCBhdCA0OjA3IFBNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQpQYXVsLA0K SG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgaG9wIHNlcnZp Y2UgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQpNYXJpYQ0KRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIFF1aW5uIChw YXVscSkNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDM6MDMgUE0NClRvOiBMdWN5IHlv bmcNCkNjOiBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsgbWlrZWJpYW5jQGFv bC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpMdWN5LA0KT3ZlcmFsbCBJIGNv bmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gSeKAmWQg bWFrZSB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRv IGRlcml2ZSB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0K SXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvIHNpbXBseSBp ZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzIG11c3QgdHJh dmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0IGluZGlyZWN0aW9u IHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzIHRocmVhZCBjYW4gYmUg c2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aCBpZGVudGlmaWVyIHByb3ZpZGVzIG5vdGhp bmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4gcmVzdWx0IGluIGEgb25lIG9y IG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dCBob3AocykuDQpQYXVsDQpP biBKdWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpBZ3JlZS4gVGhlIGFy Y2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlIHNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQpMdWN5DQpGcm9tOnNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXU9uIEJlaGFsZiBPZiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjowNiBBTQ0KVG86IG1pa2ViaWFuY0Bhb2wuY29t PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN ClJlLSwNClRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBh dGggaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUg Zm9yd2FyZGluZyBhY3Rpb25zLg0KUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBm dWxsIGtub3dsZWRnZSBvZiBldmVyeSBhdmFpbGFibGUgU0ZDIGZvcndhcmRpbmcgcGF0aHMgd2l0 aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5vciBw b3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQpTRkMgZm9yd2FyZGluZyBh Y3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwg YmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0 byBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcyB1c2Vk IHRvIGluZmVyIGZvcndhcmRpbmcgYWN0aW9ucyBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1 c3Npb24uDQpDaGVlcnMsDQpNZWQNCkRlIDpzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z11EZSBsYSBwYXJ0IGRlIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4NCkVudm95w6kgOiBtZXJjcmVkaSA5IGp1aWxsZXQgMjAxNCAyMjowMw0Kw4AgOiBqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQpJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFpbiBhbmQgU0YgUGF0aD8gT3RoZXIgdGhhbiBjbGFyaWZ5 aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxp YXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uIHRoZXNl IHRlcm1zLg0KVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdo ZXRoZXIgaXQgaXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lm eSB3aGF0IHRoZSBJRCBvZiB0aGUgU0ZDIEhlYWRlciBzaG91bGQgcmVmZXJlbmNlICh0aGUgY2hh aW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBseSBpbnRlbmRzIHRvIGxlYXZl IHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8gZGljdGF0ZSB0aGUgbWVj aGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvciBwYXRoIGFuZCB0aGUgY2hv aWNlIG9mIGNoYWluIG9yIHBhdGggdG8gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFu ZS4NCklmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUg cmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZSBy ZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25s eSBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTpqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj4NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogVHVlc2RheSwgSnVseSA4LCAy MDE0DQpTdWJqZWN0OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KDQpJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBh bnN3ZXIgYSBudW1iZXIgb2YNCmNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhl IHByb3Bvc2VkIG1lcmdlZCBhcmNodGllY3R1cmUNCmRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0 IHdvcmtpbmcgZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlDQp3aWxsIHdvcmsgdG8g aW1wcm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90DQpwYXJ0aWNp cGF0ZWQgaW4gdGhlIFdHIGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUg d29ya2luZw0KZ3JvdXAgaW50ZW5kcy4NCg0KQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwg dHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZQ0KaWYgdGhhdCBoZWxwcy4N Cg0KSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdCB3 aGF0IHdlIGFyZQ0KZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBh cmUgbm90IGF0dGVtcHRpbmcgdG8NCmRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50 aXJlIHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLg0KVGhhdCB3b3VsZCBlbmNvbXBhc3Mg T1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KdmlydHVhbCBt YWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLg0KDQpB cyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvIGV4 aXN0IGluIHRoZQ0KbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3Zl IHdoZXJlIHdlIGFyZSBmdW5jdGlvbmluZywNCmFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVk IGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy4NCg0KSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2Ug Y2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwNCkkgbmVlZCB0byBm aXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUNCmRp ZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdp dGggc2VydmljZQ0KY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLiBUaGUgcG9pbnQg b2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0bw0KcGVybWl0IGFsbCBvZiB0aGVzZSwgYnV0IG5vdCB0 byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZCBiZSB1c2VkDQppbiBhbnkgc29sdXRp b24uDQoNCjEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5k IHVzZXIuIFRoaXMgaXMgYQ0Kc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNr ZXRzLCBhbmQgbW9kaWZpZXMgdGhlbSAob3IgbWFya3MNCnRoZW0sIG9yIC4uLikgc28gYXMgdG8g Y2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZQ0KdGhlIHVzZXJz IHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZSBmdW5jdGlvbiB0byBiZSBhYmxl IHRvDQppbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MgYmVoYXZpb3IgbWF5IGFmZmVj dCByZXF1aXJlbWVudHMgb24NCmhvdyBzZXJ2aWNlIGNoYWluaW5nIGlzIGRvbmUuIEJ1dCBpdCBo YXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KYXJjaHRpZWN0dXJlLiBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhIHNlcnZpY2UNCmZ1bmN0aW9uIHdo aWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KDQoyKSBUaGVyZSBpcyBpbnRl cm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZlIHdoYXQgYXBwZWFycw0K dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9m IGNvbnRhY3QgZm9yIGENCnNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxs eSBkZWxpdmVyZWQgYnkgYSBjb2xsZWN0aW9uIG9mDQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hp bmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZA0KYmFsYW5jZXJzIChm b3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQw0KYWRk cmVzcy4pIG1vc3RseSwgdGhpcyBpcyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcg ZGF0YSBwbGFuZQ0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0 byB2YXJpb3VzIGNvbnRyb2wNCm1lY2hhbmlzbXMsIHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUg Zm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hp dGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1pdHRpbmcgdGhpcyBpcyBsYXJnZWx5DQp0aGF0IHdlIG5l ZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBkb2VzIG5vdCBsZWFkIHJlYWRl cnMgdG8NCnRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCg0KMykgVGhlcmUgY2FuIGFsc28g YmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcgcGFja2V0IHBhdGhzIGZvcg0KdGhl IHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2Vz LiBXZSB3b3VsZA0Kbm90IHdhbnQgdG8gcmVxdWlyZSB0aGF0IGEgZ2l2ZW4gc2VydmljZSBmdW5j dGlvbiBhcHBlYXIgYXQgb25seSBvbmUNCnBsYWNlIGluIHRoZSBuZXR3b3JrLg0KDQpJdCBpcyBv ZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZCB0byBy ZWZlciB0bw0KdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2Vydmlj ZSBjaGFpbmluZyBhcyBhIHNpbmdsZQ0KcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBj bHVzdGVyIGlzIGEgZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJDQpkbyBub3QgaGF2ZSBhbm90aGVy IG9uZS4gVGh1cywgdGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZyBpcyB0bw0KZGly ZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyIG9y IGNsdXN0ZXJlZA0Kc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUg bmV0d29yay4NCg0KTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFs ayBhYm91dCBzZXJ2aWNlIGNoYWluIGFuZA0Kc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlz IGEgc2VxdWVuY2Ugb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUNCmFwcGxpZWQgdG8gYSBzdWJz ZXQgb2YgcGFja2V0cy4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lDQpzdWJz ZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9u LCBhbmQNCmZpcmV3YWxsIHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3Rs eSB0byB0aGUgY2FjaGUgd2l0aG91dA0KdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rp b25zLg0KDQpUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNr ZXRzLiBBIHNlcnZpY2UgcGF0aA0KaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZiBs b2NhdGlvbnMgaW4gdGhlIG5ldHdvcmsuIFRob3NlDQpsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxh ciBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeQ0KbG9jYXRpb25zLiBUaGV5 IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkDQph cyBwb3J0cyBvbiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhl IGxvY2F0aW9ucw0KbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3Ry dWN0dXJlIGFuZCB0aGUgdHJhbnNwb3J0Lg0KDQo+RnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0 aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRvIGJlIGFibGUNCnRvIHRhbGsgYWJv dXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlIGNoYWluLCB3aGljaA0K ZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBhY3R1 YWwgZGF0YSBwYXRoDQpwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay4NCg0KU2V2ZXJh bCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGggbWF5IG5vdCBi ZSBrbm93bg0KYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aCB0aGF0 IGlzc3VlIGluIHR3byB3YXlzLg0KRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQg YmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUNCmRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdo aWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcNCm1lY2hhbmlzbXMgKGlu IG11Y2ggdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkN CmludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24g d2UgbWFrZSBpcyB0aGF0DQpyZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFp biB3aGVuIG5lY2Vzc2FyeS4gVGhhdCB3aWxsDQpkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFp bi4gQmFzZWQgb24gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZQ0KcmUtY2xhc3NpZmljYXRp b24gcG9pbnQuDQoNCkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBh ZnRlci4gSWYgaXQgZG9lcywgYW5kIGlmDQp0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhl IHdvcmtpbmcgZ3JvdXAsIHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQNCmFkZGl0aW9uYWwgd29yZHMg YXJlIG5lZWRlZCB0byBjb252ZXkgdGhpcy4NCklmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVl IHdpdGggdGhlIGludGVudCwgdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZQ0KYWRqdXN0IHRvIG1hdGNo IHRoZSB3b3JraW5nIGdyb3VwIGFncmVlbWVudHMuDQpJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIs IEkgYW0gbm90IHN1cmUgd2hhdCB0byB0cnkgbmV4dC4NCg0KWW91cnMsDQpKb2VsDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBs aXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_CFE559FB2D187jguicharciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6D042D1BBF4A9149BC90BF6C15D351D2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5RaW4sPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGljaCBpcyBwcmVjaXNlbHkgd2hhdCBvbmUgd2Fu dHMgYXMgdGhlIG11bHRpcGxlIFNGUOKAmXMgYWxsb3cgdHJhZmZpYyB0byBiZSBkaXN0cmlidXRl ZCB0aHJvdWdoIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIHNhbWUgYWJzdHJhY3RlZCBjaGFpbiBj YW4gYmUgc2VydmVkIHdpdGhvdXQgdHJhZmZpYyBmb3IgdGhhdCBjaGFpbiB0YWtpbmcgdGhlIGV4 YWN0IHNhbWUgcGF0aCB0aHJvdWdoIHRoZSBuZXR3b3JrIGZvciBtdWx0aXBsZSBmbG93cy4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+UWluIFd1ICZsdDs8YSBocmVmPSJt YWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgYXQgMTA6NDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1p a2ViaWFuY0Bhb2wuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7LCBKaW0gR3VpY2hhcmQgJmx0OzxhIGhy ZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9h PiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQu Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bh bj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2Zm aWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxu czptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHht bG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEt LVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6 KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZh dWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxl PjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAy IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+ac rCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo 5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5JZiBvbmUgc2VydmljZSBjaGFpbiBjYW4gY29ycmVzcG9uZGluZyB0byBtdWx0aXBs ZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzLGUgLmcuLCBpbiBjYXNlIG9mIGFsbCBhY3RpdmUgcmVk dW5jeSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIHRoaW5rIHVzaW5nIGNo YWluIGlkZW50aWZpZXIgaXMgbW9yZSByZWFzb25hYmxlIGNob2ljZSBzaW5jZSBwYXRoIGlkIGlz IG5vdCB1bmlxdWUgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJlZ2FyZHMhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJp YW5jQGFvbC5jb208L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFu PuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDQ6 NDc8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gPGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+ DQpqZ3VpY2hhckBjaXNjby5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20i Pm1uMTkyMUBhdHQuY29tPC9hPjxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyI+PGJyPg0KSmltLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+VGVjaG5pY2FsbHksIHdvdWxkbid0IHRoaXMg YmUgYSBDaGFpbiBJZGVudGlmaWVyIGlmIHRoZSBuZXh0IGluc3RhbmNlIGlzIGNob3NlbiBhdCBl YWNoIGhvcD8gJm5ic3A7SW4gdGhpcyBjYXNlLCB0aGVyZSB3b3VsZG4ndCBiZSBhbnkgUGF0aCBJ ZGVudGlmaWVyIGF0IGFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsiPkJ1dCBpdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgY2xhc3NpZmllciBu ZWVkaW5nIHRvIHRyYWNrIHRoZSBoZWFsdGgsIGV0YyBvZiAyMF40IFNGIFBhdGhzIGZvciBhIHNp bmdsZSBTRiBDaGFpbiwgdnMgZWFjaCBvZiB0aGUgODAgaW5zdGFuY2VzIHRyYWNraW5nIDIwIFNG SXMNCiBvZiB0aGUgbmV4dC1ob3AgZm9yIHRoZSBjaGFpbnMgb2Ygd2hpY2ggdGhleSBhcmUgbWVt YmVycyB2cyBlYWNoIFNGRiBpbiB0aGUgZW50aXJlIGRvbWFpbiB0cmFja2luZyBhbGwgODAgU0ZJ cyB2cyBzb21ldGhpbmcgZWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9y OiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86amd1 aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb20m bHQ7amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFMQSwg TUFSSUEgSCZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29t PC9hPiZndDs8YnI+DQo8Yj5jYzogPC9iPlBhdWwgUXVpbm4gKHBhdWxxKSZsdDs8YSBocmVmPSJt YWlsdG86cGF1bHFAY2lzY28uY29tIj5wYXVscUBjaXNjby5jb208L2E+Jmd0OyxMdWN5IHlvbmcm bHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+ am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZsdDs8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9s LmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNA YW9sLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4xIGFzc3VtaW5nIGxvYWQgaXMgZGlzdHJpYnV0ZWQgYW1vbmcgdGhlIDIwIGluc3RhbmNlcyBh dCBlYWNoIHNlcnZpY2UgaG9wLjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiBKdWwg MTAsIDIwMTQsIGF0IDQ6MDcgUE0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPlBhdWwsDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiPkhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBi ZSBmb3IgYSA0IGhvcCBzZXJ2aWNlIGNoYWluIHdpdGggMjANCiBpbnN0YW5jZXMgYXQgZWFjaCBo b3A/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5NYXJpYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+IHNmYw0KIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxi Pk9uIEJlaGFsZiBPZg0KPC9iPlBhdWwgUXVpbm4gKHBhdWxxKTxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBMdWN5IHlvbmc8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5MdWN5LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPk92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2 ZXMgdGhlIGZvcndhcmRpbmcuIEnigJlkIG1ha2UgdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGgg aWRlbnRpZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUgdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFu ZA0KIGFzc29jaWF0ZWQgdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIF9u b3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0byBzaW1wbHkgaWRlbnRpZnkg dGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cyBtdXN0IHRyYXZlcnNlLiBC eSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KIGluZGlyZWN0aW9uIHRoYXQg cGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzIHRocmVhZCBjYW4gYmUgc2ltcGx5 IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aCBpZGVudGlmaWVyIHByb3ZpZGVzIG5vdGhpbmcgbW9y ZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4gcmVzdWx0IGluIGEgb25lIG9yIG1vcmUg KGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dCBob3AocykuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBK dWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+QWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNl IG9mIHRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5n IGFjdGlvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5MdWN5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1z ZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5z ZmMNCiBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9zcGFuPjwvYj48YSBocmVmPSJtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwv YT48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4g PC9zcGFuPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+IDwvc3Bhbj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+UmUtLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+VGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQg ZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UNCiB0 aGF0IGlkZW50aWZpZXIgdG8gZGVyaXZlIGZvcndhcmRpbmcgYWN0aW9ucy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PlJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZl cnkgYXZhaWxhYmxlIFNGQyBmb3J3YXJkaW5nDQogcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVk IGRvbWFpbiBpcyBub3QgcmVxdWlyZWQvanVzdGlmaWVkIG5vciBwb3NzaWJsZSBpbiB2YXJpb3Vz IGRlcGxveW1lbnQgY29udGV4dHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5TRkMgZm9yd2FyZGluZyBhY3Rpb25z IHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiB0aGF0IHdpbGwgYmUgcHJl c2VudA0KIGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lIHJlcXVpcmVkIHRvIHN0 cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgdG8g aW5mZXIgZm9yd2FyZGluZyBhY3Rpb25zIGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lv bi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPkNoZWVycyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk1lZDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RGUgOjwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij48L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyI+c2ZjDQogWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48Yj5E ZSBsYSBwYXJ0IGRlPC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208 L2E+PGJyPg0KPGI+RW52b3nDqSA6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiA8L3NwYW4+bWVyY3JlZGkgOSBqdWlsbGV0IDIwMTQgMjI6MDM8YnI+DQo8Yj7DgCA6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQgOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4gPC9zcGFuPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyI+SXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gU0YgQ2hhaW4gYW5kIFNGIFBhdGg/IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUg ZGVmaW5pdGlvbg0KIHNvIHRoYXQgaXQncyBjbGVhciB0byB0aG9zZSBub3QgZmFtaWxpYXIgd2l0 aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uIHRoZXNlIHRlcm1z Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyI+VG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdo ZXRoZXIgaXQgaXMgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lm eQ0KIHdoYXQgdGhlIElEIG9mIHRoZSBTRkMgSGVhZGVyIHNob3VsZCByZWZlcmVuY2UgKHRoZSBj aGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5IGludGVuZHMgdG8gbGVh dmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyIGRyYWZ0cyB0byBkaWN0YXRlIHRoZSBt ZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluIG9yIHBhdGggYW5kIHRoZSBj aG9pY2Ugb2YgY2hhaW4gb3IgcGF0aCB0byBiZSBuZWdvdGlhdGVkDQogaW4gdGhlIGNvbnRyb2wt cGxhbmUuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyI+SWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQg d291bGQgaGF2ZSByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9y IG1ha2UNCiBvbmUgcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29t ZSB2ZW5kb3JzIG9ubHkgc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcg U0ZDLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48 c3BhbiBsYW5nPSJFTi1VUyI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIg c3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBq b2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiA8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiA8L3NwYW4+PC9iPlR1ZXNkYXksIEp1bHkgOCwgMjAxNDxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+IDwvc3Bhbj48L2I+W3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpJIGhhdmUgYmVl biB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYSBudW1iZXIgb2Y8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KY29tbWVudHMg dGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQgbWVyZ2VkIGFyY2h0aWVjdHVy ZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpkcmFmdC4g QXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nIGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50 LCB3ZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQp3aWxs IHdvcmsgdG8gaW1wcm92ZSB0aGUgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnBhcnRpY2lw YXRlZCBpbiB0aGUgV0cgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZSB3 b3JraW5nPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmdy b3VwIGludGVuZHMuPGJyPg0KPGJyPg0KQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5 IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwgdmlldywgYW5kIHNlZTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQppZiB0aGF0IGhlbHBzLjxicj4NCjxicj4NCklu IHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdCB3 ZSBhcmU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KZGVm aW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90IGF0dGVtcHRp bmcgdG88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KZGVm aW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUgc29sdXRpb24gZm9yIHNlcnZpY2Ug Y2hhaW5pbmcuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4N ClRoYXQgd291bGQgZW5jb21wYXNzIE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5 IGZ1bmN0aW9ucyw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJy Pg0KdmlydHVhbCBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBh c3BlY3RzLjxicj4NCjxicj4NCkFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGlj aCBjbGVhcmx5IG5lZWQgdG8gZXhpc3QgaW4gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PC9zcGFuPjxicj4NCmxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQg d2l0aCBhYm92ZSB3aGVyZSB3ZSBhcmUgZnVuY3Rpb25pbmcsPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVk IGJ5IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnI+DQo8YnI+DQpJbiBvcmRlciB0byBnZXQgdG8g c2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkgdW5kZXJzdGFuZCB0aGVtLDxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmRpZmZlcmVudCB3YXlz IHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsIGludGVyYWN0IHdpdGggc2VydmljZTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpjaGFpbmluZy4g VGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuIFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlz IHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnBlcm1p dCBhbGwgb2YgdGhlc2UsIGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtp bmQgYmUgdXNlZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+ DQppbiBhbnkgc29sdXRpb24uPGJyPg0KPGJyPg0KMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2 aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci4gVGhpcyBpcyBhPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2Vp dmVzIHVzZXIgcGFja2V0cywgYW5kIG1vZGlmaWVzIHRoZW0gKG9yIG1hcmtzPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnRoZW0sIG9yIC4uLikgc28gYXMg dG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UgdG8gcmVjZWl2ZTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQp0aGUgdXNlcnMgcGFja2V0 LiBUaGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGJlIGFibGUgdG88c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KaW5jbHVkZSBpbiBz ZXJ2aWNlIGNoYWluaW5nLiBJdCdzIGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9u PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmhvdyBzZXJ2 aWNlIGNoYWluaW5nIGlzIGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRo ZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQphcmNodGll Y3R1cmUuIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGEg c2VydmljZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpm dW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC48YnI+DQo8YnI+ DQoyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBo YXZlIHdoYXQgYXBwZWFyczxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bh bj48YnI+DQp0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUg cG9pbnQgb2YgY29udGFjdCBmb3IgYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui Pjwvc3Bhbj48YnI+DQpzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkg ZGVsaXZlcmVkIGJ5IGEgY29sbGVjdGlvbiBvZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjwvc3Bhbj48YnI+DQp2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJs eSBpbmNsdWRpbmcgb25lIG9yIHNldmVyYWwgbG9hZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAt bGlrZSB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PC9zcGFuPjxicj4NCmFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMgaW52aXNpYmxl IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmU8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KbWVjaGFuaXNtcy4gSXQgaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KbWVjaGFuaXNtcywgc3VjaCBhcyB0aG9zZSByZXNwb25z aWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1 cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nIHRoaXMgaXMgbGFyZ2VseTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQp0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1 bCB0aGF0IG91ciB0ZXJtaW5vbG9neSBkb2VzIG5vdCBsZWFkIHJlYWRlcnMgdG88c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KdGhpbmsgd2UgYXJlIHByb2hp Yml0aW5nIGl0Ljxicj4NCjxicj4NCjMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5n IGRvbmUgYnkgc2VsZWN0aW5nIHBhY2tldCBwYXRocyBmb3I8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJl Y3QgdHJhZmZpYyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZDxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpub3Qgd2FudCB0byByZXF1aXJlIHRoYXQg YSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZTxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpwbGFjZSBpbiB0aGUgbmV0d29yay48 YnI+DQo8YnI+DQpJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgY29t YmluZWQuIEkgdGVuZCB0byByZWZlciB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjwvc3Bhbj48YnI+DQp0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0 byBzZXJ2aWNlIGNoYWluaW5nIGFzIGEgc2luZ2xlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PC9zcGFuPjxicj4NCnBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1 c3RlciBpcyBhIGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS4gVGh1cywg dGhlIHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZyBpcyB0bzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMg b2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIgb3IgY2x1c3RlcmVkPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnNlcnZpY2UgZnVuY3Rpb25zIGlu IGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KTm93IHdpdGggdGhh dCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dCBzZXJ2aWNlIGNoYWluIGFu ZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpzZXJ2aWNl IHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZSBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0 byBiZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQphcHBs aWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuIEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRo YXQgc29tZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpz dWJzZXQgb2YgdHJhZmZpYyBpcyB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0 aW9uLCBhbmQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0K ZmlyZXdhbGwgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRo ZSBjYWNoZSB3aXRob3V0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFu Pjxicj4NCnZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy48YnI+DQo8YnI+DQpU aGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBIHNl cnZpY2UgcGF0aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+ DQppcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucyBpbiB0aGUgbmV0 d29yay4gVGhvc2U8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJy Pg0KbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b24gZGVsaXZlcnk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJy Pg0KbG9jYXRpb25zLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBt YXkgYmUgYWRkcmVzc2VkPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFu Pjxicj4NCmFzIHBvcnRzIG9uIGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMg dGhhdCB0aGUgbG9jYXRpb25zPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9z cGFuPjxicj4NCm1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVj dHVyZSBhbmQgdGhlIHRyYW5zcG9ydC48YnI+DQo8YnI+DQomZ3Q7RnJvbSB0aGUgcG9pbnQgb2Yg dmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZSBuZWVkIHRvIGJlIGFibGU8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KdG8gdGFsayBhYm91 dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlIHNlcnZpY2UgY2hhaW4sIHdoaWNoPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmRyaXZlcyB0aGUg Zm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsayBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0 aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+DQpwYWNrZXRz IHdpbGwgdGFrZSBpbiB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgJnF1b3Q7YnV0IHRoZSB3aG9sZSBwYXRoIG1heSBub3QgYmUga25vd248 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0KYXQgdGhlIGZy b250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoIHRoYXQgaXNzdWUgaW4gdHdv IHdheXMuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCkZp cnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBvbiBsb2FkIGJhbGFuY2VycyBhYm92ZSwgdGhlcmUg Y2FuIGJlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmRl Y2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmc8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48L3NwYW4+PGJyPg0K bWVjaGFuaXNtcyAoaW4gbXVjaCB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBM QU4gaXMgbGFyZ2VseTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48 YnI+DQppbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXIgcHJvdmlz aW9uIHdlIG1ha2UgaXMgdGhhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwv c3Bhbj48YnI+DQpyZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVu IG5lY2Vzc2FyeS4gVGhhdCB3aWxsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PC9zcGFuPjxicj4NCmRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbiBpbmZv cm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PC9zcGFuPjxicj4NCnJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Ljxicj4NCjxicj4NCkkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQgZG9lcywg YW5kIGlmPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCnRo ZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZyBncm91cCwgd2UgY2FuIGZpZ3Vy ZSBvdXQgd2hhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjwvc3Bhbj48YnI+ DQphZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8gY29udmV5IHRoaXMuPGJyPg0KSWYgdGhl IHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50ZW50LCB0aGVuIHdlIHdpbGwgb2Yg Y291cnNlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PC9zcGFuPjxicj4NCmFk anVzdCB0byBtYXRjaCB0aGUgd29ya2luZyBncm91cCBhZ3JlZW1lbnRzLjxicj4NCklmIHRoaXMg aXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIHRyeSBuZXh0Ljxicj4NCjxi cj4NCllvdXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_CFE559FB2D187jguicharciscocom_-- From nobody Fri Jul 11 06:14: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 365C21B27F3 for ; Fri, 11 Jul 2014 06:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXwxW7HMELm0 for ; Fri, 11 Jul 2014 06:14:15 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ACD1A03B9 for ; Fri, 11 Jul 2014 06:14:14 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 723efb35.2b99576be940.4564816.00-2478.12647647.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:14:15 +0000 (UTC) X-MXL-Hash: 53bfe32710c17172-7b5f4cfa7be32b343ffd6060b7ef8f47e7ee702e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 9c2efb35.0.4564085.00-2122.12645512.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:12:42 +0000 (UTC) X-MXL-Hash: 53bfe2ca477f611c-83f5a2b2923eeca6ac40b2dfdedd62201bb327b7 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDCe6U018131; Fri, 11 Jul 2014 09:12:41 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDCYJX017935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:12:36 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:12:12 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:09:18 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAihoAgAAJJ4CAAAULAP//vwFA Date: Fri, 11 Jul 2014 13:09:17 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> In-Reply-To: <53BFDF76.7050202@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=SIxJ8] X-AnalysisOut: [35DLtwgpZVDrTkA:9 a=wPNLvfGTeEIA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=hPjdaMEvmhQA:10 a=2Vz28ZAdlnCOM5WA:21 a=Yd3KPm] X-AnalysisOut: [B2GACGRlm5:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RqGFLGKKlZihNyxAkWLZASiyt7Q Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:14:19 -0000 > So let me say again: the curent archtiecture proposal meets the > requirement you state. It allows for, but does not require central laod > balancing. It allows for, but does not require, local load balancing of > various kinds at or with the SFF. We have discussed it yesterday that the language in the current architectur= e proposal precludes local load balancing.=20 And that re-classification is not "it". Maria =20 >=20 > On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: > > Joel, > > > > The architecture has to make NO assumptions on the actual > configuration/behavior of SFFs (whether none, some, or all of them are > stateful, flow-aware co-located with LBs/etc.). This is deployment-specif= ic. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >> Envoy=E9 : vendredi 11 juillet 2014 14:08 > >> =C0 : Ron Parker; sfc@ietf.org > >> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> And it was pointed out to me that I made a two letter major typo. > >> > >> I was trying to say that I felt that such a requirement on all SFF wou= ld > >> be an UNacceptable imposition. > >> > >> Yours, > >> Joel > >> > >> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > >>> Ron, thinking about this, I realized another major problem with the > your > >>> proposal as I understand it. (And I readily admit I may not understa= nd > >>> it.) > >>> > >>> The proposal has each SFF serve as the load balancer for the next > >>> service function that follows it (not the one it delivers to), in eve= ry > >>> service chain that goes through it. > >>> > >>> Since it has to be able to work with all services, that means that ev= ery > >>> SFF would have to be a full, flow sensitive and stateful load balance= r. > >>> I ahve no problem if some SFF are flow sensitive, and / or stateful. = But > >>> having the architecture require that every SFF be a full, flow > >>> sensitive, stateful, load balancer seems to me to be an acceptable > >>> imposition. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >>>> Part of my personal view is that I am trying to make this work sensi= bly > >>>> in a more orchestrated environment. I expect that the service > >>>> functions, and over time probably the SFF capabilities, will be > >>>> orchestrated and installed. I expect the service chains to be drive= n by > >>>> BSS tools that define offerings to clients, and enable self-selectio= n > >>>> from these. I expect service paths to be heavily policy drive. > >>>> > >>>> I can see how to make all of that work in an archtiecture driven by > >>>> initial classification to described service paths. It is harder to = see > >>>> how to make it work (but it can be done) when we allow more > dynamicity > >>>> in the network behavior. > >>>> > >>>> Having said that, most of that perspective I described is outside of= the > >>>> scope of the working group. it is not something we are tasked to > >>>> agree on. > >>>> So I do not claim that vision means we have to do it a certain way. = it > >>>> is just the perspective that drives my preferences. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>>>> For me, the amount of information about service instances that > needs > >> to > >>>>>> be widely distributed and maintained, potentially even across data > >>>>>> centers within an administrative scope, is large enough and > complex > >>>>>> enough that trying to get that into each SFF seems like a difficul= t > >>>>>> architecture to realize. > >>>>> > >>>>> I'm curious as to why that is more complicated than dynamic routing= , > >>>>> hyper-scale data center orchestration, or DNS, all of which are big= ger > >>>>> problems that have been profitably and stably implemented? > >>>>> > >>>>> It also seems that if it really is more complicated, that is a good > >>>>> sign that it is too complicated. > >>>>> > >>>>> ________________________________________ > >>>>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>>>> Sent: Thursday, July 10, 2014 9:45 PM > >>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >>>>> sfc@ietf.org > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> This is an architectural issue. And one that I would prefer we > >> actually > >>>>> decide, rather than trying to allow all possible implementations. > >>>>> Because it does have a major effect on the control requirements and > the > >>>>> functionality of SFFs. > >>>>> > >>>>> For me, the amount of information about service instances that > needs to > >>>>> be widely distributed and maintained, potentially even across data > >>>>> centers within an administrative scope, is large enough and complex > >>>>> enough that trying to get that into each SFF seems like a difficult > >>>>> architecture to realize. > >>>>> > >>>>> Yours, > >>>>> Joel > >>>>> > >>>>> But it is a fair question. > >>>>> > >>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>>>> This is the crux of my issue. Is the end to end selection of > >>>>>> (top-level) instances performed centrally (perhaps by the classifi= er) > >>>>>> or hop-by-hop (perhaps by the classifier and subsequently the > SFFs)? > >>>>>> Such selection is not equivalent to reclassification. And surely= , > >>>>>> this is an architectural issue and not relegated to > >>>>>> "implementation". > >>>>>> > >>>>>> My own view is to favor the distributed approach even though a > >>>>>> greater amount of data (chain definitions and perhaps local > selection > >>>>>> policy) is required at those distributed decision points. This > >>>>>> approach does not require an end-to-end path id at all. My > >>>>>> rationale for favoring this approach is primarily driven by increa= sed > >>>>>> resiliency over the global path id approach. With a global path = id > >>>>>> approach, consider failure of an instance and needing to alter the > >>>>>> global path ID table for each and every affected end-to-end path. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> ________________________________________ From: sfc > >>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > >>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > >>>>>> [sfc] Service Chains, Paths, and Load Balancers > >>>>>> > >>>>>> The way the architecture models the case of SF1 needing to > influence > >>>>>> the chain is that one would do reclassification at the exit from > >>>>>> SF1. > >>>>>> > >>>>>> Part of the goal is to keep the different functions logically > >>>>>> separate so that solutions can clearly describe how they choose to > >>>>>> compose them for "service" delivery. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>>>> I don't see anything in the arch draft that suggests any sort of > >>>>>>> limit. However, it does seem to indicate that the entire path (al= l > >>>>>>> SFIs) must be chosen at SFC instantiation. I believe this means > >>>>>>> either at the classifier or maybe the classifier chooses a SF Cha= in > >>>>>>> and the NF or at the latest the first SFF. In any case, the > >>>>>>> language does seem to prohibit a more dynamic SFP where SFI(n) > is > >>>>>>> determined at the SFI(n-1) hop. According to the draft, this > >>>>>>> behavior would be considered "branching" to a new SFP as > opposed to > >>>>>>> choosing and then forwarding to the selected instance of the > >>>>>>> next-hop of the current SFC. > >>>>>>> > >>>>>>> draft-merged-sfc-architecture-00: > >>>>>>>> When an SFC is instantiated into the network it is necessary to > >>>>>>>> select the specific instances of SFs that will be used, and to > >>>>>>>> create the service topology for that SFC using SF's network > >>>>>>>> locator. Thus, instantiation of the SFC results in the creation > >>>>>>>> of a Service Function Path (SFP) and is used for forwarding > >>>>>>>> packets through the SFC. In other words, an SFP is the > >>>>>>>> instantiation of the defined SFC. > >>>>>>>> > >>>>>>>> The SFC architecture supports reclassification (or non-initial > >>>>>>>> classification) as well. As packets traverse an SFP, > >>>>>>>> reclassification may occur - typically performed by a > >>>>>>>> classification function co-resident with a service function. > >>>>>>>> Reclassification may result in the selection of a new SFP, an > >>>>>>>> update of the associated metadata, or both. This is referred to > >>>>>>>> as "branching". > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----------------------------------------------------------------= ---- > >> --- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> *From: *I.Smith@F5.com > >>>>>>> *To: *Joel Halpern Direct,Joel M. > >>>>>>> > >> > Halpern,huang@sce.carleton.ca on.ca>,s > >> fc@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> *Sent: *Thursday, July 10, 2014 > >>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>>> > >>>>>>> Actually, I think I am disagreeing. > >>>>>>> > >>>>>>> If the possibility of medium-scale deployments (and that is what > >>>>>>> 16 million flows is in my world) of service chains is preconceive= d > >>>>>>> as an absurd idea, then the architecture burdened with that > >>>>>>> preconception. > >>>>>>> > >>>>>>> There has to be some point of aim, some degree of aspiration to > >>>>>>> scale that is appropriate for the lifespan of the architecture - > >>>>>>> you don't have to know what it is, but by saying that an arbitrar= y > >>>>>>> number is "too far", you're creating - even if it isn't intention= al > >>>>>>> - a limit that influences decisions that have lasting impacts > >>>>>>> regarding scale-out, failure mitigation, elasticity, address > >>>>>>> space... all kinds of things. That is a problem I'm not > >>>>>>> particularly eager to deal with. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> > >>>>>>> > >>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>>>>>> Chains, Paths, and Load Balancers > >>>>>>> > >>>>>>> Ian, I don't think you disagree with me at all in this regard. I = am > >>>>>>> not requesting the the architecture or the solution prohibit > >>>>>>> deployments in the specific fashion. I am objecting to Huang's > >>>>>>> reading of my note as saying that such deployments are required > >>>>>>> they by the archtiecture. > >>>>>>> > >>>>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>>>> things. Whether they are a good idea or not depends upon many > >>>>>>> factors outside of the scope of the WG. I happen to think that th= ey > >>>>>>> are usually a bad idea. > >>>>>>> > >>>>>>> But the archtiecture si carefully avoiding attempting to know wha= t > >>>>>>> is and is not eployable. > >>>>>>> > >>>>>>> Yours, Joel > >>>>>>> > >>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>>>> I disagree. > >>>>>>>> > >>>>>>>> We routinely have stateful devices that manage tens of millions > >>>>>>>> of > >>>>>>> concurrent flows in both access network and data center > >>>>>>> environments today. You can't seriously believe that in the > >>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > going > >>>>>>> to have small numbers of service chains with equally small > numbers > >>>>>>> of active service paths? > >>>>>>>> > >>>>>>>> Your sounds too much like "no one will ever need more than > 64K" > >>>>>>>> for > >>>>>>> comfort. > >>>>>>>> > >>>>>>>> > >>>>>>>> ________________________________________ From: sfc > >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>>>> [jmh@joelhalpern.com] > >>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; > >>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load > >>>>>>>> Balancers > >>>>>>>> > >>>>>>>> No, it will mean that if someone tries to deploy the archtieture > >>>>>>>> particularly badly, they will exceed the limits of their > >>>>>>>> devices. The architecture does not require such absurd use of > >>>>>>>> service paths. Since I can not figure out how to write > >>>>>>>> architectural words to prohibit it, the architecture does permit > >>>>>>>> such abuse. > >>>>>>>> > >>>>>>>> Please do not read my saying that the archtiecture permits > >>>>>>>> something as saying it is either deisred or required by the work= . > >>>>>>>> It isn't. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>>>> If you need to support 100 service chains, it will mean > >>>>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>>>>>>>> core router. > >>>>>>>>> > >>>>>>>>> Chang > >>>>>>>>> > >>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>>>> service path to 160000 service paths. I would hope that > >>>>>>>>>> operators are prepared for the complexities if they choose to > >>>>>>>>>> avoid any use of local load balancing and in stead provision > >>>>>>>>>> 160,000 service paths. > >>>>>>>>>> > >>>>>>>>>> Yours, Joel > >>>>>>>>>> > >>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>>> Paul, > >>>>>>>>>>> > >>>>>>>>>>> How many path identifiers there will be for a 4 hop service > >>>>>>>>>>> chain with 20 instances at each hop? > >>>>>>>>>>> > >>>>>>>>>>> Maria > >>>>>>>>>>> > >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Lucy, > >>>>>>>>>>> > >>>>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>>>> forwarding. I'd > >>>>>>> make > >>>>>>>>>>> the minor change: the path identifier can be used to derive > >>>>>>>>>>> the needed forwarding and associated transport. > >>>>>>>>>>> > >>>>>>>>>>> It is _not_ the transport, but rather is used to simply > >>>>>>>>>>> identify the service path (or graph) that packets must > >>>>>>>>>>> traverse. By having a path identifier, the exact > >>>>>>>>>>> indirection that people seem to be asking for on this > >>>>>>>>>>> thread can be simply be implemented. The path identifier > >>>>>>>>>>> provides nothing more than a lookup, that lookup can result > >>>>>>>>>>> in a one or more (equal or weighted) transport next > >>>>>>>>>>> hop(s). > >>>>>>>>>>> > >>>>>>>>>>> Paul > >>>>>>>>>>> > >>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>>>> > > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>>>>>>>>>> service path identifier to drive the forwarding actions. > >>>>>>>>>>> > >>>>>>>>>>> Lucy > >>>>>>>>>>> > >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>>>> *Sent:*Thursday, > July > >>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>>>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Re-, > >>>>>>>>>>> > >>>>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>>>> identifier. I object to use that identifier to derive > >>>>>>>>>>> forwarding actions. > >>>>>>>>>>> > >>>>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>>>>>> available SFC > >>>>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>>>> required/justified > >>>>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>>>> > >>>>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>>>> information > >>>>>>> that will > >>>>>>>>>>> be present in all deployments: that is the one required to > >>>>>>>>>>> structure a service chain. How that information is used to > >>>>>>>>>>> infer forwarding > >>>>>>> actions > >>>>>>>>>>> is a solution-oriented discussion. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> > >>>>>>>>>>> Med > >>>>>>>>>>> > >>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>>>> de*mikebianc@aol.com > >>>>>>>>>>> *Envoy=E9 :*mercredi 9 juillet > >>>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Is anyone still questioning the difference between SF Chain > >>>>>>>>>>> and SF > >>>>>>> Path? > >>>>>>>>>>> Other than clarifying the definition so that it's clear to > >>>>>>> those not > >>>>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>>>>>>>>>> these terms. > >>>>>>>>>>> > >>>>>>>>>>> To me, the one point that is still unclear is whether it is > >>>>>>>>>>> the intent of this draft to ultimately specify what the ID > >>>>>>>>>>> of the SFC Header > >>>>>>> should > >>>>>>>>>>> reference (the chain or the path), or if this draft simply > >>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>>>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>>>>>>>>>> path and the choice of chain or > >>>>>>> path to > >>>>>>>>>>> be negotiated in the control-plane. > >>>>>>>>>>> > >>>>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>>>> require that both SFP and SFC be supported (or make one > >>>>>>>>>>> required and the other optional) to avoid some vendors only > >>>>>>>>>>> supporting SFP and others only supporting SFC. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> -----------------------------------------------------------------= ---- > >> --- > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> > >>>>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>>>> > > >>>>>>>>>>> *To:*sfc@ietf.org >>>>>>>>>>> > *Sent:*Tuesday, July > >>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>>>>>>>>>> Balancers > >>>>>>>>>>> > >>>>>>>>>>> I have been trying to figure out how to clearly answer a > >>>>>>>>>>> number of comments that have been made about the > proposed > >>>>>>>>>>> merged archtiecture draft. Assuming we can get working > >>>>>>>>>>> group agreement on the intent, we will work to improve the > >>>>>>>>>>> wording so that readers who have not participated in the WG > >>>>>>>>>>> discussion will understnd it the way the > >>>>>>> working > >>>>>>>>>>> group intends. > >>>>>>>>>>> > >>>>>>>>>>> But what do we intend? I will try to explain my personal > >>>>>>>>>>> view, and see if that helps. > >>>>>>>>>>> > >>>>>>>>>>> In this regard, it is important to keep in mind that what > >>>>>>>>>>> we are defining is the data plane architecture. We are not > >>>>>>>>>>> attempting to define the architecture for the entire > >>>>>>>>>>> solution for service chaining. That would encompass > >>>>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>>>>>>>>>> machine and image management, and many other aspects. > >>>>>>>>>>> > >>>>>>>>>>> As a result there are many things which clearly need to > >>>>>>>>>>> exist in the larger system, but which are dealt with above > >>>>>>>>>>> where we are > >>>>>>> functioning, > >>>>>>>>>>> and are not directly required by the work we are doing. > >>>>>>>>>>> > >>>>>>>>>>> In order to get to service chain vs service path, as I > >>>>>>>>>>> understand > >>>>>>> them, > >>>>>>>>>>> I need to first discuss load balancing. There are at least > >>>>>>>>>>> three different ways that load balancing can and will > >>>>>>>>>>> interact with service chaining. There probably are more. > >>>>>>>>>>> The point of the archtiecture is to permit all of these, > >>>>>>>>>>> but not to mandate that any particular kind > >>>>>>> be used > >>>>>>>>>>> in any solution. > >>>>>>>>>>> > >>>>>>>>>>> 1) Load balancing as a service provided to the end user. > >>>>>>>>>>> This is a service function. It receives user packets, and > >>>>>>>>>>> modifies them (or > >>>>>>> marks > >>>>>>>>>>> them, or ...) so as to choose an end user service instance > >>>>>>>>>>> to receive the users packet. This is an important service > >>>>>>>>>>> function to be able to include in service chaining. It's > >>>>>>>>>>> behavior may affect requirements on how service chaining is > >>>>>>>>>>> done. But it has very little impact on the archtiecture. > >>>>>>>>>>> From an architectural pe3rspective it is simply a > >>>>>>> service > >>>>>>>>>>> function which may modify the underlying packet. > >>>>>>>>>>> > >>>>>>>>>>> 2) There is internal load balancing. That is, one can have > >>>>>>>>>>> what > >>>>>>> appears > >>>>>>>>>>> to the service chaining architecture as a single point of > >>>>>>>>>>> contact > >>>>>>> for a > >>>>>>>>>>> specific service function, but is actually delivered by a > >>>>>>> collection of > >>>>>>>>>>> virtual or physical machines, possibly including one or > >>>>>>>>>>> several load balancers (for example using VRRP-like > >>>>>>>>>>> techniques to share a MAC address.) mostly, this is > >>>>>>>>>>> invisible to the service chaining data plane mechanisms. It > >>>>>>>>>>> is likely that it is visible to various control mechanisms, > >>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>>>>>>>>>> instantiation. The architectural impact of permitting this > >>>>>>>>>>> is largely that we need to be careful that our terminology > >>>>>>>>>>> does not lead > >>>>>>> readers to > >>>>>>>>>>> think we are prohibiting it. > >>>>>>>>>>> > >>>>>>>>>>> 3) There can also be load balancing done by selecting > >>>>>>>>>>> packet paths for the service chaining that direct traffic > >>>>>>>>>>> to different places. We would not want to require that a > >>>>>>>>>>> given service function appear at only one place in the > >>>>>>>>>>> network. > >>>>>>>>>>> > >>>>>>>>>>> It is of course the case that these may be combined. I tend > >>>>>>>>>>> to > >>>>>>> refer to > >>>>>>>>>>> the collection of entities that appear to service chaining > >>>>>>>>>>> as a single point as a cluster. Not because cluster is a > >>>>>>>>>>> good term. But because I do not have another one. Thus, the > >>>>>>>>>>> point of type 3 load balancing > >>>>>>> is to > >>>>>>>>>>> direct different subsets of traffic to different singular > >>>>>>>>>>> or clustered service functions in different places in the > >>>>>>>>>>> network. > >>>>>>>>>>> > >>>>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>>>> service chain and service path/ Service chain is a sequence > >>>>>>>>>>> of logical functions to be applied to a subset of packets. > >>>>>>>>>>> It is equivalent of saying that some subset of traffic is > >>>>>>>>>>> to get DPI, charging, content inspection, and firewall > >>>>>>>>>>> while a different subset is to go directly to the cache > >>>>>>> without > >>>>>>>>>>> visiting any other service functions. > >>>>>>>>>>> > >>>>>>>>>>> That is not enough information to direct the packets. A > >>>>>>>>>>> service path is, in some fashion, a sequence of locations > >>>>>>>>>>> in the network. Those locations will be singular or > >>>>>>>>>>> clustered service function delivery locations. They may be > >>>>>>>>>>> addressed by IP address. They may be addressed as ports on > >>>>>>>>>>> an SFF. There are many different ways that the locations > >>>>>>>>>>> may be known to the service chaining infrastructure and the > >>>>>>>>>>> transport. > >>>>>>>>>>> > >>>>>>>>>>>> From the point of view of the work of the SFC group, we > >>>>>>>>>>>> need to be > >>>>>>>>>>> able to talk about the high level abstraction, the service > >>>>>>>>>>> chain, which drives the forwarding. And we need to talk > >>>>>>>>>>> about the actual data path packets will take in the > >>>>>>>>>>> network. > >>>>>>>>>>> > >>>>>>>>>>> Several of the comments have said "but the whole path may > >>>>>>>>>>> not be known at the front." This architecture deals with > >>>>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >>>>>>>>>>> balancers above, there can be decisions and behaviors which > >>>>>>>>>>> are invisible to the service chaining mechanisms (in much > >>>>>>>>>>> the same way that bridging within a LAN is largely > >>>>>>>>>>> invisible to routing between LANs.) The other provision we > >>>>>>>>>>> make is > >>>>>>> that > >>>>>>>>>>> reclassification can be done in mid-chain when necessary. > >>>>>>>>>>> That will direct packets to a new chain. Based on > >>>>>>>>>>> information available at the re-classification point. > >>>>>>>>>>> > >>>>>>>>>>> I hope that this helps explain what we are after. If it > >>>>>>>>>>> does, and if the intent is acceptable to the working group, > >>>>>>>>>>> we can figure out what additional words are needed to > >>>>>>>>>>> convey this. If the working group disagree with the intent, > >>>>>>>>>>> then we will of course adjust to match the working group > >>>>>>>>>>> agreements. If this is still unclear, I am not sure what to > >>>>>>>>>>> try next. > >>>>>>>>>>> > >>>>>>>>>>> Yours, Joel > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>>>> list sfc@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>>>> list sfc@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing list > >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > mailing list > >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing > list > >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing > list > >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >>> _______________________________________________ > >>> sfc mailing 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 From nobody Fri Jul 11 06: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 E84C81B27F3 for ; Fri, 11 Jul 2014 06:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G_wQkph5yVU for ; Fri, 11 Jul 2014 06:24:21 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EF31A0422 for ; Fri, 11 Jul 2014 06:24:14 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id e75efb35.2b9933c85940.4569882.00-2458.12662080.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:24:14 +0000 (UTC) X-MXL-Hash: 53bfe57e35674424-80d52fa7851d3e25a1ebf5a1cac36fc3b724e66e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id bf4efb35.0.4568686.00-2357.12658699.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:22:20 +0000 (UTC) X-MXL-Hash: 53bfe50c64dc9943-962beedc375691da07e01eee602bf1df4e2d28b4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDM22t027986; Fri, 11 Jul 2014 09:22:02 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDLsAV027837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:21:55 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:21:31 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:21:01 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ian Smith , Ron Parker , "mikebianc@aol.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAF/1gIAAUEkA//++Z1CAAEpGgP//vexg Date: Fri, 11 Jul 2014 13:21:00 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC07@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330031141@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDA76.302@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABA3@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFE1BD.3000507@joelhalpern.com> In-Reply-To: <53BFE1BD.3000507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=3oc9M9_CAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=rVzFT] X-AnalysisOut: [6SCJLBpJ1_YRb8A:9 a=wPNLvfGTeEIA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=U8Ie8EnqySEA:10 a=chC_agHSu74A:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=hPjdaMEvmhQA:10 a=qC4KNLUN8zgFlfvo:21 a=OIGvSx] X-AnalysisOut: [dyFj-HAovM:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/F48h9XxGxg-qqbyGaqIPUOSq29Q Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:24:28 -0000 =20 > There is a VERY large difference both architecturally and in terms of > solutions and implementations between saying that the SFI does not make > decisions about next SFI and saying that there is no local load balancing= . Noticed: I said that a *hop* at SFI(n-1) to determine SFI(n), and not that = SFI(n-1) determines SFI(n), > Yes, the archteicture states that the service functions themselves do > not direct the forwarding. That is a matter of separation of concerns. Agree. > It also says that the SFF is responsible for delivery to the SF. That > explicitly allows for the SFF to perform laod balancing to its local > Service Functions, or to be delivering to local load balancers, or > likely other methods that have not occurred to any of us. What about if SFIs at hop "n" are attached to different SFFs? > What the architecture prohbits in this regard is having SFF make global > decisions about how service paths are realized, and in particular how > load is delivered to instances supported by other SFF. I am not sure what you mean by "how the service paths are realized".=20 If you mean SFF at n-1 is load balancing to SFFs at n, it should not be pro= hibited. > For example, depending upon the transport and the solution specifics, it > is consonant with the archtiecture for the SFF to be a distributed > computation engine so that delivery to it is always a nearby tranfer > from the previous SFF, and then the SFF does stateful load balancing, > using shared computation within itself, to deliver packets to the > correct software image. This sounds like only "local" load balancing which is not sufficient. >=20 > That is permitted by the architecture, but not required. >=20 > Having SFI make decisions about next SFI means that we have coupled > network forwarding with the actual service functions. That complicates > construction of service functions, and requires them to deliver > additional functionality. If a service function developer wants to > include an SFF in what he delivers, that is permitted by the > architecture. We are describing logical components, not the package > developers or vendors choose to use. I agree with that. >=20 > Yours, > Joel >=20 > On 7/11/14, 8:53 AM, NAPIERALA, MARIA H wrote: > > > >> Path selection is not, from what I have seen, dynamic in nature. Ther= e > >> has been expressed repeatedly a requirement that all the packets of a > >> given flow go through the same service instances. Dynamic routing > >> simply does not do that. > > > > And you believe it is possible and scalable to ensure it centrally but = not in > a distributed manner? > > > >> And as has been said repeatedly, the archtiecture proposed does not > >> require that load balancing be done entirely at the central point. As > >> far as I can tell any solution compliant with the proposed archtiectur= e > >> allows for both centralized control of some traffic distribution, and > >> local load balancing within that. I would expect most deployments > would > >> use both. > >> > > > > Well, it was just discussed that the wording in architecture document > precludes a hop at SFI(n-1) to determine SFI(n). > > Which means that SFC system determines SFI(n) centrally, which, in turn= , > means that load balancing is done centrally. > > > > Maria > > > > > > > > Maria > >> > >> On 7/11/14, 3:49 AM, mohamed.boucadair@orange.com wrote: > >>> Hi Joel, > >>> > >>> This is one possible approach, but what several of us are trying to > >>> clarify is this is one approach among others, not possible in some > >>> contexts, more complex to ensure resiliency, etc. Below some of my > >>> concerns about your approach: > >>> > >>> (1) Having an entity that maintains a large set of service paths in a > >>> given domain is more like creating circuits...I thought distributed > >>> routing has shown its efficiency. (2) Policies are everywhere in the > >>> network , not only at the SFC structuring system. (3) Path selection > >>> is dynamic by nature because it depends on various heuristics and > >>> policies that are distributed in the network (including those of SFs > >>> and others). (4) Having a stateful function that maintains the full > >>> list of available paths may not be that resilient. This must assess > >>> frequently (very short cycle) valid and serviceable paths among > >>> available ones. Ensuring the same level of resilience would require > >>> additional features to be supported by to that entity maintaining the > >>> full set of path, and also SFs. (5) Load-balancing at a centralized > >>> entity is deployment-specific; as such it is not required nor > >>> possible in those contexts. Deciding the forwarding path a priori > >>> contradicts LB requirements. I know your answer about > >>> re-classification, but IMHO the architecture should not mandate an > >>> optional feature only because of some design choices. > >>> Re-classification should be avoided as much for the same of > >>> performance and also because this one of the complexity vector for > >>> this work. (6) There are a bunch of solutions that achieve > >>> differentiated forwarding without requiring a > >>> pre-computation/pre-determination of a path: think about ToS-based > >>> routing, multi-topology routing, etc. > >>> > >>> I could live with an optional capability that a path can be > >>> pre-determined, but this must not be the rule. > >>> > >>> Forwarding within an SFC-enabled domain is primarily inferred by the > >>> service function chain itself. How this information is used to drive > >>> forwarding actions is all about details. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] > >>>> De la part de Joel M. Halpern Envoy=E9 : vendredi 11 juillet 2014 > >>>> 04:06 =C0 : Ian Smith; Ron Parker; mikebianc@aol.com; sfc@ietf.org > >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> Part of my personal view is that I am trying to make this work > >>>> sensibly in a more orchestrated environment. I expect that the > >>>> service functions, and over time probably the SFF capabilities, > >>>> will be orchestrated and installed. I expect the service chains to > >>>> be driven by BSS tools that define offerings to clients, and enable > >>>> self-selection from these. I expect service paths to be heavily > >>>> policy drive. > >>>> > >>>> I can see how to make all of that work in an archtiecture driven > >>>> by initial classification to described service paths. It is harder > >>>> to see how to make it work (but it can be done) when we allow more > >>>> dynamicity in the network behavior. > >>>> > >>>> Having said that, most of that perspective I described is outside > >>>> of the scope of the working group. it is not something we are > >>>> tasked to agree on. So I do not claim that vision means we have to > >>>> do it a certain way. it is just the perspective that drives my > >>>> preferences. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>>>> For me, the amount of information about service instances that > >>>>>> needs to be widely distributed and maintained, potentially even > >>>>>> across data centers within an administrative scope, is large > >>>>>> enough and complex enough that trying to get that into each SFF > >>>>>> seems like a difficult architecture to realize. > >>>>> > >>>>> I'm curious as to why that is more complicated than dynamic > >>>>> routing, > >>>> hyper-scale data center orchestration, or DNS, all of which are > >>>> bigger problems that have been profitably and stably implemented? > >>>>> > >>>>> It also seems that if it really is more complicated, that is a > >>>>> good sign > >>>> that it is too complicated. > >>>>> > >>>>> ________________________________________ From: Joel M. > Halpern > >>>>> [jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 9:45 PM To: > >>>>> Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >>>> sfc@ietf.org > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> This is an architectural issue. And one that I would prefer we > >>>>> actually decide, rather than trying to allow all possible > >>>>> implementations. Because it does have a major effect on the > >>>>> control requirements and the functionality of SFFs. > >>>>> > >>>>> For me, the amount of information about service instances that > >>>>> needs to be widely distributed and maintained, potentially even > >>>>> across data centers within an administrative scope, is large > >>>>> enough and complex enough that trying to get that into each SFF > >>>>> seems like a difficult architecture to realize. > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> But it is a fair question. > >>>>> > >>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>>>> This is the crux of my issue. Is the end to end selection of > >>>>>> (top-level) instances performed centrally (perhaps by the > >>>>>> classifier) or hop-by-hop (perhaps by the classifier and > >>>>>> subsequently the SFFs)? Such selection is not equivalent to > >>>>>> reclassification. And surely, this is an architectural issue > >>>>>> and not relegated to "implementation". > >>>>>> > >>>>>> My own view is to favor the distributed approach even though a > >>>>>> greater amount of data (chain definitions and perhaps local > >>>>>> selection policy) is required at those distributed decision > >>>>>> points. This approach does not require an end-to-end path id > >>>>>> at all. My rationale for favoring this approach is primarily > >>>>>> driven by increased resiliency over the global path id > >>>>>> approach. With a global path id approach, consider failure of > >>>>>> an instance and needing to alter the global path ID table for > >>>>>> each and every affected end-to-end path. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> ________________________________________ From: sfc > >>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 > >>>>>> PM To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: > >>>>>> Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>> > >>>>>> The way the architecture models the case of SF1 needing to > >>>>>> influence the chain is that one would do reclassification at > >>>>>> the exit from SF1. > >>>>>> > >>>>>> Part of the goal is to keep the different functions logically > >>>>>> separate so that solutions can clearly describe how they choose > >>>>>> to compose them for "service" delivery. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>>>> I don't see anything in the arch draft that suggests any sort > >>>>>>> of limit. However, it does seem to indicate that the entire > >>>>>>> path (all SFIs) must be chosen at SFC instantiation. I > >>>>>>> believe this means either at the classifier or maybe the > >>>>>>> classifier chooses a SF Chain and the NF or at the latest the > >>>>>>> first SFF. In any case, the language does seem to prohibit a > >>>>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1) > >>>>>>> hop. According to the draft, this behavior would be > >>>>>>> considered "branching" to a new SFP as opposed to choosing > >>>>>>> and then forwarding to the selected instance of the next-hop > >>>>>>> of the current SFC. > >>>>>>> > >>>>>>> draft-merged-sfc-architecture-00: > >>>>>>>> When an SFC is instantiated into the network it is > >>>>>>>> necessary to select the specific instances of SFs that will > >>>>>>>> be used, and to create the service topology for that SFC > >>>>>>>> using SF's network locator. Thus, instantiation of the SFC > >>>>>>>> results in the creation of a Service Function Path (SFP) > >>>>>>>> and is used for forwarding packets through the SFC. In > >>>>>>>> other words, an SFP is the instantiation of the defined > >>>>>>>> SFC. > >>>>>>>> > >>>>>>>> The SFC architecture supports reclassification (or > >>>>>>>> non-initial classification) as well. As packets traverse > >>>>>>>> an SFP, reclassification may occur - typically performed by > >>>>>>>> a classification function co-resident with a service > >>>>>>>> function. Reclassification may result in the selection of a > >>>>>>>> new SFP, an update of the associated metadata, or both. > >>>>>>>> This is referred to as "branching". > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----------------------------------------------------------------= ------ > >>>> > >>>>>>> > >> - > >>>>>>> > >>>>>>> > >>>>> *From: *I.Smith@F5.com > >>>>>>> *To: *Joel Halpern Direct,Joel > >>>>>>> M. > >>>>>>> > >>>> > >> > Halpern,huang@sce.carleton.ca >> on.ca>,s > >>>> > >>>> > >> fc@ietf.org > >>>>>>> > >>>>>>> > >>>>> *Sent: *Thursday, July 10, 2014 > >>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load > >>>>>>> Balancers > >>>>>>> > >>>>>>> Actually, I think I am disagreeing. > >>>>>>> > >>>>>>> If the possibility of medium-scale deployments (and that is > >>>>>>> what 16 million flows is in my world) of service chains is > >>>>>>> preconceived as an absurd idea, then the architecture > >>>>>>> burdened with that preconception. > >>>>>>> > >>>>>>> There has to be some point of aim, some degree of aspiration > >>>>>>> to scale that is appropriate for the lifespan of the > >>>>>>> architecture - you don't have to know what it is, but by > >>>>>>> saying that an arbitrary number is "too far", you're creating > >>>>>>> - even if it isn't intentional - a limit that influences > >>>>>>> decisions that have lasting impacts regarding scale-out, > >>>>>>> failure mitigation, elasticity, address space... all kinds of > >>>>>>> things. That is a problem I'm not particularly eager to deal > >>>>>>> with. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> > >>>>>>> > >>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. > >>>>>>> Halpern; huang@sce.carleton.ca; sfc@ietf.org Subject: Re: > >>>>>>> [sfc] Service Chains, Paths, and Load Balancers > >>>>>>> > >>>>>>> Ian, I don't think you disagree with me at all in this > >>>>>>> regard. I am not requesting the the architecture or the > >>>>>>> solution prohibit deployments in the specific fashion. I am > >>>>>>> objecting to Huang's reading of my note as saying that such > >>>>>>> deployments are required they by the archtiecture. > >>>>>>> > >>>>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>>>> things. Whether they are a good idea or not depends upon > >>>>>>> many factors outside of the scope of the WG. I happen to > >>>>>>> think that they are usually a bad idea. > >>>>>>> > >>>>>>> But the archtiecture si carefully avoiding attempting to know > >>>>>>> what is and is not eployable. > >>>>>>> > >>>>>>> Yours, Joel > >>>>>>> > >>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>>>> I disagree. > >>>>>>>> > >>>>>>>> We routinely have stateful devices that manage tens of > >>>>>>>> millions of > >>>>>>> concurrent flows in both access network and data center > >>>>>>> environments today. You can't seriously believe that in the > >>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > >>>>>>> going to have small numbers of service chains with equally > >>>>>>> small numbers of active service paths? > >>>>>>>> > >>>>>>>> Your sounds too much like "no one will ever need more than > >>>>>>>> 64K" for > >>>>>>> comfort. > >>>>>>>> > >>>>>>>> > >>>>>>>> ________________________________________ From: sfc > >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>>>> [jmh@joelhalpern.com] > >>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > >>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] > >>>>>>>> Service Chains, Paths, and Load Balancers > >>>>>>>> > >>>>>>>> No, it will mean that if someone tries to deploy the > >>>>>>>> archtieture particularly badly, they will exceed the limits > >>>>>>>> of their devices. The architecture does not require such > >>>>>>>> absurd use of service paths. Since I can not figure out how > >>>>>>>> to write architectural words to prohibit it, the > >>>>>>>> architecture does permit such abuse. > >>>>>>>> > >>>>>>>> Please do not read my saying that the archtiecture permits > >>>>>>>> something as saying it is either deisred or required by the > >>>>>>>> work. It isn't. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>>>> If you need to support 100 service chains, it will mean > >>>>>>>>> 16,000,000 paths. That is larger than the routing table > >>>>>>>>> of a core router. > >>>>>>>>> > >>>>>>>>> Chang > >>>>>>>>> > >>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>>>> service path to 160000 service paths. I would hope > >>>>>>>>>> that operators are prepared for the complexities if > >>>>>>>>>> they choose to avoid any use of local load balancing > >>>>>>>>>> and in stead provision 160,000 service paths. > >>>>>>>>>> > >>>>>>>>>> Yours, Joel > >>>>>>>>>> > >>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>>> Paul, > >>>>>>>>>>> > >>>>>>>>>>> How many path identifiers there will be for a 4 hop > >>>>>>>>>>> service chain with 20 instances at each hop? > >>>>>>>>>>> > >>>>>>>>>>> Maria > >>>>>>>>>>> > >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf > >>>>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10, > >>>>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:* > >>>>>>>>>>> jmh@joelhalpern.com; mohamed.boucadair@orange.com; > >>>>>>>>>>> sfc@ietf.org; mikebianc@aol.com *Subject:* Re: [sfc] > >>>>>>>>>>> Service Chains, Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Lucy, > >>>>>>>>>>> > >>>>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>>>> forwarding. I'd > >>>>>>> make > >>>>>>>>>>> the minor change: the path identifier can be used to > >>>>>>>>>>> derive the needed forwarding and associated > >>>>>>>>>>> transport. > >>>>>>>>>>> > >>>>>>>>>>> It is _not_ the transport, but rather is used to > >>>>>>>>>>> simply identify the service path (or graph) that > >>>>>>>>>>> packets must traverse. By having a path identifier, > >>>>>>>>>>> the exact indirection that people seem to be asking > >>>>>>>>>>> for on this thread can be simply be implemented. The > >>>>>>>>>>> path identifier provides nothing more than a lookup, > >>>>>>>>>>> that lookup can result in a one or more (equal or > >>>>>>>>>>> weighted) transport next hop(s). > >>>>>>>>>>> > >>>>>>>>>>> Paul > >>>>>>>>>>> > >>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>>>> > > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Agree. The arch. doc should not mandate only use of > >>>>>>>>>>> the service path identifier to drive the forwarding > >>>>>>>>>>> actions. > >>>>>>>>>>> > >>>>>>>>>>> Lucy > >>>>>>>>>>> > >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>>>> > >>>>>>>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM > >>>>>>>>>>> *To:*mikebianc@aol.com > >>>>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>> *Subject:*Re: [sfc] Service > >>>>>>>>>>> Chains, Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Re-, > >>>>>>>>>>> > >>>>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>>>> identifier. I object to use that identifier to > >>>>>>>>>>> derive forwarding actions. > >>>>>>>>>>> > >>>>>>>>>>> Requiring a SFC system to have the full knowledge of > >>>>>>>>>>> every > >>>>>>> available SFC > >>>>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>>>> required/justified > >>>>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>>>> > >>>>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>>>> information > >>>>>>> that will > >>>>>>>>>>> be present in all deployments: that is the one > >>>>>>>>>>> required to structure a service chain. How that > >>>>>>>>>>> information is used to infer forwarding > >>>>>>> actions > >>>>>>>>>>> is a solution-oriented discussion. > >>>>>>>>>>> > >>>>>>>>>>> Cheers, > >>>>>>>>>>> > >>>>>>>>>>> Med > >>>>>>>>>>> > >>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>>>> de*mikebianc@aol.com > >>>>>>>>>>> *Envoy=E9 :*mercredi 9 > >>>>>>>>>>> juillet 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>> *Objet :*Re: [sfc] Service > >>>>>>>>>>> Chains, Paths, and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> Is anyone still questioning the difference between SF > >>>>>>>>>>> Chain and SF > >>>>>>> Path? > >>>>>>>>>>> Other than clarifying the definition so that it's > >>>>>>>>>>> clear to > >>>>>>> those not > >>>>>>>>>>> familiar with the draft, it seems that everyone > >>>>>>>>>>> agrees on these terms. > >>>>>>>>>>> > >>>>>>>>>>> To me, the one point that is still unclear is whether > >>>>>>>>>>> it is the intent of this draft to ultimately specify > >>>>>>>>>>> what the ID of the SFC Header > >>>>>>> should > >>>>>>>>>>> reference (the chain or the path), or if this draft > >>>>>>>>>>> simply intends to leave that ambiguous, allowing > >>>>>>>>>>> other drafts to dictate the mechanisms for forwarding > >>>>>>>>>>> based on chain or path and the choice of chain or > >>>>>>> path to > >>>>>>>>>>> be negotiated in the control-plane. > >>>>>>>>>>> > >>>>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>>>> require that both SFP and SFC be supported (or make > >>>>>>>>>>> one required and the other optional) to avoid some > >>>>>>>>>>> vendors only supporting SFP and others only > >>>>>>>>>>> supporting SFC. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> -----------------------------------------------------------------= ------ > >>>> > >>>>>>> > >> - > >>>>>>> > >>>>>>> > >>>>>>>>> > >>>>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>>>> > > >>>>>>>>>>> *To:*sfc@ietf.org >>>>>>>>>>> > *Sent:*Tuesday, > >>>>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths, > >>>>>>>>>>> and Load Balancers > >>>>>>>>>>> > >>>>>>>>>>> I have been trying to figure out how to clearly > >>>>>>>>>>> answer a number of comments that have been made about > >>>>>>>>>>> the proposed merged archtiecture draft. Assuming we > >>>>>>>>>>> can get working group agreement on the intent, we > >>>>>>>>>>> will work to improve the wording so that readers who > >>>>>>>>>>> have not participated in the WG discussion will > >>>>>>>>>>> understnd it the way the > >>>>>>> working > >>>>>>>>>>> group intends. > >>>>>>>>>>> > >>>>>>>>>>> But what do we intend? I will try to explain my > >>>>>>>>>>> personal view, and see if that helps. > >>>>>>>>>>> > >>>>>>>>>>> In this regard, it is important to keep in mind that > >>>>>>>>>>> what we are defining is the data plane architecture. > >>>>>>>>>>> We are not attempting to define the architecture for > >>>>>>>>>>> the entire solution for service chaining. That would > >>>>>>>>>>> encompass OSS/BSS, various control and policy > >>>>>>>>>>> functions, virtual machine and image management, and > >>>>>>>>>>> many other aspects. > >>>>>>>>>>> > >>>>>>>>>>> As a result there are many things which clearly need > >>>>>>>>>>> to exist in the larger system, but which are dealt > >>>>>>>>>>> with above where we are > >>>>>>> functioning, > >>>>>>>>>>> and are not directly required by the work we are > >>>>>>>>>>> doing. > >>>>>>>>>>> > >>>>>>>>>>> In order to get to service chain vs service path, as > >>>>>>>>>>> I understand > >>>>>>> them, > >>>>>>>>>>> I need to first discuss load balancing. There are at > >>>>>>>>>>> least three different ways that load balancing can > >>>>>>>>>>> and will interact with service chaining. There > >>>>>>>>>>> probably are more. The point of the archtiecture is > >>>>>>>>>>> to permit all of these, but not to mandate that any > >>>>>>>>>>> particular kind > >>>>>>> be used > >>>>>>>>>>> in any solution. > >>>>>>>>>>> > >>>>>>>>>>> 1) Load balancing as a service provided to the end > >>>>>>>>>>> user. This is a service function. It receives user > >>>>>>>>>>> packets, and modifies them (or > >>>>>>> marks > >>>>>>>>>>> them, or ...) so as to choose an end user service > >>>>>>>>>>> instance to receive the users packet. This is an > >>>>>>>>>>> important service function to be able to include in > >>>>>>>>>>> service chaining. It's behavior may affect > >>>>>>>>>>> requirements on how service chaining is done. But it > >>>>>>>>>>> has very little impact on the archtiecture. From an > >>>>>>>>>>> architectural pe3rspective it is simply a > >>>>>>> service > >>>>>>>>>>> function which may modify the underlying packet. > >>>>>>>>>>> > >>>>>>>>>>> 2) There is internal load balancing. That is, one can > >>>>>>>>>>> have what > >>>>>>> appears > >>>>>>>>>>> to the service chaining architecture as a single > >>>>>>>>>>> point of contact > >>>>>>> for a > >>>>>>>>>>> specific service function, but is actually delivered > >>>>>>>>>>> by a > >>>>>>> collection of > >>>>>>>>>>> virtual or physical machines, possibly including one > >>>>>>>>>>> or several load balancers (for example using > >>>>>>>>>>> VRRP-like techniques to share a MAC address.) mostly, > >>>>>>>>>>> this is invisible to the service chaining data plane > >>>>>>>>>>> mechanisms. It is likely that it is visible to > >>>>>>>>>>> various control mechanisms, such as those responsible > >>>>>>>>>>> for scale-in, scale-out, and vm instantiation. The > >>>>>>>>>>> architectural impact of permitting this is largely > >>>>>>>>>>> that we need to be careful that our terminology does > >>>>>>>>>>> not lead > >>>>>>> readers to > >>>>>>>>>>> think we are prohibiting it. > >>>>>>>>>>> > >>>>>>>>>>> 3) There can also be load balancing done by > >>>>>>>>>>> selecting packet paths for the service chaining that > >>>>>>>>>>> direct traffic to different places. We would not want > >>>>>>>>>>> to require that a given service function appear at > >>>>>>>>>>> only one place in the network. > >>>>>>>>>>> > >>>>>>>>>>> It is of course the case that these may be combined. > >>>>>>>>>>> I tend to > >>>>>>> refer to > >>>>>>>>>>> the collection of entities that appear to service > >>>>>>>>>>> chaining as a single point as a cluster. Not because > >>>>>>>>>>> cluster is a good term. But because I do not have > >>>>>>>>>>> another one. Thus, the point of type 3 load > >>>>>>>>>>> balancing > >>>>>>> is to > >>>>>>>>>>> direct different subsets of traffic to different > >>>>>>>>>>> singular or clustered service functions in different > >>>>>>>>>>> places in the network. > >>>>>>>>>>> > >>>>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>>>> service chain and service path/ Service chain is a > >>>>>>>>>>> sequence of logical functions to be applied to a > >>>>>>>>>>> subset of packets. It is equivalent of saying that > >>>>>>>>>>> some subset of traffic is to get DPI, charging, > >>>>>>>>>>> content inspection, and firewall while a different > >>>>>>>>>>> subset is to go directly to the cache > >>>>>>> without > >>>>>>>>>>> visiting any other service functions. > >>>>>>>>>>> > >>>>>>>>>>> That is not enough information to direct the packets. > >>>>>>>>>>> A service path is, in some fashion, a sequence of > >>>>>>>>>>> locations in the network. Those locations will be > >>>>>>>>>>> singular or clustered service function delivery > >>>>>>>>>>> locations. They may be addressed by IP address. They > >>>>>>>>>>> may be addressed as ports on an SFF. There are many > >>>>>>>>>>> different ways that the locations may be known to the > >>>>>>>>>>> service chaining infrastructure and the transport. > >>>>>>>>>>> > >>>>>>>>>>>> From the point of view of the work of the SFC > >>>>>>>>>>>> group, we need to be > >>>>>>>>>>> able to talk about the high level abstraction, the > >>>>>>>>>>> service chain, which drives the forwarding. And we > >>>>>>>>>>> need to talk about the actual data path packets will > >>>>>>>>>>> take in the network. > >>>>>>>>>>> > >>>>>>>>>>> Several of the comments have said "but the whole path > >>>>>>>>>>> may not be known at the front." This architecture > >>>>>>>>>>> deals with that issue in two ways. First, as noted in > >>>>>>>>>>> item (2) on load balancers above, there can be > >>>>>>>>>>> decisions and behaviors which are invisible to the > >>>>>>>>>>> service chaining mechanisms (in much the same way > >>>>>>>>>>> that bridging within a LAN is largely invisible to > >>>>>>>>>>> routing between LANs.) The other provision we make > >>>>>>>>>>> is > >>>>>>> that > >>>>>>>>>>> reclassification can be done in mid-chain when > >>>>>>>>>>> necessary. That will direct packets to a new chain. > >>>>>>>>>>> Based on information available at the > >>>>>>>>>>> re-classification point. > >>>>>>>>>>> > >>>>>>>>>>> I hope that this helps explain what we are after. If > >>>>>>>>>>> it does, and if the intent is acceptable to the > >>>>>>>>>>> working group, we can figure out what additional > >>>>>>>>>>> words are needed to convey this. If the working group > >>>>>>>>>>> disagree with the intent, then we will of course > >>>>>>>>>>> adjust to match the working group agreements. If this > >>>>>>>>>>> is still unclear, I am not sure what to try next. > >>>>>>>>>>> > >>>>>>>>>>> Yours, Joel > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ sfc > >>>>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ sfc > >>>>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > >>>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>> list sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > mailing > >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing > >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing > >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ sfc mailing > 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 Jul 11 06:25: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 153B01A01C1 for ; Fri, 11 Jul 2014 06:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 UV6aUKFs1-95 for ; Fri, 11 Jul 2014 06:24:58 -0700 (PDT) Received: from mxebd06-public.idz.gs.com (mxe5.gs.com [199.99.47.101]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6D41A01AD for ; Fri, 11 Jul 2014 06:24:52 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,643,1400040000"; d="scan'208,217"; a="44666515" Received: from unknown (HELO mxpcd02-public.ny.fw.gs.com) ([148.86.97.79]) by mxebd06.idz.gs.com with ESMTP; 11 Jul 2014 09:24:49 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshccdp09ex.firmwide.corp.gs.com ([10.135.172.79]) by cd02-mxp-vip-prod.ny.fw.gs.com with ESMTP; 11 Jul 2014 09:24:45 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp09ex.firmwide.corp.gs.com ([10.135.172.79]) with mapi; Fri, 11 Jul 2014 09:24:44 -0400 To: 'Ron Parker' , "'mikebianc@aol.com'" , "'jmh@joelhalpern.com'" , "'paulq@cisco.com'" Date: Fri, 11 Jul 2014 09:24:42 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKYCAgAAB5wCAAAu/AIAAIrUAgAAB4gCAABK2AIAACJsAgAAftgD//76qMP//OwEw Message-ID: References: <1916079416.1585.1405024782482.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: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4E80GSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YsaHtAHueCOio4M3f2zmX-hcGDY Cc: "'sfc@ietf.org'" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:25:04 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4E80GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm good with that. From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: 10 July 2014 9:40 PM To: Zarny, Myo [Tech]; 'mikebianc@aol.com'; 'jmh@joelhalpern.com'; 'paulq@c= isco.com' Cc: 'sfc@ietf.org' Subject: RE: [sfc] Service Chains, Paths, and Load Balancers "next-service-hop selection" ? ________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Zarny, Myo [Myo.Zarny@gs.com] Sent: Thursday, July 10, 2014 6:33 PM To: 'mikebianc@aol.com'; 'jmh@joelhalpern.com'; 'paulq@cisco.com' Cc: 'sfc@ietf.org' Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I brought up GSLB only to illustrate that next-hop selection can be done in= some other way. But I think you get my point. To me, "traffic distribution" is an improvement over "load distribution" on= ly because it's not too close to load balancing. But I'm not wedded to it. = I'll be fine with any term that is less loaded and less likely to cause con= fusion. Myo From: mikebianc@aol.com [mailto:mikebianc@aol.com= ] Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard Time To: Zarny, Myo [Tech]; jmh@joelhalpern.com >; paulq@cisco.com > Cc: sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Agree that maybe 'load distribution' isn't the best name. What is importan= t is that it is distinguished from load balancing (which is also a poor nam= e). Maybe "Traffic Distribution' or 'Traffic Balancing' or do those names alrea= dy carry other significance? ________________________________ From: Myo.Zarny@gs.com> To: 'jmh@joelhalpern.com'>,= 'mikebianc@aol.com'>,'paulq@cis= co.com'> cc: 'sfc@ietf.org'> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Using the term load distribution to refer to load balancer selection will b= e lost to a lot of people. Many people call it global sever load balancing. Plus, there could be multiple layers of "load distribution" / LB selection.= Not just two. For example, select a region from a global pool; once the re= gion is selected, select a data center in that region; in that DC, which DC= LB instance to go to; and then we have the traditional LB which selects th= e end server. In sum, (1) path selection could happen at more than 2 different tiers; (2)= "load" isn't the only criterion in those selections. I see the rationale f= or wanting the differentiation but is load distribution the best term for i= t? Regards, ----- Original Message ----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time To: mikebianc@aol.com >; paulq@cisco.com > Cc: sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The term "load distribution" works for me. I agree that there is value in differentiating the functions, and using different words usually helps such differentiation. Yours, Joel On 7/10/14, 2:55 PM, mikebianc@aol.com wrote: > I've stated before that I think we should differentiate between load > balancing and load distribution where load balancing refers to the > standard service function that we all know and love (outside of SFC) and > load distribution refers to the selection of an SFI (i.e. Chain -> Path > mapping). Not using different terms to distinguish between these leads > to confusion. > > e.g. a SF Chain* might exist whose SFs consist only of load balancers. > But you might still want SFC* to distribute load to multiple load > balancer instances. > > *trying to distinguish between SFC as "Service Function Chaining" and a > single "Service Function Chain". > > > > > > > > ------------------------------------------------------------------------ > *From: *paulq@cisco.com> > *To: *Joel M. Halpern> > *cc: *Jim Guichard > (jguichar)>,sfc@ietf.org>,mohamed.boucadair@orange.com>,Ron > Parker>,NAPIERALA, MARIA H> > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Joel, > > I concur. The goal here is to address the issues associated with generic > service function deployment and should enable localized decisions such > as load balancing (perhaps more accurately load distribution). Clearly > we sound't codify how load distribution works. > > In order to enable load distribution, for example, the right > abstractions been to be clearly defined in the architecture, a key one > bering the distinction between path vs. chain. > > Paul > > > > On Jul 10, 2014, at 12:08 PM, Joel M. Halpern > wrote: > > > That is clearly an important problem in building a full solution to > the service chaining needs of operators (e.g. you). However, I could > equally observe that if you do not have OSS/BSS capable of provisioning > service chains, or charging systems capable of turning them into > revenue, you can't offer them. > > > > The SFC working group is tasked with one part of the whole service > chain definition, construction, and deployment problem. As I read the > charter, general load balancing issues are not part of our scope. > > Given the number of different ways there are of doing load balancing, > it would strike me as very odd for the sfc working group to standardize > a particular answer to the important and difficult problem you point to. > > > > The architecture (and I believe most of the solutions) is designed to > provide tools that help with managing that scaling, while also allowing > for the use of other tools. > > If the working group wants us to be more specific in the load > balancing architecture, then if the chairs tell us to we will add more > specific text. I would be surprised personally if we had agreement on > such a goal, or agreement on how to fill such a goal. But Carlos and I > will of course do what the chairs tell us the WG wants. > > > > Yours, > > Joel > > > > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote: > >> One of the main problems in "service chains" is how to implement a > service that is conceptually one hop but scaled horizontally as 10 or > 100 different VMs. > >> So, IMO, if we are not addressing this problem than what are we solvin= g. > >> > >> Maria > >> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4E80GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m= good with that.

&nbs= p;

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent:<= /b> 10 July 2014 9:40 PM
To: Zarny, Myo [Tech]; 'mikebianc@aol.co= m'; 'jmh@joelhalpern.com'; 'paulq@cisco.com'
Cc: 'sfc@ietf.org'Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<= /o:p>

 

= "next-service-hop selection" ?

 

From: sfc [sfc-bounces@ietf.org] on behalf= of Zarny, Myo [Myo.Zarny@gs.com]
Sent: Thursday, July 10, 2014 6= :33 PM
To: 'mikebianc@aol.com'; 'jmh@joelhalpern.com'; 'paulq@cis= co.com'
Cc: 'sfc@ietf.org'
Subject: Re: [sfc] Service C= hains, Paths, and Load Balancers

I brought up GSLB only to illustrate that next-hop selection can be do= ne in some other way. But I think you get my point.

To me, "tra= ffic distribution" is an improvement over "load distribution"= ; only because it's not too close to load balancing. But I'm not wedded to = it. I'll be fine with any term that is less loaded and less likely to cause= confusion.

Myo


 =

From: mikebi= anc@aol.com [mailto:mikebianc@aol.= com]
Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard= Time
To: Zarny, Myo [Tech]; jmh@joelhalpern.com <jmh@j= oelhalpern.com>; paulq@cisco.com<= /a> <paulq@cisco.com>
C= c: sfc@ietf.org <sfc@ietf.org>
Subject: Re: [sfc] Service= Chains, Paths, and Load Balancers
&= nbsp;

Agree that maybe 'load distribution' isn't the best name. &nb= sp;What is important is that it is distinguished from load balancing (which= is also a poor name).

 

Maybe "Traffic Distribution' or 'Traff= ic Balancing' or do those names already carry other significance?



<= /div>

From:= Myo.Zarny@gs.com<Myo.Zarny@gs.com>
To: = 'jmh@joelhalpern.com'<jmh@joe= lhalpern.com>,'mikebianc@aol.com'<mikebianc@aol.com>,'paulq@cisco.com'<paulq@cisco.com>
cc: 'sfc@ietf.org'<sfc@ietf.org>
Sent: Thursday, Ju= ly 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Ba= lancers

Using the term load distribution to refer to load balancer s= election will be lost to a lot of people. Many people call it global sever = load balancing.

Plus, there could be multiple layers of "load d= istribution" / LB selection. Not just two. For example, select a regio= n from a global pool; once the region is selected, select a data center in = that region; in that DC, which DC LB instance to go to; and then we have th= e traditional LB which selects the end server.

In sum, (1) path sele= ction could happen at more than 2 different tiers; (2) "load" isn= 't the only criterion in those selections. I see the rationale for wanting = the differentiation but is load distribution the best term for it?

= Regards,



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


From: Joel = M. Halpern [mailto:jmh@joelhalpern.c= om]
Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time
= To: mikebianc@aol.com <mikebianc@aol.com>; paulq@cisco.com <paulq@cisco.com>
Cc: sfc@ietf.or= g <sfc@ietf.org>
Subject: = Re: [sfc] Service Chains, Paths, and Load Balancers

The term "l= oad distribution" works for me. I agree that there is value
in dif= ferentiating the functions, and using different words usually
helps suc= h differentiation.

Yours,
Joel

On 7/10/14, 2:55 PM, mikebianc@aol.com wrote:
> I've st= ated before that I think we should differentiate between load
> balan= cing and load distribution where load balancing refers to the
> stand= ard service function that we all know and love (outside of SFC) and
>= load distribution refers to the selection of an SFI (i.e. Chain -> Path=
> mapping). Not using different terms to distinguish between these l= eads
> to confusion.
>
> e.g. a SF Chain* might exist who= se SFs consist only of load balancers.
>   But you might still w= ant SFC* to distribute load to multiple load
> balancer instances.>
> *trying to distinguish between SFC as "Service Function = Chaining" and a
> single "Service Function Chain".
= >
>
>
>
>
>
>
> --------------= ----------------------------------------------------------
> *From: <= a href=3D"mailto:*paulq@cisco.com%3cpaulq@cisco.com">*paulq@cisco.com<pa= ulq@cisco.com>
> *To: *Joel M. Halpern<jmh@joelhalpern.com>
> *cc: *Jim Guichard> (jguichar)<jguichar@cisco.c= om>,sfc@ietf.org<sfc@ietf.org= >,mohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,Ron
> Parker<Ron_Parker@affirmednetworks.co= m>,NAPIERALA, MARIA H<mn1921@at= t.com>
> *Sent: *Thursday, July 10, 2014
> *Subject: *Re= : [sfc] Service Chains, Paths, and Load Balancers
>
> Joel,
= >
> I concur. The goal here is to address the issues associated wi= th generic
> service function deployment and should enable localized = decisions such
> as load balancing (perhaps more accurately load dist= ribution). Clearly
> we sound’t codify how load distribution wo= rks.
>
> In order to enable load distribution, for example, the= right
> abstractions been to be clearly defined in the architecture,= a key one
> bering the distinction between path vs. chain.
>> Paul
>
>
>
> On Jul 10, 2014, at 12:08 PM, J= oel M. Halpern <jmh@joelhalpern.c= om> wrote:
>
> > That is clearly an important problem= in building a full solution to
> the service chaining needs of opera= tors (e.g. you). However, I could
> equally observe that if you do no= t have OSS/BSS capable of provisioning
> service chains, or charging = systems capable of turning them into
> revenue, you can't offer them.=
> >
> > The SFC working group is tasked with one part of= the whole service
> chain definition, construction, and deployment p= roblem. As I read the
> charter, general load balancing issues are no= t part of our scope.
> > Given the number of different ways there = are of doing load balancing,
> it would strike me as very odd for the= sfc working group to standardize
> a particular answer to the import= ant and difficult problem you point to.
> >
> > The archi= tecture (and I believe most of the solutions) is designed to
> provid= e tools that help with managing that scaling, while also allowing
> f= or the use of other tools.
> > If the working group wants us to be= more specific in the load
> balancing architecture, then if the chai= rs tell us to we will add more
> specific text. I would be surprised = personally if we had agreement on
> such a goal, or agreement on how = to fill such a goal. But Carlos and I
> will of course do what the ch= airs tell us the WG wants.
> >
> > Yours,
> > Jo= el
> >
> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote= :
> >> One of the main problems in "service chains" i= s how to implement a
> service that is conceptually one hop but scale= d horizontally as 10 or
> 100 different VMs.
> >> So, IMO= , if we are not addressing this problem than what are we solving.
> &= gt;>
> >> Maria
> >>
> >
> > _= ______________________________________________
> > sfc mailing lis= t
> > sfc@ietf.org
> >= ; https://www.ietf.or= g/mailman/listinfo/sfc
>
> ________________________________= _______________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
>
= > _______________________________________________
> sfc mailing li= st
> sfc@ietf.org
> https://www.ietf.org/mailman= /listinfo/sfc
>

__________________________________________= _____
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc

= --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4E80GSCMAMP19EXfi_-- From nobody Fri Jul 11 06:27: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 3310D1A03B9 for ; Fri, 11 Jul 2014 06:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 Hu3WW8Ht9eE1 for ; Fri, 11 Jul 2014 06:27:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666E21A01AD for ; Fri, 11 Jul 2014 06:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24918; q=dns/txt; s=iport; t=1405085256; x=1406294856; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ph3l9Il7sDcAtGmvyDUaEZcPTsmgvQWWiAvCHW7OvVo=; b=J+izUQE4fFp9vHUqiZoxtIRt651y54fLwQjL9E/H9L6btEz/pl+ASAua l2i5Nh80ZnVOPbYQSFuziFXci7tnyXtXKhLj3AEq4Th1Kw+7wIX9zFuKy jb/wSafm3hxf1zvSawLyT+jAElsqGbfY+K6nm8KI6peRq1mOphHjcCRaS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAH3lv1OtJV2b/2dsb2JhbABPCoMOUlqucZF4CodCAYEKFnWEAwEBAQQBAQEXSwkCGQIBCBEBAwEBAScHJwsUAwYIAgQBEhuIEwMRDcY3EwSNGoFQBV4ChEEFih6MBEmEGotniDSDRIFvQQ X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="60078767" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 13:27:34 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6BDRF58017380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:27:15 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 08:27:15 -0500 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWA Date: Fri, 11 Jul 2014 13:27:15 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> In-Reply-To: <53BF5FB5.6020906@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.98.43.180] 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/XSHBaFWzBFZO43tfaDl-0NyEwY8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:27:21 -0000 Well I think it is even worse than that if I have understood the proposal correctly as it would require full knowledge of every single SF within the entire SFC domain at every single SFF as there is no way to know a priori which SFC=B9s a given SFF will need to service at any given point in time. On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote: >Ron, thinking about this, I realized another major problem with the your >proposal as I understand it. (And I readily admit I may not understand >it.) > >The proposal has each SFF serve as the load balancer for the next >service function that follows it (not the one it delivers to), in every >service chain that goes through it. > >Since it has to be able to work with all services, that means that every >SFF would have to be a full, flow sensitive and stateful load balancer. >I ahve no problem if some SFF are flow sensitive, and / or stateful. >But having the architecture require that every SFF be a full, flow >sensitive, stateful, load balancer seems to me to be an acceptable >imposition. > >Yours, >Joel > >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> Part of my personal view is that I am trying to make this work sensibly >> in a more orchestrated environment. I expect that the service >> functions, and over time probably the SFF capabilities, will be >> orchestrated and installed. I expect the service chains to be driven by >> BSS tools that define offerings to clients, and enable self-selection >> from these. I expect service paths to be heavily policy drive. >> >> I can see how to make all of that work in an archtiecture driven by >> initial classification to described service paths. It is harder to see >> how to make it work (but it can be done) when we allow more dynamicity >> in the network behavior. >> >> Having said that, most of that perspective I described is outside of the >> scope of the working group. it is not something we are tasked to agree >>on. >> So I do not claim that vision means we have to do it a certain way. it >> is just the perspective that drives my preferences. >> >> Yours, >> Joel >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>> For me, the amount of information about service instances that needs >>>>to >>>> be widely distributed and maintained, potentially even across data >>>> centers within an administrative scope, is large enough and complex >>>> enough that trying to get that into each SFF seems like a difficult >>>> architecture to realize. >>> >>> I'm curious as to why that is more complicated than dynamic routing, >>> hyper-scale data center orchestration, or DNS, all of which are bigger >>> problems that have been profitably and stably implemented? >>> >>> It also seems that if it really is more complicated, that is a good >>> sign that it is too complicated. >>> >>> ________________________________________ >>> From: Joel M. Halpern [jmh@joelhalpern.com] >>> Sent: Thursday, July 10, 2014 9:45 PM >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> This is an architectural issue. And one that I would prefer we >>>actually >>> decide, rather than trying to allow all possible implementations. >>> Because it does have a major effect on the control requirements and the >>> functionality of SFFs. >>> >>> For me, the amount of information about service instances that needs to >>> be widely distributed and maintained, potentially even across data >>> centers within an administrative scope, is large enough and complex >>> enough that trying to get that into each SFF seems like a difficult >>> architecture to realize. >>> >>> Yours, >>> Joel >>> >>> But it is a fair question. >>> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>> This is the crux of my issue. Is the end to end selection of >>>> (top-level) instances performed centrally (perhaps by the classifier) >>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? >>>> Such selection is not equivalent to reclassification. And surely, >>>> this is an architectural issue and not relegated to >>>> "implementation". >>>> >>>> My own view is to favor the distributed approach even though a >>>> greater amount of data (chain definitions and perhaps local selection >>>> policy) is required at those distributed decision points. This >>>> approach does not require an end-to-end path id at all. My >>>> rationale for favoring this approach is primarily driven by increased >>>> resiliency over the global path id approach. With a global path id >>>> approach, consider failure of an instance and needing to alter the >>>> global path ID table for each and every affected end-to-end path. >>>> >>>> Ron >>>> >>>> ________________________________________ From: sfc >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>>> [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> The way the architecture models the case of SF1 needing to influence >>>> the chain is that one would do reclassification at the exit from >>>> SF1. >>>> >>>> Part of the goal is to keep the different functions logically >>>> separate so that solutions can clearly describe how they choose to >>>> compose them for "service" delivery. >>>> >>>> Yours, Joel >>>> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>> I don't see anything in the arch draft that suggests any sort of >>>>> limit. However, it does seem to indicate that the entire path (all >>>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>>> either at the classifier or maybe the classifier chooses a SF Chain >>>>> and the NF or at the latest the first SFF. In any case, the >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >>>>> determined at the SFI(n-1) hop. According to the draft, this >>>>> behavior would be considered "branching" to a new SFP as opposed to >>>>> choosing and then forwarding to the selected instance of the >>>>> next-hop of the current SFC. >>>>> >>>>> draft-merged-sfc-architecture-00: >>>>>> When an SFC is instantiated into the network it is necessary to >>>>>> select the specific instances of SFs that will be used, and to >>>>>> create the service topology for that SFC using SF's network >>>>>> locator. Thus, instantiation of the SFC results in the creation >>>>>> of a Service Function Path (SFP) and is used for forwarding >>>>>> packets through the SFC. In other words, an SFP is the >>>>>> instantiation of the defined SFC. >>>>>> >>>>>> The SFC architecture supports reclassification (or non-initial >>>>>> classification) as well. As packets traverse an SFP, >>>>>> reclassification may occur - typically performed by a >>>>>> classification function co-resident with a service function. >>>>>> Reclassification may result in the selection of a new SFP, an >>>>>> update of the associated metadata, or both. This is referred to >>>>>> as "branching". >>>>> >>>>> >>>>> >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>>-- >>>>> >>>>> >>>>> >>> *From: *I.Smith@F5.com >>>>> *To: *Joel Halpern Direct,Joel M. >>>>>=20 >>>>>Halpern,huang@sce.carleton.ca>>>>ca>,sfc@ietf.org >>>>> >>>>> >>>>> >>> *Sent: *Thursday, July 10, 2014 >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Actually, I think I am disagreeing. >>>>> >>>>> If the possibility of medium-scale deployments (and that is what >>>>> 16 million flows is in my world) of service chains is preconceived >>>>> as an absurd idea, then the architecture burdened with that >>>>> preconception. >>>>> >>>>> There has to be some point of aim, some degree of aspiration to >>>>> scale that is appropriate for the lifespan of the architecture - >>>>> you don't have to know what it is, but by saying that an arbitrary >>>>> number is "too far", you're creating - even if it isn't intentional >>>>> - a limit that influences decisions that have lasting impacts >>>>> regarding scale-out, failure mitigation, elasticity, address >>>>> space... all kinds of things. That is a problem I'm not >>>>> particularly eager to deal with. >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> >>>>> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>>> Chains, Paths, and Load Balancers >>>>> >>>>> Ian, I don't think you disagree with me at all in this regard. I am >>>>> not requesting the the architecture or the solution prohibit >>>>> deployments in the specific fashion. I am objecting to Huang's >>>>> reading of my note as saying that such deployments are required >>>>> they by the archtiecture. >>>>> >>>>> As I have said repeatedly, I am not trying to prohibit such >>>>> things. Whether they are a good idea or not depends upon many >>>>> factors outside of the scope of the WG. I happen to think that they >>>>> are usually a bad idea. >>>>> >>>>> But the archtiecture si carefully avoiding attempting to know what >>>>> is and is not eployable. >>>>> >>>>> Yours, Joel >>>>> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>> I disagree. >>>>>> >>>>>> We routinely have stateful devices that manage tens of millions >>>>>> of >>>>> concurrent flows in both access network and data center >>>>> environments today. You can't seriously believe that in the >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going >>>>> to have small numbers of service chains with equally small numbers >>>>> of active service paths? >>>>>> >>>>>> Your sounds too much like "no one will ever need more than 64K" >>>>>> for >>>>> comfort. >>>>>> >>>>>> >>>>>> ________________________________________ From: sfc >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>> [jmh@joelhalpern.com] >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>> Balancers >>>>>> >>>>>> No, it will mean that if someone tries to deploy the archtieture >>>>>> particularly badly, they will exceed the limits of their >>>>>> devices. The architecture does not require such absurd use of >>>>>> service paths. Since I can not figure out how to write >>>>>> architectural words to prohibit it, the architecture does permit >>>>>> such abuse. >>>>>> >>>>>> Please do not read my saying that the archtiecture permits >>>>>> something as saying it is either deisred or required by the work. >>>>>> It isn't. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>> If you need to support 100 service chains, it will mean >>>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>>> core router. >>>>>>> >>>>>>> Chang >>>>>>> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>> operators are prepared for the complexities if they choose to >>>>>>>> avoid any use of local load balancing and in stead provision >>>>>>>> 160,000 service paths. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>>> chain with 20 instances at each hop? >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Lucy, >>>>>>>>> >>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>> forwarding. I=B9d >>>>> make >>>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>>> the needed forwarding and associated transport. >>>>>>>>> >>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>> hop(s). >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>>> >>>>>>>>> Lucy >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>> *Sent:*Thursday, July >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Re-, >>>>>>>>> >>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>> forwarding actions. >>>>>>>>> >>>>>>>>> Requiring a SFC system to have the full knowledge of every >>>>> available SFC >>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>> required/justified >>>>>>>>> nor possible in various deployment contexts. >>>>>>>>> >>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>> information >>>>> that will >>>>>>>>> be present in all deployments: that is the one required to >>>>>>>>> structure a service chain. How that information is used to >>>>>>>>> infer forwarding >>>>> actions >>>>>>>>> is a solution-oriented discussion. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Med >>>>>>>>> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>> de*mikebianc@aol.com >>>>>>>>> *Envoy=E9 :*mercredi 9 juillet >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >>>>>>>>> ;sfc@ietf.org >>>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>>> Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>>> and SF >>>>> Path? >>>>>>>>> Other than clarifying the definition so that it's clear to >>>>> those not >>>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>>> these terms. >>>>>>>>> >>>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>>> of the SFC Header >>>>> should >>>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>>> path and the choice of chain or >>>>> path to >>>>>>>>> be negotiated in the control-plane. >>>>>>>>> >>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>> >>>>>>>>> >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>>-- >>>>> >>>>> >>>>> >>>>>>> >>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>> > >>>>>>>>> *To:*sfc@ietf.org>>>>>>>> > *Sent:*Tuesday, July >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>> Balancers >>>>>>>>> >>>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>>> number of comments that have been made about the proposed >>>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>>> wording so that readers who have not participated in the WG >>>>>>>>> discussion will understnd it the way the >>>>> working >>>>>>>>> group intends. >>>>>>>>> >>>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>>> view, and see if that helps. >>>>>>>>> >>>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>>> attempting to define the architecture for the entire >>>>>>>>> solution for service chaining. That would encompass >>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>> machine and image management, and many other aspects. >>>>>>>>> >>>>>>>>> As a result there are many things which clearly need to >>>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>>> where we are >>>>> functioning, >>>>>>>>> and are not directly required by the work we are doing. >>>>>>>>> >>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>> understand >>>>> them, >>>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>>> three different ways that load balancing can and will >>>>>>>>> interact with service chaining. There probably are more. >>>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>>> but not to mandate that any particular kind >>>>> be used >>>>>>>>> in any solution. >>>>>>>>> >>>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>>> This is a service function. It receives user packets, and >>>>>>>>> modifies them (or >>>>> marks >>>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>>> to receive the users packet. This is an important service >>>>>>>>> function to be able to include in service chaining. It's >>>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>>> From an architectural pe3rspective it is simply a >>>>> service >>>>>>>>> function which may modify the underlying packet. >>>>>>>>> >>>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>>> what >>>>> appears >>>>>>>>> to the service chaining architecture as a single point of >>>>>>>>> contact >>>>> for a >>>>>>>>> specific service function, but is actually delivered by a >>>>> collection of >>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>>> is largely that we need to be careful that our terminology >>>>>>>>> does not lead >>>>> readers to >>>>>>>>> think we are prohibiting it. >>>>>>>>> >>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>>> to different places. We would not want to require that a >>>>>>>>> given service function appear at only one place in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>>> to >>>>> refer to >>>>>>>>> the collection of entities that appear to service chaining >>>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>>> point of type 3 load balancing >>>>> is to >>>>>>>>> direct different subsets of traffic to different singular >>>>>>>>> or clustered service functions in different places in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>> while a different subset is to go directly to the cache >>>>> without >>>>>>>>> visiting any other service functions. >>>>>>>>> >>>>>>>>> That is not enough information to direct the packets. A >>>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>>> in the network. Those locations will be singular or >>>>>>>>> clustered service function delivery locations. They may be >>>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>>> an SFF. There are many different ways that the locations >>>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>>> transport. >>>>>>>>> >>>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>>> need to be >>>>>>>>> able to talk about the high level abstraction, the service >>>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>>> about the actual data path packets will take in the >>>>>>>>> network. >>>>>>>>> >>>>>>>>> Several of the comments have said "but the whole path may >>>>>>>>> not be known at the front." This architecture deals with >>>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>>> make is >>>>> that >>>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>> information available at the re-classification point. >>>>>>>>> >>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>>> we can figure out what additional words are needed to >>>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>>> then we will of course adjust to match the working group >>>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>>> try next. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ sfc mailing >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 11 06:29: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 6F1761A03B9 for ; Fri, 11 Jul 2014 06:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, 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 cQqZUPxgrBdZ for ; Fri, 11 Jul 2014 06:29:15 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA77A1A009C for ; Fri, 11 Jul 2014 06:29:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9BFEF24050B; Fri, 11 Jul 2014 06:29:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DC340240380; Fri, 11 Jul 2014 06:29:12 -0700 (PDT) Message-ID: <53BFE6A8.9000903@joelhalpern.com> Date: Fri, 11 Jul 2014 09:29:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kZk3rbvN12q5JqWtppJCdJgcAIM Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:29:19 -0000 The architecture permits (and I would say even encourages) local load balancing between an SFF and the actual service functions to which it is delivering packets. The architecture prohibits service functions from adjusting the service delivery directly. And it prohibits an SFF from over-riding the decision of another SFF about how to do local load balancing to its local service functions. That leaves the possibility of having one SFF have some flexibility about which next SFF it delivers packets to. I am trying to see if there is a way to thread our way through the combination of constraints and still add some of the flexibility you suggest. We need to allow for a level of meaningful central decision. We need to allow for SFF which are not full stateful load balancers relative to other SFF. But you would like to allow the flexibility to include those. And we want an architecture that actually says something. I can not currently see how to write useful words that meet those constraints. But I will think about it. If we can allow for this flexibility without mandating every SFF to have such capability, then it seems worth allowing. Yours, Joel On 7/11/14, 9:09 AM, NAPIERALA, MARIA H wrote: >> So let me say again: the curent archtiecture proposal meets the >> requirement you state. It allows for, but does not require central laod >> balancing. It allows for, but does not require, local load balancing of >> various kinds at or with the SFF. > > We have discussed it yesterday that the language in the current architecture proposal precludes local load balancing. > And that re-classification is not "it". > > Maria > >> >> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: >>> Joel, >>> >>> The architecture has to make NO assumptions on the actual >> configuration/behavior of SFFs (whether none, some, or all of them are >> stateful, flow-aware co-located with LBs/etc.). This is deployment-specific. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>> Envoyé : vendredi 11 juillet 2014 14:08 >>>> À : Ron Parker; sfc@ietf.org >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> And it was pointed out to me that I made a two letter major typo. >>>> >>>> I was trying to say that I felt that such a requirement on all SFF would >>>> be an UNacceptable imposition. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: >>>>> Ron, thinking about this, I realized another major problem with the >> your >>>>> proposal as I understand it. (And I readily admit I may not understand >>>>> it.) >>>>> >>>>> The proposal has each SFF serve as the load balancer for the next >>>>> service function that follows it (not the one it delivers to), in every >>>>> service chain that goes through it. >>>>> >>>>> Since it has to be able to work with all services, that means that every >>>>> SFF would have to be a full, flow sensitive and stateful load balancer. >>>>> I ahve no problem if some SFF are flow sensitive, and / or stateful. But >>>>> having the architecture require that every SFF be a full, flow >>>>> sensitive, stateful, load balancer seems to me to be an acceptable >>>>> imposition. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>>>>> Part of my personal view is that I am trying to make this work sensibly >>>>>> in a more orchestrated environment. I expect that the service >>>>>> functions, and over time probably the SFF capabilities, will be >>>>>> orchestrated and installed. I expect the service chains to be driven by >>>>>> BSS tools that define offerings to clients, and enable self-selection >>>>>> from these. I expect service paths to be heavily policy drive. >>>>>> >>>>>> I can see how to make all of that work in an archtiecture driven by >>>>>> initial classification to described service paths. It is harder to see >>>>>> how to make it work (but it can be done) when we allow more >> dynamicity >>>>>> in the network behavior. >>>>>> >>>>>> Having said that, most of that perspective I described is outside of the >>>>>> scope of the working group. it is not something we are tasked to >>>>>> agree on. >>>>>> So I do not claim that vision means we have to do it a certain way. it >>>>>> is just the perspective that drives my preferences. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>>>> For me, the amount of information about service instances that >> needs >>>> to >>>>>>>> be widely distributed and maintained, potentially even across data >>>>>>>> centers within an administrative scope, is large enough and >> complex >>>>>>>> enough that trying to get that into each SFF seems like a difficult >>>>>>>> architecture to realize. >>>>>>> >>>>>>> I'm curious as to why that is more complicated than dynamic routing, >>>>>>> hyper-scale data center orchestration, or DNS, all of which are bigger >>>>>>> problems that have been profitably and stably implemented? >>>>>>> >>>>>>> It also seems that if it really is more complicated, that is a good >>>>>>> sign that it is too complicated. >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] >>>>>>> Sent: Thursday, July 10, 2014 9:45 PM >>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; >>>>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>> >>>>>>> This is an architectural issue. And one that I would prefer we >>>> actually >>>>>>> decide, rather than trying to allow all possible implementations. >>>>>>> Because it does have a major effect on the control requirements and >> the >>>>>>> functionality of SFFs. >>>>>>> >>>>>>> For me, the amount of information about service instances that >> needs to >>>>>>> be widely distributed and maintained, potentially even across data >>>>>>> centers within an administrative scope, is large enough and complex >>>>>>> enough that trying to get that into each SFF seems like a difficult >>>>>>> architecture to realize. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> But it is a fair question. >>>>>>> >>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>>>>> This is the crux of my issue. Is the end to end selection of >>>>>>>> (top-level) instances performed centrally (perhaps by the classifier) >>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently the >> SFFs)? >>>>>>>> Such selection is not equivalent to reclassification. And surely, >>>>>>>> this is an architectural issue and not relegated to >>>>>>>> "implementation". >>>>>>>> >>>>>>>> My own view is to favor the distributed approach even though a >>>>>>>> greater amount of data (chain definitions and perhaps local >> selection >>>>>>>> policy) is required at those distributed decision points. This >>>>>>>> approach does not require an end-to-end path id at all. My >>>>>>>> rationale for favoring this approach is primarily driven by increased >>>>>>>> resiliency over the global path id approach. With a global path id >>>>>>>> approach, consider failure of an instance and needing to alter the >>>>>>>> global path ID table for each and every affected end-to-end path. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> ________________________________________ From: sfc >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >>>>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> The way the architecture models the case of SF1 needing to >> influence >>>>>>>> the chain is that one would do reclassification at the exit from >>>>>>>> SF1. >>>>>>>> >>>>>>>> Part of the goal is to keep the different functions logically >>>>>>>> separate so that solutions can clearly describe how they choose to >>>>>>>> compose them for "service" delivery. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>>>>> I don't see anything in the arch draft that suggests any sort of >>>>>>>>> limit. However, it does seem to indicate that the entire path (all >>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this means >>>>>>>>> either at the classifier or maybe the classifier chooses a SF Chain >>>>>>>>> and the NF or at the latest the first SFF. In any case, the >>>>>>>>> language does seem to prohibit a more dynamic SFP where SFI(n) >> is >>>>>>>>> determined at the SFI(n-1) hop. According to the draft, this >>>>>>>>> behavior would be considered "branching" to a new SFP as >> opposed to >>>>>>>>> choosing and then forwarding to the selected instance of the >>>>>>>>> next-hop of the current SFC. >>>>>>>>> >>>>>>>>> draft-merged-sfc-architecture-00: >>>>>>>>>> When an SFC is instantiated into the network it is necessary to >>>>>>>>>> select the specific instances of SFs that will be used, and to >>>>>>>>>> create the service topology for that SFC using SF's network >>>>>>>>>> locator. Thus, instantiation of the SFC results in the creation >>>>>>>>>> of a Service Function Path (SFP) and is used for forwarding >>>>>>>>>> packets through the SFC. In other words, an SFP is the >>>>>>>>>> instantiation of the defined SFC. >>>>>>>>>> >>>>>>>>>> The SFC architecture supports reclassification (or non-initial >>>>>>>>>> classification) as well. As packets traverse an SFP, >>>>>>>>>> reclassification may occur - typically performed by a >>>>>>>>>> classification function co-resident with a service function. >>>>>>>>>> Reclassification may result in the selection of a new SFP, an >>>>>>>>>> update of the associated metadata, or both. This is referred to >>>>>>>>>> as "branching". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>> --- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> *From: *I.Smith@F5.com >>>>>>>>> *To: *Joel Halpern Direct,Joel M. >>>>>>>>> >>>> >> Halpern,huang@sce.carleton.ca> on.ca>,s >>>> fc@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> *Sent: *Thursday, July 10, 2014 >>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Actually, I think I am disagreeing. >>>>>>>>> >>>>>>>>> If the possibility of medium-scale deployments (and that is what >>>>>>>>> 16 million flows is in my world) of service chains is preconceived >>>>>>>>> as an absurd idea, then the architecture burdened with that >>>>>>>>> preconception. >>>>>>>>> >>>>>>>>> There has to be some point of aim, some degree of aspiration to >>>>>>>>> scale that is appropriate for the lifespan of the architecture - >>>>>>>>> you don't have to know what it is, but by saying that an arbitrary >>>>>>>>> number is "too far", you're creating - even if it isn't intentional >>>>>>>>> - a limit that influences decisions that have lasting impacts >>>>>>>>> regarding scale-out, failure mitigation, elasticity, address >>>>>>>>> space... all kinds of things. That is a problem I'm not >>>>>>>>> particularly eager to deal with. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________________ >>>>>>>>> >>>>>>>>> >>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Ian, I don't think you disagree with me at all in this regard. I am >>>>>>>>> not requesting the the architecture or the solution prohibit >>>>>>>>> deployments in the specific fashion. I am objecting to Huang's >>>>>>>>> reading of my note as saying that such deployments are required >>>>>>>>> they by the archtiecture. >>>>>>>>> >>>>>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>>>>> things. Whether they are a good idea or not depends upon many >>>>>>>>> factors outside of the scope of the WG. I happen to think that they >>>>>>>>> are usually a bad idea. >>>>>>>>> >>>>>>>>> But the archtiecture si carefully avoiding attempting to know what >>>>>>>>> is and is not eployable. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>>>>> I disagree. >>>>>>>>>> >>>>>>>>>> We routinely have stateful devices that manage tens of millions >>>>>>>>>> of >>>>>>>>> concurrent flows in both access network and data center >>>>>>>>> environments today. You can't seriously believe that in the >>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >> going >>>>>>>>> to have small numbers of service chains with equally small >> numbers >>>>>>>>> of active service paths? >>>>>>>>>> >>>>>>>>>> Your sounds too much like "no one will ever need more than >> 64K" >>>>>>>>>> for >>>>>>>>> comfort. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________________ From: sfc >>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>>>>> [jmh@joelhalpern.com] >>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; >>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>> Balancers >>>>>>>>>> >>>>>>>>>> No, it will mean that if someone tries to deploy the archtieture >>>>>>>>>> particularly badly, they will exceed the limits of their >>>>>>>>>> devices. The architecture does not require such absurd use of >>>>>>>>>> service paths. Since I can not figure out how to write >>>>>>>>>> architectural words to prohibit it, the architecture does permit >>>>>>>>>> such abuse. >>>>>>>>>> >>>>>>>>>> Please do not read my saying that the archtiecture permits >>>>>>>>>> something as saying it is either deisred or required by the work. >>>>>>>>>> It isn't. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>>>>> 16,000,000 paths. That is larger than the routing table of a >>>>>>>>>>> core router. >>>>>>>>>>> >>>>>>>>>>> Chang >>>>>>>>>>> >>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>>>>>> operators are prepared for the complexities if they choose to >>>>>>>>>>>> avoid any use of local load balancing and in stead provision >>>>>>>>>>>> 160,000 service paths. >>>>>>>>>>>> >>>>>>>>>>>> Yours, Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>> Paul, >>>>>>>>>>>>> >>>>>>>>>>>>> How many path identifiers there will be for a 4 hop service >>>>>>>>>>>>> chain with 20 instances at each hop? >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>>> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>> >>>>>>>>>>>>> Lucy, >>>>>>>>>>>>> >>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>>>>> forwarding. I'd >>>>>>>>> make >>>>>>>>>>>>> the minor change: the path identifier can be used to derive >>>>>>>>>>>>> the needed forwarding and associated transport. >>>>>>>>>>>>> >>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>>>>>> thread can be simply be implemented. The path identifier >>>>>>>>>>>>> provides nothing more than a lookup, that lookup can result >>>>>>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>>>>>> hop(s). >>>>>>>>>>>>> >>>>>>>>>>>>> Paul >>>>>>>>>>>>> >>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the >>>>>>>>>>>>> service path identifier to drive the forwarding actions. >>>>>>>>>>>>> >>>>>>>>>>>>> Lucy >>>>>>>>>>>>> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>>>>> *Sent:*Thursday, >> July >>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>> *Subject:*Re: [sfc] Service Chains, >>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>> >>>>>>>>>>>>> Re-, >>>>>>>>>>>>> >>>>>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>>>>>> forwarding actions. >>>>>>>>>>>>> >>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of every >>>>>>>>> available SFC >>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>>>>> required/justified >>>>>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>>>>> >>>>>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>>>>> information >>>>>>>>> that will >>>>>>>>>>>>> be present in all deployments: that is the one required to >>>>>>>>>>>>> structure a service chain. How that information is used to >>>>>>>>>>>>> infer forwarding >>>>>>>>> actions >>>>>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Med >>>>>>>>>>>>> >>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>>>>> de*mikebianc@aol.com >>>>>>>>>>>>> *Envoyé :*mercredi 9 juillet >>>>>>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, >>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>> >>>>>>>>>>>>> Is anyone still questioning the difference between SF Chain >>>>>>>>>>>>> and SF >>>>>>>>> Path? >>>>>>>>>>>>> Other than clarifying the definition so that it's clear to >>>>>>>>> those not >>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees on >>>>>>>>>>>>> these terms. >>>>>>>>>>>>> >>>>>>>>>>>>> To me, the one point that is still unclear is whether it is >>>>>>>>>>>>> the intent of this draft to ultimately specify what the ID >>>>>>>>>>>>> of the SFC Header >>>>>>>>> should >>>>>>>>>>>>> reference (the chain or the path), or if this draft simply >>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to >>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain or >>>>>>>>>>>>> path and the choice of chain or >>>>>>>>> path to >>>>>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>>>>> >>>>>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>>>>> require that both SFP and SFC be supported (or make one >>>>>>>>>>>>> required and the other optional) to avoid some vendors only >>>>>>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>> --- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>>>>> > >>>>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>>>> > *Sent:*Tuesday, July >>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>>>>>> Balancers >>>>>>>>>>>>> >>>>>>>>>>>>> I have been trying to figure out how to clearly answer a >>>>>>>>>>>>> number of comments that have been made about the >> proposed >>>>>>>>>>>>> merged archtiecture draft. Assuming we can get working >>>>>>>>>>>>> group agreement on the intent, we will work to improve the >>>>>>>>>>>>> wording so that readers who have not participated in the WG >>>>>>>>>>>>> discussion will understnd it the way the >>>>>>>>> working >>>>>>>>>>>>> group intends. >>>>>>>>>>>>> >>>>>>>>>>>>> But what do we intend? I will try to explain my personal >>>>>>>>>>>>> view, and see if that helps. >>>>>>>>>>>>> >>>>>>>>>>>>> In this regard, it is important to keep in mind that what >>>>>>>>>>>>> we are defining is the data plane architecture. We are not >>>>>>>>>>>>> attempting to define the architecture for the entire >>>>>>>>>>>>> solution for service chaining. That would encompass >>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>>>>>> machine and image management, and many other aspects. >>>>>>>>>>>>> >>>>>>>>>>>>> As a result there are many things which clearly need to >>>>>>>>>>>>> exist in the larger system, but which are dealt with above >>>>>>>>>>>>> where we are >>>>>>>>> functioning, >>>>>>>>>>>>> and are not directly required by the work we are doing. >>>>>>>>>>>>> >>>>>>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>>>>>> understand >>>>>>>>> them, >>>>>>>>>>>>> I need to first discuss load balancing. There are at least >>>>>>>>>>>>> three different ways that load balancing can and will >>>>>>>>>>>>> interact with service chaining. There probably are more. >>>>>>>>>>>>> The point of the archtiecture is to permit all of these, >>>>>>>>>>>>> but not to mandate that any particular kind >>>>>>>>> be used >>>>>>>>>>>>> in any solution. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Load balancing as a service provided to the end user. >>>>>>>>>>>>> This is a service function. It receives user packets, and >>>>>>>>>>>>> modifies them (or >>>>>>>>> marks >>>>>>>>>>>>> them, or ...) so as to choose an end user service instance >>>>>>>>>>>>> to receive the users packet. This is an important service >>>>>>>>>>>>> function to be able to include in service chaining. It's >>>>>>>>>>>>> behavior may affect requirements on how service chaining is >>>>>>>>>>>>> done. But it has very little impact on the archtiecture. >>>>>>>>>>>>> From an architectural pe3rspective it is simply a >>>>>>>>> service >>>>>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>>>>> >>>>>>>>>>>>> 2) There is internal load balancing. That is, one can have >>>>>>>>>>>>> what >>>>>>>>> appears >>>>>>>>>>>>> to the service chaining architecture as a single point of >>>>>>>>>>>>> contact >>>>>>>>> for a >>>>>>>>>>>>> specific service function, but is actually delivered by a >>>>>>>>> collection of >>>>>>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. It >>>>>>>>>>>>> is likely that it is visible to various control mechanisms, >>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm >>>>>>>>>>>>> instantiation. The architectural impact of permitting this >>>>>>>>>>>>> is largely that we need to be careful that our terminology >>>>>>>>>>>>> does not lead >>>>>>>>> readers to >>>>>>>>>>>>> think we are prohibiting it. >>>>>>>>>>>>> >>>>>>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>>>>>> packet paths for the service chaining that direct traffic >>>>>>>>>>>>> to different places. We would not want to require that a >>>>>>>>>>>>> given service function appear at only one place in the >>>>>>>>>>>>> network. >>>>>>>>>>>>> >>>>>>>>>>>>> It is of course the case that these may be combined. I tend >>>>>>>>>>>>> to >>>>>>>>> refer to >>>>>>>>>>>>> the collection of entities that appear to service chaining >>>>>>>>>>>>> as a single point as a cluster. Not because cluster is a >>>>>>>>>>>>> good term. But because I do not have another one. Thus, the >>>>>>>>>>>>> point of type 3 load balancing >>>>>>>>> is to >>>>>>>>>>>>> direct different subsets of traffic to different singular >>>>>>>>>>>>> or clustered service functions in different places in the >>>>>>>>>>>>> network. >>>>>>>>>>>>> >>>>>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>>>>> service chain and service path/ Service chain is a sequence >>>>>>>>>>>>> of logical functions to be applied to a subset of packets. >>>>>>>>>>>>> It is equivalent of saying that some subset of traffic is >>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>>>>>> while a different subset is to go directly to the cache >>>>>>>>> without >>>>>>>>>>>>> visiting any other service functions. >>>>>>>>>>>>> >>>>>>>>>>>>> That is not enough information to direct the packets. A >>>>>>>>>>>>> service path is, in some fashion, a sequence of locations >>>>>>>>>>>>> in the network. Those locations will be singular or >>>>>>>>>>>>> clustered service function delivery locations. They may be >>>>>>>>>>>>> addressed by IP address. They may be addressed as ports on >>>>>>>>>>>>> an SFF. There are many different ways that the locations >>>>>>>>>>>>> may be known to the service chaining infrastructure and the >>>>>>>>>>>>> transport. >>>>>>>>>>>>> >>>>>>>>>>>>>> From the point of view of the work of the SFC group, we >>>>>>>>>>>>>> need to be >>>>>>>>>>>>> able to talk about the high level abstraction, the service >>>>>>>>>>>>> chain, which drives the forwarding. And we need to talk >>>>>>>>>>>>> about the actual data path packets will take in the >>>>>>>>>>>>> network. >>>>>>>>>>>>> >>>>>>>>>>>>> Several of the comments have said "but the whole path may >>>>>>>>>>>>> not be known at the front." This architecture deals with >>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on load >>>>>>>>>>>>> balancers above, there can be decisions and behaviors which >>>>>>>>>>>>> are invisible to the service chaining mechanisms (in much >>>>>>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>>>>>> invisible to routing between LANs.) The other provision we >>>>>>>>>>>>> make is >>>>>>>>> that >>>>>>>>>>>>> reclassification can be done in mid-chain when necessary. >>>>>>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>>>>>> information available at the re-classification point. >>>>>>>>>>>>> >>>>>>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>>>>>> does, and if the intent is acceptable to the working group, >>>>>>>>>>>>> we can figure out what additional words are needed to >>>>>>>>>>>>> convey this. If the working group disagree with the intent, >>>>>>>>>>>>> then we will of course adjust to match the working group >>>>>>>>>>>>> agreements. If this is still unclear, I am not sure what to >>>>>>>>>>>>> try next. >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ sfc >> mailing >>>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ sfc >> mailing >>>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ sfc >> mailing >>>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc >> mailing >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >> mailing list >>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >> mailing list >>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >> list >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >> list >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing 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 Jul 11 06:38: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 0A3631B28EB for ; Fri, 11 Jul 2014 06:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQfzrpgifYmQ for ; Fri, 11 Jul 2014 06:38:46 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8274A1B27A5 for ; Fri, 11 Jul 2014 06:38:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 5e8efb35.2b98edc15940.4578636.00-2400.12687228.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:38:45 +0000 (UTC) X-MXL-Hash: 53bfe8e56362a372-826103e78287cd4bf3b1cbb6421120453e43674e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id fb8efb35.0.4578328.00-2099.12686352.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:38:08 +0000 (UTC) X-MXL-Hash: 53bfe8c0240834b4-635a3959ca7f2573ddfda6382f1045ef9257fb93 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDc6aW017417; Fri, 11 Jul 2014 09:38:07 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDbx50017302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:38:00 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:37:36 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:37:36 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAihoAgAAJJ4CAAAULAP//vwFAgABJkwD//715QA== Date: Fri, 11 Jul 2014 13:37:36 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC4A@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFE6A8.9000903@joelhalpern.com> In-Reply-To: <53BFE6A8.9000903@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=0Vge9] X-AnalysisOut: [JCLTRVmTROi7woA:9 a=wPNLvfGTeEIA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=hPjdaMEvmhQA:10 a=SRDz2l_7sHxyiJZn:21 a=oIo8q2] X-AnalysisOut: [pV01ZzY41Y:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6H7TtKG8W2gWBWeW1er4TffSiOE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:38:50 -0000 > The architecture permits (and I would say even encourages) local load > balancing between an SFF and the actual service functions to which it is > delivering packets. Local (i.e., to locally attached SFIs) load balancing is of very limited va= lue. Mostly because, for resiliency, one would want to spread SFIs across d= ifferent SFFs. >=20 > The architecture prohibits service functions from adjusting the service > delivery directly. Yes. > And it prohibits an SFF from over-riding the decision of another SFF > about how to do local load balancing to its local service functions. OK. > That leaves the possibility of having one SFF have some flexibility > about which next SFF it delivers packets to. I am trying to see if An SFF should have full flexibility to choose next SFF hop. > there is a way to thread our way through the combination of constraints > and still add some of the flexibility you suggest. > We need to allow for a level of meaningful central decision. > We need to allow for SFF which are not full stateful load balancers > relative to other SFF.=09 As Med pointed out it is implementation decision.=20 > But you would like to allow the flexibility to include those. > And we want an architecture that actually says something. >=20 > I can not currently see how to write useful words that meet those > constraints. > But I will think about it. If we can allow for this flexibility without > mandating every SFF to have such capability, then it seems worth allowing= . >=20 > Yours, > Joel >=20 > On 7/11/14, 9:09 AM, NAPIERALA, MARIA H wrote: > >> So let me say again: the curent archtiecture proposal meets the > >> requirement you state. It allows for, but does not require central la= od > >> balancing. It allows for, but does not require, local load balancing = of > >> various kinds at or with the SFF. > > > > We have discussed it yesterday that the language in the current > architecture proposal precludes local load balancing. > > And that re-classification is not "it". > > > > Maria > > > >> > >> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: > >>> Joel, > >>> > >>> The architecture has to make NO assumptions on the actual > >> configuration/behavior of SFFs (whether none, some, or all of them are > >> stateful, flow-aware co-located with LBs/etc.). This is deployment- > specific. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >>>> Envoy=E9 : vendredi 11 juillet 2014 14:08 > >>>> =C0 : Ron Parker; sfc@ietf.org > >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> And it was pointed out to me that I made a two letter major typo. > >>>> > >>>> I was trying to say that I felt that such a requirement on all SFF w= ould > >>>> be an UNacceptable imposition. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > >>>>> Ron, thinking about this, I realized another major problem with the > >> your > >>>>> proposal as I understand it. (And I readily admit I may not > understand > >>>>> it.) > >>>>> > >>>>> The proposal has each SFF serve as the load balancer for the next > >>>>> service function that follows it (not the one it delivers to), in e= very > >>>>> service chain that goes through it. > >>>>> > >>>>> Since it has to be able to work with all services, that means that > every > >>>>> SFF would have to be a full, flow sensitive and stateful load balan= cer. > >>>>> I ahve no problem if some SFF are flow sensitive, and / or stateful= . > But > >>>>> having the architecture require that every SFF be a full, flow > >>>>> sensitive, stateful, load balancer seems to me to be an acceptable > >>>>> imposition. > >>>>> > >>>>> Yours, > >>>>> Joel > >>>>> > >>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >>>>>> Part of my personal view is that I am trying to make this work > sensibly > >>>>>> in a more orchestrated environment. I expect that the service > >>>>>> functions, and over time probably the SFF capabilities, will be > >>>>>> orchestrated and installed. I expect the service chains to be dri= ven > by > >>>>>> BSS tools that define offerings to clients, and enable self-select= ion > >>>>>> from these. I expect service paths to be heavily policy drive. > >>>>>> > >>>>>> I can see how to make all of that work in an archtiecture driven b= y > >>>>>> initial classification to described service paths. It is harder t= o see > >>>>>> how to make it work (but it can be done) when we allow more > >> dynamicity > >>>>>> in the network behavior. > >>>>>> > >>>>>> Having said that, most of that perspective I described is outside = of > the > >>>>>> scope of the working group. it is not something we are tasked to > >>>>>> agree on. > >>>>>> So I do not claim that vision means we have to do it a certain way= . > it > >>>>>> is just the perspective that drives my preferences. > >>>>>> > >>>>>> Yours, > >>>>>> Joel > >>>>>> > >>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>>>>>> For me, the amount of information about service instances that > >> needs > >>>> to > >>>>>>>> be widely distributed and maintained, potentially even across > data > >>>>>>>> centers within an administrative scope, is large enough and > >> complex > >>>>>>>> enough that trying to get that into each SFF seems like a diffic= ult > >>>>>>>> architecture to realize. > >>>>>>> > >>>>>>> I'm curious as to why that is more complicated than dynamic > routing, > >>>>>>> hyper-scale data center orchestration, or DNS, all of which are > bigger > >>>>>>> problems that have been profitably and stably implemented? > >>>>>>> > >>>>>>> It also seems that if it really is more complicated, that is a go= od > >>>>>>> sign that it is too complicated. > >>>>>>> > >>>>>>> ________________________________________ > >>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>>>>>> Sent: Thursday, July 10, 2014 9:45 PM > >>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian > Smith; > >>>>>>> sfc@ietf.org > >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>>> > >>>>>>> This is an architectural issue. And one that I would prefer we > >>>> actually > >>>>>>> decide, rather than trying to allow all possible implementations. > >>>>>>> Because it does have a major effect on the control requirements > and > >> the > >>>>>>> functionality of SFFs. > >>>>>>> > >>>>>>> For me, the amount of information about service instances that > >> needs to > >>>>>>> be widely distributed and maintained, potentially even across dat= a > >>>>>>> centers within an administrative scope, is large enough and > complex > >>>>>>> enough that trying to get that into each SFF seems like a difficu= lt > >>>>>>> architecture to realize. > >>>>>>> > >>>>>>> Yours, > >>>>>>> Joel > >>>>>>> > >>>>>>> But it is a fair question. > >>>>>>> > >>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>>>>>> This is the crux of my issue. Is the end to end selection of > >>>>>>>> (top-level) instances performed centrally (perhaps by the > classifier) > >>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently the > >> SFFs)? > >>>>>>>> Such selection is not equivalent to reclassification. And sure= ly, > >>>>>>>> this is an architectural issue and not relegated to > >>>>>>>> "implementation". > >>>>>>>> > >>>>>>>> My own view is to favor the distributed approach even though a > >>>>>>>> greater amount of data (chain definitions and perhaps local > >> selection > >>>>>>>> policy) is required at those distributed decision points. This > >>>>>>>> approach does not require an end-to-end path id at all. My > >>>>>>>> rationale for favoring this approach is primarily driven by > increased > >>>>>>>> resiliency over the global path id approach. With a global pat= h > id > >>>>>>>> approach, consider failure of an instance and needing to alter t= he > >>>>>>>> global path ID table for each and every affected end-to-end path= . > >>>>>>>> > >>>>>>>> Ron > >>>>>>>> > >>>>>>>> ________________________________________ From: sfc > >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 > PM > >>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: > Re: > >>>>>>>> [sfc] Service Chains, Paths, and Load Balancers > >>>>>>>> > >>>>>>>> The way the architecture models the case of SF1 needing to > >> influence > >>>>>>>> the chain is that one would do reclassification at the exit from > >>>>>>>> SF1. > >>>>>>>> > >>>>>>>> Part of the goal is to keep the different functions logically > >>>>>>>> separate so that solutions can clearly describe how they choose > to > >>>>>>>> compose them for "service" delivery. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>>>>>> I don't see anything in the arch draft that suggests any sort o= f > >>>>>>>>> limit. However, it does seem to indicate that the entire path (= all > >>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this mean= s > >>>>>>>>> either at the classifier or maybe the classifier chooses a SF C= hain > >>>>>>>>> and the NF or at the latest the first SFF. In any case, the > >>>>>>>>> language does seem to prohibit a more dynamic SFP where > SFI(n) > >> is > >>>>>>>>> determined at the SFI(n-1) hop. According to the draft, this > >>>>>>>>> behavior would be considered "branching" to a new SFP as > >> opposed to > >>>>>>>>> choosing and then forwarding to the selected instance of the > >>>>>>>>> next-hop of the current SFC. > >>>>>>>>> > >>>>>>>>> draft-merged-sfc-architecture-00: > >>>>>>>>>> When an SFC is instantiated into the network it is necessary t= o > >>>>>>>>>> select the specific instances of SFs that will be used, and to > >>>>>>>>>> create the service topology for that SFC using SF's network > >>>>>>>>>> locator. Thus, instantiation of the SFC results in the creati= on > >>>>>>>>>> of a Service Function Path (SFP) and is used for forwarding > >>>>>>>>>> packets through the SFC. In other words, an SFP is the > >>>>>>>>>> instantiation of the defined SFC. > >>>>>>>>>> > >>>>>>>>>> The SFC architecture supports reclassification (or non-initial > >>>>>>>>>> classification) as well. As packets traverse an SFP, > >>>>>>>>>> reclassification may occur - typically performed by a > >>>>>>>>>> classification function co-resident with a service function. > >>>>>>>>>> Reclassification may result in the selection of a new SFP, an > >>>>>>>>>> update of the associated metadata, or both. This is referred = to > >>>>>>>>>> as "branching". > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ---------------------------------------------------------------= ------ > >>>> --- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> *From: *I.Smith@F5.com > >>>>>>>>> *To: *Joel Halpern Direct,Joel M. > >>>>>>>>> > >>>> > >> > Halpern,huang@sce.carleton.ca >> on.ca>,s > >>>> fc@ietf.org > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> *Sent: *Thursday, July 10, 2014 > >>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Actually, I think I am disagreeing. > >>>>>>>>> > >>>>>>>>> If the possibility of medium-scale deployments (and that is wha= t > >>>>>>>>> 16 million flows is in my world) of service chains is preconcei= ved > >>>>>>>>> as an absurd idea, then the architecture burdened with that > >>>>>>>>> preconception. > >>>>>>>>> > >>>>>>>>> There has to be some point of aim, some degree of aspiration to > >>>>>>>>> scale that is appropriate for the lifespan of the architecture = - > >>>>>>>>> you don't have to know what it is, but by saying that an > arbitrary > >>>>>>>>> number is "too far", you're creating - even if it isn't intenti= onal > >>>>>>>>> - a limit that influences decisions that have lasting impacts > >>>>>>>>> regarding scale-out, failure mitigation, elasticity, address > >>>>>>>>> space... all kinds of things. That is a problem I'm not > >>>>>>>>> particularly eager to deal with. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ________________________________________ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>>>>>>>> Chains, Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Ian, I don't think you disagree with me at all in this regard. = I am > >>>>>>>>> not requesting the the architecture or the solution prohibit > >>>>>>>>> deployments in the specific fashion. I am objecting to Huang's > >>>>>>>>> reading of my note as saying that such deployments are > required > >>>>>>>>> they by the archtiecture. > >>>>>>>>> > >>>>>>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>>>>>> things. Whether they are a good idea or not depends upon > many > >>>>>>>>> factors outside of the scope of the WG. I happen to think that > they > >>>>>>>>> are usually a bad idea. > >>>>>>>>> > >>>>>>>>> But the archtiecture si carefully avoiding attempting to know > what > >>>>>>>>> is and is not eployable. > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>>>>>> I disagree. > >>>>>>>>>> > >>>>>>>>>> We routinely have stateful devices that manage tens of > millions > >>>>>>>>>> of > >>>>>>>>> concurrent flows in both access network and data center > >>>>>>>>> environments today. You can't seriously believe that in the > >>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are > only > >> going > >>>>>>>>> to have small numbers of service chains with equally small > >> numbers > >>>>>>>>> of active service paths? > >>>>>>>>>> > >>>>>>>>>> Your sounds too much like "no one will ever need more than > >> 64K" > >>>>>>>>>> for > >>>>>>>>> comfort. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ________________________________________ From: sfc > >>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>>>>>> [jmh@joelhalpern.com] > >>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > huang@sce.carleton.ca; > >>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Loa= d > >>>>>>>>>> Balancers > >>>>>>>>>> > >>>>>>>>>> No, it will mean that if someone tries to deploy the archtietu= re > >>>>>>>>>> particularly badly, they will exceed the limits of their > >>>>>>>>>> devices. The architecture does not require such absurd use of > >>>>>>>>>> service paths. Since I can not figure out how to write > >>>>>>>>>> architectural words to prohibit it, the architecture does perm= it > >>>>>>>>>> such abuse. > >>>>>>>>>> > >>>>>>>>>> Please do not read my saying that the archtiecture permits > >>>>>>>>>> something as saying it is either deisred or required by the > work. > >>>>>>>>>> It isn't. > >>>>>>>>>> > >>>>>>>>>> Yours, Joel > >>>>>>>>>> > >>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>>>>>> If you need to support 100 service chains, it will mean > >>>>>>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>>>>>>>>>> core router. > >>>>>>>>>>> > >>>>>>>>>>> Chang > >>>>>>>>>>> > >>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>>>>>> service path to 160000 service paths. I would hope that > >>>>>>>>>>>> operators are prepared for the complexities if they choose > to > >>>>>>>>>>>> avoid any use of local load balancing and in stead provision > >>>>>>>>>>>> 160,000 service paths. > >>>>>>>>>>>> > >>>>>>>>>>>> Yours, Joel > >>>>>>>>>>>> > >>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>>>>>> Paul, > >>>>>>>>>>>>> > >>>>>>>>>>>>> How many path identifiers there will be for a 4 hop service > >>>>>>>>>>>>> chain with 20 instances at each hop? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Maria > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>>>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>>>> > >>>>>>>>>>>>> Lucy, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>>>>>> forwarding. I'd > >>>>>>>>> make > >>>>>>>>>>>>> the minor change: the path identifier can be used to derive > >>>>>>>>>>>>> the needed forwarding and associated transport. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply > >>>>>>>>>>>>> identify the service path (or graph) that packets must > >>>>>>>>>>>>> traverse. By having a path identifier, the exact > >>>>>>>>>>>>> indirection that people seem to be asking for on this > >>>>>>>>>>>>> thread can be simply be implemented. The path identifier > >>>>>>>>>>>>> provides nothing more than a lookup, that lookup can > result > >>>>>>>>>>>>> in a one or more (equal or weighted) transport next > >>>>>>>>>>>>> hop(s). > >>>>>>>>>>>>> > >>>>>>>>>>>>> Paul > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>>>>>> > > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>>>>>>>>>>>> service path identifier to drive the forwarding actions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Lucy > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>>>>>> > *Sent:*Thursday, > >> July > >>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>>>>>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>>>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>>>> > >>>>>>>>>>>>> Re-, > >>>>>>>>>>>>> > >>>>>>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>>>>>> identifier. I object to use that identifier to derive > >>>>>>>>>>>>> forwarding actions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>>>>>>>> available SFC > >>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>>>>>> required/justified > >>>>>>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>>>>>> > >>>>>>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>>>>>> information > >>>>>>>>> that will > >>>>>>>>>>>>> be present in all deployments: that is the one required to > >>>>>>>>>>>>> structure a service chain. How that information is used to > >>>>>>>>>>>>> infer forwarding > >>>>>>>>> actions > >>>>>>>>>>>>> is a solution-oriented discussion. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Med > >>>>>>>>>>>>> > >>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>>>>>> de*mikebianc@aol.com > >>>>>>>>>>>>> *Envoy=E9 :*mercredi 9 juillet > >>>>>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>>>>>> ;sfc@ietf.org > >>>>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>>>>>>>>>>>> Paths, and Load Balancers > >>>>>>>>>>>>> > >>>>>>>>>>>>> Is anyone still questioning the difference between SF Chain > >>>>>>>>>>>>> and SF > >>>>>>>>> Path? > >>>>>>>>>>>>> Other than clarifying the definition so that it's clear to > >>>>>>>>> those not > >>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>>>>>>>>>>>> these terms. > >>>>>>>>>>>>> > >>>>>>>>>>>>> To me, the one point that is still unclear is whether it is > >>>>>>>>>>>>> the intent of this draft to ultimately specify what the ID > >>>>>>>>>>>>> of the SFC Header > >>>>>>>>> should > >>>>>>>>>>>>> reference (the chain or the path), or if this draft simply > >>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>>>>>>>>>>>> path and the choice of chain or > >>>>>>>>> path to > >>>>>>>>>>>>> be negotiated in the control-plane. > >>>>>>>>>>>>> > >>>>>>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>>>>>> require that both SFP and SFC be supported (or make one > >>>>>>>>>>>>> required and the other optional) to avoid some vendors > only > >>>>>>>>>>>>> supporting SFP and others only supporting SFC. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> ---------------------------------------------------------------= ------ > >>>> --- > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>>>>>> > > >>>>>>>>>>>>> *To:*sfc@ietf.org >>>>>>>>>>>>> > *Sent:*Tuesday, July > >>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>>>>>>>>>>>> Balancers > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have been trying to figure out how to clearly answer a > >>>>>>>>>>>>> number of comments that have been made about the > >> proposed > >>>>>>>>>>>>> merged archtiecture draft. Assuming we can get working > >>>>>>>>>>>>> group agreement on the intent, we will work to improve > the > >>>>>>>>>>>>> wording so that readers who have not participated in the > WG > >>>>>>>>>>>>> discussion will understnd it the way the > >>>>>>>>> working > >>>>>>>>>>>>> group intends. > >>>>>>>>>>>>> > >>>>>>>>>>>>> But what do we intend? I will try to explain my personal > >>>>>>>>>>>>> view, and see if that helps. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In this regard, it is important to keep in mind that what > >>>>>>>>>>>>> we are defining is the data plane architecture. We are not > >>>>>>>>>>>>> attempting to define the architecture for the entire > >>>>>>>>>>>>> solution for service chaining. That would encompass > >>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>>>>>>>>>>>> machine and image management, and many other aspects. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As a result there are many things which clearly need to > >>>>>>>>>>>>> exist in the larger system, but which are dealt with above > >>>>>>>>>>>>> where we are > >>>>>>>>> functioning, > >>>>>>>>>>>>> and are not directly required by the work we are doing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In order to get to service chain vs service path, as I > >>>>>>>>>>>>> understand > >>>>>>>>> them, > >>>>>>>>>>>>> I need to first discuss load balancing. There are at least > >>>>>>>>>>>>> three different ways that load balancing can and will > >>>>>>>>>>>>> interact with service chaining. There probably are more. > >>>>>>>>>>>>> The point of the archtiecture is to permit all of these, > >>>>>>>>>>>>> but not to mandate that any particular kind > >>>>>>>>> be used > >>>>>>>>>>>>> in any solution. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1) Load balancing as a service provided to the end user. > >>>>>>>>>>>>> This is a service function. It receives user packets, and > >>>>>>>>>>>>> modifies them (or > >>>>>>>>> marks > >>>>>>>>>>>>> them, or ...) so as to choose an end user service instance > >>>>>>>>>>>>> to receive the users packet. This is an important service > >>>>>>>>>>>>> function to be able to include in service chaining. It's > >>>>>>>>>>>>> behavior may affect requirements on how service chaining > is > >>>>>>>>>>>>> done. But it has very little impact on the archtiecture. > >>>>>>>>>>>>> From an architectural pe3rspective it is simply a > >>>>>>>>> service > >>>>>>>>>>>>> function which may modify the underlying packet. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2) There is internal load balancing. That is, one can have > >>>>>>>>>>>>> what > >>>>>>>>> appears > >>>>>>>>>>>>> to the service chaining architecture as a single point of > >>>>>>>>>>>>> contact > >>>>>>>>> for a > >>>>>>>>>>>>> specific service function, but is actually delivered by a > >>>>>>>>> collection of > >>>>>>>>>>>>> virtual or physical machines, possibly including one or > >>>>>>>>>>>>> several load balancers (for example using VRRP-like > >>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is > >>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. It > >>>>>>>>>>>>> is likely that it is visible to various control mechanisms, > >>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>>>>>>>>>>>> instantiation. The architectural impact of permitting this > >>>>>>>>>>>>> is largely that we need to be careful that our terminology > >>>>>>>>>>>>> does not lead > >>>>>>>>> readers to > >>>>>>>>>>>>> think we are prohibiting it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 3) There can also be load balancing done by selecting > >>>>>>>>>>>>> packet paths for the service chaining that direct traffic > >>>>>>>>>>>>> to different places. We would not want to require that a > >>>>>>>>>>>>> given service function appear at only one place in the > >>>>>>>>>>>>> network. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It is of course the case that these may be combined. I tend > >>>>>>>>>>>>> to > >>>>>>>>> refer to > >>>>>>>>>>>>> the collection of entities that appear to service chaining > >>>>>>>>>>>>> as a single point as a cluster. Not because cluster is a > >>>>>>>>>>>>> good term. But because I do not have another one. Thus, > the > >>>>>>>>>>>>> point of type 3 load balancing > >>>>>>>>> is to > >>>>>>>>>>>>> direct different subsets of traffic to different singular > >>>>>>>>>>>>> or clustered service functions in different places in the > >>>>>>>>>>>>> network. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>>>>>> service chain and service path/ Service chain is a sequence > >>>>>>>>>>>>> of logical functions to be applied to a subset of packets. > >>>>>>>>>>>>> It is equivalent of saying that some subset of traffic is > >>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall > >>>>>>>>>>>>> while a different subset is to go directly to the cache > >>>>>>>>> without > >>>>>>>>>>>>> visiting any other service functions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> That is not enough information to direct the packets. A > >>>>>>>>>>>>> service path is, in some fashion, a sequence of locations > >>>>>>>>>>>>> in the network. Those locations will be singular or > >>>>>>>>>>>>> clustered service function delivery locations. They may be > >>>>>>>>>>>>> addressed by IP address. They may be addressed as ports > on > >>>>>>>>>>>>> an SFF. There are many different ways that the locations > >>>>>>>>>>>>> may be known to the service chaining infrastructure and > the > >>>>>>>>>>>>> transport. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> From the point of view of the work of the SFC group, we > >>>>>>>>>>>>>> need to be > >>>>>>>>>>>>> able to talk about the high level abstraction, the service > >>>>>>>>>>>>> chain, which drives the forwarding. And we need to talk > >>>>>>>>>>>>> about the actual data path packets will take in the > >>>>>>>>>>>>> network. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Several of the comments have said "but the whole path > may > >>>>>>>>>>>>> not be known at the front." This architecture deals with > >>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >>>>>>>>>>>>> balancers above, there can be decisions and behaviors > which > >>>>>>>>>>>>> are invisible to the service chaining mechanisms (in much > >>>>>>>>>>>>> the same way that bridging within a LAN is largely > >>>>>>>>>>>>> invisible to routing between LANs.) The other provision we > >>>>>>>>>>>>> make is > >>>>>>>>> that > >>>>>>>>>>>>> reclassification can be done in mid-chain when necessary. > >>>>>>>>>>>>> That will direct packets to a new chain. Based on > >>>>>>>>>>>>> information available at the re-classification point. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I hope that this helps explain what we are after. If it > >>>>>>>>>>>>> does, and if the intent is acceptable to the working group, > >>>>>>>>>>>>> we can figure out what additional words are needed to > >>>>>>>>>>>>> convey this. If the working group disagree with the intent, > >>>>>>>>>>>>> then we will of course adjust to match the working group > >>>>>>>>>>>>> agreements. If this is still unclear, I am not sure what to > >>>>>>>>>>>>> try next. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yours, Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ sfc > >> mailing > >>>>>>>>>>>>> list sfc@ietf.org > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ sfc > >> mailing > >>>>>>>>>>>>> list sfc@ietf.org > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ sfc > >> mailing > >>>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ sfc > >> mailing > >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > >> mailing list > >>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >> mailing list > >>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >> list > >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >> list > >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sfc mailing 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 Jul 11 06:49: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 80C171B2AC6 for ; Fri, 11 Jul 2014 06:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJA88Zp0VYUf for ; Fri, 11 Jul 2014 06:49:06 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1911B28AF for ; Fri, 11 Jul 2014 06:49:06 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 25befb35.2ac006449940.6638845.00-2448.18373695.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:49:06 +0000 (UTC) X-MXL-Hash: 53bfeb5218fa70e1-950ec0f958b6b3339bce954af5437903f0032f34 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e4befb35.0.6638800.00-2394.18373558.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:49:04 +0000 (UTC) X-MXL-Hash: 53bfeb505fefb159-b981add323cbaf5ab1ff879d2f17330898f76304 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDn25B029723; Fri, 11 Jul 2014 09:49:02 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDmppM029526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:48:59 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:48:34 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:48:33 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlA= Date: Fri, 11 Jul 2014 13:48:33 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 ] X-AnalysisOut: [a=n2LCcfabAAAA:8 a=z9tbli-vAAAA:8 a=i0EeH86SAAAA:8 a=M_s43] X-AnalysisOut: [9rZU_j1SnER2ZcA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=ch] X-AnalysisOut: [C_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037QrwtgA:10 a=oAXR_k] X-AnalysisOut: [dF8uMA:10 a=hPjdaMEvmhQA:10 a=iC4aPqJhItDjKnr9:21 a=oyR6BZ] X-AnalysisOut: [ecZs5IGiay:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wfOoDtdCAQO6z1Kx1N6G_teq9HA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:49:10 -0000 Absolutely not. Service chains can be instantiated only in relevant SFFs wh= en they "arrive".=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar) > Sent: Friday, July 11, 2014 9:27 AM > To: Joel M. Halpern; Ron Parker; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Well I think it is even worse than that if I have understood the proposal > correctly as it would require full knowledge of every single SF within th= e > entire SFC domain at every single SFF as there is no way to know a priori > which SFC=B9s a given SFF will need to service at any given point in time= . >=20 > On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote: >=20 > >Ron, thinking about this, I realized another major problem with the your > >proposal as I understand it. (And I readily admit I may not understand > >it.) > > > >The proposal has each SFF serve as the load balancer for the next > >service function that follows it (not the one it delivers to), in every > >service chain that goes through it. > > > >Since it has to be able to work with all services, that means that every > >SFF would have to be a full, flow sensitive and stateful load balancer. > >I ahve no problem if some SFF are flow sensitive, and / or stateful. > >But having the architecture require that every SFF be a full, flow > >sensitive, stateful, load balancer seems to me to be an acceptable > >imposition. > > > >Yours, > >Joel > > > >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >> Part of my personal view is that I am trying to make this work sensibl= y > >> in a more orchestrated environment. I expect that the service > >> functions, and over time probably the SFF capabilities, will be > >> orchestrated and installed. I expect the service chains to be driven = by > >> BSS tools that define offerings to clients, and enable self-selection > >> from these. I expect service paths to be heavily policy drive. > >> > >> I can see how to make all of that work in an archtiecture driven by > >> initial classification to described service paths. It is harder to se= e > >> how to make it work (but it can be done) when we allow more > dynamicity > >> in the network behavior. > >> > >> Having said that, most of that perspective I described is outside of t= he > >> scope of the working group. it is not something we are tasked to agre= e > >>on. > >> So I do not claim that vision means we have to do it a certain way. i= t > >> is just the perspective that drives my preferences. > >> > >> Yours, > >> Joel > >> > >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>>> For me, the amount of information about service instances that needs > >>>>to > >>>> be widely distributed and maintained, potentially even across data > >>>> centers within an administrative scope, is large enough and complex > >>>> enough that trying to get that into each SFF seems like a difficult > >>>> architecture to realize. > >>> > >>> I'm curious as to why that is more complicated than dynamic routing, > >>> hyper-scale data center orchestration, or DNS, all of which are bigge= r > >>> problems that have been profitably and stably implemented? > >>> > >>> It also seems that if it really is more complicated, that is a good > >>> sign that it is too complicated. > >>> > >>> ________________________________________ > >>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>> Sent: Thursday, July 10, 2014 9:45 PM > >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith; > >>> sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> This is an architectural issue. And one that I would prefer we > >>>actually > >>> decide, rather than trying to allow all possible implementations. > >>> Because it does have a major effect on the control requirements and > the > >>> functionality of SFFs. > >>> > >>> For me, the amount of information about service instances that needs > to > >>> be widely distributed and maintained, potentially even across data > >>> centers within an administrative scope, is large enough and complex > >>> enough that trying to get that into each SFF seems like a difficult > >>> architecture to realize. > >>> > >>> Yours, > >>> Joel > >>> > >>> But it is a fair question. > >>> > >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>>> This is the crux of my issue. Is the end to end selection of > >>>> (top-level) instances performed centrally (perhaps by the classifier= ) > >>>> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)? > >>>> Such selection is not equivalent to reclassification. And surely, > >>>> this is an architectural issue and not relegated to > >>>> "implementation". > >>>> > >>>> My own view is to favor the distributed approach even though a > >>>> greater amount of data (chain definitions and perhaps local selectio= n > >>>> policy) is required at those distributed decision points. This > >>>> approach does not require an end-to-end path id at all. My > >>>> rationale for favoring this approach is primarily driven by increase= d > >>>> resiliency over the global path id approach. With a global path id > >>>> approach, consider failure of an instance and needing to alter the > >>>> global path ID table for each and every affected end-to-end path. > >>>> > >>>> Ron > >>>> > >>>> ________________________________________ From: sfc > >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM > >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: > >>>> [sfc] Service Chains, Paths, and Load Balancers > >>>> > >>>> The way the architecture models the case of SF1 needing to influence > >>>> the chain is that one would do reclassification at the exit from > >>>> SF1. > >>>> > >>>> Part of the goal is to keep the different functions logically > >>>> separate so that solutions can clearly describe how they choose to > >>>> compose them for "service" delivery. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>>>> I don't see anything in the arch draft that suggests any sort of > >>>>> limit. However, it does seem to indicate that the entire path (all > >>>>> SFIs) must be chosen at SFC instantiation. I believe this means > >>>>> either at the classifier or maybe the classifier chooses a SF Chain > >>>>> and the NF or at the latest the first SFF. In any case, the > >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is > >>>>> determined at the SFI(n-1) hop. According to the draft, this > >>>>> behavior would be considered "branching" to a new SFP as opposed > to > >>>>> choosing and then forwarding to the selected instance of the > >>>>> next-hop of the current SFC. > >>>>> > >>>>> draft-merged-sfc-architecture-00: > >>>>>> When an SFC is instantiated into the network it is necessary to > >>>>>> select the specific instances of SFs that will be used, and to > >>>>>> create the service topology for that SFC using SF's network > >>>>>> locator. Thus, instantiation of the SFC results in the creation > >>>>>> of a Service Function Path (SFP) and is used for forwarding > >>>>>> packets through the SFC. In other words, an SFP is the > >>>>>> instantiation of the defined SFC. > >>>>>> > >>>>>> The SFC architecture supports reclassification (or non-initial > >>>>>> classification) as well. As packets traverse an SFP, > >>>>>> reclassification may occur - typically performed by a > >>>>>> classification function co-resident with a service function. > >>>>>> Reclassification may result in the selection of a new SFP, an > >>>>>> update of the associated metadata, or both. This is referred to > >>>>>> as "branching". > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>--------------------------------------------------------------------= -- > >>>>>-- > >>>>> > >>>>> > >>>>> > >>> *From: *I.Smith@F5.com > >>>>> *To: *Joel Halpern Direct,Joel M. > >>>>> > >>>>>Halpern,huang@sce.carleton.ca carleton. > >>>>>ca>,sfc@ietf.org > >>>>> > >>>>> > >>>>> > >>> *Sent: *Thursday, July 10, 2014 > >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>>>> > >>>>> Actually, I think I am disagreeing. > >>>>> > >>>>> If the possibility of medium-scale deployments (and that is what > >>>>> 16 million flows is in my world) of service chains is preconceived > >>>>> as an absurd idea, then the architecture burdened with that > >>>>> preconception. > >>>>> > >>>>> There has to be some point of aim, some degree of aspiration to > >>>>> scale that is appropriate for the lifespan of the architecture - > >>>>> you don't have to know what it is, but by saying that an arbitrary > >>>>> number is "too far", you're creating - even if it isn't intentional > >>>>> - a limit that influences decisions that have lasting impacts > >>>>> regarding scale-out, failure mitigation, elasticity, address > >>>>> space... all kinds of things. That is a problem I'm not > >>>>> particularly eager to deal with. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ________________________________________ > >>>>> > >>>>> > >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>>>> Chains, Paths, and Load Balancers > >>>>> > >>>>> Ian, I don't think you disagree with me at all in this regard. I am > >>>>> not requesting the the architecture or the solution prohibit > >>>>> deployments in the specific fashion. I am objecting to Huang's > >>>>> reading of my note as saying that such deployments are required > >>>>> they by the archtiecture. > >>>>> > >>>>> As I have said repeatedly, I am not trying to prohibit such > >>>>> things. Whether they are a good idea or not depends upon many > >>>>> factors outside of the scope of the WG. I happen to think that they > >>>>> are usually a bad idea. > >>>>> > >>>>> But the archtiecture si carefully avoiding attempting to know what > >>>>> is and is not eployable. > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>>>>> I disagree. > >>>>>> > >>>>>> We routinely have stateful devices that manage tens of millions > >>>>>> of > >>>>> concurrent flows in both access network and data center > >>>>> environments today. You can't seriously believe that in the > >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > going > >>>>> to have small numbers of service chains with equally small numbers > >>>>> of active service paths? > >>>>>> > >>>>>> Your sounds too much like "no one will ever need more than 64K" > >>>>>> for > >>>>> comfort. > >>>>>> > >>>>>> > >>>>>> ________________________________________ From: sfc > >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>>>> [jmh@joelhalpern.com] > >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca; > >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load > >>>>>> Balancers > >>>>>> > >>>>>> No, it will mean that if someone tries to deploy the archtieture > >>>>>> particularly badly, they will exceed the limits of their > >>>>>> devices. The architecture does not require such absurd use of > >>>>>> service paths. Since I can not figure out how to write > >>>>>> architectural words to prohibit it, the architecture does permit > >>>>>> such abuse. > >>>>>> > >>>>>> Please do not read my saying that the archtiecture permits > >>>>>> something as saying it is either deisred or required by the work. > >>>>>> It isn't. > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>>>>>> If you need to support 100 service chains, it will mean > >>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>>>>>> core router. > >>>>>>> > >>>>>>> Chang > >>>>>>> > >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>>>>>>> The architecture allows a range of deployments, from 1 > >>>>>>>> service path to 160000 service paths. I would hope that > >>>>>>>> operators are prepared for the complexities if they choose to > >>>>>>>> avoid any use of local load balancing and in stead provision > >>>>>>>> 160,000 service paths. > >>>>>>>> > >>>>>>>> Yours, Joel > >>>>>>>> > >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>>>>>>>> Paul, > >>>>>>>>> > >>>>>>>>> How many path identifiers there will be for a 4 hop service > >>>>>>>>> chain with 20 instances at each hop? > >>>>>>>>> > >>>>>>>>> Maria > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Lucy, > >>>>>>>>> > >>>>>>>>> Overall I concur, as you say: a path ID drives the > >>>>>>>>> forwarding. I=B9d > >>>>> make > >>>>>>>>> the minor change: the path identifier can be used to derive > >>>>>>>>> the needed forwarding and associated transport. > >>>>>>>>> > >>>>>>>>> It is _not_ the transport, but rather is used to simply > >>>>>>>>> identify the service path (or graph) that packets must > >>>>>>>>> traverse. By having a path identifier, the exact > >>>>>>>>> indirection that people seem to be asking for on this > >>>>>>>>> thread can be simply be implemented. The path identifier > >>>>>>>>> provides nothing more than a lookup, that lookup can result > >>>>>>>>> in a one or more (equal or weighted) transport next > >>>>>>>>> hop(s). > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>>>>>>>> > > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>>>>>>>> service path identifier to drive the forwarding actions. > >>>>>>>>> > >>>>>>>>> Lucy > >>>>>>>>> > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>>>>>>>> Of*mohamed.boucadair@orange.com > >>>>>>>>> *Sent:*Thursday, > July > >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>>>>>>>> ;jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Re-, > >>>>>>>>> > >>>>>>>>> The merged draft calls out explicitly a service path > >>>>>>>>> identifier. I object to use that identifier to derive > >>>>>>>>> forwarding actions. > >>>>>>>>> > >>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>>>> available SFC > >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>>>> required/justified > >>>>>>>>> nor possible in various deployment contexts. > >>>>>>>>> > >>>>>>>>> SFC forwarding actions should rely on the piece of > >>>>>>>>> information > >>>>> that will > >>>>>>>>> be present in all deployments: that is the one required to > >>>>>>>>> structure a service chain. How that information is used to > >>>>>>>>> infer forwarding > >>>>> actions > >>>>>>>>> is a solution-oriented discussion. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Med > >>>>>>>>> > >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>>>> de*mikebianc@aol.com > >>>>>>>>> *Envoy=E9 :*mercredi 9 juillet > >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >>>>>>>>> ;sfc@ietf.org > >>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>>>>>>>> Paths, and Load Balancers > >>>>>>>>> > >>>>>>>>> Is anyone still questioning the difference between SF Chain > >>>>>>>>> and SF > >>>>> Path? > >>>>>>>>> Other than clarifying the definition so that it's clear to > >>>>> those not > >>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>>>>>>>> these terms. > >>>>>>>>> > >>>>>>>>> To me, the one point that is still unclear is whether it is > >>>>>>>>> the intent of this draft to ultimately specify what the ID > >>>>>>>>> of the SFC Header > >>>>> should > >>>>>>>>> reference (the chain or the path), or if this draft simply > >>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>>>>>>>> path and the choice of chain or > >>>>> path to > >>>>>>>>> be negotiated in the control-plane. > >>>>>>>>> > >>>>>>>>> If the latter (ambiguous), then the draft would have > >>>>>>>>> require that both SFP and SFC be supported (or make one > >>>>>>>>> required and the other optional) to avoid some vendors only > >>>>>>>>> supporting SFP and others only supporting SFC. > >>>>>>>>> > >>>>>>>>> > >>>>> > >>>>>--------------------------------------------------------------------= -- > >>>>>-- > >>>>> > >>>>> > >>>>> > >>>>>>> > >>>>>>>>> *From:*jmh@joelhalpern.com >>>>>>>>> > > >>>>>>>>> *To:*sfc@ietf.org >>>>>>>>> > *Sent:*Tuesday, July > >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>>>>>>>> Balancers > >>>>>>>>> > >>>>>>>>> I have been trying to figure out how to clearly answer a > >>>>>>>>> number of comments that have been made about the proposed > >>>>>>>>> merged archtiecture draft. Assuming we can get working > >>>>>>>>> group agreement on the intent, we will work to improve the > >>>>>>>>> wording so that readers who have not participated in the WG > >>>>>>>>> discussion will understnd it the way the > >>>>> working > >>>>>>>>> group intends. > >>>>>>>>> > >>>>>>>>> But what do we intend? I will try to explain my personal > >>>>>>>>> view, and see if that helps. > >>>>>>>>> > >>>>>>>>> In this regard, it is important to keep in mind that what > >>>>>>>>> we are defining is the data plane architecture. We are not > >>>>>>>>> attempting to define the architecture for the entire > >>>>>>>>> solution for service chaining. That would encompass > >>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>>>>>>>> machine and image management, and many other aspects. > >>>>>>>>> > >>>>>>>>> As a result there are many things which clearly need to > >>>>>>>>> exist in the larger system, but which are dealt with above > >>>>>>>>> where we are > >>>>> functioning, > >>>>>>>>> and are not directly required by the work we are doing. > >>>>>>>>> > >>>>>>>>> In order to get to service chain vs service path, as I > >>>>>>>>> understand > >>>>> them, > >>>>>>>>> I need to first discuss load balancing. There are at least > >>>>>>>>> three different ways that load balancing can and will > >>>>>>>>> interact with service chaining. There probably are more. > >>>>>>>>> The point of the archtiecture is to permit all of these, > >>>>>>>>> but not to mandate that any particular kind > >>>>> be used > >>>>>>>>> in any solution. > >>>>>>>>> > >>>>>>>>> 1) Load balancing as a service provided to the end user. > >>>>>>>>> This is a service function. It receives user packets, and > >>>>>>>>> modifies them (or > >>>>> marks > >>>>>>>>> them, or ...) so as to choose an end user service instance > >>>>>>>>> to receive the users packet. This is an important service > >>>>>>>>> function to be able to include in service chaining. It's > >>>>>>>>> behavior may affect requirements on how service chaining is > >>>>>>>>> done. But it has very little impact on the archtiecture. > >>>>>>>>> From an architectural pe3rspective it is simply a > >>>>> service > >>>>>>>>> function which may modify the underlying packet. > >>>>>>>>> > >>>>>>>>> 2) There is internal load balancing. That is, one can have > >>>>>>>>> what > >>>>> appears > >>>>>>>>> to the service chaining architecture as a single point of > >>>>>>>>> contact > >>>>> for a > >>>>>>>>> specific service function, but is actually delivered by a > >>>>> collection of > >>>>>>>>> virtual or physical machines, possibly including one or > >>>>>>>>> several load balancers (for example using VRRP-like > >>>>>>>>> techniques to share a MAC address.) mostly, this is > >>>>>>>>> invisible to the service chaining data plane mechanisms. It > >>>>>>>>> is likely that it is visible to various control mechanisms, > >>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>>>>>>>> instantiation. The architectural impact of permitting this > >>>>>>>>> is largely that we need to be careful that our terminology > >>>>>>>>> does not lead > >>>>> readers to > >>>>>>>>> think we are prohibiting it. > >>>>>>>>> > >>>>>>>>> 3) There can also be load balancing done by selecting > >>>>>>>>> packet paths for the service chaining that direct traffic > >>>>>>>>> to different places. We would not want to require that a > >>>>>>>>> given service function appear at only one place in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> It is of course the case that these may be combined. I tend > >>>>>>>>> to > >>>>> refer to > >>>>>>>>> the collection of entities that appear to service chaining > >>>>>>>>> as a single point as a cluster. Not because cluster is a > >>>>>>>>> good term. But because I do not have another one. Thus, the > >>>>>>>>> point of type 3 load balancing > >>>>> is to > >>>>>>>>> direct different subsets of traffic to different singular > >>>>>>>>> or clustered service functions in different places in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> Now with that said, what do I mean when I talk about > >>>>>>>>> service chain and service path/ Service chain is a sequence > >>>>>>>>> of logical functions to be applied to a subset of packets. > >>>>>>>>> It is equivalent of saying that some subset of traffic is > >>>>>>>>> to get DPI, charging, content inspection, and firewall > >>>>>>>>> while a different subset is to go directly to the cache > >>>>> without > >>>>>>>>> visiting any other service functions. > >>>>>>>>> > >>>>>>>>> That is not enough information to direct the packets. A > >>>>>>>>> service path is, in some fashion, a sequence of locations > >>>>>>>>> in the network. Those locations will be singular or > >>>>>>>>> clustered service function delivery locations. They may be > >>>>>>>>> addressed by IP address. They may be addressed as ports on > >>>>>>>>> an SFF. There are many different ways that the locations > >>>>>>>>> may be known to the service chaining infrastructure and the > >>>>>>>>> transport. > >>>>>>>>> > >>>>>>>>>> From the point of view of the work of the SFC group, we > >>>>>>>>>> need to be > >>>>>>>>> able to talk about the high level abstraction, the service > >>>>>>>>> chain, which drives the forwarding. And we need to talk > >>>>>>>>> about the actual data path packets will take in the > >>>>>>>>> network. > >>>>>>>>> > >>>>>>>>> Several of the comments have said "but the whole path may > >>>>>>>>> not be known at the front." This architecture deals with > >>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >>>>>>>>> balancers above, there can be decisions and behaviors which > >>>>>>>>> are invisible to the service chaining mechanisms (in much > >>>>>>>>> the same way that bridging within a LAN is largely > >>>>>>>>> invisible to routing between LANs.) The other provision we > >>>>>>>>> make is > >>>>> that > >>>>>>>>> reclassification can be done in mid-chain when necessary. > >>>>>>>>> That will direct packets to a new chain. Based on > >>>>>>>>> information available at the re-classification point. > >>>>>>>>> > >>>>>>>>> I hope that this helps explain what we are after. If it > >>>>>>>>> does, and if the intent is acceptable to the working group, > >>>>>>>>> we can figure out what additional words are needed to > >>>>>>>>> convey this. If the working group disagree with the intent, > >>>>>>>>> then we will of course adjust to match the working group > >>>>>>>>> agreements. If this is still unclear, I am not sure what to > >>>>>>>>> try next. > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>>> list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > mailing > >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ sfc > mailing > >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ sfc mailing > list > >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>>> _______________________________________________ sfc mailing > list > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > list > >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > list > >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Fri Jul 11 06:49: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 6E9961B28AF for ; Fri, 11 Jul 2014 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.552 X-Spam-Level: X-Spam-Status: No, score=-16.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 NjbJSK1xM2sI for ; Fri, 11 Jul 2014 06:49:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C442B1B2AFE for ; Fri, 11 Jul 2014 06:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33006; q=dns/txt; s=iport; t=1405086590; x=1406296190; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4CubNkMkmecQ8BjVVOWtjmQrhiSjDO+oqduWJxtU6LM=; b=TES59p6RgV90OFNCryrExvEQ4Pog3vunXH5bS58/wdILhXocujFEgQO9 wxa9tTobWlmLZTb+5DRAxoZzuwtyg4WQQvp/UvdidpnidoWJ39oiviFYU HCEcq1G3xDDikVNnPjwZrrMrype2RJvR00JVFY3OiouP6VjyfXSWjxLLG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAC/qv1OtJV2R/2dsb2JhbABPCoMOUlqucZF4CodCAYEKFnWEAwEBAQMBAQEBFwFKCQIZAgEIEQEDAQEBJwcnCxQDBggCBAESG4gTAwkIDcYtF40agVAEASwFIQwCBIQ9BYoejARJhBqLZ4g0g0SBbgEfIg X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="60084359" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 13:49:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6BDnSRs024403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:49:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 08:49:28 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAihoAgAAJJoCAAAULAIAAAwSAgAAFkACAAAJZAP//wAAA Date: Fri, 11 Jul 2014 13:49:27 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFE6A8.9000903@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC4A@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC4A@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8B3D99E5F850FE42A926A693D2696D27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YrGuv9r5S44y3rzPoYp9oVBjyHk Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:49:40 -0000 Hi Maria, Question inline .. On 7/11/14, 9:37 AM, "NAPIERALA, MARIA H" wrote: >> The architecture permits (and I would say even encourages) local load >> balancing between an SFF and the actual service functions to which it is >> delivering packets. > >Local (i.e., to locally attached SFIs) load balancing is of very limited >value. Mostly because, for resiliency, one would want to spread SFIs >across different SFFs. > >>=20 >> The architecture prohibits service functions from adjusting the service >> delivery directly. > >Yes. > >> And it prohibits an SFF from over-riding the decision of another SFF >> about how to do local load balancing to its local service functions. > >OK. > >> That leaves the possibility of having one SFF have some flexibility >> about which next SFF it delivers packets to. I am trying to see if > >An SFF should have full flexibility to choose next SFF hop. Jim> are you saying that if there are 100 SFF=B9s located somewhere in the network that provide a given SF then the local SFF must have all 100 next-hops to reach said remote SFF=B9s within its forwarding logic so that it may independently choose which SF it will use for the next required service of a given flow? > >> there is a way to thread our way through the combination of constraints >> and still add some of the flexibility you suggest. >> We need to allow for a level of meaningful central decision. >> We need to allow for SFF which are not full stateful load balancers >> relative to other SFF.=09 > >As Med pointed out it is implementation decision. > >> But you would like to allow the flexibility to include those. >> And we want an architecture that actually says something. >>=20 >> I can not currently see how to write useful words that meet those >> constraints. >> But I will think about it. If we can allow for this flexibility without >> mandating every SFF to have such capability, then it seems worth >>allowing. >>=20 >> Yours, >> Joel >>=20 >> On 7/11/14, 9:09 AM, NAPIERALA, MARIA H wrote: >> >> So let me say again: the curent archtiecture proposal meets the >> >> requirement you state. It allows for, but does not require central >>laod >> >> balancing. It allows for, but does not require, local load >>balancing of >> >> various kinds at or with the SFF. >> > >> > We have discussed it yesterday that the language in the current >> architecture proposal precludes local load balancing. >> > And that re-classification is not "it". >> > >> > Maria >> > >> >> >> >> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: >> >>> Joel, >> >>> >> >>> The architecture has to make NO assumptions on the actual >> >> configuration/behavior of SFFs (whether none, some, or all of them >>are >> >> stateful, flow-aware co-located with LBs/etc.). This is deployment- >> specific. >> >>> >> >>> Cheers, >> >>> Med >> >>> >> >>>> -----Message d'origine----- >> >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. >>Halpern >> >>>> Envoy=E9 : vendredi 11 juillet 2014 14:08 >> >>>> =C0 : Ron Parker; sfc@ietf.org >> >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >>>> >> >>>> And it was pointed out to me that I made a two letter major typo. >> >>>> >> >>>> I was trying to say that I felt that such a requirement on all SFF >>would >> >>>> be an UNacceptable imposition. >> >>>> >> >>>> Yours, >> >>>> Joel >> >>>> >> >>>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: >> >>>>> Ron, thinking about this, I realized another major problem with >>the >> >> your >> >>>>> proposal as I understand it. (And I readily admit I may not >> understand >> >>>>> it.) >> >>>>> >> >>>>> The proposal has each SFF serve as the load balancer for the next >> >>>>> service function that follows it (not the one it delivers to), in >>every >> >>>>> service chain that goes through it. >> >>>>> >> >>>>> Since it has to be able to work with all services, that means that >> every >> >>>>> SFF would have to be a full, flow sensitive and stateful load >>balancer. >> >>>>> I ahve no problem if some SFF are flow sensitive, and / or >>stateful. >> But >> >>>>> having the architecture require that every SFF be a full, flow >> >>>>> sensitive, stateful, load balancer seems to me to be an acceptable >> >>>>> imposition. >> >>>>> >> >>>>> Yours, >> >>>>> Joel >> >>>>> >> >>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >>>>>> Part of my personal view is that I am trying to make this work >> sensibly >> >>>>>> in a more orchestrated environment. I expect that the service >> >>>>>> functions, and over time probably the SFF capabilities, will be >> >>>>>> orchestrated and installed. I expect the service chains to be >>driven >> by >> >>>>>> BSS tools that define offerings to clients, and enable >>self-selection >> >>>>>> from these. I expect service paths to be heavily policy drive. >> >>>>>> >> >>>>>> I can see how to make all of that work in an archtiecture driven >>by >> >>>>>> initial classification to described service paths. It is harder >>to see >> >>>>>> how to make it work (but it can be done) when we allow more >> >> dynamicity >> >>>>>> in the network behavior. >> >>>>>> >> >>>>>> Having said that, most of that perspective I described is >>outside of >> the >> >>>>>> scope of the working group. it is not something we are tasked to >> >>>>>> agree on. >> >>>>>> So I do not claim that vision means we have to do it a certain >>way. >> it >> >>>>>> is just the perspective that drives my preferences. >> >>>>>> >> >>>>>> Yours, >> >>>>>> Joel >> >>>>>> >> >>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >>>>>>>> For me, the amount of information about service instances that >> >> needs >> >>>> to >> >>>>>>>> be widely distributed and maintained, potentially even across >> data >> >>>>>>>> centers within an administrative scope, is large enough and >> >> complex >> >>>>>>>> enough that trying to get that into each SFF seems like a >>difficult >> >>>>>>>> architecture to realize. >> >>>>>>> >> >>>>>>> I'm curious as to why that is more complicated than dynamic >> routing, >> >>>>>>> hyper-scale data center orchestration, or DNS, all of which are >> bigger >> >>>>>>> problems that have been profitably and stably implemented? >> >>>>>>> >> >>>>>>> It also seems that if it really is more complicated, that is a >>good >> >>>>>>> sign that it is too complicated. >> >>>>>>> >> >>>>>>> ________________________________________ >> >>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] >> >>>>>>> Sent: Thursday, July 10, 2014 9:45 PM >> >>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian >> Smith; >> >>>>>>> sfc@ietf.org >> >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >>>>>>> >> >>>>>>> This is an architectural issue. And one that I would prefer we >> >>>> actually >> >>>>>>> decide, rather than trying to allow all possible >>implementations. >> >>>>>>> Because it does have a major effect on the control requirements >> and >> >> the >> >>>>>>> functionality of SFFs. >> >>>>>>> >> >>>>>>> For me, the amount of information about service instances that >> >> needs to >> >>>>>>> be widely distributed and maintained, potentially even across >>data >> >>>>>>> centers within an administrative scope, is large enough and >> complex >> >>>>>>> enough that trying to get that into each SFF seems like a >>difficult >> >>>>>>> architecture to realize. >> >>>>>>> >> >>>>>>> Yours, >> >>>>>>> Joel >> >>>>>>> >> >>>>>>> But it is a fair question. >> >>>>>>> >> >>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >>>>>>>> This is the crux of my issue. Is the end to end selection of >> >>>>>>>> (top-level) instances performed centrally (perhaps by the >> classifier) >> >>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently the >> >> SFFs)? >> >>>>>>>> Such selection is not equivalent to reclassification. And >>surely, >> >>>>>>>> this is an architectural issue and not relegated to >> >>>>>>>> "implementation". >> >>>>>>>> >> >>>>>>>> My own view is to favor the distributed approach even though a >> >>>>>>>> greater amount of data (chain definitions and perhaps local >> >> selection >> >>>>>>>> policy) is required at those distributed decision points. >>This >> >>>>>>>> approach does not require an end-to-end path id at all. My >> >>>>>>>> rationale for favoring this approach is primarily driven by >> increased >> >>>>>>>> resiliency over the global path id approach. With a global >>path >> id >> >>>>>>>> approach, consider failure of an instance and needing to alter >>the >> >>>>>>>> global path ID table for each and every affected end-to-end >>path. >> >>>>>>>> >> >>>>>>>> Ron >> >>>>>>>> >> >>>>>>>> ________________________________________ From: sfc >> >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >> >>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 >> PM >> >>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: >> Re: >> >>>>>>>> [sfc] Service Chains, Paths, and Load Balancers >> >>>>>>>> >> >>>>>>>> The way the architecture models the case of SF1 needing to >> >> influence >> >>>>>>>> the chain is that one would do reclassification at the exit >>from >> >>>>>>>> SF1. >> >>>>>>>> >> >>>>>>>> Part of the goal is to keep the different functions logically >> >>>>>>>> separate so that solutions can clearly describe how they choose >> to >> >>>>>>>> compose them for "service" delivery. >> >>>>>>>> >> >>>>>>>> Yours, Joel >> >>>>>>>> >> >>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> >>>>>>>>> I don't see anything in the arch draft that suggests any sort >>of >> >>>>>>>>> limit. However, it does seem to indicate that the entire path >>(all >> >>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this >>means >> >>>>>>>>> either at the classifier or maybe the classifier chooses a SF >>Chain >> >>>>>>>>> and the NF or at the latest the first SFF. In any case, the >> >>>>>>>>> language does seem to prohibit a more dynamic SFP where >> SFI(n) >> >> is >> >>>>>>>>> determined at the SFI(n-1) hop. According to the draft, this >> >>>>>>>>> behavior would be considered "branching" to a new SFP as >> >> opposed to >> >>>>>>>>> choosing and then forwarding to the selected instance of the >> >>>>>>>>> next-hop of the current SFC. >> >>>>>>>>> >> >>>>>>>>> draft-merged-sfc-architecture-00: >> >>>>>>>>>> When an SFC is instantiated into the network it is necessary >>to >> >>>>>>>>>> select the specific instances of SFs that will be used, and >>to >> >>>>>>>>>> create the service topology for that SFC using SF's network >> >>>>>>>>>> locator. Thus, instantiation of the SFC results in the >>creation >> >>>>>>>>>> of a Service Function Path (SFP) and is used for forwarding >> >>>>>>>>>> packets through the SFC. In other words, an SFP is the >> >>>>>>>>>> instantiation of the defined SFC. >> >>>>>>>>>> >> >>>>>>>>>> The SFC architecture supports reclassification (or >>non-initial >> >>>>>>>>>> classification) as well. As packets traverse an SFP, >> >>>>>>>>>> reclassification may occur - typically performed by a >> >>>>>>>>>> classification function co-resident with a service function. >> >>>>>>>>>> Reclassification may result in the selection of a new SFP, an >> >>>>>>>>>> update of the associated metadata, or both. This is >>referred to >> >>>>>>>>>> as "branching". >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>=20 >>--------------------------------------------------------------------- >> >>>> --- >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> *From: *I.Smith@F5.com >> >>>>>>>>> *To: *Joel Halpern Direct,Joel M. >> >>>>>>>>> >> >>>> >> >> >> Halpern,huang@sce.carleton.ca> >> on.ca>,s >> >>>> fc@ietf.org >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> *Sent: *Thursday, July 10, 2014 >> >>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >> >>>>>>>>> >> >>>>>>>>> Actually, I think I am disagreeing. >> >>>>>>>>> >> >>>>>>>>> If the possibility of medium-scale deployments (and that is >>what >> >>>>>>>>> 16 million flows is in my world) of service chains is >>preconceived >> >>>>>>>>> as an absurd idea, then the architecture burdened with that >> >>>>>>>>> preconception. >> >>>>>>>>> >> >>>>>>>>> There has to be some point of aim, some degree of aspiration >>to >> >>>>>>>>> scale that is appropriate for the lifespan of the >>architecture - >> >>>>>>>>> you don't have to know what it is, but by saying that an >> arbitrary >> >>>>>>>>> number is "too far", you're creating - even if it isn't >>intentional >> >>>>>>>>> - a limit that influences decisions that have lasting impacts >> >>>>>>>>> regarding scale-out, failure mitigation, elasticity, address >> >>>>>>>>> space... all kinds of things. That is a problem I'm not >> >>>>>>>>> particularly eager to deal with. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> ________________________________________ >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >> >>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>Halpern; >> >>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >> >>>>>>>>> Chains, Paths, and Load Balancers >> >>>>>>>>> >> >>>>>>>>> Ian, I don't think you disagree with me at all in this >>regard. I am >> >>>>>>>>> not requesting the the architecture or the solution prohibit >> >>>>>>>>> deployments in the specific fashion. I am objecting to Huang's >> >>>>>>>>> reading of my note as saying that such deployments are >> required >> >>>>>>>>> they by the archtiecture. >> >>>>>>>>> >> >>>>>>>>> As I have said repeatedly, I am not trying to prohibit such >> >>>>>>>>> things. Whether they are a good idea or not depends upon >> many >> >>>>>>>>> factors outside of the scope of the WG. I happen to think that >> they >> >>>>>>>>> are usually a bad idea. >> >>>>>>>>> >> >>>>>>>>> But the archtiecture si carefully avoiding attempting to know >> what >> >>>>>>>>> is and is not eployable. >> >>>>>>>>> >> >>>>>>>>> Yours, Joel >> >>>>>>>>> >> >>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >>>>>>>>>> I disagree. >> >>>>>>>>>> >> >>>>>>>>>> We routinely have stateful devices that manage tens of >> millions >> >>>>>>>>>> of >> >>>>>>>>> concurrent flows in both access network and data center >> >>>>>>>>> environments today. You can't seriously believe that in the >> >>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are >> only >> >> going >> >>>>>>>>> to have small numbers of service chains with equally small >> >> numbers >> >>>>>>>>> of active service paths? >> >>>>>>>>>> >> >>>>>>>>>> Your sounds too much like "no one will ever need more than >> >> 64K" >> >>>>>>>>>> for >> >>>>>>>>> comfort. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> ________________________________________ From: sfc >> >>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> >>>>>>>>> [jmh@joelhalpern.com] >> >>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >> huang@sce.carleton.ca; >> >>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and >>Load >> >>>>>>>>>> Balancers >> >>>>>>>>>> >> >>>>>>>>>> No, it will mean that if someone tries to deploy the >>archtieture >> >>>>>>>>>> particularly badly, they will exceed the limits of their >> >>>>>>>>>> devices. The architecture does not require such absurd use of >> >>>>>>>>>> service paths. Since I can not figure out how to write >> >>>>>>>>>> architectural words to prohibit it, the architecture does >>permit >> >>>>>>>>>> such abuse. >> >>>>>>>>>> >> >>>>>>>>>> Please do not read my saying that the archtiecture permits >> >>>>>>>>>> something as saying it is either deisred or required by the >> work. >> >>>>>>>>>> It isn't. >> >>>>>>>>>> >> >>>>>>>>>> Yours, Joel >> >>>>>>>>>> >> >>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >>>>>>>>>>> If you need to support 100 service chains, it will mean >> >>>>>>>>>>> 16,000,000 paths. That is larger than the routing table of a >> >>>>>>>>>>> core router. >> >>>>>>>>>>> >> >>>>>>>>>>> Chang >> >>>>>>>>>>> >> >>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >>>>>>>>>>>> The architecture allows a range of deployments, from 1 >> >>>>>>>>>>>> service path to 160000 service paths. I would hope that >> >>>>>>>>>>>> operators are prepared for the complexities if they choose >> to >> >>>>>>>>>>>> avoid any use of local load balancing and in stead >>provision >> >>>>>>>>>>>> 160,000 service paths. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Yours, Joel >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> >>>>>>>>>>>>> Paul, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> How many path identifiers there will be for a 4 hop >>service >> >>>>>>>>>>>>> chain with 20 instances at each hop? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Maria >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >> >>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >> >>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >> >>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >> >>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >> >>>>>>>>>>>>> Paths, and Load Balancers >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Lucy, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the >> >>>>>>>>>>>>> forwarding. I'd >> >>>>>>>>> make >> >>>>>>>>>>>>> the minor change: the path identifier can be used to >>derive >> >>>>>>>>>>>>> the needed forwarding and associated transport. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply >> >>>>>>>>>>>>> identify the service path (or graph) that packets must >> >>>>>>>>>>>>> traverse. By having a path identifier, the exact >> >>>>>>>>>>>>> indirection that people seem to be asking for on this >> >>>>>>>>>>>>> thread can be simply be implemented. The path identifier >> >>>>>>>>>>>>> provides nothing more than a lookup, that lookup can >> result >> >>>>>>>>>>>>> in a one or more (equal or weighted) transport next >> >>>>>>>>>>>>> hop(s). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Paul >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the >> >>>>>>>>>>>>> service path identifier to drive the forwarding actions. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Lucy >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> >>>>>>>>>>>>> Of*mohamed.boucadair@orange.com >> >>>>>>>>>>>>> >> *Sent:*Thursday, >> >> July >> >>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >>>>>>>>>>>>> ;jmh@joelhalpern.com >> >>>>>>>>>>>>> ;sfc@ietf.org >> >>>>>>>>>>>>> *Subject:*Re: [sfc] Service Chains, >> >>>>>>>>>>>>> Paths, and Load Balancers >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Re-, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> The merged draft calls out explicitly a service path >> >>>>>>>>>>>>> identifier. I object to use that identifier to derive >> >>>>>>>>>>>>> forwarding actions. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of every >> >>>>>>>>> available SFC >> >>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >> >>>>>>>>> required/justified >> >>>>>>>>>>>>> nor possible in various deployment contexts. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> SFC forwarding actions should rely on the piece of >> >>>>>>>>>>>>> information >> >>>>>>>>> that will >> >>>>>>>>>>>>> be present in all deployments: that is the one required to >> >>>>>>>>>>>>> structure a service chain. How that information is used to >> >>>>>>>>>>>>> infer forwarding >> >>>>>>>>> actions >> >>>>>>>>>>>>> is a solution-oriented discussion. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Med >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> >>>>>>>>> de*mikebianc@aol.com >> >>>>>>>>>>>>> *Envoy=E9 :*mercredi 9 juillet >> >>>>>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >> >>>>>>>>>>>>> ;sfc@ietf.org >> >>>>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, >> >>>>>>>>>>>>> Paths, and Load Balancers >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Is anyone still questioning the difference between SF >>Chain >> >>>>>>>>>>>>> and SF >> >>>>>>>>> Path? >> >>>>>>>>>>>>> Other than clarifying the definition so that it's clear to >> >>>>>>>>> those not >> >>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees on >> >>>>>>>>>>>>> these terms. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> To me, the one point that is still unclear is whether it >>is >> >>>>>>>>>>>>> the intent of this draft to ultimately specify what the ID >> >>>>>>>>>>>>> of the SFC Header >> >>>>>>>>> should >> >>>>>>>>>>>>> reference (the chain or the path), or if this draft simply >> >>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to >> >>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain or >> >>>>>>>>>>>>> path and the choice of chain or >> >>>>>>>>> path to >> >>>>>>>>>>>>> be negotiated in the control-plane. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> If the latter (ambiguous), then the draft would have >> >>>>>>>>>>>>> require that both SFP and SFC be supported (or make one >> >>>>>>>>>>>>> required and the other optional) to avoid some vendors >> only >> >>>>>>>>>>>>> supporting SFP and others only supporting SFC. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>=20 >>--------------------------------------------------------------------- >> >>>> --- >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>>> *From:*jmh@joelhalpern.com> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> *To:*sfc@ietf.org> >>>>>>>>>>>>> > *Sent:*Tuesday, July >> >>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >> >>>>>>>>>>>>> Balancers >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I have been trying to figure out how to clearly answer a >> >>>>>>>>>>>>> number of comments that have been made about the >> >> proposed >> >>>>>>>>>>>>> merged archtiecture draft. Assuming we can get working >> >>>>>>>>>>>>> group agreement on the intent, we will work to improve >> the >> >>>>>>>>>>>>> wording so that readers who have not participated in the >> WG >> >>>>>>>>>>>>> discussion will understnd it the way the >> >>>>>>>>> working >> >>>>>>>>>>>>> group intends. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> But what do we intend? I will try to explain my personal >> >>>>>>>>>>>>> view, and see if that helps. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> In this regard, it is important to keep in mind that what >> >>>>>>>>>>>>> we are defining is the data plane architecture. We are not >> >>>>>>>>>>>>> attempting to define the architecture for the entire >> >>>>>>>>>>>>> solution for service chaining. That would encompass >> >>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual >> >>>>>>>>>>>>> machine and image management, and many other aspects. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> As a result there are many things which clearly need to >> >>>>>>>>>>>>> exist in the larger system, but which are dealt with above >> >>>>>>>>>>>>> where we are >> >>>>>>>>> functioning, >> >>>>>>>>>>>>> and are not directly required by the work we are doing. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> In order to get to service chain vs service path, as I >> >>>>>>>>>>>>> understand >> >>>>>>>>> them, >> >>>>>>>>>>>>> I need to first discuss load balancing. There are at least >> >>>>>>>>>>>>> three different ways that load balancing can and will >> >>>>>>>>>>>>> interact with service chaining. There probably are more. >> >>>>>>>>>>>>> The point of the archtiecture is to permit all of these, >> >>>>>>>>>>>>> but not to mandate that any particular kind >> >>>>>>>>> be used >> >>>>>>>>>>>>> in any solution. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 1) Load balancing as a service provided to the end user. >> >>>>>>>>>>>>> This is a service function. It receives user packets, and >> >>>>>>>>>>>>> modifies them (or >> >>>>>>>>> marks >> >>>>>>>>>>>>> them, or ...) so as to choose an end user service instance >> >>>>>>>>>>>>> to receive the users packet. This is an important service >> >>>>>>>>>>>>> function to be able to include in service chaining. It's >> >>>>>>>>>>>>> behavior may affect requirements on how service chaining >> is >> >>>>>>>>>>>>> done. But it has very little impact on the archtiecture. >> >>>>>>>>>>>>> From an architectural pe3rspective it is simply a >> >>>>>>>>> service >> >>>>>>>>>>>>> function which may modify the underlying packet. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 2) There is internal load balancing. That is, one can have >> >>>>>>>>>>>>> what >> >>>>>>>>> appears >> >>>>>>>>>>>>> to the service chaining architecture as a single point of >> >>>>>>>>>>>>> contact >> >>>>>>>>> for a >> >>>>>>>>>>>>> specific service function, but is actually delivered by a >> >>>>>>>>> collection of >> >>>>>>>>>>>>> virtual or physical machines, possibly including one or >> >>>>>>>>>>>>> several load balancers (for example using VRRP-like >> >>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is >> >>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. >>It >> >>>>>>>>>>>>> is likely that it is visible to various control >>mechanisms, >> >>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm >> >>>>>>>>>>>>> instantiation. The architectural impact of permitting this >> >>>>>>>>>>>>> is largely that we need to be careful that our terminology >> >>>>>>>>>>>>> does not lead >> >>>>>>>>> readers to >> >>>>>>>>>>>>> think we are prohibiting it. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 3) There can also be load balancing done by selecting >> >>>>>>>>>>>>> packet paths for the service chaining that direct traffic >> >>>>>>>>>>>>> to different places. We would not want to require that a >> >>>>>>>>>>>>> given service function appear at only one place in the >> >>>>>>>>>>>>> network. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> It is of course the case that these may be combined. I >>tend >> >>>>>>>>>>>>> to >> >>>>>>>>> refer to >> >>>>>>>>>>>>> the collection of entities that appear to service chaining >> >>>>>>>>>>>>> as a single point as a cluster. Not because cluster is a >> >>>>>>>>>>>>> good term. But because I do not have another one. Thus, >> the >> >>>>>>>>>>>>> point of type 3 load balancing >> >>>>>>>>> is to >> >>>>>>>>>>>>> direct different subsets of traffic to different singular >> >>>>>>>>>>>>> or clustered service functions in different places in the >> >>>>>>>>>>>>> network. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Now with that said, what do I mean when I talk about >> >>>>>>>>>>>>> service chain and service path/ Service chain is a >>sequence >> >>>>>>>>>>>>> of logical functions to be applied to a subset of packets. >> >>>>>>>>>>>>> It is equivalent of saying that some subset of traffic is >> >>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall >> >>>>>>>>>>>>> while a different subset is to go directly to the cache >> >>>>>>>>> without >> >>>>>>>>>>>>> visiting any other service functions. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> That is not enough information to direct the packets. A >> >>>>>>>>>>>>> service path is, in some fashion, a sequence of locations >> >>>>>>>>>>>>> in the network. Those locations will be singular or >> >>>>>>>>>>>>> clustered service function delivery locations. They may be >> >>>>>>>>>>>>> addressed by IP address. They may be addressed as ports >> on >> >>>>>>>>>>>>> an SFF. There are many different ways that the locations >> >>>>>>>>>>>>> may be known to the service chaining infrastructure and >> the >> >>>>>>>>>>>>> transport. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> From the point of view of the work of the SFC group, >>we >> >>>>>>>>>>>>>> need to be >> >>>>>>>>>>>>> able to talk about the high level abstraction, the service >> >>>>>>>>>>>>> chain, which drives the forwarding. And we need to talk >> >>>>>>>>>>>>> about the actual data path packets will take in the >> >>>>>>>>>>>>> network. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Several of the comments have said "but the whole path >> may >> >>>>>>>>>>>>> not be known at the front." This architecture deals with >> >>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on >>load >> >>>>>>>>>>>>> balancers above, there can be decisions and behaviors >> which >> >>>>>>>>>>>>> are invisible to the service chaining mechanisms (in much >> >>>>>>>>>>>>> the same way that bridging within a LAN is largely >> >>>>>>>>>>>>> invisible to routing between LANs.) The other provision we >> >>>>>>>>>>>>> make is >> >>>>>>>>> that >> >>>>>>>>>>>>> reclassification can be done in mid-chain when necessary. >> >>>>>>>>>>>>> That will direct packets to a new chain. Based on >> >>>>>>>>>>>>> information available at the re-classification point. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I hope that this helps explain what we are after. If it >> >>>>>>>>>>>>> does, and if the intent is acceptable to the working >>group, >> >>>>>>>>>>>>> we can figure out what additional words are needed to >> >>>>>>>>>>>>> convey this. If the working group disagree with the >>intent, >> >>>>>>>>>>>>> then we will of course adjust to match the working group >> >>>>>>>>>>>>> agreements. If this is still unclear, I am not sure what >>to >> >>>>>>>>>>>>> try next. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Yours, Joel >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> _______________________________________________ sfc >> >> mailing >> >>>>>>>>>>>>> list sfc@ietf.org >> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> _______________________________________________ sfc >> >> mailing >> >>>>>>>>>>>>> list sfc@ietf.org >> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> _______________________________________________ sfc >> >> mailing >> >>>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ sfc >> >> mailing >> >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ sfc >> >> mailing list >> >>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc >> >> mailing list >> >>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>> >> >>>>>>>> _______________________________________________ sfc >> mailing >> >> list >> >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>> >> >>>>>>>> _______________________________________________ sfc >> mailing >> >> list >> >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> sfc mailing list >> >>>>>> sfc@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> sfc mailing list >> >>>>> sfc@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> sfc mailing list >> >>>> sfc@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> >> sfc mailing 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 Jul 11 06:54: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 8A2A21B2AE2 for ; Fri, 11 Jul 2014 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 Jdnxo7WmkSVa for ; Fri, 11 Jul 2014 06:54:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6A61B28AF for ; Fri, 11 Jul 2014 06:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37926; q=dns/txt; s=iport; t=1405086877; x=1406296477; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NeGJ1fBNdrSDzRWgMVi/lZ/nwtJ+caBEbeZmhHLqDYQ=; b=V9ydsRxr/R7NppboxxetQzansGQdG642rLI/6d83LfWitrHbj9xbU1yo xSCn4hcl2oVU+hJpLvMQ1ell2ajfWD2YIan41RTIm/89nRVWR1FsaLSEd CxUtdBwSxvFIoiwjIx3UIS3EBG1MXOUoCiXzgSN38OGgdQOguWS40wvk/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFjrv1OtJV2c/2dsb2JhbABPCoMOUlqCcawGkXgKh0IBGXIWdYQDAQEBBAEBARcJETEJAhUEAgEIEQEDAQEBAgIjAwICAiULFAECBggCBAESG4gTAxENrTCZARMEgSyLcYFQBSwQIgICAoJxgUwFliJJhBqLaIg0g0SBb0E X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="339302171" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2014 13:54:35 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6BDs7B0019712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 13:54:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 08:54:06 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AA== Date: Fri, 11 Jul 2014 13:54:06 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: <1F6DDF6E29B4D84A84DD1D7BB6882956@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eiSoVEgdjL1ymOTVYZGeZC8wq-s Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:54:13 -0000 VGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVt cyB0byBtZSB0aGF0IGlmDQp5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0 byB3aGljaCByZW1vdGUgU0ZGIGl0IHdpbGwgdXNlIGZvcg0KYSBnaXZlbiBmbG93IHRvIHJlYWNo IHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UgYmV0dGVyIG1ha2UNCnN1cmUg dGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYyB0 byByZWFjaCB0aGUNCm5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3Ug YXJlIGluIGRlZXAgdHJvdWJsZS4NCg0KT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwg TUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPiB3cm90ZToNCg0KPkFic29sdXRlbHkgbm90LiBTZXJ2 aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4gcmVsZXZhbnQgU0ZGcw0KPndo ZW4gdGhleSAiYXJyaXZlIi4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBH dWljaGFyZA0KPj4oamd1aWNoYXIpDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToy NyBBTQ0KPj4gVG86IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+IA0KPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlm IEkgaGF2ZSB1bmRlcnN0b29kIHRoZQ0KPj5wcm9wb3NhbA0KPj4gY29ycmVjdGx5IGFzIGl0IHdv dWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlIFNGIHdpdGhpbg0KPj50 aGUNCj4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMg bm8gd2F5IHRvIGtub3cgYQ0KPj5wcmlvcmkNCj4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3 aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4gcG9pbnQgaW4gdGltZS4NCj4+IA0KPj4g T24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4u Y29tPiB3cm90ZToNCj4+IA0KPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXpl ZCBhbm90aGVyIG1ham9yIHByb2JsZW0gd2l0aCB0aGUNCj4+eW91cg0KPj4gPnByb3Bvc2FsIGFz IEkgdW5kZXJzdGFuZCBpdC4gIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdCB1bmRlcnN0 YW5kDQo+PiA+aXQuKQ0KPj4gPg0KPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUg YXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZSBuZXh0DQo+PiA+c2VydmljZSBmdW5jdGlvbiB0 aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzIHRvKSwgaW4gZXZlcnkNCj4+ ID5zZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4gPg0KPj4gPlNpbmNlIGl0 IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnMgdGhh dA0KPj5ldmVyeQ0KPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRp dmUgYW5kIHN0YXRlZnVsIGxvYWQgYmFsYW5jZXIuDQo+PiA+SSBhaHZlIG5vIHByb2JsZW0gaWYg c29tZSBTRkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvciBzdGF0ZWZ1bC4NCj4+ID5CdXQg aGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGws IGZsb3cNCj4+ID5zZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRvIG1l IHRvIGJlIGFuIGFjY2VwdGFibGUNCj4+ID5pbXBvc2l0aW9uLg0KPj4gPg0KPj4gPllvdXJzLA0K Pj4gPkpvZWwNCj4+ID4NCj4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJu IHdyb3RlOg0KPj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlp bmcgdG8gbWFrZSB0aGlzIHdvcmsNCj4+c2Vuc2libHkNCj4+ID4+IGluIGEgbW9yZSBvcmNoZXN0 cmF0ZWQgZW52aXJvbm1lbnQuICBJIGV4cGVjdCB0aGF0IHRoZSBzZXJ2aWNlDQo+PiA+PiBmdW5j dGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsIHdpbGwg YmUNCj4+ID4+IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVkLiAgSSBleHBlY3QgdGhlIHNlcnZp Y2UgY2hhaW5zIHRvIGJlDQo+PmRyaXZlbiBieQ0KPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5l IG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlIHNlbGYtc2VsZWN0aW9uDQo+PiA+PiBm cm9tIHRoZXNlLiAgSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeSBk cml2ZS4NCj4+ID4+DQo+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29y ayBpbiBhbiBhcmNodGllY3R1cmUgZHJpdmVuIGJ5DQo+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0 aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiAgSXQgaXMgaGFyZGVyIHRvDQo+PnNlZQ0K Pj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFs bG93IG1vcmUNCj4+IGR5bmFtaWNpdHkNCj4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0K Pj4gPj4NCj4+ID4+IEhhdmluZyBzYWlkIHRoYXQsIG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJ IGRlc2NyaWJlZCBpcyBvdXRzaWRlIG9mDQo+PnRoZQ0KPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtp bmcgZ3JvdXAuICBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZSB0YXNrZWQgdG8NCj4+YWdyZWUN Cj4+ID4+b24uDQo+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBo YXZlIHRvIGRvIGl0IGEgY2VydGFpbiB3YXkuDQo+Pml0DQo+PiA+PiBpcyBqdXN0IHRoZSBwZXJz cGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+ID4+DQo+PiA+PiBZb3VycywN Cj4+ID4+IEpvZWwNCj4+ID4+DQo+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGgg d3JvdGU6DQo+PiA+Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBz ZXJ2aWNlIGluc3RhbmNlcyB0aGF0DQo+Pm5lZWRzDQo+PiA+Pj4+dG8NCj4+ID4+Pj4gYmUgd2lk ZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBk YXRhDQo+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBs YXJnZSBlbm91Z2ggYW5kIGNvbXBsZXgNCj4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdl dCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhIGRpZmZpY3VsdA0KPj4gPj4+PiBhcmNo aXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+Pg0KPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdo eSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBkeW5hbWljIHJvdXRpbmcsDQo+PiA+Pj4g aHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Ygd2hp Y2ggYXJlDQo+PmJpZ2dlcg0KPj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFi bHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8NCj4+ID4+Pg0KPj4gPj4+IEl0IGFsc28gc2VlbXMg dGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdCBpcyBhIGdvb2QNCj4+ ID4+PiBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0KPj4gPj4+DQo+PiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4+IEZyb206IEpvZWwg TS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+ID4+PiBTZW50OiBUaHVyc2RheSwg SnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVy biBEaXJlY3Q7IG1pa2ViaWFuY0Bhb2wuY29tOyBJYW4gU21pdGg7DQo+PiA+Pj4gc2ZjQGlldGYu b3JnDQo+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+PiA+Pj4NCj4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwg aXNzdWUuICBBbmQgb25lIHRoYXQgSSB3b3VsZCBwcmVmZXIgd2UNCj4+ID4+PmFjdHVhbGx5DQo+ PiA+Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlIGlt cGxlbWVudGF0aW9ucy4NCj4+ID4+PiBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVj dCBvbiB0aGUgY29udHJvbCByZXF1aXJlbWVudHMgYW5kDQo+PiB0aGUNCj4+ID4+PiBmdW5jdGlv bmFsaXR5IG9mIFNGRnMuDQo+PiA+Pj4NCj4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5m b3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMgdGhhdCBuZWVkcw0KPj4gdG8NCj4+ID4+ PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4g YWNyb3NzIGRhdGENCj4+ID4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29w ZSwgaXMgbGFyZ2UgZW5vdWdoIGFuZCBjb21wbGV4DQo+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5n IHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhIGRpZmZpY3VsdA0KPj4gPj4+ IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4+DQo+PiA+Pj4gWW91cnMsDQo+PiA+Pj4g Sm9lbA0KPj4gPj4+DQo+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ID4+Pg0K Pj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+PiA+Pj4+IFRo aXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBlbmQgc2VsZWN0aW9u IG9mDQo+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChw ZXJoYXBzIGJ5IHRoZQ0KPj5jbGFzc2lmaWVyKQ0KPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJo YXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkgdGhlDQo+PlNGRnMpPw0KPj4g Pj4+PiBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9u LiAgIEFuZCBzdXJlbHksDQo+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBh bmQgbm90IHJlbGVnYXRlZCB0bw0KPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPj4gPj4+Pg0K Pj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2gg ZXZlbiB0aG91Z2ggYQ0KPj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZp bml0aW9ucyBhbmQgcGVyaGFwcyBsb2NhbA0KPj5zZWxlY3Rpb24NCj4+ID4+Pj4gcG9saWN5KSBp cyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMuICAgVGhpcw0K Pj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBh dCBhbGwuICAgIE15DQo+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2Fj aCBpcyBwcmltYXJpbHkgZHJpdmVuIGJ5DQo+PmluY3JlYXNlZA0KPj4gPj4+PiByZXNpbGllbmN5 IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiAgIFdpdGggYSBnbG9iYWwgcGF0aA0K Pj5pZA0KPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBh bmQgbmVlZGluZyB0byBhbHRlciB0aGUNCj4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9y IGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkIGVuZC10by1lbmQgcGF0aC4NCj4+ID4+Pj4NCj4+ID4+ Pj4gUm9uDQo+PiA+Pj4+DQo+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gRnJvbTogc2ZjDQo+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVo YWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tXSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA2OjE1IFBNDQo+PiA+Pj4+IFRv OiBtaWtlYmlhbmNAYW9sLmNvbTsgSS5TbWl0aEBGNS5jb207IHNmY0BpZXRmLm9yZyBTdWJqZWN0 OiBSZToNCj4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+ID4+Pj4NCj4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0 aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0bw0KPj5pbmZsdWVuY2UNCj4+ID4+Pj4gdGhlIGNoYWlu IGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4aXQgZnJvbQ0K Pj4gPj4+PiBTRjEuDQo+PiA+Pj4+DQo+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2Vl cCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkNCj4+ID4+Pj4gc2VwYXJhdGUgc28g dGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkgY2hvb3NlIHRvDQo+ PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4gPj4+Pg0KPj4g Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4+Pg0KPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBt aWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGlu IHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55IHNvcnQgb2YNCj4+ID4+Pj4+IGxpbWl0 LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlIHBhdGgg KGFsbA0KPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24u ICBJIGJlbGlldmUgdGhpcyBtZWFucw0KPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVy IG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyIGNob29zZXMgYSBTRg0KPj5DaGFpbg0KPj4gPj4+Pj4g YW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuICBJbiBhbnkgY2FzZSwg dGhlDQo+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFt aWMgU0ZQIHdoZXJlIFNGSShuKSBpcw0KPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4t MSkgaG9wLiAgQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwgdGhpcw0KPj4gPj4+Pj4gYmVoYXZpb3Ig d291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMgb3Bwb3NlZA0K Pj4gdG8NCj4+ID4+Pj4+IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVj dGVkIGluc3RhbmNlIG9mIHRoZQ0KPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZD Lg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0K Pj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0 IGlzIG5lY2Vzc2FyeSB0bw0KPj4gPj4+Pj4+IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2Vz IG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvDQo+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBz ZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcmsNCj4+ID4+Pj4+ PiBsb2NhdG9yLiAgVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhl IGNyZWF0aW9uDQo+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5k IGlzIHVzZWQgZm9yIGZvcndhcmRpbmcNCj4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNG Qy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+ID4+Pj4+PiBpbnN0YW50aWF0aW9u IG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0 ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yIG5vbi1pbml0aWFsDQo+PiA+Pj4+ Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuICBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwN Cj4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3Jt ZWQgYnkgYQ0KPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdp dGggYSBzZXJ2aWNlIGZ1bmN0aW9uLg0KPj4gPj4+Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJl c3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3IFNGUCwgYW4NCj4+ID4+Pj4+PiB1cGRhdGUg b2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguICBUaGlzIGlzIHJlZmVycmVkIHRv DQo+PiA+Pj4+Pj4gYXMgImJyYW5jaGluZyIuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+ DQo+PiA+Pj4+Pg0KPj4gDQo+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4t LQ0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBG NS5jb208SS5TbWl0aEBGNS5jb20+DQo+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4gRGlyZWN0 PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPixKb2VsIE0uDQo+PiA+Pj4+Pg0KPj4gPj4+Pj5I YWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0Bz Y2UuDQo+PiBjYXJsZXRvbi4NCj4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc+ DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwg SnVseSAxMCwgMjAxNA0KPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBBY3R1YWxs eSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IElmIHRoZSBw b3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZCB0aGF0IGlzIHdoYXQN Cj4+ID4+Pj4+IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hh aW5zIGlzIHByZWNvbmNlaXZlZA0KPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhl IGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoIHRoYXQNCj4+ID4+Pj4+IHByZWNvbmNlcHRpb24u DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBz b21lIGRlZ3JlZSBvZiBhc3BpcmF0aW9uIHRvDQo+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJv cHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlIGFyY2hpdGVjdHVyZSAtDQo+PiA+Pj4+PiB5 b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbiBh cmJpdHJhcnkNCj4+ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAt IGV2ZW4gaWYgaXQgaXNuJ3QNCj4+aW50ZW50aW9uYWwNCj4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0 IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nIGltcGFjdHMNCj4+ID4+Pj4+ IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwgYWRk cmVzcw0KPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHBy b2JsZW0gSSdtIG5vdA0KPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4N Cj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4u Y29tXSBTZW50Og0KPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzog SWFuIFNtaXRoOyBKb2VsIE0uIEhhbHBlcm47DQo+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24u Y2E7IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZQ0KPj4gPj4+Pj4gQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gSWFuLCBJ IGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzIHJlZ2FyZC4g SQ0KPj5hbQ0KPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3Ig dGhlIHNvbHV0aW9uIHByb2hpYml0DQo+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lm aWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG8gSHVhbmcncw0KPj4gPj4+Pj4gcmVhZGluZyBv ZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlIHJlcXVpcmVkDQo+ PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gQXMg SSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0IHN1Y2gN Cj4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVw ZW5kcyB1cG9uIG1hbnkNCj4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2Yg dGhlIFdHLiBJIGhhcHBlbiB0byB0aGluayB0aGF0DQo+PnRoZXkNCj4+ID4+Pj4+IGFyZSB1c3Vh bGx5IGEgYmFkIGlkZWEuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUg c2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG8ga25vdyB3aGF0DQo+PiA+Pj4+PiBp cyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBZb3VycywgSm9lbA0K Pj4gPj4+Pj4NCj4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZToN Cj4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5 IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mIG1pbGxpb25zDQo+PiA+ Pj4+Pj4gb2YNCj4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29y ayBhbmQgZGF0YSBjZW50ZXINCj4+ID4+Pj4+IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0 IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4gdGhlDQo+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmls aXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91IGFyZSBvbmx5DQo+PiBnb2luZw0K Pj4gPj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1 YWxseSBzbWFsbCBudW1iZXJzDQo+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ ID4+Pj4+Pg0KPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxs IGV2ZXIgbmVlZCBtb3JlIHRoYW4gNjRLIg0KPj4gPj4+Pj4+IGZvcg0KPj4gPj4+Pj4gY29tZm9y dC4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+ID4+Pj4+IFtqbWhAam9lbGhh bHBlcm4uY29tXQ0KPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYg UE0gVG86IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsNCj4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+ID4+Pj4+ PiBCYWxhbmNlcnMNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBp ZiBzb21lb25lIHRyaWVzIHRvIGRlcGxveSB0aGUgYXJjaHRpZXR1cmUNCj4+ID4+Pj4+PiBwYXJ0 aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZiB0aGVpcg0KPj4g Pj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFi c3VyZCB1c2Ugb2YNCj4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmln dXJlIG91dCBob3cgdG8gd3JpdGUNCj4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHBy b2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlIGRvZXMgcGVybWl0DQo+PiA+Pj4+Pj4gc3VjaCBh YnVzZS4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcg dGhhdCB0aGUgYXJjaHRpZWN0dXJlIHBlcm1pdHMNCj4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5 aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5IHRoZSB3b3JrLg0KPj4gPj4+ Pj4+IEl0IGlzbid0Lg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+Pj4+ Pg0KPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6 DQo+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBp dCB3aWxsIG1lYW4NCj4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIg dGhhbiB0aGUgcm91dGluZyB0YWJsZSBvZiBhDQo+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4g Pj4+Pj4+Pg0KPj4gPj4+Pj4+PiBDaGFuZw0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBPbiAwNy8x MC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+Pj4+Pj4+PiBUaGUg YXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCBmcm9tIDENCj4+ID4+ Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3Bl IHRoYXQNCj4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4 aXRpZXMgaWYgdGhleSBjaG9vc2UgdG8NCj4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9j YWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkIHByb3Zpc2lvbg0KPj4gPj4+Pj4+Pj4gMTYw LDAwMCBzZXJ2aWNlIHBhdGhzLg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2Vs DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxB LCBNQVJJQSBIIHdyb3RlOg0KPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+ Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBo b3Agc2VydmljZQ0KPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2gg aG9wPw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4+ID4+Pj4+Pj4+Pg0KPj4g Pj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJl aGFsZiBPZg0KPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCAzOjAzDQo+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpD YzoqIGptaEBqb2VsaGFscGVybi5jb207DQo+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29t ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPj4gPj4+Pj4+Pj4+IFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBh IHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ID4+ Pj4+IG1ha2UNCj4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlm aWVyIGNhbiBiZSB1c2VkIHRvIGRlcml2ZQ0KPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2Fy ZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+ PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8gc2ltcGx5 DQo+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQg cGFja2V0cyBtdXN0DQo+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRl bnRpZmllciwgdGhlIGV4YWN0DQo+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUg c2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uIHRoaXMNCj4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJl IHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGggaWRlbnRpZmllcg0KPj4gPj4+Pj4+Pj4+ IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4gcmVz dWx0DQo+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRy YW5zcG9ydCBuZXh0DQo+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+Pj4gUGF1bA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBh dCAxMTowNCBBTSwgTHVjeSB5b25nDQo+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29t IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4g Pj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEFncmVl LiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUNCj4+ID4+ Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBh Y3Rpb25zLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPj4gPj4+Pj4+Pj4+DQo+ PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiBC ZWhhbGYNCj4+ID4+Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA+ Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiAqU2VudDoqVGh1 cnNkYXksDQo+PiBKdWx5DQo+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86Km1pa2Vi aWFuY0Bhb2wuY29tDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1o QGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT47c2ZjQGlldGYub3JnDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJq ZWN0OipSZTogW3NmY10gU2VydmljZSBDaGFpbnMsDQo+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vycw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gPj4+Pj4+ Pj4+DQo+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBh IHNlcnZpY2UgcGF0aA0KPj4gPj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0 aGF0IGlkZW50aWZpZXIgdG8gZGVyaXZlDQo+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25z Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBo YXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeQ0KPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0K Pj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFp biBpcyBub3QNCj4+ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmllZA0KPj4gPj4+Pj4+Pj4+IG5vciBw b3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ ID4+Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVj ZSBvZg0KPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+Pj4+PiB0aGF0IHdpbGwNCj4+ID4+ Pj4+Pj4+PiBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lIHJl cXVpcmVkIHRvDQo+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRo YXQgaW5mb3JtYXRpb24gaXMgdXNlZCB0bw0KPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcN Cj4+ID4+Pj4+IGFjdGlvbnMNCj4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRp c2N1c3Npb24uDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+PiA+Pj4+Pj4+ Pj4NCj4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+ICpEZSA6KnNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+PiA+Pj4+PiBkZSpt aWtlYmlhbmNAYW9sLmNvbQ0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpFbnZvecOpIDoqbWVyY3JlZGkgOSBqdWlsbGV0DQo+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAq w4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPj4gPj4+Pj4+Pj4+IFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IElzIGFueW9u ZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIENoYWluDQo+PiA+ Pj4+Pj4+Pj4gYW5kIFNGDQo+PiA+Pj4+PiBQYXRoPw0KPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4g Y2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8NCj4+ID4+Pj4+ IHRob3NlIG5vdA0KPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVt cyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbg0KPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4g Pj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGls bCB1bmNsZWFyIGlzIHdoZXRoZXIgaXQgaXMNCj4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRo aXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEDQo+PiA+Pj4+Pj4+Pj4g b2YgdGhlIFNGQyBIZWFkZXINCj4+ID4+Pj4+IHNob3VsZA0KPj4gPj4+Pj4+Pj4+IHJlZmVyZW5j ZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkNCj4+ID4+ Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBk cmFmdHMgdG8NCj4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJk aW5nIGJhc2VkIG9uIGNoYWluIG9yDQo+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBv ZiBjaGFpbiBvcg0KPj4gPj4+Pj4gcGF0aCB0bw0KPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQg aW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJZiB0aGUg bGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlDQo+PiA+Pj4+Pj4+ Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9u ZQ0KPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lk IHNvbWUgdmVuZG9ycyBvbmx5DQo+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVy cyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+ Pj4+DQo+PiANCj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pi0tDQo+PiA+Pj4+Pi0tDQo+PiA+ Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gKkZyb206 KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4+Pj4+Pj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4gPj4+ Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0KPj4gPj4+Pj4+Pj4+IDxtYWls dG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4gKlNlbnQ6KlR1ZXNkYXksIEp1bHkNCj4+ ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkDQo+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+ Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3 ZXIgYQ0KPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRl IGFib3V0IHRoZSBwcm9wb3NlZA0KPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJh ZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZw0KPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVl bWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUNCj4+ID4+Pj4+ Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGlu IHRoZSBXRw0KPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdh eSB0aGUNCj4+ID4+Pj4+IHdvcmtpbmcNCj4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPj4g Pj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5 IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwNCj4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRo YXQgaGVscHMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQg aXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0IHdoYXQNCj4+ID4+Pj4+Pj4+PiB3ZSBh cmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90DQo+ PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhl IGVudGlyZQ0KPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0 IHdvdWxkIGVuY29tcGFzcw0KPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBh bmQgcG9saWN5IGZ1bmN0aW9ucywgdmlydHVhbA0KPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGlt YWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJs eSBuZWVkIHRvDQo+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3 aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZQ0KPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4g Pj4+Pj4gZnVuY3Rpb25pbmcsDQo+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVx dWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlIGRvaW5nLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+ Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJ DQo+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPj4gPj4+Pj4gdGhlbSwNCj4+ID4+Pj4+Pj4+PiBJ IG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0 DQo+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBj YW4gYW5kIHdpbGwNCj4+ID4+Pj4+Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcu IFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLg0KPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUg YXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YgdGhlc2UsDQo+PiA+Pj4+Pj4+Pj4gYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPj4gPj4+Pj4gYmUgdXNl ZA0KPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+ Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVz ZXIuDQo+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVz IHVzZXIgcGFja2V0cywgYW5kDQo+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4+ID4+ Pj4+IG1hcmtzDQo+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4g ZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZQ0KPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVz ZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZQ0KPj4gPj4+Pj4+Pj4+IGZ1 bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzDQo+ PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZp Y2UgY2hhaW5pbmcgaXMNCj4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxl IGltcGFjdCBvbiB0aGUgYXJjaHRpZWN0dXJlLg0KPj4gPj4+Pj4+Pj4+ICBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhDQo+PiA+Pj4+PiBzZXJ2aWNlDQo+ PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNr ZXQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2Fk IGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZlDQo+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4g Pj4+Pj4gYXBwZWFycw0KPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hp dGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZg0KPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+ Pj4+IGZvciBhDQo+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlz IGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhDQo+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+Pj4+ Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9u ZSBvcg0KPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVz aW5nIFZSUlAtbGlrZQ0KPj4gPj4+Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRk cmVzcy4pIG1vc3RseSwgdGhpcyBpcw0KPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIG1lY2hhbmlzbXMuIEl0DQo+PiA+Pj4+Pj4+Pj4gaXMg bGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wgbWVjaGFuaXNtcywN Cj4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2Nh bGUtb3V0LCBhbmQgdm0NCj4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0 dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzDQo+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0 aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neQ0KPj4gPj4+Pj4+ Pj4+IGRvZXMgbm90IGxlYWQNCj4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+ID4+Pj4+Pj4+PiB0aGlu ayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAzKSBU aGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZw0KPj4gPj4+ Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3Qg dHJhZmZpYw0KPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3 YW50IHRvIHJlcXVpcmUgdGhhdCBhDQo+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlv biBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gdGhlDQo+PiA+Pj4+Pj4+Pj4gbmV0d29yay4N Cj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0 IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kDQo+PiA+Pj4+Pj4+Pj4gdG8NCj4+ID4+Pj4+ IHJlZmVyIHRvDQo+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBh cHBlYXIgdG8gc2VydmljZSBjaGFpbmluZw0KPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50 IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhDQo+PiA+Pj4+Pj4+Pj4gZ29v ZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLCB0aGUN Cj4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+ID4+Pj4+IGlz IHRvDQo+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8g ZGlmZmVyZW50IHNpbmd1bGFyDQo+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVu Y3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlDQo+PiA+Pj4+Pj4+Pj4gbmV0d29yay4N Cj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJ IG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBz ZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBzZXF1ZW5jZQ0KPj4gPj4+Pj4+Pj4+IG9m IGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4N Cj4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0 IG9mIHRyYWZmaWMgaXMNCj4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVu dCBpbnNwZWN0aW9uLCBhbmQgZmlyZXdhbGwNCj4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVu dCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlDQo+PiA+Pj4+PiB3aXRob3V0 DQo+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4g Pj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRv IGRpcmVjdCB0aGUgcGFja2V0cy4gQQ0KPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4g c29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mIGxvY2F0aW9ucw0KPj4gPj4+Pj4+Pj4+IGluIHRo ZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcg0KPj4gPj4+Pj4+ Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleSBt YXkgYmUNCj4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUg YWRkcmVzc2VkIGFzIHBvcnRzIG9uDQo+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFu eSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMNCj4+ID4+Pj4+Pj4+PiBtYXkgYmUg a25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZQ0KPj4g Pj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+PiAgRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZQ0KPj4gPj4+ Pj4+Pj4+PiBuZWVkIHRvIGJlDQo+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBo aWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZQ0KPj4gPj4+Pj4+Pj4+IGNoYWluLCB3 aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvIHRhbGsNCj4+ID4+Pj4+ Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUN Cj4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gU2V2ZXJh bCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGggbWF5DQo+PiA+ Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRl YWxzIHdpdGgNCj4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMg bm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZA0KPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwg dGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzIHdoaWNoDQo+PiA+Pj4+Pj4+Pj4g YXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbiBtdWNo DQo+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlz IGxhcmdlbHkNCj4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMu KSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlDQo+PiA+Pj4+Pj4+Pj4gbWFrZSBpcw0KPj4gPj4+Pj4g dGhhdA0KPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNo YWluIHdoZW4gbmVjZXNzYXJ5Lg0KPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0 cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24NCj4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFp bGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+ Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVy LiBJZiBpdA0KPj4gPj4+Pj4+Pj4+IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFi bGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsDQo+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQg d2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8NCj4+ID4+Pj4+Pj4+PiBjb252ZXkg dGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUgaW50ZW50LA0KPj4g Pj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3Jr aW5nIGdyb3VwDQo+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNs ZWFyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdG8NCj4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMN Cj4+IG1haWxpbmcNCj4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiBtYWlsaW5nDQo+PiA+Pj4+Pj4+Pj4g bGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4+Pj4+Pg0KPj4g Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+Pj4+ Pg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gc2ZjIG1haWxpbmcNCj4+IGxpc3QNCj4+ID4+Pj4+PiBzZmNAaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4+Pg0K Pj4gPj4+Pj4NCj4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHNmYyBtYWlsaW5nDQo+PiBsaXN0DQo+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4NCj4+ID4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjIG1haWxp bmcNCj4+IGxpc3QNCj4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+DQo+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYyBtYWlsaW5nDQo+PiBsaXN0DQo+PiA+Pj4+ IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4gPj4+Pg0KPj4gPj4+DQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+IHNmY0Bp ZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+c2ZjQGlldGYub3JnDQo+PiA+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+IA0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxp c3QNCj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg0K From nobody Fri Jul 11 06:55: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 30D6D1B28E5 for ; Fri, 11 Jul 2014 06:55:51 -0700 (PDT) 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 RGYuDoYxdZ4Y for ; Fri, 11 Jul 2014 06:55:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B991B28AF for ; Fri, 11 Jul 2014 06:55:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3522024066E; Fri, 11 Jul 2014 06:55:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CA0524050B; Fri, 11 Jul 2014 06:55:49 -0700 (PDT) Message-ID: <53BFECE5.8080207@joelhalpern.com> Date: Fri, 11 Jul 2014 09:55:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HJ9wB2oPzL9SiVAV1S_TCb2wyPI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:55:51 -0000 Hmm. Would it meet your goals Maria if all packets that arrived at SFF-X with SFP-Y were (after local SF processing) forwarded to some specific SFF-Z? Where SFF-Z was selected when the first packet with SFP-Y arrived at SFF-X? While that is more easily met, that does not seem likely to produce the scale flexibility you asked for. And if SFF-X may forward packets with SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the capability to ensure that a given flow continues to go to the same next SFF even when SFF-Z3 is added to the mix. Yours, Joel On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: > Absolutely not. Service chains can be instantiated only in relevant SFFs when they "arrive". > ... From nobody Fri Jul 11 06:56: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 BCFD51B2AFB for ; Fri, 11 Jul 2014 06:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 747KFlhN1ZI5 for ; Fri, 11 Jul 2014 06:56:17 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B17B1B2AF0 for ; Fri, 11 Jul 2014 06:56:17 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 10defb35.2abffee4a940.6643249.00-2497.18386306.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:56:17 +0000 (UTC) X-MXL-Hash: 53bfed01491944e1-bfab78801e79fca33aa3342489548fe6cabb9d12 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 3ecefb35.0.6643002.00-2339.18385565.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:55:56 +0000 (UTC) X-MXL-Hash: 53bfecec317b97ea-9472fc0ea0b985d9a1c696e9d8b430dff5344cff Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDtk0c005665; Fri, 11 Jul 2014 09:55:47 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDtaBA005460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:55:42 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:55:24 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:55:24 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAihoAgAAJJ4CAAAULAP//vwFAgABJkwD//715QAAJBfKAAAhVwUA= Date: Fri, 11 Jul 2014 13:55:24 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC9C@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFE6A8.9000903@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC4A@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=kqqwp] X-AnalysisOut: [LEBsc0Ihu-xQw4A:9 a=wPNLvfGTeEIA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=hPjdaMEvmhQA:10 a=tzy2DZLLay8QCEP1:21 a=uFpgwx] X-AnalysisOut: [G57paA2GmF:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iJ1p1Ue5H4raU9n8Co-S12ioIaQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:56:23 -0000 >=20 > >> The architecture permits (and I would say even encourages) local load > >> balancing between an SFF and the actual service functions to which it = is > >> delivering packets. > > > >Local (i.e., to locally attached SFIs) load balancing is of very limited > >value. Mostly because, for resiliency, one would want to spread SFIs > >across different SFFs. > > > >> > >> The architecture prohibits service functions from adjusting the servic= e > >> delivery directly. > > > >Yes. > > > >> And it prohibits an SFF from over-riding the decision of another SFF > >> about how to do local load balancing to its local service functions. > > > >OK. > > > >> That leaves the possibility of having one SFF have some flexibility > >> about which next SFF it delivers packets to. I am trying to see if > > > >An SFF should have full flexibility to choose next SFF hop. >=20 > Jim> are you saying that if there are 100 SFF=B9s located somewhere in th= e > network that provide a given SF then the local SFF must have all 100 > next-hops to reach said remote SFF=B9s within its forwarding logic so tha= t > it may independently choose which SF it will use for the next required > service of a given flow? I assume you mean "may independently choose which *SFI* it will use for the= next required service of a given flow". Then yes. =20 =20 > > > >> there is a way to thread our way through the combination of constraint= s > >> and still add some of the flexibility you suggest. > >> We need to allow for a level of meaningful central decision. > >> We need to allow for SFF which are not full stateful load balancers > >> relative to other SFF. > > > >As Med pointed out it is implementation decision. > > > >> But you would like to allow the flexibility to include those. > >> And we want an architecture that actually says something. > >> > >> I can not currently see how to write useful words that meet those > >> constraints. > >> But I will think about it. If we can allow for this flexibility witho= ut > >> mandating every SFF to have such capability, then it seems worth > >>allowing. > >> > >> Yours, > >> Joel > >> > >> On 7/11/14, 9:09 AM, NAPIERALA, MARIA H wrote: > >> >> So let me say again: the curent archtiecture proposal meets the > >> >> requirement you state. It allows for, but does not require central > >>laod > >> >> balancing. It allows for, but does not require, local load > >>balancing of > >> >> various kinds at or with the SFF. > >> > > >> > We have discussed it yesterday that the language in the current > >> architecture proposal precludes local load balancing. > >> > And that re-classification is not "it". > >> > > >> > Maria > >> > > >> >> > >> >> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: > >> >>> Joel, > >> >>> > >> >>> The architecture has to make NO assumptions on the actual > >> >> configuration/behavior of SFFs (whether none, some, or all of them > >>are > >> >> stateful, flow-aware co-located with LBs/etc.). This is deployment- > >> specific. > >> >>> > >> >>> Cheers, > >> >>> Med > >> >>> > >> >>>> -----Message d'origine----- > >> >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. > >>Halpern > >> >>>> Envoy=E9 : vendredi 11 juillet 2014 14:08 > >> >>>> =C0 : Ron Parker; sfc@ietf.org > >> >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >> >>>> > >> >>>> And it was pointed out to me that I made a two letter major typo. > >> >>>> > >> >>>> I was trying to say that I felt that such a requirement on all SF= F > >>would > >> >>>> be an UNacceptable imposition. > >> >>>> > >> >>>> Yours, > >> >>>> Joel > >> >>>> > >> >>>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: > >> >>>>> Ron, thinking about this, I realized another major problem with > >>the > >> >> your > >> >>>>> proposal as I understand it. (And I readily admit I may not > >> understand > >> >>>>> it.) > >> >>>>> > >> >>>>> The proposal has each SFF serve as the load balancer for the nex= t > >> >>>>> service function that follows it (not the one it delivers to), i= n > >>every > >> >>>>> service chain that goes through it. > >> >>>>> > >> >>>>> Since it has to be able to work with all services, that means th= at > >> every > >> >>>>> SFF would have to be a full, flow sensitive and stateful load > >>balancer. > >> >>>>> I ahve no problem if some SFF are flow sensitive, and / or > >>stateful. > >> But > >> >>>>> having the architecture require that every SFF be a full, flow > >> >>>>> sensitive, stateful, load balancer seems to me to be an acceptab= le > >> >>>>> imposition. > >> >>>>> > >> >>>>> Yours, > >> >>>>> Joel > >> >>>>> > >> >>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >> >>>>>> Part of my personal view is that I am trying to make this work > >> sensibly > >> >>>>>> in a more orchestrated environment. I expect that the service > >> >>>>>> functions, and over time probably the SFF capabilities, will be > >> >>>>>> orchestrated and installed. I expect the service chains to be > >>driven > >> by > >> >>>>>> BSS tools that define offerings to clients, and enable > >>self-selection > >> >>>>>> from these. I expect service paths to be heavily policy drive. > >> >>>>>> > >> >>>>>> I can see how to make all of that work in an archtiecture drive= n > >>by > >> >>>>>> initial classification to described service paths. It is harde= r > >>to see > >> >>>>>> how to make it work (but it can be done) when we allow more > >> >> dynamicity > >> >>>>>> in the network behavior. > >> >>>>>> > >> >>>>>> Having said that, most of that perspective I described is > >>outside of > >> the > >> >>>>>> scope of the working group. it is not something we are tasked = to > >> >>>>>> agree on. > >> >>>>>> So I do not claim that vision means we have to do it a certain > >>way. > >> it > >> >>>>>> is just the perspective that drives my preferences. > >> >>>>>> > >> >>>>>> Yours, > >> >>>>>> Joel > >> >>>>>> > >> >>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: > >> >>>>>>>> For me, the amount of information about service instances > that > >> >> needs > >> >>>> to > >> >>>>>>>> be widely distributed and maintained, potentially even across > >> data > >> >>>>>>>> centers within an administrative scope, is large enough and > >> >> complex > >> >>>>>>>> enough that trying to get that into each SFF seems like a > >>difficult > >> >>>>>>>> architecture to realize. > >> >>>>>>> > >> >>>>>>> I'm curious as to why that is more complicated than dynamic > >> routing, > >> >>>>>>> hyper-scale data center orchestration, or DNS, all of which ar= e > >> bigger > >> >>>>>>> problems that have been profitably and stably implemented? > >> >>>>>>> > >> >>>>>>> It also seems that if it really is more complicated, that is a > >>good > >> >>>>>>> sign that it is too complicated. > >> >>>>>>> > >> >>>>>>> ________________________________________ > >> >>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] > >> >>>>>>> Sent: Thursday, July 10, 2014 9:45 PM > >> >>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian > >> Smith; > >> >>>>>>> sfc@ietf.org > >> >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> >>>>>>> > >> >>>>>>> This is an architectural issue. And one that I would prefer w= e > >> >>>> actually > >> >>>>>>> decide, rather than trying to allow all possible > >>implementations. > >> >>>>>>> Because it does have a major effect on the control > requirements > >> and > >> >> the > >> >>>>>>> functionality of SFFs. > >> >>>>>>> > >> >>>>>>> For me, the amount of information about service instances that > >> >> needs to > >> >>>>>>> be widely distributed and maintained, potentially even across > >>data > >> >>>>>>> centers within an administrative scope, is large enough and > >> complex > >> >>>>>>> enough that trying to get that into each SFF seems like a > >>difficult > >> >>>>>>> architecture to realize. > >> >>>>>>> > >> >>>>>>> Yours, > >> >>>>>>> Joel > >> >>>>>>> > >> >>>>>>> But it is a fair question. > >> >>>>>>> > >> >>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >> >>>>>>>> This is the crux of my issue. Is the end to end selection o= f > >> >>>>>>>> (top-level) instances performed centrally (perhaps by the > >> classifier) > >> >>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently the > >> >> SFFs)? > >> >>>>>>>> Such selection is not equivalent to reclassification. And > >>surely, > >> >>>>>>>> this is an architectural issue and not relegated to > >> >>>>>>>> "implementation". > >> >>>>>>>> > >> >>>>>>>> My own view is to favor the distributed approach even though > a > >> >>>>>>>> greater amount of data (chain definitions and perhaps local > >> >> selection > >> >>>>>>>> policy) is required at those distributed decision points. > >>This > >> >>>>>>>> approach does not require an end-to-end path id at all. My > >> >>>>>>>> rationale for favoring this approach is primarily driven by > >> increased > >> >>>>>>>> resiliency over the global path id approach. With a global > >>path > >> id > >> >>>>>>>> approach, consider failure of an instance and needing to alte= r > >>the > >> >>>>>>>> global path ID table for each and every affected end-to-end > >>path. > >> >>>>>>>> > >> >>>>>>>> Ron > >> >>>>>>>> > >> >>>>>>>> ________________________________________ From: sfc > >> >>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >> >>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 > 6:15 > >> PM > >> >>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: > >> Re: > >> >>>>>>>> [sfc] Service Chains, Paths, and Load Balancers > >> >>>>>>>> > >> >>>>>>>> The way the architecture models the case of SF1 needing to > >> >> influence > >> >>>>>>>> the chain is that one would do reclassification at the exit > >>from > >> >>>>>>>> SF1. > >> >>>>>>>> > >> >>>>>>>> Part of the goal is to keep the different functions logically > >> >>>>>>>> separate so that solutions can clearly describe how they > choose > >> to > >> >>>>>>>> compose them for "service" delivery. > >> >>>>>>>> > >> >>>>>>>> Yours, Joel > >> >>>>>>>> > >> >>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >> >>>>>>>>> I don't see anything in the arch draft that suggests any sor= t > >>of > >> >>>>>>>>> limit. However, it does seem to indicate that the entire pat= h > >>(all > >> >>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this > >>means > >> >>>>>>>>> either at the classifier or maybe the classifier chooses a S= F > >>Chain > >> >>>>>>>>> and the NF or at the latest the first SFF. In any case, the > >> >>>>>>>>> language does seem to prohibit a more dynamic SFP where > >> SFI(n) > >> >> is > >> >>>>>>>>> determined at the SFI(n-1) hop. According to the draft, thi= s > >> >>>>>>>>> behavior would be considered "branching" to a new SFP as > >> >> opposed to > >> >>>>>>>>> choosing and then forwarding to the selected instance of the > >> >>>>>>>>> next-hop of the current SFC. > >> >>>>>>>>> > >> >>>>>>>>> draft-merged-sfc-architecture-00: > >> >>>>>>>>>> When an SFC is instantiated into the network it is necessar= y > >>to > >> >>>>>>>>>> select the specific instances of SFs that will be used, and > >>to > >> >>>>>>>>>> create the service topology for that SFC using SF's network > >> >>>>>>>>>> locator. Thus, instantiation of the SFC results in the > >>creation > >> >>>>>>>>>> of a Service Function Path (SFP) and is used for forwarding > >> >>>>>>>>>> packets through the SFC. In other words, an SFP is the > >> >>>>>>>>>> instantiation of the defined SFC. > >> >>>>>>>>>> > >> >>>>>>>>>> The SFC architecture supports reclassification (or > >>non-initial > >> >>>>>>>>>> classification) as well. As packets traverse an SFP, > >> >>>>>>>>>> reclassification may occur - typically performed by a > >> >>>>>>>>>> classification function co-resident with a service function= . > >> >>>>>>>>>> Reclassification may result in the selection of a new SFP, = an > >> >>>>>>>>>> update of the associated metadata, or both. This is > >>referred to > >> >>>>>>>>>> as "branching". > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >>--------------------------------------------------------------------- > >> >>>> --- > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>> *From: *I.Smith@F5.com > >> >>>>>>>>> *To: *Joel Halpern Direct,Joel > M. > >> >>>>>>>>> > >> >>>> > >> >> > >> > Halpern,huang@sce.carleton.ca >> >> on.ca>,s > >> >>>> fc@ietf.org > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>> *Sent: *Thursday, July 10, 2014 > >> >>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balance= rs > >> >>>>>>>>> > >> >>>>>>>>> Actually, I think I am disagreeing. > >> >>>>>>>>> > >> >>>>>>>>> If the possibility of medium-scale deployments (and that is > >>what > >> >>>>>>>>> 16 million flows is in my world) of service chains is > >>preconceived > >> >>>>>>>>> as an absurd idea, then the architecture burdened with that > >> >>>>>>>>> preconception. > >> >>>>>>>>> > >> >>>>>>>>> There has to be some point of aim, some degree of > aspiration > >>to > >> >>>>>>>>> scale that is appropriate for the lifespan of the > >>architecture - > >> >>>>>>>>> you don't have to know what it is, but by saying that an > >> arbitrary > >> >>>>>>>>> number is "too far", you're creating - even if it isn't > >>intentional > >> >>>>>>>>> - a limit that influences decisions that have lasting impact= s > >> >>>>>>>>> regarding scale-out, failure mitigation, elasticity, address > >> >>>>>>>>> space... all kinds of things. That is a problem I'm not > >> >>>>>>>>> particularly eager to deal with. > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> ________________________________________ > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >> >>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. > >>Halpern; > >> >>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Servi= ce > >> >>>>>>>>> Chains, Paths, and Load Balancers > >> >>>>>>>>> > >> >>>>>>>>> Ian, I don't think you disagree with me at all in this > >>regard. I am > >> >>>>>>>>> not requesting the the architecture or the solution prohibit > >> >>>>>>>>> deployments in the specific fashion. I am objecting to > Huang's > >> >>>>>>>>> reading of my note as saying that such deployments are > >> required > >> >>>>>>>>> they by the archtiecture. > >> >>>>>>>>> > >> >>>>>>>>> As I have said repeatedly, I am not trying to prohibit such > >> >>>>>>>>> things. Whether they are a good idea or not depends upon > >> many > >> >>>>>>>>> factors outside of the scope of the WG. I happen to think > that > >> they > >> >>>>>>>>> are usually a bad idea. > >> >>>>>>>>> > >> >>>>>>>>> But the archtiecture si carefully avoiding attempting to kno= w > >> what > >> >>>>>>>>> is and is not eployable. > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >> >>>>>>>>>> I disagree. > >> >>>>>>>>>> > >> >>>>>>>>>> We routinely have stateful devices that manage tens of > >> millions > >> >>>>>>>>>> of > >> >>>>>>>>> concurrent flows in both access network and data center > >> >>>>>>>>> environments today. You can't seriously believe that in the > >> >>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are > >> only > >> >> going > >> >>>>>>>>> to have small numbers of service chains with equally small > >> >> numbers > >> >>>>>>>>> of active service paths? > >> >>>>>>>>>> > >> >>>>>>>>>> Your sounds too much like "no one will ever need more > than > >> >> 64K" > >> >>>>>>>>>> for > >> >>>>>>>>> comfort. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> ________________________________________ From: sfc > >> >>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >> >>>>>>>>> [jmh@joelhalpern.com] > >> >>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > >> huang@sce.carleton.ca; > >> >>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and > >>Load > >> >>>>>>>>>> Balancers > >> >>>>>>>>>> > >> >>>>>>>>>> No, it will mean that if someone tries to deploy the > >>archtieture > >> >>>>>>>>>> particularly badly, they will exceed the limits of their > >> >>>>>>>>>> devices. The architecture does not require such absurd use > of > >> >>>>>>>>>> service paths. Since I can not figure out how to write > >> >>>>>>>>>> architectural words to prohibit it, the architecture does > >>permit > >> >>>>>>>>>> such abuse. > >> >>>>>>>>>> > >> >>>>>>>>>> Please do not read my saying that the archtiecture permits > >> >>>>>>>>>> something as saying it is either deisred or required by the > >> work. > >> >>>>>>>>>> It isn't. > >> >>>>>>>>>> > >> >>>>>>>>>> Yours, Joel > >> >>>>>>>>>> > >> >>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> >>>>>>>>>>> If you need to support 100 service chains, it will mean > >> >>>>>>>>>>> 16,000,000 paths. That is larger than the routing table of= a > >> >>>>>>>>>>> core router. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Chang > >> >>>>>>>>>>> > >> >>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >> >>>>>>>>>>>> The architecture allows a range of deployments, from 1 > >> >>>>>>>>>>>> service path to 160000 service paths. I would hope that > >> >>>>>>>>>>>> operators are prepared for the complexities if they > choose > >> to > >> >>>>>>>>>>>> avoid any use of local load balancing and in stead > >>provision > >> >>>>>>>>>>>> 160,000 service paths. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >> >>>>>>>>>>>>> Paul, > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> How many path identifiers there will be for a 4 hop > >>service > >> >>>>>>>>>>>>> chain with 20 instances at each hop? > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Maria > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >> >>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >> >>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >> >>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >> >>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >> >>>>>>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Lucy, > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the > >> >>>>>>>>>>>>> forwarding. I'd > >> >>>>>>>>> make > >> >>>>>>>>>>>>> the minor change: the path identifier can be used to > >>derive > >> >>>>>>>>>>>>> the needed forwarding and associated transport. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply > >> >>>>>>>>>>>>> identify the service path (or graph) that packets must > >> >>>>>>>>>>>>> traverse. By having a path identifier, the exact > >> >>>>>>>>>>>>> indirection that people seem to be asking for on this > >> >>>>>>>>>>>>> thread can be simply be implemented. The path > identifier > >> >>>>>>>>>>>>> provides nothing more than a lookup, that lookup can > >> result > >> >>>>>>>>>>>>> in a one or more (equal or weighted) transport next > >> >>>>>>>>>>>>> hop(s). > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Paul > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >> >>>>>>>>>>>>> > > >> >>>>>>>>>>>>> wrote: > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the > >> >>>>>>>>>>>>> service path identifier to drive the forwarding actions. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Lucy > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >> >>>>>>>>>>>>> Of*mohamed.boucadair@orange.com > >> >>>>>>>>>>>>> > >> *Sent:*Thursday, > >> >> July > >> >>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >> >>>>>>>>>>>>> ;jmh@joelhalpern.com > >> >>>>>>>>>>>>> ;sfc@ietf.org > >> >>>>>>>>>>>>> *Subject:*Re: [sfc] Service Chains= , > >> >>>>>>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Re-, > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> The merged draft calls out explicitly a service path > >> >>>>>>>>>>>>> identifier. I object to use that identifier to derive > >> >>>>>>>>>>>>> forwarding actions. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of > every > >> >>>>>>>>> available SFC > >> >>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not > >> >>>>>>>>> required/justified > >> >>>>>>>>>>>>> nor possible in various deployment contexts. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> SFC forwarding actions should rely on the piece of > >> >>>>>>>>>>>>> information > >> >>>>>>>>> that will > >> >>>>>>>>>>>>> be present in all deployments: that is the one required > to > >> >>>>>>>>>>>>> structure a service chain. How that information is used > to > >> >>>>>>>>>>>>> infer forwarding > >> >>>>>>>>> actions > >> >>>>>>>>>>>>> is a solution-oriented discussion. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Cheers, > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Med > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >> >>>>>>>>> de*mikebianc@aol.com > >> >>>>>>>>>>>>> *Envoy=E9 :*mercredi 9 > juillet > >> >>>>>>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com > >> >>>>>>>>>>>>> ;sfc@ietf.org > >> >>>>>>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >> >>>>>>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Is anyone still questioning the difference between SF > >>Chain > >> >>>>>>>>>>>>> and SF > >> >>>>>>>>> Path? > >> >>>>>>>>>>>>> Other than clarifying the definition so that it's clear = to > >> >>>>>>>>> those not > >> >>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees o= n > >> >>>>>>>>>>>>> these terms. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> To me, the one point that is still unclear is whether it > >>is > >> >>>>>>>>>>>>> the intent of this draft to ultimately specify what the = ID > >> >>>>>>>>>>>>> of the SFC Header > >> >>>>>>>>> should > >> >>>>>>>>>>>>> reference (the chain or the path), or if this draft simp= ly > >> >>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts > to > >> >>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain > or > >> >>>>>>>>>>>>> path and the choice of chain or > >> >>>>>>>>> path to > >> >>>>>>>>>>>>> be negotiated in the control-plane. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> If the latter (ambiguous), then the draft would have > >> >>>>>>>>>>>>> require that both SFP and SFC be supported (or make > one > >> >>>>>>>>>>>>> required and the other optional) to avoid some vendors > >> only > >> >>>>>>>>>>>>> supporting SFP and others only supporting SFC. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>> > >>--------------------------------------------------------------------- > >> >>>> --- > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>>>> *From:*jmh@joelhalpern.com >> >>>>>>>>>>>>> > > > >> >>>>>>>>>>>>> *To:*sfc@ietf.org >> >>>>>>>>>>>>> > *Sent:*Tuesday, > July > >> >>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >> >>>>>>>>>>>>> Balancers > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> I have been trying to figure out how to clearly answer a > >> >>>>>>>>>>>>> number of comments that have been made about the > >> >> proposed > >> >>>>>>>>>>>>> merged archtiecture draft. Assuming we can get working > >> >>>>>>>>>>>>> group agreement on the intent, we will work to improve > >> the > >> >>>>>>>>>>>>> wording so that readers who have not participated in > the > >> WG > >> >>>>>>>>>>>>> discussion will understnd it the way the > >> >>>>>>>>> working > >> >>>>>>>>>>>>> group intends. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> But what do we intend? I will try to explain my personal > >> >>>>>>>>>>>>> view, and see if that helps. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> In this regard, it is important to keep in mind that wha= t > >> >>>>>>>>>>>>> we are defining is the data plane architecture. We are > not > >> >>>>>>>>>>>>> attempting to define the architecture for the entire > >> >>>>>>>>>>>>> solution for service chaining. That would encompass > >> >>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual > >> >>>>>>>>>>>>> machine and image management, and many other > aspects. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> As a result there are many things which clearly need to > >> >>>>>>>>>>>>> exist in the larger system, but which are dealt with > above > >> >>>>>>>>>>>>> where we are > >> >>>>>>>>> functioning, > >> >>>>>>>>>>>>> and are not directly required by the work we are doing. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> In order to get to service chain vs service path, as I > >> >>>>>>>>>>>>> understand > >> >>>>>>>>> them, > >> >>>>>>>>>>>>> I need to first discuss load balancing. There are at lea= st > >> >>>>>>>>>>>>> three different ways that load balancing can and will > >> >>>>>>>>>>>>> interact with service chaining. There probably are more. > >> >>>>>>>>>>>>> The point of the archtiecture is to permit all of these, > >> >>>>>>>>>>>>> but not to mandate that any particular kind > >> >>>>>>>>> be used > >> >>>>>>>>>>>>> in any solution. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> 1) Load balancing as a service provided to the end user. > >> >>>>>>>>>>>>> This is a service function. It receives user packets, an= d > >> >>>>>>>>>>>>> modifies them (or > >> >>>>>>>>> marks > >> >>>>>>>>>>>>> them, or ...) so as to choose an end user service instan= ce > >> >>>>>>>>>>>>> to receive the users packet. This is an important servic= e > >> >>>>>>>>>>>>> function to be able to include in service chaining. It's > >> >>>>>>>>>>>>> behavior may affect requirements on how service > chaining > >> is > >> >>>>>>>>>>>>> done. But it has very little impact on the archtiecture. > >> >>>>>>>>>>>>> From an architectural pe3rspective it is simply a > >> >>>>>>>>> service > >> >>>>>>>>>>>>> function which may modify the underlying packet. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> 2) There is internal load balancing. That is, one can ha= ve > >> >>>>>>>>>>>>> what > >> >>>>>>>>> appears > >> >>>>>>>>>>>>> to the service chaining architecture as a single point o= f > >> >>>>>>>>>>>>> contact > >> >>>>>>>>> for a > >> >>>>>>>>>>>>> specific service function, but is actually delivered by = a > >> >>>>>>>>> collection of > >> >>>>>>>>>>>>> virtual or physical machines, possibly including one or > >> >>>>>>>>>>>>> several load balancers (for example using VRRP-like > >> >>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is > >> >>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. > >>It > >> >>>>>>>>>>>>> is likely that it is visible to various control > >>mechanisms, > >> >>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and v= m > >> >>>>>>>>>>>>> instantiation. The architectural impact of permitting th= is > >> >>>>>>>>>>>>> is largely that we need to be careful that our > terminology > >> >>>>>>>>>>>>> does not lead > >> >>>>>>>>> readers to > >> >>>>>>>>>>>>> think we are prohibiting it. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> 3) There can also be load balancing done by selecting > >> >>>>>>>>>>>>> packet paths for the service chaining that direct traffi= c > >> >>>>>>>>>>>>> to different places. We would not want to require that a > >> >>>>>>>>>>>>> given service function appear at only one place in the > >> >>>>>>>>>>>>> network. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> It is of course the case that these may be combined. I > >>tend > >> >>>>>>>>>>>>> to > >> >>>>>>>>> refer to > >> >>>>>>>>>>>>> the collection of entities that appear to service chaini= ng > >> >>>>>>>>>>>>> as a single point as a cluster. Not because cluster is a > >> >>>>>>>>>>>>> good term. But because I do not have another one. > Thus, > >> the > >> >>>>>>>>>>>>> point of type 3 load balancing > >> >>>>>>>>> is to > >> >>>>>>>>>>>>> direct different subsets of traffic to different singula= r > >> >>>>>>>>>>>>> or clustered service functions in different places in th= e > >> >>>>>>>>>>>>> network. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Now with that said, what do I mean when I talk about > >> >>>>>>>>>>>>> service chain and service path/ Service chain is a > >>sequence > >> >>>>>>>>>>>>> of logical functions to be applied to a subset of packet= s. > >> >>>>>>>>>>>>> It is equivalent of saying that some subset of traffic i= s > >> >>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall > >> >>>>>>>>>>>>> while a different subset is to go directly to the cache > >> >>>>>>>>> without > >> >>>>>>>>>>>>> visiting any other service functions. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> That is not enough information to direct the packets. A > >> >>>>>>>>>>>>> service path is, in some fashion, a sequence of location= s > >> >>>>>>>>>>>>> in the network. Those locations will be singular or > >> >>>>>>>>>>>>> clustered service function delivery locations. They may > be > >> >>>>>>>>>>>>> addressed by IP address. They may be addressed as > ports > >> on > >> >>>>>>>>>>>>> an SFF. There are many different ways that the locations > >> >>>>>>>>>>>>> may be known to the service chaining infrastructure and > >> the > >> >>>>>>>>>>>>> transport. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>>> From the point of view of the work of the SFC group, > >>we > >> >>>>>>>>>>>>>> need to be > >> >>>>>>>>>>>>> able to talk about the high level abstraction, the servi= ce > >> >>>>>>>>>>>>> chain, which drives the forwarding. And we need to talk > >> >>>>>>>>>>>>> about the actual data path packets will take in the > >> >>>>>>>>>>>>> network. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Several of the comments have said "but the whole path > >> may > >> >>>>>>>>>>>>> not be known at the front." This architecture deals with > >> >>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on > >>load > >> >>>>>>>>>>>>> balancers above, there can be decisions and behaviors > >> which > >> >>>>>>>>>>>>> are invisible to the service chaining mechanisms (in > much > >> >>>>>>>>>>>>> the same way that bridging within a LAN is largely > >> >>>>>>>>>>>>> invisible to routing between LANs.) The other provision > we > >> >>>>>>>>>>>>> make is > >> >>>>>>>>> that > >> >>>>>>>>>>>>> reclassification can be done in mid-chain when > necessary. > >> >>>>>>>>>>>>> That will direct packets to a new chain. Based on > >> >>>>>>>>>>>>> information available at the re-classification point. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> I hope that this helps explain what we are after. If it > >> >>>>>>>>>>>>> does, and if the intent is acceptable to the working > >>group, > >> >>>>>>>>>>>>> we can figure out what additional words are needed to > >> >>>>>>>>>>>>> convey this. If the working group disagree with the > >>intent, > >> >>>>>>>>>>>>> then we will of course adjust to match the working > group > >> >>>>>>>>>>>>> agreements. If this is still unclear, I am not sure what > >>to > >> >>>>>>>>>>>>> try next. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> _______________________________________________ > sfc > >> >> mailing > >> >>>>>>>>>>>>> list sfc@ietf.org > >> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> _______________________________________________ > sfc > >> >> mailing > >> >>>>>>>>>>>>> list sfc@ietf.org > >> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> _______________________________________________ > sfc > >> >> 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/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 > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> sfc mailing list > >> >>>> sfc@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/sfc > >> >> > >> >> _______________________________________________ > >> >> sfc mailing 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 Jul 11 06:59: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 D438E1B2AE2 for ; Fri, 11 Jul 2014 06:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df7n3Pxr_Rk6 for ; Fri, 11 Jul 2014 06:59:14 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214B71B2ACD for ; Fri, 11 Jul 2014 06:59:14 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 2bdefb35.2ac01365e940.6644824.00-2435.18390803.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:59:14 +0000 (UTC) X-MXL-Hash: 53bfedb240e71865-0e1230a4f6346dfaf1358b4ccf1eee041e7fe32e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id aadefb35.0.6644758.00-2156.18390659.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 13:59:07 +0000 (UTC) X-MXL-Hash: 53bfedab44777eb3-1504d353c34fccfce098240b5b7f7ef27ef819d4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDx6Qc009292; Fri, 11 Jul 2014 09:59:06 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BDx1Aq009197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 09:59:02 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 13:58:51 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 09:58:51 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNg Date: Fri, 11 Jul 2014 13:58:50 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 ] X-AnalysisOut: [a=n2LCcfabAAAA:8 a=z9tbli-vAAAA:8 a=i0EeH86SAAAA:8 a=UhMfR] X-AnalysisOut: [uZGMvWekcTX8oQA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=Hz] X-AnalysisOut: [7IrDYlS0cA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037] X-AnalysisOut: [QrwtgA:10 a=oAXR_kdF8uMA:10 a=xHx6DIdHgOMjA4NC:21 a=HxvylM] X-AnalysisOut: [EUdKl_VpDj:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uvUEUQmyp1CSpAJUDs5kotFjOj8 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 13:59:19 -0000 QWJzb2x1dGVseS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKQ0KPiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPiBUbzog TkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4gDQo+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkg Li4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgdGhhdCBpZg0KPiB5b3UgYWxsb3cgYW4gU0ZGIHRv IG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0IHdpbGwgdXNlIGZvcg0K PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVu IHlvdSBiZXR0ZXIgbWFrZQ0KPiBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVj ZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8gcmVhY2ggdGhlDQo+IG5leHQtbmV4dC1TRiBmb3Ig dGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4gDQo+IE9u IDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4g d3JvdGU6DQo+IA0KPiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0 YW50aWF0ZWQgb25seSBpbiByZWxldmFudCBTRkZzDQo+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+ ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQNCj4gPj4o amd1aWNoYXIpDQo+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjI3IEFNDQo+ID4+ IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4gPj4NCj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkg aGF2ZSB1bmRlcnN0b29kIHRoZQ0KPiA+PnByb3Bvc2FsDQo+ID4+IGNvcnJlY3RseSBhcyBpdCB3 b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZSBTRiB3aXRoaW4NCj4g Pj50aGUNCj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVy ZSBpcyBubyB3YXkgdG8ga25vdyBhDQo+ID4+cHJpb3JpDQo+ID4+IHdoaWNoIFNGQ8K5cyBhIGdp dmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4gcG9pbnQgaW4gdGltZS4N Cj4gPj4NCj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhA am9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQg dGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0gd2l0aCB0aGUNCj4gPj55b3Vy DQo+ID4+ID5wcm9wb3NhbCBhcyBJIHVuZGVyc3RhbmQgaXQuICAoQW5kIEkgcmVhZGlseSBhZG1p dCBJIG1heSBub3QgdW5kZXJzdGFuZA0KPiA+PiA+aXQuKQ0KPiA+PiA+DQo+ID4+ID5UaGUgcHJv cG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvciB0aGUgbmV4 dA0KPiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0 IGRlbGl2ZXJzIHRvKSwgaW4gZXZlcnkNCj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRo cm91Z2ggaXQuDQo+ID4+ID4NCj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsg d2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnMgdGhhdA0KPiA+PmV2ZXJ5DQo+ID4+ID5TRkYg d291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2Fk IGJhbGFuY2VyLg0KPiA+PiA+SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cg c2Vuc2l0aXZlLCBhbmQgLyBvciBzdGF0ZWZ1bC4NCj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hp dGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwgZmxvdw0KPiA+PiA+c2Vu c2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbiBhY2Nl cHRhYmxlDQo+ID4+ID5pbXBvc2l0aW9uLg0KPiA+PiA+DQo+ID4+ID5Zb3VycywNCj4gPj4gPkpv ZWwNCj4gPj4gPg0KPiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4gPj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlp bmcgdG8gbWFrZSB0aGlzIHdvcmsNCj4gPj5zZW5zaWJseQ0KPiA+PiA+PiBpbiBhIG1vcmUgb3Jj aGVzdHJhdGVkIGVudmlyb25tZW50LiAgSSBleHBlY3QgdGhhdCB0aGUgc2VydmljZQ0KPiA+PiA+ PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMs IHdpbGwgYmUNCj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0 aGUgc2VydmljZSBjaGFpbnMgdG8gYmUNCj4gPj5kcml2ZW4gYnkNCj4gPj4gPj4gQlNTIHRvb2xz IHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlIHNlbGYtc2VsZWN0 aW9uDQo+ID4+ID4+IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhl YXZpbHkgcG9saWN5IGRyaXZlLg0KPiA+PiA+Pg0KPiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1h a2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUgZHJpdmVuIGJ5DQo+ID4+ID4+ IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuICBJdCBp cyBoYXJkZXIgdG8NCj4gPj5zZWUNCj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0 IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmUNCj4gPj4gZHluYW1pY2l0eQ0KPiA+PiA+ PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4gPj4gPj4NCj4gPj4gPj4gSGF2aW5nIHNhaWQg dGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNpZGUgb2YN Cj4gPj50aGUNCj4gPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBpdCBpcyBub3Qg c29tZXRoaW5nIHdlIGFyZSB0YXNrZWQgdG8NCj4gPj5hZ3JlZQ0KPiA+PiA+Pm9uLg0KPiA+PiA+ PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGEg Y2VydGFpbiB3YXkuDQo+ID4+aXQNCj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhh dCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+ID4+ID4+DQo+ID4+ID4+IFlvdXJzLA0KPiA+PiA+ PiBKb2VsDQo+ID4+ID4+DQo+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQg c2VydmljZSBpbnN0YW5jZXMgdGhhdA0KPiA+Pm5lZWRzDQo+ID4+ID4+Pj50bw0KPiA+PiA+Pj4+ IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbiBh Y3Jvc3MgZGF0YQ0KPiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNj b3BlLCBpcyBsYXJnZSBlbm91Z2ggYW5kDQo+IGNvbXBsZXgNCj4gPj4gPj4+PiBlbm91Z2ggdGhh dCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGEgZGlmZmljdWx0 DQo+ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4g SSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIGR5bmFt aWMNCj4gcm91dGluZywNCj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3Ry YXRpb24sIG9yIEROUywgYWxsIG9mIHdoaWNoIGFyZQ0KPiA+PmJpZ2dlcg0KPiA+PiA+Pj4gcHJv YmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVudGVkPw0K PiA+PiA+Pj4NCj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9y ZSBjb21wbGljYXRlZCwgdGhhdCBpcyBhIGdvb2QNCj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0 b28gY29tcGxpY2F0ZWQuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhA am9lbGhhbHBlcm4uY29tXQ0KPiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQg OTo0NSBQTQ0KPiA+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1p a2ViaWFuY0Bhb2wuY29tOyBJYW4gU21pdGg7DQo+ID4+ID4+PiBzZmNAaWV0Zi5vcmcNCj4gPj4g Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPiA+PiA+Pj4NCj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1 ZS4gIEFuZCBvbmUgdGhhdCBJIHdvdWxkIHByZWZlciB3ZQ0KPiA+PiA+Pj5hY3R1YWxseQ0KPiA+ PiA+Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlIGlt cGxlbWVudGF0aW9ucy4NCj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZm ZWN0IG9uIHRoZSBjb250cm9sIHJlcXVpcmVtZW50cyBhbmQNCj4gPj4gdGhlDQo+ID4+ID4+PiBm dW5jdGlvbmFsaXR5IG9mIFNGRnMuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1v dW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4gbmVlZHMN Cj4gPj4gdG8NCj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwg cG90ZW50aWFsbHkgZXZlbiBhY3Jvc3MgZGF0YQ0KPiA+PiA+Pj4gY2VudGVycyB3aXRoaW4gYW4g YWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQgY29tcGxleA0KPiA+PiA+ Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlr ZSBhIGRpZmZpY3VsdA0KPiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+ID4+ID4+ Pg0KPiA+PiA+Pj4gWW91cnMsDQo+ID4+ID4+PiBKb2VsDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gQnV0 IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4gPj4gPj4+DQo+ID4+ID4+PiBPbiA3LzEwLzE0LCA5 OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2Yg bXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBlbmQgc2VsZWN0aW9uIG9mDQo+ID4+ID4+Pj4gKHRv cC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhlDQo+ ID4+Y2xhc3NpZmllcikNCj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBj bGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkgdGhlDQo+ID4+U0ZGcyk/DQo+ID4+ID4+Pj4gU3Vj aCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4gICBBbmQg c3VyZWx5LA0KPiA+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90 IHJlbGVnYXRlZCB0bw0KPiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+ID4+ID4+Pj4NCj4g Pj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2gg ZXZlbiB0aG91Z2ggYQ0KPiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRl ZmluaXRpb25zIGFuZCBwZXJoYXBzIGxvY2FsDQo+ID4+c2VsZWN0aW9uDQo+ID4+ID4+Pj4gcG9s aWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMuICAg VGhpcw0KPiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBw YXRoIGlkIGF0IGFsbC4gICAgTXkNCj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRo aXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbiBieQ0KPiA+PmluY3JlYXNlZA0KPiA+PiA+ Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICAgV2l0aCBh IGdsb2JhbCBwYXRoDQo+ID4+aWQNCj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVy ZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0byBhbHRlciB0aGUNCj4gPj4gPj4+PiBnbG9i YWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQgZW5kLXRvLWVuZCBw YXRoLg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gUm9uDQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPiA+PiA+Pj4+ IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QN Cj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6IFRodXJzZGF5LCBK dWx5IDEwLCAyMDE0IDY6MTUNCj4gUE0NCj4gPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb207 IEkuU21pdGhARjUuY29tOyBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+ID4+ID4+Pj4gW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4+Pg0K PiA+PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0Yx IG5lZWRpbmcgdG8NCj4gPj5pbmZsdWVuY2UNCj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBv bmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUgZXhpdCBmcm9tDQo+ID4+ID4+Pj4g U0YxLg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRo ZSBkaWZmZXJlbnQgZnVuY3Rpb25zIGxvZ2ljYWxseQ0KPiA+PiA+Pj4+IHNlcGFyYXRlIHNvIHRo YXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5IGNob29zZSB0bw0KPiA+ PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPiA+PiA+Pj4+DQo+ ID4+ID4+Pj4gWW91cnMsIEpvZWwNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6 MTAgUE0sIG1pa2ViaWFuY0Bhb2wuY29tIHdyb3RlOg0KPiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBh bnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueSBzb3J0IG9mDQo+ID4+ ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUg ZW50aXJlIHBhdGggKGFsbA0KPiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMg aW5zdGFudGlhdGlvbi4gIEkgYmVsaWV2ZSB0aGlzIG1lYW5zDQo+ID4+ID4+Pj4+IGVpdGhlciBh dCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllciBjaG9vc2VzIGEgU0YNCj4g Pj5DaGFpbg0KPiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0 IFNGRi4gIEluIGFueSBjYXNlLCB0aGUNCj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRv IHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNGUCB3aGVyZSBTRkkobikNCj4gaXMNCj4gPj4gPj4+ Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiAgQWNjb3JkaW5nIHRvIHRoZSBkcmFm dCwgdGhpcw0KPiA+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICJicmFuY2hp bmciIHRvIGEgbmV3IFNGUCBhcw0KPiBvcHBvc2VkDQo+ID4+IHRvDQo+ID4+ID4+Pj4+IGNob29z aW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlIG9mIHRoZQ0K PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+ID4+ID4+Pj4+DQo+ID4+ ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0KPiA+PiA+Pj4+Pj4gV2hl biBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVjZXNzYXJ5 IHRvDQo+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhh dCB3aWxsIGJlIHVzZWQsIGFuZCB0bw0KPiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRv cG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcmsNCj4gPj4gPj4+Pj4+IGxvY2F0 b3IuICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUgY3JlYXRp b24NCj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1 c2VkIGZvciBmb3J3YXJkaW5nDQo+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4g SW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24g b2YgdGhlIGRlZmluZWQgU0ZDLg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJj aGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yIG5vbi1pbml0aWFsDQo+ID4+ ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4g U0ZQLA0KPiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkg cGVyZm9ybWVkIGJ5IGENCj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJl c2lkZW50IHdpdGggYSBzZXJ2aWNlIGZ1bmN0aW9uLg0KPiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNh dGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcgU0ZQLCBhbg0KPiA+PiA+ Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiAgVGhpcyBp cyByZWZlcnJlZCB0bw0KPiA+PiA+Pj4+Pj4gYXMgImJyYW5jaGluZyIuDQo+ID4+ID4+Pj4+DQo+ ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+DQo+ID4+Pj4+Pj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pj4+Pj4+LS0NCj4gPj4gPj4+Pj4tLQ0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0K PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNvbTxJLlNtaXRoQEY1LmNv bT4NCj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuIERpcmVjdDxqbWguZGlyZWN0QGpvZWxo YWxwZXJuLmNvbT4sSm9lbCBNLg0KPiA+PiA+Pj4+Pg0KPiA+Pg0KPiA+Pj4+PkhhbHBlcm48am1o QGpvZWxoYWxwZXJuLmNvbT4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5nQHNjZS4NCj4gPj4g Y2FybGV0b24uDQo+ID4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc+DQo+ID4+ ID4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0DQo+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+ IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+ID4+ID4+Pj4+DQo+ID4+ID4+ Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZCB0 aGF0IGlzIHdoYXQNCj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkg b2Ygc2VydmljZSBjaGFpbnMgaXMgcHJlY29uY2VpdmVkDQo+ID4+ID4+Pj4+IGFzIGFuIGFic3Vy ZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aCB0aGF0DQo+ID4+ID4+ Pj4+IHByZWNvbmNlcHRpb24uDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBi ZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YgYXNwaXJhdGlvbiB0bw0KPiA+PiA+ Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlIGFy Y2hpdGVjdHVyZSAtDQo+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBp cywgYnV0IGJ5IHNheWluZyB0aGF0IGFuIGFyYml0cmFyeQ0KPiA+PiA+Pj4+PiBudW1iZXIgaXMg InRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+ID4+aW50ZW50 aW9uYWwNCj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhh dCBoYXZlIGxhc3RpbmcgaW1wYWN0cw0KPiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBm YWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksIGFkZHJlc3MNCj4gPj4gPj4+Pj4gc3BhY2Uu Li4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPiA+PiA+ Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPiA+PiA+Pj4+Pg0KPiA+PiA+ Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+ID4+ Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29t XSBTZW50Og0KPiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJ YW4gU21pdGg7IEpvZWwgTS4gSGFscGVybjsNCj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9u LmNhOyBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UNCj4gPj4gPj4+Pj4g Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+ IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcyBy ZWdhcmQuIEkNCj4gPj5hbQ0KPiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hp dGVjdHVyZSBvciB0aGUgc29sdXRpb24gcHJvaGliaXQNCj4gPj4gPj4+Pj4gZGVwbG95bWVudHMg aW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRvIEh1YW5nJ3MNCj4gPj4g Pj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMg YXJlIHJlcXVpcmVkDQo+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4gPj4g Pj4+Pj4NCj4gPj4gPj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5 aW5nIHRvIHByb2hpYml0IHN1Y2gNCj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJl IGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueQ0KPiA+PiA+Pj4+PiBmYWN0b3Jz IG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8gdGhpbmsgdGhhdA0K PiA+PnRoZXkNCj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4gPj4gPj4+Pj4N Cj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0 dGVtcHRpbmcgdG8ga25vdyB3aGF0DQo+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxl Lg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+Pj4+Pg0KPiA+PiA+ Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ID4+ID4+Pj4+PiBJ IGRpc2FncmVlLg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0 YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZiBtaWxsaW9ucw0KPiA+PiA+Pj4+Pj4g b2YNCj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFu ZCBkYXRhIGNlbnRlcg0KPiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBz ZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluIHRoZQ0KPiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmls aXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91IGFyZSBvbmx5DQo+ID4+IGdvaW5n DQo+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRo IGVxdWFsbHkgc21hbGwNCj4gbnVtYmVycw0KPiA+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBw YXRocz8NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtl ICJubyBvbmUgd2lsbCBldmVyIG5lZWQgbW9yZSB0aGFuDQo+IDY0SyINCj4gPj4gPj4+Pj4+IGZv cg0KPiA+PiA+Pj4+PiBjb21mb3J0Lg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0K PiA+PiA+Pj4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBI YWxwZXJuDQo+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+PiA+Pj4+Pj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzogaHVhbmdAc2NlLmNhcmxldG9u LmNhOw0KPiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4gPj4+ Pj4+DQo+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0 byBkZXBsb3kgdGhlIGFyY2h0aWV0dXJlDQo+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHks IHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZiB0aGVpcg0KPiA+PiA+Pj4+Pj4gZGV2aWNl cy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkIHVzZSBvZg0K PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93 IHRvIHdyaXRlDQo+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0 LCB0aGUgYXJjaGl0ZWN0dXJlIGRvZXMgcGVybWl0DQo+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0K PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhh dCB0aGUgYXJjaHRpZWN0dXJlIHBlcm1pdHMNCj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlp bmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkgdGhlIHdvcmsuDQo+ID4+ID4+ Pj4+PiBJdCBpc24ndC4NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPiA+ PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVh bmcgd3JvdGU6DQo+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2Vydmlj ZSBjaGFpbnMsIGl0IHdpbGwgbWVhbg0KPiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRo YXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcgdGFibGUgb2YgYQ0KPiA+PiA+Pj4+Pj4+IGNv cmUgcm91dGVyLg0KPiA+PiA+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4gPj4gPj4+Pj4+ Pg0KPiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBk ZXBsb3ltZW50cywgZnJvbSAxDQo+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAg c2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlIHRoYXQNCj4gPj4gPj4+Pj4+Pj4gb3BlcmF0b3Jz IGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5IGNob29zZSB0bw0KPiA+ PiA+Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBz dGVhZCBwcm92aXNpb24NCj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPiA+ PiA+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+Pj4+Pj4+Pg0KPiA+ PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6 DQo+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IEhv dyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcCBzZXJ2aWNl DQo+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g Pj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJl aGFsZiBPZg0KPiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJz ZGF5LCBKdWx5IDEwLCAyMDE0IDM6MDMNCj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9u ZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tOw0KPiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPiA+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5j QGFvbC5jb20gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsDQo+ID4+ID4+Pj4+ Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+ Pj4+Pj4gTHVjeSwNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29u Y3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPiA+PiA+Pj4+Pj4+Pj4gZm9y d2FyZGluZy4gScK5ZA0KPiA+PiA+Pj4+PiBtYWtlDQo+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlub3Ig Y2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvIGRlcml2ZQ0KPiA+PiA+ Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9ydC4N Cj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0 LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8gc2ltcGx5DQo+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0 aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzIG11c3QNCj4gPj4gPj4+Pj4+ Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPiA+ PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9y IG9uIHRoaXMNCj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVu dGVkLiBUaGUgcGF0aCBpZGVudGlmaWVyDQo+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5n IG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuIHJlc3VsdA0KPiA+PiA+Pj4+Pj4+ Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+ ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gUGF1 bA0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6 MDQgQU0sIEx1Y3kgeW9uZw0KPiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tIDxt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KPiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+ PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhl DQo+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9y d2FyZGluZyBhY3Rpb25zLg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPiA+PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KPiAqU2VudDoqVGh1cnNkYXksDQo+ID4+IEp1bHkNCj4gPj4gPj4+Pj4+Pj4+ IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0KPiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+Pj4+ Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4gPj4gPj4+ Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLA0KPiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+ Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRo DQo+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlm aWVyIHRvIGRlcml2ZQ0KPiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0 aGUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPiA+ PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWlu IGlzIG5vdA0KPiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4gPj4gPj4+Pj4+Pj4+IG5v ciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+ID4+ID4+Pj4+Pj4+ Pg0KPiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0 aGUgcGllY2Ugb2YNCj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+ID4+ID4+Pj4+IHRoYXQg d2lsbA0KPiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQg aXMgdGhlIG9uZSByZXF1aXJlZCB0bw0KPiA+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2Vydmlj ZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCB0bw0KPiA+PiA+Pj4+Pj4+Pj4g aW5mZXIgZm9yd2FyZGluZw0KPiA+PiA+Pj4+PiBhY3Rpb25zDQo+ID4+ID4+Pj4+Pj4+PiBpcyBh IHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+ Pj4+Pj4gQ2hlZXJzLA0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSpEZSBsYSBwYXJ0DQo+ID4+ID4+Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tDQo+ID4+ ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRp IDkganVpbGxldA0KPiA+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBl cm4uY29tDQo+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0Bp ZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywNCj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwg cXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFpbg0KPiA+PiA+Pj4+Pj4+ Pj4gYW5kIFNGDQo+ID4+ID4+Pj4+IFBhdGg/DQo+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNs YXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzIGNsZWFyIHRvDQo+ID4+ID4+Pj4+ IHRob3NlIG5vdA0KPiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNl ZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uDQo+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4N Cj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0 IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcw0KPiA+PiA+Pj4+Pj4+Pj4gdGhlIGlu dGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRA0KPiA+ PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4gPj4gPj4+Pj4gc2hvdWxkDQo+ID4+ID4+ Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJh ZnQgc2ltcGx5DQo+ID4+ID4+Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3Vz LCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8NCj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1l Y2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3INCj4gPj4gPj4+Pj4+Pj4+ IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4gPj4gPj4+Pj4gcGF0aCB0bw0KPiA+ PiA+Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRo ZSBkcmFmdCB3b3VsZCBoYXZlDQo+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAg YW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2Ugb25lDQo+ID4+ID4+Pj4+Pj4+PiByZXF1aXJl ZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seQ0KPiA+ PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZD Lg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+DQo+ID4+DQo+ID4+ Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+LS0NCj4gPj4gPj4+Pj4tLQ0KPiA+PiA+Pj4+Pg0K PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAqRnJv bToqam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+ID4+Pj4+Pj4+ PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4g Pj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+ Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+PiAqU2VudDoqVHVlc2RheSwg SnVseQ0KPiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZA0KPiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93 IHRvIGNsZWFybHkgYW5zd2VyIGENCj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0 aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPiBwcm9wb3NlZA0KPiA+PiA+Pj4+Pj4+Pj4g bWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nDQo+ ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3Jr IHRvIGltcHJvdmUgdGhlDQo+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3 aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluIHRoZSBXRw0KPiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vz c2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPiA+PiA+Pj4+PiB3b3JraW5nDQo+ ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+ Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15IHBlcnNv bmFsDQo+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+ID4+ID4+ Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0 byBrZWVwIGluIG1pbmQgdGhhdCB3aGF0DQo+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcg aXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90DQo+ID4+ID4+Pj4+Pj4+ PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlDQo+ ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBl bmNvbXBhc3MNCj4gPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9s aWN5IGZ1bmN0aW9ucywgdmlydHVhbA0KPiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2Ug bWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIgYXNwZWN0cy4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJs eSBuZWVkIHRvDQo+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0 IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlDQo+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUN Cj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJl Y3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUgZG9pbmcuDQo+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2Vydmlj ZSBwYXRoLCBhcyBJDQo+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+ID4+ID4+Pj4+IHRoZW0s DQo+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4g VGhlcmUgYXJlIGF0IGxlYXN0DQo+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0 aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbA0KPiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qg d2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS4NCj4gPj4gPj4+ Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Yg dGhlc2UsDQo+ID4+ID4+Pj4+Pj4+PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGlj dWxhciBraW5kDQo+ID4+ID4+Pj4+IGJlIHVzZWQNCj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1 dGlvbi4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBh cyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLg0KPiA+PiA+Pj4+Pj4+Pj4gVGhp cyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kDQo+ ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPiA+PiA+Pj4+PiBtYXJrcw0KPiA+PiA+ Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vydmlj ZSBpbnN0YW5jZQ0KPiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBU aGlzIGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlDQo+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBi ZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncw0KPiA+PiA+Pj4+Pj4+ Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UgY2hhaW5p bmcgaXMNCj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0 IG9uIHRoZSBhcmNodGllY3R1cmUuDQo+ID4+ID4+Pj4+Pj4+PiAgRnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPiA+PiA+Pj4+PiBzZXJ2aWNlDQo+ID4+ ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tl dC4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBs b2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBoYXZlDQo+ID4+ID4+Pj4+Pj4+PiB3aGF0 DQo+ID4+ID4+Pj4+IGFwcGVhcnMNCj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBvZg0KPiA+PiA+Pj4+Pj4+Pj4gY29u dGFjdA0KPiA+PiA+Pj4+PiBmb3IgYQ0KPiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBm dW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhDQo+ID4+ID4+Pj4+IGNvbGxl Y3Rpb24gb2YNCj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBv c3NpYmx5IGluY2x1ZGluZyBvbmUgb3INCj4gPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBiYWxh bmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPiA+PiA+Pj4+Pj4+Pj4gdGVjaG5p cXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+ID4+ID4+Pj4+ Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZSBtZWNoYW5p c21zLiBJdA0KPiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2 YXJpb3VzIGNvbnRyb2wgbWVjaGFuaXNtcywNCj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2Ug cmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KPiA+PiA+Pj4+Pj4+ Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1pdHRpbmcg dGhpcw0KPiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1 bCB0aGF0IG91ciB0ZXJtaW5vbG9neQ0KPiA+PiA+Pj4+Pj4+Pj4gZG9lcyBub3QgbGVhZA0KPiA+ PiA+Pj4+PiByZWFkZXJzIHRvDQo+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRp bmcgaXQuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28g YmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcNCj4gPj4gPj4+Pj4+Pj4+IHBhY2tl dCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYw0KPiA+ PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8gcmVx dWlyZSB0aGF0IGENCj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFy IGF0IG9ubHkgb25lIHBsYWNlIGluIHRoZQ0KPiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0 aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZA0KPiA+PiA+Pj4+Pj4+Pj4gdG8NCj4gPj4gPj4+ Pj4gcmVmZXIgdG8NCj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRo YXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmcNCj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xl IHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciBpcyBhDQo+ID4+ID4+Pj4+ Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRo dXMsIHRoZQ0KPiA+PiA+Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+ ID4+ID4+Pj4+IGlzIHRvDQo+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMg b2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXINCj4gPj4gPj4+Pj4+Pj4+IG9yIGNsdXN0 ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZQ0KPiA+PiA+ Pj4+Pj4+Pj4gbmV0d29yay4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0 aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0DQo+ID4+ID4+Pj4+ Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYSBz ZXF1ZW5jZQ0KPiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGll ZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLg0KPiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVu dCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZiB0cmFmZmljIGlzDQo+ID4+ID4+Pj4+Pj4+ PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQgZmlyZXdhbGwN Cj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3Rs eSB0byB0aGUgY2FjaGUNCj4gPj4gPj4+Pj4gd2l0aG91dA0KPiA+PiA+Pj4+Pj4+Pj4gdmlzaXRp bmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tl dHMuIEENCj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBh IHNlcXVlbmNlIG9mIGxvY2F0aW9ucw0KPiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRo b3NlIGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkgbWF5IGJlDQo+ID4+ ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2Vk IGFzIHBvcnRzIG9uDQo+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZl cmVudCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0KPiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3du IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlIGFuZCB0aGUNCj4gPj4gPj4+ Pj4+Pj4+IHRyYW5zcG9ydC4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pj4gIEZyb20g dGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91cCwgd2UNCj4gPj4g Pj4+Pj4+Pj4+PiBuZWVkIHRvIGJlDQo+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQg dGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlDQo+ID4+ID4+Pj4+Pj4+PiBj aGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrDQo+ ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFr ZSBpbiB0aGUNCj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+ Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xl IHBhdGggbWF5DQo+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhp cyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aA0KPiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0 d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQNCj4gPj4gPj4+Pj4+ Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgYmVoYXZpb3Jz IHdoaWNoDQo+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIG1lY2hhbmlzbXMgKGluIG11Y2gNCj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0 IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+ID4+ID4+Pj4+Pj4+PiBpbnZpc2li bGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXIgcHJvdmlzaW9uIHdlDQo+ID4+ ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+ID4+ID4+Pj4+IHRoYXQNCj4gPj4gPj4+Pj4+Pj4+IHJlY2xh c3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4gbmVjZXNzYXJ5Lg0KPiA+ PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNl ZCBvbg0KPiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFz c2lmaWNhdGlvbiBwb2ludC4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUg dGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0DQo+ID4+ID4+ Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3Jr aW5nIGdyb3VwLA0KPiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlv bmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8NCj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0 aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsDQo+ID4+ID4+Pj4+Pj4+ PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZyBncm91 cA0KPiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJ IGFtIG5vdCBzdXJlIHdoYXQgdG8NCj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g c2ZjDQo+ID4+IG1haWxpbmcNCj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWls dG86c2ZjQGlldGYub3JnPg0KPiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4gPj4gbWFpbGlu Zw0KPiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ID4+IG1haWxpbmcN Cj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0K PiA+PiBtYWlsaW5nDQo+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4N Cj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHNmYw0KPiBtYWlsaW5nDQo+ID4+IGxpc3QNCj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+Pj4+Pj4NCj4g Pj4gPj4+Pj4NCj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjDQo+IG1haWxpbmcNCj4gPj4gbGlzdA0KPiA+PiA+Pj4+PiBzZmNAaWV0 Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+ Pg0KPiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHNmYyBtYWlsaW5nDQo+ID4+IGxpc3QNCj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYyBtYWls aW5nDQo+ID4+IGxpc3QNCj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4NCj4g Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4NCj4gPj4gPg0K PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gPnNmY0BpZXRmLm9yZw0KPiA+PiA+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4NCj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gc2ZjIG1haWxpbmcgbGlz dA0KPiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Fri Jul 11 07:09: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 C29201B2B0E for ; Fri, 11 Jul 2014 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQilzvzpIWGy for ; Fri, 11 Jul 2014 07:09:00 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D962F1B2B2B for ; Fri, 11 Jul 2014 07:08:31 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id fdfefb35.2ac036696940.6651112.00-2476.18408982.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 14:08:31 +0000 (UTC) X-MXL-Hash: 53bfefdf190a97ab-f6ba7b09815ebcaad710b598797a641dcdb209f4 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id acfefb35.0.6650909.00-2386.18408399.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 14:08:10 +0000 (UTC) X-MXL-Hash: 53bfefca0452a99d-9c523ea18044c07ff39f4ad2574a79eaa1b41c93 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BE89NS025520; Fri, 11 Jul 2014 10:08:09 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BE81Eb025420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 10:08:05 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 14:07:51 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 10:07:50 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEWlgP//vtHA Date: Fri, 11 Jul 2014 14:07:50 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> In-Reply-To: <53BFECE5.8080207@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=otSi8UBo2X61uvyYYUoA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QoM8in7tF5evRHM7gKn8lR8do-M Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:09:02 -0000 Joel, > Hmm. Would it meet your goals Maria if all packets that arrived at > SFF-X with SFP-Y were (after local SF processing) forwarded to some > specific SFF-Z? Where SFF-Z was selected when the first packet with > SFP-Y arrived at SFF-X? Yes. >=20 > While that is more easily met, that does not seem likely to produce the > scale flexibility you asked for. And if SFF-X may forward packets with Why not? > SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the > capability to ensure that a given flow continues to go to the same next > SFF even when SFF-Z3 is added to the mix. Precisely. > On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: > > Absolutely not. Service chains can be instantiated only in relevant SFF= s > when they "arrive". > > > ... From nobody Fri Jul 11 07:17: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 E857A1B2B0C for ; Fri, 11 Jul 2014 07:17:54 -0700 (PDT) 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 XCwJ_r0oTJXs for ; Fri, 11 Jul 2014 07:17:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483E21B2AFD for ; Fri, 11 Jul 2014 07:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F082324066E; Fri, 11 Jul 2014 07:17:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 14069240380; Fri, 11 Jul 2014 07:17:50 -0700 (PDT) Message-ID: <53BFF20E.60900@joelhalpern.com> Date: Fri, 11 Jul 2014 10:17:50 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dHPMgxe8Gu9sUG494zHfm9ey4Hw Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:17:55 -0000 Just to check, I am going to get pedantic. We have SFF-X, is supporting (possibly via local load balancing) some collection of local service function instances. When packets on a given service function path (SFP-Y) arrive, they are processed by theose service functions, and SFF-X then has to forward the packets (with suitable transport) to a next SFF, who may locally balance among his service function instances. For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z. We consider first the state at time T0 when a packet arrives as SFF-X on SFP-Y with no prior special state in SFF-X (obviously, there is some state about SFP-Y, as we do not want policy lookups at packet handling times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2. If I understand your request, you want SFF-X to pick one of those two SFF, say SFF-Z1. And send all the packets for SFP-Y on to SFF-Z1. Even if SFF-Z3 is added to the network, all packets for all flows using SFP-Y at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only time SFF-X would change that is if discovered or was told that SFF-Z1 was down or unreachable. In that case, it would pick a new one from among the known choices. Maria, if that is what you would like, I believe that either is currently allowed by the architecture or can easily be added. And I am happy to do so. I believe we can describe that in the resilience and failure recovery section that we need to add. But I want to be really sure that is what you want. I don't think that meets Ron's request. Yours, Joel On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: > Joel, > >> Hmm. Would it meet your goals Maria if all packets that arrived at >> SFF-X with SFP-Y were (after local SF processing) forwarded to some >> specific SFF-Z? Where SFF-Z was selected when the first packet with >> SFP-Y arrived at SFF-X? > > Yes. >> >> While that is more easily met, that does not seem likely to produce the >> scale flexibility you asked for. And if SFF-X may forward packets with > > Why not? > >> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the >> capability to ensure that a given flow continues to go to the same next >> SFF even when SFF-Z3 is added to the mix. > > Precisely. > > >> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: >>> Absolutely not. Service chains can be instantiated only in relevant SFFs >> when they "arrive". >>> >> ... > From nobody Fri Jul 11 07:18: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 E8C461B2B12 for ; Fri, 11 Jul 2014 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 1OlMVmbVXeHY for ; Fri, 11 Jul 2014 07:18:17 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337E71B2B0C for ; Fri, 11 Jul 2014 07:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41970; q=dns/txt; s=iport; t=1405088313; x=1406297913; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WMv76jyEQusKcbHfbhQhNGostblJbGmTsRZQP24lz1g=; b=f9MCRxWmNuPxw1gFmOxXGkjvRcdVYp7iuYb0Tlnzyr8+UqEhALSzSpnG crg030CqBmMVSGYK4ebPvNDn2fTll63ekFbJQ0vwwptq3LaPreviNquUl r3U9Dbg3PtAlkNtK1Z973l2Ic6kjIVnI3AHdc0P/5noPMJtboax9BdwFu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHPxv1OtJV2U/2dsb2JhbABPCoMOUlqCcawHkXgKh0IBGXIWdYQDAQEBAwEBAQEXCRExCQIVBAIBCBEBAwEBAQICIwMCAgIlCxQBAgYIAgQBEhuIEwMJCA2tMZkCEwSBLItxgVAFLBAiAgICgnGBTAWWIkmEGotoiDSDRIFvQQ X-IronPort-AV: E=Sophos;i="5.01,643,1400025600"; d="scan'208";a="60079951" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 11 Jul 2014 14:18:31 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6BEIFoB004463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 14:18:15 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 09:18:15 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHIA= Date: Fri, 11 Jul 2014 14:18:14 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: <6B17A5468AC1C5448183EB2AC44F5BF2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7MQegEcemkVTD4eJDab8uG1QQ_c Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:18:23 -0000 T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVu Y3Rpb25hbGl0eQ0KcHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBu ZXh0LWhvcHMgdG8gKmFsbCogU0ZG4oCZcw0Kd2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVu IGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50IHRvIGEgbG9va3VwDQppbnRvIHRob3NlIG5l eHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90IHN1cmUg aG93DQp0aGUgYXJjaGl0ZWN0dXJlIHByZXZlbnRzIHRoYXQ/DQoNCk9uIDcvMTEvMTQsIDk6NTgg QU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQoNCj5BYnNv bHV0ZWx5LiANCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0K Pj4oamd1aWNoYXIpDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4g VG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4gDQo+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9z YWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaWYNCj4+IHlvdSBhbGxvdyBh biBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYgaXQgd2lsbCB1 c2UNCj4+Zm9yDQo+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRo ZSBjaGFpbiB0aGVuIHlvdSBiZXR0ZXIgbWFrZQ0KPj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNG RiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvIHJlYWNoDQo+PnRoZQ0KPj4g bmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0 cm91YmxlLg0KPj4gDQo+PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb20+IHdyb3RlOg0KPj4gDQo+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZp Y2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbiByZWxldmFudA0KPj5TRkZzDQo+ PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4gPg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+ID4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+PiA+PihqZ3VpY2hhcikNCj4+ID4+IFNlbnQ6IEZyaWRh eSwgSnVseSAxMSwgMjAxNCA5OjI3IEFNDQo+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4NCj4+ID4+IFdlbGwgSSB0aGlu ayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGUNCj4+ ID4+cHJvcG9zYWwNCj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25v d2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZSBTRg0KPj53aXRoaW4NCj4+ID4+dGhlDQo+PiA+PiBlbnRp cmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0byBr bm93IGENCj4+ID4+cHJpb3JpDQo+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBu ZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuIHBvaW50IGluDQo+PnRpbWUuDQo+PiA+Pg0KPj4g Pj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBl cm4uY29tPiB3cm90ZToNCj4+ID4+DQo+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJ IHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJvYmxlbSB3aXRoIHRoZQ0KPj4gPj55b3VyDQo+PiA+ PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBt YXkgbm90DQo+PnVuZGVyc3RhbmQNCj4+ID4+ID5pdC4pDQo+PiA+PiA+DQo+PiA+PiA+VGhlIHBy b3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlIG5l eHQNCj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUg aXQgZGVsaXZlcnMgdG8pLCBpbg0KPj5ldmVyeQ0KPj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBn b2VzIHRocm91Z2ggaXQuDQo+PiA+PiA+DQo+PiA+PiA+U2luY2UgaXQgaGFzIHRvIGJlIGFibGUg dG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucyB0aGF0DQo+PiA+PmV2ZXJ5DQo+ PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3Rh dGVmdWwgbG9hZA0KPj5iYWxhbmNlci4NCj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21l IFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yIHN0YXRlZnVsLg0KPj4gPj4gPkJ1dCBo YXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwg Zmxvdw0KPj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8g bWUgdG8gYmUgYW4gYWNjZXB0YWJsZQ0KPj4gPj4gPmltcG9zaXRpb24uDQo+PiA+PiA+DQo+PiA+ PiA+WW91cnMsDQo+PiA+PiA+Sm9lbA0KPj4gPj4gPg0KPj4gPj4gPk9uIDcvMTAvMTQsIDEwOjA2 IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFs IHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMgd29yaw0KPj4gPj5zZW5zaWJs eQ0KPj4gPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gIEkgZXhwZWN0 IHRoYXQgdGhlIHNlcnZpY2UNCj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9i YWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcywgd2lsbCBiZQ0KPj4gPj4gPj4gb3JjaGVzdHJhdGVk IGFuZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8gYmUNCj4+ID4+ ZHJpdmVuIGJ5DQo+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNs aWVudHMsIGFuZCBlbmFibGUNCj4+c2VsZi1zZWxlY3Rpb24NCj4+ID4+ID4+IGZyb20gdGhlc2Uu ICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkgcG9saWN5IGRyaXZlLg0KPj4g Pj4gPj4NCj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGlu IGFuIGFyY2h0aWVjdHVyZSBkcml2ZW4NCj4+YnkNCj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmlj YXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuICBJdCBpcyBoYXJkZXINCj4+dG8NCj4+ ID4+c2VlDQo+PiA+PiA+PiBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUp IHdoZW4gd2UgYWxsb3cgbW9yZQ0KPj4gPj4gZHluYW1pY2l0eQ0KPj4gPj4gPj4gaW4gdGhlIG5l dHdvcmsgYmVoYXZpb3IuDQo+PiA+PiA+Pg0KPj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9z dCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNpZGUNCj4+b2YNCj4+ID4+ dGhlDQo+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21l dGhpbmcgd2UgYXJlIHRhc2tlZCB0bw0KPj4gPj5hZ3JlZQ0KPj4gPj4gPj5vbi4NCj4+ID4+ID4+ IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYSBj ZXJ0YWluDQo+PndheS4NCj4+ID4+aXQNCj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZl IHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4gPj4gPj4NCj4+ID4+ID4+IFlvdXJzLA0K Pj4gPj4gPj4gSm9lbA0KPj4gPj4gPj4NCj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElh biBTbWl0aCB3cm90ZToNCj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0 aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4+ID4+bmVlZHMNCj4+ID4+ID4+Pj50 bw0KPj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVu dGlhbGx5IGV2ZW4gYWNyb3NzDQo+PmRhdGENCj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4g YWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQNCj4+IGNvbXBsZXgNCj4+ ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2Vl bXMgbGlrZSBhDQo+PmRpZmZpY3VsdA0KPj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6 ZS4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1v cmUgY29tcGxpY2F0ZWQgdGhhbiBkeW5hbWljDQo+PiByb3V0aW5nLA0KPj4gPj4gPj4+IGh5cGVy LXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mIHdoaWNoIGFy ZQ0KPj4gPj5iaWdnZXINCj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRh Ymx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBJdCBhbHNv IHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQgaXMgYQ0K Pj5nb29kDQo+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4NCj4+ID4+ ID4+Pg0KPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+ PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsg SWFuDQo+PlNtaXRoOw0KPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gPj4+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g Pj4gPj4+DQo+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiAgQW5kIG9u ZSB0aGF0IEkgd291bGQgcHJlZmVyIHdlDQo+PiA+PiA+Pj5hY3R1YWxseQ0KPj4gPj4gPj4+IGRl Y2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZSBpbXBsZW1lbnRh dGlvbnMuDQo+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24g dGhlIGNvbnRyb2wgcmVxdWlyZW1lbnRzDQo+PmFuZA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gZnVu Y3Rpb25hbGl0eSBvZiBTRkZzLg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1v dW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4+IG5lZWRz DQo+PiA+PiB0bw0KPj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5l ZCwgcG90ZW50aWFsbHkgZXZlbiBhY3Jvc3MNCj4+ZGF0YQ0KPj4gPj4gPj4+IGNlbnRlcnMgd2l0 aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2ggYW5kDQo+PmNvbXBs ZXgNCj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNG RiBzZWVtcyBsaWtlIGENCj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJl YWxpemUuDQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBZb3VycywNCj4+ID4+ID4+PiBKb2VsDQo+PiA+ PiA+Pj4NCj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gPj4gPj4+DQo+ PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ID4+ID4+ Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0aGUgZW5kIHRvIGVuZCBzZWxl Y3Rpb24gb2YNCj4+ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50 cmFsbHkgKHBlcmhhcHMgYnkgdGhlDQo+PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4+IG9yIGhv cC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseSB0aGUN Cj4+ID4+U0ZGcyk/DQo+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50 IHRvIHJlY2xhc3NpZmljYXRpb24uICAgQW5kDQo+PnN1cmVseSwNCj4+ID4+ID4+Pj4gdGhpcyBp cyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+PiA+PiA+Pj4+ ICJpbXBsZW1lbnRhdGlvbiIuDQo+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlz IHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuIHRob3VnaCBhDQo+PiA+PiA+ Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBz IGxvY2FsDQo+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4+PiBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0 IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy4gICBUaGlzDQo+PiA+PiA+Pj4+IGFw cHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0IGFsbC4gICAg TXkNCj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHBy aW1hcmlseSBkcml2ZW4gYnkNCj4+ID4+aW5jcmVhc2VkDQo+PiA+PiA+Pj4+IHJlc2lsaWVuY3kg b3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICAgV2l0aCBhIGdsb2JhbA0KPj5wYXRo DQo+PiA+PmlkDQo+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGlu c3RhbmNlIGFuZCBuZWVkaW5nIHRvIGFsdGVyDQo+PnRoZQ0KPj4gPj4gPj4+PiBnbG9iYWwgcGF0 aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQgZW5kLXRvLWVuZA0KPj5wYXRo Lg0KPj4gPj4gPj4+Pg0KPj4gPj4gPj4+PiBSb24NCj4+ID4+ID4+Pj4NCj4+ID4+ID4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+ Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVj dA0KPj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0IDY6MTUNCj4+IFBNDQo+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9s LmNvbTsgSS5TbWl0aEBGNS5jb207IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4+ID4+ID4+ Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ ID4+Pj4NCj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2Fz ZSBvZiBTRjEgbmVlZGluZyB0bw0KPj4gPj5pbmZsdWVuY2UNCj4+ID4+ID4+Pj4gdGhlIGNoYWlu IGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4aXQgZnJvbQ0K Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwg aXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkNCj4+ID4+ID4+Pj4g c2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkg Y2hvb3NlDQo+PnRvDQo+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2 ZXJ5Lg0KPj4gPj4gPj4+Pg0KPj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+Pg0KPj4g Pj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4+ ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3Vn Z2VzdHMgYW55IHNvcnQNCj4+b2YNCj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2Vz IHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlIHBhdGgNCj4+KGFsbA0KPj4gPj4gPj4+ Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uICBJIGJlbGlldmUg dGhpcw0KPj5tZWFucw0KPj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1h eWJlIHRoZSBjbGFzc2lmaWVyIGNob29zZXMgYSBTRg0KPj4gPj5DaGFpbg0KPj4gPj4gPj4+Pj4g YW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuICBJbiBhbnkgY2FzZSwg dGhlDQo+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5 bmFtaWMgU0ZQIHdoZXJlIFNGSShuKQ0KPj4gaXMNCj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQg dGhlIFNGSShuLTEpIGhvcC4gIEFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoaXMNCj4+ID4+ID4+ Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQ IGFzDQo+PiBvcHBvc2VkDQo+PiA+PiB0bw0KPj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4g Zm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YgdGhlDQo+PiA+PiA+Pj4+PiBu ZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4gZHJh ZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMg aXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVjZXNzYXJ5DQo+PnRvDQo+ PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2ls bCBiZSB1c2VkLCBhbmQgdG8NCj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xv Z3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MgbmV0d29yaw0KPj4gPj4gPj4+Pj4+IGxvY2F0b3Iu ICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4+Y3JlYXRp b24NCj4+ID4+ID4+Pj4+PiBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMg dXNlZCBmb3IgZm9yd2FyZGluZw0KPj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZD LiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRp b24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4+Pj4gVGhlIFNG QyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3Igbm9uLWluaXRpYWwN Cj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVy c2UgYW4gU0ZQLA0KPj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlw aWNhbGx5IHBlcmZvcm1lZCBieSBhDQo+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rp b24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24uDQo+PiA+PiA+Pj4+Pj4gUmVj bGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcgU0ZQLCBh bg0KPj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3IgYm90 aC4gIFRoaXMgaXMgcmVmZXJyZWQNCj4+dG8NCj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4N Cj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+Pj4+DQo+PiA+ Pg0KPj4gDQo+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+LS0NCj4+ ID4+ID4+Pj4+LS0NCj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPj4gPj4gPj4+Pj4g KlRvOiAqSm9lbCBIYWxwZXJuIERpcmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4sSm9l bCBNLg0KPj4gPj4gPj4+Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJu LmNvbT4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5nQHNjZS4NCj4+ID4+IGNhcmxldG9uLg0K Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0DQo+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+Pj4+IEFj dHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ Pj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kIHRo YXQgaXMNCj4+d2hhdA0KPj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3Js ZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMNCj4+cHJlY29uY2VpdmVkDQo+PiA+PiA+Pj4+PiBhcyBh biBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGggdGhhdA0K Pj4gPj4gPj4+Pj4gcHJlY29uY2VwdGlvbi4NCj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+PiBUaGVy ZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mIGFzcGlyYXRpb24g dG8NCj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3Bh biBvZiB0aGUgYXJjaGl0ZWN0dXJlDQo+Pi0NCj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRv IGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFuDQo+PmFyYml0cmFyeQ0KPj4g Pj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBp dCBpc24ndA0KPj4gPj5pbnRlbnRpb25hbA0KPj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5m bHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3RpbmcgaW1wYWN0cw0KPj4gPj4gPj4+Pj4g cmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LCBhZGRy ZXNzDQo+PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEg cHJvYmxlbSBJJ20gbm90DQo+PiA+PiA+Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3 aXRoLg0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4N Cj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERp cmVjdCBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6DQo+PiA+PiA+Pj4+PiBUaHVy c2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS4gSGFscGVy bjsNCj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3JnIFN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsg eW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXMgcmVnYXJkLg0KPj5JDQo+PiA+PmFt DQo+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUg c29sdXRpb24gcHJvaGliaXQNCj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZp YyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0byBIdWFuZydzDQo+PiA+PiA+Pj4+PiByZWFkaW5n IG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmUgcmVxdWlyZWQN Cj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJv aGliaXQgc3VjaA0KPj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBp ZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueQ0KPj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRl IG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvIHRoaW5rIHRoYXQNCj4+ID4+dGhl eQ0KPj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4+PiBCdXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1w dGluZyB0byBrbm93DQo+PndoYXQNCj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxl Lg0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4gPj4gPj4+ Pj4+IEkgZGlzYWdyZWUuDQo+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkg aGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YNCj4+bWlsbGlvbnMNCj4+ ID4+ID4+Pj4+PiBvZg0KPj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2Vz cyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPj4gPj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5 LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbiB0aGUNCj4+ID4+ID4+Pj4+IENs b3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3UgYXJlIG9u bHkNCj4+ID4+IGdvaW5nDQo+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2Vy dmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5IHNtYWxsDQo+PiBudW1iZXJzDQo+PiA+PiA+Pj4+PiBv ZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+Pj4+IFlvdXIg c291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlIHRoYW4NCj4+ IDY0SyINCj4+ID4+ID4+Pj4+PiBmb3INCj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4+Pj4gW3NmYy1ib3VuY2VzQGlldGYu b3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+PiA+PiA+Pj4+PiBbam1oQGpvZWxo YWxwZXJuLmNvbV0NCj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0 OjQ2IFBNIFRvOg0KPj5odWFuZ0BzY2UuY2FybGV0b24uY2E7DQo+PiA+PiA+Pj4+Pj4gc2ZjQGll dGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj5M b2FkDQo+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+Pj4+PiBO bywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+PmFy Y2h0aWV0dXJlDQo+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhj ZWVkIHRoZSBsaW1pdHMgb2YgdGhlaXINCj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0 ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQgdXNlIG9mDQo+PiA+PiA+Pj4+Pj4g c2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlDQo+ PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hp dGVjdHVyZSBkb2VzDQo+PnBlcm1pdA0KPj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+PiA+PiA+ Pj4+Pj4NCj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhl IGFyY2h0aWVjdHVyZSBwZXJtaXRzDQo+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBp dCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieSB0aGUNCj4+d29yay4NCj4+ID4+ID4+ Pj4+PiBJdCBpc24ndC4NCj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+ PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5n IEh1YW5nIHdyb3RlOg0KPj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBz ZXJ2aWNlIGNoYWlucywgaXQgd2lsbCBtZWFuDQo+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0 aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcgdGFibGUgb2YgYQ0KPj4gPj4gPj4+ Pj4+PiBjb3JlIHJvdXRlci4NCj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9lbCBN LiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3Mg YSByYW5nZSBvZiBkZXBsb3ltZW50cywgZnJvbSAxDQo+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBh dGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZSB0aGF0DQo+PiA+PiA+Pj4+ Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlmIHRoZXkg Y2hvb3NlDQo+PnRvDQo+PiA+PiA+Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQg YmFsYW5jaW5nIGFuZCBpbiBzdGVhZCBwcm92aXNpb24NCj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAg c2VydmljZSBwYXRocy4NCj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9l bA0KPj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5B UElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3 aWxsIGJlIGZvciBhIDQgaG9wIHNlcnZpY2UNCj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIw IGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+ IE1hcmlhDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4+ID4+ID4+Pj4+Pj4+PiAq UGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMzowMw0K Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4u Y29tOw0KPj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZzsNCj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSAqU3ViamVjdDoqIFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywNCj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTog YSBwYXRoIElEIGRyaXZlcyB0aGUNCj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nLiBJwrlkDQo+ PiA+PiA+Pj4+PiBtYWtlDQo+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBh dGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUNCj4+ID4+ID4+Pj4+Pj4+PiB0aGUg bmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhl ciBpcyB1c2VkIHRvIHNpbXBseQ0KPj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNl IHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMgbXVzdA0KPj4gPj4gPj4+Pj4+Pj4+IHRyYXZl cnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4gPj4+Pj4+ Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlz DQo+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRo ZSBwYXRoIGlkZW50aWZpZXINCj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUg dGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuIHJlc3VsdA0KPj4gPj4gPj4+Pj4+Pj4+IGlu IGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4gPj4g Pj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IFBhdWwN Cj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6 MDQgQU0sIEx1Y3kgeW9uZw0KPj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbSA8 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCj4+ID4+ID4+Pj4+Pj4+PiB3cm90ZToNCj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ug b2YgdGhlDQo+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUg dGhlIGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+ IEx1Y3kNCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxmDQo+PiA+PiA+Pj4+Pj4+Pj4gT2YqbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+IEp1bHkN Cj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb20N Cj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBl cm4uY29tDQo+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNA aWV0Zi5vcmcNCj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1YmplY3Q6 KlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywNCj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBl eHBsaWNpdGx5IGEgc2VydmljZSBwYXRoDQo+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBv YmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUNCj4+ID4+ID4+Pj4+Pj4+PiBm b3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBSZXF1 aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5DQo+ PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRo cyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPj4gPj4gPj4+Pj4gcmVxdWly ZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVw bG95bWVudCBjb250ZXh0cy4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IFNGQyBm b3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4+ Pj4+Pj4gaW5mb3JtYXRpb24NCj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4gPj4gPj4+Pj4+Pj4+ IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUgcmVxdWlyZWQg dG8NCj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBp bmZvcm1hdGlvbiBpcyB1c2VkIHRvDQo+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0K Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50 ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IENoZWVycywN Cj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRl IGxhIHBhcnQNCj4+ID4+ID4+Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tDQo+PiA+PiA+Pj4+Pj4+ Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gKkVudm95w6kgOiptZXJjcmVkaSA5IGp1aWxs ZXQNCj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb20N Cj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9y Zw0KPj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQgOipSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsDQo+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1 ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU0YgQ2hhaW4NCj4+ID4+ID4+Pj4+Pj4+ PiBhbmQgU0YNCj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBj bGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0bw0KPj4gPj4gPj4+ Pj4gdGhvc2Ugbm90DQo+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0 IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9uDQo+PiA+PiA+Pj4+Pj4+Pj4gdGhlc2UgdGVy bXMuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2lu dCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMgd2hldGhlciBpdCBpcw0KPj4gPj4gPj4+Pj4+Pj4+ IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUg SUQNCj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4+Pj4gc2hvdWxk DQo+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBp ZiB0aGlzIGRyYWZ0IHNpbXBseQ0KPj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhh dCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyIGRyYWZ0cyB0bw0KPj4gPj4gPj4+Pj4+Pj4+IGRp Y3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4gb3INCj4+ ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+PiA+PiA+Pj4+ PiBwYXRoIHRvDQo+PiA+PiA+Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1w bGFuZS4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIgKGFt YmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+ID4+ID4+Pj4+Pj4+PiByZXF1 aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2Ugb25lDQo+PiA+ PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29t ZSB2ZW5kb3JzIG9ubHkNCj4+ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJz IG9ubHkgc3VwcG9ydGluZyBTRkMuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+Pj4NCj4+ID4+DQo+PiANCj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+LS0N Cj4+ID4+Pj4+Pj4tLQ0KPj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+Pj4NCj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipqbWhAam9l bGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb20NCj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+ID4+Pj4+ Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+Pj4+Pj4+PiA8bWFp bHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+ICpTZW50OipUdWVzZGF5LCBKdWx5DQo+ PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZA0KPj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRv IGNsZWFybHkgYW5zd2VyIGENCj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29tbWVudHMgdGhh dCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUNCj4+IHByb3Bvc2VkDQo+PiA+PiA+Pj4+Pj4+Pj4g bWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nDQo+ PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29y ayB0byBpbXByb3ZlIHRoZQ0KPj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJz IHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIFdHDQo+PiA+PiA+Pj4+Pj4+Pj4gZGlz Y3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4gPj4gPj4+Pj4gd29ya2lu Zw0KPj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBt eSBwZXJzb25hbA0KPj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4N Cj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBp bXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdA0KPj4gPj4gPj4+Pj4+Pj4+IHdlIGFy ZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlIGFyZSBub3QNCj4+ ID4+ID4+Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0 aGUgZW50aXJlDQo+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcu IFRoYXQgd291bGQgZW5jb21wYXNzDQo+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBj b250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLCB2aXJ0dWFsDQo+PiA+PiA+Pj4+Pj4+Pj4gbWFj aGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIgYXNwZWN0cy4NCj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRo aW5ncyB3aGljaCBjbGVhcmx5IG5lZWQgdG8NCj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUg bGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlDQo+PiA+PiA+Pj4+ Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ID4+ID4+Pj4+ Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUgZG9p bmcuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8g c2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsIGFzIEkNCj4+ID4+ID4+Pj4+Pj4+PiB1bmRl cnN0YW5kDQo+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJz dCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQgbGVhc3QNCj4+ID4+ID4+Pj4+ Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2ls bA0KPj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUg cHJvYmFibHkgYXJlIG1vcmUuDQo+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNo dGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZiB0aGVzZSwNCj4+ID4+ID4+Pj4+Pj4+PiBidXQg bm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+PiA+PiA+Pj4+PiBiZSB1 c2VkDQo+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRv IHRoZSBlbmQgdXNlci4NCj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlv bi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLCBhbmQNCj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmll cyB0aGVtIChvcg0KPj4gPj4gPj4+Pj4gbWFya3MNCj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBvciAu Li4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlIGluc3RhbmNlDQo+PiA+PiA+ Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFu dCBzZXJ2aWNlDQo+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRl IGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3MNCj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkg YWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZSBjaGFpbmluZyBpcw0KPj4gPj4gPj4+ Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSBhcmNodGll Y3R1cmUuDQo+PiA+PiA+Pj4+Pj4+Pj4gIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3Rp dmUgaXQgaXMgc2ltcGx5IGENCj4+ID4+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+ID4+Pj4+Pj4+PiBm dW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5j aW5nLiBUaGF0IGlzLCBvbmUgY2FuIGhhdmUNCj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+PiA+PiA+ Pj4+PiBhcHBlYXJzDQo+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJj aGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9mDQo+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0K Pj4gPj4gPj4+Pj4gZm9yIGENCj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0 aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGENCj4+ID4+ID4+Pj4+IGNvbGxlY3Rp b24gb2YNCj4+ID4+ID4+Pj4+Pj4+PiB2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3Nz aWJseSBpbmNsdWRpbmcgb25lIG9yDQo+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFu Y2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5p cXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+PiA+PiA+Pj4+ Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUgbWVjaGFu aXNtcy4gSXQNCj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbCBtZWNoYW5pc21zLA0KPj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhv c2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KPj4gPj4gPj4+ Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0 aW5nIHRoaXMNCj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBj YXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5DQo+PiA+PiA+Pj4+Pj4+Pj4gZG9lcyBub3QgbGVh ZA0KPj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBw cm9oaWJpdGluZyBpdC4NCj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJl IGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgc2VsZWN0aW5nDQo+PiA+PiA+Pj4+ Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdCB0 cmFmZmljDQo+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90 IHdhbnQgdG8gcmVxdWlyZSB0aGF0IGENCj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1 bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSBwbGFjZSBpbiB0aGUNCj4+ID4+ID4+Pj4+Pj4+PiBu ZXR3b3JrLg0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNl IHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJIHRlbmQNCj4+ID4+ID4+Pj4+ Pj4+PiB0bw0KPj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVj dGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlIGNoYWluaW5nDQo+PiA+PiA+ Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVz dGVyIGlzIGENCj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90 IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsIHRoZQ0KPj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5 cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4+Pj4gaXMgdG8NCj4+ID4+ID4+Pj4+Pj4+PiBk aXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIN Cj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVy ZW50IHBsYWNlcyBpbiB0aGUNCj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3 aGVuIEkgdGFsayBhYm91dA0KPj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZp Y2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlDQo+PiA+PiA+Pj4+Pj4+Pj4gb2Yg bG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLg0K Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJz ZXQgb2YgdHJhZmZpYyBpcw0KPj4gPj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBj b250ZW50IGluc3BlY3Rpb24sIGFuZCBmaXJld2FsbA0KPj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEg ZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUNCj4+ID4+ID4+ Pj4+IHdpdGhvdXQNCj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBm dW5jdGlvbnMuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBl bm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBDQo+PiA+PiA+Pj4+Pj4+ Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRp b25zDQo+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9ucyB3aWxs IGJlIHNpbmd1bGFyIG9yDQo+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5IG1heSBiZQ0KPj4gPj4gPj4+Pj4+Pj4+IGFkZHJl c3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXMgcG9ydHMgb24NCj4+ ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQg dGhlIGxvY2F0aW9ucw0KPj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2Vydmlj ZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlDQo+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNw b3J0Lg0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRoZSBwb2ludCBv ZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3JvdXAsIHdlDQo+PiA+PiA+Pj4+Pj4+Pj4+ IG5lZWQgdG8gYmUNCj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2gg bGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlDQo+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdo aWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsaw0KPj4gPj4gPj4+ Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRo ZQ0KPj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+ Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUgcGF0 aCBtYXkNCj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBh cmNoaXRlY3R1cmUgZGVhbHMgd2l0aA0KPj4gPj4gPj4+Pj4+Pj4+IHRoYXQgaXNzdWUgaW4gdHdv IHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBvbiBsb2FkDQo+PiA+PiA+Pj4+Pj4+ Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMg d2hpY2gNCj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIG1lY2hhbmlzbXMgKGluIG11Y2gNCj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhh dCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KPj4gPj4gPj4+Pj4+Pj4+IGludmlz aWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UNCj4+ ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+PiA+Pj4+PiB0aGF0DQo+PiA+PiA+Pj4+Pj4+Pj4g cmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbiBuZWNlc3Nhcnku DQo+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWlu LiBCYXNlZCBvbg0KPj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUg cmUtY2xhc3NpZmljYXRpb24gcG9pbnQuDQo+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4+ PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0 DQo+PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0 byB0aGUgd29ya2luZyBncm91cCwNCj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3 aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0bw0KPj4gPj4gPj4+Pj4+Pj4+IGNvbnZl eSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsDQo+ PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhl IHdvcmtpbmcgZ3JvdXANCj4+ID4+ID4+Pj4+Pj4+PiBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0 aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUgd2hhdCB0bw0KPj4gPj4gPj4+Pj4+Pj4+IHRyeSBu ZXh0Lg0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4+ Pj4+Pg0KPj4gPj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0Bp ZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4g Pj4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+ Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+IG1haWxp bmcNCj4+ID4+IGxpc3QNCj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+Pj4NCj4+ ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IHNmYw0KPj4gbWFpbGluZw0KPj4gPj4gbGlzdA0KPj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4+DQo+PiA+ PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNm YyBtYWlsaW5nDQo+PiA+PiBsaXN0DQo+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+Pg0KPj4gPj4gPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGlu Zw0KPj4gPj4gbGlzdA0KPj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+Pj4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4N Cj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiA+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pg0K Pj4gPj4gPg0KPj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPnNmY0BpZXRmLm9yZw0KPj4g Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pg0KPj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNm Y0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0K From nobody Fri Jul 11 07:31: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 D4FBE1B2B58 for ; Fri, 11 Jul 2014 07:31:07 -0700 (PDT) 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, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=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 J8YMi6Ux2zTf for ; Fri, 11 Jul 2014 07:31:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C13E1B2B1A for ; Fri, 11 Jul 2014 07:31:01 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8145F324313; Fri, 11 Jul 2014 16:30:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6183B35C045; Fri, 11 Jul 2014 16:30:59 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 16:30:59 +0200 From: To: "Jim Guichard (jguichar)" , "NAPIERALA, MARIA H" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WtSqAftugz0CPuFwsDNNeGpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHID///EV4A== Date: Fri, 11 Jul 2014 14:30:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.11.63919 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QF4HQa3l-Kz3BQK770uVQ7AYF18 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:31:08 -0000 UmUtLA0KDQpGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQg Y2xlYXJseSBpbiB0aGUgZHJhZnQuIA0KDQpNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwgZGlzdHJpYnV0ZWQgbW9kZWwg aXMgbm90IGFsbG93ZWQuDQoNClNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRl ZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZiBzaG91bGQgYmUgcHJvdmlkZWQgaW5zdGVh ZC4NCg0KQ2hlZXJzLA0KTWVkIA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXC oDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1 aWNoYXJkDQo+KGpndWljaGFyKQ0KPkVudm95w6nCoDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0 IDE2OjE4DQo+w4DCoDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQ YXJrZXI7IHNmY0BpZXRmLm9yZw0KPk9iamV0wqA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPg0KPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0 ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj5wcm9oaWJpdGVkPyBJ ZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlz DQo+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVy IHBvaW50IHRvIGEgbG9va3VwDQo+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5l eHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdCBzdXJlIGhvdw0KPnRoZSBhcmNoaXRlY3R1cmUg cHJldmVudHMgdGhhdD8NCj4NCj5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJ QSBIIiA8bW4xOTIxQGF0dC5jb20+IHdyb3RlOg0KPg0KPj5BYnNvbHV0ZWx5Lg0KPj4NCj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+Pj4oamd1aWNoYXIpDQo+ Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+PiBUbzogTkFQSUVSQUxB LCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4+ IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPj4+DQo+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBI b3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0IGlmDQo+Pj4geW91IGFsbG93IGFuIFNGRiB0byBt YWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdCB3aWxsIHVzZQ0KPj4+Zm9y DQo+Pj4gYSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4g dGhlbiB5b3UgYmV0dGVyIG1ha2UNCj4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0 aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8gcmVhY2gNCj4+PnRoZQ0KPj4+IG5leHQt bmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJs ZS4NCj4+Pg0KPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxt bjE5MjFAYXR0LmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2Ug Y2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbiByZWxldmFudA0KPj4+U0ZGcw0KPj4+ ID53aGVuIHRoZXkgImFycml2ZSIuDQo+Pj4gPg0KPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQNCj4+PiA+PihqZ3VpY2hhcikNCj4+PiA+PiBTZW50OiBG cmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47 IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ID4+DQo+Pj4gPj4gV2Vs bCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29k IHRoZQ0KPj4+ID4+cHJvcG9zYWwNCj4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWly ZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBzaW5nbGUgU0YNCj4+PndpdGhpbg0KPj4+ID4+dGhl DQo+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBp cyBubyB3YXkgdG8ga25vdyBhDQo+Pj4gPj5wcmlvcmkNCj4+PiA+PiB3aGljaCBTRkPCuXMgYSBn aXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuIHBvaW50IGluDQo+Pj50 aW1lLg0KPj4+ID4+DQo+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBl cm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+PiA+Pg0KPj4+ID4+ID5Sb24sIHRo aW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvciBwcm9ibGVtIHdpdGgg dGhlDQo+Pj4gPj55b3VyDQo+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gIChB bmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdA0KPj4+dW5kZXJzdGFuZA0KPj4+ID4+ID5pdC4p DQo+Pj4gPj4gPg0KPj4+ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRo ZSBsb2FkIGJhbGFuY2VyIGZvciB0aGUgbmV4dA0KPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRo YXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnMgdG8pLCBpbg0KPj4+ZXZlcnkN Cj4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4+PiA+PiA+DQo+ Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMs IHRoYXQgbWVhbnMgdGhhdA0KPj4+ID4+ZXZlcnkNCj4+PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8g YmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPj4+YmFsYW5jZXIu DQo+Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2 ZSwgYW5kIC8gb3Igc3RhdGVmdWwuDQo+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVy ZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwgZmxvdw0KPj4+ID4+ID5zZW5zaXRp dmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRvIG1lIHRvIGJlIGFuIGFjY2VwdGFi bGUNCj4+PiA+PiA+aW1wb3NpdGlvbi4NCj4+PiA+PiA+DQo+Pj4gPj4gPllvdXJzLA0KPj4+ID4+ ID5Kb2VsDQo+Pj4gPj4gPg0KPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBI YWxwZXJuIHdyb3RlOg0KPj4+ID4+ID4+IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0 IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcyB3b3JrDQo+Pj4gPj5zZW5zaWJseQ0KPj4+ID4+ID4+ IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuICBJIGV4cGVjdCB0aGF0IHRoZSBz ZXJ2aWNlDQo+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBT RkYgY2FwYWJpbGl0aWVzLCB3aWxsIGJlDQo+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0 YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8gYmUNCj4+PiA+PmRyaXZlbiBi eQ0KPj4+ID4+ID4+IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywg YW5kIGVuYWJsZQ0KPj4+c2VsZi1zZWxlY3Rpb24NCj4+PiA+PiA+PiBmcm9tIHRoZXNlLiAgSSBl eHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeSBkcml2ZS4NCj4+PiA+PiA+ Pg0KPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFu IGFyY2h0aWVjdHVyZSBkcml2ZW4NCj4+PmJ5DQo+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNh dGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gIEl0IGlzIGhhcmRlcg0KPj4+dG8NCj4+ PiA+PnNlZQ0KPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9u ZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+Pj4gPj4gZHluYW1pY2l0eQ0KPj4+ID4+ID4+IGluIHRo ZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhh dCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNpZGUNCj4+Pm9m DQo+Pj4gPj50aGUNCj4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlz IG5vdCBzb21ldGhpbmcgd2UgYXJlIHRhc2tlZCB0bw0KPj4+ID4+YWdyZWUNCj4+PiA+PiA+Pm9u Lg0KPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUg dG8gZG8gaXQgYSBjZXJ0YWluDQo+Pj53YXkuDQo+Pj4gPj5pdA0KPj4+ID4+ID4+IGlzIGp1c3Qg dGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4+ID4+ID4+DQo+ Pj4gPj4gPj4gWW91cnMsDQo+Pj4gPj4gPj4gSm9lbA0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gT24g Ny8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4+ID4+ID4+Pj4gRm9yIG1lLCB0 aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4+ PiA+Pm5lZWRzDQo+Pj4gPj4gPj4+PnRvDQo+Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0 ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4gYWNyb3NzDQo+Pj5kYXRhDQo+Pj4g Pj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2Ug ZW5vdWdoIGFuZA0KPj4+IGNvbXBsZXgNCj4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0 byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4+ZGlmZmljdWx0DQo+Pj4g Pj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+PiA+PiA+Pj4NCj4+PiA+PiA+Pj4g SSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIGR5bmFt aWMNCj4+PiByb3V0aW5nLA0KPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNo ZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZiB3aGljaCBhcmUNCj4+PiA+PmJpZ2dlcg0KPj4+ID4+ ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVt ZW50ZWQ/DQo+Pj4gPj4gPj4+DQo+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCBy ZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdCBpcyBhDQo+Pj5nb29kDQo+Pj4gPj4gPj4+ IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+Pj4gPj4gPj4+DQo+Pj4gPj4gPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+PiA+Pj4gRnJv bTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+ID4+ID4+PiBTZW50 OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+Pj4gPj4gPj4+IFRvOiBSb24gUGFy a2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsgSWFuDQo+Pj5TbWl0 aDsNCj4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ID4+ID4+Pg0K Pj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuICBBbmQgb25lIHRoYXQg SSB3b3VsZCBwcmVmZXIgd2UNCj4+PiA+PiA+Pj5hY3R1YWxseQ0KPj4+ID4+ID4+PiBkZWNpZGUs IHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGUgaW1wbGVtZW50YXRpb25z Lg0KPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUg Y29udHJvbCByZXF1aXJlbWVudHMNCj4+PmFuZA0KPj4+ID4+IHRoZQ0KPj4+ID4+ID4+PiBmdW5j dGlvbmFsaXR5IG9mIFNGRnMuDQo+Pj4gPj4gPj4+DQo+Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFt b3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcyB0aGF0DQo+Pj4gbmVl ZHMNCj4+PiA+PiB0bw0KPj4+ID4+ID4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50 YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4gYWNyb3NzDQo+Pj5kYXRhDQo+Pj4gPj4gPj4+IGNlbnRl cnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2ggYW5kDQo+ Pj5jb21wbGV4DQo+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRv IGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4+ZGlmZmljdWx0DQo+Pj4gPj4gPj4+IGFyY2hpdGVj dHVyZSB0byByZWFsaXplLg0KPj4+ID4+ID4+Pg0KPj4+ID4+ID4+PiBZb3VycywNCj4+PiA+PiA+ Pj4gSm9lbA0KPj4+ID4+ID4+Pg0KPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9u Lg0KPj4+ID4+ID4+Pg0KPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2Vy IHdyb3RlOg0KPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0 aGUgZW5kIHRvIGVuZCBzZWxlY3Rpb24gb2YNCj4+PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3Rh bmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZQ0KPj4+ID4+Y2xhc3NpZmll cikNCj4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIg YW5kIHN1YnNlcXVlbnRseSB0aGUNCj4+PiA+PlNGRnMpPw0KPj4+ID4+ID4+Pj4gU3VjaCBzZWxl Y3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4gICBBbmQNCj4+PnN1 cmVseSwNCj4+PiA+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90 IHJlbGVnYXRlZCB0bw0KPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+PiA+PiA+Pj4+ DQo+Pj4gPj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBw cm9hY2ggZXZlbiB0aG91Z2ggYQ0KPj4+ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAo Y2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMgbG9jYWwNCj4+PiA+PnNlbGVjdGlvbg0KPj4+ ID4+ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lv biBwb2ludHMuICAgVGhpcw0KPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBh biBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLiAgICBNeQ0KPj4+ID4+ID4+Pj4gcmF0aW9uYWxl IGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseSBkcml2ZW4gYnkNCj4+PiA+ PmluY3JlYXNlZA0KPj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBp ZCBhcHByb2FjaC4gICBXaXRoIGEgZ2xvYmFsDQo+Pj5wYXRoDQo+Pj4gPj5pZA0KPj4+ID4+ID4+ Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcg dG8gYWx0ZXINCj4+PnRoZQ0KPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVh Y2ggYW5kIGV2ZXJ5IGFmZmVjdGVkIGVuZC10by1lbmQNCj4+PnBhdGguDQo+Pj4gPj4gPj4+Pg0K Pj4+ID4+ID4+Pj4gUm9uDQo+Pj4gPj4gPj4+Pg0KPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+PiA+PiA+Pj4+IFtzZmMtYm91 bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+PiA+PiA+ Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNjoxNQ0KPj4+IFBNDQo+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb207IEku U21pdGhARjUuY29tOyBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+Pj4gPj4gPj4+PiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ID4+ID4+Pj4N Cj4+PiA+PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2Yg U0YxIG5lZWRpbmcgdG8NCj4+PiA+PmluZmx1ZW5jZQ0KPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlz IHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4aXQgZnJvbQ0KPj4+ ID4+ID4+Pj4gU0YxLg0KPj4+ID4+ID4+Pj4NCj4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwg aXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkNCj4+PiA+PiA+Pj4+ IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5 IGNob29zZQ0KPj4+dG8NCj4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRl bGl2ZXJ5Lg0KPj4+ID4+ID4+Pj4NCj4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+Pj4gPj4gPj4+ Pg0KPj4+ID4+ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20gd3Jv dGU6DQo+Pj4gPj4gPj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQg dGhhdCBzdWdnZXN0cyBhbnkgc29ydA0KPj4+b2YNCj4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZl ciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZSBwYXRoDQo+Pj4oYWxs DQo+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24u ICBJIGJlbGlldmUgdGhpcw0KPj4+bWVhbnMNCj4+PiA+PiA+Pj4+PiBlaXRoZXIgYXQgdGhlIGNs YXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXIgY2hvb3NlcyBhIFNGDQo+Pj4gPj5DaGFp bg0KPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZG LiAgSW4gYW55IGNhc2UsIHRoZQ0KPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBw cm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUgU0ZJKG4pDQo+Pj4gaXMNCj4+PiA+PiA+ Pj4+PiBkZXRlcm1pbmVkIGF0IHRoZSBTRkkobi0xKSBob3AuICBBY2NvcmRpbmcgdG8gdGhlIGRy YWZ0LCB0aGlzDQo+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJh bmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4+PiBvcHBvc2VkDQo+Pj4gPj4gdG8NCj4+PiA+PiA+ Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5j ZSBvZiB0aGUNCj4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+Pj4g Pj4gPj4+Pj4NCj4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoN Cj4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdv cmsgaXQgaXMgbmVjZXNzYXJ5DQo+Pj50bw0KPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNp ZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0bw0KPj4+ID4+ID4+ Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3Mg bmV0d29yaw0KPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiAgVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0 aGUgU0ZDIHJlc3VsdHMgaW4gdGhlDQo+Pj5jcmVhdGlvbg0KPj4+ID4+ID4+Pj4+PiBvZiBhIFNl cnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3IgZm9yd2FyZGluZw0KPj4+ ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNG UCBpcyB0aGUNCj4+PiA+PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMu DQo+Pj4gPj4gPj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBv cnRzIHJlY2xhc3NpZmljYXRpb24gKG9yIG5vbi1pbml0aWFsDQo+Pj4gPj4gPj4+Pj4+IGNsYXNz aWZpY2F0aW9uKSBhcyB3ZWxsLiAgQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsDQo+Pj4gPj4g Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBi eSBhDQo+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdp dGggYSBzZXJ2aWNlIGZ1bmN0aW9uLg0KPj4+ID4+ID4+Pj4+PiBSZWNsYXNzaWZpY2F0aW9uIG1h eSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldyBTRlAsIGFuDQo+Pj4gPj4gPj4+Pj4+ IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3IgYm90aC4gIFRoaXMgaXMgcmVm ZXJyZWQNCj4+PnRvDQo+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4+ID4+ID4+Pj4+ DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+ID4+Pj4+DQo+Pj4gPj4NCj4+Pg0K Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pi0tDQo+Pj4gPj4+Pj4+Pi0tDQo+Pj4gPj4g Pj4+Pj4tLQ0KPj4+ID4+ID4+Pj4+DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+ ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPj4+ID4+ID4+Pj4+ ICpUbzogKkpvZWwgSGFscGVybiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpv ZWwgTS4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+DQo+Pj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFs cGVybi5jb20+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0BzY2UuDQo+Pj4gPj4gY2FybGV0 b24uDQo+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4+PiA+PiA+ Pj4+Pg0KPj4+ID4+ID4+Pj4+DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVy c2RheSwgSnVseSAxMCwgMjAxNA0KPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gPj4gPj4+Pj4NCj4+ PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPj4+ID4+ID4+ Pj4+DQo+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBs b3ltZW50cyAoYW5kIHRoYXQgaXMNCj4+PndoYXQNCj4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZs b3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4+cHJlY29uY2VpdmVk DQo+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBi dXJkZW5lZCB3aXRoIHRoYXQNCj4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPj4+ID4+ID4+ Pj4+DQo+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21l IGRlZ3JlZSBvZiBhc3BpcmF0aW9uIHRvDQo+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHBy b3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZSBhcmNoaXRlY3R1cmUNCj4+Pi0NCj4+PiA+ PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcg dGhhdCBhbg0KPj4+YXJiaXRyYXJ5DQo+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFyIiwg eW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPj4+ID4+aW50ZW50aW9uYWwNCj4+ PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUg bGFzdGluZyBpbXBhY3RzDQo+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVy ZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LCBhZGRyZXNzDQo+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4g YWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPj4+ID4+ID4+ Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+Pj4gPj4gPj4+Pj4NCj4+PiA+ PiA+Pj4+Pg0KPj4+ID4+ID4+Pj4+DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+ Pj4+Pg0KPj4+ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tXSBTZW50Og0KPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLiBIYWxwZXJuOw0KPj4+ID4+ID4+Pj4+ IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBT ZXJ2aWNlDQo+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVl IHdpdGggbWUgYXQgYWxsIGluIHRoaXMgcmVnYXJkLg0KPj4+SQ0KPj4+ID4+YW0NCj4+PiA+PiA+ Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24g cHJvaGliaXQNCj4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlv bi4gSSBhbSBvYmplY3RpbmcgdG8gSHVhbmcncw0KPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkg bm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZSByZXF1aXJlZA0KPj4+ID4+ ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+ID4+ Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJp dCBzdWNoDQo+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVh IG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueQ0KPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBv ZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0byB0aGluayB0aGF0DQo+Pj4gPj50aGV5 DQo+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4+PiA+PiA+Pj4+Pg0KPj4+ ID4+ID4+Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRl bXB0aW5nIHRvIGtub3cNCj4+PndoYXQNCj4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95 YWJsZS4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+Pj4gPj4gPj4+ Pj4NCj4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+Pj4gPj4gPj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+IFdl IHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZg0KPj4+ bWlsbGlvbnMNCj4+PiA+PiA+Pj4+Pj4gb2YNCj4+PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZsb3dz IGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyDQo+Pj4gPj4gPj4+Pj4gZW52 aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbiB0aGUN Cj4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9t b3Jyb3cgeW91IGFyZSBvbmx5DQo+Pj4gPj4gZ29pbmcNCj4+PiA+PiA+Pj4+PiB0byBoYXZlIHNt YWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5IHNtYWxsDQo+Pj4gbnVt YmVycw0KPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPj4+ID4+ID4+Pj4+ Pg0KPj4+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBl dmVyIG5lZWQgbW9yZSB0aGFuDQo+Pj4gNjRLIg0KPj4+ID4+ID4+Pj4+PiBmb3INCj4+PiA+PiA+ Pj4+PiBjb21mb3J0Lg0KPj4+ID4+ID4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pg0KPj4+ID4+ID4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPj4+ ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhh bHBlcm4NCj4+PiA+PiA+Pj4+PiBbam1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+PiA+PiA+Pj4+Pj4g U2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzoNCj4+Pmh1YW5nQHNjZS5j YXJsZXRvbi5jYTsNCj4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj4+TG9hZA0KPj4+ID4+ID4+Pj4+PiBCYWxh bmNlcnMNCj4+PiA+PiA+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0 IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZQ0KPj4+YXJjaHRpZXR1cmUNCj4+PiA+PiA+ Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2Yg dGhlaXINCj4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBy ZXF1aXJlIHN1Y2ggYWJzdXJkIHVzZSBvZg0KPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBT aW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4+PiA+PiA+Pj4+Pj4gYXJj aGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZSBkb2VzDQo+ Pj5wZXJtaXQNCj4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+PiA+PiA+Pj4+Pj4NCj4+PiA+ PiA+Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1 cmUgcGVybWl0cw0KPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhl ciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5IHRoZQ0KPj4+d29yay4NCj4+PiA+PiA+Pj4+Pj4gSXQg aXNuJ3QuDQo+Pj4gPj4gPj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+Pj4gPj4g Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVh bmcgd3JvdGU6DQo+Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2 aWNlIGNoYWlucywgaXQgd2lsbCBtZWFuDQo+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhz LiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nIHRhYmxlIG9mIGENCj4+PiA+PiA+Pj4+ Pj4+IGNvcmUgcm91dGVyLg0KPj4+ID4+ID4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+ Pj4gPj4gPj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9l bCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxs b3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20gMQ0KPj4+ID4+ID4+Pj4+Pj4+IHNlcnZp Y2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlIHRoYXQNCj4+PiA+ PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlm IHRoZXkgY2hvb3NlDQo+Pj50bw0KPj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9j YWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkIHByb3Zpc2lvbg0KPj4+ID4+ID4+Pj4+Pj4+ IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+ IFlvdXJzLCBKb2VsDQo+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0 LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+Pj4gPj4gPj4+Pj4+Pj4+IFBh dWwsDQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRl bnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcCBzZXJ2aWNlDQo+Pj4gPj4gPj4+Pj4+ Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+ Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYg T2YNCj4+PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0IDM6MDMNCj4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25n ICpDYzoqIGptaEBqb2VsaGFscGVybi5jb207DQo+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZzsNCj4+PiA+PiA+Pj4+Pj4+Pj4gbWlrZWJp YW5jQGFvbC5jb20gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsDQo+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4g T3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUNCj4+PiA+ PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4+ID4+ID4+Pj4+IG1ha2UNCj4+PiA+PiA+ Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNl ZCB0byBkZXJpdmUNCj4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBh c3NvY2lhdGVkIHRyYW5zcG9ydC4NCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4g SXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvIHNpbXBseQ0K Pj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhh dCBwYWNrZXRzIG11c3QNCj4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBh dGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRo YXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzDQo+Pj4gPj4gPj4+Pj4+Pj4+ IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aCBpZGVudGlmaWVy DQo+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0 aGF0IGxvb2t1cCBjYW4gcmVzdWx0DQo+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUg KGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4+ID4+ID4+Pj4+Pj4+PiBob3Ao cykuDQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVj eSB5b25nDQo+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbSA8bWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tPj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4gPj4gPj4+ Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+ Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0 aGUNCj4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhl IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4g THVjeQ0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPj4+ID4+ID4+Pj4+Pj4+PiBPZipt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+PiAqU2VudDoqVGh1cnNkYXksDQo+Pj4gPj4g SnVseQ0KPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFv bC5jb20NCj4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpv ZWxoYWxwZXJuLmNvbQ0KPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+O3NmY0BpZXRmLm9yZw0KPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4g KlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywNCj4+PiA+PiA+Pj4+Pj4+Pj4gUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+ PiBSZS0sDQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJh ZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4+PiA+PiA+Pj4+Pj4+Pj4g aWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUNCj4+ PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25v d2xlZGdlIG9mIGV2ZXJ5DQo+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4+ID4+ID4+Pj4+ Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90 DQo+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBw b3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+Pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24g dGhlIHBpZWNlIG9mDQo+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+Pj4gPj4gPj4+Pj4g dGhhdCB3aWxsDQo+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRz OiB0aGF0IGlzIHRoZSBvbmUgcmVxdWlyZWQgdG8NCj4+PiA+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJl IGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCB0bw0KPj4+ID4+ ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJkaW5nDQo+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4+ID4+ ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+Pj4gPj4gPj4+ Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+ PiA+Pj4+Pj4+Pj4gTWVkDQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6 KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+Pj4gPj4gPj4+ Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlh bmNAYW9sLmNvbT4gKkVudm95w6kgOiptZXJjcmVkaSA5IGp1aWxsZXQNCj4+PiA+PiA+Pj4+Pj4+ Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPj4gPj4+Pj4+Pj4+ IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+Pj4gPj4gPj4+Pj4+ Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQgOipSZTogW3NmY10gU2VydmljZSBDaGFp bnMsDQo+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRo ZSBkaWZmZXJlbmNlIGJldHdlZW4gU0YgQ2hhaW4NCj4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIFNGDQo+ Pj4gPj4gPj4+Pj4gUGF0aD8NCj4+PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBjbGFyaWZ5aW5n IHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0bw0KPj4+ID4+ID4+Pj4+IHRob3Nl IG5vdA0KPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMg dGhhdCBldmVyeW9uZSBhZ3JlZXMgb24NCj4+PiA+PiA+Pj4+Pj4+Pj4gdGhlc2UgdGVybXMuDQo+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRo YXQgaXMgc3RpbGwgdW5jbGVhciBpcyB3aGV0aGVyIGl0IGlzDQo+Pj4gPj4gPj4+Pj4+Pj4+IHRo ZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdCB0aGUgSUQN Cj4+PiA+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4+PiA+PiA+Pj4+PiBzaG91bGQN Cj4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBp ZiB0aGlzIGRyYWZ0IHNpbXBseQ0KPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRo YXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8NCj4+PiA+PiA+Pj4+Pj4+Pj4g ZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvcg0K Pj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+Pj4gPj4g Pj4+Pj4gcGF0aCB0bw0KPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250 cm9sLXBsYW5lLg0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0 dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlDQo+Pj4gPj4gPj4+Pj4+ Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZSBv bmUNCj4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8g YXZvaWQgc29tZSB2ZW5kb3JzIG9ubHkNCj4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAg YW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+DQo+Pj4gPj4NCj4+Pg0KPj4+Pj4+Pj4+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+Pj4+Pj4+Pi0tDQo+Pj4gPj4+Pj4+Pi0tDQo+Pj4gPj4gPj4+Pj4tLQ0KPj4+ID4+ID4+ Pj4+DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4NCj4+PiA+PiA+ Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0K Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhh bHBlcm4uY29tPj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmc8c2ZjQGlldGYu b3JnDQo+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3Jn Pj4gKlNlbnQ6KlR1ZXNkYXksIEp1bHkNCj4+PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVj dDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4+ID4+ID4+Pj4+Pj4+ PiBCYWxhbmNlcnMNCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJl ZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGENCj4+PiA+PiA+ Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhl DQo+Pj4gcHJvcG9zZWQNCj4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFm dC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nDQo+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFn cmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUNCj4+PiA+ PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lw YXRlZCBpbiB0aGUgV0cNCj4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3Ru ZCBpdCB0aGUgd2F5IHRoZQ0KPj4+ID4+ID4+Pj4+IHdvcmtpbmcNCj4+PiA+PiA+Pj4+Pj4+Pj4g Z3JvdXAgaW50ZW5kcy4NCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdo YXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwNCj4+PiA+ PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0KPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtl ZXAgaW4gbWluZCB0aGF0IHdoYXQNCj4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlz IHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlIG5vdA0KPj4+ID4+ID4+Pj4+Pj4+ PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlDQo+ Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxk IGVuY29tcGFzcw0KPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5k IHBvbGljeSBmdW5jdGlvbnMsIHZpcnR1YWwNCj4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQg aW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXIgYXNwZWN0cy4NCj4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdo aWNoIGNsZWFybHkgbmVlZCB0bw0KPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2Vy IHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3ZlDQo+Pj4gPj4gPj4+Pj4+Pj4+ IHdoZXJlIHdlIGFyZQ0KPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4+ID4+ID4+Pj4+Pj4+ PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUgZG9pbmcu DQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBz ZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSQ0KPj4+ID4+ID4+Pj4+Pj4+PiB1bmRl cnN0YW5kDQo+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZp cnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdCBsZWFzdA0KPj4+ID4+ID4+ Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQg d2lsbA0KPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRo ZXJlIHByb2JhYmx5IGFyZSBtb3JlLg0KPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhl IGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIG9mIHRoZXNlLA0KPj4+ID4+ID4+Pj4+Pj4+ PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+Pj4gPj4gPj4+ Pj4gYmUgdXNlZA0KPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+Pj4gPj4gPj4+ Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBw cm92aWRlZCB0byB0aGUgZW5kIHVzZXIuDQo+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2 aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZA0KPj4+ID4+ID4+Pj4+ Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPj4+ID4+ID4+Pj4+IG1hcmtzDQo+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5z dGFuY2UNCj4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlz IGlzIGFuIGltcG9ydGFudCBzZXJ2aWNlDQo+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJl IGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzDQo+Pj4gPj4gPj4+Pj4+ Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlIGNoYWlu aW5nIGlzDQo+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1w YWN0IG9uIHRoZSBhcmNodGllY3R1cmUuDQo+Pj4gPj4gPj4+Pj4+Pj4+ICBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhDQo+Pj4gPj4gPj4+Pj4gc2Vydmlj ZQ0KPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5 aW5nIHBhY2tldC4NCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4gMikgVGhlcmUg aXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZSBjYW4gaGF2ZQ0KPj4+ID4+ ID4+Pj4+Pj4+PiB3aGF0DQo+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4+ID4+ID4+Pj4+Pj4+PiB0 byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUgcG9pbnQgb2YN Cj4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4+ID4+ID4+Pj4+IGZvciBhDQo+Pj4gPj4gPj4+ Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVy ZWQgYnkgYQ0KPj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+PiA+PiA+Pj4+Pj4+Pj4gdmly dHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvcg0KPj4+ ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBW UlJQLWxpa2UNCj4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRy ZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUg c2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIG1lY2hhbmlzbXMuIEl0DQo+Pj4gPj4gPj4+Pj4+ Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sIG1lY2hh bmlzbXMsDQo+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNj YWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2bQ0KPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9u LiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzDQo+Pj4gPj4gPj4+ Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXIgdGVy bWlub2xvZ3kNCj4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcyBub3QgbGVhZA0KPj4+ID4+ID4+Pj4+IHJl YWRlcnMgdG8NCj4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0K Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBs b2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZw0KPj4+ID4+ID4+Pj4+Pj4+PiBwYWNrZXQg cGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0IHRyYWZmaWMNCj4+PiA+ PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8gcmVx dWlyZSB0aGF0IGENCj4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBl YXIgYXQgb25seSBvbmUgcGxhY2UgaW4gdGhlDQo+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2Fz ZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kDQo+Pj4gPj4gPj4+Pj4+Pj4+IHRv DQo+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rpb24g b2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZw0KPj4+ID4+ID4+Pj4+ Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIg aXMgYQ0KPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhh dmUgYW5vdGhlciBvbmUuIFRodXMsIHRoZQ0KPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBl IDMgbG9hZCBiYWxhbmNpbmcNCj4+PiA+PiA+Pj4+PiBpcyB0bw0KPj4+ID4+ID4+Pj4+Pj4+PiBk aXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2luZ3VsYXIN Cj4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZl cmVudCBwbGFjZXMgaW4gdGhlDQo+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+Pj4gPj4gPj4+ Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1l YW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQg c2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGEgc2VxdWVuY2UNCj4+PiA+PiA+Pj4+Pj4+ Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNr ZXRzLg0KPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNv bWUgc3Vic2V0IG9mIHRyYWZmaWMgaXMNCj4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hh cmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kIGZpcmV3YWxsDQo+Pj4gPj4gPj4+Pj4+Pj4+ IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUN Cj4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5nIGFueSBvdGhl ciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+Pj4g VGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQQ0K Pj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1 ZW5jZSBvZiBsb2NhdGlvbnMNCj4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3Nl IGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJl ZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleSBtYXkgYmUNCj4+PiA+ PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3Nl ZCBhcyBwb3J0cyBvbg0KPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRp ZmZlcmVudCB3YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0KPj4+ID4+ID4+Pj4+Pj4+PiBtYXkgYmUg a25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZQ0KPj4+ ID4+ID4+Pj4+Pj4+PiB0cmFuc3BvcnQuDQo+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+ Pj4+PiAgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3Vw LCB3ZQ0KPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4+ID4+ID4+Pj4+Pj4+PiBhYmxl IHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNlDQo+ Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3 ZSBuZWVkIHRvIHRhbGsNCj4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBh dGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRz IGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZSBwYXRoIG1heQ0KPj4+ID4+ID4+Pj4+Pj4+PiBub3Qg YmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aA0KPj4+ ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4g aXRlbSAoMikgb24gbG9hZA0KPj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJl IGNhbiBiZSBkZWNpc2lvbnMgYW5kIGJlaGF2aW9ycyB3aGljaA0KPj4+ID4+ID4+Pj4+Pj4+PiBh cmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluIG11Y2gN Cj4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFO IGlzIGxhcmdlbHkNCj4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2Vl biBMQU5zLikgVGhlIG90aGVyIHByb3Zpc2lvbiB3ZQ0KPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlz DQo+Pj4gPj4gPj4+Pj4gdGhhdA0KPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNh biBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vzc2FyeS4NCj4+PiA+PiA+Pj4+Pj4+Pj4g VGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0KPj4+ID4+ ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9u IHBvaW50Lg0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0 aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0DQo+Pj4gPj4gPj4+Pj4+ Pj4+IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcg Z3JvdXAsDQo+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25h bCB3b3JkcyBhcmUgbmVlZGVkIHRvDQo+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0 aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsDQo+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdy b3VwDQo+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVh ciwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvDQo+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4+ID4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBzZmMNCj4+PiA+PiBtYWlsaW5nDQo+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qg c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ID4+ID4+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4+ID4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBzZmMNCj4+PiA+PiBtYWlsaW5nDQo+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+ ID4+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gc2ZjDQo+Pj4gPj4gbWFpbGluZw0KPj4+ID4+ID4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4+DQo+Pj4gPj4gPj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+PiA+PiBtYWls aW5nDQo+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+ID4+Pj4+Pj4NCj4+PiA+PiA+Pj4+Pj4NCj4+ PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gc2ZjDQo+Pj4gbWFpbGluZw0KPj4+ID4+IGxpc3QNCj4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYu b3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gPj4gPj4+ Pj4+DQo+Pj4gPj4gPj4+Pj4NCj4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+PiBtYWlsaW5nDQo+Pj4gPj4gbGlzdA0KPj4+ ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4+ID4+ID4+Pj4NCj4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHNmYyBtYWlsaW5nDQo+Pj4gPj4gbGlzdA0KPj4+ID4+ ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+Pj4gPj4gPj4+Pg0KPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gc2ZjIG1haWxpbmcNCj4+PiA+PiBsaXN0DQo+Pj4gPj4gPj4+ PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+PiA+PiA+Pj4+DQo+Pj4gPj4gPj4+DQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+ID4+IHNmYyBtYWls aW5nIGxpc3QNCj4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+PiA+PiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+ID4+DQo+Pj4gPj4gPg0KPj4+ID4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+ ID5zZmMgbWFpbGluZyBsaXN0DQo+Pj4gPj4gPnNmY0BpZXRmLm9yZw0KPj4+ID4+ID5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+DQo+Pj4gPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+Pj4gPj4gc2ZjQGlldGYub3JnDQo+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0Bp ZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMg bWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCg== From nobody Fri Jul 11 07:41: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 640681B2B93 for ; Fri, 11 Jul 2014 07:41:38 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 swqHi9iUhgVP for ; Fri, 11 Jul 2014 07:41:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4AE1B2B27 for ; Fri, 11 Jul 2014 07:41:34 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 02309C0604; Fri, 11 Jul 2014 16:41:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D4E1318004F; Fri, 11 Jul 2014 16:41:32 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 16:41:32 +0200 From: To: "Joel M. Halpern" , "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPnRLltSqAftugz0CPuFwsDNNeGpua7AZw Date: Fri, 11 Jul 2014 14:41:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933003172A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> In-Reply-To: <53BFF20E.60900@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.11.63919 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Lz_9qVTP1TNubFNk-EBPIp-FGfI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:41:38 -0000 Please see inline. >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: vendredi 11 juillet 2014 16:18 >=C0=A0: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; sfc@ietf.= org >Objet=A0: Re: [sfc] Service Chains, Paths, and Load Balancers > >Just to check, I am going to get pedantic. >We have SFF-X, is supporting (possibly via local load balancing) some >collection of local service function instances. >When packets on a given service function path (SFP-Y) arrive, [Med] s/When packets on a given service function path (SFP-Y) arrive/When p= ackets bound to a given Service Function Chain arrive From nobody Fri Jul 11 08:00: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 8C4351B2B6A for ; Fri, 11 Jul 2014 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36XYuo1huLRI for ; Fri, 11 Jul 2014 07:59:47 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EDA1B2B6C for ; Fri, 11 Jul 2014 07:59:46 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 2ebffb35.2b98dda08940.4629367.00-2430.12832288.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 14:59:46 +0000 (UTC) X-MXL-Hash: 53bffbe25ebf24d1-333f424b6963cfd9d6a0f2dad6efdb8889f24e12 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 3dbffb35.0.4629225.00-2338.12831848.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 14:59:35 +0000 (UTC) X-MXL-Hash: 53bffbd773fc8b8a-364b6e8389a50bc2303beb75f3566acf71a691b9 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BExUUF027191; Fri, 11 Jul 2014 10:59:31 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BExGir026954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 10:59:24 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 14:58:56 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 10:58:56 -0400 From: "NAPIERALA, MARIA H" To: "mohamed.boucadair@orange.com" , "Jim Guichard (jguichar)" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA Date: Fri, 11 Jul 2014 14:58:56 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=ABeY7kuGAAAA:8 ] X-AnalysisOut: [a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=2IWtr] X-AnalysisOut: [GXcZVZVxC2lXtAA:9 a=QEXdDO2ut3YA:10 a=oAXR_kdF8uMA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=chC_agHSu74A:10 a=U8Ie8E] X-AnalysisOut: [nqySEA:10 a=3XJ037QrwtgA:10 a=vOdJKjWQMmk2Rps_:21 a=nAVLs3] X-AnalysisOut: [XrqYw_KpMs:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IksuChMsiMlO0xYHIMRAAMrGCek Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 14:59:54 -0000 X-List-Received-Date: Fri, 11 Jul 2014 14:59:54 -0000 RGl0dG8uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b21dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPiBUbzogSmltIEd1 aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBS b24NCj4gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+IA0KPiBSZS0sDQo+IA0KPiBGb3Ig d2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0 aGUgZHJhZnQuDQo+IA0KPiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBp biBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwgZGlzdHJpYnV0ZWQNCj4gbW9kZWwgaXMgbm90 IGFsbG93ZWQuDQo+IA0KPiBTZXZlcmFsIHZvaWNlcyBpbiB0aGlzIHRocmVhZCBpbmRpY2F0ZWQg dGhhdCB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGYgc2hvdWxkIGJlDQo+IHByb3ZpZGVkIGluc3Rl YWQuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiA+RGXCoDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgZGUgSmltIEd1aWNoYXJkDQo+ID4oamd1aWNoYXIpDQo+ID5FbnZvecOpwqA6IHZlbmRyZWRp IDExIGp1aWxsZXQgMjAxNCAxNjoxOA0KPiA+w4DCoDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2Vs IE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPiA+T2JqZXTCoDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4NCj4gPk9r IGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0 aW9uYWxpdHkNCj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCog bmV4dC1ob3BzIHRvICphbGwqIFNGRuKAmXMNCj4gPndpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQg dGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhIGxvb2t1cA0KPiA+aW50byB0 aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5v dCBzdXJlIGhvdw0KPiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPiA+DQo+ID5P biA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+ IHdyb3RlOg0KPiA+DQo+ID4+QWJzb2x1dGVseS4NCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPiA+Pj4oamd1aWNoYXIpDQo+ID4+PiBTZW50 OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPiA+Pj4gVG86IE5BUElFUkFMQSwgTUFS SUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gPj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPiA+Pj4NCj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4g SG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgdGhhdCBpZg0KPiA+Pj4geW91IGFsbG93IGFuIFNGRiB0 byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdCB3aWxsIHVzZQ0KPiA+ Pj5mb3INCj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhl IGNoYWluIHRoZW4geW91IGJldHRlciBtYWtlDQo+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUg U0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8gcmVhY2gNCj4gPj4+dGhl DQo+ID4+PiBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBp biBkZWVwIHRyb3VibGUuDQo+ID4+Pg0KPiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElF UkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPiB3cm90ZToNCj4gPj4+DQo+ID4+PiA+ QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBp biByZWxldmFudA0KPiA+Pj5TRkZzDQo+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPiA+Pj4g Pg0KPiA+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ID4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJk DQo+ID4+PiA+PihqZ3VpY2hhcikNCj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAx NCA5OjI3IEFNDQo+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmcNCj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+Pj4gPj4NCj4gPj4+ID4+IFdlbGwgSSB0aGluayBp dCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGUNCj4gPj4+ ID4+cHJvcG9zYWwNCj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwg a25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZSBTRg0KPiA+Pj53aXRoaW4NCj4gPj4+ID4+dGhlDQo+ ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlz IG5vIHdheSB0byBrbm93IGENCj4gPj4+ID4+cHJpb3JpDQo+ID4+PiA+PiB3aGljaCBTRkPCuXMg YSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuIHBvaW50IGluDQo+ ID4+PnRpbWUuDQo+ID4+PiA+Pg0KPiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiB3cm90ZToNCj4gPj4+ID4+DQo+ ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFq b3IgcHJvYmxlbSB3aXRoIHRoZQ0KPiA+Pj4gPj55b3VyDQo+ID4+PiA+PiA+cHJvcG9zYWwgYXMg SSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90DQo+ID4+PnVu ZGVyc3RhbmQNCj4gPj4+ID4+ID5pdC4pDQo+ID4+PiA+PiA+DQo+ID4+PiA+PiA+VGhlIHByb3Bv c2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlIG5leHQN Cj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUg aXQgZGVsaXZlcnMgdG8pLCBpbg0KPiA+Pj5ldmVyeQ0KPiA+Pj4gPj4gPnNlcnZpY2UgY2hhaW4g dGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+ID4+PiA+PiA+DQo+ID4+PiA+PiA+U2luY2UgaXQgaGFz IHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucyB0aGF0DQo+ ID4+PiA+PmV2ZXJ5DQo+ID4+PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93 IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPiA+Pj5iYWxhbmNlci4NCj4gPj4+ID4+ID5J IGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9y IHN0YXRlZnVsLg0KPiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJl IHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwgZmxvdw0KPiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3Rh dGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4gYWNjZXB0YWJsZQ0KPiA+ Pj4gPj4gPmltcG9zaXRpb24uDQo+ID4+PiA+PiA+DQo+ID4+PiA+PiA+WW91cnMsDQo+ID4+PiA+ PiA+Sm9lbA0KPiA+Pj4gPj4gPg0KPiA+Pj4gPj4gPk9uIDcvMTAvMTQsIDEwOjA2IFBNLCBKb2Vs IE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcg aXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMgd29yaw0KPiA+Pj4gPj5zZW5zaWJseQ0K PiA+Pj4gPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gIEkgZXhwZWN0 IHRoYXQgdGhlIHNlcnZpY2UNCj4gPj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBw cm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcywgd2lsbCBiZQ0KPiA+Pj4gPj4gPj4gb3JjaGVz dHJhdGVkIGFuZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8gYmUN Cj4gPj4+ID4+ZHJpdmVuIGJ5DQo+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2Zm ZXJpbmdzIHRvIGNsaWVudHMsIGFuZCBlbmFibGUNCj4gPj4+c2VsZi1zZWxlY3Rpb24NCj4gPj4+ ID4+ID4+IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkg cG9saWN5IGRyaXZlLg0KPiA+Pj4gPj4gPj4NCj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8g bWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZSBkcml2ZW4NCj4gPj4+YnkN Cj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2Ug cGF0aHMuICBJdCBpcyBoYXJkZXINCj4gPj4+dG8NCj4gPj4+ID4+c2VlDQo+ID4+PiA+PiA+PiBo b3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cgbW9y ZQ0KPiA+Pj4gPj4gZHluYW1pY2l0eQ0KPiA+Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsgYmVoYXZp b3IuDQo+ID4+PiA+PiA+Pg0KPiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0 aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNpZGUNCj4gPj4+b2YNCj4gPj4+ID4+ dGhlDQo+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBz b21ldGhpbmcgd2UgYXJlIHRhc2tlZCB0bw0KPiA+Pj4gPj5hZ3JlZQ0KPiA+Pj4gPj4gPj5vbi4N Cj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUg dG8gZG8gaXQgYSBjZXJ0YWluDQo+ID4+PndheS4NCj4gPj4+ID4+aXQNCj4gPj4+ID4+ID4+IGlz IGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPiA+Pj4g Pj4gPj4NCj4gPj4+ID4+ID4+IFlvdXJzLA0KPiA+Pj4gPj4gPj4gSm9lbA0KPiA+Pj4gPj4gPj4N Cj4gPj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZToNCj4gPj4+ ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2Ug aW5zdGFuY2VzDQo+IHRoYXQNCj4gPj4+ID4+bmVlZHMNCj4gPj4+ID4+ID4+Pj50bw0KPiA+Pj4g Pj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5 IGV2ZW4gYWNyb3NzDQo+ID4+PmRhdGENCj4gPj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4g YWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQNCj4gPj4+IGNvbXBsZXgN Cj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBT RkYgc2VlbXMgbGlrZSBhDQo+ID4+PmRpZmZpY3VsdA0KPiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1 cmUgdG8gcmVhbGl6ZS4NCj4gPj4+ID4+ID4+Pg0KPiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFz IHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBkeW5hbWljDQo+ID4+PiByb3V0 aW5nLA0KPiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24s IG9yIEROUywgYWxsIG9mIHdoaWNoIGFyZQ0KPiA+Pj4gPj5iaWdnZXINCj4gPj4+ID4+ID4+PiBw cm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/ DQo+ID4+PiA+PiA+Pj4NCj4gPj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVh bGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQgaXMgYQ0KPiA+Pj5nb29kDQo+ID4+PiA+PiA+ Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4NCj4gPj4+ID4+ID4+Pg0KPiA+Pj4g Pj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ID4+ ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+ID4+PiA+ PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPiA+Pj4gPj4gPj4+ IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsg SWFuDQo+ID4+PlNtaXRoOw0KPiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+Pj4gPj4gPj4+ IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPiA+Pj4gPj4gPj4+DQo+ID4+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFs IGlzc3VlLiAgQW5kIG9uZSB0aGF0IEkgd291bGQgcHJlZmVyIHdlDQo+ID4+PiA+PiA+Pj5hY3R1 YWxseQ0KPiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFs bCBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2Vz IGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wgcmVxdWlyZW1lbnRzDQo+ID4+PmFu ZA0KPiA+Pj4gPj4gdGhlDQo+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPiA+ Pj4gPj4gPj4+DQo+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9u IGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4gPj4+IG5lZWRzDQo+ID4+PiA+PiB0bw0K PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50 aWFsbHkgZXZlbiBhY3Jvc3MNCj4gPj4+ZGF0YQ0KPiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGlu IGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2ggYW5kDQo+ID4+PmNvbXBs ZXgNCj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNo IFNGRiBzZWVtcyBsaWtlIGENCj4gPj4+ZGlmZmljdWx0DQo+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0 dXJlIHRvIHJlYWxpemUuDQo+ID4+PiA+PiA+Pj4NCj4gPj4+ID4+ID4+PiBZb3VycywNCj4gPj4+ ID4+ID4+PiBKb2VsDQo+ID4+PiA+PiA+Pj4NCj4gPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWly IHF1ZXN0aW9uLg0KPiA+Pj4gPj4gPj4+DQo+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQ TSwgUm9uIFBhcmtlciB3cm90ZToNCj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBt eSBpc3N1ZS4gICBJcyB0aGUgZW5kIHRvIGVuZCBzZWxlY3Rpb24gb2YNCj4gPj4+ID4+ID4+Pj4g KHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhl DQo+ID4+PiA+PmNsYXNzaWZpZXIpDQo+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhh cHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseSB0aGUNCj4gPj4+ID4+U0ZGcyk/ DQo+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xh c3NpZmljYXRpb24uICAgQW5kDQo+ID4+PnN1cmVseSwNCj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBh biBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+ID4+PiA+PiA+Pj4+ ICJpbXBsZW1lbnRhdGlvbiIuDQo+ID4+PiA+PiA+Pj4+DQo+ID4+PiA+PiA+Pj4+IE15IG93biB2 aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuIHRob3VnaA0KPiBh DQo+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25z IGFuZCBwZXJoYXBzIGxvY2FsDQo+ID4+PiA+PnNlbGVjdGlvbg0KPiA+Pj4gPj4gPj4+PiBwb2xp Y3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy4gICBU aGlzDQo+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVu ZCBwYXRoIGlkIGF0IGFsbC4gICAgTXkNCj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZv cmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseSBkcml2ZW4gYnkNCj4gPj4+ID4+aW5jcmVh c2VkDQo+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBw cm9hY2guICAgV2l0aCBhIGdsb2JhbA0KPiA+Pj5wYXRoDQo+ID4+PiA+PmlkDQo+ID4+PiA+PiA+ Pj4+IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5n IHRvIGFsdGVyDQo+ID4+PnRoZQ0KPiA+Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBm b3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQgZW5kLXRvLWVuZA0KPiA+Pj5wYXRoLg0KPiA+Pj4g Pj4gPj4+Pg0KPiA+Pj4gPj4gPj4+PiBSb24NCj4gPj4+ID4+ID4+Pj4NCj4gPj4+ID4+ID4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4gPj4+ ID4+ID4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJu IERpcmVjdA0KPiA+Pj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+IDY6MTUNCj4gPj4+IFBNDQo+ID4+PiA+PiA+Pj4+ IFRvOiBtaWtlYmlhbmNAYW9sLmNvbTsgSS5TbWl0aEBGNS5jb207IHNmY0BpZXRmLm9yZyBTdWJq ZWN0Og0KPiBSZToNCj4gPj4+ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4+ID4+ID4+Pj4NCj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0 aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0bw0KPiA+Pj4g Pj5pbmZsdWVuY2UNCj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRv IHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4aXQgZnJvbQ0KPiA+Pj4gPj4gPj4+PiBTRjEuDQo+ ID4+PiA+PiA+Pj4+DQo+ID4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0 aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkNCj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUg c28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4gY2hvb3Nl DQo+ID4+PnRvDQo+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2 ZXJ5Lg0KPiA+Pj4gPj4gPj4+Pg0KPiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPiA+Pj4gPj4g Pj4+Pg0KPiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNv bSB3cm90ZToNCj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNo IGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55IHNvcnQNCj4gPj4+b2YNCj4gPj4+ID4+ID4+Pj4+IGxp bWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlIHBh dGgNCj4gPj4+KGFsbA0KPiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZD IGluc3RhbnRpYXRpb24uICBJIGJlbGlldmUgdGhpcw0KPiA+Pj5tZWFucw0KPiA+Pj4gPj4gPj4+ Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyIGNob29z ZXMgYSBTRg0KPiA+Pj4gPj5DaGFpbg0KPiA+Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0 aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuICBJbiBhbnkgY2FzZSwgdGhlDQo+ID4+PiA+PiA+Pj4+ PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJl DQo+IFNGSShuKQ0KPiA+Pj4gaXMNCj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNG SShuLTEpIGhvcC4gIEFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoaXMNCj4gPj4+ID4+ID4+Pj4+ IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQIGFz DQo+ID4+PiBvcHBvc2VkDQo+ID4+PiA+PiB0bw0KPiA+Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5k IHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YgdGhlDQo+ID4+PiA+ PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+ID4+PiA+PiA+Pj4+Pg0KPiA+ Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+ID4+PiA+PiA+ Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMg bmVjZXNzYXJ5DQo+ID4+PnRvDQo+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBp bnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLCBhbmQgdG8NCj4gPj4+ID4+ID4+Pj4+ PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MgbmV0 d29yaw0KPiA+Pj4gPj4gPj4+Pj4+IGxvY2F0b3IuICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRo ZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4gPj4+Y3JlYXRpb24NCj4gPj4+ID4+ID4+Pj4+PiBvZiBh IFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3IgZm9yd2FyZGluZw0K PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3Jkcywg YW4gU0ZQIGlzIHRoZQ0KPiA+Pj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmlu ZWQgU0ZDLg0KPiA+Pj4gPj4gPj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRl Y3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3Igbm9uLWluaXRpYWwNCj4gPj4+ID4+ ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4g U0ZQLA0KPiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNh bGx5IHBlcmZvcm1lZCBieSBhDQo+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rp b24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24uDQo+ID4+PiA+PiA+Pj4+Pj4g UmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcgU0ZQ LCBhbg0KPiA+Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwg b3IgYm90aC4gIFRoaXMgaXMgcmVmZXJyZWQNCj4gPj4+dG8NCj4gPj4+ID4+ID4+Pj4+PiBhcyAi YnJhbmNoaW5nIi4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4gPj4gPj4+ Pj4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+Pg0KPiA+Pj4NCj4gPj4+Pj4+Pj4+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+Pj4+Pj4+Pj4+LS0NCj4gPj4+ID4+Pj4+Pj4tLQ0KPiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+ Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4gPj4gPj4+ ICpGcm9tOiAqSS5TbWl0aEBGNS5jb208SS5TbWl0aEBGNS5jb20+DQo+ID4+PiA+PiA+Pj4+PiAq VG86ICpKb2VsIEhhbHBlcm4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPixKb2Vs DQo+IE0uDQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4gPj4NCj4gPj4+DQo+ID4+Pj4+SGFscGVybjxq bWhAam9lbGhhbHBlcm4uY29tPixodWFuZ0BzY2UuY2FybGV0b24uY2E8aHVhbmdAc2NlLg0KPiA+ Pj4gPj4gY2FybGV0b24uDQo+ID4+PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYu b3JnPg0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pg0KPiA+ Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4gPj4+ID4+ID4+Pj4+ ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsg SSBhbSBkaXNhZ3JlZWluZy4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+PiBJZiB0aGUg cG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQgdGhhdCBpcw0KPiA+ Pj53aGF0DQo+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBv ZiBzZXJ2aWNlIGNoYWlucyBpcw0KPiA+Pj5wcmVjb25jZWl2ZWQNCj4gPj4+ID4+ID4+Pj4+IGFz IGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aCB0aGF0 DQo+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2Yg YXNwaXJhdGlvbg0KPiB0bw0KPiA+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0 ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZSBhcmNoaXRlY3R1cmUNCj4gPj4+LQ0KPiA+Pj4gPj4g Pj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRo YXQgYW4NCj4gPj4+YXJiaXRyYXJ5DQo+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIi LCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+ID4+PiA+PmludGVudGlvbmFs DQo+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0 IGhhdmUgbGFzdGluZyBpbXBhY3RzDQo+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0 LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksIGFkZHJlc3MNCj4gPj4+ID4+ID4+Pj4+ IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3QN Cj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+ID4+PiA+ PiA+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pg0K PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2Vs IEhhbHBlcm4gRGlyZWN0IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2VudDoNCj4gPj4+ ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsg Sm9lbCBNLg0KPiBIYWxwZXJuOw0KPiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNh OyBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UNCj4gPj4+ID4+ID4+Pj4+ IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwg aW4gdGhpcyByZWdhcmQuDQo+ID4+PkkNCj4gPj4+ID4+YW0NCj4gPj4+ID4+ID4+Pj4+IG5vdCBy ZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbiBwcm9oaWJpdA0K PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0g b2JqZWN0aW5nIHRvIEh1YW5nJ3MNCj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBh cyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPiByZXF1aXJlZA0KPiA+Pj4gPj4g Pj4+Pj4gdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLg0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9o aWJpdCBzdWNoDQo+ID4+PiA+PiA+Pj4+PiB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29k IGlkZWEgb3Igbm90IGRlcGVuZHMgdXBvbg0KPiBtYW55DQo+ID4+PiA+PiA+Pj4+PiBmYWN0b3Jz IG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8gdGhpbmsgdGhhdA0K PiA+Pj4gPj50aGV5DQo+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPiA+ Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVm dWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvIGtub3cNCj4gPj4+d2hhdA0KPiA+Pj4gPj4gPj4+ Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4gPj4gPj4+ Pj4gWW91cnMsIEpvZWwNCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0 LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4N Cj4gPj4+ID4+ID4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRl ZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZg0KPiA+Pj5taWxsaW9ucw0KPiA+Pj4gPj4g Pj4+Pj4+IG9mDQo+ID4+PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNz IG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyDQo+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9k YXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluIHRoZQ0KPiA+Pj4gPj4gPj4+ Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdSBh cmUNCj4gb25seQ0KPiA+Pj4gPj4gZ29pbmcNCj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwg bnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkgc21hbGwNCj4gPj4+IG51bWJl cnMNCj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPiA+Pj4gPj4gPj4+ Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25lIHdp bGwgZXZlciBuZWVkIG1vcmUgdGhhbg0KPiA+Pj4gNjRLIg0KPiA+Pj4gPj4gPj4+Pj4+IGZvcg0K PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4gPj4+ID4+ID4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+ DQo+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBGcm9tOiBzZmMNCj4gPj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJl aGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4u Y29tXQ0KPiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYg UE0gVG86DQo+ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYTsNCj4gPj4+ID4+ID4+Pj4+PiBzZmNA aWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+ ID4+PkxvYWQNCj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4+ID4+ID4+Pj4+Pg0KPiA+ Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRvIGRl cGxveSB0aGUNCj4gPj4+YXJjaHRpZXR1cmUNCj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkg YmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZiB0aGVpcg0KPiA+Pj4gPj4gPj4+ Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3Vy ZCB1c2UNCj4gb2YNCj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBu b3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFs IHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlIGRvZXMNCj4gPj4+cGVybWl0 DQo+ID4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4gPj4+ID4+ID4+Pj4+Pg0KPiA+Pj4gPj4g Pj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJl IHBlcm1pdHMNCj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhl ciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5IHRoZQ0KPiA+Pj53b3JrLg0KPiA+Pj4gPj4gPj4+Pj4+ IEl0IGlzbid0Lg0KPiA+Pj4gPj4gPj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwN Cj4gPj4+ID4+ID4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENo YW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1 cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsIG1lYW4NCj4gPj4+ID4+ID4+Pj4+Pj4g MTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZyB0YWJsZSBv ZiBhDQo+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+ Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+PiBP biAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+PiA+PiA+ Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCBm cm9tIDENCj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBw YXRocy4gSSB3b3VsZCBob3BlIHRoYXQNCj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUg cHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleSBjaG9vc2UNCj4gPj4+dG8NCj4g Pj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5k IGluIHN0ZWFkDQo+IHByb3Zpc2lvbg0KPiA+Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNl IHBhdGhzLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2Vs DQo+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQ TSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50 aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4gc2VydmljZQ0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g Kk9uIEJlaGFsZiBPZg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNl bnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0g KlRvOiogTHVjeSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVybi5jb207DQo+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5 OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnC uWQNCj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hh bmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+IGRlcml2ZQ0KPiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3Bv cnQuDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0 aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8gc2ltcGx5DQo+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cyBt dXN0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRp ZmllciwgdGhlIGV4YWN0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9w bGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uIHRoaXMNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJl YWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4gaWRlbnRpZmllcg0K PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0 aGF0IGxvb2t1cCBjYW4NCj4gcmVzdWx0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3Ig bW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaG9wKHMpLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0K PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBh dCAxMTowNCBBTSwgTHVjeSB5b25nDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3 ZWkuY29tDQo+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KPiA+Pj4gPj4gPj4+Pj4+ Pj4+IHdyb3RlOg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNo b3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLg0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSpPbiBCZWhhbGYNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPiA+Pj4gPj4gSnVseQ0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0K PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+O2ptaEBqb2VsaGFs cGVybi5jb20NCj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ O3NmY0BpZXRmLm9yZw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAq U3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IFJlLSwNCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBt ZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRv IGRlcml2ZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8g aGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4gZXZlcnkNCj4gPj4+ID4+ID4+Pj4+IGF2YWls YWJsZSBTRkMNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBT RkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZp ZWQNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50 IGNvbnRleHRzLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZv cndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2YNCj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZSBy ZXF1aXJlZA0KPiB0bw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hh aW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgdG8NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bmZlciBmb3J3YXJkaW5nDQo+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+ PiA+Pj4+Pj4+Pj4gTWVkDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiAq RGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGEgcGFydA0KPiA+Pj4g Pj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4ganVpbGxldA0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3Jn DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBJcyBhbnlv bmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRg0KPiBDaGFpbg0K PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4gPj4+ID4+ ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBp dCdzIGNsZWFyIHRvDQo+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4gPj4+ID4+ID4+Pj4+Pj4+ PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZSBhZ3JlZXMg b24NCj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5j bGVhciBpcyB3aGV0aGVyIGl0IGlzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0 aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRA0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+ID4+PiA+PiA+Pj4+PiBzaG91bGQNCj4gPj4+ID4+ ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMg ZHJhZnQgc2ltcGx5DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFt YmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlj dGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbiBvcg0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4gPj4+ID4+ ID4+Pj4+IHBhdGggdG8NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBj b250cm9sLXBsYW5lLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYg dGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2ZQ0KPiA+Pj4g Pj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAo b3IgbWFrZQ0KPiBvbmUNCj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlZCBhbmQgdGhlIG90aGVy IG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMNCj4gb25seQ0KPiA+Pj4gPj4gPj4+Pj4+ Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4NCj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pg0KPiA+Pj4g Pj4NCj4gPj4+DQo+ID4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pi0tDQo+ID4+PiA+ Pj4+Pj4+LS0NCj4gPj4+ID4+ID4+Pj4+LS0NCj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+ Pg0KPiA+Pj4gPj4gPj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiAq RnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJu LmNvbT4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3Jn DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+ PiAqU2VudDoqVHVlc2RheSwNCj4gSnVseQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIwMTQgKlN1 YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4+ID4+ID4+ Pj4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFuc3dlciBh DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1h ZGUgYWJvdXQgdGhlDQo+ID4+PiBwcm9wb3NlZA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBh cmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQgd29ya2luZw0KPiA+Pj4gPj4g Pj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8g aW1wcm92ZQ0KPiB0aGUNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVy cyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluIHRoZQ0KPiBXRw0KPiA+Pj4gPj4gPj4+Pj4+ Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4gPj4+ID4+ID4+ Pj4+IHdvcmtpbmcNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdp bGwgdHJ5IHRvIGV4cGxhaW4gbXkgcGVyc29uYWwNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBh bmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0 IHdoYXQNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxh bmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUNCj4gbm90DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1w dGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZQ0KPiA+Pj4gPj4g Pj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29t cGFzcw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9s aWN5IGZ1bmN0aW9ucywgdmlydHVhbA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGlt YWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+IGFzcGVjdHMuDQo+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGlu Z3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhl IGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aCBhYm92ZQ0KPiA+Pj4gPj4g Pj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsg d2UgYXJlIGRvaW5nLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4g b3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJDQo+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUg YXJlIGF0IGxlYXN0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhh dCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZSBtb3JlLg0KPiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBh bGwgb2YgdGhlc2UsDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQg YW55IHBhcnRpY3VsYXIga2luZA0KPiA+Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5k IHVzZXIuDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0 IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMg dGhlbSAob3INCj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwg b3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZQ0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBp bXBvcnRhbnQgc2VydmljZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUg dG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4g YmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4gY2hhaW5p bmcgaXMNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGlt cGFjdCBvbiB0aGUgYXJjaHRpZWN0dXJlLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ICBGcm9tIGFuIGFy Y2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhDQo+ID4+PiA+PiA+Pj4+PiBz ZXJ2aWNlDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUg dW5kZXJseWluZyBwYWNrZXQuDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+ PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbiBo YXZlDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBh IHNpbmdsZSBwb2ludCBvZg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4gPj4+ID4+ID4+ Pj4+IGZvciBhDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwg YnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhDQo+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9u IG9mDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9z c2libHkgaW5jbHVkaW5nIG9uZSBvcg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBi YWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcw0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBs YW5lIG1lY2hhbmlzbXMuDQo+IEl0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wgbWVjaGFuaXNtcywNCj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0 LCBhbmQgdm0NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0 dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFy Z2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91ciB0ZXJtaW5vbG9neQ0KPiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8N Cj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2Fk IGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBw YXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYw0KPiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJl cXVpcmUgdGhhdCBhDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBh cHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gdGhlDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29y ay4NCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJz ZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSQ0KPiB0ZW5kDQo+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdG8NCj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFp bmluZw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4g Tm90IGJlY2F1c2UgY2x1c3RlciBpcyBhDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBC dXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLA0KPiB0aGUNCj4gPj4+ ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4gPj4+ID4+ID4+ Pj4+IGlzIHRvDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9m IHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1 c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgaW4gdGhlDQo+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+ Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJv dXQNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNl cnZpY2UgY2hhaW4gaXMgYQ0KPiBzZXF1ZW5jZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2lj YWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4NCj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0 IG9mIHRyYWZmaWMgaXMNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywg Y29udGVudCBpbnNwZWN0aW9uLCBhbmQgZmlyZXdhbGwNCj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGls ZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIGNhY2hlDQo+ID4+ PiA+PiA+Pj4+PiB3aXRob3V0DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVy IHNlcnZpY2UgZnVuY3Rpb25zLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4g QQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBh IHNlcXVlbmNlIG9mIGxvY2F0aW9ucw0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3Jr LiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleSBtYXkg YmUNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkg YmUgYWRkcmVzc2VkIGFzIHBvcnRzDQo+IG9uDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBU aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2NhdGlvbnMNCj4gPj4+ID4+ ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1 Y3R1cmUgYW5kDQo+IHRoZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+PiAgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBv ZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLA0KPiB3ZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+PiBu ZWVkIHRvIGJlDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdo IGxldmVsIGFic3RyYWN0aW9uLCB0aGUgc2VydmljZQ0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWlu LCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvIHRhbGsNCj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFr ZSBpbiB0aGUNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJi dXQgdGhlIHdob2xlIHBhdGgNCj4gbWF5DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3du IGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGgNCj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAo Mikgb24gbG9hZA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2Fu IGJlIGRlY2lzaW9ucyBhbmQgYmVoYXZpb3JzDQo+IHdoaWNoDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4g YXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbiBtdWNo DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEg TEFOIGlzIGxhcmdlbHkNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBi ZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXIgcHJvdmlzaW9uDQo+IHdlDQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbWFrZSBpcw0KPiA+Pj4gPj4gPj4+Pj4gdGhhdA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xh c3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4gbmVjZXNzYXJ5Lg0K PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFp bi4gQmFzZWQgb24NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQg dGhlIHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFm dGVyLiBJZiBpdA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlz IGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcNCj4gZ3JvdXAsDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4g d2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQgdG8NCj4g Pj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdy ZWUgd2l0aCB0aGUNCj4gaW50ZW50LA0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBv ZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJl IHdoYXQgdG8NCj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4+ID4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzZmMNCj4gPj4+ID4+IG1haWxpbmcNCj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0 IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+ID4+ID4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2ZjDQo+ID4+PiA+PiBtYWlsaW5nDQo+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4+ID4+ID4+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYw0KPiA+Pj4gPj4g bWFpbGluZw0KPiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+PiA+ PiA+Pj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIHNmYw0KPiA+Pj4gPj4gbWFpbGluZw0KPiA+Pj4gPj4gPj4+Pj4+ PiBsaXN0IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+Pj4gPj4gPj4+Pj4+DQo+ID4+PiA+PiA+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ID4+ PiBtYWlsaW5nDQo+ID4+PiA+PiBsaXN0DQo+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+PiA+PiA+Pj4+Pj4N Cj4gPj4+ID4+ID4+Pj4+DQo+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4gPj4+IG1haWxpbmcNCj4gPj4+ID4+IGxpc3QN Cj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiA+Pj4gPj4gPj4+Pg0KPiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4gbWFpbGluZw0KPiA+Pj4g Pj4gbGlzdA0KPiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4+ID4+ID4+Pj4NCj4gPj4+ID4+ID4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+IG1haWxpbmcN Cj4gPj4+ID4+IGxpc3QNCj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+PiA+PiA+Pj4+DQo+ID4+PiA+PiA+Pj4N Cj4gPj4+ID4+ID4+DQo+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+Pj4gPj4g Pj4gc2ZjQGlldGYub3JnDQo+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiA+Pj4gPj4gPj4NCj4gPj4+ID4+ID4NCj4gPj4+ID4+ID5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gPj4gPnNmYyBt YWlsaW5nIGxpc3QNCj4gPj4+ID4+ID5zZmNAaWV0Zi5vcmcNCj4gPj4+ID4+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+Pj4gPj4NCj4gPj4+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiA+PiBzZmMg bWFpbGluZyBsaXN0DQo+ID4+PiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHNmYyBtYWlsaW5nIGxp c3QNCj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPnNmY0BpZXRmLm9yZw0KPiA+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri Jul 11 08:05: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 483A21B2911 for ; Fri, 11 Jul 2014 08:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL112zMzpD2P for ; Fri, 11 Jul 2014 08:05:28 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5682A1B2921 for ; Fri, 11 Jul 2014 08:04:38 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 60dffb35.2b993f097940.4633439.00-2468.12844011.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 15:04:38 +0000 (UTC) X-MXL-Hash: 53bffd066cfd2102-1947a8d903060ebf025437672ba0095a5abb9931 Received: from unknown [144.160.229.24] by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with SMTP id bfcffb35.0.4631563.00-2091.12843676.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 15:04:28 +0000 (UTC) X-MXL-Hash: 53bffcfc4d9bd0e1-208d728eae4e76955477a904ec137700a5257e85 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BEvE1S024439; Fri, 11 Jul 2014 10:57:15 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BEv669024343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 10:57:10 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 14:56:50 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 10:56:50 -0400 From: "NAPIERALA, MARIA H" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEWlgP//vtHAAAjq1gAAB1zggA== Date: Fri, 11 Jul 2014 14:56:50 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD3B@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> In-Reply-To: <53BFF20E.60900@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=dr62ZZATblG3QCPcl7AA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/iAVcebYCkrVZXUSj6Rx_xbFAU3c Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:05:31 -0000 =20 > Just to check, I am going to get pedantic. NP > We have SFF-X, is supporting (possibly via local load balancing) some > collection of local service function instances. > When packets on a given service function path (SFP-Y) arrive, they are > processed by theose service functions, and SFF-X then has to forward the > packets (with suitable transport) to a next SFF, who may locally balance > among his service function instances. Similar comment to Med's (I will use his expression as it does reflect it c= orrectly): "if packets bound to a given Service Function Chain arrive", etc= . This applies to the text below also. > For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z. >=20 > We consider first the state at time T0 when a packet arrives as SFF-X on > SFP-Y with no prior special state in SFF-X (obviously, there is some > state about SFP-Y, as we do not want policy lookups at packet handling > times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2. > If I understand your request, you want SFF-X to pick one of those two > SFF, say SFF-Z1. =20 Yes. > And send all the packets for SFP-Y on to SFF-Z1. Even This could be per-destination load balancing, for example, to get a better = load distribution. > if SFF-Z3 is added to the network, all packets for all flows using SFP-Y > at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only Existing flows go to SFF-Z1. New flows may go to SFF-Z3. > time SFF-X would change that is if discovered or was told that SFF-Z1 > was down or unreachable. In that case, it would pick a new one from > among the known choices. Yes. > Maria, if that is what you would like, I believe that either is > currently allowed by the architecture or can easily be added. And I am > happy to do so. I believe we can describe that in the resilience and > failure recovery section that we need to add. OK.=20 > But I want to be really sure that is what you want. I don't think that > meets Ron's request. >=20 > Yours, > Joel >=20 > On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: > > Joel, > > > >> Hmm. Would it meet your goals Maria if all packets that arrived at > >> SFF-X with SFP-Y were (after local SF processing) forwarded to some > >> specific SFF-Z? Where SFF-Z was selected when the first packet with > >> SFP-Y arrived at SFF-X? > > > > Yes. > >> > >> While that is more easily met, that does not seem likely to produce th= e > >> scale flexibility you asked for. And if SFF-X may forward packets wit= h > > > > Why not? > > > >> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the > >> capability to ensure that a given flow continues to go to the same nex= t > >> SFF even when SFF-Z3 is added to the mix. > > > > Precisely. > > > > > >> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: > >>> Absolutely not. Service chains can be instantiated only in relevant S= FFs > >> when they "arrive". > >>> > >> ... > > From nobody Fri Jul 11 08:13: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 3161D1B2B17 for ; Fri, 11 Jul 2014 08:13:25 -0700 (PDT) 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 yUm56_mDGd3V for ; Fri, 11 Jul 2014 08:13:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8B21B2B06 for ; Fri, 11 Jul 2014 08:13:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6CE4724066E; Fri, 11 Jul 2014 08:13:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3AB4C240669; Fri, 11 Jul 2014 08:13:22 -0700 (PDT) Message-ID: <53BFFF12.4060700@joelhalpern.com> Date: Fri, 11 Jul 2014 11:13:22 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD3B@MISOUT7MSGUSRCF.ITServices.sbc.co m> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD3B@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dYFxtcDJME2208Wy4T63Z00CZLQ Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:13:25 -0000 In order to allow for SFFs which do not have ability to resolve an SFC to the set of next SFFs, we need to do one level of mapping from the abstract SFC to the more resolved SFP. In addition to allowing for a range of SFF deployments, this also allows for a degree of centralized traffic control to be used in conjunction with the distributed behavior you are requesting. If we only used an identifier of the service chain in the packet we would be prohibiting that important alternative deployment. The SFF still has the ability to map the SFP to the transport information, which allows it to have a collection of next SFFs which it uses for redundancy or load balancing. If we structure it this way, we can allow the SFF to have a collection of next-SFFs for a given SFP. And we can allow it to pick one, or to balance as it chooses subject to the constraint that a given flow must continue to use a given next-SFF as long as that is available. If we write it that way, the architecture will not mandate full load balancing. It will allow that a given SFF uses a single next-SFF hope. Or that it does whatever degree of load balncing it chooses among the set of next-SFF it is aware of for use with a given service path (SFP). Whether that knowledge of next-SFFs is static or dynamic, provisioned or discovered, is outside the scope of the architecture, and probably outside the scope of any solution this WG develops. Can you live with this compromise? (If so, and if the WG is comfortable with this, Carlos and I can add this to the slides for presentation in Toronto, and then add text to the next version of the document.) Yours, Joel On 7/11/14, 10:56 AM, NAPIERALA, MARIA H wrote: > >> Just to check, I am going to get pedantic. > > NP > >> We have SFF-X, is supporting (possibly via local load balancing) some >> collection of local service function instances. >> When packets on a given service function path (SFP-Y) arrive, they are >> processed by theose service functions, and SFF-X then has to forward the >> packets (with suitable transport) to a next SFF, who may locally balance >> among his service function instances. > > Similar comment to Med's (I will use his expression as it does reflect it correctly): "if packets bound to a given Service Function Chain arrive", etc. > This applies to the text below also. > >> For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z. >> >> We consider first the state at time T0 when a packet arrives as SFF-X on >> SFP-Y with no prior special state in SFF-X (obviously, there is some >> state about SFP-Y, as we do not want policy lookups at packet handling >> times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2. >> If I understand your request, you want SFF-X to pick one of those two >> SFF, say SFF-Z1. > > Yes. > >> And send all the packets for SFP-Y on to SFF-Z1. Even > > This could be per-destination load balancing, for example, to get a better load distribution. > >> if SFF-Z3 is added to the network, all packets for all flows using SFP-Y >> at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only > > Existing flows go to SFF-Z1. New flows may go to SFF-Z3. > >> time SFF-X would change that is if discovered or was told that SFF-Z1 >> was down or unreachable. In that case, it would pick a new one from >> among the known choices. > > Yes. > >> Maria, if that is what you would like, I believe that either is >> currently allowed by the architecture or can easily be added. And I am >> happy to do so. I believe we can describe that in the resilience and >> failure recovery section that we need to add. > > OK. > >> But I want to be really sure that is what you want. I don't think that >> meets Ron's request. >> >> Yours, >> Joel >> >> On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: >>> Joel, >>> >>>> Hmm. Would it meet your goals Maria if all packets that arrived at >>>> SFF-X with SFP-Y were (after local SF processing) forwarded to some >>>> specific SFF-Z? Where SFF-Z was selected when the first packet with >>>> SFP-Y arrived at SFF-X? >>> >>> Yes. >>>> >>>> While that is more easily met, that does not seem likely to produce the >>>> scale flexibility you asked for. And if SFF-X may forward packets with >>> >>> Why not? >>> >>>> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the >>>> capability to ensure that a given flow continues to go to the same next >>>> SFF even when SFF-Z3 is added to the mix. >>> >>> Precisely. >>> >>> >>>> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: >>>>> Absolutely not. Service chains can be instantiated only in relevant SFFs >>>> when they "arrive". >>>>> >>>> ... >>> From nobody Fri Jul 11 08:14: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 038E41B2B62 for ; Fri, 11 Jul 2014 08:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 YORUvVKGKapw for ; Fri, 11 Jul 2014 08:14:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509D61B2B44 for ; Fri, 11 Jul 2014 08:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48608; q=dns/txt; s=iport; t=1405091696; x=1406301296; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y2k5BrrAqpH6n+3E69NduvvPgtl3LJAFoQp006nBsug=; b=dWj6KVSiHN9ASyA8T9dRg8CyNMAPIglvMejuRtU3kSSzwzNQL1qPKwkB 0Ytgq7PJoUBb08PvHhTZ2AvYmNRMjO1uD8eosXXp3zcfhcZZsZeQgdXYY M2Y78aJRZTWR6zO6WXGxoJ+gsqKSdqFlpU+Cl7paqueZSQcVilv6baAYn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJD+v1OtJV2S/2dsb2JhbABPCoMOUlqCcawHkXgKh0IBGXIWdYQDAQEBBAEBARcBCBExCQIVBAIBCBEBAwEBAQICIwMCAgIlCxQBAgYIAgQBEhuIEwMRDa05mHwTBIEsiFGDIIFQBSQIECICAgKCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="339155108" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2014 15:14:53 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BFEmke026501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 15:14:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 10:14:48 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Ron Parker" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4A= Date: Fri, 11 Jul 2014 15:14:47 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: <53C37A96154466429DC7D77CC400C397@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-rf_Pcy6d3hfUf_XhKsOWA_5egI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:14:56 -0000 SeKAmW0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNl IHBhdGggaWRlbnRpZmllcg0KcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1o b3BzIG9yIHdoeSBjYWxsaW5nIGl0IGEgc2VydmljZQ0KY2hhaW4gaWRlbnRpZmllciBtYWtlcyBh bnkgZGlmZmVyZW5jZT8NCg0KT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQoNCj5EaXR0by4NCj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQo+PiBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsg TkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbg0KPj4gUGFya2VyOyBzZmNA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4gDQo+PiBSZS0sDQo+PiANCj4+IEZvciB3aGF0IEkgY2FuIHNh eSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZSBkcmFmdC4NCj4+ IA0KPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEg aGludCB0aGF0IHRoZSBmdWxsDQo+PmRpc3RyaWJ1dGVkDQo+PiBtb2RlbCBpcyBub3QgYWxsb3dl ZC4NCj4+IA0KPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQg dGhlIHNlcnZpY2UgY2hhaW4gaXRzZWxmDQo+PnNob3VsZCBiZQ0KPj4gcHJvdmlkZWQgaW5zdGVh ZC4NCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWVkDQo+PiANCj4+ID4tLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4+ID5EZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBs YSBwYXJ0IGRlIEppbSBHdWljaGFyZA0KPj4gPihqZ3VpY2hhcikNCj4+ID5FbnZvecOpIDogdmVu ZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4DQo+PiA+w4AgOiBOQVBJRVJBTEEsIE1BUklBIEg7 IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+PiA+T2JqZXQgOiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4N Cj4+ID5PayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhp cyBmdW5jdGlvbmFsaXR5DQo+PiA+cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0 ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZG4oCZcw0KPj4gPndpdGhpbiB0aGUgU0ZDIGRv bWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhDQo+Pmxvb2t1 cA0KPj4gPmludG8gdGhvc2UgbmV4dC1ob3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBj aGFpbiwgSSBhbSBub3Qgc3VyZQ0KPj5ob3cNCj4+ID50aGUgYXJjaGl0ZWN0dXJlIHByZXZlbnRz IHRoYXQ/DQo+PiA+DQo+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEg SCIgPG1uMTkyMUBhdHQuY29tPiB3cm90ZToNCj4+ID4NCj4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ DQo+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPj4g Pj4+KGpndWljaGFyKQ0KPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFN DQo+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFy a2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pg0KPj4gPj4+IFRoZW4gSSBtaXN1 bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4+ dGhhdCBpZg0KPj4gPj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRv IHdoaWNoIHJlbW90ZSBTRkYgaXQgd2lsbA0KPj51c2UNCj4+ID4+PmZvcg0KPj4gPj4+IGEgZ2l2 ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91IGJl dHRlcg0KPj5tYWtlDQo+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5l Y2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvDQo+PnJlYWNoDQo+PiA+Pj50aGUNCj4+ID4+PiBu ZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRy b3VibGUuDQo+PiA+Pj4NCj4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBN QVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+PiB3cm90ZToNCj4+ID4+Pg0KPj4gPj4+ID5BYnNv bHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluIHJl bGV2YW50DQo+PiA+Pj5TRkZzDQo+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4NCj4+ID4+PiA+ DQo+PiA+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+PiA+PiBGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFy ZA0KPj4gPj4+ID4+KGpndWljaGFyKQ0KPj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwg MjAxNCA5OjI3IEFNDQo+PiA+Pj4gPj4gVG86IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsg c2ZjQGlldGYub3JnDQo+PiA+Pj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiBXZWxsIEkg dGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhl DQo+PiA+Pj4gPj5wcm9wb3NhbA0KPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1 aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZSBTRg0KPj4gPj4+d2l0aGluDQo+PiA+ Pj4gPj50aGUNCj4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUgU0ZG IGFzIHRoZXJlIGlzIG5vIHdheSB0byBrbm93DQo+PmENCj4+ID4+PiA+PnByaW9yaQ0KPj4gPj4+ ID4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkg Z2l2ZW4gcG9pbnQNCj4+aW4NCj4+ID4+PnRpbWUuDQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiBPbiA3 LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+ DQo+PiB3cm90ZToNCj4+ID4+PiA+Pg0KPj4gPj4+ID4+ID5Sb24sIHRoaW5raW5nIGFib3V0IHRo aXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvciBwcm9ibGVtIHdpdGgNCj4+dGhlDQo+PiA+Pj4g Pj55b3VyDQo+PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gIChBbmQgSSBy ZWFkaWx5IGFkbWl0IEkgbWF5IG5vdA0KPj4gPj4+dW5kZXJzdGFuZA0KPj4gPj4+ID4+ID5pdC4p DQo+PiA+Pj4gPj4gPg0KPj4gPj4+ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZl IGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvciB0aGUNCj4+bmV4dA0KPj4gPj4+ID4+ID5zZXJ2aWNl IGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnMgdG8pLA0K Pj5pbg0KPj4gPj4+ZXZlcnkNCj4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhy b3VnaCBpdC4NCj4+ID4+PiA+PiA+DQo+PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxl IHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnMNCj4+dGhhdA0KPj4gPj4+ID4+ ZXZlcnkNCj4+ID4+PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNp dGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPj4gPj4+YmFsYW5jZXIuDQo+PiA+Pj4gPj4gPkkgYWh2 ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3INCj4+ c3RhdGVmdWwuDQo+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJl IHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwNCj4+Zmxvdw0KPj4gPj4+ID4+ID5zZW5zaXRpdmUs IHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRvIG1lIHRvIGJlIGFuDQo+PmFjY2VwdGFi bGUNCj4+ID4+PiA+PiA+aW1wb3NpdGlvbi4NCj4+ID4+PiA+PiA+DQo+PiA+Pj4gPj4gPllvdXJz LA0KPj4gPj4+ID4+ID5Kb2VsDQo+PiA+Pj4gPj4gPg0KPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAx MDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkg cGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcyB3b3JrDQo+PiA+ Pj4gPj5zZW5zaWJseQ0KPj4gPj4+ID4+ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJv bm1lbnQuICBJIGV4cGVjdCB0aGF0IHRoZSBzZXJ2aWNlDQo+PiA+Pj4gPj4gPj4gZnVuY3Rpb25z LCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLCB3aWxsDQo+PmJl DQo+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUg c2VydmljZSBjaGFpbnMgdG8gYmUNCj4+ID4+PiA+PmRyaXZlbiBieQ0KPj4gPj4+ID4+ID4+IEJT UyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZQ0KPj4g Pj4+c2VsZi1zZWxlY3Rpb24NCj4+ID4+PiA+PiA+PiBmcm9tIHRoZXNlLiAgSSBleHBlY3Qgc2Vy dmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeQ0KPj5kcml2ZS4NCj4+ID4+PiA+PiA+Pg0K Pj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFu IGFyY2h0aWVjdHVyZQ0KPj5kcml2ZW4NCj4+ID4+PmJ5DQo+PiA+Pj4gPj4gPj4gaW5pdGlhbCBj bGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gIEl0IGlzDQo+PmhhcmRl cg0KPj4gPj4+dG8NCj4+ID4+PiA+PnNlZQ0KPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdv cmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+PiA+Pj4gPj4gZHlu YW1pY2l0eQ0KPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4+ID4+ ID4+DQo+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0 aXZlIEkgZGVzY3JpYmVkIGlzDQo+Pm91dHNpZGUNCj4+ID4+Pm9mDQo+PiA+Pj4gPj50aGUNCj4+ ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhp bmcgd2UgYXJlDQo+PnRhc2tlZCB0bw0KPj4gPj4+ID4+YWdyZWUNCj4+ID4+PiA+PiA+Pm9uLg0K Pj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUg dG8gZG8gaXQgYSBjZXJ0YWluDQo+PiA+Pj53YXkuDQo+PiA+Pj4gPj5pdA0KPj4gPj4+ID4+ID4+ IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4g Pj4+ID4+ID4+DQo+PiA+Pj4gPj4gPj4gWW91cnMsDQo+PiA+Pj4gPj4gPj4gSm9lbA0KPj4gPj4+ ID4+ID4+DQo+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3Rl Og0KPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0 IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiB0aGF0DQo+PiA+Pj4gPj5uZWVkcw0KPj4gPj4+ID4+ID4+ Pj50bw0KPj4gPj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVk LCBwb3RlbnRpYWxseSBldmVuDQo+PmFjcm9zcw0KPj4gPj4+ZGF0YQ0KPj4gPj4+ID4+ID4+Pj4g Y2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBh bmQNCj4+ID4+PiBjb21wbGV4DQo+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8g Z2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+PmRpZmZpY3VsdA0KPj4g Pj4+ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+Pj4gPj4gPj4+DQo+PiA+ Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQg dGhhbiBkeW5hbWljDQo+PiA+Pj4gcm91dGluZywNCj4+ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUg ZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Ygd2hpY2gNCj4+YXJlDQo+ PiA+Pj4gPj5iaWdnZXINCj4+ID4+PiA+PiA+Pj4gcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJv Zml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVudGVkPw0KPj4gPj4+ID4+ID4+Pg0KPj4gPj4+ID4+ ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQs IHRoYXQgaXMNCj4+YQ0KPj4gPj4+Z29vZA0KPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQgaXQgaXMg dG9vIGNvbXBsaWNhdGVkLg0KPj4gPj4+ID4+ID4+Pg0KPj4gPj4+ID4+ID4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pj4gPj4gPj4+IEZyb206IEpvZWwg TS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+ID4+PiA+PiA+Pj4gU2VudDogVGh1 cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtl cjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb207IElhbg0KPj4gPj4+U21p dGg7DQo+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ PiA+PiA+Pj4NCj4+ID4+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiAg QW5kIG9uZSB0aGF0IEkgd291bGQgcHJlZmVyDQo+PndlDQo+PiA+Pj4gPj4gPj4+YWN0dWFsbHkN Cj4+ID4+PiA+PiA+Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBv c3NpYmxlDQo+PmltcGxlbWVudGF0aW9ucy4NCj4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2Vz IGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+cmVxdWlyZW1lbnRzDQo+PiA+ Pj5hbmQNCj4+ID4+PiA+PiB0aGUNCj4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZz Lg0KPj4gPj4+ID4+ID4+Pg0KPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5m b3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+dGhhdA0KPj4gPj4+IG5lZWRzDQo+ PiA+Pj4gPj4gdG8NCj4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWlu dGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcw0KPj4gPj4+ZGF0YQ0KPj4gPj4+ID4+ID4+ PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdo IGFuZA0KPj4gPj4+Y29tcGxleA0KPj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8g Z2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+PmRpZmZpY3VsdA0KPj4g Pj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+PiA+PiA+Pj4NCj4+ID4+ PiA+PiA+Pj4gWW91cnMsDQo+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ID4+PiA+PiA+Pj4NCj4+ID4+ PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ID4+PiA+PiA+Pj4NCj4+ID4+ PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ID4+PiA+ PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBlbmQg c2VsZWN0aW9uDQo+Pm9mDQo+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVy Zm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+ PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFu ZCBzdWJzZXF1ZW50bHkNCj4+dGhlDQo+PiA+Pj4gPj5TRkZzKT8NCj4+ID4+PiA+PiA+Pj4+IFN1 Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uICAgQW5k DQo+PiA+Pj5zdXJlbHksDQo+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwg aXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlv biIuDQo+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2 b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4gdGhvdWdoDQo+PiBhDQo+PiA+Pj4gPj4g Pj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFw cyBsb2NhbA0KPj4gPj4+ID4+c2VsZWN0aW9uDQo+PiA+Pj4gPj4gPj4+PiBwb2xpY3kpIGlzIHJl cXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy4NCj4+VGhpcw0KPj4g Pj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGgg aWQgYXQgYWxsLg0KPj5NeQ0KPj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0 aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseSBkcml2ZW4gYnkNCj4+ID4+PiA+PmluY3JlYXNlZA0K Pj4gPj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2Fj aC4gICBXaXRoIGEgZ2xvYmFsDQo+PiA+Pj5wYXRoDQo+PiA+Pj4gPj5pZA0KPj4gPj4+ID4+ID4+ Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcg dG8NCj4+YWx0ZXINCj4+ID4+PnRoZQ0KPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFi bGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkIGVuZC10by1lbmQNCj4+ID4+PnBhdGguDQo+ PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBz ZmMNCj4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpv ZWwgSGFscGVybiBEaXJlY3QNCj4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbV0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+IDY6MTUNCj4+ID4+PiBQTQ0K Pj4gPj4+ID4+ID4+Pj4gVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBJLlNtaXRoQEY1LmNvbTsgc2Zj QGlldGYub3JnIFN1YmplY3Q6DQo+PiBSZToNCj4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEg bmVlZGluZyB0bw0KPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4g aXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUgZXhpdA0KPj5mcm9t DQo+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ID4+ID4+Pj4gUGFy dCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+PmxvZ2lj YWxseQ0KPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFy bHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+IGNob29zZQ0KPj4gPj4+dG8NCj4+ID4+PiA+PiA+Pj4+ IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4gPj4+ID4+ID4+Pj4NCj4+ ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4+ID4+ID4+Pj4g T24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20gd3JvdGU6DQo+PiA+Pj4gPj4g Pj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0 cyBhbnkNCj4+c29ydA0KPj4gPj4+b2YNCj4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwg aXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZQ0KPj5wYXRoDQo+PiA+Pj4o YWxsDQo+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRp YXRpb24uICBJIGJlbGlldmUgdGhpcw0KPj4gPj4+bWVhbnMNCj4+ID4+PiA+PiA+Pj4+PiBlaXRo ZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXIgY2hvb3NlcyBhDQo+ PlNGDQo+PiA+Pj4gPj5DaGFpbg0KPj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhl IGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiAgSW4gYW55IGNhc2UsDQo+PnRoZQ0KPj4gPj4+ID4+ID4+ Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hl cmUNCj4+IFNGSShuKQ0KPj4gPj4+IGlzDQo+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0 aGUgU0ZJKG4tMSkgaG9wLiAgQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwNCj4+dGhpcw0KPj4gPj4+ ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBu ZXcgU0ZQIGFzDQo+PiA+Pj4gb3Bwb3NlZA0KPj4gPj4+ID4+IHRvDQo+PiA+Pj4gPj4gPj4+Pj4g Y2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YN Cj4+dGhlDQo+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1 cmUtMDA6DQo+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRv IHRoZSBuZXR3b3JrIGl0IGlzDQo+Pm5lY2Vzc2FyeQ0KPj4gPj4+dG8NCj4+ID4+PiA+PiA+Pj4+ Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2Vk LA0KPj5hbmQgdG8NCj4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5 IGZvciB0aGF0IFNGQyB1c2luZyBTRidzDQo+Pm5ldHdvcmsNCj4+ID4+PiA+PiA+Pj4+Pj4gbG9j YXRvci4gIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluIHRoZQ0KPj4g Pj4+Y3JlYXRpb24NCj4+ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGgg KFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+PmZvcndhcmRpbmcNCj4+ID4+PiA+PiA+Pj4+Pj4gcGFj a2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhlDQo+PiA+ Pj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4+ID4+ ID4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyBy ZWNsYXNzaWZpY2F0aW9uIChvcg0KPj5ub24taW5pdGlhbA0KPj4gPj4+ID4+ID4+Pj4+PiBjbGFz c2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPj4gPj4+ ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3Jt ZWQgYnkgYQ0KPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNp ZGVudCB3aXRoIGEgc2VydmljZQ0KPj5mdW5jdGlvbi4NCj4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFz c2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4+U0ZQLCBh bg0KPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9y IGJvdGguICBUaGlzIGlzDQo+PnJlZmVycmVkDQo+PiA+Pj50bw0KPj4gPj4+ID4+ID4+Pj4+PiBh cyAiYnJhbmNoaW5nIi4NCj4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+DQo+PiA+Pj4NCj4+IA0KPj4+Pj4+ Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+ID4+ Pj4+Pj4tLQ0KPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNv bTxJLlNtaXRoQEY1LmNvbT4NCj4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4gRGly ZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPixKb2VsDQo+PiBNLg0KPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+Pj4gPj4NCj4+ID4+Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5j b20+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0BzY2UuDQo+PiA+Pj4gPj4gY2FybGV0b24u DQo+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4g KlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0 OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+QmFsYW5jZXJz DQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFt IGRpc2FncmVlaW5nLg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBv c3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kIHRoYXQgaXMNCj4+ID4+ PndoYXQNCj4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBv ZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4gPj4+cHJlY29uY2VpdmVkDQo+PiA+Pj4gPj4gPj4+Pj4g YXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoIHRo YXQNCj4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3Jl ZSBvZg0KPj5hc3BpcmF0aW9uDQo+PiB0bw0KPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMg YXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4+YXJjaGl0ZWN0dXJlDQo+PiA+ Pj4tDQo+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBi dXQgYnkgc2F5aW5nIHRoYXQgYW4NCj4+ID4+PmFyYml0cmFyeQ0KPj4gPj4+ID4+ID4+Pj4+IG51 bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNuJ3QNCj4+ ID4+PiA+PmludGVudGlvbmFsDQo+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVl bmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3RpbmcNCj4+aW1wYWN0cw0KPj4gPj4+ID4+ID4+ Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwN Cj4+YWRkcmVzcw0KPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3Mu IFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3QNCj4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1bGFybHkg ZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFtqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCj4+U2VudDoNCj4+ID4+PiA+PiA+Pj4+PiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS4NCj4+IEhhbHBl cm47DQo+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhOyBzZmNAaWV0Zi5vcmcg U3ViamVjdDogUmU6IFtzZmNdDQo+PlNlcnZpY2UNCj4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+ IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcw0K Pj5yZWdhcmQuDQo+PiA+Pj5JDQo+PiA+Pj4gPj5hbQ0KPj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1 ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbg0KPj5wcm9oaWJpdA0K Pj4gPj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFt IG9iamVjdGluZyB0bw0KPj5IdWFuZydzDQo+PiA+Pj4gPj4gPj4+Pj4gcmVhZGluZyBvZiBteSBu b3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlDQo+PiByZXF1aXJlZA0KPj4g Pj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWlu ZyB0byBwcm9oaWJpdCBzdWNoDQo+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkg YXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24NCj4+IG1hbnkNCj4+ID4+PiA+PiA+ Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8g dGhpbmsNCj4+dGhhdA0KPj4gPj4+ID4+dGhleQ0KPj4gPj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5 IGEgYmFkIGlkZWEuDQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFy Y2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bw0KPj5rbm93DQo+ PiA+Pj53aGF0DQo+PiA+Pj4gPj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0K Pj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4+ID4+ ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRl bnMgb2YNCj4+ID4+Pm1pbGxpb25zDQo+PiA+Pj4gPj4gPj4+Pj4+IG9mDQo+PiA+Pj4gPj4gPj4+ Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRl cg0KPj4gPj4+ID4+ID4+Pj4+IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNs eSBiZWxpZXZlIHRoYXQgaW4gdGhlDQo+PiA+Pj4gPj4gPj4+Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0 eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdSBhcmUNCj4+IG9ubHkNCj4+ID4+PiA+ PiBnb2luZw0KPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNl IGNoYWlucyB3aXRoIGVxdWFsbHkgc21hbGwNCj4+ID4+PiBudW1iZXJzDQo+PiA+Pj4gPj4gPj4+ Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4gPj4g Pj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCBt b3JlIHRoYW4NCj4+ID4+PiA2NEsiDQo+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4+ID4+ID4+ Pj4+IGNvbWZvcnQuDQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4g Pj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTog c2ZjDQo+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9m IEpvZWwgTS4gSGFscGVybg0KPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tXQ0K Pj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRv Og0KPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0 Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+PiA+ Pj5Mb2FkDQo+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4+ID4+ID4+Pj4+Pg0KPj4g Pj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBk ZXBsb3kgdGhlDQo+PiA+Pj5hcmNodGlldHVyZQ0KPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFy bHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZiB0aGVpcg0KPj4gPj4+ID4+ ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBh YnN1cmQgdXNlDQo+PiBvZg0KPj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJ IGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0 ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZSBkb2VzDQo+PiA+ Pj5wZXJtaXQNCj4+ID4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+ID4+PiA+PiA+Pj4+Pj4N Cj4+ID4+PiA+PiA+Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBh cmNodGllY3R1cmUgcGVybWl0cw0KPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5n IGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5DQo+PnRoZQ0KPj4gPj4+d29yay4N Cj4+ID4+PiA+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4gPj4g Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+IE9u IDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiA+Pj4gPj4gPj4+ Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbCBt ZWFuDQo+PiA+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0 aGFuIHRoZSByb3V0aW5nIHRhYmxlDQo+Pm9mIGENCj4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91 dGVyLg0KPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+Pj4g Pj4gPj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9l bCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUg YWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20gMQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+ IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlIHRoYXQN Cj4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxl eGl0aWVzIGlmIHRoZXkNCj4+Y2hvb3NlDQo+PiA+Pj50bw0KPj4gPj4+ID4+ID4+Pj4+Pj4+IGF2 b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkDQo+PiBwcm92 aXNpb24NCj4+ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiA+Pj4g Pj4gPj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4+ID4+ID4+ Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxB LCBNQVJJQSBIIHdyb3RlOg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRo ZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4+IHNlcnZpY2UNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Y2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4g Pj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9u IEJlaGFsZiBPZg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50 OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+MzowMw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQ TSAqVG86KiBMdWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbTsNCj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSAqU3ViamVjdDoqIFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBh cyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3 YXJkaW5nLiBJwrlkDQo+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+PiBk ZXJpdmUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3Nv Y2lhdGVkIHRyYW5zcG9ydC4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvIHNpbXBs eQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFw aCkgdGhhdCBwYWNrZXRzIG11c3QNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhh dmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu ZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzDQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUg cGF0aA0KPj4gaWRlbnRpZmllcg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5n IG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuDQo+PiByZXN1bHQNCj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9y dCBuZXh0DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcNCj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tDQo+PiA8bWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tPj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5 IHVzZSBvZiB0aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIg dG8gZHJpdmUgdGhlIGZvcndhcmRpbmcNCj4+YWN0aW9ucy4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJl aGFsZg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4NCj4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+PiA+Pj4gPj4gSnVseQ0KPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb20NCj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNv bQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0Bp ZXRmLm9yZw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1Ympl Y3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PkNoYWlucywNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBSZS0sDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRo ZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmll ciB0byBkZXJpdmUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lz dGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mDQo+PiBldmVyeQ0KPj4gPj4+ID4+ID4+ Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3 aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPj4gPj4+ID4+ID4+Pj4+IHJlcXVp cmVkL2p1c3RpZmllZA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91 cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBv Zg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4+ID4+ID4+Pj4+IHRoYXQg d2lsbA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czog dGhhdCBpcyB0aGUgb25lIHJlcXVpcmVkDQo+PiB0bw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1 Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj51c2VkIHRv DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+PiA+PiA+Pj4+PiBh Y3Rpb25zDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vz c2lvbi4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0K Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9s LmNvbQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52 b3nDqSA6Km1lcmNyZWRpIDkNCj4+IGp1aWxsZXQNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMjAxNCAy MjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQgOipSZTogW3NmY10gU2VydmljZQ0KPj5DaGFp bnMsDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0 aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU0YNCj4+IENoYWluDQo+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuZCBTRg0KPj4gPj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4+Y2xl YXIgdG8NCj4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFt aWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzDQo+Pm9u DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVu Y2xlYXIgaXMgd2hldGhlcg0KPj5pdCBpcw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50 IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQNCj4+dGhlIElEDQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxk DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwg b3IgaWYgdGhpcyBkcmFmdA0KPj5zaW1wbHkNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0 byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzDQo+PnRvDQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFz ZWQgb24gY2hhaW4gb3INCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBv ZiBjaGFpbiBvcg0KPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUg ZHJhZnQgd291bGQgaGF2ZQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBT RlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2UNCj4+IG9uZQ0KPj4gPj4+ID4+ID4+Pj4+ Pj4+PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRv cnMNCj4+IG9ubHkNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVy cyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4NCj4+ID4+Pg0KPj4gDQo+Pj4+Pj4+ Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4gPj4+ Pj4+Pi0tDQo+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4+ID4+ID4+Pj4+DQo+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxo YWxwZXJuLmNvbT4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0Bp ZXRmLm9yZw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0Bp ZXRmLm9yZz4+ICpTZW50OipUdWVzZGF5LA0KPj4gSnVseQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4 LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xl YXJseSBhbnN3ZXINCj4+YQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29tbWVudHMg dGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUNCj4+ID4+PiBwcm9wb3NlZA0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0 IHdvcmtpbmcNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRl bnQsIHdlIHdpbGwgd29yayB0byBpbXByb3ZlDQo+PiB0aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbg0KPj50 aGUNCj4+IFdHDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQg aXQgdGhlIHdheSB0aGUNCj4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+PnBl cnNvbmFsDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4N Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQs IGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdA0KPj53aGF0DQo+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUu IFdlIGFyZQ0KPj4gbm90DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5l IHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29s dXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQgZW5jb21wYXNzDQo+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9u cywgdmlydHVhbA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2Vt ZW50LCBhbmQgbWFueSBvdGhlcg0KPj4gYXNwZWN0cy4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNo IGNsZWFybHkgbmVlZCB0bw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2Vy IHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoDQo+PmFib3ZlDQo+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3 ZSBhcmUgZG9pbmcuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElu IG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSQ0KPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRo ZXJlIGFyZSBhdA0KPj5sZWFzdA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQg d2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbA0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZQ0KPj5t b3JlLg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBp cyB0byBwZXJtaXQgYWxsIG9mDQo+PnRoZXNlLA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90 IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+PiA+Pj4gPj4gPj4+Pj4gYmUg dXNlZA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2Vydmlj ZSBwcm92aWRlZCB0byB0aGUgZW5kDQo+PnVzZXIuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMg aXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsDQo+PmFuZA0K Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPj4gPj4+ID4+ID4+Pj4+IG1h cmtzDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFu IGVuZCB1c2VyIHNlcnZpY2UNCj4+aW5zdGFuY2UNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVj ZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj5zZXJ2aWNlDQo+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2 aWNlIGNoYWluaW5nLg0KPj5JdCdzDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBh ZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+PiBjaGFpbmluZyBpcw0KPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUN Cj4+YXJjaHRpZWN0dXJlLg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiAgRnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UN Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJs eWluZyBwYWNrZXQuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIp IFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuDQo+Pmhh dmUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFz IGEgc2luZ2xlIHBvaW50DQo+Pm9mDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+ PiA+PiA+Pj4+PiBmb3IgYQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1 bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkDQo+PmJ5IGENCj4+ID4+PiA+PiA+Pj4+ PiBjb2xsZWN0aW9uIG9mDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwg bWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3INCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g c2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3Rs eSwgdGhpcyBpcw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgZGF0YSBwbGFuZQ0KPj5tZWNoYW5pc21zLg0KPj4gSXQNCj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wNCj4+ bWVjaGFuaXNtcywNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJs ZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kDQo+PnZtDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nDQo+ PnRoaXMNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUg Y2FyZWZ1bCB0aGF0IG91cg0KPj50ZXJtaW5vbG9neQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2Vz IG5vdCBsZWFkDQo+PiA+Pj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUg Ynkgc2VsZWN0aW5nDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNl cnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+dHJhZmZpYw0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlIHRoYXQN Cj4+YQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBh dCBvbmx5IG9uZSBwbGFjZSBpbiB0aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRo ZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJDQo+PiB0ZW5kDQo+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRvDQo+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZQ0KPj5j aGFpbmluZw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0 ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMNCj4+YQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29k IHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsDQo+PiB0 aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+ PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVu dCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50DQo+PnNpbmd1bGFyDQo+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxh Y2VzIGluDQo+PnRoZQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8g SSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hh aW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhDQo+PiBzZXF1ZW5jZQ0KPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEg c3Vic2V0IG9mDQo+PnBhY2tldHMuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxl bnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YgdHJhZmZpYw0KPj5pcw0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQg ZmlyZXdhbGwNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlz IHRvIGdvIGRpcmVjdGx5IHRvIHRoZSBjYWNoZQ0KPj4gPj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0K Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91 Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLiBBDQo+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+Pmxv Y2F0aW9ucw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRp b25zIHdpbGwgYmUgc2luZ3VsYXIgb3INCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNl cnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5DQo+Pm1heSBiZQ0KPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVz c2VkIGFzIHBvcnRzDQo+PiBvbg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFy ZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+PmxvY2F0aW9ucw0KPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1 cmUgYW5kDQo+PiB0aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gIEZyb20gdGhlIHBvaW50IG9mIHZpZXcg b2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91cCwNCj4+IHdlDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+ PiBuZWVkIHRvIGJlDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUg aGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlDQo+PnNlcnZpY2UNCj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFs aw0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRz IHdpbGwgdGFrZSBpbiB0aGUNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMg aGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGgNCj4+IG1heQ0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMNCj4+ d2l0aA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwg YXMgbm90ZWQgaW4gaXRlbSAoMikgb24NCj4+bG9hZA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiYWxh bmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kIGJlaGF2aW9ycw0KPj4gd2hp Y2gNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFp bmluZyBtZWNoYW5pc21zIChpbg0KPj5tdWNoDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1l IHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92 aXNpb24NCj4+IHdlDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+PiA+PiA+Pj4+ PiB0aGF0DQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUg aW4gbWlkLWNoYWluIHdoZW4NCj4+IG5lY2Vzc2FyeS4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhh dCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9u IHBvaW50Lg0KPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUg dGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0DQo+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhl IHdvcmtpbmcNCj4+IGdyb3VwLA0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91 dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZCB0bw0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUNCj4+ IGludGVudCwNCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1 c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcNCj4+Z3JvdXANCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdy ZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlDQo+PndoYXQg dG8NCj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBzZmMNCj4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBz ZmMNCj4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5v cmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+PiA+ PiA+Pj4+Pj4+Pg0KPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4+ID4+IG1h aWxpbmcNCj4+ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIA0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+Pj4gbWFpbGluZw0KPj4gPj4+ID4+IGxpc3QN Cj4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBzZmMNCj4+ID4+PiBtYWlsaW5nDQo+PiA+Pj4gPj4gbGlzdA0KPj4gPj4+ID4+ID4+Pj4+IHNm Y0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4+ID4+ID4+Pj4NCj4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+ID4+IGxpc3QNCj4+ID4+ PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4+ID4+ID4+Pj4NCj4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+ID4+ IGxpc3QNCj4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+ID4+ID4+Pj4NCj4+ID4+PiA+PiA+Pj4NCj4+ID4+ PiA+PiA+Pg0KPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4+ID4+ID4+ IHNmY0BpZXRmLm9yZw0KPj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+PiA+Pj4gPj4gPj4NCj4+ID4+PiA+PiA+DQo+PiA+Pj4gPj4gPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pj4gPj4gPnNm YyBtYWlsaW5nIGxpc3QNCj4+ID4+PiA+PiA+c2ZjQGlldGYub3JnDQo+PiA+Pj4gPj4gPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4gPj4NCj4+ID4+PiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4+ ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+PiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+DQo+PiA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+PiBz ZmMgbWFpbGluZyBsaXN0DQo+PiA+Pj4gc2ZjQGlldGYub3JnDQo+PiA+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ ID5zZmNAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KDQo= From nobody Fri Jul 11 08:27: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 3F4901B2B9F for ; Fri, 11 Jul 2014 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ9_292EPNah for ; Fri, 11 Jul 2014 08:27:18 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392DD1B2B8E for ; Fri, 11 Jul 2014 08:27:18 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 65200c35.2b1608439940.8951861.00-2481.21485415.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 11 Jul 2014 15:27:18 +0000 (UTC) X-MXL-Hash: 53c002563b4aeb9d-c7cbcca37798857c671aad9ea0d65f22f15f8d8e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 35200c35.0.8951838.00-2388.21485332.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 11 Jul 2014 15:27:16 +0000 (UTC) X-MXL-Hash: 53c0025477062247-bd6375f5dde1be901fdd1f912313d4c89ee72ae2 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BFREg2002625; Fri, 11 Jul 2014 11:27:15 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BFR6x6002507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 11:27:10 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 15:26:52 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 11:26:52 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA///Q1oCAAEKp8A== Date: Fri, 11 Jul 2014 15:26:52 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=NtNmhbhJ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH] X-AnalysisOut: [86SAAAA:8 a=ttBcPeHlu64fSnSlNi4A:9 a=QEXdDO2ut3YA:10 a=JfD] X-AnalysisOut: [0Fch1gWkA:10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=Hz7IrDY] X-AnalysisOut: [lS0cA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037Qrwtg] X-AnalysisOut: [A:10 a=jtBhQZAsqHBOnusq:21 a=7iknMiERILcKVaB0:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZuAnXrFSGY6XFxXQz0YcTMYv0a0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:27:23 -0000 SmltLA0KDQpDb3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNl cnZpY2UgcGF0aCIgYW5kIGEgInNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIj8NCklmIGEgc2Vydmlj ZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgICh3 aGljaCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxv Y2FsIGRlY2lzaW9uIHdoaWNoIG5leHQtaG9wIFNGRiB0byBwaWNrLiAgSXQgaXMgYSBjZW50cmFs aXplZCBkZWNpc2lvbi4NCg0KTWFyaWENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28u Y29tXQ0KPiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4gVG86IE5BUElF UkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9lbCBNLg0KPiBI YWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+IA0KPiBJ4oCZbSBzb3Jy eSBidXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBhIHNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyDQo+IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3 aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UNCj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlm ZmVyZW5jZT8NCj4gDQo+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb20+IHdyb3RlOg0KPiANCj4gPkRpdHRvLg0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPiA+PiBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4gPj4gVG86IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+ ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+Pg0KPiA+PiBSZS0sDQo+ID4+ DQo+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBj bGVhcmx5IGluIHRoZSBkcmFmdC4NCj4gPj4NCj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRo IGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxsDQo+ID4+ZGlzdHJp YnV0ZWQNCj4gPj4gbW9kZWwgaXMgbm90IGFsbG93ZWQuDQo+ID4+DQo+ID4+IFNldmVyYWwgdm9p Y2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2Vs Zg0KPiA+PnNob3VsZCBiZQ0KPiA+PiBwcm92aWRlZCBpbnN0ZWFkLg0KPiA+Pg0KPiA+PiBDaGVl cnMsDQo+ID4+IE1lZA0KPiA+Pg0KPiA+PiA+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4+ID5EZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IEppbSBHdWljaGFyZA0KPiA+PiA+KGpndWljaGFyKQ0KPiA+PiA+RW52b3nDqSA6IHZlbmRyZWRp IDExIGp1aWxsZXQgMjAxNCAxNjoxOA0KPiA+PiA+w4AgOiBOQVBJRVJBTEEsIE1BUklBIEg7IEpv ZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ID4+ID5PYmpldCA6IFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+ DQo+ID4+ID5PayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMg dGhpcyBmdW5jdGlvbmFsaXR5DQo+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0 cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+ID4+ID53aXRoaW4gdGhl IFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlkZW50aWZpZXIgcG9pbnQgdG8gYQ0K PiA+Pmxvb2t1cA0KPiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQg U0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdCBzdXJlDQo+ID4+aG93DQo+ID4+ID50aGUgYXJjaGl0 ZWN0dXJlIHByZXZlbnRzIHRoYXQ/DQo+ID4+ID4NCj4gPj4gPk9uIDcvMTEvMTQsIDk6NTggQU0s ICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4gd3JvdGU6DQo+ID4+ID4N Cj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPiA+PiA+Pg0KPiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+ID4+ID4+PihqZ3VpY2hhcikNCj4gPj4gPj4+ IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+ID4+ID4+PiBUbzogTkFQSUVS QUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0K PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhl IHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZQ0KPiA+PnRoYXQgaWYNCj4g Pj4gPj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJl bW90ZSBTRkYgaXQgd2lsbA0KPiA+PnVzZQ0KPiA+PiA+Pj5mb3INCj4gPj4gPj4+IGEgZ2l2ZW4g ZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91IGJldHRl cg0KPiA+Pm1ha2UNCj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBu ZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYyB0bw0KPiA+PnJlYWNoDQo+ID4+ID4+PnRoZQ0KPiA+ PiA+Pj4gbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4g ZGVlcCB0cm91YmxlLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJO QVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+ID4+ Pg0KPiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFu dGlhdGVkIG9ubHkgaW4gcmVsZXZhbnQNCj4gPj4gPj4+U0ZGcw0KPiA+PiA+Pj4gPndoZW4gdGhl eSAiYXJyaXZlIi4NCj4gPj4gPj4+ID4NCj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+ID4+PiA+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+ID4+ ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPiA+PiA+Pj4gPj4g VG86IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ID4+ID4+PiA+ PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4gPj4gPj4+ID4+DQo+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3 b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhlDQo+ID4+ID4+PiA+PnByb3Bv c2FsDQo+ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3ds ZWRnZSBvZiBldmVyeSBzaW5nbGUgU0YNCj4gPj4gPj4+d2l0aGluDQo+ID4+ID4+PiA+PnRoZQ0K PiA+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVy ZSBpcyBubyB3YXkgdG8ga25vdw0KPiA+PmENCj4gPj4gPj4+ID4+cHJpb3JpDQo+ID4+ID4+PiA+ PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdp dmVuIHBvaW50DQo+ID4+aW4NCj4gPj4gPj4+dGltZS4NCj4gPj4gPj4+ID4+DQo+ID4+ID4+PiA+ PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVy bi5jb20+DQo+ID4+IHdyb3RlOg0KPiA+PiA+Pj4gPj4NCj4gPj4gPj4+ID4+ID5Sb24sIHRoaW5r aW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvciBwcm9ibGVtIHdpdGgNCj4g Pj50aGUNCj4gPj4gPj4+ID4+eW91cg0KPiA+PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJz dGFuZCBpdC4gIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdA0KPiA+PiA+Pj51bmRlcnN0 YW5kDQo+ID4+ID4+PiA+PiA+aXQuKQ0KPiA+PiA+Pj4gPj4gPg0KPiA+PiA+Pj4gPj4gPlRoZSBw cm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZQ0K PiA+Pm5leHQNCj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAo bm90IHRoZSBvbmUgaXQgZGVsaXZlcnMgdG8pLA0KPiA+PmluDQo+ID4+ID4+PmV2ZXJ5DQo+ID4+ ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4gPj4gPj4+ID4+ ID4NCj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxs IHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+ID4+dGhhdA0KPiA+PiA+Pj4gPj5ldmVyeQ0KPiA+PiA+ Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0 YXRlZnVsIGxvYWQNCj4gPj4gPj4+YmFsYW5jZXIuDQo+ID4+ID4+PiA+PiA+SSBhaHZlIG5vIHBy b2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcg0KPiA+PnN0YXRl ZnVsLg0KPiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRo YXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwNCj4gPj5mbG93DQo+ID4+ID4+PiA+PiA+c2Vuc2l0aXZl LCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPiA+PmFjY2Vw dGFibGUNCj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0KPiA+PiA+Pj4gPj4gPg0KPiA+PiA+Pj4g Pj4gPllvdXJzLA0KPiA+PiA+Pj4gPj4gPkpvZWwNCj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4+ID4+ ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+PiA+Pj4g Pj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFr ZSB0aGlzIHdvcmsNCj4gPj4gPj4+ID4+c2Vuc2libHkNCj4gPj4gPj4+ID4+ID4+IGluIGEgbW9y ZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuICBJIGV4cGVjdCB0aGF0IHRoZSBzZXJ2aWNlDQo+ ID4+ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBj YXBhYmlsaXRpZXMsIHdpbGwNCj4gPj5iZQ0KPiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFu ZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8gYmUNCj4gPj4gPj4+ ID4+ZHJpdmVuIGJ5DQo+ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJp bmdzIHRvIGNsaWVudHMsIGFuZCBlbmFibGUNCj4gPj4gPj4+c2VsZi1zZWxlY3Rpb24NCj4gPj4g Pj4+ID4+ID4+IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZp bHkgcG9saWN5DQo+ID4+ZHJpdmUuDQo+ID4+ID4+PiA+PiA+Pg0KPiA+PiA+Pj4gPj4gPj4gSSBj YW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRpZWN0dXJlDQo+ ID4+ZHJpdmVuDQo+ID4+ID4+PmJ5DQo+ID4+ID4+PiA+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0 aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiAgSXQgaXMNCj4gPj5oYXJkZXINCj4gPj4g Pj4+dG8NCj4gPj4gPj4+ID4+c2VlDQo+ID4+ID4+PiA+PiA+PiBob3cgdG8gbWFrZSBpdCB3b3Jr IChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cgbW9yZQ0KPiA+PiA+Pj4gPj4gZHlu YW1pY2l0eQ0KPiA+PiA+Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsgYmVoYXZpb3IuDQo+ID4+ID4+ PiA+PiA+Pg0KPiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBl cnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzDQo+ID4+b3V0c2lkZQ0KPiA+PiA+Pj5vZg0KPiA+PiA+ Pj4gPj50aGUNCj4gPj4gPj4+ID4+ID4+IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiAgaXQg aXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4gPj50YXNrZWQgdG8NCj4gPj4gPj4+ID4+YWdyZWUN Cj4gPj4gPj4+ID4+ID4+b24uDQo+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0 IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGEgY2VydGFpbg0KPiA+PiA+Pj53YXkuDQo+ ID4+ID4+PiA+Pml0DQo+ID4+ID4+PiA+PiA+PiBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0 IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+PiA+PiA+PiBZ b3VycywNCj4gPj4gPj4+ID4+ID4+IEpvZWwNCj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+PiA+PiA+ PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ID4+ID4+PiA+PiA+Pj4+ IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNl cw0KPiA+PiB0aGF0DQo+ID4+ID4+PiA+Pm5lZWRzDQo+ID4+ID4+PiA+PiA+Pj4+dG8NCj4gPj4g Pj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRp YWxseSBldmVuDQo+ID4+YWNyb3NzDQo+ID4+ID4+PmRhdGENCj4gPj4gPj4+ID4+ID4+Pj4gY2Vu dGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQN Cj4gPj4gPj4+IGNvbXBsZXgNCj4gPj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRv IGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhDQo+ID4+ID4+PmRpZmZpY3VsdA0K PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4gPj4gPj4+ID4+ID4+ Pg0KPiA+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29t cGxpY2F0ZWQgdGhhbiBkeW5hbWljDQo+ID4+ID4+PiByb3V0aW5nLA0KPiA+PiA+Pj4gPj4gPj4+ IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mIHdo aWNoDQo+ID4+YXJlDQo+ID4+ID4+PiA+PmJpZ2dlcg0KPiA+PiA+Pj4gPj4gPj4+IHByb2JsZW1z IHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8NCj4gPj4g Pj4+ID4+ID4+Pg0KPiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFs bHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdCBpcw0KPiA+PmENCj4gPj4gPj4+Z29vZA0KPiA+ PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+ID4+ID4+PiA+ PiA+Pj4NCj4gPj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhh bHBlcm4uY29tXQ0KPiA+PiA+Pj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDk6NDUgUE0NCj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERp cmVjdDsgbWlrZWJpYW5jQGFvbC5jb207IElhbg0KPiA+PiA+Pj5TbWl0aDsNCj4gPj4gPj4+ID4+ ID4+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4+ID4+ID4+Pg0K PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gIEFuZCBvbmUg dGhhdCBJIHdvdWxkIHByZWZlcg0KPiA+PndlDQo+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPiA+ PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3Nz aWJsZQ0KPiA+PmltcGxlbWVudGF0aW9ucy4NCj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRv ZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPiA+PnJlcXVpcmVtZW50cw0K PiA+PiA+Pj5hbmQNCj4gPj4gPj4+ID4+IHRoZQ0KPiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxp dHkgb2YgU0ZGcy4NCj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwgdGhl IGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcw0KPiA+PnRoYXQN Cj4gPj4gPj4+IG5lZWRzDQo+ID4+ID4+PiA+PiB0bw0KPiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVs eSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPiBhY3Jvc3MN Cj4gPj4gPj4+ZGF0YQ0KPiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0 cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2ggYW5kDQo+ID4+ID4+PmNvbXBsZXgNCj4gPj4g Pj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBz ZWVtcyBsaWtlIGENCj4gPj4gPj4+ZGlmZmljdWx0DQo+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0 dXJlIHRvIHJlYWxpemUuDQo+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4+ID4+ID4+PiBZb3VycywN Cj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4+ID4+ID4+PiBC dXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPiA+PiA+Pj4gPj4gPj4+DQo+ID4+ID4+PiA+PiA+ Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4gPj4gPj4+ID4+ID4+ Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0aGUgZW5kIHRvIGVuZCBzZWxl Y3Rpb24NCj4gPj5vZg0KPiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVy Zm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4gPj4gPj4+ID4+Y2xhc3NpZmllcikN Cj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmll ciBhbmQgc3Vic2VxdWVudGx5DQo+ID4+dGhlDQo+ID4+ID4+PiA+PlNGRnMpPw0KPiA+PiA+Pj4g Pj4gPj4+PiBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0 aW9uLiAgIEFuZA0KPiA+PiA+Pj5zdXJlbHksDQo+ID4+ID4+PiA+PiA+Pj4+IHRoaXMgaXMgYW4g YXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90IHJlbGVnYXRlZCB0bw0KPiA+PiA+Pj4gPj4gPj4+ PiAiaW1wbGVtZW50YXRpb24iLg0KPiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+Pj4gPj4gPj4+PiBN eSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbg0KPiB0 aG91Z2gNCj4gPj4gYQ0KPiA+PiA+Pj4gPj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChj aGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwcyBsb2NhbA0KPiA+PiA+Pj4gPj5zZWxlY3Rpb24N Cj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRl ZCBkZWNpc2lvbiBwb2ludHMuDQo+ID4+VGhpcw0KPiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBk b2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+ID4+TXkNCj4g Pj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHBy aW1hcmlseSBkcml2ZW4gYnkNCj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+ID4+ID4+PiA+PiA+Pj4+ IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICAgV2l0aCBhIGds b2JhbA0KPiA+PiA+Pj5wYXRoDQo+ID4+ID4+PiA+PmlkDQo+ID4+ID4+PiA+PiA+Pj4+IGFwcHJv YWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvDQo+ID4+ YWx0ZXINCj4gPj4gPj4+dGhlDQo+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxl IGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZCBlbmQtdG8tZW5kDQo+ID4+ID4+PnBhdGguDQo+ ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+IFJvbg0KPiA+PiA+Pj4gPj4gPj4+Pg0K PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IEZyb206IHNmYw0KPiA+PiA+Pj4gPj4gPj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJl aGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0 QGpvZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4gPj4gNjox NQ0KPiA+PiA+Pj4gUE0NCj4gPj4gPj4+ID4+ID4+Pj4gVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBJ LlNtaXRoQEY1LmNvbTsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6DQo+ID4+IFJlOg0KPiA+PiA+ Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRl Y3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNGMSBuZWVkaW5nIHRvDQo+ID4+ID4+PiA+PmluZmx1 ZW5jZQ0KPiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVj bGFzc2lmaWNhdGlvbiBhdCB0aGUgZXhpdA0KPiA+PmZyb20NCj4gPj4gPj4+ID4+ID4+Pj4gU0Yx Lg0KPiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlz IHRvIGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4gPj5sb2dpY2FsbHkNCj4gPj4gPj4+ ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUg aG93IHRoZXkNCj4gPj4gY2hvb3NlDQo+ID4+ID4+PnRvDQo+ID4+ID4+PiA+PiA+Pj4+IGNvbXBv c2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+ Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+Pj4gPj4gPj4+ PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4gPj4gPj4+ ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3Vn Z2VzdHMgYW55DQo+ID4+c29ydA0KPiA+PiA+Pj5vZg0KPiA+PiA+Pj4gPj4gPj4+Pj4gbGltaXQu IEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUNCj4gPj5w YXRoDQo+ID4+ID4+PihhbGwNCj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2Vu IGF0IFNGQyBpbnN0YW50aWF0aW9uLiAgSSBiZWxpZXZlIHRoaXMNCj4gPj4gPj4+bWVhbnMNCj4g Pj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xh c3NpZmllciBjaG9vc2VzIGENCj4gPj5TRg0KPiA+PiA+Pj4gPj5DaGFpbg0KPiA+PiA+Pj4gPj4g Pj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuICBJbiBhbnkg Y2FzZSwNCj4gPj50aGUNCj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBw cm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4gPj4gU0ZJKG4pDQo+ID4+ID4+PiBp cw0KPiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiAgQWNj b3JkaW5nIHRvIHRoZSBkcmFmdCwNCj4gPj50aGlzDQo+ID4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlv ciB3b3VsZCBiZSBjb25zaWRlcmVkICJicmFuY2hpbmciIHRvIGEgbmV3IFNGUCBhcw0KPiA+PiA+ Pj4gb3Bwb3NlZA0KPiA+PiA+Pj4gPj4gdG8NCj4gPj4gPj4+ID4+ID4+Pj4+IGNob29zaW5nIGFu ZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlIG9mDQo+ID4+dGhlDQo+ ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUt MDA6DQo+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8g dGhlIG5ldHdvcmsgaXQgaXMNCj4gPj5uZWNlc3NhcnkNCj4gPj4gPj4+dG8NCj4gPj4gPj4+ID4+ ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJl IHVzZWQsDQo+ID4+YW5kIHRvDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNl IHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzDQo+ID4+bmV0d29yaw0KPiA+PiA+Pj4g Pj4gPj4+Pj4+IGxvY2F0b3IuICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0 cyBpbiB0aGUNCj4gPj4gPj4+Y3JlYXRpb24NCj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBhIFNlcnZp Y2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3INCj4gPj5mb3J3YXJkaW5nDQo+ ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRz LCBhbiBTRlAgaXMgdGhlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBvZiB0aGUg ZGVmaW5lZCBTRkMuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUg U0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9uIChvcg0KPiA+Pm5vbi1p bml0aWFsDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuICBBcyBw YWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0 aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPiA+PiA+Pj4gPj4gPj4+ Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlDQo+ ID4+ZnVuY3Rpb24uDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVz dWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4gPj5TRlAsIGFuDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiAgVGhpcyBp cw0KPiA+PnJlZmVycmVkDQo+ID4+ID4+PnRvDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gYXMgImJyYW5j aGluZyIuDQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4NCj4gPj4gPj4+DQo+ID4+DQo+ ID4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4gPj4gPj4+Pj4+Pj4+Pi0t DQo+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4gPj4gPj4+ID4+ID4+ Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+ PiAqRnJvbTogKkkuU21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPiA+PiA+Pj4gPj4gPj4+ Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+IERpcmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNv bT4sSm9lbA0KPiA+PiBNLg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+DQo+ID4+ID4+ Pg0KPiA+Pg0KPiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbT4saHVhbmdAc2NlLmNh cmxldG9uLmNhPGh1YW5nQHNjZS4NCj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPiA+PiA+Pj4gPj4g Pj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+PiAqU2Vu dDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDog KlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ID4+QmFsYW5jZXJz DQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsg SSBhbSBkaXNhZ3JlZWluZy4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+PiBJ ZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQgdGhhdCBp cw0KPiA+PiA+Pj53aGF0DQo+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGlu IG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4g Pj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUg YnVyZGVuZWQgd2l0aA0KPiB0aGF0DQo+ID4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0K PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21l IHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YNCj4gPj5hc3BpcmF0aW9uDQo+ID4+IHRvDQo+ ID4+ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNw YW4gb2YgdGhlDQo+ID4+YXJjaGl0ZWN0dXJlDQo+ID4+ID4+Pi0NCj4gPj4gPj4+ID4+ID4+Pj4+ IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFu DQo+ID4+ID4+PmFyYml0cmFyeQ0KPiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFy IiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPiA+PiA+Pj4gPj5pbnRlbnRp b25hbA0KPiA+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lv bnMgdGhhdCBoYXZlIGxhc3RpbmcNCj4gPj5pbXBhY3RzDQo+ID4+ID4+PiA+PiA+Pj4+PiByZWdh cmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksDQo+ID4+YWRk cmVzcw0KPiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhh dCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPiA+PiA+Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVh Z2VyIHRvIGRlYWwgd2l0aC4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pg0K PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVy biBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KPiA+PlNlbnQ6DQo+ID4+ID4+ PiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7 IEpvZWwgTS4NCj4gPj4gSGFscGVybjsNCj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJs ZXRvbi5jYTsgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXQ0KPiA+PlNlcnZpY2UNCj4g Pj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlz YWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcw0KPiA+PnJlZ2FyZC4NCj4gPj4gPj4+SQ0KPiA+ PiA+Pj4gPj5hbQ0KPiA+PiA+Pj4gPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNo aXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uDQo+ID4+cHJvaGliaXQNCj4gPj4gPj4+ID4+ID4+Pj4+ IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0bw0K PiA+Pkh1YW5nJ3MNCj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlp bmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPiA+PiByZXF1aXJlZA0KPiA+PiA+Pj4gPj4g Pj4+Pj4gdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4g Pj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0 byBwcm9oaWJpdCBzdWNoDQo+ID4+ID4+PiA+PiA+Pj4+PiB0aGluZ3MuIFdoZXRoZXIgdGhleSBh cmUgYSBnb29kIGlkZWEgb3Igbm90IGRlcGVuZHMgdXBvbg0KPiA+PiBtYW55DQo+ID4+ID4+PiA+ PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4g dG8gdGhpbmsNCj4gPj50aGF0DQo+ID4+ID4+PiA+PnRoZXkNCj4gPj4gPj4+ID4+ID4+Pj4+IGFy ZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+ Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcg dG8NCj4gPj5rbm93DQo+ID4+ID4+PndoYXQNCj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBu b3QgZXBsb3lhYmxlLg0KPiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJz LCBKb2VsDQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwg NTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUu DQo+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2 ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YNCj4gPj4gPj4+bWlsbGlvbnMN Cj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93 cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPiA+PiA+Pj4gPj4gPj4+ Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBp biB0aGUNCj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3 b3JsZCBvZiB0b21vcnJvdyB5b3UNCj4gYXJlDQo+ID4+IG9ubHkNCj4gPj4gPj4+ID4+IGdvaW5n DQo+ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFp bnMgd2l0aCBlcXVhbGx5IHNtYWxsDQo+ID4+ID4+PiBudW1iZXJzDQo+ID4+ID4+PiA+PiA+Pj4+ PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiA+Pj4g Pj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVl ZCBtb3JlDQo+IHRoYW4NCj4gPj4gPj4+IDY0SyINCj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4g Pj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+ID4+ ID4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gRnJvbTogc2ZjDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gW3NmYy1ib3VuY2VzQGll dGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+ID4+ID4+PiA+PiA+Pj4+PiBb am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwg SnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2E7 DQo+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPiA+PiA+Pj5Mb2FkDQo+ID4+ID4+PiA+PiA+Pj4+Pj4g QmFsYW5jZXJzDQo+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQg d2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+ID4+ID4+PmFy Y2h0aWV0dXJlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdp bGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YgdGhlaXINCj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2Vz LiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQNCj4gdXNlDQo+ ID4+IG9mDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90 IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJh bCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZSBkb2VzDQo+ID4+ID4+PnBl cm1pdA0KPiA+PiA+Pj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4N Cj4gPj4gPj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhl IGFyY2h0aWVjdHVyZQ0KPiBwZXJtaXRzDQo+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFz IHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieQ0KPiA+PnRoZQ0KPiA+ PiA+Pj53b3JrLg0KPiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPiA+PiA+Pj4gPj4gPj4+ Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4gPj4gPj4+ID4+ID4+Pj4+Pg0K PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcg d3JvdGU6DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNl cnZpY2UgY2hhaW5zLCBpdCB3aWxsIG1lYW4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAw MCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZyB0YWJsZQ0KPiA+Pm9mIGEN Cj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToN Cj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2Yg ZGVwbG95bWVudHMsIGZyb20gMQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRv IDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGUgdGhhdA0KPiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5 DQo+ID4+Y2hvb3NlDQo+ID4+ID4+PnRvDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBhdm9pZCBhbnkg dXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZA0KPiA+PiBwcm92aXNpb24N Cj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElF UkFMQSwgTUFSSUEgSCB3cm90ZToNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVu dGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgaG9wDQo+ID4+IHNlcnZpY2UNCj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYNCj4gT2YNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4g Pj4zOjAzDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGpt aEBqb2VsaGFscGVybi5jb207DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1pa2Vi aWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4gQ2hhaW5zLA0KPiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5 OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcu IEnCuWQNCj4gPj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUg bWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+ID4+IGRl cml2ZQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNz b2NpYXRlZCB0cmFuc3BvcnQuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8g c2ltcGx5DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAo b3IgZ3JhcGgpIHRoYXQgcGFja2V0cyBtdXN0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVy c2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9u IHRoaXMNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBs ZW1lbnRlZC4gVGhlIHBhdGgNCj4gPj4gaWRlbnRpZmllcg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4NCj4g Pj4gcmVzdWx0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwg b3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMp Lg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0 LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9u Z0BodWF3ZWkuY29tDQo+ID4+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZg0KPiB0 aGUNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2 ZSB0aGUgZm9yd2FyZGluZw0KPiA+PmFjdGlvbnMuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9u IEJlaGFsZg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+DQo+ID4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+ID4+ID4+PiA+PiBKdWx5DQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86Km1pa2ViaWFuY0Bhb2wu Y29tDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1o QGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpz ZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTogW3NmY10gU2VydmljZQ0KPiA+PkNoYWlucywNCj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBl eHBsaWNpdGx5IGEgc2VydmljZSBwYXRoDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmll ci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmUNCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1 bGwga25vd2xlZGdlIG9mDQo+ID4+IGV2ZXJ5DQo+ID4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUg U0ZDDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZD LWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlm aWVkDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95 bWVudCBjb250ZXh0cy4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24NCj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQg d2lsbA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRz OiB0aGF0IGlzIHRoZSBvbmUNCj4gcmVxdWlyZWQNCj4gPj4gdG8NCj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0K PiA+PnVzZWQgdG8NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJkaW5nDQo+ID4+ ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1dGlv bi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gTWVkDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGEgcGFydA0KPiA+ PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4gPj4g anVpbGxldA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxo YWxwZXJuLmNvbQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0 Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+ID4+Q2hhaW5zLA0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGDQo+ID4+IENoYWluDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYW5kIFNGDQo+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4gPj5j bGVhciB0bw0KPiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVz DQo+ID4+b24NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRo YXQgaXMgc3RpbGwgdW5jbGVhciBpcyB3aGV0aGVyDQo+ID4+aXQgaXMNCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdo YXQNCj4gPj50aGUgSUQNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0K PiA+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNl ICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0DQo+ID4+c2ltcGx5DQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxs b3dpbmcgb3RoZXIgZHJhZnRzDQo+ID4+dG8NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRl IHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+IG9yDQo+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcg0KPiA+PiA+ Pj4gPj4gPj4+Pj4gcGF0aCB0bw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQg aW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3Vs ZCBoYXZlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBT RkMgYmUgc3VwcG9ydGVkIChvciBtYWtlDQo+ID4+IG9uZQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4gdmVuZG9y cw0KPiA+PiBvbmx5DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90 aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+Pg0KPiA+PiA+Pj4N Cj4gPj4NCj4gPj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPiA+PiA+Pj4+ Pj4+Pj4+LS0NCj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipqbWhAam9lbGhhbHBl cm4uY29tPGptaEBqb2VsaGFscGVybi5jb20NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQo+ICpT ZW50OipUdWVzZGF5LA0KPiA+PiBKdWx5DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAq U3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFy bHkgYW5zd2VyDQo+ID4+YQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50 cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPiA+PiA+Pj4gcHJvcG9zZWQNCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBj YW4gZ2V0DQo+IHdvcmtpbmcNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQg b24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvDQo+IGltcHJvdmUNCj4gPj4gdGhlDQo+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBh cnRpY2lwYXRlZCBpbg0KPiA+PnRoZQ0KPiA+PiBXRw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRp c2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4gPj4gPj4+ID4+ID4+Pj4+ IHdvcmtpbmcNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5k PyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkNCj4gPj5wZXJzb25hbA0KPiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQg dG8ga2VlcCBpbiBtaW5kIHRoYXQNCj4gPj53aGF0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug YXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlDQo+ID4+ IG5vdA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBm b3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3MNCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsIHZp cnR1YWwNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50 LCBhbmQgbWFueSBvdGhlcg0KPiA+PiBhc3BlY3RzLg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdo aWNoIGNsZWFybHkgbmVlZA0KPiB0bw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRo ZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgNCj4gPj5hYm92ZQ0KPiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPiA+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rp b25pbmcsDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWly ZWQgYnkgdGhlIHdvcmsgd2UgYXJlDQo+IGRvaW5nLg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMg c2VydmljZSBwYXRoLCBhcyBJDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPiA+ PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0DQo+ID4+bGVhc3QNCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5n IGNhbiBhbmQgd2lsbA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2Vydmlj ZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlDQo+ID4+bW9yZS4NCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIG9m DQo+ID4+dGhlc2UsDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRo YXQgYW55IHBhcnRpY3VsYXIga2luZA0KPiA+PiA+Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92 aWRlZCB0byB0aGUgZW5kDQo+ID4+dXNlci4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlz IGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlciBwYWNrZXRzLA0KPiA+PmFuZA0K PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+ID4+ID4+PiA+PiA+Pj4+ PiBtYXJrcw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hv b3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4gPj5pbnN0YW5jZQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQNCj4g Pj5zZXJ2aWNlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBp bmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuDQo+ID4+SXQncw0KPiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+ID4+ IGNoYWluaW5nIGlzDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5 IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+ID4+YXJjaHRpZWN0dXJlLg0KPiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+ICBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBh DQo+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rp b24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2Fk IGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNhbg0KPiA+PmhhdmUNCj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB3aGF0DQo+ID4+ID4+PiA+PiA+Pj4+PiBhcHBlYXJzDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50 DQo+ID4+b2YNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+ID4+ID4+PiA+PiA+Pj4+ PiBmb3IgYQ0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4gPj5ieSBhDQo+ID4+ID4+PiA+PiA+Pj4+PiBj b2xsZWN0aW9uIG9mDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBt YWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvcg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1v c3RseSwgdGhpcyBpcw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+ID4+bWVjaGFuaXNtcy4NCj4gPj4gSXQNCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMg Y29udHJvbA0KPiA+Pm1lY2hhbmlzbXMsDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0 aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kDQo+ID4+dm0NCj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBh Y3Qgb2YgcGVybWl0dGluZw0KPiA+PnRoaXMNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJn ZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyDQo+ID4+dGVybWlub2xvZ3kN Cj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+ID4+ID4+PiA+PiA+Pj4+PiBy ZWFkZXJzIHRvDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5n IGl0Lg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhl cmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBzZWxlY3RpbmcNCj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBwYWNrZXQgcGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQg ZGlyZWN0DQo+ID4+dHJhZmZpYw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBw bGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmUNCj4gdGhhdA0KPiA+PmENCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9u ZSBwbGFjZSBpbiB0aGUNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBj YXNlIHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLiBJDQo+ID4+IHRlbmQNCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0bw0KPiA+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNl DQo+ID4+Y2hhaW5pbmcNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBh cyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIgaXMNCj4gPj5hDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25l Lg0KPiBUaHVzLA0KPiA+PiB0aGUNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBl IDMgbG9hZCBiYWxhbmNpbmcNCj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50 DQo+ID4+c2luZ3VsYXINCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2Vydmlj ZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbg0KPiA+PnRoZQ0KPiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFi b3V0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRo LyBTZXJ2aWNlIGNoYWluIGlzIGENCj4gPj4gc2VxdWVuY2UNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0IG9mDQo+ID4+ cGFja2V0cy4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWlu ZyB0aGF0IHNvbWUgc3Vic2V0IG9mIHRyYWZmaWMNCj4gPj5pcw0KPiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCBmaXJld2Fs bA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBn byBkaXJlY3RseSB0byB0aGUgY2FjaGUNCj4gPj4gPj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBl bm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBwYWNrZXRzLg0KPiBBDQo+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ug b2YNCj4gPj5sb2NhdGlvbnMNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4g VGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3INCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4g Pj5tYXkgYmUNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4g VGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzDQo+IHBvcnRzDQo+ID4+IG9uDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZQ0K PiA+PmxvY2F0aW9ucw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUg c2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZQ0KPiBhbmQNCj4gPj4gdGhlDQo+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMgZ3JvdXAsDQo+ID4+IHdlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUN Cj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwg YWJzdHJhY3Rpb24sIHRoZQ0KPiA+PnNlcnZpY2UNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFp biwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0bw0KPiB0YWxrDQo+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3 aWxsIHRha2UgaW4gdGhlDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1l bnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZQ0KPiBwYXRoDQo+ID4+IG1heQ0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVy ZSBkZWFscw0KPiA+PndpdGgNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3 byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgb24NCj4gPj5sb2FkDQo+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFu ZCBiZWhhdmlvcnMNCj4gPj4gd2hpY2gNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNp YmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+ID4+bXVjaA0KPiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExB TiBpcyBsYXJnZWx5DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcg YmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+IHByb3Zpc2lvbg0KPiA+PiB3ZQ0KPiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVu DQo+ID4+IG5lY2Vzc2FyeS4NCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0 IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRo aXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQNCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3Jr aW5nDQo+ID4+IGdyb3VwLA0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0 IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkDQo+IHRvDQo+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhl DQo+ID4+IGludGVudCwNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291 cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZw0KPiA+Pmdyb3VwDQo+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBz dXJlDQo+ID4+d2hhdCB0bw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNmYw0KPiA+PiA+Pj4gPj4g bWFpbGluZw0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiBzZmMNCj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4gc2ZjDQo+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNm Y0BpZXRmLm9yZw0KPiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4gPj4g Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzZmMNCj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNA aWV0Zi5vcmcNCj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Zj DQo+ID4+ID4+PiBtYWlsaW5nDQo+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ID4+PiA+PiA+Pj4+Pj4g c2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+PiA+PiA+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4gPj4g Pj4+IG1haWxpbmcNCj4gPj4gPj4+ID4+IGxpc3QNCj4gPj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRm Lm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+Pj4g Pj4gPj4+Pg0KPiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXyBzZmMNCj4gPj4gbWFpbGluZw0KPiA+PiA+Pj4gPj4gbGlzdA0KPiA+ PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ID4+IG1haWxpbmcN Cj4gPj4gPj4+ID4+IGxpc3QNCj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ ID4+PiA+PiA+Pj4NCj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4gPj4gPj4gc2ZjIG1h aWxpbmcgbGlzdA0KPiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnDQo+ID4+ID4+PiA+PiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+Pj4gPj4gPj4N Cj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPj4g Pj4+ID4+ID5zZmNAaWV0Zi5vcmcNCj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+Pj4gPj4NCj4gPj4gPj4+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4+IHNm YyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPg0KPiA+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPnNmYyBtYWlsaW5n IGxpc3QNCj4gPj4gPnNmY0BpZXRmLm9yZw0KPiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Fri Jul 11 08:35: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 AD9DC1B2BB1 for ; Fri, 11 Jul 2014 08:35:35 -0700 (PDT) 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_29=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 g6nH5k-wEYB8 for ; Fri, 11 Jul 2014 08:35:29 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2621B2BB2 for ; Fri, 11 Jul 2014 08:35:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 33F7E240914; Fri, 11 Jul 2014 08:35:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 44B1024066E; Fri, 11 Jul 2014 08:35:09 -0700 (PDT) Message-ID: <53C0041E.6050605@joelhalpern.com> Date: Fri, 11 Jul 2014 11:34:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/F2geHCeUvFPHszxOty9IakwukYI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:35:35 -0000 I agree that the current text treats the SFP is selecting a specific sequence of SFFs. Note that the selection is still mediated by the configuration in the SFFs which act on the service path information in the header. So what I am suggesting, to address your concern, is that we relax the (implicit) requirement that the mapping to the next-SFF be singular. We will describe how it can be multiple sufficiently equivalent next-SFFs. Jim's reading of the document is that such multiplicity was already allowed. By making it explicit, we will avoid any confusion. This should then allow: Some traffic distribution management by service path selection Some traffic distribution management by load balancing between the SFF and the actual service functions it is connecting. And some traffic distribution management by the use of multiple next-SFF at some SFF, in a variety of fashions. Yours, Joel On 7/11/14, 11:26 AM, NAPIERALA, MARIA H wrote: > Jim, > > Could you tell us what is the definition of a "service path" and a "service path identifier"? > If a service path means that all SF instances are chosen apriori (which is my current understanding) then it is not SFF's local decision which next-hop SFF to pick. It is a centralized decision. > > Maria > > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Friday, July 11, 2014 11:15 AM >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. >> Halpern; Ron Parker; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> I’m sorry but I really don’t understand why a service path identifier >> prevents full distribution of SF next-hops or why calling it a service >> chain identifier makes any difference? >> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" wrote: >> >>> Ditto. >>> >>>> -----Original Message----- >>>> From: mohamed.boucadair@orange.com >>>> [mailto:mohamed.boucadair@orange.com] >>>> Sent: Friday, July 11, 2014 10:31 AM >>>> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron >>>> Parker; sfc@ietf.org >>>> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> Re-, >>>> >>>> For what I can say at best this is not described clearly in the draft. >>>> >>>> Mandating a service path identifier is in itself a hint that the full >>>> distributed >>>> model is not allowed. >>>> >>>> Several voices in this thread indicated that the service chain itself >>>> should be >>>> provided instead. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >>>>> (jguichar) >>>>> Envoyé : vendredi 11 juillet 2014 16:18 >>>>> À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org >>>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Ok but where in the architecture specifically is this functionality >>>>> prohibited? If you want to distribute *all* next-hops to *all* SFF’s >>>>> within the SFC domain and then let the path identifier point to a >>>> lookup >>>>> into those next-hops to reach the next SF in the chain, I am not sure >>>> how >>>>> the architecture prevents that? >>>>> >>>>> On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" >> wrote: >>>>> >>>>>> Absolutely. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>>>> (jguichar) >>>>>>> Sent: Friday, July 11, 2014 9:54 AM >>>>>>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>> >>>>>>> Then I misunderstand the proposal ;-) .. However, it seems to me >>>> that if >>>>>>> you allow an SFF to make a decision as to which remote SFF it will >>>> use >>>>>>> for >>>>>>> a given flow to reach the next SF within the chain then you better >>>> make >>>>>>> sure that that remote SFF has the necessary forwarding logic to >>>> reach >>>>>>> the >>>>>>> next-next-SF for the chain as otherwise you are in deep trouble. >>>>>>> >>>>>>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" >>>> wrote: >>>>>>> >>>>>>>> Absolutely not. Service chains can be instantiated only in relevant >>>>>>> SFFs >>>>>>>> when they "arrive". >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>>>>>> (jguichar) >>>>>>>>> Sent: Friday, July 11, 2014 9:27 AM >>>>>>>>> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>> >>>>>>>>> Well I think it is even worse than that if I have understood the >>>>>>>>> proposal >>>>>>>>> correctly as it would require full knowledge of every single SF >>>>>>> within >>>>>>>>> the >>>>>>>>> entire SFC domain at every single SFF as there is no way to know >>>> a >>>>>>>>> priori >>>>>>>>> which SFC¹s a given SFF will need to service at any given point >>>> in >>>>>>> time. >>>>>>>>> >>>>>>>>> On 7/10/14, 11:53 PM, "Joel M. Halpern" >>>> wrote: >>>>>>>>> >>>>>>>>>> Ron, thinking about this, I realized another major problem with >>>> the >>>>>>>>> your >>>>>>>>>> proposal as I understand it. (And I readily admit I may not >>>>>>> understand >>>>>>>>>> it.) >>>>>>>>>> >>>>>>>>>> The proposal has each SFF serve as the load balancer for the >>>> next >>>>>>>>>> service function that follows it (not the one it delivers to), >>>> in >>>>>>> every >>>>>>>>>> service chain that goes through it. >>>>>>>>>> >>>>>>>>>> Since it has to be able to work with all services, that means >>>> that >>>>>>>>> every >>>>>>>>>> SFF would have to be a full, flow sensitive and stateful load >>>>>>> balancer. >>>>>>>>>> I ahve no problem if some SFF are flow sensitive, and / or >>>> stateful. >>>>>>>>>> But having the architecture require that every SFF be a full, >>>> flow >>>>>>>>>> sensitive, stateful, load balancer seems to me to be an >>>> acceptable >>>>>>>>>> imposition. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>>>>>>>>>> Part of my personal view is that I am trying to make this work >>>>>>>>> sensibly >>>>>>>>>>> in a more orchestrated environment. I expect that the service >>>>>>>>>>> functions, and over time probably the SFF capabilities, will >>>> be >>>>>>>>>>> orchestrated and installed. I expect the service chains to be >>>>>>>>> driven by >>>>>>>>>>> BSS tools that define offerings to clients, and enable >>>>>>> self-selection >>>>>>>>>>> from these. I expect service paths to be heavily policy >>>> drive. >>>>>>>>>>> >>>>>>>>>>> I can see how to make all of that work in an archtiecture >>>> driven >>>>>>> by >>>>>>>>>>> initial classification to described service paths. It is >>>> harder >>>>>>> to >>>>>>>>> see >>>>>>>>>>> how to make it work (but it can be done) when we allow more >>>>>>>>> dynamicity >>>>>>>>>>> in the network behavior. >>>>>>>>>>> >>>>>>>>>>> Having said that, most of that perspective I described is >>>> outside >>>>>>> of >>>>>>>>> the >>>>>>>>>>> scope of the working group. it is not something we are >>>> tasked to >>>>>>>>> agree >>>>>>>>>>> on. >>>>>>>>>>> So I do not claim that vision means we have to do it a certain >>>>>>> way. >>>>>>>>> it >>>>>>>>>>> is just the perspective that drives my preferences. >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>>>>>>>>> For me, the amount of information about service instances >>>> that >>>>>>>>> needs >>>>>>>>>>>>> to >>>>>>>>>>>>> be widely distributed and maintained, potentially even >>>> across >>>>>>> data >>>>>>>>>>>>> centers within an administrative scope, is large enough and >>>>>>> complex >>>>>>>>>>>>> enough that trying to get that into each SFF seems like a >>>>>>> difficult >>>>>>>>>>>>> architecture to realize. >>>>>>>>>>>> >>>>>>>>>>>> I'm curious as to why that is more complicated than dynamic >>>>>>> routing, >>>>>>>>>>>> hyper-scale data center orchestration, or DNS, all of which >>>> are >>>>>>>>> bigger >>>>>>>>>>>> problems that have been profitably and stably implemented? >>>>>>>>>>>> >>>>>>>>>>>> It also seems that if it really is more complicated, that is >>>> a >>>>>>> good >>>>>>>>>>>> sign that it is too complicated. >>>>>>>>>>>> >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] >>>>>>>>>>>> Sent: Thursday, July 10, 2014 9:45 PM >>>>>>>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian >>>>>>> Smith; >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>> >>>>>>>>>>>> This is an architectural issue. And one that I would prefer >>>> we >>>>>>>>>>>> actually >>>>>>>>>>>> decide, rather than trying to allow all possible >>>> implementations. >>>>>>>>>>>> Because it does have a major effect on the control >>>> requirements >>>>>>> and >>>>>>>>> the >>>>>>>>>>>> functionality of SFFs. >>>>>>>>>>>> >>>>>>>>>>>> For me, the amount of information about service instances >>>> that >>>>>>> needs >>>>>>>>> to >>>>>>>>>>>> be widely distributed and maintained, potentially even >> across >>>>>>> data >>>>>>>>>>>> centers within an administrative scope, is large enough and >>>>>>> complex >>>>>>>>>>>> enough that trying to get that into each SFF seems like a >>>>>>> difficult >>>>>>>>>>>> architecture to realize. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> But it is a fair question. >>>>>>>>>>>> >>>>>>>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>>>>>>>>>> This is the crux of my issue. Is the end to end selection >>>> of >>>>>>>>>>>>> (top-level) instances performed centrally (perhaps by the >>>>>>>>> classifier) >>>>>>>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently >>>> the >>>>>>>>> SFFs)? >>>>>>>>>>>>> Such selection is not equivalent to reclassification. And >>>>>>> surely, >>>>>>>>>>>>> this is an architectural issue and not relegated to >>>>>>>>>>>>> "implementation". >>>>>>>>>>>>> >>>>>>>>>>>>> My own view is to favor the distributed approach even >> though >>>> a >>>>>>>>>>>>> greater amount of data (chain definitions and perhaps local >>>>>>>>> selection >>>>>>>>>>>>> policy) is required at those distributed decision points. >>>> This >>>>>>>>>>>>> approach does not require an end-to-end path id at all. >>>> My >>>>>>>>>>>>> rationale for favoring this approach is primarily driven by >>>>>>>>> increased >>>>>>>>>>>>> resiliency over the global path id approach. With a global >>>>>>> path >>>>>>>>> id >>>>>>>>>>>>> approach, consider failure of an instance and needing to >>>> alter >>>>>>> the >>>>>>>>>>>>> global path ID table for each and every affected end-to-end >>>>>>> path. >>>>>>>>>>>>> >>>>>>>>>>>>> Ron >>>>>>>>>>>>> >>>>>>>>>>>>> ________________________________________ From: sfc >>>>>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>>>>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 >>>> 6:15 >>>>>>> PM >>>>>>>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org >> Subject: >>>> Re: >>>>>>>>>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>>> >>>>>>>>>>>>> The way the architecture models the case of SF1 needing to >>>>>>>>> influence >>>>>>>>>>>>> the chain is that one would do reclassification at the exit >>>> from >>>>>>>>>>>>> SF1. >>>>>>>>>>>>> >>>>>>>>>>>>> Part of the goal is to keep the different functions >>>> logically >>>>>>>>>>>>> separate so that solutions can clearly describe how they >>>> choose >>>>>>> to >>>>>>>>>>>>> compose them for "service" delivery. >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>>>>>>>>>> I don't see anything in the arch draft that suggests any >>>> sort >>>>>>> of >>>>>>>>>>>>>> limit. However, it does seem to indicate that the entire >>>> path >>>>>>> (all >>>>>>>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this >>>>>>> means >>>>>>>>>>>>>> either at the classifier or maybe the classifier chooses a >>>> SF >>>>>>>>> Chain >>>>>>>>>>>>>> and the NF or at the latest the first SFF. In any case, >>>> the >>>>>>>>>>>>>> language does seem to prohibit a more dynamic SFP where >>>> SFI(n) >>>>>>> is >>>>>>>>>>>>>> determined at the SFI(n-1) hop. According to the draft, >>>> this >>>>>>>>>>>>>> behavior would be considered "branching" to a new SFP as >>>>>>> opposed >>>>>>>>> to >>>>>>>>>>>>>> choosing and then forwarding to the selected instance of >>>> the >>>>>>>>>>>>>> next-hop of the current SFC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> draft-merged-sfc-architecture-00: >>>>>>>>>>>>>>> When an SFC is instantiated into the network it is >>>> necessary >>>>>>> to >>>>>>>>>>>>>>> select the specific instances of SFs that will be used, >>>> and to >>>>>>>>>>>>>>> create the service topology for that SFC using SF's >>>> network >>>>>>>>>>>>>>> locator. Thus, instantiation of the SFC results in the >>>>>>> creation >>>>>>>>>>>>>>> of a Service Function Path (SFP) and is used for >>>> forwarding >>>>>>>>>>>>>>> packets through the SFC. In other words, an SFP is the >>>>>>>>>>>>>>> instantiation of the defined SFC. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The SFC architecture supports reclassification (or >>>> non-initial >>>>>>>>>>>>>>> classification) as well. As packets traverse an SFP, >>>>>>>>>>>>>>> reclassification may occur - typically performed by a >>>>>>>>>>>>>>> classification function co-resident with a service >>>> function. >>>>>>>>>>>>>>> Reclassification may result in the selection of a new >>>> SFP, an >>>>>>>>>>>>>>> update of the associated metadata, or both. This is >>>> referred >>>>>>> to >>>>>>>>>>>>>>> as "branching". >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>>>>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> *From: *I.Smith@F5.com >>>>>>>>>>>>>> *To: *Joel Halpern >> Direct,Joel >>>> M. >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>>>>> Halpern,huang@sce.carleton.ca>>>>>>>> carleton. >>>>>>>>>>>>>> ca>,sfc@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> *Sent: *Thursday, July 10, 2014 >>>>>>>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>>> Balancers >>>>>>>>>>>>>> >>>>>>>>>>>>>> Actually, I think I am disagreeing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the possibility of medium-scale deployments (and that is >>>>>>> what >>>>>>>>>>>>>> 16 million flows is in my world) of service chains is >>>>>>> preconceived >>>>>>>>>>>>>> as an absurd idea, then the architecture burdened with >> that >>>>>>>>>>>>>> preconception. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There has to be some point of aim, some degree of >>>> aspiration >>>> to >>>>>>>>>>>>>> scale that is appropriate for the lifespan of the >>>> architecture >>>>>>> - >>>>>>>>>>>>>> you don't have to know what it is, but by saying that an >>>>>>> arbitrary >>>>>>>>>>>>>> number is "too far", you're creating - even if it isn't >>>>>>>>> intentional >>>>>>>>>>>>>> - a limit that influences decisions that have lasting >>>> impacts >>>>>>>>>>>>>> regarding scale-out, failure mitigation, elasticity, >>>> address >>>>>>>>>>>>>> space... all kinds of things. That is a problem I'm not >>>>>>>>>>>>>> particularly eager to deal with. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] >>>> Sent: >>>>>>>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>>> Halpern; >>>>>>>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >>>> Service >>>>>>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ian, I don't think you disagree with me at all in this >>>> regard. >>>>>>> I >>>>>>>>> am >>>>>>>>>>>>>> not requesting the the architecture or the solution >>>> prohibit >>>>>>>>>>>>>> deployments in the specific fashion. I am objecting to >>>> Huang's >>>>>>>>>>>>>> reading of my note as saying that such deployments are >>>> required >>>>>>>>>>>>>> they by the archtiecture. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>>>>>>>>>> things. Whether they are a good idea or not depends upon >>>> many >>>>>>>>>>>>>> factors outside of the scope of the WG. I happen to think >>>> that >>>>>>>>> they >>>>>>>>>>>>>> are usually a bad idea. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But the archtiecture si carefully avoiding attempting to >>>> know >>>>>>> what >>>>>>>>>>>>>> is and is not eployable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>>>>>>>>>> I disagree. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We routinely have stateful devices that manage tens of >>>>>>> millions >>>>>>>>>>>>>>> of >>>>>>>>>>>>>> concurrent flows in both access network and data center >>>>>>>>>>>>>> environments today. You can't seriously believe that in the >>>>>>>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you >> are >>>> only >>>>>>>>> going >>>>>>>>>>>>>> to have small numbers of service chains with equally small >>>>>>> numbers >>>>>>>>>>>>>> of active service paths? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Your sounds too much like "no one will ever need more >> than >>>>>>> 64K" >>>>>>>>>>>>>>> for >>>>>>>>>>>>>> comfort. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ________________________________________ From: sfc >>>>>>>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>>>>>>>>>> [jmh@joelhalpern.com] >>>>>>>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>>>>>> huang@sce.carleton.ca; >>>>>>>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and >>>>>>> Load >>>>>>>>>>>>>>> Balancers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No, it will mean that if someone tries to deploy the >>>>>>> archtieture >>>>>>>>>>>>>>> particularly badly, they will exceed the limits of their >>>>>>>>>>>>>>> devices. The architecture does not require such absurd >> use >>>> of >>>>>>>>>>>>>>> service paths. Since I can not figure out how to write >>>>>>>>>>>>>>> architectural words to prohibit it, the architecture does >>>>>>> permit >>>>>>>>>>>>>>> such abuse. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please do not read my saying that the archtiecture >> permits >>>>>>>>>>>>>>> something as saying it is either deisred or required by >>>> the >>>>>>> work. >>>>>>>>>>>>>>> It isn't. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>>>>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>>>>>>>>>> 16,000,000 paths. That is larger than the routing table >>>> of a >>>>>>>>>>>>>>>> core router. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Chang >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>>>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>>>>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>>>>>>>>>>> operators are prepared for the complexities if they >>>> choose >>>>>>> to >>>>>>>>>>>>>>>>> avoid any use of local load balancing and in stead >>>> provision >>>>>>>>>>>>>>>>> 160,000 service paths. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>>>>>> Paul, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> How many path identifiers there will be for a 4 hop >>>> service >>>>>>>>>>>>>>>>>> chain with 20 instances at each hop? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Maria >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >> Of >>>>>>>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 >>>> 3:03 >>>>>>>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service >> Chains, >>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Lucy, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>>>>>>>>>> forwarding. I¹d >>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>> the minor change: the path identifier can be used to >>>> derive >>>>>>>>>>>>>>>>>> the needed forwarding and associated transport. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>>>>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>>>>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>>>>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>>>>>>>>>>> thread can be simply be implemented. The path >>>> identifier >>>>>>>>>>>>>>>>>> provides nothing more than a lookup, that lookup can >>>> result >>>>>>>>>>>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>>>>>>>>>>> hop(s). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of >> the >>>>>>>>>>>>>>>>>> service path identifier to drive the forwarding >>>> actions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Lucy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>>>>>>>>>> >>>>>>> *Sent:*Thursday, >>>>>>>>> July >>>>>>>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>>>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>>>>>>> *Subject:*Re: [sfc] Service >>>> Chains, >>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Re-, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>>>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>>>>>>>>>>> forwarding actions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of >>>> every >>>>>>>>>>>>>> available SFC >>>>>>>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>>>>>>>>>> required/justified >>>>>>>>>>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>> that will >>>>>>>>>>>>>>>>>> be present in all deployments: that is the one >> required >>>> to >>>>>>>>>>>>>>>>>> structure a service chain. How that information is >>>> used to >>>>>>>>>>>>>>>>>> infer forwarding >>>>>>>>>>>>>> actions >>>>>>>>>>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Med >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>>>>>>>>>> de*mikebianc@aol.com >>>>>>>>>>>>>>>>>> *Envoyé :*mercredi 9 >>>> juillet >>>>>>>>>>>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>>>>>>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>>>>>>> *Objet :*Re: [sfc] Service >>>> Chains, >>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is anyone still questioning the difference between SF >>>> Chain >>>>>>>>>>>>>>>>>> and SF >>>>>>>>>>>>>> Path? >>>>>>>>>>>>>>>>>> Other than clarifying the definition so that it's >>>> clear to >>>>>>>>>>>>>> those not >>>>>>>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees >>>> on >>>>>>>>>>>>>>>>>> these terms. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To me, the one point that is still unclear is whether >>>> it is >>>>>>>>>>>>>>>>>> the intent of this draft to ultimately specify what >>>> the ID >>>>>>>>>>>>>>>>>> of the SFC Header >>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>> reference (the chain or the path), or if this draft >>>> simply >>>>>>>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts >>>> to >>>>>>>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain >> or >>>>>>>>>>>>>>>>>> path and the choice of chain or >>>>>>>>>>>>>> path to >>>>>>>>>>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>>>>>>>>>> require that both SFP and SFC be supported (or make >>>> one >>>>>>>>>>>>>>>>>> required and the other optional) to avoid some >> vendors >>>> only >>>>>>>>>>>>>>>>>> supporting SFP and others only supporting SFC. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>>>>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>>>>>>>>>> >>>> > >>>>>>>>>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>>>>>>>>> > >> *Sent:*Tuesday, >>>> July >>>>>>>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>>>>>>>>>>> Balancers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have been trying to figure out how to clearly answer >>>> a >>>>>>>>>>>>>>>>>> number of comments that have been made about the >>>>>>> proposed >>>>>>>>>>>>>>>>>> merged archtiecture draft. Assuming we can get >> working >>>>>>>>>>>>>>>>>> group agreement on the intent, we will work to >> improve >>>> the >>>>>>>>>>>>>>>>>> wording so that readers who have not participated in >>>> the >>>> WG >>>>>>>>>>>>>>>>>> discussion will understnd it the way the >>>>>>>>>>>>>> working >>>>>>>>>>>>>>>>>> group intends. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But what do we intend? I will try to explain my >>>> personal >>>>>>>>>>>>>>>>>> view, and see if that helps. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In this regard, it is important to keep in mind that >>>> what >>>>>>>>>>>>>>>>>> we are defining is the data plane architecture. We are >>>> not >>>>>>>>>>>>>>>>>> attempting to define the architecture for the entire >>>>>>>>>>>>>>>>>> solution for service chaining. That would encompass >>>>>>>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>>>>>>>>>>> machine and image management, and many other >>>> aspects. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As a result there are many things which clearly need >> to >>>>>>>>>>>>>>>>>> exist in the larger system, but which are dealt with >>>> above >>>>>>>>>>>>>>>>>> where we are >>>>>>>>>>>>>> functioning, >>>>>>>>>>>>>>>>>> and are not directly required by the work we are >> doing. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>> them, >>>>>>>>>>>>>>>>>> I need to first discuss load balancing. There are at >>>> least >>>>>>>>>>>>>>>>>> three different ways that load balancing can and will >>>>>>>>>>>>>>>>>> interact with service chaining. There probably are >>>> more. >>>>>>>>>>>>>>>>>> The point of the archtiecture is to permit all of >>>> these, >>>>>>>>>>>>>>>>>> but not to mandate that any particular kind >>>>>>>>>>>>>> be used >>>>>>>>>>>>>>>>>> in any solution. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1) Load balancing as a service provided to the end >>>> user. >>>>>>>>>>>>>>>>>> This is a service function. It receives user packets, >>>> and >>>>>>>>>>>>>>>>>> modifies them (or >>>>>>>>>>>>>> marks >>>>>>>>>>>>>>>>>> them, or ...) so as to choose an end user service >>>> instance >>>>>>>>>>>>>>>>>> to receive the users packet. This is an important >>>> service >>>>>>>>>>>>>>>>>> function to be able to include in service chaining. >>>> It's >>>>>>>>>>>>>>>>>> behavior may affect requirements on how service >>>> chaining is >>>>>>>>>>>>>>>>>> done. But it has very little impact on the >>>> archtiecture. >>>>>>>>>>>>>>>>>> From an architectural pe3rspective it is simply a >>>>>>>>>>>>>> service >>>>>>>>>>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2) There is internal load balancing. That is, one can >>>> have >>>>>>>>>>>>>>>>>> what >>>>>>>>>>>>>> appears >>>>>>>>>>>>>>>>>> to the service chaining architecture as a single point >>>> of >>>>>>>>>>>>>>>>>> contact >>>>>>>>>>>>>> for a >>>>>>>>>>>>>>>>>> specific service function, but is actually delivered >>>> by a >>>>>>>>>>>>>> collection of >>>>>>>>>>>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>>>>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>>>>>>>>>>> invisible to the service chaining data plane >>>> mechanisms. >>>> It >>>>>>>>>>>>>>>>>> is likely that it is visible to various control >>>> mechanisms, >>>>>>>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and >>>> vm >>>>>>>>>>>>>>>>>> instantiation. The architectural impact of permitting >>>> this >>>>>>>>>>>>>>>>>> is largely that we need to be careful that our >>>> terminology >>>>>>>>>>>>>>>>>> does not lead >>>>>>>>>>>>>> readers to >>>>>>>>>>>>>>>>>> think we are prohibiting it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>>>>>>>>>>> packet paths for the service chaining that direct >>>> traffic >>>>>>>>>>>>>>>>>> to different places. We would not want to require >> that >>>> a >>>>>>>>>>>>>>>>>> given service function appear at only one place in the >>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It is of course the case that these may be combined. I >>>> tend >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>> refer to >>>>>>>>>>>>>>>>>> the collection of entities that appear to service >>>> chaining >>>>>>>>>>>>>>>>>> as a single point as a cluster. Not because cluster is >>>> a >>>>>>>>>>>>>>>>>> good term. But because I do not have another one. >> Thus, >>>> the >>>>>>>>>>>>>>>>>> point of type 3 load balancing >>>>>>>>>>>>>> is to >>>>>>>>>>>>>>>>>> direct different subsets of traffic to different >>>> singular >>>>>>>>>>>>>>>>>> or clustered service functions in different places in >>>> the >>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>>>>>>>>>> service chain and service path/ Service chain is a >>>> sequence >>>>>>>>>>>>>>>>>> of logical functions to be applied to a subset of >>>> packets. >>>>>>>>>>>>>>>>>> It is equivalent of saying that some subset of traffic >>>> is >>>>>>>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>>>>>>>>>>> while a different subset is to go directly to the cache >>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>> visiting any other service functions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> That is not enough information to direct the packets. >> A >>>>>>>>>>>>>>>>>> service path is, in some fashion, a sequence of >>>> locations >>>>>>>>>>>>>>>>>> in the network. Those locations will be singular or >>>>>>>>>>>>>>>>>> clustered service function delivery locations. They >>>> may be >>>>>>>>>>>>>>>>>> addressed by IP address. They may be addressed as >> ports >>>> on >>>>>>>>>>>>>>>>>> an SFF. There are many different ways that the >>>> locations >>>>>>>>>>>>>>>>>> may be known to the service chaining infrastructure >> and >>>> the >>>>>>>>>>>>>>>>>> transport. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> From the point of view of the work of the SFC group, >>>> we >>>>>>>>>>>>>>>>>>> need to be >>>>>>>>>>>>>>>>>> able to talk about the high level abstraction, the >>>> service >>>>>>>>>>>>>>>>>> chain, which drives the forwarding. And we need to >> talk >>>>>>>>>>>>>>>>>> about the actual data path packets will take in the >>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Several of the comments have said "but the whole >> path >>>> may >>>>>>>>>>>>>>>>>> not be known at the front." This architecture deals >>>> with >>>>>>>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on >>>> load >>>>>>>>>>>>>>>>>> balancers above, there can be decisions and behaviors >>>> which >>>>>>>>>>>>>>>>>> are invisible to the service chaining mechanisms (in >>>> much >>>>>>>>>>>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>>>>>>>>>>> invisible to routing between LANs.) The other >> provision >>>> we >>>>>>>>>>>>>>>>>> make is >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> reclassification can be done in mid-chain when >>>> necessary. >>>>>>>>>>>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>>>>>>>>>>> information available at the re-classification point. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>>>>>>>>>>> does, and if the intent is acceptable to the working >>>> group, >>>>>>>>>>>>>>>>>> we can figure out what additional words are needed >> to >>>>>>>>>>>>>>>>>> convey this. If the working group disagree with the >>>> intent, >>>>>>>>>>>>>>>>>> then we will of course adjust to match the working >>>> group >>>>>>>>>>>>>>>>>> agreements. If this is still unclear, I am not sure >>>> what to >>>>>>>>>>>>>>>>>> try next. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> _______________________________________________ >>>> sfc >>>>>>>>> mailing >>>>>>>>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> _______________________________________________ >>>> sfc >>>>>>>>> mailing >>>>>>>>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >> _______________________________________________ >>>> sfc >>>>>>>>> mailing >>>>>>>>>>>>>>>>> list sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >> sfc >>>>>>>>> mailing >>>>>>>>>>>>>>>> list sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >> sfc >>>>>>> mailing >>>>>>>>> list >>>>>>>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ sfc >>>>>>> mailing >>>>>>>>> list >>>>>>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ sfc >>>> mailing >>>>>>>>> list >>>>>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ sfc >>>> mailing >>>>>>>>> list >>>>>>>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing 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 Jul 11 08:44: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 695E51A0503 for ; Fri, 11 Jul 2014 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 soHKZmlQXcjc for ; Fri, 11 Jul 2014 08:44:17 -0700 (PDT) Received: from omr-d07.mx.aol.com (omr-d07.mx.aol.com [205.188.109.204]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9984F1B2B14 for ; Fri, 11 Jul 2014 08:44:15 -0700 (PDT) Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-d07.mx.aol.com (Outbound Mail Relay) with ESMTP id C99DA7029DFCF; Fri, 11 Jul 2014 11:44:14 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 64B3D3800009C; Fri, 11 Jul 2014 11:44:14 -0400 (EDT) Date: Fri, 11 Jul 2014 11:44:14 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com Message-ID: <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3036_250657991.1405093454290" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405093454; bh=fC+Zwm6c9e/eda8IwmTar5pY3B5DUwdin4REhB6BDac=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kT00++1AJYjiwET7zfurvJXvBPXAkdr7GHeYom3jOYKlIT26/czSV6Dh9QhnS1/JL 8fTF7ktBNR/smS1/OIh1Yb38mfp3+WLBS92F8emrCmEj6ybr0rVj9v14P3HqHr2Mre PHfqmtt62zJWYHWlcCFeUykroZ95FohQ0DJ79tcs= x-aol-sid: 3039ac1b03ce53c0064e62a9 X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ux9ytd03FWBilAfHu7vuL7l9iac Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:44:21 -0000 ------=_Part_3036_250657991.1405093454290 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When you say "20 instances of the SF2 SF" are "Connected to that SFF" do yo= u mean physically? =C2=A0I had always just assumed that if I had 20 instanc= es of a SF, that they would be diverse. =C2=A0Even if within the same datac= enter, they would be not near each other. =C2=A0It also seems like you are = saying that there is only a single SFF for SF2 and that your traffic path r= equires traversing SF2 as a separate hop from the SF2 instance. =C2=A0Ideal= ly, the traffic would flow from SF1 instance to SF2 instance over the best = path without the need for an intermediary hop. *In my statements above, I assuming that each SF Instance is SFC aware to s= implify the text. From: jguichar@cisco.com To: mikebianc@aol.com,mn1921@att.com cc: sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =E2=80=9C3. Generic SFC encapsulation: T= his document will describe a single service-level data plane encapsulation = format that indicates the sequence of service functions that make up the Service Functi= on Chain; specifies the Service Function Path=E2=80=9D. The wording here is very impo= rtant and shows that the intent is that the sequence of SF=E2=80=99s be ind= icated within the SFC encapsulation e.g. not carried =E2=80=93 this is not source routing, and specifies the SFP, hence the path identifier. For my example let=E2=80=99s assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=E2=80=99s call it =E2=80=9CSFC-= 1=E2=80=9D It is possible that each of those SF=E2=80=99s be directly addressable (i.e= . provide SFF functionality) or reachable through some other network device= that provides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF=E2=80=99s; let=E2=80=99s call = them SF1-loc1, SF2-loc2, and SF3-loc3.=20 When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier =E2=80=9C100=E2=80=9D. This information is distributed to the r= elevant network devices basically saying =E2=80=9Cif you receive an SFC enc= apsulated packet with path identifier =E2=80=9C100=E2=80=9D then use the pa= th identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=E2=80=9D. So traffic flows through the SFP with path identifier =E2=80=9C100=E2=80=9D= , via a network transport (the path identifier is encapsulated). It reaches= SF1-loc1 which uses the path identifier to determine that it is in fact th= e SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth.=20 So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From:=20 "mikebianc@aol.com" Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard , "mn1921@att.com" Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim,=20 Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at a= ll. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. From: jguichar@cisco.com To: NAPIERALA, MARIA H cc: Paul Quinn (paulq),Lucy yong,jmh= @joelhalpern.com,mohamed.boucadair@orange.com,sfc@ietf.org,mikebianc@aol.com Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com;=20 mohamed.boucadair@orange.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy,=20 Overall I concur, as you say: a path ID drives the forwarding. I=E2=80=99d = make the minor change: the path identifier can be used to derive the needed= forwarding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;jmh@joelhalpern.com;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la part de mikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. From:jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing 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_3036_250657991.1405093454290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
When you say "20 in= stances of the SF2 SF" are "Connected to that SFF" do you mean physically? =  I had always just assumed that if I had 20 instances of a SF, that th= ey would be diverse.  Even if within the same datacenter, they would b= e not near each other.  It also seems like you are saying that there i= s only a single SFF for SF2 and that your traffic path requires traversing = SF2 as a separate hop from the SF2 instance.  Ideally, the traffic wou= ld flow from SF1 instance to SF2 instance over the best path without the ne= ed for an intermediary hop.

*In my statements abov= e, I assuming that each SF Instance is SFC aware to simplify the text.
<= br>



From: jguichar@cisco.com<jguichar@cisco.com>
T= o: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@= att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: = Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, a= nd Load Balancers

Hi Mike,

There still seems to be some confusion around this topic so let me try= to provide a more detailed explanation as to how I believe this should wor= k and why what I explained earlier is in fact a path identifier and not a c= hain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =E2=80=9C3. Generic SFC encapsulation: T= his document will describe a single service-level data plane encapsulation = format that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path=E2=80=9D. The wording here is ve= ry important and shows that the intent is that the sequence of SF=E2=80=99s= be indicated within the SFC encapsulation e.g. not carried =E2=80=93 this = is not source routing, and specifie= s the SFP, hence the path identifier.

For my example let=E2=80=99s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=E2=80=99s call it = =E2=80=9CSFC-1=E2=80=9D

It is possible that each of those SF=E2=80=99s be directly addressable= (i.e. provide SFF functionality) or reachable through some other network d= evice that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 = relies on a connected switch to provide the needed SFF functionality. Conne= cted to that SFF are 20 instances of the SF2 SF. In this case you have exac= tly 3 network locators from which to choose in order to reach the required SF=E2=80=99s; let=E2=80=99s call = them SF1-loc1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locator= s are selected to construct the path, and a path identifier is allocated. I= n this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> = SF2-loc2 -> SF3-loc3 and it has a path identifier =E2=80=9C100=E2=80=9D. This information is distributed to the r= elevant network devices basically saying =E2=80=9Cif you receive an SFC enc= apsulated packet with path identifier =E2=80=9C100=E2=80=9D then use the pa= th identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=E2=80=9D.=

So traffic flows through the SFP with path identifier =E2=80=9C100=E2= =80=9D, via a network transport (the path identifier is encapsulated). It r= eaches SF1-loc1 which uses the path identifier to determine that it is in f= act the SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth.

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).


From:=20 "<= a href=3D"mailto:mikebianc@aol.com" style=3D"font-family: Calibri; font-siz= e: 11pt;" class=3D"">mikebianc@aol.com" <mikebia= nc@aol.com>

Date: Thursday, July 10, 2014 at 4:= 46 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn192= 1@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>= ;
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers


Jim,

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop? In this case, there wouldn't be any Path Identifier= at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there wil= l be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=E2=80=99d make the minor change: the path identifier can be us= ed to derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc should not man= date only use of the service path identifier to drive the forwarding action= s.

Lucy

From:sfc [mailto:sfc-bounces@ietf.org<= /a>]On Behalf Of moh= amed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com;jmh@joelhalpern.com<= /a>;sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a s= ervice path identifier. I object to use that identifier to derive forwardin= g actions.

Requiring a SFC system to have the full k= nowledge of every available SFC forwarding paths within an SFC-enabled doma= in is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the= piece of information that will be present in all deployments: that is the = one required to structure a service chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion.

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org<= /a>]De la part de mikebianc@aol.com
Envoy=C3=A9 : mercredi = 9 juillet 2014 22:03
=C3=80 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain an= d SF Path? Other than clarifying the definition so that it's clear to those= not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is th= e intent of this draft to ultimately specify what the ID of the SFC Header = should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require t= hat both SFP and SFC be supported (or make one required and the other optio= nal) to avoid some vendors only supporting SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
 ------=_Part_3036_250657991.1405093454290-- From nobody Fri Jul 11 08:55: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 EC3E21A0A8A for ; Fri, 11 Jul 2014 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 NCOHDu31fmVv for ; Fri, 11 Jul 2014 08:55:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E1C1A0A82 for ; Fri, 11 Jul 2014 08:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56744; q=dns/txt; s=iport; t=1405094120; x=1406303720; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/+ThZNESxt4TCsfiGLmz3abB/EO2wE5LxqBlbe1Ei1o=; b=iF7e1a9cjxnwgo+EeXmsCClLIlZHTOGbUR1C2soXDN0k4wDEkVO6UCIZ 9sWn40y5Q5g7e/XGHu8QjtL8pU89KWZ3E4YRw+6lAikF77VIU24ncRADm LDNyeUhgdefWn+KvuO5fU0XSi0YXcN6ARYn3Q3ZOcIvWHFzw+6qke01Y6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALQHwFOtJV2S/2dsb2JhbABPCoMOUlqCcawIkXgKh0IBGXIWdYQDAQEBBAEBARcBCAQNMQkCFQQCAQgRAQMBAQECAiMDAgICJQsUAQIGCAIEARIbiBMDEQ2tQJh/EwSBLIhRgyCBUAUsECICAgKCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="60106880" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 11 Jul 2014 15:55:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BFsvjL028039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 15:54:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 10:54:57 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Ron Parker" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AACNZ7AP//xIOA Date: Fri, 11 Jul 2014 15:54:56 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: <95FB1D46C7A7714FB323B9A61C488443@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2NRmalqJIUA2GaZBHngCG2XnUHE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:55:09 -0000 TWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQphIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFp bnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91IGRlZmluZSBhDQpjaGFpbiwgbGV0 4oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAg c3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8g ZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCkhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRv IGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQgKEkNCndpbGwgYXJndWUg dGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSku IFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBv aW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRpb24gaW50byB0 aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0Kc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWluIHRoZQ0K bmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZD IC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxk IHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50cmFsaXplZA0KY29udHJvbGxlciwgY29uZmlndXJl IHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0Kc29tZSBw cm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90IGNv cnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5z dGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkNCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2Nl cHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvDQpzby4NCg0KTGV0 4oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoNCg0KSSBk ZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBG b3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5h bWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9m IFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQphc3NpZ24g YSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRz IHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRo YXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9y bWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzDQp3aXRoIHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0 aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMg YW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQplbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFj dGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkgd2UNCmFyZSBhdCBTMiBp biB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhv cCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJl YWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxt bjE5MjFAYXR0LmNvbT4gd3JvdGU6DQoNCj5KaW0sDQo+DQo+Q291bGQgeW91IHRlbGwgdXMgd2hh dCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCBhDQo+InNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyIj8NCj5JZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBp bnN0YW5jZXMgYXJlIGNob3NlbiBhcHJpb3JpICAod2hpY2gNCj5pcyBteSBjdXJyZW50IHVuZGVy c3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoDQo+bmV4 dC1ob3AgU0ZGIHRvIHBpY2suICBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1h cmlhDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSmltIEd1 aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBG cmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEpvZWwgTS4NCj4+IEhhbHBlcm47IFJvbiBQ YXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiANCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJl YWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+ IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGlu ZyBpdCBhIHNlcnZpY2UNCj4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/ DQo+PiANCj4+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4x OTIxQGF0dC5jb20+IHdyb3RlOg0KPj4gDQo+PiA+RGl0dG8uDQo+PiA+DQo+PiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPj4gPj4g U2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+PiA+PiBUbzogSmltIEd1aWNo YXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24N Cj4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBSRTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+DQo+PiA+PiBSZS0s DQo+PiA+Pg0KPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVz Y3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+PmRyYWZ0Lg0KPj4gPj4NCj4+ID4+IE1hbmRhdGluZyBh IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVs bA0KPj4gPj5kaXN0cmlidXRlZA0KPj4gPj4gbW9kZWwgaXMgbm90IGFsbG93ZWQuDQo+PiA+Pg0K Pj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNl cnZpY2UgY2hhaW4gaXRzZWxmDQo+PiA+PnNob3VsZCBiZQ0KPj4gPj4gcHJvdmlkZWQgaW5zdGVh ZC4NCj4+ID4+DQo+PiA+PiBDaGVlcnMsDQo+PiA+PiBNZWQNCj4+ID4+DQo+PiA+PiA+LS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiA+PiA+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQNCj4+ID4+ID4oamd1aWNoYXIp DQo+PiA+PiA+RW52b3nDqSA6IHZlbmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxOA0KPj4gPj4g PsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNm Y0BpZXRmLm9yZw0KPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+DQo+PiA+PiA+T2sgYnV0IHdoZXJlIGluIHRo ZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eQ0KPj4gPj4g PnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4dC1ob3BzIHRv ICphbGwqIFNGRuKAmXMNCj4+ID4+ID53aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0 IHRoZSBwYXRoIGlkZW50aWZpZXIgcG9pbnQgdG8gYQ0KPj4gPj5sb29rdXANCj4+ID4+ID5pbnRv IHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0g bm90DQo+PnN1cmUNCj4+ID4+aG93DQo+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0 aGF0Pw0KPj4gPj4gPg0KPj4gPj4gPk9uIDcvMTEvMTQsIDk6NTggQU0sICJOQVBJRVJBTEEsIE1B UklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4gPj5BYnNv bHV0ZWx5Lg0KPj4gPj4gPj4NCj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmltIEd1aWNoYXJkDQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gU2VudDog RnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBN QVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4gPj4g Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHBy b3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZQ0KPj4gPj50aGF0IGlmDQo+PiA+ PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVt b3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0KPj4gPj4gPj4+Zm9yDQo+PiA+PiA+Pj4gYSBn aXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UN Cj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZG IGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8NCj4+ID4+cmVhY2gNCj4+ID4+ ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lz ZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IE9uIDcvMTEv MTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4+ID4+ IHdyb3RlOg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNo YWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4+cmVsZXZhbnQNCj4+ID4+ID4+PlNG RnMNCj4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4gPj4gPj4+ID4NCj4+ID4+ID4+ PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4+ID4+IEZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+Pkd1aWNoYXJk DQo+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5 IDExLCAyMDE0IDk6MjcgQU0NCj4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+Pg0KPj4g Pj4gPj4+ID4+IFdlbGwgSSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhh dmUgdW5kZXJzdG9vZA0KPj50aGUNCj4+ID4+ID4+PiA+PnByb3Bvc2FsDQo+PiA+PiA+Pj4gPj4g Y29ycmVjdGx5IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2lu Z2xlDQo+PlNGDQo+PiA+PiA+Pj53aXRoaW4NCj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5 IHRvDQo+Pmtub3cNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+cHJpb3JpDQo+PiA+PiA+Pj4gPj4gd2hp Y2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbg0K Pj5wb2ludA0KPj4gPj5pbg0KPj4gPj4gPj4+dGltZS4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gPlJvbiwg dGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4+ d2l0aA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ID4+PiA+PiA+cHJvcG9zYWwg YXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90DQo+PiA+ PiA+Pj51bmRlcnN0YW5kDQo+PiA+PiA+Pj4gPj4gPml0LikNCj4+ID4+ID4+PiA+PiA+DQo+PiA+ PiA+Pj4gPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFs YW5jZXIgZm9yIHRoZQ0KPj4gPj5uZXh0DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24g dGhhdCBmb2xsb3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj50byksDQo+PiA+Pmlu DQo+PiA+PiA+Pj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0 aHJvdWdoIGl0Lg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+U2luY2UgaXQgaGFzIHRv IGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucw0KPj4gPj50aGF0 DQo+PiA+PiA+Pj4gPj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBh IGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkDQo+PiA+PiA+Pj5iYWxhbmNl ci4NCj4+ID4+ID4+PiA+PiA+SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cg c2Vuc2l0aXZlLCBhbmQgLyBvcg0KPj4gPj5zdGF0ZWZ1bC4NCj4+ID4+ID4+PiA+PiA+QnV0IGhh dmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLA0K Pj4gPj5mbG93DQo+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5j ZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+ID4+YWNjZXB0YWJsZQ0KPj4gPj4gPj4+ID4+ID5p bXBvc2l0aW9uLg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+WW91cnMsDQo+PiA+PiA+ Pj4gPj4gPkpvZWwNCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPk9uIDcvMTAvMTQsIDEw OjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBt eSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZSB0aGlzDQo+PndvcmsN Cj4+ID4+ID4+PiA+PnNlbnNpYmx5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3Ry YXRlZCBlbnZpcm9ubWVudC4gIEkgZXhwZWN0IHRoYXQgdGhlDQo+PnNlcnZpY2UNCj4+ID4+ID4+ PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmls aXRpZXMsDQo+PndpbGwNCj4+ID4+YmUNCj4+ID4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5k IGluc3RhbGxlZC4gIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0KPj50byBiZQ0KPj4gPj4g Pj4+ID4+ZHJpdmVuIGJ5DQo+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9m ZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlDQo+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0K Pj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJl IGhlYXZpbHkgcG9saWN5DQo+PiA+PmRyaXZlLg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4g Pj4gPj4gSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRp ZWN0dXJlDQo+PiA+PmRyaXZlbg0KPj4gPj4gPj4+YnkNCj4+ID4+ID4+PiA+PiA+PiBpbml0aWFs IGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiAgSXQgaXMNCj4+ID4+ aGFyZGVyDQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+c2VlDQo+PiA+PiA+Pj4gPj4gPj4gaG93 IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmUN Cj4+ID4+ID4+PiA+PiBkeW5hbWljaXR5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsg YmVoYXZpb3IuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0 aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXMNCj4+ID4+b3V0c2lk ZQ0KPj4gPj4gPj4+b2YNCj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+IHNjb3BlIG9m IHRoZSB3b3JraW5nIGdyb3VwLiAgaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4+ID4+dGFz a2VkIHRvDQo+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gPj4gPj4+ID4+ID4+b24uDQo+PiA+PiA+Pj4g Pj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBp dCBhDQo+PmNlcnRhaW4NCj4+ID4+ID4+PndheS4NCj4+ID4+ID4+PiA+Pml0DQo+PiA+PiA+Pj4g Pj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMu DQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+ PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4 IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ID4+IHRoYXQNCj4+ ID4+ID4+PiA+Pm5lZWRzDQo+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBi ZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ ID4+YWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhp biBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4g Pj4+IGNvbXBsZXgNCj4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQg dGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+ PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21w bGljYXRlZCB0aGFuDQo+PmR5bmFtaWMNCj4+ID4+ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4+ID4+ ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBv Zg0KPj53aGljaA0KPj4gPj5hcmUNCj4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4gPj4gPj4+ID4+ID4+ PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50 ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhh dCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPj5pcw0KPj4gPj5hDQo+ PiA+PiA+Pj5nb29kDQo+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxp Y2F0ZWQuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBN LiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4gPj4gPj4+ID4+ID4+PiBTZW50OiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiA+PiA+Pj4gPj4gPj4+IFRvOiBSb24g UGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsNCj4+SWFuDQo+ PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+Pj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk DQo+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlz IGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuICBBbmQgb25lIHRoYXQgSSB3b3VsZA0KPj5wcmVmZXIN Cj4+ID4+d2UNCj4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPj4gPj4gPj4+ID4+ID4+PiBkZWNp ZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGUNCj4+ID4+aW1wbGVt ZW50YXRpb25zLg0KPj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9y IGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPj4gPj5yZXF1aXJlbWVudHMNCj4+ID4+ID4+PmFuZA0K Pj4gPj4gPj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+PiBmdW5jdGlvbmFsaXR5IG9mIFNGRnMu DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFtb3VudCBv ZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcw0KPj4gPj50aGF0DQo+PiA+PiA+ Pj4gbmVlZHMNCj4+ID4+ID4+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+PiBiZSB3aWRlbHkgZGlz dHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+IGFjcm9zcw0KPj4g Pj4gPj4+ZGF0YQ0KPj4gPj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJh dGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+Y29tcGxleA0KPj4g Pj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNG RiBzZWVtcyBsaWtlIGENCj4+ID4+ID4+PmRpZmZpY3VsdA0KPj4gPj4gPj4+ID4+ID4+PiBhcmNo aXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4g WW91cnMsDQo+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuICAgSXMgdGhlIGVu ZCB0byBlbmQNCj4+c2VsZWN0aW9uDQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxl dmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+ ID4+PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJo YXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkNCj4+ID4+dGhlDQo+PiA+PiA+ Pj4gPj5TRkZzKT8NCj4+ID4+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVp dmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+PkFuZA0KPj4gPj4gPj4+c3VyZWx5LA0KPj4g Pj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVs ZWdhdGVkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPj4gPj4gPj4+ ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBk aXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiB0aG91Z2gNCj4+ID4+IGENCj4+ID4+ID4+PiA+ PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJo YXBzDQo+PmxvY2FsDQo+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4+ID4+ID4+PiA+PiA+Pj4+IHBv bGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0K Pj4gPj5UaGlzDQo+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFu IGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+PiA+Pk15DQo+PiA+PiA+Pj4gPj4gPj4+PiBy YXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0K Pj5ieQ0KPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5 IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiAgIFdpdGggYQ0KPj5nbG9iYWwNCj4+ ID4+ID4+PnBhdGgNCj4+ID4+ID4+PiA+PmlkDQo+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwg Y29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0bw0KPj4gPj5hbHRl cg0KPj4gPj4gPj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBm b3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQNCj4+ZW5kLXRvLWVuZA0KPj4gPj4gPj4+cGF0aC4N Cj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4+ID4+ID4+PiA+PiA+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIEZyb206IHNmYw0KPj4gPj4gPj4+ID4+ID4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3Jn XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0KPj4gPj4gPj4+ID4+ID4+Pj4gW2pt aC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwNCj4+MjAx NA0KPj4gPj4gNjoxNQ0KPj4gPj4gPj4+IFBNDQo+PiA+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJp YW5jQGFvbC5jb207IEkuU21pdGhARjUuY29tOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6DQo+ PiA+PiBSZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4g VGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZw0K Pj50bw0KPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4g aXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUNCj4+ZXhpdA0KPj4g Pj5mcm9tDQo+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVu Y3Rpb25zDQo+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhh dCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+ID4+IGNob29zZQ0K Pj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2Ui IGRlbGl2ZXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBK b2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8xNCwgNjox MCBQTSwgbWlrZWJpYW5jQGFvbC5jb20gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24n dCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnkNCj4+ID4+ c29ydA0KPj4gPj4gPj4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwgaXQg ZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZQ0KPj4gPj5wYXRoDQo+PiA+PiA+ Pj4oYWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGlu c3RhbnRpYXRpb24uICBJIGJlbGlldmUNCj4+dGhpcw0KPj4gPj4gPj4+bWVhbnMNCj4+ID4+ID4+ PiA+PiA+Pj4+PiBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZp ZXINCj4+Y2hvb3NlcyBhDQo+PiA+PlNGDQo+PiA+PiA+Pj4gPj5DaGFpbg0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiAgSW4gYW55 IGNhc2UsDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0 byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNGSShuKQ0KPj4gPj4g Pj4+IGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9w LiAgQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQIGFz DQo+PiA+PiA+Pj4gb3Bwb3NlZA0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g Y2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YN Cj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZD Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNm Yy1hcmNoaXRlY3R1cmUtMDA6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGlu c3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+PiA+Pm5lY2Vzc2FyeQ0KPj4gPj4g Pj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMg b2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLA0KPj4gPj5hbmQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzDQo+ PiA+Pm5ldHdvcmsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gbG9jYXRvci4gIFRodXMsIGluc3RhbnRp YXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluIHRoZQ0KPj4gPj4gPj4+Y3JlYXRpb24NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVz ZWQgZm9yDQo+PiA+PmZvcndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJv dWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhlDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyBy ZWNsYXNzaWZpY2F0aW9uIChvcg0KPj4gPj5ub24taW5pdGlhbA0KPj4gPj4gPj4+ID4+ID4+Pj4+ PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxs eSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5j dGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24g b2YgYSBuZXcNCj4+ID4+U0ZQLCBhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhl IGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguICBUaGlzIGlzDQo+PiA+PnJlZmVycmVkDQo+ PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+PiANCj4+Pj4+ Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+ PiA+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pi0t DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb208SS5TbWl0aEBGNS5j b20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+PiBEaXJlY3Q8am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpvZWwNCj4+ID4+IE0uDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBq b2VsaGFscGVybi5jb20+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0BzY2UuDQo+PiA+PiA+ Pj4gPj4gY2FybGV0b24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0Bp ZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwg MjAxNA0KPj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQNCj4+ID4+QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmlsaXR5 IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PnRoYXQgaXMNCj4+ID4+ID4+Pndo YXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBv ZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3 aXRoDQo+PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29uY2VwdGlvbi4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50 IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YNCj4+ID4+YXNwaXJhdGlvbg0KPj4gPj4gdG8NCj4+ID4+ ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4g b2YgdGhlDQo+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj4+LQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFu DQo+PiA+PiA+Pj5hcmJpdHJhcnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBm YXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+PiA+PiA+Pj4gPj5pbnRl bnRpb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVj aXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nDQo+PiA+PmltcGFjdHMNCj4+ID4+ID4+PiA+PiA+Pj4+ PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksDQo+ PiA+PmFkZHJlc3MNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhp bmdzLiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcGFydGlj dWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g RnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+ PiA+PlNlbnQ6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTow NCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsIE0uDQo+PiA+PiBIYWxwZXJuOw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBb c2ZjXQ0KPj4gPj5TZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBJ YW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXMNCj4+ ID4+cmVnYXJkLg0KPj4gPj4gPj4+SQ0KPj4gPj4gPj4+ID4+YW0NCj4+ID4+ID4+PiA+PiA+Pj4+ PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ ID4+cHJvaGliaXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lm aWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG8NCj4+ID4+SHVhbmcncw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRz IGFyZQ0KPj4gPj4gcmVxdWlyZWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNo dGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhh dmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJvaGliaXQNCj4+c3VjaA0K Pj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBv ciBub3QgZGVwZW5kcyB1cG9uDQo+PiA+PiBtYW55DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9y cyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+PnRoaW5rDQo+ PiA+PnRoYXQNCj4+ID4+ID4+PiA+PnRoZXkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxs eSBhIGJhZCBpZGVhLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0 IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG8NCj4+ ID4+a25vdw0KPj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3Qg ZXBsb3lhYmxlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMs IEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQs IDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3Jl ZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5 IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+PiA+PiA+Pj5taWxs aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJl bnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXINCj4+ID4+ID4+ PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2 ZSB0aGF0IGluDQo+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkv V2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3UNCj4+IGFyZQ0KPj4gPj4gb25seQ0KPj4g Pj4gPj4+ID4+IGdvaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJz IG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseQ0KPj5zbWFsbA0KPj4gPj4gPj4+IG51bWJl cnMNCj4+ID4+ID4+PiA+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlr ZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUNCj4+IHRoYW4NCj4+ID4+ID4+PiA2NEsiDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwg TS4gSGFscGVybg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRv Og0KPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywNCj4+ YW5kDQo+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQg aWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+PiA+PiA+Pj5hcmNodGlldHVyZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhl IGxpbWl0cyBvZg0KPj50aGVpcg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJj aGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQNCj4+IHVzZQ0KPj4gPj4gb2YN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3Vy ZSBvdXQgaG93IHRvIHdyaXRlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hpdGVjdHVyYWwgd29y ZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmUNCj4+ZG9lcw0KPj4gPj4gPj4+cGVy bWl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0 aGUgYXJjaHRpZWN0dXJlDQo+PiBwZXJtaXRzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGlu ZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4+ID4+dGhl DQo+PiA+PiA+Pj53b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdj aGVuZyBIdWFuZyB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1 cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsDQo+Pm1lYW4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcN Cj4+dGFibGUNCj4+ID4+b2YgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBN LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hp dGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgZnJvbQ0KPj4xDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdv dWxkIGhvcGUNCj4+dGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJl cGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleQ0KPj4gPj5jaG9vc2UNCj4+ID4+ID4+ PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJh bGFuY2luZyBhbmQgaW4gc3RlYWQNCj4+ID4+IHByb3Zpc2lvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEgg d3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhl cmUgd2lsbCBiZSBmb3IgYSA0IGhvcA0KPj4gPj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSAqT24gQmVoYWxmDQo+PiBPZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAq UGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ID4+ MzowMw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBMdWN5IHlvbmcgKkNjOiogam1o QGpvZWxoYWxwZXJuLmNvbTsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtaWtl YmlhbmNAYW9sLmNvbSAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiBDaGFpbnMsDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFsbCBJIGNvbmN1ciwgYXMg eW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9y d2FyZGluZy4gScK5ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0 bw0KPj4gPj4gZGVyaXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2Fy ZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRo ZXIgaXMgdXNlZCB0bw0KPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkg dGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cw0KPj5tdXN0DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRo ZSBleGFjdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBz ZWVtIHRvIGJlIGFza2luZyBmb3Igb24NCj4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4+ID4+IGlkZW50 aWZpZXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4g YSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbg0KPj4gPj4gcmVzdWx0DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4 dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5 b25nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbQ0KPj4gPj4g PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdy b3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFy Y2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YNCj4+IHRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2Fy ZGluZw0KPj4gPj5hY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxm DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPg0KPj4gPj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+ID4+PiA+PiBKdWx5DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNv bQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhA am9lbGhhbHBlcm4uY29tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86 c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxs cyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp ZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+PmRlcml2ZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0g dG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBh dGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJs ZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJl bHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHBy ZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+IHJlcXVpcmVkDQo+ PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWlu LiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2VkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZSpt aWtlYmlhbmNAYW9sLmNvbQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+ID4+IGp1aWxsZXQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYu b3JnDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQg OipSZTogW3NmY10gU2VydmljZQ0KPj4gPj5DaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4NCj4+U0YNCj4+ID4+IENoYWluDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFu ZCBTRg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90 aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4+ID4+Y2xl YXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUNCj4+YWdy ZWVzDQo+PiA+Pm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBw b2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+d2hldGhlcg0KPj4gPj5pdCBpcw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVs eSBzcGVjaWZ5IHdoYXQNCj4+ID4+dGhlIElEDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRo ZSBTRkMgSGVhZGVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFm dA0KPj4gPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0 aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXINCj4+ZHJhZnRzDQo+PiA+PnRvDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFz ZWQgb24gY2hhaW4NCj4+IG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBj aG9pY2Ugb2YgY2hhaW4gb3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIgKGFt YmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlDQo+ PiA+PiBvbmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBv cHRpb25hbCkgdG8gYXZvaWQgc29tZQ0KPj4gdmVuZG9ycw0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBT RkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4g Pj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4t LQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206 KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxw ZXJuLmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0Bp ZXRmLm9yZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3Nm Y0BpZXRmLm9yZz4+DQo+PiAqU2VudDoqVHVlc2RheSwNCj4+ID4+IEp1bHkNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQNCj4+TG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5n IHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkNCj4+YW5zd2VyDQo+PiA+PmENCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJv dXQgdGhlDQo+PiA+PiA+Pj4gcHJvcG9zZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2Vk IGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldA0KPj4gd29ya2luZw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2ls bCB3b3JrIHRvDQo+PiBpbXByb3ZlDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbg0KPj4g Pj50aGUNCj4+ID4+IFdHDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1 bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRy eSB0byBleHBsYWluIG15DQo+PiA+PnBlcnNvbmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZp ZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVw IGluIG1pbmQgdGhhdA0KPj4gPj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBk ZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlDQo+PmFyZQ0KPj4gPj4g bm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24g Zm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQgZW5jb21wYXNzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywN Cj4+dmlydHVhbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5h Z2VtZW50LCBhbmQgbWFueSBvdGhlcg0KPj4gPj4gYXNwZWN0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkg dGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZA0KPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aA0KPj4g Pj5hYm92ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3Qg ZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlDQo+PiBkb2luZy4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRv IHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLA0KPj5hcyBJDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHVuZGVyc3RhbmQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUg YXJlIGF0DQo+PiA+PmxlYXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZlcmVu dCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZA0KPj53aWxsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkg YXJlDQo+PiA+Pm1vcmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUg YXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YNCj4+ID4+dGhlc2UsDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFu eSBzb2x1dGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQNCj4+ ID4+dXNlci4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rp b24uIEl0IHJlY2VpdmVzIHVzZXINCj4+cGFja2V0cywNCj4+ID4+YW5kDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5k IHVzZXIgc2VydmljZQ0KPj4gPj5pbnN0YW5jZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBy ZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50DQo+PiA+PnNlcnZp Y2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRl IGluIHNlcnZpY2UgY2hhaW5pbmcuDQo+PiA+Pkl0J3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4+ID4+IGNo YWluaW5nIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBs aXR0bGUgaW1wYWN0IG9uIHRoZQ0KPj4gPj5hcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+ICBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBh DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5j dGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwg bG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZQ0KPj5jYW4NCj4+ID4+aGF2ZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBz aW5nbGUNCj4+cG9pbnQNCj4+ID4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmlj IHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4+ID4+YnkgYQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+Pm9uZSBv cg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChmb3IgZXhh bXBsZSB1c2luZyBWUlJQLWxpa2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0 byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+PiA+ Pm1lY2hhbmlzbXMuDQo+PiA+PiBJdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkg dGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4gPj5tZWNoYW5pc21zLA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2Fs ZS1pbiwgc2NhbGUtb3V0LCANCj4+YW5kDQo+PiA+PnZtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiANCj4+cGVybWl0dGlu Zw0KPj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBu ZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+ID4+dGVybWlub2xvZ3kNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZG9lcyBub3QgbGVhZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4g YWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IA0KPj5zZWxlY3RpbmcNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRp cmVjdA0KPj4gPj50cmFmZmljDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBw bGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmUNCj4+IHRoYXQNCj4+ID4+YQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5 IG9uZSBwbGFjZSBpbiANCj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNv dXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSANCj4+Y29tYmluZWQuIEkNCj4+ID4+IHRl bmQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0 bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0 IGFwcGVhciB0byBzZXJ2aWNlDQo+PiA+PmNoYWluaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciANCj4+ aXMNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNl IEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuDQo+PiBUaHVzLA0KPj4gPj4gdGhlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4+ ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQg c3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudA0KPj4gPj5zaW5ndWxhcg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50 IHBsYWNlcyANCj4+aW4NCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRo IHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWlu IGlzIGENCj4+ID4+IHNlcXVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwg ZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YNCj4+ID4+cGFja2V0cy4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21l IHN1YnNldCBvZiANCj4+dHJhZmZpYw0KPj4gPj5pcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQgDQo+PmZpcmV3YWxs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBn byBkaXJlY3RseSB0byB0aGUgDQo+PmNhY2hlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0aG91dA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlv bnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQg aXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIA0KPj5wYWNrZXRzLg0KPj4g QQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlv biwgYSBzZXF1ZW5jZSBvZg0KPj4gPj5sb2NhdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aW4gdGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxv Y2F0aW9ucy4gVGhleQ0KPj4gPj5tYXkgYmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWRkcmVz c2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBhcw0KPj4gcG9ydHMNCj4+ ID4+IG9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlm ZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ID4+bG9jYXRpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZQ0K Pj4gYW5kDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gIEZyb20gdGhlIHBv aW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyANCj4+Z3JvdXAsDQo+PiA+PiB3ZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZQ0KPj4g Pj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3aGljaCBkcml2ZXMgdGhl IGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvDQo+PiB0YWxrDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQg ImJ1dCB0aGUgd2hvbGUNCj4+IHBhdGgNCj4+ID4+IG1heQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMNCj4+ ID4+d2l0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBG aXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgDQo+Pm9uDQo+PiA+PmxvYWQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCAN Cj4+YmVoYXZpb3JzDQo+PiA+PiB3aGljaA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52 aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+PiA+Pm11Y2gN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGlu IGEgTEFOIGlzIGxhcmdlbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJv dXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+PiBwcm92aXNpb24NCj4+ID4+IHdlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlk LWNoYWluIHdoZW4NCj4+ID4+IG5lY2Vzc2FyeS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhh dCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0 aW9uIA0KPj5wb2ludC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiAN Cj4+SWYgaXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQg aXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZw0KPj4gPj4gZ3JvdXAsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVl ZGVkDQo+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdv cmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUNCj4+ID4+IGludGVudCwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdv cmtpbmcNCj4+ID4+Z3JvdXANCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYg dGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlDQo+PiA+PndoYXQgdG8NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qg c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBz ZmNAaWV0Zi5vcmcNCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBs aXN0IHNmY0BpZXRmLm9yZw0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IHNmYw0KPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gc2ZjDQo+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxp bmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+ Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4g Pj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+ PiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPg0K Pj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gPj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPnNmY0Bp ZXRmLm9yZw0KPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0 DQo+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+DQo+PiA+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID5zZmMgbWFpbGlu ZyBsaXN0DQo+PiA+PiA+c2ZjQGlldGYub3JnDQo+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0K From nobody Fri Jul 11 08:55: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 CD5801A0ACB for ; Fri, 11 Jul 2014 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 WWuFrcBIp9T5 for ; Fri, 11 Jul 2014 08:55:11 -0700 (PDT) Received: from omr-d07.mx.aol.com (omr-d07.mx.aol.com [205.188.109.204]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6141A0A89 for ; Fri, 11 Jul 2014 08:55:10 -0700 (PDT) Received: from mtaout-mad01.mx.aol.com (mtaout-mad01.mx.aol.com [172.26.221.205]) by omr-d07.mx.aol.com (Outbound Mail Relay) with ESMTP id 7F68D700000A6; Fri, 11 Jul 2014 11:55:09 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2F39E3800008C; Fri, 11 Jul 2014 11:55:09 -0400 (EDT) Date: Fri, 11 Jul 2014 11:55:08 -0400 From: "mikebianc@aol.com" To: jmh@joelhalpern.com, mn1921@att.com, mohamed.boucadair@orange.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <333979677.3057.1405094108957.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <53BFE6A8.9000903@joelhalpern.com> References: <53BCAB74.4060801@joelhalpern.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca>, <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com>, <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com>, <53BF108D.4090509@joelhalpern.com> , <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <53BFD38E.2080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933003149D@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53BFDF76.7050202@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ABE0@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFE6A8.9000903@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3056_1707963818.1405094108955" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405094109; bh=dd+MXJoYMeWcwP4B1ojpzAgZyO7QQCtkGn87iypVFXY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=o9Jfmo7QoDEUBOkvjDd6yqWvK4Z6bkqk9cb85+lpTUMinX6lIl0fSuG8JK+BohMjt XkrP7FiwGUZmkvjFkf8Uc7ZrwAyUmECGp5lsmOjn+JFn50M6FZr5R7BMbxpeKLXCuS fmCUxtz+J7QKCS2CyFCt6B0MzFgYhIWi29tcfhVo= x-aol-sid: 3039ac1addcd53c008dd3977 X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CXVxMcGfzHtzDa-LFSj80ebCPh4 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:55:20 -0000 ------=_Part_3056_1707963818.1405094108955 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >=C2=A0I can not currently see how to write useful words that meet those=C2= =A0> constraints. > But I will think about it. If we can allow for this flexibility without= =C2=A0> mandating every SFF to have such capability, then it seems worth al= lowing. Could you negotiate this in the control plane? =C2=A0Make one way required = and the other optional. =C2=A0It could even be negotiated per-chain. =C2=A0= If you install devices that don't support certain features, then you simple= can't use those features, but if the devices do, then they can be configur= ed to operate one way or another. From: jmh@joelhalpern.com To: NAPIERALA, MARIA H,mohamed.boucadair@orange.com,Ron Parker,sfc@ietf= .org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The architecture permits (and I would say even encourages) local load=20 balancing between an SFF and the actual service functions to which it is=20 delivering packets. The architecture prohibits service functions from adjusting the service=20 delivery directly. And it prohibits an SFF from over-riding the decision of another SFF=20 about how to do local load balancing to its local service functions. That leaves the possibility of having one SFF have some flexibility=20 about which next SFF it delivers packets to. I am trying to see if=20 there is a way to thread our way through the combination of constraints=20 and still add some of the flexibility you suggest. We need to allow for a level of meaningful central decision. We need to allow for SFF which are not full stateful load balancers=20 relative to other SFF. But you would like to allow the flexibility to include those. And we want an architecture that actually says something. I can not currently see how to write useful words that meet those=20 constraints. But I will think about it. If we can allow for this flexibility without=20 mandating every SFF to have such capability, then it seems worth allowing. Yours, Joel On 7/11/14, 9:09 AM, NAPIERALA, MARIA H wrote: >> So let me say again: the curent archtiecture proposal meets the >> requirement you state. It allows for, but does not require central laod >> balancing. It allows for, but does not require, local load balancing of >> various kinds at or with the SFF. > > We have discussed it yesterday that the language in the current architect= ure proposal precludes local load balancing. > And that re-classification is not "it". > > Maria > >> >> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote: >>> Joel, >>> >>> The architecture has to make NO assumptions on the actual >> configuration/behavior of SFFs (whether none, some, or all of them are >> stateful, flow-aware co-located with LBs/etc.). This is deployment-speci= fic. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>> Envoy=C3=A9 : vendredi 11 juillet 2014 14:08 >>>> =C3=80 : Ron Parker; sfc@ietf.org >>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> And it was pointed out to me that I made a two letter major typo. >>>> >>>> I was trying to say that I felt that such a requirement on all SFF wou= ld >>>> be an UNacceptable imposition. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote: >>>>> Ron, thinking about this, I realized another major problem with the >> your >>>>> proposal as I understand it. (And I readily admit I may not understa= nd >>>>> it.) >>>>> >>>>> The proposal has each SFF serve as the load balancer for the next >>>>> service function that follows it (not the one it delivers to), in eve= ry >>>>> service chain that goes through it. >>>>> >>>>> Since it has to be able to work with all services, that means that ev= ery >>>>> SFF would have to be a full, flow sensitive and stateful load balance= r. >>>>> I ahve no problem if some SFF are flow sensitive, and / or stateful. = But >>>>> having the architecture require that every SFF be a full, flow >>>>> sensitive, stateful, load balancer seems to me to be an acceptable >>>>> imposition. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>>>>> Part of my personal view is that I am trying to make this work sensi= bly >>>>>> in a more orchestrated environment. I expect that the service >>>>>> functions, and over time probably the SFF capabilities, will be >>>>>> orchestrated and installed. I expect the service chains to be drive= n by >>>>>> BSS tools that define offerings to clients, and enable self-selectio= n >>>>>> from these. I expect service paths to be heavily policy drive. >>>>>> >>>>>> I can see how to make all of that work in an archtiecture driven by >>>>>> initial classification to described service paths. It is harder to = see >>>>>> how to make it work (but it can be done) when we allow more >> dynamicity >>>>>> in the network behavior. >>>>>> >>>>>> Having said that, most of that perspective I described is outside of= the >>>>>> scope of the working group. it is not something we are tasked to >>>>>> agree on. >>>>>> So I do not claim that vision means we have to do it a certain way. = it >>>>>> is just the perspective that drives my preferences. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>>>> For me, the amount of information about service instances that >> needs >>>> to >>>>>>>> be widely distributed and maintained, potentially even across data >>>>>>>> centers within an administrative scope, is large enough and >> complex >>>>>>>> enough that trying to get that into each SFF seems like a difficul= t >>>>>>>> architecture to realize. >>>>>>> >>>>>>> I'm curious as to why that is more complicated than dynamic routing= , >>>>>>> hyper-scale data center orchestration, or DNS, all of which are big= ger >>>>>>> problems that have been profitably and stably implemented? >>>>>>> >>>>>>> It also seems that if it really is more complicated, that is a good >>>>>>> sign that it is too complicated. >>>>>>> >>>>>>> ________________________________________ >>>>>>>=20 From: Joel M. Halpern [jmh@joelhalpern.com]>>>>>>> Sent: Thursday, July 10,= 2014 9:45 PM>>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com= ; Ian Smith;>>>>>>> sfc@ietf.org>>>>>>> Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers>>>>>>>>>>>>>> This is an architectural issue. An= d one that I would prefer we>>>> actually>>>>>>> decide, rather than trying= to allow all possible implementations.>>>>>>> Because it does have a major= effect on the control requirements and>> the>>>>>>> functionality of SFFs.= >>>>>>>>>>>>>> For me, the amount of information about service instances th= at>> needs to>>>>>>> be widely distributed and maintained, potentially even= across data>>>>>>> centers within an administrative scope, is large enough= and complex>>>>>>> enough that trying to get that into each SFF seems like= a difficult>>>>>>> architecture to realize.>>>>>>>>>>>>>> Yours,>>>>>>> Jo= el>>>>>>>>>>>>>> But it is a fair question.>>>>>>>>>>>>>> On 7/10/14, 9:38 = PM, Ron Parker wrote:>>>>>>>> This is the crux of my issue. =C2=A0 Is the e= nd to end selection of>>>>>>>> (top-level) instances performed centrally (p= erhaps by the classifier)>>>>>>>> or hop-by-hop (perhaps by the classifier = and subsequently the>> SFFs)?>>>>>>>> Such selection is not equivalent to r= eclassification. =C2=A0 And surely,>>>>>>>> this is an architectural issue = and not relegated to>>>>>>>> "implementation".>>>>>>>>>>>>>>>> My own view = is to favor the distributed approach even though a>>>>>>>> greater amount o= f data (chain definitions and perhaps local>> selection>>>>>>>> policy) is = required at those distributed decision points. =C2=A0 This>>>>>>>> approach= does not require an end-to-end path id at all. =C2=A0=C2=A0 My>>>>>>>> rat= ionale for favoring this approach is primarily driven by increased>>>>>>>> = resiliency over the global path id approach. =C2=A0 With a global path id>>= >>>>>> approach, consider failure of an instance and needing to alter the>>= >>>>>> global path ID table for each and every affected end-to-end path.>>>= >>>>>>>>>>>>> Ron>>>>>>>>>>>>>>>> ________________________________________ = From: sfc>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct>>= >>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM>>= >>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:>>>>= >>>> [sfc] Service Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>> The wa= y the architecture models the case of SF1 needing to>> influence>>>>>>>> th= e chain is that one would do reclassification at the exit from>>>>>>>> SF1.= >>>>>>>>>>>>>>>> Part of the goal is to keep the different functions logica= lly>>>>>>>> separate so that solutions can clearly describe how they choose= to>>>>>>>> compose them for "service" delivery.>>>>>>>>>>>>>>>> Yours, Joe= l>>>>>>>>>>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote:>>>>>>>>> I = don't see anything in the arch draft that suggests any sort of>>>>>>>>> lim= it. However, it does seem to indicate that the entire path (all>>>>>>>>> SF= Is) must be chosen at SFC instantiation. I believe this means>>>>>>>>> eit= her at the classifier or maybe the classifier chooses a SF Chain>>>>>>>>> a= nd the NF or at the latest the first SFF. In any case, the>>>>>>>>> langua= ge does seem to prohibit a more dynamic SFP where SFI(n)>> is>>>>>>>>> dete= rmined at the SFI(n-1) hop. According to the draft, this>>>>>>>>> behavior= would be considered "branching" to a new SFP as>> opposed to>>>>>>>>> choo= sing and then forwarding to the selected instance of the>>>>>>>>> next-hop = of the current SFC.>>>>>>>>>>>>>>>>>> draft-merged-sfc-architecture-00:>>>>= >>>>>> When an SFC is instantiated into the network it is necessary to>>>>>= >>>>> select the specific instances of SFs that will be used, and to>>>>>>>= >>> create the service topology for that SFC using SF's network>>>>>>>>>> l= ocator. Thus, instantiation of the SFC results in the creation>>>>>>>>>> o= f a Service Function Path (SFP) and is used for forwarding>>>>>>>>>> packet= s through the SFC. In other words, an SFP is the>>>>>>>>>> instantiation of= the defined SFC.>>>>>>>>>>>>>>>>>>>> The SFC architecture supports reclass= ification (or non-initial>>>>>>>>>> classification) as well. As packets tr= averse an SFP,>>>>>>>>>> reclassification may occur - typically performed b= y a>>>>>>>>>> classification function co-resident with a service function.>= >>>>>>>>> Reclassification may result in the selection of a new SFP, an>>>>= >>>>>> update of the associated metadata, or both. This is referred to>>>>= >>>>>> as "branching".>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ----------------= ----------------------------------------------------->>>> --->>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>>>>>>>>>>>> *From: *I.Smith@F5.com>>>>>>>= >> *To: *Joel Halpern Direct,Joel M.>>>>>>>>>>>= >>>> Halpern,huang@sce.carleton.ca> = on.ca>,s>>>> fc@ietf.org>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>= >>>>>> *Sent: *Thursday, July 10, 2014>>>>>>>>> *Subject: *Re: [sfc] Servic= e Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>>>> Actually, I think I a= m disagreeing.>>>>>>>>>>>>>>>>>> If the possibility of medium-scale deploym= ents (and that is what>>>>>>>>> 16 million flows is in my world) of service= chains is preconceived>>>>>>>>> as an absurd idea, then the architecture b= urdened with that>>>>>>>>> preconception.>>>>>>>>>>>>>>>>>> There has to be= some point of aim, some degree of aspiration to>>>>>>>>> scale that is app= ropriate for the lifespan of the architecture ->>>>>>>>> you don't have to = know what it is, but by saying that an arbitrary>>>>>>>>> number is "too fa= r", you're creating - even if it isn't intentional>>>>>>>>> - a limit that = influences decisions that have lasting impacts>>>>>>>>> regarding scale-out= , failure mitigation, elasticity, address>>>>>>>>> space... all kinds of th= ings. That is a problem I'm not>>>>>>>>> particularly eager to deal with.>>= >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________= _________>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Joel Halpern Direct [jmh.direct@= joelhalpern.com] Sent:>>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smi= th; Joel M. Halpern;>>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: = Re: [sfc] Service>>>>>>>>> Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>= >>> Ian, I don't think you disagree with me at all in this regard. I am>>>>= >>>>> not requesting the the architecture or the solution prohibit>>>>>>>>>= deployments in the specific fashion. I am objecting to Huang's>>>>>>>>> re= ading of my note as saying that such deployments are required>>>>>>>>> they= by the archtiecture.>>>>>>>>>>>>>>>>>> As I have said repeatedly, I am not= trying to prohibit such>>>>>>>>> things. Whether they are a good idea or n= ot depends upon many>>>>>>>>> factors outside of the scope of the WG. I hap= pen to think that they>>>>>>>>> are usually a bad idea.>>>>>>>>>>>>>>>>>> B= ut the archtiecture si carefully avoiding attempting to know what>>>>>>>>> = is and is not eployable.>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>> On= 7/10/14, 5:01 PM, Ian Smith wrote:>>>>>>>>>> I disagree.>>>>>>>>>>>>>>>>>>= >> We routinely have stateful devices that manage tens of millions>>>>>>>>>= > of>>>>>>>>> concurrent flows in both access network and data center>>>>>>= >>> environments today. You can't seriously believe that in the>>>>>>>>> Cl= oud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only>> going>>>>>>>>= > to have small numbers of service chains with equally small>> numbers>>>>>= >>>> of active service paths?>>>>>>>>>>>>>>>>>>>> Your sounds too much like= "no one will ever need more than>> 64K">>>>>>>>>> for>>>>>>>>> comfort.>>>= >>>>>>>>>>>>>>>>>>>>>>>>>>> ________________________________________ From: = sfc>>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern>>>>>>>>> = [jmh@joelhalpern.com]>>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: h= uang@sce.carleton.ca;>>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Cha= ins, Paths, and Load>>>>>>>>>> Balancers>>>>>>>>>>>>>>>>>>>> No, it will me= an that if someone tries to deploy the archtieture>>>>>>>>>> particularly b= adly, they will exceed the limits of their>>>>>>>>>> devices. The architect= ure does not require such absurd use of>>>>>>>>>> service paths. Since I ca= n not figure out how to write>>>>>>>>>> architectural words to prohibit it,= the architecture does permit>>>>>>>>>> such abuse.>>>>>>>>>>>>>>>>>>>> Ple= ase do not read my saying that the archtiecture permits>>>>>>>>>> something= as saying it is either deisred or required by the work.>>>>>>>>>> It isn't= .>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>> On 7/10/14, 4:36 PM, = Changcheng Huang wrote:>>>>>>>>>>> If you need to support 100 service chain= s, it will mean>>>>>>>>>>> 16,000,000 paths. That is larger than the routin= g table of a>>>>>>>>>>> core router.>>>>>>>>>>>>>>>>>>>>>> Chang>>>>>>>>>>>= >>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>>>>>>>>>>>> The = architecture allows a range of deployments, from 1>>>>>>>>>>>> service path= to 160000 service paths. I would hope that>>>>>>>>>>>> operators are prepa= red for the complexities if they choose to>>>>>>>>>>>> avoid any use of loc= al load balancing and in stead provision>>>>>>>>>>>> 160,000 service paths.= >>>>>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>>>>>> On 7/10/14, 4:= 06 PM, NAPIERALA, MARIA H wrote:>>>>>>>>>>>>> Paul,>>>>>>>>>>>>>>>>>>>>>>>>= >> How many path identifiers there will be for a 4 hop service>>>>>>>>>>>>>= chain with 20 instances at each hop?>>>>>>>>>>>>>>>>>>>>>>>>>> Maria>>>>>>= >>>>>>>>>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of= >>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>>>>>= >>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;>>>>>>>>>>>>> mohamed= .boucadair@orange.com; sfc@ietf.org;>>>>>>>>>>>>> mikebianc@aol.com *Subjec= t:* Re: [sfc] Service Chains,>>>>>>>>>>>>> Paths, and Load Balancers>>>>>>>= >>>>>>>>>>>>>>>>>>> Lucy,>>>>>>>>>>>>>>>>>>>>>>>>>> Overall I concur, as yo= u say: a path ID drives the>>>>>>>>>>>>> forwarding. I'd>>>>>>>>> make>>>>>= >>>>>>>> the minor change: the path identifier can be used to derive>>>>>>>= >>>>>> the needed forwarding and associated transport.>>>>>>>>>>>>>>>>>>>>>= >>>>> It is _not_ the transport, but rather is used to simply>>>>>>>>>>>>> = identify the service path (or graph) that packets must>>>>>>>>>>>>> travers= e. By having a path identifier, the exact>>>>>>>>>>>>> indirection that peo= ple seem to be asking for on this>>>>>>>>>>>>> thread can be simply be impl= emented. The path identifier>>>>>>>>>>>>> provides nothing more than a look= up, that lookup can result>>>>>>>>>>>>> in a one or more (equal or weighted= ) transport next>>>>>>>>>>>>> hop(s).>>>>>>>>>>>>>>>>>>>>>>>>>> Paul>>>>>>>= >>>>>>>>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote:>>>>>= >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Agree. The arch. doc should= not mandate only use of the>>>>>>>>>>>>> service path identifier to drive = the forwarding actions.>>>>>>>>>>>>>>>>>>>>>>>>>> Lucy>>>>>>>>>>>>>>>>>>>>>= >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf>>>>>>>>>>>>> Of*mo= hamed.boucadair@orange.com>>>>>>>>>>>>> *Sent:*Thursday,>> July>>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol= .com>>>>>>>>>>>>> ;jmh@joelhalpern.com>>>>>>>>>>>= >> ;sfc@ietf.org>>>>>>>>>>>>> *Subject:*Re: [sfc] Service Chains,>>>>>>>>>>>>> Paths, and Load Balan= cers>>>>>>>>>>>>>>>>>>>>>>>>>> Re-,>>>>>>>>>>>>>>>>>>>>>>>>>> The merged dr= aft calls out explicitly a service path>>>>>>>>>>>>> identifier. I object t= o use that identifier to derive>>>>>>>>>>>>> forwarding actions.>>>>>>>>>>>= >>>>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of every>= >>>>>>>> available SFC>>>>>>>>>>>>> forwarding paths within an SFC-enabled = domain is not>>>>>>>>> required/justified>>>>>>>>>>>>> nor possible in vari= ous deployment contexts.>>>>>>>>>>>>>>>>>>>>>>>>>> SFC forwarding actions s= hould rely on the piece of>>>>>>>>>>>>> information>>>>>>>>> that will>>>>>= >>>>>>>> be present in all deployments: that is the one required to>>>>>>>>= >>>>> structure a service chain. How that information is used to>>>>>>>>>>>= >> infer forwarding>>>>>>>>> actions>>>>>>>>>>>>> is a solution-oriented di= scussion.>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,>>>>>>>>>>>>>>>>>>>>>>>>>> Med>>= >>>>>>>>>>>>>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part= >>>>>>>>> de*mikebianc@aol.com>>>>>>>>>>>>> *Env= oy=C3=A9 :*mercredi 9 juillet>>>>>>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhal= pern.com>>>>>>>>>>>>> ;sfc@ietf.org>>>>>>>>>>>>= > *Objet :*Re: [sfc] Service Chains,>>>>>>>>>>>>> Pat= hs, and Load Balancers>>>>>>>>>>>>>>>>>>>>>>>>>> Is anyone still questionin= g the difference between SF Chain>>>>>>>>>>>>> and SF>>>>>>>>> Path?>>>>>>>= >>>>>> Other than clarifying the definition so that it's clear to>>>>>>>>> = those not>>>>>>>>>>>>> familiar with the draft, it seems that everyone agre= es on>>>>>>>>>>>>> these terms.>>>>>>>>>>>>>>>>>>>>>>>>>> To me, the one po= int that is still unclear is whether it is>>>>>>>>>>>>> the intent of this = draft to ultimately specify what the ID>>>>>>>>>>>>> of the SFC Header>>>>>= >>>> should>>>>>>>>>>>>> reference (the chain or the path), or if this draf= t simply>>>>>>>>>>>>> intends to leave that ambiguous, allowing other draft= s to>>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain or>>= >>>>>>>>>>> path and the choice of chain or>>>>>>>>> path to>>>>>>>>>>>>> b= e negotiated in the control-plane.>>>>>>>>>>>>>>>>>>>>>>>>>> If the latter = (ambiguous), then the draft would have>>>>>>>>>>>>> require that both SFP a= nd SFC be supported (or make one>>>>>>>>>>>>> required and the other option= al) to avoid some vendors only>>>>>>>>>>>>> supporting SFP and others only = supporting SFC.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------= --------------------------------------------->>>> --->>>>>>>>>>>>>>>>>>>>>>= >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *From:*jmh@joelhalpern.com>>>>>>>>>>>> >= >>>>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>>>> > *Sent:*Tuesday, July>>>>>>>>>>>>> 8, 2014 *Subject:*[s= fc] Service Chains, Paths, and Load>>>>>>>>>>>>> Balancers>>>>>>>>>>>>>>>>>= >>>>>>>>> I have been trying to figure out how to clearly answer a>>>>>>>>>= >>>> number of comments that have been made about the>> proposed>>>>>>>>>>>= >> merged archtiecture draft. Assuming we can get working>>>>>>>>>>>>> grou= p agreement on the intent, we will work to improve the>>>>>>>>>>>>> wording= so that readers who have not participated in the WG>>>>>>>>>>>>> discussio= n will understnd it the way the>>>>>>>>> working>>>>>>>>>>>>> group intends= .>>>>>>>>>>>>>>>>>>>>>>>>>> But what do we intend? I will try to explain my= personal>>>>>>>>>>>>> view, and see if that helps.>>>>>>>>>>>>>>>>>>>>>>>>= >> In this regard, it is important to keep in mind that what>>>>>>>>>>>>> w= e are defining is the data plane architecture. We are not>>>>>>>>>>>>> atte= mpting to define the architecture for the entire>>>>>>>>>>>>> solution for = service chaining. That would encompass>>>>>>>>>>>>> OSS/BSS, various contro= l and policy functions, virtual>>>>>>>>>>>>> machine and image management, = and many other aspects.>>>>>>>>>>>>>>>>>>>>>>>>>> As a result there are man= y things which clearly need to>>>>>>>>>>>>> exist in the larger system, but= which are dealt with above>>>>>>>>>>>>> where we are>>>>>>>>> functioning,= >>>>>>>>>>>>> and are not directly required by the work we are doing.>>>>>>= >>>>>>>>>>>>>>>>>>>> In order to get to service chain vs service path, as I= >>>>>>>>>>>>> understand>>>>>>>>> them,>>>>>>>>>>>>> I need to first discus= s load balancing. There are at least>>>>>>>>>>>>> three different ways that= load balancing can and will>>>>>>>>>>>>> interact with service chaining. T= here probably are more.>>>>>>>>>>>>> The point of the archtiecture is to pe= rmit all of these,>>>>>>>>>>>>> but not to mandate that any particular kind= >>>>>>>>> be used>>>>>>>>>>>>> in any solution.>>>>>>>>>>>>>>>>>>>>>>>>>> 1= ) Load balancing as a service provided to the end user.>>>>>>>>>>>>> This i= s a service function. It receives user packets, and>>>>>>>>>>>>> modifies t= hem (or>>>>>>>>> marks>>>>>>>>>>>>> them, or ...) so as to choose an end us= er service instance>>>>>>>>>>>>> to receive the users packet. This is an im= portant service>>>>>>>>>>>>> function to be able to include in service chai= ning. It's>>>>>>>>>>>>> behavior may affect requirements on how service cha= ining is>>>>>>>>>>>>> done. But it has very little impact on the archtiectu= re.>>>>>>>>>>>>> =C2=A0=C2=A0 From an architectural pe3rspective it is simp= ly a>>>>>>>>> service>>>>>>>>>>>>> function which may modify the underlying= packet.>>>>>>>>>>>>>>>>>>>>>>>>>> 2) There is internal load balancing. Tha= t is, one can have>>>>>>>>>>>>> what>>>>>>>>> appears>>>>>>>>>>>>> to the s= ervice chaining architecture as a single point of>>>>>>>>>>>>> contact>>>>>= >>>> for a>>>>>>>>>>>>> specific service function, but is actually delivere= d by a>>>>>>>>> collection of>>>>>>>>>>>>> virtual or physical machines, po= ssibly including one or>>>>>>>>>>>>> several load balancers (for example us= ing VRRP-like>>>>>>>>>>>>> techniques to share a MAC address.) mostly, this= is>>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. I= t>>>>>>>>>>>>> is likely that it is visible to various control mechanisms,>= >>>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm>>>>>= >>>>>>>> instantiation. The architectural impact of permitting this>>>>>>>>= >>>>> is largely that we need to be careful that our terminology>>>>>>>>>>>= >> does not lead>>>>>>>>> readers to>>>>>>>>>>>>> think we are prohibiting = it.>>>>>>>>>>>>>>>>>>>>>>>>>> 3) There can also be load balancing done by s= electing>>>>>>>>>>>>> packet paths for the service chaining that direct tra= ffic>>>>>>>>>>>>> to different places. We would not want to require that a>= >>>>>>>>>>>> given service function appear at only one place in the>>>>>>>>= >>>>> network.>>>>>>>>>>>>>>>>>>>>>>>>>> It is of course the case that thes= e may be combined. I tend>>>>>>>>>>>>> to>>>>>>>>> refer to>>>>>>>>>>>>> th= e collection of entities that appear to service chaining>>>>>>>>>>>>> as a = single point as a cluster. Not because cluster is a>>>>>>>>>>>>> good term.= But because I do not have another one. Thus, the>>>>>>>>>>>>> point of typ= e 3 load balancing>>>>>>>>> is to>>>>>>>>>>>>> direct different subsets of = traffic to different singular>>>>>>>>>>>>> or clustered service functions i= n different places in the>>>>>>>>>>>>> network.>>>>>>>>>>>>>>>>>>>>>>>>>> N= ow with that said, what do I mean when I talk about>>>>>>>>>>>>> service ch= ain and service path/ Service chain is a sequence>>>>>>>>>>>>> of logical f= unctions to be applied to a subset of packets.>>>>>>>>>>>>> It is equivalen= t of saying that some subset of traffic is>>>>>>>>>>>>> to get DPI, chargin= g, content inspection, and firewall>>>>>>>>>>>>> while a different subset i= s to go directly to the cache>>>>>>>>> without>>>>>>>>>>>>> visiting any ot= her service functions.>>>>>>>>>>>>>>>>>>>>>>>>>> That is not enough informa= tion to direct the packets. A>>>>>>>>>>>>> service path is, in some fashion= , a sequence of locations>>>>>>>>>>>>> in the network. Those locations will= be singular or>>>>>>>>>>>>> clustered service function delivery locations.= They may be>>>>>>>>>>>>> addressed by IP address. They may be addressed as= ports on>>>>>>>>>>>>> an SFF. There are many different ways that the locat= ions>>>>>>>>>>>>> may be known to the service chaining infrastructure and t= he>>>>>>>>>>>>> transport.>>>>>>>>>>>>>>>>>>>>>>>>>>> =C2=A0=C2=A0 From the= point of view of the work of the SFC group, we>>>>>>>>>>>>>> need to be>>>= >>>>>>>>>> able to talk about the high level abstraction, the service>>>>>>= >>>>>>> chain, which drives the forwarding. And we need to talk>>>>>>>>>>>>= > about the actual data path packets will take in the>>>>>>>>>>>>> network.= >>>>>>>>>>>>>>>>>>>>>>>>>> Several of the comments have said "but the whole= path may>>>>>>>>>>>>> not be known at the front." This architecture deals = with>>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on lo= ad>>>>>>>>>>>>> balancers above, there can be decisions and behaviors which= >>>>>>>>>>>>> are invisible to the service chaining mechanisms (in much>>>>= >>>>>>>>> the same way that bridging within a LAN is largely>>>>>>>>>>>>> i= nvisible to routing between LANs.) The other provision we>>>>>>>>>>>>> make= is>>>>>>>>> that>>>>>>>>>>>>> reclassification can be done in mid-chain wh= en necessary.>>>>>>>>>>>>> That will direct packets to a new chain. Based o= n>>>>>>>>>>>>> information available at the re-classification point.>>>>>>>= >>>>>>>>>>>>>>>>>>> I hope that this helps explain what we are after. If it= >>>>>>>>>>>>> does, and if the intent is acceptable to the working group,>>= >>>>>>>>>>> we can figure out what additional words are needed to>>>>>>>>>>= >>> convey this. If the working group disagree with the intent,>>>>>>>>>>>>= > then we will of course adjust to match the working group>>>>>>>>>>>>> agr= eements. If this is still unclear, I am not sure what to>>>>>>>>>>>>> try n= ext.>>>>>>>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>>>>>>>> ______= _________________________________________ 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/listinf= o/sfc>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ___________________________________= ____________ sfc>> mailing>>>>>>>>>>> list sfc@ietf.org https://www.ietf.or= g/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.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@iet= f.org>>>>> https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>>>>> _________= ______________________________________>>>> sfc mailing list>>>> sfc@ietf.or= g>>>> https://www.ietf.org/mailman/listinfo/sfc>>>> _______________________= ________________________>> sfc mailing list>> sfc@ietf.org>> https://www.ie= tf.org/mailman/listinfo/sfc_______________________________________________s= fc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_3056_1707963818.1405094108955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

>=  I ca= n not currently see how to write useful words that meet those <= br style=3D"font-family: sans-serif, arial; font-size: 14px;">> constraints.
> But I will think about it. If we can allow for this flexibility wi= thout 
>= mandating every SFF to have such capability, then it seems worth allowing.=

C= ould you negotiate this in the control plane?  Make one way required a= nd the other optional.  It could even be negotiated per-chain.  I= f you install devices that don't support certain features, then you simple = can't use those features, but if the devices do, then they can be configure= d to operate one way or another.

=


From: jmh@joelhalpern.com= <jmh@joelhalpern.com>
To: NAPIERALA, MARIA H<mn1921@att.= com>,mohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,Ro= n Parker<Ron_Parker@affirmednetworks.com>,sfc@ietf.org<sfc@ietf.or= g>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Se= rvice Chains, Paths, and Load Balancers

The architect= ure permits (and I would say even encourages) local load
balancing betw= een an SFF and the actual service functions to which it is
delivering p= ackets.

The architecture prohibits service functions from adjusting = the service
delivery directly.
And it prohibits an SFF from over-rid= ing the decision of another SFF
about how to do local load balancing to= its local service functions.

That leaves the possibility of having = one SFF have some flexibility
about which next SFF it delivers packets = to. I am trying to see if
there is a way to thread our way through the= combination of constraints
and still add some of the flexibility you s= uggest.
We need to allow for a level of meaningful central decision.
= We need to allow for SFF which are not full stateful load balancers
rel= ative to other SFF.
But you would like to allow the flexibility to inclu= de those.
And we want an architecture that actually says something.
<= br>I can not currently see how to write useful words that meet those
co= nstraints.
But I will think about it. If we can allow for this flexibil= ity without
mandating every SFF to have such capability, then it seems = worth allowing.

Yours,
Joel

On 7/11/14, 9:09 AM, NAPIERALA= , MARIA H wrote:
>> So let me say again: the curent archtiecture = proposal meets the
>> requirement you state. It allows for, but d= oes not require central laod
>> balancing. It allows for, but doe= s not require, local load balancing of
>> various kinds at or with= the SFF.
>
> We have discussed it yesterday that the language = in the current architecture proposal precludes local load balancing.
>= ; And that re-classification is not "it".
>
> Maria
>
= >>
>> On 7/11/14, 8:40 AM, mohamed.boucadair@orange.com wrote:
>>> Joel= ,
>>>
>>> The architecture has to make NO assumptio= ns on the actual
>> configuration/behavior of SFFs (whether none, = some, or all of them are
>> stateful, flow-aware co-located with L= Bs/etc.). This is deployment-specific.
>>>
>>> Chee= rs,
>>> Med
>>>
>>>> -----Message d'= origine-----
>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern
&= gt;>>> Envoy=C3=A9 : vendredi 11 juillet 2014 14:08
>>>= ;> =C3=80 : Ron Parker; sfc@ietf.org=
>>>> Objet : Re: [sfc] Service Chains, Paths, and Load Bala= ncers
>>>>
>>>> And it was pointed out to me = that I made a two letter major typo.
>>>>
>>>>= ; I was trying to say that I felt that such a requirement on all SFF would<= br>>>>> be an UNacceptable imposition.
>>>>
&= gt;>>> Yours,
>>>> Joel
>>>>
>= >>> On 7/10/14, 11:53 PM, Joel M. Halpern wrote:
>>>&g= t;> Ron, thinking about this, I realized another major problem with the<= br>>> your
>>>>> proposal as I understand it. (And= I readily admit I may not understand
>>>>> it.)
>&= gt;>>>
>>>>> The proposal has each SFF serve as = the load balancer for the next
>>>>> service function tha= t follows it (not the one it delivers to), in every
>>>>>= service chain that goes through it.
>>>>>
>>>= ;>> Since it has to be able to work with all services, that means tha= t every
>>>>> SFF would have to be a full, flow sensitive= and stateful load balancer.
>>>>> I ahve no problem if s= ome SFF are flow sensitive, and / or stateful. But
>>>>> = having the architecture require that every SFF be a full, flow
>>&= gt;>> sensitive, stateful, load balancer seems to me to be an accepta= ble
>>>>> imposition.
>>>>>
>>= >>> Yours,
>>>>> Joel
>>>>>>>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote:
>&= gt;>>>> Part of my personal view is that I am trying to make th= is work sensibly
>>>>>> in a more orchestrated environ= ment. I expect that the service
>>>>>> functions, and= over time probably the SFF capabilities, will be
>>>>>&g= t; orchestrated and installed. I expect the service chains to be driven by=
>>>>>> BSS tools that define offerings to clients, an= d enable self-selection
>>>>>> from these. I expect s= ervice paths to be heavily policy drive.
>>>>>>
>= ;>>>>> I can see how to make all of that work in an archtiec= ture driven by
>>>>>> initial classification to descri= bed service paths. It is harder to see
>>>>>> how to = make it work (but it can be done) when we allow more
>> dynamicity=
>>>>>> in the network behavior.
>>>>&g= t;>
>>>>>> Having said that, most of that perspecti= ve I described is outside of the
>>>>>> scope of the w= orking group. it is not something we are tasked to
>>>>>= > agree on.
>>>>>> So I do not claim that vision me= ans we have to do it a certain way. it
>>>>>> is just= the perspective that drives my preferences.
>>>>>>>>>>>> Yours,
>>>>>> Joel
>&g= t;>>>>
>>>>>> On 7/10/14, 9:58 PM, Ian Smi= th wrote:
>>>>>>>> For me, the amount of informa= tion about service instances that
>> needs
>>>> to<= br>>>>>>>>> be widely distributed and maintained, p= otentially even across data
>>>>>>>> centers wit= hin an administrative scope, is large enough and
>> complex
>= ;>>>>>>> enough that trying to get that into each SFF = seems like a difficult
>>>>>>>> architecture to = realize.
>>>>>>>
>>>>>>> I'= m curious as to why that is more complicated than dynamic routing,
>&= gt;>>>>> hyper-scale data center orchestration, or DNS, all = of which are bigger
>>>>>>> problems that have been= profitably and stably implemented?
>>>>>>>
>= >>>>>> It also seems that if it really is more complicate= d, that is a good
>>>>>>> sign that it is too compl= icated.
>>>>>>>
>>>>>>> ___= _____________________________________
>>>>>>>
<= br class=3D"">From: Joel M. Halpern [jmh@joelhalpern.com]
>= ;>>>>>> Sent: Thursday, July 10, 2014 9:45 PM
>>>>>>> To: Ron Parker; Joel Halpern Direct; mikebi= anc@aol.com; Ian Smith;
>>>>>>> sfc@ietf= .org
>>>>>>> Subject: Re: [sfc] Service = Chains, Paths, and Load Balancers
>>>>>>>= ;
>>>>>>> This is an architectural issue= . And one that I would prefer we
>>>> actually>>>>>>> decide, rather than trying to all= ow all possible implementations.
>>>>>>>= Because it does have a major effect on the control requirements and
>> the
>>>>>>> functionali= ty of SFFs.
>>>>>>>
>&g= t;>>>>> For me, the amount of information about service inst= ances that
>> needs to
>>>>&g= t;>> be widely distributed and maintained, potentially even across da= ta
>>>>>>> centers within an administrat= ive scope, is large enough and complex
>>>>>&g= t;> enough that trying to get that into each SFF seems like a difficult<= br class=3D"">>>>>>>> architecture to realize.
>>>>>>>
>>>>>>&= gt; Yours,
>>>>>>> Joel
&g= t;>>>>>>
>>>>>>> But i= t is a fair question.
>>>>>>>
>>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote:>>>>>>>> This is the crux of my issue.=   Is the end to end selection of
>>>>>&g= t;>> (top-level) instances performed centrally (perhaps by the classi= fier)
>>>>>>>> or hop-by-hop (perhaps= by the classifier and subsequently the
>> SFFs)?
>>>>>>>> Such selection is not equivalent = to reclassification.   And surely,
>>>>>&= gt;>> this is an architectural issue and not relegated to
>>>>>>>> "implementation".
>>= ;>>>>>>
>>>>>>>> My= own view is to favor the distributed approach even though a
= >>>>>>>> greater amount of data (chain definitions = and perhaps local
>> selection
>>&g= t;>>>>> policy) is required at those distributed decision po= ints.   This
>>>>>>>> approach d= oes not require an end-to-end path id at all.    My
>>>>>>>> rationale for favoring this approach is p= rimarily driven by increased
>>>>>>>>= resiliency over the global path id approach.   With a global path id<= br class=3D"">>>>>>>>> approach, consider failure o= f an instance and needing to alter the
>>>>>&g= t;>> global path ID table for each and every affected end-to-end path= .
>>>>>>>>
>>>= >>>>> Ron
>>>>>>>>
>>>>>>>> _______________________________= _________ From: sfc
>>>>>>>> [sfc-bou= nces@ietf.org] on behalf of Joel Halpern Direct
>>>&= gt;>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2= 014 6:15 PM
>>>>>>>> To: mikebianc@ao= l.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:
>>>= >>>>> [sfc] Service Chains, Paths, and Load Balancers
>>>>>>>>
>>>>>= >>> The way the architecture models the case of SF1 needing to
>> influence
>>>>>>>>= ; the chain is that one would do reclassification at the exit from
>>>>>>>> SF1.
>>>>&= gt;>>>
>>>>>>>> Part of the = goal is to keep the different functions logically
>>>= ;>>>>> separate so that solutions can clearly describe how t= hey choose to
>>>>>>>> compose them f= or "service" delivery.
>>>>>>>>
>>>>>>>> Yours, Joel
>>= ;>>>>>>
>>>>>>>> On= 7/10/14, 6:10 PM, mikebianc@aol.com wrote:
>>>>&= gt;>>>> I don't see anything in the arch draft that suggests an= y sort of
>>>>>>>>> limit. However= , it does seem to indicate that the entire path (all
>>= >>>>>>> SFIs) must be chosen at SFC instantiation. I = believe this means
>>>>>>>>> eithe= r at the classifier or maybe the classifier chooses a SF Chain
>>>>>>>>> and the NF or at the latest the firs= t SFF. In any case, the
>>>>>>>>>= language does seem to prohibit a more dynamic SFP where SFI(n)
>> is
>>>>>>>>> determine= d at the SFI(n-1) hop. According to the draft, this
>>= >>>>>>> behavior would be considered "branching" to a = new SFP as
>> opposed to
>>>>= >>>>> choosing and then forwarding to the selected instance = of the
>>>>>>>>> next-hop of the c= urrent SFC.
>>>>>>>>>
>>>>>>>>> draft-merged-sfc-architecture-00:>>>>>>>>>> When an SFC is instant= iated into the network it is necessary to
>>>>>= ;>>>>> select the specific instances of SFs that will be use= d, and to
>>>>>>>>>> create the= service topology for that SFC using SF's network
>>>= ;>>>>>>> locator. Thus, instantiation of the SFC resu= lts in the creation
>>>>>>>>>> = of a Service Function Path (SFP) and is used for forwarding
&= gt;>>>>>>>>> packets through the SFC. In other w= ords, an SFP is the
>>>>>>>>>> = instantiation of the defined SFC.
>>>>>>>= ;>>>
>>>>>>>>>> The SF= C architecture supports reclassification (or non-initial
>= >>>>>>>>> classification) as well. As packets t= raverse an SFP,
>>>>>>>>>> recl= assification may occur - typically performed by a
>>>= ;>>>>>>> classification function co-resident with a se= rvice function.
>>>>>>>>>> Recl= assification may result in the selection of a new SFP, an
>= ;>>>>>>>>> update of the associated metadata, or= both. This is referred to
>>>>>>>>&= gt;> as "branching".
>>>>>>>>><= br class=3D"">>>>>>>>>>
>>&g= t;>>>>>>
>>>>>>>>&g= t; --------------------------------------------------------------------->>>> ---
>>>>>>>= >>
>>>>>>>>>
&= gt;>>>>>>>>
>>>>>>&= gt;>>
>>>>>>> *From: *I.Smith@F5.c= om<I.Smith@F5.com>
>>>>>>>>>= *To: *Joel Halpern Direct<jmh.direct@joelhalpern.com>,Joel M.
>>>>>>>>>
>>>>=
>> Halpern<jmh@joelhalpern.com>,huang@sce.carlet= on.ca<huang@sce.carlet
>> on.ca>,s
= >>>> fc@ietf.org<sfc@ietf.org>
>>>= >>>>>>
>>>>>>>>>=
>>>>>>>>>
>>&= gt;>>>>>>
>>>>>>> *Sen= t: *Thursday, July 10, 2014
>>>>>>>>&= gt; *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers
>>>>>>>>>
>>>>&g= t;>>>> Actually, I think I am disagreeing.
>&g= t;>>>>>>>
>>>>>>>&g= t;> If the possibility of medium-scale deployments (and that is what
>>>>>>>>> 16 million flows is in my w= orld) of service chains is preconceived
>>>>>&= gt;>>> as an absurd idea, then the architecture burdened with that=
>>>>>>>>> preconception.
>>>>>>>>>
>>>>&g= t;>>>> There has to be some point of aim, some degree of aspira= tion to
>>>>>>>>> scale that is ap= propriate for the lifespan of the architecture -
>>>= >>>>>> you don't have to know what it is, but by saying t= hat an arbitrary
>>>>>>>>> number = is "too far", you're creating - even if it isn't intentional
= >>>>>>>>> - a limit that influences decisions th= at have lasting impacts
>>>>>>>>> = regarding scale-out, failure mitigation, elasticity, address
= >>>>>>>>> space... all kinds of things. That is = a problem I'm not
>>>>>>>>> partic= ularly eager to deal with.
>>>>>>>>&g= t;
>>>>>>>>>
>>= ;>>>>>>>
>>>>>>>>= ;>
>>>>>>>>> __________________= ______________________
>>>>>>>>>>>>>>>>>>
>>>= ;>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern= .com] Sent:
>>>>>>>>> Thursday, Ju= ly 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;
>>&= gt;>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re= : [sfc] Service
>>>>>>>>> Chains, = Paths, and Load Balancers
>>>>>>>>>= ;
>>>>>>>>> Ian, I don't think you= disagree with me at all in this regard. I am
>>>>= ;>>>>> not requesting the the architecture or the solution p= rohibit
>>>>>>>>> deployments in t= he specific fashion. I am objecting to Huang's
>>>&g= t;>>>>> reading of my note as saying that such deployments a= re required
>>>>>>>>> they by the = archtiecture.
>>>>>>>>>
>>>>>>>>> As I have said repeatedly, I am = not trying to prohibit such
>>>>>>>>&= gt; things. Whether they are a good idea or not depends upon many
>>>>>>>>> factors outside of the scope of = the WG. I happen to think that they
>>>>>>&= gt;>> are usually a bad idea.
>>>>>>&= gt;>>
>>>>>>>>> But the arch= tiecture si carefully avoiding attempting to know what
>&g= t;>>>>>>> is and is not eployable.
>&= gt;>>>>>>>
>>>>>>>&= gt;> Yours, Joel
>>>>>>>>>
>>>>>>>>> On 7/10/14, 5:01 PM, Ian Smi= th wrote:
>>>>>>>>>> I disagree= .
>>>>>>>>>>
>= >>>>>>>>> We routinely have stateful devices tha= t manage tens of millions
>>>>>>>>>= ;> of
>>>>>>>>> concurrent flow= s in both access network and data center
>>>>>= >>>> environments today. You can't seriously believe that in th= e
>>>>>>>>> Cloud/IPv6/Mobility/We= b2.0/IoT world of tomorrow you are only
>> going
>>>>>>>>> to have small numbers of servi= ce chains with equally small
>> numbers
&= gt;>>>>>>>> of active service paths?
= >>>>>>>>>>
>>>>>= >>>>> Your sounds too much like "no one will ever need more = than
>> 64K"
>>>>>>>= >>> for
>>>>>>>>> comfort= .
>>>>>>>>>>
>= >>>>>>>>>
>>>>>>= >>>> ________________________________________ From: sfc
>>>>>>>>>> [sfc-bounces@ietf.org] on b= ehalf of Joel M. Halpern
>>>>>>>>>= [jmh@joelhalpern.com]
>>>>>>>>>&g= t; Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca;
>>>>>>>>>> sfc@ietf.org Subject: Re: [= sfc] Service Chains, Paths, and Load
>>>>>>= >>>> Balancers
>>>>>>>>&g= t;>
>>>>>>>>>> No, it will m= ean that if someone tries to deploy the archtieture
>>&= gt;>>>>>>> particularly badly, they will exceed the li= mits of their
>>>>>>>>>> device= s. The architecture does not require such absurd use of
>&= gt;>>>>>>>> service paths. Since I can not figure o= ut how to write
>>>>>>>>>> arch= itectural words to prohibit it, the architecture does permit
= >>>>>>>>>> such abuse.
>>= >>>>>>>>
>>>>>>>= >>> Please do not read my saying that the archtiecture permits
>>>>>>>>>> something as saying it = is either deisred or required by the work.
>>>>&g= t;>>>>> It isn't.
>>>>>>>= >>>
>>>>>>>>>> Yours, = Joel
>>>>>>>>>>
&= gt;>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Hua= ng wrote:
>>>>>>>>>>> If you= need to support 100 service chains, it will mean
>>>= ;>>>>>>>> 16,000,000 paths. That is larger than the= routing table of a
>>>>>>>>>>&= gt; core router.
>>>>>>>>>>>=
>>>>>>>>>>> Chang
>>>>>>>>>>>
>>&g= t;>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern = wrote:
>>>>>>>>>>>> The a= rchitecture allows a range of deployments, from 1
>>>= ;>>>>>>>>> service path to 160000 service paths.= I would hope that
>>>>>>>>>>&g= t;> operators are prepared for the complexities if they choose to
>>>>>>>>>>>> avoid any use of l= ocal load balancing and in stead provision
>>>>&g= t;>>>>>>> 160,000 service paths.
>>= ;>>>>>>>>>>
>>>>>= ;>>>>>>> Yours, Joel
>>>>>= ;>>>>>>>
>>>>>>>>= ;>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
>>>>>>>>>>>>> Paul,
>>>>>>>>>>>>>
&g= t;>>>>>>>>>>>> How many path identifier= s there will be for a 4 hop service
>>>>>>&= gt;>>>>>> chain with 20 instances at each hop?
>>>>>>>>>>>>>
&g= t;>>>>>>>>>>>> Maria
>= >>>>>>>>>>>>
>>>= >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@iet= f.org] *On Behalf Of
>>>>>>>>>>= >>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03
>>>>>>>>>>>>> PM *To:* Lucy= yong *Cc:* jmh@joelhalpern.com;
>>>>>>>= >>>>>> mohamed.boucadair@orange.com; sfc@ietf.org;
>>>>>>>>>>>>> mikebianc@aol.= com *Subject:* Re: [sfc] Service Chains,
>>>>>= >>>>>>>> Paths, and Load Balancers
&g= t;>>>>>>>>>>>>
>>&g= t;>>>>>>>>>> Lucy,
>>>= >>>>>>>>>>
>>>>>= >>>>>>>> Overall I concur, as you say: a path ID dr= ives the
>>>>>>>>>>>>>= forwarding. I'd
>>>>>>>>> make>>>>>>>>>>>>> the minor = change: the path identifier can be used to derive
>>>= ;>>>>>>>>>> the needed forwarding and associa= ted transport.
>>>>>>>>>>>&g= t;>
>>>>>>>>>>>>> I= t is _not_ the transport, but rather is used to simply
>&g= t;>>>>>>>>>>> identify the service path (o= r graph) that packets must
>>>>>>>>&g= t;>>>> traverse. By having a path identifier, the exact
>>>>>>>>>>>>> indirection tha= t people seem to be asking for on this
>>>>>&g= t;>>>>>>> thread can be simply be implemented. The pat= h identifier
>>>>>>>>>>>>= > provides nothing more than a lookup, that lookup can result
>>>>>>>>>>>>> in a one or more= (equal or weighted) transport next
>>>>>>&= gt;>>>>>> hop(s).
>>>>>>&= gt;>>>>>>
>>>>>>>>&= gt;>>>> Paul
>>>>>>>>>= >>>>
>>>>>>>>>>>= >> On Jul 10, 2014, at 11:04 AM, Lucy yong
>>>= >>>>>>>>>> <lucy.yong@huawei.com <mailt= o:lucy.yong@huawei.com>>
>>>>>>>&g= t;>>>>> wrote:
>>>>>>>>= ;>>>>>
>>>>>>>>>>= ;>>>
>>>>>>>>>>>>= ;>
>>>>>>>>>>>>> Ag= ree. The arch. doc should not mandate only use of the
>>= ;>>>>>>>>>>> service path identifier to dr= ive the forwarding actions.
>>>>>>>>&= gt;>>>>
>>>>>>>>>>&= gt;>> Lucy
>>>>>>>>>>>= >>
>>>>>>>>>>>>>= *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf
>>&= gt;>>>>>>>>>> Of*mohamed.boucadair@orange.com=
>>>>>>>>>>>>> <mai= lto:mohamed.boucadair@orange.com> *Sent:*Thursday,
>>= ; July
>>>>>>>>>>>>> 1= 0, 2014 2:06 AM *To:*mikebianc@aol.com
>>>>>&g= t;>>>>>>> <mailto:mikebianc@aol.com>;jmh@joelhal= pern.com
>>>>>>>>>>>>>= <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>>>= >>>>>>>>>> <mailto:sfc@ietf.org> *Subje= ct:*Re: [sfc] Service Chains,
>>>>>>>>= ;>>>>> Paths, and Load Balancers
>>>&= gt;>>>>>>>>>
>>>>>&= gt;>>>>>>> Re-,
>>>>>>= >>>>>>>
>>>>>>>>= >>>>> The merged draft calls out explicitly a service path>>>>>>>>>>>>> identifie= r. I object to use that identifier to derive
>>>>= >>>>>>>>> forwarding actions.
>= >>>>>>>>>>>>
>>>= >>>>>>>>>> Requiring a SFC system to have the= full knowledge of every
>>>>>>>>>= available SFC
>>>>>>>>>>>&g= t;> forwarding paths within an SFC-enabled domain is not
&= gt;>>>>>>>> required/justified
>&g= t;>>>>>>>>>>> nor possible in various depl= oyment contexts.
>>>>>>>>>>>= >>
>>>>>>>>>>>>>= SFC forwarding actions should rely on the piece of
>>&= gt;>>>>>>>>>> information
>&= gt;>>>>>>> that will
>>>>>= ;>>>>>>>> be present in all deployments: that is th= e one required to
>>>>>>>>>>>= ;>> structure a service chain. How that information is used to
>>>>>>>>>>>>> infer forwardi= ng
>>>>>>>>> actions
>>>>>>>>>>>>> is a solution-oriente= d discussion.
>>>>>>>>>>>>= ;>
>>>>>>>>>>>>> Ch= eers,
>>>>>>>>>>>>>>>>>>>>>>>>>> Med
>>>>>>>>>>>>>
= >>>>>>>>>>>>> *De :*sfc [mailto:sfc-= bounces@ietf.org]*De la part
>>>>>>>>= > de*mikebianc@aol.com
>>>>>>>>>= ;>>>> <mailto:mikebianc@aol.com> *Envoy=C3=A9 :*mercredi = 9 juillet
>>>>>>>>>>>>>= ; 2014 22:03 *=C3=80 :*jmh@joelhalpern.com
>>>>&g= t;>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@i= etf.org
>>>>>>>>>>>>> = <mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service Chains,
>>>>>>>>>>>>> Paths, and Load Bala= ncers
>>>>>>>>>>>>>>>>>>>>>>>>>> Is anyone = still questioning the difference between SF Chain
>>>= ;>>>>>>>>>> and SF
>>>= >>>>>> Path?
>>>>>>>&g= t;>>>>> Other than clarifying the definition so that it's cl= ear to
>>>>>>>>> those not
>>>>>>>>>>>>> familiar with t= he draft, it seems that everyone agrees on
>>>>&g= t;>>>>>>>> these terms.
>>>&= gt;>>>>>>>>>
>>>>>&= gt;>>>>>>> To me, the one point that is still unclear = is whether it is
>>>>>>>>>>>= >> the intent of this draft to ultimately specify what the ID
>>>>>>>>>>>>> of the SFC Head= er
>>>>>>>>> should
= >>>>>>>>>>>>> reference (the chain o= r the path), or if this draft simply
>>>>>>= >>>>>>> intends to leave that ambiguous, allowing othe= r drafts to
>>>>>>>>>>>>&= gt; dictate the mechanisms for forwarding based on chain or
&= gt;>>>>>>>>>>>> path and the choice of = chain or
>>>>>>>>> path to
>>>>>>>>>>>>> be negotiated i= n the control-plane.
>>>>>>>>>>= >>>
>>>>>>>>>>>>= > If the latter (ambiguous), then the draft would have
>= ;>>>>>>>>>>>> require that both SFP and= SFC be supported (or make one
>>>>>>>&g= t;>>>>> required and the other optional) to avoid some vendo= rs only
>>>>>>>>>>>>> = supporting SFP and others only supporting SFC.
>>>&g= t;>>>>>>>>>
>>>>>&g= t;>>>>>>>
>>>>>>>&g= t;> --------------------------------------------------------------------= -
>>>> ---
>>>>>>= >>>
>>>>>>>>>
>>>>>>>>>
>>>>>&= gt;>>>
>>>>>>>>>>><= br class=3D"">>>>>>>>>>>>>> *From:*j= mh@joelhalpern.com<jmh@joelhalpern.com
>>>>>= ;>>>>>>>> <mailto:jmh@joelhalpern.com%3cjmh@joel= halpern.com>>
>>>>>>>>>>&= gt;>> *To:*sfc@ietf.org<sfc@ietf.org
>>>>= ;>>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.or= g>> *Sent:*Tuesday, July
>>>>>>>&g= t;>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and L= oad
>>>>>>>>>>>>> Bala= ncers
>>>>>>>>>>>>>>>>>>>>>>>>>> I have bee= n trying to figure out how to clearly answer a
>>>&g= t;>>>>>>>>> number of comments that have been ma= de about the
>> proposed
>>>>= >>>>>>>>> merged archtiecture draft. Assuming we= can get working
>>>>>>>>>>>= >> group agreement on the intent, we will work to improve the
>>>>>>>>>>>>> wording so that= readers who have not participated in the WG
>>>>= >>>>>>>>> discussion will understnd it the way t= he
>>>>>>>>> working
>>>>>>>>>>>>> group intends.
>>>>>>>>>>>>>
= >>>>>>>>>>>>> But what do we intend?= I will try to explain my personal
>>>>>>&g= t;>>>>>> view, and see if that helps.
>&= gt;>>>>>>>>>>>
>>>&= gt;>>>>>>>>> In this regard, it is important to = keep in mind that what
>>>>>>>>>&g= t;>>> we are defining is the data plane architecture. We are not>>>>>>>>>>>>> attemptin= g to define the architecture for the entire
>>>>&= gt;>>>>>>>> solution for service chaining. That wou= ld encompass
>>>>>>>>>>>>= > OSS/BSS, various control and policy functions, virtual
&= gt;>>>>>>>>>>>> machine and image manag= ement, and many other aspects.
>>>>>>>&g= t;>>>>>
>>>>>>>>>&g= t;>>> As a result there are many things which clearly need to
>>>>>>>>>>>>> exist in the= larger system, but which are dealt with above
>>>&g= t;>>>>>>>>> where we are
>>&= gt;>>>>>> functioning,
>>>>>= >>>>>>>> and are not directly required by the work = we are doing.
>>>>>>>>>>>>= ;>
>>>>>>>>>>>>> In= order to get to service chain vs service path, as I
>>= >>>>>>>>>>> understand
>&= gt;>>>>>>> them,
>>>>>>= ;>>>>>>> I need to first discuss load balancing. There= are at least
>>>>>>>>>>>>= ;> three different ways that load balancing can and will
&= gt;>>>>>>>>>>>> interact with service c= haining. There probably are more.
>>>>>>>= ;>>>>>> The point of the archtiecture is to permit all of= these,
>>>>>>>>>>>>> = but not to mandate that any particular kind
>>>>&= gt;>>>> be used
>>>>>>>>&= gt;>>>> in any solution.
>>>>>>= >>>>>>>
>>>>>>>>= >>>>> 1) Load balancing as a service provided to the end use= r.
>>>>>>>>>>>>> This = is a service function. It receives user packets, and
>>= >>>>>>>>>>> modifies them (or
>>>>>>>>> marks
>>>>= >>>>>>>>> them, or ...) so as to choose an end u= ser service instance
>>>>>>>>>>= >>> to receive the users packet. This is an important service
>>>>>>>>>>>>> function to = be able to include in service chaining. It's
>>>>= >>>>>>>>> behavior may affect requirements on ho= w service chaining is
>>>>>>>>>>= ;>>> done. But it has very little impact on the archtiecture.
>>>>>>>>>>>>>   = From an architectural pe3rspective it is simply a
>>&g= t;>>>>>> service
>>>>>>&g= t;>>>>>> function which may modify the underlying packet.=
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) There is int= ernal load balancing. That is, one can have
>>>>&= gt;>>>>>>>> what
>>>>>= >>>> appears
>>>>>>>>>= >>>> to the service chaining architecture as a single point of<= br class=3D"">>>>>>>>>>>>>> contact<= br class=3D"">>>>>>>>>> for a
>= >>>>>>>>>>>> specific service function,= but is actually delivered by a
>>>>>>>&= gt;> collection of
>>>>>>>>>>= ;>>> virtual or physical machines, possibly including one or
>>>>>>>>>>>>> several load = balancers (for example using VRRP-like
>>>>>&g= t;>>>>>>> techniques to share a MAC address.) mostly, = this is
>>>>>>>>>>>>> = invisible to the service chaining data plane mechanisms. It
&= gt;>>>>>>>>>>>> is likely that it is vi= sible to various control mechanisms,
>>>>>>= >>>>>>> such as those responsible for scale-in, scale-= out, and vm
>>>>>>>>>>>>&= gt; instantiation. The architectural impact of permitting this
>>>>>>>>>>>>> is largely that we n= eed to be careful that our terminology
>>>>>&g= t;>>>>>>> does not lead
>>>>= >>>>> readers to
>>>>>>>&= gt;>>>>> think we are prohibiting it.
>>= >>>>>>>>>>>
>>>>= >>>>>>>>> 3) There can also be load balancing do= ne by selecting
>>>>>>>>>>>&= gt;> packet paths for the service chaining that direct traffic
>>>>>>>>>>>>> to different pla= ces. We would not want to require that a
>>>>>= >>>>>>>> given service function appear at only one = place in the
>>>>>>>>>>>>= > network.
>>>>>>>>>>>>= ;>
>>>>>>>>>>>>> It= is of course the case that these may be combined. I tend
>= ;>>>>>>>>>>>> to
>>= >>>>>>> refer to
>>>>>>= ;>>>>>>> the collection of entities that appear to ser= vice chaining
>>>>>>>>>>>>= ;> as a single point as a cluster. Not because cluster is a
>>>>>>>>>>>>> good term. But becau= se I do not have another one. Thus, the
>>>>>&= gt;>>>>>>> point of type 3 load balancing
>>>>>>>>> is to
>>>>= >>>>>>>>> direct different subsets of traffic to= different singular
>>>>>>>>>>&= gt;>> or clustered service functions in different places in the
>>>>>>>>>>>>> network.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now with that said, = what do I mean when I talk about
>>>>>>>= >>>>>> service chain and service path/ Service chain is a= sequence
>>>>>>>>>>>>>= ; of logical functions to be applied to a subset of packets.
= >>>>>>>>>>>>> It is equivalent of sa= ying that some subset of traffic is
>>>>>>&= gt;>>>>>> to get DPI, charging, content inspection, and f= irewall
>>>>>>>>>>>>> = while a different subset is to go directly to the cache
>&= gt;>>>>>>> without
>>>>>&= gt;>>>>>>> visiting any other service functions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not enough in= formation to direct the packets. A
>>>>>>&g= t;>>>>>> service path is, in some fashion, a sequence of = locations
>>>>>>>>>>>>>= ; in the network. Those locations will be singular or
>>= ;>>>>>>>>>>> clustered service function de= livery locations. They may be
>>>>>>>>= ;>>>>> addressed by IP address. They may be addressed as por= ts on
>>>>>>>>>>>>> an= SFF. There are many different ways that the locations
>&g= t;>>>>>>>>>>> may be known to the service = chaining infrastructure and the
>>>>>>>&= gt;>>>>> transport.
>>>>>>&g= t;>>>>>>
>>>>>>>>&g= t;>>>>>    From the point of view of the work of t= he SFC group, we
>>>>>>>>>>>= >>> need to be
>>>>>>>>>&= gt;>>> able to talk about the high level abstraction, the service<= br class=3D"">>>>>>>>>>>>>> chain, w= hich drives the forwarding. And we need to talk
>>>&= gt;>>>>>>>>> about the actual data path packets = will take in the
>>>>>>>>>>>= >> network.
>>>>>>>>>>>= ;>>
>>>>>>>>>>>>>= ; Several of the comments have said "but the whole path may
&= gt;>>>>>>>>>>>> not be known at the fro= nt." This architecture deals with
>>>>>>>= ;>>>>>> that issue in two ways. First, as noted in item (= 2) on load
>>>>>>>>>>>>&g= t; balancers above, there can be decisions and behaviors which
>>>>>>>>>>>>> are invisible to the= service chaining mechanisms (in much
>>>>>>= ;>>>>>>> the same way that bridging within a LAN is la= rgely
>>>>>>>>>>>>> in= visible to routing between LANs.) The other provision we
>= >>>>>>>>>>>> make is
>= >>>>>>>> that
>>>>>>= ;>>>>>>> reclassification can be done in mid-chain whe= n necessary.
>>>>>>>>>>>>= > That will direct packets to a new chain. Based on
>&g= t;>>>>>>>>>>> information available at the= re-classification point.
>>>>>>>>>= ;>>>>
>>>>>>>>>>>= ;>> I hope that this helps explain what we are after. If it
>>>>>>>>>>>>> does, and if the= intent is acceptable to the working group,
>>>>&= gt;>>>>>>>> we can figure out what additional words= are needed to
>>>>>>>>>>>&g= t;> convey this. If the working group disagree with the intent,
>>>>>>>>>>>>> then we will of = course adjust to match the working group
>>>>>= >>>>>>>> agreements. If this is still unclear, I am= not sure what to
>>>>>>>>>>>= ;>> try next.
>>>>>>>>>>&= gt;>>
>>>>>>>>>>>>&= gt; Yours, Joel
>>>>>>>>>>>&= gt;>
>>>>>>>>>>>>> = _______________________________________________ sfc
>> = mailing
>>>>>>>>>>>>> = list sfc@ietf.org <mailto:sfc@ietf.org>
>>>>= ;>>>>>>>>> https://www.ietf.org/mailman/listinfo= /sfc
>>>>>>>>>>>>>
>>>>>>>>>>>>> ___________= ____________________________________ sfc
>> mailing
>>>>>>>>>>>>> list sfc@ie= tf.org <mailto:sfc@ietf.org>
>>>>>>&g= t;>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>>>>>
= >>>>>>>>>>>>
>>>= >>>>>>>>> ______________________________________= _________ sfc
>> mailing
>>>>= >>>>>>>> list sfc@ietf.org https://www.ietf.org/mai= lman/listinfo/sfc
>>>>>>>>>>>= ;>
>>>>>>>>>>>
>>>>>>>>>>> ________________________= _______________________ sfc
>> mailing
&g= t;>>>>>>>>>> list sfc@ietf.org https://www.ie= tf.org/mailman/listinfo/sfc
>>>>>>>>&= gt;>>
>>>>>>>>>>
>>>>>>>>>> ____________________________= ___________________ sfc
>> mailing list
&= gt;>>>>>>>>> sfc@ietf.org https://www.ietf.org/m= ailman/listinfo/sfc
>>>>>>>>>><= br class=3D"">>>>>>>>>>
>>&g= t;>>>>>> _______________________________________________ = sfc
>> mailing list
>>>>>&= gt;>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>
>>>>&g= t;>>> _______________________________________________ sfc mailing<= br class=3D"">>> list
>>>>>>>> = sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>&g= t;>>>>>>
>>>>>>>> _= ______________________________________________ sfc mailing
&g= t;> list
>>>>>>>> sfc@ietf.org htt= ps://www.ietf.org/mailman/listinfo/sfc
>>>>>&g= t;>>
>>>>>>>
>>= ;>>>>
>>>>>> __________________= _____________________________
>>>>>> sfc ma= iling list
>>>>>> sfc@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>
>>>>>
>>>>> _______________________________________________=
>>>>> sfc mailing list
>>= >>> sfc@ietf.org
>>>>> https://www.ie= tf.org/mailman/listinfo/sfc
>>>>>
>>>>
>>>> _________________________= ______________________
>>>> sfc mailing list
>>>> sfc@ietf.org
>>>> http= s://www.ietf.org/mailman/listinfo/sfc
>>
= >> _______________________________________________
>= > sfc mailing 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_3056_1707963818.1405094108955-- From nobody Fri Jul 11 08:57: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 23ED51B2B22 for ; Fri, 11 Jul 2014 08:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.551 X-Spam-Level: X-Spam-Status: No, score=-13.551 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_BACKHAIR_27=1, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 o_gmsV4fb2P2 for ; Fri, 11 Jul 2014 08:57:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1F01B2B0A for ; Fri, 11 Jul 2014 08:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51634; q=dns/txt; s=iport; t=1405094312; x=1406303912; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bxXo1pxwAMyQPP+DOaBN8WjlXiReTYYdXToHcBYZ0Sg=; b=hJvXggVzHTtWYi0U1N7QvK9OHnltWbaAYPNjCc2fy7SAEMyI8ykTjiew Tiuim1TbYhGUI+pDnr2Zoa24aLYGvnSBbHGLTc36sWNjHgvCwzJY4nG+A HvsKtPga4SgSU5QKW1xImzZwMkAj3iKkeaewRSSa+PJuimZIE82smgJza c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPAHwFOtJV2c/2dsb2JhbABPCoJHR1Jap2qHD5F4AQmHQgGBCxZ1hAMBAQEEAQEBFw0xDQIHCxACAQgRAQIBAQEhAQYHJwsUAwYIAgQBDQUbiBMDEQ3GPxMEjR2BUEsHBgQGAYRDBZYiSYQai2iININEgjA X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208,217";a="339384801" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2014 15:58:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6BFvQJV009940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 15:57:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 10:57:26 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAXQIAgADO1gCAAG79AP//wFoA Date: Fri, 11 Jul 2014 15:57:26 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE5811E2D4B8jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ad_7hE_I6Gb_Y_W96Nq4fplj4lk Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 15:57:38 -0000 --_000_CFE5811E2D4B8jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No they do not have to be physically connected but they are hidden behind a= n SFF in this case but do not have to be. From: "mikebianc@aol.com" > Date: Friday, July 11, 2014 at 11:44 AM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers When you say "20 instances of the SF2 SF" are "Connected to that SFF" do yo= u mean physically? I had always just assumed that if I had 20 instances of= a SF, that they would be diverse. Even if within the same datacenter, the= y would be not near each other. It also seems like you are saying that the= re is only a single SFF for SF2 and that your traffic path requires travers= ing SF2 as a separate hop from the SF2 instance. Ideally, the traffic woul= d flow from SF1 instance to SF2 instance over the best path without the nee= d for an intermediary hop. *In my statements above, I assuming that each SF Instance is SFC aware to s= implify the text. ________________________________ From: jguichar@cisco.com> To: mikebianc@aol.com>,mn1921@att.com> cc: sfc@ietf.org> Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation wil= l contain a path identifier as described within our charter which says =933= . Generic SFC encapsulation: This document will describe a single service-l= evel data plane encapsulation format that indicates the sequence of service= functions that make up the Service Function Chain; specifies the Service F= unction Path=94. The wording here is very important and shows that the inte= nt is that the sequence of SF=92s be indicated within the SFC encapsulation= e.g. not carried =96 this is not source routing, and specifies the SFP, he= nce the path identifier. For my example let=92s assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1=94 It is possible that each of those SF=92s be directly addressable (i.e. prov= ide SFF functionality) or reachable through some other network device that = provides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF=92= s; let=92s call them SF1-loc1, SF2-loc2, and SF3-loc3. When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier =93100=94. This information is di= stributed to the relevant network devices basically saying =93if you receiv= e an SFC encapsulated packet with path identifier =93100=94 then use the pa= th identifier and index to perform a lookup in a data structure that will t= ell you which SF to forward the traffic to and how to get there=94. So traffic flows through the SFP with path identifier =93100=94, via a netw= ork transport (the path identifier is encapsulated). It reaches SF1-loc1 wh= ich uses the path identifier to determine that it is in fact the SF that sh= ould be applied. It applies SF1 SF and then uses the path identifier to det= ermine that SF2 is the next service and its reachable at next-hop SF2-loc2.= The needed transport (for example VXLAN) is imposed for network forwarding= . Traffic reaches SF2-loc2. It uses the path identifier to determine that S= F2 should be applied. It uses a local decision to determine which of the 20= instances of SF2 it should forward the traffic to. It forwards the traffic= to the selected instance. SF2 is applied and then another lookup occurs on= the path identifier, which results in the needed transport being imposed t= o reach the next service hop SF3-loc3 .. And so on and so forth. So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From: "mikebianc@aol.com" > Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim, Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at al= l. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. ________________________________ From: jguichar@cisco.com> To: NAPIERALA, MARIA H> cc: Paul Quinn (paulq)>,Lucy yong>,jmh@joelhalpern.com>,moh= amed.boucadair@orange.com>,sfc@ietf.org>,mikebianc@aol.com> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make t= he minor change: the path identifier can be used to derive the needed forwa= rding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a = lookup, that lookup can result in a one or more (equal or weighted) transpo= rt next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behal= f Ofmohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;= jmh@joelhalpern.com= ;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la par= t demikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From:jmh@joelhalpern.com<= mailto:jmh@joelhalpern.com>= > To: sfc@ietf.org<= sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CFE5811E2D4B8jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
No they do not have to be physically connected but they are hidden beh= ind an SFF in this case but do not have to be.

From: "mikebianc@aol.com" <mikebianc@aol.com>
Date: Friday, July 11, 2014 at 11:4= 4 AM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers

When you say "20 instances of the SF2 SF" are "Connecte= d to that SFF" do you mean physically?  I had always just assumed= that if I had 20 instances of a SF, that they would be diverse.  Even= if within the same datacenter, they would be not near each other.  It also seems like you are saying that there is only a single SFF fo= r SF2 and that your traffic path requires traversing SF2 as a separate hop = from the SF2 instance.  Ideally, the traffic would flow from SF1 insta= nce to SF2 instance over the best path without the need for an intermediary hop.

*In my statements above, I assuming that each SF Instance is SFC aware= to simplify the text.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Mike,

There still seems to be some confusion around this topic so let me try= to provide a more detailed explanation as to how I believe this should wor= k and why what I explained earlier is in fact a path identifier and not a c= hain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =933. Generic SFC encapsulation: This do= cument will describe a single service-level data plane encapsulation format= that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path=94. The wording here is very imp= ortant and shows that the intent is that the sequence of SF=92s be indicate= d within the SFC encapsulation e.g. not carried =96 this is not source routing, and specifies= the SFP, hence the path identifier.

For my example let=92s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1= =94

It is possible that each of those SF=92s be directly addressable (i.e.= provide SFF functionality) or reachable through some other network device = that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 = relies on a connected switch to provide the needed SFF functionality. Conne= cted to that SFF are 20 instances of the SF2 SF. In this case you have exac= tly 3 network locators from which to choose in order to reach the required SF=92s; let=92s call them SF1-loc= 1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locator= s are selected to construct the path, and a path identifier is allocated. I= n this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> = SF2-loc2 -> SF3-loc3 and it has a path identifier =93100=94. This information is distributed to the relevant netw= ork devices basically saying =93if you receive an SFC encapsulated packet w= ith path identifier =93100=94 then use the path identifier and index to per= form a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=94.

So traffic flows through the SFP with path identifier =93100=94, via a= network transport (the path identifier is encapsulated). It reaches SF1-lo= c1 which uses the path identifier to determine that it is in fact the SF th= at should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth.

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).


<= /span>

From: &qu= ot;mikebianc@aol.com" <mikebianc@aol.com>

Date: Thursday, July 10, 2014 at 4:= 46 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers


Jim,

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop? In this case, there wouldn't be any Path Identifier = at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there wil= l be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=92d make the minor change: the path identifier can be used to = derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc should not man= date only use of the service path identifier to drive the forwarding action= s.

Lucy

From:sfc [mailto:sfc-bounces@ietf.org<= /a>]On Behalf Ofmohamed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com;jmh@joelhalpern.com<= /a>;sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a s= ervice path identifier. I object to use that identifier to derive forwardin= g actions.

Requiring a SFC system to have the full k= nowledge of every available SFC forwarding paths within an SFC-enabled doma= in is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the= piece of information that will be present in all deployments: that is the = one required to structure a service chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion.

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org<= /a>]De la part demikebianc@aol.com
Envoy=E9 : mercredi 9 j= uillet 2014 22:03
=C0 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain an= d SF Path? Other than clarifying the definition so that it's clear to those= not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is th= e intent of this draft to ultimately specify what the ID of the SFC Header = should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require t= hat both SFP and SFC be supported (or make one required and the other optio= nal) to avoid some vendors only supporting SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
 --_000_CFE5811E2D4B8jguicharciscocom_-- From nobody Fri Jul 11 09:00: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 AFC951B2B55 for ; Fri, 11 Jul 2014 09:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_29=0.6, 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 zFr1w25g3DCK for ; Fri, 11 Jul 2014 09:00:24 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A0F1B2B4F for ; Fri, 11 Jul 2014 09:00:22 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so362209pab.34 for ; Fri, 11 Jul 2014 09:00:22 -0700 (PDT) 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=nVFW2T05q3OJ0w39j8rXXrgCegaoSSngID1t4brppgg=; b=bLzAcTVCJKCQvNTA/27GTkdUjBnAcDR2LQBYrtLX13a0sSbp33uh+zcQ0YH0RsUQzE YZSWc3WSQaLaZwvNALcUmhzGe//NvqiCCY6zD47ggoeI5Z3wOtfoP+cXRmtL1eV1LRTe V8/Z0kpY3lyacBRdOS8rNHAemOwmXk/VXry4zmZkpQkShKB1EN3/9HL5B13fLGpa3Qfk PxMNEGJwRx81lGQCwoCXlD0iB70Cgwd0bQPpjsYwKhkQHz43FufNvy6WT0mDK2WVhrXN T/KkVtPrOl7IwNy5ftzuL8CJxhtPapkz2HszRvmdMUWlKmvnZVGtHLk2Av1KbislSYRV /jZA== X-Received: by 10.68.229.68 with SMTP id so4mr29533899pbc.110.1405094422314; Fri, 11 Jul 2014 09:00:22 -0700 (PDT) Received: from [192.168.1.177] ([157.22.28.27]) by mx.google.com with ESMTPSA id ih6sm2695699pbc.22.2014.07.11.09.00.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 09:00:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11D257) In-Reply-To: <53C0041E.6050605@joelhalpern.com> Date: Fri, 11 Jul 2014 09:00:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53BCAB74.4060801@joelhalpern.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C0041E.6050605@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qN6uPa86xrnn_GwDVRtCcKpqsJs Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" , "mohamed.boucadair@orange.com" , Ron Parker , "NAPIERALA, MARIA H" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:00:29 -0000 We can reference other standard ID-Location mapping mechanisms (local or dis= tributed) for matching SF-SFF. These can be leveraged by SFFs for load distr= ibution and dynamic failure recovery not based on centralized orchestration.= --szb > On Jul 11, 2014, at 8:34, "Joel M. Halpern" wrote: >=20 > I agree that the current text treats the SFP is selecting a specific seque= nce of SFFs. > Note that the selection is still mediated by the configuration in the SFFs= which act on the service path information in the header. >=20 > So what I am suggesting, to address your concern, is that we relax the (im= plicit) requirement that the mapping to the next-SFF be singular. We will d= escribe how it can be multiple sufficiently equivalent next-SFFs. Jim's rea= ding of the document is that such multiplicity was already allowed. By maki= ng it explicit, we will avoid any confusion. >=20 > This should then allow: > Some traffic distribution management by service path selection > Some traffic distribution management by load balancing between the SFF and= the actual service functions it is connecting. > And some traffic distribution management by the use of multiple next-SFF a= t some SFF, in a variety of fashions. >=20 > Yours, > Joel >=20 >> On 7/11/14, 11:26 AM, NAPIERALA, MARIA H wrote: >> Jim, >>=20 >> Could you tell us what is the definition of a "service path" and a "servi= ce path identifier"? >> If a service path means that all SF instances are chosen apriori (which i= s my current understanding) then it is not SFF's local decision which next-h= op SFF to pick. It is a centralized decision. >>=20 >> Maria >>=20 >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Friday, July 11, 2014 11:15 AM >>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. >>> Halpern; Ron Parker; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> I=E2=80=99m sorry but I really don=E2=80=99t understand why a service pa= th identifier >>> prevents full distribution of SF next-hops or why calling it a service >>> chain identifier makes any difference? >>>=20 >>>> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" wrote: >>>>=20 >>>> Ditto. >>>>=20 >>>>> -----Original Message----- >>>>> From: mohamed.boucadair@orange.com >>>>> [mailto:mohamed.boucadair@orange.com] >>>>> Sent: Friday, July 11, 2014 10:31 AM >>>>> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron >>>>> Parker; sfc@ietf.org >>>>> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> Re-, >>>>>=20 >>>>> For what I can say at best this is not described clearly in the draft.= >>>>>=20 >>>>> Mandating a service path identifier is in itself a hint that the full >>>>> distributed >>>>> model is not allowed. >>>>>=20 >>>>> Several voices in this thread indicated that the service chain itself >>>>> should be >>>>> provided instead. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >>>>>> (jguichar) >>>>>> Envoy=C3=A9 : vendredi 11 juillet 2014 16:18 >>>>>> =C3=80 : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.or= g >>>>>> Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Ok but where in the architecture specifically is this functionality >>>>>> prohibited? If you want to distribute *all* next-hops to *all* SFF=E2= =80=99s >>>>>> within the SFC domain and then let the path identifier point to a >>>>> lookup >>>>>> into those next-hops to reach the next SF in the chain, I am not sure= >>>>> how >>>>>> the architecture prevents that? >>>>>>=20 >>>>>> On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" >>> wrote: >>>>>>=20 >>>>>>> Absolutely. >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>>>>>>> (jguichar) >>>>>>>> Sent: Friday, July 11, 2014 9:54 AM >>>>>>>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>=20 >>>>>>>> Then I misunderstand the proposal ;-) .. However, it seems to me >>>>> that if >>>>>>>> you allow an SFF to make a decision as to which remote SFF it will >>>>> use >>>>>>>> for >>>>>>>> a given flow to reach the next SF within the chain then you better >>>>> make >>>>>>>> sure that that remote SFF has the necessary forwarding logic to >>>>> reach >>>>>>>> the >>>>>>>> next-next-SF for the chain as otherwise you are in deep trouble. >>>>>>>>=20 >>>>>>>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" >>>>> wrote: >>>>>>>>=20 >>>>>>>>> Absolutely not. Service chains can be instantiated only in relevan= t >>>>>>>> SFFs >>>>>>>>> when they "arrive". >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard= >>>>>>>>>> (jguichar) >>>>>>>>>> Sent: Friday, July 11, 2014 9:27 AM >>>>>>>>>> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>=20 >>>>>>>>>> Well I think it is even worse than that if I have understood the >>>>>>>>>> proposal >>>>>>>>>> correctly as it would require full knowledge of every single SF >>>>>>>> within >>>>>>>>>> the >>>>>>>>>> entire SFC domain at every single SFF as there is no way to know >>>>> a >>>>>>>>>> priori >>>>>>>>>> which SFC=C2=B9s a given SFF will need to service at any given po= int >>>>> in >>>>>>>> time. >>>>>>>>>>=20 >>>>>>>>>> On 7/10/14, 11:53 PM, "Joel M. Halpern" >>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Ron, thinking about this, I realized another major problem with >>>>> the >>>>>>>>>> your >>>>>>>>>>> proposal as I understand it. (And I readily admit I may not >>>>>>>> understand >>>>>>>>>>> it.) >>>>>>>>>>>=20 >>>>>>>>>>> The proposal has each SFF serve as the load balancer for the >>>>> next >>>>>>>>>>> service function that follows it (not the one it delivers to), >>>>> in >>>>>>>> every >>>>>>>>>>> service chain that goes through it. >>>>>>>>>>>=20 >>>>>>>>>>> Since it has to be able to work with all services, that means >>>>> that >>>>>>>>>> every >>>>>>>>>>> SFF would have to be a full, flow sensitive and stateful load >>>>>>>> balancer. >>>>>>>>>>> I ahve no problem if some SFF are flow sensitive, and / or >>>>> stateful. >>>>>>>>>>> But having the architecture require that every SFF be a full, >>>>> flow >>>>>>>>>>> sensitive, stateful, load balancer seems to me to be an >>>>> acceptable >>>>>>>>>>> imposition. >>>>>>>>>>>=20 >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>>=20 >>>>>>>>>>>> On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>>>>>>>>>>> Part of my personal view is that I am trying to make this work >>>>>>>>>> sensibly >>>>>>>>>>>> in a more orchestrated environment. I expect that the service >>>>>>>>>>>> functions, and over time probably the SFF capabilities, will >>>>> be >>>>>>>>>>>> orchestrated and installed. I expect the service chains to be >>>>>>>>>> driven by >>>>>>>>>>>> BSS tools that define offerings to clients, and enable >>>>>>>> self-selection >>>>>>>>>>>> from these. I expect service paths to be heavily policy >>>>> drive. >>>>>>>>>>>>=20 >>>>>>>>>>>> I can see how to make all of that work in an archtiecture >>>>> driven >>>>>>>> by >>>>>>>>>>>> initial classification to described service paths. It is >>>>> harder >>>>>>>> to >>>>>>>>>> see >>>>>>>>>>>> how to make it work (but it can be done) when we allow more >>>>>>>>>> dynamicity >>>>>>>>>>>> in the network behavior. >>>>>>>>>>>>=20 >>>>>>>>>>>> Having said that, most of that perspective I described is >>>>> outside >>>>>>>> of >>>>>>>>>> the >>>>>>>>>>>> scope of the working group. it is not something we are >>>>> tasked to >>>>>>>>>> agree >>>>>>>>>>>> on. >>>>>>>>>>>> So I do not claim that vision means we have to do it a certain >>>>>>>> way. >>>>>>>>>> it >>>>>>>>>>>> is just the perspective that drives my preferences. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>> On 7/10/14, 9:58 PM, Ian Smith wrote: >>>>>>>>>>>>>> For me, the amount of information about service instances >>>>> that >>>>>>>>>> needs >>>>>>>>>>>>>> to >>>>>>>>>>>>>> be widely distributed and maintained, potentially even >>>>> across >>>>>>>> data >>>>>>>>>>>>>> centers within an administrative scope, is large enough and >>>>>>>> complex >>>>>>>>>>>>>> enough that trying to get that into each SFF seems like a >>>>>>>> difficult >>>>>>>>>>>>>> architecture to realize. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm curious as to why that is more complicated than dynamic >>>>>>>> routing, >>>>>>>>>>>>> hyper-scale data center orchestration, or DNS, all of which >>>>> are >>>>>>>>>> bigger >>>>>>>>>>>>> problems that have been profitably and stably implemented? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It also seems that if it really is more complicated, that is >>>>> a >>>>>>>> good >>>>>>>>>>>>> sign that it is too complicated. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ________________________________________ >>>>>>>>>>>>> From: Joel M. Halpern [jmh@joelhalpern.com] >>>>>>>>>>>>> Sent: Thursday, July 10, 2014 9:45 PM >>>>>>>>>>>>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian >>>>>>>> Smith; >>>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This is an architectural issue. And one that I would prefer >>>>> we >>>>>>>>>>>>> actually >>>>>>>>>>>>> decide, rather than trying to allow all possible >>>>> implementations. >>>>>>>>>>>>> Because it does have a major effect on the control >>>>> requirements >>>>>>>> and >>>>>>>>>> the >>>>>>>>>>>>> functionality of SFFs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> For me, the amount of information about service instances >>>>> that >>>>>>>> needs >>>>>>>>>> to >>>>>>>>>>>>> be widely distributed and maintained, potentially even >>> across >>>>>>>> data >>>>>>>>>>>>> centers within an administrative scope, is large enough and >>>>>>>> complex >>>>>>>>>>>>> enough that trying to get that into each SFF seems like a >>>>>>>> difficult >>>>>>>>>>>>> architecture to realize. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>> But it is a fair question. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>>>>>>>>>>>>> This is the crux of my issue. Is the end to end selection >>>>> of >>>>>>>>>>>>>> (top-level) instances performed centrally (perhaps by the >>>>>>>>>> classifier) >>>>>>>>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently >>>>> the >>>>>>>>>> SFFs)? >>>>>>>>>>>>>> Such selection is not equivalent to reclassification. And >>>>>>>> surely, >>>>>>>>>>>>>> this is an architectural issue and not relegated to >>>>>>>>>>>>>> "implementation". >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> My own view is to favor the distributed approach even >>> though >>>>> a >>>>>>>>>>>>>> greater amount of data (chain definitions and perhaps local >>>>>>>>>> selection >>>>>>>>>>>>>> policy) is required at those distributed decision points. >>>>> This >>>>>>>>>>>>>> approach does not require an end-to-end path id at all. >>>>> My >>>>>>>>>>>>>> rationale for favoring this approach is primarily driven by >>>>>>>>>> increased >>>>>>>>>>>>>> resiliency over the global path id approach. With a global >>>>>>>> path >>>>>>>>>> id >>>>>>>>>>>>>> approach, consider failure of an instance and needing to >>>>> alter >>>>>>>> the >>>>>>>>>>>>>> global path ID table for each and every affected end-to-end >>>>>>>> path. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ________________________________________ From: sfc >>>>>>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >>>>>>>>>>>>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 >>>>> 6:15 >>>>>>>> PM >>>>>>>>>>>>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org >>> Subject: >>>>> Re: >>>>>>>>>>>>>> [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The way the architecture models the case of SF1 needing to >>>>>>>>>> influence >>>>>>>>>>>>>> the chain is that one would do reclassification at the exit >>>>> from >>>>>>>>>>>>>> SF1. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Part of the goal is to keep the different functions >>>>> logically >>>>>>>>>>>>>> separate so that solutions can clearly describe how they >>>>> choose >>>>>>>> to >>>>>>>>>>>>>> compose them for "service" delivery. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >>>>>>>>>>>>>>> I don't see anything in the arch draft that suggests any >>>>> sort >>>>>>>> of >>>>>>>>>>>>>>> limit. However, it does seem to indicate that the entire >>>>> path >>>>>>>> (all >>>>>>>>>>>>>>> SFIs) must be chosen at SFC instantiation. I believe this >>>>>>>> means >>>>>>>>>>>>>>> either at the classifier or maybe the classifier chooses a >>>>> SF >>>>>>>>>> Chain >>>>>>>>>>>>>>> and the NF or at the latest the first SFF. In any case, >>>>> the >>>>>>>>>>>>>>> language does seem to prohibit a more dynamic SFP where >>>>> SFI(n) >>>>>>>> is >>>>>>>>>>>>>>> determined at the SFI(n-1) hop. According to the draft, >>>>> this >>>>>>>>>>>>>>> behavior would be considered "branching" to a new SFP as >>>>>>>> opposed >>>>>>>>>> to >>>>>>>>>>>>>>> choosing and then forwarding to the selected instance of >>>>> the >>>>>>>>>>>>>>> next-hop of the current SFC. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> draft-merged-sfc-architecture-00: >>>>>>>>>>>>>>>> When an SFC is instantiated into the network it is >>>>> necessary >>>>>>>> to >>>>>>>>>>>>>>>> select the specific instances of SFs that will be used, >>>>> and to >>>>>>>>>>>>>>>> create the service topology for that SFC using SF's >>>>> network >>>>>>>>>>>>>>>> locator. Thus, instantiation of the SFC results in the >>>>>>>> creation >>>>>>>>>>>>>>>> of a Service Function Path (SFP) and is used for >>>>> forwarding >>>>>>>>>>>>>>>> packets through the SFC. In other words, an SFP is the >>>>>>>>>>>>>>>> instantiation of the defined SFC. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The SFC architecture supports reclassification (or >>>>> non-initial >>>>>>>>>>>>>>>> classification) as well. As packets traverse an SFP, >>>>>>>>>>>>>>>> reclassification may occur - typically performed by a >>>>>>>>>>>>>>>> classification function co-resident with a service >>>>> function. >>>>>>>>>>>>>>>> Reclassification may result in the selection of a new >>>>> SFP, an >>>>>>>>>>>>>>>> update of the associated metadata, or both. This is >>>>> referred >>>>>>>> to >>>>>>>>>>>>>>>> as "branching". >>>>>=20 >>>>>>>>>>>>>>> ------------------------------------------------------------= --- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>> *From: *I.Smith@F5.com >>>>>>>>>>>>>>> *To: *Joel Halpern >>> Direct,Joel >>>>> M. >>>>>=20 >>>>>>>> Halpern,huang@sce.carleton.ca>>>>>>>>> carleton. >>>>>>>>>>>>>>> ca>,sfc@ietf.org >>>>>>>>>>>>> *Sent: *Thursday, July 10, 2014 >>>>>>>>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>>>> Balancers >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Actually, I think I am disagreeing. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If the possibility of medium-scale deployments (and that is >>>>>>>> what >>>>>>>>>>>>>>> 16 million flows is in my world) of service chains is >>>>>>>> preconceived >>>>>>>>>>>>>>> as an absurd idea, then the architecture burdened with >>> that >>>>>>>>>>>>>>> preconception. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There has to be some point of aim, some degree of >>>>> aspiration >>>>> to >>>>>>>>>>>>>>> scale that is appropriate for the lifespan of the >>>>> architecture >>>>>>>> - >>>>>>>>>>>>>>> you don't have to know what it is, but by saying that an >>>>>>>> arbitrary >>>>>>>>>>>>>>> number is "too far", you're creating - even if it isn't >>>>>>>>>> intentional >>>>>>>>>>>>>>> - a limit that influences decisions that have lasting >>>>> impacts >>>>>>>>>>>>>>> regarding scale-out, failure mitigation, elasticity, >>>>> address >>>>>>>>>>>>>>> space... all kinds of things. That is a problem I'm not >>>>>>>>>>>>>>> particularly eager to deal with. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ________________________________________ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] >>>>> Sent: >>>>>>>>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>>>> Halpern; >>>>>>>>>>>>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >>>>> Service >>>>>>>>>>>>>>> Chains, Paths, and Load Balancers >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ian, I don't think you disagree with me at all in this >>>>> regard. >>>>>>>> I >>>>>>>>>> am >>>>>>>>>>>>>>> not requesting the the architecture or the solution >>>>> prohibit >>>>>>>>>>>>>>> deployments in the specific fashion. I am objecting to >>>>> Huang's >>>>>>>>>>>>>>> reading of my note as saying that such deployments are >>>>> required >>>>>>>>>>>>>>> they by the archtiecture. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As I have said repeatedly, I am not trying to prohibit such >>>>>>>>>>>>>>> things. Whether they are a good idea or not depends upon >>>>> many >>>>>>>>>>>>>>> factors outside of the scope of the WG. I happen to think >>>>> that >>>>>>>>>> they >>>>>>>>>>>>>>> are usually a bad idea. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> But the archtiecture si carefully avoiding attempting to >>>>> know >>>>>>>> what >>>>>>>>>>>>>>> is and is not eployable. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>>>>>>>>>>>>>>> I disagree. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> We routinely have stateful devices that manage tens of >>>>>>>> millions >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> concurrent flows in both access network and data center >>>>>>>>>>>>>>> environments today. You can't seriously believe that in the >>>>>>>>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you >>> are >>>>> only >>>>>>>>>> going >>>>>>>>>>>>>>> to have small numbers of service chains with equally small >>>>>>>> numbers >>>>>>>>>>>>>>> of active service paths? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Your sounds too much like "no one will ever need more >>> than >>>>>>>> 64K" >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> comfort. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> ________________________________________ From: sfc >>>>>>>>>>>>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >>>>>>>>>>>>>>> [jmh@joelhalpern.com] >>>>>>>>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>>>>>>> huang@sce.carleton.ca; >>>>>>>>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and >>>>>>>> Load >>>>>>>>>>>>>>>> Balancers >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> No, it will mean that if someone tries to deploy the >>>>>>>> archtieture >>>>>>>>>>>>>>>> particularly badly, they will exceed the limits of their >>>>>>>>>>>>>>>> devices. The architecture does not require such absurd >>> use >>>>> of >>>>>>>>>>>>>>>> service paths. Since I can not figure out how to write >>>>>>>>>>>>>>>> architectural words to prohibit it, the architecture does >>>>>>>> permit >>>>>>>>>>>>>>>> such abuse. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Please do not read my saying that the archtiecture >>> permits >>>>>>>>>>>>>>>> something as saying it is either deisred or required by >>>>> the >>>>>>>> work. >>>>>>>>>>>>>>>> It isn't. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>>>>>>>>>>>>>>>> If you need to support 100 service chains, it will mean >>>>>>>>>>>>>>>>> 16,000,000 paths. That is larger than the routing table >>>>> of a >>>>>>>>>>>>>>>>> core router. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Chang >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>>>>>>>>>>>>>>>>> The architecture allows a range of deployments, from 1 >>>>>>>>>>>>>>>>>> service path to 160000 service paths. I would hope that >>>>>>>>>>>>>>>>>> operators are prepared for the complexities if they >>>>> choose >>>>>>>> to >>>>>>>>>>>>>>>>>> avoid any use of local load balancing and in stead >>>>> provision >>>>>>>>>>>>>>>>>> 160,000 service paths. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>>>>>>> Paul, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> How many path identifiers there will be for a 4 hop >>>>> service >>>>>>>>>>>>>>>>>>> chain with 20 instances at each hop? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Maria >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>> Of >>>>>>>>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 >>>>> 3:03 >>>>>>>>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; >>>>>>>>>>>>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >>>>>>>>>>>>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service >>> Chains, >>>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Lucy, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the >>>>>>>>>>>>>>>>>>> forwarding. I=C2=B9d >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>> the minor change: the path identifier can be used to >>>>> derive >>>>>>>>>>>>>>>>>>> the needed forwarding and associated transport. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply >>>>>>>>>>>>>>>>>>> identify the service path (or graph) that packets must >>>>>>>>>>>>>>>>>>> traverse. By having a path identifier, the exact >>>>>>>>>>>>>>>>>>> indirection that people seem to be asking for on this >>>>>>>>>>>>>>>>>>> thread can be simply be implemented. The path >>>>> identifier >>>>>>>>>>>>>>>>>>> provides nothing more than a lookup, that lookup can >>>>> result >>>>>>>>>>>>>>>>>>> in a one or more (equal or weighted) transport next >>>>>>>>>>>>>>>>>>> hop(s). >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>>>>>>>>>>>>>>>>>> >>>> > >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of >>> the >>>>>>>>>>>>>>>>>>> service path identifier to drive the forwarding >>>>> actions. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Lucy >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>>>>>>>>>>>>>>>>>> Of*mohamed.boucadair@orange.com >>>>>>>>>>>>>>>>>>> >>>>>>>> *Sent:*Thursday, >>>>>>>>>> July >>>>>>>>>>>>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>>>>>>>>>>>>>>>>>> ;jmh@joelhalpern.com >>>>>>>>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>>>>>>>> *Subject:*Re: [sfc] Service >>>>> Chains, >>>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Re-, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> The merged draft calls out explicitly a service path >>>>>>>>>>>>>>>>>>> identifier. I object to use that identifier to derive >>>>>>>>>>>>>>>>>>> forwarding actions. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of >>>>> every >>>>>>>>>>>>>>> available SFC >>>>>>>>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not >>>>>>>>>>>>>>> required/justified >>>>>>>>>>>>>>>>>>> nor possible in various deployment contexts. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> SFC forwarding actions should rely on the piece of >>>>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>> that will >>>>>>>>>>>>>>>>>>> be present in all deployments: that is the one >>> required >>>>> to >>>>>>>>>>>>>>>>>>> structure a service chain. How that information is >>>>> used to >>>>>>>>>>>>>>>>>>> infer forwarding >>>>>>>>>>>>>>> actions >>>>>>>>>>>>>>>>>>> is a solution-oriented discussion. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Med >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>>>>>>>>>>>>>> de*mikebianc@aol.com >>>>>>>>>>>>>>>>>>> *Envoy=C3=A9 :*mercredi 9 >>>>> juillet >>>>>>>>>>>>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com >>>>>>>>>>>>>>>>>>> ;sfc@ietf.org >>>>>>>>>>>>>>>>>>> *Objet :*Re: [sfc] Service >>>>> Chains, >>>>>>>>>>>>>>>>>>> Paths, and Load Balancers >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Is anyone still questioning the difference between SF >>>>> Chain >>>>>>>>>>>>>>>>>>> and SF >>>>>>>>>>>>>>> Path? >>>>>>>>>>>>>>>>>>> Other than clarifying the definition so that it's >>>>> clear to >>>>>>>>>>>>>>> those not >>>>>>>>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees >>>>> on >>>>>>>>>>>>>>>>>>> these terms. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> To me, the one point that is still unclear is whether >>>>> it is >>>>>>>>>>>>>>>>>>> the intent of this draft to ultimately specify what >>>>> the ID >>>>>>>>>>>>>>>>>>> of the SFC Header >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>> reference (the chain or the path), or if this draft >>>>> simply >>>>>>>>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts >>>>> to >>>>>>>>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain >>> or >>>>>>>>>>>>>>>>>>> path and the choice of chain or >>>>>>>>>>>>>>> path to >>>>>>>>>>>>>>>>>>> be negotiated in the control-plane. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> If the latter (ambiguous), then the draft would have >>>>>>>>>>>>>>>>>>> require that both SFP and SFC be supported (or make >>>>> one >>>>>>>>>>>>>>>>>>> required and the other optional) to avoid some >>> vendors >>>>> only >>>>>>>>>>>>>>>>>>> supporting SFP and others only supporting SFC. >>>>>=20 >>>>>>>>>>>>>>> ------------------------------------------------------------= --- >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> *From:*jmh@joelhalpern.com>>>> > >>>>>>>>>>>>>>>>>>> *To:*sfc@ietf.org>>>>>>>>>>>>>>>>>> > >>> *Sent:*Tuesday, >>>>> July >>>>>>>>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >>>>>>>>>>>>>>>>>>> Balancers >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I have been trying to figure out how to clearly answer >>>>> a >>>>>>>>>>>>>>>>>>> number of comments that have been made about the >>>>>>>> proposed >>>>>>>>>>>>>>>>>>> merged archtiecture draft. Assuming we can get >>> working >>>>>>>>>>>>>>>>>>> group agreement on the intent, we will work to >>> improve >>>>> the >>>>>>>>>>>>>>>>>>> wording so that readers who have not participated in >>>>> the >>>>> WG >>>>>>>>>>>>>>>>>>> discussion will understnd it the way the >>>>>>>>>>>>>>> working >>>>>>>>>>>>>>>>>>> group intends. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> But what do we intend? I will try to explain my >>>>> personal >>>>>>>>>>>>>>>>>>> view, and see if that helps. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In this regard, it is important to keep in mind that >>>>> what >>>>>>>>>>>>>>>>>>> we are defining is the data plane architecture. We are >>>>> not >>>>>>>>>>>>>>>>>>> attempting to define the architecture for the entire >>>>>>>>>>>>>>>>>>> solution for service chaining. That would encompass >>>>>>>>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual >>>>>>>>>>>>>>>>>>> machine and image management, and many other >>>>> aspects. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> As a result there are many things which clearly need >>> to >>>>>>>>>>>>>>>>>>> exist in the larger system, but which are dealt with >>>>> above >>>>>>>>>>>>>>>>>>> where we are >>>>>>>>>>>>>>> functioning, >>>>>>>>>>>>>>>>>>> and are not directly required by the work we are >>> doing. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In order to get to service chain vs service path, as I >>>>>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>> them, >>>>>>>>>>>>>>>>>>> I need to first discuss load balancing. There are at >>>>> least >>>>>>>>>>>>>>>>>>> three different ways that load balancing can and will >>>>>>>>>>>>>>>>>>> interact with service chaining. There probably are >>>>> more. >>>>>>>>>>>>>>>>>>> The point of the archtiecture is to permit all of >>>>> these, >>>>>>>>>>>>>>>>>>> but not to mandate that any particular kind >>>>>>>>>>>>>>> be used >>>>>>>>>>>>>>>>>>> in any solution. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> 1) Load balancing as a service provided to the end >>>>> user. >>>>>>>>>>>>>>>>>>> This is a service function. It receives user packets, >>>>> and >>>>>>>>>>>>>>>>>>> modifies them (or >>>>>>>>>>>>>>> marks >>>>>>>>>>>>>>>>>>> them, or ...) so as to choose an end user service >>>>> instance >>>>>>>>>>>>>>>>>>> to receive the users packet. This is an important >>>>> service >>>>>>>>>>>>>>>>>>> function to be able to include in service chaining. >>>>> It's >>>>>>>>>>>>>>>>>>> behavior may affect requirements on how service >>>>> chaining is >>>>>>>>>>>>>>>>>>> done. But it has very little impact on the >>>>> archtiecture. >>>>>>>>>>>>>>>>>>> =46rom an architectural pe3rspective it is simply a >>>>>>>>>>>>>>> service >>>>>>>>>>>>>>>>>>> function which may modify the underlying packet. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> 2) There is internal load balancing. That is, one can >>>>> have >>>>>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>> appears >>>>>>>>>>>>>>>>>>> to the service chaining architecture as a single point >>>>> of >>>>>>>>>>>>>>>>>>> contact >>>>>>>>>>>>>>> for a >>>>>>>>>>>>>>>>>>> specific service function, but is actually delivered >>>>> by a >>>>>>>>>>>>>>> collection of >>>>>>>>>>>>>>>>>>> virtual or physical machines, possibly including one or >>>>>>>>>>>>>>>>>>> several load balancers (for example using VRRP-like >>>>>>>>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is >>>>>>>>>>>>>>>>>>> invisible to the service chaining data plane >>>>> mechanisms. >>>>> It >>>>>>>>>>>>>>>>>>> is likely that it is visible to various control >>>>> mechanisms, >>>>>>>>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and >>>>> vm >>>>>>>>>>>>>>>>>>> instantiation. The architectural impact of permitting >>>>> this >>>>>>>>>>>>>>>>>>> is largely that we need to be careful that our >>>>> terminology >>>>>>>>>>>>>>>>>>> does not lead >>>>>>>>>>>>>>> readers to >>>>>>>>>>>>>>>>>>> think we are prohibiting it. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> 3) There can also be load balancing done by selecting >>>>>>>>>>>>>>>>>>> packet paths for the service chaining that direct >>>>> traffic >>>>>>>>>>>>>>>>>>> to different places. We would not want to require >>> that >>>>> a >>>>>>>>>>>>>>>>>>> given service function appear at only one place in the >>>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> It is of course the case that these may be combined. I >>>>> tend >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> refer to >>>>>>>>>>>>>>>>>>> the collection of entities that appear to service >>>>> chaining >>>>>>>>>>>>>>>>>>> as a single point as a cluster. Not because cluster is >>>>> a >>>>>>>>>>>>>>>>>>> good term. But because I do not have another one. >>> Thus, >>>>> the >>>>>>>>>>>>>>>>>>> point of type 3 load balancing >>>>>>>>>>>>>>> is to >>>>>>>>>>>>>>>>>>> direct different subsets of traffic to different >>>>> singular >>>>>>>>>>>>>>>>>>> or clustered service functions in different places in >>>>> the >>>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Now with that said, what do I mean when I talk about >>>>>>>>>>>>>>>>>>> service chain and service path/ Service chain is a >>>>> sequence >>>>>>>>>>>>>>>>>>> of logical functions to be applied to a subset of >>>>> packets. >>>>>>>>>>>>>>>>>>> It is equivalent of saying that some subset of traffic >>>>> is >>>>>>>>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall >>>>>>>>>>>>>>>>>>> while a different subset is to go directly to the cache >>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>>> visiting any other service functions. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> That is not enough information to direct the packets. >>> A >>>>>>>>>>>>>>>>>>> service path is, in some fashion, a sequence of >>>>> locations >>>>>>>>>>>>>>>>>>> in the network. Those locations will be singular or >>>>>>>>>>>>>>>>>>> clustered service function delivery locations. They >>>>> may be >>>>>>>>>>>>>>>>>>> addressed by IP address. They may be addressed as >>> ports >>>>> on >>>>>>>>>>>>>>>>>>> an SFF. There are many different ways that the >>>>> locations >>>>>>>>>>>>>>>>>>> may be known to the service chaining infrastructure >>> and >>>>> the >>>>>>>>>>>>>>>>>>> transport. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> =46rom the point of view of the work of the SFC group,= >>>>> we >>>>>>>>>>>>>>>>>>>> need to be >>>>>>>>>>>>>>>>>>> able to talk about the high level abstraction, the >>>>> service >>>>>>>>>>>>>>>>>>> chain, which drives the forwarding. And we need to >>> talk >>>>>>>>>>>>>>>>>>> about the actual data path packets will take in the >>>>>>>>>>>>>>>>>>> network. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Several of the comments have said "but the whole >>> path >>>>> may >>>>>>>>>>>>>>>>>>> not be known at the front." This architecture deals >>>>> with >>>>>>>>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on >>>>> load >>>>>>>>>>>>>>>>>>> balancers above, there can be decisions and behaviors >>>>> which >>>>>>>>>>>>>>>>>>> are invisible to the service chaining mechanisms (in >>>>> much >>>>>>>>>>>>>>>>>>> the same way that bridging within a LAN is largely >>>>>>>>>>>>>>>>>>> invisible to routing between LANs.) The other >>> provision >>>>> we >>>>>>>>>>>>>>>>>>> make is >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>> reclassification can be done in mid-chain when >>>>> necessary. >>>>>>>>>>>>>>>>>>> That will direct packets to a new chain. Based on >>>>>>>>>>>>>>>>>>> information available at the re-classification point. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I hope that this helps explain what we are after. If it >>>>>>>>>>>>>>>>>>> does, and if the intent is acceptable to the working >>>>> group, >>>>>>>>>>>>>>>>>>> we can figure out what additional words are needed >>> to >>>>>>>>>>>>>>>>>>> convey this. If the working group disagree with the >>>>> intent, >>>>>>>>>>>>>>>>>>> then we will of course adjust to match the working >>>>> group >>>>>>>>>>>>>>>>>>> agreements. If this is still unclear, I am not sure >>>>> what to >>>>>>>>>>>>>>>>>>> try next. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Yours, Joel >>> _______________________________________________ >>>>> sfc >>>>>>>>>> mailing >>>>>>>>>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ >>>>> sfc >>>>>>>>>> mailing >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>=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 >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 09:03: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 D7FA11B2B49 for ; Fri, 11 Jul 2014 09:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 kIAwkhYNxEML for ; Fri, 11 Jul 2014 09:03:00 -0700 (PDT) Received: from omr-m10.mx.aol.com (omr-m10.mx.aol.com [64.12.143.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060741B2B54 for ; Fri, 11 Jul 2014 09:03:00 -0700 (PDT) Received: from mtaout-mce01.mx.aol.com (mtaout-mce01.mx.aol.com [172.29.27.205]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id C7C1E702C6601; Fri, 11 Jul 2014 12:02:58 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mce01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1E23C3800009E; Fri, 11 Jul 2014 12:02:58 -0400 (EDT) Date: Fri, 11 Jul 2014 12:02:57 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com, jmh@joelhalpern.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3070_948379510.1405094577794" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405094578; bh=qnSrts5t+3SG58BOiWD2szrYLVpe3IAlckRqe4oVjjc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=vVFDii/ZuRLUMjalBehUihaGgBbYd1tFePDEbfupNqKmaWftL0mLCY0Rk+GDRySim oEuzTlB/clBRVbQ/UiWDcBcOQzBKHN3vWhmxe53X1fGPxOxoG4wIgUHzteHtUc3ZWX iYARuwHca0G/38i3zkXzCAZ8qjVx5Rtb1izb6e0U= x-aol-sid: 3039ac1d1bcd53c00ab24c26 X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yvAVY_NUh3pCn0whNM5G3d7tHSg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:03:08 -0000 ------=_Part_3070_948379510.1405094577794 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable heh. =C2=A0well, if it did not, then you should not do it like that. =C2=A0= e.g. I'm not going to configure real servers on a server load balancer that= are not reachable. =C2=A0e.g. I'm not going to configure my BGP to announc= e prefixes for which I cannot provide connectivity. =C2=A0If you do things = like that, then you are doing it wrong. From: jguichar@cisco.com To: NAPIERALA, MARIA H,Joel M. Halpern= ,Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Then I misunderstand the proposal ;-) .. However, it seems to me that if you allow an SFF to make a decision as to which remote SFF it will use for a given flow to reach the next SF within the chain then you better make sure that that remote SFF has the necessary forwarding logic to reach the next-next-SF for the chain as otherwise you are in deep trouble. On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" wrote: >Absolutely not. Service chains can be instantiated only in relevant SFFs >when they "arrive". > >> -----Original Message----- >>=20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard>>(jguicha= r)>> Sent: Friday, July 11, 2014 9:27 AM>> To: Joel M. Halpern; Ron Parker;= sfc@ietf.org>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancer= s>> >> Well I think it is even worse than that if I have understood the>>pr= oposal>> correctly as it would require full knowledge of every single SF wi= thin>>the>> entire SFC domain at every single SFF as there is no way to kno= w a>>priori>> which SFC=C2=B9s a given SFF will need to service at any give= n point in time.>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote:>> >> >Ron, thinking about this, I realized another major pr= oblem with the>>your>> >proposal as I understand it. (And I readily admit = I may not understand>> >it.)>> >>> >The proposal has each SFF serve as the = load balancer for the next>> >service function that follows it (not the one= it delivers to), in every>> >service chain that goes through it.>> >>> >Si= nce it has to be able to work with all services, that means that>>every>> >= SFF would have to be a full, flow sensitive and stateful load balancer.>> >= I ahve no problem if some SFF are flow sensitive, and / or stateful.>> >But= having the architecture require that every SFF be a full, flow>> >sensitiv= e, stateful, load balancer seems to me to be an acceptable>> >imposition.>>= >>> >Yours,>> >Joel>> >>> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>> = >> Part of my personal view is that I am trying to make this work>>sensibly= >> >> in a more orchestrated environment. I expect that the service>> >> f= unctions, and over time probably the SFF capabilities, will be>> >> orchest= rated and installed. I expect the service chains to be>>driven by>> >> BSS= tools that define offerings to clients, and enable self-selection>> >> fro= m these. I expect service paths to be heavily policy drive.>> >>>> >> I ca= n see how to make all of that work in an archtiecture driven by>> >> initia= l classification to described service paths. It is harder to>>see>> >> how= to make it work (but it can be done) when we allow more>> dynamicity>> >> = in the network behavior.>> >>>> >> Having said that, most of that perspecti= ve I described is outside of>>the>> >> scope of the working group. it is n= ot something we are tasked to>>agree>> >>on.>> >> So I do not claim that vi= sion means we have to do it a certain way.>>it>> >> is just the perspective= that drives my preferences.>> >>>> >> Yours,>> >> Joel>> >>>> >> On 7/10/1= 4, 9:58 PM, Ian Smith wrote:>> >>>> For me, the amount of information about= service instances that>>needs>> >>>>to>> >>>> be widely distributed and ma= intained, potentially even across data>> >>>> centers within an administrat= ive scope, is large enough and complex>> >>>> enough that trying to get tha= t into each SFF seems like a difficult>> >>>> architecture to realize.>> >>= >>> >>> I'm curious as to why that is more complicated than dynamic routing= ,>> >>> hyper-scale data center orchestration, or DNS, all of which are>>bi= gger>> >>> problems that have been profitably and stably implemented?>> >>>= >> >>> It also seems that if it really is more complicated, that is a good>= > >>> sign that it is too complicated.>> >>>>> >>> ________________________= ________________>> >>> From: Joel M. Halpern [jmh@joelhalpern.com]>> >>> Se= nt: Thursday, July 10, 2014 9:45 PM>> >>> To: Ron Parker; Joel Halpern Dire= ct; mikebianc@aol.com; Ian Smith;>> >>> sfc@ietf.org>> >>> Subject: Re: [sf= c] Service Chains, Paths, and Load Balancers>> >>>>> >>> This is an archite= ctural issue. And one that I would prefer we>> >>>actually>> >>> decide, r= ather than trying to allow all possible implementations.>> >>> Because it d= oes have a major effect on the control requirements and>> the>> >>> functio= nality of SFFs.>> >>>>> >>> For me, the amount of information about service= instances that needs>> to>> >>> be widely distributed and maintained, pote= ntially even across data>> >>> centers within an administrative scope, is l= arge enough and complex>> >>> enough that trying to get that into each SFF = seems like a difficult>> >>> architecture to realize.>> >>>>> >>> Yours,>> = >>> Joel>> >>>>> >>> But it is a fair question.>> >>>>> >>> On 7/10/14, 9:3= 8 PM, Ron Parker wrote:>> >>>> This is the crux of my issue. =C2=A0 Is the = end to end selection of>> >>>> (top-level) instances performed centrally (p= erhaps by the>>classifier)>> >>>> or hop-by-hop (perhaps by the classifier = and subsequently the>>SFFs)?>> >>>> Such selection is not equivalent to rec= lassification. =C2=A0 And surely,>> >>>> this is an architectural issue and= not relegated to>> >>>> "implementation".>> >>>>>> >>>> My own view is to = favor the distributed approach even though a>> >>>> greater amount of data = (chain definitions and perhaps local>>selection>> >>>> policy) is required = at those distributed decision points. =C2=A0 This>> >>>> approach does not = require an end-to-end path id at all. =C2=A0=C2=A0 My>> >>>> rationale for = favoring this approach is primarily driven by>>increased>> >>>> resiliency = over the global path id approach. =C2=A0 With a global path>>id>> >>>> appr= oach, consider failure of an instance and needing to alter the>> >>>> globa= l path ID table for each and every affected end-to-end path.>> >>>>>> >>>> = Ron>> >>>>>> >>>> ________________________________________ From: sfc>> >>>>= [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct>> >>>> [jmh.direct= @joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM>> >>>> To: mikebian= c@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:>> >>>> [sfc] Service C= hains, Paths, and Load Balancers>> >>>>>> >>>> The way the architecture mod= els the case of SF1 needing to>>influence>> >>>> the chain is that one woul= d do reclassification at the exit from>> >>>> SF1.>> >>>>>> >>>> Part of th= e goal is to keep the different functions logically>> >>>> separate so that= solutions can clearly describe how they choose to>> >>>> compose them for = "service" delivery.>> >>>>>> >>>> Yours, Joel>> >>>>>> >>>> On 7/10/14, 6:1= 0 PM, mikebianc@aol.com wrote:>> >>>>> I don't see anything in the arch dra= ft that suggests any sort of>> >>>>> limit. However, it does seem to indica= te that the entire path (all>> >>>>> SFIs) must be chosen at SFC instantiat= ion. I believe this means>> >>>>> either at the classifier or maybe the cl= assifier chooses a SF>>Chain>> >>>>> and the NF or at the latest the first = SFF. In any case, the>> >>>>> language does seem to prohibit a more dynami= c SFP where SFI(n) is>> >>>>> determined at the SFI(n-1) hop. According to= the draft, this>> >>>>> behavior would be considered "branching" to a new = SFP as opposed>> to>> >>>>> choosing and then forwarding to the selected in= stance of the>> >>>>> next-hop of the current SFC.>> >>>>>>> >>>>> draft-me= rged-sfc-architecture-00:>> >>>>>> When an SFC is instantiated into the net= work it is necessary to>> >>>>>> select the specific instances of SFs that = will be used, and to>> >>>>>> create the service topology for that SFC usin= g SF's network>> >>>>>> locator. Thus, instantiation of the SFC results in= the creation>> >>>>>> of a Service Function Path (SFP) and is used for for= warding>> >>>>>> packets through the SFC. In other words, an SFP is the>> >= >>>>> instantiation of the defined SFC.>> >>>>>>>> >>>>>> The SFC architect= ure supports reclassification (or non-initial>> >>>>>> classification) as w= ell. As packets traverse an SFP,>> >>>>>> reclassification may occur - typ= ically performed by a>> >>>>>> classification function co-resident with a s= ervice function.>> >>>>>> Reclassification may result in the selection of a= new SFP, an>> >>>>>> update of the associated metadata, or both. This is = referred to>> >>>>>> as "branching".>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>= >>>-------------------------------------------------------------------->>>>= >>>-->> >>>>>-->> >>>>>>> >>>>>>> >>>>>>> >>> *From: *I.Smith@F5.com>> >>>>> *To: *Joel Halpern Direct,Joe= l M.>> >>>>>>> >>>>>Halpern,huang@sce.carleton.ca> carleton.>> >>>>>ca>,sfc@ietf.org>> >>>>>>> >>>>>>> = >>>>>>> >>> *Sent: *Thursday, July 10, 2014>> >>>>> *Subject: *Re: [sfc] Se= rvice Chains, Paths, and Load Balancers>> >>>>>>> >>>>> Actually, I think I= am disagreeing.>> >>>>>>> >>>>> If the possibility of medium-scale deploym= ents (and that is what>> >>>>> 16 million flows is in my world) of service = chains is preconceived>> >>>>> as an absurd idea, then the architecture bur= dened with that>> >>>>> preconception.>> >>>>>>> >>>>> There has to be some= point of aim, some degree of aspiration to>> >>>>> scale that is appropria= te for the lifespan of the architecture ->> >>>>> you don't have to know wh= at it is, but by saying that an arbitrary>> >>>>> number is "too far", you'= re creating - even if it isn't>>intentional>> >>>>> - a limit that influenc= es decisions that have lasting impacts>> >>>>> regarding scale-out, failure= mitigation, elasticity, address>> >>>>> space... all kinds of things. That= is a problem I'm not>> >>>>> particularly eager to deal with.>> >>>>>>> >>= >>>>> >>>>>>> >>>>>>> >>>>> ________________________________________>> >>>>= >>> >>>>>>> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Se= nt:>> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;= >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service>> >= >>>> Chains, Paths, and Load Balancers>> >>>>>>> >>>>> Ian, I don't think y= ou disagree with me at all in this regard. I>>am>> >>>>> not requesting the= the architecture or the solution prohibit>> >>>>> deployments in the speci= fic fashion. I am objecting to Huang's>> >>>>> reading of my note as saying= that such deployments are required>> >>>>> they by the archtiecture.>> >>>= >>>> >>>>> As I have said repeatedly, I am not trying to prohibit such>> >>= >>> things. Whether they are a good idea or not depends upon many>> >>>>> f= actors outside of the scope of the WG. I happen to think that>>they>> >>>>>= are usually a bad idea.>> >>>>>>> >>>>> But the archtiecture si carefully = avoiding attempting to know what>> >>>>> is and is not eployable.>> >>>>>>>= >>>>> Yours, Joel>> >>>>>>> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>> = >>>>>> I disagree.>> >>>>>>>> >>>>>> We routinely have stateful devices tha= t manage tens of millions>> >>>>>> of>> >>>>> concurrent flows in both acce= ss network and data center>> >>>>> environments today. You can't seriously = believe that in the>> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorro= w you are only>> going>> >>>>> to have small numbers of service chains with= equally small numbers>> >>>>> of active service paths?>> >>>>>>>> >>>>>> Y= our sounds too much like "no one will ever need more than 64K">> >>>>>> for= >> >>>>> comfort.>> >>>>>>>> >>>>>>>> >>>>>> ______________________________= __________ From: sfc>> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. H= alpern>> >>>>> [jmh@joelhalpern.com]>> >>>>>> Sent: Thursday, July 10, 2014= 4:46 PM To: huang@sce.carleton.ca;>> >>>>>> sfc@ietf.org Subject: Re: [sfc= ] Service Chains, Paths, and Load>> >>>>>> Balancers>> >>>>>>>> >>>>>> No, = it will mean that if someone tries to deploy the archtieture>> >>>>>> parti= cularly badly, they will exceed the limits of their>> >>>>>> devices. The a= rchitecture does not require such absurd use of>> >>>>>> service paths. Sin= ce I can not figure out how to write>> >>>>>> architectural words to prohib= it it, the architecture does permit>> >>>>>> such abuse.>> >>>>>>>> >>>>>> = Please do not read my saying that the archtiecture permits>> >>>>>> somethi= ng as saying it is either deisred or required by the work.>> >>>>>> It isn'= t.>> >>>>>>>> >>>>>> Yours, Joel>> >>>>>>>> >>>>>> On 7/10/14, 4:36 PM, Cha= ngcheng Huang wrote:>> >>>>>>> If you need to support 100 service chains, i= t will mean>> >>>>>>> 16,000,000 paths. That is larger than the routing tab= le of a>> >>>>>>> core router.>> >>>>>>>>> >>>>>>> Chang>> >>>>>>>>> >>>>>>= > On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>> >>>>>>>> The architectur= e allows a range of deployments, from 1>> >>>>>>>> service path to 160000 s= ervice paths. I would hope that>> >>>>>>>> operators are prepared for the c= omplexities if they choose to>> >>>>>>>> avoid any use of local load balanc= ing and in stead provision>> >>>>>>>> 160,000 service paths.>> >>>>>>>>>> >= >>>>>>> Yours, Joel>> >>>>>>>>>> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, M= ARIA H wrote:>> >>>>>>>>> Paul,>> >>>>>>>>>>> >>>>>>>>> How many path ident= ifiers there will be for a 4 hop service>> >>>>>>>>> chain with 20 instance= s at each hop?>> >>>>>>>>>>> >>>>>>>>> Maria>> >>>>>>>>>>> >>>>>>>>> *From:= *sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of>> >>>>>>>>> *Paul Quinn (p= aulq) *Sent:* Thursday, July 10, 2014 3:03>> >>>>>>>>> PM *To:* Lucy yong *= Cc:* jmh@joelhalpern.com;>> >>>>>>>>> mohamed.boucadair@orange.com; sfc@iet= f.org;>> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains,>>= >>>>>>>>> Paths, and Load Balancers>> >>>>>>>>>>> >>>>>>>>> Lucy,>> >>>>>>= >>>>> >>>>>>>>> Overall I concur, as you say: a path ID drives the>> >>>>>>= >>> forwarding. I=C2=B9d>> >>>>> make>> >>>>>>>>> the minor change: the pat= h identifier can be used to derive>> >>>>>>>>> the needed forwarding and as= sociated transport.>> >>>>>>>>>>> >>>>>>>>> It is _not_ the transport, but = rather is used to simply>> >>>>>>>>> identify the service path (or graph) t= hat packets must>> >>>>>>>>> traverse. By having a path identifier, the exa= ct>> >>>>>>>>> indirection that people seem to be asking for on this>> >>>>= >>>>> thread can be simply be implemented. The path identifier>> >>>>>>>>> = provides nothing more than a lookup, that lookup can result>> >>>>>>>>> in = a one or more (equal or weighted) transport next>> >>>>>>>>> hop(s).>> >>>>= >>>>>>> >>>>>>>>> Paul>> >>>>>>>>>>> >>>>>>>>> On Jul 10, 2014, at 11:04 AM= , Lucy yong>> >>>>>>>>> = >>> >>>>>>>>> wrote:>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> Agree.= The arch. doc should not mandate only use of the>> >>>>>>>>> service path = identifier to drive the forwarding actions.>> >>>>>>>>>>> >>>>>>>>> Lucy>> = >>>>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf>> = >>>>>>>>> Of*mohamed.boucadair@orange.com>> >>>>>>>>> *Sent:*Thursday,>> July>> >>>>>>>>> 10, 2014 2:06 AM *To:*= mikebianc@aol.com>> >>>>>>>>> ;jmh@joelhalpern.co= m>> >>>>>>>>> ;sfc@ietf.org>> >>>>>>>>> *Subject:*Re: [sfc] Service Chains,>> >>>>>>>>> Paths, and L= oad Balancers>> >>>>>>>>>>> >>>>>>>>> Re-,>> >>>>>>>>>>> >>>>>>>>> The merg= ed draft calls out explicitly a service path>> >>>>>>>>> identifier. I obje= ct to use that identifier to derive>> >>>>>>>>> forwarding actions.>> >>>>>= >>>>>> >>>>>>>>> Requiring a SFC system to have the full knowledge of every= >> >>>>> available SFC>> >>>>>>>>> forwarding paths within an SFC-enabled d= omain is not>> >>>>> required/justified>> >>>>>>>>> nor possible in various= deployment contexts.>> >>>>>>>>>>> >>>>>>>>> SFC forwarding actions should= rely on the piece of>> >>>>>>>>> information>> >>>>> that will>> >>>>>>>>>= be present in all deployments: that is the one required to>> >>>>>>>>> str= ucture a service chain. How that information is used to>> >>>>>>>>> infer f= orwarding>> >>>>> actions>> >>>>>>>>> is a solution-oriented discussion.>> = >>>>>>>>>>> >>>>>>>>> Cheers,>> >>>>>>>>>>> >>>>>>>>> Med>> >>>>>>>>>>> >>>= >>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part>> >>>>> de*mikebi= anc@aol.com>> >>>>>>>>> *Envoy=C3=A9 :*mercredi = 9 juillet>> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com>> >>>>>>>>> = ;sfc@ietf.org>> >>>>>>>>> = *Objet :*Re: [sfc] Service Chains,>> >>>>>>>>> Paths, and Load Balancers>>= >>>>>>>>>>> >>>>>>>>> Is anyone still questioning the difference between S= F Chain>> >>>>>>>>> and SF>> >>>>> Path?>> >>>>>>>>> Other than clarifying = the definition so that it's clear to>> >>>>> those not>> >>>>>>>>> familiar= with the draft, it seems that everyone agrees on>> >>>>>>>>> these terms.>= > >>>>>>>>>>> >>>>>>>>> To me, the one point that is still unclear is wheth= er it is>> >>>>>>>>> the intent of this draft to ultimately specify what th= e ID>> >>>>>>>>> of the SFC Header>> >>>>> should>> >>>>>>>>> reference (th= e chain or the path), or if this draft simply>> >>>>>>>>> intends to leave = that ambiguous, allowing other drafts to>> >>>>>>>>> dictate the mechanisms= for forwarding based on chain or>> >>>>>>>>> path and the choice of chain = or>> >>>>> path to>> >>>>>>>>> be negotiated in the control-plane.>> >>>>>>= >>>>> >>>>>>>>> If the latter (ambiguous), then the draft would have>> >>>>= >>>>> require that both SFP and SFC be supported (or make one>> >>>>>>>>> r= equired and the other optional) to avoid some vendors only>> >>>>>>>>> supp= orting SFP and others only supporting SFC.>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>= > >>>>>>>------------------------------------------------------------------= -->>>>>>>-->> >>>>>-->> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> *From:*= jmh@joelhalpern.com> >>>>>>>>> >>> >>>>>>>>> *To:*sfc@ietf.org> >= >>>>>>>> > *Sent:*Tuesday, July>> >>>>>= >>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load>> >>>>>>>>> Ba= lancers>> >>>>>>>>>>> >>>>>>>>> I have been trying to figure out how to cle= arly answer a>> >>>>>>>>> number of comments that have been made about the = proposed>> >>>>>>>>> merged archtiecture draft. Assuming we can get working= >> >>>>>>>>> group agreement on the intent, we will work to improve the>> >= >>>>>>>> wording so that readers who have not participated in the WG>> >>>>= >>>>> discussion will understnd it the way the>> >>>>> working>> >>>>>>>>> = group intends.>> >>>>>>>>>>> >>>>>>>>> But what do we intend? I will try to= explain my personal>> >>>>>>>>> view, and see if that helps.>> >>>>>>>>>>>= >>>>>>>>> In this regard, it is important to keep in mind that what>> >>>>= >>>>> we are defining is the data plane architecture. We are not>> >>>>>>>>= > attempting to define the architecture for the entire>> >>>>>>>>> solution= for service chaining. That would encompass>> >>>>>>>>> OSS/BSS, various co= ntrol and policy functions, virtual>> >>>>>>>>> machine and image managemen= t, and many other aspects.>> >>>>>>>>>>> >>>>>>>>> As a result there are ma= ny things which clearly need to>> >>>>>>>>> exist in the larger system, but= which are dealt with above>> >>>>>>>>> where we are>> >>>>> functioning,>>= >>>>>>>>> and are not directly required by the work we are doing.>> >>>>>>= >>>>> >>>>>>>>> In order to get to service chain vs service path, as I>> >>= >>>>>>> understand>> >>>>> them,>> >>>>>>>>> I need to first discuss load b= alancing. There are at least>> >>>>>>>>> three different ways that load bal= ancing can and will>> >>>>>>>>> interact with service chaining. There proba= bly are more.>> >>>>>>>>> The point of the archtiecture is to permit all of= these,>> >>>>>>>>> but not to mandate that any particular kind>> >>>>> be = used>> >>>>>>>>> in any solution.>> >>>>>>>>>>> >>>>>>>>> 1) Load balancing= as a service provided to the end user.>> >>>>>>>>> This is a service funct= ion. It receives user packets, and>> >>>>>>>>> modifies them (or>> >>>>> ma= rks>> >>>>>>>>> them, or ...) so as to choose an end user service instance>= > >>>>>>>>> to receive the users packet. This is an important service>> >>>= >>>>>> function to be able to include in service chaining. It's>> >>>>>>>>>= behavior may affect requirements on how service chaining is>> >>>>>>>>> do= ne. But it has very little impact on the archtiecture.>> >>>>>>>>> From an= architectural pe3rspective it is simply a>> >>>>> service>> >>>>>>>>> func= tion which may modify the underlying packet.>> >>>>>>>>>>> >>>>>>>>> 2) The= re is internal load balancing. That is, one can have>> >>>>>>>>> what>> >>>= >> appears>> >>>>>>>>> to the service chaining architecture as a single poi= nt of>> >>>>>>>>> contact>> >>>>> for a>> >>>>>>>>> specific service functi= on, but is actually delivered by a>> >>>>> collection of>> >>>>>>>>> virtua= l or physical machines, possibly including one or>> >>>>>>>>> several load = balancers (for example using VRRP-like>> >>>>>>>>> techniques to share a MA= C address.) mostly, this is>> >>>>>>>>> invisible to the service chaining d= ata plane mechanisms. It>> >>>>>>>>> is likely that it is visible to variou= s control mechanisms,>> >>>>>>>>> such as those responsible for scale-in, s= cale-out, and vm>> >>>>>>>>> instantiation. The architectural impact of per= mitting this>> >>>>>>>>> is largely that we need to be careful that our ter= minology>> >>>>>>>>> does not lead>> >>>>> readers to>> >>>>>>>>> think we = are prohibiting it.>> >>>>>>>>>>> >>>>>>>>> 3) There can also be load balan= cing done by selecting>> >>>>>>>>> packet paths for the service chaining th= at direct traffic>> >>>>>>>>> to different places. We would not want to req= uire that a>> >>>>>>>>> given service function appear at only one place in = the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> It is of course the case t= hat these may be combined. I tend>> >>>>>>>>> to>> >>>>> refer to>> >>>>>>>= >> the collection of entities that appear to service chaining>> >>>>>>>>> a= s a single point as a cluster. Not because cluster is a>> >>>>>>>>> good te= rm. But because I do not have another one. Thus, the>> >>>>>>>>> point of t= ype 3 load balancing>> >>>>> is to>> >>>>>>>>> direct different subsets of = traffic to different singular>> >>>>>>>>> or clustered service functions in= different places in the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> Now w= ith that said, what do I mean when I talk about>> >>>>>>>>> service chain a= nd service path/ Service chain is a sequence>> >>>>>>>>> of logical functio= ns to be applied to a subset of packets.>> >>>>>>>>> It is equivalent of sa= ying that some subset of traffic is>> >>>>>>>>> to get DPI, charging, conte= nt inspection, and firewall>> >>>>>>>>> while a different subset is to go d= irectly to the cache>> >>>>> without>> >>>>>>>>> visiting any other service= functions.>> >>>>>>>>>>> >>>>>>>>> That is not enough information to direc= t the packets. A>> >>>>>>>>> service path is, in some fashion, a sequence o= f locations>> >>>>>>>>> in the network. Those locations will be singular or= >> >>>>>>>>> clustered service function delivery locations. They may be>> >= >>>>>>>> addressed by IP address. They may be addressed as ports on>> >>>>>= >>>> an SFF. There are many different ways that the locations>> >>>>>>>>> m= ay be known to the service chaining infrastructure and the>> >>>>>>>>> tran= sport.>> >>>>>>>>>>> >>>>>>>>>> From the point of view of the work of the = SFC group, we>> >>>>>>>>>> need to be>> >>>>>>>>> able to talk about the hi= gh level abstraction, the service>> >>>>>>>>> chain, which drives the forwa= rding. And we need to talk>> >>>>>>>>> about the actual data path packets w= ill take in the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> Several of the= comments have said "but the whole path may>> >>>>>>>>> not be known at the= front." This architecture deals with>> >>>>>>>>> that issue in two ways. F= irst, as noted in item (2) on load>> >>>>>>>>> balancers above, there can b= e decisions and behaviors which>> >>>>>>>>> are invisible to the service ch= aining mechanisms (in much>> >>>>>>>>> the same way that bridging within a = LAN is largely>> >>>>>>>>> invisible to routing between LANs.) The other pr= ovision we>> >>>>>>>>> make is>> >>>>> that>> >>>>>>>>> reclassification ca= n be done in mid-chain when necessary.>> >>>>>>>>> That will direct packets= to a new chain. Based on>> >>>>>>>>> information available at the re-class= ification point.>> >>>>>>>>>>> >>>>>>>>> I hope that this helps explain wha= t we are after. If it>> >>>>>>>>> does, and if the intent is acceptable to = the working group,>> >>>>>>>>> we can figure out what additional words are = needed to>> >>>>>>>>> convey this. If the working group disagree with the i= ntent,>> >>>>>>>>> then we will of course adjust to match the working group= >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to>> = >>>>>>>>> try next.>> >>>>>>>>>>> >>>>>>>>> Yours, Joel>> >>>>>>>>>>> >>>>>= >>>> _______________________________________________ sfc>> mailing>> >>>>>>= >>> list sfc@ietf.org >> >>>>>>>>> https://www.ietf.or= g/mailman/listinfo/sfc>> >>>>>>>>>>> >>>>>>>>> ____________________________= ___________________ sfc>> mailing>> >>>>>>>>> list sfc@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>> >>>>>>>>= >>> >>>>>>>>>> >>>>>>>> _______________________________________________ sfc= >> mailing>> >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listin= fo/sfc>> >>>>>>>>>> >>>>>>>>> >>>>>>> _____________________________________= __________ sfc>> mailing>> >>>>>>> list sfc@ietf.org https://www.ietf.org/m= ailman/listinfo/sfc>> >>>>>>>>> >>>>>>>> >>>>>> ___________________________= ____________________ sfc mailing>> list>> >>>>>> sfc@ietf.org https://www.i= etf.org/mailman/listinfo/sfc>> >>>>>>>> >>>>>>> >>>>> _____________________= __________________________ sfc mailing>> list>> >>>>> sfc@ietf.org https://= www.ietf.org/mailman/listinfo/sfc>> >>>>>> >>>> ___________________________= ____________________ sfc mailing>> list>> >>>> sfc@ietf.org https://www.iet= f.org/mailman/listinfo/sfc>> >>>>>> >>>> __________________________________= _____________ sfc mailing>> list>> >>>> sfc@ietf.org https://www.ietf.org/m= ailman/listinfo/sfc>> >>>>>> >>>>> >>>> >> ________________________________= _______________>> >> sfc mailing list>> >> sfc@ietf.org>> >> https://www.ie= tf.org/mailman/listinfo/sfc>> >>>> >>> >___________________________________= ____________>> >sfc mailing list>> >sfc@ietf.org>> >https://www.ietf.org/ma= ilman/listinfo/sfc>> >> _______________________________________________>> s= fc mailing list>> sfc@ietf.org>> https://www.ietf.org/mailman/listinfo/sfc_= ______________________________________________sfc mailing listsfc@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/sfc ------=_Part_3070_948379510.1405094577794 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
heh.  well, if= it did not, then you should not do it like that.  e.g. I'm not going = to configure real servers on a server load balancer that are not reachable.=  e.g. I'm not going to configure my BGP to announce prefixes for whic= h I cannot provide connectivity.  If you do things like that, then you= are doing it wrong.




=
From: jguichar@cisco.com<jguic= har@cisco.com>
To: NAPIERALA, MARIA H<mn1921@att.com>,Jo= el M. Halpern<jmh@joelhalpern.com>,Ron Parker<Ron_Parker@affirmedn= etworks.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Friday, Ju= ly 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Ba= lancers

Then I misunderstand the proposal ;-) .. Howe= ver, it seems to me that if
you allow an SFF to make a decision as to wh= ich remote SFF it will use for
a given flow to reach the next SF within = the chain then you better make
sure that that remote SFF has the necessa= ry forwarding logic to reach the
next-next-SF for the chain as otherwise= you are in deep trouble.

On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" = <mn1921@att.com> wrote:

= >Absolutely not. Service chains can be instantiated only in relevant SFF= s
>when they "arrive".
>
>> -----Original Message-----=
>>

From: sfc [mailto:sfc-bounces@ietf.org] On = Behalf Of Jim Guichard
>>(jguichar)
>&= gt; Sent: Friday, July 11, 2014 9:27 AM
>> To: Joel M. = Halpern; Ron Parker; sfc@ietf.org
>> Subject: Re: [sfc]= Service Chains, Paths, and Load Balancers
>>
>> Well I think it is even worse than that if I have understood= the
>>proposal
>> correctly as it = would require full knowledge of every single SF within
>&g= t;the
>> entire SFC domain at every single SFF as there= is no way to know a
>>priori
>> wh= ich SFC=C2=B9s a given SFF will need to service at any given point in time.=
>>
>> On 7/10/14, 11:53 PM, "Joel= M. Halpern" <jmh@joelhalpern.com> wrote:
>>
>> >Ron, thinking about this, I realized another major = problem with the
>>your
>> >prop= osal as I understand it. (And I readily admit I may not understand
>> >it.)
>> >
>>= >The proposal has each SFF serve as the load balancer for the next
>> >service function that follows it (not the one it del= ivers to), in every
>> >service chain that goes thro= ugh it.
>> >
>> >Since it has= to be able to work with all services, that means that
>&g= t;every
>> >SFF would have to be a full, flow sensit= ive and stateful load balancer.
>> >I ahve no proble= m if some SFF are flow sensitive, and / or stateful.
>>= >But having the architecture require that every SFF be a full, flow
>> >sensitive, stateful, load balancer seems to me to b= e an acceptable
>> >imposition.
>&g= t; >
>> >Yours,
>> >Joel>> >
>> >On 7/10/14, 10:06 PM,= Joel M. Halpern wrote:
>> >> Part of my personal= view is that I am trying to make this work
>>sensibly<= br class=3D"">>> >> in a more orchestrated environment. I expe= ct that the service
>> >> functions, and over tim= e probably the SFF capabilities, will be
>> >> or= chestrated and installed. I expect the service chains to be
= >>driven by
>> >> BSS tools that define off= erings to clients, and enable self-selection
>> >>= ; from these. I expect service paths to be heavily policy drive.
>> >>
>> >> I can see how to ma= ke all of that work in an archtiecture driven by
>> >= ;> initial classification to described service paths. It is harder to>>see
>> >> how to make it wor= k (but it can be done) when we allow more
>> dynamicity=
>> >> in the network behavior.
>= ;> >>
>> >> Having said that, most of th= at perspective I described is outside of
>>the
>> >> scope of the working group. it is not something we= are tasked to
>>agree
>> >>o= n.
>> >> So I do not claim that vision means we h= ave to do it a certain way.
>>it
>>= >> is just the perspective that drives my preferences.
>> >>
>> >> Yours,
>= ;> >> Joel
>> >>
>> = >> On 7/10/14, 9:58 PM, Ian Smith wrote:
>> >&= gt;>> For me, the amount of information about service instances that<= br class=3D"">>>needs
>> >>>>to
>> >>>> be widely distributed and maintained, po= tentially even across data
>> >>>> centers = within an administrative scope, is large enough and complex
&= gt;> >>>> enough that trying to get that into each SFF seems= like a difficult
>> >>>> architecture to r= ealize.
>> >>>
>> >>= > I'm curious as to why that is more complicated than dynamic routing,>> >>> hyper-scale data center orchestration, o= r DNS, all of which are
>>bigger
>>= >>> problems that have been profitably and stably implemented?>> >>>
>> >>> It al= so seems that if it really is more complicated, that is a good
>> >>> sign that it is too complicated.
>= > >>>
>> >>> _____________________= ___________________
>> >>> From: Joel M. Halpe= rn [jmh@joelhalpern.com]
>> >>> Sent: Thursday= , July 10, 2014 9:45 PM
>> >>> To: Ron Parker;= Joel Halpern Direct; mikebianc@aol.com; Ian Smith;
>> = >>> sfc@ietf.org
>> >>> Subject: Re: = [sfc] Service Chains, Paths, and Load Balancers
>> >= >>
>> >>> This is an architectural issue= . And one that I would prefer we
>> >>>actual= ly
>> >>> decide, rather than trying to allow = all possible implementations.
>> >>> Because i= t does have a major effect on the control requirements and
&g= t;> the
>> >>> functionality of SFFs.
>> >>>
>> >>> For me, = the amount of information about service instances that needs
= >> to
>> >>> be widely distributed and m= aintained, potentially even across data
>> >>>= centers within an administrative scope, is large enough and complex
>> >>> enough that trying to get that into each SFF = seems like a difficult
>> >>> architecture to = realize.
>> >>>
>> >>= ;> Yours,
>> >>> Joel
>>= ; >>>
>> >>> But it is a fair questio= n.
>> >>>
>> >>> = On 7/10/14, 9:38 PM, Ron Parker wrote:
>> >>>&= gt; This is the crux of my issue.   Is the end to end selection of
>> >>>> (top-level) instances performed centra= lly (perhaps by the
>>classifier)
>>= ; >>>> or hop-by-hop (perhaps by the classifier and subsequentl= y the
>>SFFs)?
>> >>>> = Such selection is not equivalent to reclassification.   And surely,>> >>>> this is an architectural issue and no= t relegated to
>> >>>> "implementation".>> >>>>
>> >>>&g= t; My own view is to favor the distributed approach even though a
>> >>>> greater amount of data (chain definitions a= nd perhaps local
>>selection
>> >= ;>>> policy) is required at those distributed decision points. &nb= sp; This
>> >>>> approach does not require = an end-to-end path id at all.    My
>> >&g= t;>> rationale for favoring this approach is primarily driven by
>>increased
>> >>>> resilie= ncy over the global path id approach.   With a global path
>>id
>> >>>> approach, consider fa= ilure of an instance and needing to alter the
>> >&g= t;>> global path ID table for each and every affected end-to-end path= .
>> >>>>
>> >>&g= t;> Ron
>> >>>>
>> &= gt;>>> ________________________________________ From: sfc
>> >>>> [sfc-bounces@ietf.org] on behalf of Joel Ha= lpern Direct
>> >>>> [jmh.direct@joelhalper= n.com] Sent: Thursday, July 10, 2014 6:15 PM
>> >>= ;>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:<= br class=3D"">>> >>>> [sfc] Service Chains, Paths, and Lo= ad Balancers
>> >>>>
>>= >>>> The way the architecture models the case of SF1 needing t= o
>>influence
>> >>>> t= he chain is that one would do reclassification at the exit from
>> >>>> SF1.
>> >>>>>> >>>> Part of the goal is to keep the diff= erent functions logically
>> >>>> separate = so that solutions can clearly describe how they choose to
>= ;> >>>> compose them for "service" delivery.
&= gt;> >>>>
>> >>>> Yours, Joe= l
>> >>>>
>> >>&g= t;> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote:
>>= >>>>> I don't see anything in the arch draft that suggests = any sort of
>> >>>>> limit. However, it = does seem to indicate that the entire path (all
>> >= >>>> SFIs) must be chosen at SFC instantiation. I believe this= means
>> >>>>> either at the classifier= or maybe the classifier chooses a SF
>>Chain
>> >>>>> and the NF or at the latest the first S= FF. In any case, the
>> >>>>> language = does seem to prohibit a more dynamic SFP where SFI(n) is
>= > >>>>> determined at the SFI(n-1) hop. According to the= draft, this
>> >>>>> behavior would be = considered "branching" to a new SFP as opposed
>> to>> >>>>> choosing and then forwarding to t= he selected instance of the
>> >>>>> nex= t-hop of the current SFC.
>> >>>>>
>> >>>>> draft-merged-sfc-architecture-00:>> >>>>>> When an SFC is instantiated i= nto the network it is necessary to
>> >>>>&= gt;> select the specific instances of SFs that will be used, and to
>> >>>>>> create the service topology for= that SFC using SF's network
>> >>>>>>= ; locator. Thus, instantiation of the SFC results in the creation
>> >>>>>> of a Service Function Path (SFP) an= d is used for forwarding
>> >>>>>> pa= ckets through the SFC. In other words, an SFP is the
>>= >>>>>> instantiation of the defined SFC.
&= gt;> >>>>>>
>> >>>>>= ;> The SFC architecture supports reclassification (or non-initial
>> >>>>>> classification) as well. As pack= ets traverse an SFP,
>> >>>>>> reclas= sification may occur - typically performed by a
>> >= >>>>> classification function co-resident with a service fun= ction.
>> >>>>>> Reclassification may= result in the selection of a new SFP, an
>> >>&g= t;>>> update of the associated metadata, or both. This is referre= d to
>> >>>>>> as "branching".
>> >>>>>
>> >>>&g= t;>
>> >>>>>
>> &= gt;>>>>
>>
>>>>&= gt;>>----------------------------------------------------------------= ----
>>>>>>>--
>> &g= t;>>>>--
>> >>>>>
>> >>>>>
>> >>>>= >
>> >>> *From: *I.Smith@F5.com<I.Smith@= F5.com>
>> >>>>> *To: *Joel Halpern D= irect<jmh.direct@joelhalpern.com>,Joel M.
>> >= >>>>
>> >>>>>Halpern<jmh@= joelhalpern.com>,huang@sce.carleton.ca<huang@sce.
>&= gt; carleton.
>> >>>>>ca>,sfc@ietf.or= g<sfc@ietf.org>
>> >>>>>
>> >>>>>
>> >>>>= >
>> >>> *Sent: *Thursday, July 10, 2014>> >>>>> *Subject: *Re: [sfc] Service Chai= ns, Paths, and Load Balancers
>> >>>>>>> >>>>> Actually, I think I am disagreei= ng.
>> >>>>>
>> >= >>>> If the possibility of medium-scale deployments (and that i= s what
>> >>>>> 16 million flows is in m= y world) of service chains is preconceived
>> >>&= gt;>> as an absurd idea, then the architecture burdened with that
>> >>>>> preconception.
>&= gt; >>>>>
>> >>>>> There = has to be some point of aim, some degree of aspiration to
>= ;> >>>>> scale that is appropriate for the lifespan of th= e architecture -
>> >>>>> you don't have= to know what it is, but by saying that an arbitrary
>>= >>>>> number is "too far", you're creating - even if it isn= 't
>>intentional
>> >>>>= ;> - a limit that influences decisions that have lasting impacts
>> >>>>> regarding scale-out, failure mitigatio= n, elasticity, address
>> >>>>> space...= all kinds of things. That is a problem I'm not
>> >= >>>> particularly eager to deal with.
>> &g= t;>>>>
>> >>>>>
>> >>>>>
>> >>>>>=
>> >>>>> ______________________________= __________
>> >>>>>
>&g= t; >>>>>
>> >>>>> From: J= oel Halpern Direct [jmh.direct@joelhalpern.com] Sent:
>>= ; >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel = M. Halpern;
>> >>>>> huang@sce.carleton.= ca; sfc@ietf.org Subject: Re: [sfc] Service
>> >>= >>> Chains, Paths, and Load Balancers
>> >&= gt;>>>
>> >>>>> Ian, I don't th= ink you disagree with me at all in this regard. I
>>am<= br class=3D"">>> >>>>> not requesting the the architec= ture or the solution prohibit
>> >>>>> d= eployments in the specific fashion. I am objecting to Huang's
>> >>>>> reading of my note as saying that such deplo= yments are required
>> >>>>> they by the= archtiecture.
>> >>>>>
&g= t;> >>>>> As I have said repeatedly, I am not trying to p= rohibit such
>> >>>>> things. Whether th= ey are a good idea or not depends upon many
>> >>= >>> factors outside of the scope of the WG. I happen to think that=
>>they
>> >>>>> are= usually a bad idea.
>> >>>>>
>> >>>>> But the archtiecture si carefully avoid= ing attempting to know what
>> >>>>> is = and is not eployable.
>> >>>>>
>> >>>>> Yours, Joel
>> >= >>>>
>> >>>>> On 7/10/14, 5:= 01 PM, Ian Smith wrote:
>> >>>>>> I d= isagree.
>> >>>>>>
>= > >>>>>> We routinely have stateful devices that manag= e tens of millions
>> >>>>>> of
>> >>>>> concurrent flows in both access netw= ork and data center
>> >>>>> environment= s today. You can't seriously believe that in the
>> >= ;>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are = only
>> going
>> >>>>&g= t; to have small numbers of service chains with equally small numbers
>> >>>>> of active service paths?
>> >>>>>>
>> >>>>= ;>> Your sounds too much like "no one will ever need more than 64K">> >>>>>> for
>> &= gt;>>>> comfort.
>> >>>>>>= ;
>> >>>>>>
>> &g= t;>>>>> ________________________________________ From: sfc>> >>>>>> [sfc-bounces@ietf.org] on be= half of Joel M. Halpern
>> >>>>> [jmh@jo= elhalpern.com]
>> >>>>>> Sent: Thursd= ay, July 10, 2014 4:46 PM To: huang@sce.carleton.ca;
>>= >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, P= aths, and Load
>> >>>>>> Balancers>> >>>>>>
>> >&g= t;>>>> No, it will mean that if someone tries to deploy the arc= htieture
>> >>>>>> particularly badly= , they will exceed the limits of their
>> >>>&= gt;>> devices. The architecture does not require such absurd use of>> >>>>>> service paths. Since I can n= ot figure out how to write
>> >>>>>> = architectural words to prohibit it, the architecture does permit
>> >>>>>> such abuse.
>> = >>>>>>
>> >>>>>> Pl= ease do not read my saying that the archtiecture permits
>= > >>>>>> something as saying it is either deisred or r= equired by the work.
>> >>>>>> It isn= 't.
>> >>>>>>
>> = >>>>>> Yours, Joel
>> >>>>= ;>>
>> >>>>>> On 7/10/14, 4:36 = PM, Changcheng Huang wrote:
>> >>>>>>= > If you need to support 100 service chains, it will mean
= >> >>>>>>> 16,000,000 paths. That is larger than= the routing table of a
>> >>>>>>>= core router.
>> >>>>>>>
>> >>>>>>> Chang
>> &g= t;>>>>>>
>> >>>>>>&= gt; On 07/10/2014 01:15 PM, Joel M. Halpern wrote:
>> &= gt;>>>>>>> The architecture allows a range of deployme= nts, from 1
>> >>>>>>>> service= path to 160000 service paths. I would hope that
>> >= ;>>>>>>> operators are prepared for the complexities i= f they choose to
>> >>>>>>>> av= oid any use of local load balancing and in stead provision
&g= t;> >>>>>>>> 160,000 service paths.
>> >>>>>>>>
>> >>= >>>>>> Yours, Joel
>> >>>>= ;>>>>
>> >>>>>>>> O= n 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
>> >&g= t;>>>>>>> Paul,
>> >>>>= ;>>>>>
>> >>>>>>>&g= t;> How many path identifiers there will be for a 4 hop service
>> >>>>>>>>> chain with 20 instances= at each hop?
>> >>>>>>>>>>> >>>>>>>>> Maria
>> >>>>>>>>>
>> = >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.or= g] *On Behalf Of
>> >>>>>>>>>= ; *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03
&g= t;> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@jo= elhalpern.com;
>> >>>>>>>>> = mohamed.boucadair@orange.com; sfc@ietf.org;
>> >>= >>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service= Chains,
>> >>>>>>>>> Paths,= and Load Balancers
>> >>>>>>>>= >
>> >>>>>>>>> Lucy,
>> >>>>>>>>>
>&= gt; >>>>>>>>> Overall I concur, as you say: a pa= th ID drives the
>> >>>>>>>>>= ; forwarding. I=C2=B9d
>> >>>>> make
>> >>>>>>>>> the minor change: = the path identifier can be used to derive
>> >>&g= t;>>>>>> the needed forwarding and associated transport.<= br class=3D"">>> >>>>>>>>>
&= gt;> >>>>>>>>> It is _not_ the transport, but= rather is used to simply
>> >>>>>>&g= t;>> identify the service path (or graph) that packets must
>> >>>>>>>>> traverse. By having a p= ath identifier, the exact
>> >>>>>>&g= t;>> indirection that people seem to be asking for on this
>> >>>>>>>>> thread can be simply be= implemented. The path identifier
>> >>>>&g= t;>>>> provides nothing more than a lookup, that lookup can res= ult
>> >>>>>>>>> in a one or= more (equal or weighted) transport next
>> >>>= ;>>>>>> hop(s).
>> >>>>&g= t;>>>>
>> >>>>>>>>&= gt; Paul
>> >>>>>>>>>
>> >>>>>>>>> On Jul 10, 2014, at 1= 1:04 AM, Lucy yong
>> >>>>>>>>&= gt; <lucy.yong@huawei.com <mailto:lucy.yong@huawei.com>>
>> >>>>>>>>> wrote:
= >> >>>>>>>>>
>> >&g= t;>>>>>>>
>> >>>>>&= gt;>>>
>> >>>>>>>>>= Agree. The arch. doc should not mandate only use of the
>= > >>>>>>>>> service path identifier to drive = the forwarding actions.
>> >>>>>>>= >>
>> >>>>>>>>> Lucy>> >>>>>>>>>
&g= t;> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@= ietf.org]*On Behalf
>> >>>>>>>>= > Of*mohamed.boucadair@orange.com
>> >>>>= ;>>>>> <mailto:mohamed.boucadair@orange.com> *Sent:*Th= ursday,
>> July
>> >>>>= >>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com
= >> >>>>>>>>> <mailto:mikebianc@aol.com&= gt;;jmh@joelhalpern.com
>> >>>>>>>= >> <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>= > >>>>>>>>> <mailto:sfc@ietf.org> *Subj= ect:*Re: [sfc] Service Chains,
>> >>>>>&= gt;>>> Paths, and Load Balancers
>> >>&g= t;>>>>>>
>> >>>>>>&= gt;>> Re-,
>> >>>>>>>>>= ;
>> >>>>>>>>> The merged dr= aft calls out explicitly a service path
>> >>>= >>>>>> identifier. I object to use that identifier to der= ive
>> >>>>>>>>> forwarding = actions.
>> >>>>>>>>>
>> >>>>>>>>> Requiring a SFC syste= m to have the full knowledge of every
>> >>>&g= t;> available SFC
>> >>>>>>>>= ;> forwarding paths within an SFC-enabled domain is not
&g= t;> >>>>> required/justified
>> >&= gt;>>>>>>> nor possible in various deployment contexts= .
>> >>>>>>>>>
>> >>>>>>>>> SFC forwarding actions shoul= d rely on the piece of
>> >>>>>>>&= gt;> information
>> >>>>> that will>> >>>>>>>>> be present in al= l deployments: that is the one required to
>> >>&= gt;>>>>>> structure a service chain. How that information= is used to
>> >>>>>>>>> inf= er forwarding
>> >>>>> actions
>> >>>>>>>>> is a solution-oriented = discussion.
>> >>>>>>>>>
>> >>>>>>>>> Cheers,
>> >>>>>>>>>
>> = >>>>>>>>> Med
>> >>>= ;>>>>>>
>> >>>>>>&g= t;>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part
>> >>>>> de*mikebianc@aol.com
>> = >>>>>>>>> <mailto:mikebianc@aol.com> *Envo= y=C3=A9 :*mercredi 9 juillet
>> >>>>>>= ;>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com
>&g= t; >>>>>>>>> <mailto:jmh@joelhalpern.com>;= sfc@ietf.org
>> >>>>>>>>> &l= t;mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service Chains,
= >> >>>>>>>>> Paths, and Load Balancers
>> >>>>>>>>>
>= > >>>>>>>>> Is anyone still questioning the d= ifference between SF Chain
>> >>>>>>&= gt;>> and SF
>> >>>>> Path?
>> >>>>>>>>> Other than clarifying= the definition so that it's clear to
>> >>>&g= t;> those not
>> >>>>>>>>>= ; familiar with the draft, it seems that everyone agrees on
&= gt;> >>>>>>>>> these terms.
>= ;> >>>>>>>>>
>> >>&= gt;>>>>>> To me, the one point that is still unclear is w= hether it is
>> >>>>>>>>> th= e intent of this draft to ultimately specify what the ID
>= > >>>>>>>>> of the SFC Header
&= gt;> >>>>> should
>> >>>>= >>>>> reference (the chain or the path), or if this draft si= mply
>> >>>>>>>>> intends to= leave that ambiguous, allowing other drafts to
>> >= >>>>>>>> dictate the mechanisms for forwarding base= d on chain or
>> >>>>>>>>> p= ath and the choice of chain or
>> >>>>> = path to
>> >>>>>>>>> be nego= tiated in the control-plane.
>> >>>>>>= ;>>>
>> >>>>>>>>> I= f the latter (ambiguous), then the draft would have
>> = >>>>>>>>> require that both SFP and SFC be suppo= rted (or make one
>> >>>>>>>>&g= t; required and the other optional) to avoid some vendors only
>> >>>>>>>>> supporting SFP and others o= nly supporting SFC.
>> >>>>>>>>= >
>> >>>>>>>>>
>> >>>>>
>>
&= gt;>>>>>>------------------------------------------------= --------------------
>>>>>>>--
>> >>>>>--
>> >>>&g= t;>
>> >>>>>
>> &= gt;>>>>
>> >>>>>>>
>> >>>>>>>>> *From:*jmh@joelhal= pern.com<jmh@joelhalpern.com
>> >>>>>= >>>> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>&g= t;
>> >>>>>>>>> *To:*sfc@iet= f.org<sfc@ietf.org
>> >>>>>>>&g= t;> <mailto:sfc@ietf.org%3csfc@ietf.org>> *Sent:*Tuesday, July<= br class=3D"">>> >>>>>>>>> 8, 2014 *Subjec= t:*[sfc] Service Chains, Paths, and Load
>> >>>= ;>>>>>> Balancers
>> >>>>= >>>>>
>> >>>>>>>>= ;> I have been trying to figure out how to clearly answer a
>> >>>>>>>>> number of comments that hav= e been made about the proposed
>> >>>>>&= gt;>>> merged archtiecture draft. Assuming we can get working
>> >>>>>>>>> group agreement on = the intent, we will work to improve the
>> >>>= >>>>>> wording so that readers who have not participated = in the WG
>> >>>>>>>>> discu= ssion will understnd it the way the
>> >>>>= > working
>> >>>>>>>>> gr= oup intends.
>> >>>>>>>>>>> >>>>>>>>> But what do we in= tend? I will try to explain my personal
>> >>>= >>>>>> view, and see if that helps.
>>= ; >>>>>>>>>
>> >>>&= gt;>>>>> In this regard, it is important to keep in mind tha= t what
>> >>>>>>>>> we are d= efining is the data plane architecture. We are not
>> &= gt;>>>>>>>> attempting to define the architecture f= or the entire
>> >>>>>>>>> s= olution for service chaining. That would encompass
>> &= gt;>>>>>>>> OSS/BSS, various control and policy fun= ctions, virtual
>> >>>>>>>>>= machine and image management, and many other aspects.
>&g= t; >>>>>>>>>
>> >>>= >>>>>> As a result there are many things which clearly ne= ed to
>> >>>>>>>>> exist in = the larger system, but which are dealt with above
>> &g= t;>>>>>>>> where we are
>> >= >>>> functioning,
>> >>>>>&g= t;>>> and are not directly required by the work we are doing.
>> >>>>>>>>>
>&= gt; >>>>>>>>> In order to get to service chain v= s service path, as I
>> >>>>>>>>= ;> understand
>> >>>>> them,
>> >>>>>>>>> I need to first discuss= load balancing. There are at least
>> >>>>= >>>>> three different ways that load balancing can and will<= br class=3D"">>> >>>>>>>>> interact with s= ervice chaining. There probably are more.
>> >>&g= t;>>>>>> The point of the archtiecture is to permit all o= f these,
>> >>>>>>>>> but no= t to mandate that any particular kind
>> >>>&g= t;> be used
>> >>>>>>>>> = in any solution.
>> >>>>>>>>>= ;
>> >>>>>>>>> 1) Load balan= cing as a service provided to the end user.
>> >>= >>>>>>> This is a service function. It receives user p= ackets, and
>> >>>>>>>>> mod= ifies them (or
>> >>>>> marks
>> >>>>>>>>> them, or ...) so as to = choose an end user service instance
>> >>>>= >>>>> to receive the users packet. This is an important serv= ice
>> >>>>>>>>> function to= be able to include in service chaining. It's
>> >&g= t;>>>>>>> behavior may affect requirements on how serv= ice chaining is
>> >>>>>>>>>= done. But it has very little impact on the archtiecture.
>= ;> >>>>>>>>> From an architectural pe3rspect= ive it is simply a
>> >>>>> service
>> >>>>>>>>> function which may = modify the underlying packet.
>> >>>>>&g= t;>>>
>> >>>>>>>>> = 2) There is internal load balancing. That is, one can have
&g= t;> >>>>>>>>> what
>> >= ;>>>> appears
>> >>>>>>&g= t;>> to the service chaining architecture as a single point of
>> >>>>>>>>> contact
>> >>>>> for a
>> >>>>= ;>>>>> specific service function, but is actually delivered = by a
>> >>>>> collection of
>> >>>>>>>>> virtual or physical machine= s, possibly including one or
>> >>>>>>= ;>>> several load balancers (for example using VRRP-like
>> >>>>>>>>> techniques to share a M= AC address.) mostly, this is
>> >>>>>>= ;>>> invisible to the service chaining data plane mechanisms. It>> >>>>>>>>> is likely that i= t is visible to various control mechanisms,
>> >>= >>>>>>> such as those responsible for scale-in, scale-= out, and vm
>> >>>>>>>>> ins= tantiation. The architectural impact of permitting this
>&= gt; >>>>>>>>> is largely that we need to be care= ful that our terminology
>> >>>>>>>= ;>> does not lead
>> >>>>> readers= to
>> >>>>>>>>> think we ar= e prohibiting it.
>> >>>>>>>>&g= t;
>> >>>>>>>>> 3) There can= also be load balancing done by selecting
>> >>&g= t;>>>>>> packet paths for the service chaining that direc= t traffic
>> >>>>>>>>> to di= fferent places. We would not want to require that a
>> = >>>>>>>>> given service function appear at only = one place in the
>> >>>>>>>>>= ; network.
>> >>>>>>>>>
>> >>>>>>>>> It is of course the= case that these may be combined. I tend
>> >>>= ;>>>>>> to
>> >>>>> re= fer to
>> >>>>>>>>> the coll= ection of entities that appear to service chaining
>> &= gt;>>>>>>>> as a single point as a cluster. Not bec= ause cluster is a
>> >>>>>>>>&g= t; good term. But because I do not have another one. Thus, the
>> >>>>>>>>> point of type 3 load balanc= ing
>> >>>>> is to
>>= ; >>>>>>>>> direct different subsets of traffic = to different singular
>> >>>>>>>&g= t;> or clustered service functions in different places in the
>> >>>>>>>>> network.
= >> >>>>>>>>>
>> >&g= t;>>>>>>> Now with that said, what do I mean when I ta= lk about
>> >>>>>>>>> servic= e chain and service path/ Service chain is a sequence
>>= ; >>>>>>>>> of logical functions to be applied t= o a subset of packets.
>> >>>>>>>&= gt;> It is equivalent of saying that some subset of traffic is
>> >>>>>>>>> to get DPI, charging, c= ontent inspection, and firewall
>> >>>>>= >>>> while a different subset is to go directly to the cache>> >>>>> without
>> &g= t;>>>>>>>> visiting any other service functions.>> >>>>>>>>>
>= ;> >>>>>>>>> That is not enough information t= o direct the packets. A
>> >>>>>>>= >> service path is, in some fashion, a sequence of locations
>> >>>>>>>>> in the network. Those l= ocations will be singular or
>> >>>>>>= ;>>> clustered service function delivery locations. They may be>> >>>>>>>>> addressed by IP a= ddress. They may be addressed as ports on
>> >>&g= t;>>>>>> an SFF. There are many different ways that the l= ocations
>> >>>>>>>>> may be= known to the service chaining infrastructure and the
>>= ; >>>>>>>>> transport.
>> &g= t;>>>>>>>>
>> >>>>&= gt;>>>>> From the point of view of the work of the SFC grou= p, we
>> >>>>>>>>>> need = to be
>> >>>>>>>>> able to t= alk about the high level abstraction, the service
>> &g= t;>>>>>>>> chain, which drives the forwarding. And = we need to talk
>> >>>>>>>>>= about the actual data path packets will take in the
>>= >>>>>>>>> network.
>> >&= gt;>>>>>>>
>> >>>>>= >>>> Several of the comments have said "but the whole path may<= br class=3D"">>> >>>>>>>>> not be known at= the front." This architecture deals with
>> >>&g= t;>>>>>> that issue in two ways. First, as noted in item = (2) on load
>> >>>>>>>>> bal= ancers above, there can be decisions and behaviors which
>= > >>>>>>>>> are invisible to the service chai= ning mechanisms (in much
>> >>>>>>>= ;>> the same way that bridging within a LAN is largely
= >> >>>>>>>>> invisible to routing between = LANs.) The other provision we
>> >>>>>&g= t;>>> make is
>> >>>>> that
>> >>>>>>>>> reclassification c= an be done in mid-chain when necessary.
>> >>>= >>>>>> That will direct packets to a new chain. Based on<= br class=3D"">>> >>>>>>>>> information ava= ilable at the re-classification point.
>> >>>&= gt;>>>>>
>> >>>>>>>= >> I hope that this helps explain what we are after. If it
>> >>>>>>>>> does, and if the intent= is acceptable to the working group,
>> >>>>= ;>>>>> we can figure out what additional words are needed to=
>> >>>>>>>>> convey this. I= f the working group disagree with the intent,
>> >&g= t;>>>>>>> then we will of course adjust to match the w= orking group
>> >>>>>>>>> ag= reements. If this is still unclear, I am not sure what to
>= ;> >>>>>>>>> try next.
>>= >>>>>>>>>
>> >>>&g= t;>>>>> Yours, Joel
>> >>>>&= gt;>>>>
>> >>>>>>>>= > _______________________________________________ sfc
>= > mailing
>> >>>>>>>>> li= st sfc@ietf.org <mailto:sfc@ietf.org>
>> >>= >>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>>>>>>
>&= gt; >>>>>>>>> __________________________________= _____________ sfc
>> mailing
>> >= ;>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org= >
>> >>>>>>>>> https://ww= w.ietf.org/mailman/listinfo/sfc
>> >>>>>= >>>>
>> >>>>>>>>>> >>>>>>>> _____________________= __________________________ sfc
>> mailing
>> >>>>>>>> list sfc@ietf.org https://www.ie= tf.org/mailman/listinfo/sfc
>> >>>>>>= >>
>> >>>>>>>
= >> >>>>>>> _____________________________________= __________ sfc
>> mailing
>> >&g= t;>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listi= nfo/sfc
>> >>>>>>>
&= gt;> >>>>>>
>> >>>>>= ;> _______________________________________________ sfc mailing
>> list
>> >>>>>> sfc@iet= f.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.org https:= //www.ietf.org/mailman/listinfo/sfc
>> >>>>=
>> >>>> __________________________________= _____________ sfc mailing
>> list
>>= ; >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc>> >>>>
>> >>><= br class=3D"">>> >>
>> >> ___________= ____________________________________
>> >> sfc ma= iling list
>> >> sfc@ietf.org
>&= gt; >> https://www.ietf.org/mailman/listinfo/sfc
>&g= t; >>
>> >
>> >________= _______________________________________
>> >sfc mail= ing list
>> >sfc@ietf.org
>> >= ;https://www.ietf.org/mailman/listinfo/sfc
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc m= ailing list
sfc@ietf.org
https://www.ietf.org/m= ailman/listinfo/sfc
------=_Part_3070_948379510.1405094577794-- From nobody Fri Jul 11 09:08: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 192641B2B96 for ; Fri, 11 Jul 2014 09:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsVv_pvKdZrI for ; Fri, 11 Jul 2014 09:08:20 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEF81A0AB5 for ; Fri, 11 Jul 2014 09:08:19 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 3fb00c35.2b994feb2940.4682632.00-2462.12983156.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:08:19 +0000 (UTC) X-MXL-Hash: 53c00bf362c704ed-d5eb80deb3581ff8d7e0e5798f16e6372c2216db Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 9aa00c35.0.4678305.00-2245.12970919.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:02:51 +0000 (UTC) X-MXL-Hash: 53c00aab0b950881-aa7332b538e149daa1bc526204583bbff7db8d7b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BG2lY4025176; Fri, 11 Jul 2014 12:02:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BG2V8d024823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:02:42 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:02:17 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:02:17 -0400 From: "NAPIERALA, MARIA H" To: Joel Halpern Direct , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "Ron Parker" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEWlgP//vtHAAAjq1gAAB1zggP//1J0AgAA5FLA= Date: Fri, 11 Jul 2014 16:02:16 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AE5A@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD3B@MISOUT7MSGUSRCF.ITServices.sbc.co m> <53BFFF12.4060700@joelhalpern.com> In-Reply-To: <53BFFF12.4060700@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=4fQN7dVo2eYYr_-R5hAA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EZYsXlikVq1c6olcnLXwFdT7IG0 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:08:24 -0000 Joel, I saw your latest e-mail but I am responding to this one because it is more= comprehensive. I have a hard time understanding why an SFF will not have ability to resolv= e an SFC to the set of next SFFs. Then what kind of "forwarder" is it if it= cannot deal with next-hops. Second, if we do it as you suggest, what is the definition of a service pat= h and why it is even needed? For me a service path is more of an abstract c= oncept that is meant to denote one actual path (among many) that a service = chain traffic will take. Maria > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct > Sent: Friday, July 11, 2014 11:13 AM > To: NAPIERALA, MARIA H; Joel M. Halpern; Jim Guichard (jguichar); Ron > Parker; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > In order to allow for SFFs which do not have ability to resolve an SFC > to the set of next SFFs, we need to do one level of mapping from the > abstract SFC to the more resolved SFP. > In addition to allowing for a range of SFF deployments, this also allows > for a degree of centralized traffic control to be used in conjunction > with the distributed behavior you are requesting. If we only used an > identifier of the service chain in the packet we would be prohibiting > that important alternative deployment. >=20 > The SFF still has the ability to map the SFP to the transport > information, which allows it to have a collection of next SFFs which it > uses for redundancy or load balancing. >=20 > If we structure it this way, we can allow the SFF to have a collection > of next-SFFs for a given SFP. And we can allow it to pick one, or to > balance as it chooses subject to the constraint that a given flow must > continue to use a given next-SFF as long as that is available. >=20 > If we write it that way, the architecture will not mandate full load > balancing. It will allow that a given SFF uses a single next-SFF hope. > Or that it does whatever degree of load balncing it chooses among the > set of next-SFF it is aware of for use with a given service path (SFP). > Whether that knowledge of next-SFFs is static or dynamic, provisioned > or discovered, is outside the scope of the architecture, and probably > outside the scope of any solution this WG develops. >=20 > Can you live with this compromise? > (If so, and if the WG is comfortable with this, Carlos and I can add > this to the slides for presentation in Toronto, and then add text to the > next version of the document.) >=20 > Yours, > Joel >=20 > On 7/11/14, 10:56 AM, NAPIERALA, MARIA H wrote: > > > >> Just to check, I am going to get pedantic. > > > > NP > > > >> We have SFF-X, is supporting (possibly via local load balancing) some > >> collection of local service function instances. > >> When packets on a given service function path (SFP-Y) arrive, they are > >> processed by theose service functions, and SFF-X then has to forward t= he > >> packets (with suitable transport) to a next SFF, who may locally balan= ce > >> among his service function instances. > > > > Similar comment to Med's (I will use his expression as it does reflect = it > correctly): "if packets bound to a given Service Function Chain arrive", = etc. > > This applies to the text below also. > > > >> For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z= . > >> > >> We consider first the state at time T0 when a packet arrives as SFF-X = on > >> SFP-Y with no prior special state in SFF-X (obviously, there is some > >> state about SFP-Y, as we do not want policy lookups at packet handling > >> times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2= . > >> If I understand your request, you want SFF-X to pick one of those t= wo > >> SFF, say SFF-Z1. > > > > Yes. > > > >> And send all the packets for SFP-Y on to SFF-Z1. Even > > > > This could be per-destination load balancing, for example, to get a bet= ter > load distribution. > > > >> if SFF-Z3 is added to the network, all packets for all flows using SFP= -Y > >> at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only > > > > Existing flows go to SFF-Z1. New flows may go to SFF-Z3. > > > >> time SFF-X would change that is if discovered or was told that SFF-Z1 > >> was down or unreachable. In that case, it would pick a new one from > >> among the known choices. > > > > Yes. > > > >> Maria, if that is what you would like, I believe that either is > >> currently allowed by the architecture or can easily be added. And I a= m > >> happy to do so. I believe we can describe that in the resilience and > >> failure recovery section that we need to add. > > > > OK. > > > >> But I want to be really sure that is what you want. I don't think tha= t > >> meets Ron's request. > >> > >> Yours, > >> Joel > >> > >> On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: > >>> Joel, > >>> > >>>> Hmm. Would it meet your goals Maria if all packets that arrived at > >>>> SFF-X with SFP-Y were (after local SF processing) forwarded to some > >>>> specific SFF-Z? Where SFF-Z was selected when the first packet with > >>>> SFP-Y arrived at SFF-X? > >>> > >>> Yes. > >>>> > >>>> While that is more easily met, that does not seem likely to produce > the > >>>> scale flexibility you asked for. And if SFF-X may forward packets w= ith > >>> > >>> Why not? > >>> > >>>> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have th= e > >>>> capability to ensure that a given flow continues to go to the same > next > >>>> SFF even when SFF-Z3 is added to the mix. > >>> > >>> Precisely. > >>> > >>> > >>>> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: > >>>>> Absolutely not. Service chains can be instantiated only in relevant > SFFs > >>>> when they "arrive". > >>>>> > >>>> ... > >>> >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 09:09: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 8965E1B2B6D for ; Fri, 11 Jul 2014 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.951 X-Spam-Level: X-Spam-Status: No, score=-6.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 3yh5j14PuFX7 for ; Fri, 11 Jul 2014 09:09:21 -0700 (PDT) Received: from mxebd05-public.idz.gs.com (mxe5.gs.com [199.99.47.101]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497791A0385 for ; Fri, 11 Jul 2014 09:09:19 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,644,1400040000"; d="scan'208,217"; a="71300005" Received: from unknown (HELO mxpcd01-public.ny.fw.gs.com) ([148.86.97.78]) by mxebd05.idz.gs.com with ESMTP; 11 Jul 2014 12:09:18 -0400 From: "Zarny, Myo" X-sendergroup: RELAYLIST Received: from gshcbdp11ex.firmwide.corp.gs.com ([10.135.172.20]) by cd01-mxp-vip-prod.ny.fw.gs.com with ESMTP; 11 Jul 2014 12:09:18 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp11ex.firmwide.corp.gs.com ([10.135.172.20]) with mapi; Fri, 11 Jul 2014 12:09:18 -0400 To: "'mikebianc@aol.com'" , "'jguichar@cisco.com'" , "'mn1921@att.com'" , "'jmh@joelhalpern.com'" , "'Ron_Parker@affirmednetworks.com'" , "'sfc@ietf.org'" Date: Fri, 11 Jul 2014 12:09:16 -0400 Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: Ac+dIaUHN7VfWUWjReasIBX0DMFd4AAADZ+w Message-ID: References: <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4EDCGSCMAMP19EXfi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MzYxJks0igfB72KS5dDEG11132s Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:09:31 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4EDCGSCMAMP19EXfi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHVuZGVyc3RhbmQuIChJ4oCZbSBzdXJlIEnigJltIG1pc3VuZGVyc3RhbmRpbmfi gKYpDQoNCllvdXIgYmFja2VuZCBzZXJ2ZXJzIGNvdWxkIGdvIGRvd24sIGJlIHVucmVhY2hhYmxl IG9yIGJlIHVuYWJsZSB0byBzZXJ2ZXIgbW9yZS4NCg0KUm91dGUgaGVhbHRoIGluamVjdGlvbiAo UkhJKSBpcyBhIHBlcmZlY3RseSBmaW5lLCBhY2NlcHRlZCwgd2F5IG9mIGluZGljYXRpbmcgdGhl IGhlYWx0aCBvZiB0aGUgYmFja2VuZCBzZXJ2aWNlcyB0byB0aGUgbmV0d29yay4gWW914oCZcmUg bm90IHNheWluZyB0aGF04oCZcyB3cm9uZywgYXJlIHlvdT8NCg0KDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wuY29tDQpT ZW50OiAxMSBKdWx5IDIwMTQgMTI6MDMgUE0NClRvOiBqZ3VpY2hhckBjaXNjby5jb207IG1uMTky MUBhdHQuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpoZWguICB3ZWxsLCBpZiBpdCBkaWQgbm90LCB0 aGVuIHlvdSBzaG91bGQgbm90IGRvIGl0IGxpa2UgdGhhdC4gIGUuZy4gSSdtIG5vdCBnb2luZyB0 byBjb25maWd1cmUgcmVhbCBzZXJ2ZXJzIG9uIGEgc2VydmVyIGxvYWQgYmFsYW5jZXIgdGhhdCBh cmUgbm90IHJlYWNoYWJsZS4gIGUuZy4gSSdtIG5vdCBnb2luZyB0byBjb25maWd1cmUgbXkgQkdQ IHRvIGFubm91bmNlIHByZWZpeGVzIGZvciB3aGljaCBJIGNhbm5vdCBwcm92aWRlIGNvbm5lY3Rp dml0eS4gIElmIHlvdSBkbyB0aGluZ3MgbGlrZSB0aGF0LCB0aGVuIHlvdSBhcmUgZG9pbmcgaXQg d3JvbmcuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogamd1 aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tJTNjamd1aWNoYXJAY2lzY28uY29tPj4NClRvOiBOQVBJRVJBTEEsIE1BUklBIEg8bW4xOTIx QGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sSm9lbCBNLiBIYWxwZXJuPGptaEBqb2Vs aGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixSb24gUGFya2VyPFJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3 b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KVGhlbiBJIG1pc3VuZGVyc3Rh bmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0IGlmDQp5 b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZG IGl0IHdpbGwgdXNlIGZvcg0KYSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhp biB0aGUgY2hhaW4gdGhlbiB5b3UgYmV0dGVyIG1ha2UNCnN1cmUgdGhhdCB0aGF0IHJlbW90ZSBT RkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYyB0byByZWFjaCB0aGUNCm5leHQt bmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJs ZS4NCg0KT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBh dHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KDQo+QWJzb2x1dGVseSBub3Qu IFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbiByZWxldmFudCBTRkZz DQo+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSmltIEd1aWNoYXJkDQo+PihqZ3VpY2hhcikNCj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwg MjAxNCA5OjI3IEFNDQo+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IFdlbGwgSSB0aGluayBp dCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZCB0aGUNCj4+cHJv cG9zYWwNCj4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9m IGV2ZXJ5IHNpbmdsZSBTRiB3aXRoaW4NCj4+dGhlDQo+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBl dmVyeSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0byBrbm93IGENCj4+cHJpb3JpDQo+ PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdp dmVuIHBvaW50IGluIHRpbWUuDQo+Pg0KPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0u IEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pj4gd3JvdGU6DQo+Pg0KPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBh bm90aGVyIG1ham9yIHByb2JsZW0gd2l0aCB0aGUNCj4+eW91cg0KPj4gPnByb3Bvc2FsIGFzIEkg dW5kZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90IHVuZGVyc3RhbmQN Cj4+ID5pdC4pDQo+PiA+DQo+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0 aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlIG5leHQNCj4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQg Zm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnMgdG8pLCBpbiBldmVyeQ0KPj4gPnNl cnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+DQo+PiA+U2luY2UgaXQgaGFz IHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucyB0aGF0DQo+ PmV2ZXJ5DQo+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBh bmQgc3RhdGVmdWwgbG9hZCBiYWxhbmNlci4NCj4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21l IFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yIHN0YXRlZnVsLg0KPj4gPkJ1dCBoYXZp bmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwgZmxv dw0KPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8g YmUgYW4gYWNjZXB0YWJsZQ0KPj4gPmltcG9zaXRpb24uDQo+PiA+DQo+PiA+WW91cnMsDQo+PiA+ Sm9lbA0KPj4gPg0KPj4gPk9uIDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3Jv dGU6DQo+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0 byBtYWtlIHRoaXMgd29yaw0KPj5zZW5zaWJseQ0KPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3RyYXRl ZCBlbnZpcm9ubWVudC4gSSBleHBlY3QgdGhhdCB0aGUgc2VydmljZQ0KPj4gPj4gZnVuY3Rpb25z LCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLCB3aWxsIGJlDQo+ PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZpY2UgY2hh aW5zIHRvIGJlDQo+PmRyaXZlbiBieQ0KPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVy aW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlIHNlbGYtc2VsZWN0aW9uDQo+PiA+PiBmcm9tIHRo ZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkgcG9saWN5IGRyaXZlLg0K Pj4gPj4NCj4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFu IGFyY2h0aWVjdHVyZSBkcml2ZW4gYnkNCj4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8g ZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzIGhhcmRlciB0bw0KPj5zZWUNCj4+ID4+IGhv dyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3Jl DQo+PiBkeW5hbWljaXR5DQo+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4+ID4+DQo+ PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmli ZWQgaXMgb3V0c2lkZSBvZg0KPj50aGUNCj4+ID4+IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3Vw LiBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZSB0YXNrZWQgdG8NCj4+YWdyZWUNCj4+ID4+b24u DQo+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRv IGl0IGEgY2VydGFpbiB3YXkuDQo+Pml0DQo+PiA+PiBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0 aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+ID4+DQo+PiA+PiBZb3VycywNCj4+ID4+IEpv ZWwNCj4+ID4+DQo+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ PiA+Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGlu c3RhbmNlcyB0aGF0DQo+Pm5lZWRzDQo+PiA+Pj4+dG8NCj4+ID4+Pj4gYmUgd2lkZWx5IGRpc3Ry aWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBkYXRhDQo+PiA+ Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91 Z2ggYW5kIGNvbXBsZXgNCj4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGlu dG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhIGRpZmZpY3VsdA0KPj4gPj4+PiBhcmNoaXRlY3R1cmUg dG8gcmVhbGl6ZS4NCj4+ID4+Pg0KPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlz IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBkeW5hbWljIHJvdXRpbmcsDQo+PiA+Pj4gaHlwZXItc2Nh bGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Ygd2hpY2ggYXJlDQo+ PmJpZ2dlcg0KPj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0 YWJseSBpbXBsZW1lbnRlZD8NCj4+ID4+Pg0KPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBp dCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdCBpcyBhIGdvb2QNCj4+ID4+PiBzaWdu IHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0KPj4gPj4+DQo+PiA+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4+IEZyb206IEpvZWwgTS4gSGFscGVy biBbam1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwg MjAxNCA5OjQ1IFBNDQo+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7 IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IElhbiBTbWl0aDsN Cj4+ID4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+PiBTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ ID4+Pg0KPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0 IEkgd291bGQgcHJlZmVyIHdlDQo+PiA+Pj5hY3R1YWxseQ0KPj4gPj4+IGRlY2lkZSwgcmF0aGVy IHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbnMuDQo+PiA+ Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wgcmVx dWlyZW1lbnRzIGFuZA0KPj4gdGhlDQo+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPj4g Pj4+DQo+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZp Y2UgaW5zdGFuY2VzIHRoYXQgbmVlZHMNCj4+IHRvDQo+PiA+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1 dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBkYXRhDQo+PiA+Pj4g Y2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBh bmQgY29tcGxleA0KPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVh Y2ggU0ZGIHNlZW1zIGxpa2UgYSBkaWZmaWN1bHQNCj4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS4NCj4+ID4+Pg0KPj4gPj4+IFlvdXJzLA0KPj4gPj4+IEpvZWwNCj4+ID4+Pg0KPj4gPj4+ IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+PiA+Pj4NCj4+ID4+PiBPbiA3LzEwLzE0LCA5 OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15 IGlzc3VlLiAgIElzIHRoZSBlbmQgdG8gZW5kIHNlbGVjdGlvbiBvZg0KPj4gPj4+PiAodG9wLWxl dmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4+Y2xh c3NpZmllcikNCj4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmll ciBhbmQgc3Vic2VxdWVudGx5IHRoZQ0KPj5TRkZzKT8NCj4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24g aXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4gICBBbmQgc3VyZWx5LA0KPj4g Pj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8N Cj4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ID4+Pj4NCj4+ID4+Pj4gTXkgb3duIHZpZXcg aXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4gdGhvdWdoIGENCj4+ID4+ Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMg bG9jYWwNCj4+c2VsZWN0aW9uDQo+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2Ug ZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLiAgIFRoaXMNCj4+ID4+Pj4gYXBwcm9hY2ggZG9l cyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLiAgICBNeQ0KPj4gPj4+ PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZl biBieQ0KPj5pbmNyZWFzZWQNCj4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0 aCBpZCBhcHByb2FjaC4gICBXaXRoIGEgZ2xvYmFsIHBhdGgNCj4+aWQNCj4+ID4+Pj4gYXBwcm9h Y2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcgdG8gYWx0ZXIg dGhlDQo+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZl Y3RlZCBlbmQtdG8tZW5kIHBhdGguDQo+PiA+Pj4+DQo+PiA+Pj4+IFJvbg0KPj4gPj4+Pg0KPj4g Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0K Pj4gPj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4g RGlyZWN0DQo+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQgNjoxNSBQTQ0KPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb208 bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgSS5TbWl0aEBGNS5jb208bWFpbHRvOkkuU21pdGhA RjUuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0K Pj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K Pj4gPj4+Pg0KPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNl IG9mIFNGMSBuZWVkaW5nIHRvDQo+PmluZmx1ZW5jZQ0KPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhh dCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUgZXhpdCBmcm9tDQo+PiA+Pj4+ IFNGMS4NCj4+ID4+Pj4NCj4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBk aWZmZXJlbnQgZnVuY3Rpb25zIGxvZ2ljYWxseQ0KPj4gPj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNv bHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cgdGhleSBjaG9vc2UgdG8NCj4+ID4+Pj4g Y29tcG9zZSB0aGVtIGZvciAic2VydmljZSIgZGVsaXZlcnkuDQo+PiA+Pj4+DQo+PiA+Pj4+IFlv dXJzLCBKb2VsDQo+PiA+Pj4+DQo+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAgUE0sIG1pa2ViaWFu Y0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gd3JvdGU6DQo+PiA+Pj4+PiBJIGRv bid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueSBzb3J0 IG9mDQo+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRo YXQgdGhlIGVudGlyZSBwYXRoIChhbGwNCj4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0 IFNGQyBpbnN0YW50aWF0aW9uLiBJIGJlbGlldmUgdGhpcyBtZWFucw0KPj4gPj4+Pj4gZWl0aGVy IGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyIGNob29zZXMgYSBTRg0K Pj5DaGFpbg0KPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBT RkYuIEluIGFueSBjYXNlLCB0aGUNCj4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9o aWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUgU0ZJKG4pIGlzDQo+PiA+Pj4+PiBkZXRlcm1p bmVkIGF0IHRoZSBTRkkobi0xKSBob3AuIEFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoaXMNCj4+ ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcg U0ZQIGFzIG9wcG9zZWQNCj4+IHRvDQo+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJk aW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZiB0aGUNCj4+ID4+Pj4+IG5leHQtaG9wIG9m IHRoZSBjdXJyZW50IFNGQy4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFy Y2hpdGVjdHVyZS0wMDoNCj4+ID4+Pj4+PiBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50 byB0aGUgbmV0d29yayBpdCBpcyBuZWNlc3NhcnkgdG8NCj4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNw ZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0bw0KPj4gPj4+ Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0YncyBu ZXR3b3JrDQo+PiA+Pj4+Pj4gbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZD IHJlc3VsdHMgaW4gdGhlIGNyZWF0aW9uDQo+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9u IFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yIGZvcndhcmRpbmcNCj4+ID4+Pj4+PiBwYWNrZXRz IHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+ID4+Pj4+ PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+ IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yIG5vbi1p bml0aWFsDQo+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJh dmVyc2UgYW4gU0ZQLA0KPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlw aWNhbGx5IHBlcmZvcm1lZCBieSBhDQo+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rpb24g Y28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UgZnVuY3Rpb24uDQo+PiA+Pj4+Pj4gUmVjbGFzc2lm aWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcgU0ZQLCBhbg0KPj4g Pj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3IgYm90aC4gVGhpcyBp cyByZWZlcnJlZCB0bw0KPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4+Pj4NCj4+ID4+ Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+DQo+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4t LQ0KPj4gPj4+Pj4tLQ0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+ICpGcm9t OiAqSS5TbWl0aEBGNS5jb208SS5TbWl0aEBGNS5jb208bWFpbHRvOipJLlNtaXRoQEY1LmNvbSUz Y0kuU21pdGhARjUuY29tPj4NCj4+ID4+Pj4+ICpUbzogKkpvZWwgSGFscGVybiBEaXJlY3Q8am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29t Pj4sSm9lbCBNLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+SGFscGVybjxqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5n QHNjZS4NCjxtYWlsdG86aHVhbmdAc2NlLiUwYj4+PiBjYXJsZXRvbi4NCj4+ID4+Pj4+Y2E+LHNm Y0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiA+Pj4+Pg0K Pj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAx NA0KPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJ IGFtIGRpc2FncmVlaW5nLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBv ZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZCB0aGF0IGlzIHdoYXQNCj4+ID4+Pj4+IDE2 IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzIHByZWNv bmNlaXZlZA0KPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVy ZSBidXJkZW5lZCB3aXRoIHRoYXQNCj4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+PiA+Pj4+Pg0K Pj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBv ZiBhc3BpcmF0aW9uIHRvDQo+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0 aGUgbGlmZXNwYW4gb2YgdGhlIGFyY2hpdGVjdHVyZSAtDQo+PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2 ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbiBhcmJpdHJhcnkNCj4+ ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQg aXNuJ3QNCj4+aW50ZW50aW9uYWwNCj4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMg ZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nIGltcGFjdHMNCj4+ID4+Pj4+IHJlZ2FyZGluZyBz Y2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwgYWRkcmVzcw0KPj4gPj4+ Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5v dA0KPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+Pj4+DQo+ PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IEZyb206 IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXSBTZW50Og0K Pj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBK b2VsIE0uIEhhbHBlcm47DQo+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1 YW5nQHNjZS5jYXJsZXRvbi5jYT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBT dWJqZWN0OiBSZTogW3NmY10gU2VydmljZQ0KPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBk aXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzIHJlZ2FyZC4gSQ0KPj5hbQ0KPj4gPj4+Pj4g bm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uIHByb2hp Yml0DQo+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBv YmplY3RpbmcgdG8gSHVhbmcncw0KPj4gPj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWlu ZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlIHJlcXVpcmVkDQo+PiA+Pj4+PiB0aGV5IGJ5IHRo ZSBhcmNodGllY3R1cmUuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0 ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0IHN1Y2gNCj4+ID4+Pj4+IHRoaW5ncy4g V2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uIG1hbnkNCj4+ ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0 byB0aGluayB0aGF0DQo+PnRoZXkNCj4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+ PiA+Pj4+Pg0KPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lk aW5nIGF0dGVtcHRpbmcgdG8ga25vdyB3aGF0DQo+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95 YWJsZS4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4+Pj4NCj4+ID4+Pj4+ IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ID4+Pj4+PiBJIGRpc2Fn cmVlLg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2 aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mIG1pbGxpb25zDQo+PiA+Pj4+Pj4gb2YNCj4+ID4+Pj4+ IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXIN Cj4+ID4+Pj4+IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZl IHRoYXQgaW4gdGhlDQo+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29y bGQgb2YgdG9tb3Jyb3cgeW91IGFyZSBvbmx5DQo+PiBnb2luZw0KPj4gPj4+Pj4gdG8gaGF2ZSBz bWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseSBzbWFsbCBudW1iZXJz DQo+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+ IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlIHRo YW4gNjRLIg0KPj4gPj4+Pj4+IGZvcg0KPj4gPj4+Pj4gY29tZm9ydC4NCj4+ID4+Pj4+Pg0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBGcm9tOiBzZmMNCj4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBv ZiBKb2VsIE0uIEhhbHBlcm4NCj4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4gPj4+ Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86IGh1YW5nQHNjZS5j YXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsNCj4+ID4+Pj4+PiBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+Pj4+Pg0K Pj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRvIGRlcGxv eSB0aGUgYXJjaHRpZXR1cmUNCj4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2ls bCBleGNlZWQgdGhlIGxpbWl0cyBvZiB0aGVpcg0KPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNo aXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZCB1c2Ugb2YNCj4+ID4+Pj4+PiBz ZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4+ ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0 dXJlIGRvZXMgcGVybWl0DQo+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+ID4+Pj4+Pg0KPj4gPj4+ Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlIHBl cm1pdHMNCj4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVk IG9yIHJlcXVpcmVkIGJ5IHRoZSB3b3JrLg0KPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4gPj4+Pj4+ DQo+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IE9uIDcvMTAvMTQs IDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiA+Pj4+Pj4+IElmIHlvdSBuZWVk IHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsIG1lYW4NCj4+ID4+Pj4+Pj4g MTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZyB0YWJsZSBv ZiBhDQo+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBDaGFu Zw0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0u IEhhbHBlcm4gd3JvdGU6DQo+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJh bmdlIG9mIGRlcGxveW1lbnRzLCBmcm9tIDENCj4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAx NjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlIHRoYXQNCj4+ID4+Pj4+Pj4+IG9wZXJh dG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleSBjaG9vc2UgdG8N Cj4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGlu IHN0ZWFkIHByb3Zpc2lvbg0KPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPj4g Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+ Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4gPj4+ Pj4+Pj4+IFBhdWwsDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlk ZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3Agc2VydmljZQ0KPj4gPj4+Pj4+Pj4+ IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4gPj4+Pj4+Pj4+DQo+PiA+ Pj4+Pj4+Pj4gTWFyaWENCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZg0KPj4gPj4+Pj4+Pj4+ICpQ YXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzDQo+ PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Ow0KPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFv bC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywNCj4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+ Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4g T3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUNCj4+ID4+ Pj4+Pj4+PiBmb3J3YXJkaW5nLiBJwrlkDQo+PiA+Pj4+PiBtYWtlDQo+PiA+Pj4+Pj4+Pj4gdGhl IG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0byBkZXJpdmUN Cj4+ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNw b3J0Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9y dCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvIHNpbXBseQ0KPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRo ZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMgbXVzdA0KPj4gPj4+Pj4+Pj4+ IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4+ Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0 aGlzDQo+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRo ZSBwYXRoIGlkZW50aWZpZXINCj4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhh biBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuIHJlc3VsdA0KPj4gPj4+Pj4+Pj4+IGluIGEgb25l IG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4gPj4+Pj4+Pj4+ IGhvcChzKS4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+ID4+Pj4+Pj4+Pg0K Pj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4g Pj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbSA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUyMCUzY21haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4+Pg0KPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+ Pj4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3Vs ZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUNCj4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4gPj4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gKkZyb206KnNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiBCZWhhbGYNCj4+ID4+Pj4+Pj4+PiBP Ziptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzpPZiptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4gKlNlbnQ6KlRodXJzZGF5LA0KPj4gSnVseQ0KPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0 IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+O2ptaEBqb2VsaGFscGVybi5jb20NCj4+ID4+Pj4+Pj4+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86 c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPj4gPj4+ Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+ Pj4+IFJlLSwNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJhZnQgY2Fs bHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVy LiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2ZQ0KPj4gPj4+Pj4+Pj4+ IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IFJlcXVpcmlu ZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4+ID4+ Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBh biBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQN Cj4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRz Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91 bGQgcmVseSBvbiB0aGUgcGllY2Ugb2YNCj4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4+ Pj4gdGhhdCB3aWxsDQo+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6 IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0bw0KPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNl cnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQgdG8NCj4+ID4+Pj4+Pj4+ PiBpbmZlciBmb3J3YXJkaW5nDQo+PiA+Pj4+PiBhY3Rpb25zDQo+PiA+Pj4+Pj4+Pj4gaXMgYSBz b2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4g Q2hlZXJzLA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gTWVkDQo+PiA+Pj4+Pj4+Pj4NCj4+ ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGEg cGFydA0KPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOmRlKm1pa2ViaWFuY0Bh b2wuY29tPg0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOp IDoqbWVyY3JlZGkgOSBqdWlsbGV0DQo+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhA am9lbGhhbHBlcm4uY29tDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t PjtzZmNAaWV0Zi5vcmcNCj4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0 IDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBx dWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIFNGIENoYWluDQo+PiA+Pj4+Pj4+Pj4g YW5kIFNGDQo+PiA+Pj4+PiBQYXRoPw0KPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWlu ZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MgY2xlYXIgdG8NCj4+ID4+Pj4+IHRob3NlIG5v dA0KPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2 ZXJ5b25lIGFncmVlcyBvbg0KPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gPj4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFy IGlzIHdoZXRoZXIgaXQgaXMNCj4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQg dG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQgdGhlIElEDQo+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNG QyBIZWFkZXINCj4+ID4+Pj4+IHNob3VsZA0KPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNo YWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdCBzaW1wbHkNCj4+ID4+Pj4+Pj4+PiBp bnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlciBkcmFmdHMgdG8N Cj4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2Vk IG9uIGNoYWluIG9yDQo+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBv cg0KPj4gPj4+Pj4gcGF0aCB0bw0KPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNv bnRyb2wtcGxhbmUuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChh bWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlDQo+PiA+Pj4+Pj4+Pj4gcmVxdWly ZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZQ0KPj4gPj4+ Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUgdmVu ZG9ycyBvbmx5DQo+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1 cHBvcnRpbmcgU0ZDLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+DQo+Pg0K Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+LS0NCj4+ID4+Pj4+LS0NCj4+ID4+Pj4+DQo+PiA+ Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAqRnJvbToqam1oQGpvZWxo YWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20lMGI+Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2Vs aGFscGVybi5jb20+Pg0KPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9y Zw0KPG1haWx0bzpzZmNAaWV0Zi5vcmclMGI+Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYu b3JnJTNjc2ZjQGlldGYub3JnPj4gKlNlbnQ6KlR1ZXNkYXksIEp1bHkNCj4+ID4+Pj4+Pj4+PiA4 LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJIGhhdmUg YmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXIgYQ0KPj4gPj4+ Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZSBw cm9wb3NlZA0KPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5n IHdlIGNhbiBnZXQgd29ya2luZw0KPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUg aW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8gaW1wcm92ZSB0aGUNCj4+ID4+Pj4+Pj4+PiB3b3JkaW5n IHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluIHRoZSBXRw0KPj4g Pj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ID4+ Pj4+IHdvcmtpbmcNCj4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPj4gPj4+Pj4+Pj4+DQo+ PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4g bXkgcGVyc29uYWwNCj4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+ PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50 IHRvIGtlZXAgaW4gbWluZCB0aGF0IHdoYXQNCj4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcg aXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90DQo+PiA+Pj4+Pj4+Pj4g YXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZQ0KPj4g Pj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29t cGFzcw0KPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1 bmN0aW9ucywgdmlydHVhbA0KPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1l bnQsIGFuZCBtYW55IG90aGVyIGFzcGVjdHMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBB cyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRvDQo+ PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVh bHQgd2l0aCBhYm92ZQ0KPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4+Pj4gZnVuY3Rp b25pbmcsDQo+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhl IHdvcmsgd2UgYXJlIGRvaW5nLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIg dG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJDQo+PiA+Pj4+Pj4+ Pj4gdW5kZXJzdGFuZA0KPj4gPj4+Pj4gdGhlbSwNCj4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0DQo+PiA+Pj4+Pj4+ Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwN Cj4+ID4+Pj4+Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2Jh Ymx5IGFyZSBtb3JlLg0KPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJl IGlzIHRvIHBlcm1pdCBhbGwgb2YgdGhlc2UsDQo+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5k YXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPj4gPj4+Pj4gYmUgdXNlZA0KPj4gPj4+Pj4+ Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IDEpIExvYWQg YmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kIHVzZXIuDQo+PiA+Pj4+ Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0 cywgYW5kDQo+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4+ID4+Pj4+IG1hcmtzDQo+ PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vy dmljZSBpbnN0YW5jZQ0KPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4g VGhpcyBpcyBhbiBpbXBvcnRhbnQgc2VydmljZQ0KPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJl IGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLiBJdCdzDQo+PiA+Pj4+Pj4+Pj4g YmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UgY2hhaW5pbmcg aXMNCj4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0 aGUgYXJjaHRpZWN0dXJlLg0KPj4gPj4+Pj4+Pj4+IEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNy c3BlY3RpdmUgaXQgaXMgc2ltcGx5IGENCj4+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+Pj4+Pj4+PiBm dW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+Pj4+ Pj4+Pg0KPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBU aGF0IGlzLCBvbmUgY2FuIGhhdmUNCj4+ID4+Pj4+Pj4+PiB3aGF0DQo+PiA+Pj4+PiBhcHBlYXJz DQo+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEg c2luZ2xlIHBvaW50IG9mDQo+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4gPj4+Pj4gZm9yIGENCj4+ ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVs aXZlcmVkIGJ5IGENCj4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+ID4+Pj4+Pj4+PiB2aXJ0dWFs IG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcgb25lIG9yDQo+PiA+Pj4+ Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtl DQo+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5 LCB0aGlzIGlzDQo+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5n IGRhdGEgcGxhbmUgbWVjaGFuaXNtcy4gSXQNCj4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBp dCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbCBtZWNoYW5pc21zLA0KPj4gPj4+Pj4+Pj4+ IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZCB2 bQ0KPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBv ZiBwZXJtaXR0aW5nIHRoaXMNCj4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0 byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5DQo+PiA+Pj4+Pj4+Pj4gZG9lcyBub3Qg bGVhZA0KPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBwcm9o aWJpdGluZyBpdC4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNv IGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgc2VsZWN0aW5nDQo+PiA+Pj4+Pj4+Pj4gcGFja2V0 IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdCB0cmFmZmljDQo+PiA+ Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8gcmVxdWly ZSB0aGF0IGENCj4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBv bmx5IG9uZSBwbGFjZSBpbiB0aGUNCj4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJl IGNvbWJpbmVkLiBJIHRlbmQNCj4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4+Pj4gcmVmZXIgdG8NCj4+ ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2 aWNlIGNoYWluaW5nDQo+PiA+Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVy LiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGENCj4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBi ZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuIFRodXMsIHRoZQ0KPj4gPj4+Pj4+Pj4+ IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4+Pj4gaXMgdG8NCj4+ID4+Pj4+ Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQgc2lu Z3VsYXINCj4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlm ZmVyZW50IHBsYWNlcyBpbiB0aGUNCj4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkg dGFsayBhYm91dA0KPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8g U2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlDQo+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5j dGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZiBwYWNrZXRzLg0KPj4gPj4+Pj4+Pj4+ IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YgdHJhZmZpYyBp cw0KPj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24s IGFuZCBmaXJld2FsbA0KPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0 byBnbyBkaXJlY3RseSB0byB0aGUgY2FjaGUNCj4+ID4+Pj4+IHdpdGhvdXQNCj4+ID4+Pj4+Pj4+ PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSBw YWNrZXRzLiBBDQo+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24s IGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zDQo+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRo b3NlIGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVk IHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5IG1heSBiZQ0KPj4gPj4+ Pj4+Pj4+IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXMg cG9ydHMgb24NCj4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3 YXlzIHRoYXQgdGhlIGxvY2F0aW9ucw0KPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUg c2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlDQo+PiA+Pj4+Pj4+Pj4gdHJh bnNwb3J0Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9mIHZp ZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91cCwgd2UNCj4+ID4+Pj4+Pj4+Pj4gbmVlZCB0 byBiZQ0KPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0 cmFjdGlvbiwgdGhlIHNlcnZpY2UNCj4+ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRo ZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byB0YWxrDQo+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhl IGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+PiA+Pj4+Pj4+Pj4g bmV0d29yay4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1l bnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZSBwYXRoIG1heQ0KPj4gPj4+Pj4+Pj4+IG5vdCBi ZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoDQo+PiA+ Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0g KDIpIG9uIGxvYWQNCj4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBk ZWNpc2lvbnMgYW5kIGJlaGF2aW9ycyB3aGljaA0KPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUg dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgbWVjaGFuaXNtcyAoaW4gbXVjaA0KPj4gPj4+Pj4+Pj4+ IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+PiA+ Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyIHBy b3Zpc2lvbiB3ZQ0KPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+Pj4+IHRoYXQNCj4+ID4+Pj4+ Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuIG5lY2Vz c2FyeS4NCj4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hh aW4uIEJhc2VkIG9uDQo+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSBy ZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQNCj4+ID4+ Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3Jr aW5nIGdyb3VwLA0KPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25h bCB3b3JkcyBhcmUgbmVlZGVkIHRvDQo+PiA+Pj4+Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3 b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlIGludGVudCwNCj4+ID4+Pj4+Pj4+PiB0aGVu IHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZyBncm91cA0KPj4g Pj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qg c3VyZSB3aGF0IHRvDQo+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+ Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiBtYWlsaW5nDQo+ PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+ Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+IG1haWxpbmcN Cj4+ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+ Pj4+Pg0KPj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBzZmMNCj4+IG1haWxpbmcNCj4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYyBtYWlsaW5nDQo+PiBsaXN0DQo+PiA+Pj4+ Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGluZw0K Pj4gbGlzdA0KPj4gPj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+DQo+PiA+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYyBtYWlsaW5n DQo+PiBsaXN0DQo+PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+Pg0KPj4gPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGlu Zw0KPj4gbGlzdA0KPj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4NCj4+ID4+Pg0K Pj4gPj4NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+PiA+Pg0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPnNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4EDCGSCMAMP19EXfi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCB1bmRlcnN0YW5kLiAoSeKAmW0g c3VyZSBJ4oCZbSBtaXN1bmRlcnN0YW5kaW5n4oCmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WW91ciBi YWNrZW5kIHNlcnZlcnMgY291bGQgZ28gZG93biwgYmUgdW5yZWFjaGFibGUgb3IgYmUgdW5hYmxl IHRvIHNlcnZlciBtb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Um91dGUgaGVhbHRoIGluamVjdGlv biAoUkhJKSBpcyBhIHBlcmZlY3RseSBmaW5lLCBhY2NlcHRlZCwgd2F5IG9mIGluZGljYXRpbmcg dGhlIGhlYWx0aCBvZiB0aGUgYmFja2VuZCBzZXJ2aWNlcyB0byB0aGUgbmV0d29yay4gWW914oCZ cmUgbm90IHNheWluZyB0aGF04oCZcyB3cm9uZywgYXJlIHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPm1pa2ViaWFu Y0Bhb2wuY29tPGJyPjxiPlNlbnQ6PC9iPiAxMSBKdWx5IDIwMTQgMTI6MDMgUE08YnI+PGI+VG86 PC9iPiBqZ3VpY2hhckBjaXNjby5jb207IG1uMTkyMUBhdHQuY29tOyBqbWhAam9lbGhhbHBlcm4u Y29tOyBSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tOyBzZmNAaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+aGVoLiAmbmJzcDt3ZWxsLCBpZiBpdCBk aWQgbm90LCB0aGVuIHlvdSBzaG91bGQgbm90IGRvIGl0IGxpa2UgdGhhdC4gJm5ic3A7ZS5nLiBJ J20gbm90IGdvaW5nIHRvIGNvbmZpZ3VyZSByZWFsIHNlcnZlcnMgb24gYSBzZXJ2ZXIgbG9hZCBi YWxhbmNlciB0aGF0IGFyZSBub3QgcmVhY2hhYmxlLiAmbmJzcDtlLmcuIEknbSBub3QgZ29pbmcg dG8gY29uZmlndXJlIG15IEJHUCB0byBhbm5vdW5jZSBwcmVmaXhlcyBmb3Igd2hpY2ggSSBjYW5u b3QgcHJvdmlkZSBjb25uZWN0aXZpdHkuICZuYnNwO0lmIHlvdSBkbyB0aGluZ3MgbGlrZSB0aGF0 LCB0aGVuIHlvdSBhcmUgZG9pbmcgaXQgd3JvbmcuPGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbic+ PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjYuNzVwdDttYXJnaW4tbGVmdDouNWluO3RleHQtYWxpZ246Y2VudGVyJz48aHIgc2l6ZT0x IHdpZHRoPSIxMDAlIiBub3NoYWRlIHN0eWxlPSdjb2xvcjojOTk5OTk5JyBhbGlnbj1jZW50ZXI+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo2Ljc1cHQ7bWFyZ2luLWxlZnQ6LjVpbic+PGI+ RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBj aXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbSZsdDtqZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0 Ozxicj48Yj5UbzogPC9iPk5BUElFUkFMQSwgTUFSSUEgSCZsdDs8YSBocmVmPSJtYWlsdG86bW4x OTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDssSm9lbCBNLiBIYWxwZXJuJmx0Ozxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9h PiZndDssUm9uIFBhcmtlciZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LHNmY0Bp ZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj48Yj5TZW50OiA8L2I+RnJpZGF5LCBKdWx5IDExLCAyMDE0PGJyPjxiPlN1YmplY3Q6 IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 YnI+PGJyPlRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwg aXQgc2VlbXMgdG8gbWUgdGhhdCBpZjxicj55b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNp c2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0IHdpbGwgdXNlIGZvcjxicj5hIGdpdmVuIGZs b3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdSBiZXR0ZXIg bWFrZTxicj5zdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndh cmRpbmcgbG9naWMgdG8gcmVhY2ggdGhlPGJyPm5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFz IG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS48YnI+PGJyPk9uIDcvMTEvMTQsIDk6 NDggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0 O0Fic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkg aW4gcmVsZXZhbnQgU0ZGczxicj4mZ3Q7d2hlbiB0aGV5ICZxdW90O2Fycml2ZSZxdW90Oy48YnI+ Jmd0Ozxicj4mZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7Jmd0OyA8 YnI+PGJyPkZyb206IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJk PGJyPiZndDsmZ3Q7KGpndWljaGFyKTxicj4mZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEs IDIwMTQgOToyNyBBTTxicj4mZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2Vy OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPiZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vyczxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsgV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4g d29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29kIHRoZTxicj4mZ3Q7Jmd0O3Byb3Bv c2FsPGJyPiZndDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xl ZGdlIG9mIGV2ZXJ5IHNpbmdsZSBTRiB3aXRoaW48YnI+Jmd0OyZndDt0aGU8YnI+Jmd0OyZndDsg ZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkg dG8ga25vdyBhPGJyPiZndDsmZ3Q7cHJpb3JpPGJyPiZndDsmZ3Q7IHdoaWNoIFNGQ8K5cyBhIGdp dmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4gcG9pbnQgaW4gdGltZS48 YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAmcXVvdDtKb2Vs IE0uIEhhbHBlcm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Ij5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7 Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFq b3IgcHJvYmxlbSB3aXRoIHRoZTxicj4mZ3Q7Jmd0O3lvdXI8YnI+Jmd0OyZndDsgJmd0O3Byb3Bv c2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90IHVu ZGVyc3RhbmQ8YnI+Jmd0OyZndDsgJmd0O2l0Lik8YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0 OyAmZ3Q7VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNl ciBmb3IgdGhlIG5leHQ8YnI+Jmd0OyZndDsgJmd0O3NlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xs b3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycyB0byksIGluIGV2ZXJ5PGJyPiZndDsmZ3Q7 ICZndDtzZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Ljxicj4mZ3Q7Jmd0OyAmZ3Q7 PGJyPiZndDsmZ3Q7ICZndDtTaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxs IHNlcnZpY2VzLCB0aGF0IG1lYW5zIHRoYXQ8YnI+Jmd0OyZndDtldmVyeTxicj4mZ3Q7Jmd0OyAm Z3Q7U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVm dWwgbG9hZCBiYWxhbmNlci48YnI+Jmd0OyZndDsgJmd0O0kgYWh2ZSBubyBwcm9ibGVtIGlmIHNv bWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3Igc3RhdGVmdWwuPGJyPiZndDsmZ3Q7 ICZndDtCdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBi ZSBhIGZ1bGwsIGZsb3c8YnI+Jmd0OyZndDsgJmd0O3NlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQg YmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4gYWNjZXB0YWJsZTxicj4mZ3Q7Jmd0OyAmZ3Q7 aW1wb3NpdGlvbi48YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7WW91cnMsPGJyPiZn dDsmZ3Q7ICZndDtKb2VsPGJyPiZndDsmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0O09uIDcvMTAv MTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhp cyB3b3JrPGJyPiZndDsmZ3Q7c2Vuc2libHk8YnI+Jmd0OyZndDsgJmd0OyZndDsgaW4gYSBtb3Jl IG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gSSBleHBlY3QgdGhhdCB0aGUgc2VydmljZTxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNG RiBjYXBhYmlsaXRpZXMsIHdpbGwgYmU8YnI+Jmd0OyZndDsgJmd0OyZndDsgb3JjaGVzdHJhdGVk IGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucyB0byBiZTxicj4mZ3Q7 Jmd0O2RyaXZlbiBieTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyBCU1MgdG9vbHMgdGhhdCBkZWZpbmUg b2ZmZXJpbmdzIHRvIGNsaWVudHMsIGFuZCBlbmFibGUgc2VsZi1zZWxlY3Rpb248YnI+Jmd0OyZn dDsgJmd0OyZndDsgZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2 aWx5IHBvbGljeSBkcml2ZS48YnI+Jmd0OyZndDsgJmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZn dDsgSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRpZWN0 dXJlIGRyaXZlbiBieTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbml0aWFsIGNsYXNzaWZpY2F0aW9u IHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBpcyBoYXJkZXIgdG88YnI+Jmd0OyZndDtz ZWU8YnI+Jmd0OyZndDsgJmd0OyZndDsgaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBi ZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmU8YnI+Jmd0OyZndDsgZHluYW1pY2l0eTxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yayBiZWhhdmlvci48YnI+Jmd0OyZndDsgJmd0OyZn dDs8YnI+Jmd0OyZndDsgJmd0OyZndDsgSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBl cnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNpZGUgb2Y8YnI+Jmd0OyZndDt0aGU8YnI+Jmd0 OyZndDsgJmd0OyZndDsgc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21l dGhpbmcgd2UgYXJlIHRhc2tlZCB0bzxicj4mZ3Q7Jmd0O2FncmVlPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7b24uPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9u IG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYSBjZXJ0YWluIHdheS48YnI+Jmd0OyZndDtpdDxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBw cmVmZXJlbmNlcy48YnI+Jmd0OyZndDsgJmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsgWW91 cnMsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7IEpvZWw8YnI+Jmd0OyZndDsgJmd0OyZndDs8YnI+Jmd0 OyZndDsgJmd0OyZndDsgT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOjxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlv biBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcyB0aGF0PGJyPiZndDsmZ3Q7bmVlZHM8YnI+Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0O3RvPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYmUgd2lk ZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBk YXRhPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5p c3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQgY29tcGxleDxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2gg U0ZGIHNlZW1zIGxpa2UgYSBkaWZmaWN1bHQ8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBh cmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBs aWNhdGVkIHRoYW4gZHluYW1pYyByb3V0aW5nLDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlw ZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Ygd2hpY2gg YXJlPGJyPiZndDsmZ3Q7YmlnZ2VyPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm9ibGVtcyB0 aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSXQgYWxzbyBzZWVtcyB0 aGF0IGlmIGl0IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNhdGVkLCB0aGF0IGlzIGEgZ29vZDxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC48YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBG cm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21dPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgPGEg aHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT47IElh biBTbWl0aDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoaXMgaXMgYW4g YXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQgcHJlZmVyIHdlPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FjdHVhbGx5PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWNp ZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGUgaW1wbGVtZW50YXRp b25zLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpv ciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wgcmVxdWlyZW1lbnRzIGFuZDxicj4mZ3Q7Jmd0OyB0aGU8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy48YnI+Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGb3IgbWUsIHRoZSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMgdGhhdCBuZWVkczxicj4m Z3Q7Jmd0OyB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVk IGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBkYXRhPGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMg bGFyZ2UgZW5vdWdoIGFuZCBjb21wbGV4PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBlbm91Z2gg dGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGEgZGlmZmlj dWx0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IEpvZWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLjxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDk6Mzgg UE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBp cyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gJm5ic3A7IElzIHRoZSBlbmQgdG8gZW5kIHNlbGVjdGlv biBvZjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBw ZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZTxicj4mZ3Q7Jmd0O2NsYXNzaWZpZXIp PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0 aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5IHRoZTxicj4mZ3Q7Jmd0O1NGRnMpPzxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50 IHRvIHJlY2xhc3NpZmljYXRpb24uICZuYnNwOyBBbmQgc3VyZWx5LDxicj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90IHJlbGVn YXRlZCB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O2ltcGxlbWVudGF0aW9u JnF1b3Q7Ljxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNo IGV2ZW4gdGhvdWdoIGE8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBncmVhdGVyIGFtb3Vu dCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwcyBsb2NhbDxicj4mZ3Q7Jmd0 O3NlbGVjdGlvbjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBvbGljeSkgaXMgcmVxdWly ZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLiAmbmJzcDsgVGhpczxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5k LXRvLWVuZCBwYXRoIGlkIGF0IGFsbC4gJm5ic3A7Jm5ic3A7IE15PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1h cmlseSBkcml2ZW4gYnk8YnI+Jmd0OyZndDtpbmNyZWFzZWQ8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiAmbmJz cDsgV2l0aCBhIGdsb2JhbCBwYXRoPGJyPiZndDsmZ3Q7aWQ8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVl ZGluZyB0byBhbHRlciB0aGU8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBnbG9iYWwgcGF0 aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQgZW5kLXRvLWVuZCBwYXRoLjxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Um9uPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYzxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVo YWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3Q8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBb am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDY6MTUgUE08YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0 bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOjxicj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNGMSBuZWVk aW5nIHRvPGJyPiZndDsmZ3Q7aW5mbHVlbmNlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg dGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlIGV4 aXQgZnJvbTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNGMS48YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBhcnQgb2YgdGhlIGdv YWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHk8YnI+Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJs eSBkZXNjcmliZSBob3cgdGhleSBjaG9vc2UgdG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBjb21wb3NlIHRoZW0gZm9yICZxdW90O3NlcnZpY2UmcXVvdDsgZGVsaXZlcnkuPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBZb3Vycywg Sm9lbDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgT24gNy8xMC8xNCwgNjoxMCBQTSwgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4gd3JvdGU6PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3Vn Z2VzdHMgYW55IHNvcnQgb2Y8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGltaXQu IEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUgcGF0aCAo YWxsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNGSXMpIG11c3QgYmUgY2hvc2Vu IGF0IFNGQyBpbnN0YW50aWF0aW9uLiBJIGJlbGlldmUgdGhpcyBtZWFuczxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhl IGNsYXNzaWZpZXIgY2hvb3NlcyBhIFNGPGJyPiZndDsmZ3Q7Q2hhaW48YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBT RkYuIEluIGFueSBjYXNlLCB0aGU8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGFu Z3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNGUCB3aGVyZSBTRkko bikgaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV0ZXJtaW5lZCBhdCB0aGUg U0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LCB0aGlzPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgJnF1b3Q7YnJh bmNoaW5nJnF1b3Q7IHRvIGEgbmV3IFNGUCBhcyBvcHBvc2VkPGJyPiZndDsmZ3Q7IHRvPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcg dG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlIG9mIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LW1lcmdl ZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVj ZXNzYXJ5IHRvPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZWxlY3QgdGhl IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0bzxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9s b2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcms8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGxvY2F0b3IuIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyBy ZXN1bHRzIGluIHRoZSBjcmVhdGlvbjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yIGZvcndh cmRpbmc8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhY2tldHMgdGhyb3Vn aCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNh dGlvbiAob3Igbm9uLWluaXRpYWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCw8YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gbWF5IG9j Y3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBhPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2Vy dmljZSBmdW5jdGlvbi48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlY2xh c3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3IFNGUCwgYW48 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVwZGF0ZSBvZiB0aGUgYXNzb2Np YXRlZCBtZXRhZGF0YSwgb3IgYm90aC4gVGhpcyBpcyByZWZlcnJlZCB0bzxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgJnF1b3Q7YnJhbmNoaW5nJnF1b3Q7Ljxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyA8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqRnJvbTogPGEgaHJlZj0ibWFpbHRvOipJ LlNtaXRoQEY1LmNvbSUzY0kuU21pdGhARjUuY29tIj4qSS5TbWl0aEBGNS5jb20mbHQ7SS5TbWl0 aEBGNS5jb208L2E+Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86ICpK b2VsIEhhbHBlcm4gRGlyZWN0Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxw ZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxKb2VsIE0uPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7SGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LGh1YW5nQHNjZS5jYXJsZXRvbi5jYSZsdDs8YSBocmVmPSJt YWlsdG86aHVhbmdAc2NlLiUwYiI+aHVhbmdAc2NlLjxicj48L2E+Jmd0OyZndDsgY2FybGV0b24u PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Y2EmZ3Q7LHNmY0BpZXRmLm9yZyZsdDs8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vyczxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVl aW5nLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1l bnRzIChhbmQgdGhhdCBpcyB3aGF0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2 IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzIHByZWNv bmNlaXZlZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBhbiBhYnN1cmQgaWRl YSwgdGhlbiB0aGUgYXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGggdGhhdDxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcmVjb25jZXB0aW9uLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBoYXMgdG8g YmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mIGFzcGlyYXRpb24gdG88YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3Ig dGhlIGxpZmVzcGFuIG9mIHRoZSBhcmNoaXRlY3R1cmUgLTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlp bmcgdGhhdCBhbiBhcmJpdHJhcnk8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbnVt YmVyIGlzICZxdW90O3RvbyBmYXImcXVvdDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQg aXNuJ3Q8YnI+Jmd0OyZndDtpbnRlbnRpb25hbDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGlu ZyBpbXBhY3RzPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2FyZGluZyBzY2Fs ZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwgYWRkcmVzczxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0 IGlzIGEgcHJvYmxlbSBJJ20gbm90PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBh cnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbTog Sm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6PGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6 MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLiBIYWxwZXJuOzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFu Z0BzY2UuY2FybGV0b24uY2E8L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXMg cmVnYXJkLiBJPGJyPiZndDsmZ3Q7YW08YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg bm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uIHByb2hp Yml0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlcGxveW1lbnRzIGluIHRoZSBz cGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0byBIdWFuZydzPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNo IGRlcGxveW1lbnRzIGFyZSByZXF1aXJlZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFzIEkgaGF2ZSBzYWlkIHJlcGVh dGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdCBzdWNoPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBu b3QgZGVwZW5kcyB1cG9uIG1hbnk8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFj dG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvIHRoaW5rIHRo YXQ8YnI+Jmd0OyZndDt0aGV5PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSB1 c3VhbGx5IGEgYmFkIGlkZWEuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVm dWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvIGtub3cgd2hhdDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS48YnI+Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpv ZWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOjxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkaXNhZ3JlZS48YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2Yg bWlsbGlvbnM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3Mg bmV0d29yayBhbmQgZGF0YSBjZW50ZXI8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg ZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbiB0 aGU8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9X ZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdSBhcmUgb25seTxicj4mZ3Q7Jmd0OyBnb2lu Zzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBoYXZlIHNtYWxsIG51bWJlcnMg b2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5IHNtYWxsIG51bWJlcnM8YnI+Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/PGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAmcXVvdDtubyBvbmUgd2lsbCBldmVyIG5l ZWQgbW9yZSB0aGFuIDY0SyZxdW90Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZm9yPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbWZvcnQuPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBK b2VsIE0uIEhhbHBlcm48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgW2ptaEBqb2Vs aGFscGVybi5jb21dPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOiA8YSBocmVmPSJtYWlsdG86aHVhbmdA c2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Ozxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8g ZGVwbG95IHRoZSBhcmNodGlldHVyZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YgdGhl aXI8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMuIFRoZSBhcmNo aXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZCB1c2Ugb2Y8YnI+Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBm aWd1cmUgb3V0IGhvdyB0byB3cml0ZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZSBk b2VzIHBlcm1pdDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBhYnVz ZS48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhl IGFyY2h0aWVjdHVyZSBwZXJtaXRzPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5 IHRoZSB3b3JrLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXNuJ3Qu PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0 LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hh aW5zLCBpdCB3aWxsIG1lYW48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nIHRhYmxl IG9mIGE8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3JlIHJvdXRl ci48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYW5nPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBhcmNoaXRlY3R1cmUgYWxs b3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20gMTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0 aHMuIEkgd291bGQgaG9wZSB0aGF0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYg dGhleSBjaG9vc2UgdG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQgcHJv dmlzaW9uPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2MCww MDAgc2VydmljZSBwYXRocy48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMs IEpvZWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNDowNiBQ TSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF1bCw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEg NCBob3Agc2VydmljZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/PGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFyaWE8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2Y8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpQYXVsIFF1 aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5IHlv bmcgKkNjOiogPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFs cGVybi5jb208L2E+Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNA YW9sLmNvbTwvYT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTHVjeSw8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdmVyYWxsIEkgY29uY3Vy LCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZy4gScK5ZDxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNh biBiZSB1c2VkIHRvIGRlcml2ZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9y dC48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBfbm90XyB0 aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8gc2ltcGx5PGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpZGVudGlmeSB0aGUgc2VydmljZSBw YXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzIG11c3Q8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50 aWZpZXIsIHRoZSBleGFjdDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9u IHRoaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo cmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aCBpZGVudGlmaWVyPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBu b3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuIHJlc3VsdDxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYSBvbmUgb3IgbW9y ZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob3AocykuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF1bDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZzxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUyMCUzY21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNv bSI+bHVjeS55b25nQGh1YXdlaS5jb20gJmx0O21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbTwv YT4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgd3JvdGU6PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBZ3JlZS4gVGhlIGFyY2guIGRvYyBz aG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YgdGhlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2 ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEx1Y3k8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAq RnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dKk9uIEJlaGFsZjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9mKm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20iPk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgKlNlbnQ6KlRodXJzZGF5LDxicj4mZ3Q7Jmd0OyBK dWx5PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxMCwg MjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb208YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7O2ptaEBqb2VsaGFscGVy bi5jb208YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmd0OztzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5t YWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucyw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBSZS0sPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhl IG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aDxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaWRlbnRpZmllci4gSSBv YmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJpdmU8YnI+Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcgYWN0aW9ucy48YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZXF1aXJpbmcgYSBTRkMgc3lzdGVt IHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGF2YWlsYWJsZSBTRkM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVk IGRvbWFpbiBpcyBub3Q8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQv anVzdGlmaWVkPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLjxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hv dWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGF0IHdpbGw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUgcmVx dWlyZWQgdG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHVzZWQg dG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVy IGZvcndhcmRpbmc8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWN0aW9uczxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBzb2x1dGlv bi1vcmllbnRlZCBkaXNjdXNzaW9uLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IENoZWVycyw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBN ZWQ8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRGUgOipzZmMgWzxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPC9hPl0qRGUgbGEgcGFydDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20iPmRlKm1pa2ViaWFuY0Bhb2wuY29t PC9hPjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0 OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPC9hPiZndDsgKkVudm95w6kgOiptZXJjcmVkaSA5IGp1aWxsZXQ8YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpv ZWxoYWxwZXJuLmNvbTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7O3NmY0BpZXRmLm9yZzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqT2JqZXQgOipSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gU0YgQ2hhaW48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFuZCBTRjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRoPzxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXIgdGhh biBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQncyBjbGVhciB0bzxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBub3Q8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBz ZWVtcyB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlc2UgdGVybXMuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNs ZWFyIGlzIHdoZXRoZXIgaXQgaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNp Znkgd2hhdCB0aGUgSUQ8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG9mIHRoZSBTRkMgSGVhZGVyPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNob3VsZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg cmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0IHNpbXBs eTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50ZW5k cyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaWN0YXRlIHRoZSBt ZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluIG9yPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIGFuZCB0aGUgY2hvaWNlIG9m IGNoYWluIG9yPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGggdG88YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIG5lZ290aWF0ZWQg aW4gdGhlIGNvbnRyb2wtcGxhbmUuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2 ZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWly ZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZTxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQgYW5kIHRo ZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZSB2ZW5kb3JzIG9ubHk8YnI+Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1cHBvcnRpbmcgU0ZQIGFuZCBv dGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyA8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29tJmx0OzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIj5qbWhAam9lbGhhbHBlcm4uY29tPGJyPjwvYT4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86KnNmY0Bp ZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnJTBiIj5zZmNAaWV0Zi5vcmc8 YnI+PC9hPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0Bp ZXRmLm9yZyUzY3NmY0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyAqU2VudDoqVHVlc2RheSwgSnVseTxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgOCwgMjAxNCAq U3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZp Z3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGE8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVl biBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2Ug Y2FuIGdldCB3b3JraW5nPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvIGlt cHJvdmUgdGhlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluIHRo ZSBXRzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlz Y3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB3b3JraW5nPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBncm91cCBpbnRlbmRzLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWlu IG15IHBlcnNvbmFsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVw IGluIG1pbmQgdGhhdCB3aGF0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJl LiBXZSBhcmUgbm90PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJl PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlv biBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3M8YnI+Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlvdXMgY29u dHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgdmlydHVhbDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwg YW5kIG1hbnkgb3RoZXIgYXNwZWN0cy48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBu ZWVkIHRvPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBl eGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoIGFib3Zl PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGVyZSB3 ZSBhcmU8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgYXJlIG5vdCBk aXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUgZG9pbmcuPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hh aW4gdnMgc2VydmljZSBwYXRoLCBhcyBJPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoZW0sPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxl YXN0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJl ZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQgd2lsbDxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50ZXJhY3Qgd2l0aCBz ZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS48YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRp ZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YgdGhlc2UsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFy dGljdWxhciBraW5kPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHVzZWQ8YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGFueSBzb2x1 dGlvbi48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBMb2FkIGJh bGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLjxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBhIHNlcnZpY2Ug ZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywgYW5kPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtb2RpZmllcyB0aGVtIChvcjxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXJrczxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4g ZW5kIHVzZXIgc2VydmljZSBpbnN0YW5jZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFu IGltcG9ydGFudCBzZXJ2aWNlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFp bmluZy4gSXQnczxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UgY2hhaW5p bmcgaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRv bmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZSBhcmNodGllY3R1cmUuPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIGFuIGFy Y2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2U8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcg cGFja2V0Ljxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIpIFRoZXJl IGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuIGhhdmU8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQ8YnI+Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyczxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0 dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9mPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBjb250YWN0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGZvciBhPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz cGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGE8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxicj4mZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNh bCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvcjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9y IGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0 bHksIHRoaXMgaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIG1lY2hhbmlz bXMuIEl0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp cyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbCBtZWNoYW5pc21z LDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBh cyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgYW5kIHZtPGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnN0YW50aWF0aW9u LiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0aGlzPGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBsYXJnZWx5IHRoYXQgd2Ug bmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyIHRlcm1pbm9sb2d5PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFkPGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRlcnMgdG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC48YnI+ Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxzbyBi ZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBj aGFpbmluZyB0aGF0IGRpcmVjdCB0cmFmZmljPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2Fu dCB0byByZXF1aXJlIHRoYXQgYTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxh Y2UgaW4gdGhlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBuZXR3b3JrLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlz IG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0ZW5kPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxicj4mZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhh dCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3Qg YmVjYXVzZSBjbHVzdGVyIGlzIGE8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVy IG9uZS4gVGh1cywgdGhlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmc8YnI+Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaXMgdG88YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZl cmVudCBzaW5ndWxhcjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMg aW4gdGhlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBu ZXR3b3JrLjxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdyB3aXRo IHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQ8YnI+Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgY2hhaW4gYW5kIHNl cnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlPGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBi ZSBhcHBsaWVkIHRvIGEgc3Vic2V0IG9mIHBhY2tldHMuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0 IHNvbWUgc3Vic2V0IG9mIHRyYWZmaWMgaXM8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rp b24sIGFuZCBmaXJld2FsbDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRo ZSBjYWNoZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXRob3V0PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2aXNpdGluZyBhbnkgb3Ro ZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0 cy4gQTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vy dmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zPGJy PiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0 d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3I8YnI+Jmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0 aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleSBtYXkgYmU8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5 IG1heSBiZSBhZGRyZXNzZWQgYXMgcG9ydHMgb248YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdh eXMgdGhhdCB0aGUgbG9jYXRpb25zPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFz dHJ1Y3R1cmUgYW5kIHRoZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdHJhbnNwb3J0Ljxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgZ3Jv dXAsIHdlPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbmVlZCB0byBiZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUg c2VydmljZTxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Y2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8gdGFsazxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWJvdXQgdGhl IGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlPGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4mZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUg c2FpZCAmcXVvdDtidXQgdGhlIHdob2xlIHBhdGggbWF5PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90 OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscyB3aXRoPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMg bm90ZWQgaW4gaXRlbSAoMikgb24gbG9hZDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25z IGFuZCBiZWhhdmlvcnMgd2hpY2g8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgbWVjaGFu aXNtcyAoaW4gbXVjaDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8 YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJs ZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2U8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2UgaXM8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdDxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBt aWQtY2hhaW4gd2hlbiBuZWNlc3NhcnkuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4u IEJhc2VkIG9uPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Ljxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaG9wZSB0aGF0IHRoaXMg aGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQ8YnI+Jmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlz IGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcgZ3JvdXAsPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9u YWwgd29yZHMgYXJlIG5lZWRlZCB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVl IHdpdGggdGhlIGludGVudCw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3Jr aW5nIGdyb3VwPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUgd2hh dCB0bzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5 IG5leHQuPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpv ZWw8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmM8YnI+Jmd0OyZndDsgbWFpbGlu Zzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBzZmM8YnI+Jmd0OyZndDsgbWFpbGluZzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2Zj QGlldGYub3JnPC9hPiZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHNmYzxicj4mZ3Q7Jmd0OyBtYWlsaW5nPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBzZmM8YnI+Jmd0OyZndDsgbWFpbGluZzxicj4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm YyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGluZzxicj4m Z3Q7Jmd0OyBsaXN0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHNmYyBtYWlsaW5nPGJyPiZndDsmZ3Q7IGxpc3Q8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGluZzxicj4mZ3Q7Jmd0OyBs aXN0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBz ZmMgbWFpbGluZzxicj4mZ3Q7Jmd0OyBsaXN0PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPiZndDsm Z3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4m Z3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyPiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPiZndDsmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0O19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7 ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBz ZmMgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT48YnI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+c2ZjIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_A3233753A4B65F43BCA1B64DA99A9C230708FD4EDCGSCMAMP19EXfi_-- From nobody Fri Jul 11 09:09: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 31C951B2BA2 for ; Fri, 11 Jul 2014 09:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 s4ijjyGKJ8JX for ; Fri, 11 Jul 2014 09:09:32 -0700 (PDT) Received: from omr-d08.mx.aol.com (omr-d08.mx.aol.com [205.188.109.207]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029431B2B55 for ; Fri, 11 Jul 2014 09:09:25 -0700 (PDT) Received: from mtaout-mbb02.mx.aol.com (mtaout-mbb02.mx.aol.com [172.26.254.110]) by omr-d08.mx.aol.com (Outbound Mail Relay) with ESMTP id 3D8BC700000AE; Fri, 11 Jul 2014 12:09:24 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mbb02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B34F638000083; Fri, 11 Jul 2014 12:09:23 -0400 (EDT) Date: Fri, 11 Jul 2014 12:09:23 -0400 From: "mikebianc@aol.com" To: jmh@joelhalpern.com, mn1921@att.com, jguichar@cisco.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <202520617.3090.1405094963576.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <53BFF20E.60900@joelhalpern.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3089_34255259.1405094963575" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405094964; bh=Rh237KqUbrki+FhSn8z5cBWTZ7Q11Xbn+DqJ5rPU44E=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=sWtgJ3N1uYy/dea+mjl3zZoaJG6WZql+Vgo01cYdv7lTnMilZlw4AR4+FKDIgiwEX VYTKTYyZ4gn7M0IdKDL2SdKONbNlDoyc27aZNtg5qHUJQWrIYGU5BrljOswMucha6V bAx+g+fBCIW0WjT0CaZ3auCFwE6QcZNavwtkSSyQ= x-aol-sid: 3039ac1afe6e53c00c33155c X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2mdULaSiLylPtW14XknYu5Nrugo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:09:37 -0000 ------=_Part_3089_34255259.1405094963575 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The arch should not prevent this, but "(even new flows)" is hardly ideal. = =C2=A0I can make the case for "(only existing flows)" (stateful) and for "S= FF-Z1 is eligible for all flows, even existing ones" (stateless). I don't see anything currently in the arch draft that would prohibit any of= these. From: jmh@joelhalpern.com To: NAPIERALA, MARIA H,Jim Guichard (jguichar),Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Just to check, I am going to get pedantic. We have SFF-X, is supporting (possibly via local load balancing) some=20 collection of local service function instances. When packets on a given service function path (SFP-Y) arrive, they are=20 processed by theose service functions, and SFF-X then has to forward the=20 packets (with suitable transport) to a next SFF, who may locally balance=20 among his service function instances. For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z. We consider first the state at time T0 when a packet arrives as SFF-X on=20 SFP-Y with no prior special state in SFF-X (obviously, there is some=20 state about SFP-Y, as we do not want policy lookups at packet handling=20 times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2.=20 If I understand your request, you want SFF-X to pick one of those two=20 SFF, say SFF-Z1. And send all the packets for SFP-Y on to SFF-Z1. Even=20 if SFF-Z3 is added to the network, all packets for all flows using SFP-Y=20 at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only=20 time SFF-X would change that is if discovered or was told that SFF-Z1=20 was down or unreachable. In that case, it would pick a new one from=20 among the known choices. Maria, if that is what you would like, I believe that either is=20 currently allowed by the architecture or can easily be added. And I am=20 happy to do so. I believe we can describe that in the resilience and=20 failure recovery section that we need to add. But I want to be really sure that is what you want. I don't think that=20 meets Ron's request. Yours, Joel On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: > Joel, > >> Hmm. Would it meet your goals Maria if all packets that arrived at >> SFF-X with SFP-Y were (after local SF processing) forwarded to some >> specific SFF-Z? Where SFF-Z was selected when the first packet with >> SFP-Y arrived at SFF-X? > > Yes. >> >> While that is more easily met, that does not seem likely to produce the >> scale flexibility you asked for. And if SFF-X may forward packets with > > Why not? > >> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the >> capability to ensure that a given flow continues to go to the same next >> SFF even when SFF-Z3 is added to the mix. > > Precisely. > > >> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: >>> Absolutely not. Service chains can be instantiated only in relevant SFF= s >> when they "arrive". >>> >> ... > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_3089_34255259.1405094963575 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The arch should not= prevent this, but "(even new flows)" is hardly ideal.  I can make the= case for "(only existing flows)" (stateful) and for "SFF-Z1 is eligible fo= r all flows, even existing ones" (stateless).

I don't see any= thing currently in the arch draft that would prohibit any of these.

=



From: jmh@joelhalpern.com<jmh@joelhalpern.com>
To= : NAPIERALA, MARIA H<mn1921@att.com>,Jim Guichard (jguichar)<j= guichar@cisco.com>,Ron Parker<Ron_Parker@affirmednetworks.com>,sfc= @ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
S= ubject: Re: [sfc] Service Chains, Paths, and Load Balancers

Just to check, I am going to get pedantic.
We have SFF-X, is = supporting (possibly via local load balancing) some
collection of local= service function instances.
When packets on a given service function pa= th (SFP-Y) arrive, they are
processed by theose service functions, and = SFF-X then has to forward the
packets (with suitable transport) to a ne= xt SFF, who may locally balance
among his service function instances.
For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-= Z.

We consider first the state at time T0 when a packet arrives as S= FF-X on
SFP-Y with no prior special state in SFF-X (obviously, there is= some
state about SFP-Y, as we do not want policy lookups at packet han= dling
times.) At this time T0, there exist in the network SFF-Z1 and S= FF-Z2.
If I understand your request, you want SFF-X to pick one of th= ose two
SFF, say SFF-Z1. And send all the packets for SFP-Y on to SFF-= Z1. Even
if SFF-Z3 is added to the network, all packets for all flows = using SFP-Y
at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1.= The only
time SFF-X would change that is if discovered or was told th= at SFF-Z1
was down or unreachable. In that case, it would pick a new o= ne from
among the known choices.

Maria, if that is what you woul= d like, I believe that either is
currently allowed by the architecture = or can easily be added. And I am
happy to do so. I believe we can des= cribe that in the resilience and
failure recovery section that we need = to add.

But I want to be really sure that is what you want. I don't= think that
meets Ron's request.

Yours,
Joel

On 7/11/1= 4, 10:07 AM, NAPIERALA, MARIA H wrote:
> Joel,
>
>> Hm= m. Would it meet your goals Maria if all packets that arrived at
>&g= t; SFF-X with SFP-Y were (after local SF processing) forwarded to some
&= gt;> specific SFF-Z? Where SFF-Z was selected when the first packet wit= h
>> SFP-Y arrived at SFF-X?
>
> Yes.
>>
&= gt;> While that is more easily met, that does not seem likely to produce= the
>> scale flexibility you asked for. And if SFF-X may forward= packets with
>
> Why not?
>
>> SFP-Y to SFF-Z1 = and SFF-Z2 then SFF-X has to be stateful and have the
>> capabilit= y to ensure that a given flow continues to go to the same next
>> = SFF even when SFF-Z3 is added to the mix.
>
> Precisely.
>= ;
>
>> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote:
>= ;>> Absolutely not. Service chains can be instantiated only in releva= nt SFFs
>> when they "arrive".
>>>
>> ...
= >

_______________________________________________
sfc mailing = list
sfc@ietf.org
https://www.ietf.org/mailman/listinf= o/sfc
------=_Part_3089_34255259.1405094963575-- From nobody Fri Jul 11 09:10: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 BECC91B2B4C for ; Fri, 11 Jul 2014 09:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 JlsJMkpzsCcX for ; Fri, 11 Jul 2014 09:09:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5119F1B2BA2 for ; Fri, 11 Jul 2014 09:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=121203; q=dns/txt; s=iport; t=1405095004; x=1406304604; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Nc6ms+VbFVwEs6rk5rcZRMx7OIOWziO9pZaaNrMV61o=; b=JJ2QBDOKd74MMpZhyylGIGoIqkGV/c6c6UMFTiNXXYnMmWrnFAU8B9jS Ag1ZGHOolsT4tp6tltkJJ0S5HbpisiiapP9GyDX3NM/hB2KV8P2MLt/WH zXsM+zviDJE4zzRPfYbxHTsp0o41jtntM8ypGV3ThoxvYvKLDUn6aKzjS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADULwFOtJV2S/2dsb2JhbABPCoJHR1JagnGsCZF4AQmHQgEZchZ1hAMBAQEEAQEBFwEIQgkCFQQCAQgRAQIBAQEBIAEGAwICAiULFAMGCAIEARIbiBMDEQ2tSph+EwSNHYFQBSAMEAoHBgoBAgSCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208,217";a="339383512" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2014 16:10:01 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BG9chi009107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:09:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:09:37 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" , "jmh@joelhalpern.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAAZ06A//++iQA= Date: Fri, 11 Jul 2014 16:09:37 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE583F72D4F1jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SOKPG8ErSwQoyAQD5Fti29tCQcY Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:10:07 -0000 --_000_CFE583F72D4F1jguicharciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgTWlrZTsgSSB0aGluayBteSB3aWRlciBwb2ludCB3YXMgdGhhdCBpbiBvcmRlciB0byBz YXRpc2Z5IHRoaXMgdHlwZSBvZiBkaXN0cmlidXRpb24geW91IHdpbGwgbmVlZCB0byBrZWVwIGEg bG90IG9mIHN0YXRlIGF0IGV2ZXJ5IFNGRiBpbiB0aGUgU0ZDIGRvbWFpbiBzbyBhcyB0byBhdm9p ZCBzaXR1YXRpb25zIHdoZXJlIHRyYWZmaWMgaXMgZm9yd2FyZGVkIGZyb20gb25lIFNGRiB0byBh bm90aGVyIHRoYXQgZG9lcyBub3QgaGF2ZSB0aGUgcmVxdWlyZWQgc3RhdGUuDQoNCkZyb206ICJt aWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJpYW5jQGFv bC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4NCkRhdGU6IEZyaWRheSwgSnVseSAxMSwg MjAxNCBhdCAxMjowMiBQTQ0KVG86IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFA YXR0LmNvbT4iIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgImptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxw ZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LCAiUm9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4iIDxS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KaGVoLiAgd2VsbCwgaWYgaXQg ZGlkIG5vdCwgdGhlbiB5b3Ugc2hvdWxkIG5vdCBkbyBpdCBsaWtlIHRoYXQuICBlLmcuIEknbSBu b3QgZ29pbmcgdG8gY29uZmlndXJlIHJlYWwgc2VydmVycyBvbiBhIHNlcnZlciBsb2FkIGJhbGFu Y2VyIHRoYXQgYXJlIG5vdCByZWFjaGFibGUuICBlLmcuIEknbSBub3QgZ29pbmcgdG8gY29uZmln dXJlIG15IEJHUCB0byBhbm5vdW5jZSBwcmVmaXhlcyBmb3Igd2hpY2ggSSBjYW5ub3QgcHJvdmlk ZSBjb25uZWN0aXZpdHkuICBJZiB5b3UgZG8gdGhpbmdzIGxpa2UgdGhhdCwgdGhlbiB5b3UgYXJl IGRvaW5nIGl0IHdyb25nLg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48 amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElF UkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PixKb2Vs IE0uIEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwg Oy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaWYNCnlvdSBhbGxvdyBhbiBTRkYg dG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYgaXQgd2lsbCB1c2UgZm9y DQphIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVu IHlvdSBiZXR0ZXIgbWFrZQ0Kc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vz c2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvIHJlYWNoIHRoZQ0KbmV4dC1uZXh0LVNGIGZvciB0aGUg Y2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0cm91YmxlLg0KDQpPbiA3LzExLzE0 LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1u MTkyMUBhdHQuY29tPj4gd3JvdGU6DQoNCj5BYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMg Y2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluIHJlbGV2YW50IFNGRnMNCj53aGVuIHRoZXkgImFy cml2ZSIuDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQN Cj4+KGpndWljaGFyKQ0KPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4+ IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2Ug dGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29kIHRoZQ0KPj5wcm9wb3NhbA0KPj4gY29ycmVj dGx5IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlIFNG IHdpdGhpbg0KPj50aGUNCj4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYg YXMgdGhlcmUgaXMgbm8gd2F5IHRvIGtub3cgYQ0KPj5wcmlvcmkNCj4+IHdoaWNoIFNGQ8K5cyBh IGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4gcG9pbnQgaW4gdGlt ZS4NCj4+DQo+PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCj4+DQo+ PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJv YmxlbSB3aXRoIHRoZQ0KPj55b3VyDQo+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAo QW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QgdW5kZXJzdGFuZA0KPj4gPml0LikNCj4+ID4N Cj4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2Vy IGZvciB0aGUgbmV4dA0KPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0IChub3Qg dGhlIG9uZSBpdCBkZWxpdmVycyB0byksIGluIGV2ZXJ5DQo+PiA+c2VydmljZSBjaGFpbiB0aGF0 IGdvZXMgdGhyb3VnaCBpdC4NCj4+ID4NCj4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3 b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zIHRoYXQNCj4+ZXZlcnkNCj4+ID5TRkYg d291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2Fk IGJhbGFuY2VyLg0KPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNl bnNpdGl2ZSwgYW5kIC8gb3Igc3RhdGVmdWwuDQo+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0 dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLCBmbG93DQo+PiA+c2Vuc2l0aXZl LCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbiBhY2NlcHRhYmxl DQo+PiA+aW1wb3NpdGlvbi4NCj4+ID4NCj4+ID5Zb3VycywNCj4+ID5Kb2VsDQo+PiA+DQo+PiA+ T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+IFBhcnQg b2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcyB3b3Jr DQo+PnNlbnNpYmx5DQo+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJ IGV4cGVjdCB0aGF0IHRoZSBzZXJ2aWNlDQo+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUg cHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsIHdpbGwgYmUNCj4+ID4+IG9yY2hlc3RyYXRl ZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8gYmUNCj4+ZHJp dmVuIGJ5DQo+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMs IGFuZCBlbmFibGUgc2VsZi1zZWxlY3Rpb24NCj4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNl cnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kgZHJpdmUuDQo+PiA+Pg0KPj4gPj4gSSBj YW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRpZWN0dXJlIGRy aXZlbiBieQ0KPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2Vydmlj ZSBwYXRocy4gSXQgaXMgaGFyZGVyIHRvDQo+PnNlZQ0KPj4gPj4gaG93IHRvIG1ha2UgaXQgd29y ayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmUNCj4+IGR5bmFtaWNpdHkN Cj4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4NCj4+ID4+IEhhdmluZyBzYWlk IHRoYXQsIG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJIGRlc2NyaWJlZCBpcyBvdXRzaWRlIG9m DQo+PnRoZQ0KPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21l dGhpbmcgd2UgYXJlIHRhc2tlZCB0bw0KPj5hZ3JlZQ0KPj4gPj5vbi4NCj4+ID4+IFNvIEkgZG8g bm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYSBjZXJ0YWluIHdh eS4NCj4+aXQNCj4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHBy ZWZlcmVuY2VzLg0KPj4gPj4NCj4+ID4+IFlvdXJzLA0KPj4gPj4gSm9lbA0KPj4gPj4NCj4+ID4+ IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ID4+Pj4gRm9yIG1lLCB0 aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQNCj4+ bmVlZHMNCj4+ID4+Pj50bw0KPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50 YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4gYWNyb3NzIGRhdGENCj4+ID4+Pj4gY2VudGVycyB3aXRo aW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQgY29tcGxleA0K Pj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVt cyBsaWtlIGEgZGlmZmljdWx0DQo+PiA+Pj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4g Pj4+DQo+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRl ZCB0aGFuIGR5bmFtaWMgcm91dGluZywNCj4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBv cmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZiB3aGljaCBhcmUNCj4+YmlnZ2VyDQo+PiA+Pj4g cHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVudGVk Pw0KPj4gPj4+DQo+PiA+Pj4gSXQgYWxzbyBzZWVtcyB0aGF0IGlmIGl0IHJlYWxseSBpcyBtb3Jl IGNvbXBsaWNhdGVkLCB0aGF0IGlzIGEgZ29vZA0KPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28g Y29tcGxpY2F0ZWQuDQo+PiA+Pj4NCj4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+PiBTZW50OiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFs cGVybiBEaXJlY3Q7IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47 IElhbiBTbWl0aDsNCj4+ID4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ ID4+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4+ID4+Pg0KPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4g QW5kIG9uZSB0aGF0IEkgd291bGQgcHJlZmVyIHdlDQo+PiA+Pj5hY3R1YWxseQ0KPj4gPj4+IGRl Y2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZSBpbXBsZW1lbnRh dGlvbnMuDQo+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhl IGNvbnRyb2wgcmVxdWlyZW1lbnRzIGFuZA0KPj4gdGhlDQo+PiA+Pj4gZnVuY3Rpb25hbGl0eSBv ZiBTRkZzLg0KPj4gPj4+DQo+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9u IGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQgbmVlZHMNCj4+IHRvDQo+PiA+Pj4gYmUgd2lk ZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuIGFjcm9zcyBk YXRhDQo+PiA+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxh cmdlIGVub3VnaCBhbmQgY29tcGxleA0KPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQg dGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYSBkaWZmaWN1bHQNCj4+ID4+PiBhcmNoaXRl Y3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+Pg0KPj4gPj4+IFlvdXJzLA0KPj4gPj4+IEpvZWwNCj4+ ID4+Pg0KPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+PiA+Pj4NCj4+ID4+PiBP biA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4+PiBUaGlzIGlzIHRo ZSBjcnV4IG9mIG15IGlzc3VlLiAgIElzIHRoZSBlbmQgdG8gZW5kIHNlbGVjdGlvbiBvZg0KPj4g Pj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBi eSB0aGUNCj4+Y2xhc3NpZmllcikNCj4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0 aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5IHRoZQ0KPj5TRkZzKT8NCj4+ID4+Pj4gU3Vj aCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4gICBBbmQg c3VyZWx5LA0KPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCBy ZWxlZ2F0ZWQgdG8NCj4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ID4+Pj4NCj4+ID4+Pj4g TXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4gdGhv dWdoIGENCj4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMg YW5kIHBlcmhhcHMgbG9jYWwNCj4+c2VsZWN0aW9uDQo+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWly ZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLiAgIFRoaXMNCj4+ID4+Pj4g YXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLiAg ICBNeQ0KPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJp bWFyaWx5IGRyaXZlbiBieQ0KPj5pbmNyZWFzZWQNCj4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRo ZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gICBXaXRoIGEgZ2xvYmFsIHBhdGgNCj4+aWQNCj4+ ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRp bmcgdG8gYWx0ZXIgdGhlDQo+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFu ZCBldmVyeSBhZmZlY3RlZCBlbmQtdG8tZW5kIHBhdGguDQo+PiA+Pj4+DQo+PiA+Pj4+IFJvbg0K Pj4gPj4+Pg0KPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IEZyb206IHNmYw0KPj4gPj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+ID4+Pj4g W2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDY6MTUgUE0NCj4+ID4+Pj4gVG86 IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IEkuU21pdGhARjUu Y29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPiBTdWJqZWN0OiBSZToNCj4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4NCj4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0 dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0bw0KPj5pbmZsdWVuY2UNCj4+ID4+ Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhl IGV4aXQgZnJvbQ0KPj4gPj4+PiBTRjEuDQo+PiA+Pj4+DQo+PiA+Pj4+IFBhcnQgb2YgdGhlIGdv YWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBsb2dpY2FsbHkNCj4+ID4+Pj4g c2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkg Y2hvb3NlIHRvDQo+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0K Pj4gPj4+Pg0KPj4gPj4+PiBZb3VycywgSm9lbA0KPj4gPj4+Pg0KPj4gPj4+PiBPbiA3LzEwLzE0 LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IHdy b3RlOg0KPj4gPj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhh dCBzdWdnZXN0cyBhbnkgc29ydCBvZg0KPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMg c2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUgcGF0aCAoYWxsDQo+PiA+Pj4+PiBTRklz KSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlIHRoaXMgbWVh bnMNCj4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3Np ZmllciBjaG9vc2VzIGEgU0YNCj4+Q2hhaW4NCj4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhl IGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSwgdGhlDQo+PiA+Pj4+PiBsYW5ndWFn ZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlIFNGSShuKSBp cw0KPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8g dGhlIGRyYWZ0LCB0aGlzDQo+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICJi cmFuY2hpbmciIHRvIGEgbmV3IFNGUCBhcyBvcHBvc2VkDQo+PiB0bw0KPj4gPj4+Pj4gY2hvb3Np bmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YgdGhlDQo+ PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4g ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMg aXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVjZXNzYXJ5IHRvDQo+PiA+ Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1 c2VkLCBhbmQgdG8NCj4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRo YXQgU0ZDIHVzaW5nIFNGJ3MgbmV0d29yaw0KPj4gPj4+Pj4+IGxvY2F0b3IuIFRodXMsIGluc3Rh bnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluIHRoZSBjcmVhdGlvbg0KPj4gPj4+Pj4+IG9m IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvciBmb3J3YXJkaW5n DQo+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBT RlAgaXMgdGhlDQo+PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+ PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNz aWZpY2F0aW9uIChvciBub24taW5pdGlhbA0KPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3 ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0 aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4+Pj4+IGNsYXNz aWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlIGZ1bmN0aW9uLg0K Pj4gPj4+Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9m IGEgbmV3IFNGUCwgYW4NCj4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRh dGEsIG9yIGJvdGguIFRoaXMgaXMgcmVmZXJyZWQgdG8NCj4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5n Ii4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+Pg0KPj4+Pj4+Pi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4+Pj4+LS0NCj4+ID4+Pj4+LS0NCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4g Pj4+Pj4NCj4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPG1haWx0bzoqSS5TbWl0aEBGNS5j b20+PEkuU21pdGhARjUuY29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+DQo+PiA+Pj4+PiAqVG86 ICpKb2VsIEhhbHBlcm4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpq bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4+LEpvZWwgTS4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pkhh bHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1 YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0Bz Y2UuDQo+PiBjYXJsZXRvbi4NCj4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiA+Pj4+Pg0KPj4g Pj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0K Pj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFt IGRpc2FncmVlaW5nLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBt ZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZCB0aGF0IGlzIHdoYXQNCj4+ID4+Pj4+IDE2IG1p bGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzIHByZWNvbmNl aXZlZA0KPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBi dXJkZW5lZCB3aXRoIHRoYXQNCj4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+PiA+Pj4+Pg0KPj4g Pj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZiBh c3BpcmF0aW9uIHRvDQo+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUg bGlmZXNwYW4gb2YgdGhlIGFyY2hpdGVjdHVyZSAtDQo+PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0 byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbiBhcmJpdHJhcnkNCj4+ID4+ Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNu J3QNCj4+aW50ZW50aW9uYWwNCj4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVj aXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nIGltcGFjdHMNCj4+ID4+Pj4+IHJlZ2FyZGluZyBzY2Fs ZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwgYWRkcmVzcw0KPj4gPj4+Pj4g c3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0K Pj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+Pj4+DQo+PiA+ Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IEZyb206IEpv ZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dIFNlbnQ6DQo+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAx MCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS4gSGFscGVybjsNCj4+ID4+Pj4+ IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl DQo+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+DQo+ PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGlu IHRoaXMgcmVnYXJkLiBJDQo+PmFtDQo+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFy Y2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24gcHJvaGliaXQNCj4+ID4+Pj4+IGRlcGxveW1lbnRz IGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0byBIdWFuZydzDQo+PiA+ Pj4+PiByZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBh cmUgcmVxdWlyZWQNCj4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ID4+Pj4+ DQo+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8g cHJvaGliaXQgc3VjaA0KPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBp ZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueQ0KPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9m IHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvIHRoaW5rIHRoYXQNCj4+dGhleQ0KPj4g Pj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBCdXQgdGhl IGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0byBrbm93IHdo YXQNCj4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+ IFlvdXJzLCBKb2VsDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFu IFNtaXRoIHdyb3RlOg0KPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+ PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2Yg bWlsbGlvbnMNCj4+ID4+Pj4+PiBvZg0KPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3Ro IGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRv ZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbiB0aGUNCj4+ID4+Pj4+IENs b3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3UgYXJlIG9u bHkNCj4+IGdvaW5nDQo+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBj aGFpbnMgd2l0aCBlcXVhbGx5IHNtYWxsIG51bWJlcnMNCj4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2 aWNlIHBhdGhzPw0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlr ZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUgdGhhbiA2NEsiDQo+PiA+Pj4+Pj4gZm9yDQo+ PiA+Pj4+PiBjb21mb3J0Lg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPj4gPj4+Pj4+IFtz ZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhh bGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+PiA+Pj4+PiBbam1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgNDo0NiBQTSBUbzogaHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0Bz Y2UuY2FybGV0b24uY2E+Ow0KPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0K Pj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVh biB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZSBhcmNodGlldHVyZQ0KPj4gPj4+ Pj4+IHBhcnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mIHRo ZWlyDQo+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJl IHN1Y2ggYWJzdXJkIHVzZSBvZg0KPj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2Fu IG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZQ0KPj4gPj4+Pj4+IGFyY2hpdGVjdHVyYWwgd29y ZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmUgZG9lcyBwZXJtaXQNCj4+ID4+Pj4+ PiBzdWNoIGFidXNlLg0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15 IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUgcGVybWl0cw0KPj4gPj4+Pj4+IHNvbWV0aGlu ZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkgdGhlIHdvcmsu DQo+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBZb3VycywgSm9lbA0K Pj4gPj4+Pj4+DQo+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFu ZyB3cm90ZToNCj4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBj aGFpbnMsIGl0IHdpbGwgbWVhbg0KPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlz IGxhcmdlciB0aGFuIHRoZSByb3V0aW5nIHRhYmxlIG9mIGENCj4+ID4+Pj4+Pj4gY29yZSByb3V0 ZXIuDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+ IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+Pj4+ Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20g MQ0KPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdv dWxkIGhvcGUgdGhhdA0KPj4gPj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhl IGNvbXBsZXhpdGllcyBpZiB0aGV5IGNob29zZSB0bw0KPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVz ZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQgcHJvdmlzaW9uDQo+PiA+Pj4+ Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gWW91 cnMsIEpvZWwNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBO QVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4+ID4+Pj4+Pj4+ Pg0KPj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBm b3IgYSA0IGhvcCBzZXJ2aWNlDQo+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMg YXQgZWFjaCBob3A/DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4gPj4+Pj4+ Pj4+DQo+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSAqT24gQmVoYWxmIE9mDQo+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoq IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDM6MDMNCj4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBMdWN5 IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT47DQo+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPjsNCj4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLA0KPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEx1 Y3ksDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ug c2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQN Cj4+ID4+Pj4+IG1ha2UNCj4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBp ZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvIGRlcml2ZQ0KPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQg Zm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+ Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8g c2ltcGx5DQo+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgp IHRoYXQgcGFja2V0cyBtdXN0DQo+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBh dGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBw ZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uIHRoaXMNCj4+ID4+Pj4+Pj4+PiB0aHJlYWQg Y2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGggaWRlbnRpZmllcg0KPj4gPj4+ Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBj YW4gcmVzdWx0DQo+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0 ZWQpIHRyYW5zcG9ydCBuZXh0DQo+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gPj4+Pj4+Pj4+DQo+ PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAy MDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3 ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4gPG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4+DQo+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+ Pg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxk IG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mIHRoZQ0KPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+Pj4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAqRnJvbToqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPj4gPj4+Pj4+Pj4+IE9m Km1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOk9mKm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+DQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPiAqU2VudDoqVGh1cnNkYXksDQo+PiBKdWx5DQo+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQg MjowNiBBTSAqVG86Km1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20+ DQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJu LmNvbQ0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYu b3JnDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsDQo+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0 aA0KPj4gPj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZp ZXIgdG8gZGVyaXZlDQo+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4gPj4+Pj4+ Pj4+DQo+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxs IGtub3dsZWRnZSBvZiBldmVyeQ0KPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4+Pj4+Pj4+ IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3QNCj4+ ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmllZA0KPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2 YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBT RkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZg0KPj4gPj4+ Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+Pj4+PiB0aGF0IHdpbGwNCj4+ID4+Pj4+Pj4+PiBiZSBw cmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lIHJlcXVpcmVkIHRvDQo+ PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRp b24gaXMgdXNlZCB0bw0KPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+Pj4+IGFj dGlvbnMNCj4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+ PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+ Pj4+PiBNZWQNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9s LmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+DQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbT4gKkVudm95w6kgOiptZXJjcmVkaSA5IGp1aWxsZXQNCj4+ID4+Pj4+ Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9l bGhhbHBlcm4uY29tPg0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47 c2ZjQGlldGYub3JnDQo+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6 KlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywNCj4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVl c3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTRiBDaGFpbg0KPj4gPj4+Pj4+Pj4+IGFu ZCBTRg0KPj4gPj4+Pj4gUGF0aD8NCj4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcg dGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzIGNsZWFyIHRvDQo+PiA+Pj4+PiB0aG9zZSBub3QN Cj4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVy eW9uZSBhZ3JlZXMgb24NCj4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+Pj4+Pj4+Pg0K Pj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBp cyB3aGV0aGVyIGl0IGlzDQo+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRv IHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRA0KPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMg SGVhZGVyDQo+PiA+Pj4+PiBzaG91bGQNCj4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFp biBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQgc2ltcGx5DQo+PiA+Pj4+Pj4+Pj4gaW50 ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzIHRvDQo+ PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBv biBjaGFpbiBvcg0KPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3IN Cj4+ID4+Pj4+IHBhdGggdG8NCj4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250 cm9sLXBsYW5lLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRlciAoYW1i aWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2ZQ0KPj4gPj4+Pj4+Pj4+IHJlcXVpcmUg dGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZSBvbmUNCj4+ID4+Pj4+ Pj4+PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRv cnMgb25seQ0KPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBw b3J0aW5nIFNGQy4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pg0KPj4NCj4+ Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pi0tDQo+PiA+Pj4+Pi0tDQo+PiA+Pj4+Pg0KPj4gPj4+ Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFs cGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4gPj4+Pj4+Pj4+ICpUbzoq c2ZjQGlldGYub3JnPG1haWx0bzoqc2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRm Lm9yZz4+ICpTZW50OipUdWVzZGF5LCBKdWx5DQo+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVj dDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gPj4+Pj4+Pj4+IEJh bGFuY2Vycw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRv IGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkgYW5zd2VyIGENCj4+ID4+Pj4+Pj4+PiBudW1iZXIg b2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUgcHJvcG9zZWQNCj4+ID4+ Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdv cmtpbmcNCj4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2ls bCB3b3JrIHRvIGltcHJvdmUgdGhlDQo+PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJlYWRl cnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbiB0aGUgV0cNCj4+ID4+Pj4+Pj4+PiBkaXNj dXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+PiA+Pj4+PiB3b3JraW5nDQo+ PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEJ1 dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15IHBlcnNvbmFsDQo+ PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0KPj4gPj4+Pj4+Pj4+DQo+ PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1p bmQgdGhhdCB3aGF0DQo+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBs YW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlIG5vdA0KPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8g ZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+ID4+Pj4+Pj4+PiBzb2x1 dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3MNCj4+ID4+Pj4+ Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsIHZpcnR1 YWwNCj4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBv dGhlciBhc3BlY3RzLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhl cmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZCB0bw0KPj4gPj4+Pj4+Pj4+IGV4 aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGggYWJvdmUN Cj4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4gPj4+ Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZSBk b2luZy4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2 aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwgYXMgSQ0KPj4gPj4+Pj4+Pj4+IHVuZGVyc3RhbmQN Cj4+ID4+Pj4+IHRoZW0sDQo+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9h ZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdCBsZWFzdA0KPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZl cmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsDQo+PiA+Pj4+Pj4+Pj4g aW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUgbW9yZS4N Cj4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQg YWxsIG9mIHRoZXNlLA0KPj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBw YXJ0aWN1bGFyIGtpbmQNCj4+ID4+Pj4+IGJlIHVzZWQNCj4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29s dXRpb24uDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBh IHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZCB1c2VyLg0KPj4gPj4+Pj4+Pj4+IFRoaXMgaXMg YSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyIHBhY2tldHMsIGFuZA0KPj4gPj4+ Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+PiA+Pj4+PiBtYXJrcw0KPj4gPj4+Pj4+Pj4+IHRo ZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UgaW5zdGFuY2UN Cj4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1w b3J0YW50IHNlcnZpY2UNCj4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1 ZGUgaW4gc2VydmljZSBjaGFpbmluZy4gSXQncw0KPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBh ZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlIGNoYWluaW5nIGlzDQo+PiA+Pj4+Pj4+ Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlIGFyY2h0aWVjdHVy ZS4NCj4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlz IHNpbXBseSBhDQo+PiA+Pj4+PiBzZXJ2aWNlDQo+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2gg bWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+ Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lIGNh biBoYXZlDQo+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4+Pj4+Pj4+ IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludCBv Zg0KPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+Pj4+IGZvciBhDQo+PiA+Pj4+Pj4+Pj4gc3Bl Y2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZCBieSBhDQo+ PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBt YWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nIG9uZSBvcg0KPj4gPj4+Pj4+Pj4+IHNldmVyYWwg bG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPj4gPj4+Pj4+Pj4+ IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcw0KPj4g Pj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lIG1l Y2hhbmlzbXMuIEl0DQo+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0 byB2YXJpb3VzIGNvbnRyb2wgbWVjaGFuaXNtcywNCj4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3Nl IHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBhbmQgdm0NCj4+ID4+Pj4+Pj4+ PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgcGVybWl0dGluZyB0 aGlzDQo+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0 aGF0IG91ciB0ZXJtaW5vbG9neQ0KPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+ID4+Pj4+ IHJlYWRlcnMgdG8NCj4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+ PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFu Y2luZyBkb25lIGJ5IHNlbGVjdGluZw0KPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhl IHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QgdHJhZmZpYw0KPj4gPj4+Pj4+Pj4+IHRvIGRp ZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmUgdGhhdCBhDQo+PiA+ Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2Ug aW4gdGhlDQo+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+ IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSSB0 ZW5kDQo+PiA+Pj4+Pj4+Pj4gdG8NCj4+ID4+Pj4+IHJlZmVyIHRvDQo+PiA+Pj4+Pj4+Pj4gdGhl IGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZSBjaGFpbmluZw0K Pj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2Ug Y2x1c3RlciBpcyBhDQo+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5v dCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLCB0aGUNCj4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBl IDMgbG9hZCBiYWxhbmNpbmcNCj4+ID4+Pj4+IGlzIHRvDQo+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRp ZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyDQo+PiA+Pj4+ Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMg aW4gdGhlDQo+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+ IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+ ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4g aXMgYSBzZXF1ZW5jZQ0KPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFw cGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy4NCj4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFs ZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIHRyYWZmaWMgaXMNCj4+ID4+Pj4+Pj4+ PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQgZmlyZXdhbGwN Cj4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkg dG8gdGhlIGNhY2hlDQo+PiA+Pj4+PiB3aXRob3V0DQo+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55 IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gVGhh dCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQQ0KPj4g Pj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9m IGxvY2F0aW9ucw0KPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMg d2lsbCBiZSBzaW5ndWxhciBvcg0KPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0 aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleSBtYXkgYmUNCj4+ID4+Pj4+Pj4+PiBhZGRyZXNz ZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzIHBvcnRzIG9uDQo+PiA+ Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBs b2NhdGlvbnMNCj4+ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5p bmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZQ0KPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3Jr IG9mIHRoZSBTRkMgZ3JvdXAsIHdlDQo+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+ID4+Pj4+ Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBz ZXJ2aWNlDQo+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4g QW5kIHdlIG5lZWQgdG8gdGFsaw0KPj4gPj4+Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBw YXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZQ0KPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+ Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQg ImJ1dCB0aGUgd2hvbGUgcGF0aCBtYXkNCj4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhl IGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMgd2l0aA0KPj4gPj4+Pj4+Pj4+IHRoYXQg aXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSBvbiBsb2FkDQo+ PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCBi ZWhhdmlvcnMgd2hpY2gNCj4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nIG1lY2hhbmlzbXMgKGluIG11Y2gNCj4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkg dGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KPj4gPj4+Pj4+Pj4+IGludmlz aWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2UNCj4+ ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+Pj4+PiB0aGF0DQo+PiA+Pj4+Pj4+Pj4gcmVjbGFzc2lm aWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbiBuZWNlc3NhcnkuDQo+PiA+Pj4+ Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0K Pj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRp b24gcG9pbnQuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhl bHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIElmIGl0DQo+PiA+Pj4+Pj4+Pj4gZG9lcywg YW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZyBncm91cCwNCj4+ ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZCB0bw0KPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBk aXNhZ3JlZSB3aXRoIHRoZSBpbnRlbnQsDQo+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNv dXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcgZ3JvdXANCj4+ID4+Pj4+Pj4+PiBhZ3Jl ZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUgd2hhdCB0bw0K Pj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gWW91cnMs IEpvZWwNCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gbWFpbGluZw0KPj4gPj4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBzZmMNCj4+IG1haWxpbmcNCj4+ID4+Pj4+Pj4+PiBsaXN0IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiBtYWlsaW5nDQo+PiA+Pj4+Pj4+PiBs aXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ PiBtYWlsaW5nDQo+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+Pj4+ DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBzZmMgbWFpbGluZw0KPj4gbGlzdA0KPj4gPj4+Pj4+IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjIG1haWxpbmcNCj4+IGxpc3QNCj4+ID4+ Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+Pg0KPj4gPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGluZw0KPj4gbGlzdA0KPj4g Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+Pj4NCj4+ID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjIG1haWxpbmcNCj4+IGxpc3QNCj4+ ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+Pj4+DQo+PiA+Pj4NCj4+ID4+DQo+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2Zj IG1haWxpbmcgbGlzdA0KPj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4NCj4+ ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMg bWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo= --_000_CFE583F72D4F1jguicharciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BZ3JlZSBNaWtl OyBJIHRoaW5rIG15IHdpZGVyIHBvaW50IHdhcyB0aGF0IGluIG9yZGVyIHRvIHNhdGlzZnkgdGhp cyB0eXBlIG9mIGRpc3RyaWJ1dGlvbiB5b3Ugd2lsbCBuZWVkIHRvIGtlZXAgYSBsb3Qgb2Ygc3Rh dGUgYXQgZXZlcnkgU0ZGIGluIHRoZSBTRkMgZG9tYWluIHNvIGFzIHRvIGF2b2lkIHNpdHVhdGlv bnMgd2hlcmUgdHJhZmZpYyBpcyBmb3J3YXJkZWQgZnJvbSBvbmUgU0ZGIHRvIGFub3RoZXIgdGhh dCBkb2VzIG5vdCBoYXZlDQogdGhlIHJlcXVpcmVkIHN0YXRlLiZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEp1bHkgMTEsIDIwMTQgYXQg MTI6MDIgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5K aW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWlj aGFyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5j b20iPm1uMTkyMUBhdHQuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBh dHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20iPlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiIHNpemU9IjIiPg0KPGRpdj5o ZWguICZuYnNwO3dlbGwsIGlmIGl0IGRpZCBub3QsIHRoZW4geW91IHNob3VsZCBub3QgZG8gaXQg bGlrZSB0aGF0LiAmbmJzcDtlLmcuIEknbSBub3QgZ29pbmcgdG8gY29uZmlndXJlIHJlYWwgc2Vy dmVycyBvbiBhIHNlcnZlciBsb2FkIGJhbGFuY2VyIHRoYXQgYXJlIG5vdCByZWFjaGFibGUuICZu YnNwO2UuZy4gSSdtIG5vdCBnb2luZyB0byBjb25maWd1cmUgbXkgQkdQIHRvIGFubm91bmNlIHBy ZWZpeGVzIGZvciB3aGljaCBJIGNhbm5vdCBwcm92aWRlIGNvbm5lY3Rpdml0eS4NCiAmbmJzcDtJ ZiB5b3UgZG8gdGhpbmdzIGxpa2UgdGhhdCwgdGhlbiB5b3UgYXJlIGRvaW5nIGl0IHdyb25nLjxi cj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9mb250Pg0KPGRpdiBjbGFzcz0iIj48L2Rpdj4NCjxi cj4NCjxicj4NCjxicj4NCjxociBzdHlsZT0iYm9yZGVyOjA7aGVpZ2h0OjFweDtjb2xvcjojOTk5 O2JhY2tncm91bmQtY29sb3I6Izk5OTt3aWR0aDoxMDAlO21hcmdpbjowIDAgOXB4IDA7cGFkZGlu ZzowOyI+DQo8Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+ amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+TkFQSUVSQUxB LCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5j b208L2E+Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxSb24gUGFya2VyJmx0OzxhIGhy ZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzPGJyPg0KPGJyPg0KPHRpdGxlPjwvdGl0bGU+DQpUaGVuIEkgbWlzdW5kZXJz dGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lIHRoYXQgaWY8 YnI+DQp5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1v dGUgU0ZGIGl0IHdpbGwgdXNlIGZvcjxicj4NCmEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4 dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91IGJldHRlciBtYWtlPGJyPg0Kc3VyZSB0aGF0 IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvIHJl YWNoIHRoZTxicj4NCm5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3Ug YXJlIGluIGRlZXAgdHJvdWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0LCA5OjQ4IEFNLCAmcXVv dDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0 LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7QWJzb2x1 dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbiByZWxl dmFudCBTRkZzPGJyPg0KJmd0O3doZW4gdGhleSAmcXVvdDthcnJpdmUmcXVvdDsuPGJyPg0KJmd0 Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsg PGJyPg0KPGJyIGNsYXNzPSIiPg0KRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBKaW0gR3VpY2hhcmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyhqZ3VpY2hhcik8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBX ZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rv b2QgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtwcm9wb3NhbDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5 IHNpbmdsZSBTRiB3aXRoaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUg aXMgbm8gd2F5IHRvIGtub3cgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7cHJpb3JpPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2 aWNlIGF0IGFueSBnaXZlbiBwb2ludCBpbiB0aW1lLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAmcXVvdDtKb2VsIE0u IEhhbHBlcm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5q bWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0O1JvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSBy ZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0gd2l0aCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O3lvdXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7cHJvcG9zYWwgYXMgSSB1bmRlcnN0 YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QgdW5kZXJzdGFuZDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDtpdC4pPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDtUaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFz IHRoZSBsb2FkIGJhbGFuY2VyIGZvciB0aGUgbmV4dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDtzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZl cnMgdG8pLCBpbiBldmVyeTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDtzZXJ2aWNlIGNoYWlu IHRoYXQgZ29lcyB0aHJvdWdoIGl0LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRo IGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucyB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtldmVy eTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDtTRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGws IGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkIGJhbGFuY2VyLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDtJIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5z aXRpdmUsIGFuZCAvIG9yIHN0YXRlZnVsLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDtCdXQg aGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGws IGZsb3c8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9h ZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbiBhY2NlcHRhYmxlPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0O2ltcG9zaXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDtZb3Vycyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Sm9lbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZTo8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJ IGFtIHRyeWluZyB0byBtYWtlIHRoaXMgd29yazxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7c2Vuc2li bHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbiBhIG1vcmUgb3JjaGVzdHJhdGVk IGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZSBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYg Y2FwYWJpbGl0aWVzLCB3aWxsIGJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgb3Jj aGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucyB0byBi ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ZHJpdmVuIGJ5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQg ZW5hYmxlIHNlbGYtc2VsZWN0aW9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgZnJv bSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeSBkcml2 ZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFy Y2h0aWVjdHVyZSBkcml2ZW4gYnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbml0 aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBpcyBoYXJk ZXIgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3NlZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBh bGxvdyBtb3JlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgZHluYW1pY2l0eTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgSGF2aW5n IHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzIG91dHNp ZGUgb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5nIHdl IGFyZSB0YXNrZWQgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2FncmVlPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDtvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTbyBJ IGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGEgY2VydGFp biB3YXkuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtpdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2Vz LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgWW91cnMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgSm9lbDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9u IGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzIHRoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O25lZWRz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50 YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4gYWNyb3NzIGRhdGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3Bl LCBpcyBsYXJnZSBlbm91Z2ggYW5kIGNvbXBsZXg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZG IHNlZW1zIGxpa2UgYSBkaWZmaWN1bHQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBJJ20gY3VyaW91 cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gZHluYW1pYyByb3V0aW5n LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBoeXBlci1zY2FsZSBkYXRhIGNl bnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZiB3aGljaCBhcmU8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0O2JpZ2dlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm9i bGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21w bGljYXRlZCwgdGhhdCBpcyBhIGdvb2Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQ TTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzogUm9uIFBhcmtlcjsgSm9l bCBIYWxwZXJuIERpcmVjdDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtl YmlhbmNAYW9sLmNvbTwvYT47IElhbiBTbWl0aDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhp cyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZCBwcmVmZXIg d2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthY3R1YWxseTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBh bGxvdyBhbGwgcG9zc2libGUgaW1wbGVtZW50YXRpb25zLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUg Y29udHJvbCByZXF1aXJlbWVudHMgYW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgdGhlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZp Y2UgaW5zdGFuY2VzIHRoYXQgbmVlZHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB0bzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1h aW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4gYWNyb3NzIGRhdGE8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUs IGlzIGxhcmdlIGVub3VnaCBhbmQgY29tcGxleDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVt cyBsaWtlIGEgZGlmZmljdWx0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGFy Y2hpdGVjdHVyZSB0byByZWFsaXplLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSm9lbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBm YWlyIHF1ZXN0aW9uLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFy a2VyIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBp cyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gJm5ic3A7IElzIHRoZSBlbmQgdG8gZW5kIHNlbGVjdGlv biBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgKHRvcC1sZXZlbCkg aW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDtjbGFzc2lmaWVyKTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2Vx dWVudGx5IHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7U0ZGcyk/PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0 byByZWNsYXNzaWZpY2F0aW9uLiAmbmJzcDsgQW5kIHN1cmVseSw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQg bm90IHJlbGVnYXRlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg JnF1b3Q7aW1wbGVtZW50YXRpb24mcXVvdDsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTXkgb3du IHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4gdGhvdWdoIGE8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdyZWF0ZXIgYW1vdW50IG9m IGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzIGxvY2FsPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDtzZWxlY3Rpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRz LiAmbmJzcDsgVGhpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBw cm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLiAmbmJz cDsmbmJzcDsgTXk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJhdGlv bmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkgZHJpdmVuIGJ5PGJy IGNsYXNzPSIiPg0KJmd0OyZndDtpbmNyZWFzZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2gu ICZuYnNwOyBXaXRoIGEgZ2xvYmFsIHBhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2lkPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCwgY29uc2lkZXIgZmFp bHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0byBhbHRlciB0aGU8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNo IGFuZCBldmVyeSBhZmZlY3RlZCBlbmQtdG8tZW5kIHBhdGguPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgUm9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBGcm9tOiBzZmM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3Q8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVj dEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPl0gU2VudDog VGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNjoxNSBQTTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlr ZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPg0KSS5T bWl0aEBGNS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+IFN1YmplY3Q6IFJlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNl IG9mIFNGMSBuZWVkaW5nIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtpbmZsdWVuY2U8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3 b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0IHRoZSBleGl0IGZyb208YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNGMS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBQYXJ0 IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMgbG9naWNhbGx5 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0 IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cgdGhleSBjaG9vc2UgdG88YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbXBvc2UgdGhlbSBmb3IgJnF1b3Q7 c2VydmljZSZxdW90OyBkZWxpdmVyeS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9l bDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDY6MTAgUE0sIDxhIGhyZWY9Im1h aWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+IHdyb3RlOjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueXRo aW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55IHNvcnQgb2Y8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaW1pdC4gSG93ZXZlciwgaXQgZG9l cyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZSBwYXRoIChhbGw8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBT RkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlIHRoaXMgbWVhbnM8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5 YmUgdGhlIGNsYXNzaWZpZXIgY2hvb3NlcyBhIFNGPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtDaGFp bjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCB0aGUgTkYg b3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSwgdGhlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGFuZ3VhZ2UgZG9lcyBzZWVtIHRv IHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNGUCB3aGVyZSBTRkkobikgaXM8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXRlcm1pbmVkIGF0IHRoZSBTRkkobi0x KSBob3AuIEFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICZxdW90 O2JyYW5jaGluZyZxdW90OyB0byBhIG5ldyBTRlAgYXMgb3Bwb3NlZDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hv b3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YgdGhl PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV4dC1ob3Agb2Yg dGhlIGN1cnJlbnQgU0ZDLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3 b3JrIGl0IGlzIG5lY2Vzc2FyeSB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3 aWxsIGJlIHVzZWQsIGFuZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5n IFNGJ3MgbmV0d29yazxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0 aGUgY3JlYXRpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yIGZvcndh cmRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFj a2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24g b2YgdGhlIGRlZmluZWQgU0ZDLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9uIChvciBub24t aW5pdGlhbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBj bGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRp b24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBhPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNv LXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlIGZ1bmN0aW9uLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1bHQgaW4g dGhlIHNlbGVjdGlvbiBvZiBhIG5ldyBTRlAsIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwg b3IgYm90aC4gVGhpcyBpcyByZWZlcnJlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyAmcXVvdDticmFuY2hpbmcmcXVvdDsuPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpGcm9tOiA8YSBo cmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29tIj4qSS5TbWl0aEBGNS5jb208L2E+Jmx0OzxhIGhy ZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb208L2E+Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzogKkpvZWwgSGFscGVybiBE aXJlY3QmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LEpvZWwgTS48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7SGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2Uu Y2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT4mbHQ7aHVhbmdAc2NlLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IGNhcmxldG9uLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Y2EmZ3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3lt ZW50cyAoYW5kIHRoYXQgaXMgd2hhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hh aW5zIGlzIHByZWNvbmNlaXZlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQg d2l0aCB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJl Y29uY2VwdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGhhcyB0byBi ZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YgYXNwaXJhdGlvbiB0bzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMgYXBwcm9w cmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIC08YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdo YXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbiBhcmJpdHJhcnk8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBudW1iZXIgaXMgJnF1b3Q7dG9vIGZhciZxdW90 OywgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7aW50ZW50aW9uYWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZyBp bXBhY3RzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnYXJk aW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LCBhZGRyZXNzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BhY2UuLi4gYWxsIGtp bmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdp dGguPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZy b206IEpvZWwgSGFscGVybiBEaXJlY3QgWzxhIGhyZWY9Im1haWx0bzpqbWguZGlyZWN0QGpvZWxo YWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208L2E+XSBTZW50OjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLiBIYWxwZXJuOzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2Uu Y2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT47IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWFu LCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzIHJlZ2Fy ZC4gSTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YW08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0 aGUgc29sdXRpb24gcHJvaGliaXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3Rp bmcgdG8gSHVhbmcnczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZSBy ZXF1aXJlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXkg YnkgdGhlIGFyY2h0aWVjdHVyZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFzIEkg aGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdCBzdWNoPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmdzLiBXaGV0aGVy IHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24gbWFueTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUg c2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0byB0aGluayB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDt0aGV5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJl IHVzdWFsbHkgYSBiYWQgaWRlYS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB0 aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvIGtub3cg d2hhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGFuZCBp cyBub3QgZXBsb3lhYmxlLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpv ZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElh biBTbWl0aCB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSBkaXNhZ3JlZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg V2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mIG1p bGxpb25zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9m PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uY3VycmVudCBm bG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNh bid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4gdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9UIHdvcmxk IG9mIHRvbW9ycm93IHlvdSBhcmUgb25seTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGdvaW5nPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gaGF2ZSBzbWFsbCBu dW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseSBzbWFsbCBudW1iZXJzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2Ug cGF0aHM/PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXIgc291bmRz IHRvbyBtdWNoIGxpa2UgJnF1b3Q7bm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUgdGhhbiA2NEsm cXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9y PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29tZm9ydC48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBGcm9tOiBzZmM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNDo0NiBQTSBUbzogPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+ DQpodWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFu Y2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBObywgaXQgd2lsbCBt ZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlIGFyY2h0aWV0dXJlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBi YWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mIHRoZWlyPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1 cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZCB1c2Ugb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4g bm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRo ZSBhcmNoaXRlY3R1cmUgZG9lcyBwZXJtaXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBhYnVzZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGll Y3R1cmUgcGVybWl0czxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVk IGJ5IHRoZSB3b3JrLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJdCBpc24ndC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91 cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8x NCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAw IHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsIG1lYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2Vy IHRoYW4gdGhlIHJvdXRpbmcgdGFibGUgb2YgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29yZSByb3V0ZXIuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hhbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhh bHBlcm4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50 cywgZnJvbSAxPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhv cGUgdGhhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhl eSBjaG9vc2UgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBz dGVhZCBwcm92aXNpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwg NDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsLDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgbWFu eSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3Agc2VydmljZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBj aGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFyaWE8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZy b206KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSAqT24gQmVoYWxmIE9mPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpQYXVsIFF1aW5uIChwYXVs cSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjAzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBNICpUbzoqIEx1Y3kg eW9uZyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxo YWxwZXJuLmNvbTwvYT47PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT47PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptaWtl YmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+ICpTdWJqZWN0OiogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEx1Y3ks PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhl PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZvcndhcmRpbmcuIEnCuWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBtYWtlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2Fu IGJlIHVzZWQgdG8gZGVyaXZlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRl ZCB0cmFuc3BvcnQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIg aXMgdXNlZCB0byBzaW1wbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgp IHRoYXQgcGFja2V0cyBtdXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZp ZXIsIHRoZSBleGFjdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2lu ZyBmb3Igb24gdGhpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhl IHBhdGggaWRlbnRpZmllcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwg dGhhdCBsb29rdXAgY2FuIHJlc3VsdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWln aHRlZCkgdHJhbnNwb3J0IG5leHQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaG9wKHMpLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAx MCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4gJmx0OzxhIGhyZWY9 Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDsiPm1haWx0bzpsdWN5LnlvbmdAaHVhd2Vp LmNvbSZndDs8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWdyZWUuIFRoZSBhcmNoLiBk b2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mIHRoZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaWRl bnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZyBhY3Rpb25zLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24iPm1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT248L2E+IEJlaGFsZjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+T2YqbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7ICpT ZW50OipUaHVyc2RheSw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBKdWx5PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEwLCAyMDE0IDI6 MDYgQU0gKlRvOjxhIGhyZWY9Im1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20iPiptaWtlYmlhbmNA YW9sLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSZndDs7 am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJmd0OztqbWhAam9l bGhhbHBlcm4uY29tPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20mZ3Q7O3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0Bp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpz ZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlLSw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIG1lcmdlZCBk cmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpZGVudGlmaWVyLiBJ IG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvIGRlcml2ZTxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nIGFj dGlvbnMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93 bGVkZ2Ugb2YgZXZlcnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhdmFpbGFibGUgU0ZDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVk IGRvbWFpbiBpcyBub3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyByZXF1aXJlZC9qdXN0aWZpZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVu dCBjb250ZXh0cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0 aGUgcGllY2Ugb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGF0IHdpbGw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6 IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWlu LiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcyB1c2VkIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndhcmRpbmc8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhY3Rpb25zPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGEg c29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgKkRlIDoqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIj5t YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlPC9hPiBsYSBwYXJ0PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRlKm1pa2ViaWFu Y0Bhb2wuY29tIj5kZSptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZndDsgKkVu dm95w6kgOiptZXJjcmVkaSA5IGp1aWxsZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMjAxNCAyMjowMyAqw4AgOjxhIGhyZWY9Im1h aWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7c2ZjQGlldGYub3JnIj5t YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICpP YmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBTRiBDaGFpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgU0Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBQYXRoPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24g c28gdGhhdCBpdCdzIGNsZWFyIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhvc2Ugbm90PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0 aGF0IGV2ZXJ5b25lIGFncmVlcyBvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVzZSB0ZXJtcy48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG8gbWUsIHRoZSBv bmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdoZXRoZXIgaXQgaXM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGlu dGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0IHRoZSBJRDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv ZiB0aGUgU0ZDIEhlYWRlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHNob3VsZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRo aXMgZHJhZnQgc2ltcGx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93 aW5nIG90aGVyIGRyYWZ0cyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJk aW5nIGJhc2VkIG9uIGNoYWluIG9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3I8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIHRvPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJl IG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBsYXR0ZXIgKGFt YmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZSB0aGF0IGJvdGgg U0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlIG9uZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlZCBhbmQgdGhl IG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lIHZlbmRvcnMgb25seTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0aW5n IFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbTo8YSBocmVm PSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNv bTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpv ZWxoYWxwZXJuLmNvbSZndDsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxo YWxwZXJuLmNvbSZndDs8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86PGEgaHJlZj0ibWFpbHRvOipzZmNAaWV0Zi5v cmciPipzZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNA aWV0Zi5vcmcmZ3Q7Ij5tYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJmd0OzwvYT4m Z3Q7ICpTZW50OipUdWVzZGF5LCBKdWx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBiZWVu IHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5IGFuc3dlciBhPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBv ZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZSBwcm9wb3NlZDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtZXJn ZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0IHdvcmtpbmc8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3Jv dXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0byBpbXByb3ZlIHRoZTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluIHRo ZSBXRzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ya2luZzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBpbnRl bmRzLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBt eSBwZXJzb25hbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoaXMg cmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgd2hhdDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBh cmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZSBhcmUgbm90PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg c29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQgZW5jb21wYXNzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9T Uy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgdmlydHVhbDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBt YWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlciBhc3BlY3RzLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkIHRv PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgg YWJvdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgd2hlcmUgd2UgYXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5 IHRoZSB3b3JrIHdlIGFyZSBkb2luZy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2Ug Y2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVuZGVyc3RhbmQ8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVtLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8gZmlyc3QgZGlz Y3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0IGxlYXN0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRocmVlIGRpZmZlcmVu dCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVyYWN0IHdpdGgg c2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlIG1vcmUuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBv ZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YgdGhlc2UsPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ1dCBub3Qg dG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSB1c2VkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGFueSBzb2x1dGlvbi48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg MSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQgdXNlci48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXIgcGFja2V0cywg YW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG1vZGlmaWVzIHRoZW0gKG9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgbWFya3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5k IHVzZXIgc2VydmljZSBpbnN0YW5jZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRo aXMgaXMgYW4gaW1wb3J0YW50IHNlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNs dWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuIEl0J3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1 aXJlbWVudHMgb24gaG93IHNlcnZpY2UgY2hhaW5pbmcgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9uZS4gQnV0IGl0IGhhcyB2 ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlIGFyY2h0aWVjdHVyZS48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNoaXRl Y3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlm eSB0aGUgdW5kZXJseWluZyBwYWNrZXQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQg YmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuIGhhdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hhdDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcGVhcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlIHBvaW50IG9mPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhY3Q8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3IgYTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVjaWZpYyBz ZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkIGJ5IGE8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb2xsZWN0aW9uIG9mPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpcnR1 YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZyBvbmUgb3I8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2V2 ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRlY2hu aXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpczxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2li bGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZSBtZWNoYW5pc21zLiBJdDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp cyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbCBtZWNoYW5pc21z LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCBh bmQgdm08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mIHBlcm1p dHRpbmcgdGhpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQg b3VyIHRlcm1pbm9sb2d5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGxlYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWFkZXJzIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGlu ZyBpdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSBz ZWxlY3Rpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRp cmVjdCB0cmFmZmljPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRv IHJlcXVpcmUgdGhhdCBhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkg b25lIHBsYWNlIGluIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNh c2UgdGhhdCB0aGVzZSBtYXkgYmUgY29tYmluZWQuIEkgdGVuZDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVyIHRvPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjb2xsZWN0aW9u IG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UgY2hhaW5pbmc8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYSBzaW5n bGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzIGE8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ29vZCB0 ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLiBUaHVzLCB0aGU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg cG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgaXMgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRy YWZmaWMgdG8gZGlmZmVyZW50IHNpbmd1bGFyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0 aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb3cgd2l0 aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2Ug Y2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhIHNlcXVlbmNlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9m IGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YgcGFja2V0cy48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZiB0cmFmZmlj IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCBmaXJl d2FsbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhl IGNhY2hlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91 dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYXQgaXMg bm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIHBhY2tldHMuIEE8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vydmlj ZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YgbG9jYXRpb25zPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlu IHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbHVz dGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkgbWF5IGJlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXMgcG9ydHMg b248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZSBsb2Nh dGlvbnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0 dXJlIGFuZCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQgb2Ygdmll dyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIGdyb3VwLCB3ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmVlZCB0byBiZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh YmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZSBzZXJ2aWNl PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvIHRh bGs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhl PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVv dDtidXQgdGhlIHdob2xlIHBhdGggbWF5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuJnF1 b3Q7IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzIHdpdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBpc3N1ZSBpbiB0d28gd2F5 cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uIGxvYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmFsYW5jZXJzIGFib3Zl LCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCBiZWhhdmlvcnMgd2hpY2g8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlz aWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbiBtdWNoPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBz YW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJs ZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlciBwcm92aXNpb24gd2U8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFr ZSBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg cmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbiBuZWNlc3Nhcnku PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb248YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbiBwb2ludC48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiBJZiBp dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5n IGdyb3VwLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0 aCB0aGUgaW50ZW50LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0 aGUgd29ya2luZyBncm91cDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIs IEkgYW0gbm90IHN1cmUgd2hhdCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cnkgbmV4dC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHNmYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IG1haWxpbmc8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlz dCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgbWFpbGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IG1h aWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIHNmYyBtYWlsaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgbGlzdDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjIG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMgbWFpbGluZzxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4g PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g c2ZjIG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnNmYyBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj PC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CFE583F72D4F1jguicharciscocom_-- From nobody Fri Jul 11 09:13: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 3BA031B2BAB for ; Fri, 11 Jul 2014 09:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 FDEQMM_fm8_b for ; Fri, 11 Jul 2014 09:12:59 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975E11B2BCD for ; Fri, 11 Jul 2014 09:11:49 -0700 (PDT) Received: from mtaout-mce02.mx.aol.com (mtaout-mce02.mx.aol.com [172.29.27.206]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id BE5C17029000D; Fri, 11 Jul 2014 12:11:48 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mce02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7614138000083; Fri, 11 Jul 2014 12:11:48 -0400 (EDT) Date: Fri, 11 Jul 2014 12:11:48 -0400 From: "mikebianc@aol.com" To: mohamed.boucadair@orange.com, jguichar@cisco.com, mn1921@att.com, jmh@joelhalpern.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <793508013.3099.1405095108294.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3098_1010221885.1405095108293" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405095108; bh=En9R3uzYFoN/NPPgGCSf6CWZxQWopEyXHJlN0eGyhyI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=eVHfoWin2/uYtH2i71/3At1PD4vTl85j7nBnr5snn6T6kL/RDd7cewv19H1DL/KTV IX0PONMUcjk3WMJyjh73rm/Fh48146GZUEaNR9AMd5SrssBOrkQ5kBz60I519JPdiF FIJ929xhYEA6fwPdOFxYZI1Ath64PK/kJ3an/Xl4= x-aol-sid: 3039ac1d1bce53c00cc4368f X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AbciFb05eFj6TgiobrhVaU5NKcA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:13:04 -0000 ------=_Part_3098_1010221885.1405095108293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, the draft seems to indicate that if you want this distributed behavior= , you need to re-classify onto a new SFP. =C2=A0If that is not the intent o= f the draft, then it is unclear. From: mohamed.boucadair@orange.com To: Jim Guichard (jguichar),NAPIERALA, MARIA H,Joel M. Halpern,Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, For what I can say at best this is not described clearly in the draft.=20 Mandating a service path identifier is in itself a hint that the full distr= ibuted model is not allowed. Several voices in this thread indicated that the service chain itself shoul= d be provided instead. Cheers, Med=20 >-----Message d'origine----- >De=C2=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >(jguichar) >Envoy=C3=A9=C2=A0: vendredi 11 juillet 2014 16:18 >=C3=80=C2=A0: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.or= g >Objet=C2=A0: Re: [sfc] Service Chains, Paths, and Load Balancers >>Ok but where in the architecture specifically is this functionality>prohi= bited? If you want to distribute *all* next-hops to *all* SFF=E2=80=99s>wit= hin the SFC domain and then let the path identifier point to a lookup>into = those next-hops to reach the next SF in the chain, I am not sure how>the ar= chitecture prevents that?>>On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" wrote:>>>Absolutely.>>>>> -----Original Message----->>> From: sf= c [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard>>>(jguichar)>>> S= ent: Friday, July 11, 2014 9:54 AM>>> To: NAPIERALA, MARIA H; Joel M. Halpe= rn; Ron Parker; sfc@ietf.org>>> Subject: Re: [sfc] Service Chains, Paths, a= nd Load Balancers>>>>>> Then I misunderstand the proposal ;-) .. However, i= t seems to me that if>>> you allow an SFF to make a decision as to which re= mote SFF it will use>>>for>>> a given flow to reach the next SF within the = chain then you better make>>> sure that that remote SFF has the necessary f= orwarding logic to reach>>>the>>> next-next-SF for the chain as otherwise y= ou are in deep trouble.>>>>>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" wrote:>>>>>> >Absolutely not. Service chains can be instantia= ted only in relevant>>>SFFs>>> >when they "arrive".>>> >>>> >> -----Origina= l Message----->>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of J= im Guichard>>> >>(jguichar)>>> >> Sent: Friday, July 11, 2014 9:27 AM>>> >>= To: Joel M. Halpern; Ron Parker; sfc@ietf.org>>> >> Subject: Re: [sfc] Ser= vice Chains, Paths, and Load Balancers>>> >>>>> >> Well I think it is even = worse than that if I have understood the>>> >>proposal>>> >> correctly as i= t would require full knowledge of every single SF>>>within>>> >>the>>> >> e= ntire SFC domain at every single SFF as there is no way to know a>>> >>prio= ri>>> >> which SFC=C2=B9s a given SFF will need to service at any given poi= nt in>>>time.>>> >>>>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote:>>> >>>>> >> >Ron, thinking about this, I realized anoth= er major problem with the>>> >>your>>> >> >proposal as I understand it. (A= nd I readily admit I may not>>>understand>>> >> >it.)>>> >> >>>> >> >The pr= oposal has each SFF serve as the load balancer for the next>>> >> >service = function that follows it (not the one it delivers to), in>>>every>>> >> >se= rvice chain that goes through it.>>> >> >>>> >> >Since it has to be able to= work with all services, that means that>>> >>every>>> >> >SFF would have t= o be a full, flow sensitive and stateful load>>>balancer.>>> >> >I ahve no = problem if some SFF are flow sensitive, and / or stateful.>>> >> >But havin= g the architecture require that every SFF be a full, flow>>> >> >sensitive,= stateful, load balancer seems to me to be an acceptable>>> >> >imposition.= >>> >> >>>> >> >Yours,>>> >> >Joel>>> >> >>>> >> >On 7/10/14, 10:06 PM, Joe= l M. Halpern wrote:>>> >> >> Part of my personal view is that I am trying t= o make this work>>> >>sensibly>>> >> >> in a more orchestrated environment.= I expect that the service>>> >> >> functions, and over time probably the = SFF capabilities, will be>>> >> >> orchestrated and installed. I expect th= e service chains to be>>> >>driven by>>> >> >> BSS tools that define offeri= ngs to clients, and enable>>>self-selection>>> >> >> from these. I expect = service paths to be heavily policy drive.>>> >> >>>>> >> >> I can see how t= o make all of that work in an archtiecture driven>>>by>>> >> >> initial cla= ssification to described service paths. It is harder>>>to>>> >>see>>> >> >= > how to make it work (but it can be done) when we allow more>>> >> dynamic= ity>>> >> >> in the network behavior.>>> >> >>>>> >> >> Having said that, m= ost of that perspective I described is outside>>>of>>> >>the>>> >> >> scope= of the working group. it is not something we are tasked to>>> >>agree>>> = >> >>on.>>> >> >> So I do not claim that vision means we have to do it a ce= rtain>>>way.>>> >>it>>> >> >> is just the perspective that drives my prefer= ences.>>> >> >>>>> >> >> Yours,>>> >> >> Joel>>> >> >>>>> >> >> On 7/10/14,= 9:58 PM, Ian Smith wrote:>>> >> >>>> For me, the amount of information abo= ut service instances that>>> >>needs>>> >> >>>>to>>> >> >>>> be widely dist= ributed and maintained, potentially even across>>>data>>> >> >>>> centers w= ithin an administrative scope, is large enough and>>> complex>>> >> >>>> en= ough that trying to get that into each SFF seems like a>>>difficult>>> >> >= >>> architecture to realize.>>> >> >>>>>> >> >>> I'm curious as to why that= is more complicated than dynamic>>> routing,>>> >> >>> hyper-scale data ce= nter orchestration, or DNS, all of which are>>> >>bigger>>> >> >>> problems= that have been profitably and stably implemented?>>> >> >>>>>> >> >>> It a= lso seems that if it really is more complicated, that is a>>>good>>> >> >>>= sign that it is too complicated.>>> >> >>>>>> >> >>> _____________________= ___________________>>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com]>>= > >> >>> Sent: Thursday, July 10, 2014 9:45 PM>>> >> >>> To: Ron Parker; Jo= el Halpern Direct; mikebianc@aol.com; Ian>>>Smith;>>> >> >>> sfc@ietf.org>>= > >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>> >>= >>>>>> >> >>> This is an architectural issue. And one that I would prefer= we>>> >> >>>actually>>> >> >>> decide, rather than trying to allow all pos= sible implementations.>>> >> >>> Because it does have a major effect on the= control requirements>>>and>>> >> the>>> >> >>> functionality of SFFs.>>> >= > >>>>>> >> >>> For me, the amount of information about service instances t= hat>>> needs>>> >> to>>> >> >>> be widely distributed and maintained, poten= tially even across>>>data>>> >> >>> centers within an administrative scope,= is large enough and>>>complex>>> >> >>> enough that trying to get that int= o each SFF seems like a>>>difficult>>> >> >>> architecture to realize.>>> >= > >>>>>> >> >>> Yours,>>> >> >>> Joel>>> >> >>>>>> >> >>> But it is a fair = question.>>> >> >>>>>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>>> >> = >>>> This is the crux of my issue. =C2=A0 Is the end to end selection of>>>= >> >>>> (top-level) instances performed centrally (perhaps by the>>> >>cla= ssifier)>>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequent= ly the>>> >>SFFs)?>>> >> >>>> Such selection is not equivalent to reclassif= ication. =C2=A0 And>>>surely,>>> >> >>>> this is an architectural issue and= not relegated to>>> >> >>>> "implementation".>>> >> >>>>>>> >> >>>> My own= view is to favor the distributed approach even though a>>> >> >>>> greater= amount of data (chain definitions and perhaps local>>> >>selection>>> >> >= >>> policy) is required at those distributed decision points. =C2=A0 This>>= > >> >>>> approach does not require an end-to-end path id at all. =C2=A0=C2= =A0 My>>> >> >>>> rationale for favoring this approach is primarily driven = by>>> >>increased>>> >> >>>> resiliency over the global path id approach. = =C2=A0 With a global>>>path>>> >>id>>> >> >>>> approach, consider failure o= f an instance and needing to alter>>>the>>> >> >>>> global path ID table fo= r each and every affected end-to-end>>>path.>>> >> >>>>>>> >> >>>> Ron>>> >= > >>>>>>> >> >>>> ________________________________________ From: sfc>>> >> = >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct>>> >> >>>> [jm= h.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15>>> PM>>> >> >>= >> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re:>>> >> >= >>> [sfc] Service Chains, Paths, and Load Balancers>>> >> >>>>>>> >> >>>> T= he way the architecture models the case of SF1 needing to>>> >>influence>>>= >> >>>> the chain is that one would do reclassification at the exit from>>= > >> >>>> SF1.>>> >> >>>>>>> >> >>>> Part of the goal is to keep the differ= ent functions logically>>> >> >>>> separate so that solutions can clearly d= escribe how they choose>>>to>>> >> >>>> compose them for "service" delivery= .>>> >> >>>>>>> >> >>>> Yours, Joel>>> >> >>>>>>> >> >>>> On 7/10/14, 6:10 = PM, mikebianc@aol.com wrote:>>> >> >>>>> I don't see anything in the arch d= raft that suggests any sort>>>of>>> >> >>>>> limit. However, it does seem t= o indicate that the entire path>>>(all>>> >> >>>>> SFIs) must be chosen at = SFC instantiation. I believe this>>>means>>> >> >>>>> either at the classi= fier or maybe the classifier chooses a SF>>> >>Chain>>> >> >>>>> and the NF= or at the latest the first SFF. In any case, the>>> >> >>>>> language doe= s seem to prohibit a more dynamic SFP where SFI(n)>>> is>>> >> >>>>> determ= ined at the SFI(n-1) hop. According to the draft, this>>> >> >>>>> behavio= r would be considered "branching" to a new SFP as>>> opposed>>> >> to>>> >>= >>>>> choosing and then forwarding to the selected instance of the>>> >> >= >>>> next-hop of the current SFC.>>> >> >>>>>>>> >> >>>>> draft-merged-sfc-= architecture-00:>>> >> >>>>>> When an SFC is instantiated into the network = it is necessary>>>to>>> >> >>>>>> select the specific instances of SFs that= will be used, and to>>> >> >>>>>> create the service topology for that SFC= using SF's network>>> >> >>>>>> locator. Thus, instantiation of the SFC r= esults in the>>>creation>>> >> >>>>>> of a Service Function Path (SFP) and = is used for forwarding>>> >> >>>>>> packets through the SFC. In other words= , an SFP is the>>> >> >>>>>> instantiation of the defined SFC.>>> >> >>>>>>= >>> >> >>>>>> The SFC architecture supports reclassification (or non-initia= l>>> >> >>>>>> classification) as well. As packets traverse an SFP,>>> >> = >>>>>> reclassification may occur - typically performed by a>>> >> >>>>>> c= lassification function co-resident with a service function.>>> >> >>>>>> Re= classification may result in the selection of a new SFP, an>>> >> >>>>>> up= date of the associated metadata, or both. This is referred>>>to>>> >> >>>>= >> as "branching".>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>>>>= >>>>>>>>>>-----------------------------------------------------------------= ->>>>>>>>>>-->>> >>>>>>>-->>> >> >>>>>-->>> >> >>>>>>>> >> >>>>>>>> >> >>>>= >>>> >> >>> *From: *I.Smith@F5.com>>> >> >>>>> *To: *Joel H= alpern Direct,Joel M.>>> >> >>>>>>>> >>>>> >>>>= >Halpern,huang@sce.carleton.ca>> >> carlet= on.>>> >> >>>>>ca>,sfc@ietf.org>>> >> >>>>>>>> >> >>>>>>>> >>= >>>>>>>> >> >>> *Sent: *Thursday, July 10, 2014>>> >> >>>>> *Subject: *Re:= [sfc] Service Chains, Paths, and Load Balancers>>> >> >>>>>>>> >> >>>>> Ac= tually, I think I am disagreeing.>>> >> >>>>>>>> >> >>>>> If the possibilit= y of medium-scale deployments (and that is>>>what>>> >> >>>>> 16 million fl= ows is in my world) of service chains is>>>preconceived>>> >> >>>>> as an a= bsurd idea, then the architecture burdened with that>>> >> >>>>> preconcept= ion.>>> >> >>>>>>>> >> >>>>> There has to be some point of aim, some degree= of aspiration to>>> >> >>>>> scale that is appropriate for the lifespan of= the architecture>>>->>> >> >>>>> you don't have to know what it is, but by= saying that an>>>arbitrary>>> >> >>>>> number is "too far", you're creatin= g - even if it isn't>>> >>intentional>>> >> >>>>> - a limit that influences= decisions that have lasting impacts>>> >> >>>>> regarding scale-out, failu= re mitigation, elasticity, address>>> >> >>>>> space... all kinds of things= . That is a problem I'm not>>> >> >>>>> particularly eager to deal with.>>>= >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> _________________= _______________________>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> From: Joel Halp= ern Direct [jmh.direct@joelhalpern.com] Sent:>>> >> >>>>> Thursday, July 10= , 2014 5:04 PM To: Ian Smith; Joel M. Halpern;>>> >> >>>>> huang@sce.carlet= on.ca; sfc@ietf.org Subject: Re: [sfc] Service>>> >> >>>>> Chains, Paths, a= nd Load Balancers>>> >> >>>>>>>> >> >>>>> Ian, I don't think you disagree w= ith me at all in this regard.>>>I>>> >>am>>> >> >>>>> not requesting the th= e architecture or the solution prohibit>>> >> >>>>> deployments in the spec= ific fashion. I am objecting to Huang's>>> >> >>>>> reading of my note as s= aying that such deployments are required>>> >> >>>>> they by the archtiectu= re.>>> >> >>>>>>>> >> >>>>> As I have said repeatedly, I am not trying to p= rohibit such>>> >> >>>>> things. Whether they are a good idea or not depend= s upon many>>> >> >>>>> factors outside of the scope of the WG. I happen to= think that>>> >>they>>> >> >>>>> are usually a bad idea.>>> >> >>>>>>>> >>= >>>>> But the archtiecture si carefully avoiding attempting to know>>>what= >>> >> >>>>> is and is not eployable.>>> >> >>>>>>>> >> >>>>> Yours, Joel>>= > >> >>>>>>>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>>> >> >>>>>> I= disagree.>>> >> >>>>>>>>> >> >>>>>> We routinely have stateful devices tha= t manage tens of>>>millions>>> >> >>>>>> of>>> >> >>>>> concurrent flows in= both access network and data center>>> >> >>>>> environments today. You ca= n't seriously believe that in the>>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/Io= T world of tomorrow you are only>>> >> going>>> >> >>>>> to have small numb= ers of service chains with equally small>>> numbers>>> >> >>>>> of active s= ervice paths?>>> >> >>>>>>>>> >> >>>>>> Your sounds too much like "no one w= ill ever need more than>>> 64K">>> >> >>>>>> for>>> >> >>>>> comfort.>>> >>= >>>>>>>>> >> >>>>>>>>> >> >>>>>> ________________________________________ = From: sfc>>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern>= >> >> >>>>> [jmh@joelhalpern.com]>>> >> >>>>>> Sent: Thursday, July 10, 201= 4 4:46 PM To:>>>huang@sce.carleton.ca;>>> >> >>>>>> sfc@ietf.org Subject: R= e: [sfc] Service Chains, Paths, and>>>Load>>> >> >>>>>> Balancers>>> >> >>>= >>>>>> >> >>>>>> No, it will mean that if someone tries to deploy the>>>arc= htieture>>> >> >>>>>> particularly badly, they will exceed the limits of th= eir>>> >> >>>>>> devices. The architecture does not require such absurd use= of>>> >> >>>>>> service paths. Since I can not figure out how to write>>> = >> >>>>>> architectural words to prohibit it, the architecture does>>>permi= t>>> >> >>>>>> such abuse.>>> >> >>>>>>>>> >> >>>>>> Please do not read my = saying that the archtiecture permits>>> >> >>>>>> something as saying it is= either deisred or required by the>>>work.>>> >> >>>>>> It isn't.>>> >> >>>= >>>>>> >> >>>>>> Yours, Joel>>> >> >>>>>>>>> >> >>>>>> On 7/10/14, 4:36 PM,= Changcheng Huang wrote:>>> >> >>>>>>> If you need to support 100 service c= hains, it will mean>>> >> >>>>>>> 16,000,000 paths. That is larger than the= routing table of a>>> >> >>>>>>> core router.>>> >> >>>>>>>>>> >> >>>>>>> = Chang>>> >> >>>>>>>>>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern w= rote:>>> >> >>>>>>>> The architecture allows a range of deployments, from 1= >>> >> >>>>>>>> service path to 160000 service paths. I would hope that>>> = >> >>>>>>>> operators are prepared for the complexities if they choose>>>to= >>> >> >>>>>>>> avoid any use of local load balancing and in stead provisio= n>>> >> >>>>>>>> 160,000 service paths.>>> >> >>>>>>>>>>> >> >>>>>>>> Yours= , Joel>>> >> >>>>>>>>>>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA = H wrote:>>> >> >>>>>>>>> Paul,>>> >> >>>>>>>>>>>> >> >>>>>>>>> How many pat= h identifiers there will be for a 4 hop service>>> >> >>>>>>>>> chain with = 20 instances at each hop?>>> >> >>>>>>>>>>>> >> >>>>>>>>> Maria>>> >> >>>>>= >>>>>>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of= >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>>= > >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;>>> >> >>>>>>>>= > mohamed.boucadair@orange.com; sfc@ietf.org;>>> >> >>>>>>>>> mikebianc@aol= .com *Subject:* Re: [sfc] Service Chains,>>> >> >>>>>>>>> Paths, and Load B= alancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> Lucy,>>> >> >>>>>>>>>>>> >> >>>>>>= >>> Overall I concur, as you say: a path ID drives the>>> >> >>>>>>>>> forw= arding. I=C2=B9d>>> >> >>>>> make>>> >> >>>>>>>>> the minor change: the pat= h identifier can be used to derive>>> >> >>>>>>>>> the needed forwarding an= d associated transport.>>> >> >>>>>>>>>>>> >> >>>>>>>>> It is _not_ the tra= nsport, but rather is used to simply>>> >> >>>>>>>>> identify the service p= ath (or graph) that packets must>>> >> >>>>>>>>> traverse. By having a path= identifier, the exact>>> >> >>>>>>>>> indirection that people seem to be a= sking for on this>>> >> >>>>>>>>> thread can be simply be implemented. The = path identifier>>> >> >>>>>>>>> provides nothing more than a lookup, that l= ookup can result>>> >> >>>>>>>>> in a one or more (equal or weighted) trans= port next>>> >> >>>>>>>>> hop(s).>>> >> >>>>>>>>>>>> >> >>>>>>>>> Paul>>> >= > >>>>>>>>>>>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>>> >> >= >>>>>>>> >>>> >> >>>>>>>= >> wrote:>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>> A= gree. The arch. doc should not mandate only use of the>>> >> >>>>>>>>> serv= ice path identifier to drive the forwarding actions.>>> >> >>>>>>>>>>>> >> = >>>>>>>>> Lucy>>> >> >>>>>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounc= es@ietf.org]*On Behalf>>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com>>> >= > >>>>>>>>> >>> *Sent:*Thursday,>>> >>= July>>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com>>> >> >>>>>>>= >> ;jmh@joelhalpern.com>>> >> >>>>>>>>> ;sfc@ietf.org>>> >> >>>>>>>>> *Sub= ject:*Re: [sfc] Service Chains,>>> >> >>>>>>>>> Paths, and Load Balancers>>= > >> >>>>>>>>>>>> >> >>>>>>>>> Re-,>>> >> >>>>>>>>>>>> >> >>>>>>>>> The mer= ged draft calls out explicitly a service path>>> >> >>>>>>>>> identifier. I= object to use that identifier to derive>>> >> >>>>>>>>> forwarding actions= .>>> >> >>>>>>>>>>>> >> >>>>>>>>> Requiring a SFC system to have the full k= nowledge of every>>> >> >>>>> available SFC>>> >> >>>>>>>>> forwarding path= s within an SFC-enabled domain is not>>> >> >>>>> required/justified>>> >> = >>>>>>>>> nor possible in various deployment contexts.>>> >> >>>>>>>>>>>> >= > >>>>>>>>> SFC forwarding actions should rely on the piece of>>> >> >>>>>>= >>> information>>> >> >>>>> that will>>> >> >>>>>>>>> be present in all dep= loyments: that is the one required to>>> >> >>>>>>>>> structure a service c= hain. How that information is used to>>> >> >>>>>>>>> infer forwarding>>> >= > >>>>> actions>>> >> >>>>>>>>> is a solution-oriented discussion.>>> >> >>= >>>>>>>>>> >> >>>>>>>>> Cheers,>>> >> >>>>>>>>>>>> >> >>>>>>>>> Med>>> >> >= >>>>>>>>>>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part= >>> >> >>>>> de*mikebianc@aol.com>>> >> >>>>>>>>> *Envoy=C3=A9 :*mercredi 9 juillet>>> >> >>>>>>>>> 2014 22:03 *=C3=80 :*jm= h@joelhalpern.com>>> >> >>>>>>>>> ;sfc@ietf.org= >>> >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains,>>= > >> >>>>>>>>> Paths, and Load Balancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> Is= anyone still questioning the difference between SF Chain>>> >> >>>>>>>>> a= nd SF>>> >> >>>>> Path?>>> >> >>>>>>>>> Other than clarifying the definitio= n so that it's clear to>>> >> >>>>> those not>>> >> >>>>>>>>> familiar with= the draft, it seems that everyone agrees on>>> >> >>>>>>>>> these terms.>>= > >> >>>>>>>>>>>> >> >>>>>>>>> To me, the one point that is still unclear i= s whether it is>>> >> >>>>>>>>> the intent of this draft to ultimately spec= ify what the ID>>> >> >>>>>>>>> of the SFC Header>>> >> >>>>> should>>> >> = >>>>>>>>> reference (the chain or the path), or if this draft simply>>> >> = >>>>>>>>> intends to leave that ambiguous, allowing other drafts to>>> >> >= >>>>>>>> dictate the mechanisms for forwarding based on chain or>>> >> >>>>= >>>>> path and the choice of chain or>>> >> >>>>> path to>>> >> >>>>>>>>> b= e negotiated in the control-plane.>>> >> >>>>>>>>>>>> >> >>>>>>>>> If the l= atter (ambiguous), then the draft would have>>> >> >>>>>>>>> require that b= oth SFP and SFC be supported (or make one>>> >> >>>>>>>>> required and the = other optional) to avoid some vendors only>>> >> >>>>>>>>> supporting SFP a= nd others only supporting SFC.>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>= >> >>>>>>>>>>>>>>>---------------------------------------------------------= --------->>>>>>>>>>-->>> >>>>>>>-->>> >> >>>>>-->>> >> >>>>>>>> >> >>>>>>>>= >> >>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> *From:*jmh@joelhalpern.com>> >> >>>>>>>>> >>>> >> >>>>>>>>> *To:*sfc@ietf.org>> >> >>>>>>>>> > *Sent:*Tuesday, July>>> >> >>>>>>>>> 8, 2014= *Subject:*[sfc] Service Chains, Paths, and Load>>> >> >>>>>>>>> Balancers>= >> >> >>>>>>>>>>>> >> >>>>>>>>> I have been trying to figure out how to cle= arly answer a>>> >> >>>>>>>>> number of comments that have been made about = the>>> proposed>>> >> >>>>>>>>> merged archtiecture draft. Assuming we can = get working>>> >> >>>>>>>>> group agreement on the intent, we will work to = improve the>>> >> >>>>>>>>> wording so that readers who have not participat= ed in the WG>>> >> >>>>>>>>> discussion will understnd it the way the>>> >>= >>>>> working>>> >> >>>>>>>>> group intends.>>> >> >>>>>>>>>>>> >> >>>>>>>= >> But what do we intend? I will try to explain my personal>>> >> >>>>>>>>>= view, and see if that helps.>>> >> >>>>>>>>>>>> >> >>>>>>>>> In this regar= d, it is important to keep in mind that what>>> >> >>>>>>>>> we are definin= g is the data plane architecture. We are not>>> >> >>>>>>>>> attempting to = define the architecture for the entire>>> >> >>>>>>>>> solution for service= chaining. That would encompass>>> >> >>>>>>>>> OSS/BSS, various control an= d policy functions, virtual>>> >> >>>>>>>>> machine and image management, a= nd many other aspects.>>> >> >>>>>>>>>>>> >> >>>>>>>>> As a result there ar= e many things which clearly need to>>> >> >>>>>>>>> exist in the larger sys= tem, but which are dealt with above>>> >> >>>>>>>>> where we are>>> >> >>>>= > functioning,>>> >> >>>>>>>>> and are not directly required by the work we= are doing.>>> >> >>>>>>>>>>>> >> >>>>>>>>> In order to get to service chai= n vs service path, as I>>> >> >>>>>>>>> understand>>> >> >>>>> them,>>> >> = >>>>>>>>> I need to first discuss load balancing. There are at least>>> >> = >>>>>>>>> three different ways that load balancing can and will>>> >> >>>>>= >>>> interact with service chaining. There probably are more.>>> >> >>>>>>>= >> The point of the archtiecture is to permit all of these,>>> >> >>>>>>>>>= but not to mandate that any particular kind>>> >> >>>>> be used>>> >> >>>>= >>>>> in any solution.>>> >> >>>>>>>>>>>> >> >>>>>>>>> 1) Load balancing as= a service provided to the end user.>>> >> >>>>>>>>> This is a service func= tion. It receives user packets, and>>> >> >>>>>>>>> modifies them (or>>> >>= >>>>> marks>>> >> >>>>>>>>> them, or ...) so as to choose an end user serv= ice instance>>> >> >>>>>>>>> to receive the users packet. This is an import= ant service>>> >> >>>>>>>>> function to be able to include in service chain= ing. It's>>> >> >>>>>>>>> behavior may affect requirements on how service c= haining is>>> >> >>>>>>>>> done. But it has very little impact on the archt= iecture.>>> >> >>>>>>>>> From an architectural pe3rspective it is simply a= >>> >> >>>>> service>>> >> >>>>>>>>> function which may modify the underlyi= ng packet.>>> >> >>>>>>>>>>>> >> >>>>>>>>> 2) There is internal load balanc= ing. That is, one can have>>> >> >>>>>>>>> what>>> >> >>>>> appears>>> >> >= >>>>>>>> to the service chaining architecture as a single point of>>> >> >>= >>>>>>> contact>>> >> >>>>> for a>>> >> >>>>>>>>> specific service function= , but is actually delivered by a>>> >> >>>>> collection of>>> >> >>>>>>>>> = virtual or physical machines, possibly including one or>>> >> >>>>>>>>> sev= eral load balancers (for example using VRRP-like>>> >> >>>>>>>>> techniques= to share a MAC address.) mostly, this is>>> >> >>>>>>>>> invisible to the = service chaining data plane mechanisms. It>>> >> >>>>>>>>> is likely that i= t is visible to various control mechanisms,>>> >> >>>>>>>>> such as those r= esponsible for scale-in, scale-out, and vm>>> >> >>>>>>>>> instantiation. T= he architectural impact of permitting this>>> >> >>>>>>>>> is largely that = we need to be careful that our terminology>>> >> >>>>>>>>> does not lead>>>= >> >>>>> readers to>>> >> >>>>>>>>> think we are prohibiting it.>>> >> >>>= >>>>>>>>> >> >>>>>>>>> 3) There can also be load balancing done by selectin= g>>> >> >>>>>>>>> packet paths for the service chaining that direct traffic= >>> >> >>>>>>>>> to different places. We would not want to require that a>>= > >> >>>>>>>>> given service function appear at only one place in the>>> >>= >>>>>>>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> It is of course the cas= e that these may be combined. I tend>>> >> >>>>>>>>> to>>> >> >>>>> refer t= o>>> >> >>>>>>>>> the collection of entities that appear to service chainin= g>>> >> >>>>>>>>> as a single point as a cluster. Not because cluster is a>= >> >> >>>>>>>>> good term. But because I do not have another one. Thus, the= >>> >> >>>>>>>>> point of type 3 load balancing>>> >> >>>>> is to>>> >> >>>= >>>>>> direct different subsets of traffic to different singular>>> >> >>>>= >>>>> or clustered service functions in different places in the>>> >> >>>>>= >>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Now with that said, what do I= mean when I talk about>>> >> >>>>>>>>> service chain and service path/ Ser= vice chain is a sequence>>> >> >>>>>>>>> of logical functions to be applied= to a subset of packets.>>> >> >>>>>>>>> It is equivalent of saying that so= me subset of traffic is>>> >> >>>>>>>>> to get DPI, charging, content inspe= ction, and firewall>>> >> >>>>>>>>> while a different subset is to go direc= tly to the cache>>> >> >>>>> without>>> >> >>>>>>>>> visiting any other ser= vice functions.>>> >> >>>>>>>>>>>> >> >>>>>>>>> That is not enough informat= ion to direct the packets. A>>> >> >>>>>>>>> service path is, in some fashi= on, a sequence of locations>>> >> >>>>>>>>> in the network. Those locations= will be singular or>>> >> >>>>>>>>> clustered service function delivery lo= cations. They may be>>> >> >>>>>>>>> addressed by IP address. They may be a= ddressed as ports on>>> >> >>>>>>>>> an SFF. There are many different ways = that the locations>>> >> >>>>>>>>> may be known to the service chaining inf= rastructure and the>>> >> >>>>>>>>> transport.>>> >> >>>>>>>>>>>> >> >>>>>>= >>>> From the point of view of the work of the SFC group, we>>> >> >>>>>>>= >>> need to be>>> >> >>>>>>>>> able to talk about the high level abstractio= n, the service>>> >> >>>>>>>>> chain, which drives the forwarding. And we n= eed to talk>>> >> >>>>>>>>> about the actual data path packets will take in= the>>> >> >>>>>>>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Several of th= e comments have said "but the whole path may>>> >> >>>>>>>>> not be known a= t the front." This architecture deals with>>> >> >>>>>>>>> that issue in tw= o ways. First, as noted in item (2) on load>>> >> >>>>>>>>> balancers above= , there can be decisions and behaviors which>>> >> >>>>>>>>> are invisible = to the service chaining mechanisms (in much>>> >> >>>>>>>>> the same way th= at bridging within a LAN is largely>>> >> >>>>>>>>> invisible to routing be= tween LANs.) The other provision we>>> >> >>>>>>>>> make is>>> >> >>>>> tha= t>>> >> >>>>>>>>> reclassification can be done in mid-chain when necessary.= >>> >> >>>>>>>>> That will direct packets to a new chain. Based on>>> >> >>= >>>>>>> information available at the re-classification point.>>> >> >>>>>>>= >>>>> >> >>>>>>>>> I hope that this helps explain what we are after. If it>= >> >> >>>>>>>>> does, and if the intent is acceptable to the working group,= >>> >> >>>>>>>>> we can figure out what additional words are needed to>>> >= > >>>>>>>>> convey this. If the working group disagree with the intent,>>> = >> >>>>>>>>> then we will of course adjust to match the working group>>> >>= >>>>>>>>> agreements. If this is still unclear, I am not sure what to>>> >= > >>>>>>>>> try next.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Yours, Joel>>> >> >>>= >>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc>= >> >> mailing>>> >> >>>>>>>>> list sfc@ietf.org >>> >>= >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>>> >> >>>>>>>>>>>> >> = >>>>>>>>> _______________________________________________ sfc>>> >> mailing= >>> >> >>>>>>>>> list sfc@ietf.org >>> >> >>>>>>>>> ht= tps://www.ietf.org/mailman/listinfo/sfc>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >= > >>>>>>>> _______________________________________________ sfc>>> >> mailin= g>>> >> >>>>>>>> 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/m= ailman/listinfo/sfc>>> >> >>>>>>> >> >>>> _________________________________= ______________ sfc mailing>>> >> list>>> >> >>>> sfc@ietf.org https://www.i= etf.org/mailman/listinfo/sfc>>> >> >>>>>>> >> >>>> ________________________= _______________________ sfc mailing>>> >> list>>> >> >>>> sfc@ietf.org http= s://www.ietf.org/mailman/listinfo/sfc>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >= > _______________________________________________>>> >> >> sfc mailing list= >>> >> >> sfc@ietf.org>>> >> >> https://www.ietf.org/mailman/listinfo/sfc>>= > >> >>>>> >> >>>> >> >_______________________________________________>>> >= > >sfc mailing list>>> >> >sfc@ietf.org>>> >> >https://www.ietf.org/mailman= /listinfo/sfc>>> >>>>> >> _______________________________________________>>= > >> sfc mailing list>>> >> sfc@ietf.org>>> >> https://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 listsfc@ietf.orghttps://www.ietf.org/mailman/li= stinfo/sfc ------=_Part_3098_1010221885.1405095108293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, the draft seem= s to indicate that if you want this distributed behavior, you need to re-cl= assify onto a new SFP.  If that is not the intent of the draft, then i= t is unclear.





From: mohamed.boucadair@orange.com<mo= hamed.boucadair@orange.com>
To: Jim Guichard (jguichar)<jgu= ichar@cisco.com>,NAPIERALA, MARIA H<mn1921@att.com>,Joel M. Halper= n<jmh@joelhalpern.com>,Ron Parker<Ron_Parker@affirmednetworks.com&= gt;,sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014<= br>Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
<= br>Re-,

For what I can say at best this is not descri= bed clearly in the draft.

Mandating a service path identifier is in= itself a hint that the full distributed model is not allowed.

Sever= al voices in this thread indicated that the service chain itself should be = provided instead.

Cheers,
Med

>-----Message d'origine-= ----
>De : sfc [mailto:s= fc-bounces@ietf.org] De la part de Jim Guichard
>(jguichar)
&g= t;Envoy=C3=A9 : vendredi 11 juillet 2014 16:18
>=C3=80 : NA= PIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org
>Objet : Re: [sfc] Service Chains, Paths, a= nd Load Balancers


>
>Ok but where= in the architecture specifically is this functionality
>p= rohibited? If you want to distribute *all* next-hops to *all* SFF=E2=80=99s=
>within the SFC domain and then let the path identifier p= oint to a lookup
>into those next-hops to reach the next S= F in the chain, I am not sure how
>the architecture preven= ts that?
>
>On 7/11/14, 9:58 AM, "NAPIERA= LA, MARIA H" <mn1921@att.com> wrote:
>
>>Absolutely.
>>
>>> ----= -Original Message-----
>>> From: sfc [mailto:sfc-bou= nces@ietf.org] On Behalf Of Jim Guichard
>>>(jguicha= r)
>>> Sent: Friday, July 11, 2014 9:54 AM
>>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc= @ietf.org
>>> Subject: Re: [sfc] Service Chains, Pat= hs, and Load Balancers
>>>
>>>= ; Then I misunderstand the proposal ;-) .. However, it seems to me that if<= br class=3D"">>>> you allow an SFF to make a decision as to which = remote SFF it will use
>>>for
>>= > a given flow to reach the next SF within the chain then you better mak= e
>>> sure that that remote SFF has the necessary fo= rwarding logic to reach
>>>the
>>= ;> next-next-SF for the chain as otherwise you are in deep trouble.
>>>
>>> On 7/11/14, 9:48 AM, "NAP= IERALA, MARIA H" <mn1921@att.com> wrote:
>>>>>> >Absolutely not. Service chains can be instant= iated only in relevant
>>>SFFs
>>= ;> >when they "arrive".
>>> >
>>> >> -----Original Message-----
>>>= ; >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichar= d
>>> >>(jguichar)
>>> = >> Sent: Friday, July 11, 2014 9:27 AM
>>> >= ;> To: Joel M. Halpern; Ron Parker; sfc@ietf.org
>>&= gt; >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>> >>
>>> >> Well= I think it is even worse than that if I have understood the
= >>> >>proposal
>>> >> correctly= as it would require full knowledge of every single SF
>&g= t;>within
>>> >>the
>>&= gt; >> entire SFC domain at every single SFF as there is no way to kn= ow a
>>> >>priori
>>> &= gt;> which SFC=C2=B9s a given SFF will need to service at any given poin= t in
>>>time.
>>> >>>>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" &= lt;jmh@joelhalpern.com> wrote:
>>> >>
>>> >> >Ron, thinking about this, I realized ano= ther major problem with the
>>> >>your
>>> >> >proposal as I understand it. (And I readi= ly admit I may not
>>>understand
>&= gt;> >> >it.)
>>> >> >
>>> >> >The proposal has each SFF serve as the load= balancer for the next
>>> >> >service func= tion that follows it (not the one it delivers to), in
>>= ;>every
>>> >> >service chain that goes = through it.
>>> >> >
>>= > >> >Since it has to be able to work with all services, that m= eans that
>>> >>every
>>&g= t; >> >SFF would have to be a full, flow sensitive and stateful lo= ad
>>>balancer.
>>> >> = >I ahve no problem if some SFF are flow sensitive, and / or stateful.>>> >> >But having the architecture require t= hat every SFF be a full, flow
>>> >> >sensi= tive, stateful, load balancer seems to me to be an acceptable
>>> >> >imposition.
>>> >> = >
>>> >> >Yours,
>>&= gt; >> >Joel
>>> >> >
>>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>>> >> >> Part of my personal view is that= I am trying to make this work
>>> >>sensibly<= br class=3D"">>>> >> >> in a more orchestrated environ= ment. I expect that the service
>>> >> >&g= t; functions, and over time probably the SFF capabilities, will be
>>> >> >> orchestrated and installed. I expect = the service chains to be
>>> >>driven by
>>> >> >> BSS tools that define offerings to = clients, and enable
>>>self-selection
= >>> >> >> from these. I expect service paths to be he= avily policy drive.
>>> >> >>
>>> >> >> I can see how to make all of that work= in an archtiecture driven
>>>by
>&= gt;> >> >> initial classification to described service paths= . It is harder
>>>to
>>> >= ;>see
>>> >> >> how to make it work (= but it can be done) when we allow more
>>> >> = dynamicity
>>> >> >> in the network beha= vior.
>>> >> >>
>>&g= t; >> >> Having said that, most of that perspective I described= is outside
>>>of
>>> >>= ;the
>>> >> >> scope of the working grou= p. it is not something we are tasked to
>>> >>= ;agree
>>> >> >>on.
>&g= t;> >> >> So I do not claim that vision means we have to do = it a certain
>>>way.
>>> >= >it
>>> >> >> is just the perspective= that drives my preferences.
>>> >> >>>>> >> >> Yours,
>>&g= t; >> >> Joel
>>> >> >>
>>> >> >> On 7/10/14, 9:58 PM, Ian Smith wro= te:
>>> >> >>>> For me, the amount= of information about service instances that
>>> >= ;>needs
>>> >> >>>>to
>>> >> >>>> be widely distributed and main= tained, potentially even across
>>>data
>>> >> >>>> centers within an administrative s= cope, is large enough and
>>> complex
= >>> >> >>>> enough that trying to get that into = each SFF seems like a
>>>difficult
>= ;>> >> >>>> architecture to realize.
= >>> >> >>>
>>> >> >= >> I'm curious as to why that is more complicated than dynamic
>>> routing,
>>> >> >>&= gt; hyper-scale data center orchestration, or DNS, all of which are
>>> >>bigger
>>> >> >= >> problems that have been profitably and stably implemented?
>>> >> >>>
>>> >&g= t; >>> It also seems that if it really is more complicated, that i= s a
>>>good
>>> >> >= >> sign that it is too complicated.
>>> >&g= t; >>>
>>> >> >>> __________= ______________________________
>>> >> >>= > From: Joel M. Halpern [jmh@joelhalpern.com]
>>>= >> >>> Sent: Thursday, July 10, 2014 9:45 PM
= >>> >> >>> To: Ron Parker; Joel Halpern Direct; mik= ebianc@aol.com; Ian
>>>Smith;
>>= > >> >>> sfc@ietf.org
>>> >>= >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= br class=3D"">>>> >> >>>
>>>= >> >>> This is an architectural issue. And one that I woul= d prefer we
>>> >> >>>actually
>>> >> >>> decide, rather than trying to al= low all possible implementations.
>>> >> >&= gt;> Because it does have a major effect on the control requirements
>>>and
>>> >> the
>>> >> >>> functionality of SFFs.
>>> >> >>>
>>> >> &= gt;>> For me, the amount of information about service instances that<= br class=3D"">>>> needs
>>> >> to
>>> >> >>> be widely distributed and mai= ntained, potentially even across
>>>data
>>> >> >>> centers within an administrative scop= e, is large enough and
>>>complex
>= >> >> >>> enough that trying to get that into each SFF= seems like a
>>>difficult
>>>= ; >> >>> architecture to realize.
>>>= >> >>>
>>> >> >>> You= rs,
>>> >> >>> Joel
>= ;>> >> >>>
>>> >> >>= ;> But it is a fair question.
>>> >> >&g= t;>
>>> >> >>> On 7/10/14, 9:38 PM= , Ron Parker wrote:
>>> >> >>>> Th= is is the crux of my issue.   Is the end to end selection of
>>> >> >>>> (top-level) instances performe= d centrally (perhaps by the
>>> >>classifier)<= br class=3D"">>>> >> >>>> or hop-by-hop (perhaps= by the classifier and subsequently the
>>> >>= SFFs)?
>>> >> >>>> Such selection = is not equivalent to reclassification.   And
>>>= ;surely,
>>> >> >>>> this is an ar= chitectural issue and not relegated to
>>> >> = >>>> "implementation".
>>> >> >= >>>
>>> >> >>>> My own vi= ew is to favor the distributed approach even though a
>>= ;> >> >>>> greater amount of data (chain definitions a= nd perhaps local
>>> >>selection
>>> >> >>>> policy) is required at those distri= buted decision points.   This
>>> >> >= >>> approach does not require an end-to-end path id at all.  =   My
>>> >> >>>> rationale fo= r favoring this approach is primarily driven by
>>> = >>increased
>>> >> >>>> resi= liency over the global path id approach.   With a global
>>>path
>>> >>id
>&= gt;> >> >>>> approach, consider failure of an instance= and needing to alter
>>>the
>>&= gt; >> >>>> global path ID table for each and every affec= ted end-to-end
>>>path.
>>> &= gt;> >>>>
>>> >> >>>&g= t; Ron
>>> >> >>>>
&= gt;>> >> >>>> _____________________________________= ___ From: sfc
>>> >> >>>> [sfc-bou= nces@ietf.org] on behalf of Joel Halpern Direct
>>> = >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July= 10, 2014 6:15
>>> PM
>>> >= ;> >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org = Subject: Re:
>>> >> >>>> [sfc] Ser= vice Chains, Paths, and Load Balancers
>>> >> = >>>>
>>> >> >>>> The w= ay the architecture models the case of SF1 needing to
>>= ;> >>influence
>>> >> >>>>= ; the chain is that one would do reclassification at the exit from
>>> >> >>>> SF1.
>>>= ; >> >>>>
>>> >> >>>= ;> Part of the goal is to keep the different functions logically
>>> >> >>>> separate so that solutions ca= n clearly describe how they choose
>>>to
>>> >> >>>> compose them for "service" delive= ry.
>>> >> >>>>
>= >> >> >>>> Yours, Joel
>>> &= gt;> >>>>
>>> >> >>>&g= t; On 7/10/14, 6:10 PM, mikebianc@aol.com wrote:
>>>= >> >>>>> I don't see anything in the arch draft that = suggests any sort
>>>of
>>> &= gt;> >>>>> limit. However, it does seem to indicate that = the entire path
>>>(all
>>> &= gt;> >>>>> SFIs) must be chosen at SFC instantiation. I = believe this
>>>means
>>> >= ;> >>>>> either at the classifier or maybe the classifier= chooses a SF
>>> >>Chain
>&g= t;> >> >>>>> and the NF or at the latest the first = SFF. In any case, the
>>> >> >>>>= > language does seem to prohibit a more dynamic SFP where SFI(n)
>>> is
>>> >> >>>>= > determined at the SFI(n-1) hop. According to the draft, this
>>> >> >>>>> behavior would be consider= ed "branching" to a new SFP as
>>> opposed
>>> >> to
>>> >> >>= >>> choosing and then forwarding to the selected instance of the>>> >> >>>>> next-hop of the cur= rent SFC.
>>> >> >>>>>
>>> >> >>>>> draft-merged-sfc-architect= ure-00:
>>> >> >>>>>> When a= n SFC is instantiated into the network it is necessary
>&g= t;>to
>>> >> >>>>>> selec= t the specific instances of SFs that will be used, and to
>= ;>> >> >>>>>> create the service topology for= that SFC using SF's network
>>> >> >>&g= t;>>> locator. Thus, instantiation of the SFC results in the
>>>creation
>>> >> >>= >>>> of a Service Function Path (SFP) and is used for forwardin= g
>>> >> >>>>>> packets thro= ugh the SFC. In other words, an SFP is the
>>> >&= gt; >>>>>> instantiation of the defined SFC.
>>> >> >>>>>>
>>>= >> >>>>>> The SFC architecture supports reclassifi= cation (or non-initial
>>> >> >>>>= >> classification) as well. As packets traverse an SFP,
>>> >> >>>>>> reclassification may occur= - typically performed by a
>>> >> >>>= ;>>> classification function co-resident with a service function.<= br class=3D"">>>> >> >>>>>> Reclassificati= on may result in the selection of a new SFP, an
>>> = >> >>>>>> update of the associated metadata, or bot= h. This is referred
>>>to
>>>= ; >> >>>>>> as "branching".
>>&= gt; >> >>>>>
>>> >> >&= gt;>>>
>>> >> >>>>>>>> >> >>>>>
>&g= t;> >>
>>>
>>>>&g= t;>>>>>-----------------------------------------------------= -------------
>>>>>>>>>>--
>>> >>>>>>>--
>>= ;> >> >>>>>--
>>> >> &= gt;>>>>
>>> >> >>>>>= ;
>>> >> >>>>>
&g= t;>> >> >>> *From: *I.Smith@F5.com<I.Smith@F5.com&g= t;
>>> >> >>>>> *To: *Joel Halp= ern Direct<jmh.direct@joelhalpern.com>,Joel M.
>>= > >> >>>>>
>>> >>
>>> >>>>>Halpern<jmh@joelhalpern.com&g= t;,huang@sce.carleton.ca<huang@sce.
>>> >> = carleton.
>>> >> >>>>>ca>,sf= c@ietf.org<sfc@ietf.org>
>>> >> >>= >>>
>>> >> >>>>>
>>> >> >>>>>
>>&= gt; >> >>> *Sent: *Thursday, July 10, 2014
>= ;>> >> >>>>> *Subject: *Re: [sfc] Service Chains= , Paths, and Load Balancers
>>> >> >>>= ;>>
>>> >> >>>>> Actually= , I think I am disagreeing.
>>> >> >>>= ;>>
>>> >> >>>>> If the p= ossibility of medium-scale deployments (and that is
>>&= gt;what
>>> >> >>>>> 16 million= flows is in my world) of service chains is
>>>preco= nceived
>>> >> >>>>> as an absu= rd idea, then the architecture burdened with that
>>>= ; >> >>>>> preconception.
>>> &= gt;> >>>>>
>>> >> >>&g= t;>> There has to be some point of aim, some degree of aspiration to<= br class=3D"">>>> >> >>>>> scale that is appr= opriate for the lifespan of the architecture
>>>->>> >> >>>>> you don't have to kn= ow what it is, but by saying that an
>>>arbitrary>>> >> >>>>> number is "too far",= you're creating - even if it isn't
>>> >>inte= ntional
>>> >> >>>>> - a limit = that influences decisions that have lasting impacts
>>&= gt; >> >>>>> regarding scale-out, failure mitigation, = elasticity, address
>>> >> >>>>>= ; space... all kinds of things. That is a problem I'm not
>= ;>> >> >>>>> particularly eager to deal with.>>> >> >>>>>
>&g= t;> >> >>>>>
>>> >> &g= t;>>>>
>>> >> >>>>>=
>>> >> >>>>> _________________= _______________________
>>> >> >>>>= ;>
>>> >> >>>>>
>>> >> >>>>> From: Joel Halpern Direct [jmh= .direct@joelhalpern.com] Sent:
>>> >> >>= >>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern= ;
>>> >> >>>>> huang@sce.carlet= on.ca; sfc@ietf.org Subject: Re: [sfc] Service
>>> &= gt;> >>>>> Chains, Paths, and Load Balancers
>>> >> >>>>>
>>> >= ;> >>>>> Ian, I don't think you disagree with me at all i= n this regard.
>>>I
>>> >&= gt;am
>>> >> >>>>> not requesti= ng the the architecture or the solution prohibit
>>>= >> >>>>> deployments in the specific fashion. I am ob= jecting to Huang's
>>> >> >>>>>= reading of my note as saying that such deployments are required
>>> >> >>>>> they by the archtiecture.<= br class=3D"">>>> >> >>>>>
>= >> >> >>>>> As I have said repeatedly, I am not = trying to prohibit such
>>> >> >>>>= ;> things. Whether they are a good idea or not depends upon many
>>> >> >>>>> factors outside of the sc= ope of the WG. I happen to think that
>>> >>th= ey
>>> >> >>>>> are usually a b= ad idea.
>>> >> >>>>>
>>> >> >>>>> But the archtiecture si ca= refully avoiding attempting to know
>>>what
>>> >> >>>>> is and is not eployable.>>> >> >>>>>
>&= gt;> >> >>>>> Yours, Joel
>>>= ; >> >>>>>
>>> >> >>= ;>>> On 7/10/14, 5:01 PM, Ian Smith wrote:
>>&= gt; >> >>>>>> I disagree.
>>>= ; >> >>>>>>
>>> >> >= ;>>>>> We routinely have stateful devices that manage tens o= f
>>>millions
>>> >> &g= t;>>>>> of
>>> >> >>>&= gt;> concurrent flows in both access network and data center
>>> >> >>>>> environments today. You can't= seriously believe that in the
>>> >> >>= >>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only<= br class=3D"">>>> >> going
>>> >&g= t; >>>>> to have small numbers of service chains with equall= y small
>>> numbers
>>> >&= gt; >>>>> of active service paths?
>>>= ; >> >>>>>>
>>> >> >= ;>>>>> Your sounds too much like "no one will ever need more= than
>>> 64K"
>>> >> &= gt;>>>>> for
>>> >> >>>= ;>> comfort.
>>> >> >>>>>= >
>>> >> >>>>>>
>>> >> >>>>>> ______________________= __________________ From: sfc
>>> >> >>&g= t;>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern
>>> >> >>>>> [jmh@joelhalpern.com]
>>> >> >>>>>> Sent: Thursday, Ju= ly 10, 2014 4:46 PM To:
>>>huang@sce.carleton.ca;>>> >> >>>>>> sfc@ietf.org Sub= ject: Re: [sfc] Service Chains, Paths, and
>>>Load>>> >> >>>>>> Balancers
>>> >> >>>>>>
>&= gt;> >> >>>>>> No, it will mean that if someone = tries to deploy the
>>>archtieture
>= ;>> >> >>>>>> particularly badly, they will e= xceed the limits of their
>>> >> >>>&= gt;>> devices. The architecture does not require such absurd use of>>> >> >>>>>> service paths. = Since I can not figure out how to write
>>> >>= >>>>>> architectural words to prohibit it, the architect= ure does
>>>permit
>>> >&g= t; >>>>>> such abuse.
>>> >>= >>>>>>
>>> >> >>>&= gt;>> Please do not read my saying that the archtiecture permits
>>> >> >>>>>> something as sayin= g it is either deisred or required by the
>>>work.>>> >> >>>>>> It isn't.
>>> >> >>>>>>
>&= gt;> >> >>>>>> Yours, Joel
>>= ;> >> >>>>>>
>>> >>= >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:
>>> >> >>>>>>> If you need to= support 100 service chains, it will mean
>>> >&g= t; >>>>>>> 16,000,000 paths. That is larger than the r= outing table of a
>>> >> >>>>>&= gt;> core router.
>>> >> >>>>&g= t;>>
>>> >> >>>>>>>= Chang
>>> >> >>>>>>>
>>> >> >>>>>>> On 07/10/2014= 01:15 PM, Joel M. Halpern wrote:
>>> >> >&= gt;>>>>>> The architecture allows a range of deployments,= from 1
>>> >> >>>>>>>>= ; service path to 160000 service paths. I would hope that
>= ;>> >> >>>>>>>> operators are prepared = for the complexities if they choose
>>>to
>>> >> >>>>>>>> avoid any use = of local load balancing and in stead provision
>>> &= gt;> >>>>>>>> 160,000 service paths.
>>> >> >>>>>>>>
>= ;>> >> >>>>>>>> Yours, Joel
>>> >> >>>>>>>>
>= ;>> >> >>>>>>>> On 7/10/14, 4:06 PM, NA= PIERALA, MARIA H wrote:
>>> >> >>>>= ;>>>>> Paul,
>>> >> >>>= ;>>>>>>
>>> >> >>>&= gt;>>>>> How many path identifiers there will be for a 4 hop= service
>>> >> >>>>>>>&g= t;> chain with 20 instances at each hop?
>>> >= > >>>>>>>>>
>>> >&g= t; >>>>>>>>> Maria
>>> &g= t;> >>>>>>>>>
>>> >= > >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ie= tf.org] *On Behalf Of
>>> >> >>>>&= gt;>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:0= 3
>>> >> >>>>>>>>> = PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;
>>> &g= t;> >>>>>>>>> mohamed.boucadair@orange.com; s= fc@ietf.org;
>>> >> >>>>>>&g= t;>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains,
>>> >> >>>>>>>>> Paths, and= Load Balancers
>>> >> >>>>>>= ;>>>
>>> >> >>>>>>&= gt;>> Lucy,
>>> >> >>>>>&= gt;>>>
>>> >> >>>>>>= ;>>> Overall I concur, as you say: a path ID drives the
>>> >> >>>>>>>>> forwarding= . I=C2=B9d
>>> >> >>>>> make>>> >> >>>>>>>>> the = minor change: the path identifier can be used to derive
>&= gt;> >> >>>>>>>>> the needed forwarding= and associated transport.
>>> >> >>>= >>>>>>
>>> >> >>>&g= t;>>>>> It is _not_ the transport, but rather is used to sim= ply
>>> >> >>>>>>>>>= ; identify the service path (or graph) that packets must
>= >> >> >>>>>>>>> traverse. By having = a path identifier, the exact
>>> >> >>&g= t;>>>>>> indirection that people seem to be asking for on= this
>>> >> >>>>>>>>&= gt; thread can be simply be implemented. The path identifier
= >>> >> >>>>>>>>> provides nothing= more than a lookup, that lookup can result
>>> >= > >>>>>>>>> in a one or more (equal or weight= ed) transport next
>>> >> >>>>>= >>>> hop(s).
>>> >> >>>&g= t;>>>>>
>>> >> >>>>= >>>>> Paul
>>> >> >>>&= gt;>>>>>
>>> >> >>>>= ;>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong
>>> >> >>>>>>>>> <lucy.yong@h= uawei.com <mailto:lucy.yong@huawei.com>>
>>>= ; >> >>>>>>>>> wrote:
>&g= t;> >> >>>>>>>>>
>>= > >> >>>>>>>>>
>>&g= t; >> >>>>>>>>>
>>>= >> >>>>>>>>> Agree. The arch. doc should = not mandate only use of the
>>> >> >>>= ;>>>>>> service path identifier to drive the forwarding a= ctions.
>>> >> >>>>>>>>= ;>
>>> >> >>>>>>>>&= gt; Lucy
>>> >> >>>>>>>&g= t;>
>>> >> >>>>>>>>= > *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf
>&= gt;> >> >>>>>>>>> Of*mohamed.boucadair@= orange.com
>>> >> >>>>>>>= >> <mailto:mohamed.boucadair@orange.com>
>>= > *Sent:*Thursday,
>>> >> July
>>> >> >>>>>>>>> 10, 2014 2:06 = AM *To:*mikebianc@aol.com
>>> >> >>>&= gt;>>>>> <mailto:mikebianc@aol.com>;jmh@joelhalpern.co= m
>>> >> >>>>>>>>> = <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>>> = >> >>>>>>>>> <mailto:sfc@ietf.org> *= Subject:*Re: [sfc] Service Chains,
>>> >> >= >>>>>>>> Paths, and Load Balancers
&g= t;>> >> >>>>>>>>>
>= >> >> >>>>>>>>> Re-,
&= gt;>> >> >>>>>>>>>
>= ;>> >> >>>>>>>>> The merged draft ca= lls out explicitly a service path
>>> >> >&= gt;>>>>>>> identifier. I object to use that identifier= to derive
>>> >> >>>>>>>= >> forwarding actions.
>>> >> >>&g= t;>>>>>>
>>> >> >>>= >>>>>> Requiring a SFC system to have the full knowledge = of every
>>> >> >>>>> available= SFC
>>> >> >>>>>>>>&g= t; forwarding paths within an SFC-enabled domain is not
>&= gt;> >> >>>>> required/justified
>= >> >> >>>>>>>>> nor possible in vari= ous deployment contexts.
>>> >> >>>&g= t;>>>>>
>>> >> >>>>= >>>>> SFC forwarding actions should rely on the piece of
>>> >> >>>>>>>>> infor= mation
>>> >> >>>>> that will>>> >> >>>>>>>>> be = present in all deployments: that is the one required to
>&= gt;> >> >>>>>>>>> structure a service c= hain. How that information is used to
>>> >> &= gt;>>>>>>>> infer forwarding
>>= > >> >>>>> actions
>>> >&= gt; >>>>>>>>> is a solution-oriented discussion.=
>>> >> >>>>>>>>>>>> >> >>>>>>>>> Che= ers,
>>> >> >>>>>>>>&g= t;
>>> >> >>>>>>>>>= Med
>>> >> >>>>>>>>&g= t;
>>> >> >>>>>>>>>= *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part
>>&= gt; >> >>>>> de*mikebianc@aol.com
>&g= t;> >> >>>>>>>>> <mailto:mikebianc@a= ol.com> *Envoy=C3=A9 :*mercredi 9 juillet
>>> >= ;> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhal= pern.com
>>> >> >>>>>>>&g= t;> <mailto:jmh@joelhalpern.com>;sfc@ietf.org
>&g= t;> >> >>>>>>>>> <mailto:sfc@ietf.or= g> *Objet :*Re: [sfc] Service Chains,
>>> >>= ; >>>>>>>>> Paths, and Load Balancers
>>> >> >>>>>>>>>
>>> >> >>>>>>>>> Is anyone = still questioning the difference between SF Chain
>>>= ; >> >>>>>>>>> and SF
>&g= t;> >> >>>>> Path?
>>> >&= gt; >>>>>>>>> Other than clarifying the definiti= on so that it's clear to
>>> >> >>>&g= t;> those not
>>> >> >>>>>&g= t;>>> familiar with the draft, it seems that everyone agrees on>>> >> >>>>>>>>> thes= e terms.
>>> >> >>>>>>>&g= t;>
>>> >> >>>>>>>>= > To me, the one point that is still unclear is whether it is
>>> >> >>>>>>>>> the intent= of this draft to ultimately specify what the ID
>>>= >> >>>>>>>>> of the SFC Header
>>> >> >>>>> should
>&= gt;> >> >>>>>>>>> reference (the chain = or the path), or if this draft simply
>>> >> &= gt;>>>>>>>> intends to leave that ambiguous, allowi= ng other drafts to
>>> >> >>>>>= >>>> dictate the mechanisms for forwarding based on chain or>>> >> >>>>>>>>> path= and the choice of chain or
>>> >> >>>= ;>> path to
>>> >> >>>>>&= gt;>>> be negotiated in the control-plane.
>>&= gt; >> >>>>>>>>>
>>>= ; >> >>>>>>>>> If the latter (ambiguous), = then the draft would have
>>> >> >>>&= gt;>>>>> require that both SFP and SFC be supported (or make= one
>>> >> >>>>>>>>&g= t; required and the other optional) to avoid some vendors only
>>> >> >>>>>>>>> supporting SFP= and others only supporting SFC.
>>> >> >&g= t;>>>>>>>
>>> >> >>= >>>>>>>
>>> >> >>&g= t;>>
>>> >>
>>>>>>>>>>>>>----------------------= --------------------------------------------
>>>>= >>>>>>--
>>> >>>>>&= gt;>--
>>> >> >>>>>--
>>> >> >>>>>
>>&g= t; >> >>>>>
>>> >> >&g= t;>>>
>>> >> >>>>>>= >
>>> >> >>>>>>>>&g= t; *From:*jmh@joelhalpern.com<jmh@joelhalpern.com
>>= > >> >>>>>>>>> <mailto:jmh@joelhalpe= rn.com%3cjmh@joelhalpern.com>>
>>> >> &g= t;>>>>>>>> *To:*sfc@ietf.org<sfc@ietf.org
>>> >> >>>>>>>>> <mail= to:sfc@ietf.org%3csfc@ietf.org>> *Sent:*Tuesday, July
&= gt;>> >> >>>>>>>>> 8, 2014 *Subject:= *[sfc] Service Chains, Paths, and Load
>>> >> = >>>>>>>>> Balancers
>>> &= gt;> >>>>>>>>>
>>> >= ;> >>>>>>>>> I have been trying to figure out= how to clearly answer a
>>> >> >>>&g= t;>>>>> number of comments that have been made about the
>>> proposed
>>> >> >&g= t;>>>>>>> merged archtiecture draft. Assuming we can g= et working
>>> >> >>>>>>>= >> group agreement on the intent, we will work to improve the
>>> >> >>>>>>>>> wording s= o that readers who have not participated in the WG
>>&g= t; >> >>>>>>>>> discussion will understnd = it the way the
>>> >> >>>>> wor= king
>>> >> >>>>>>>>&g= t; group intends.
>>> >> >>>>>&= gt;>>>
>>> >> >>>>>>= ;>>> But what do we intend? I will try to explain my personal
>>> >> >>>>>>>>> view, = and see if that helps.
>>> >> >>>>= >>>>>
>>> >> >>>>&g= t;>>>> In this regard, it is important to keep in mind that wha= t
>>> >> >>>>>>>>> = we are defining is the data plane architecture. We are not
&g= t;>> >> >>>>>>>>> attempting to defi= ne the architecture for the entire
>>> >> >= >>>>>>>> solution for service chaining. That would = encompass
>>> >> >>>>>>>&= gt;> OSS/BSS, various control and policy functions, virtual
>>> >> >>>>>>>>> machine and im= age management, and many other aspects.
>>> >>= >>>>>>>>>
>>> >> &= gt;>>>>>>>> As a result there are many things which= clearly need to
>>> >> >>>>>&g= t;>>> exist in the larger system, but which are dealt with above>>> >> >>>>>>>>> whe= re we are
>>> >> >>>>> function= ing,
>>> >> >>>>>>>>&g= t; and are not directly required by the work we are doing.
&g= t;>> >> >>>>>>>>>
>= >> >> >>>>>>>>> In order to get to s= ervice chain vs service path, as I
>>> >> >= >>>>>>>> understand
>>> >= > >>>>> them,
>>> >> >>= ;>>>>>>> I need to first discuss load balancing. There= are at least
>>> >> >>>>>>&= gt;>> three different ways that load balancing can and will
>>> >> >>>>>>>>> interact w= ith service chaining. There probably are more.
>>> &= gt;> >>>>>>>>> The point of the archtiecture = is to permit all of these,
>>> >> >>>= >>>>>> but not to mandate that any particular kind
>>> >> >>>>> be used
&g= t;>> >> >>>>>>>>> in any solution.>>> >> >>>>>>>>>
>>> >> >>>>>>>>> 1) Lo= ad balancing as a service provided to the end user.
>>&= gt; >> >>>>>>>>> This is a service functio= n. It receives user packets, and
>>> >> >&g= t;>>>>>>> modifies them (or
>>>= >> >>>>> marks
>>> >> &g= t;>>>>>>>> them, or ...) so as to choose an end use= r service instance
>>> >> >>>>>= >>>> to receive the users packet. This is an important service<= br class=3D"">>>> >> >>>>>>>>> fu= nction to be able to include in service chaining. It's
>&g= t;> >> >>>>>>>>> behavior may affect re= quirements on how service chaining is
>>> >> &= gt;>>>>>>>> done. But it has very little impact on = the archtiecture.
>>> >> >>>>>&= gt;>>> From an architectural pe3rspective it is simply a
>>> >> >>>>> service
>= >> >> >>>>>>>>> function which may m= odify the underlying packet.
>>> >> >>&g= t;>>>>>>
>>> >> >>>= >>>>>> 2) There is internal load balancing. That is, one = can have
>>> >> >>>>>>>&g= t;> what
>>> >> >>>>> appear= s
>>> >> >>>>>>>>> = to the service chaining architecture as a single point of
>= ;>> >> >>>>>>>>> contact
>>> >> >>>>> for a
>>&= gt; >> >>>>>>>>> specific service function= , but is actually delivered by a
>>> >> >&g= t;>>> collection of
>>> >> >>&g= t;>>>>>> virtual or physical machines, possibly including= one or
>>> >> >>>>>>>>= ;> several load balancers (for example using VRRP-like
>= ;>> >> >>>>>>>>> techniques to share= a MAC address.) mostly, this is
>>> >> >&g= t;>>>>>>> invisible to the service chaining data plane= mechanisms. It
>>> >> >>>>>>= ;>>> is likely that it is visible to various control mechanisms,>>> >> >>>>>>>>> suc= h as those responsible for scale-in, scale-out, and vm
>&g= t;> >> >>>>>>>>> instantiation. The arc= hitectural impact of permitting this
>>> >> &g= t;>>>>>>>> is largely that we need to be careful th= at our terminology
>>> >> >>>>>= >>>> does not lead
>>> >> >>= >>> readers to
>>> >> >>>>= ;>>>>> think we are prohibiting it.
>>&g= t; >> >>>>>>>>>
>>>= >> >>>>>>>>> 3) There can also be load ba= lancing done by selecting
>>> >> >>>&= gt;>>>>> packet paths for the service chaining that direct t= raffic
>>> >> >>>>>>>>= > to different places. We would not want to require that a
>>> >> >>>>>>>>> given service f= unction appear at only one place in the
>>> >>= >>>>>>>>> network.
>>> &= gt;> >>>>>>>>>
>>> >= ;> >>>>>>>>> It is of course the case that th= ese may be combined. I tend
>>> >> >>>= ;>>>>>> to
>>> >> >>&g= t;>> refer to
>>> >> >>>>>= ;>>>> the collection of entities that appear to service chainin= g
>>> >> >>>>>>>>> = as a single point as a cluster. Not because cluster is a
>= >> >> >>>>>>>>> good term. But becau= se I do not have another one. Thus, the
>>> >>= >>>>>>>>> point of type 3 load balancing
>>> >> >>>>> is to
>= >> >> >>>>>>>>> direct different sub= sets of traffic to different singular
>>> >> &= gt;>>>>>>>> or clustered service functions in diffe= rent places in the
>>> >> >>>>>= >>>> network.
>>> >> >>>&= gt;>>>>>
>>> >> >>>>= ;>>>>> Now with that said, what do I mean when I talk about<= br class=3D"">>>> >> >>>>>>>>> se= rvice chain and service path/ Service chain is a sequence
>= ;>> >> >>>>>>>>> of logical function= s to be applied to a subset of packets.
>>> >>= >>>>>>>>> It is equivalent of saying that some = subset of traffic is
>>> >> >>>>&g= t;>>>> to get DPI, charging, content inspection, and firewall>>> >> >>>>>>>>> whi= le a different subset is to go directly to the cache
>>= > >> >>>>> without
>>> >&= gt; >>>>>>>>> visiting any other service functio= ns.
>>> >> >>>>>>>>>= ;
>>> >> >>>>>>>>> = That is not enough information to direct the packets. A
>&= gt;> >> >>>>>>>>> service path is, in s= ome fashion, a sequence of locations
>>> >> &g= t;>>>>>>>> in the network. Those locations will be = singular or
>>> >> >>>>>>>= ;>> clustered service function delivery locations. They may be
>>> >> >>>>>>>>> addresse= d by IP address. They may be addressed as ports on
>>&g= t; >> >>>>>>>>> an SFF. There are many dif= ferent ways that the locations
>>> >> >>= >>>>>>> may be known to the service chaining infrastru= cture and the
>>> >> >>>>>>&= gt;>> transport.
>>> >> >>>>= >>>>>
>>> >> >>>>&g= t;>>>>> From the point of view of the work of the SFC group= , we
>>> >> >>>>>>>>&g= t;> need to be
>>> >> >>>>>&= gt;>>> able to talk about the high level abstraction, the service<= br class=3D"">>>> >> >>>>>>>>> ch= ain, which drives the forwarding. And we need to talk
>>= ;> >> >>>>>>>>> about the actual data p= ath packets will take in the
>>> >> >>&g= t;>>>>>> network.
>>> >> >= ;>>>>>>>>
>>> >> >&= gt;>>>>>>> Several of the comments have said "but the = whole path may
>>> >> >>>>>>= >>> not be known at the front." This architecture deals with
>>> >> >>>>>>>>> that is= sue in two ways. First, as noted in item (2) on load
>>= > >> >>>>>>>>> balancers above, there c= an be decisions and behaviors which
>>> >> >= ;>>>>>>>> are invisible to the service chaining mec= hanisms (in much
>>> >> >>>>>&g= t;>>> the same way that bridging within a LAN is largely
>>> >> >>>>>>>>> invisible = to routing between LANs.) The other provision we
>>>= >> >>>>>>>>> make is
>&g= t;> >> >>>>> that
>>> >&g= t; >>>>>>>>> reclassification can be done in mid= -chain when necessary.
>>> >> >>>>= >>>>> That will direct packets to a new chain. Based on
>>> >> >>>>>>>>> inform= ation available at the re-classification point.
>>> = >> >>>>>>>>>
>>> &g= t;> >>>>>>>>> I hope that this helps explain = what we are after. If it
>>> >> >>>&g= t;>>>>> does, and if the intent is acceptable to the working= group,
>>> >> >>>>>>>>= ;> we can figure out what additional words are needed to
&= gt;>> >> >>>>>>>>> convey this. If t= he working group disagree with the intent,
>>> >&= gt; >>>>>>>>> then we will of course adjust to m= atch the working group
>>> >> >>>>= >>>>> agreements. If this is still unclear, I am not sure wh= at to
>>> >> >>>>>>>>&= gt; try next.
>>> >> >>>>>>&= gt;>>
>>> >> >>>>>>>= ;>> Yours, Joel
>>> >> >>>>&= gt;>>>>
>>> >> >>>>>= ;>>>> _______________________________________________ sfc
>>> >> mailing
>>> >> = >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.= org>
>>> >> >>>>>>>>= ;> https://www.ietf.org/mailman/listinfo/sfc
>>> = >> >>>>>>>>>
>>> &g= t;> >>>>>>>>> _______________________________= ________________ sfc
>>> >> mailing
>>> >> >>>>>>>>> list sfc@i= etf.org <mailto:sfc@ietf.org>
>>> >> >= ;>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc=
>>> >> >>>>>>>>>>>> >> >>>>>>>>
>>> >> >>>>>>>> _____________= __________________________________ sfc
>>> >> = mailing
>>> >> >>>>>>>>= ; list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>> >> >>>>>>>>
>&= gt;> >> >>>>>>>
>>> &g= t;> >>>>>>> _______________________________________= ________ sfc
>>> >> mailing
>= >> >> >>>>>>> list sfc@ietf.org https://ww= w.ietf.org/mailman/listinfo/sfc
>>> >> >>= ;>>>>>
>>> >> >>>>&= gt;>
>>> >> >>>>>> ______= _________________________________________ sfc
>>> ma= iling
>>> >> list
>>> &= gt;> >>>>>> sfc@ietf.org https://www.ietf.org/mailman/= listinfo/sfc
>>> >> >>>>>>>>> >> >>>>>
>&= gt;> >> >>>>> _____________________________________= __________ sfc
>>> mailing
>>>= ; >> list
>>> >> >>>>> sf= c@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.org https://www.ietf.org/mailman/listi= nfo/sfc
>>> >> >>>>
= >>> >> >>>
>>> >> >= >
>>> >> >> _________________________= ______________________
>>> >> >> sfc mai= ling list
>>> >> >> sfc@ietf.org
>>> >> >> https://www.ietf.org/mailman/listinfo= /sfc
>>> >> >>
>>>= ; >> >
>>> >> >___________________= ____________________________
>>> >> >sfc ma= iling list
>>> >> >sfc@ietf.org
>>> >> >https://www.ietf.org/mailman/listinfo/sfc
>>> >>
>>> >> _______= ________________________________________
>>> >>= ; sfc mailing list
>>> >> sfc@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _________________________= ______________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf= .org/mailman/listinfo/sfc
>
>____________= ___________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/l= istinfo/sfc
_______________________________________________sfc mailing list
sfc@ietf.org
http= s://www.ietf.org/mailman/listinfo/sfc
------=_Part_3098_1010221885.1405095108293-- From nobody Fri Jul 11 09:13: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 36D911B2BB9 for ; Fri, 11 Jul 2014 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgjbPNIOCmm0 for ; Fri, 11 Jul 2014 09:13:26 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099B91B2B65 for ; Fri, 11 Jul 2014 09:13:25 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 62d00c35.2b9928873940.4686094.00-2486.12993006.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:13:26 +0000 (UTC) X-MXL-Hash: 53c00d2620675a3d-1d5efabba58719a87c2ff6a77561d7befd643dfa Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id cdc00c35.0.4685340.00-2377.12990836.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:12:14 +0000 (UTC) X-MXL-Hash: 53c00cde4f1c9f58-653dc88141df83f32aed22a2eb1257352038318e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGCBgj004040; Fri, 11 Jul 2014 12:12:12 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGC2eb003845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:12:06 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:11:46 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:11:46 -0400 From: "NAPIERALA, MARIA H" To: "mikebianc@aol.com" , "jmh@joelhalpern.com" , "jguichar@cisco.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEWlgP//vtHAAAjq1gAAA+VWgAAIUPGg Date: Fri, 11 Jul 2014 16:11:45 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AE9A@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> <202520617.3090.1405094963576.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <202520617.3090.1405094963576.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AE9AMISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=ABeY7kuGA] X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=qN95wPeSAAAA:8 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=jSkwWliSwC0xfCy9vjQA:9 a=QEXdDO2ut3YA:10 a=chC_agHSu74A:1] X-AnalysisOut: [0 a=Hz7IrDYlS0cA:10 a=JfD0Fch1gWkA:10 a=paC5pjApGzsA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=nMh0gQ] X-AnalysisOut: [tm7EpSAcBvXzYA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZ] X-AnalysisOut: [eC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=PEcOBfVcWN5Fs3_s:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PuoElCVodSNpcaNso2f_dZfsBhA Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:13:29 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AE9AMISOUT7MSGUSRCF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGUgYXJjaCBzaG91bGQgbm90IHByZXZlbnQgdGhpcywgYnV0ICIoZXZlbiBuZXcgZmxvd3Mp IiBpcyBoYXJkbHkgaWRlYWwuICBJIGNhbiBtYWtlIHRoZSBjYXNlIGZvciAiKG9ubHkgZXhpc3Rp bmcgZmxvd3MpIiAoc3RhdGVmdWwpIGFuZCBmb3IgIlNGRi1aMSBpcyBlbGlnaWJsZSBmb3IgYWxs IGZsb3dzLCBldmVuIGV4aXN0aW5nIG9uZXMiIChzdGF0ZWxlc3MpLg0KDQpZZXMsIHRoaXMgZ29l cyB3aXRob3V0IHNheWluZywgc28gdG8gc3BlYWsuDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVy bi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4N ClRvOiBOQVBJRVJBTEEsIE1BUklBIEg8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQu Y29tPj4sSmltIEd1aWNoYXJkIChqZ3VpY2hhcik8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20+PixSb24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5v cmc8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5 IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCg0KSnVzdCB0byBjaGVjaywgSSBhbSBnb2luZyB0byBnZXQgcGVkYW50 aWMuDQpXZSBoYXZlIFNGRi1YLCBpcyBzdXBwb3J0aW5nIChwb3NzaWJseSB2aWEgbG9jYWwgbG9h ZCBiYWxhbmNpbmcpIHNvbWUNCmNvbGxlY3Rpb24gb2YgbG9jYWwgc2VydmljZSBmdW5jdGlvbiBp bnN0YW5jZXMuDQpXaGVuIHBhY2tldHMgb24gYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGgg KFNGUC1ZKSBhcnJpdmUsIHRoZXkgYXJlDQpwcm9jZXNzZWQgYnkgdGhlb3NlIHNlcnZpY2UgZnVu Y3Rpb25zLCBhbmQgU0ZGLVggdGhlbiBoYXMgdG8gZm9yd2FyZCB0aGUNCnBhY2tldHMgKHdpdGgg c3VpdGFibGUgdHJhbnNwb3J0KSB0byBhIG5leHQgU0ZGLCB3aG8gbWF5IGxvY2FsbHkgYmFsYW5j ZQ0KYW1vbmcgaGlzIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzLg0KDQpGb3IgU0ZGLVggaGFu ZGxpbmcgU0ZQLVksIHRoZSBuZXh0IFNGRiBpcyAocG9zc2libHkgZ2VuZXJpY2FsbHkpIFNGRi1a Lg0KDQpXZSBjb25zaWRlciBmaXJzdCB0aGUgc3RhdGUgYXQgdGltZSBUMCB3aGVuIGEgcGFja2V0 IGFycml2ZXMgYXMgU0ZGLVggb24NClNGUC1ZIHdpdGggbm8gcHJpb3Igc3BlY2lhbCBzdGF0ZSBp biBTRkYtWCAob2J2aW91c2x5LCB0aGVyZSBpcyBzb21lDQpzdGF0ZSBhYm91dCBTRlAtWSwgYXMg d2UgZG8gbm90IHdhbnQgcG9saWN5IGxvb2t1cHMgYXQgcGFja2V0IGhhbmRsaW5nDQp0aW1lcy4p IEF0IHRoaXMgdGltZSBUMCwgdGhlcmUgZXhpc3QgaW4gdGhlIG5ldHdvcmsgU0ZGLVoxIGFuZCBT RkYtWjIuDQpJZiBJIHVuZGVyc3RhbmQgeW91ciByZXF1ZXN0LCB5b3Ugd2FudCBTRkYtWCB0byBw aWNrIG9uZSBvZiB0aG9zZSB0d28NClNGRiwgc2F5IFNGRi1aMS4gQW5kIHNlbmQgYWxsIHRoZSBw YWNrZXRzIGZvciBTRlAtWSBvbiB0byBTRkYtWjEuIEV2ZW4NCmlmIFNGRi1aMyBpcyBhZGRlZCB0 byB0aGUgbmV0d29yaywgYWxsIHBhY2tldHMgZm9yIGFsbCBmbG93cyB1c2luZyBTRlAtWQ0KYXQg U0ZGLVggKGV2ZW4gbmV3IGZsb3dzKSB3aWxsIGdldCBzZW50IGJ5IFNGRi1YIHRvIFNGRi1aMS4g VGhlIG9ubHkNCnRpbWUgU0ZGLVggd291bGQgY2hhbmdlIHRoYXQgaXMgaWYgZGlzY292ZXJlZCBv ciB3YXMgdG9sZCB0aGF0IFNGRi1aMQ0Kd2FzIGRvd24gb3IgdW5yZWFjaGFibGUuIEluIHRoYXQg Y2FzZSwgaXQgd291bGQgcGljayBhIG5ldyBvbmUgZnJvbQ0KYW1vbmcgdGhlIGtub3duIGNob2lj ZXMuDQoNCk1hcmlhLCBpZiB0aGF0IGlzIHdoYXQgeW91IHdvdWxkIGxpa2UsIEkgYmVsaWV2ZSB0 aGF0IGVpdGhlciBpcw0KY3VycmVudGx5IGFsbG93ZWQgYnkgdGhlIGFyY2hpdGVjdHVyZSBvciBj YW4gZWFzaWx5IGJlIGFkZGVkLiBBbmQgSSBhbQ0KaGFwcHkgdG8gZG8gc28uIEkgYmVsaWV2ZSB3 ZSBjYW4gZGVzY3JpYmUgdGhhdCBpbiB0aGUgcmVzaWxpZW5jZSBhbmQNCmZhaWx1cmUgcmVjb3Zl cnkgc2VjdGlvbiB0aGF0IHdlIG5lZWQgdG8gYWRkLg0KDQpCdXQgSSB3YW50IHRvIGJlIHJlYWxs eSBzdXJlIHRoYXQgaXMgd2hhdCB5b3Ugd2FudC4gSSBkb24ndCB0aGluayB0aGF0DQptZWV0cyBS b24ncyByZXF1ZXN0Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gNy8xMS8xNCwgMTA6MDcgQU0sIE5B UElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4gSm9lbCwNCj4NCj4+IEhtbS4gV291bGQgaXQgbWVl dCB5b3VyIGdvYWxzIE1hcmlhIGlmIGFsbCBwYWNrZXRzIHRoYXQgYXJyaXZlZCBhdA0KPj4gU0ZG LVggd2l0aCBTRlAtWSB3ZXJlIChhZnRlciBsb2NhbCBTRiBwcm9jZXNzaW5nKSBmb3J3YXJkZWQg dG8gc29tZQ0KPj4gc3BlY2lmaWMgU0ZGLVo/IFdoZXJlIFNGRi1aIHdhcyBzZWxlY3RlZCB3aGVu IHRoZSBmaXJzdCBwYWNrZXQgd2l0aA0KPj4gU0ZQLVkgYXJyaXZlZCBhdCBTRkYtWD8NCj4NCj4g WWVzLg0KPj4NCj4+IFdoaWxlIHRoYXQgaXMgbW9yZSBlYXNpbHkgbWV0LCB0aGF0IGRvZXMgbm90 IHNlZW0gbGlrZWx5IHRvIHByb2R1Y2UgdGhlDQo+PiBzY2FsZSBmbGV4aWJpbGl0eSB5b3UgYXNr ZWQgZm9yLiBBbmQgaWYgU0ZGLVggbWF5IGZvcndhcmQgcGFja2V0cyB3aXRoDQo+DQo+IFdoeSBu b3Q/DQo+DQo+PiBTRlAtWSB0byBTRkYtWjEgYW5kIFNGRi1aMiB0aGVuIFNGRi1YIGhhcyB0byBi ZSBzdGF0ZWZ1bCBhbmQgaGF2ZSB0aGUNCj4+IGNhcGFiaWxpdHkgdG8gZW5zdXJlIHRoYXQgYSBn aXZlbiBmbG93IGNvbnRpbnVlcyB0byBnbyB0byB0aGUgc2FtZSBuZXh0DQo+PiBTRkYgZXZlbiB3 aGVuIFNGRi1aMyBpcyBhZGRlZCB0byB0aGUgbWl4Lg0KPg0KPiBQcmVjaXNlbHkuDQo+DQo+DQo+ PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+Pj4gQWJz b2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbiBy ZWxldmFudCBTRkZzDQo+PiB3aGVuIHRoZXkgImFycml2ZSIuDQo+Pj4NCj4+IC4uLg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AE9AMISOUT7MSGUSRCF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPlRoZSBhcmNoIHNob3VsZCBub3QgcHJldmVudCB0aGlzLCBidXQgJnF1b3Q7KGV2ZW4g bmV3IGZsb3dzKSZxdW90OyBpcyBoYXJkbHkgaWRlYWwuICZuYnNwO0kgY2FuIG1ha2UgdGhlIGNh c2UgZm9yICZxdW90Oyhvbmx5IGV4aXN0aW5nIGZsb3dzKSZxdW90OyAoc3RhdGVmdWwpIGFuZCBm b3IgJnF1b3Q7U0ZGLVoxIGlzIGVsaWdpYmxlIGZvciBhbGwgZmxvd3MsIGV2ZW4NCiBleGlzdGlu ZyBvbmVzJnF1b3Q7IChzdGF0ZWxlc3MpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB0aGlzIGdvZXMgd2l0aG91 dCBzYXlpbmcsIHNvIHRvIHNwZWFrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIx IiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNl bnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjYuNzVwdCI+PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTNjam1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhh bHBlcm4uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFMQSwgTUFSSUEgSCZsdDs8 YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDssSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDssUm9uIFBhcmtlciZsdDs8YSBocmVmPSJtYWls dG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbTwvYT4mZ3Q7LHNmY0BpZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1 bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KPGJyPg0KSnVzdCB0byBjaGVjaywgSSBh bSBnb2luZyB0byBnZXQgcGVkYW50aWMuPGJyPg0KV2UgaGF2ZSBTRkYtWCwgaXMgc3VwcG9ydGlu ZyAocG9zc2libHkgdmlhIGxvY2FsIGxvYWQgYmFsYW5jaW5nKSBzb21lIDxicj4NCmNvbGxlY3Rp b24gb2YgbG9jYWwgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMuPGJyPg0KV2hlbiBwYWNrZXRz IG9uIGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBwYXRoIChTRlAtWSkgYXJyaXZlLCB0aGV5IGFy ZSA8YnI+DQpwcm9jZXNzZWQgYnkgdGhlb3NlIHNlcnZpY2UgZnVuY3Rpb25zLCBhbmQgU0ZGLVgg dGhlbiBoYXMgdG8gZm9yd2FyZCB0aGUgPGJyPg0KcGFja2V0cyAod2l0aCBzdWl0YWJsZSB0cmFu c3BvcnQpIHRvIGEgbmV4dCBTRkYsIHdobyBtYXkgbG9jYWxseSBiYWxhbmNlIDxicj4NCmFtb25n IGhpcyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcy48YnI+DQo8YnI+DQpGb3IgU0ZGLVggaGFu ZGxpbmcgU0ZQLVksIHRoZSBuZXh0IFNGRiBpcyAocG9zc2libHkgZ2VuZXJpY2FsbHkpIFNGRi1a Ljxicj4NCjxicj4NCldlIGNvbnNpZGVyIGZpcnN0IHRoZSBzdGF0ZSBhdCB0aW1lIFQwIHdoZW4g YSBwYWNrZXQgYXJyaXZlcyBhcyBTRkYtWCBvbiA8YnI+DQpTRlAtWSB3aXRoIG5vIHByaW9yIHNw ZWNpYWwgc3RhdGUgaW4gU0ZGLVggKG9idmlvdXNseSwgdGhlcmUgaXMgc29tZSA8YnI+DQpzdGF0 ZSBhYm91dCBTRlAtWSwgYXMgd2UgZG8gbm90IHdhbnQgcG9saWN5IGxvb2t1cHMgYXQgcGFja2V0 IGhhbmRsaW5nIDxicj4NCnRpbWVzLikgQXQgdGhpcyB0aW1lIFQwLCB0aGVyZSBleGlzdCBpbiB0 aGUgbmV0d29yayBTRkYtWjEgYW5kIFNGRi1aMi4gPGJyPg0KSWYgSSB1bmRlcnN0YW5kIHlvdXIg cmVxdWVzdCwgeW91IHdhbnQgU0ZGLVggdG8gcGljayBvbmUgb2YgdGhvc2UgdHdvIDxicj4NClNG Riwgc2F5IFNGRi1aMS4gQW5kIHNlbmQgYWxsIHRoZSBwYWNrZXRzIGZvciBTRlAtWSBvbiB0byBT RkYtWjEuIEV2ZW4gPGJyPg0KaWYgU0ZGLVozIGlzIGFkZGVkIHRvIHRoZSBuZXR3b3JrLCBhbGwg cGFja2V0cyBmb3IgYWxsIGZsb3dzIHVzaW5nIFNGUC1ZIDxicj4NCmF0IFNGRi1YIChldmVuIG5l dyBmbG93cykgd2lsbCBnZXQgc2VudCBieSBTRkYtWCB0byBTRkYtWjEuIFRoZSBvbmx5IDxicj4N CnRpbWUgU0ZGLVggd291bGQgY2hhbmdlIHRoYXQgaXMgaWYgZGlzY292ZXJlZCBvciB3YXMgdG9s ZCB0aGF0IFNGRi1aMSA8YnI+DQp3YXMgZG93biBvciB1bnJlYWNoYWJsZS4gSW4gdGhhdCBjYXNl LCBpdCB3b3VsZCBwaWNrIGEgbmV3IG9uZSBmcm9tIDxicj4NCmFtb25nIHRoZSBrbm93biBjaG9p Y2VzLjxicj4NCjxicj4NCk1hcmlhLCBpZiB0aGF0IGlzIHdoYXQgeW91IHdvdWxkIGxpa2UsIEkg YmVsaWV2ZSB0aGF0IGVpdGhlciBpcyA8YnI+DQpjdXJyZW50bHkgYWxsb3dlZCBieSB0aGUgYXJj aGl0ZWN0dXJlIG9yIGNhbiBlYXNpbHkgYmUgYWRkZWQuIEFuZCBJIGFtIDxicj4NCmhhcHB5IHRv IGRvIHNvLiBJIGJlbGlldmUgd2UgY2FuIGRlc2NyaWJlIHRoYXQgaW4gdGhlIHJlc2lsaWVuY2Ug YW5kIDxicj4NCmZhaWx1cmUgcmVjb3Zlcnkgc2VjdGlvbiB0aGF0IHdlIG5lZWQgdG8gYWRkLjxi cj4NCjxicj4NCkJ1dCBJIHdhbnQgdG8gYmUgcmVhbGx5IHN1cmUgdGhhdCBpcyB3aGF0IHlvdSB3 YW50LiBJIGRvbid0IHRoaW5rIHRoYXQgPGJyPg0KbWVldHMgUm9uJ3MgcmVxdWVzdC48YnI+DQo8 YnI+DQpZb3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gNy8xMS8xNCwgMTA6MDcgQU0sIE5B UElFUkFMQSwgTUFSSUEgSCB3cm90ZTo8YnI+DQomZ3Q7IEpvZWwsPGJyPg0KJmd0Ozxicj4NCiZn dDsmZ3Q7IEhtbS4gV291bGQgaXQgbWVldCB5b3VyIGdvYWxzIE1hcmlhIGlmIGFsbCBwYWNrZXRz IHRoYXQgYXJyaXZlZCBhdDxicj4NCiZndDsmZ3Q7IFNGRi1YIHdpdGggU0ZQLVkgd2VyZSAoYWZ0 ZXIgbG9jYWwgU0YgcHJvY2Vzc2luZykgZm9yd2FyZGVkIHRvIHNvbWU8YnI+DQomZ3Q7Jmd0OyBz cGVjaWZpYyBTRkYtWj8gV2hlcmUgU0ZGLVogd2FzIHNlbGVjdGVkIHdoZW4gdGhlIGZpcnN0IHBh Y2tldCB3aXRoPGJyPg0KJmd0OyZndDsgU0ZQLVkgYXJyaXZlZCBhdCBTRkYtWD88YnI+DQomZ3Q7 PGJyPg0KJmd0OyBZZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXaGlsZSB0aGF0IGlz IG1vcmUgZWFzaWx5IG1ldCwgdGhhdCBkb2VzIG5vdCBzZWVtIGxpa2VseSB0byBwcm9kdWNlIHRo ZTxicj4NCiZndDsmZ3Q7IHNjYWxlIGZsZXhpYmlsaXR5IHlvdSBhc2tlZCBmb3IuIEFuZCBpZiBT RkYtWCBtYXkgZm9yd2FyZCBwYWNrZXRzIHdpdGg8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaHkgbm90 Pzxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBTRlAtWSB0byBTRkYtWjEgYW5kIFNGRi1aMiB0aGVu IFNGRi1YIGhhcyB0byBiZSBzdGF0ZWZ1bCBhbmQgaGF2ZSB0aGU8YnI+DQomZ3Q7Jmd0OyBjYXBh YmlsaXR5IHRvIGVuc3VyZSB0aGF0IGEgZ2l2ZW4gZmxvdyBjb250aW51ZXMgdG8gZ28gdG8gdGhl IHNhbWUgbmV4dDxicj4NCiZndDsmZ3Q7IFNGRiBldmVuIHdoZW4gU0ZGLVozIGlzIGFkZGVkIHRv IHRoZSBtaXguPGJyPg0KJmd0Ozxicj4NCiZndDsgUHJlY2lzZWx5Ljxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyZndDsgT24gNy8xMS8xNCwgOTo0OCBBTSwgTkFQSUVSQUxBLCBNQVJJQSBI IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBBYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMg Y2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluIHJlbGV2YW50IFNGRnM8YnI+DQomZ3Q7Jmd0OyB3 aGVuIHRoZXkgJnF1b3Q7YXJyaXZlJnF1b3Q7Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IC4uLjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AE9AMISOUT7MSGUSRCF_-- From nobody Fri Jul 11 09:18: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 6D3171B2B0B for ; Fri, 11 Jul 2014 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 q9HkCihkSryB for ; Fri, 11 Jul 2014 09:18:48 -0700 (PDT) Received: from omr-m07.mx.aol.com (omr-m07.mx.aol.com [64.12.143.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3681A0385 for ; Fri, 11 Jul 2014 09:18:47 -0700 (PDT) Received: from mtaout-mad02.mx.aol.com (mtaout-mad02.mx.aol.com [172.26.221.206]) by omr-m07.mx.aol.com (Outbound Mail Relay) with ESMTP id 6D437700354AD; Fri, 11 Jul 2014 12:18:46 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 075AF38000096; Fri, 11 Jul 2014 12:18:46 -0400 (EDT) Date: Fri, 11 Jul 2014 12:18:45 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com, mohamed.boucadair@orange.com, jmh@joelhalpern.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3118_280747497.1405095525429" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405095526; bh=DZ9CjZnK2lhSJf8nbtghb8inlEks3lhPFE73/J4QDQM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=w2SAlkpHZgj3Z7piO4bo3O5YOxIXG0bnNCXxmUHP+G5m/D0a0hhZSVXPk+dh+G29V LkHVarzfu8F1hmvCB2OwWum1F5ztPcaoSR/xNyqcaVdfPMRt9ndc8r+KZbQwpndAc5 1N+uopilxdxCWLYht+nNnQyoZM9vjgv5udnJ7ENs= x-aol-sid: 3039ac1addce53c00e66416c X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_dzr3XK47cBkBE6-uz4kg8O7M3Q Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:18:55 -0000 ------=_Part_3118_280747497.1405095525429 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this is the root of the confusion: > I don=E2=80=99t want to specify> specific instances of S1, S2, and S3 (or= some combination thereof). I> assign a service path identifier =E2=80=9C10= 0=E2=80=9D that basically points to S1->S2->S3> and then push this into the= network By definition, I understood a "service path" to be an ordered list of speci= fic SF instances. =C2=A0In the statement above, you use a "service path ide= ntifier" to refer to a service *chain* that specifically "[does not] specif= y specific instances". From: jguichar@cisco.com To: NAPIERALA, MARIA H,mohamed.boucadair@orange.com,Joel M. Halpern,Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Maria, I think of it this way. The service path identifier is simply a pointer to a data structure that contains SF to next-hop mappings. When you define a chain, let=E2=80=99s say S1 ->S2-> S3, you *might* when creating the SFP sp= ecify the specific next-hops that you want traffic to flow through for that SFP. However, you do *not* have to do this from an architectural standpoint (I will argue that you should but you don=E2=80=99t have to architecturally). = You could simply assign a service path identifier to point to a given SFC and then push that information into the network. At the SFF it will have a service path identifier to SFC mapping and said mapping would contain the next-hops available for each of the SF=E2=80=99s within the SFC - how you l= earn those next-hops is up to you. You could push them down from a centralized controller, configure them through CLI, learn them dynamically through some protocol exchange, whatever .. So, given this it is not correct to say that the service path means that all SF instances are chosen a priori although it is perfectly acceptable (and some would say recommended) to do so. Let=E2=80=99s take an example to hopefully make this clear: I define an SFC (let=E2=80=99s refer to it as SFC-1) S1->S2->S3. For argume= nts sake let=E2=80=99s say I want it to be fully dynamic e.g. I don=E2=80=99t w= ant to specify specific instances of S1, S2, and S3 (or some combination thereof). I assign a service path identifier =E2=80=9C100=E2=80=9D that basically point= s to S1->S2->S3 and then push this into the network so that the SFF data structures are populated with this information. Now at a given SFF, when traffic arrives with service path identifier 100, the SFF will look this up in the data structure and find that it points to S1->S2->S3 and the index in the SFC encapsulation will tell it exactly where it is in the chain. Let=E2=80=99s = say we are at S2 in the chain. The SFF will now have to resolve the next-hop to S3 and will do a lookup to determine where S3 is reachable. On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" wrote: >Jim, > >Could you tell us what is the definition of a "service path" and a >"service path identifier"? >If a service path means that all SF instances are chosen apriori (which >is my current understanding) then it is not SFF's local decision which >next-hop SFF to pick. It is a centralized decision. > >Maria > > >> -----Original Message----- >>=20 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]>> Sent: Friday, J= uly 11, 2014 11:15 AM>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.co= m; Joel M.>> Halpern; Ron Parker; sfc@ietf.org>> Subject: Re: [sfc] Service= Chains, Paths, and Load Balancers>> >> I=E2=80=99m sorry but I really don= =E2=80=99t understand why a service path identifier>> prevents full distrib= ution of SF next-hops or why calling it a service>> chain identifier makes = any difference?>> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" wrote:>> >> >Ditto.>> >>> >> -----Original Message----->> >> From: mo= hamed.boucadair@orange.com>> >> [mailto:mohamed.boucadair@orange.com]>> >> = Sent: Friday, July 11, 2014 10:31 AM>> >> To: Jim Guichard (jguichar); NAPI= ERALA, MARIA H; Joel M. Halpern; Ron>> >> Parker; sfc@ietf.org>> >> Subject= : RE: [sfc] Service Chains, Paths, and Load Balancers>> >>>> >> Re-,>> >>>>= >> For what I can say at best this is not described clearly in the>>draft.= >> >>>> >> Mandating a service path identifier is in itself a hint that the= full>> >>distributed>> >> model is not allowed.>> >>>> >> Several voices i= n this thread indicated that the service chain itself>> >>should be>> >> pr= ovided instead.>> >>>> >> Cheers,>> >> Med>> >>>> >> >-----Message d'origin= e----->> >> >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guich= ard>> >> >(jguichar)>> >> >Envoy=C3=A9 : vendredi 11 juillet 2014 16:18>> >= > >=C3=80 : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org>>= >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers>> >> >>> >= > >Ok but where in the architecture specifically is this functionality>> >>= >prohibited? If you want to distribute *all* next-hops to *all* SFF=E2=80= =99s>> >> >within the SFC domain and then let the path identifier point to = a>> >>lookup>> >> >into those next-hops to reach the next SF in the chain, = I am not>>sure>> >>how>> >> >the architecture prevents that?>> >> >>> >> >O= n 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" >> wrote:>> >> >>>= >> >>Absolutely.>> >> >>>> >> >>> -----Original Message----->> >> >>> From= : sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard>> >> >>>(jgui= char)>> >> >>> Sent: Friday, July 11, 2014 9:54 AM>> >> >>> To: NAPIERALA, = MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org>> >> >>> Subject: Re: [s= fc] Service Chains, Paths, and Load Balancers>> >> >>>>> >> >>> Then I misu= nderstand the proposal ;-) .. However, it seems to me>> >>that if>> >> >>> = you allow an SFF to make a decision as to which remote SFF it>>will>> >>use= >> >> >>>for>> >> >>> a given flow to reach the next SF within the chain th= en you>>better>> >>make>> >> >>> sure that that remote SFF has the necessar= y forwarding logic to>> >>reach>> >> >>>the>> >> >>> next-next-SF for the c= hain as otherwise you are in deep trouble.>> >> >>>>> >> >>> On 7/11/14, 9:= 48 AM, "NAPIERALA, MARIA H" >> >> wrote:>> >> >>>>> >> >>> = >Absolutely not. Service chains can be instantiated only in>>relevant>> >> = >>>SFFs>> >> >>> >when they "arrive".>> >> >>> >>> >> >>> >> -----Original = Message----->> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf = Of Jim>>Guichard>> >> >>> >>(jguichar)>> >> >>> >> Sent: Friday, July 11, 2= 014 9:27 AM>> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org>> >> = >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >> >>= > >>>> >> >>> >> Well I think it is even worse than that if I have understo= od>>the>> >> >>> >>proposal>> >> >>> >> correctly as it would require full = knowledge of every single>>SF>> >> >>>within>> >> >>> >>the>> >> >>> >> ent= ire SFC domain at every single SFF as there is no way to>>know>> >>a>> >> >= >> >>priori>> >> >>> >> which SFC=C2=B9s a given SFF will need to service a= t any given>>point>> >>in>> >> >>>time.>> >> >>> >>>> >> >>> >> On 7/10/14,= 11:53 PM, "Joel M. Halpern" >> >> wrote:>> >> >>> >>>= > >> >>> >> >Ron, thinking about this, I realized another major problem>>wi= th>> >>the>> >> >>> >>your>> >> >>> >> >proposal as I understand it. (And = I readily admit I may not>> >> >>>understand>> >> >>> >> >it.)>> >> >>> >> = >>> >> >>> >> >The proposal has each SFF serve as the load balancer for the= >> >>next>> >> >>> >> >service function that follows it (not the one it del= ivers>>to),>> >>in>> >> >>>every>> >> >>> >> >service chain that goes throu= gh it.>> >> >>> >> >>> >> >>> >> >Since it has to be able to work with all = services, that means>> >>that>> >> >>> >>every>> >> >>> >> >SFF would have = to be a full, flow sensitive and stateful load>> >> >>>balancer.>> >> >>> >= > >I ahve no problem if some SFF are flow sensitive, and / or>> >>stateful.= >> >> >>> >> >But having the architecture require that every SFF be a full,= >> >>flow>> >> >>> >> >sensitive, stateful, load balancer seems to me to be= an>> >>acceptable>> >> >>> >> >imposition.>> >> >>> >> >>> >> >>> >> >Your= s,>> >> >>> >> >Joel>> >> >>> >> >>> >> >>> >> >On 7/10/14, 10:06 PM, Joel = M. Halpern wrote:>> >> >>> >> >> Part of my personal view is that I am tryi= ng to make this>>work>> >> >>> >>sensibly>> >> >>> >> >> in a more orchestr= ated environment. I expect that the>>service>> >> >>> >> >> functions, and= over time probably the SFF capabilities,>>will>> >>be>> >> >>> >> >> orche= strated and installed. I expect the service chains>>to be>> >> >>> >>drive= n by>> >> >>> >> >> BSS tools that define offerings to clients, and enable>= > >> >>>self-selection>> >> >>> >> >> from these. I expect service paths t= o be heavily policy>> >>drive.>> >> >>> >> >>>> >> >>> >> >> I can see how = to make all of that work in an archtiecture>> >>driven>> >> >>>by>> >> >>> = >> >> initial classification to described service paths. It is>> >>harder>= > >> >>>to>> >> >>> >>see>> >> >>> >> >> how to make it work (but it can be= done) when we allow more>> >> >>> >> dynamicity>> >> >>> >> >> in the netw= ork behavior.>> >> >>> >> >>>> >> >>> >> >> Having said that, most of that = perspective I described is>> >>outside>> >> >>>of>> >> >>> >>the>> >> >>> >= > >> scope of the working group. it is not something we are>> >>tasked to>= > >> >>> >>agree>> >> >>> >> >>on.>> >> >>> >> >> So I do not claim that vi= sion means we have to do it a>>certain>> >> >>>way.>> >> >>> >>it>> >> >>> = >> >> is just the perspective that drives my preferences.>> >> >>> >> >>>> = >> >>> >> >> Yours,>> >> >>> >> >> Joel>> >> >>> >> >>>> >> >>> >> >> On 7/= 10/14, 9:58 PM, Ian Smith wrote:>> >> >>> >> >>>> For me, the amount of inf= ormation about service instances>> >> that>> >> >>> >>needs>> >> >>> >> >>>= >to>> >> >>> >> >>>> be widely distributed and maintained, potentially even= >> >>across>> >> >>>data>> >> >>> >> >>>> centers within an administrative = scope, is large enough>>and>> >> >>> complex>> >> >>> >> >>>> enough that t= rying to get that into each SFF seems like a>> >> >>>difficult>> >> >>> >> = >>>> architecture to realize.>> >> >>> >> >>>>> >> >>> >> >>> I'm curious a= s to why that is more complicated than>>dynamic>> >> >>> routing,>> >> >>> = >> >>> hyper-scale data center orchestration, or DNS, all of>>which>> >>are= >> >> >>> >>bigger>> >> >>> >> >>> problems that have been profitably and s= tably implemented?>> >> >>> >> >>>>> >> >>> >> >>> It also seems that if it= really is more complicated, that>>is>> >>a>> >> >>>good>> >> >>> >> >>> si= gn that it is too complicated.>> >> >>> >> >>>>> >> >>> >> >>> ____________= ____________________________>> >> >>> >> >>> From: Joel M. Halpern [jmh@joe= lhalpern.com]>> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM>> >> >>= > >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com;>>Ian>> >> = >>>Smith;>> >> >>> >> >>> sfc@ietf.org>> >> >>> >> >>> Subject: Re: [sfc] S= ervice Chains, Paths, and Load>>Balancers>> >> >>> >> >>>>> >> >>> >> >>> T= his is an architectural issue. And one that I would>>prefer>> >>we>> >> >>= > >> >>>actually>> >> >>> >> >>> decide, rather than trying to allow all po= ssible>> >>implementations.>> >> >>> >> >>> Because it does have a major ef= fect on the control>> >>requirements>> >> >>>and>> >> >>> >> the>> >> >>> >= > >>> functionality of SFFs.>> >> >>> >> >>>>> >> >>> >> >>> For me, the am= ount of information about service instances>> >>that>> >> >>> needs>> >> >>= > >> to>> >> >>> >> >>> be widely distributed and maintained, potentially e= ven>> across>> >> >>>data>> >> >>> >> >>> centers within an administrative = scope, is large enough>>and>> >> >>>complex>> >> >>> >> >>> enough that try= ing to get that into each SFF seems like a>> >> >>>difficult>> >> >>> >> >>= > architecture to realize.>> >> >>> >> >>>>> >> >>> >> >>> Yours,>> >> >>> = >> >>> Joel>> >> >>> >> >>>>> >> >>> >> >>> But it is a fair question.>> >>= >>> >> >>>>> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>> >> >>>= >> >>>> This is the crux of my issue. =C2=A0 Is the end to end>>selection>= > >>of>> >> >>> >> >>>> (top-level) instances performed centrally (perhaps = by the>> >> >>> >>classifier)>> >> >>> >> >>>> or hop-by-hop (perhaps by th= e classifier and subsequently>> >>the>> >> >>> >>SFFs)?>> >> >>> >> >>>> Su= ch selection is not equivalent to reclassification.>>And>> >> >>>surely,>> = >> >>> >> >>>> this is an architectural issue and not relegated to>> >> >>>= >> >>>> "implementation".>> >> >>> >> >>>>>> >> >>> >> >>>> My own view is= to favor the distributed approach even>> though>> >> a>> >> >>> >> >>>> gr= eater amount of data (chain definitions and perhaps>>local>> >> >>> >>selec= tion>> >> >>> >> >>>> policy) is required at those distributed decision poi= nts.>> >>This>> >> >>> >> >>>> approach does not require an end-to-end path= id at all.>> >>My>> >> >>> >> >>>> rationale for favoring this approach is= primarily driven>>by>> >> >>> >>increased>> >> >>> >> >>>> resiliency over= the global path id approach. =C2=A0 With a>>global>> >> >>>path>> >> >>> >= >id>> >> >>> >> >>>> approach, consider failure of an instance and needing = to>> >>alter>> >> >>>the>> >> >>> >> >>>> global path ID table for each and= every affected>>end-to-end>> >> >>>path.>> >> >>> >> >>>>>> >> >>> >> >>>>= Ron>> >> >>> >> >>>>>> >> >>> >> >>>> ____________________________________= ____ From: sfc>> >> >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Ha= lpern Direct>> >> >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, = July 10,>>2014>> >> 6:15>> >> >>> PM>> >> >>> >> >>>> To: mikebianc@aol.com= ; I.Smith@F5.com; sfc@ietf.org>> Subject:>> >> Re:>> >> >>> >> >>>> [sfc] S= ervice Chains, Paths, and Load Balancers>> >> >>> >> >>>>>> >> >>> >> >>>> = The way the architecture models the case of SF1 needing>>to>> >> >>> >>infl= uence>> >> >>> >> >>>> the chain is that one would do reclassification at t= he>>exit>> >>from>> >> >>> >> >>>> SF1.>> >> >>> >> >>>>>> >> >>> >> >>>> P= art of the goal is to keep the different functions>> >>logically>> >> >>> >= > >>>> separate so that solutions can clearly describe how they>> >> choose= >> >> >>>to>> >> >>> >> >>>> compose them for "service" delivery.>> >> >>> = >> >>>>>> >> >>> >> >>>> Yours, Joel>> >> >>> >> >>>>>> >> >>> >> >>>> On 7= /10/14, 6:10 PM, mikebianc@aol.com wrote:>> >> >>> >> >>>>> I don't see any= thing in the arch draft that suggests any>> >>sort>> >> >>>of>> >> >>> >> >= >>>> limit. However, it does seem to indicate that the entire>> >>path>> >>= >>>(all>> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I be= lieve>>this>> >> >>>means>> >> >>> >> >>>>> either at the classifier or may= be the classifier>>chooses a>> >>SF>> >> >>> >>Chain>> >> >>> >> >>>>> and = the NF or at the latest the first SFF. In any case,>> >>the>> >> >>> >> >>= >>> language does seem to prohibit a more dynamic SFP where>> >> SFI(n)>> >= > >>> is>> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to th= e draft,>> >>this>> >> >>> >> >>>>> behavior would be considered "branching= " to a new SFP as>> >> >>> opposed>> >> >>> >> to>> >> >>> >> >>>>> choosin= g and then forwarding to the selected instance of>> >>the>> >> >>> >> >>>>>= next-hop of the current SFC.>> >> >>> >> >>>>>>> >> >>> >> >>>>> draft-mer= ged-sfc-architecture-00:>> >> >>> >> >>>>>> When an SFC is instantiated int= o the network it is>> >>necessary>> >> >>>to>> >> >>> >> >>>>>> select the = specific instances of SFs that will be used,>> >>and to>> >> >>> >> >>>>>> = create the service topology for that SFC using SF's>> >>network>> >> >>> >>= >>>>>> locator. Thus, instantiation of the SFC results in the>> >> >>>cre= ation>> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for>>= >>forwarding>> >> >>> >> >>>>>> packets through the SFC. In other words, a= n SFP is the>> >> >>> >> >>>>>> instantiation of the defined SFC.>> >> >>> = >> >>>>>>>> >> >>> >> >>>>>> The SFC architecture supports reclassification= (or>> >>non-initial>> >> >>> >> >>>>>> classification) as well. As packet= s traverse an SFP,>> >> >>> >> >>>>>> reclassification may occur - typicall= y performed by a>> >> >>> >> >>>>>> classification function co-resident wit= h a service>> >>function.>> >> >>> >> >>>>>> Reclassification may result in= the selection of a new>> >>SFP, an>> >> >>> >> >>>>>> update of the associ= ated metadata, or both. This is>> >>referred>> >> >>>to>> >> >>> >> >>>>>>= as "branching".>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >>= >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>> >>>>>>>>>>>>>>-------------------= ------------------------------------------>>>>>>>>>>>>>>-->> >>>>>>>>>>>>--= ->> >> >>>>>>>>>>-->> >> >>> >>>>>>>-->> >> >>> >> >>>>>-->> >> >>> >> >>>>= >>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>> *From: *I.Smith@F5.co= m>> >> >>> >> >>>>> *To: *Joel Halpern>> Direct,Joel>> >> M.>> >> >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>>= >>>>>Halpern,huang@sce.carleton.ca> >> >>= > >> carleton.>> >> >>> >> >>>>>ca>,sfc@ietf.org>> >> >>> >> = >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>> *Sent: *Thursday,= July 10, 2014>> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths= , and Load>> >>Balancers>> >> >>> >> >>>>>>> >> >>> >> >>>>> Actually, I th= ink I am disagreeing.>> >> >>> >> >>>>>>> >> >>> >> >>>>> If the possibilit= y of medium-scale deployments (and>>that is>> >> >>>what>> >> >>> >> >>>>> = 16 million flows is in my world) of service chains is>> >> >>>preconceived>= > >> >>> >> >>>>> as an absurd idea, then the architecture burdened with>> = that>> >> >>> >> >>>>> preconception.>> >> >>> >> >>>>>>> >> >>> >> >>>>> T= here has to be some point of aim, some degree of>> >>aspiration>> >> to>> >= > >>> >> >>>>> scale that is appropriate for the lifespan of the>> >>archit= ecture>> >> >>>->> >> >>> >> >>>>> you don't have to know what it is, but b= y saying that an>> >> >>>arbitrary>> >> >>> >> >>>>> number is "too far", y= ou're creating - even if it isn't>> >> >>> >>intentional>> >> >>> >> >>>>> = - a limit that influences decisions that have lasting>> >>impacts>> >> >>> = >> >>>>> regarding scale-out, failure mitigation, elasticity,>> >>address>>= >> >>> >> >>>>> space... all kinds of things. That is a problem I'm not>> = >> >>> >> >>>>> particularly eager to deal with.>> >> >>> >> >>>>>>> >> >>>= >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>> ___________= _____________________________>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> = >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com]>> >>Sent:>>= >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M.>> >= > Halpern;>> >> >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: R= e: [sfc]>> >>Service>> >> >>> >> >>>>> Chains, Paths, and Load Balancers>> = >> >>> >> >>>>>>> >> >>> >> >>>>> Ian, I don't think you disagree with me a= t all in this>> >>regard.>> >> >>>I>> >> >>> >>am>> >> >>> >> >>>>> not req= uesting the the architecture or the solution>> >>prohibit>> >> >>> >> >>>>>= deployments in the specific fashion. I am objecting to>> >>Huang's>> >> >>= > >> >>>>> reading of my note as saying that such deployments are>> >> requ= ired>> >> >>> >> >>>>> they by the archtiecture.>> >> >>> >> >>>>>>> >> >>>= >> >>>>> As I have said repeatedly, I am not trying to prohibit>>such>> >>= >>> >> >>>>> things. Whether they are a good idea or not depends upon>> >>= many>> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to= >>think>> >>that>> >> >>> >>they>> >> >>> >> >>>>> are usually a bad idea.>= > >> >>> >> >>>>>>> >> >>> >> >>>>> But the archtiecture si carefully avoid= ing attempting to>> >>know>> >> >>>what>> >> >>> >> >>>>> is and is not epl= oyable.>> >> >>> >> >>>>>>> >> >>> >> >>>>> Yours, Joel>> >> >>> >> >>>>>>>= >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>> >> >>> >> >>>>>> I= disagree.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> We routinely have stateful= devices that manage tens of>> >> >>>millions>> >> >>> >> >>>>>> of>> >> >>= > >> >>>>> concurrent flows in both access network and data center>> >> >>>= >> >>>>> environments today. You can't seriously believe that in>>the>> >>= >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you>> are>> = >> only>> >> >>> >> going>> >> >>> >> >>>>> to have small numbers of servic= e chains with equally>>small>> >> >>> numbers>> >> >>> >> >>>>> of active s= ervice paths?>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Your sounds too much li= ke "no one will ever need more>> than>> >> >>> 64K">> >> >>> >> >>>>>> for>= > >> >>> >> >>>>> comfort.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>>>> >> >>> >= > >>>>>> ________________________________________ From: sfc>> >> >>> >> >>>= >>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern>> >> >>> >> >>>>> [= jmh@joelhalpern.com]>> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 = PM To:>> >> >>>huang@sce.carleton.ca;>> >> >>> >> >>>>>> sfc@ietf.org Subje= ct: Re: [sfc] Service Chains, Paths,>>and>> >> >>>Load>> >> >>> >> >>>>>> B= alancers>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> No, it will mean that if som= eone tries to deploy the>> >> >>>archtieture>> >> >>> >> >>>>>> particularl= y badly, they will exceed the limits of>>their>> >> >>> >> >>>>>> devices. = The architecture does not require such absurd>> use>> >> of>> >> >>> >> >>>= >>> service paths. Since I can not figure out how to write>> >> >>> >> >>>>= >> architectural words to prohibit it, the architecture>>does>> >> >>>permi= t>> >> >>> >> >>>>>> such abuse.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Plea= se do not read my saying that the archtiecture>> permits>> >> >>> >> >>>>>>= something as saying it is either deisred or required by>> >>the>> >> >>>wo= rk.>> >> >>> >> >>>>>> It isn't.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Your= s, Joel>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changche= ng Huang wrote:>> >> >>> >> >>>>>>> If you need to support 100 service chai= ns, it will>>mean>> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than= the routing>>table>> >>of a>> >> >>> >> >>>>>>> core router.>> >> >>> >> >= >>>>>>>> >> >>> >> >>>>>>> Chang>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>> On= 07/10/2014 01:15 PM, Joel M. Halpern wrote:>> >> >>> >> >>>>>>>> The archi= tecture allows a range of deployments, from>>1>> >> >>> >> >>>>>>>> service= path to 160000 service paths. I would hope>>that>> >> >>> >> >>>>>>>> oper= ators are prepared for the complexities if they>> >>choose>> >> >>>to>> >> = >>> >> >>>>>>>> avoid any use of local load balancing and in stead>> >> pro= vision>> >> >>> >> >>>>>>>> 160,000 service paths.>> >> >>> >> >>>>>>>>>> >= > >>> >> >>>>>>>> Yours, Joel>> >> >>> >> >>>>>>>>>> >> >>> >> >>>>>>>> On = 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>> >> >>> >> >>>>>>>>> Paul,>> >= > >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> How many path identifiers there wi= ll be for a 4 hop>> >> service>> >> >>> >> >>>>>>>>> chain with 20 instance= s at each hop?>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Maria>> >> >>> >= > >>>>>>>>>>> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] = *On Behalf>> Of>> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday,= July 10, 2014>> >>3:03>> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@= joelhalpern.com;>> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ie= tf.org;>> >> >>> >> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Servic= e>> Chains,>> >> >>> >> >>>>>>>>> Paths, and Load Balancers>> >> >>> >> >>>= >>>>>>>> >> >>> >> >>>>>>>>> Lucy,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>= >>> Overall I concur, as you say: a path ID drives the>> >> >>> >> >>>>>>>>= > forwarding. I=C2=B9d>> >> >>> >> >>>>> make>> >> >>> >> >>>>>>>>> the min= or change: the path identifier can be used to>> >> derive>> >> >>> >> >>>>>= >>>> the needed forwarding and associated transport.>> >> >>> >> >>>>>>>>>>= > >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to>>sim= ply>> >> >>> >> >>>>>>>>> identify the service path (or graph) that packets= >>must>> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exa= ct>> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on>>= this>> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path>> = >> identifier>> >> >>> >> >>>>>>>>> provides nothing more than a lookup, th= at lookup can>> >> result>> >> >>> >> >>>>>>>>> in a one or more (equal or = weighted) transport next>> >> >>> >> >>>>>>>>> hop(s).>> >> >>> >> >>>>>>>>= >>> >> >>> >> >>>>>>>>> Paul>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> On= Jul 10, 2014, at 11:04 AM, Lucy yong>> >> >>> >> >>>>>>>>> > >> >>> >> >>> >> >>>>>>>>> wrote:>> >= > >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> = >>>>>>>>> Agree. The arch. doc should not mandate only use of>> the>> >> >>= > >> >>>>>>>>> service path identifier to drive the forwarding>> >>actions.= >> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Lucy>> >> >>> >> >>>>>>>>>>> >= > >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf>> >> = >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com>> >> >>> >> >>>>>>>>> >> >> >>> *Sent:*Thursday,>> >> >>> >> Jul= y>> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com>> >> >>> >>= >>>>>>>>> ;jmh@joelhalpern.com>> >> >>> >> >>>>>= >>>> ;sfc@ietf.org>> >> >>> >> >>>>>>>>> *Subject:*Re: [sfc] Service>> >>Chains,>> >> >>> >> >>>>>>>= >> Paths, and Load Balancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Re= -,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> The merged draft calls out e= xplicitly a service path>> >> >>> >> >>>>>>>>> identifier. I object to use = that identifier to>>derive>> >> >>> >> >>>>>>>>> forwarding actions.>> >> >= >> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Requiring a SFC system to have the fu= ll knowledge of>> >> every>> >> >>> >> >>>>> available SFC>> >> >>> >> >>>>= >>>>> forwarding paths within an SFC-enabled domain is not>> >> >>> >> >>>>= > required/justified>> >> >>> >> >>>>>>>>> nor possible in various deployme= nt contexts.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> SFC forwarding act= ions should rely on the piece of>> >> >>> >> >>>>>>>>> information>> >> >>>= >> >>>>> that will>> >> >>> >> >>>>>>>>> be present in all deployments: th= at is the one>> required>> >> to>> >> >>> >> >>>>>>>>> structure a service = chain. How that information is>> >>used to>> >> >>> >> >>>>>>>>> infer forw= arding>> >> >>> >> >>>>> actions>> >> >>> >> >>>>>>>>> is a solution-orient= ed discussion.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Cheers,>> >> >>>= >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Med>> >> >>> >> >>>>>>>>>>> >> >>> >> >= >>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part>> >> >>> >> >>>= >> de*mikebianc@aol.com>> >> >>> >> >>>>>>>>> *E= nvoy=C3=A9 :*mercredi 9>> >> juillet>> >> >>> >> >>>>>>>>> 2014 22:03 *=C3= =80 :*jmh@joelhalpern.com>> >> >>> >> >>>>>>>>> ;sfc@ietf.org>> >> >>> >> >>>>>>>>> *Objet :*Re: [sf= c] Service>> >>Chains,>> >> >>> >> >>>>>>>>> Paths, and Load Balancers>> >>= >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Is anyone still questioning the dif= ference between>>SF>> >> Chain>> >> >>> >> >>>>>>>>> and SF>> >> >>> >> >>>= >> Path?>> >> >>> >> >>>>>>>>> Other than clarifying the definition so that= it's>> >>clear to>> >> >>> >> >>>>> those not>> >> >>> >> >>>>>>>>> famili= ar with the draft, it seems that everyone>>agrees>> >>on>> >> >>> >> >>>>>>= >>> these terms.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> To me, the one= point that is still unclear is>>whether>> >>it is>> >> >>> >> >>>>>>>>> th= e intent of this draft to ultimately specify what>> >>the ID>> >> >>> >> >>= >>>>>>> of the SFC Header>> >> >>> >> >>>>> should>> >> >>> >> >>>>>>>>> re= ference (the chain or the path), or if this draft>> >>simply>> >> >>> >> >>= >>>>>>> intends to leave that ambiguous, allowing other>>drafts>> >>to>> >>= >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain>> or= >> >> >>> >> >>>>>>>>> path and the choice of chain or>> >> >>> >> >>>>> pa= th to>> >> >>> >> >>>>>>>>> be negotiated in the control-plane.>> >> >>> >>= >>>>>>>>>>> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft = would have>> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported= (or make>> >> one>> >> >>> >> >>>>>>>>> required and the other optional) t= o avoid some>> vendors>> >> only>> >> >>> >> >>>>>>>>> supporting SFP and o= thers only supporting SFC.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >>= >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>> >>>>>>>>>>>>>>-------------------= ------------------------------------------>>>>>>>>>>>>>>-->> >>>>>>>>>>>>--= ->> >> >>>>>>>>>>-->> >> >>> >>>>>>>-->> >> >>> >> >>>>>-->> >> >>> >> >>>>= >>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>= >>>> *From:*jmh@joelhalpern.com> >> >>> >> >>>>>>>>>>>= >> >>> >> >>> >> >>>>>>>= >> *To:*sfc@ietf.org> >> >>> >> >>>>>>>>> >>> *Sent:*Tuesday,>> >> July>> >> >>> >> >>>>>>>>> 8, 201= 4 *Subject:*[sfc] Service Chains, Paths, and>>Load>> >> >>> >> >>>>>>>>> Ba= lancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> I have been trying to f= igure out how to clearly>>answer>> >>a>> >> >>> >> >>>>>>>>> number of comm= ents that have been made about the>> >> >>> proposed>> >> >>> >> >>>>>>>>> = merged archtiecture draft. Assuming we can get>> working>> >> >>> >> >>>>>>= >>> group agreement on the intent, we will work to>> improve>> >> the>> >> = >>> >> >>>>>>>>> wording so that readers who have not participated in>> >>t= he>> >> WG>> >> >>> >> >>>>>>>>> discussion will understnd it the way the>>= >> >>> >> >>>>> working>> >> >>> >> >>>>>>>>> group intends.>> >> >>> >> >= >>>>>>>>>> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain= my>> >>personal>> >> >>> >> >>>>>>>>> view, and see if that helps.>> >> >>= > >> >>>>>>>>>>> >> >>> >> >>>>>>>>> In this regard, it is important to kee= p in mind that>> >>what>> >> >>> >> >>>>>>>>> we are defining is the data p= lane architecture. We>>are>> >> not>> >> >>> >> >>>>>>>>> attempting to def= ine the architecture for the entire>> >> >>> >> >>>>>>>>> solution for serv= ice chaining. That would encompass>> >> >>> >> >>>>>>>>> OSS/BSS, various c= ontrol and policy functions,>>virtual>> >> >>> >> >>>>>>>>> machine and ima= ge management, and many other>> >> aspects.>> >> >>> >> >>>>>>>>>>> >> >>> = >> >>>>>>>>> As a result there are many things which clearly need>> to>> >>= >>> >> >>>>>>>>> exist in the larger system, but which are dealt with>> >>= above>> >> >>> >> >>>>>>>>> where we are>> >> >>> >> >>>>> functioning,>> >= > >>> >> >>>>>>>>> and are not directly required by the work we are>> doing= .>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> In order to get to service ch= ain vs service path,>>as I>> >> >>> >> >>>>>>>>> understand>> >> >>> >> >>>= >> them,>> >> >>> >> >>>>>>>>> I need to first discuss load balancing. Ther= e are at>> >>least>> >> >>> >> >>>>>>>>> three different ways that load bal= ancing can and>>will>> >> >>> >> >>>>>>>>> interact with service chaining. = There probably are>> >>more.>> >> >>> >> >>>>>>>>> The point of the archtie= cture is to permit all of>> >>these,>> >> >>> >> >>>>>>>>> but not to manda= te that any particular kind>> >> >>> >> >>>>> be used>> >> >>> >> >>>>>>>>>= in any solution.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> 1) Load balan= cing as a service provided to the end>> >>user.>> >> >>> >> >>>>>>>>> This = is a service function. It receives user>>packets,>> >>and>> >> >>> >> >>>>>= >>>> modifies them (or>> >> >>> >> >>>>> marks>> >> >>> >> >>>>>>>>> them, = or ...) so as to choose an end user service>> >>instance>> >> >>> >> >>>>>>= >>> to receive the users packet. This is an important>> >>service>> >> >>> = >> >>>>>>>>> function to be able to include in service chaining.>> >>It's>>= >> >>> >> >>>>>>>>> behavior may affect requirements on how service>> >> c= haining is>> >> >>> >> >>>>>>>>> done. But it has very little impact on the= >> >>archtiecture.>> >> >>> >> >>>>>>>>> From an architectural pe3rspectiv= e it is simply a>> >> >>> >> >>>>> service>> >> >>> >> >>>>>>>>> function w= hich may modify the underlying packet.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>= >>>>>>> 2) There is internal load balancing. That is, one>>can>> >>have>> >= > >>> >> >>>>>>>>> what>> >> >>> >> >>>>> appears>> >> >>> >> >>>>>>>>> to = the service chaining architecture as a single>>point>> >>of>> >> >>> >> >>>= >>>>>> contact>> >> >>> >> >>>>> for a>> >> >>> >> >>>>>>>>> specific servi= ce function, but is actually delivered>> >>by a>> >> >>> >> >>>>> collectio= n of>> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including= >>one or>> >> >>> >> >>>>>>>>> several load balancers (for example using VR= RP-like>> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, t= his is>> >> >>> >> >>>>>>>>> invisible to the service chaining data plane>>= >>mechanisms.>> >> It>> >> >>> >> >>>>>>>>> is likely that it is visible t= o various control>> >>mechanisms,>> >> >>> >> >>>>>>>>> such as those respo= nsible for scale-in, scale-out, >>and>> >>vm>> >> >>> >> >>>>>>>>> instanti= ation. The architectural impact of >>permitting>> >>this>> >> >>> >> >>>>>>= >>> is largely that we need to be careful that our>> >>terminology>> >> >>>= >> >>>>>>>>> does not lead>> >> >>> >> >>>>> readers to>> >> >>> >> >>>>>>= >>> think we are prohibiting it.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>= > 3) There can also be load balancing done by >>selecting>> >> >>> >> >>>>>= >>>> packet paths for the service chaining that direct>> >>traffic>> >> >>>= >> >>>>>>>>> to different places. We would not want to require>> that>> >>= a>> >> >>> >> >>>>>>>>> given service function appear at only one place in = >>the>> >> >>> >> >>>>>>>>> network.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>= >>>>> It is of course the case that these may be >>combined. I>> >> tend>> = >> >>> >> >>>>>>>>> to>> >> >>> >> >>>>> refer to>> >> >>> >> >>>>>>>>> the= collection of entities that appear to service>> >>chaining>> >> >>> >> >>>= >>>>>> as a single point as a cluster. Not because cluster >>is>> >>a>> >> = >>> >> >>>>>>>>> good term. But because I do not have another one.>> Thus,>= > >> the>> >> >>> >> >>>>>>>>> point of type 3 load balancing>> >> >>> >> >= >>>> is to>> >> >>> >> >>>>>>>>> direct different subsets of traffic to dif= ferent>> >>singular>> >> >>> >> >>>>>>>>> or clustered service functions in= different places >>in>> >>the>> >> >>> >> >>>>>>>>> network.>> >> >>> >> >= >>>>>>>>>> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I ta= lk about>> >> >>> >> >>>>>>>>> service chain and service path/ Service chai= n is a>> >> sequence>> >> >>> >> >>>>>>>>> of logical functions to be appli= ed to a subset of>> >>packets.>> >> >>> >> >>>>>>>>> It is equivalent of sa= ying that some subset of >>traffic>> >>is>> >> >>> >> >>>>>>>>> to get DPI,= charging, content inspection, and >>firewall>> >> >>> >> >>>>>>>>> while a= different subset is to go directly to the >>cache>> >> >>> >> >>>>> withou= t>> >> >>> >> >>>>>>>>> visiting any other service functions.>> >> >>> >> >= >>>>>>>>>> >> >>> >> >>>>>>>>> That is not enough information to direct the= >>packets.>> A>> >> >>> >> >>>>>>>>> service path is, in some fashion, a s= equence of>> >>locations>> >> >>> >> >>>>>>>>> in the network. Those locati= ons will be singular or>> >> >>> >> >>>>>>>>> clustered service function de= livery locations. They>> >>may be>> >> >>> >> >>>>>>>>> addressed by IP add= ress. They may be addressed as>> ports>> >> on>> >> >>> >> >>>>>>>>> an SFF= . There are many different ways that the>> >>locations>> >> >>> >> >>>>>>>>= > may be known to the service chaining infrastructure>> and>> >> the>> >> >= >> >> >>>>>>>>> transport.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>> Fr= om the point of view of the work of the SFC >>group,>> >> we>> >> >>> >> >>= >>>>>>>> need to be>> >> >>> >> >>>>>>>>> able to talk about the high level= abstraction, the>> >>service>> >> >>> >> >>>>>>>>> chain, which drives the= forwarding. And we need to>> talk>> >> >>> >> >>>>>>>>> about the actual d= ata path packets will take in the>> >> >>> >> >>>>>>>>> network.>> >> >>> >= > >>>>>>>>>>> >> >>> >> >>>>>>>>> Several of the comments have said "but th= e whole>> path>> >> may>> >> >>> >> >>>>>>>>> not be known at the front." T= his architecture deals>> >>with>> >> >>> >> >>>>>>>>> that issue in two way= s. First, as noted in item (2) >>on>> >>load>> >> >>> >> >>>>>>>>> balancer= s above, there can be decisions and >>behaviors>> >> which>> >> >>> >> >>>>= >>>>> are invisible to the service chaining mechanisms (in>> >>much>> >> >>= > >> >>>>>>>>> the same way that bridging within a LAN is largely>> >> >>> = >> >>>>>>>>> invisible to routing between LANs.) The other>> provision>> >>= we>> >> >>> >> >>>>>>>>> make is>> >> >>> >> >>>>> that>> >> >>> >> >>>>>>= >>> reclassification can be done in mid-chain when>> >> necessary.>> >> >>>= >> >>>>>>>>> That will direct packets to a new chain. Based on>> >> >>> >>= >>>>>>>>> information available at the re-classification >>point.>> >> >>>= >> >>>>>>>>>>> >> >>> >> >>>>>>>>> I hope that this helps explain what we = are after. >>If it>> >> >>> >> >>>>>>>>> does, and if the intent is accepta= ble to the working>> >> group,>> >> >>> >> >>>>>>>>> we can figure out what= additional words are needed>> to>> >> >>> >> >>>>>>>>> convey this. If the= working group disagree with the>> >> intent,>> >> >>> >> >>>>>>>>> then we= will of course adjust to match the working>> >>group>> >> >>> >> >>>>>>>>>= agreements. If this is still unclear, I am not sure>> >>what to>> >> >>> >= > >>>>>>>>> try next.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Yours, Jo= el>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> __________________________= _____________________>> >> sfc>> >> >>> >> mailing>> >> >>> >> >>>>>>>>> li= st sfc@ietf.org >> >> >>> >> >>>>>>>>> https://www.iet= f.org/mailman/listinfo/sfc>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> __= _____________________________________________>> >> sfc>> >> >>> >> mailing>= > >> >>> >> >>>>>>>>> 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>> >> >>> >> >>>>>>> list sfc@ietf.or= g>> >>https://www.ietf.org/mailman/listinfo/sfc>> >> >>> >> >>>>>>>>> >> >>= > >> >>>>>>>> >> >>> >> >>>>>> ____________________________________________= ___>> sfc>> >> >>> mailing>> >> >>> >> list>> >> >>> >> >>>>>> sfc@ietf.org= https://www.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://www.ietf.org/mailman/listinfo/sfc>> >> = >>> >> >>>>>> >> >>> >> >>>> ______________________________________________= _ sfc>> >> mailing>> >> >>> >> list>> >> >>> >> >>>> sfc@ietf.org https://w= ww.ietf.org/mailman/listinfo/sfc>> >> >>> >> >>>>>> >> >>> >> >>>>> >> >>> = >> >>>> >> >>> >> >> _______________________________________________>> >> >= >> >> >> sfc mailing list>> >> >>> >> >> sfc@ietf.org>> >> >>> >> >> https:= //www.ietf.org/mailman/listinfo/sfc>> >> >>> >> >>>> >> >>> >> >>> >> >>> >= > >_______________________________________________>> >> >>> >> >sfc mailing= list>> >> >>> >> >sfc@ietf.org>> >> >>> >> >https://www.ietf.org/mailman/l= istinfo/sfc>> >> >>> >>>> >> >>> >> _______________________________________= ________>> >> >>> >> sfc mailing list>> >> >>> >> sfc@ietf.org>> >> >>> >> = https://www.ietf.org/mailman/listinfo/sfc>> >> >>>>> >> >>> _______________= ________________________________>> >> >>> sfc mailing list>> >> >>> sfc@iet= f.org>> >> >>> https://www.ietf.org/mailman/listinfo/sfc>> >> >>> >> >_____= __________________________________________>> >> >sfc mailing list>> >> >sfc= @ietf.org>> >> >https://www.ietf.org/mailman/listinfo/sfc>_________________= ______________________________sfc mailing listsfc@ietf.orghttps://www.ietf.= org/mailman/listinfo/sfc ------=_Part_3118_280747497.1405095525429 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think= this is the root of the confusion:

> I don=E2=80=99t want to specify
> specific instances of S1, S2, and S3 (or some combinatio= n thereof). I
> assign a service path identi= fier =E2=80=9C100=E2=80=9D that basically points to S1->S2->S3=
> and then push this into the network
By definition, I understood a "service path" to be an ordered list of spe= cific SF instances.  In the statement above, you use a "service path i= dentifier" to refer to a service *chain* that specifically "[does not] spec= ify specific instances".



=
From: jguichar@cisco.com<jguic= har@cisco.com>
To: NAPIERALA, MARIA H<mn1921@att.com>,mo= hamed.boucadair@orange.com<mohamed.boucadair@orange.com>,Joel M. Halp= ern<jmh@joelhalpern.com>,Ron Parker<Ron_Parker@affirmednetworks.co= m>,sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 201= 4
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
Maria,

I think of it this way. The service path = identifier is simply a pointer to
a data structure that contains SF to n= ext-hop mappings. When you define a
chain, let=E2=80=99s say S1 ->S2-= > S3, you *might* when creating the SFP specify
the specific next-hop= s that you want traffic to flow through for that SFP.
However, you do *n= ot* have to do this from an architectural standpoint (I
will argue that = you should but you don=E2=80=99t have to architecturally). You
could sim= ply assign a service path identifier to point to a given SFC and
then pu= sh that information into the network. At the SFF it will have a
service = path identifier to SFC mapping and said mapping would contain the
next-h= ops available for each of the SF=E2=80=99s within the SFC - how you learnthose next-hops is up to you. You could push them down from a centralized=
controller, configure them through CLI, learn them dynamically through<= br>some protocol exchange, whatever .. So, given this it is not correct to<= br>say that the service path means that all SF instances are chosen a prior= i
although it is perfectly acceptable (and some would say recommended) t= o do
so.

Let=E2=80=99s take an example to hopefully make this cle= ar:

I define an SFC (let=E2=80=99s refer to it as SFC-1) S1->S2-&= gt;S3. For arguments
sake let=E2=80=99s say I want it to be fully dynami= c e.g. I don=E2=80=99t want to specify
specific instances of S1, S2, and= S3 (or some combination thereof). I
assign a service path identifier = =E2=80=9C100=E2=80=9D that basically points to S1->S2->S3
and then= push this into the network so that the SFF data structures are
populate= d with this information. Now at a given SFF, when traffic arrives
with s= ervice path identifier 100, the SFF will look this up in the data
struct= ure and find that it points to S1->S2->S3 and the index in the SFCencapsulation will tell it exactly where it is in the chain. Let=E2=80=99s= say we
are at S2 in the chain. The SFF will now have to resolve the nex= t-hop to
S3 and will do a lookup to determine where S3 is reachable.
=
On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

>Jim,
>
>Coul= d you tell us what is the definition of a "service path" and a
>"serv= ice path identifier"?
>If a service path means that all SF instances = are chosen apriori (which
>is my current understanding) then it is n= ot SFF's local decision which
>next-hop SFF to pick. It is a central= ized decision.
>
>Maria
>
>
>> -----Origin= al Message-----
>>

From: Jim Guichard (jguichar= ) [mailto:jguichar@cisco.com]
>> Sent: Friday, July 11,= 2014 11:15 AM
>> To: NAPIERALA, MARIA H; mohamed.bouca= dair@orange.com; Joel M.
>> Halpern; Ron Parker; sfc@ie= tf.org
>> Subject: Re: [sfc] Service Chains, Paths, and= Load Balancers
>>
>> I=E2=80=99m = sorry but I really don=E2=80=99t understand why a service path identifier>> prevents full distribution of SF next-hops or why cal= ling it a service
>> chain identifier makes any differe= nce?
>>
>> On 7/11/14, 10:58 AM, "= NAPIERALA, MARIA H" <mn1921@att.com> wrote:
>> >> >Ditto.
>> >
= >> >> -----Original Message-----
>> >>= ; From: mohamed.boucadair@orange.com
>> >> [mailt= o:mohamed.boucadair@orange.com]
>> >> Sent: Frida= y, July 11, 2014 10:31 AM
>> >> To: Jim Guichard = (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron
>>= >> Parker; sfc@ietf.org
>> >> Subject: RE:= [sfc] Service Chains, Paths, and Load Balancers
>> >= ;>
>> >> Re-,
>> >><= br class=3D"">>> >> For what I can say at best this is not desc= ribed clearly in the
>>draft.
>> &g= t;>
>> >> Mandating a service path identifier = is in itself a hint that the full
>> >>distribute= d
>> >> model is not allowed.
>&= gt; >>
>> >> Several voices in this thread = indicated that the service chain itself
>> >>shou= ld be
>> >> provided instead.
>&= gt; >>
>> >> Cheers,
>>= >> Med
>> >>
>> >&g= t; >-----Message d'origine-----
>> >> >De := sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard
>> >> >(jguichar)
>> >> >Envoy= =C3=A9 : vendredi 11 juillet 2014 16:18
>> >> >= ;=C3=80 : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org
>> >> >Objet : Re: [sfc] Service Chains, Paths, a= nd Load Balancers
>> >> >
>&g= t; >> >Ok but where in the architecture specifically is this funct= ionality
>> >> >prohibited? If you want to dis= tribute *all* next-hops to *all* SFF=E2=80=99s
>> >&= gt; >within the SFC domain and then let the path identifier point to a>> >>lookup
>> >> >in= to those next-hops to reach the next SF in the chain, I am not
>>sure
>> >>how
>> &g= t;> >the architecture prevents that?
>> >> = >
>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, M= ARIA H" <mn1921@att.com>
>> wrote:
= >> >> >
>> >> >>Absolutely.<= br class=3D"">>> >> >>
>> >> &g= t;>> -----Original Message-----
>> >> >&= gt;> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard>> >> >>>(jguichar)
>>= ; >> >>> Sent: Friday, July 11, 2014 9:54 AM
&= gt;> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron = Parker; sfc@ietf.org
>> >> >>> Subject: = Re: [sfc] Service Chains, Paths, and Load Balancers
>> = >> >>>
>> >> >>> Then I m= isunderstand the proposal ;-) .. However, it seems to me
>= > >>that if
>> >> >>> you allow= an SFF to make a decision as to which remote SFF it
>>= will
>> >>use
>> >> >= ;>>for
>> >> >>> a given flow to r= each the next SF within the chain then you
>>better
>> >>make
>> >> >>&g= t; sure that that remote SFF has the necessary forwarding logic to
>> >>reach
>> >> >>>th= e
>> >> >>> next-next-SF for the chain a= s otherwise you are in deep trouble.
>> >> >&g= t;>
>> >> >>> On 7/11/14, 9:48 AM, "N= APIERALA, MARIA H" <mn1921@att.com>
>> >> w= rote:
>> >> >>>
>> &= gt;> >>> >Absolutely not. Service chains can be instantiated= only in
>>relevant
>> >> >= ;>>SFFs
>> >> >>> >when they "a= rrive".
>> >> >>> >
>= ;> >> >>> >> -----Original Message-----
>> >> >>> >> From: sfc [mailto:sfc-bounces@ie= tf.org] On Behalf Of Jim
>>Guichard
>&= gt; >> >>> >>(jguichar)
>> >>= ; >>> >> Sent: Friday, July 11, 2014 9:27 AM
&= gt;> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc= @ietf.org
>> >> >>> >> Subject: Re= : [sfc] Service Chains, Paths, and Load Balancers
>> &g= t;> >>> >>
>> >> >>> &= gt;> Well I think it is even worse than that if I have understood
>>the
>> >> >>> >>pr= oposal
>> >> >>> >> correctly as i= t would require full knowledge of every single
>>SF
>> >> >>>within
>> >= > >>> >>the
>> >> >>> = >> entire SFC domain at every single SFF as there is no way to
>>know
>> >>a
>>= ; >> >>> >>priori
>> >> >= >> >> which SFC=C2=B9s a given SFF will need to service at any = given
>>point
>> >>in
>> >> >>>time.
>> >> = >>> >>
>> >> >>> >>= On 7/10/14, 11:53 PM, "Joel M. Halpern" <jmh@joelhalpern.com>
>> >> wrote:
>> >> >>&g= t; >>
>> >> >>> >> >Ron, = thinking about this, I realized another major problem
>>= ;with
>> >>the
>> >> &g= t;>> >>your
>> >> >>> >&g= t; >proposal as I understand it. (And I readily admit I may not
>> >> >>>understand
>> >= > >>> >> >it.)
>> >> >>= ;> >> >
>> >> >>> >> &= gt;The proposal has each SFF serve as the load balancer for the
>> >>next
>> >> >>> >&= gt; >service function that follows it (not the one it delivers
>>to),
>> >>in
>>= >> >>>every
>> >> >>> &g= t;> >service chain that goes through it.
>> >&= gt; >>> >> >
>> >> >>>= >> >Since it has to be able to work with all services, that means=
>> >>that
>> >> >&g= t;> >>every
>> >> >>> >> = >SFF would have to be a full, flow sensitive and stateful load
>> >> >>>balancer.
>> >&g= t; >>> >> >I ahve no problem if some SFF are flow sensiti= ve, and / or
>> >>stateful.
>>= ; >> >>> >> >But having the architecture require th= at every SFF be a full,
>> >>flow
&= gt;> >> >>> >> >sensitive, stateful, load balanc= er seems to me to be an
>> >>acceptable
>> >> >>> >> >imposition.
>> >> >>> >> >
>> >&g= t; >>> >> >Yours,
>> >> >>= ;> >> >Joel
>> >> >>> >&g= t; >
>> >> >>> >> >On 7/10/1= 4, 10:06 PM, Joel M. Halpern wrote:
>> >> >>= ;> >> >> Part of my personal view is that I am trying to mak= e this
>>work
>> >> >>&= gt; >>sensibly
>> >> >>> >> = >> in a more orchestrated environment. I expect that the
>>service
>> >> >>> >> &g= t;> functions, and over time probably the SFF capabilities,
>>will
>> >>be
>> >= ;> >>> >> >> orchestrated and installed. I expect = the service chains
>>to be
>> >&= gt; >>> >>driven by
>> >> >>= > >> >> BSS tools that define offerings to clients, and enab= le
>> >> >>>self-selection
>> >> >>> >> >> from these. I expect ser= vice paths to be heavily policy
>> >>drive.
>> >> >>> >> >>
>= ;> >> >>> >> >> I can see how to make all of = that work in an archtiecture
>> >>driven
>> >> >>>by
>> >> >= >> >> >> initial classification to described service path= s. It is
>> >>harder
>> >= > >>>to
>> >> >>> >>se= e
>> >> >>> >> >> how to mak= e it work (but it can be done) when we allow more
>> &g= t;> >>> >> dynamicity
>> >> >= ;>> >> >> in the network behavior.
>>= >> >>> >> >>
>> >> &g= t;>> >> >> Having said that, most of that perspective I d= escribed is
>> >>outside
>> &= gt;> >>>of
>> >> >>> >>= ;the
>> >> >>> >> >> scope o= f the working group. it is not something we are
>> >= ;>tasked to
>> >> >>> >>agree>> >> >>> >> >>on.
>> >> >>> >> >> So I do not claim th= at vision means we have to do it a
>>certain
>> >> >>>way.
>> >> &g= t;>> >>it
>> >> >>> >>= >> is just the perspective that drives my preferences.
>> >> >>> >> >>
>> &g= t;> >>> >> >> Yours,
>> >>= ; >>> >> >> Joel
>> >> >&= gt;> >> >>
>> >> >>> >= > >> On 7/10/14, 9:58 PM, Ian Smith wrote:
>> = >> >>> >> >>>> For me, the amount of infor= mation about service instances
>> >> that
>> >> >>> >>needs
>> = >> >>> >> >>>>to
>> &g= t;> >>> >> >>>> be widely distributed and mai= ntained, potentially even
>> >>across
>> >> >>>data
>> >> >&= gt;> >> >>>> centers within an administrative scope, i= s large enough
>>and
>> >> &g= t;>> complex
>> >> >>> >> &g= t;>>> enough that trying to get that into each SFF seems like a>> >> >>>difficult
>> = >> >>> >> >>>> architecture to realize.>> >> >>> >> >>>
>> >> >>> >> >>> I'm curious as t= o why that is more complicated than
>>dynamic
>> >> >>> routing,
>> >&g= t; >>> >> >>> hyper-scale data center orchestration= , or DNS, all of
>>which
>> >>= ;are
>> >> >>> >>bigger
>> >> >>> >> >>> problems that ha= ve been profitably and stably implemented?
>> >> = >>> >> >>>
>> >> >>= > >> >>> It also seems that if it really is more complica= ted, that
>>is
>> >>a
>> >> >>>good
>> >> &= gt;>> >> >>> sign that it is too complicated.
>> >> >>> >> >>>
&g= t;> >> >>> >> >>> ________________________= ________________
>> >> >>> >> >= >> From: Joel M. Halpern [jmh@joelhalpern.com]
>>= >> >>> >> >>> Sent: Thursday, July 10, 2014 = 9:45 PM
>> >> >>> >> >>> = To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com;
>&= gt;Ian
>> >> >>>Smith;
>= ;> >> >>> >> >>> sfc@ietf.org
>> >> >>> >> >>> Subject: Re: [sfc] S= ervice Chains, Paths, and Load
>>Balancers
>> >> >>> >> >>>
>&g= t; >> >>> >> >>> This is an architectural iss= ue. And one that I would
>>prefer
>&g= t; >>we
>> >> >>> >> >>= ;>actually
>> >> >>> >> >>= ;> decide, rather than trying to allow all possible
>&g= t; >>implementations.
>> >> >>> &g= t;> >>> Because it does have a major effect on the control
>> >>requirements
>> >> >= ;>>and
>> >> >>> >> the
>> >> >>> >> >>> functionalit= y of SFFs.
>> >> >>> >> >>&g= t;
>> >> >>> >> >>> For m= e, the amount of information about service instances
>>= >>that
>> >> >>> needs
>> >> >>> >> to
>> >= ;> >>> >> >>> be widely distributed and maintain= ed, potentially even
>> across
>> &= gt;> >>>data
>> >> >>> >&= gt; >>> centers within an administrative scope, is large enough>>and
>> >> >>>complex=
>> >> >>> >> >>> enough = that trying to get that into each SFF seems like a
>> &= gt;> >>>difficult
>> >> >>> = >> >>> architecture to realize.
>> >&= gt; >>> >> >>>
>> >> >= >> >> >>> Yours,
>> >> >&= gt;> >> >>> Joel
>> >> >>= > >> >>>
>> >> >>> >= ;> >>> But it is a fair question.
>> >&g= t; >>> >> >>>
>> >> >&= gt;> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:
>> >> >>> >> >>>> This is th= e crux of my issue.   Is the end to end
>>selectio= n
>> >>of
>> >> >>= ;> >> >>>> (top-level) instances performed centrally (= perhaps by the
>> >> >>> >>classif= ier)
>> >> >>> >> >>>>= or hop-by-hop (perhaps by the classifier and subsequently
&g= t;> >>the
>> >> >>> >>SFF= s)?
>> >> >>> >> >>>> = Such selection is not equivalent to reclassification.
>>= ;And
>> >> >>>surely,
>= > >> >>> >> >>>> this is an architectur= al issue and not relegated to
>> >> >>> = >> >>>> "implementation".
>> >>= >>> >> >>>>
>> >> >= ;>> >> >>>> My own view is to favor the distributed= approach even
>> though
>> >>= ; a
>> >> >>> >> >>>> = greater amount of data (chain definitions and perhaps
>>= ;local
>> >> >>> >>selection
>> >> >>> >> >>>> policy) i= s required at those distributed decision points.
>> >= ;>This
>> >> >>> >> >>>= ;> approach does not require an end-to-end path id at all.
>> >>My
>> >> >>> >> = >>>> rationale for favoring this approach is primarily driven>>by
>> >> >>> >&g= t;increased
>> >> >>> >> >>&= gt;> resiliency over the global path id approach.   With a
>>global
>> >> >>>path
>> >> >>> >>id
>> &= gt;> >>> >> >>>> approach, consider failure o= f an instance and needing to
>> >>alter
>> >> >>>the
>> >> >= ;>> >> >>>> global path ID table for each and every= affected
>>end-to-end
>> >> = >>>path.
>> >> >>> >> >= ;>>>
>> >> >>> >> >>= ;>> Ron
>> >> >>> >> >>= ;>>
>> >> >>> >> >>>= ;> ________________________________________ From: sfc
>= > >> >>> >> >>>> [sfc-bounces@ietf.org]= on behalf of Joel Halpern Direct
>> >> >>&= gt; >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, = July 10,
>>2014
>> >> 6:15>> >> >>> PM
>> >&g= t; >>> >> >>>> To: mikebianc@aol.com; I.Smith@F5= .com; sfc@ietf.org
>> Subject:
>> &= gt;> Re:
>> >> >>> >> >>&= gt;> [sfc] Service Chains, Paths, and Load Balancers
>&= gt; >> >>> >> >>>>
>> = >> >>> >> >>>> The way the architecture mo= dels the case of SF1 needing
>>to
>>= ; >> >>> >>influence
>> >> &= gt;>> >> >>>> the chain is that one would do reclas= sification at the
>>exit
>> >>= ;from
>> >> >>> >> >>>>= ; SF1.
>> >> >>> >> >>>&g= t;
>> >> >>> >> >>>> P= art of the goal is to keep the different functions
>> &= gt;>logically
>> >> >>> >> >= >>> separate so that solutions can clearly describe how they
>> >> choose
>> >> >>&= gt;to
>> >> >>> >> >>>>= ; compose them for "service" delivery.
>> >> >= >> >> >>>>
>> >> >>= > >> >>>> Yours, Joel
>> >> = >>> >> >>>>
>> >> >= >> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com w= rote:
>> >> >>> >> >>>>= ;> I don't see anything in the arch draft that suggests any
>> >>sort
>> >> >>>of
>> >> >>> >> >>>>> limi= t. However, it does seem to indicate that the entire
>>= >>path
>> >> >>>(all
>> >> >>> >> >>>>> SFIs) must b= e chosen at SFC instantiation. I believe
>>this
>> >> >>>means
>> >>= >>> >> >>>>> either at the classifier or may= be the classifier
>>chooses a
>> &g= t;>SF
>> >> >>> >>Chain
>> >> >>> >> >>>>> and the= NF or at the latest the first SFF. In any case,
>> &g= t;>the
>> >> >>> >> >>>= ;>> language does seem to prohibit a more dynamic SFP where
>> >> SFI(n)
>> >> >>>= is
>> >> >>> >> >>>>&= gt; determined at the SFI(n-1) hop. According to the draft,
= >> >>this
>> >> >>> >>= >>>>> behavior would be considered "branching" to a new SFP= as
>> >> >>> opposed
>= > >> >>> >> to
>> >> >= >> >> >>>>> choosing and then forwarding to the = selected instance of
>> >>the
>&= gt; >> >>> >> >>>>> next-hop of the cur= rent SFC.
>> >> >>> >> >>>= ;>>
>> >> >>> >> >>>= ;>> draft-merged-sfc-architecture-00:
>> >>= >>> >> >>>>>> When an SFC is instantiated= into the network it is
>> >>necessary
>> >> >>>to
>> >> >= >> >> >>>>>> select the specific instances of= SFs that will be used,
>> >>and to
>> >> >>> >> >>>>>> create th= e service topology for that SFC using SF's
>> >>n= etwork
>> >> >>> >> >>>&g= t;>> locator. Thus, instantiation of the SFC results in the
>> >> >>>creation
>> >>= ; >>> >> >>>>>> of a Service Function Path= (SFP) and is used for
>> >>forwarding
>> >> >>> >> >>>>>> pack= ets through the SFC. In other words, an SFP is the
>> &= gt;> >>> >> >>>>>> instantiation of the= defined SFC.
>> >> >>> >> >>= ;>>>>
>> >> >>> >> >= ;>>>>> The SFC architecture supports reclassification (or>> >>non-initial
>> >> &g= t;>> >> >>>>>> classification) as well. As p= ackets traverse an SFP,
>> >> >>> >&g= t; >>>>>> reclassification may occur - typically performe= d by a
>> >> >>> >> >>>&g= t;>> classification function co-resident with a service
>> >>function.
>> >> >>> &g= t;> >>>>>> Reclassification may result in the selectio= n of a new
>> >>SFP, an
>> &g= t;> >>> >> >>>>>> update of the associa= ted metadata, or both. This is
>> >>referred
>> >> >>>to
>> >>= >>> >> >>>>>> as "branching".
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> = >>>
>> >>
>>
>>>>>>>>>>>>>>-----------= --------------------------------------------------
>>&g= t;>>>>>>>>>>>--
>> >= ;>>>>>>>>>>>---
>> >= ;> >>>>>>>>>>--
>> >= ;> >>> >>>>>>>--
>> &g= t;> >>> >> >>>>>--
>> = >> >>> >> >>>>>
>> = >> >>> >> >>>>>
>> = >> >>> >> >>>>>
>> = >> >>> >> >>> *From: *I.Smith@F5.com<I.Smi= th@F5.com>
>> >> >>> >> >>= ;>>> *To: *Joel Halpern
>> Direct<jmh.direc= t@joelhalpern.com>,Joel
>> >> M.
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> &g= t;>>
>> >>
>> >>&= gt;>>Halpern<jmh@joelhalpern.com>,huang@sce.carleton.ca<huan= g@sce.
>> >> >>> >> carleton.
>> >> >>> >> >>>>>ca>= ;,sfc@ietf.org<sfc@ietf.org>
>> >> >>= > >> >>>>>
>> >> >>= > >> >>>>>
>> >> >>= > >> >>>>>
>> >> >>= > >> >>> *Sent: *Thursday, July 10, 2014
&g= t;> >> >>> >> >>>>> *Subject: *Re: [= sfc] Service Chains, Paths, and Load
>> >>Balance= rs
>> >> >>> >> >>>>&g= t;
>> >> >>> >> >>>>&g= t; Actually, I think I am disagreeing.
>> >> >= >> >> >>>>>
>> >> >= >> >> >>>>> If the possibility of medium-scale d= eployments (and
>>that is
>> >&g= t; >>>what
>> >> >>> >> &= gt;>>>> 16 million flows is in my world) of service chains is>> >> >>>preconceived
>&= gt; >> >>> >> >>>>> as an absurd idea, = then the architecture burdened with
>> that
>> >> >>> >> >>>>> preconcepti= on.
>> >> >>> >> >>>>&= gt;
>> >> >>> >> >>>>&= gt; There has to be some point of aim, some degree of
>>= ; >>aspiration
>> >> to
>&= gt; >> >>> >> >>>>> scale that is appro= priate for the lifespan of the
>> >>architecture<= br class=3D"">>> >> >>>-
>> >&g= t; >>> >> >>>>> you don't have to know what i= t is, but by saying that an
>> >> >>>arb= itrary
>> >> >>> >> >>>&g= t;> number is "too far", you're creating - even if it isn't
>> >> >>> >>intentional
>>= >> >>> >> >>>>> - a limit that influen= ces decisions that have lasting
>> >>impacts
>> >> >>> >> >>>>> rega= rding scale-out, failure mitigation, elasticity,
>> >= ;>address
>> >> >>> >> >>= >>> space... all kinds of things. That is a problem I'm not
>> >> >>> >> >>>>> partic= ularly eager to deal with.
>> >> >>> >= ;> >>>>>
>> >> >>> >= ;> >>>>>
>> >> >>> >= ;> >>>>>
>> >> >>> >= ;> >>>>>
>> >> >>> >= ;> >>>>> ________________________________________
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> From: J= oel Halpern Direct [jmh.direct@joelhalpern.com]
>> >= >Sent:
>> >> >>> >> >>>= ;>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M.
>> >> Halpern;
>> >> >>&g= t; >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subjec= t: Re: [sfc]
>> >>Service
>> = >> >>> >> >>>>> Chains, Paths, and Load= Balancers
>> >> >>> >> >>&g= t;>>
>> >> >>> >> >>&g= t;>> Ian, I don't think you disagree with me at all in this
>> >>regard.
>> >> >>>= I
>> >> >>> >>am
>= ;> >> >>> >> >>>>> not requesting th= e the architecture or the solution
>> >>prohibit<= br class=3D"">>> >> >>> >> >>>>> = deployments in the specific fashion. I am objecting to
>&g= t; >>Huang's
>> >> >>> >> &g= t;>>>> reading of my note as saying that such deployments are>> >> required
>> >> >= ;>> >> >>>>> they by the archtiecture.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> As I hav= e said repeatedly, I am not trying to prohibit
>>such>> >> >>> >> >>>>> t= hings. Whether they are a good idea or not depends upon
>&= gt; >> many
>> >> >>> >> >= ;>>>> factors outside of the scope of the WG. I happen to
>>think
>> >>that
&g= t;> >> >>> >>they
>> >> &= gt;>> >> >>>>> are usually a bad idea.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> But the = archtiecture si carefully avoiding attempting to
>> >= ;>know
>> >> >>>what
&g= t;> >> >>> >> >>>>> is and is not ep= loyable.
>> >> >>> >> >>>= >>
>> >> >>> >> >>>= >> Yours, Joel
>> >> >>> >> = >>>>>
>> >> >>> >> = >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:
&g= t;> >> >>> >> >>>>>> I disagree.<= br class=3D"">>> >> >>> >> >>>>>&= gt;
>> >> >>> >> >>>>&= gt;> We routinely have stateful devices that manage tens of
>> >> >>>millions
>> >> &g= t;>> >> >>>>>> of
>> >= > >>> >> >>>>> concurrent flows in both ac= cess network and data center
>> >> >>> &= gt;> >>>>> environments today. You can't seriously believ= e that in
>>the
>> >> >>= ;> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of= tomorrow you
>> are
>> >> on= ly
>> >> >>> >> going
>> >> >>> >> >>>>> to have smal= l numbers of service chains with equally
>>small
>> >> >>> numbers
>> >&= gt; >>> >> >>>>> of active service paths?
>> >> >>> >> >>>>>>=
>> >> >>> >> >>>>>= > Your sounds too much like "no one will ever need more
&g= t;> than
>> >> >>> 64K"
>> >> >>> >> >>>>>> for
>> >> >>> >> >>>>> comfo= rt.
>> >> >>> >> >>>>&= gt;>
>> >> >>> >> >>>&= gt;>>
>> >> >>> >> >>&= gt;>>> ________________________________________ From: sfc
>> >> >>> >> >>>>>> [sfc= -bounces@ietf.org] on behalf of Joel M. Halpern
>> >= > >>> >> >>>>> [jmh@joelhalpern.com]
>> >> >>> >> >>>>>> S= ent: Thursday, July 10, 2014 4:46 PM To:
>> >> &g= t;>>huang@sce.carleton.ca;
>> >> >>&g= t; >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Servic= e Chains, Paths,
>>and
>> >> = >>>Load
>> >> >>> >> >= >>>>> Balancers
>> >> >>>= >> >>>>>>
>> >> >>= > >> >>>>>> No, it will mean that if someone tri= es to deploy the
>> >> >>>archtieture>> >> >>> >> >>>>>>= ; particularly badly, they will exceed the limits of
>>= their
>> >> >>> >> >>>>= ;>> devices. The architecture does not require such absurd
>> use
>> >> of
>>= ; >> >>> >> >>>>>> service paths. Si= nce I can not figure out how to write
>> >> >&= gt;> >> >>>>>> architectural words to prohibit i= t, the architecture
>>does
>> >&= gt; >>>permit
>> >> >>> >>= ; >>>>>> such abuse.
>> >> >= >> >> >>>>>>
>> >> = >>> >> >>>>>> Please do not read my saying= that the archtiecture
>> permits
>>= ; >> >>> >> >>>>>> something as sayi= ng it is either deisred or required by
>> >>the>> >> >>>work.
>> >= ;> >>> >> >>>>>> It isn't.
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> Your= s, Joel
>> >> >>> >> >>>&= gt;>>
>> >> >>> >> >>&= gt;>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:
= >> >> >>> >> >>>>>>> If you= need to support 100 service chains, it will
>>mean
>> >> >>> >> >>>>>>= > 16,000,000 paths. That is larger than the routing
>&g= t;table
>> >>of a
>> >>= >>> >> >>>>>>> core router.
>> >> >>> >> >>>>>>><= br class=3D"">>> >> >>> >> >>>>>&= gt;> Chang
>> >> >>> >> >>= ;>>>>>
>> >> >>> >>= >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote= :
>> >> >>> >> >>>>>= ;>>> The architecture allows a range of deployments, from
>>1
>> >> >>> >> >&= gt;>>>>>> service path to 160000 service paths. I would h= ope
>>that
>> >> >>>= >> >>>>>>>> operators are prepared for the c= omplexities if they
>> >>choose
>= ;> >> >>>to
>> >> >>> = >> >>>>>>>> avoid any use of local load balan= cing and in stead
>> >> provision
&= gt;> >> >>> >> >>>>>>>> 160= ,000 service paths.
>> >> >>> >> &= gt;>>>>>>>
>> >> >>>= ; >> >>>>>>>> Yours, Joel
>&= gt; >> >>> >> >>>>>>>>
>> >> >>> >> >>>>>>>= > On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
>> = >> >>> >> >>>>>>>>> Paul,>> >> >>> >> >>>>>&g= t;>>>
>> >> >>> >> >&g= t;>>>>>>> How many path identifiers there will be for = a 4 hop
>> >> service
>> >= > >>> >> >>>>>>>>> chain with = 20 instances at each hop?
>> >> >>> >= > >>>>>>>>>
>> >> &= gt;>> >> >>>>>>>>> Maria
>> >> >>> >> >>>>>>>>= >
>> >> >>> >> >>>>= >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf>> Of
>> >> >>> >&g= t; >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursda= y, July 10, 2014
>> >>3:03
>>= >> >>> >> >>>>>>>>> PM *To= :* Lucy yong *Cc:* jmh@joelhalpern.com;
>> >> >= ;>> >> >>>>>>>>> mohamed.boucadair@o= range.com; sfc@ietf.org;
>> >> >>> >&= gt; >>>>>>>>> mikebianc@aol.com *Subject:* Re: [= sfc] Service
>> Chains,
>> >>= >>> >> >>>>>>>>> Paths, and Load= Balancers
>> >> >>> >> >>&g= t;>>>>>>
>> >> >>> >= ;> >>>>>>>>> Lucy,
>> >= ;> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>&= gt;> Overall I concur, as you say: a path ID drives the
&g= t;> >> >>> >> >>>>>>>>> = forwarding. I=C2=B9d
>> >> >>> >> = >>>>> make
>> >> >>> >= > >>>>>>>>> the minor change: the path identi= fier can be used to
>> >> derive
&g= t;> >> >>> >> >>>>>>>>> = the needed forwarding and associated transport.
>> >= > >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>= > It is _not_ the transport, but rather is used to
>>= ;simply
>> >> >>> >> >>>&= gt;>>>>> identify the service path (or graph) that packets>>must
>> >> >>> >= > >>>>>>>>> traverse. By having a path identi= fier, the exact
>> >> >>> >> >&= gt;>>>>>>> indirection that people seem to be asking f= or on
>>this
>> >> >>&g= t; >> >>>>>>>>> thread can be simply be im= plemented. The path
>> >> identifier
>> >> >>> >> >>>>>>>>&= gt; provides nothing more than a lookup, that lookup can
>= > >> result
>> >> >>> >> = >>>>>>>>> in a one or more (equal or weighted) t= ransport next
>> >> >>> >> >>= ;>>>>>>> hop(s).
>> >> >&= gt;> >> >>>>>>>>>
>>= ; >> >>> >> >>>>>>>>> Paul<= br class=3D"">>> >> >>> >> >>>>>&= gt;>>>
>> >> >>> >> >&= gt;>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong
>> >> >>> >> >>>>>>= >>> <lucy.yong@huawei.com
>> >> <m= ailto:lucy.yong@huawei.com>>
>> >> >>= > >> >>>>>>>>> wrote:
>= ;> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>&g= t;>>>
>> >> >>> >> >&g= t;>>>>>>>
>> >> >>>= >> >>>>>>>>> Agree. The arch. doc should = not mandate only use of
>> the
>> &= gt;> >>> >> >>>>>>>>> service = path identifier to drive the forwarding
>> >>acti= ons.
>> >> >>> >> >>>>= >>>>>
>> >> >>> >> = >>>>>>>>> Lucy
>> >> &= gt;>> >> >>>>>>>>>
>= ;> >> >>> >> >>>>>>>>> *= From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf
>> &g= t;> >>> >> >>>>>>>>> Of*mohame= d.boucadair@orange.com
>> >> >>> >>= ; >>>>>>>>> <mailto:mohamed.boucadair@orange.= com>
>> >> >>> *Sent:*Thursday,
>> >> >>> >> July
>>= ; >> >>> >> >>>>>>>>> 10, 2= 014 2:06 AM *To:*mikebianc@aol.com
>> >> >>= > >> >>>>>>>>> <mailto:mikebianc@aol= .com>;jmh@joelhalpern.com
>> >> >>> &= gt;> >>>>>>>>> <mailto:jmh@joelhalpern.com= >;sfc@ietf.org
>> >> >>> >> >= ;>>>>>>>> <mailto:sfc@ietf.org> *Subject:*Re:= [sfc] Service
>> >>Chains,
>>= ; >> >>> >> >>>>>>>>> Paths= , and Load Balancers
>> >> >>> >> = >>>>>>>>>
>> >> >&g= t;> >> >>>>>>>>> Re-,
>= ;> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>&g= t;>>> The merged draft calls out explicitly a service path
>> >> >>> >> >>>>>>>= >> identifier. I object to use that identifier to
>&= gt;derive
>> >> >>> >> >>>= ;>>>>>> forwarding actions.
>> >&g= t; >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>&g= t; Requiring a SFC system to have the full knowledge of
>&= gt; >> every
>> >> >>> >> &g= t;>>>> available SFC
>> >> >>&g= t; >> >>>>>>>>> forwarding paths within an= SFC-enabled domain is not
>> >> >>> >= ;> >>>>> required/justified
>> >&g= t; >>> >> >>>>>>>>> nor possible = in various deployment contexts.
>> >> >>>= ; >> >>>>>>>>>
>> >= > >>> >> >>>>>>>>> SFC forward= ing actions should rely on the piece of
>> >> >= ;>> >> >>>>>>>>> information
>> >> >>> >> >>>>> that wi= ll
>> >> >>> >> >>>>&g= t;>>>> be present in all deployments: that is the one
>> required
>> >> to
&g= t;> >> >>> >> >>>>>>>>> = structure a service chain. How that information is
>> &= gt;>used to
>> >> >>> >> >&g= t;>>>>>>> infer forwarding
>> >= > >>> >> >>>>> actions
>&= gt; >> >>> >> >>>>>>>>> is = a solution-oriented discussion.
>> >> >>>= ; >> >>>>>>>>>
>> >= > >>> >> >>>>>>>>> Cheers,
>> >> >>> >> >>>>>>= >>>
>> >> >>> >> >>= >>>>>>> Med
>> >> >>&g= t; >> >>>>>>>>>
>> >= ;> >>> >> >>>>>>>>> *De :*sfc = [mailto:sfc-bounces@ietf.org]*De la part
>> >> &g= t;>> >> >>>>> de*mikebianc@aol.com
>> >> >>> >> >>>>>>>>&g= t; <mailto:mikebianc@aol.com> *Envoy=C3=A9 :*mercredi 9
>> >> juillet
>> >> >>> >= ;> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhal= pern.com
>> >> >>> >> >>>= >>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org>> >> >>> >> >>>>>>= ;>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service
>> >>Chains,
>> >> >>&g= t; >> >>>>>>>>> Paths, and Load Balancers<= br class=3D"">>> >> >>> >> >>>>>&= gt;>>>
>> >> >>> >> >&= gt;>>>>>>> Is anyone still questioning the difference = between
>>SF
>> >> Chain
>> >> >>> >> >>>>>>&= gt;>> and SF
>> >> >>> >> &g= t;>>>> Path?
>> >> >>> >&= gt; >>>>>>>>> Other than clarifying the definiti= on so that it's
>> >>clear to
>&= gt; >> >>> >> >>>>> those not
>> >> >>> >> >>>>>>>&= gt;> familiar with the draft, it seems that everyone
>&= gt;agrees
>> >>on
>> >>= >>> >> >>>>>>>>> these terms.>> >> >>> >> >>>>>>= ;>>>
>> >> >>> >> >>= ;>>>>>>> To me, the one point that is still unclear is=
>>whether
>> >>it is
>> >> >>> >> >>>>>>>= >> the intent of this draft to ultimately specify what
= >> >>the ID
>> >> >>> >&g= t; >>>>>>>>> of the SFC Header
>= ;> >> >>> >> >>>>> should
>> >> >>> >> >>>>>>>&= gt;> reference (the chain or the path), or if this draft
&= gt;> >>simply
>> >> >>> >>= ; >>>>>>>>> intends to leave that ambiguous, all= owing other
>>drafts
>> >>to<= br class=3D"">>> >> >>> >> >>>>>&= gt;>>> dictate the mechanisms for forwarding based on chain
>> or
>> >> >>> >> &= gt;>>>>>>>> path and the choice of chain or
>> >> >>> >> >>>>> path to=
>> >> >>> >> >>>>>= >>>> be negotiated in the control-plane.
>>= >> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>= ;>> If the latter (ambiguous), then the draft would have
>> >> >>> >> >>>>>>>>&= gt; require that both SFP and SFC be supported (or make
>&= gt; >> one
>> >> >>> >> >= >>>>>>>> required and the other optional) to avoid = some
>> vendors
>> >> only>> >> >>> >> >>>>>>= ;>>> supporting SFP and others only supporting SFC.
= >> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>= ;>>>>
>> >> >>> >> >= ;>>>>
>> >> >>> >>
>> >> >>>
>> >>>>
>>>>>>>>>&g= t;>>>>---------------------------------------------------------= ----
>>>>>>>>>>>>>>= --
>> >>>>>>>>>>>>-= --
>> >> >>>>>>>>>>= --
>> >> >>> >>>>>>>= ;--
>> >> >>> >> >>>>&= gt;--
>> >> >>> >> >>>>= ;>
>> >> >>> >> >>>>= ;>
>> >> >>> >> >>>>= ;>
>> >> >>> >> >>>>= ;>>>
>> >> >>> >> >>= ;>>>>>>> *From:*jmh@joelhalpern.com<jmh@joelhalpern= .com
>> >> >>> >> >>>>= >>>>>
>> >> <mailto:jmh@joelhal= pern.com%3cjmh@joelhalpern.com>>
>> >> >= >> >> >>>>>>>>> *To:*sfc@ietf.org<= ;sfc@ietf.org
>> >> >>> >> >>= ;>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org>>= ;
>> *Sent:*Tuesday,
>> >> Ju= ly
>> >> >>> >> >>>>&g= t;>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and
>>Load
>> >> >>> >>= >>>>>>>>> Balancers
>> >= > >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>= > I have been trying to figure out how to clearly
>>= answer
>> >>a
>> >> >= ;>> >> >>>>>>>>> number of comments = that have been made about the
>> >> >>> = proposed
>> >> >>> >> >>>= >>>>>> merged archtiecture draft. Assuming we can get
>> working
>> >> >>> &g= t;> >>>>>>>>> group agreement on the intent, = we will work to
>> improve
>> >&= gt; the
>> >> >>> >> >>>&= gt;>>>>> wording so that readers who have not participated i= n
>> >>the
>> >> WG
>> >> >>> >> >>>>>>= >>> discussion will understnd it the way the
>>= ; >> >>> >> >>>>> working
>> >> >>> >> >>>>>>>>&g= t; group intends.
>> >> >>> >> >= ;>>>>>>>>
>> >> >>&= gt; >> >>>>>>>>> But what do we intend? I = will try to explain my
>> >>personal
>> >> >>> >> >>>>>>>>&= gt; view, and see if that helps.
>> >> >>&g= t; >> >>>>>>>>>
>> >= ;> >>> >> >>>>>>>>> In this re= gard, it is important to keep in mind that
>> >>w= hat
>> >> >>> >> >>>>&= gt;>>>> we are defining is the data plane architecture. We
>>are
>> >> not
>= ;> >> >>> >> >>>>>>>>> a= ttempting to define the architecture for the entire
>> = >> >>> >> >>>>>>>>> solutio= n for service chaining. That would encompass
>> >>= ; >>> >> >>>>>>>>> OSS/BSS, vario= us control and policy functions,
>>virtual
>> >> >>> >> >>>>>>>>&= gt; machine and image management, and many other
>> >= ;> aspects.
>> >> >>> >> >&g= t;>>>>>>>
>> >> >>>= >> >>>>>>>>> As a result there are many t= hings which clearly need
>> to
>> &= gt;> >>> >> >>>>>>>>> exist in= the larger system, but which are dealt with
>> >>= ;above
>> >> >>> >> >>>&g= t;>>>>> where we are
>> >> >>= ;> >> >>>>> functioning,
>> >= ;> >>> >> >>>>>>>>> and are no= t directly required by the work we are
>> doing.
>> >> >>> >> >>>>>>>= ;>>
>> >> >>> >> >>>= ;>>>>>> In order to get to service chain vs service path,=
>>as I
>> >> >>> &g= t;> >>>>>>>>> understand
>&g= t; >> >>> >> >>>>> them,
= >> >> >>> >> >>>>>>>>>= ; I need to first discuss load balancing. There are at
>&g= t; >>least
>> >> >>> >> >= >>>>>>>> three different ways that load balancing c= an and
>>will
>> >> >>&= gt; >> >>>>>>>>> interact with service cha= ining. There probably are
>> >>more.
>> >> >>> >> >>>>>>>>&= gt; The point of the archtiecture is to permit all of
>>= ; >>these,
>> >> >>> >> >= >>>>>>>> but not to mandate that any particular kin= d
>> >> >>> >> >>>>>= ; be used
>> >> >>> >> >>>= ;>>>>>> in any solution.
>> >> = >>> >> >>>>>>>>>
&g= t;> >> >>> >> >>>>>>>>> = 1) Load balancing as a service provided to the end
>> &= gt;>user.
>> >> >>> >> >>= >>>>>>> This is a service function. It receives user>>packets,
>> >>and
>> >> >>> >> >>>>>>>&= gt;> modifies them (or
>> >> >>> >= > >>>>> marks
>> >> >>>= ; >> >>>>>>>>> them, or ...) so as to choo= se an end user service
>> >>instance
>> >> >>> >> >>>>>>>>&= gt; to receive the users packet. This is an important
>>= ; >>service
>> >> >>> >> >= ;>>>>>>>> function to be able to include in service= chaining.
>> >>It's
>> >&= gt; >>> >> >>>>>>>>> behavior may= affect requirements on how service
>> >> chainin= g is
>> >> >>> >> >>>>= >>>>> done. But it has very little impact on the
>> >>archtiecture.
>> >> >>&= gt; >> >>>>>>>>> From an architectural pe= 3rspective it is simply a
>> >> >>> >= > >>>>> service
>> >> >>&= gt; >> >>>>>>>>> function which may modify= the underlying packet.
>> >> >>> >&g= t; >>>>>>>>>
>> >> >= ;>> >> >>>>>>>>> 2) There is interna= l load balancing. That is, one
>>can
>= > >>have
>> >> >>> >> >= ;>>>>>>>> what
>> >> >= >> >> >>>>> appears
>> >&= gt; >>> >> >>>>>>>>> to the servi= ce chaining architecture as a single
>>point
>> >>of
>> >> >>> >= > >>>>>>>>> contact
>> &g= t;> >>> >> >>>>> for a
>&= gt; >> >>> >> >>>>>>>>> spe= cific service function, but is actually delivered
>> &g= t;>by a
>> >> >>> >> >>&g= t;>> collection of
>> >> >>> >&= gt; >>>>>>>>> virtual or physical machines, poss= ibly including
>>one or
>> >>= >>> >> >>>>>>>>> several load ba= lancers (for example using VRRP-like
>> >> >&g= t;> >> >>>>>>>>> techniques to share a = MAC address.) mostly, this is
>> >> >>> = >> >>>>>>>>> invisible to the service chai= ning data plane
>> >>mechanisms.
&g= t;> >> It
>> >> >>> >> &g= t;>>>>>>>> is likely that it is visible to various = control
>> >>mechanisms,
>> &= gt;> >>> >> >>>>>>>>> such as = those responsible for scale-in, scale-out,
>>and
>> >>vm
>> >> >>> &= gt;> >>>>>>>>> instantiation. The architectur= al impact of
>>permitting
>> >&= gt;this
>> >> >>> >> >>>&= gt;>>>>> is largely that we need to be careful that our
>> >>terminology
>> >> >= >> >> >>>>>>>>> does not lead
>> >> >>> >> >>>>> reader= s to
>> >> >>> >> >>>>= >>>>> think we are prohibiting it.
>> &g= t;> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>&= gt;> 3) There can also be load balancing done by
>>= selecting
>> >> >>> >> >>>= ;>>>>>> packet paths for the service chaining that direct=
>> >>traffic
>> >> >= ;>> >> >>>>>>>>> to different places= . We would not want to require
>> that
&g= t;> >>a
>> >> >>> >> >= >>>>>>>> given service function appear at only one = place in
>>the
>> >> >>= ;> >> >>>>>>>>> network.
= >> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>= ;>>>> It is of course the case that these may be
>>combined. I
>> >> tend
>= ;> >> >>> >> >>>>>>>>> t= o
>> >> >>> >> >>>>>= ; refer to
>> >> >>> >> >>&g= t;>>>>>> the collection of entities that appear to servic= e
>> >>chaining
>> >> &= gt;>> >> >>>>>>>>> as a single point= as a cluster. Not because cluster
>>is
= >> >>a
>> >> >>> >> &g= t;>>>>>>>> good term. But because I do not have ano= ther one.
>> Thus,
>> >> the<= br class=3D"">>> >> >>> >> >>>>>&= gt;>>> point of type 3 load balancing
>> >&= gt; >>> >> >>>>> is to
>>= >> >>> >> >>>>>>>>> direct= different subsets of traffic to different
>> >>s= ingular
>> >> >>> >> >>>&= gt;>>>>> or clustered service functions in different places =
>>in
>> >>the
= >> >> >>> >> >>>>>>>>>= ; network.
>> >> >>> >> >>&g= t;>>>>>>
>> >> >>> >= ;> >>>>>>>>> Now with that said, what do I me= an when I talk about
>> >> >>> >> = >>>>>>>>> service chain and service path/ Servic= e chain is a
>> >> sequence
>>= ; >> >>> >> >>>>>>>>> of lo= gical functions to be applied to a subset of
>> >>= ;packets.
>> >> >>> >> >>>= ;>>>>>> It is equivalent of saying that some subset of >>traffic
>> >>is
>> >> >>> >> >>>>>>>>&= gt; to get DPI, charging, content inspection, and
>>fi= rewall
>> >> >>> >> >>>&g= t;>>>>> while a different subset is to go directly to the >>cache
>> >> >>> >= ;> >>>>> without
>> >> >>= > >> >>>>>>>>> visiting any other servi= ce functions.
>> >> >>> >> >>= ;>>>>>>>
>> >> >>> = >> >>>>>>>>> That is not enough informatio= n to direct the
>>packets.
>> A>> >> >>> >> >>>>>>= ;>>> service path is, in some fashion, a sequence of
>> >>locations
>> >> >>> &g= t;> >>>>>>>>> in the network. Those locations= will be singular or
>> >> >>> >> = >>>>>>>>> clustered service function delivery lo= cations. They
>> >>may be
>> = >> >>> >> >>>>>>>>> address= ed by IP address. They may be addressed as
>> ports
>> >> on
>> >> >>>= ; >> >>>>>>>>> an SFF. There are many diff= erent ways that the
>> >>locations
= >> >> >>> >> >>>>>>>>>= ; may be known to the service chaining infrastructure
>>= ; and
>> >> the
>> >> &= gt;>> >> >>>>>>>>> transport.
>> >> >>> >> >>>>>>>= ;>>
>> >> >>> >> >>>= ;>>>>>>> From the point of view of the work of the SF= C
>>group,
>> >> we
>> >> >>> >> >>>>>>>&= gt;>> need to be
>> >> >>> >>= ; >>>>>>>>> able to talk about the high level ab= straction, the
>> >>service
>>= ; >> >>> >> >>>>>>>>> chain= , which drives the forwarding. And we need to
>> talk>> >> >>> >> >>>>>&g= t;>>> about the actual data path packets will take in the
>> >> >>> >> >>>>>>>&= gt;> network.
>> >> >>> >> >= >>>>>>>>
>> >> >>&g= t; >> >>>>>>>>> Several of the comments ha= ve said "but the whole
>> path
>> &= gt;> may
>> >> >>> >> >>&= gt;>>>>>> not be known at the front." This architecture d= eals
>> >>with
>> >> &g= t;>> >> >>>>>>>>> that issue in two = ways. First, as noted in item (2)
>>on
&= gt;> >>load
>> >> >>> >> = >>>>>>>>> balancers above, there can be decision= s and
>>behaviors
>> >> whic= h
>> >> >>> >> >>>>>= ;>>>> are invisible to the service chaining mechanisms (in
>> >>much
>> >> >>>= ; >> >>>>>>>>> the same way that bridging = within a LAN is largely
>> >> >>> >&g= t; >>>>>>>>> invisible to routing between LANs.)= The other
>> provision
>> >>= we
>> >> >>> >> >>>>&= gt;>>>> make is
>> >> >>> &g= t;> >>>>> that
>> >> >>&g= t; >> >>>>>>>>> reclassification can be do= ne in mid-chain when
>> >> necessary.
>> >> >>> >> >>>>>>>>= > That will direct packets to a new chain. Based on
>&g= t; >> >>> >> >>>>>>>>> info= rmation available at the re-classification
>>point.>> >> >>> >> >>>>>>= ;>>>
>> >> >>> >> >>= ;>>>>>>> I hope that this helps explain what we are af= ter.
>>If it
>> >> >>&= gt; >> >>>>>>>>> does, and if the intent i= s acceptable to the working
>> >> group,
>> >> >>> >> >>>>>>>&= gt;> we can figure out what additional words are needed
&g= t;> to
>> >> >>> >> >>>= ;>>>>>> convey this. If the working group disagree with t= he
>> >> intent,
>> >> = >>> >> >>>>>>>>> then we will of = course adjust to match the working
>> >>group
>> >> >>> >> >>>>>>= >>> agreements. If this is still unclear, I am not sure
>> >>what to
>> >> >>>= >> >>>>>>>>> try next.
>= > >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>= ;>>> Yours, Joel
>> >> >>> >= > >>>>>>>>>
>> >> &= gt;>> >> >>>>>>>>>
>= ;> _______________________________________________
>>= ; >> sfc
>> >> >>> >> mailin= g
>> >> >>> >> >>>>>= ;>>>> list sfc@ietf.org <mailto:sfc@ietf.org>
>> >> >>> >> >>>>>>>>= > https://www.ietf.org/mailman/listinfo/sfc
>> >&= gt; >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>&= gt;
>> _______________________________________________<= br class=3D"">>> >> sfc
>> >> >>= ;> >> mailing
>> >> >>> >>= ; >>>>>>>>> list sfc@ietf.org <mailto:sfc@iet= f.org>
>> >> >>> >> >>>= ;>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>>>>= >>
>> >> >>> >> >>>= >>>>>
>> >> >>> >> = >>>>>>>>
>> ___________________= ____________________________
>> >> sfc
>> >> >>> >> mailing
>>= ; >> >>> >> >>>>>>>> list sfc@= ietf.org
>> >>https://www.ietf.org/mailman/listin= fo/sfc
>> >> >>> >> >>>&g= t;>>>>
>> >> >>> >> &g= t;>>>>>>
>> >> >>> >= ;> >>>>>>> ________________________________________= _______
>> sfc
>> >> >>= > >> mailing
>> >> >>> >>= >>>>>>> list sfc@ietf.org
>> >= >https://www.ietf.org/mailman/listinfo/sfc
>> >&g= t; >>> >> >>>>>>>
>>= ; >> >>> >> >>>>>>
>= ;> >> >>> >> >>>>>> _____________= __________________________________
>> sfc
>> >> >>> mailing
>> >> >= ;>> >> list
>> >> >>> >&g= t; >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listi= nfo/sfc
>> >> >>> >> >>>&= gt;>>
>> >> >>> >> >>&= gt;>>
>> >> >>> >> >>&= gt;>> _______________________________________________ sfc
>> >> >>> mailing
>> >> &= gt;>> >> list
>> >> >>> >= > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinf= o/sfc
>> >> >>> >> >>>>= ;
>> >> >>> >> >>>> __= _____________________________________________ sfc
>> &g= t;> mailing
>> >> >>> >> list>> >> >>> >> >>>> sfc@i= etf.org https://www.ietf.org/mailman/listinfo/sfc
>> &g= t;> >>> >> >>>>
>> >&g= t; >>> >> >>>> _________________________________= ______________ sfc
>> >> mailing
&g= t;> >> >>> >> list
>> >> = >>> >> >>>> sfc@ietf.org https://www.ietf.org/ma= ilman/listinfo/sfc
>> >> >>> >> &g= t;>>>
>> >> >>> >> >&g= t;>
>> >> >>> >> >>
>> >> >>> >> >> _________________= ______________________________
>> >> >>>= >> >> sfc mailing list
>> >> >>= ;> >> >> sfc@ietf.org
>> >> >&g= t;> >> >> https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>
>&g= t; >> >>> >> >
>> >> >= >> >> >_______________________________________________
>> >> >>> >> >sfc mailing list
>> >> >>> >> >sfc@ietf.org
>> >> >>> >> >https://www.ietf.org/mail= man/listinfo/sfc
>> >> >>> >>
>> >> >>> >> _________________________= ______________________
>> >> >>> >>= ; sfc mailing list
>> >> >>> >> sf= c@ietf.org
>> >> >>> >> https://ww= w.ietf.org/mailman/listinfo/sfc
>> >> >>>= ;
>> >> >>> ____________________________= ___________________
>> >> >>> sfc mailin= g list
>> >> >>> sfc@ietf.org
>> >> >>> https://www.ietf.org/mailman/listinfo/= sfc
>> >> >
>> >> &g= t;_______________________________________________
>> &g= t;> >sfc mailing list
>> >> >sfc@ietf.or= g
>> >> >https://www.ietf.org/mailman/listinfo= /sfc
>

______________________= _________________________
sfc mailing list
sfc@= ietf.org
https://www.ietf.org/mailman/listinfo/sfc
------=_Part_3118_280747497.1405095525429-- From nobody Fri Jul 11 09:20: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 454271B2B0B for ; Fri, 11 Jul 2014 09:20:21 -0700 (PDT) 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 tDt67U4DXJLg for ; Fri, 11 Jul 2014 09:20:18 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1221B290B for ; Fri, 11 Jul 2014 09:20:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9BA1824066E; Fri, 11 Jul 2014 09:20:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6338D240183; Fri, 11 Jul 2014 09:20:17 -0700 (PDT) Message-ID: <53C00EC1.9040502@joelhalpern.com> Date: Fri, 11 Jul 2014 12:20:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker , "sfc@ietf.org" References: <53BCAB74.4060801@joelhalpern.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACE8@MISOUT7MSGUSRCF.ITServices.sbc.c om> <53BFF20E.60900@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD3B@MISOUT7MSGUSRCF.ITServices.sbc.co m> <53BFFF12.4060700@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AE5A@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AE5A@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0rexsfha8nsMOsLSy4aibx5H8LM Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:20:21 -0000 If one declares that every SFC is realized by only one SFP (i.e each service chain is always realized by only one directive to the network forwarders, which then make choices based on that directive), then indeed the SFP does not add value. I would call what results from such an equivalence and SFP, but if we were to accept such a limit, we could call it either one. However, we also indicated we want to allow a degree of central arbitrarition and central control of traffic distribution. So we need a layer of indirection to represent that. The SFP represents the decision by the control plane and entry as to which initial subset is to be used. This does not prevent there from being further load balancing (as discussed in the emails) within that envelop. If there is no SFP distinct from the SFC then there is no envelop. Yours, Joel On 7/11/14, 12:02 PM, NAPIERALA, MARIA H wrote: > Joel, > > I saw your latest e-mail but I am responding to this one because it is more comprehensive. > > I have a hard time understanding why an SFF will not have ability to resolve an SFC to the set of next SFFs. Then what kind of "forwarder" is it if it cannot deal with next-hops. > Second, if we do it as you suggest, what is the definition of a service path and why it is even needed? For me a service path is more of an abstract concept that is meant to denote one actual path (among many) that a service chain traffic will take. > > Maria > > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >> Sent: Friday, July 11, 2014 11:13 AM >> To: NAPIERALA, MARIA H; Joel M. Halpern; Jim Guichard (jguichar); Ron >> Parker; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> In order to allow for SFFs which do not have ability to resolve an SFC >> to the set of next SFFs, we need to do one level of mapping from the >> abstract SFC to the more resolved SFP. >> In addition to allowing for a range of SFF deployments, this also allows >> for a degree of centralized traffic control to be used in conjunction >> with the distributed behavior you are requesting. If we only used an >> identifier of the service chain in the packet we would be prohibiting >> that important alternative deployment. >> >> The SFF still has the ability to map the SFP to the transport >> information, which allows it to have a collection of next SFFs which it >> uses for redundancy or load balancing. >> >> If we structure it this way, we can allow the SFF to have a collection >> of next-SFFs for a given SFP. And we can allow it to pick one, or to >> balance as it chooses subject to the constraint that a given flow must >> continue to use a given next-SFF as long as that is available. >> >> If we write it that way, the architecture will not mandate full load >> balancing. It will allow that a given SFF uses a single next-SFF hope. >> Or that it does whatever degree of load balncing it chooses among the >> set of next-SFF it is aware of for use with a given service path (SFP). >> Whether that knowledge of next-SFFs is static or dynamic, provisioned >> or discovered, is outside the scope of the architecture, and probably >> outside the scope of any solution this WG develops. >> >> Can you live with this compromise? >> (If so, and if the WG is comfortable with this, Carlos and I can add >> this to the slides for presentation in Toronto, and then add text to the >> next version of the document.) >> >> Yours, >> Joel >> >> On 7/11/14, 10:56 AM, NAPIERALA, MARIA H wrote: >>> >>>> Just to check, I am going to get pedantic. >>> >>> NP >>> >>>> We have SFF-X, is supporting (possibly via local load balancing) some >>>> collection of local service function instances. >>>> When packets on a given service function path (SFP-Y) arrive, they are >>>> processed by theose service functions, and SFF-X then has to forward the >>>> packets (with suitable transport) to a next SFF, who may locally balance >>>> among his service function instances. >>> >>> Similar comment to Med's (I will use his expression as it does reflect it >> correctly): "if packets bound to a given Service Function Chain arrive", etc. >>> This applies to the text below also. >>> >>>> For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z. >>>> >>>> We consider first the state at time T0 when a packet arrives as SFF-X on >>>> SFP-Y with no prior special state in SFF-X (obviously, there is some >>>> state about SFP-Y, as we do not want policy lookups at packet handling >>>> times.) At this time T0, there exist in the network SFF-Z1 and SFF-Z2. >>>> If I understand your request, you want SFF-X to pick one of those two >>>> SFF, say SFF-Z1. >>> >>> Yes. >>> >>>> And send all the packets for SFP-Y on to SFF-Z1. Even >>> >>> This could be per-destination load balancing, for example, to get a better >> load distribution. >>> >>>> if SFF-Z3 is added to the network, all packets for all flows using SFP-Y >>>> at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only >>> >>> Existing flows go to SFF-Z1. New flows may go to SFF-Z3. >>> >>>> time SFF-X would change that is if discovered or was told that SFF-Z1 >>>> was down or unreachable. In that case, it would pick a new one from >>>> among the known choices. >>> >>> Yes. >>> >>>> Maria, if that is what you would like, I believe that either is >>>> currently allowed by the architecture or can easily be added. And I am >>>> happy to do so. I believe we can describe that in the resilience and >>>> failure recovery section that we need to add. >>> >>> OK. >>> >>>> But I want to be really sure that is what you want. I don't think that >>>> meets Ron's request. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: >>>>> Joel, >>>>> >>>>>> Hmm. Would it meet your goals Maria if all packets that arrived at >>>>>> SFF-X with SFP-Y were (after local SF processing) forwarded to some >>>>>> specific SFF-Z? Where SFF-Z was selected when the first packet with >>>>>> SFP-Y arrived at SFF-X? >>>>> >>>>> Yes. >>>>>> >>>>>> While that is more easily met, that does not seem likely to produce >> the >>>>>> scale flexibility you asked for. And if SFF-X may forward packets with >>>>> >>>>> Why not? >>>>> >>>>>> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the >>>>>> capability to ensure that a given flow continues to go to the same >> next >>>>>> SFF even when SFF-Z3 is added to the mix. >>>>> >>>>> Precisely. >>>>> >>>>> >>>>>> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: >>>>>>> Absolutely not. Service chains can be instantiated only in relevant >> SFFs >>>>>> when they "arrive". >>>>>>> >>>>>> ... >>>>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 09:21: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 04DB71B2B2A for ; Fri, 11 Jul 2014 09:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 jbaaGiobqB9V for ; Fri, 11 Jul 2014 09:21:03 -0700 (PDT) Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F417B1B2B0B for ; Fri, 11 Jul 2014 09:21:02 -0700 (PDT) Received: from mtaout-aak01.mx.aol.com (mtaout-aak01.mx.aol.com [172.27.2.225]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id 4CCBA70057C6E; Fri, 11 Jul 2014 12:21:02 -0400 (EDT) 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-aak01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EFD3F38000081; Fri, 11 Jul 2014 12:21:01 -0400 (EDT) Date: Fri, 11 Jul 2014 12:21:01 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com Message-ID: <1124016040.3120.1405095661844.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3119_677136899.1405095661843" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405095662; bh=zUrQA8+KzxkSmwdUt9GUo2OM0YGX9aYVWrhbbs1ik5c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=L5O6nMDKlEOV2gyBQIpT5wOY/Qrt2G/UZyUa6SL4tjqoQIS3mxjR2y7IggRHTmdwI uNG+31hPQW9UhIqSSZDbBnKXhYT3IVw1fEsia8gRi+zt21J4MzCpCfwQxBT01Lz/H/ pSLyndrcvnV2gC2jZax5p2kbAhLjPv4mYcY1/HzI= x-aol-sid: 3039ac1b02e153c00eed037a X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2Rkn9FteDB6Uzi0Rsm5mxU9dWXw Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:21:08 -0000 ------=_Part_3119_677136899.1405095661843 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable but it still sounds like there is a single SFF entity tied to the 20 instan= ces through which ALL traffic destined for any of the 20 instances MUST tra= verse. =C2=A0While this should surely not be prohibited, it shouldn't be ma= ndated. From: jguichar@cisco.com To: mikebianc@aol.com,mn1921@att.com cc: sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers No they do not have to be physically connected but they are hidden behind a= n SFF in this case but do not have to be. From: "mikebianc@aol.com" Date: Friday, July 11, 2014 at 11:44 AM To: Jim Guichard , "mn1921@att.com" Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers When you say "20 instances of the SF2 SF" are "Connected to that SFF" do yo= u mean physically? I had always just assumed that if I had 20 instances of= a SF, that they would be diverse. Even if within the same datacenter, the= y would be not near each other. It also seems like you are saying that there is only a single SFF for SF2= and that your traffic path requires traversing SF2 as a separate hop from = the SF2 instance. Ideally, the traffic would flow from SF1 instance to SF2= instance over the best path without the need for an intermediary hop. *In my statements above, I assuming that each SF Instance is SFC aware to s= implify the text. From: jguichar@cisco.com To: mikebianc@aol.com,mn1921@att.com cc: sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =E2=80=9C3. Generic SFC encapsulation: T= his document will describe a single service-level data plane encapsulation = format that indicates the sequence of service functions that make up the Service Functi= on Chain; specifies the Service Function Path=E2=80=9D. The wording here is very impo= rtant and shows that the intent is that the sequence of SF=E2=80=99s be ind= icated within the SFC encapsulation e.g. not carried =E2=80=93 this is not source routing, and specifies the SFP, hence the path identifier. For my example let=E2=80=99s assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=E2=80=99s call it =E2=80=9CSFC-= 1=E2=80=9D It is possible that each of those SF=E2=80=99s be directly addressable (i.e= . provide SFF functionality) or reachable through some other network device= that provides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF=E2=80=99s; let=E2=80=99s call = them SF1-loc1, SF2-loc2, and SF3-loc3. When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier =E2=80=9C100=E2=80=9D. This information is distributed to the r= elevant network devices basically saying =E2=80=9Cif you receive an SFC enc= apsulated packet with path identifier =E2=80=9C100=E2=80=9D then use the pa= th identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=E2=80=9D. So traffic flows through the SFP with path identifier =E2=80=9C100=E2=80=9D= , via a network transport (the path identifier is encapsulated). It reaches= SF1-loc1 which uses the path identifier to determine that it is in fact th= e SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth. So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From: "mikebianc@aol.com" Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard , "mn1921@att.com" Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim,=20 Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at al= l. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. From: jguichar@cisco.com To: NAPIERALA, MARIA H cc: Paul Quinn (paulq),Lucy yong,jmh= @joelhalpern.com,mohamed.boucadair@orange.com,sfc@ietf.org,mikebianc@aol.com Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com;=20 mohamed.boucadair@orange.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy,=20 Overall I concur, as you say: a path ID drives the forwarding. I=E2=80=99d = make the minor change: the path identifier can be used to derive the needed= forwarding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behalf Ofmohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;jmh@joelhalpern.com;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la part demikebianc@aol.com Envoy=C3=A9 : mercredi 9 juillet 2014 22:03 =C3=80 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. From:jmh@joelhalpern.com To: sfc@ietf.org Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing 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_3119_677136899.1405095661843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
but it still sounds= like there is a single SFF entity tied to the 20 instances through which A= LL traffic destined for any of the 20 instances MUST traverse.  While = this should surely not be prohibited, it shouldn't be mandated.


=



From: jguichar@cisco.com<jguichar@cisco.com>
To: = mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com= >
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday,= July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers

No they do not have to be physically connected but they are hidden beh= ind an SFF in this case but do not have to be.

From: "mikebianc@aol= .com" <mikebianc@aol= .com>
Date: Friday, July 11, 2= 014 at 11:44 AM
To: Jim Guichard <jguichar@cisco.com>, "= mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

When you say "20 instances of the SF2 SF" are "Connected to that SFF" = do you mean physically? I had always just assumed that if I had 20 instanc= es of a SF, that they would be diverse. Even if within the same datacenter= , they would be not near each other. It also seems like you are saying that there is only a single SFF for SF2= and that your traffic path requires traversing SF2 as a separate hop from = the SF2 instance. Ideally, the traffic would flow from SF1 instance to SF2= instance over the best path without the need for an intermediary hop.

*In my statements above, I assuming that each SF Instance is SFC aware= to simplify the text.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Mike,

There still seems to be some confusion around this topic so let me try= to provide a more detailed explanation as to how I believe this should wor= k and why what I explained earlier is in fact a path identifier and not a c= hain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =E2=80=9C3. Generic SFC encapsulation: T= his document will describe a single service-level data plane encapsulation = format that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path=E2=80=9D. The wording here is ve= ry important and shows that the intent is that the sequence of SF=E2=80=99s= be indicated within the SFC encapsulation e.g. not carried =E2=80=93 this = is not source routing, and specifies= the SFP, hence the path identifier.

For my example let=E2=80=99s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=E2=80=99s call it = =E2=80=9CSFC-1=E2=80=9D

It is possible that each of those SF=E2=80=99s be directly addressable= (i.e. provide SFF functionality) or reachable through some other network d= evice that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 = relies on a connected switch to provide the needed SFF functionality. Conne= cted to that SFF are 20 instances of the SF2 SF. In this case you have exac= tly 3 network locators from which to choose in order to reach the required SF=E2=80=99s; let=E2=80=99s call = them SF1-loc1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locator= s are selected to construct the path, and a path identifier is allocated. I= n this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> = SF2-loc2 -> SF3-loc3 and it has a path identifier =E2=80=9C100=E2=80=9D. This information is distributed to the r= elevant network devices basically saying =E2=80=9Cif you receive an SFC enc= apsulated packet with path identifier =E2=80=9C100=E2=80=9D then use the pa= th identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=E2=80=9D.=

So traffic flows through the SFP with path identifier =E2=80=9C100=E2= =80=9D, via a network transport (the path identifier is encapsulated). It r= eaches SF1-loc1 which uses the path identifier to determine that it is in f= act the SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth.

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).


Date: Thursday, July 10, 2014 at 4:= 46 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn192= 1@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>= ;
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers


Jim,

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop? In this case, there wouldn't be any Path Identifier = at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there wil= l be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=E2=80=99d make the minor change: the path identifier can be us= ed to derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc should not man= date only use of the service path identifier to drive the forwarding action= s.

Lucy

From:sfc [mailto:sfc-bounces@ietf.org<= /a>]On Behalf Ofmohamed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com;jmh@joelhalpern.com<= /a>;sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a s= ervice path identifier. I object to use that identifier to derive forwardin= g actions.

Requiring a SFC system to have the full k= nowledge of every available SFC forwarding paths within an SFC-enabled doma= in is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the= piece of information that will be present in all deployments: that is the = one required to structure a service chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion.

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org<= /a>]De la part demikebianc@aol.com
Envoy=C3=A9 : mercredi = 9 juillet 2014 22:03
=C3=80 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain an= d SF Path? Other than clarifying the definition so that it's clear to those= not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is th= e intent of this draft to ultimately specify what the ID of the SFC Header = should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require t= hat both SFP and SFC be supported (or make one required and the other optio= nal) to avoid some vendors only supporting SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
------=_Part_3119_677136899.1405095661843-- From nobody Fri Jul 11 09:23: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 8D2C91B2B2A for ; Fri, 11 Jul 2014 09:23:20 -0700 (PDT) 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_29=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 fntHNJMe-3gf for ; Fri, 11 Jul 2014 09:23:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7633D1B290B for ; Fri, 11 Jul 2014 09:23:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 56B23240A31; Fri, 11 Jul 2014 09:23:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 14CE8240914; Fri, 11 Jul 2014 09:23:13 -0700 (PDT) Message-ID: <53C00F71.2050805@joelhalpern.com> Date: Fri, 11 Jul 2014 12:23:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , mohamed.boucadair@orange.com, jguichar@cisco.com, mn1921@att.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <793508013.3099.1405095108294.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <793508013.3099.1405095108294.JavaMail.tomcat@mgs-aad01.mail.aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hbaFgZwS6q5EBPfXLR1p4_U8TQ4 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:23:20 -0000 I am looking for a compromise whereby we add some flexibility to what is documented, retain the capabilities that are already included, and improve the clarity. Yours, Joel On 7/11/14, 12:11 PM, mikebianc@aol.com wrote: > Yes, the draft seems to indicate that if you want this distributed > behavior, you need to re-classify onto a new SFP. If that is not the > intent of the draft, then it is unclear. > > > > > > ------------------------------------------------------------------------ > *From: *mohamed.boucadair@orange.com > *To: *Jim Guichard (jguichar),NAPIERALA, MARIA > H,Joel M. Halpern,Ron > Parker,sfc@ietf.org > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Re-, > > For what I can say at best this is not described clearly in the draft. > > Mandating a service path identifier is in itself a hint that the full > distributed model is not allowed. > > Several voices in this thread indicated that the service chain itself > should be provided instead. > > Cheers, > Med > > >-----Message d'origine----- > >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > >(jguichar) > >Envoyé : vendredi 11 juillet 2014 16:18 > >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org > > >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > >Ok but where in the architecture specifically is this functionality > >prohibited? If you want to distribute *all* next-hops to *all* SFF’s > >within the SFC domain and then let the path identifier point to a lookup > >into those next-hops to reach the next SF in the chain, I am not sure how > >the architecture prevents that? > > > >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" wrote: > > > >>Absolutely. > >> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >>>(jguichar) > >>> Sent: Friday, July 11, 2014 9:54 AM > >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; sfc@ietf.org > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> > >>> Then I misunderstand the proposal ;-) .. However, it seems to me > that if > >>> you allow an SFF to make a decision as to which remote SFF it will use > >>>for > >>> a given flow to reach the next SF within the chain then you better make > >>> sure that that remote SFF has the necessary forwarding logic to reach > >>>the > >>> next-next-SF for the chain as otherwise you are in deep trouble. > >>> > >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" wrote: > >>> > >>> >Absolutely not. Service chains can be instantiated only in relevant > >>>SFFs > >>> >when they "arrive". > >>> > > >>> >> -----Original Message----- > >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >>> >>(jguichar) > >>> >> Sent: Friday, July 11, 2014 9:27 AM > >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org > >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> >> > >>> >> Well I think it is even worse than that if I have understood the > >>> >>proposal > >>> >> correctly as it would require full knowledge of every single SF > >>>within > >>> >>the > >>> >> entire SFC domain at every single SFF as there is no way to know a > >>> >>priori > >>> >> which SFC¹s a given SFF will need to service at any given point in > >>>time. > >>> >> > >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote: > >>> >> > >>> >> >Ron, thinking about this, I realized another major problem with the > >>> >>your > >>> >> >proposal as I understand it. (And I readily admit I may not > >>>understand > >>> >> >it.) > >>> >> > > >>> >> >The proposal has each SFF serve as the load balancer for the next > >>> >> >service function that follows it (not the one it delivers to), in > >>>every > >>> >> >service chain that goes through it. > >>> >> > > >>> >> >Since it has to be able to work with all services, that means that > >>> >>every > >>> >> >SFF would have to be a full, flow sensitive and stateful load > >>>balancer. > >>> >> >I ahve no problem if some SFF are flow sensitive, and / or > stateful. > >>> >> >But having the architecture require that every SFF be a full, flow > >>> >> >sensitive, stateful, load balancer seems to me to be an acceptable > >>> >> >imposition. > >>> >> > > >>> >> >Yours, > >>> >> >Joel > >>> >> > > >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >>> >> >> Part of my personal view is that I am trying to make this work > >>> >>sensibly > >>> >> >> in a more orchestrated environment. I expect that the service > >>> >> >> functions, and over time probably the SFF capabilities, will be > >>> >> >> orchestrated and installed. I expect the service chains to be > >>> >>driven by > >>> >> >> BSS tools that define offerings to clients, and enable > >>>self-selection > >>> >> >> from these. I expect service paths to be heavily policy drive. > >>> >> >> > >>> >> >> I can see how to make all of that work in an archtiecture driven > >>>by > >>> >> >> initial classification to described service paths. It is harder > >>>to > >>> >>see > >>> >> >> how to make it work (but it can be done) when we allow more > >>> >> dynamicity > >>> >> >> in the network behavior. > >>> >> >> > >>> >> >> Having said that, most of that perspective I described is outside > >>>of > >>> >>the > >>> >> >> scope of the working group. it is not something we are tasked to > >>> >>agree > >>> >> >>on. > >>> >> >> So I do not claim that vision means we have to do it a certain > >>>way. > >>> >>it > >>> >> >> is just the perspective that drives my preferences. > >>> >> >> > >>> >> >> Yours, > >>> >> >> Joel > >>> >> >> > >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >>> >> >>>> For me, the amount of information about service instances that > >>> >>needs > >>> >> >>>>to > >>> >> >>>> be widely distributed and maintained, potentially even across > >>>data > >>> >> >>>> centers within an administrative scope, is large enough and > >>> complex > >>> >> >>>> enough that trying to get that into each SFF seems like a > >>>difficult > >>> >> >>>> architecture to realize. > >>> >> >>> > >>> >> >>> I'm curious as to why that is more complicated than dynamic > >>> routing, > >>> >> >>> hyper-scale data center orchestration, or DNS, all of which are > >>> >>bigger > >>> >> >>> problems that have been profitably and stably implemented? > >>> >> >>> > >>> >> >>> It also seems that if it really is more complicated, that is a > >>>good > >>> >> >>> sign that it is too complicated. > >>> >> >>> > >>> >> >>> ________________________________________ > >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com] > >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM > >>> >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian > >>>Smith; > >>> >> >>> sfc@ietf.org > >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >>> >> >>> > >>> >> >>> This is an architectural issue. And one that I would prefer we > >>> >> >>>actually > >>> >> >>> decide, rather than trying to allow all possible > implementations. > >>> >> >>> Because it does have a major effect on the control requirements > >>>and > >>> >> the > >>> >> >>> functionality of SFFs. > >>> >> >>> > >>> >> >>> For me, the amount of information about service instances that > >>> needs > >>> >> to > >>> >> >>> be widely distributed and maintained, potentially even across > >>>data > >>> >> >>> centers within an administrative scope, is large enough and > >>>complex > >>> >> >>> enough that trying to get that into each SFF seems like a > >>>difficult > >>> >> >>> architecture to realize. > >>> >> >>> > >>> >> >>> Yours, > >>> >> >>> Joel > >>> >> >>> > >>> >> >>> But it is a fair question. > >>> >> >>> > >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >>> >> >>>> This is the crux of my issue. Is the end to end selection of > >>> >> >>>> (top-level) instances performed centrally (perhaps by the > >>> >>classifier) > >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the > >>> >>SFFs)? > >>> >> >>>> Such selection is not equivalent to reclassification. And > >>>surely, > >>> >> >>>> this is an architectural issue and not relegated to > >>> >> >>>> "implementation". > >>> >> >>>> > >>> >> >>>> My own view is to favor the distributed approach even though a > >>> >> >>>> greater amount of data (chain definitions and perhaps local > >>> >>selection > >>> >> >>>> policy) is required at those distributed decision points. > This > >>> >> >>>> approach does not require an end-to-end path id at all. My > >>> >> >>>> rationale for favoring this approach is primarily driven by > >>> >>increased > >>> >> >>>> resiliency over the global path id approach. With a global > >>>path > >>> >>id > >>> >> >>>> approach, consider failure of an instance and needing to alter > >>>the > >>> >> >>>> global path ID table for each and every affected end-to-end > >>>path. > >>> >> >>>> > >>> >> >>>> Ron > >>> >> >>>> > >>> >> >>>> ________________________________________ From: sfc > >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct > >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 > >>> PM > >>> >> >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org > Subject: Re: > >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers > >>> >> >>>> > >>> >> >>>> The way the architecture models the case of SF1 needing to > >>> >>influence > >>> >> >>>> the chain is that one would do reclassification at the exit > from > >>> >> >>>> SF1. > >>> >> >>>> > >>> >> >>>> Part of the goal is to keep the different functions logically > >>> >> >>>> separate so that solutions can clearly describe how they choose > >>>to > >>> >> >>>> compose them for "service" delivery. > >>> >> >>>> > >>> >> >>>> Yours, Joel > >>> >> >>>> > >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: > >>> >> >>>>> I don't see anything in the arch draft that suggests any sort > >>>of > >>> >> >>>>> limit. However, it does seem to indicate that the entire path > >>>(all > >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe this > >>>means > >>> >> >>>>> either at the classifier or maybe the classifier chooses a SF > >>> >>Chain > >>> >> >>>>> and the NF or at the latest the first SFF. In any case, the > >>> >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) > >>> is > >>> >> >>>>> determined at the SFI(n-1) hop. According to the draft, this > >>> >> >>>>> behavior would be considered "branching" to a new SFP as > >>> opposed > >>> >> to > >>> >> >>>>> choosing and then forwarding to the selected instance of the > >>> >> >>>>> next-hop of the current SFC. > >>> >> >>>>> > >>> >> >>>>> draft-merged-sfc-architecture-00: > >>> >> >>>>>> When an SFC is instantiated into the network it is necessary > >>>to > >>> >> >>>>>> select the specific instances of SFs that will be used, > and to > >>> >> >>>>>> create the service topology for that SFC using SF's network > >>> >> >>>>>> locator. Thus, instantiation of the SFC results in the > >>>creation > >>> >> >>>>>> of a Service Function Path (SFP) and is used for forwarding > >>> >> >>>>>> packets through the SFC. In other words, an SFP is the > >>> >> >>>>>> instantiation of the defined SFC. > >>> >> >>>>>> > >>> >> >>>>>> The SFC architecture supports reclassification (or > non-initial > >>> >> >>>>>> classification) as well. As packets traverse an SFP, > >>> >> >>>>>> reclassification may occur - typically performed by a > >>> >> >>>>>> classification function co-resident with a service function. > >>> >> >>>>>> Reclassification may result in the selection of a new SFP, an > >>> >> >>>>>> update of the associated metadata, or both. This is referred > >>>to > >>> >> >>>>>> as "branching". > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> > >>> > >>>>>>>>>>------------------------------------------------------------------ > >>>>>>>>>>-- > >>> >>>>>>>-- > >>> >> >>>>>-- > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>> *From: *I.Smith@F5.com > >>> >> >>>>> *To: *Joel Halpern Direct,Joel M. > >>> >> >>>>> > >>> >> > >>> >>>>>Halpern,huang@sce.carleton.ca >>> >> carleton. > >>> >> >>>>>ca>,sfc@ietf.org > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>> *Sent: *Thursday, July 10, 2014 > >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >>> >> >>>>> > >>> >> >>>>> Actually, I think I am disagreeing. > >>> >> >>>>> > >>> >> >>>>> If the possibility of medium-scale deployments (and that is > >>>what > >>> >> >>>>> 16 million flows is in my world) of service chains is > >>>preconceived > >>> >> >>>>> as an absurd idea, then the architecture burdened with that > >>> >> >>>>> preconception. > >>> >> >>>>> > >>> >> >>>>> There has to be some point of aim, some degree of > aspiration to > >>> >> >>>>> scale that is appropriate for the lifespan of the architecture > >>>- > >>> >> >>>>> you don't have to know what it is, but by saying that an > >>>arbitrary > >>> >> >>>>> number is "too far", you're creating - even if it isn't > >>> >>intentional > >>> >> >>>>> - a limit that influences decisions that have lasting impacts > >>> >> >>>>> regarding scale-out, failure mitigation, elasticity, address > >>> >> >>>>> space... all kinds of things. That is a problem I'm not > >>> >> >>>>> particularly eager to deal with. > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> ________________________________________ > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: > >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. > Halpern; > >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service > >>> >> >>>>> Chains, Paths, and Load Balancers > >>> >> >>>>> > >>> >> >>>>> Ian, I don't think you disagree with me at all in this regard. > >>>I > >>> >>am > >>> >> >>>>> not requesting the the architecture or the solution prohibit > >>> >> >>>>> deployments in the specific fashion. I am objecting to Huang's > >>> >> >>>>> reading of my note as saying that such deployments are > required > >>> >> >>>>> they by the archtiecture. > >>> >> >>>>> > >>> >> >>>>> As I have said repeatedly, I am not trying to prohibit such > >>> >> >>>>> things. Whether they are a good idea or not depends upon many > >>> >> >>>>> factors outside of the scope of the WG. I happen to think that > >>> >>they > >>> >> >>>>> are usually a bad idea. > >>> >> >>>>> > >>> >> >>>>> But the archtiecture si carefully avoiding attempting to know > >>>what > >>> >> >>>>> is and is not eployable. > >>> >> >>>>> > >>> >> >>>>> Yours, Joel > >>> >> >>>>> > >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >>> >> >>>>>> I disagree. > >>> >> >>>>>> > >>> >> >>>>>> We routinely have stateful devices that manage tens of > >>>millions > >>> >> >>>>>> of > >>> >> >>>>> concurrent flows in both access network and data center > >>> >> >>>>> environments today. You can't seriously believe that in the > >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > >>> >> going > >>> >> >>>>> to have small numbers of service chains with equally small > >>> numbers > >>> >> >>>>> of active service paths? > >>> >> >>>>>> > >>> >> >>>>>> Your sounds too much like "no one will ever need more than > >>> 64K" > >>> >> >>>>>> for > >>> >> >>>>> comfort. > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> ________________________________________ From: sfc > >>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern > >>> >> >>>>> [jmh@joelhalpern.com] > >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > >>>huang@sce.carleton.ca; > >>> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and > >>>Load > >>> >> >>>>>> Balancers > >>> >> >>>>>> > >>> >> >>>>>> No, it will mean that if someone tries to deploy the > >>>archtieture > >>> >> >>>>>> particularly badly, they will exceed the limits of their > >>> >> >>>>>> devices. The architecture does not require such absurd use of > >>> >> >>>>>> service paths. Since I can not figure out how to write > >>> >> >>>>>> architectural words to prohibit it, the architecture does > >>>permit > >>> >> >>>>>> such abuse. > >>> >> >>>>>> > >>> >> >>>>>> Please do not read my saying that the archtiecture permits > >>> >> >>>>>> something as saying it is either deisred or required by the > >>>work. > >>> >> >>>>>> It isn't. > >>> >> >>>>>> > >>> >> >>>>>> Yours, Joel > >>> >> >>>>>> > >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >>> >> >>>>>>> If you need to support 100 service chains, it will mean > >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a > >>> >> >>>>>>> core router. > >>> >> >>>>>>> > >>> >> >>>>>>> Chang > >>> >> >>>>>>> > >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >>> >> >>>>>>>> The architecture allows a range of deployments, from 1 > >>> >> >>>>>>>> service path to 160000 service paths. I would hope that > >>> >> >>>>>>>> operators are prepared for the complexities if they choose > >>>to > >>> >> >>>>>>>> avoid any use of local load balancing and in stead > provision > >>> >> >>>>>>>> 160,000 service paths. > >>> >> >>>>>>>> > >>> >> >>>>>>>> Yours, Joel > >>> >> >>>>>>>> > >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >>> >> >>>>>>>>> Paul, > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop > service > >>> >> >>>>>>>>> chain with 20 instances at each hop? > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Maria > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com; > >>> >> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; > >>> >> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, > >>> >> >>>>>>>>> Paths, and Load Balancers > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Lucy, > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the > >>> >> >>>>>>>>> forwarding. I¹d > >>> >> >>>>> make > >>> >> >>>>>>>>> the minor change: the path identifier can be used to > derive > >>> >> >>>>>>>>> the needed forwarding and associated transport. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to simply > >>> >> >>>>>>>>> identify the service path (or graph) that packets must > >>> >> >>>>>>>>> traverse. By having a path identifier, the exact > >>> >> >>>>>>>>> indirection that people seem to be asking for on this > >>> >> >>>>>>>>> thread can be simply be implemented. The path identifier > >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can > result > >>> >> >>>>>>>>> in a one or more (equal or weighted) transport next > >>> >> >>>>>>>>> hop(s). > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Paul > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >>> >> >>>>>>>>> > > >>> >> >>>>>>>>> wrote: > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the > >>> >> >>>>>>>>> service path identifier to drive the forwarding actions. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Lucy > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com > >>> >> >>>>>>>>> > >>> *Sent:*Thursday, > >>> >> July > >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > >>> >> >>>>>>>>> ;jmh@joelhalpern.com > >>> >> >>>>>>>>> ;sfc@ietf.org > >>> >> >>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >>> >> >>>>>>>>> Paths, and Load Balancers > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Re-, > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> The merged draft calls out explicitly a service path > >>> >> >>>>>>>>> identifier. I object to use that identifier to derive > >>> >> >>>>>>>>> forwarding actions. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every > >>> >> >>>>> available SFC > >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >>> >> >>>>> required/justified > >>> >> >>>>>>>>> nor possible in various deployment contexts. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of > >>> >> >>>>>>>>> information > >>> >> >>>>> that will > >>> >> >>>>>>>>> be present in all deployments: that is the one required to > >>> >> >>>>>>>>> structure a service chain. How that information is used to > >>> >> >>>>>>>>> infer forwarding > >>> >> >>>>> actions > >>> >> >>>>>>>>> is a solution-oriented discussion. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Cheers, > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Med > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >>> >> >>>>> de*mikebianc@aol.com > >>> >> >>>>>>>>> *Envoyé :*mercredi 9 juillet > >>> >> >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com > >>> >> >>>>>>>>> ;sfc@ietf.org > >>> >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >>> >> >>>>>>>>> Paths, and Load Balancers > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Is anyone still questioning the difference between SF > Chain > >>> >> >>>>>>>>> and SF > >>> >> >>>>> Path? > >>> >> >>>>>>>>> Other than clarifying the definition so that it's clear to > >>> >> >>>>> those not > >>> >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on > >>> >> >>>>>>>>> these terms. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> To me, the one point that is still unclear is whether > it is > >>> >> >>>>>>>>> the intent of this draft to ultimately specify what the ID > >>> >> >>>>>>>>> of the SFC Header > >>> >> >>>>> should > >>> >> >>>>>>>>> reference (the chain or the path), or if this draft simply > >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or > >>> >> >>>>>>>>> path and the choice of chain or > >>> >> >>>>> path to > >>> >> >>>>>>>>> be negotiated in the control-plane. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have > >>> >> >>>>>>>>> require that both SFP and SFC be supported (or make one > >>> >> >>>>>>>>> required and the other optional) to avoid some vendors > only > >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> > >>> >> >>>>> > >>> >> > >>> > >>>>>>>>>>------------------------------------------------------------------ > >>>>>>>>>>-- > >>> >>>>>>>-- > >>> >> >>>>>-- > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>>>> > >>> >> >>>>>>>>> *From:*jmh@joelhalpern.com >>> >> >>>>>>>>> > > >>> >> >>>>>>>>> *To:*sfc@ietf.org >>> >> >>>>>>>>> > *Sent:*Tuesday, July > >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >>> >> >>>>>>>>> Balancers > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> I have been trying to figure out how to clearly answer a > >>> >> >>>>>>>>> number of comments that have been made about the > >>> proposed > >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get working > >>> >> >>>>>>>>> group agreement on the intent, we will work to improve the > >>> >> >>>>>>>>> wording so that readers who have not participated in > the WG > >>> >> >>>>>>>>> discussion will understnd it the way the > >>> >> >>>>> working > >>> >> >>>>>>>>> group intends. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> But what do we intend? I will try to explain my personal > >>> >> >>>>>>>>> view, and see if that helps. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> In this regard, it is important to keep in mind that what > >>> >> >>>>>>>>> we are defining is the data plane architecture. We are not > >>> >> >>>>>>>>> attempting to define the architecture for the entire > >>> >> >>>>>>>>> solution for service chaining. That would encompass > >>> >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual > >>> >> >>>>>>>>> machine and image management, and many other aspects. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> As a result there are many things which clearly need to > >>> >> >>>>>>>>> exist in the larger system, but which are dealt with above > >>> >> >>>>>>>>> where we are > >>> >> >>>>> functioning, > >>> >> >>>>>>>>> and are not directly required by the work we are doing. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> In order to get to service chain vs service path, as I > >>> >> >>>>>>>>> understand > >>> >> >>>>> them, > >>> >> >>>>>>>>> I need to first discuss load balancing. There are at least > >>> >> >>>>>>>>> three different ways that load balancing can and will > >>> >> >>>>>>>>> interact with service chaining. There probably are more. > >>> >> >>>>>>>>> The point of the archtiecture is to permit all of these, > >>> >> >>>>>>>>> but not to mandate that any particular kind > >>> >> >>>>> be used > >>> >> >>>>>>>>> in any solution. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> 1) Load balancing as a service provided to the end user. > >>> >> >>>>>>>>> This is a service function. It receives user packets, and > >>> >> >>>>>>>>> modifies them (or > >>> >> >>>>> marks > >>> >> >>>>>>>>> them, or ...) so as to choose an end user service instance > >>> >> >>>>>>>>> to receive the users packet. This is an important service > >>> >> >>>>>>>>> function to be able to include in service chaining. It's > >>> >> >>>>>>>>> behavior may affect requirements on how service > chaining is > >>> >> >>>>>>>>> done. But it has very little impact on the archtiecture. > >>> >> >>>>>>>>> From an architectural pe3rspective it is simply a > >>> >> >>>>> service > >>> >> >>>>>>>>> function which may modify the underlying packet. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one can have > >>> >> >>>>>>>>> what > >>> >> >>>>> appears > >>> >> >>>>>>>>> to the service chaining architecture as a single point of > >>> >> >>>>>>>>> contact > >>> >> >>>>> for a > >>> >> >>>>>>>>> specific service function, but is actually delivered by a > >>> >> >>>>> collection of > >>> >> >>>>>>>>> virtual or physical machines, possibly including one or > >>> >> >>>>>>>>> several load balancers (for example using VRRP-like > >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is > >>> >> >>>>>>>>> invisible to the service chaining data plane > mechanisms. It > >>> >> >>>>>>>>> is likely that it is visible to various control > mechanisms, > >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >>> >> >>>>>>>>> instantiation. The architectural impact of permitting this > >>> >> >>>>>>>>> is largely that we need to be careful that our terminology > >>> >> >>>>>>>>> does not lead > >>> >> >>>>> readers to > >>> >> >>>>>>>>> think we are prohibiting it. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> 3) There can also be load balancing done by selecting > >>> >> >>>>>>>>> packet paths for the service chaining that direct traffic > >>> >> >>>>>>>>> to different places. We would not want to require that a > >>> >> >>>>>>>>> given service function appear at only one place in the > >>> >> >>>>>>>>> network. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> It is of course the case that these may be combined. I > tend > >>> >> >>>>>>>>> to > >>> >> >>>>> refer to > >>> >> >>>>>>>>> the collection of entities that appear to service chaining > >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster is a > >>> >> >>>>>>>>> good term. But because I do not have another one. > Thus, the > >>> >> >>>>>>>>> point of type 3 load balancing > >>> >> >>>>> is to > >>> >> >>>>>>>>> direct different subsets of traffic to different singular > >>> >> >>>>>>>>> or clustered service functions in different places in the > >>> >> >>>>>>>>> network. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Now with that said, what do I mean when I talk about > >>> >> >>>>>>>>> service chain and service path/ Service chain is a > sequence > >>> >> >>>>>>>>> of logical functions to be applied to a subset of packets. > >>> >> >>>>>>>>> It is equivalent of saying that some subset of traffic is > >>> >> >>>>>>>>> to get DPI, charging, content inspection, and firewall > >>> >> >>>>>>>>> while a different subset is to go directly to the cache > >>> >> >>>>> without > >>> >> >>>>>>>>> visiting any other service functions. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> That is not enough information to direct the packets. A > >>> >> >>>>>>>>> service path is, in some fashion, a sequence of locations > >>> >> >>>>>>>>> in the network. Those locations will be singular or > >>> >> >>>>>>>>> clustered service function delivery locations. They may be > >>> >> >>>>>>>>> addressed by IP address. They may be addressed as ports on > >>> >> >>>>>>>>> an SFF. There are many different ways that the locations > >>> >> >>>>>>>>> may be known to the service chaining infrastructure > and the > >>> >> >>>>>>>>> transport. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>>> From the point of view of the work of the SFC group, we > >>> >> >>>>>>>>>> need to be > >>> >> >>>>>>>>> able to talk about the high level abstraction, the service > >>> >> >>>>>>>>> chain, which drives the forwarding. And we need to talk > >>> >> >>>>>>>>> about the actual data path packets will take in the > >>> >> >>>>>>>>> network. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Several of the comments have said "but the whole path may > >>> >> >>>>>>>>> not be known at the front." This architecture deals with > >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on > load > >>> >> >>>>>>>>> balancers above, there can be decisions and behaviors > which > >>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in much > >>> >> >>>>>>>>> the same way that bridging within a LAN is largely > >>> >> >>>>>>>>> invisible to routing between LANs.) The other provision we > >>> >> >>>>>>>>> make is > >>> >> >>>>> that > >>> >> >>>>>>>>> reclassification can be done in mid-chain when necessary. > >>> >> >>>>>>>>> That will direct packets to a new chain. Based on > >>> >> >>>>>>>>> information available at the re-classification point. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> I hope that this helps explain what we are after. If it > >>> >> >>>>>>>>> does, and if the intent is acceptable to the working > group, > >>> >> >>>>>>>>> we can figure out what additional words are needed to > >>> >> >>>>>>>>> convey this. If the working group disagree with the > intent, > >>> >> >>>>>>>>> then we will of course adjust to match the working group > >>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure > what to > >>> >> >>>>>>>>> try next. > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> Yours, Joel > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> _______________________________________________ sfc > >>> >> mailing > >>> >> >>>>>>>>> list sfc@ietf.org > >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>>>>>>> > >>> >> >>>>>>>>> _______________________________________________ sfc > >>> >> mailing > >>> >> >>>>>>>>> list sfc@ietf.org > >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>>>>>>> > >>> >> >>>>>>>> > >>> >> >>>>>>>> _______________________________________________ sfc > >>> >> mailing > >>> >> >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>>>>>> > >>> >> >>>>>>> > >>> >> >>>>>>> _______________________________________________ sfc > >>> >> mailing > >>> >> >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>>>>> > >>> >> >>>>>> > >>> >> >>>>>> _______________________________________________ sfc > >>> mailing > >>> >> list > >>> >> >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>>>> > >>> >> >>>>> > >>> >> >>>>> _______________________________________________ sfc > >>> mailing > >>> >> list > >>> >> >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>> > >>> >> >>>> _______________________________________________ sfc mailing > >>> >> list > >>> >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>> > >>> >> >>>> _______________________________________________ sfc mailing > >>> >> list > >>> >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> >> >>>> > >>> >> >>> > >>> >> >> > >>> >> >> _______________________________________________ > >>> >> >> sfc mailing list > >>> >> >> sfc@ietf.org > >>> >> >> https://www.ietf.org/mailman/listinfo/sfc > >>> >> >> > >>> >> > > >>> >> >_______________________________________________ > >>> >> >sfc mailing list > >>> >> >sfc@ietf.org > >>> >> >https://www.ietf.org/mailman/listinfo/sfc > >>> >> > >>> >> _______________________________________________ > >>> >> sfc mailing list > >>> >> sfc@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > > > >_______________________________________________ > >sfc mailing 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 Jul 11 09:23: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 093291A0385 for ; Fri, 11 Jul 2014 09:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.551 X-Spam-Level: X-Spam-Status: No, score=-13.551 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_BACKHAIR_27=1, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 0wWZyy5l43sX for ; Fri, 11 Jul 2014 09:23:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607901B2B69 for ; Fri, 11 Jul 2014 09:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55750; q=dns/txt; s=iport; t=1405095849; x=1406305449; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0qivHSdJ57N8TDJIw1mPAw6U1SNNYlEFq2YvUBM9qT4=; b=QOK2DqpTuae4DtJUxvk/9m3CFBK0hDuM18mke9x5MTt1jab6wgG/Djfz ExS4QNYVi8ZN9p3SQDdE1qF32rCmGTG3fEcaWtx1MDOo32F5unTwG1nPe cJh1ILHzrcpvoyv6FtoLcA4idElFs3DiNy0eTLdN8uyp+yy1PsWMioYHK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAPwOwFOtJA2F/2dsb2JhbABPCoJHR1Jap2uHD5F4AQmHQgGBCxZ1hAMBAQEEAQEBFwEMMQ0CBwsQAgEIEQECAQEBIQEGBycLFAMGCAIEAQ0FG4gTAxENxlMTBI0dgVBLBwYEBgGEQwWWIkmEGotoiDSDRIIw X-IronPort-AV: E=Sophos; i="5.01,644,1400025600"; d="scan'208,217"; a="60121160" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 11 Jul 2014 16:24:08 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGNhg5009129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:23:43 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:23:43 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywD//65IVoAAXQIAgADO1gCAAG79AP//wFoAgABJ7ID//71sgA== Date: Fri, 11 Jul 2014 16:23:42 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1124016040.3120.1405095661844.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1124016040.3120.1405095661844.JavaMail.tomcat@mgs-aam01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE587492D538jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Fr7IlWsdz67GkGmiLZBeQw97qZc Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:23:51 -0000 --_000_CFE587492D538jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable it=92s just an example where the 20 instances are hidden behind the SFF but= they do not have to be; if you wanted to address them individually then th= e architecture does not prevent that. From: "mikebianc@aol.com" > Date: Friday, July 11, 2014 at 12:21 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers but it still sounds like there is a single SFF entity tied to the 20 instan= ces through which ALL traffic destined for any of the 20 instances MUST tra= verse. While this should surely not be prohibited, it shouldn't be mandate= d. ________________________________ From: jguichar@cisco.com> To: mikebianc@aol.com>,mn1921@att.com> cc: sfc@ietf.org> Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers No they do not have to be physically connected but they are hidden behind a= n SFF in this case but do not have to be. From: "mikebianc@aol.com" > Date: Friday, July 11, 2014 at 11:44 AM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers When you say "20 instances of the SF2 SF" are "Connected to that SFF" do yo= u mean physically? I had always just assumed that if I had 20 instances of = a SF, that they would be diverse. Even if within the same datacenter, they = would be not near each other. It also seems like you are saying that there = is only a single SFF for SF2 and that your traffic path requires traversing= SF2 as a separate hop from the SF2 instance. Ideally, the traffic would fl= ow from SF1 instance to SF2 instance over the best path without the need fo= r an intermediary hop. *In my statements above, I assuming that each SF Instance is SFC aware to s= implify the text. ________________________________ From: jguichar@cisco.com> To: mikebianc@aol.com>,mn1921@att.com> cc: sfc@ietf.org> Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation wil= l contain a path identifier as described within our charter which says =933= . Generic SFC encapsulation: This document will describe a single service-l= evel data plane encapsulation format that indicates the sequence of service= functions that make up the Service Function Chain; specifies the Service F= unction Path=94. The wording here is very important and shows that the inte= nt is that the sequence of SF=92s be indicated within the SFC encapsulation= e.g. not carried =96 this is not source routing, and specifies the SFP, he= nce the path identifier. For my example let=92s assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1=94 It is possible that each of those SF=92s be directly addressable (i.e. prov= ide SFF functionality) or reachable through some other network device that = provides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF=92= s; let=92s call them SF1-loc1, SF2-loc2, and SF3-loc3. When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier =93100=94. This information is di= stributed to the relevant network devices basically saying =93if you receiv= e an SFC encapsulated packet with path identifier =93100=94 then use the pa= th identifier and index to perform a lookup in a data structure that will t= ell you which SF to forward the traffic to and how to get there=94. So traffic flows through the SFP with path identifier =93100=94, via a netw= ork transport (the path identifier is encapsulated). It reaches SF1-loc1 wh= ich uses the path identifier to determine that it is in fact the SF that sh= ould be applied. It applies SF1 SF and then uses the path identifier to det= ermine that SF2 is the next service and its reachable at next-hop SF2-loc2.= The needed transport (for example VXLAN) is imposed for network forwarding= . Traffic reaches SF2-loc2. It uses the path identifier to determine that S= F2 should be applied. It uses a local decision to determine which of the 20= instances of SF2 it should forward the traffic to. It forwards the traffic= to the selected instance. SF2 is applied and then another lookup occurs on= the path identifier, which results in the needed transport being imposed t= o reach the next service hop SF3-loc3 .. And so on and so forth. So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From: "mikebianc@aol.com" > Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim, Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at al= l. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. ________________________________ From: jguichar@cisco.com> To: NAPIERALA, MARIA H> cc: Paul Quinn (paulq)>,Lucy yong>,jmh@joelhalpern.com>,moh= amed.boucadair@orange.com>,sfc@ietf.org>,mikebianc@aol.com> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I=92d make t= he minor change: the path identifier can be used to derive the needed forwa= rding and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a = lookup, that lookup can result in a one or more (equal or weighted) transpo= rt next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behal= f Ofmohamed.boucadair@orange.com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;= jmh@joelhalpern.com= ;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la par= t demikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From:jmh@joelhalpern.com<= mailto:jmh@joelhalpern.com>= > To: sfc@ietf.org<= sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/lis= tinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CFE587492D538jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <82A1718E951DB4489A34521F13421BB4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
it=92s just an example where the 20 instances are hidden behind the SF= F but they do not have to be; if you wanted to address them individually th= en the architecture does not prevent that. 

From: "mikebianc@aol.com" <mikebianc@aol.com>
Date: Friday, July 11, 2014 at 12:2= 1 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers

but it still sounds like there is a single SFF entity tied to the 20 i= nstances through which ALL traffic destined for any of the 20 instances MUS= T traverse.  While this should surely not be prohibited, it shouldn't = be mandated.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

No they do not have to be physically connected but they are hidden beh= ind an SFF in this case but do not have to be.

From: "mikebianc@aol.com" <mikebianc@aol.com>
Date: Friday, July 11, 2= 014 at 11:44 AM
To: Jim Guichard <jguichar@cisco.com>, &= quot;mn1921@att.com" = <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

When you say "20 instances of the SF2 SF" are "Connecte= d to that SFF" do you mean physically? I had always just assumed that = if I had 20 instances of a SF, that they would be diverse. Even if within t= he same datacenter, they would be not near each other. It also seems like you are saying that there is only a single SFF for SF2 = and that your traffic path requires traversing SF2 as a separate hop from t= he SF2 instance. Ideally, the traffic would flow from SF1 instance to SF2 i= nstance over the best path without the need for an intermediary hop.

*In my statements above, I assuming that each SF Instance is SFC aware= to simplify the text.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Mike,

There still seems to be some confusion around this topic so let me try= to provide a more detailed explanation as to how I believe this should wor= k and why what I explained earlier is in fact a path identifier and not a c= hain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as descr= ibed within our charter which says =933. Generic SFC encapsulation: This do= cument will describe a single service-level data plane encapsulation format= that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path=94. The wording here is very imp= ortant and shows that the intent is that the sequence of SF=92s be indicate= d within the SFC encapsulation e.g. not carried =96 this is not source routing, and specifies= the SFP, hence the path identifier.

For my example let=92s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let=92s call it =93SFC-1= =94

It is possible that each of those SF=92s be directly addressable (i.e.= provide SFF functionality) or reachable through some other network device = that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 = relies on a connected switch to provide the needed SFF functionality. Conne= cted to that SFF are 20 instances of the SF2 SF. In this case you have exac= tly 3 network locators from which to choose in order to reach the required SF=92s; let=92s call them SF1-loc= 1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locator= s are selected to construct the path, and a path identifier is allocated. I= n this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> = SF2-loc2 -> SF3-loc3 and it has a path identifier =93100=94. This information is distributed to the relevant netw= ork devices basically saying =93if you receive an SFC encapsulated packet w= ith path identifier =93100=94 then use the path identifier and index to per= form a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there=94.

So traffic flows through the SFP with path identifier =93100=94, via a= network transport (the path identifier is encapsulated). It reaches SF1-lo= c1 which uses the path identifier to determine that it is in fact the SF th= at should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next ser= vice and its reachable at next-hop SF2-loc2. The needed transport (for exam= ple VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It = uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of= the 20 instances of SF2 it should forward the traffic to. It forwards the = traffic to the selected instance. SF2 is applied and then another lookup oc= curs on the path identifier, which results in the needed transport being imposed to reach the next service ho= p SF3-loc3 .. And so on and so forth.

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).


<= /span>

From: &qu= ot;mikebianc@aol.com" <mikebianc@aol.com>

Date: Thursday, July 10, 2014 at 4:= 46 PM
To: Jim Guichard <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers


Jim,

Technically, wouldn't this be a Chain Identifier if the next instance = is chosen at each hop? In this case, there wouldn't be any Path Identifier = at all.

But it is the difference between a classifier needing to track the hea= lth, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instance= s tracking 20 SFIs of the next-hop for the chains of which they are members= vs each SFF in the entire domain tracking all 80 SFIs vs something else.



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service = hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there wil= l be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the f= orwarding. I=92d make the minor change: the path identifier can be used to = derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to sim= ply identify the service path (or graph) that packets must traverse. By hav= ing a path identifier, the exact indirection that people seem to be asking = for on this thread can be simply be implemented. The path identifier provides nothing more than a lookup, that= lookup can result in a one or more (equal or weighted) transport next hop(= s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <lucy.yong@huawei.com> wrote:



Agree. The arch. doc should not man= date only use of the service path identifier to drive the forwarding action= s.

Lucy

From:sfc [mailto:sfc-bounces@ietf.org<= /a>]On Behalf Ofmohamed.boucadair@orange.com
Sent: Thursday, July 10= , 2014 2:06 AM
To: mikebianc@aol.com;jmh@joelhalpern.com<= /a>;sfc@ietf.org
Subject: Re: [sfc] Serv= ice Chains, Paths, and Load Balancers

Re-,

The merged draft calls out explicitly a s= ervice path identifier. I object to use that identifier to derive forwardin= g actions.

Requiring a SFC system to have the full k= nowledge of every available SFC forwarding paths within an SFC-enabled doma= in is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the= piece of information that will be present in all deployments: that is the = one required to structure a service chain. How that information is used to infer forwarding actions is a solut= ion-oriented discussion.

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org<= /a>]De la part demikebianc@aol.com
Envoy=E9 : mercredi 9 j= uillet 2014 22:03
=C0 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference between SF Chain an= d SF Path? Other than clarifying the definition so that it's clear to those= not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is th= e intent of this draft to ultimately specify what the ID of the SFC Header = should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other dr= afts to dictate the mechanisms for forwarding based on chain or path and th= e choice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft would have require t= hat both SFP and SFC be supported (or make one required and the other optio= nal) to avoid some vendors only supporting SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used
in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without
visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways.
First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
 --_000_CFE587492D538jguicharciscocom_-- From nobody Fri Jul 11 09:25: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 02C841A0AAB for ; Fri, 11 Jul 2014 09:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 pGDpTOdgnW1Q for ; Fri, 11 Jul 2014 09:25:10 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335B81A0385 for ; Fri, 11 Jul 2014 09:25:10 -0700 (PDT) Received: from mtaout-aac02.mx.aol.com (mtaout-aac02.mx.aol.com [172.27.2.34]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id 785C1702AB44E; Fri, 11 Jul 2014 12:25:09 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aac02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1D6CA38000094; Fri, 11 Jul 2014 12:25:09 -0400 (EDT) Date: Fri, 11 Jul 2014 12:25:08 -0400 From: "mikebianc@aol.com" To: Myo.Zarny@gs.com, jguichar@cisco.com, mn1921@att.com, jmh@joelhalpern.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <1236229119.3129.1405095908893.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3128_816799649.1405095908889" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405095909; bh=yA5PnoHjpQ6HnqkcA4Hm+3Kwj+BGOW89lCAf3dyBjOw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=1TMarlFsrpu2ndZSop5RIqeL1EqJeEE2sQ17KELLCyAOABDa/lizDgVAh410dRZb8 KjkXAZ6tdzx3PRHvekgxPoIdg9b928DjedCSbQ2pQaA7UEm25THFR3dJsGO1V0xN1R /4IehGJqHop5djGyNli20Toer0q6JDZ1Q8NFfMOE= x-aol-sid: 3039ac1b022253c00fe565eb X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wl0n7U_xGrWyEd90F6Zm1LLJfBI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:25:16 -0000 ------=_Part_3128_816799649.1405095908889 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I meant as a design principle when everything is working. =C2=A0I was tryin= g to come up with a concise example of configuring a network such that it d= oes not work that would be analogous to configuring SFC such that "that rem= ote SFF has the necessary forwarding logic to reach the=C2=A0next-next-SF". From: Myo.Zarny@gs.com To: 'mikebianc@aol.com','jguichar@cisco.com','mn1921@att.com','jmh@joelhalpern.com','Ron_Parker@affirmednetworks.com','sfc@ietf.org' Sent: Friday, July 11, 2014 Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I don=E2=80=99t understand. (I=E2=80=99m sure I=E2=80=99m misunderstanding= =E2=80=A6) Your backend servers could go down, be unreachable or be unable = to server more. Route health injection (RHI) is a perfectly fine, accepted,= way of indicating the health of the backend services to the network. You= =E2=80=99re not saying that=E2=80=99s wrong, are you? =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: 11 July 2014 12:03 PM To: jguichar@cisco.com; mn1921@att.com; jmh@joelhalpern.com; Ron_Parker@aff= irmednetworks.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers heh. well, if= it did not, then you should not do it like that. e.g. I'm not going to co= nfigure real servers on a server load balancer that are not reachable. e.g= . I'm not going to configure my BGP to announce prefixes for which I cannot= provide connectivity. If you do things like that, then you are doing it w= rong. From: jguichar@cisco.com To: NAPIERALA, MARIA H,Joel M. Halpern= ,Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Then I misunderstand the proposal ;-) .. However, it seems to me that if you allow an SFF to make a decision as to which remote SFF it will use for a given flow to reach the next SF within the chain then you better make sure that that remote SFF has the necessary forwarding logic to reach the next-next-SF for the chain as otherwise you are in deep trouble. On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" wrote: >Absolutely not. Service chains can be instantiated only in relevant SFFs >when they "arrive". > >> -----Original Message----- >>=20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>(jguichar) >> Sent: Friday, July 11, 2014 9:27 AM >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Well I think it is even worse than that if I have understood the >>proposal >> correctly as it would require full knowledge of every single SF within >>the >> entire SFC domain at every single SFF as there is no way to know a >>priori >> which SFC=C2=B9s a given SFF will need to service at any given point in = time. >>=20 >> On 7/10/14, 11:53 PM, "Joel M. Halpern" wrote: >>=20 >> >Ron, thinking about this, I realized another major problem with the >>your >> >proposal as I understand it. (And I readily admit I may not understand >> >it.) >> > >> >The proposal has each SFF serve as the load balancer for the next >> >service function that follows it (not the one it delivers to), in every >> >service chain that goes through it. >> > >> >Since it has to be able to work with all services, that means that >>every >> >SFF would have to be a full, flow sensitive and stateful load balancer. >> >I ahve no problem if some SFF are flow sensitive, and / or stateful. >> >But having the architecture require that every SFF be a full, flow >> >sensitive, stateful, load balancer seems to me to be an acceptable >> >imposition. >> > >> >Yours, >> >Joel >> > >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >> Part of my personal view is that I am trying to make this work >>sensibly >> >> in a more orchestrated environment. I expect that the service >> >> functions, and over time probably the SFF capabilities, will be >> >> orchestrated and installed. I expect the service chains to be >>driven by >> >> BSS tools that define offerings to clients, and enable self-selection >> >> from these. I expect service paths to be heavily policy drive. >> >> >> >> I can see how to make all of that work in an archtiecture driven by >> >> initial classification to described service paths. It is harder to >>see >> >> how to make it work (but it can be done) when we allow more >> dynamicity >> >> in the network behavior. >> >> >> >> Having said that, most of that perspective I described is outside of >>the >> >> scope of the working group. it is not something we are tasked to >>agree >> >>on. >> >> So I do not claim that vision means we have to do it a certain way. >>it >> >> is just the perspective that drives my preferences. >> >> >> >> Yours, >> >> Joel >> >> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >>>> For me, the amount of information about service instances that >>needs >> >>>>to >> >>>> be widely distributed and maintained, potentially even across data >> >>>> centers within an administrative scope, is large enough and complex >> >>>> enough that trying to get that into each SFF seems like a difficult >> >>>> architecture to realize. >> >>> >> >>> I'm curious as to why that is more complicated than dynamic routing, >> >>> hyper-scale data center orchestration, or DNS, all of which are >>bigger >> >>> problems that have been profitably and stably implemented? >> >>> >> >>> It also seems that if it really is more complicated, that is a good >> >>> sign that it is too complicated. >> >>> >> >>> ________________________________________ >> >>> From: Joel M. Halpern [jmh@joelhalpern.com] >> >>> Sent: Thursday, July 10, 2014 9:45 PM >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com; Ian Smith ;>> >>> sfc@ietf.org >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >>> >> >>> This is an architectural issue. And one that I would prefer we >> >>>actually >> >>> decide, rather than trying to allow all possible implementations. >> >>> Because it does have a major effect on the control requirements and >> the >> >>> functionality of SFFs. >> >>> >> >>> For me, the amount of information about service instances that needs >> to >> >>> be widely distributed and maintained, potentially even across data >> >>> centers within an administrative scope, is large enough and complex >> >>> enough that trying to get that into each SFF seems like a difficult >> >>> architecture to realize. >> >>> >> >>> Yours, >> >>> Joel >> >>> >> >>> But it is a fair question. >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >>>> This is the crux of my issue. Is the end to end selection of >> >>>> (top-level) instances performed centrally (perhaps by the >>classifier) >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the >>SFFs)? >> >>>> Such selection is not equivalent to reclassification. And surely, >> >>>> this is an architectural issue and not relegated to >> >>>> "implementation". >> >>>> >> >>>> My own view is to favor the distributed approach even though a >> >>>> greater amount of data (chain definitions and perhaps local >>selection >> >>>> policy) is required at those distributed decision points. This >> >>>> approach does not require an end-to-end path id at all. My >> >>>> rationale for favoring this approach is primarily driven by >>increased >> >>>> resiliency over the global path id approach. With a global path >>id >> >>>> approach, consider failure of an instance and needing to alter the >> >>>> global path ID table for each and every affected end-to-end path. >> >>>> >> >>>> Ron >> >>>> >> >>>> ________________________________________ From: sfc >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014 6:15 PM >> >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org Subject: Re: >> >>>> [sfc] Service Chains, Paths, and Load Balancers >> >>>> >> >>>> The way the architecture models the case of SF1 needing to >>influence >> >>>> the chain is that one would do reclassification at the exit from >> >>>> SF1. >> >>>> >> >>>> Part of the goal is to keep the different functions logically >> >>>> separate so that solutions can clearly describe how they choose to >> >>>> compose them for "service" delivery. >> >>>> >> >>>> Yours, Joel >> >>>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> >>>>> I don't see anything in the arch draft that suggests any sort of >> >>>>> limit. However, it does seem to indicate that the entire path (all >> >>>>> SFIs) must be chosen at SFC instantiation. I believe this means >> >>>>> either at the classifier or maybe the classifier chooses a SF >>Chain >> >>>>> and the NF or at the latest the first SFF. In any case, the >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is >> >>>>> determined at the SFI(n-1) hop. According to the draft, this >> >>>>> behavior would be considered "branching" to a new SFP as opposed >> to >> >>>>> choosing and then forwarding to the selected instance of the >> >>>>> next-hop of the current SFC. >> >>>>> >> >>>>> draft-merged-sfc-architecture-00: >> >>>>>> When an SFC is instantiated into the network it is necessary to >> >>>>>> select the specific instances of SFs that will be used, and to >> >>>>>> create the service topology for that SFC using SF's network >> >>>>>> locator. Thus, instantiation of the SFC results in the creation >> >>>>>> of a Service Function Path (SFP) and is used for forwarding >> >>>>>> packets through the SFC. In other words, an SFP is the >> >>>>>> instantiation of the defined SFC. >> >>>>>> >> >>>>>> The SFC architecture supports reclassification (or non-initial >> >>>>>> classification) as well. As packets traverse an SFP, >> >>>>>> reclassification may occur - typically performed by a >> >>>>>> classification function co-resident with a service function. >> >>>>>> Reclassification may result in the selection of a new SFP, an >> >>>>>> update of the associated metadata, or both. This is referred to >> >>>>>> as "branching". >> >>>>> >> >>>>> >> >>>>> >> >>>>> >>=20 >>>>>>>-------------------------------------------------------------------- >>>>>>>-- >> >>>>>-- >> >>>>> >> >>>>> >> >>>>> >> >>> *From: *I.Smith@F5.com >> >>>>> *To: *Joel Halpern Direct,Joel M. >> >>>>> >> >>>>>Halpern,huang@sce.carleton.ca> carleton. >> >>>>>ca>,sfc@ietf.org >> >>>>> >> >>>>> >> >>>>> >> >>> *Sent: *Thursday, July 10, 2014 >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >> >>>>> >> >>>>> Actually, I think I am disagreeing. >> >>>>> >> >>>>> If the possibility of medium-scale deployments (and that is what >> >>>>> 16 million flows is in my world) of service chains is preconceived >> >>>>> as an absurd idea, then the architecture burdened with that >> >>>>> preconception. >> >>>>> >> >>>>> There has to be some point of aim, some degree of aspiration to >> >>>>> scale that is appropriate for the lifespan of the architecture - >> >>>>> you don't have to know what it is, but by saying that an arbitrary >> >>>>> number is "too far", you're creating - even if it isn't >>intentional >> >>>>> - a limit that influences decisions that have lasting impacts >> >>>>> regarding scale-out, failure mitigation, elasticity, address >> >>>>> space... all kinds of things. That is a problem I'm not >> >>>>> particularly eager to deal with. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> ________________________________________ >> >>>>> >> >>>>> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent: >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern ;>> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] Service >> >>>>> Chains, Paths, and Load Balancers >> >>>>> >> >>>>> Ian, I don't think you disagree with me at all in this regard. I >>am >> >>>>> not requesting the the architecture or the solution prohibit >> >>>>> deployments in the specific fashion. I am objecting to Huang's >> >>>>> reading of my note as saying that such deployments are required >> >>>>> they by the archtiecture. >> >>>>> >> >>>>> As I have said repeatedly, I am not trying to prohibit such >> >>>>> things. Whether they are a good idea or not depends upon many >> >>>>> factors outside of the scope of the WG. I happen to think that >>they >> >>>>> are usually a bad idea. >> >>>>> >> >>>>> But the archtiecture si carefully avoiding attempting to know what >> >>>>> is and is not eployable. >> >>>>> >> >>>>> Yours, Joel >> >>>>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >>>>>> I disagree. >> >>>>>> >> >>>>>> We routinely have stateful devices that manage tens of millions >> >>>>>> of >> >>>>> concurrent flows in both access network and data center >> >>>>> environments today. You can't seriously believe that in the >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >> going >> >>>>> to have small numbers of service chains with equally small numbers >> >>>>> of active service paths? >> >>>>>> >> >>>>>> Your sounds too much like "no one will ever need more than 64K" >> >>>>>> for >> >>>>> comfort. >> >>>>>> >> >>>>>> >> >>>>>> ________________________________________ From: sfc >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> >>>>> [jmh@joelhalpern.com] >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: huang@sce.carleton.ca ;>> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load >> >>>>>> Balancers >> >>>>>> >> >>>>>> No, it will mean that if someone tries to deploy the archtieture >> >>>>>> particularly badly, they will exceed the limits of their >> >>>>>> devices. The architecture does not require such absurd use of >> >>>>>> service paths. Since I can not figure out how to write >> >>>>>> architectural words to prohibit it, the architecture does permit >> >>>>>> such abuse. >> >>>>>> >> >>>>>> Please do not read my saying that the archtiecture permits >> >>>>>> something as saying it is either deisred or required by the work. >> >>>>>> It isn't. >> >>>>>> >> >>>>>> Yours, Joel >> >>>>>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >>>>>>> If you need to support 100 service chains, it will mean >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a >> >>>>>>> core router. >> >>>>>>> >> >>>>>>> Chang >> >>>>>>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >>>>>>>> The architecture allows a range of deployments, from 1 >> >>>>>>>> service path to 160000 service paths. I would hope that >> >>>>>>>> operators are prepared for the complexities if they choose to >> >>>>>>>> avoid any use of local load balancing and in stead provision >> >>>>>>>> 160,000 service paths. >> >>>>>>>> >> >>>>>>>> Yours, Joel >> >>>>>>>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> >>>>>>>>> Paul, >> >>>>>>>>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop service >> >>>>>>>>> chain with 20 instances at each hop? >> >>>>>>>>> >> >>>>>>>>> Maria >> >>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com ;>> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org ;>> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service Chains, >> >>>>>>>>> Paths, and Load Balancers >> >>>>>>>>> >> >>>>>>>>> Lucy, >> >>>>>>>>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the >> >>>>>>>>> forwarding. I=C2=B9d >> >>>>> make >> >>>>>>>>> the minor change: the path identifier can be used to derive >> >>>>>>>>> the needed forwarding and associated transport. >> >>>>>>>>> >> >>>>>>>>> It is _not_ the transport, but rather is used to simply >> >>>>>>>>> identify the service path (or graph) that packets must >> >>>>>>>>> traverse. By having a path identifier, the exact >> >>>>>>>>> indirection that people seem to be asking for on this >> >>>>>>>>> thread can be simply be implemented. The path identifier >> >>>>>>>>> provides nothing more than a lookup, that lookup can result >> >>>>>>>>> in a one or more (equal or weighted) transport next >> >>>>>>>>> hop(s). >> >>>>>>>>> >> >>>>>>>>> Paul >> >>>>>>>>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >>>>>>>>> > >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the >> >>>>>>>>> service path identifier to drive the forwarding actions. >> >>>>>>>>> >> >>>>>>>>> Lucy >> >>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> >>>>>>>>> Of*mohamed.boucadair@orange.com >> >>>>>>>>> *Sent:*Thursday, >> July >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >>>>>>>>> ;jmh@joelhalpern.com >> >>>>>>>>> ;sfc@ietf.org >> >>>>>>>>> *Subject:*Re: [sfc] Service Chains, >> >>>>>>>>> Paths, and Load Balancers >> >>>>>>>>> >> >>>>>>>>> Re-, >> >>>>>>>>> >> >>>>>>>>> The merged draft calls out explicitly a service path >> >>>>>>>>> identifier. I object to use that identifier to derive >> >>>>>>>>> forwarding actions. >> >>>>>>>>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every >> >>>>> available SFC >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not >> >>>>> required/justified >> >>>>>>>>> nor possible in various deployment contexts. >> >>>>>>>>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of >> >>>>>>>>> information >> >>>>> that will >> >>>>>>>>> be present in all deployments: that is the one required to >> >>>>>>>>> structure a service chain. How that information is used to >> >>>>>>>>> infer forwarding >> >>>>> actions >> >>>>>>>>> is a solution-oriented discussion. >> >>>>>>>>> >> >>>>>>>>> Cheers, >> >>>>>>>>> >> >>>>>>>>> Med >> >>>>>>>>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> >>>>> de*mikebianc@aol.com >> >>>>>>>>> *Envoy=C3=A9 :*mercredi 9 juillet >> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com >> >>>>>>>>> ;sfc@ietf.org >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains, >> >>>>>>>>> Paths, and Load Balancers >> >>>>>>>>> >> >>>>>>>>> Is anyone still questioning the difference between SF Chain >> >>>>>>>>> and SF >> >>>>> Path? >> >>>>>>>>> Other than clarifying the definition so that it's clear to >> >>>>> those not >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on >> >>>>>>>>> these terms. >> >>>>>>>>> >> >>>>>>>>> To me, the one point that is still unclear is whether it is >> >>>>>>>>> the intent of this draft to ultimately specify what the ID >> >>>>>>>>> of the SFC Header >> >>>>> should >> >>>>>>>>> reference (the chain or the path), or if this draft simply >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or >> >>>>>>>>> path and the choice of chain or >> >>>>> path to >> >>>>>>>>> be negotiated in the control-plane. >> >>>>>>>>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have >> >>>>>>>>> require that both SFP and SFC be supported (or make one >> >>>>>>>>> required and the other optional) to avoid some vendors only >> >>>>>>>>> supporting SFP and others only supporting SFC. >> >>>>>>>>> >> >>>>>>>>> >> >>>>> >>=20 >>>>>>>-------------------------------------------------------------------- >>>>>>>-- >> >>>>>-- >> >>>>> >> >>>>> >> >>>>> >> >>>>>>> >> >>>>>>>>> *From:*jmh@joelhalpern.com> >>>>>>>>> > >> >>>>>>>>> *To:*sfc@ietf.org> >>>>>>>>> > *Sent:*Tuesday, July >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >> >>>>>>>>> Balancers >> >>>>>>>>> >> >>>>>>>>> I have been trying to figure out how to clearly answer a >> >>>>>>>>> number of comments that have been made about the proposed >> >>>>>>>>> merged archtiecture draft. Assuming we can get working >> >>>>>>>>> group agreement on the intent, we will work to improve the >> >>>>>>>>> wording so that readers who have not participated in the WG >> >>>>>>>>> discussion will understnd it the way the >> >>>>> working >> >>>>>>>>> group intends. >> >>>>>>>>> >> >>>>>>>>> But what do we intend? I will try to explain my personal >> >>>>>>>>> view, and see if that helps. >> >>>>>>>>> >> >>>>>>>>> In this regard, it is important to keep in mind that what >> >>>>>>>>> we are defining is the data plane architecture. We are not >> >>>>>>>>> attempting to define the architecture for the entire >> >>>>>>>>> solution for service chaining. That would encompass >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual >> >>>>>>>>> machine and image management, and many other aspects. >> >>>>>>>>> >> >>>>>>>>> As a result there are many things which clearly need to >> >>>>>>>>> exist in the larger system, but which are dealt with above >> >>>>>>>>> where we are >> >>>>> functioning, >> >>>>>>>>> and are not directly required by the work we are doing. >> >>>>>>>>> >> >>>>>>>>> In order to get to service chain vs service path, as I >> >>>>>>>>> understand >> >>>>> them, >> >>>>>>>>> I need to first discuss load balancing. There are at least >> >>>>>>>>> three different ways that load balancing can and will >> >>>>>>>>> interact with service chaining. There probably are more. >> >>>>>>>>> The point of the archtiecture is to permit all of these, >> >>>>>>>>> but not to mandate that any particular kind >> >>>>> be used >> >>>>>>>>> in any solution. >> >>>>>>>>> >> >>>>>>>>> 1) Load balancing as a service provided to the end user. >> >>>>>>>>> This is a service function. It receives user packets, and >> >>>>>>>>> modifies them (or >> >>>>> marks >> >>>>>>>>> them, or ...) so as to choose an end user service instance >> >>>>>>>>> to receive the users packet. This is an important service >> >>>>>>>>> function to be able to include in service chaining. It's >> >>>>>>>>> behavior may affect requirements on how service chaining is >> >>>>>>>>> done. But it has very little impact on the archtiecture. >> >>>>>>>>> From an architectural pe3rspective it is simply a >> >>>>> service >> >>>>>>>>> function which may modify the underlying packet. >> >>>>>>>>> >> >>>>>>>>> 2) There is internal load balancing. That is, one can have >> >>>>>>>>> what >> >>>>> appears >> >>>>>>>>> to the service chaining architecture as a single point of >> >>>>>>>>> contact >> >>>>> for a >> >>>>>>>>> specific service function, but is actually delivered by a >> >>>>> collection of >> >>>>>>>>> virtual or physical machines, possibly including one or >> >>>>>>>>> several load balancers (for example using VRRP-like >> >>>>>>>>> techniques to share a MAC address.) mostly, this is >> >>>>>>>>> invisible to the service chaining data plane mechanisms. It >> >>>>>>>>> is likely that it is visible to various control mechanisms, >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm >> >>>>>>>>> instantiation. The architectural impact of permitting this >> >>>>>>>>> is largely that we need to be careful that our terminology >> >>>>>>>>> does not lead >> >>>>> readers to >> >>>>>>>>> think we are prohibiting it. >> >>>>>>>>> >> >>>>>>>>> 3) There can also be load balancing done by selecting >> >>>>>>>>> packet paths for the service chaining that direct traffic >> >>>>>>>>> to different places. We would not want to require that a >> >>>>>>>>> given service function appear at only one place in the >> >>>>>>>>> network. >> >>>>>>>>> >> >>>>>>>>> It is of course the case that these may be combined. I tend >> >>>>>>>>> to >> >>>>> refer to >> >>>>>>>>> the collection of entities that appear to service chaining >> >>>>>>>>> as a single point as a cluster. Not because cluster is a >> >>>>>>>>> good term. But because I do not have another one. Thus, the >> >>>>>>>>> point of type 3 load balancing >> >>>>> is to >> >>>>>>>>> direct different subsets of traffic to different singular >> >>>>>>>>> or clustered service functions in different places in the >> >>>>>>>>> network. >> >>>>>>>>> >> >>>>>>>>> Now with that said, what do I mean when I talk about >> >>>>>>>>> service chain and service path/ Service chain is a sequence >> >>>>>>>>> of logical functions to be applied to a subset of packets. >> >>>>>>>>> It is equivalent of saying that some subset of traffic is >> >>>>>>>>> to get DPI, charging, content inspection, and firewall >> >>>>>>>>> while a different subset is to go directly to the cache >> >>>>> without >> >>>>>>>>> visiting any other service functions. >> >>>>>>>>> >> >>>>>>>>> That is not enough information to direct the packets. A >> >>>>>>>>> service path is, in some fashion, a sequence of locations >> >>>>>>>>> in the network. Those locations will be singular or >> >>>>>>>>> clustered service function delivery locations. They may be >> >>>>>>>>> addressed by IP address. They may be addressed as ports on >> >>>>>>>>> an SFF. There are many different ways that the locations >> >>>>>>>>> may be known to the service chaining infrastructure and the >> >>>>>>>>> transport. >> >>>>>>>>> >> >>>>>>>>>> From the point of view of the work of the SFC group, we >> >>>>>>>>>> need to be >> >>>>>>>>> able to talk about the high level abstraction, the service >> >>>>>>>>> chain, which drives the forwarding. And we need to talk >> >>>>>>>>> about the actual data path packets will take in the >> >>>>>>>>> network. >> >>>>>>>>> >> >>>>>>>>> Several of the comments have said "but the whole path may >> >>>>>>>>> not be known at the front." This architecture deals with >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load >> >>>>>>>>> balancers above, there can be decisions and behaviors which >> >>>>>>>>> are invisible to the service chaining mechanisms (in much >> >>>>>>>>> the same way that bridging within a LAN is largely >> >>>>>>>>> invisible to routing between LANs.) The other provision we >> >>>>>>>>> make is >> >>>>> that >> >>>>>>>>> reclassification can be done in mid-chain when necessary. >> >>>>>>>>> That will direct packets to a new chain. Based on >> >>>>>>>>> information available at the re-classification point. >> >>>>>>>>> >> >>>>>>>>> I hope that this helps explain what we are after. If it >> >>>>>>>>> does, and if the intent is acceptable to the working group, >> >>>>>>>>> we can figure out what additional words are needed to >> >>>>>>>>> convey this. If the working group disagree with the intent, >> >>>>>>>>> then we will of course adjust to match the working group >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to >> >>>>>>>>> try next. >> >>>>>>>>> >> >>>>>>>>> Yours, Joel >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc >> mailing >> >>>>>>>>> list sfc@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc >> mailing >> >>>>>>>>> list sfc@ietf.org >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ sfc >> mailing >> >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ sfc >> mailing >> >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ sfc mailing >> list >> >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>>>> >> >>>>> >> >>>>> _______________________________________________ sfc mailing >> list >> >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>> >> >>>> _______________________________________________ sfc mailing >> list >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>> >> >>>> _______________________________________________ sfc mailing >> list >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> >>>> >> >>> >> >> >> >> _______________________________________________ >> >> sfc mailing 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_3128_816799649.1405095908889 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I meant as a design= principle when everything is working.  I was trying to come up with a= concise example of configuring a network such that it does not work that w= ould be analogous to configuring SFC such that "that remote SFF has the necessary for= warding logic to reach the next-next-SF".





From: Myo.Z= arny@gs.com<Myo.Zarny@gs.com>
To: 'mikebianc@aol.com'<mi= kebianc@aol.com>,'jguichar@cisco.com'<jguichar@cisco.com>,'mn1921@= att.com'<mn1921@att.com>,'jmh@joelhalpern.com'<jmh@joelhalpern.com= >,'Ron_Parker@affirmednetworks.com'<Ron_Parker@affirmednetworks.com&g= t;,'sfc@ietf.org'<sfc@ietf.org>
Sent: Friday, July 11, 2014=
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers
=
=

I don=E2=80=99t understand. (I=E2=80=99m sure I=E2=80=99m= misunderstanding=E2=80=A6)

Your backend servers could go down, be unreachable or= be unable to server more.

Route health injection (RHI) is a perfectly fine, acce= pted, way of indicating the health of the backend services to the network. = You=E2=80=99re not saying that=E2=80=99s wrong, are you?<= /p>

<= p class=3D"MsoNormal" style=3D"margin-left:.5in">

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com
Sent: 11 July 2014 12:03 = PM
To: jguichar@cisco.com; mn1921@att.com; jmh@joelhalpern.com; Ron_Parker@affirmednetworks.com; sfc@ietf.org
Subject: Re: [sfc] Service Chai= ns, Paths, and Load Balancers

<= p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0in;margin-right:0in;marg= in-bottom:12.0pt;margin-left:.5in">heh. well, if it did not, then you should not= do it like that. e.g. I'm not going to configure real servers on a server= load balancer that are not reachable. e.g. I'm not going to configure my = BGP to announce prefixes for which I cannot provide connectivity. If you d= o things like that, then you are doing it wrong.

<= /p>



From: jguichar@cisco.com<jguichar@cisco.com>=
To: NAPIERALA, MARIA H<mn19= 21@att.com>,Joel M. Halpern<jmh@joelhalpern.com>,Ron Parker<Ron_Parker@affirmednetworks.com>,sfc@ietf.org<sfc@ie= tf.org>
Sent: Friday, July 11, 2014
Subject: Re:= [sfc] Service Chains, Paths, and Load Balancers

Then I misunderstan= d the proposal ;-) .. However, it seems to me that if
you allow an SFF t= o make a decision as to which remote SFF it will use for
a given flow to= reach the next SF within the chain then you better make
sure that that = remote SFF has the necessary forwarding logic to reach the
next-next-SF = for the chain as otherwise you are in deep trouble.

On 7/11/14, 9:48= AM, "NAPIERALA, MARIA H" <mn1921@att.= com> wrote:

>Absolutely not. Service chains can be instant= iated only in relevant SFFs
>when they "arrive".
>
>> = -----Original Message-----
>>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Gu= ichard
>>(jguichar)
>> Sent: Friday, July 11, 2014 9:27 A= M
>> To: Joel M. Halpern; Ron Parker; sfc@ietf.org
>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers
>>
>> Well I think it is even worse t= han that if I have understood the
>>proposal
>> correctly= as it would require full knowledge of every single SF within
>>th= e
>> entire SFC domain at every single SFF as there is no way to k= now a
>>priori
>> which SFC=C2=B9s a given SFF will need = to service at any given point in time.
>>
>> On 7/10/14,= 11:53 PM, "Joel M. Halpern" <jmh= @joelhalpern.com> wrote:
>>
>> >Ron, thinking = about this, I realized another major problem with the
>>your
&g= t;> >proposal as I understand it. (And I readily admit I may not unde= rstand
>> >it.)
>> >
>> >The proposal h= as each SFF serve as the load balancer for the next
>> >service= function that follows it (not the one it delivers to), in every
>>= ; >service chain that goes through it.
>> >
>> >= Since it has to be able to work with all services, that means that
>&= gt;every
>> >SFF would have to be a full, flow sensitive and st= ateful load balancer.
>> >I ahve no problem if some SFF are flo= w sensitive, and / or stateful.
>> >But having the architecture= require that every SFF be a full, flow
>> >sensitive, stateful= , load balancer seems to me to be an acceptable
>> >imposition.=
>> >
>> >Yours,
>> >Joel
>> &= gt;
>> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:
>>= ; >> Part of my personal view is that I am trying to make this work>>sensibly
>> >> in a more orchestrated environment.= I expect that the service
>> >> functions, and over time pr= obably the SFF capabilities, will be
>> >> orchestrated and = installed. I expect the service chains to be
>>driven by
>&g= t; >> BSS tools that define offerings to clients, and enable self-sel= ection
>> >> from these. I expect service paths to be heavil= y policy drive.
>> >>
>> >> I can see how to = make all of that work in an archtiecture driven by
>> >> ini= tial classification to described service paths. It is harder to
>>= see
>> >> how to make it work (but it can be done) when we a= llow more
>> dynamicity
>> >> in the network behavi= or.
>> >>
>> >> Having said that, most of tha= t perspective I described is outside of
>>the
>> >>= scope of the working group. it is not something we are tasked to
>&g= t;agree
>> >>on.
>> >> So I do not claim that= vision means we have to do it a certain way.
>>it
>> >= ;> is just the perspective that drives my preferences.
>> >&= gt;
>> >> Yours,
>> >> Joel
>> >&= gt;
>> >> On 7/10/14, 9:58 PM, Ian Smith wrote:
>> = >>>> For me, the amount of information about service instances = that
>>needs
>> >>>>to
>> >>&g= t;> be widely distributed and maintained, potentially even across data>> >>>> centers within an administrative scope, is larg= e enough and complex
>> >>>> enough that trying to get= that into each SFF seems like a difficult
>> >>>> arc= hitecture to realize.
>> >>>
>> >>> I'm= curious as to why that is more complicated than dynamic routing,
>&g= t; >>> hyper-scale data center orchestration, or DNS, all of which= are
>>bigger
>> >>> problems that have been pro= fitably and stably implemented?
>> >>>
>> >&g= t;> It also seems that if it really is more complicated, that is a good<= br>>> >>> sign that it is too complicated.
>> >&= gt;>
>> >>> ________________________________________>> >>> From: Joel M. Halpern [jmh@joelhalpern.com]
>> >>> Sent: Thursday= , July 10, 2014 9:45 PM
>> >>> To: Ron Parker; Joel Halpe= rn Direct; mikebianc@aol.com; Ian = Smith;
>> >>> sfc@ietf.or= g
>> >>> Subject: Re: [sfc] Service Chains, Paths, an= d Load Balancers
>> >>>
>> >>> This is = an architectural issue. And one that I would prefer we
>> >>= >actually
>> >>> decide, rather than trying to allow a= ll possible implementations.
>> >>> Because it does have = a major effect on the control requirements and
>> the
>> = >>> functionality of SFFs.
>> >>>
>> &g= t;>> For me, the amount of information about service instances that n= eeds
>> to
>> >>> be widely distributed and main= tained, potentially even across data
>> >>> centers withi= n an administrative scope, is large enough and complex
>> >>= > enough that trying to get that into each SFF seems like a difficult>> >>> architecture to realize.
>> >>>>> >>> Yours,
>> >>> Joel
>> >= ;>>
>> >>> But it is a fair question.
>> &= gt;>>
>> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:=
>> >>>> This is the crux of my issue. Is the end to= end selection of
>> >>>> (top-level) instances perfor= med centrally (perhaps by the
>>classifier)
>> >>&g= t;> or hop-by-hop (perhaps by the classifier and subsequently the
>= ;>SFFs)?
>> >>>> Such selection is not equivalent t= o reclassification. And surely,
>> >>>> this is an a= rchitectural issue and not relegated to
>> >>>> "imple= mentation".
>> >>>>
>> >>>> My ow= n view is to favor the distributed approach even though a
>> >&= gt;>> greater amount of data (chain definitions and perhaps local
= >>selection
>> >>>> policy) is required at those= distributed decision points. This
>> >>>> approach = does not require an end-to-end path id at all. My
>> >>&g= t;> rationale for favoring this approach is primarily driven by
>&= gt;increased
>> >>>> resiliency over the global path i= d approach. With a global path
>>id
>> >>>>= approach, consider failure of an instance and needing to alter the
>= > >>>> global path ID table for each and every affected end-= to-end path.
>> >>>>
>> >>>> Ron<= br>>> >>>>
>> >>>> _________________= _______________________ From: sfc
>> >>>> [sfc-bounces@ietf.org] on behalf of Joel Ha= lpern Direct
>> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, 2014= 6:15 PM
>> >>>> To: mikebianc@aol.com; I.Smith@F5.com= ; sfc@ietf.org Subject: Re:
>= > >>>> [sfc] Service Chains, Paths, and Load Balancers
&g= t;> >>>>
>> >>>> The way the architectu= re models the case of SF1 needing to
>>influence
>> >&= gt;>> the chain is that one would do reclassification at the exit fro= m
>> >>>> SF1.
>> >>>>
>>= ; >>>> Part of the goal is to keep the different functions logi= cally
>> >>>> separate so that solutions can clearly d= escribe how they choose to
>> >>>> compose them for "s= ervice" delivery.
>> >>>>
>> >>>>= Yours, Joel
>> >>>>
>> >>>> On 7= /10/14, 6:10 PM, mikebianc@aol.com= wrote:
>> >>>>> I don't see anything in the arch d= raft that suggests any sort of
>> >>>>> limit. Howe= ver, it does seem to indicate that the entire path (all
>> >>= ;>>> SFIs) must be chosen at SFC instantiation. I believe this mea= ns
>> >>>>> either at the classifier or maybe the c= lassifier chooses a SF
>>Chain
>> >>>>> an= d the NF or at the latest the first SFF. In any case, the
>> >&= gt;>>> language does seem to prohibit a more dynamic SFP where SFI= (n) is
>> >>>>> determined at the SFI(n-1) hop. Acc= ording to the draft, this
>> >>>>> behavior would b= e considered "branching" to a new SFP as opposed
>> to
>>= >>>>> choosing and then forwarding to the selected instance= of the
>> >>>>> next-hop of the current SFC.
&g= t;> >>>>>
>> >>>>> draft-merged-s= fc-architecture-00:
>> >>>>>> When an SFC is ins= tantiated into the network it is necessary to
>> >>>>&= gt;> select the specific instances of SFs that will be used, and to
&= gt;> >>>>>> create the service topology for that SFC u= sing SF's network
>> >>>>>> locator. Thus, insta= ntiation of the SFC results in the creation
>> >>>>>= ;> of a Service Function Path (SFP) and is used for forwarding
>&g= t; >>>>>> packets through the SFC. In other words, an SFP= is the
>> >>>>>> instantiation of the defined S= FC.
>> >>>>>>
>> >>>>>&g= t; The SFC architecture supports reclassification (or non-initial
>&g= t; >>>>>> classification) as well. As packets traverse an= SFP,
>> >>>>>> reclassification may occur - typ= ically performed by a
>> >>>>>> classification f= unction co-resident with a service function.
>> >>>>&g= t;> Reclassification may result in the selection of a new SFP, an
>= ;> >>>>>> update of the associated metadata, or both. = This is referred to
>> >>>>>> as "branching".>> >>>>>
>> >>>>>
>>= >>>>>
>> >>>>>
>>
>= >>>>>>---------------------------------------------------= -----------------
>>>>>>>--
>> >>>= ;>>--
>> >>>>>
>> >>>>&g= t;
>> >>>>>
>> >>> *From: *I.Smith@F5.com<I.Smith@F5.= com>
>> >>>>> *To: *Joel Halpern Direct<<= a href=3D"mailto:jmh.direct@joelhalpern.com">jmh.direct@joelhalpern.com= >,Joel M.
>> >>>>>
>> >>>>&= gt;Halpern<jmh@joelhalpern.com>,huang@sce.carleton.ca<= ;huang@sce.
>> carleton.
&= gt;> >>>>>ca>,sfc@ietf= .org<sfc@ietf.org>
>>= ; >>>>>
>> >>>>>
>> >>= ;>>>
>> >>> *Sent: *Thursday, July 10, 2014
&= gt;> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, an= d Load Balancers
>> >>>>>
>> >>>&= gt;> Actually, I think I am disagreeing.
>> >>>>>= ;
>> >>>>> If the possibility of medium-scale deplo= yments (and that is what
>> >>>>> 16 million flows = is in my world) of service chains is preconceived
>> >>>&= gt;> as an absurd idea, then the architecture burdened with that
>= > >>>>> preconception.
>> >>>>>>> >>>>> There has to be some point of aim, some deg= ree of aspiration to
>> >>>>> scale that is appropr= iate for the lifespan of the architecture -
>> >>>>>= ; you don't have to know what it is, but by saying that an arbitrary
>= ;> >>>>> number is "too far", you're creating - even if i= t isn't
>>intentional
>> >>>>> - a limit t= hat influences decisions that have lasting impacts
>> >>>= >> regarding scale-out, failure mitigation, elasticity, address
&g= t;> >>>>> space... all kinds of things. That is a problem= I'm not
>> >>>>> particularly eager to deal with.<= br>>> >>>>>
>> >>>>>
>&g= t; >>>>>
>> >>>>>
>> >&g= t;>>> ________________________________________
>> >>= ;>>>
>> >>>>>
>> >>>>= > From: Joel Halpern Direct [jmh.direct@joelhalpern.com] Sent:
>> >>>>> T= hursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;
>> = >>>>> huang@sce.car= leton.ca; sfc@ietf.org Subject: Re:= [sfc] Service
>> >>>>> Chains, Paths, and Load Bal= ancers
>> >>>>>
>> >>>>> Ia= n, I don't think you disagree with me at all in this regard. I
>>a= m
>> >>>>> not requesting the the architecture or t= he solution prohibit
>> >>>>> deployments in the sp= ecific fashion. I am objecting to Huang's
>> >>>>> = reading of my note as saying that such deployments are required
>>= >>>>> they by the archtiecture.
>> >>>>= ;>
>> >>>>> As I have said repeatedly, I am not = trying to prohibit such
>> >>>>> things. Whether th= ey are a good idea or not depends upon many
>> >>>>>= ; factors outside of the scope of the WG. I happen to think that
>>= ;they
>> >>>>> are usually a bad idea.
>> = >>>>>
>> >>>>> But the archtiecture = si carefully avoiding attempting to know what
>> >>>>&= gt; is and is not eployable.
>> >>>>>
>> &= gt;>>>> Yours, Joel
>> >>>>>
>>= ; >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:
>> &g= t;>>>>> I disagree.
>> >>>>>>
= >> >>>>>> We routinely have stateful devices that m= anage tens of millions
>> >>>>>> of
>> = >>>>> concurrent flows in both access network and data cente= r
>> >>>>> environments today. You can't seriously = believe that in the
>> >>>>> Cloud/IPv6/Mobility/We= b2.0/IoT world of tomorrow you are only
>> going
>> >&= gt;>>> to have small numbers of service chains with equally small = numbers
>> >>>>> of active service paths?
>&g= t; >>>>>>
>> >>>>>> Your sound= s too much like "no one will ever need more than 64K"
>> >>&= gt;>>> for
>> >>>>> comfort.
>> &= gt;>>>>>
>> >>>>>>
>> &g= t;>>>>> ________________________________________ From: sfc>> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern
>> >&g= t;>>> [jmh@joelhalpern.com<= /a>]
>> >>>>>> Sent: Thursday, July 10, 2014 4:4= 6 PM To: huang@sce.carleton.ca= ;
>> >>>>>> sfc@= ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load
>>= >>>>>> Balancers
>> >>>>>>>> >>>>>> No, it will mean that if someone tries t= o deploy the archtieture
>> >>>>>> particularly = badly, they will exceed the limits of their
>> >>>>>= ;> devices. The architecture does not require such absurd use of
>= > >>>>>> service paths. Since I can not figure out how= to write
>> >>>>>> architectural words to prohi= bit it, the architecture does permit
>> >>>>>> s= uch abuse.
>> >>>>>>
>> >>>>= ;>> Please do not read my saying that the archtiecture permits
>= ;> >>>>>> something as saying it is either deisred or = required by the work.
>> >>>>>> It isn't.
>= ;> >>>>>>
>> >>>>>> Yours, = Joel
>> >>>>>>
>> >>>>>&= gt; On 7/10/14, 4:36 PM, Changcheng Huang wrote:
>> >>>&g= t;>>> If you need to support 100 service chains, it will mean
&= gt;> >>>>>>> 16,000,000 paths. That is larger than = the routing table of a
>> >>>>>>> core router= .
>> >>>>>>>
>> >>>>>= >> Chang
>> >>>>>>>
>> >>= ;>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:
>= ;> >>>>>>>> The architecture allows a range of d= eployments, from 1
>> >>>>>>>> service pat= h to 160000 service paths. I would hope that
>> >>>>&g= t;>>> operators are prepared for the complexities if they choose t= o
>> >>>>>>>> avoid any use of local load = balancing and in stead provision
>> >>>>>>>&g= t; 160,000 service paths.
>> >>>>>>>>
&= gt;> >>>>>>>> Yours, Joel
>> >>&g= t;>>>>>
>> >>>>>>>> On 7/10= /14, 4:06 PM, NAPIERALA, MARIA H wrote:
>> >>>>>>= ;>>> Paul,
>> >>>>>>>>>
>= ;> >>>>>>>>> How many path identifiers there = will be for a 4 hop service
>> >>>>>>>>>= ; chain with 20 instances at each hop?
>> >>>>>>= >>>
>> >>>>>>>>> Maria
>= > >>>>>>>>>
>> >>>>>&= gt;>>> *From:*sfc [mailto:= sfc-bounces@ietf.org] *On Behalf Of
>> >>>>>>= ;>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03
&= gt;> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;
>> >= >>>>>>>> mohamed.boucadair@orange.com; sfc= @ietf.org;
>> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Servic= e Chains,
>> >>>>>>>>> Paths, and Load = Balancers
>> >>>>>>>>>
>> >= >>>>>>>> Lucy,
>> >>>>>>= >>>
>> >>>>>>>>> Overall I con= cur, as you say: a path ID drives the
>> >>>>>>&= gt;>> forwarding. I=C2=B9d
>> >>>>> make
&= gt;> >>>>>>>>> the minor change: the path ide= ntifier can be used to derive
>> >>>>>>>>&= gt; the needed forwarding and associated transport.
>> >>>= ;>>>>>>
>> >>>>>>>>> = It is _not_ the transport, but rather is used to simply
>> >>= ;>>>>>>> identify the service path (or graph) that pac= kets must
>> >>>>>>>>> traverse. By hav= ing a path identifier, the exact
>> >>>>>>>&g= t;> indirection that people seem to be asking for on this
>> &g= t;>>>>>>>> thread can be simply be implemented. The= path identifier
>> >>>>>>>>> provides = nothing more than a lookup, that lookup can result
>> >>>= >>>>>> in a one or more (equal or weighted) transport nex= t
>> >>>>>>>>> hop(s).
>> >= >>>>>>>>
>> >>>>>>>&g= t;> Paul
>> >>>>>>>>>
>> &g= t;>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong<= br>>> >>>>>>>>> <lucy.yong@huawei.com <= ;mailto:lucy.yong@huawei.com>>
>> >>>>>&g= t;>>> wrote:
>> >>>>>>>>>
&= gt;> >>>>>>>>>
>> >>>>&g= t;>>>>
>> >>>>>>>>> Agree. = The arch. doc should not mandate only use of the
>> >>>&g= t;>>>>> service path identifier to drive the forwarding acti= ons.
>> >>>>>>>>>
>> >>&= gt;>>>>>> Lucy
>> >>>>>>>&g= t;>
>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf=
>> >>>>>>>>> Of*mohamed.boucadair@orange.com
>> &= gt;>>>>>>>> <mailto:mohamed.boucadair@orange.com> *Sent:*Thursday,>> July
>> >>>>>>>>> 10, 2014 2= :06 AM *To:*mikebianc@aol.com
&= gt;> >>>>>>>>> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com
>> >>>>>>>>= ;> <mailto:jmh@joelhalpern.com= >;sfc@ietf.org
>> >&= gt;>>>>>>> <mailto:= sfc@ietf.org> *Subject:*Re: [sfc] Service Chains,
>> >&g= t;>>>>>>> Paths, and Load Balancers
>> >&g= t;>>>>>>>
>> >>>>>>>>= > Re-,
>> >>>>>>>>>
>> >= >>>>>>>> The merged draft calls out explicitly a se= rvice path
>> >>>>>>>>> identifier. I o= bject to use that identifier to derive
>> >>>>>>= >>> forwarding actions.
>> >>>>>>>&g= t;>
>> >>>>>>>>> Requiring a SFC sys= tem to have the full knowledge of every
>> >>>>> av= ailable SFC
>> >>>>>>>>> forwarding pat= hs within an SFC-enabled domain is not
>> >>>>> req= uired/justified
>> >>>>>>>>> nor possib= le in various deployment contexts.
>> >>>>>>>= >>
>> >>>>>>>>> SFC forwarding ac= tions should rely on the piece of
>> >>>>>>>&= gt;> information
>> >>>>> that will
>> = >>>>>>>>> be present in all deployments: that is= the one required to
>> >>>>>>>>> struc= ture a service chain. How that information is used to
>> >>&= gt;>>>>>> infer forwarding
>> >>>>&g= t; actions
>> >>>>>>>>> is a solution-o= riented discussion.
>> >>>>>>>>>
>= ;> >>>>>>>>> Cheers,
>> >>>= >>>>>>
>> >>>>>>>>> M= ed
>> >>>>>>>>>
>> >>>= ;>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part
>> >>>>&= gt; de*mikebianc@aol.com
>= ;> >>>>>>>>> <mailto:mikebianc@aol.com> *Envoy=C3=A9 :*mercredi 9 juillet=
>> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com
>> >= >>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@iet= f.org
>> >>>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service = Chains,
>> >>>>>>>>> Paths, and Load Ba= lancers
>> >>>>>>>>>
>> >&g= t;>>>>>>> Is anyone still questioning the difference b= etween SF Chain
>> >>>>>>>>> and SF
= >> >>>>> Path?
>> >>>>>>>= ;>> Other than clarifying the definition so that it's clear to
>= ;> >>>>> those not
>> >>>>>>&g= t;>> familiar with the draft, it seems that everyone agrees on
>= ;> >>>>>>>>> these terms.
>> >>= ;>>>>>>>
>> >>>>>>>>&= gt; To me, the one point that is still unclear is whether it is
>>= >>>>>>>>> the intent of this draft to ultimatel= y specify what the ID
>> >>>>>>>>> of t= he SFC Header
>> >>>>> should
>> >>&= gt;>>>>>> reference (the chain or the path), or if this d= raft simply
>> >>>>>>>>> intends to lea= ve that ambiguous, allowing other drafts to
>> >>>>>= ;>>>> dictate the mechanisms for forwarding based on chain or>> >>>>>>>>> path and the choice of chai= n or
>> >>>>> path to
>> >>>>&= gt;>>>> be negotiated in the control-plane.
>> >>= ;>>>>>>>
>> >>>>>>>>&= gt; If the latter (ambiguous), then the draft would have
>> >&g= t;>>>>>>> require that both SFP and SFC be supported (= or make one
>> >>>>>>>>> required and t= he other optional) to avoid some vendors only
>> >>>>&= gt;>>>> supporting SFP and others only supporting SFC.
>&= gt; >>>>>>>>>
>> >>>>>&g= t;>>>
>> >>>>>
>>
>>>= ;>>>>----------------------------------------------------------= ----------
>>>>>>>--
>> >>>>&g= t;--
>> >>>>>
>> >>>>>
&= gt;> >>>>>
>> >>>>>>>
&g= t;> >>>>>>>>> *From:*jmh@joelhalpern.com<jmh@joelhalpern.com
>> >>>>>>>&g= t;> <mai= lto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>>
>> >&= gt;>>>>>>> *To:*sfc@ie= tf.org<sfc@ietf.org
>&g= t; >>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org>> *Sent:*Tuesd= ay, July
>> >>>>>>>>> 8, 2014 *Subject:= *[sfc] Service Chains, Paths, and Load
>> >>>>>>= >>> Balancers
>> >>>>>>>>>
= >> >>>>>>>>> I have been trying to figure = out how to clearly answer a
>> >>>>>>>>>= ; number of comments that have been made about the proposed
>> >= ;>>>>>>>> merged archtiecture draft. Assuming we ca= n get working
>> >>>>>>>>> group agreem= ent on the intent, we will work to improve the
>> >>>>= >>>>> wording so that readers who have not participated in t= he WG
>> >>>>>>>>> discussion will unde= rstnd it the way the
>> >>>>> working
>> &= gt;>>>>>>>> group intends.
>> >>>= >>>>>>
>> >>>>>>>>> B= ut what do we intend? I will try to explain my personal
>> >>= ;>>>>>>> view, and see if that helps.
>> >= >>>>>>>>
>> >>>>>>>&g= t;> In this regard, it is important to keep in mind that what
>>= ; >>>>>>>>> we are defining is the data plane ar= chitecture. We are not
>> >>>>>>>>> att= empting to define the architecture for the entire
>> >>>&= gt;>>>>> solution for service chaining. That would encompass=
>> >>>>>>>>> OSS/BSS, various control = and policy functions, virtual
>> >>>>>>>>&= gt; machine and image management, and many other aspects.
>> >&= gt;>>>>>>>
>> >>>>>>>>= ;> As a result there are many things which clearly need to
>> &= gt;>>>>>>>> exist in the larger system, but which a= re dealt with above
>> >>>>>>>>> where = we are
>> >>>>> functioning,
>> >>&g= t;>>>>>> and are not directly required by the work we are= doing.
>> >>>>>>>>>
>> >&g= t;>>>>>>> In order to get to service chain vs service = path, as I
>> >>>>>>>>> understand
&= gt;> >>>>> them,
>> >>>>>>>= >> I need to first discuss load balancing. There are at least
>= > >>>>>>>>> three different ways that load ba= lancing can and will
>> >>>>>>>>> inter= act with service chaining. There probably are more.
>> >>>= ;>>>>>> The point of the archtiecture is to permit all of= these,
>> >>>>>>>>> but not to mandate= that any particular kind
>> >>>>> be used
>&= gt; >>>>>>>>> in any solution.
>> >&= gt;>>>>>>>
>> >>>>>>>>= ;> 1) Load balancing as a service provided to the end user.
>> = >>>>>>>>> This is a service function. It receive= s user packets, and
>> >>>>>>>>> modifi= es them (or
>> >>>>> marks
>> >>>= >>>>>> them, or ...) so as to choose an end user service = instance
>> >>>>>>>>> to receive the us= ers packet. This is an important service
>> >>>>>&g= t;>>> function to be able to include in service chaining. It's
= >> >>>>>>>>> behavior may affect requireme= nts on how service chaining is
>> >>>>>>>>= > done. But it has very little impact on the archtiecture.
>> &= gt;>>>>>>>> From an architectural pe3rspective it i= s simply a
>> >>>>> service
>> >>>= ;>>>>>> function which may modify the underlying packet.<= br>>> >>>>>>>>>
>> >>>&g= t;>>>>> 2) There is internal load balancing. That is, one ca= n have
>> >>>>>>>>> what
>> &g= t;>>>> appears
>> >>>>>>>>>= to the service chaining architecture as a single point of
>> >= >>>>>>>> contact
>> >>>>> f= or a
>> >>>>>>>>> specific service func= tion, but is actually delivered by a
>> >>>>> colle= ction of
>> >>>>>>>>> virtual or physic= al machines, possibly including one or
>> >>>>>>= >>> several load balancers (for example using VRRP-like
>>= ; >>>>>>>>> techniques to share a MAC address.) = mostly, this is
>> >>>>>>>>> invisible = to the service chaining data plane mechanisms. It
>> >>>&= gt;>>>>> is likely that it is visible to various control mec= hanisms,
>> >>>>>>>>> such as those res= ponsible for scale-in, scale-out, and vm
>> >>>>>&g= t;>>> instantiation. The architectural impact of permitting this>> >>>>>>>>> is largely that we need to = be careful that our terminology
>> >>>>>>>>= ;> does not lead
>> >>>>> readers to
>>= >>>>>>>>> think we are prohibiting it.
>&= gt; >>>>>>>>>
>> >>>>>&g= t;>>> 3) There can also be load balancing done by selecting
>= ;> >>>>>>>>> packet paths for the service cha= ining that direct traffic
>> >>>>>>>>> = to different places. We would not want to require that a
>> >&g= t;>>>>>>> given service function appear at only one pl= ace in the
>> >>>>>>>>> network.
>= ;> >>>>>>>>>
>> >>>>>= >>>> It is of course the case that these may be combined. I ten= d
>> >>>>>>>>> to
>> >>&= gt;>> refer to
>> >>>>>>>>> the c= ollection of entities that appear to service chaining
>> >>&= gt;>>>>>> as a single point as a cluster. Not because clu= ster is a
>> >>>>>>>>> good term. But b= ecause I do not have another one. Thus, the
>> >>>>>= ;>>>> point of type 3 load balancing
>> >>>&g= t;> is to
>> >>>>>>>>> direct differ= ent subsets of traffic to different singular
>> >>>>&g= t;>>>> or clustered service functions in different places in th= e
>> >>>>>>>>> network.
>> >= ;>>>>>>>>
>> >>>>>>>&= gt;> Now with that said, what do I mean when I talk about
>> &g= t;>>>>>>>> service chain and service path/ Service = chain is a sequence
>> >>>>>>>>> of log= ical functions to be applied to a subset of packets.
>> >>&g= t;>>>>>> It is equivalent of saying that some subset of t= raffic is
>> >>>>>>>>> to get DPI, char= ging, content inspection, and firewall
>> >>>>>>= >>> while a different subset is to go directly to the cache
>= ;> >>>>> without
>> >>>>>>>= >> visiting any other service functions.
>> >>>>= >>>>>
>> >>>>>>>>> That = is not enough information to direct the packets. A
>> >>>= >>>>>> service path is, in some fashion, a sequence of lo= cations
>> >>>>>>>>> in the network. Th= ose locations will be singular or
>> >>>>>>>&= gt;> clustered service function delivery locations. They may be
>&= gt; >>>>>>>>> addressed by IP address. They may = be addressed as ports on
>> >>>>>>>>> a= n SFF. There are many different ways that the locations
>> >>= ;>>>>>>> may be known to the service chaining infrastr= ucture and the
>> >>>>>>>>> transport.<= br>>> >>>>>>>>>
>> >>>&g= t;>>>>>> From the point of view of the work of the SFC gr= oup, we
>> >>>>>>>>>> need to be
= >> >>>>>>>>> able to talk about the high l= evel abstraction, the service
>> >>>>>>>>&= gt; chain, which drives the forwarding. And we need to talk
>> >= ;>>>>>>>> about the actual data path packets will t= ake in the
>> >>>>>>>>> network.
>= ;> >>>>>>>>>
>> >>>>>= >>>> Several of the comments have said "but the whole path may<= br>>> >>>>>>>>> not be known at the front.= " This architecture deals with
>> >>>>>>>>= > that issue in two ways. First, as noted in item (2) on load
>>= ; >>>>>>>>> balancers above, there can be decisi= ons and behaviors which
>> >>>>>>>>> ar= e invisible to the service chaining mechanisms (in much
>> >>= ;>>>>>>> the same way that bridging within a LAN is la= rgely
>> >>>>>>>>> invisible to routing= between LANs.) The other provision we
>> >>>>>>= >>> make is
>> >>>>> that
>> >= >>>>>>>> reclassification can be done in mid-chain = when necessary.
>> >>>>>>>>> That will = direct packets to a new chain. Based on
>> >>>>>>= ;>>> information available at the re-classification point.
>= > >>>>>>>>>
>> >>>>>&= gt;>>> I hope that this helps explain what we are after. If it
= >> >>>>>>>>> does, and if the intent is ac= ceptable to the working group,
>> >>>>>>>>= > we can figure out what additional words are needed to
>> >= >>>>>>>> convey this. If the working group disagree= with the intent,
>> >>>>>>>>> then we = will of course adjust to match the working group
>> >>>&g= t;>>>>> agreements. If this is still unclear, I am not sure = what to
>> >>>>>>>>> try next.
>&= gt; >>>>>>>>>
>> >>>>>&g= t;>>> Yours, Joel
>> >>>>>>>>>=
>> >>>>>>>>> _________________________= ______________________ sfc
>> mailing
>> >>>>= >>>>> list sfc@ietf.org = <mailto:sfc@ietf.org>
>>= >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>> = >>>>>>>>>
>> >>>>>>&g= t;>> _______________________________________________ sfc
>> = mailing
>> >>>>>>>>> list sfc@ietf.org <mai= lto:sfc@ietf.org>
>> >>>>>>>>> <= a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/m= ailman/listinfo/sfc
>> >>>>>>>>>>> >>>>>>>>
>> >>>>>= >>> _______________________________________________ sfc
>>= ; mailing
>> >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >= >>>>>>>
>> >>>>>>>
&g= t;> >>>>>>> _______________________________________= ________ sfc
>> mailing
>> >>>>>>> l= ist sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >>>>>>>
>> >>>>>= ;>
>> >>>>>> ________________________________= _______________ sfc mailing
>> list
>> >>>>&g= t;> 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
>> >>&g= t;> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sf= c
>> >>>>
>> >>>> ___________= ____________________________________ sfc mailing
>> list
>&g= t; >>>> sfc@ietf.org https://www.ietf.org/mailma= n/listinfo/sfc
>> >>>>
>> >>>>> >>
>> >> ___________________________________= ____________
>> >> sfc mailing list
>> >> sfc@ietf.org
>> >> https://www.ietf.org/mailman= /listinfo/sfc
>> >>
>> >
>> >___= ____________________________________________
>> >sfc mailing li= st
>> >sfc@ietf.org
>= > >https://www.= ietf.org/mailman/listinfo/sfc
>>
>> ________________= _______________________________
>> sfc mailing list
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo= /sfc

_______________________________________________
sfc mail= ing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc

------=_Part_3128_816799649.1405095908889-- From nobody Fri Jul 11 09:26: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 A03381B290B for ; Fri, 11 Jul 2014 09:26:36 -0700 (PDT) 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_29=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 agY6hLpfCxQs for ; Fri, 11 Jul 2014 09:26:33 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF86F1B2B54 for ; Fri, 11 Jul 2014 09:26:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 91C79240380; Fri, 11 Jul 2014 09:26:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 73020240183; Fri, 11 Jul 2014 09:26:31 -0700 (PDT) Message-ID: <53C01036.6020106@joelhalpern.com> Date: Fri, 11 Jul 2014 12:26:30 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , jguichar@cisco.com, mn1921@att.com References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1124016040.3120.1405095661844.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1124016040.3120.1405095661844.JavaMail.tomcat@mgs-aam01.mail.aol.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5gqcplXinA_xHuVt8Wa9SsHURV8 Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:26:36 -0000 The draft does not mandate that singular SFF for 120 SFs. If you want only one Service Path, then it implies that there is one SFF. The relaxation I have proposed (which arguably was already permitted, but was either not clear or not present) is to allow there to be several, with carefully limited requirements on preceding SFFs, while permitting more powerful SFF behavior. The way the text was written before, you could have achieved the same goal with a logically singular physically distributed SFF. But that would have been complicated, and it was certainly hard to see that from the text. So if the behavior I described is acceptable, we can relax that far. Getting rid of the indirection of the SFP would actually cost us capability, which is why I keep harping on keeping it. Yours, Joel On 7/11/14, 12:21 PM, mikebianc@aol.com wrote: > but it still sounds like there is a single SFF entity tied to the 20 > instances through which ALL traffic destined for any of the 20 instances > MUST traverse. While this should surely not be prohibited, it shouldn't > be mandated. > > > > > > ------------------------------------------------------------------------ > *From: *jguichar@cisco.com > *To: *mikebianc@aol.com,mn1921@att.com > *cc: *sfc@ietf.org > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > No they do not have to be physically connected but they are hidden > behind an SFF in this case but do not have to be. > > From: "mikebianc@aol.com " > > Date: Friday, July 11, 2014 at 11:44 AM > To: Jim Guichard >, > "mn1921@att.com " > > Cc: "sfc@ietf.org " > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > When you say "20 instances of the SF2 SF" are "Connected to that SFF" do > you mean physically? I had always just assumed that if I had 20 > instances of a SF, that they would be diverse. Even if within the same > datacenter, they would be not near each other. It also seems like you > are saying that there is only a single SFF for SF2 and that your traffic > path requires traversing SF2 as a separate hop from the SF2 instance. > Ideally, the traffic would flow from SF1 instance to SF2 instance over > the best path without the need for an intermediary hop. > > *In my statements above, I assuming that each SF Instance is SFC aware > to simplify the text. > > > > > > ------------------------------------------------------------------------ > *From: *jguichar@cisco.com > > > *To: *mikebianc@aol.com >,mn1921@att.com > > > *cc: *sfc@ietf.org > > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Hi Mike, > > There still seems to be some confusion around this topic so let me try > to provide a more detailed explanation as to how I believe this should > work and why what I explained earlier is in fact a path identifier and > not a chain identifier. Note that my explanation assumes that the SFC > encapsulation will contain a path identifier as described within our > charter which says “3. Generic SFC encapsulation: This document will > describe a single service-level data plane encapsulation format that > *indicates* the sequence of service functions that make up the Service > Function Chain; *specifies* the Service Function Path”. The wording here > is very important and shows that the intent is that the sequence of SF’s > be indicated within the SFC encapsulation e.g. not carried – this is not > source routing, and specifies the SFP, hence the path identifier. > > For my example let’s assume the following SFC: > > (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let’s call it “SFC-1” > > It is possible that each of those SF’s be directly addressable (i.e. > provide SFF functionality) or reachable through some other network > device that provides the forwarding (i.e. external, but connected SFF). > > In this example, SF1 and SF3 provide direct SFF functionality and SF2 > relies on a connected switch to provide the needed SFF functionality. > Connected to that SFF are 20 instances of the SF2 SF. In this case you > have exactly 3 network locators from which to choose in order to reach > the required SF’s; let’s call them SF1-loc1, SF2-loc2, and SF3-loc3. > > When an operator instantiates SFC-1 into the network, specific locators > are selected to construct the path, and a path identifier is allocated. > In this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> > SF2-loc2 -> SF3-loc3 and it has a path identifier “100”. This > information is distributed to the relevant network devices basically > saying “if you receive an SFC encapsulated packet with path identifier > “100” then use the path identifier and index to perform a lookup in a > data structure that will tell you which SF to forward the traffic to and > how to get there”. > > So traffic flows through the SFP with path identifier “100”, via a > network transport (the path identifier is encapsulated). It reaches > SF1-loc1 which uses the path identifier to determine that it is in fact > the SF that should be applied. It applies SF1 SF and then uses the path > identifier to determine that SF2 is the next service and its reachable > at next-hop SF2-loc2. The needed transport (for example VXLAN) is > imposed for network forwarding. Traffic reaches SF2-loc2. It uses the > path identifier to determine that SF2 should be applied. It uses a local > decision to determine which of the 20 instances of SF2 it should forward > the traffic to. It forwards the traffic to the selected instance. SF2 is > applied and then another lookup occurs on the path identifier, which > results in the needed transport being imposed to reach the next service > hop SF3-loc3 .. And so on and so forth. > > So with this example we have exactly 1 SFP. > > Jim (as a WG participant, not a chair). > > > From: "mikebianc@aol.com " > > > Date: Thursday, July 10, 2014 at 4:46 PM > To: Jim Guichard >, > "mn1921@att.com " > > Cc: "sfc@ietf.org " > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > Jim, > > Technically, wouldn't this be a Chain Identifier if the next instance is > chosen at each hop? In this case, there wouldn't be any Path Identifier > at all. > > But it is the difference between a classifier needing to track the > health, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 > instances tracking 20 SFIs of the next-hop for the chains of which they > are members vs each SFF in the entire domain tracking all 80 SFIs vs > something else. > > > > > ------------------------------------------------------------------------ > *From: *jguichar@cisco.com > > > *To: *NAPIERALA, MARIA H> > *cc: *Paul Quinn (paulq)>,Lucy > yong >,jmh@joelhalpern.com > >,mohamed.boucadair@orange.com > >,sfc@ietf.org > >,mikebianc@aol.com > > > *Sent: *Thursday, July 10, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > 1 assuming load is distributed among the 20 instances at each service hop. > > Sent from my iPhone > > On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: > >> Paul, >> >> How many path identifiers there will be for a 4 hop service chain with >> 20 instances at each hop? >> >> Maria >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq) >> *Sent:* Thursday, July 10, 2014 3:03 PM >> *To:* Lucy yong >> *Cc:* jmh@joelhalpern.com ; >> mohamed.boucadair@orange.com ; >> sfc@ietf.org ; mikebianc@aol.com >> >> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Lucy, >> >> Overall I concur, as you say: a path ID drives the forwarding. I’d >> make the minor change: the path identifier can be used to derive the >> needed forwarding and associated transport. >> >> It is _not_ the transport, but rather is used to simply identify the >> service path (or graph) that packets must traverse. By having a path >> identifier, the exact indirection that people seem to be asking for on >> this thread can be simply be implemented. The path identifier provides >> nothing more than a lookup, that lookup can result in a one or more >> (equal or weighted) transport next hop(s). >> >> Paul >> >> On Jul 10, 2014, at 11:04 AM, Lucy yong > > wrote: >> >> >> >> Agree. The arch. doc should not mandate only use of the service path >> identifier to drive the forwarding actions. >> >> Lucy >> >> *From:*sfc >> [mailto:sfc-bounces@ietf.org]*On Behalf >> Of*mohamed.boucadair@orange.com >> >> *Sent:*Thursday, July 10, 2014 2:06 AM >> *To:*mikebianc@aol.com >> ;jmh@joelhalpern.com >> ;sfc@ietf.org >> >> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Re-, >> >> The merged draft calls out explicitly a service path identifier. I >> object to use that identifier to derive forwarding actions. >> >> Requiring a SFC system to have the full knowledge of every available >> SFC forwarding paths within an SFC-enabled domain is not >> required/justified nor possible in various deployment contexts. >> >> SFC forwarding actions should rely on the piece of information that >> will be present in all deployments: that is the one required to >> structure a service chain. How that information is used to infer >> forwarding actions is a solution-oriented discussion. >> >> Cheers, >> >> Med >> >> *De :*sfc >> [mailto:sfc-bounces@ietf.org]*De la part >> de*mikebianc@aol.com >> *Envoyé :*mercredi 9 juillet 2014 22:03 >> *À :*jmh@joelhalpern.com >> ;sfc@ietf.org >> >> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers >> >> Is anyone still questioning the difference between SF Chain and SF >> Path? Other than clarifying the definition so that it's clear to those >> not familiar with the draft, it seems that everyone agrees on these terms. >> >> To me, the one point that is still unclear is whether it is the intent >> of this draft to ultimately specify what the ID of the SFC Header >> should reference (the chain or the path), or if this draft simply >> intends to leave that ambiguous, allowing other drafts to dictate the >> mechanisms for forwarding based on chain or path and the choice of >> chain or path to be negotiated in the control-plane. >> >> If the latter (ambiguous), then the draft would have require that both >> SFP and SFC be supported (or make one required and the other optional) >> to avoid some vendors only supporting SFP and others only supporting SFC. >> >> ------------------------------------------------------------------------ >> >> *From:*jmh@joelhalpern.com >> > > >> *To:*sfc@ietf.org >> > >> *Sent:*Tuesday, July 8, 2014 >> *Subject:*[sfc] Service Chains, Paths, and Load Balancers >> >> I have been trying to figure out how to clearly answer a number of >> comments that have been made about the proposed merged archtiecture >> draft. Assuming we can get working group agreement on the intent, we >> will work to improve the wording so that readers who have not >> participated in the WG discussion will understnd it the way the working >> group intends. >> >> But what do we intend? I will try to explain my personal view, and see >> if that helps. >> >> In this regard, it is important to keep in mind that what we are >> defining is the data plane architecture. We are not attempting to >> define the architecture for the entire solution for service chaining. >> That would encompass OSS/BSS, various control and policy functions, >> virtual machine and image management, and many other aspects. >> >> As a result there are many things which clearly need to exist in the >> larger system, but which are dealt with above where we are functioning, >> and are not directly required by the work we are doing. >> >> In order to get to service chain vs service path, as I understand them, >> I need to first discuss load balancing. There are at least three >> different ways that load balancing can and will interact with service >> chaining. There probably are more. The point of the archtiecture is to >> permit all of these, but not to mandate that any particular kind be used >> in any solution. >> >> 1) Load balancing as a service provided to the end user. This is a >> service function. It receives user packets, and modifies them (or marks >> them, or ...) so as to choose an end user service instance to receive >> the users packet. This is an important service function to be able to >> include in service chaining. It's behavior may affect requirements on >> how service chaining is done. But it has very little impact on the >> archtiecture. From an architectural pe3rspective it is simply a service >> function which may modify the underlying packet. >> >> 2) There is internal load balancing. That is, one can have what appears >> to the service chaining architecture as a single point of contact for a >> specific service function, but is actually delivered by a collection of >> virtual or physical machines, possibly including one or several load >> balancers (for example using VRRP-like techniques to share a MAC >> address.) mostly, this is invisible to the service chaining data plane >> mechanisms. It is likely that it is visible to various control >> mechanisms, such as those responsible for scale-in, scale-out, and vm >> instantiation. The architectural impact of permitting this is largely >> that we need to be careful that our terminology does not lead readers to >> think we are prohibiting it. >> >> 3) There can also be load balancing done by selecting packet paths for >> the service chaining that direct traffic to different places. We would >> not want to require that a given service function appear at only one >> place in the network. >> >> It is of course the case that these may be combined. I tend to refer to >> the collection of entities that appear to service chaining as a single >> point as a cluster. Not because cluster is a good term. But because I >> do not have another one. Thus, the point of type 3 load balancing is to >> direct different subsets of traffic to different singular or clustered >> service functions in different places in the network. >> >> Now with that said, what do I mean when I talk about service chain and >> service path/ Service chain is a sequence of logical functions to be >> applied to a subset of packets. It is equivalent of saying that some >> subset of traffic is to get DPI, charging, content inspection, and >> firewall while a different subset is to go directly to the cache without >> visiting any other service functions. >> >> That is not enough information to direct the packets. A service path >> is, in some fashion, a sequence of locations in the network. Those >> locations will be singular or clustered service function delivery >> locations. They may be addressed by IP address. They may be addressed >> as ports on an SFF. There are many different ways that the locations >> may be known to the service chaining infrastructure and the transport. >> >> >From the point of view of the work of the SFC group, we need to be able >> to talk about the high level abstraction, the service chain, which >> drives the forwarding. And we need to talk about the actual data path >> packets will take in the network. >> >> Several of the comments have said "but the whole path may not be known >> at the front." This architecture deals with that issue in two ways. >> First, as noted in item (2) on load balancers above, there can be >> decisions and behaviors which are invisible to the service chaining >> mechanisms (in much the same way that bridging within a LAN is largely >> invisible to routing between LANs.) The other provision we make is that >> reclassification can be done in mid-chain when necessary. That will >> direct packets to a new chain. Based on information available at the >> re-classification point. >> >> I hope that this helps explain what we are after. If it does, and if >> the intent is acceptable to the working group, we can figure out what >> additional words are needed to convey this. >> If the working group disagree with the intent, then we will of course >> adjust to match the working group agreements. >> If this is still unclear, I am not sure what to try next. >> >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Jul 11 09: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 C66321B2B5F for ; Fri, 11 Jul 2014 09:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85N5gqa7jnQq for ; Fri, 11 Jul 2014 09:27:00 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685BB1B2B5D for ; Fri, 11 Jul 2014 09:27:00 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 45010c35.2abfecc2d940.6752344.00-2425.18695567.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:27:00 +0000 (UTC) X-MXL-Hash: 53c01054634e47bc-5d513c7a746d806a7f8e5c7c7c5fd678a463e500 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 15010c35.0.6752324.00-2070.18695487.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:26:58 +0000 (UTC) X-MXL-Hash: 53c01052737bc346-446b87d850d9535ced4eb3b4fc8efbcbe3f86333 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGQv5H019652; Fri, 11 Jul 2014 12:26:57 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGQlAW019483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:26:51 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:26:27 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:26:27 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA///Q1oCAAEKp8P//yI4AgAA9hfA= Date: Fri, 11 Jul 2014 16:26:26 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH] X-AnalysisOut: [86SAAAA:8 a=oaNnyxNoOycKo6k7kfcA:9 a=QEXdDO2ut3YA:10 a=Hz7] X-AnalysisOut: [IrDYlS0cA:10 a=JfD0Fch1gWkA:10 a=oAXR_kdF8uMA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037Qrwtg] X-AnalysisOut: [A:10 a=KJ7A6KuyOK8v9c22:21 a=DJVxE61PD--YYHQ_:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fXq8SbVQW5FUrW2lRM4gV5a3w7k Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:27:13 -0000 SmltLA0KDQo+IEkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQo+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250 YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGENCg0KTGV0J3Mg cGFyayBpdCBmb3Igbm93Lg0KDQo+IGNoYWluLCBsZXTigJlzIHNheSBTMSAtPlMyLT4gUzMsIHlv dSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5DQo+IHRoZSBzcGVjaWZpYyBu ZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBT RlAuDQoNCllvdSBhcmUgdGFsa2luZyBhYm91dCB0cmFmZmljIGVuZ2luZWVyaW5nIG9mIHBhdGhz IHRoYXQgYSBzZXJ2aWNlIGNoYWluIGNhbiB0YWtlLiANClRoaXMgc3VyZWx5IGNvdWxkIGJlIGRv bmUvYWxsb3dlZCBidXQgdGhpcyBjYW5ub3QgYmUgYSByZXF1aXJlbWVudCBmb3IgYWxsIHRyYWZm aWMuIA0KDQo+IEhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBh cmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQgKEkNCj4gd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQg YnV0IHlvdSBkb27igJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91DQo+IGNvdWxkIHNp bXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBwb2ludCB0byBhIGdpdmVu IFNGQyBhbmQNCg0KDQpJZiBhbnl0aGluZywgSSBjb3VsZCBpbWFnZSBhIHNlcnZpY2UgKmNoYWlu KiAobm90IHBhdGgpIGlkZW50aWZpZXIgcG9pbnRpbmcgdG8gYSBzcGVjaWZpYyBTRkMgc3RydWN0 dXJlLg0KDQo+IHRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdvcmsuIEF0 IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGENCj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZD IG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWluIHRoZQ0KPiBuZXh0LWhvcHMg YXZhaWxhYmxlIGZvciBlYWNoIG9mIHRoZSBTRuKAmXMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91 IGxlYXJuDQo+IHRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRo ZW0gZG93biBmcm9tIGEgY2VudHJhbGl6ZWQNCj4gY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0g dGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0KPiBzb21lIHByb3Rv Y29sIGV4Y2hhbmdlLCB3aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVj dCB0bw0KPiBzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3Rh bmNlcyBhcmUgY2hvc2VuIGEgcHJpb3JpDQo+IGFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2Nl cHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvDQo+IGRvDQo+IHNvLg0K DQpBZ3JlZSwgZ2l2ZW4gdGhlIGFib3ZlIGNvbW1lbnQgYWJvdXQgKmNoYWluKiB2cyAqcGF0aCog aWRlbnRpZmllci4NCiANCj4gTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1h a2UgdGhpcyBjbGVhcjoNCj4gDQo+IEkgZGVmaW5lIGFuIFNGQyAobGV04oCZcyByZWZlciB0byBp dCBhcyBTRkMtMSkgUzEtPlMyLT5TMy4gRm9yIGFyZ3VtZW50cw0KPiBzYWtlIGxldOKAmXMgc2F5 IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3Bl Y2lmeQ0KPiBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29t YmluYXRpb24gdGhlcmVvZikuIEkNCj4gYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg 4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0+UzItPlMzDQoNCkFnYWluLCBm b3IgbWUgdGhpcyBpcyAgKmNoYWluKiBpZGVudGlmaWVyLCBub3QgdGhlICBwYXRoIGlkZW50aWZp ZXIuDQoNCj4gYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUg U0ZGIGRhdGEgc3RydWN0dXJlcyBhcmUNCj4gcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlv bi4gTm93IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlcw0KPiB3aXRoIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUg ZGF0YQ0KPiBzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5TMyBh bmQgdGhlIGluZGV4IGluIHRoZSBTRkMNCj4gZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhh Y3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlDQo+IGFyZSBhdCBT MiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0 LWhvcCB0bw0KPiBTMyBhbmQgd2lsbCBkbyBhIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMg aXMgcmVhY2hhYmxlLg0KPiANCj4gT24gNy8xMS8xNCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1B UklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPiA+SmltLA0KPiA+DQo+ID5Db3Vs ZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIg YW5kIGENCj4gPiJzZXJ2aWNlIHBhdGggaWRlbnRpZmllciI/DQo+ID5JZiBhIHNlcnZpY2UgcGF0 aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhcHJpb3JpICAod2hpY2gN Cj4gPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9j YWwgZGVjaXNpb24gd2hpY2gNCj4gPm5leHQtaG9wIFNGRiB0byBwaWNrLiAgSXQgaXMgYSBjZW50 cmFsaXplZCBkZWNpc2lvbi4NCj4gPg0KPiA+TWFyaWENCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFtt YWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIw MTQgMTE6MTUgQU0NCj4gPj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgSm9lbCBNLg0KPiA+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0 Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+ID4+DQo+ID4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27i gJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4gPj4gcHJldmVu dHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBjYWxsaW5nIGl0IGEg c2VydmljZQ0KPiA+PiBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0KPiA+ Pg0KPiA+PiBPbiA3LzExLzE0LCAxMDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTky MUBhdHQuY29tPg0KPiB3cm90ZToNCj4gPj4NCj4gPj4gPkRpdHRvLg0KPiA+PiA+DQo+ID4+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tXQ0KPiA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4gPj4g Pj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwg TS4gSGFscGVybjsNCj4gUm9uDQo+ID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ID4+ID4+ IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPiA+PiA+Pg0KPiA+PiA+PiBSZS0sDQo+ID4+ID4+DQo+ID4+ID4+IEZvciB3aGF0IEkg Y2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPiA+ PmRyYWZ0Lg0KPiA+PiA+Pg0KPiA+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4gPj4gPj5kaXN0cmlidXRl ZA0KPiA+PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4gPj4gPj4NCj4gPj4gPj4gU2V2ZXJh bCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4g aXRzZWxmDQo+ID4+ID4+c2hvdWxkIGJlDQo+ID4+ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+ID4+ ID4+DQo+ID4+ID4+IENoZWVycywNCj4gPj4gPj4gTWVkDQo+ID4+ID4+DQo+ID4+ID4+ID4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gPj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+ID4+ID4+ID4oamd1 aWNoYXIpDQo+ID4+ID4+ID5FbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4 DQo+ID4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+ID4NCj4gPj4gPj4gPk9r IGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0 aW9uYWxpdHkNCj4gPj4gPj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUg KmFsbCogbmV4dC1ob3BzIHRvICphbGwqIFNGRuKAmXMNCj4gPj4gPj4gPndpdGhpbiB0aGUgU0ZD IGRvbWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhDQo+ID4+ ID4+bG9va3VwDQo+ID4+ID4+ID5pbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUgbmV4 dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+ID4+c3VyZQ0KPiA+PiA+Pmhvdw0KPiA+PiA+ PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPiA+PiA+PiA+DQo+ID4+ID4+ID5P biA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+ DQo+ID4+IHdyb3RlOg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4+QWJzb2x1dGVseS4NCj4gPj4gPj4g Pj4NCj4gPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+ID4+PiBG cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBH dWljaGFyZA0KPiA+PiA+PiA+Pj4oamd1aWNoYXIpDQo+ID4+ID4+ID4+PiBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPiA+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEg SDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4g Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRo ZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4gPj4gPj50aGF0IGlm DQo+ID4+ID4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3 aGljaCByZW1vdGUgU0ZGIGl0DQo+ID4+d2lsbA0KPiA+PiA+PnVzZQ0KPiA+PiA+PiA+Pj5mb3IN Cj4gPj4gPj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhl IGNoYWluIHRoZW4geW91DQo+ID4+YmV0dGVyDQo+ID4+ID4+bWFrZQ0KPiA+PiA+PiA+Pj4gc3Vy ZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2lj IHRvDQo+ID4+ID4+cmVhY2gNCj4gPj4gPj4gPj4+dGhlDQo+ID4+ID4+ID4+PiBuZXh0LW5leHQt U0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRyb3VibGUuDQo+ ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwg TUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPiA+PiA+PiB3cm90ZToNCj4gPj4gPj4gPj4+DQo+ ID4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50 aWF0ZWQgb25seSBpbg0KPiA+PnJlbGV2YW50DQo+ID4+ID4+ID4+PlNGRnMNCj4gPj4gPj4gPj4+ ID53aGVuIHRoZXkgImFycml2ZSIuDQo+ID4+ID4+ID4+PiA+DQo+ID4+ID4+ID4+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4gPj5HdWljaGFyZA0KPiA+ PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+ID4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkg MTEsIDIwMTQgOToyNyBBTQ0KPiA+PiA+PiA+Pj4gPj4gVG86IEpvZWwgTS4gSGFscGVybjsgUm9u IFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4+ID4+ DQo+ID4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQg aWYgSSBoYXZlIHVuZGVyc3Rvb2QNCj4gPj50aGUNCj4gPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4g Pj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdl IG9mIGV2ZXJ5IHNpbmdsZQ0KPiA+PlNGDQo+ID4+ID4+ID4+PndpdGhpbg0KPiA+PiA+PiA+Pj4g Pj50aGUNCj4gPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBT RkYgYXMgdGhlcmUgaXMgbm8gd2F5IHRvDQo+ID4+a25vdw0KPiA+PiA+PmENCj4gPj4gPj4gPj4+ ID4+cHJpb3JpDQo+ID4+ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBu ZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+ID4+cG9pbnQNCj4gPj4gPj5pbg0KPiA+PiA+ PiA+Pj50aW1lLg0KPiA+PiA+PiA+Pj4gPj4NCj4gPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDEx OjUzIFBNLCAiSm9lbCBNLiBIYWxwZXJuIg0KPiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gPj4g Pj4gd3JvdGU6DQo+ID4+ID4+ID4+PiA+Pg0KPiA+PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcg YWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4gPj53aXRoDQo+ ID4+ID4+dGhlDQo+ID4+ID4+ID4+PiA+PnlvdXINCj4gPj4gPj4gPj4+ID4+ID5wcm9wb3NhbCBh cyBJIHVuZGVyc3RhbmQgaXQuICAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4gPj4g Pj4gPj4+dW5kZXJzdGFuZA0KPiA+PiA+PiA+Pj4gPj4gPml0LikNCj4gPj4gPj4gPj4+ID4+ID4N Cj4gPj4gPj4gPj4+ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBs b2FkIGJhbGFuY2VyIGZvciB0aGUNCj4gPj4gPj5uZXh0DQo+ID4+ID4+ID4+PiA+PiA+c2Vydmlj ZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzDQo+ID4+ dG8pLA0KPiA+PiA+PmluDQo+ID4+ID4+ID4+PmV2ZXJ5DQo+ID4+ID4+ID4+PiA+PiA+c2Vydmlj ZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4gPj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4g Pj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2Vz LCB0aGF0IG1lYW5zDQo+ID4+ID4+dGhhdA0KPiA+PiA+PiA+Pj4gPj5ldmVyeQ0KPiA+PiA+PiA+ Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0 YXRlZnVsIGxvYWQNCj4gPj4gPj4gPj4+YmFsYW5jZXIuDQo+ID4+ID4+ID4+PiA+PiA+SSBhaHZl IG5vIHByb2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcg0KPiA+ PiA+PnN0YXRlZnVsLg0KPiA+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVy ZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwNCj4gPj4gPj5mbG93DQo+ID4+ID4+ ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0 byBiZSBhbg0KPiA+PiA+PmFjY2VwdGFibGUNCj4gPj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0K PiA+PiA+PiA+Pj4gPj4gPg0KPiA+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPiA+PiA+PiA+Pj4gPj4g PkpvZWwNCj4gPj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDow NiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBt eSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZSB0aGlzDQo+ID4+d29y aw0KPiA+PiA+PiA+Pj4gPj5zZW5zaWJseQ0KPiA+PiA+PiA+Pj4gPj4gPj4gaW4gYSBtb3JlIG9y Y2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gIEkgZXhwZWN0IHRoYXQgdGhlDQo+ID4+c2VydmljZQ0K PiA+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBT RkYgY2FwYWJpbGl0aWVzLA0KPiA+PndpbGwNCj4gPj4gPj5iZQ0KPiA+PiA+PiA+Pj4gPj4gPj4g b3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMN Cj4gPj50byBiZQ0KPiA+PiA+PiA+Pj4gPj5kcml2ZW4gYnkNCj4gPj4gPj4gPj4+ID4+ID4+IEJT UyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZQ0KPiA+ PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPiA+PiA+PiA+Pj4gPj4gPj4gZnJvbSB0aGVzZS4gIEkg ZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4gPj4gPj5kcml2ZS4N Cj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1h a2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4gPj4gPj5kcml2ZW4NCj4g Pj4gPj4gPj4+YnkNCj4gPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8g ZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuICBJdCBpcw0KPiA+PiA+PmhhcmRlcg0KPiA+PiA+PiA+ Pj50bw0KPiA+PiA+PiA+Pj4gPj5zZWUNCj4gPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0 IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdw0KPiBtb3JlDQo+ID4+ID4+ ID4+PiA+PiBkeW5hbWljaXR5DQo+ID4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhh dmlvci4NCj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0 aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXMNCj4gPj4gPj5vdXRz aWRlDQo+ID4+ID4+ID4+Pm9mDQo+ID4+ID4+ID4+PiA+PnRoZQ0KPiA+PiA+PiA+Pj4gPj4gPj4g c2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZQ0K PiA+PiA+PnRhc2tlZCB0bw0KPiA+PiA+PiA+Pj4gPj5hZ3JlZQ0KPiA+PiA+PiA+Pj4gPj4gPj5v bi4NCj4gPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5z IHdlIGhhdmUgdG8gZG8gaXQgYQ0KPiA+PmNlcnRhaW4NCj4gPj4gPj4gPj4+d2F5Lg0KPiA+PiA+ PiA+Pj4gPj5pdA0KPiA+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhh dCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+ID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiA+PiA+Pj4g Pj4gPj4gWW91cnMsDQo+ID4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+ID4+ID4+ID4+PiA+PiA+Pg0K PiA+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0K PiA+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJv dXQgc2VydmljZQ0KPiBpbnN0YW5jZXMNCj4gPj4gPj4gdGhhdA0KPiA+PiA+PiA+Pj4gPj5uZWVk cw0KPiA+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBk aXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPiA+PiA+PmFjcm9z cw0KPiA+PiA+PiA+Pj5kYXRhDQo+ID4+ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFu IGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4gPj5hbmQNCj4gPj4gPj4g Pj4+IGNvbXBsZXgNCj4gPj4gPj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdl dCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhDQo+ID4+ID4+ID4+PmRpZmZpY3VsdA0K PiA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4gPj4gPj4gPj4+ ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlz IG1vcmUgY29tcGxpY2F0ZWQgdGhhbg0KPiA+PmR5bmFtaWMNCj4gPj4gPj4gPj4+IHJvdXRpbmcs DQo+ID4+ID4+ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlv biwgb3IgRE5TLCBhbGwgb2YNCj4gPj53aGljaA0KPiA+PiA+PmFyZQ0KPiA+PiA+PiA+Pj4gPj5i aWdnZXINCj4gPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRh Ymx5IGFuZCBzdGFibHkNCj4gaW1wbGVtZW50ZWQ/DQo+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4g Pj4gPj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29t cGxpY2F0ZWQsIHRoYXQNCj4gPj5pcw0KPiA+PiA+PmENCj4gPj4gPj4gPj4+Z29vZA0KPiA+PiA+ PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+ID4+ID4+ID4+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtq bWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+PiA+PiA+Pj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBK dWx5IDEwLCAyMDE0IDk6NDUgUE0NCj4gPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsg Sm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb207DQo+ID4+SWFuDQo+ID4+ID4+ ID4+PlNtaXRoOw0KPiA+PiA+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+Pj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk DQo+ID4+QmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+PiBU aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuICBBbmQgb25lIHRoYXQgSSB3b3VsZA0KPiA+ PnByZWZlcg0KPiA+PiA+PndlDQo+ID4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPiA+PiA+PiA+ Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJs ZQ0KPiA+PiA+PmltcGxlbWVudGF0aW9ucy4NCj4gPj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0 IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPiA+PiA+PnJlcXVpcmVt ZW50cw0KPiA+PiA+PiA+Pj5hbmQNCj4gPj4gPj4gPj4+ID4+IHRoZQ0KPiA+PiA+PiA+Pj4gPj4g Pj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+ Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNl DQo+IGluc3RhbmNlcw0KPiA+PiA+PnRoYXQNCj4gPj4gPj4gPj4+IG5lZWRzDQo+ID4+ID4+ID4+ PiA+PiB0bw0KPiA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFp bnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPiA+PiBhY3Jvc3MNCj4gPj4gPj4gPj4+ZGF0YQ0K PiA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3Bl LCBpcyBsYXJnZSBlbm91Z2gNCj4gPj5hbmQNCj4gPj4gPj4gPj4+Y29tcGxleA0KPiA+PiA+PiA+ Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNl ZW1zIGxpa2UgYQ0KPiA+PiA+PiA+Pj5kaWZmaWN1bHQNCj4gPj4gPj4gPj4+ID4+ID4+PiBhcmNo aXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gPj4g Pj4+IFlvdXJzLA0KPiA+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4gPj4gPj4gPj4+ID4+ID4+Pg0K PiA+PiA+PiA+Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+ID4+ID4+ID4+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFy a2VyIHdyb3RlOg0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlz c3VlLiAgIElzIHRoZSBlbmQgdG8gZW5kDQo+ID4+c2VsZWN0aW9uDQo+ID4+ID4+b2YNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkg KHBlcmhhcHMgYnkgdGhlDQo+ID4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kDQo+IHN1 YnNlcXVlbnRseQ0KPiA+PiA+PnRoZQ0KPiA+PiA+PiA+Pj4gPj5TRkZzKT8NCj4gPj4gPj4gPj4+ ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNh dGlvbi4NCj4gPj5BbmQNCj4gPj4gPj4gPj4+c3VyZWx5LA0KPiA+PiA+PiA+Pj4gPj4gPj4+PiB0 aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4gPj4g Pj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVk IGFwcHJvYWNoIGV2ZW4NCj4gPj4gdGhvdWdoDQo+ID4+ID4+IGENCj4gPj4gPj4gPj4+ID4+ID4+ Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMN Cj4gPj5sb2NhbA0KPiA+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4gPj4gPj4gPj4+ID4+ID4+Pj4g cG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMu DQo+ID4+ID4+VGhpcw0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1 aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+ID4+ID4+TXkNCj4gPj4gPj4gPj4+ ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmls eSBkcml2ZW4NCj4gPj5ieQ0KPiA+PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4gPj4gPj4gPj4+ID4+ ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gICBXaXRo IGENCj4gPj5nbG9iYWwNCj4gPj4gPj4gPj4+cGF0aA0KPiA+PiA+PiA+Pj4gPj5pZA0KPiA+PiA+ PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBh bmQgbmVlZGluZyB0bw0KPiA+PiA+PmFsdGVyDQo+ID4+ID4+ID4+PnRoZQ0KPiA+PiA+PiA+Pj4g Pj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQN Cj4gPj5lbmQtdG8tZW5kDQo+ID4+ID4+ID4+PnBhdGguDQo+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ ID4+ID4+ID4+PiA+PiA+Pj4+IFJvbg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+Pj4g Pj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNm Yw0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBv ZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpv ZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsDQo+ID4+MjAxNA0KPiA+PiA+ PiA2OjE1DQo+ID4+ID4+ID4+PiBQTQ0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5j QGFvbC5jb207IEkuU21pdGhARjUuY29tOyBzZmNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDoNCj4g Pj4gPj4gUmU6DQo+ID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+PiA+ PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxIG5l ZWRpbmcNCj4gPj50bw0KPiA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UNCj4gPj4gPj4gPj4+ID4+ID4+ Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhl DQo+ID4+ZXhpdA0KPiA+PiA+PmZyb20NCj4gPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRv IGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4gPj4gPj5sb2dpY2FsbHkNCj4gPj4gPj4g Pj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3Jp YmUgaG93IHRoZXkNCj4gPj4gPj4gY2hvb3NlDQo+ID4+ID4+ID4+PnRvDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNA YW9sLmNvbSB3cm90ZToNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5n IGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55DQo+ID4+ID4+c29ydA0KPiA+PiA+ PiA+Pj5vZg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2Vl bSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUNCj4gPj4gPj5wYXRoDQo+ID4+ID4+ID4+Pihh bGwNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0 YW50aWF0aW9uLiAgSSBiZWxpZXZlDQo+ID4+dGhpcw0KPiA+PiA+PiA+Pj5tZWFucw0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFz c2lmaWVyDQo+ID4+Y2hvb3NlcyBhDQo+ID4+ID4+U0YNCj4gPj4gPj4gPj4+ID4+Q2hhaW4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3Qg U0ZGLiAgSW4gYW55IGNhc2UsDQo+ID4+ID4+dGhlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5n dWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQDQo+IHdoZXJlDQo+ ID4+ID4+IFNGSShuKQ0KPiA+PiA+PiA+Pj4gaXMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGRldGVy bWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gIEFjY29yZGluZyB0byB0aGUgZHJhZnQsDQo+ID4+ ID4+dGhpcw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJl ZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlANCj4gYXMNCj4gPj4gPj4gPj4+IG9wcG9zZWQNCj4g Pj4gPj4gPj4+ID4+IHRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBm b3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZQ0KPiBvZg0KPiA+PiA+PnRoZQ0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPiA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0 ZWN0dXJlLTAwOg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRp YXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+ID4+ID4+bmVjZXNzYXJ5DQo+ID4+ID4+ID4+ PnRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMg b2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLA0KPiA+PiA+PmFuZCB0bw0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Yn cw0KPiA+PiA+Pm5ldHdvcmsNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiAgVGh1cywg aW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlDQo+ID4+ID4+ID4+PmNyZWF0 aW9uDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNG UCkgYW5kIGlzIHVzZWQgZm9yDQo+ID4+ID4+Zm9yd2FyZGluZw0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRo ZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZD Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBh cmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4gPj4gPj5ub24taW5p dGlhbA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiAgQXMg cGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcmVjbGFzc2lm aWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGENCj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2Vy dmljZQ0KPiA+PiA+PmZ1bmN0aW9uLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3NpZmlj YXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3DQo+ID4+ID4+U0ZQLCBh bg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0 YSwgb3IgYm90aC4gIFRoaXMgaXMNCj4gPj4gPj5yZWZlcnJlZA0KPiA+PiA+PiA+Pj50bw0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ID4+Pg0KPiA+PiA+Pg0KPiA+Pg0KPiA+ Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+Pj4+Pj4+Pj4+Pj4t LS0NCj4gPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+LS0NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21p dGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9l bCBIYWxwZXJuDQo+ID4+IERpcmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4sSm9lbA0K PiA+PiA+PiBNLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ ID4+Pg0KPiA+PiA+Pg0KPiA+Pg0KPiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbT4s aHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5nQHNjZS4NCj4gPj4gPj4gPj4+ID4+IGNhcmxldG9u Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkDQo+ID4+ID4+QmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWlu Zy4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBJZiB0aGUgcG9z c2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQNCj4gPj50aGF0IGlzDQo+ ID4+ID4+ID4+PndoYXQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IDE2IG1pbGxpb24gZmxvd3MgaXMg aW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzDQo+ID4+ID4+ID4+PnByZWNvbmNlaXZl ZA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hp dGVjdHVyZSBidXJkZW5lZCB3aXRoDQo+ID4+IHRoYXQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBy ZWNvbmNlcHRpb24uDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4g VGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZg0KPiA+PiA+ PmFzcGlyYXRpb24NCj4gPj4gPj4gdG8NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQg aXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4gPj4gPj5hcmNoaXRlY3R1 cmUNCj4gPj4gPj4gPj4+LQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8g a25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQgYW4NCj4gPj4gPj4gPj4+YXJiaXRy YXJ5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3Jl YXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+ID4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+ID4+ ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0 IGhhdmUgbGFzdGluZw0KPiA+PiA+PmltcGFjdHMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZ2Fy ZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4gPj4gPj5h ZGRyZXNzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdz LiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1 bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBqb2Vs aGFscGVybi5jb21dDQo+ID4+ID4+U2VudDoNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5 LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLg0KPiA+PiA+PiBI YWxwZXJuOw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhOyBzZmNA aWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdDQo+ID4+ID4+U2VydmljZQ0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNh Z3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzDQo+ID4+ID4+cmVnYXJkLg0KPiA+PiA+PiA+Pj5J DQo+ID4+ID4+ID4+PiA+PmFtDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0 aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4gPj4gPj5wcm9oaWJpdA0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkg YW0gb2JqZWN0aW5nIHRvDQo+ID4+ID4+SHVhbmcncw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVh ZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlDQo+ID4+ ID4+IHJlcXVpcmVkDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1 cmUuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gQXMgSSBoYXZl IHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0DQo+ID4+c3VjaA0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVh IG9yIG5vdCBkZXBlbmRzDQo+IHVwb24NCj4gPj4gPj4gbWFueQ0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+ ID4+dGhpbmsNCj4gPj4gPj50aGF0DQo+ID4+ID4+ID4+PiA+PnRoZXkNCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lk aW5nIGF0dGVtcHRpbmcgdG8NCj4gPj4gPj5rbm93DQo+ID4+ID4+ID4+PndoYXQNCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdy b3RlOg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBk ZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMNCj4gb2YNCj4gPj4gPj4gPj4+bWlsbGlvbnMNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+PiBvZg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93 cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhDQo+IGNlbnRlcg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUg dGhhdCBpbg0KPiA+PnRoZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0 eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93DQo+IHlvdQ0KPiA+PiBhcmUNCj4gPj4gPj4g b25seQ0KPiA+PiA+PiA+Pj4gPj4gZ29pbmcNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUg c21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkNCj4gPj5zbWFsbA0K PiA+PiA+PiA+Pj4gbnVtYmVycw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZp Y2UgcGF0aHM/DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBZ b3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBldmVyIG5lZWQNCj4gbW9yZQ0K PiA+PiB0aGFuDQo+ID4+ID4+ID4+PiA2NEsiDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBjb21mb3J0Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIEZyb206DQo+IHNmYw0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzoNCj4gPj4g Pj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0Bp ZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPiA+PmFu ZA0KPiA+PiA+PiA+Pj5Mb2FkDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFu IHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+ID4+ID4+ID4+PmFyY2h0aWV0 dXJlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwg ZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4gPj50aGVpcg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRl dmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZA0KPiA+ PiB1c2UNCj4gPj4gPj4gb2YNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBT aW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJl DQo+ID4+ZG9lcw0KPiA+PiA+PiA+Pj5wZXJtaXQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNo IGFidXNlLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUGxl YXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUNCj4gPj4gcGVy bWl0cw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0 aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4gPj4gPj50aGUNCj4gPj4gPj4gPj4+d29yay4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1 YW5nIHdyb3RlOg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0 IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbA0KPiA+Pm1lYW4NCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZw0K PiA+PnRhYmxlDQo+ID4+ID4+b2YgYQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBjb3JlIHJvdXRl ci4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcN Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAv MjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywNCj4g ZnJvbQ0KPiA+PjENCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAw MDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlDQo+ID4+dGhhdA0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0 aGV5DQo+ID4+ID4+Y2hvb3NlDQo+ID4+ID4+ID4+PnRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZA0KPiA+ PiA+PiBwcm92aXNpb24NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBw YXRocy4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZ b3VycywgSm9lbA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxs IGJlIGZvciBhIDQgaG9wDQo+ID4+ID4+IHNlcnZpY2UNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddICpPbg0KPiBCZWhhbGYNCj4gPj4gT2YNCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQNCj4gPj4gPj4zOjAzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVj eSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVybi5jb207DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdIFNl cnZpY2UNCj4gPj4gQ2hhaW5zLA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEx1Y3ksDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVz IHRoZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IG1ha2UNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hh bmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkDQo+IHRvDQo+ID4+ID4+IGRlcml2 ZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNz b2NpYXRlZCB0cmFuc3BvcnQuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVz ZWQgdG8NCj4gPj5zaW1wbHkNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUg c2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzDQo+ID4+bXVzdA0KPiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRo ZSBleGFjdA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxl IHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbg0KPiA+PnRoaXMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4gPj4g Pj4gaWRlbnRpZmllcg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcg bW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cA0KPiBjYW4NCj4gPj4gPj4gcmVzdWx0DQo+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0 ZWQpIHRyYW5zcG9ydA0KPiBuZXh0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVs IDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tDQo+ID4+ID4+IDxtYWlsdG86bHVjeS55b25nQGh1YXdl aS5jb20+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3Vs ZCBub3QgbWFuZGF0ZSBvbmx5IHVzZQ0KPiBvZg0KPiA+PiB0aGUNCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZw0K PiA+PiA+PmFjdGlvbnMuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBMdWN5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uDQo+ IEJlaGFsZg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+DQo+ID4+ID4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+ID4+ID4+ID4+ PiA+PiBKdWx5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86 Km1pa2ViaWFuY0Bhb2wuY29tDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPG1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTogW3Nm Y10gU2VydmljZQ0KPiA+PiA+PkNoYWlucywNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEg c2VydmljZSBwYXRoDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmpl Y3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPiA+PmRlcml2ZQ0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0 aGUgZnVsbCBrbm93bGVkZ2UNCj4gb2YNCj4gPj4gPj4gZXZlcnkNCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IGF2YWlsYWJsZSBTRkMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBh dGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMNCj4gbm90DQo+ID4+ID4+ID4+PiA+ PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3Ig cG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9u cyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2YNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bmZvcm1hdGlvbg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9u ZQ0KPiA+PiByZXF1aXJlZA0KPiA+PiA+PiB0bw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0 cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzDQo+ID4+ID4+ dXNlZCB0bw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IGFjdGlvbnMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNv bHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSpEZSBsYSBwYXJ0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9s LmNvbQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPiA+PiA+PiBqdWlsbGV0DQo+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcN Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoq UmU6IFtzZmNdIFNlcnZpY2UNCj4gPj4gPj5DaGFpbnMsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4NCj4gPj5TRg0KPiA+PiA+PiBDaGFpbg0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGFuZCBTRg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhh dCBpdCdzDQo+ID4+ID4+Y2xlYXIgdG8NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRob3NlIG5vdA0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVt cyB0aGF0IGV2ZXJ5b25lDQo+ID4+YWdyZWVzDQo+ID4+ID4+b24NCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVh ciBpcw0KPiA+PndoZXRoZXINCj4gPj4gPj5pdCBpcw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdA0KPiA+ PiA+PnRoZSBJRA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBzaG91bGQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZl cmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQNCj4gPj4gPj5z aW1wbHkNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1i aWd1b3VzLCBhbGxvd2luZyBvdGhlcg0KPiA+PmRyYWZ0cw0KPiA+PiA+PnRvDQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNl ZCBvbg0KPiBjaGFpbg0KPiA+PiBvcg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5k IHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5l Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYg dGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQNCj4gaGF2ZQ0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1 cHBvcnRlZCAob3INCj4gbWFrZQ0KPiA+PiA+PiBvbmUNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lDQo+ID4+IHZl bmRvcnMNCj4gPj4gPj4gb25seQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcg U0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiA+PiA+Pj4gPj4NCj4gPj4gPj4gPj4+DQo+ID4+ID4+DQo+ID4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPiA+PiA+PiA+ Pj4+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4t LQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb20NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86 KnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFp bHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQo+ID4+ICpTZW50OipUdWVzZGF5LA0K PiA+PiA+PiBKdWx5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoq W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQNCj4gPj5Mb2FkDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8g Y2xlYXJseQ0KPiA+PmFuc3dlcg0KPiA+PiA+PmENCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBu dW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dA0KPiB0aGUNCj4gPj4g Pj4gPj4+IHByb3Bvc2VkDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVj dHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldA0KPiA+PiB3b3JraW5nDQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29y ayB0bw0KPiA+PiBpbXByb3ZlDQo+ID4+ID4+IHRoZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQNCj4gaW4N Cj4gPj4gPj50aGUNCj4gPj4gPj4gV0cNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNz aW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiB3 b3JraW5nDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRvIHdl IGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+ID4+ID4+cGVyc29uYWwNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2Fy ZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0DQo+ID4+ID4+d2hhdA0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBh cmNoaXRlY3R1cmUuIFdlDQo+ID4+YXJlDQo+ID4+ID4+IG5vdA0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRp cmUNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmlu Zy4gVGhhdCB3b3VsZA0KPiBlbmNvbXBhc3MNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1Mv QlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQo+ID4+dmlydHVhbA0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFu ZCBtYW55IG90aGVyDQo+ID4+ID4+IGFzcGVjdHMuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGlu Z3Mgd2hpY2ggY2xlYXJseQ0KPiBuZWVkDQo+ID4+IHRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aA0K PiA+PiA+PmFib3ZlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+ID4+ ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh bmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUNCj4gPj4gZG9p bmcuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJ biBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsDQo+ID4+YXMg SQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHVuZGVyc3RhbmQNCj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IHRoZW0sDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1 c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdA0KPiA+PiA+PmxlYXN0DQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBj YW4gYW5kDQo+ID4+d2lsbA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGgg c2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlDQo+ID4+ID4+bW9yZS4NCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBw ZXJtaXQgYWxsIG9mDQo+ID4+ID4+dGhlc2UsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gYmUgdXNlZA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExv YWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kDQo+ID4+ID4+dXNl ci4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4g SXQgcmVjZWl2ZXMgdXNlcg0KPiA+PnBhY2tldHMsDQo+ID4+ID4+YW5kDQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtz DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2Ug YW4gZW5kIHVzZXIgc2VydmljZQ0KPiA+PiA+Pmluc3RhbmNlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0K PiA+PiA+PnNlcnZpY2UNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBh YmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4NCj4gPj4gPj5JdCdzDQo+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93 IHNlcnZpY2UNCj4gPj4gPj4gY2hhaW5pbmcgaXMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBk b25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4gPj4gPj5hcmNodGll Y3R1cmUuDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBw ZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGENCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UN Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1 bmRlcmx5aW5nIHBhY2tldC4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlz LCBvbmUNCj4gPj5jYW4NCj4gPj4gPj5oYXZlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hh dA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZQ0KPiA+PnBv aW50DQo+ID4+ID4+b2YNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+ID4+ID4+ ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNl cnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4gPj4gPj5ieSBhDQo+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+ID4+ b25lIG9yDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAo Zm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVj aG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEg cGxhbmUNCj4gPj4gPj5tZWNoYW5pc21zLg0KPiA+PiA+PiBJdA0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sDQo+ ID4+ID4+bWVjaGFuaXNtcywNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3Nl IHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LA0KPiA+PmFuZA0KPiA+PiA+PnZt DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVy YWwgaW1wYWN0IG9mDQo+ID4+cGVybWl0dGluZw0KPiA+PiA+PnRoaXMNCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3Vy DQo+ID4+ID4+dGVybWlub2xvZ3kNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBs ZWFkDQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBi YWxhbmNpbmcgZG9uZSBieQ0KPiA+PnNlbGVjdGluZw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4gPj4g Pj50cmFmZmljDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4g V2Ugd291bGQgbm90IHdhbnQgdG8gcmVxdWlyZQ0KPiA+PiB0aGF0DQo+ID4+ID4+YQ0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkg b25lIHBsYWNlIGluDQo+ID4+dGhlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlz IG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPiA+PmNvbWJpbmVkLiBJDQo+ ID4+ID4+IHRlbmQNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gcmVmZXIgdG8NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBv ZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlDQo+ID4+ID4+Y2hhaW5pbmcNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBi ZWNhdXNlIGNsdXN0ZXINCj4gPj5pcw0KPiA+PiA+PmENCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuDQo+ID4+ IFRodXMsDQo+ID4+ID4+IHRoZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5 cGUgMyBsb2FkIGJhbGFuY2luZw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBk aWZmZXJlbnQNCj4gPj4gPj5zaW5ndWxhcg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9yIGNs dXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzDQo+ID4+aW4NCj4g Pj4gPj50aGUNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlk LCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsaw0KPiBhYm91dA0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBh DQo+ID4+ID4+IHNlcXVlbmNlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBm dW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZg0KPiA+PiA+PnBhY2tldHMuDQo+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBz b21lIHN1YnNldCBvZg0KPiA+PnRyYWZmaWMNCj4gPj4gPj5pcw0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KPiA+ PmZpcmV3YWxsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vi c2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRoZQ0KPiA+PmNhY2hlDQo+ID4+ID4+ID4+PiA+PiA+ Pj4+PiB3aXRob3V0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVy IHNlcnZpY2UgZnVuY3Rpb25zLg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0 aGUNCj4gPj5wYWNrZXRzLg0KPiA+PiBBDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vydmlj ZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4gPj4gPj5sb2NhdGlv bnMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRp b25zIHdpbGwgYmUgc2luZ3VsYXIgb3INCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4gPj4gPj5tYXkg YmUNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhl eSBtYXkgYmUgYWRkcmVzc2VkIGFzDQo+ID4+IHBvcnRzDQo+ID4+ID4+IG9uDQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0 IHRoZQ0KPiA+PiA+PmxvY2F0aW9ucw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBr bm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KPiBpbmZyYXN0cnVjdHVyZQ0KPiA+PiBhbmQN Cj4gPj4gPj4gdGhlDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRoZSBw b2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMNCj4gPj5ncm91cCwNCj4gPj4gPj4g d2UNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwg dGhlDQo+ID4+ID4+c2VydmljZQ0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3aGlj aCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvDQo+ID4+IHRhbGsNCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdp bGwgdGFrZSBpbiB0aGUNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0 aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlDQo+ID4+IHBhdGgNCj4gPj4gPj4g bWF5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4i IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzDQo+ID4+ID4+d2l0aA0KPiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgy KQ0KPiA+Pm9uDQo+ID4+ID4+bG9hZA0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2Vy cyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4gPj5iZWhhdmlvcnMNCj4gPj4g Pj4gd2hpY2gNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBz ZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+ID4+ID4+bXVjaA0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBs YXJnZWx5DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0 d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+ID4+IHByb3Zpc2lvbg0KPiA+PiA+PiB3ZQ0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1p ZC1jaGFpbiB3aGVuDQo+ID4+ID4+IG5lY2Vzc2FyeS4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uDQo+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFz c2lmaWNhdGlvbg0KPiA+PnBvaW50Lg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2Ug YXJlIGFmdGVyLg0KPiA+PklmIGl0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5k IGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZw0KPiA+PiA+PiBncm91 cCwNCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0 aW9uYWwgd29yZHMgYXJlDQo+IG5lZWRlZA0KPiA+PiB0bw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZQ0K PiA+PiA+PiBpbnRlbnQsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9m IGNvdXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcNCj4gPj4gPj5ncm91cA0KPiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwg SSBhbSBub3Qgc3VyZQ0KPiA+PiA+PndoYXQgdG8NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 cnkgbmV4dC4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiA+PiBzZmMNCj4gPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4gPj4gc2ZjDQo+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+ID4+IHNmYw0KPiA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcNCj4gPj4gPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4N Cj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gc2ZjDQo+ID4+ ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYu b3JnDQo+ID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IHNmYw0KPiA+PiA+PiA+Pj4gbWFpbGluZw0KPiA+PiA+PiA+Pj4gPj4gbGlzdA0K PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2ZjDQo+ID4+ID4+ID4+PiBtYWlsaW5nDQo+ID4+ID4+ ID4+PiA+PiBsaXN0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4g Pj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2ZjDQo+ID4+ID4+IG1haWxpbmcNCj4gPj4gPj4gPj4+ID4+IGxpc3QNCj4g Pj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+PiA+PiA+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYw0K PiA+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ID4+ID4+PiA+PiA+Pj4+ IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ID4+ID4+PiA+PiA+ Pg0KPiA+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4g Pj4+ID4+ID4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+ PiA+PiA+DQo+ID4+ID4+ID4+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gPj4gPj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ ID4+PiA+PiA+c2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ID4+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+ Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnDQo+ID4+ ID4+ID4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+ID4+ID4+PiBzZmMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ID4+PiBz ZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+ID4+ID4+ID4NCj4gPj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ ID5zZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+ID4NCg0K From nobody Fri Jul 11 09:28: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 B01D31A854B for ; Fri, 11 Jul 2014 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 mX5hOAD-wTj0 for ; Fri, 11 Jul 2014 09:28:35 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581B11B290B for ; Fri, 11 Jul 2014 09:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=197323; q=dns/txt; s=iport; t=1405096115; x=1406305715; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aI/e9q7R4EXehsdG7mCOo0DEhUbVGgS98A18MwW6s1Y=; b=hqe5zm5FGF6s8p0VSb7WD4UhJQvfz/lPKVEieAj3kgE1j3YXtHu5qMVA KHA5iPIpSTDV//lmfwAJR/dTow8YakOJ6M7xYrCABO9o6ar57CxlesLs+ QH8MSf48sEmpg02ZeUEOjWocBPXhpn5/suxKFpbqqR9BPgVcKMXQfkhJc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAKsPwFOtJA2K/2dsb2JhbABPCoJHR1JagnGsCZF4AQmHQgEZchZ1hAMBAQEDAQEBARcBCAQ+CQIOBwQCAQgRAQIBAQEBIAEGAwICAiULFAMGCAIEARIbiBMDCQgNrVqYfhMEiX2DIIFQBSAMEAoHBgoBAgSCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos; i="5.01,644,1400025600"; d="scan'208,217"; a="60127510" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 16:28:31 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGSVTs008814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:28:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:28:31 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" , "mohamed.boucadair@orange.com" , "jmh@joelhalpern.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AACNZ7AP//xIOAgABJ/ID//79hAA== Date: Fri, 11 Jul 2014 16:28:30 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE587DA2D547jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ulIjULDOlbzD7gzKR6tdIPRuP9w Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:28:44 -0000 --_000_CFE587DA2D547jguicharciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9y d2FyZGluZyBwYXRoIHRocm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRo ZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBob3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZSBj aGFpbiBkYXRhIHN0cnVjdHVyZSBhbmQgdGhhdCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmlj IGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMg YXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlz IGluIHBsYXkuIFdoZW4gaW5zdGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBu ZXR3b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBz cGVjaWZ5IHdoaWNoIG5leHQtaG9wcyBtYXkgYmUgdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1o b3Agd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNl cnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wg LyBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQoNCkZy b206ICJtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJp YW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4NCkRhdGU6IEZyaWRheSwgSnVs eSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KVG86IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28u Y29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzpt bjE5MjFAYXR0LmNvbT4iIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Piwg Im1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPj4sICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PiwgInNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCg0K PiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5DQo+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwg UzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KPiBhc3NpZ24gYSBz ZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRv IFMxLT5TMi0+UzMNCj4gYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsNCg0KQnkg ZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJl ZCBsaXN0IG9mIHNwZWNpZmljIFNGIGluc3RhbmNlcy4gIEluIHRoZSBzdGF0ZW1lbnQgYWJvdmUs IHlvdSB1c2UgYSAic2VydmljZSBwYXRoIGlkZW50aWZpZXIiIHRvIHJlZmVyIHRvIGEgc2Vydmlj ZSAqY2hhaW4qIHRoYXQgc3BlY2lmaWNhbGx5ICJbZG9lcyBub3RdIHNwZWNpZnkgc3BlY2lmaWMg aW5zdGFuY2VzIi4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjxqZ3VpY2hh ckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpUbzogTkFQSUVSQUxBLCBN QVJJQSBIPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+PixKb2VsIE0uIEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpNYXJpYSwNCg0KSSB0aGluayBvZiBp dCB0aGlzIHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50 ZXIgdG8NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBtYXBw aW5ncy4gV2hlbiB5b3UgZGVmaW5lIGENCmNoYWluLCBsZXTigJlzIHNheSBTMSAtPlMyLT4gUzMs IHlvdSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5DQp0aGUgc3BlY2lmaWMg bmV4dC1ob3BzIHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91Z2ggZm9yIHRoYXQg U0ZQLg0KSG93ZXZlciwgeW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hp dGVjdHVyYWwgc3RhbmRwb2ludCAoSQ0Kd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlv dSBkb27igJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91DQpjb3VsZCBzaW1wbHkgYXNz aWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMgYW5k DQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZG IGl0IHdpbGwgaGF2ZSBhDQpzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMgbWFwcGluZyBh bmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4gdGhlDQpuZXh0LWhvcHMgYXZhaWxhYmxlIGZv ciBlYWNoIG9mIHRoZSBTRuKAmXMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuDQp0aG9z ZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBh IGNlbnRyYWxpemVkDQpjb250cm9sbGVyLCBjb25maWd1cmUgdGhlbSB0aHJvdWdoIENMSSwgbGVh cm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoDQpzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3aGF0 ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bw0Kc2F5IHRoYXQgdGhl IHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhIHBy aW9yaQ0KYWx0aG91Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxk IHNheSByZWNvbW1lbmRlZCkgdG8gZG8NCnNvLg0KDQpMZXTigJlzIHRha2UgYW4gZXhhbXBsZSB0 byBob3BlZnVsbHkgbWFrZSB0aGlzIGNsZWFyOg0KDQpJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMg cmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMxLT5TMi0+UzMuIEZvciBhcmd1bWVudHMNCnNha2UgbGV0 4oCZcyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKAmXQgd2Fu dCB0byBzcGVjaWZ5DQpzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNv bWUgY29tYmluYXRpb24gdGhlcmVvZikuIEkNCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KYW5kIHRo ZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEgc3RydWN0 dXJlcyBhcmUNCnBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBhdCBhIGdpdmVu IFNGRiwgd2hlbiB0cmFmZmljIGFycml2ZXMNCndpdGggc2VydmljZSBwYXRoIGlkZW50aWZpZXIg MTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhDQpzdHJ1Y3R1cmUgYW5k IGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5TMyBhbmQgdGhlIGluZGV4IGluIHRoZSBT RkMNCmVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0IGV4YWN0bHkgd2hlcmUgaXQgaXMgaW4gdGhl IGNoYWluLiBMZXTigJlzIHNheSB3ZQ0KYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3 aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9wIHRvDQpTMyBhbmQgd2lsbCBkbyBh IGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMgcmVhY2hhYmxlLg0KDQpPbiA3LzExLzE0 LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzpt bjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KDQo+SmltLA0KPg0KPkNvdWxkIHlvdSB0ZWxsIHVzIHdo YXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAic2VydmljZSBwYXRoIiBhbmQgYQ0KPiJzZXJ2aWNl IHBhdGggaWRlbnRpZmllciI/DQo+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0Yg aW5zdGFuY2VzIGFyZSBjaG9zZW4gYXByaW9yaSAod2hpY2gNCj5pcyBteSBjdXJyZW50IHVuZGVy c3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoDQo+bmV4 dC1ob3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uDQo+DQo+TWFy aWENCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pg0KDQpGcm9tOiBKaW0g R3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+IFNlbnQ6 IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTQ0KPj4gVG86IE5BUElFUkFMQSwgTUFSSUEg SDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT47IEpvZWwgTS4NCj4+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gSeKAmW0gc29ycnkgYnV0IEkg cmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0K Pj4gcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBjYWxs aW5nIGl0IGEgc2VydmljZQ0KPj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVyZW5j ZT8NCj4+DQo+PiBPbiA3LzExLzE0LCAxMDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1u MTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPj4NCj4+ID5EaXR0 by4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPj4g Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+PiA+PiBUbzogSmltIEd1 aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBS b24NCj4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+ PiBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+ID4+DQo+PiA+PiBSZS0sDQo+PiA+Pg0KPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5 IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+PmRyYWZ0Lg0K Pj4gPj4NCj4+ID4+IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0 c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbA0KPj4gPj5kaXN0cmlidXRlZA0KPj4gPj4gbW9kZWwg aXMgbm90IGFsbG93ZWQuDQo+PiA+Pg0KPj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJl YWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4gaXRzZWxmDQo+PiA+PnNob3VsZCBi ZQ0KPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4NCj4+ID4+DQo+PiA+PiBDaGVlcnMsDQo+PiA+PiBN ZWQNCj4+ID4+DQo+PiA+PiA+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiA+PiA+RGUg OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0gR3Vp Y2hhcmQNCj4+ID4+ID4oamd1aWNoYXIpDQo+PiA+PiA+RW52b3nDqSA6IHZlbmRyZWRpIDExIGp1 aWxsZXQgMjAxNCAxNjoxOA0KPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0u IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiA+PiA+DQo+PiA+PiA+T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1 cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eQ0KPj4gPj4gPnByb2hpYml0ZWQ/ IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4dC1ob3BzIHRvICphbGwqIFNGRuKA mXMNCj4+ID4+ID53aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlk ZW50aWZpZXIgcG9pbnQgdG8gYQ0KPj4gPj5sb29rdXANCj4+ID4+ID5pbnRvIHRob3NlIG5leHQt aG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+PnN1cmUN Cj4+ID4+aG93DQo+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPj4gPj4g Pg0KPj4gPj4gPk9uIDcvMTEvMTQsIDk6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5 MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gd3JvdGU6DQo+PiA+PiA+DQo+ PiA+PiA+PkFic29sdXRlbHkuDQo+PiA+PiA+Pg0KPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+PiA+Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQNCj4+ID4+ID4+PihqZ3VpY2hhcikNCj4+ID4+ ID4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4gPj4gPj4+IFRvOiBO QVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4NCj4+ID4+ ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0 IHNlZW1zIHRvIG1lDQo+PiA+PnRoYXQgaWYNCj4+ID4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZGIHRv IG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0DQo+PndpbGwNCj4+ID4+ dXNlDQo+PiA+PiA+Pj5mb3INCj4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5l eHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPj5iZXR0ZXINCj4+ID4+bWFrZQ0KPj4g Pj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2Fy ZGluZyBsb2dpYyB0bw0KPj4gPj5yZWFjaA0KPj4gPj4gPj4+dGhlDQo+PiA+PiA+Pj4gbmV4dC1u ZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0cm91Ymxl Lg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwg TUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQo+PiA+PiB3 cm90ZToNCj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID5BYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFp bnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluDQo+PnJlbGV2YW50DQo+PiA+PiA+Pj5TRkZz DQo+PiA+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4NCj4+ID4+ID4+PiA+DQo+PiA+PiA+Pj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+PiA+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj5HdWljaGFyZA0K Pj4gPj4gPj4+ID4+KGpndWljaGFyKQ0KPj4gPj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNCA5OjI3IEFNDQo+PiA+PiA+Pj4gPj4gVG86IEpvZWwgTS4gSGFscGVybjsgUm9uIFBh cmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3Jz ZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2QNCj4+dGhlDQo+PiA+PiA+Pj4gPj5wcm9w b3NhbA0KPj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25v d2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZQ0KPj5TRg0KPj4gPj4gPj4+d2l0aGluDQo+PiA+PiA+Pj4g Pj50aGUNCj4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUgU0ZG IGFzIHRoZXJlIGlzIG5vIHdheSB0bw0KPj5rbm93DQo+PiA+PmENCj4+ID4+ID4+PiA+PnByaW9y aQ0KPj4gPj4gPj4+ID4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2Vy dmljZSBhdCBhbnkgZ2l2ZW4NCj4+cG9pbnQNCj4+ID4+aW4NCj4+ID4+ID4+PnRpbWUuDQo+PiA+ PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFs cGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0K Pj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBh Ym91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJvYmxlbQ0KPj53aXRoDQo+PiA+ PnRoZQ0KPj4gPj4gPj4+ID4+eW91cg0KPj4gPj4gPj4+ID4+ID5wcm9wb3NhbCBhcyBJIHVuZGVy c3RhbmQgaXQuIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdA0KPj4gPj4gPj4+dW5kZXJz dGFuZA0KPj4gPj4gPj4+ID4+ID5pdC4pDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5U aGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvciB0 aGUNCj4+ID4+bmV4dA0KPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93 cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnMNCj4+dG8pLA0KPj4gPj5pbg0KPj4gPj4gPj4+ ZXZlcnkNCj4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4N Cj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRv IHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnMNCj4+ID4+dGhhdA0KPj4gPj4gPj4+ ID4+ZXZlcnkNCj4+ID4+ID4+PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93 IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPj4gPj4gPj4+YmFsYW5jZXIuDQo+PiA+PiA+ Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwg YW5kIC8gb3INCj4+ID4+c3RhdGVmdWwuDQo+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFy Y2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwNCj4+ID4+Zmxvdw0K Pj4gPj4gPj4+ID4+ID5zZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRv IG1lIHRvIGJlIGFuDQo+PiA+PmFjY2VwdGFibGUNCj4+ID4+ID4+PiA+PiA+aW1wb3NpdGlvbi4N Cj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPj4gPj4gPj4+ID4+ID5Kb2Vs DQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9l bCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkgcGVyc29uYWwg dmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcw0KPj53b3JrDQo+PiA+PiA+Pj4g Pj5zZW5zaWJseQ0KPj4gPj4gPj4+ID4+ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJv bm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlDQo+PnNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+PiBmdW5j dGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsDQo+Pndp bGwNCj4+ID4+YmUNCj4+ID4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4g SSBleHBlY3QgdGhlIHNlcnZpY2UgY2hhaW5zDQo+PnRvIGJlDQo+PiA+PiA+Pj4gPj5kcml2ZW4g YnkNCj4+ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNs aWVudHMsIGFuZCBlbmFibGUNCj4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+PiA+PiA+Pj4gPj4g Pj4gZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGlj eQ0KPj4gPj5kcml2ZS4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IEkgY2FuIHNl ZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZQ0KPj4gPj5k cml2ZW4NCj4+ID4+ID4+PmJ5DQo+PiA+PiA+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNhdGlv biB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQgaXMNCj4+ID4+aGFyZGVyDQo+PiA+PiA+ Pj50bw0KPj4gPj4gPj4+ID4+c2VlDQo+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29y ayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmUNCj4+ID4+ID4+PiA+PiBk eW5hbWljaXR5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsgYmVoYXZpb3IuDQo+PiA+ PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRo YXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXMNCj4+ID4+b3V0c2lkZQ0KPj4gPj4gPj4+b2YN Cj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdy b3VwLiBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZQ0KPj4gPj50YXNrZWQgdG8NCj4+ID4+ID4+ PiA+PmFncmVlDQo+PiA+PiA+Pj4gPj4gPj5vbi4NCj4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5v dCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGENCj4+Y2VydGFpbg0K Pj4gPj4gPj4+d2F5Lg0KPj4gPj4gPj4+ID4+aXQNCj4+ID4+ID4+PiA+PiA+PiBpcyBqdXN0IHRo ZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+ID4+ID4+PiA+PiA+ Pg0KPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPj4gPj4gPj4+ID4+ID4+IEpvZWwNCj4+ID4+ID4+ PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlv biBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcw0KPj4gPj4gdGhhdA0KPj4gPj4gPj4+ID4+bmVlZHMN Cj4+ID4+ID4+PiA+PiA+Pj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBkaXN0cmli dXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gPj5hY3Jvc3MNCj4+ID4+ ID4+PmRhdGENCj4+ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0 aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj4gY29tcGxleA0KPj4g Pj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBT RkYgc2VlbXMgbGlrZSBhDQo+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4+IGFy Y2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+ PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4NCj4+ ZHluYW1pYw0KPj4gPj4gPj4+IHJvdXRpbmcsDQo+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxl IGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mDQo+PndoaWNoDQo+PiA+ PmFyZQ0KPj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiA+PiA+Pj4gPj4gPj4+IHByb2JsZW1zIHRoYXQg aGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8NCj4+ID4+ID4+PiA+ PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSXQgYWxzbyBzZWVtcyB0aGF0IGlmIGl0IHJlYWxseSBp cyBtb3JlIGNvbXBsaWNhdGVkLCB0aGF0DQo+PmlzDQo+PiA+PmENCj4+ID4+ID4+Pmdvb2QNCj4+ ID4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4NCj4+ID4+ID4+ PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj4gPj4+ID4+ ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiA+PiA+Pj4gPj4g Pj4+IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNv bTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPj5JYW4NCj4+ID4+ID4+PlNtaXRoOw0KPj4g Pj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQNCj4+QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IFRoaXMg aXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQNCj4+cHJlZmVy DQo+PiA+PndlDQo+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+ID4+ID4+PiA+PiA+Pj4gZGVj aWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlDQo+PiA+PmltcGxl bWVudGF0aW9ucy4NCj4+ID4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpv ciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+ID4+cmVxdWlyZW1lbnRzDQo+PiA+PiA+Pj5hbmQN Cj4+ID4+ID4+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZz Lg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQg b2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ID4+dGhhdA0KPj4gPj4g Pj4+IG5lZWRzDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5IGRp c3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuDQo+PiBhY3Jvc3MNCj4+ ID4+ID4+PmRhdGENCj4+ID4+ID4+PiA+PiA+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3Ry YXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaA0KPj5hbmQNCj4+ID4+ID4+PmNvbXBsZXgNCj4+ ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBT RkYgc2VlbXMgbGlrZSBhDQo+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4gYXJj aGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+ IFlvdXJzLA0KPj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+ Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+PiA+PiA+Pj4gPj4gPj4+DQo+ PiA+PiA+Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+ PiA+PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiAgIElzIHRoZSBl bmQgdG8gZW5kDQo+PnNlbGVjdGlvbg0KPj4gPj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4gKHRvcC1s ZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhlDQo+PiA+ PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVy aGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5DQo+PiA+PnRoZQ0KPj4gPj4g Pj4+ID4+U0ZGcyk/DQo+PiA+PiA+Pj4gPj4gPj4+PiBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1 aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9uLg0KPj5BbmQNCj4+ID4+ID4+PnN1cmVseSwNCj4+ ID4+ID4+PiA+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90IHJl bGVnYXRlZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ID4+ID4+ PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUg ZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbg0KPj4gdGhvdWdoDQo+PiA+PiBhDQo+PiA+PiA+Pj4g Pj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVy aGFwcw0KPj5sb2NhbA0KPj4gPj4gPj4+ID4+c2VsZWN0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+PiBw b2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy4N Cj4+ID4+VGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBh biBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLg0KPj4gPj5NeQ0KPj4gPj4gPj4+ID4+ID4+Pj4g cmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseSBkcml2ZW4N Cj4+YnkNCj4+ID4+ID4+PiA+PmluY3JlYXNlZA0KPj4gPj4gPj4+ID4+ID4+Pj4gcmVzaWxpZW5j eSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gICBXaXRoIGENCj4+Z2xvYmFsDQo+ PiA+PiA+Pj5wYXRoDQo+PiA+PiA+Pj4gPj5pZA0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gs IGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcgdG8NCj4+ID4+YWx0 ZXINCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUg Zm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkDQo+PmVuZC10by1lbmQNCj4+ID4+ID4+PnBhdGgu DQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiA+PiA+Pj4gPj4g Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJu IERpcmVjdA0KPj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEw LA0KPj4yMDE0DQo+PiA+PiA2OjE1DQo+PiA+PiA+Pj4gUE0NCj4+ID4+ID4+PiA+PiA+Pj4+IFRv OiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBJLlNtaXRoQEY1 LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+IFN1YmplY3Q6DQo+PiA+PiBSZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUg Y2FzZSBvZiBTRjEgbmVlZGluZw0KPj50bw0KPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+ Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlv biBhdCB0aGUNCj4+ZXhpdA0KPj4gPj5mcm9tDQo+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+ PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBr ZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93 IHRoZXkNCj4+ID4+IGNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBv c2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0 aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueQ0KPj4gPj5zb3J0DQo+PiA+ PiA+Pj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0g dG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlDQo+PiA+PnBhdGgNCj4+ID4+ID4+PihhbGwNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlv bi4gSSBiZWxpZXZlDQo+PnRoaXMNCj4+ID4+ID4+Pm1lYW5zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g ZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyDQo+PmNob29z ZXMgYQ0KPj4gPj5TRg0KPj4gPj4gPj4+ID4+Q2hhaW4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQg dGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsDQo+PiA+ PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBh IG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNGSShuKQ0KPj4gPj4gPj4+IGlzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcg dG8gdGhlIGRyYWZ0LA0KPj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291 bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4+ID4+ID4+PiBv cHBvc2VkDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQg dGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZg0KPj4gPj50aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVy ZS0wMDoNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGlu dG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ID4+bmVjZXNzYXJ5DQo+PiA+PiA+Pj50bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3 aWxsIGJlIHVzZWQsDQo+PiA+PmFuZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhl IHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MNCj4+ID4+bmV0d29yaw0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBT RkMgcmVzdWx0cyBpbiB0aGUNCj4+ID4+ID4+PmNyZWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4gPj5m b3J3YXJkaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJ biBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50 aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlv biAob3INCj4+ID4+bm9uLWluaXRpYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRp b24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkg YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVu dCB3aXRoIGEgc2VydmljZQ0KPj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVj bGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4+ID4+ U0ZQLCBhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0 YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+PnRvDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+ PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPG1haWx0bzoqSS5TbWl0aEBGNS5jb20+PEkuU21p dGhARjUuY29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRv OiAqSm9lbCBIYWxwZXJuDQo+PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPj4gPj4gTS4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBl cm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5n QHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0BzY2Uu DQo+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0K Pj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQNCj4+ID4+QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1l ZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PnRoYXQgaXMNCj4+ID4+ID4+PndoYXQNCj4+ ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2 aWNlIGNoYWlucyBpcw0KPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g YXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoDQo+ PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29uY2VwdGlvbi4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFp bSwgc29tZSBkZWdyZWUgb2YNCj4+ID4+YXNwaXJhdGlvbg0KPj4gPj4gdG8NCj4+ID4+ID4+PiA+ PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhl DQo+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj4+LQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHlvdSBk b24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFuDQo+PiA+ PiA+Pj5hcmJpdHJhcnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5 b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+PiA+PiA+Pj4gPj5pbnRlbnRpb25h bA0KPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25z IHRoYXQgaGF2ZSBsYXN0aW5nDQo+PiA+PmltcGFjdHMNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWdh cmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksDQo+PiA+PmFk ZHJlc3MNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBU aGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5 IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTog Sm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmpt aC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+U2VudDoNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS4N Cj4+ID4+IEhhbHBlcm47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNh PG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdDQo+PiA+PlNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+ Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0 aCBtZSBhdCBhbGwgaW4gdGhpcw0KPj4gPj5yZWdhcmQuDQo+PiA+PiA+Pj5JDQo+PiA+PiA+Pj4g Pj5hbQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0 dXJlIG9yIHRoZSBzb2x1dGlvbg0KPj4gPj5wcm9oaWJpdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRl cGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0bw0KPj4g Pj5IdWFuZydzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWlu ZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlDQo+PiA+PiByZXF1aXJlZA0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWlu ZyB0byBwcm9oaWJpdA0KPj5zdWNoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVy IHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb24NCj4+ID4+IG1hbnkNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4g SSBoYXBwZW4gdG8NCj4+dGhpbmsNCj4+ID4+dGhhdA0KPj4gPj4gPj4+ID4+dGhleQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZv aWRpbmcgYXR0ZW1wdGluZyB0bw0KPj4gPj5rbm93DQo+PiA+PiA+Pj53aGF0DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdl IHRlbnMgb2YNCj4+ID4+ID4+Pm1pbGxpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFu ZCBkYXRhIGNlbnRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGVudmlyb25tZW50cyB0b2RheS4gWW91 IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4NCj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdQ0K Pj4gYXJlDQo+PiA+PiBvbmx5DQo+PiA+PiA+Pj4gPj4gZ29pbmcNCj4+ID4+ID4+PiA+PiA+Pj4+ PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5DQo+ PnNtYWxsDQo+PiA+PiA+Pj4gbnVtYmVycw0KPj4gPj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBz ZXJ2aWNlIHBhdGhzPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBZ b3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBldmVyIG5lZWQgbW9yZQ0KPj4g dGhhbg0KPj4gPj4gPj4+IDY0SyINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gY29tZm9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gW3NmYy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhh bHBlcm4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBbam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBK dWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86DQo+PiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2E8 bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLA0KPj5hbmQNCj4+ID4+ID4+PkxvYWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IE5vLCBp dCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRvIGRlcGxveSB0aGUNCj4+ID4+ID4+ PmFyY2h0aWV0dXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhcnRpY3VsYXJseSBiYWRseSwgdGhl eSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mDQo+PnRoZWlyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZA0K Pj4gdXNlDQo+PiA+PiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5j ZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g YXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZQ0KPj5k b2VzDQo+PiA+PiA+Pj5wZXJtaXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFk IG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUNCj4+IHBlcm1pdHMNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1 aXJlZCBieQ0KPj4gPj50aGUNCj4+ID4+ID4+PndvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0 IGlzbid0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3Vycywg Sm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0 LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4g SWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGwNCj4+bWVh bg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIg dGhhbiB0aGUgcm91dGluZw0KPj50YWJsZQ0KPj4gPj5vZiBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ PiBjb3JlIHJvdXRlci4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ PiBDaGFuZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3 LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCBm cm9tDQo+PjENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNl cnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZQ0KPj50aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4g b3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5DQo+PiA+ PmNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBhdm9pZCBhbnkgdXNl IG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZA0KPj4gPj4gcHJvdmlzaW9uDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5B UElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0 aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgaG9wDQo+PiA+PiBzZXJ2aWNlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9w Pw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYNCj4+IE9mDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVs eSAxMCwgMjAxNA0KPj4gPj4zOjAzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1 Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5j b208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNl DQo+PiBDaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVj eSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFs bCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmll ciBjYW4gYmUgdXNlZCB0bw0KPj4gPj4gZGVyaXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo ZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFu c3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cw0K Pj5tdXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRo IGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlv biB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb24NCj4+dGhpcw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBh dGgNCj4+ID4+IGlkZW50aWZpZXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90 aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbg0KPj4gPj4gcmVzdWx0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVk KSB0cmFuc3BvcnQgbmV4dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAx MTowNCBBTSwgTHVjeSB5b25nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVh d2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+DQo+PiA+PiA8bWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3Vs ZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZg0KPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+PiA+PmFj dGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1 Y3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206 KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiBCZWhhbGYNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86T2YqbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gPj4gPj4+ICpTZW50OipUaHVyc2Rh eSwNCj4+ID4+ID4+PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6 MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9l bGhhbHBlcm4uY29tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2Zj QGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBv dXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVu dGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+PmRlcml2ZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8g aGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhz IHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBp biB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkg b24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNl bnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+IHJlcXVpcmVkDQo+PiA+ PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBI b3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2VkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtl YmlhbmNAYW9sLmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpIDoqbWVyY3JlZGkg OQ0KPj4gPj4ganVpbGxldA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6 KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9y Zw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoq UmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuDQo+PlNGDQo+PiA+PiBDaGFpbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQg U0YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhl ciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzDQo+PiA+PmNsZWFy IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lDQo+PmFncmVl cw0KPj4gPj5vbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9p bnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+PndoZXRoZXINCj4+ID4+aXQgaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkg c3BlY2lmeSB3aGF0DQo+PiA+PnRoZSBJRA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUg U0ZDIEhlYWRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNob3VsZA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQN Cj4+ID4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhh dCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+PmRyYWZ0cw0KPj4gPj50bw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2Vk IG9uIGNoYWluDQo+PiBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hv aWNlIG9mIGNoYWluIG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcGF0aCB0bw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJp Z3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZQ0KPj4g Pj4gb25lDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0 aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+IHZlbmRvcnMNCj4+ID4+IG9ubHkNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZD Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4g Pj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206Kmpt aEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJu LmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPG1haWx0bzoq c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KPj4g KlNlbnQ6KlR1ZXNkYXksDQo+PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIw MTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+PkxvYWQNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhv dyB0byBjbGVhcmx5DQo+PmFuc3dlcg0KPj4gPj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51 bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPj4gPj4gPj4+ IHByb3Bvc2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJh ZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4+IHdvcmtpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPj4gaW1w cm92ZQ0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCBy ZWFkZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4NCj4+ID4+dGhlDQo+PiA+PiBXRw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3 YXkgdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBncm91cCBpbnRlbmRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0K Pj4gPj5wZXJzb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRo YXQgaGVscHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQNCj4+ ID4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRh dGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZQ0KPj5hcmUNCj4+ID4+IG5vdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUg ZW50aXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWlu aW5nLiBUaGF0IHdvdWxkIGVuY29tcGFzcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNT LCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQo+PnZpcnR1YWwNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkg b3RoZXINCj4+ID4+IGFzcGVjdHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVh cmx5IG5lZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJn ZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgNCj4+ID4+YWJvdmUNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25p bmcsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVk IGJ5IHRoZSB3b3JrIHdlIGFyZQ0KPj4gZG9pbmcuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZz IHNlcnZpY2UgcGF0aCwNCj4+YXMgSQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5k DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVk IHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdA0KPj4gPj5sZWFz dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQg YmFsYW5jaW5nIGNhbiBhbmQNCj4+d2lsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZQ0KPj4gPj5tb3JlLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0 byBwZXJtaXQgYWxsIG9mDQo+PiA+PnRoZXNlLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQg bm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gYmUgdXNlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5j aW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kDQo+PiA+PnVzZXIuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1 c2VyDQo+PnBhY2tldHMsDQo+PiA+PmFuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmll cyB0aGVtIChvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4+ ID4+aW5zdGFuY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMg cGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj4gPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWlu aW5nLg0KPj4gPj5JdCdzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBhZmZl Y3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+PiA+PiBjaGFpbmluZyBpcw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0 aGUNCj4+ID4+YXJjaHRpZWN0dXJlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFy Y2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9k aWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRo YXQgaXMsIG9uZQ0KPj5jYW4NCj4+ID4+aGF2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUNCj4+cG9pbnQNCj4+ ID4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGZvciBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4+ID4+YnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGNvbGxlY3Rpb24gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNh bCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+Pm9uZSBvcg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxp a2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRy ZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0 byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+PiA+Pm1lY2hhbmlzbXMuDQo+PiA+ PiBJdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxl IHRvIHZhcmlvdXMgY29udHJvbA0KPj4gPj5tZWNoYW5pc21zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LA0K Pj5hbmQNCj4+ID4+dm0NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhl IGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+PnBlcm1pdHRpbmcNCj4+ID4+dGhpcw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRo YXQgb3VyDQo+PiA+PnRlcm1pbm9sb2d5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90 IGxlYWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNp bmcgZG9uZSBieQ0KPj5zZWxlY3RpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBh dGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdA0KPj4gPj50cmFmZmljDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3 YW50IHRvIHJlcXVpcmUNCj4+IHRoYXQNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBn aXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSBwbGFjZSBpbg0KPj50aGUN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhl c2UgbWF5IGJlDQo+PmNvbWJpbmVkLiBJDQo+PiA+PiB0ZW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZQ0KPj4g Pj5jaGFpbmluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBh IGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXINCj4+aXMNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBv bmUuDQo+PiBUaHVzLA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9m IHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRp ZmZlcmVudA0KPj4gPj5zaW5ndWxhcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcw0KPj5pbg0KPj4gPj50aGUN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVh biB3aGVuIEkgdGFsayBhYm91dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWlu IGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYQ0KPj4gPj4gc2VxdWVuY2UNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0 byBhIHN1YnNldCBvZg0KPj4gPj5wYWNrZXRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBp cyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mDQo+PnRyYWZmaWMNCj4+ ID4+aXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRl bnQgaW5zcGVjdGlvbiwgYW5kDQo+PmZpcmV3YWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdo aWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUNCj4+Y2FjaGUN Cj4+ID4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0 aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRv IGRpcmVjdCB0aGUNCj4+cGFja2V0cy4NCj4+IEENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vy dmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4+ID4+bG9jYXRp b25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlv bnMgd2lsbCBiZSBzaW5ndWxhciBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQg c2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4+ID4+bWF5IGJlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBi ZSBhZGRyZXNzZWQgYXMNCj4+IHBvcnRzDQo+PiA+PiBvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+PiA+Pmxv Y2F0aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUNCj4+IGFuZA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhl IFNGQw0KPj5ncm91cCwNCj4+ID4+IHdlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRv IGJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBs ZXZlbCBhYnN0cmFjdGlvbiwgdGhlDQo+PiA+PnNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8NCj4+ IHRhbGsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGgg cGFja2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwg b2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZQ0KPj4gcGF0aA0KPj4gPj4g bWF5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBU aGlzIGFyY2hpdGVjdHVyZSBkZWFscw0KPj4gPj53aXRoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKQ0KPj5v bg0KPj4gPj5sb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhl cmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+YmVoYXZpb3JzDQo+PiA+PiB3aGljaA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1l Y2hhbmlzbXMgKGluDQo+PiA+Pm11Y2gNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUg d2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+ PiBwcm92aXNpb24NCj4+ID4+IHdlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ ID4+ID4+PiA+PiA+Pj4+PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmlj YXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4+ID4+IG5lY2Vzc2FyeS4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNo YWluLiBCYXNlZCBvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFi bGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uDQo+PnBvaW50Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxh aW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuDQo+PklmIGl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRv ZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcNCj4+ID4+ IGdyb3VwLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFk ZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZA0KPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Y29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlDQo+PiA+ PiBpbnRlbnQsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2Ug YWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nDQo+PiA+Pmdyb3VwDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3Vy ZQ0KPj4gPj53aGF0IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4g Pj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+ Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFp bGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBzZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+ PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4g Pj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0K Pj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ ID4+ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQo+PiA+PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+ PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcg bGlzdA0KPj4gPj4gPj4+ID4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4g Pj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+ PiA+Pj4NCj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPg0KPj4gPj4gPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4g Pj4gPnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo= --_000_CFE587DA2D547jguicharciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <264E8FA925F5EA43930B2CC124A7C56C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Zb3VyIGRlZmlu aXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBh dGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEg c3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2Vz IGJhc2VkIHVwb24gd2hpY2gNCiBuZXh0LWhvcHMgdG8gdGhvc2UgaW5zdGFuY2VzIGFyZSBhdmFp bGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBpcyBpbiBwbGF5 LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0aGUgbmV0d29yayB5 b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3 aGljaCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wDQogd291 bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNlcnZpY2Ug Y2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wgLyBtZWNo YW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWdu OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzptaWtlYmlh bmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgSnVseSAxMSwg MjAxNCBhdCAxMjoxOCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPkppbSBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbjE5 MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsbW9ub3NwYWNlIiBz aXplPSIyIj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhbHRvLWZvbnQsIGFyaWFs OyBmb250LXNpemU6IDE0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkkgdGhpbmsgdGhpcyBp cyB0aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBhbHRvLWZvbnQsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IHdoaXRl LXNwYWNlOiBwcmUtd3JhcDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBhbHRvLWZvbnQsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsiPiZndDsgSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBhbHRvLWZvbnQsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhbHRvLWZv bnQsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZndDsg c3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9u IHRoZXJlb2YpLiBJPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IGFsdG8tZm9udCwgYXJp YWw7IGZvbnQtc2l6ZTogMTRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IGFsdG8tZm9udCwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgd2hpdGUt c3BhY2U6IHByZS13cmFwOyI+Jmd0OyBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDi gJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogYWx0by1mb250LCBhcmlhbDsgZm9udC1zaXplOiAxNHB4 OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYWx0 by1mb250LCBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4m Z3Q7IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrPC9zcGFuPjxicj4NCjxicj4N CkJ5IGRlZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICZxdW90O3NlcnZpY2UgcGF0aCZxdW90OyB0 byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiAmbmJzcDtJbiB0 aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgJnF1b3Q7c2VydmljZSBwYXRoIGlkZW50aWZp ZXImcXVvdDsgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkg JnF1b3Q7W2RvZXMgbm90XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNlcyZxdW90Oy48YnI+DQo8 YnI+DQo8L2Rpdj4NCjwvZm9udD4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8aHIgc3R5bGU9ImJvcmRlcjowO2hlaWdodDoxcHg7Y29sb3I6Izk5OTtiYWNrZ3JvdW5k LWNvbG9yOiM5OTk7d2lkdGg6MTAwJTttYXJnaW46MCAwIDlweCAwO3BhZGRpbmc6MDsiPg0KPGI+ RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNp c2NvLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNo YXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFMQSwgTUFSSUEgSCZs dDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDss PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssSm9lbCBN LiBIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiZndDssUm9uDQogUGFya2VyJmx0OzxhIGhyZWY9Im1haWx0bzpSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJy Pg0KPGJyPg0KPHRpdGxlPjwvdGl0bGU+DQpNYXJpYSw8YnI+DQo8YnI+DQpJIHRoaW5rIG9mIGl0 IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgc2ltcGx5IGEgcG9pbnRl ciB0bzxicj4NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBt YXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGE8YnI+DQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLSZn dDtTMi0mZ3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeTxi cj4NCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRvIGZsb3cg dGhyb3VnaCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZlciwgeW91IGRvICpub3QqIGhhdmUgdG8g ZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSTxicj4NCndpbGwgYXJn dWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxs eSkuIFlvdTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmll ciB0byBwb2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+DQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1h dGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhPGJyPg0Kc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3Vs ZCBjb250YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG 4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVhcm48YnI+DQp0aG9zZSBuZXh0LWhvcHMg aXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhIGNlbnRyYWxpemVk PGJyPg0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0g ZHluYW1pY2FsbHkgdGhyb3VnaDxicj4NCnNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVy IC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvPGJyPg0Kc2F5IHRoYXQgdGhl IHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhIHBy aW9yaTxicj4NCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29tZSB3 b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvPGJyPg0Kc28uPGJyPg0KPGJyPg0KTGV04oCZcyB0 YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjo8YnI+DQo8YnI+DQpJ IGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMxLSZndDtTMi0m Z3Q7UzMuIEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBi ZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTxicj4NCnNwZWNp ZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVy ZW9mKS4gSTxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0 aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxicj4NCmFuZCB0aGVuIHB1 c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMg YXJlPGJyPg0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93IGF0IGEgZ2l2ZW4g U0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlczxicj4NCndpdGggc2VydmljZSBwYXRoIGlkZW50aWZp ZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhPGJyPg0Kc3RydWN0 dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzMgYW5kIHRoZSBp bmRleCBpbiB0aGUgU0ZDPGJyPg0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhhY3RseSB3 aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlPGJyPg0KYXJlIGF0IFMyIGlu IHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9w IHRvPGJyPg0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlz IHJlYWNoYWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0LCAxMToyNiBBTSwgJnF1b3Q7TkFQSUVS QUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1u MTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0ppbSw8YnI+DQomZ3Q7 PGJyPg0KJmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAm cXVvdDtzZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8YnI+DQomZ3Q7JnF1b3Q7c2VydmljZSBwYXRo IGlkZW50aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQg YWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoPGJyPg0KJmd0O2lzIG15 IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNp b24gd2hpY2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6 ZWQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDtNYXJpYTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyA8 YnI+DQo8YnIgY2xhc3M9IiI+DQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbPGEgaHJl Zj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbTwv YT5dPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEx OjE1IEFNPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+OyBKb2VsIE0uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGFscGVy bjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVu ZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXI8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMgb3Igd2h5IGNh bGxpbmcgaXQgYSBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgY2hhaW4gaWRlbnRpZmll ciBtYWtlcyBhbnkgZGlmZmVyZW5jZT88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyBPbiA3LzExLzE0LCAxMDo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJ QSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQu Y29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0O0RpdHRvLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ XTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwg MjAxNCAxMDozMSBBTTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJv bjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgUmUtLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3Qg dGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDtkcmFmdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGlu IGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ZGlzdHJpYnV0ZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtb2RlbCBpcyBu b3QgYWxsb3dlZC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRl ZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7c2hvdWxkIGJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlkZWQg aW5zdGVhZC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IENoZWVycyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBN ZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDstLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RGUgOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBk ZSBKaW0gR3VpY2hhcmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7KGpndWlj aGFyKTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtFbnZvecOpIDogdmVuZHJl ZGkgMTEganVpbGxldCAyMDE0IDE2OjE4PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0O8OAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2sgYnV0IHdo ZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0 eTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9oaWJpdGVkPyBJZiB5b3Ug d2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3dpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQg dGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDtsb29rdXA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJ IGFtIG5vdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7c3VyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7aG93PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3RoZSBhcmNo aXRlY3R1cmUgcHJldmVudHMgdGhhdD88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTEvMTQsIDk6NTgg QU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1u MTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1dGVseS48YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIEppbSBHdWljaGFyZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyhqZ3VpY2hhcik8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU08YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsg Sm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij4NCnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoZW4gSSBtaXN1 bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQgaWY8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgeW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNp b24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7d2lsbDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Zm9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhl IGNoYWluIHRoZW4geW91PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtiZXR0ZXI8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21ha2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBm b3J3YXJkaW5nIGxvZ2ljIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtyZWFjaDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBuZXh0LW5leHQtU0YgZm9yIHRoZSBj aGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRyb3VibGUuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTEvMTQsIDk6NDggQU0sICZxdW90O05BUElFUkFMQSwg TUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFA YXR0LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDtBYnNvbHV0ZWx5IG5vdC4gU2Vydmlj ZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDtyZWxldmFudDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NG RnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O3doZW4g dGhleSAmcXVvdDthcnJpdmUmcXVvdDsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVm PSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIE9uIEJlaGFsZiBPZiBKaW08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0d1aWNoYXJkPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7KGpndWlj aGFyKTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBS b24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1 YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy czxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBXZWxs IEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2Q8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3Byb3Bvc2FsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJl IGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7U0Y8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aXRoaW48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZW50aXJlIFNG QyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG88YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0O2tub3c8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtwcmlvcmk8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgd2hp Y2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7cG9pbnQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2luPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGltZS48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gNy8xMC8x NCwgMTE6NTMgUE0sICZxdW90O0pvZWwgTS4gSGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91dCB0aGlz LCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJvYmxlbTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 d2l0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7eW91cjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7cHJvcG9zYWwgYXMgSSB1 bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3Q8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt1bmRlcnN0YW5kPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpdC4pPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1RoZSBw cm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmV4dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBmdW5jdGlvbiB0aGF0 IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDt0byksPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtpbjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2V2ZXJ5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZXJ2aWNlIGNoYWluIHRoYXQgZ29l cyB0aHJvdWdoIGl0LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDtTaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxs IHNlcnZpY2VzLCB0aGF0IG1lYW5zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZXZl cnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0O1NGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRl ZnVsIGxvYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtiYWxh bmNlci48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0O0kgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwg YW5kIC8gb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3N0YXRlZnVsLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7QnV0IGhh dmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZmxvdzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwg bG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7YWNjZXB0YWJsZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW1wb3NpdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7WW91cnMsPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtKb2VsPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcv MTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFBhcnQgb2YgbXkg cGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpczxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7d29yazxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O3NlbnNpYmx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJv bm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtzZXJ2aWNlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxpdGll cyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3dpbGw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2JlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUgc2Vy dmljZSBjaGFpbnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RvIGJlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmVuIGJ5PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEJTUyB0 b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3NlbGYtc2VsZWN0aW9uPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3k8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlLjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGNhbiBz ZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O2J5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVz Y3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDtoYXJkZXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlZTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxs b3cgbW9yZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBkeW5hbWljaXR5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQg aXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O291dHNpZGU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzY29wZSBvZiB0aGUgd29ya2lu ZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3Rhc2tlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O2FncmVlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7b24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFNvIEkgZG8gbm90IGNsYWltIHRo YXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Y2VydGFpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dheS48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpdDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsgWW91cnMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgT24gNy8xMC8xNCwgOTo1 OCBQTSwgSWFuIFNtaXRoIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBv ZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IHRoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDtuZWVkczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7dG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBiZSB3aWRl bHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fjcm9zczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1p bmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDth bmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tcGxleDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZG IHNlZW1zIGxpa2UgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O2RpZmZpY3VsdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0 ZWQgdGhhbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ZHluYW1pYzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByb3V0aW5nLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlwZXItc2NhbGUg ZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Y8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0O3doaWNoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthcmU8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtiaWdnZXI8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1l bnRlZD88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5 IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2lzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Z29vZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGlj YXRlZC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUgUE08YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRvOiBSb24g UGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20iPg0KbWlrZWJpYW5jQGFvbC5jb208L2E+OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7SWFu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U21pdGg7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7QmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBp cyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7cHJlZmVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt3ZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDthY3R1YWxseTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxs b3cgYWxsIHBvc3NpYmxlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtpbXBsZW1lbnRh dGlvbnMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0 aGUgY29udHJvbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVxdWlyZW1lbnRzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YW5kPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg ZnVuY3Rpb25hbGl0eSBvZiBTRkZzLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFt b3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBuZWVkczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWlu dGFpbmVkLCBwb3RlbnRpYWxseSBldmVuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgYWNyb3NzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGF0YTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Y2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7YW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Y29tcGxleDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0 aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEpvZWw8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhp cyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gJm5ic3A7IElzIHRoZSBlbmQgdG8gZW5kPGJyIGNs YXNzPSIiPg0KJmd0OyZndDtzZWxlY3Rpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O29mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFs bHkgKHBlcmhhcHMgYnkgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7Y2xhc3NpZmllcik8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBvciBob3AtYnktaG9wIChw ZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHk8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O1NGRnMpPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFN1Y2ggc2VsZWN0aW9uIGlzIG5v dCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtB bmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtzdXJlbHksPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdh dGVkIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7aW1wbGVtZW50YXRpb24mcXVvdDsuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0 ZWQgYXBwcm9hY2ggZXZlbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRob3VnaDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBncmVhdGVyIGFtb3VudCBvZiBk YXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 bG9jYWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDtzZWxlY3Rpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRp c3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O1RoaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1l bmQgcGF0aCBpZCBhdCBhbGwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtNeTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJp bHkgZHJpdmVuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtieTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2luY3JlYXNlZDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJl c2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICZuYnNwOyBXaXRoIGE8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2dsb2JhbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O3BhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDtpZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoLCBjb25zaWRlciBmYWls dXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDthbHRlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVy eSBhZmZlY3RlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ZW5kLXRvLWVuZDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGguPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBSb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9 Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBv biBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJt YWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4u Y29tPC9hPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsy MDE0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgNjoxNTxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBQTTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVm PSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOkkuU21pdGhARjUuY29tIj4NCkkuU21pdGhARjUuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IFN1YmplY3Q6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgUmU6PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMg dGhlIGNhc2Ugb2YgU0YxIG5lZWRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RvPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW5mbHVlbmNlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRp b24gYXQgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtleGl0PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDtmcm9tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU0YxLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25z PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtsb2dpY2FsbHk8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBz ZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cgdGhleTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGNob29zZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY29tcG9zZSB0aGVtIGZv ciAmcXVvdDtzZXJ2aWNlJnF1b3Q7IGRlbGl2ZXJ5LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgWW91cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDY6 MTAgUE0sIDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5j b208L2E+IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0 aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7c29ydDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O29m PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNh dGUgdGhhdCB0aGUgZW50aXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtwYXRoPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGFsbDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxp ZXZlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7bWVhbnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZWl0aGVyIGF0IHRoZSBj bGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtj aG9vc2VzIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NGPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueSBj YXNlLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmU8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTRkkobik8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV0ZXJtaW5l ZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWhhdmlvciB3b3Vs ZCBiZSBjb25zaWRlcmVkICZxdW90O2JyYW5jaGluZyZxdW90OyB0byBhIG5ldyBTRlAgYXM8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgb3Bwb3NlZDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBp bnN0YW5jZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29y ayBpdCBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmVjZXNzYXJ5PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNl ZCw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZCB0bzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtuZXR3b3JrPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0 aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtjcmVhdGlvbjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5k IGlzIHVzZWQgZm9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtmb3J3YXJkaW5nPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29y ZHMsIGFuIFNGUCBpcyB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24gb2Yg dGhlIGRlZmluZWQgU0ZDLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtub24taW5pdGlhbDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQ LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBp Y2FsbHkgcGVyZm9ybWVkIGJ5IGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZpY2F0aW9u IGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDtmdW5jdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlY2xhc3NpZmljYXRp b24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDtTRlAsIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1cGRhdGUgb2YgdGhl IGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3JlZmVycmVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7dG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzICZxdW90O2JyYW5jaGluZyZxdW90 Oy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS08YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICpGcm9tOiA8YSBocmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29tIj4qSS5TbWl0aEBGNS5j b208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb208 L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86ICpKb2VsIEhhbHBlcm48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyBEaXJlY3QmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LEpvZWw8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDtIYWxwZXJuJmx0 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29t PC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+aHVhbmdAc2Nl LmNhcmxldG9uLmNhPC9hPiZsdDtodWFuZ0BzY2UuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNhcmxldG9uLjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2Nh Jmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAq U2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTdWJqZWN0 OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQ8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0JhbGFuY2VyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxl IGRlcGxveW1lbnRzIChhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RoYXQgaXM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7cHJlY29uY2VpdmVkPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUg YnVyZGVuZWQgd2l0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoYXQ8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgcHJlY29uY2VwdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhl cmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXNwaXJhdGlvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9y IHRoZSBsaWZlc3BhbiBvZiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FyY2hp dGVjdHVyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Oy08YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgeW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkg c2F5aW5nIHRoYXQgYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDthcmJpdHJhcnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbnVtYmVyIGlzICZxdW90O3RvbyBmYXImcXVv dDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNuJ3Q8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbnRlbnRpb25hbDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFz dGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW1wYWN0czxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHks PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthZGRyZXNzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3Q8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFs8YSBocmVmPSJtYWlsdG86am1oLmRp cmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPl08YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NlbnQ6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXJz ZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEhhbHBlcm47PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwv YT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1Ympl Y3Q6IFJlOiBbc2ZjXTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U2VydmljZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3Jl ZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDty ZWdhcmQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7STxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2FtPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBz b2x1dGlvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cHJvaGliaXQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0 aW5nIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtIdWFuZydzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRz IGFyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHJlcXVpcmVkPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRv IHByb2hpYml0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtzdWNoPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo aW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbWFueTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmYWN0 b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG88YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0O3RoaW5rPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7dGhleTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZv aWRpbmcgYXR0ZW1wdGluZyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7a25vdzxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZTo8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEkgZGlzYWdyZWUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5z IG9mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7bWlsbGlvbnM8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmN1cnJlbnQgZmxv d3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXI8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBp bjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENsb3VkL0lQdjYv TW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3U8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGdvaW5nPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRo IGVxdWFsbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3NtYWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG51bWJlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYWN0 aXZlIHNlcnZpY2UgcGF0aHM/PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAmcXVvdDtubyBvbmUgd2lsbCBldmVyIG5l ZWQgbW9yZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgNjRLJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBm b3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29tZm9ydC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFs8 YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbPGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ XTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0 NiBQTSBUbzo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YSBo cmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8 L2E+OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7TG9hZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm8sIGl0IHdpbGwgbWVhbiB0 aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FyY2h0aWV0dXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBw YXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7dGhlaXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMuIFRoZSBh cmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IHVzZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9mPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cg dG8gd3JpdGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJv aGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2RvZXM8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwZXJtaXQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHN1Y2ggYWJ1c2UuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGll Y3R1cmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwZXJtaXRzPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3b3JrLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXNu J3QuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpv ZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0 LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsPGJy IGNsYXNzPSIiPg0KJmd0OyZndDttZWFuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYsMDAw LDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7dGFibGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29mIGE8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3JlIHJvdXRlci48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2Vs IE0uIEhhbHBlcm4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBhcmNo aXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb208YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OzE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRoIHRv IDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 O3RoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0b3JzIGFyZSBwcmVwYXJl ZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDtjaG9vc2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0 bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxv YWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHByb3Zpc2lvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNjAsMDAwIHNlcnZpY2Ug cGF0aHMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwg TUFSSUEgSCB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdWwsPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQg aG9wPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgc2VydmljZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/ PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgTWFyaWE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpP biBCZWhhbGY8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBPZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDszOjAzPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5IHlvbmcgKkNjOiogPGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpvZWxoYWxwZXJuLmNvbTwvYT47PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47DQo8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5t aWtlYmlhbmNAYW9sLmNvbTwvYT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IENoYWlucyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5LDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE92 ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nLiBJwrlkPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG1ha2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtaW5vciBjaGFu Z2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG88YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBkZXJpdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvPGJyIGNsYXNz PSIiPg0KJmd0OyZndDtzaW1wbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlk ZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0O211c3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZl cnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBh c2tpbmcgZm9yIG9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGlzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhl IHBhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpZGVudGlmaWVyPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxv b2t1cCwgdGhhdCBsb29rdXAgY2FuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgcmVz dWx0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhIG9uZSBvciBtb3JlIChl cXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGhvcChzKS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDEwLCAy MDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdA aHVhd2VpLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OyI+bWFpbHRvOmx1Y3kueW9uZ0BodWF3 ZWkuY29tJmd0OzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90 ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3Qg bWFuZGF0ZSBvbmx5IHVzZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoZTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUg dGhlIGZvcndhcmRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FjdGlvbnMuPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgTHVjeTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10qT24iPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT248L2E+ IEJlaGFsZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv Ok9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgKlNlbnQ6KlRodXJzZGF5LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdWx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAxMCwgMjAxNCAyOjA2IEFNICpUbzo8YSBocmVmPSJtYWlsdG86Km1pa2ViaWFu Y0Bhb2wuY29tIj4qbWlrZWJpYW5jQGFvbC5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJmd0OztqbWhA am9lbGhhbHBlcm4uY29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb20mZ3Q7O2ptaEBqb2VsaGFs cGVybi5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZyI+bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86 c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmUtLDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGg8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRv IHVzZSB0aGF0IGlkZW50aWZpZXIgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2Rlcml2ZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBhY3Rpb25zLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2Y8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBldmVyeTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh dmFpbGFibGUgU0ZDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5n IHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHJlcXVpcmVkL2p1c3RpZmllZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBT RkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhhdCB3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBwcmVzZW50IGlu IGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg cmVxdWlyZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQg aW5mb3JtYXRpb24gaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZWQgdG88YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndhcmRpbmc8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYWN0aW9uczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBz b2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBNZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAqRGUgOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10qRGUiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGU8L2E+IGxhIHBhcnQ8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tIj5k ZSptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1haWx0bzptaWtlYmlhbmNA YW9sLmNvbTwvYT4mZ3Q7ICpFbnZvecOpIDoqbWVyY3JlZGkgOTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IGp1aWxsZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIw MTQgMjI6MDMgKsOAIDo8YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhA am9lbGhhbHBlcm4uY29tPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJmd0OztzZmNAaWV0Zi5vcmciPm1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJmd0OztzZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXMgYW55 b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0O1NGPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgQ2hhaW48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBTRjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRo PzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXIgdGhhbiBjbGFyaWZ5aW5n IHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQnczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Y2xlYXIgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhvc2Ugbm90PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBl dmVyeW9uZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YWdyZWVzPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDtvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlc2UgdGVy bXMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFy IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3aGV0aGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDtpdCBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGludGVu dCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDt0aGUgSUQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG9mIHRoZSBTRkMgSGVhZGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNob3VsZDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBv ciBpZiB0aGlzIGRyYWZ0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtzaW1wbHk8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJp Z3VvdXMsIGFsbG93aW5nIG90aGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtkcmFmdHM8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWlu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0 aCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUgbmVnb3RpYXRlZCBpbiB0 aGUgY29udHJvbC1wbGFuZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0 aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2U8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWU8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB2ZW5kb3JzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgb25seTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VwcG9ydGluZyBT RlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Oy0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOjxhIGhyZWY9 Im1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFscGVybi5jb208L2E+Jmx0 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29t PC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2Nq bWhAam9lbGhhbHBlcm4uY29tJmd0OyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhA am9lbGhhbHBlcm4uY29tJmd0OzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAqVG86PGEgaHJlZj0ibWFpbHRvOipzZmNAaWV0Zi5vcmciPipzZmNAaWV0Zi5vcmc8L2E+ Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnJTNjc2ZjQGlldGYub3JnJmd0OyI+bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9y ZyZndDs8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICpTZW50OipUdWVzZGF5LDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtMb2FkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJl IG91dCBob3cgdG8gY2xlYXJseTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YW5zd2VyPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDthPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJvcG9zZWQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3Vt aW5nIHdlIGNhbiBnZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB3b3JraW5nPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ug d2lsbCB3b3JrIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgaW1wcm92ZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgV0c8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc2N1c3Npb24gd2ls bCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ya2luZzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5kcy48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBC dXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGVyc29uYWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiB0aGlzIHJl Z2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDt3aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3 ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7YXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbm90PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUg YXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3M8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlvdXMgY29udHJv bCBhbmQgcG9saWN5IGZ1bmN0aW9ucyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3ZpcnR1YWw8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1l bnQsIGFuZCBtYW55IG90aGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgYXNwZWN0 cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xl YXJseSBuZWVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRl YWx0IHdpdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fib3ZlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGVyZSB3ZSBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVu Y3Rpb25pbmcsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgYXJlIG5vdCBk aXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyBkb2luZy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBz ZXJ2aWNlIHBhdGgsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDthcyBJPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2Fk IGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDts ZWFzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWUgZGlmZmVyZW50IHdh eXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3aWxs PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcmFjdCB3aXRoIHNlcnZpY2Ug Y2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7bW9yZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBvZiB0 aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3RoZXNlLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnV0IG5v dCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi ZSB1c2VkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhbnkgc29sdXRpb24u PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRo ZSBlbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2 ZXMgdXNlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7cGFja2V0cyw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2FuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kaWZp ZXMgdGhlbSAob3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFya3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNl cnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3RhbmNlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMg aXMgYW4gaW1wb3J0YW50PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGlu Y2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O0l0J3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlaGF2aW9yIG1heSBhZmZl Y3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgY2hhaW5pbmcgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvbmUu IEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7YXJjaHRpZWN0dXJlLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBm dW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lPGJyIGNs YXNzPSIiPg0KJmd0OyZndDtjYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhdmU8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YXBwZWFyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtw b2ludDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhY3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yIGE8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBp cyBhY3R1YWxseSBkZWxpdmVyZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2J5IGE8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5n PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtvbmUgb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlr ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGVjaG5pcXVlcyB0byBzaGFyZSBh IE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBJdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGlr ZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O21lY2hhbmlzbXMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCA8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2FuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dm08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24uIFRoZSBh cmNoaXRlY3R1cmFsIGltcGFjdCBvZiA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3Blcm1pdHRpbmc8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBv dXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rlcm1pbm9sb2d5PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFkPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJl YWRlcnMgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFyZSBw cm9oaWJpdGluZyBpdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFu Y2luZyBkb25lIGJ5IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7c2VsZWN0aW5nPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIHRoYXQgZGlyZWN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0cmFmZmljPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3 b3VsZCBub3Qgd2FudCB0byByZXF1aXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgdGhhdDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4g PGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhl c2UgbWF5IGJlIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Y29tYmluZWQuIEk8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0ZW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2Vydmlj ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hhaW5pbmc8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJl Y2F1c2UgY2x1c3RlciA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2lzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDthPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnb29kIHRl cm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgVGh1cyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2lu ZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtzaW5ndWxhcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBw bGFjZXMgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJv dXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgY2hhaW4gYW5kIHNl cnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgc2VxdWVuY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGxvZ2lj YWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2Y8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3BhY2tldHMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7dHJhZmZpYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXM8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBEUEksIGNoYXJnaW5nLCBj b250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2ZpcmV3YWxsPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQg aXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Y2FjaGU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgd2l0aG91dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYXQgaXMg bm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7cGFja2V0cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBBPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5j ZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdp bGwgYmUgc2luZ3VsYXIgb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsdXN0 ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5IGJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgcG9ydHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW4gU0ZGLiBUaGVyZSBhcmUg bWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7bG9jYXRpb25zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkgYmUga25v d24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyBhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Z3JvdXAsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRvIGJlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJh Y3Rpb24sIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2VydmljZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2Fy ZGluZy4gQW5kIHdlIG5lZWQgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB0YWxrPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNr ZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5l dHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICZxdW90 O2J1dCB0aGUgd2hvbGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwYXRoPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgbWF5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBu b3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFsczxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2l0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0 ZW0gKDIpIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7b248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2xvYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJhbGFuY2VycyBh Ym92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDti ZWhhdmlvcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3aGljaDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFp bmluZyBtZWNoYW5pc21zIChpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bXVjaDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdp bmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IHByb3Zpc2lvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHdlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlIGlzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmlj YXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBuZWNlc3NhcnkuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBU aGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJl LWNsYXNzaWZpY2F0aW9uIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7cG9pbnQuPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0O0lmIGl0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBk b2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgZ3JvdXAsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0 aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbnRlbnQsPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRj aCB0aGUgd29ya2luZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Z3JvdXA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwg dW5jbGVhciwgSSBhbSBub3Qgc3VyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2hh dCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5IG5leHQuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgWW91cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+ Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5n PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBzZmM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBzZmM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHNm YyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDtzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnNmYyBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj PC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CFE587DA2D547jguicharciscocom_-- From nobody Fri Jul 11 09: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 0C3B61B2BA9 for ; Fri, 11 Jul 2014 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 p5Iv_LYMpdH9 for ; Fri, 11 Jul 2014 09:31:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562431B2BAB for ; Fri, 11 Jul 2014 09:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63038; q=dns/txt; s=iport; t=1405096286; x=1406305886; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=w5mHn/b6zN8ZcZtthfVCWhvTEpSKpCLJcYvUO2FhKzg=; b=iGbDOEYas28vqhsOYYBMPGCYtSemcS4FhhHDXo07HmjJ3xDArVJaYOGY dbeEDU7xN4HGKPJ6j6hzDQZQ3W3hlfVBCfIo8waMGt3uDGl0rhOorxqvW QsTYWov+LZTiohmwgOZxkK81qr24oug4atiJkCWnI7a58VYQeHnVbDlQA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAO8PwFOtJA2K/2dsb2JhbABPCoMOUlqCcawJkXgKh0IBGXIWdYQDAQEBBAEBARcBCAQNMQkCFQQCAQgRAQMBAQECAiMDAgICJQsUAQIGCAIEARIbiBMDEQ2tWph+EwSBLIhRgyCBUAUsECICAgKCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="339175263" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2014 16:31:23 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGVHnk010324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:31:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:31:16 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Ron Parker" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AACNZ7AP//xIOAgABMIQD//74DgA== Date: Fri, 11 Jul 2014 16:31:15 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NbafglhQW52f7TgqWHJNF5Ds3kE Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:31:34 -0000 TWFyaWEsDQoNCk9uIDcvMTEvMTQsIDEyOjI2IFBNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4x OTIxQGF0dC5jb20+IHdyb3RlOg0KDQo+SmltLA0KPg0KPj4gSSB0aGluayBvZiBpdCB0aGlzIHdh eS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50ZXINCj4+dG8N Cj4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5n cy4gV2hlbiB5b3UgZGVmaW5lDQo+PmENCj4NCj5MZXQncyBwYXJrIGl0IGZvciBub3cuDQo+DQo+ PiBjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0 aW5nIHRoZSBTRlAgc3BlY2lmeQ0KPj4gdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3 YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0DQo+PlNGUC4NCj4NCj5Zb3UgYXJl IHRhbGtpbmcgYWJvdXQgdHJhZmZpYyBlbmdpbmVlcmluZyBvZiBwYXRocyB0aGF0IGEgc2Vydmlj ZSBjaGFpbg0KPmNhbiB0YWtlLiANCj5UaGlzIHN1cmVseSBjb3VsZCBiZSBkb25lL2FsbG93ZWQg YnV0IHRoaXMgY2Fubm90IGJlIGEgcmVxdWlyZW1lbnQgZm9yDQo+YWxsIHRyYWZmaWMuDQoNCkpp bT4gdGhhdOKAmXMgd2h5IEkgc2FpZCAqbWlnaHQqIC0gSU9XIHlvdSBkbyBub3QgaGF2ZSB0bywg aXRzIGEgZGVwbG95bWVudA0KY2hvaWNlIGFuZCBpcyBzdXBwb3J0ZWQgYnkgdGhlIGFyY2hpdGVj dHVyZS4NCg0KPiANCj4NCj4+IEhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMg ZnJvbSBhbiBhcmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQNCj4+KEkNCj4+IHdpbGwgYXJndWUgdGhh dCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlv dQ0KPj4gY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBv aW50IHRvIGEgZ2l2ZW4gU0ZDDQo+PmFuZA0KPg0KPg0KPklmIGFueXRoaW5nLCBJIGNvdWxkIGlt YWdlIGEgc2VydmljZSAqY2hhaW4qIChub3QgcGF0aCkgaWRlbnRpZmllcg0KPnBvaW50aW5nIHRv IGEgc3BlY2lmaWMgU0ZDIHN0cnVjdHVyZS4NCj4NCj4+IHRoZW4gcHVzaCB0aGF0IGluZm9ybWF0 aW9uIGludG8gdGhlIG5ldHdvcmsuIEF0IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGENCj4+IHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQg Y29udGFpbg0KPj50aGUNCj4+IG5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG 4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVhcm4NCj4+IHRob3NlIG5leHQtaG9wcyBp cyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRoZW0gZG93biBmcm9tIGENCj4+Y2VudHJhbGl6 ZWQNCj4+IGNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91Z2ggQ0xJLCBsZWFybiB0aGVt IGR5bmFtaWNhbGx5IHRocm91Z2gNCj4+IHNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVy IC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvDQo+PiBzYXkgdGhhdCB0aGUg c2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGENCj4+ cHJpb3JpDQo+PiBhbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAoYW5kIHNvbWUg d291bGQgc2F5IHJlY29tbWVuZGVkKSB0bw0KPj4gZG8NCj4+IHNvLg0KPg0KPkFncmVlLCBnaXZl biB0aGUgYWJvdmUgY29tbWVudCBhYm91dCAqY2hhaW4qIHZzICpwYXRoKiBpZGVudGlmaWVyLg0K PiANCj4+IExldOKAmXMgdGFrZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xl YXI6DQo+PiANCj4+IEkgZGVmaW5lIGFuIFNGQyAobGV04oCZcyByZWZlciB0byBpdCBhcyBTRkMt MSkgUzEtPlMyLT5TMy4gRm9yIGFyZ3VtZW50cw0KPj4gc2FrZSBsZXTigJlzIHNheSBJIHdhbnQg aXQgdG8gYmUgZnVsbHkgZHluYW1pYyBlLmcuIEkgZG9u4oCZdCB3YW50IHRvDQo+PnNwZWNpZnkN Cj4+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5h dGlvbiB0aGVyZW9mKS4gSQ0KPj4gYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCc MTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0bw0KPj5TMS0+UzItPlMzDQo+DQo+QWdhaW4s IGZvciBtZSB0aGlzIGlzICAqY2hhaW4qIGlkZW50aWZpZXIsIG5vdCB0aGUgIHBhdGggaWRlbnRp Zmllci4NCj4NCj4+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQg dGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQo+PiBwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9y bWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYw0KPj5hcnJpdmVzDQo+PiB3 aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1 cCBpbiB0aGUgZGF0YQ0KPj4gc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMx LT5TMi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQo+PiBlbmNhcHN1bGF0aW9uIHdpbGwg dGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkNCj4+ d2UNCj4+IGFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byBy ZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KPj4gUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0 ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCj4+IA0KPj4gT24gNy8xMS8xNCwgMTE6MjYg QU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQo+PiANCj4+ ID5KaW0sDQo+PiA+DQo+PiA+Q291bGQgeW91IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlv biBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCBhDQo+PiA+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVy Ij8NCj4+ID5JZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJl IGNob3NlbiBhcHJpb3JpDQo+Pih3aGljaA0KPj4gPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGlu ZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2gNCj4+ID5uZXh0LWhv cCBTRkYgdG8gcGljay4gIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uDQo+PiA+DQo+PiA+ TWFyaWENCj4+ID4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ PiBGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bV0NCj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTQ0KPj4gPj4gVG86 IE5BUElFUkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9lbCBN Lg0KPj4gPj4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ ID4+DQo+PiA+PiBJ4oCZbSBzb3JyeSBidXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdo eSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyDQo+PiA+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1 dGlvbiBvZiBTRiBuZXh0LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYQ0KPj5zZXJ2aWNlDQo+PiA+ PiBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0KPj4gPj4NCj4+ID4+IE9u IDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+ DQo+PiB3cm90ZToNCj4+ID4+DQo+PiA+PiA+RGl0dG8uDQo+PiA+PiA+DQo+PiA+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPj4gPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t XQ0KPj4gPj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+PiA+PiA+ PiBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBN LiBIYWxwZXJuOw0KPj4gUm9uDQo+PiA+PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4gPj4g Pj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+PiA+PiA+Pg0KPj4gPj4gPj4gUmUtLA0KPj4gPj4gPj4NCj4+ID4+ID4+IEZvciB3 aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRo ZQ0KPj4gPj5kcmFmdC4NCj4+ID4+ID4+DQo+PiA+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBh dGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlDQo+PmZ1bGwNCj4+ID4+ ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4gPj4gPj4N Cj4+ID4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRo ZSBzZXJ2aWNlIGNoYWluDQo+Pml0c2VsZg0KPj4gPj4gPj5zaG91bGQgYmUNCj4+ID4+ID4+IHBy b3ZpZGVkIGluc3RlYWQuDQo+PiA+PiA+Pg0KPj4gPj4gPj4gQ2hlZXJzLA0KPj4gPj4gPj4gTWVk DQo+PiA+PiA+Pg0KPj4gPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4g Pj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg SmltIEd1aWNoYXJkDQo+PiA+PiA+PiA+KGpndWljaGFyKQ0KPj4gPj4gPj4gPkVudm95w6kgOiB2 ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+ID4+ID4+ID7DgCA6IE5BUElFUkFMQSwg TUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+ ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0 ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzDQo+PmZ1bmN0aW9uYWxpdHkNCj4+ID4+ID4+ID5w cm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAq YWxsKg0KPj5TRkbigJlzDQo+PiA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVu IGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50IHRvIGENCj4+ID4+ID4+bG9va3VwDQo+PiA+ PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNo YWluLCBJIGFtIG5vdA0KPj4gPj5zdXJlDQo+PiA+PiA+Pmhvdw0KPj4gPj4gPj4gPnRoZSBhcmNo aXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID5PbiA3LzExLzE0 LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+PiA+PiB3 cm90ZToNCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ID4+ID4+DQo+ PiA+PiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+ID4+PiBGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj5H dWljaGFyZA0KPj4gPj4gPj4gPj4+KGpndWljaGFyKQ0KPj4gPj4gPj4gPj4+IFNlbnQ6IEZyaWRh eSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+PiA+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFS SUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPj4gc2ZjQGlldGYub3JnDQo+PiA+ PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJz dGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zIHRvDQo+Pm1lDQo+PiA+ PiA+PnRoYXQgaWYNCj4+ID4+ID4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNp c2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0DQo+PiA+PndpbGwNCj4+ID4+ID4+dXNlDQo+ PiA+PiA+PiA+Pj5mb3INCj4+ID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5l eHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPj4gPj5iZXR0ZXINCj4+ID4+ID4+bWFr ZQ0KPj4gPj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3Nh cnkgZm9yd2FyZGluZyBsb2dpYw0KPj50bw0KPj4gPj4gPj5yZWFjaA0KPj4gPj4gPj4gPj4+dGhl DQo+PiA+PiA+PiA+Pj4gbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlv dSBhcmUgaW4gZGVlcA0KPj50cm91YmxlLg0KPj4gPj4gPj4gPj4+DQo+PiA+PiA+PiA+Pj4gT24g Ny8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0K Pj4gPj4gPj4gd3JvdGU6DQo+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+PiA+QWJzb2x1dGVseSBu b3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbg0KPj4gPj5yZWxl dmFudA0KPj4gPj4gPj4gPj4+U0ZGcw0KPj4gPj4gPj4gPj4+ID53aGVuIHRoZXkgImFycml2ZSIu DQo+PiA+PiA+PiA+Pj4gPg0KPj4gPj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiA+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+ID4+R3VpY2hhcmQNCj4+ID4+ID4+ID4+PiA+PihqZ3Vp Y2hhcikNCj4+ID4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBB TQ0KPj4gPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0Bp ZXRmLm9yZw0KPj4gPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkDQo+PkJhbGFuY2Vycw0KPj4gPj4gPj4gPj4+ID4+DQo+PiA+PiA+ PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2 ZQ0KPj51bmRlcnN0b29kDQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+ID4+ ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBv ZiBldmVyeQ0KPj5zaW5nbGUNCj4+ID4+U0YNCj4+ID4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4g Pj4+ID4+dGhlDQo+PiA+PiA+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2lu Z2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG8NCj4+ID4+a25vdw0KPj4gPj4gPj5hDQo+PiA+ PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ID4+ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBT RkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+PiA+PnBvaW50DQo+PiA+PiA+ PmluDQo+PiA+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4gPj4+ID4+DQo+PiA+PiA+PiA+Pj4gPj4g T24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iDQo+PiA8am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4+ID4+ID4+IHdyb3RlOg0KPj4gPj4gPj4gPj4+ID4+DQo+PiA+PiA+PiA+Pj4g Pj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHBy b2JsZW0NCj4+ID4+d2l0aA0KPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkg YWRtaXQgSSBtYXkNCj4+bm90DQo+PiA+PiA+PiA+Pj51bmRlcnN0YW5kDQo+PiA+PiA+PiA+Pj4g Pj4gPml0LikNCj4+ID4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+PiA+Pj4gPj4gPlRoZSBwcm9wb3Nh bCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yDQo+PnRoZQ0KPj4g Pj4gPj5uZXh0DQo+PiA+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dz IGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj4gPj50byksDQo+PiA+PiA+PmluDQo+PiA+ PiA+PiA+Pj5ldmVyeQ0KPj4gPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0 aHJvdWdoIGl0Lg0KPj4gPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+ID4+PiA+PiA+U2luY2UgaXQg aGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdA0KPj5tZWFucw0K Pj4gPj4gPj50aGF0DQo+PiA+PiA+PiA+Pj4gPj5ldmVyeQ0KPj4gPj4gPj4gPj4+ID4+ID5TRkYg d291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bA0KPj5s b2FkDQo+PiA+PiA+PiA+Pj5iYWxhbmNlci4NCj4+ID4+ID4+ID4+PiA+PiA+SSBhaHZlIG5vIHBy b2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcg0KPj4gPj4gPj5z dGF0ZWZ1bC4NCj4+ID4+ID4+ID4+PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJl cXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYQ0KPj5mdWxsLA0KPj4gPj4gPj5mbG93DQo+PiA+PiA+ PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUg dG8gYmUgYW4NCj4+ID4+ID4+YWNjZXB0YWJsZQ0KPj4gPj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9u Lg0KPj4gPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+ID4+PiA+PiA+WW91cnMsDQo+PiA+PiA+PiA+ Pj4gPj4gPkpvZWwNCj4+ID4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+PiA+Pj4gPj4gPk9uIDcvMTAv MTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+PiA+Pj4gPj4gPj4g UGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZQ0KPj50 aGlzDQo+PiA+PndvcmsNCj4+ID4+ID4+ID4+PiA+PnNlbnNpYmx5DQo+PiA+PiA+PiA+Pj4gPj4g Pj4gaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gIEkgZXhwZWN0IHRoYXQgdGhl DQo+PiA+PnNlcnZpY2UNCj4+ID4+ID4+ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRp bWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsDQo+PiA+PndpbGwNCj4+ID4+ID4+YmUN Cj4+ID4+ID4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gIEkgZXhwZWN0 IHRoZSBzZXJ2aWNlIGNoYWlucw0KPj4gPj50byBiZQ0KPj4gPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5 DQo+PiA+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBj bGllbnRzLCBhbmQgZW5hYmxlDQo+PiA+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4g Pj4+ID4+ID4+IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZp bHkgcG9saWN5DQo+PiA+PiA+PmRyaXZlLg0KPj4gPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+ Pj4gPj4gPj4gSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4NCj4+ YXJjaHRpZWN0dXJlDQo+PiA+PiA+PmRyaXZlbg0KPj4gPj4gPj4gPj4+YnkNCj4+ID4+ID4+ID4+ PiA+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhz LiAgSXQNCj4+aXMNCj4+ID4+ID4+aGFyZGVyDQo+PiA+PiA+PiA+Pj50bw0KPj4gPj4gPj4gPj4+ ID4+c2VlDQo+PiA+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNh biBiZSBkb25lKSB3aGVuIHdlIGFsbG93DQo+PiBtb3JlDQo+PiA+PiA+PiA+Pj4gPj4gZHluYW1p Y2l0eQ0KPj4gPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4g Pj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBv ZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkDQo+PmlzDQo+PiA+PiA+Pm91dHNpZGUNCj4+ ID4+ID4+ID4+Pm9mDQo+PiA+PiA+PiA+Pj4gPj50aGUNCj4+ID4+ID4+ID4+PiA+PiA+PiBzY29w ZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+PiA+ PiA+PnRhc2tlZCB0bw0KPj4gPj4gPj4gPj4+ID4+YWdyZWUNCj4+ID4+ID4+ID4+PiA+PiA+Pm9u Lg0KPj4gPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5z IHdlIGhhdmUgdG8gZG8gaXQgYQ0KPj4gPj5jZXJ0YWluDQo+PiA+PiA+PiA+Pj53YXkuDQo+PiA+ PiA+PiA+Pj4gPj5pdA0KPj4gPj4gPj4gPj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZl IHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4gPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+ PiA+Pj4gPj4gPj4gWW91cnMsDQo+PiA+PiA+PiA+Pj4gPj4gPj4gSm9lbA0KPj4gPj4gPj4gPj4+ ID4+ID4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRo IHdyb3RlOg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9y bWF0aW9uIGFib3V0IHNlcnZpY2UNCj4+IGluc3RhbmNlcw0KPj4gPj4gPj4gdGhhdA0KPj4gPj4g Pj4gPj4+ID4+bmVlZHMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+dG8NCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZl bg0KPj4gPj4gPj5hY3Jvc3MNCj4+ID4+ID4+ID4+PmRhdGENCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZQ0KPj5lbm91 Z2gNCj4+ID4+YW5kDQo+PiA+PiA+PiA+Pj4gY29tcGxleA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4g ZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4+bGlr ZSBhDQo+PiA+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IGFyY2hpdGVj dHVyZSB0byByZWFsaXplLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+ PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4NCj4+ ID4+ZHluYW1pYw0KPj4gPj4gPj4gPj4+IHJvdXRpbmcsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+IGh5 cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mDQo+PiA+ PndoaWNoDQo+PiA+PiA+PmFyZQ0KPj4gPj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseQ0KPj4g aW1wbGVtZW50ZWQ/DQo+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+IEl0 IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwNCj4+dGhh dA0KPj4gPj5pcw0KPj4gPj4gPj5hDQo+PiA+PiA+PiA+Pj5nb29kDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ DQo+PiA+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9l bGhhbHBlcm4uY29tXQ0KPj4gPj4gPj4gPj4+ID4+ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAx MCwgMjAxNCA5OjQ1IFBNDQo+PiA+PiA+PiA+Pj4gPj4gPj4+IFRvOiBSb24gUGFya2VyOyBKb2Vs IEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsNCj4+ID4+SWFuDQo+PiA+PiA+PiA+ Pj5TbWl0aDsNCj4+ID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk DQo+PiA+PkJhbGFuY2Vycw0KPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+ PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuICBBbmQgb25lIHRoYXQgSSB3b3VsZA0K Pj4gPj5wcmVmZXINCj4+ID4+ID4+d2UNCj4+ID4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPj4g Pj4gPj4gPj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwg cG9zc2libGUNCj4+ID4+ID4+aW1wbGVtZW50YXRpb25zLg0KPj4gPj4gPj4gPj4+ID4+ID4+PiBC ZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPj4gPj4g Pj5yZXF1aXJlbWVudHMNCj4+ID4+ID4+ID4+PmFuZA0KPj4gPj4gPj4gPj4+ID4+IHRoZQ0KPj4g Pj4gPj4gPj4+ID4+ID4+PiBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlv biBhYm91dCBzZXJ2aWNlDQo+PiBpbnN0YW5jZXMNCj4+ID4+ID4+dGhhdA0KPj4gPj4gPj4gPj4+ IG5lZWRzDQo+PiA+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5 IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuDQo+PiA+PiBhY3Jv c3MNCj4+ID4+ID4+ID4+PmRhdGENCj4+ID4+ID4+ID4+PiA+PiA+Pj4gY2VudGVycyB3aXRoaW4g YW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaA0KPj4gPj5hbmQNCj4+ID4+ ID4+ID4+PmNvbXBsZXgNCj4+ID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRv IGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4+bGlrZSBhDQo+PiA+PiA+PiA+Pj5kaWZm aWN1bHQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+ PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+IFlvdXJzLA0KPj4gPj4gPj4gPj4+ ID4+ID4+PiBKb2VsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+IEJ1 dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+ Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiAgIElzIHRoZSBlbmQg dG8gZW5kDQo+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj5vZg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4g KHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkNCj4+ dGhlDQo+PiA+PiA+PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4gb3Ig aG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQNCj4+IHN1YnNlcXVlbnRs eQ0KPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+PiA+PlNGRnMpPw0KPj4gPj4gPj4gPj4+ID4+ID4+ Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4N Cj4+ID4+QW5kDQo+PiA+PiA+PiA+Pj5zdXJlbHksDQo+PiA+PiA+PiA+Pj4gPj4gPj4+PiB0aGlz IGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4+ID4+ID4+ ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVk IGFwcHJvYWNoIGV2ZW4NCj4+ID4+IHRob3VnaA0KPj4gPj4gPj4gYQ0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhh cHMNCj4+ID4+bG9jYWwNCj4+ID4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0K Pj5wb2ludHMuDQo+PiA+PiA+PlRoaXMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRv ZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0DQo+PmFsbC4NCj4+ID4+ID4+ TXkNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHBy b2FjaCBpcyBwcmltYXJpbHkNCj4+ZHJpdmVuDQo+PiA+PmJ5DQo+PiA+PiA+PiA+Pj4gPj5pbmNy ZWFzZWQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBh dGggaWQgYXBwcm9hY2guICAgV2l0aCBhDQo+PiA+Pmdsb2JhbA0KPj4gPj4gPj4gPj4+cGF0aA0K Pj4gPj4gPj4gPj4+ID4+aWQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRl ciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nDQo+PnRvDQo+PiA+PiA+PmFsdGVy DQo+PiA+PiA+PiA+Pj50aGUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRh YmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZA0KPj4gPj5lbmQtdG8tZW5kDQo+PiA+PiA+ PiA+Pj5wYXRoLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IFJv bg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4NCj4+ RGlyZWN0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21d IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPj4gPj4yMDE0DQo+PiA+PiA+PiA2OjE1DQo+PiA+ PiA+PiA+Pj4gUE0NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNvbTsg SS5TbWl0aEBGNS5jb207IHNmY0BpZXRmLm9yZw0KPj4gPj4gU3ViamVjdDoNCj4+ID4+ID4+IFJl Og0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+ PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNGMQ0KPj5uZWVk aW5nDQo+PiA+PnRvDQo+PiA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UNCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0IHRo ZQ0KPj4gPj5leGl0DQo+PiA+PiA+PmZyb20NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IFNGMS4NCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2Fs IGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4+ID4+ID4+bG9naWNhbGx5DQo+ PiA+PiA+PiA+Pj4gPj4gPj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJs eSBkZXNjcmliZSBob3cNCj4+dGhleQ0KPj4gPj4gPj4gY2hvb3NlDQo+PiA+PiA+PiA+Pj50bw0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVtIGZvciAic2VydmljZSIgZGVsaXZlcnku DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4gWW91cnMsIEpvZWwN Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2 OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBJ IGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzDQo+PmFu eQ0KPj4gPj4gPj5zb3J0DQo+PiA+PiA+PiA+Pj5vZg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGxp bWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUNCj4+ZW50aXJl DQo+PiA+PiA+PnBhdGgNCj4+ID4+ID4+ID4+PihhbGwNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBT RklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gIEkgYmVsaWV2ZQ0KPj4g Pj50aGlzDQo+PiA+PiA+PiA+Pj5tZWFucw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBh dCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcg0KPj4gPj5jaG9vc2VzIGEN Cj4+ID4+ID4+U0YNCj4+ID4+ID4+ID4+PiA+PkNoYWluDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g YW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuICBJbiBhbnkNCj4+Y2Fz ZSwNCj4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVt IHRvIHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNGUA0KPj4gd2hlcmUNCj4+ID4+ID4+IFNGSShu KQ0KPj4gPj4gPj4gPj4+IGlzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0 aGUgU0ZJKG4tMSkgaG9wLiAgQWNjb3JkaW5nIHRvIHRoZQ0KPj5kcmFmdCwNCj4+ID4+ID4+dGhp cw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJy YW5jaGluZyIgdG8gYSBuZXcgU0ZQDQo+PiBhcw0KPj4gPj4gPj4gPj4+IG9wcG9zZWQNCj4+ID4+ ID4+ID4+PiA+PiB0bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGNob29zaW5nIGFuZCB0aGVuIGZv cndhcmRpbmcgdG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlDQo+PiBvZg0KPj4gPj4gPj50aGUNCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFy Y2hpdGVjdHVyZS0wMDoNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5z dGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ID4+ID4+bmVjZXNzYXJ5DQo+PiA+ PiA+PiA+Pj50bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGlu c3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlDQo+PnVzZWQsDQo+PiA+PiA+PmFuZCB0bw0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQg U0ZDIHVzaW5nIFNGJ3MNCj4+ID4+ID4+bmV0d29yaw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBs b2NhdG9yLiAgVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4NCj4+dGhl DQo+PiA+PiA+PiA+Pj5jcmVhdGlvbg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBhIFNlcnZp Y2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3INCj4+ID4+ID4+Zm9yd2FyZGlu Zw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3Ro ZXIgd29yZHMsIGFuIFNGUCBpcw0KPj50aGUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gaW5zdGFu dGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3Np ZmljYXRpb24gKG9yDQo+PiA+PiA+Pm5vbi1pbml0aWFsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiAgQXMgcGFja2V0cyB0cmF2ZXJzZSBhbg0KPj5TRlAs DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlw aWNhbGx5IHBlcmZvcm1lZCBieQ0KPj5hDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZp Y2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlDQo+PiA+PiA+PmZ1bmN0 aW9uLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1bHQg aW4gdGhlIHNlbGVjdGlvbiBvZiBhDQo+Pm5ldw0KPj4gPj4gPj5TRlAsIGFuDQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3IgYm90aC4g IFRoaXMgaXMNCj4+ID4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+ID4+PnRvDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4NCj4+ID4+DQo+PiAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4+ Pi0tDQo+PiA+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4g Pj4gPj4+ID4+Pj4+Pj4tLQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+ID4+PiA+PiA+Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNvbTxJLlNtaXRoQEY1LmNvbT4N Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4NCj4+ID4+IERpcmVjdDxq bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4sSm9lbA0KPj4gPj4gPj4gTS4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+DQo+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+DQo+PiA+ Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20+LGh1YW5nQHNjZS5jYXJsZXRv bi5jYTxodWFuZ0BzY2UuDQo+PiA+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQNCj4+ID4+ID4+QmFsYW5jZXJzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmls aXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PiA+PnRoYXQgaXMNCj4+ID4+ ID4+ID4+PndoYXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGlu IG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4gPj4gPj4gPj4+cHJlY29uY2VpdmVk DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hp dGVjdHVyZSBidXJkZW5lZA0KPj53aXRoDQo+PiA+PiB0aGF0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gcHJlY29uY2VwdGlvbi4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YN Cj4+ID4+ID4+YXNwaXJhdGlvbg0KPj4gPj4gPj4gdG8NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBz Y2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlDQo+PiA+PiA+ PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj4gPj4+LQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHlvdSBk b24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZw0KPj50aGF0IGFuDQo+ PiA+PiA+PiA+Pj5hcmJpdHJhcnkNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRv byBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0DQo+Pmlzbid0DQo+PiA+PiA+PiA+ Pj4gPj5pbnRlbnRpb25hbA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGlu Zmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nDQo+PiA+PiA+PmltcGFjdHMNCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRp b24sIGVsYXN0aWNpdHksDQo+PiA+PiA+PmFkZHJlc3MNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBz cGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20NCj4+bm90 DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4N Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJv bTogSm9lbCBIYWxwZXJuIERpcmVjdA0KPj5bam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+ PiA+PiA+PlNlbnQ6DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsDQo+Pk0uDQo+PiA+PiA+PiBIYWxwZXJuOw0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTsgc2ZjQGlldGYub3Jn IFN1YmplY3Q6IFJlOg0KPj5bc2ZjXQ0KPj4gPj4gPj5TZXJ2aWNlDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2Fn cmVlIHdpdGggbWUgYXQgYWxsIGluDQo+PnRoaXMNCj4+ID4+ID4+cmVnYXJkLg0KPj4gPj4gPj4g Pj4+SQ0KPj4gPj4gPj4gPj4+ID4+YW0NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVz dGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ID4+ID4+cHJvaGli aXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFz aGlvbi4gSSBhbSBvYmplY3RpbmcNCj4+dG8NCj4+ID4+ID4+SHVhbmcncw0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1l bnRzDQo+PmFyZQ0KPj4gPj4gPj4gcmVxdWlyZWQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5 IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8N Cj4+cHJvaGliaXQNCj4+ID4+c3VjaA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hl dGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcw0KPj4gdXBvbg0KPj4gPj4g Pj4gbWFueQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bw0KPj4gPj50aGluaw0KPj4gPj4gPj50aGF0DQo+PiA+ PiA+PiA+Pj4gPj50aGV5DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQg aWRlYS4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IEJ1dCB0 aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZw0KPj5hdHRlbXB0aW5nIHRvDQo+ PiA+PiA+Pmtub3cNCj4+ID4+ID4+ID4+PndoYXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBh bmQgaXMgbm90IGVwbG95YWJsZS4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhh dCBtYW5hZ2UgdGVucw0KPj4gb2YNCj4+ID4+ID4+ID4+Pm1pbGxpb25zDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IG9mDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBi b3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhDQo+PiBjZW50ZXINCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0 DQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxp dHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdw0KPj4geW91DQo+PiA+PiBhcmUNCj4+ID4+ ID4+IG9ubHkNCj4+ID4+ID4+ID4+PiA+PiBnb2luZw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRv IGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkNCj4+ID4+ c21hbGwNCj4+ID4+ID4+ID4+PiBudW1iZXJzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0 aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVl ZA0KPj4gbW9yZQ0KPj4gPj4gdGhhbg0KPj4gPj4gPj4gPj4+IDY0SyINCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gZm9yDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOg0KPj4gc2Zj DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxm IG9mIEpvZWwgTS4gSGFscGVybg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBl cm4uY29tXQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwg MjAxNCA0OjQ2IFBNIFRvOg0KPj4gPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLA0KPj5QYXRocywNCj4+ID4+YW5kDQo+PiA+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0 byBkZXBsb3kgdGhlDQo+PiA+PiA+PiA+Pj5hcmNodGlldHVyZQ0KPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0K Pj4gPj50aGVpcg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0 dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaA0KPj5hYnN1cmQNCj4+ID4+IHVzZQ0KPj4gPj4gPj4g b2YNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90 IGZpZ3VyZSBvdXQgaG93IHRvDQo+PndyaXRlDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hp dGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmUNCj4+ID4+ZG9l cw0KPj4gPj4gPj4gPj4+cGVybWl0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2Uu DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBk byBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiA+PiBwZXJtaXRz DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVy IGRlaXNyZWQgb3INCj4+cmVxdWlyZWQgYnkNCj4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+Pj53b3Jr Lg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdj aGVuZyBIdWFuZyB3cm90ZToNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRv IHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsDQo+PiA+Pm1lYW4NCj4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhl IHJvdXRpbmcNCj4+ID4+dGFibGUNCj4+ID4+ID4+b2YgYQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4gY29yZSByb3V0ZXIuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4gQ2hhbmcNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBv ZiBkZXBsb3ltZW50cywNCj4+IGZyb20NCj4+ID4+MQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlDQo+PiA+ PnRoYXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZv ciB0aGUgY29tcGxleGl0aWVzIGlmDQo+PnRoZXkNCj4+ID4+ID4+Y2hvb3NlDQo+PiA+PiA+PiA+ Pj50bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9h ZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkDQo+PiA+PiA+PiBwcm92aXNpb24NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQ TSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQ YXVsLA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNA0KPj5ob3AN Cj4+ID4+ID4+IHNlcnZpY2UNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAy MCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gKk9uDQo+PiBCZWhhbGYNCj4+ID4+IE9mDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwNCj4+MjAx NA0KPj4gPj4gPj4zOjAzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kg eW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tOw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmc7DQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdIFNl cnZpY2UNCj4+ID4+IENoYWlucywNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQg ZHJpdmVzDQo+PnRoZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nLiBJwrlk DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkDQo+PiB0bw0K Pj4gPj4gPj4gZGVyaXZlDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9y d2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQs IGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPj4gPj5zaW1wbHkNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cw0K Pj4gPj5tdXN0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcg YSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb24NCj4+ID4+dGhp cw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBs ZW1lbnRlZC4gVGhlIHBhdGgNCj4+ID4+ID4+IGlkZW50aWZpZXINCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3Vw DQo+PiBjYW4NCj4+ID4+ID4+IHJlc3VsdA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBh IG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0DQo+PiBuZXh0DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0IDExOjA0IEFN LCBMdWN5IHlvbmcNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWku Y29tDQo+PiA+PiA+PiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBv bmx5IHVzZQ0KPj4gb2YNCj4+ID4+IHRoZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZw0KPj4gPj4gPj5hY3Rp b25zLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBMdWN5DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24NCj4+IEJlaGFs Zg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4NCj4+ID4+ID4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+PiA+PiA+PiA+Pj4g Pj4gSnVseQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoq bWlrZWJpYW5jQGFvbC5jb20NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IDxtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20+O2ptaEBqb2VsaGFscGVybi5jb20NCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTog W3NmY10gU2VydmljZQ0KPj4gPj4gPj5DaGFpbnMsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBs aWNpdGx5IGEgc2VydmljZQ0KPj5wYXRoDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50 aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8NCj4+ID4+ZGVyaXZlDQo+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZD IHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZQ0KPj4gb2YNCj4+ID4+ID4+IGV2ZXJ5 DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMN Cj4+IG5vdA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmllZA0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNv bnRleHRzLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZQ0KPj5v Zg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IHRoYXQgd2lsbA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGlu IGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lDQo+PiA+PiByZXF1aXJlZA0KPj4gPj4g Pj4gdG8NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFp bi4gSG93IHRoYXQgaW5mb3JtYXRpb24NCj4+aXMNCj4+ID4+ID4+dXNlZCB0bw0KPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJkaW5nDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g YWN0aW9ucw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVk IGRpc2N1c3Npb24uDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IENoZWVycywNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gTWVkDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpE ZSBsYQ0KPj5wYXJ0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20N Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gKkVu dm95w6kgOiptZXJjcmVkaSA5DQo+PiA+PiA+PiBqdWlsbGV0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoq UmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0 aGUgZGlmZmVyZW5jZQ0KPj5iZXR3ZWVuDQo+PiA+PlNGDQo+PiA+PiA+PiBDaGFpbg0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmlu aXRpb24gc28gdGhhdCBpdCdzDQo+PiA+PiA+PmNsZWFyIHRvDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gdGhvc2Ugbm90DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhl IGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lDQo+PiA+PmFncmVlcw0KPj4gPj4gPj5vbg0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQg dGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+PiA+PndoZXRoZXINCj4+ID4+ID4+aXQgaXMNCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGlt YXRlbHkgc3BlY2lmeQ0KPj53aGF0DQo+PiA+PiA+PnRoZSBJRA0KPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNob3VsZA0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0 aCksIG9yIGlmIHRoaXMNCj4+ZHJhZnQNCj4+ID4+ID4+c2ltcGx5DQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVy DQo+PiA+PmRyYWZ0cw0KPj4gPj4gPj50bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0 YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uDQo+PiBjaGFpbg0KPj4g Pj4gb3INCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBj aGFpbiBvcg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRlciAo YW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQNCj4+IGhhdmUNCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChv cg0KPj4gbWFrZQ0KPj4gPj4gPj4gb25lDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVp cmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+ID4+IHZlbmRvcnMN Cj4+ID4+ID4+IG9ubHkNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAg YW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+PiA+Pj4gPj4NCj4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4NCj4+ID4+DQo+PiANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+ PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4gPj4gPj4+ID4+ Pj4+Pj4tLQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAqRnJvbToqam1oQGpv ZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBl cm4uY29tPj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmc8c2Zj QGlldGYub3JnDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3Jn JTNjc2ZjQGlldGYub3JnPj4NCj4+ID4+ICpTZW50OipUdWVzZGF5LA0KPj4gPj4gPj4gSnVseQ0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsDQo+PmFuZA0KPj4gPj5Mb2FkDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJs eQ0KPj4gPj5hbnN3ZXINCj4+ID4+ID4+YQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1i ZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dA0KPj4gdGhlDQo+PiA+PiA+ PiA+Pj4gcHJvcG9zZWQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVj dHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldA0KPj4gPj4gd29ya2luZw0KPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3 b3JrIHRvDQo+PiA+PiBpbXByb3ZlDQo+PiA+PiA+PiB0aGUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZA0K Pj4gaW4NCj4+ID4+ID4+dGhlDQo+PiA+PiA+PiBXRw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gd29ya2luZw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRz Lg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBC dXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4gPj4gPj5w ZXJzb25hbA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQg aGVscHMuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIA0KPj50 aGF0DQo+PiA+PiA+PndoYXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmlu aW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gDQo+PldlDQo+PiA+PmFyZQ0KPj4g Pj4gPj4gbm90DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5l IHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSANCj4+ZW50aXJlDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkDQo+PiBlbmNv bXBhc3MNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9s IGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KPj4gPj52aXJ0dWFsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+PiA+ PiA+PiBhc3BlY3RzLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJs eQ0KPj4gbmVlZA0KPj4gPj4gdG8NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4g dGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgDQo+PndpdGgNCj4+ID4+ID4+ YWJvdmUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBh cmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZQ0KPj4gPj4gZG9pbmcu DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElu IG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwNCj4+ID4+YXMg SQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gdGhlbSwNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRp c2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIA0KPj5hcmUgYXQNCj4+ID4+ID4+bGVhc3QNCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJh bGFuY2luZyBjYW4gYW5kDQo+PiA+PndpbGwNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50 ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSANCj4+YXJlDQo+PiA+ PiA+Pm1vcmUuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJj aHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YNCj4+ID4+ID4+dGhlc2UsDQo+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtp bmQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVk IHRvIHRoZSANCj4+ZW5kDQo+PiA+PiA+PnVzZXIuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+PiA+PnBhY2tl dHMsDQo+PiA+PiA+PmFuZA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVt IChvcg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4+ ID4+ID4+aW5zdGFuY2UNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUg dXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj4gPj4gPj5zZXJ2aWNlDQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBz ZXJ2aWNlIA0KPj5jaGFpbmluZy4NCj4+ID4+ID4+SXQncw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZQ0KPj4g Pj4gPj4gY2hhaW5pbmcgaXMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0 IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiA+PiA+PmFyY2h0aWVjdHVyZS4NCj4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3Rp dmUgaXQgaXMgc2ltcGx5IA0KPj5hDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRl cmx5aW5nIHBhY2tldC4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMs IG9uZQ0KPj4gPj5jYW4NCj4+ID4+ID4+aGF2ZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 aGF0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUNCj4+ ID4+cG9pbnQNCj4+ID4+ID4+b2YNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBhDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNw ZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSANCj4+ZGVsaXZlcmVkDQo+ PiA+PiA+PmJ5IGENCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5 IGluY2x1ZGluZw0KPj4gPj5vbmUgb3INCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJh bCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgDQo+PlZSUlAtbGlrZQ0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBt b3N0bHksIHRoaXMgDQo+PmlzDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0 byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+PiA+PiA+Pm1lY2hhbmlzbXMuDQo+ PiA+PiA+PiBJdA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBp cyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4gPj4gPj5tZWNoYW5pc21zLA0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1p biwgDQo+PnNjYWxlLW91dCwNCj4+ID4+YW5kDQo+PiA+PiA+PnZtDQo+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZg0KPj4g Pj5wZXJtaXR0aW5nDQo+PiA+PiA+PnRoaXMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMg bGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4gPj4gPj50ZXJt aW5vbG9neQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGlu ayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5n IGRvbmUgYnkNCj4+ID4+c2VsZWN0aW5nDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tl dCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+ID4+ID4+dHJh ZmZpYw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3 b3VsZCBub3Qgd2FudCB0byByZXF1aXJlDQo+PiA+PiB0aGF0DQo+PiA+PiA+PmENCj4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBv bmUgcGxhY2UgDQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3 b3JrLg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUNCj4+ID4+Y29tYmlu ZWQuIEkNCj4+ID4+ID4+IHRlbmQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8NCj4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUg Y29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlDQo+PiA+PiA+PmNo YWluaW5nDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEg Y2x1c3Rlci4gTm90IGJlY2F1c2UgDQo+PmNsdXN0ZXINCj4+ID4+aXMNCj4+ID4+ID4+YQ0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhh dmUgYW5vdGhlciBvbmUuDQo+PiA+PiBUaHVzLA0KPj4gPj4gPj4gdGhlDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJl bnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudA0KPj4gPj4gPj5zaW5ndWxhcg0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4g ZGlmZmVyZW50IA0KPj5wbGFjZXMNCj4+ID4+aW4NCj4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hl biBJIHRhbGsNCj4+IGFib3V0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hh aW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyANCj4+YQ0KPj4gPj4gPj4gc2Vx dWVuY2UNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8g YmUgYXBwbGllZCB0byBhIHN1YnNldCBvZg0KPj4gPj4gPj5wYWNrZXRzLg0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0 IG9mDQo+PiA+PnRyYWZmaWMNCj4+ID4+ID4+aXMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kDQo+PiA+PmZpcmV3 YWxsDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBp cyB0byBnbyBkaXJlY3RseSB0byB0aGUNCj4+ID4+Y2FjaGUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ PiB3aXRob3V0DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5nIGFueSBvdGhlciBz ZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0 aGUNCj4+ID4+cGFja2V0cy4NCj4+ID4+IEENCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vy dmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4+ID4+ID4+bG9j YXRpb25zDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBs b2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciANCj4+b3INCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiANCj4+VGhl eQ0KPj4gPj4gPj5tYXkgYmUNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5 IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBhcw0KPj4gPj4gcG9ydHMNCj4+ID4+ ID4+IG9uDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkg ZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ID4+ID4+bG9jYXRpb25zDQo+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KPj4gaW5m cmFzdHJ1Y3R1cmUNCj4+ID4+IGFuZA0KPj4gPj4gPj4gdGhlDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMNCj4+ID4+Z3JvdXAsDQo+PiA+PiA+PiB3ZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pj4gbmVlZCB0byBiZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJv dXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIA0KPj50aGUNCj4+ID4+ID4+c2VydmljZQ0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJk aW5nLiBBbmQgd2UgbmVlZCANCj4+dG8NCj4+ID4+IHRhbGsNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gDQo+ PnRoZQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUNCj4+ID4+IHBhdGgNCj4+ID4+ID4+IG1heQ0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhp cyBhcmNoaXRlY3R1cmUgDQo+PmRlYWxzDQo+PiA+PiA+PndpdGgNCj4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0g DQo+PigyKQ0KPj4gPj5vbg0KPj4gPj4gPj5sb2FkDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+ID4+YmVoYXZp b3JzDQo+PiA+PiA+PiB3aGljaA0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNp YmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgDQo+Pihpbg0KPj4gPj4gPj5t dWNoDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5n IHdpdGhpbiBhIExBTiBpcyANCj4+bGFyZ2VseQ0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXINCj4+ID4+IHByb3Zp c2lvbg0KPj4gPj4gPj4gd2UNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFrZSBpcw0KPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVjbGFz c2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPj4gPj4gPj4gbmVjZXNz YXJ5Lg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMg dG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9y bWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24NCj4+ID4+cG9pbnQuDQo+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9w ZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4NCj4+ID4+SWYgaXQN Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNj ZXB0YWJsZSB0byB0aGUgDQo+PndvcmtpbmcNCj4+ID4+ID4+IGdyb3VwLA0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJl DQo+PiBuZWVkZWQNCj4+ID4+IHRvDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0 aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIA0KPj50aGUNCj4+ID4+ID4+ IGludGVudCwNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJz ZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIA0KPj53b3JraW5nDQo+PiA+PiA+Pmdyb3VwDQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwg SSBhbSBub3QgDQo+PnN1cmUNCj4+ID4+ID4+d2hhdCB0bw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiA+PiBzZmMNCj4+ID4+ID4+ID4+PiA+PiBtYWlsaW5n DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+ID4+IHNmYw0KPj4gPj4gPj4gPj4+ID4+IG1haWxpbmcN Cj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+IHNmYw0K Pj4gPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNm Y0BpZXRmLm9yZw0KPj4gPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0K Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZw0KPj4gPj4gPj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMN Cj4+ID4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4g Pj4+ID4+IGxpc3QNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+Pj4gPj4gPj4+ Pg0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IHNmYw0KPj4gPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4gPj4+ID4+ IGxpc3QNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzZmMNCj4+ID4+ID4+IG1haWxpbmcNCj4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+ PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+Pj4gPj4gPj4+ DQo+PiA+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4+ID4+ID4+IHNmYyBt YWlsaW5nIGxpc3QNCj4+ID4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4g Pj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4+ID4+ID5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4+ID4+ ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiA+Pj4gPj4gPnNmY0BpZXRmLm9yZw0KPj4gPj4g Pj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4gPj4gPj4+ID4+DQo+PiA+PiA+PiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+ PiA+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4g Pj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+ PiA+DQo+PiA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiA+c2ZjQGlldGYub3Jn DQo+PiA+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ID4NCj4NCg0K From nobody Fri Jul 11 09:34: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 9AF961B2911 for ; Fri, 11 Jul 2014 09:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnN5DKjaIFGa for ; Fri, 11 Jul 2014 09:33:55 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD231A0385 for ; Fri, 11 Jul 2014 09:33:53 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 1f110c35.2b9915254940.4701325.00-2476.13036119.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:33:54 +0000 (UTC) X-MXL-Hash: 53c011f27234087b-638ca936049b44acf7438de99fcff579903d13f2 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 45110c35.0.4699631.00-1965.13031360.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:31:17 +0000 (UTC) X-MXL-Hash: 53c011555ff6b499-b1edfd08e89e765eee60f92b560a940347345ed9 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGVFkQ028246; Fri, 11 Jul 2014 12:31:16 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGV7I0028114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:31:13 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:30:51 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:30:50 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mikebianc@aol.com" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEYhAIAACTEAgAESJQCAACuuAIAAA7AAgAAGl4CAAADAAP//vs4w Date: Fri, 11 Jul 2014 16:30:50 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF37@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <1890567552.55008.1404936150807.JavaMail.tomcat@mgs-aam01.mail.aol.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <479ABDBD-55D9-4784-A460-E4BDBC6D5631@cisco.com> <1474631168.1583.1405025202694.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1593422970.3037.1405093454291.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1124016040.3120.1405095661844.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: [135.70.229.13] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AF37MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=AUd_NHdVA] X-AnalysisOut: [AAA:8 a=3oc9M9_CAAAA:8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a] X-AnalysisOut: [=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=sv1n6CdO8AQGI0LYcLsA:9 ] X-AnalysisOut: [a=wPNLvfGTeEIA:10 a=JfD0Fch1gWkA:10 a=U8Ie8EnqySEA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=Z1poonrc269sjTVF:21 a=JM] X-AnalysisOut: [ONJvRMF1iL-IWt:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6qCG] X-AnalysisOut: [sL5S8LmwNEAwPT8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=h] X-AnalysisOut: [TZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=Xs_a5P9QfIibZB8B:21 a=V] X-AnalysisOut: [F5lkizWanLg86vI:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uKDH7Ctt3zPDqNTGlUaU8Ql5TWw Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:34:02 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AF37MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The point here, I believe, is not to use as an example something that it no= t realistic ;-) From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Friday, July 11, 2014 12:24 PM To: mikebianc@aol.com; NAPIERALA, MARIA H Cc: sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers it's just an example where the 20 instances are hidden behind the SFF but t= hey do not have to be; if you wanted to address them individually then the = architecture does not prevent that. From: "mikebianc@aol.com" > Date: Friday, July 11, 2014 at 12:21 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers but it still sounds like there is a single SFF entity tied to the 20 instan= ces through which ALL traffic destined for any of the 20 instances MUST tra= verse. While this should surely not be prohibited, it shouldn't be mandate= d. ________________________________ From: jguichar@cisco.com> To: mikebianc@aol.com>,mn1921@att.com> cc: sfc@ietf.org> Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers No they do not have to be physically connected but they are hidden behind a= n SFF in this case but do not have to be. From: "mikebianc@aol.com" > Date: Friday, July 11, 2014 at 11:44 AM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers When you say "20 instances of the SF2 SF" are "Connected to that SFF" do yo= u mean physically? I had always just assumed that if I had 20 instances of = a SF, that they would be diverse. Even if within the same datacenter, they = would be not near each other. It also seems like you are saying that there = is only a single SFF for SF2 and that your traffic path requires traversing= SF2 as a separate hop from the SF2 instance. Ideally, the traffic would fl= ow from SF1 instance to SF2 instance over the best path without the need fo= r an intermediary hop. *In my statements above, I assuming that each SF Instance is SFC aware to s= implify the text. ________________________________ From: jguichar@cisco.com> To: mikebianc@aol.com>,mn1921@att.com> cc: sfc@ietf.org> Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi Mike, There still seems to be some confusion around this topic so let me try to p= rovide a more detailed explanation as to how I believe this should work and= why what I explained earlier is in fact a path identifier and not a chain = identifier. Note that my explanation assumes that the SFC encapsulation wil= l contain a path identifier as described within our charter which says "3. = Generic SFC encapsulation: This document will describe a single service-lev= el data plane encapsulation format that indicates the sequence of service f= unctions that make up the Service Function Chain; specifies the Service Fun= ction Path". The wording here is very important and shows that the intent i= s that the sequence of SF's be indicated within the SFC encapsulation e.g. = not carried - this is not source routing, and specifies the SFP, hence the = path identifier. For my example let's assume the following SFC: (SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let's call it "SFC-1" It is possible that each of those SF's be directly addressable (i.e. provid= e SFF functionality) or reachable through some other network device that pr= ovides the forwarding (i.e. external, but connected SFF). In this example, SF1 and SF3 provide direct SFF functionality and SF2 relie= s on a connected switch to provide the needed SFF functionality. Connected = to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3= network locators from which to choose in order to reach the required SF's;= let's call them SF1-loc1, SF2-loc2, and SF3-loc3. When an operator instantiates SFC-1 into the network, specific locators are= selected to construct the path, and a path identifier is allocated. In thi= s example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2= -> SF3-loc3 and it has a path identifier "100". This information is distri= buted to the relevant network devices basically saying "if you receive an S= FC encapsulated packet with path identifier "100" then use the path identif= ier and index to perform a lookup in a data structure that will tell you wh= ich SF to forward the traffic to and how to get there". So traffic flows through the SFP with path identifier "100", via a network = transport (the path identifier is encapsulated). It reaches SF1-loc1 which = uses the path identifier to determine that it is in fact the SF that should= be applied. It applies SF1 SF and then uses the path identifier to determi= ne that SF2 is the next service and its reachable at next-hop SF2-loc2. The= needed transport (for example VXLAN) is imposed for network forwarding. Tr= affic reaches SF2-loc2. It uses the path identifier to determine that SF2 s= hould be applied. It uses a local decision to determine which of the 20 ins= tances of SF2 it should forward the traffic to. It forwards the traffic to = the selected instance. SF2 is applied and then another lookup occurs on the= path identifier, which results in the needed transport being imposed to re= ach the next service hop SF3-loc3 .. And so on and so forth. So with this example we have exactly 1 SFP. Jim (as a WG participant, not a chair). From: "mikebianc@aol.com" > Date: Thursday, July 10, 2014 at 4:46 PM To: Jim Guichard >, "mn1921@a= tt.com" > Cc: "sfc@ietf.org" > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Jim, Technically, wouldn't this be a Chain Identifier if the next instance is ch= osen at each hop? In this case, there wouldn't be any Path Identifier at al= l. But it is the difference between a classifier needing to track the health, = etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tra= cking 20 SFIs of the next-hop for the chains of which they are members vs e= ach SFF in the entire domain tracking all 80 SFIs vs something else. ________________________________ From: jguichar@cisco.com> To: NAPIERALA, MARIA H> cc: Paul Quinn (paulq)>,Lucy yong>,jmh@joelhalpern.com>,moh= amed.boucadair@orange.com>,sfc@ietf.org>,mikebianc@aol.com> Sent: Thursday, July 10, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers 1 assuming load is distributed among the 20 instances at each service hop. Sent from my iPhone On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" > wrote: Paul, How many path identifiers there will be for a 4 hop service chain with 20 i= nstances at each hop? Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, July 10, 2014 3:03 PM To: Lucy yong Cc: jmh@joelhalpern.com; mohamed.boucadair@oran= ge.com; sfc@ietf.org; mikebianc@aol.com Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Lucy, Overall I concur, as you say: a path ID drives the forwarding. I'd make the= minor change: the path identifier can be used to derive the needed forward= ing and associated transport. It is _not_ the transport, but rather is used to simply identify the servic= e path (or graph) that packets must traverse. By having a path identifier, = the exact indirection that people seem to be asking for on this thread can = be simply be implemented. The path identifier provides nothing more than a = lookup, that lookup can result in a one or more (equal or weighted) transpo= rt next hop(s). Paul On Jul 10, 2014, at 11:04 AM, Lucy yong > wrote: Agree. The arch. doc should not mandate only use of the service path identi= fier to drive the forwarding actions. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behalf Ofmohamed.boucadair@orange.= com Sent: Thursday, July 10, 2014 2:06 AM To: mikebianc@aol.com;jmh@joelhalpern.com;sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Re-, The merged draft calls out explicitly a service path identifier. I object t= o use that identifier to derive forwarding actions. Requiring a SFC system to have the full knowledge of every available SFC fo= rwarding paths within an SFC-enabled domain is not required/justified nor p= ossible in various deployment contexts. SFC forwarding actions should rely on the piece of information that will be= present in all deployments: that is the one required to structure a servic= e chain. How that information is used to infer forwarding actions is a solu= tion-oriented discussion. Cheers, Med De :sfc [mailto:sfc-bounces@ietf.org]De la part demikebianc@aol.com Envoy=E9 : mercredi 9 juillet 2014 22:03 =C0 : jmh@joelhalpern.com;sfc@ietf.org Objet : Re: [sfc] Service Chains, Paths, and Load Balancers Is anyone still questioning the difference between SF Chain and SF Path? Ot= her than clarifying the definition so that it's clear to those not familiar= with the draft, it seems that everyone agrees on these terms. To me, the one point that is still unclear is whether it is the intent of t= his draft to ultimately specify what the ID of the SFC Header should refere= nce (the chain or the path), or if this draft simply intends to leave that = ambiguous, allowing other drafts to dictate the mechanisms for forwarding b= ased on chain or path and the choice of chain or path to be negotiated in t= he control-plane. If the latter (ambiguous), then the draft would have require that both SFP = and SFC be supported (or make one required and the other optional) to avoid= some vendors only supporting SFP and others only supporting SFC. ________________________________ From:jmh@joelhalpern.com> To: sfc@ietf.org> Sent: Tuesday, July 8, 2014 Subject: [sfc] Service Chains, Paths, and Load Balancers I have been trying to figure out how to clearly answer a number of comments that have been made about the proposed merged archtiecture draft. Assuming we can get working group agreement on the intent, we will work to improve the wording so that readers who have not participated in the WG discussion will understnd it the way the working group intends. But what do we intend? I will try to explain my personal view, and see if that helps. In this regard, it is important to keep in mind that what we are defining is the data plane architecture. We are not attempting to define the architecture for the entire solution for service chaining. That would encompass OSS/BSS, various control and policy functions, virtual machine and image management, and many other aspects. As a result there are many things which clearly need to exist in the larger system, but which are dealt with above where we are functioning, and are not directly required by the work we are doing. In order to get to service chain vs service path, as I understand them, I need to first discuss load balancing. There are at least three different ways that load balancing can and will interact with service chaining. There probably are more. The point of the archtiecture is to permit all of these, but not to mandate that any particular kind be used in any solution. 1) Load balancing as a service provided to the end user. This is a service function. It receives user packets, and modifies them (or marks them, or ...) so as to choose an end user service instance to receive the users packet. This is an important service function to be able to include in service chaining. It's behavior may affect requirements on how service chaining is done. But it has very little impact on the archtiecture. From an architectural pe3rspective it is simply a service function which may modify the underlying packet. 2) There is internal load balancing. That is, one can have what appears to the service chaining architecture as a single point of contact for a specific service function, but is actually delivered by a collection of virtual or physical machines, possibly including one or several load balancers (for example using VRRP-like techniques to share a MAC address.) mostly, this is invisible to the service chaining data plane mechanisms. It is likely that it is visible to various control mechanisms, such as those responsible for scale-in, scale-out, and vm instantiation. The architectural impact of permitting this is largely that we need to be careful that our terminology does not lead readers to think we are prohibiting it. 3) There can also be load balancing done by selecting packet paths for the service chaining that direct traffic to different places. We would not want to require that a given service function appear at only one place in the network. It is of course the case that these may be combined. I tend to refer to the collection of entities that appear to service chaining as a single point as a cluster. Not because cluster is a good term. But because I do not have another one. Thus, the point of type 3 load balancing is to direct different subsets of traffic to different singular or clustered service functions in different places in the network. Now with that said, what do I mean when I talk about service chain and service path/ Service chain is a sequence of logical functions to be applied to a subset of packets. It is equivalent of saying that some subset of traffic is to get DPI, charging, content inspection, and firewall while a different subset is to go directly to the cache without visiting any other service functions. That is not enough information to direct the packets. A service path is, in some fashion, a sequence of locations in the network. Those locations will be singular or clustered service function delivery locations. They may be addressed by IP address. They may be addressed as ports on an SFF. There are many different ways that the locations may be known to the service chaining infrastructure and the transport. >From the point of view of the work of the SFC group, we need to be able to talk about the high level abstraction, the service chain, which drives the forwarding. And we need to talk about the actual data path packets will take in the network. Several of the comments have said "but the whole path may not be known at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be decisions and behaviors which are invisible to the service chaining mechanisms (in much the same way that bridging within a LAN is largely invisible to routing between LANs.) The other provision we make is that reclassification can be done in mid-chain when necessary. That will direct packets to a new chain. Based on information available at the re-classification point. I hope that this helps explain what we are after. If it does, and if the intent is acceptable to the working group, we can figure out what additional words are needed to convey this. If the working group disagree with the intent, then we will of course adjust to match the working group agreements. If this is still unclear, I am not sure what to try next. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AF37MISOUT7MSGUSRCF_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The point here, I believe= , is not to use as an example something that it not realistic ;-)

 <= /p>

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Friday, July 11, 2014 12:24 PM
To: mikebianc@aol.com; NAPIERALA, MARIA H
Cc: sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

it’s just an example = where the 20 instances are hidden behind the SFF but they do not have to be= ; if you wanted to address them individually then the architecture does not prevent that. 

 

From: "mikebianc@aol.com" <mi= kebianc@aol.com>
Date: Friday, July 11, 2014 at 12:21 PM
To: Jim Guichard <jguichar@= cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

but it still so= unds like there is a single SFF entity tied to the 20 instances through whi= ch ALL traffic destined for any of the 20 instances MUST traverse.  While this should surely not be prohibited, it should= n't be mandated.



From: j= guichar@cisco.com<jguichar@cis= co.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

No they do not have to be physically connected but they are hidden behi= nd an SFF in this case but do not have to be.

 

From: "mikebianc@aol.com" <mi= kebianc@aol.com>
Date: Friday, July 11, 2014 at 11:44 AM
To: Jim Guichard <jguichar@= cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 

When you say &q= uot;20 instances of the SF2 SF" are "Connected to that SFF" = do you mean physically? I had always just assumed that if I had 20 instance= s of a SF, that they would be diverse. Even if within the same datacenter, t= hey would be not near each other. It also seems like you are saying that th= ere is only a single SFF for SF2 and that your traffic path requires traver= sing SF2 as a separate hop from the SF2 instance. Ideally, the traffic would flow from SF1 instance to SF2= instance over the best path without the need for an intermediary hop.=

 

*In my statemen= ts above, I assuming that each SF Instance is SFC aware to simplify the tex= t.



From: j= guichar@cisco.com<jguichar@cis= co.com>
To: mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>
cc: sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers


Hi Mike,

 

There still seems to be some confusion around this topic so let me try = to provide a more detailed explanation as to how I believe this should work and why what I explained earlier is in fact a path identi= fier and not a chain identifier. Note that my explanation assumes that the = SFC encapsulation will contain a path identifier as described within our ch= arter which says “3. Generic SFC encapsulation: This document will describe a single service-level data pla= ne encapsulation format that indicates the sequence of service functions that make up the Service= Function Chain; specifies the Service Function Path”. The wording here is very= important and shows that the intent is that the sequence of SF’s be = indicated within the SFC encapsulation e.g. not carried – this is not source routing, and specifies the SFP, hence the path identifier= .

 

For my example let’s assume the following SFC:<= /p>

 

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let’s call it ̶= 0;SFC-1”

 

It is possible that each of those SF’s be directly addressable (i= .e. provide SFF functionality) or reachable through some other network device that provides the forwarding (i.e. external, but connected SFF).

 

In this example, SF1 and SF3 provide direct SFF functionality and SF2 r= elies on a connected switch to provide the needed SFF functionality. Connected to that SFF are 20 instances of the SF2 SF. In this case you hav= e exactly 3 network locators from which to choose in order to reach the req= uired SF’s; let’s call them SF1-loc1, SF2-loc2, and SF3-loc3.

 

When an operator instantiates SFC-1 into the network, specific locators= are selected to construct the path, and a path identifier is allocated. In this example there are 3 locators so the SFP for SFC-1 is= SF1-loc1 -> SF2-loc2 -> SF3-loc3 and it has a path identifier “= ;100”. This information is distributed to the relevant network device= s basically saying “if you receive an SFC encapsulated packet with path identifier “100” then use the path identifier= and index to perform a lookup in a data structure that will tell you which= SF to forward the traffic to and how to get there”.

 

So traffic flows through the SFP with path identifier “100”= , via a network transport (the path identifier is encapsulated). It reaches SF1-loc1 which uses the path identifier to determine that it is in fact th= e SF that should be applied. It applies SF1 SF and then uses the path ident= ifier to determine that SF2 is the next service and its reachable at next-h= op SF2-loc2. The needed transport (for example VXLAN) is imposed for network forwarding. Traffic reaches SF2= -loc2. It uses the path identifier to determine that SF2 should be applied.= It uses a local decision to determine which of the 20 instances of SF2 it = should forward the traffic to. It forwards the traffic to the selected instance. SF2 is applied and then ano= ther lookup occurs on the path identifier, which results in the needed tran= sport being imposed to reach the next service hop SF3-loc3 .. And so on and= so forth.

 

So with this example we have exactly 1 SFP.

 

Jim (as a WG participant, not a chair).

 

Date: Thursday, July 10, 2014 at 4:46 PM
To: Jim Guichard <jguichar@= cisco.com>, "mn1921@att.com" <mn1921@att.com>
Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

 


Jim,

 

Technically, wouldn't this be= a Chain Identifier if the next instance is chosen at each hop? In this cas= e, there wouldn't be any Path Identifier at all.

 

But it is the difference betw= een a classifier needing to track the health, etc of 20^4 SF Paths for a si= ngle SF Chain, vs each of the 80 instances tracking 20 SFIs of the next-hop for the chains of which they are members vs each SFF in th= e entire domain tracking all 80 SFIs vs something else.

 



From: j= guichar@cisco.com<jguichar@cis= co.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>
cc: Paul Quinn (paulq)<paulq@c= isco.com>,Lucy yong<lucy.= yong@huawei.com>,jmh@joelhalp= ern.com<jmh@joelhalpern.com>,mohamed.boucadair@or= ange.com<mohamed.bou= cadair@orange.com>,sfc@ietf.org&= lt;sfc@ietf.org>,mikebianc@aol.com<mikebianc@aol.com>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

1 assuming load is distributed among the 20 instances at each service h= op.

Sent from my iPhone


On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Paul,

How many path identifiers there will be= for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: jmh@joelhalpern.com; = mohamed.boucadair@orange.com; sfc@ietf.= org; mikebianc@aol.com
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Lucy,

Overall I concur, as you say: a path I= D drives the forwarding. I’d make the minor change: the path identifi= er can be used to derive the needed forwarding and associated transport.

It is _not_ the transport, but rather = is used to simply identify the service path (or graph) that packets must tr= averse. By having a path identifier, the exact indirection that people seem to be asking for on this thread can be = simply be implemented. The path identifier provides nothing more than a loo= kup, that lookup can result in a one or more (equal or weighted) transport = next hop(s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yon= g <lucy.yong@huawei.com> = wrote:




Agree. The arch. doc should not mandate= only use of the service path identifier to drive the forwarding actions.

Lucy=

Re-,<= /p>

The merged draft calls out explicitly a service path ident= ifier. I object to use that identifier to derive forwarding actions.

Requiring a SFC system to have the full knowledge of every= available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contex= ts.

SFC forwarding actions should rely on the piece of informa= tion that will be present in all deployments: that is the one required to structure a service chain. How that information is = used to infer forwarding actions is a solution-oriented discussion.<= span style=3D"color:black">

Cheers,

Med

De :sfc [mailto:sfc-bounces@ietf.org]De la part demikebianc@aol.com
Envoy=E9 : mercredi 9 j= uillet 2014 22:03
=C0 : jmh@joelhalpern.com;sfc@ietf.org
Objet : Re: [sfc] Servi= ce Chains, Paths, and Load Balancers

Is anyone still questioning the difference = between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that eve= ryone agrees on these terms.<= /span>

To me, the one point that is still unclear = is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or= if this draft simply intends to leave that ambiguous, allowing other draft= s to dictate the mechanisms for forwarding based on chain or path and the c= hoice of chain or path to be negotiated in the control-plane.

If the latter (ambiguous), then the draft w= ould have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting= SFP and others only supporting SFC.

From:jmh@joelhalpern.com<jmh@joelhalpern.com>
To: sfc@ietf.org<sfc@ietf.o= rg>
Sent: Tuesday, July 8, = 2014
Subject: [sfc] Service = Chains, Paths, and Load Balancers

I have been trying to figure out how to clearly answer a number of
comments that have been made about the proposed merged archtiecture
draft. Assuming we can get working group agreement on the intent, we
will work to improve the wording so that readers who have not
participated in the WG discussion will understnd it the way the working
group intends.

But what do we intend? I will try to explain my personal view, and see
if that helps.

In this regard, it is important to keep in mind that what we are
defining is the data plane architecture. We are not attempting to
define the architecture for the entire solution for service chaining.
That would encompass OSS/BSS, various control and policy functions,
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the
larger system, but which are dealt with above where we are functioning,
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them,
I need to first discuss load balancing. There are at least three
different ways that load balancing can and will interact with service
chaining. There probably are more. The point of the archtiecture is to
permit all of these, but not to mandate that any particular kind be used in any solution.

1) Load balancing as a service provided to the end user. This is a
service function. It receives user packets, and modifies them (or marks
them, or ...) so as to choose an end user service instance to receive
the users packet. This is an important service function to be able to
include in service chaining. It's behavior may affect requirements on
how service chaining is done. But it has very little impact on the
archtiecture. From an architectural pe3rspective it is simply a service
function which may modify the underlying packet.

2) There is internal load balancing. That is, one can have what appears
to the service chaining architecture as a single point of contact for a
specific service function, but is actually delivered by a collection of
virtual or physical machines, possibly including one or several load
balancers (for example using VRRP-like techniques to share a MAC
address.) mostly, this is invisible to the service chaining data plane
mechanisms. It is likely that it is visible to various control
mechanisms, such as those responsible for scale-in, scale-out, and vm
instantiation. The architectural impact of permitting this is largely
that we need to be careful that our terminology does not lead readers to think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for
the service chaining that direct traffic to different places. We would
not want to require that a given service function appear at only one
place in the network.

It is of course the case that these may be combined. I tend to refer to
the collection of entities that appear to service chaining as a single
point as a cluster. Not because cluster is a good term. But because I
do not have another one. Thus, the point of type 3 load balancing is to
direct different subsets of traffic to different singular or clustered
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and
service path/ Service chain is a sequence of logical functions to be
applied to a subset of packets. It is equivalent of saying that some
subset of traffic is to get DPI, charging, content inspection, and
firewall while a different subset is to go directly to the cache without visiting any other service functions.

That is not enough information to direct the packets. A service path
is, in some fashion, a sequence of locations in the network. Those
locations will be singular or clustered service function delivery
locations. They may be addressed by IP address. They may be addressed
as ports on an SFF. There are many different ways that the locations
may be known to the service chaining infrastructure and the transport.

>From the point of view of the work of the SFC group, we need to be able=
to talk about the high level abstraction, the service chain, which
drives the forwarding. And we need to talk about the actual data path
packets will take in the network.

Several of the comments have said "but the whole path may not be known=
at the front." This architecture deals with that issue in two ways. First, as noted in item (2) on load balancers above, there can be
decisions and behaviors which are invisible to the service chaining
mechanisms (in much the same way that bridging within a LAN is largely
invisible to routing between LANs.) The other provision we make is that
reclassification can be done in mid-chain when necessary. That will
direct packets to a new chain. Based on information available at the
re-classification point.

I hope that this helps explain what we are after. If it does, and if
the intent is acceptable to the working group, we can figure out what
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

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

________________________________________= _______
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

___________________________= ____________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AF37MISOUT7MSGUSRCF_-- From nobody Fri Jul 11 09:34: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 51EAC1B2911 for ; Fri, 11 Jul 2014 09:34:54 -0700 (PDT) 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_29=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 iGLS6fIWp5nq for ; Fri, 11 Jul 2014 09:34:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51D71A0385 for ; Fri, 11 Jul 2014 09:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C6A3C24066E; Fri, 11 Jul 2014 09:34:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 87234240380; Fri, 11 Jul 2014 09:34:47 -0700 (PDT) Message-ID: <53C01227.9030909@joelhalpern.com> Date: Fri, 11 Jul 2014 12:34:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , Myo.Zarny@gs.com, jguichar@cisco.com, mn1921@att.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org References: <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1236229119.3129.1405095908893.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1236229119.3129.1405095908893.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lvKx3OS7Mf4FsazLs57JzNiqC9Q Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:34:54 -0000 The way the draft uses the terms, and the way most discussions outside the IETF SFC working group use the term, a service function chain is something that you would discuss a policy about. Certain traffic from certain users is supposed to receive a certain sequence of services, the service chain. At the policy level, that does not care where in the network that is delivered. So as to allow control a level of influence, and to have flexibility to have multiple representations in the network of that policy construct, we have the intermediate notion of service function path. If the control system does not need to apply any influence, then it uses one service path for the service chain. If it needs a level of control, it instantiates a suitable number of service paths in the control system, and rules for how those are used. Then, the mapping in the SFF is based on that path, so as to enable the influence of the control system. While still allowing several other layers of traffic management as discussed. Yours, Joel On 7/11/14, 12:25 PM, mikebianc@aol.com wrote: > I meant as a design principle when everything is working. I was trying > to come up with a concise example of configuring a network such that it > does not work that would be analogous to configuring SFC such that "that > remote SFF has the necessary forwarding logic to reach the next-next-SF". > > > > > > ------------------------------------------------------------------------ > *From: *Myo.Zarny@gs.com > *To: > *'mikebianc@aol.com','jguichar@cisco.com','mn1921@att.com','jmh@joelhalpern.com','Ron_Parker@affirmednetworks.com','sfc@ietf.org' > *Sent: *Friday, July 11, 2014 > *Subject: *RE: [sfc] Service Chains, Paths, and Load Balancers > > I don’t understand. (I’m sure I’m misunderstanding…) > > Your backend servers could go down, be unreachable or be unable to > server more. > > Route health injection (RHI) is a perfectly fine, accepted, way of > indicating the health of the backend services to the network. You’re not > saying that’s wrong, are you? > > ** > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > *mikebianc@aol.com > *Sent:* 11 July 2014 12:03 PM > *To:* jguichar@cisco.com ; mn1921@att.com > ; jmh@joelhalpern.com > ; Ron_Parker@affirmednetworks.com > ; sfc@ietf.org > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > heh. well, if it did not, then you should not do it like that. e.g. I'm > not going to configure real servers on a server load balancer that are > not reachable. e.g. I'm not going to configure my BGP to announce > prefixes for which I cannot provide connectivity. If you do things like > that, then you are doing it wrong. > > > > ------------------------------------------------------------------------ > > *From: *jguichar@cisco.com > > *To: *NAPIERALA, MARIA H>,Joel M. > Halpern>,Ron > Parker >,sfc@ietf.org > > > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Then I misunderstand the proposal ;-) .. However, it seems to me that if > you allow an SFF to make a decision as to which remote SFF it will use for > a given flow to reach the next SF within the chain then you better make > sure that that remote SFF has the necessary forwarding logic to reach the > next-next-SF for the chain as otherwise you are in deep trouble. > > On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" > wrote: > > >Absolutely not. Service chains can be instantiated only in relevant SFFs > >when they "arrive". > > > >> -----Original Message----- > >> > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >>(jguichar) > >> Sent: Friday, July 11, 2014 9:27 AM > >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> Well I think it is even worse than that if I have understood the > >>proposal > >> correctly as it would require full knowledge of every single SF within > >>the > >> entire SFC domain at every single SFF as there is no way to know a > >>priori > >> which SFC¹s a given SFF will need to service at any given point in time. > >> > >> On 7/10/14, 11:53 PM, "Joel M. Halpern" > wrote: > >> > >> >Ron, thinking about this, I realized another major problem with the > >>your > >> >proposal as I understand it. (And I readily admit I may not understand > >> >it.) > >> > > >> >The proposal has each SFF serve as the load balancer for the next > >> >service function that follows it (not the one it delivers to), in every > >> >service chain that goes through it. > >> > > >> >Since it has to be able to work with all services, that means that > >>every > >> >SFF would have to be a full, flow sensitive and stateful load balancer. > >> >I ahve no problem if some SFF are flow sensitive, and / or stateful. > >> >But having the architecture require that every SFF be a full, flow > >> >sensitive, stateful, load balancer seems to me to be an acceptable > >> >imposition. > >> > > >> >Yours, > >> >Joel > >> > > >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >> >> Part of my personal view is that I am trying to make this work > >>sensibly > >> >> in a more orchestrated environment. I expect that the service > >> >> functions, and over time probably the SFF capabilities, will be > >> >> orchestrated and installed. I expect the service chains to be > >>driven by > >> >> BSS tools that define offerings to clients, and enable self-selection > >> >> from these. I expect service paths to be heavily policy drive. > >> >> > >> >> I can see how to make all of that work in an archtiecture driven by > >> >> initial classification to described service paths. It is harder to > >>see > >> >> how to make it work (but it can be done) when we allow more > >> dynamicity > >> >> in the network behavior. > >> >> > >> >> Having said that, most of that perspective I described is outside of > >>the > >> >> scope of the working group. it is not something we are tasked to > >>agree > >> >>on. > >> >> So I do not claim that vision means we have to do it a certain way. > >>it > >> >> is just the perspective that drives my preferences. > >> >> > >> >> Yours, > >> >> Joel > >> >> > >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >> >>>> For me, the amount of information about service instances that > >>needs > >> >>>>to > >> >>>> be widely distributed and maintained, potentially even across data > >> >>>> centers within an administrative scope, is large enough and complex > >> >>>> enough that trying to get that into each SFF seems like a difficult > >> >>>> architecture to realize. > >> >>> > >> >>> I'm curious as to why that is more complicated than dynamic routing, > >> >>> hyper-scale data center orchestration, or DNS, all of which are > >>bigger > >> >>> problems that have been profitably and stably implemented? > >> >>> > >> >>> It also seems that if it really is more complicated, that is a good > >> >>> sign that it is too complicated. > >> >>> > >> >>> ________________________________________ > >> >>> From: Joel M. Halpern [jmh@joelhalpern.com > ] > >> >>> Sent: Thursday, July 10, 2014 9:45 PM > >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com > ; Ian Smith; > >> >>> sfc@ietf.org > >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> >>> > >> >>> This is an architectural issue. And one that I would prefer we > >> >>>actually > >> >>> decide, rather than trying to allow all possible implementations. > >> >>> Because it does have a major effect on the control requirements and > >> the > >> >>> functionality of SFFs. > >> >>> > >> >>> For me, the amount of information about service instances that needs > >> to > >> >>> be widely distributed and maintained, potentially even across data > >> >>> centers within an administrative scope, is large enough and complex > >> >>> enough that trying to get that into each SFF seems like a difficult > >> >>> architecture to realize. > >> >>> > >> >>> Yours, > >> >>> Joel > >> >>> > >> >>> But it is a fair question. > >> >>> > >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >> >>>> This is the crux of my issue. Is the end to end selection of > >> >>>> (top-level) instances performed centrally (perhaps by the > >>classifier) > >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the > >>SFFs)? > >> >>>> Such selection is not equivalent to reclassification. And surely, > >> >>>> this is an architectural issue and not relegated to > >> >>>> "implementation". > >> >>>> > >> >>>> My own view is to favor the distributed approach even though a > >> >>>> greater amount of data (chain definitions and perhaps local > >>selection > >> >>>> policy) is required at those distributed decision points. This > >> >>>> approach does not require an end-to-end path id at all. My > >> >>>> rationale for favoring this approach is primarily driven by > >>increased > >> >>>> resiliency over the global path id approach. With a global path > >>id > >> >>>> approach, consider failure of an instance and needing to alter the > >> >>>> global path ID table for each and every affected end-to-end path. > >> >>>> > >> >>>> Ron > >> >>>> > >> >>>> ________________________________________ From: sfc > >> >>>> [sfc-bounces@ietf.org ] on behalf > of Joel Halpern Direct > >> >>>> [jmh.direct@joelhalpern.com > ] Sent: Thursday, July 10, 2014 6:15 PM > >> >>>> To: mikebianc@aol.com ; > I.Smith@F5.com ; sfc@ietf.org > Subject: Re: > >> >>>> [sfc] Service Chains, Paths, and Load Balancers > >> >>>> > >> >>>> The way the architecture models the case of SF1 needing to > >>influence > >> >>>> the chain is that one would do reclassification at the exit from > >> >>>> SF1. > >> >>>> > >> >>>> Part of the goal is to keep the different functions logically > >> >>>> separate so that solutions can clearly describe how they choose to > >> >>>> compose them for "service" delivery. > >> >>>> > >> >>>> Yours, Joel > >> >>>> > >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com > wrote: > >> >>>>> I don't see anything in the arch draft that suggests any sort of > >> >>>>> limit. However, it does seem to indicate that the entire path (all > >> >>>>> SFIs) must be chosen at SFC instantiation. I believe this means > >> >>>>> either at the classifier or maybe the classifier chooses a SF > >>Chain > >> >>>>> and the NF or at the latest the first SFF. In any case, the > >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is > >> >>>>> determined at the SFI(n-1) hop. According to the draft, this > >> >>>>> behavior would be considered "branching" to a new SFP as opposed > >> to > >> >>>>> choosing and then forwarding to the selected instance of the > >> >>>>> next-hop of the current SFC. > >> >>>>> > >> >>>>> draft-merged-sfc-architecture-00: > >> >>>>>> When an SFC is instantiated into the network it is necessary to > >> >>>>>> select the specific instances of SFs that will be used, and to > >> >>>>>> create the service topology for that SFC using SF's network > >> >>>>>> locator. Thus, instantiation of the SFC results in the creation > >> >>>>>> of a Service Function Path (SFP) and is used for forwarding > >> >>>>>> packets through the SFC. In other words, an SFP is the > >> >>>>>> instantiation of the defined SFC. > >> >>>>>> > >> >>>>>> The SFC architecture supports reclassification (or non-initial > >> >>>>>> classification) as well. As packets traverse an SFP, > >> >>>>>> reclassification may occur - typically performed by a > >> >>>>>> classification function co-resident with a service function. > >> >>>>>> Reclassification may result in the selection of a new SFP, an > >> >>>>>> update of the associated metadata, or both. This is referred to > >> >>>>>> as "branching". > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> > >>>>>>>-------------------------------------------------------------------- > >>>>>>>-- > >> >>>>>-- > >> >>>>> > >> >>>>> > >> >>>>> > >> >>> *From: *I.Smith@F5.com > > >> >>>>> *To: *Joel Halpern Direct >,Joel M. > >> >>>>> > >> >>>>>Halpern >,huang@sce.carleton.ca > >> carleton. > >> >>>>>ca>,sfc@ietf.org > > >> >>>>> > >> >>>>> > >> >>>>> > >> >>> *Sent: *Thursday, July 10, 2014 > >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > >> >>>>> > >> >>>>> Actually, I think I am disagreeing. > >> >>>>> > >> >>>>> If the possibility of medium-scale deployments (and that is what > >> >>>>> 16 million flows is in my world) of service chains is preconceived > >> >>>>> as an absurd idea, then the architecture burdened with that > >> >>>>> preconception. > >> >>>>> > >> >>>>> There has to be some point of aim, some degree of aspiration to > >> >>>>> scale that is appropriate for the lifespan of the architecture - > >> >>>>> you don't have to know what it is, but by saying that an arbitrary > >> >>>>> number is "too far", you're creating - even if it isn't > >>intentional > >> >>>>> - a limit that influences decisions that have lasting impacts > >> >>>>> regarding scale-out, failure mitigation, elasticity, address > >> >>>>> space... all kinds of things. That is a problem I'm not > >> >>>>> particularly eager to deal with. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ________________________________________ > >> >>>>> > >> >>>>> > >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com > ] Sent: > >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; > >> >>>>> huang@sce.carleton.ca ; > sfc@ietf.org Subject: Re: [sfc] Service > >> >>>>> Chains, Paths, and Load Balancers > >> >>>>> > >> >>>>> Ian, I don't think you disagree with me at all in this regard. I > >>am > >> >>>>> not requesting the the architecture or the solution prohibit > >> >>>>> deployments in the specific fashion. I am objecting to Huang's > >> >>>>> reading of my note as saying that such deployments are required > >> >>>>> they by the archtiecture. > >> >>>>> > >> >>>>> As I have said repeatedly, I am not trying to prohibit such > >> >>>>> things. Whether they are a good idea or not depends upon many > >> >>>>> factors outside of the scope of the WG. I happen to think that > >>they > >> >>>>> are usually a bad idea. > >> >>>>> > >> >>>>> But the archtiecture si carefully avoiding attempting to know what > >> >>>>> is and is not eployable. > >> >>>>> > >> >>>>> Yours, Joel > >> >>>>> > >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >> >>>>>> I disagree. > >> >>>>>> > >> >>>>>> We routinely have stateful devices that manage tens of millions > >> >>>>>> of > >> >>>>> concurrent flows in both access network and data center > >> >>>>> environments today. You can't seriously believe that in the > >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only > >> going > >> >>>>> to have small numbers of service chains with equally small numbers > >> >>>>> of active service paths? > >> >>>>>> > >> >>>>>> Your sounds too much like "no one will ever need more than 64K" > >> >>>>>> for > >> >>>>> comfort. > >> >>>>>> > >> >>>>>> > >> >>>>>> ________________________________________ From: sfc > >> >>>>>> [sfc-bounces@ietf.org ] on > behalf of Joel M. Halpern > >> >>>>> [jmh@joelhalpern.com ] > >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > huang@sce.carleton.ca ; > >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service > Chains, Paths, and Load > >> >>>>>> Balancers > >> >>>>>> > >> >>>>>> No, it will mean that if someone tries to deploy the archtieture > >> >>>>>> particularly badly, they will exceed the limits of their > >> >>>>>> devices. The architecture does not require such absurd use of > >> >>>>>> service paths. Since I can not figure out how to write > >> >>>>>> architectural words to prohibit it, the architecture does permit > >> >>>>>> such abuse. > >> >>>>>> > >> >>>>>> Please do not read my saying that the archtiecture permits > >> >>>>>> something as saying it is either deisred or required by the work. > >> >>>>>> It isn't. > >> >>>>>> > >> >>>>>> Yours, Joel > >> >>>>>> > >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> >>>>>>> If you need to support 100 service chains, it will mean > >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a > >> >>>>>>> core router. > >> >>>>>>> > >> >>>>>>> Chang > >> >>>>>>> > >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >> >>>>>>>> The architecture allows a range of deployments, from 1 > >> >>>>>>>> service path to 160000 service paths. I would hope that > >> >>>>>>>> operators are prepared for the complexities if they choose to > >> >>>>>>>> avoid any use of local load balancing and in stead provision > >> >>>>>>>> 160,000 service paths. > >> >>>>>>>> > >> >>>>>>>> Yours, Joel > >> >>>>>>>> > >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >> >>>>>>>>> Paul, > >> >>>>>>>>> > >> >>>>>>>>> How many path identifiers there will be for a 4 hop service > >> >>>>>>>>> chain with 20 instances at each hop? > >> >>>>>>>>> > >> >>>>>>>>> Maria > >> >>>>>>>>> > >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 > >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com > ; > >> >>>>>>>>> mohamed.boucadair@orange.com > ; sfc@ietf.org ; > >> >>>>>>>>> mikebianc@aol.com *Subject:* > Re: [sfc] Service Chains, > >> >>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>> > >> >>>>>>>>> Lucy, > >> >>>>>>>>> > >> >>>>>>>>> Overall I concur, as you say: a path ID drives the > >> >>>>>>>>> forwarding. I¹d > >> >>>>> make > >> >>>>>>>>> the minor change: the path identifier can be used to derive > >> >>>>>>>>> the needed forwarding and associated transport. > >> >>>>>>>>> > >> >>>>>>>>> It is _not_ the transport, but rather is used to simply > >> >>>>>>>>> identify the service path (or graph) that packets must > >> >>>>>>>>> traverse. By having a path identifier, the exact > >> >>>>>>>>> indirection that people seem to be asking for on this > >> >>>>>>>>> thread can be simply be implemented. The path identifier > >> >>>>>>>>> provides nothing more than a lookup, that lookup can result > >> >>>>>>>>> in a one or more (equal or weighted) transport next > >> >>>>>>>>> hop(s). > >> >>>>>>>>> > >> >>>>>>>>> Paul > >> >>>>>>>>> > >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >> >>>>>>>>> >> > >> >>>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the > >> >>>>>>>>> service path identifier to drive the forwarding actions. > >> >>>>>>>>> > >> >>>>>>>>> Lucy > >> >>>>>>>>> > >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >> >>>>>>>>> Of*mohamed.boucadair@orange.com > > >> >>>>>>>>> *Sent:*Thursday, > >> July > >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > > >> >>>>>>>>> ;jmh@joelhalpern.com > > >> >>>>>>>>> ;sfc@ietf.org > > >> >>>>>>>>> *Subject:*Re: [sfc] Service Chains, > >> >>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>> > >> >>>>>>>>> Re-, > >> >>>>>>>>> > >> >>>>>>>>> The merged draft calls out explicitly a service path > >> >>>>>>>>> identifier. I object to use that identifier to derive > >> >>>>>>>>> forwarding actions. > >> >>>>>>>>> > >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every > >> >>>>> available SFC > >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >> >>>>> required/justified > >> >>>>>>>>> nor possible in various deployment contexts. > >> >>>>>>>>> > >> >>>>>>>>> SFC forwarding actions should rely on the piece of > >> >>>>>>>>> information > >> >>>>> that will > >> >>>>>>>>> be present in all deployments: that is the one required to > >> >>>>>>>>> structure a service chain. How that information is used to > >> >>>>>>>>> infer forwarding > >> >>>>> actions > >> >>>>>>>>> is a solution-oriented discussion. > >> >>>>>>>>> > >> >>>>>>>>> Cheers, > >> >>>>>>>>> > >> >>>>>>>>> Med > >> >>>>>>>>> > >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >> >>>>> de*mikebianc@aol.com > >> >>>>>>>>> *Envoyé :*mercredi 9 juillet > >> >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com > > >> >>>>>>>>> ;sfc@ietf.org > > >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains, > >> >>>>>>>>> Paths, and Load Balancers > >> >>>>>>>>> > >> >>>>>>>>> Is anyone still questioning the difference between SF Chain > >> >>>>>>>>> and SF > >> >>>>> Path? > >> >>>>>>>>> Other than clarifying the definition so that it's clear to > >> >>>>> those not > >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on > >> >>>>>>>>> these terms. > >> >>>>>>>>> > >> >>>>>>>>> To me, the one point that is still unclear is whether it is > >> >>>>>>>>> the intent of this draft to ultimately specify what the ID > >> >>>>>>>>> of the SFC Header > >> >>>>> should > >> >>>>>>>>> reference (the chain or the path), or if this draft simply > >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to > >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or > >> >>>>>>>>> path and the choice of chain or > >> >>>>> path to > >> >>>>>>>>> be negotiated in the control-plane. > >> >>>>>>>>> > >> >>>>>>>>> If the latter (ambiguous), then the draft would have > >> >>>>>>>>> require that both SFP and SFC be supported (or make one > >> >>>>>>>>> required and the other optional) to avoid some vendors only > >> >>>>>>>>> supporting SFP and others only supporting SFC. > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>> > >> > >>>>>>>-------------------------------------------------------------------- > >>>>>>>-- > >> >>>>>-- > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>>>> > >> >>>>>>>>> *From:*jmh@joelhalpern.com > >> >>>>>>>>> > > > >> >>>>>>>>> *To:*sfc@ietf.org >> >>>>>>>>> > > *Sent:*Tuesday, July > >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load > >> >>>>>>>>> Balancers > >> >>>>>>>>> > >> >>>>>>>>> I have been trying to figure out how to clearly answer a > >> >>>>>>>>> number of comments that have been made about the proposed > >> >>>>>>>>> merged archtiecture draft. Assuming we can get working > >> >>>>>>>>> group agreement on the intent, we will work to improve the > >> >>>>>>>>> wording so that readers who have not participated in the WG > >> >>>>>>>>> discussion will understnd it the way the > >> >>>>> working > >> >>>>>>>>> group intends. > >> >>>>>>>>> > >> >>>>>>>>> But what do we intend? I will try to explain my personal > >> >>>>>>>>> view, and see if that helps. > >> >>>>>>>>> > >> >>>>>>>>> In this regard, it is important to keep in mind that what > >> >>>>>>>>> we are defining is the data plane architecture. We are not > >> >>>>>>>>> attempting to define the architecture for the entire > >> >>>>>>>>> solution for service chaining. That would encompass > >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual > >> >>>>>>>>> machine and image management, and many other aspects. > >> >>>>>>>>> > >> >>>>>>>>> As a result there are many things which clearly need to > >> >>>>>>>>> exist in the larger system, but which are dealt with above > >> >>>>>>>>> where we are > >> >>>>> functioning, > >> >>>>>>>>> and are not directly required by the work we are doing. > >> >>>>>>>>> > >> >>>>>>>>> In order to get to service chain vs service path, as I > >> >>>>>>>>> understand > >> >>>>> them, > >> >>>>>>>>> I need to first discuss load balancing. There are at least > >> >>>>>>>>> three different ways that load balancing can and will > >> >>>>>>>>> interact with service chaining. There probably are more. > >> >>>>>>>>> The point of the archtiecture is to permit all of these, > >> >>>>>>>>> but not to mandate that any particular kind > >> >>>>> be used > >> >>>>>>>>> in any solution. > >> >>>>>>>>> > >> >>>>>>>>> 1) Load balancing as a service provided to the end user. > >> >>>>>>>>> This is a service function. It receives user packets, and > >> >>>>>>>>> modifies them (or > >> >>>>> marks > >> >>>>>>>>> them, or ...) so as to choose an end user service instance > >> >>>>>>>>> to receive the users packet. This is an important service > >> >>>>>>>>> function to be able to include in service chaining. It's > >> >>>>>>>>> behavior may affect requirements on how service chaining is > >> >>>>>>>>> done. But it has very little impact on the archtiecture. > >> >>>>>>>>> From an architectural pe3rspective it is simply a > >> >>>>> service > >> >>>>>>>>> function which may modify the underlying packet. > >> >>>>>>>>> > >> >>>>>>>>> 2) There is internal load balancing. That is, one can have > >> >>>>>>>>> what > >> >>>>> appears > >> >>>>>>>>> to the service chaining architecture as a single point of > >> >>>>>>>>> contact > >> >>>>> for a > >> >>>>>>>>> specific service function, but is actually delivered by a > >> >>>>> collection of > >> >>>>>>>>> virtual or physical machines, possibly including one or > >> >>>>>>>>> several load balancers (for example using VRRP-like > >> >>>>>>>>> techniques to share a MAC address.) mostly, this is > >> >>>>>>>>> invisible to the service chaining data plane mechanisms. It > >> >>>>>>>>> is likely that it is visible to various control mechanisms, > >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm > >> >>>>>>>>> instantiation. The architectural impact of permitting this > >> >>>>>>>>> is largely that we need to be careful that our terminology > >> >>>>>>>>> does not lead > >> >>>>> readers to > >> >>>>>>>>> think we are prohibiting it. > >> >>>>>>>>> > >> >>>>>>>>> 3) There can also be load balancing done by selecting > >> >>>>>>>>> packet paths for the service chaining that direct traffic > >> >>>>>>>>> to different places. We would not want to require that a > >> >>>>>>>>> given service function appear at only one place in the > >> >>>>>>>>> network. > >> >>>>>>>>> > >> >>>>>>>>> It is of course the case that these may be combined. I tend > >> >>>>>>>>> to > >> >>>>> refer to > >> >>>>>>>>> the collection of entities that appear to service chaining > >> >>>>>>>>> as a single point as a cluster. Not because cluster is a > >> >>>>>>>>> good term. But because I do not have another one. Thus, the > >> >>>>>>>>> point of type 3 load balancing > >> >>>>> is to > >> >>>>>>>>> direct different subsets of traffic to different singular > >> >>>>>>>>> or clustered service functions in different places in the > >> >>>>>>>>> network. > >> >>>>>>>>> > >> >>>>>>>>> Now with that said, what do I mean when I talk about > >> >>>>>>>>> service chain and service path/ Service chain is a sequence > >> >>>>>>>>> of logical functions to be applied to a subset of packets. > >> >>>>>>>>> It is equivalent of saying that some subset of traffic is > >> >>>>>>>>> to get DPI, charging, content inspection, and firewall > >> >>>>>>>>> while a different subset is to go directly to the cache > >> >>>>> without > >> >>>>>>>>> visiting any other service functions. > >> >>>>>>>>> > >> >>>>>>>>> That is not enough information to direct the packets. A > >> >>>>>>>>> service path is, in some fashion, a sequence of locations > >> >>>>>>>>> in the network. Those locations will be singular or > >> >>>>>>>>> clustered service function delivery locations. They may be > >> >>>>>>>>> addressed by IP address. They may be addressed as ports on > >> >>>>>>>>> an SFF. There are many different ways that the locations > >> >>>>>>>>> may be known to the service chaining infrastructure and the > >> >>>>>>>>> transport. > >> >>>>>>>>> > >> >>>>>>>>>> From the point of view of the work of the SFC group, we > >> >>>>>>>>>> need to be > >> >>>>>>>>> able to talk about the high level abstraction, the service > >> >>>>>>>>> chain, which drives the forwarding. And we need to talk > >> >>>>>>>>> about the actual data path packets will take in the > >> >>>>>>>>> network. > >> >>>>>>>>> > >> >>>>>>>>> Several of the comments have said "but the whole path may > >> >>>>>>>>> not be known at the front." This architecture deals with > >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load > >> >>>>>>>>> balancers above, there can be decisions and behaviors which > >> >>>>>>>>> are invisible to the service chaining mechanisms (in much > >> >>>>>>>>> the same way that bridging within a LAN is largely > >> >>>>>>>>> invisible to routing between LANs.) The other provision we > >> >>>>>>>>> make is > >> >>>>> that > >> >>>>>>>>> reclassification can be done in mid-chain when necessary. > >> >>>>>>>>> That will direct packets to a new chain. Based on > >> >>>>>>>>> information available at the re-classification point. > >> >>>>>>>>> > >> >>>>>>>>> I hope that this helps explain what we are after. If it > >> >>>>>>>>> does, and if the intent is acceptable to the working group, > >> >>>>>>>>> we can figure out what additional words are needed to > >> >>>>>>>>> convey this. If the working group disagree with the intent, > >> >>>>>>>>> then we will of course adjust to match the working group > >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to > >> >>>>>>>>> try next. > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ sfc > >> mailing > >> >>>>>>>>> list sfc@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ sfc > >> mailing > >> >>>>>>>>> list sfc@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ sfc > >> mailing > >> >>>>>>>> list sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> _______________________________________________ sfc > >> mailing > >> >>>>>>> list sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>>> > >> >>>>>> > >> >>>>>> _______________________________________________ sfc mailing > >> list > >> >>>>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>>>> > >> >>>>> > >> >>>>> _______________________________________________ sfc mailing > >> list > >> >>>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>> > >> >>>> _______________________________________________ sfc mailing > >> list > >> >>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>> > >> >>>> _______________________________________________ sfc mailing > >> list > >> >>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > >> >>>> > >> >>> > >> >> > >> >> _______________________________________________ > >> >> sfc mailing list > >> >> sfc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/sfc > >> >> > >> > > >> >_______________________________________________ > >> >sfc mailing list > >> >sfc@ietf.org > >> >https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing 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 Jul 11 09:38: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 BFDC01B2BC2 for ; Fri, 11 Jul 2014 09:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzI-0j6YtW_D for ; Fri, 11 Jul 2014 09:38:02 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E711B2BC3 for ; Fri, 11 Jul 2014 09:38:01 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 9e210c35.2ac0488b3940.6759263.00-2449.18715157.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:38:01 +0000 (UTC) X-MXL-Hash: 53c012e9707edaf5-50cc0513f737c2f2b31bc21fb68f57bc8bc8f688 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id dd210c35.0.6759174.00-2387.18714894.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:37:50 +0000 (UTC) X-MXL-Hash: 53c012de11b5f415-228967aa3c1ddc7ad9211c6b5bdf821931f76602 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGbnBC002494; Fri, 11 Jul 2014 12:37:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGbgk4002452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:37:45 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:37:24 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:37:24 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA///Q1oCAAEKp8P//yI4AgAA9hfD//8yhgIAAQnMQ Date: Fri, 11 Jul 2014 16:37:24 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=K5mV6VqI c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH] X-AnalysisOut: [86SAAAA:8 a=Ztuu8nrycVTbFyw9mJkA:9 a=QEXdDO2ut3YA:10 a=Hz7] X-AnalysisOut: [IrDYlS0cA:10 a=JfD0Fch1gWkA:10 a=oAXR_kdF8uMA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySEA:10 a=3XJ037Qrwtg] X-AnalysisOut: [A:10 a=mvZ2XyujAn7j_lWw:21 a=jKWgIyWfH9_FG9HK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/U3iNWzRhWZmuJS4-6WrJHvl660c Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:38:09 -0000 PiA+PiBJIHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg aXMgc2ltcGx5IGEgcG9pbnRlcg0KPiA+PnRvDQo+ID4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBj b250YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UNCj4gZGVmaW5lDQo+ID5Z b3UgYXJlIHRhbGtpbmcgYWJvdXQgdHJhZmZpYyBlbmdpbmVlcmluZyBvZiBwYXRocyB0aGF0IGEg c2VydmljZSBjaGFpbg0KPiA+Y2FuIHRha2UuDQo+ID5UaGlzIHN1cmVseSBjb3VsZCBiZSBkb25l L2FsbG93ZWQgYnV0IHRoaXMgY2Fubm90IGJlIGEgcmVxdWlyZW1lbnQgZm9yDQo+ID5hbGwgdHJh ZmZpYy4NCj4gDQo+IEppbT4gdGhhdOKAmXMgd2h5IEkgc2FpZCAqbWlnaHQqIC0gSU9XIHlvdSBk byBub3QgaGF2ZSB0bywgaXRzIGEgZGVwbG95bWVudA0KPiBjaG9pY2UgYW5kIGlzIHN1cHBvcnRl ZCBieSB0aGUgYXJjaGl0ZWN0dXJlLg0KDQpZZXMsIEkgbm90aWNlZCwgYnV0IEkgYWxzbyBub3Rp Y2VkIHRoYXQgeW91IGFyZSBwcm9wb3NpbmcgYSBzb2x1dGlvbiBiYXNlZCBvbiBpdC4NCg0KWW91 IGhhdmUgbm90IGNvbW1lbnQgb24gdGhlIHJlc3Q6IGlzIGl0IHN0aWxsICJzZXJ2aWNlICpwYXRo KiBpZGVudGlmaWVyIj8NCg0KTWFyaWENCg0KPiA+PiBPbiA3LzExLzE0LCAxMToyNiBBTSwgIk5B UElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPiB3cm90ZToNCj4gPj4NCj4gPj4g PkppbSwNCj4gPj4gPg0KPiA+PiA+Q291bGQgeW91IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5p dGlvbiBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCBhDQo+ID4+ID4ic2VydmljZSBwYXRoIGlkZW50 aWZpZXIiPw0KPiA+PiA+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFu Y2VzIGFyZSBjaG9zZW4gYXByaW9yaQ0KPiA+Pih3aGljaA0KPiA+PiA+aXMgbXkgY3VycmVudCB1 bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0K PiA+PiA+bmV4dC1ob3AgU0ZGIHRvIHBpY2suICBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9u Lg0KPiA+PiA+DQo+ID4+ID5NYXJpYQ0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikg W21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ID4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNCAxMToxNSBBTQ0KPiA+PiA+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKb2VsIE0uDQo+ID4+ID4+IEhhbHBlcm47IFJvbiBQYXJr ZXI7IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4NCj4gPj4gPj4gSeKAmW0gc29y cnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGggaWRl bnRpZmllcg0KPiA+PiA+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhv cHMgb3Igd2h5IGNhbGxpbmcgaXQgYQ0KPiA+PnNlcnZpY2UNCj4gPj4gPj4gY2hhaW4gaWRlbnRp ZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT8NCj4gPj4gPj4NCj4gPj4gPj4gT24gNy8xMS8xNCwg MTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4gPj4gd3Jv dGU6DQo+ID4+ID4+DQo+ID4+ID4+ID5EaXR0by4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiA+PiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+ID4+ID4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbV0NCj4gPj4gPj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+ ID4+ID4+ID4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBI OyBKb2VsIE0uIEhhbHBlcm47DQo+ID4+IFJvbg0KPiA+PiA+PiA+PiBQYXJrZXI7IHNmY0BpZXRm Lm9yZw0KPiA+PiA+PiA+PiBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gUmUtLA0KPiA+PiA+ PiA+Pg0KPiA+PiA+PiA+PiBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBk ZXNjcmliZWQgY2xlYXJseSBpbiB0aGUNCj4gPj4gPj5kcmFmdC4NCj4gPj4gPj4gPj4NCj4gPj4g Pj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEg aGludCB0aGF0IHRoZQ0KPiA+PmZ1bGwNCj4gPj4gPj4gPj5kaXN0cmlidXRlZA0KPiA+PiA+PiA+ PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gU2V2ZXJhbCB2 b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4NCj4g Pj5pdHNlbGYNCj4gPj4gPj4gPj5zaG91bGQgYmUNCj4gPj4gPj4gPj4gcHJvdmlkZWQgaW5zdGVh ZC4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gQ2hlZXJzLA0KPiA+PiA+PiA+PiBNZWQNCj4gPj4g Pj4gPj4NCj4gPj4gPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiA+PiA+ PiA+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBK aW0gR3VpY2hhcmQNCj4gPj4gPj4gPj4gPihqZ3VpY2hhcikNCj4gPj4gPj4gPj4gPkVudm95w6kg OiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4gPj4gPj4gPj4gPsOAIDogTkFQSUVS QUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+IHNmY0BpZXRmLm9y Zw0KPiA+PiA+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPg0KPiA+PiA+PiA+PiA+T2sgYnV0IHdoZXJl IGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMNCj4gPj5mdW5jdGlvbmFs aXR5DQo+ID4+ID4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICph bGwqIG5leHQtaG9wcyB0byAqYWxsKg0KPiA+PlNGRuKAmXMNCj4gPj4gPj4gPj4gPndpdGhpbiB0 aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBh DQo+ID4+ID4+ID4+bG9va3VwDQo+ID4+ID4+ID4+ID5pbnRvIHRob3NlIG5leHQtaG9wcyB0byBy ZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+ID4+ID4+c3VyZQ0KPiA+ PiA+PiA+Pmhvdw0KPiA+PiA+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0K PiA+PiA+PiA+PiA+DQo+ID4+ID4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxB LCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+PiA+PiA+ DQo+ID4+ID4+ID4+ID4+QWJzb2x1dGVseS4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+ID4+ID4+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPiA+Pkd1aWNoYXJk DQo+ID4+ID4+ID4+ID4+PihqZ3VpY2hhcikNCj4gPj4gPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwg SnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+ID4+ID4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+ID4+IHNmY0BpZXRmLm9yZw0KPiA+ PiA+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gVGhlbiBJIG1p c3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0bw0KPiA+ Pm1lDQo+ID4+ID4+ID4+dGhhdCBpZg0KPiA+PiA+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0 byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdA0KPiA+PiA+PndpbGwN Cj4gPj4gPj4gPj51c2UNCj4gPj4gPj4gPj4gPj4+Zm9yDQo+ID4+ID4+ID4+ID4+PiBhIGdpdmVu IGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPiA+ PiA+PmJldHRlcg0KPiA+PiA+PiA+Pm1ha2UNCj4gPj4gPj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0 IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYw0KPiA+PnRvDQo+ ID4+ID4+ID4+cmVhY2gNCj4gPj4gPj4gPj4gPj4+dGhlDQo+ID4+ID4+ID4+ID4+PiBuZXh0LW5l eHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwDQo+ID4+dHJv dWJsZS4NCj4gPj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFN LCAiTkFQSUVSQUxBLCBNQVJJQSBIIg0KPiA8bW4xOTIxQGF0dC5jb20+DQo+ID4+ID4+ID4+IHdy b3RlOg0KPiA+PiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4+ID5BYnNvbHV0ZWx5IG5vdC4gU2Vy dmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluDQo+ID4+ID4+cmVsZXZhbnQN Cj4gPj4gPj4gPj4gPj4+U0ZGcw0KPiA+PiA+PiA+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4N Cj4gPj4gPj4gPj4gPj4+ID4NCj4gPj4gPj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+ID4+ID4+ID4+PiA+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPiA+PiA+Pkd1aWNoYXJkDQo+ID4+ID4+ID4+ID4+ PiA+PihqZ3VpY2hhcikNCj4gPj4gPj4gPj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwg MjAxNCA5OjI3IEFNDQo+ID4+ID4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ID4+QmFsYW5jZXJzDQo+ID4+ID4+ ID4+ID4+PiA+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29y c2UgdGhhbiB0aGF0IGlmIEkgaGF2ZQ0KPiA+PnVuZGVyc3Rvb2QNCj4gPj4gPj50aGUNCj4gPj4g Pj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4gPj4gPj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3 b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5DQo+ID4+c2luZ2xlDQo+ID4+ID4+ U0YNCj4gPj4gPj4gPj4gPj4+d2l0aGluDQo+ID4+ID4+ID4+ID4+PiA+PnRoZQ0KPiA+PiA+PiA+ PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBp cyBubyB3YXkgdG8NCj4gPj4gPj5rbm93DQo+ID4+ID4+ID4+YQ0KPiA+PiA+PiA+PiA+Pj4gPj5w cmlvcmkNCj4gPj4gPj4gPj4gPj4+ID4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5l ZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4NCj4gPj4gPj5wb2ludA0KPiA+PiA+PiA+PmluDQo+ ID4+ID4+ID4+ID4+PnRpbWUuDQo+ID4+ID4+ID4+ID4+PiA+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4g T24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iDQo+ID4+IDxqbWhAam9lbGhh bHBlcm4uY29tPg0KPiA+PiA+PiA+PiB3cm90ZToNCj4gPj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIg bWFqb3IgcHJvYmxlbQ0KPiA+PiA+PndpdGgNCj4gPj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+ ID4+eW91cg0KPiA+PiA+PiA+PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4g IChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5DQo+ID4+bm90DQo+ID4+ID4+ID4+ID4+PnVuZGVy c3RhbmQNCj4gPj4gPj4gPj4gPj4+ID4+ID5pdC4pDQo+ID4+ID4+ID4+ID4+PiA+PiA+DQo+ID4+ ID4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9h ZCBiYWxhbmNlciBmb3INCj4gPj50aGUNCj4gPj4gPj4gPj5uZXh0DQo+ID4+ID4+ID4+ID4+PiA+ PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2 ZXJzDQo+ID4+ID4+dG8pLA0KPiA+PiA+PiA+PmluDQo+ID4+ID4+ID4+ID4+PmV2ZXJ5DQo+ID4+ ID4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4gPj4g Pj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJs ZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0DQo+ID4+bWVhbnMNCj4gPj4gPj4gPj50 aGF0DQo+ID4+ID4+ID4+ID4+PiA+PmV2ZXJ5DQo+ID4+ID4+ID4+ID4+PiA+PiA+U0ZGIHdvdWxk IGhhdmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwNCj4gPj5sb2Fk DQo+ID4+ID4+ID4+ID4+PmJhbGFuY2VyLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPkkgYWh2ZSBubyBw cm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3INCj4gPj4gPj4g Pj5zdGF0ZWZ1bC4NCj4gPj4gPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1 cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhDQo+ID4+ZnVsbCwNCj4gPj4gPj4gPj5mbG93 DQo+ID4+ID4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBz ZWVtcyB0byBtZSB0byBiZSBhbg0KPiA+PiA+PiA+PmFjY2VwdGFibGUNCj4gPj4gPj4gPj4gPj4+ ID4+ID5pbXBvc2l0aW9uLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPg0KPiA+PiA+PiA+PiA+Pj4gPj4g PllvdXJzLA0KPiA+PiA+PiA+PiA+Pj4gPj4gPkpvZWwNCj4gPj4gPj4gPj4gPj4+ID4+ID4NCj4g Pj4gPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdy b3RlOg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRo YXQgSSBhbSB0cnlpbmcgdG8gbWFrZQ0KPiA+PnRoaXMNCj4gPj4gPj53b3JrDQo+ID4+ID4+ID4+ ID4+PiA+PnNlbnNpYmx5DQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJh dGVkIGVudmlyb25tZW50LiAgSSBleHBlY3QgdGhhdCB0aGUNCj4gPj4gPj5zZXJ2aWNlDQo+ID4+ ID4+ID4+ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNG RiBjYXBhYmlsaXRpZXMsDQo+ID4+ID4+d2lsbA0KPiA+PiA+PiA+PmJlDQo+ID4+ID4+ID4+ID4+ PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gIEkgZXhwZWN0IHRoZSBzZXJ2aWNl IGNoYWlucw0KPiA+PiA+PnRvIGJlDQo+ID4+ID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRz LCBhbmQgZW5hYmxlDQo+ID4+ID4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+ID4+ID4+ID4+ID4+ PiA+PiA+PiBmcm9tIHRoZXNlLiAgSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5 IHBvbGljeQ0KPiA+PiA+PiA+PmRyaXZlLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4NCj4gPj4gPj4g Pj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFu DQo+ID4+YXJjaHRpZWN0dXJlDQo+ID4+ID4+ID4+ZHJpdmVuDQo+ID4+ID4+ID4+ID4+PmJ5DQo+ ID4+ID4+ID4+ID4+PiA+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBz ZXJ2aWNlIHBhdGhzLiAgSXQNCj4gPj5pcw0KPiA+PiA+PiA+PmhhcmRlcg0KPiA+PiA+PiA+PiA+ Pj50bw0KPiA+PiA+PiA+PiA+Pj4gPj5zZWUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBt YWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdw0KPiA+PiBtb3Jl DQo+ID4+ID4+ID4+ID4+PiA+PiBkeW5hbWljaXR5DQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBpbiB0 aGUgbmV0d29yayBiZWhhdmlvci4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+ PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNj cmliZWQNCj4gPj5pcw0KPiA+PiA+PiA+Pm91dHNpZGUNCj4gPj4gPj4gPj4gPj4+b2YNCj4gPj4g Pj4gPj4gPj4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2lu ZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+ID4+ID4+ID4+dGFza2VkIHRv DQo+ID4+ID4+ID4+ID4+PiA+PmFncmVlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pm9uLg0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2 ZSB0byBkbyBpdCBhDQo+ID4+ID4+Y2VydGFpbg0KPiA+PiA+PiA+PiA+Pj53YXkuDQo+ID4+ID4+ ID4+ID4+PiA+Pml0DQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2 ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ ID4+ID4+ID4+PiA+PiA+PiBZb3VycywNCj4gPj4gPj4gPj4gPj4+ID4+ID4+IEpvZWwNCj4gPj4g Pj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBN LCBJYW4gU21pdGggd3JvdGU6DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IEZvciBtZSwgdGhlIGFt b3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlDQo+ID4+IGluc3RhbmNlcw0KPiA+PiA+ PiA+PiB0aGF0DQo+ID4+ID4+ID4+ID4+PiA+Pm5lZWRzDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ dG8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWlu dGFpbmVkLCBwb3RlbnRpYWxseQ0KPiBldmVuDQo+ID4+ID4+ID4+YWNyb3NzDQo+ID4+ID4+ID4+ ID4+PmRhdGENCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5p c3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlDQo+ID4+ZW5vdWdoDQo+ID4+ID4+YW5kDQo+ID4+ID4+ ID4+ID4+PiBjb21wbGV4DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWlu ZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+ID4+bGlrZSBhDQo+ID4+ID4+ID4+ ID4+PmRpZmZpY3VsdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+IEknbSBj dXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbg0KPiA+PiA+PmR5 bmFtaWMNCj4gPj4gPj4gPj4gPj4+IHJvdXRpbmcsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gaHlw ZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2YNCj4gPj4g Pj53aGljaA0KPiA+PiA+PiA+PmFyZQ0KPiA+PiA+PiA+PiA+Pj4gPj5iaWdnZXINCj4gPj4gPj4g Pj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFi bHkNCj4gPj4gaW1wbGVtZW50ZWQ/DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxp Y2F0ZWQsDQo+ID4+dGhhdA0KPiA+PiA+PmlzDQo+ID4+ID4+ID4+YQ0KPiA+PiA+PiA+PiA+Pj5n b29kDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRl ZC4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBG cm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0Ow0KPiBtaWtl YmlhbmNAYW9sLmNvbTsNCj4gPj4gPj5JYW4NCj4gPj4gPj4gPj4gPj4+U21pdGg7DQo+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVj dDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4gPj5CYWxh bmNlcnMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMg aXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gIEFuZCBvbmUgdGhhdCBJIHdvdWxkDQo+ID4+ID4+ cHJlZmVyDQo+ID4+ID4+ID4+d2UNCj4gPj4gPj4gPj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxs IHBvc3NpYmxlDQo+ID4+ID4+ID4+aW1wbGVtZW50YXRpb25zLg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+ ID4+ID4+ID4+cmVxdWlyZW1lbnRzDQo+ID4+ID4+ID4+ID4+PmFuZA0KPiA+PiA+PiA+PiA+Pj4g Pj4gdGhlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1v dW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UNCj4gPj4gaW5zdGFuY2VzDQo+ID4+ID4+ ID4+dGhhdA0KPiA+PiA+PiA+PiA+Pj4gbmVlZHMNCj4gPj4gPj4gPj4gPj4+ID4+IHRvDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBw b3RlbnRpYWxseSBldmVuDQo+ID4+ID4+IGFjcm9zcw0KPiA+PiA+PiA+PiA+Pj5kYXRhDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUs IGlzIGxhcmdlIGVub3VnaA0KPiA+PiA+PmFuZA0KPiA+PiA+PiA+PiA+Pj5jb21wbGV4DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFj aCBTRkYgc2VlbXMNCj4gPj5saWtlIGENCj4gPj4gPj4gPj4gPj4+ZGlmZmljdWx0DQo+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4gPj4gPj4gPj4gPj4+ID4+ID4+ PiBKb2VsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBCdXQg aXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0aGUg ZW5kIHRvIGVuZA0KPiA+PiA+PnNlbGVjdGlvbg0KPiA+PiA+PiA+Pm9mDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJo YXBzIGJ5DQo+ID4+dGhlDQo+ID4+ID4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5k DQo+ID4+IHN1YnNlcXVlbnRseQ0KPiA+PiA+PiA+PnRoZQ0KPiA+PiA+PiA+PiA+Pj4gPj5TRkZz KT8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxl bnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4gPj4gPj5BbmQNCj4gPj4gPj4gPj4gPj4+c3VyZWx5 LA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUg YW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0 aW9uIi4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gTXkg b3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoDQo+IGV2ZW4NCj4g Pj4gPj4gdGhvdWdoDQo+ID4+ID4+ID4+IGENCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gZ3JlYXRl ciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMNCj4gPj4gPj5s b2NhbA0KPiA+PiA+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4g cG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0KPiA+PnBv aW50cy4NCj4gPj4gPj4gPj5UaGlzDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRv ZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0DQo+ID4+YWxsLg0KPiA+PiA+ PiA+Pk15DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhp cyBhcHByb2FjaCBpcyBwcmltYXJpbHkNCj4gPj5kcml2ZW4NCj4gPj4gPj5ieQ0KPiA+PiA+PiA+ PiA+Pj4gPj5pbmNyZWFzZWQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVy IHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gICBXaXRoIGENCj4gPj4gPj5nbG9iYWwNCj4g Pj4gPj4gPj4gPj4+cGF0aA0KPiA+PiA+PiA+PiA+Pj4gPj5pZA0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGlu Zw0KPiA+PnRvDQo+ID4+ID4+ID4+YWx0ZXINCj4gPj4gPj4gPj4gPj4+dGhlDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZl Y3RlZA0KPiA+PiA+PmVuZC10by1lbmQNCj4gPj4gPj4gPj4gPj4+cGF0aC4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gRnJvbToNCj4gc2ZjDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMt Ym91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybg0KPiA+PkRpcmVjdA0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDEwLA0KPiA+PiA+PjIwMTQNCj4gPj4gPj4gPj4gNjoxNQ0KPiA+PiA+ PiA+PiA+Pj4gUE0NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gVG86IG1pa2ViaWFuY0Bhb2wuY29t OyBJLlNtaXRoQEY1LmNvbTsgc2ZjQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6DQo+ID4+ID4+ ID4+IFJlOg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9m IFNGMQ0KPiA+Pm5lZWRpbmcNCj4gPj4gPj50bw0KPiA+PiA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJl Y2xhc3NpZmljYXRpb24gYXQgdGhlDQo+ID4+ID4+ZXhpdA0KPiA+PiA+PiA+PmZyb20NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVudCBm dW5jdGlvbnMNCj4gPj4gPj4gPj5sb2dpY2FsbHkNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gc2Vw YXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93DQo+ID4+dGhl eQ0KPiA+PiA+PiA+PiBjaG9vc2UNCj4gPj4gPj4gPj4gPj4+dG8NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4gY29tcG9zZSB0aGVtIGZvciAic2VydmljZSIgZGVsaXZlcnkuDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAgUE0s IG1pa2ViaWFuY0Bhb2wuY29tIHdyb3RlOg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24n dCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cw0KPiA+PmFueQ0K PiA+PiA+PiA+PnNvcnQNCj4gPj4gPj4gPj4gPj4+b2YNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUNCj4gPj5l bnRpcmUNCj4gPj4gPj4gPj5wYXRoDQo+ID4+ID4+ID4+ID4+PihhbGwNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0aW9uLiAgSSBi ZWxpZXZlDQo+ID4+ID4+dGhpcw0KPiA+PiA+PiA+PiA+Pj5tZWFucw0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVy DQo+ID4+ID4+Y2hvb3NlcyBhDQo+ID4+ID4+ID4+U0YNCj4gPj4gPj4gPj4gPj4+ID4+Q2hhaW4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUg Zmlyc3QgU0ZGLiAgSW4gYW55DQo+ID4+Y2FzZSwNCj4gPj4gPj4gPj50aGUNCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1p YyBTRlANCj4gPj4gd2hlcmUNCj4gPj4gPj4gPj4gU0ZJKG4pDQo+ID4+ID4+ID4+ID4+PiBpcw0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiAg QWNjb3JkaW5nIHRvIHRoZQ0KPiA+PmRyYWZ0LA0KPiA+PiA+PiA+PnRoaXMNCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8g YSBuZXcNCj4gU0ZQDQo+ID4+IGFzDQo+ID4+ID4+ID4+ID4+PiBvcHBvc2VkDQo+ID4+ID4+ID4+ ID4+PiA+PiB0bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9y d2FyZGluZyB0byB0aGUgc2VsZWN0ZWQNCj4gaW5zdGFuY2UNCj4gPj4gb2YNCj4gPj4gPj4gPj50 aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1t ZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBXaGVu IGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpcw0KPiA+PiA+PiA+ Pm5lY2Vzc2FyeQ0KPiA+PiA+PiA+PiA+Pj50bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNl bGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUNCj4gPj51c2Vk LA0KPiA+PiA+PiA+PmFuZCB0bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUg c2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Yncw0KPiA+PiA+PiA+Pm5ldHdv cmsNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiAgVGh1cywgaW5zdGFudGlhdGlv biBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4NCj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+Y3JlYXRpb24N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQ KSBhbmQgaXMgdXNlZCBmb3INCj4gPj4gPj4gPj5mb3J3YXJkaW5nDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAg aXMNCj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRo ZSBkZWZpbmVkIFNGQy4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24g KG9yDQo+ID4+ID4+ID4+bm9uLWluaXRpYWwNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFz c2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4NCj4gPj5TRlAsDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBp Y2FsbHkgcGVyZm9ybWVkIGJ5DQo+ID4+YQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNz aWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlDQo+ID4+ID4+ID4+ ZnVuY3Rpb24uDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkg cmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYQ0KPiA+Pm5ldw0KPiA+PiA+PiA+PlNGUCwgYW4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRh dGEsIG9yIGJvdGguICBUaGlzIGlzDQo+ID4+ID4+ID4+cmVmZXJyZWQNCj4gPj4gPj4gPj4gPj4+ dG8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+Pg0KPiA+PiA+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+ID4+ Pj4+Pj4+Pj4+Pi0tLQ0KPiA+PiA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4gPj4+ID4+ Pj4+Pj4tLQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb208SS5TbWl0aEBGNS5jb20+ DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4NCj4gPj4gPj4gRGly ZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPixKb2VsDQo+ID4+ID4+ID4+IE0uDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4NCj4gPj4gPj4gPj4gPj4+DQo+ ID4+ID4+ID4+DQo+ID4+ID4+DQo+ID4+DQo+ID4+Pj4+SGFscGVybjxqbWhAam9lbGhhbHBlcm4u Y29tPixodWFuZ0BzY2UuY2FybGV0b24uY2E8aHVhbmdAc2NlLg0KPiA+PiA+PiA+PiA+Pj4gPj4g Y2FybGV0b24uDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmc8c2ZjQGll dGYub3JnPg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ICpTZW50OiAq VGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0 OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4gPj4gPj5C YWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRp dW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPiA+PiA+PnRoYXQgaXMNCj4gPj4gPj4gPj4gPj4+ d2hhdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3 b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMNCj4gPj4gPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0 ZWN0dXJlIGJ1cmRlbmVkDQo+ID4+d2l0aA0KPiA+PiA+PiB0aGF0DQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBk ZWdyZWUgb2YNCj4gPj4gPj4gPj5hc3BpcmF0aW9uDQo+ID4+ID4+ID4+IHRvDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4g b2YgdGhlDQo+ID4+ID4+ID4+YXJjaGl0ZWN0dXJlDQo+ID4+ID4+ID4+ID4+Pi0NCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5 IHNheWluZw0KPiA+PnRoYXQgYW4NCj4gPj4gPj4gPj4gPj4+YXJiaXRyYXJ5DQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVu IGlmIGl0DQo+ID4+aXNuJ3QNCj4gPj4gPj4gPj4gPj4+ID4+aW50ZW50aW9uYWwNCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQg aGF2ZSBsYXN0aW5nDQo+ID4+ID4+ID4+aW1wYWN0cw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LA0KPiA+ PiA+PiA+PmFkZHJlc3MNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5k cyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbQ0KPiA+Pm5vdA0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QNCj4gPj5bam1oLmRpcmVjdEBqb2VsaGFscGVybi5j b21dDQo+ID4+ID4+ID4+U2VudDoNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBK dWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbA0KPiA+Pk0uDQo+ID4+ID4+ ID4+IEhhbHBlcm47DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24u Y2E7IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4gPj5bc2ZjXQ0KPiA+PiA+PiA+PlNlcnZp Y2UNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IElh biwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4NCj4gPj50aGlz DQo+ID4+ID4+ID4+cmVnYXJkLg0KPiA+PiA+PiA+PiA+Pj5JDQo+ID4+ID4+ID4+ID4+PiA+PmFt DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVj dHVyZSBvciB0aGUgc29sdXRpb24NCj4gPj4gPj4gPj5wcm9oaWJpdA0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0 aW5nDQo+ID4+dG8NCj4gPj4gPj4gPj5IdWFuZydzDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBy ZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cw0KPiA+PmFy ZQ0KPiA+PiA+PiA+PiByZXF1aXJlZA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhleSBieSB0 aGUgYXJjaHRpZWN0dXJlLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0bw0K PiA+PnByb2hpYml0DQo+ID4+ID4+c3VjaA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdz LiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzDQo+ID4+IHVwb24N Cj4gPj4gPj4gPj4gbWFueQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRl IG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+ID4+ID4+dGhpbmsNCj4gPj4g Pj4gPj50aGF0DQo+ID4+ID4+ID4+ID4+PiA+PnRoZXkNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lk aW5nDQo+ID4+YXR0ZW1wdGluZyB0bw0KPiA+PiA+PiA+Pmtub3cNCj4gPj4gPj4gPj4gPj4+d2hh dA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEw LzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4g SSBkaXNhZ3JlZS4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UNCj4g dGVucw0KPiA+PiBvZg0KPiA+PiA+PiA+PiA+Pj5taWxsaW9ucw0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IG9mDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZsb3dzIGluIGJv dGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGENCj4gPj4gY2VudGVyDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0 aGF0DQo+ID4+aW4NCj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQ djYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdw0KPiA+PiB5b3UNCj4gPj4g Pj4gYXJlDQo+ID4+ID4+ID4+IG9ubHkNCj4gPj4gPj4gPj4gPj4+ID4+IGdvaW5nDQo+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMg d2l0aCBlcXVhbGx5DQo+ID4+ID4+c21hbGwNCj4gPj4gPj4gPj4gPj4+IG51bWJlcnMNCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11 Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVkDQo+ID4+IG1vcmUNCj4gPj4gPj4gdGhhbg0K PiA+PiA+PiA+PiA+Pj4gNjRLIg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOg0KPiA+PiBzZmMNCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBK b2VsIE0uIEhhbHBlcm4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4u Y29tXQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDQ6NDYgUE0gVG86DQo+ID4+ID4+ID4+ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYTsNCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLA0KPiA+PlBhdGhzLA0KPiA+PiA+PmFuZA0KPiA+PiA+PiA+PiA+Pj5Mb2Fk DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYg c29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+ID4+ID4+ID4+ID4+PmFyY2h0aWV0dXJlDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhj ZWVkIHRoZSBsaW1pdHMgb2YNCj4gPj4gPj50aGVpcg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoDQo+ID4+YWJz dXJkDQo+ID4+ID4+IHVzZQ0KPiA+PiA+PiA+PiBvZg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0bw0KPiA+Pndy aXRlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9o aWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZQ0KPiA+PiA+PmRvZXMNCj4gPj4gPj4gPj4gPj4+cGVy bWl0DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBt eSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+ID4+ID4+IHBlcm1pdHMNCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVk IG9yDQo+ID4+cmVxdWlyZWQgYnkNCj4gPj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+d29yay4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBN LCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5 b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbA0KPiA+PiA+Pm1l YW4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBs YXJnZXIgdGhhbiB0aGUgcm91dGluZw0KPiA+PiA+PnRhYmxlDQo+ID4+ID4+ID4+b2YgYQ0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQ TSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhl IGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywNCj4gPj4gZnJvbQ0K PiA+PiA+PjENCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAw MDAgc2VydmljZSBwYXRocy4gSSB3b3VsZA0KPiBob3BlDQo+ID4+ID4+dGhhdA0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhp dGllcyBpZg0KPiA+PnRoZXkNCj4gPj4gPj4gPj5jaG9vc2UNCj4gPj4gPj4gPj4gPj4+dG8NCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxh bmNpbmcgYW5kIGluIHN0ZWFkDQo+ID4+ID4+ID4+IHByb3Zpc2lvbg0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwg NDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIDQo+IHdyb3RlOg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdWwsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUg Zm9yIGEgNA0KPiA+PmhvcA0KPiA+PiA+PiA+PiBzZXJ2aWNlDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZy b206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24NCj4gPj4gQmVoYWxmDQo+ ID4+ID4+IE9mDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxx KSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEwLA0KPiA+PjIwMTQNCj4gPj4gPj4gPj4zOjAzDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqDQo+IGpt aEBqb2VsaGFscGVybi5jb207DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4g Pj4gPj4gQ2hhaW5zLA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGgg SUQgZHJpdmVzDQo+ID4+dGhlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGlu Zy4gScK5ZA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlDQo+ IHVzZWQNCj4gPj4gdG8NCj4gPj4gPj4gPj4gZGVyaXZlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkDQo+IHRyYW5zcG9ydC4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPiA+PiA+ PnNpbXBseQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNl IHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMNCj4gPj4gPj5tdXN0DQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhl IGV4YWN0DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9w bGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uDQo+ID4+ID4+dGhpcw0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0 aA0KPiA+PiA+PiA+PiBpZGVudGlmaWVyDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJv dmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQNCj4gbG9va3VwDQo+ID4+IGNh bg0KPiA+PiA+PiA+PiByZXN1bHQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhIG9u ZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0DQo+ID4+IG5leHQNCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0 IDExOjA0IEFNLCBMdWN5IHlvbmcNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55 b25nQGh1YXdlaS5jb20NCj4gPj4gPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+ DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNoLiBk b2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkNCj4gdXNlDQo+ID4+IG9mDQo+ID4+ID4+IHRoZQ0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRy aXZlIHRoZSBmb3J3YXJkaW5nDQo+ID4+ID4+ID4+YWN0aW9ucy4NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24NCj4gPj4gQmVoYWxmDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4NCj4gPj4gPj4gPj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4gPj4gPj4gPj4gPj4+ID4+IEp1 bHkNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlr ZWJpYW5jQGFvbC5jb20NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA8bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1YmplY3Q6 KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+ID4+ID4+ID4+Q2hhaW5zLA0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJh ZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlDQo+ID4+cGF0aA0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZp ZXIgdG8NCj4gPj4gPj5kZXJpdmUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJk aW5nIGFjdGlvbnMuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwNCj4g a25vd2xlZGdlDQo+ID4+IG9mDQo+ID4+ID4+ID4+IGV2ZXJ5DQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBhdmFpbGFibGUgU0ZDDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGlu ZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluDQo+IGlzDQo+ID4+IG5vdA0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy4N Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlDQo+ID4+b2YN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gdGhhdCB3aWxsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2Vu dCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZQ0KPiA+PiA+PiByZXF1aXJlZA0K PiA+PiA+PiA+PiB0bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNl cnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uDQo+ID4+aXMNCj4gPj4gPj4gPj51c2Vk IHRvDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlz IGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhDQo+ID4+cGFydA0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqQ0KPiA6Km1lcmNyZWRp IDkNCj4gPj4gPj4gPj4ganVpbGxldA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQg MjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2Zj XSBTZXJ2aWNlDQo+ID4+ID4+ID4+Q2hhaW5zLA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0 aGUgZGlmZmVyZW5jZQ0KPiA+PmJldHdlZW4NCj4gPj4gPj5TRg0KPiA+PiA+PiA+PiBDaGFpbg0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gUGF0aD8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlp bmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzDQo+ID4+ID4+ID4+Y2xlYXIgdG8NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IHRob3NlIG5vdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lDQo+ID4+ID4+ YWdyZWVzDQo+ID4+ID4+ID4+b24NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0 ZXJtcy4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcw0KPiA+ PiA+PndoZXRoZXINCj4gPj4gPj4gPj5pdCBpcw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkNCj4gPj53aGF0 DQo+ID4+ID4+ID4+dGhlIElEDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNG QyBIZWFkZXINCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNob3VsZA0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhp cw0KPiA+PmRyYWZ0DQo+ID4+ID4+ID4+c2ltcGx5DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXINCj4gPj4g Pj5kcmFmdHMNCj4gPj4gPj4gPj50bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpY3Rh dGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24NCj4gPj4gY2hhaW4NCj4g Pj4gPj4gb3INCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNl IG9mIGNoYWluIG9yDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElm IHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkDQo+ID4+IGhhdmUN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNG QyBiZSBzdXBwb3J0ZWQgKG9yDQo+ID4+IG1ha2UNCj4gPj4gPj4gPj4gb25lDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZv aWQgc29tZQ0KPiA+PiA+PiB2ZW5kb3JzDQo+ID4+ID4+ID4+IG9ubHkNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBT RkMuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ ID4+ID4+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+Pg0KPiA+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4+ Pj4+Pj4+Pj4+LS0tDQo+ID4+ID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+PiA+PiA+Pj4gPj4+ Pj4+Pi0tDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g KkZyb206KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpU bzoqc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4NCj4gPj4gPj4gKlNlbnQ6KlR1 ZXNkYXksDQo+ID4+ID4+ID4+IEp1bHkNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAy MDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+ID4+YW5kDQo+ID4+ ID4+TG9hZA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJl ZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkNCj4gPj4gPj5hbnN3ZXINCj4g Pj4gPj4gPj5hDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRz IHRoYXQgaGF2ZSBiZWVuIG1hZGUNCj4gYWJvdXQNCj4gPj4gdGhlDQo+ID4+ID4+ID4+ID4+PiBw cm9wb3NlZA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUg ZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4gPj4gPj4gd29ya2luZw0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdv cmsgdG8NCj4gPj4gPj4gaW1wcm92ZQ0KPiA+PiA+PiA+PiB0aGUNCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QNCj4gcGFydGlj aXBhdGVkDQo+ID4+IGluDQo+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ID4+IFdHDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRo ZQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkg dG8gZXhwbGFpbiBteQ0KPiA+PiA+PiA+PnBlcnNvbmFsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlz IGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQNCj4gPj50aGF0DQo+ID4+ID4+ID4+d2hhdA0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFu ZSBhcmNoaXRlY3R1cmUuDQo+ID4+V2UNCj4gPj4gPj5hcmUNCj4gPj4gPj4gPj4gbm90DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVj dHVyZSBmb3IgdGhlDQo+ID4+ZW50aXJlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29s dXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQNCj4gPj4gZW5jb21wYXNzDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBw b2xpY3kgZnVuY3Rpb25zLA0KPiA+PiA+PnZpcnR1YWwNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueQ0KPiBvdGhlcg0KPiA+ PiA+PiA+PiBhc3BlY3RzLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNo IGNsZWFybHkNCj4gPj4gbmVlZA0KPiA+PiA+PiB0bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0DQo+ID4+ d2l0aA0KPiA+PiA+PiA+PmFib3ZlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUg d2UgYXJlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29y ayB3ZSBhcmUNCj4gPj4gPj4gZG9pbmcuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFp biB2cyBzZXJ2aWNlIHBhdGgsDQo+ID4+ID4+YXMgSQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHVuZGVyc3RhbmQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcu IFRoZXJlDQo+ID4+YXJlIGF0DQo+ID4+ID4+ID4+bGVhc3QNCj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQN Cj4gPj4gPj53aWxsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBz ZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseQ0KPiA+PmFyZQ0KPiA+PiA+PiA+Pm1vcmUu DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1 cmUgaXMgdG8gcGVybWl0IGFsbCBvZg0KPiA+PiA+PiA+PnRoZXNlLA0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGJlIHVzZWQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJv dmlkZWQgdG8gdGhlDQo+ID4+ZW5kDQo+ID4+ID4+ID4+dXNlci4NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlcg0K PiA+PiA+PnBhY2tldHMsDQo+ID4+ID4+ID4+YW5kDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4g ZW5kIHVzZXIgc2VydmljZQ0KPiA+PiA+PiA+Pmluc3RhbmNlDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFu dA0KPiA+PiA+PiA+PnNlcnZpY2UNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlv biB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZQ0KPiA+PmNoYWluaW5nLg0KPiA+PiA+ PiA+Pkl0J3MNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0 IHJlcXVpcmVtZW50cyBvbiBob3cNCj4gc2VydmljZQ0KPiA+PiA+PiA+PiBjaGFpbmluZyBpcw0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUg aW1wYWN0IG9uIHRoZQ0KPiA+PiA+PiA+PmFyY2h0aWVjdHVyZS4NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAgRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1w bHkNCj4gPj5hDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZw0K PiBwYWNrZXQuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywg b25lDQo+ID4+ID4+Y2FuDQo+ID4+ID4+ID4+aGF2ZQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHdoYXQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBz aW5nbGUNCj4gPj4gPj5wb2ludA0KPiA+PiA+PiA+Pm9mDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gY29udGFjdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFs bHkNCj4gPj5kZWxpdmVyZWQNCj4gPj4gPj4gPj5ieSBhDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ PiBjb2xsZWN0aW9uIG9mDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBw aHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+ID4+ID4+b25lIG9yDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1w bGUgdXNpbmcNCj4gPj5WUlJQLWxpa2UNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNo bmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksDQo+IHRoaXMNCj4gPj5pcw0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFp bmluZyBkYXRhIHBsYW5lDQo+ID4+ID4+ID4+bWVjaGFuaXNtcy4NCj4gPj4gPj4gPj4gSXQNCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbA0KPiA+PiA+PiA+Pm1lY2hhbmlzbXMsDQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sDQo+ID4+ c2NhbGUtb3V0LA0KPiA+PiA+PmFuZA0KPiA+PiA+PiA+PnZtDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+ID4+ ID4+cGVybWl0dGluZw0KPiA+PiA+PiA+PnRoaXMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyDQo+ID4+ID4+ ID4+dGVybWlub2xvZ3kNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFk DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28g YmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0KPiA+PiA+PnNlbGVjdGluZw0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhh dCBkaXJlY3QNCj4gPj4gPj4gPj50cmFmZmljDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8NCj4gcmVxdWlyZQ0KPiA+ PiA+PiB0aGF0DQo+ID4+ID4+ID4+YQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVu IHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lIHBsYWNlDQo+ID4+aW4NCj4gPj4g Pj50aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291 cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlDQo+ID4+ID4+Y29tYmluZWQuIEkNCj4gPj4g Pj4gPj4gdGVuZA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiByZWZlciB0bw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xs ZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UNCj4gPj4gPj4gPj5jaGFp bmluZw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEg Y2x1c3Rlci4gTm90IGJlY2F1c2UNCj4gPj5jbHVzdGVyDQo+ID4+ID4+aXMNCj4gPj4gPj4gPj5h DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRv IG5vdCBoYXZlIGFub3RoZXINCj4gb25lLg0KPiA+PiA+PiBUaHVzLA0KPiA+PiA+PiA+PiB0aGUN Cj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNp bmcNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50DQo+ ID4+ID4+ID4+c2luZ3VsYXINCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50DQo+ID4+cGxhY2VzDQo+ID4+ID4+aW4N Cj4gPj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93 IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsaw0KPiA+PiBhYm91dA0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0 aC8gU2VydmljZSBjaGFpbiBpcw0KPiA+PmENCj4gPj4gPj4gPj4gc2VxdWVuY2UNCj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRv IGEgc3Vic2V0IG9mDQo+ID4+ID4+ID4+cGFja2V0cy4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mDQo+ID4+ ID4+dHJhZmZpYw0KPiA+PiA+PiA+PmlzDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8g Z2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kDQo+ID4+ID4+ZmlyZXdh bGwNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQg aXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlDQo+ID4+ID4+Y2FjaGUNCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IHdpdGhvdXQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkg b3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24g dG8gZGlyZWN0IHRoZQ0KPiA+PiA+PnBhY2tldHMuDQo+ID4+ID4+IEENCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5j ZSBvZg0KPiA+PiA+PiA+PmxvY2F0aW9ucw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu IHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhcg0KPiA+Pm9yDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVs aXZlcnkgbG9jYXRpb25zLg0KPiA+PlRoZXkNCj4gPj4gPj4gPj5tYXkgYmUNCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUNCj4g YWRkcmVzc2VkIGFzDQo+ID4+ID4+IHBvcnRzDQo+ID4+ID4+ID4+IG9uDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0 IHRoZQ0KPiA+PiA+PiA+PmxvY2F0aW9ucw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1h eSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KPiA+PiBpbmZyYXN0cnVjdHVyZQ0K PiA+PiA+PiBhbmQNCj4gPj4gPj4gPj4gdGhlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dHJhbnNwb3J0Lg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBT RkMNCj4gPj4gPj5ncm91cCwNCj4gPj4gPj4gPj4gd2UNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pj4gbmVlZCB0byBiZQ0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFs ayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwNCj4gPj50aGUNCj4gPj4gPj4gPj5z ZXJ2aWNlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0 aGUgZm9yd2FyZGluZy4gQW5kIHdlDQo+IG5lZWQNCj4gPj50bw0KPiA+PiA+PiB0YWxrDQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0 cyB3aWxsIHRha2UgaW4NCj4gPj50aGUNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3 b3JrLg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlDQo+IHdob2xl DQo+ID4+ID4+IHBhdGgNCj4gPj4gPj4gPj4gbWF5DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlDQo+ID4+ZGVh bHMNCj4gPj4gPj4gPj53aXRoDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1 ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0NCj4gPj4oMikNCj4gPj4gPj5v bg0KPiA+PiA+PiA+PmxvYWQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMg YWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kDQo+ID4+ID4+YmVoYXZpb3JzDQo+ID4+ ID4+ID4+IHdoaWNoDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlzaWJsZSB0 byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zDQo+ID4+KGluDQo+ID4+ID4+ID4+bXVj aA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5n IHdpdGhpbiBhIExBTiBpcw0KPiA+PmxhcmdlbHkNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXINCj4gPj4gPj4g cHJvdmlzaW9uDQo+ID4+ID4+ID4+IHdlDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFr ZSBpcw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4g Pj4gPj4gPj4gbmVjZXNzYXJ5Lg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2ls bCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQNCj4gb24NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZp Y2F0aW9uDQo+ID4+ID4+cG9pbnQuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hh dCB3ZSBhcmUgYWZ0ZXIuDQo+ID4+ID4+SWYgaXQNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZQ0KPiA+Pndvcmtp bmcNCj4gPj4gPj4gPj4gZ3JvdXAsDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2Fu IGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZQ0KPiA+PiBuZWVkZWQNCj4gPj4g Pj4gdG8NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdv cmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aA0KPiA+PnRoZQ0KPiA+PiA+PiA+PiBpbnRlbnQsDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3Qg dG8gbWF0Y2ggdGhlDQo+ID4+d29ya2luZw0KPiA+PiA+PiA+Pmdyb3VwDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFt IG5vdA0KPiA+PnN1cmUNCj4gPj4gPj4gPj53aGF0IHRvDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdHJ5IG5leHQuDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gc2ZjDQo+ID4+ID4+ID4+ ID4+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ID4+IHNm Yw0KPiA+PiA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiBzZmMNCj4gPj4gPj4gPj4gPj4+ ID4+IG1haWxpbmcNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3Jn DQo+ID4+ID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+ID4+IHNmYw0KPiA+PiA+PiA+PiA+Pj4gPj4gbWFpbGlu Zw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiA+PiBzZmMNCj4gPj4gPj4gPj4gPj4+IG1haWxpbmcNCj4gPj4gPj4gPj4gPj4+ ID4+IGxpc3QNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4gPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g c2ZjDQo+ID4+ID4+ID4+ID4+PiBtYWlsaW5nDQo+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4gPj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiBzZmMNCj4gPj4gPj4gPj4gbWFpbGluZw0KPiA+PiA+PiA+PiA+Pj4gPj4g bGlzdA0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gc2ZjDQo+ID4+ID4+ID4+IG1haWxpbmcNCj4gPj4gPj4gPj4gPj4+ ID4+IGxpc3QNCj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+ PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiA+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiA+PiA+PiA+Pj4gPj4g Pj4gc2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+PiA+Pj4gPj4gPj4NCj4gPj4gPj4gPj4g Pj4+ID4+ID4NCj4gPj4gPj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QN Cj4gPj4gPj4gPj4gPj4+ID4+ID5zZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4+ID4+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+PiA+Pj4gPj4N Cj4gPj4gPj4gPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+ID4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ID4+ ID4+PiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4g Pj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+ PiA+PiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4g Pj4gPj4gPj4gPg0KPiA+PiA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4gPj4g PnNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPj4gPg0KPiA+DQoNCg== From nobody Fri Jul 11 09:42: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 4DD831A0AD2 for ; Fri, 11 Jul 2014 09:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 Z31Tz5Nsdmq5 for ; Fri, 11 Jul 2014 09:41:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378581A0AC6 for ; Fri, 11 Jul 2014 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=637; q=dns/txt; s=iport; t=1405096912; x=1406306512; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t3rlNipg5x67DQ2qufysdHWxqVfE89Rei03qnfvAAPI=; b=fdrVCd6iQ5iiimPdxS7cKwitijiZxQQjrSG+1U/OZIEvh8SfLHlJq+js 8AZAnHty5kqgFUUGGNS/rU9294UFFiPY+CQ9MenVZ47s1lG5Fy23wzC8I nne38Q8TZfEToEQc+IgznlPgf0kCzzcy30seeF4xYux7bovb5NDa2jwsO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFADETwFOtJV2S/2dsb2JhbABZgw6BLMg+AYELFnWEAwEBAQMBZRQFCwIBCEYhESUCBA4FiC4DCQi/QA2HGBeNHYF5MweDLYEWAQSZBYIAi2iCHoYWg0SCMA X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="60131003" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 16:41:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGfpCD000803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:41:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:41:51 -0500 From: "Paul Quinn (paulq)" To: Sharon Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAoFSAgAAF84CAAAGNAIAAAVMAgAAFawCAAAOPAIAAB9AAgAAEboCAAANgAIAAAj8AgAAHGwCAAAuYAA== Date: Fri, 11 Jul 2014 16:41:50 +0000 Message-ID: <30DB499A-72C3-46CB-A28C-4346FBC6AF51@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C0041E.6050605@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.19.17.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1C1D44DA211DD848B8B5640746ABA71B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ONVKAuYZwvk8nsO_Cdhv_Qr3AQA Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:41:55 -0000 Sharon, On Jul 11, 2014, at 12:00 PM, Sharon wrote: > We can reference other standard ID-Location mapping mechanisms (local or = distributed) for matching SF-SFF. These can be leveraged by SFFs for load d= istribution and dynamic failure recovery not based on centralized orchestra= tion. >=20 As you probably know: I think is a great example =97 and one I think will l= ikely be deployed =97 of how service path to network next hops will be reso= lved. The SFF can =93ask=94 LISP for a locator so the service path identif= iers and get back one or more based on policy and load requirements. Paul From nobody Fri Jul 11 09:43: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 D8D071A0AC9 for ; Fri, 11 Jul 2014 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 80GPe1e_zE4E for ; Fri, 11 Jul 2014 09:43:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68301A0A9E for ; Fri, 11 Jul 2014 09:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35956; q=dns/txt; s=iport; t=1405097010; x=1406306610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XRoCABVDY7SxDw9Q2XuJuY9s8dyPvFGzmKSz/DbjC5s=; b=f6Qxc/9KLIPeBpiO/TzoQxUzPQlixQ1Y/1okfiph5R/m/zq8yEbe5G1y YZNZd7U+aZFXHZBsHgo3r/K7oRr+uNJx2os5zK3Kh8PciSwTeg9yCqNlm phMlHpaoLM6ja7F6qJdIcTlULBVx7IJqzcueHTjfWs8zXgBnnUb84ZkyK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8NAG4TwFOtJV2P/2dsb2JhbABPCoFsBoEcUlquepF4CodCAYELFnWEAwEBAQMBAQEBFwFKCQIJBQcEAgEIEQEDAQEBJwcnCxQDBggCBA4FG4gTAwkIDcZXEwSNHYFQBSQIKwcCBIMngRYFliJJhBqLaIg0g0SBb0E X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="339391263" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2014 16:43:28 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGh3fG014338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:43:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:43:03 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8W4jHzfPAnGkSKMHddp+YojpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAoFSAgAAF84CAAAGNAIAAJACAgAABxACAAARvAIAAArKAgAACTYA= Date: Fri, 11 Jul 2014 16:43:02 +0000 Message-ID: <0275A2C3-2D1F-452F-A845-1C57294B03B3@cisco.com> References: <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1236229119.3129.1405095908893.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53C01227.9030909@joelhalpern.com> In-Reply-To: <53C01227.9030909@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8E87CF465B778447AD40882DB7171DCA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-WuHGAIfmLP1O36cB-q8MtG8VZ8 Cc: "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "mn1921@att.com" , "Myo.Zarny@gs.com" , Ron Parker , "mikebianc@aol.com" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:43:10 -0000 On Jul 11, 2014, at 12:34 PM, Joel M. Halpern wrote: > The way the draft uses the terms, and the way most discussions outside th= e IETF SFC working group use the term, a service function chain is somethin= g that you would discuss a policy about. Certain traffic from certain user= s is supposed to receive a certain sequence of services, the service chain. >=20 I fail to see the confusion around these terms. I think your definition ab= ove put them into context. The other way I think about it: the chain is in= tent, and the path is the realization of that intent.=20 > At the policy level, that does not care where in the network that is deli= vered. So as to allow control a level of influence, and to have flexibilit= y to have multiple representations in the network of that policy construct,= we have the intermediate notion of service function path. If the control = system does not need to apply any influence, then it uses one service path = for the service chain. If it needs a level of control, it instantiates a s= uitable number of service paths in the control system, and rules for how th= ose are used. >=20 > Then, the mapping in the SFF is based on that path, so as to enable the i= nfluence of the control system. While still allowing several other layers = of traffic management as discussed. >=20 > Yours, > Joel >=20 > On 7/11/14, 12:25 PM, mikebianc@aol.com wrote: >> I meant as a design principle when everything is working. I was trying >> to come up with a concise example of configuring a network such that it >> does not work that would be analogous to configuring SFC such that "that >> remote SFF has the necessary forwarding logic to reach the next-next-SF"= . >>=20 >>=20 >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >> *From: *Myo.Zarny@gs.com >> *To: >> *'mikebianc@aol.com','jguichar@cisco.com','mn1921@att.com','jmh@joelhalpern.com','Ron_Parker@affirmednetworks.com','sfc@ietf.org' >> *Sent: *Friday, July 11, 2014 >> *Subject: *RE: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> I don=92t understand. (I=92m sure I=92m misunderstanding=85) >>=20 >> Your backend servers could go down, be unreachable or be unable to >> server more. >>=20 >> Route health injection (RHI) is a perfectly fine, accepted, way of >> indicating the health of the backend services to the network. You=92re n= ot >> saying that=92s wrong, are you? >>=20 >> ** >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >> *mikebianc@aol.com >> *Sent:* 11 July 2014 12:03 PM >> *To:* jguichar@cisco.com ; mn1921@att.com >> ; jmh@joelhalpern.com >> ; Ron_Parker@affirmednetworks.com >> ; sfc@ietf.org >> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> heh. well, if it did not, then you should not do it like that. e.g. I'm >> not going to configure real servers on a server load balancer that are >> not reachable. e.g. I'm not going to configure my BGP to announce >> prefixes for which I cannot provide connectivity. If you do things like >> that, then you are doing it wrong. >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From: *jguichar@cisco.com> > >> *To: *NAPIERALA, MARIA H>,Joel M. >> Halpern>,Ron >> Parker> >,sfc@ietf.org >> > >> *Sent: *Friday, July 11, 2014 >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> Then I misunderstand the proposal ;-) .. However, it seems to me that if >> you allow an SFF to make a decision as to which remote SFF it will use f= or >> a given flow to reach the next SF within the chain then you better make >> sure that that remote SFF has the necessary forwarding logic to reach th= e >> next-next-SF for the chain as otherwise you are in deep trouble. >>=20 >> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" > > wrote: >>=20 >> >Absolutely not. Service chains can be instantiated only in relevant SFF= s >> >when they "arrive". >> > >> >> -----Original Message----- >> >> >>=20 >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >> >>(jguichar) >> >> Sent: Friday, July 11, 2014 9:27 AM >> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> Well I think it is even worse than that if I have understood the >> >>proposal >> >> correctly as it would require full knowledge of every single SF withi= n >> >>the >> >> entire SFC domain at every single SFF as there is no way to know a >> >>priori >> >> which SFC=B9s a given SFF will need to service at any given point in = time. >> >> >> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" > > wrote: >> >> >> >> >Ron, thinking about this, I realized another major problem with the >> >>your >> >> >proposal as I understand it. (And I readily admit I may not understa= nd >> >> >it.) >> >> > >> >> >The proposal has each SFF serve as the load balancer for the next >> >> >service function that follows it (not the one it delivers to), in ev= ery >> >> >service chain that goes through it. >> >> > >> >> >Since it has to be able to work with all services, that means that >> >>every >> >> >SFF would have to be a full, flow sensitive and stateful load balanc= er. >> >> >I ahve no problem if some SFF are flow sensitive, and / or stateful. >> >> >But having the architecture require that every SFF be a full, flow >> >> >sensitive, stateful, load balancer seems to me to be an acceptable >> >> >imposition. >> >> > >> >> >Yours, >> >> >Joel >> >> > >> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >> >> Part of my personal view is that I am trying to make this work >> >>sensibly >> >> >> in a more orchestrated environment. I expect that the service >> >> >> functions, and over time probably the SFF capabilities, will be >> >> >> orchestrated and installed. I expect the service chains to be >> >>driven by >> >> >> BSS tools that define offerings to clients, and enable self-select= ion >> >> >> from these. I expect service paths to be heavily policy drive. >> >> >> >> >> >> I can see how to make all of that work in an archtiecture driven b= y >> >> >> initial classification to described service paths. It is harder to >> >>see >> >> >> how to make it work (but it can be done) when we allow more >> >> dynamicity >> >> >> in the network behavior. >> >> >> >> >> >> Having said that, most of that perspective I described is outside = of >> >>the >> >> >> scope of the working group. it is not something we are tasked to >> >>agree >> >> >>on. >> >> >> So I do not claim that vision means we have to do it a certain way= . >> >>it >> >> >> is just the perspective that drives my preferences. >> >> >> >> >> >> Yours, >> >> >> Joel >> >> >> >> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >> >>>> For me, the amount of information about service instances that >> >>needs >> >> >>>>to >> >> >>>> be widely distributed and maintained, potentially even across da= ta >> >> >>>> centers within an administrative scope, is large enough and comp= lex >> >> >>>> enough that trying to get that into each SFF seems like a diffic= ult >> >> >>>> architecture to realize. >> >> >>> >> >> >>> I'm curious as to why that is more complicated than dynamic routi= ng, >> >> >>> hyper-scale data center orchestration, or DNS, all of which are >> >>bigger >> >> >>> problems that have been profitably and stably implemented? >> >> >>> >> >> >>> It also seems that if it really is more complicated, that is a go= od >> >> >>> sign that it is too complicated. >> >> >>> >> >> >>> ________________________________________ >> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com >> ] >> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >> >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com >> ; Ian Smith; >> >> >>> sfc@ietf.org >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >>> >> >> >>> This is an architectural issue. And one that I would prefer we >> >> >>>actually >> >> >>> decide, rather than trying to allow all possible implementations. >> >> >>> Because it does have a major effect on the control requirements a= nd >> >> the >> >> >>> functionality of SFFs. >> >> >>> >> >> >>> For me, the amount of information about service instances that ne= eds >> >> to >> >> >>> be widely distributed and maintained, potentially even across dat= a >> >> >>> centers within an administrative scope, is large enough and compl= ex >> >> >>> enough that trying to get that into each SFF seems like a difficu= lt >> >> >>> architecture to realize. >> >> >>> >> >> >>> Yours, >> >> >>> Joel >> >> >>> >> >> >>> But it is a fair question. >> >> >>> >> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >> >>>> This is the crux of my issue. Is the end to end selection of >> >> >>>> (top-level) instances performed centrally (perhaps by the >> >>classifier) >> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the >> >>SFFs)? >> >> >>>> Such selection is not equivalent to reclassification. And surely= , >> >> >>>> this is an architectural issue and not relegated to >> >> >>>> "implementation". >> >> >>>> >> >> >>>> My own view is to favor the distributed approach even though a >> >> >>>> greater amount of data (chain definitions and perhaps local >> >>selection >> >> >>>> policy) is required at those distributed decision points. This >> >> >>>> approach does not require an end-to-end path id at all. My >> >> >>>> rationale for favoring this approach is primarily driven by >> >>increased >> >> >>>> resiliency over the global path id approach. With a global path >> >>id >> >> >>>> approach, consider failure of an instance and needing to alter t= he >> >> >>>> global path ID table for each and every affected end-to-end path= . >> >> >>>> >> >> >>>> Ron >> >> >>>> >> >> >>>> ________________________________________ From: sfc >> >> >>>> [sfc-bounces@ietf.org ] on behalf >> of Joel Halpern Direct >> >> >>>> [jmh.direct@joelhalpern.com >> ] Sent: Thursday, July 10, 2014 6:15 = PM >> >> >>>> To: mikebianc@aol.com ; >> I.Smith@F5.com ; sfc@ietf.org >> Subject: Re: >> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >> >> >>>> >> >> >>>> The way the architecture models the case of SF1 needing to >> >>influence >> >> >>>> the chain is that one would do reclassification at the exit from >> >> >>>> SF1. >> >> >>>> >> >> >>>> Part of the goal is to keep the different functions logically >> >> >>>> separate so that solutions can clearly describe how they choose = to >> >> >>>> compose them for "service" delivery. >> >> >>>> >> >> >>>> Yours, Joel >> >> >>>> >> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com >> wrote: >> >> >>>>> I don't see anything in the arch draft that suggests any sort o= f >> >> >>>>> limit. However, it does seem to indicate that the entire path (= all >> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe this means >> >> >>>>> either at the classifier or maybe the classifier chooses a SF >> >>Chain >> >> >>>>> and the NF or at the latest the first SFF. In any case, the >> >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) = is >> >> >>>>> determined at the SFI(n-1) hop. According to the draft, this >> >> >>>>> behavior would be considered "branching" to a new SFP as oppose= d >> >> to >> >> >>>>> choosing and then forwarding to the selected instance of the >> >> >>>>> next-hop of the current SFC. >> >> >>>>> >> >> >>>>> draft-merged-sfc-architecture-00: >> >> >>>>>> When an SFC is instantiated into the network it is necessary t= o >> >> >>>>>> select the specific instances of SFs that will be used, and to >> >> >>>>>> create the service topology for that SFC using SF's network >> >> >>>>>> locator. Thus, instantiation of the SFC results in the creatio= n >> >> >>>>>> of a Service Function Path (SFP) and is used for forwarding >> >> >>>>>> packets through the SFC. In other words, an SFP is the >> >> >>>>>> instantiation of the defined SFC. >> >> >>>>>> >> >> >>>>>> The SFC architecture supports reclassification (or non-initial >> >> >>>>>> classification) as well. As packets traverse an SFP, >> >> >>>>>> reclassification may occur - typically performed by a >> >> >>>>>> classification function co-resident with a service function. >> >> >>>>>> Reclassification may result in the selection of a new SFP, an >> >> >>>>>> update of the associated metadata, or both. This is referred t= o >> >> >>>>>> as "branching". >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >> >>>>>>>-----------------------------------------------------------------= --- >> >>>>>>>-- >> >> >>>>>-- >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>> *From: *I.Smith@F5.com> > >> >> >>>>> *To: *Joel Halpern Direct> >,Joel M. >> >> >>>>> >> >> >>>>>Halpern> >,huang@sce.carleton.ca >> > >> carleton. >> >> >>>>>ca>,sfc@ietf.org > > >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>> *Sent: *Thursday, July 10, 2014 >> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >>>>> >> >> >>>>> Actually, I think I am disagreeing. >> >> >>>>> >> >> >>>>> If the possibility of medium-scale deployments (and that is wha= t >> >> >>>>> 16 million flows is in my world) of service chains is preconcei= ved >> >> >>>>> as an absurd idea, then the architecture burdened with that >> >> >>>>> preconception. >> >> >>>>> >> >> >>>>> There has to be some point of aim, some degree of aspiration to >> >> >>>>> scale that is appropriate for the lifespan of the architecture = - >> >> >>>>> you don't have to know what it is, but by saying that an arbitr= ary >> >> >>>>> number is "too far", you're creating - even if it isn't >> >>intentional >> >> >>>>> - a limit that influences decisions that have lasting impacts >> >> >>>>> regarding scale-out, failure mitigation, elasticity, address >> >> >>>>> space... all kinds of things. That is a problem I'm not >> >> >>>>> particularly eager to deal with. >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ________________________________________ >> >> >>>>> >> >> >>>>> >> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com >> ] Sent: >> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern; >> >> >>>>> huang@sce.carleton.ca ; >> sfc@ietf.org Subject: Re: [sfc] Service >> >> >>>>> Chains, Paths, and Load Balancers >> >> >>>>> >> >> >>>>> Ian, I don't think you disagree with me at all in this regard. = I >> >>am >> >> >>>>> not requesting the the architecture or the solution prohibit >> >> >>>>> deployments in the specific fashion. I am objecting to Huang's >> >> >>>>> reading of my note as saying that such deployments are required >> >> >>>>> they by the archtiecture. >> >> >>>>> >> >> >>>>> As I have said repeatedly, I am not trying to prohibit such >> >> >>>>> things. Whether they are a good idea or not depends upon many >> >> >>>>> factors outside of the scope of the WG. I happen to think that >> >>they >> >> >>>>> are usually a bad idea. >> >> >>>>> >> >> >>>>> But the archtiecture si carefully avoiding attempting to know w= hat >> >> >>>>> is and is not eployable. >> >> >>>>> >> >> >>>>> Yours, Joel >> >> >>>>> >> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >> >>>>>> I disagree. >> >> >>>>>> >> >> >>>>>> We routinely have stateful devices that manage tens of million= s >> >> >>>>>> of >> >> >>>>> concurrent flows in both access network and data center >> >> >>>>> environments today. You can't seriously believe that in the >> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only >> >> going >> >> >>>>> to have small numbers of service chains with equally small numb= ers >> >> >>>>> of active service paths? >> >> >>>>>> >> >> >>>>>> Your sounds too much like "no one will ever need more than 64K= " >> >> >>>>>> for >> >> >>>>> comfort. >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> ________________________________________ From: sfc >> >> >>>>>> [sfc-bounces@ietf.org ] on >> behalf of Joel M. Halpern >> >> >>>>> [jmh@joelhalpern.com ] >> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >> huang@sce.carleton.ca ; >> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service >> Chains, Paths, and Load >> >> >>>>>> Balancers >> >> >>>>>> >> >> >>>>>> No, it will mean that if someone tries to deploy the archtietu= re >> >> >>>>>> particularly badly, they will exceed the limits of their >> >> >>>>>> devices. The architecture does not require such absurd use of >> >> >>>>>> service paths. Since I can not figure out how to write >> >> >>>>>> architectural words to prohibit it, the architecture does perm= it >> >> >>>>>> such abuse. >> >> >>>>>> >> >> >>>>>> Please do not read my saying that the archtiecture permits >> >> >>>>>> something as saying it is either deisred or required by the wo= rk. >> >> >>>>>> It isn't. >> >> >>>>>> >> >> >>>>>> Yours, Joel >> >> >>>>>> >> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >> >>>>>>> If you need to support 100 service chains, it will mean >> >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a >> >> >>>>>>> core router. >> >> >>>>>>> >> >> >>>>>>> Chang >> >> >>>>>>> >> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >> >>>>>>>> The architecture allows a range of deployments, from 1 >> >> >>>>>>>> service path to 160000 service paths. I would hope that >> >> >>>>>>>> operators are prepared for the complexities if they choose t= o >> >> >>>>>>>> avoid any use of local load balancing and in stead provision >> >> >>>>>>>> 160,000 service paths. >> >> >>>>>>>> >> >> >>>>>>>> Yours, Joel >> >> >>>>>>>> >> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> >> >>>>>>>>> Paul, >> >> >>>>>>>>> >> >> >>>>>>>>> How many path identifiers there will be for a 4 hop service >> >> >>>>>>>>> chain with 20 instances at each hop? >> >> >>>>>>>>> >> >> >>>>>>>>> Maria >> >> >>>>>>>>> >> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03 >> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com >> ; >> >> >>>>>>>>> mohamed.boucadair@orange.com >> ; sfc@ietf.org ; >> >> >>>>>>>>> mikebianc@aol.com *Subject:* >> Re: [sfc] Service Chains, >> >> >>>>>>>>> Paths, and Load Balancers >> >> >>>>>>>>> >> >> >>>>>>>>> Lucy, >> >> >>>>>>>>> >> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the >> >> >>>>>>>>> forwarding. I=B9d >> >> >>>>> make >> >> >>>>>>>>> the minor change: the path identifier can be used to derive >> >> >>>>>>>>> the needed forwarding and associated transport. >> >> >>>>>>>>> >> >> >>>>>>>>> It is _not_ the transport, but rather is used to simply >> >> >>>>>>>>> identify the service path (or graph) that packets must >> >> >>>>>>>>> traverse. By having a path identifier, the exact >> >> >>>>>>>>> indirection that people seem to be asking for on this >> >> >>>>>>>>> thread can be simply be implemented. The path identifier >> >> >>>>>>>>> provides nothing more than a lookup, that lookup can result >> >> >>>>>>>>> in a one or more (equal or weighted) transport next >> >> >>>>>>>>> hop(s). >> >> >>>>>>>>> >> >> >>>>>>>>> Paul >> >> >>>>>>>>> >> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >> >>>>>>>>> > >> >> >> >>>>>>>>> wrote: >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the >> >> >>>>>>>>> service path identifier to drive the forwarding actions. >> >> >>>>>>>>> >> >> >>>>>>>>> Lucy >> >> >>>>>>>>> >> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> >> >>>>>>>>> Of*mohamed.boucadair@orange.com >> >> >> >>>>>>>>> *Sent:*Thursday, >> >> July >> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >> >> >>>>>>>>> ;jmh@joelhalpern.com >> >> >> >>>>>>>>> ;sfc@ietf.org >> >> >> >>>>>>>>> *Subject:*Re: [sfc] Service Chains, >> >> >>>>>>>>> Paths, and Load Balancers >> >> >>>>>>>>> >> >> >>>>>>>>> Re-, >> >> >>>>>>>>> >> >> >>>>>>>>> The merged draft calls out explicitly a service path >> >> >>>>>>>>> identifier. I object to use that identifier to derive >> >> >>>>>>>>> forwarding actions. >> >> >>>>>>>>> >> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every >> >> >>>>> available SFC >> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not >> >> >>>>> required/justified >> >> >>>>>>>>> nor possible in various deployment contexts. >> >> >>>>>>>>> >> >> >>>>>>>>> SFC forwarding actions should rely on the piece of >> >> >>>>>>>>> information >> >> >>>>> that will >> >> >>>>>>>>> be present in all deployments: that is the one required to >> >> >>>>>>>>> structure a service chain. How that information is used to >> >> >>>>>>>>> infer forwarding >> >> >>>>> actions >> >> >>>>>>>>> is a solution-oriented discussion. >> >> >>>>>>>>> >> >> >>>>>>>>> Cheers, >> >> >>>>>>>>> >> >> >>>>>>>>> Med >> >> >>>>>>>>> >> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> >> >>>>> de*mikebianc@aol.com >> >> >>>>>>>>> *Envoy=E9 :*mercredi 9 juillet >> >> >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >> >> >> >>>>>>>>> ;sfc@ietf.org >> >> >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains, >> >> >>>>>>>>> Paths, and Load Balancers >> >> >>>>>>>>> >> >> >>>>>>>>> Is anyone still questioning the difference between SF Chain >> >> >>>>>>>>> and SF >> >> >>>>> Path? >> >> >>>>>>>>> Other than clarifying the definition so that it's clear to >> >> >>>>> those not >> >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on >> >> >>>>>>>>> these terms. >> >> >>>>>>>>> >> >> >>>>>>>>> To me, the one point that is still unclear is whether it is >> >> >>>>>>>>> the intent of this draft to ultimately specify what the ID >> >> >>>>>>>>> of the SFC Header >> >> >>>>> should >> >> >>>>>>>>> reference (the chain or the path), or if this draft simply >> >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to >> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or >> >> >>>>>>>>> path and the choice of chain or >> >> >>>>> path to >> >> >>>>>>>>> be negotiated in the control-plane. >> >> >>>>>>>>> >> >> >>>>>>>>> If the latter (ambiguous), then the draft would have >> >> >>>>>>>>> require that both SFP and SFC be supported (or make one >> >> >>>>>>>>> required and the other optional) to avoid some vendors only >> >> >>>>>>>>> supporting SFP and others only supporting SFC. >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>> >> >> >> >>>>>>>-----------------------------------------------------------------= --- >> >>>>>>>-- >> >> >>>>>-- >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>>>> >> >> >>>>>>>>> *From:*jmh@joelhalpern.com >> > >> >>>>>>>>> >> > >> >> >>>>>>>>> *To:*sfc@ietf.org > >> >>>>>>>>> >> > *Sent:*Tuesday, July >> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load >> >> >>>>>>>>> Balancers >> >> >>>>>>>>> >> >> >>>>>>>>> I have been trying to figure out how to clearly answer a >> >> >>>>>>>>> number of comments that have been made about the proposed >> >> >>>>>>>>> merged archtiecture draft. Assuming we can get working >> >> >>>>>>>>> group agreement on the intent, we will work to improve the >> >> >>>>>>>>> wording so that readers who have not participated in the WG >> >> >>>>>>>>> discussion will understnd it the way the >> >> >>>>> working >> >> >>>>>>>>> group intends. >> >> >>>>>>>>> >> >> >>>>>>>>> But what do we intend? I will try to explain my personal >> >> >>>>>>>>> view, and see if that helps. >> >> >>>>>>>>> >> >> >>>>>>>>> In this regard, it is important to keep in mind that what >> >> >>>>>>>>> we are defining is the data plane architecture. We are not >> >> >>>>>>>>> attempting to define the architecture for the entire >> >> >>>>>>>>> solution for service chaining. That would encompass >> >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual >> >> >>>>>>>>> machine and image management, and many other aspects. >> >> >>>>>>>>> >> >> >>>>>>>>> As a result there are many things which clearly need to >> >> >>>>>>>>> exist in the larger system, but which are dealt with above >> >> >>>>>>>>> where we are >> >> >>>>> functioning, >> >> >>>>>>>>> and are not directly required by the work we are doing. >> >> >>>>>>>>> >> >> >>>>>>>>> In order to get to service chain vs service path, as I >> >> >>>>>>>>> understand >> >> >>>>> them, >> >> >>>>>>>>> I need to first discuss load balancing. There are at least >> >> >>>>>>>>> three different ways that load balancing can and will >> >> >>>>>>>>> interact with service chaining. There probably are more. >> >> >>>>>>>>> The point of the archtiecture is to permit all of these, >> >> >>>>>>>>> but not to mandate that any particular kind >> >> >>>>> be used >> >> >>>>>>>>> in any solution. >> >> >>>>>>>>> >> >> >>>>>>>>> 1) Load balancing as a service provided to the end user. >> >> >>>>>>>>> This is a service function. It receives user packets, and >> >> >>>>>>>>> modifies them (or >> >> >>>>> marks >> >> >>>>>>>>> them, or ...) so as to choose an end user service instance >> >> >>>>>>>>> to receive the users packet. This is an important service >> >> >>>>>>>>> function to be able to include in service chaining. It's >> >> >>>>>>>>> behavior may affect requirements on how service chaining is >> >> >>>>>>>>> done. But it has very little impact on the archtiecture. >> >> >>>>>>>>> From an architectural pe3rspective it is simply a >> >> >>>>> service >> >> >>>>>>>>> function which may modify the underlying packet. >> >> >>>>>>>>> >> >> >>>>>>>>> 2) There is internal load balancing. That is, one can have >> >> >>>>>>>>> what >> >> >>>>> appears >> >> >>>>>>>>> to the service chaining architecture as a single point of >> >> >>>>>>>>> contact >> >> >>>>> for a >> >> >>>>>>>>> specific service function, but is actually delivered by a >> >> >>>>> collection of >> >> >>>>>>>>> virtual or physical machines, possibly including one or >> >> >>>>>>>>> several load balancers (for example using VRRP-like >> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is >> >> >>>>>>>>> invisible to the service chaining data plane mechanisms. It >> >> >>>>>>>>> is likely that it is visible to various control mechanisms, >> >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm >> >> >>>>>>>>> instantiation. The architectural impact of permitting this >> >> >>>>>>>>> is largely that we need to be careful that our terminology >> >> >>>>>>>>> does not lead >> >> >>>>> readers to >> >> >>>>>>>>> think we are prohibiting it. >> >> >>>>>>>>> >> >> >>>>>>>>> 3) There can also be load balancing done by selecting >> >> >>>>>>>>> packet paths for the service chaining that direct traffic >> >> >>>>>>>>> to different places. We would not want to require that a >> >> >>>>>>>>> given service function appear at only one place in the >> >> >>>>>>>>> network. >> >> >>>>>>>>> >> >> >>>>>>>>> It is of course the case that these may be combined. I tend >> >> >>>>>>>>> to >> >> >>>>> refer to >> >> >>>>>>>>> the collection of entities that appear to service chaining >> >> >>>>>>>>> as a single point as a cluster. Not because cluster is a >> >> >>>>>>>>> good term. But because I do not have another one. Thus, the >> >> >>>>>>>>> point of type 3 load balancing >> >> >>>>> is to >> >> >>>>>>>>> direct different subsets of traffic to different singular >> >> >>>>>>>>> or clustered service functions in different places in the >> >> >>>>>>>>> network. >> >> >>>>>>>>> >> >> >>>>>>>>> Now with that said, what do I mean when I talk about >> >> >>>>>>>>> service chain and service path/ Service chain is a sequence >> >> >>>>>>>>> of logical functions to be applied to a subset of packets. >> >> >>>>>>>>> It is equivalent of saying that some subset of traffic is >> >> >>>>>>>>> to get DPI, charging, content inspection, and firewall >> >> >>>>>>>>> while a different subset is to go directly to the cache >> >> >>>>> without >> >> >>>>>>>>> visiting any other service functions. >> >> >>>>>>>>> >> >> >>>>>>>>> That is not enough information to direct the packets. A >> >> >>>>>>>>> service path is, in some fashion, a sequence of locations >> >> >>>>>>>>> in the network. Those locations will be singular or >> >> >>>>>>>>> clustered service function delivery locations. They may be >> >> >>>>>>>>> addressed by IP address. They may be addressed as ports on >> >> >>>>>>>>> an SFF. There are many different ways that the locations >> >> >>>>>>>>> may be known to the service chaining infrastructure and the >> >> >>>>>>>>> transport. >> >> >>>>>>>>> >> >> >>>>>>>>>> From the point of view of the work of the SFC group, we >> >> >>>>>>>>>> need to be >> >> >>>>>>>>> able to talk about the high level abstraction, the service >> >> >>>>>>>>> chain, which drives the forwarding. And we need to talk >> >> >>>>>>>>> about the actual data path packets will take in the >> >> >>>>>>>>> network. >> >> >>>>>>>>> >> >> >>>>>>>>> Several of the comments have said "but the whole path may >> >> >>>>>>>>> not be known at the front." This architecture deals with >> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load >> >> >>>>>>>>> balancers above, there can be decisions and behaviors which >> >> >>>>>>>>> are invisible to the service chaining mechanisms (in much >> >> >>>>>>>>> the same way that bridging within a LAN is largely >> >> >>>>>>>>> invisible to routing between LANs.) The other provision we >> >> >>>>>>>>> make is >> >> >>>>> that >> >> >>>>>>>>> reclassification can be done in mid-chain when necessary. >> >> >>>>>>>>> That will direct packets to a new chain. Based on >> >> >>>>>>>>> information available at the re-classification point. >> >> >>>>>>>>> >> >> >>>>>>>>> I hope that this helps explain what we are after. If it >> >> >>>>>>>>> does, and if the intent is acceptable to the working group, >> >> >>>>>>>>> we can figure out what additional words are needed to >> >> >>>>>>>>> convey this. If the working group disagree with the intent, >> >> >>>>>>>>> then we will of course adjust to match the working group >> >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to >> >> >>>>>>>>> try next. >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> _______________________________________________ sfc >> >> mailing >> >> >>>>>>>>> list sfc@ietf.org >> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>>>>>>> >> >> >>>>>>>>> _______________________________________________ sfc >> >> mailing >> >> >>>>>>>>> list sfc@ietf.org >> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> _______________________________________________ sfc >> >> mailing >> >> >>>>>>>> list sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>>>>>> >> >> >>>>>>> >> >> >>>>>>> _______________________________________________ sfc >> >> mailing >> >> >>>>>>> list sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>>>>> >> >> >>>>>> >> >> >>>>>> _______________________________________________ sfc mailing >> >> list >> >> >>>>>> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>>>> >> >> >>>>> >> >> >>>>> _______________________________________________ sfc mailing >> >> list >> >> >>>>> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>> >> >> >>>> _______________________________________________ sfc mailing >> >> list >> >> >>>> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>> >> >> >>>> _______________________________________________ sfc mailing >> >> list >> >> >>>> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>>> >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> sfc mailing list >> >> >> sfc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >> > >> >> >_______________________________________________ >> >> >sfc mailing 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 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 09:43: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 64D2F1B2B50 for ; Fri, 11 Jul 2014 09:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 SjEetVDfT_HU for ; Fri, 11 Jul 2014 09:43:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967201A0A9E for ; Fri, 11 Jul 2014 09:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66342; q=dns/txt; s=iport; t=1405097026; x=1406306626; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Gi1mDAiNiVm5Yo//DBg3IRC+lZ+Z7uYsnmFwZ4VnGE8=; b=YL/HpTba4cHCTq9fG/2Hay8F9bKTEpfVTUiIVHEGDjSN+6Bf9qibLRK7 QK3AwNNLol8kqMJmUgGimayGXRbGI80VFZM0s5jUpavrPT1qNiXW/laR/ z/lxAJFTHUWcPXZlYX73P6DGDg7KeANknPzVD61lw1jQTOY1+Hd3rAZF1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAP8SwFOtJV2a/2dsb2JhbABPCoMOUlqCcawJkXgKh0IBGXIWdYQDAQEBBAEBARcBCBExCQIVBAIBCBEBAwEBAQICIwMCAgIlCxQBAgYIAgQBEhuIEwMRDa1ZmH4TBIEsiFGDIIFKBgUGAR0IECICAgKCcYFMBZYiSYQai2iININEgW8IFyI X-IronPort-AV: E=Sophos;i="5.01,644,1400025600"; d="scan'208";a="60128257" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 11 Jul 2014 16:43:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGhcZ3014378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:43:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:43:38 -0500 From: "Jim Guichard (jguichar)" To: "NAPIERALA, MARIA H" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Ron Parker" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AACNZ7AP//xIOAgABMIQD//74DgIAARQ0A//++ZYA= Date: Fri, 11 Jul 2014 16:43:37 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="utf-8" Content-ID: <468066C505C31C4698FAB3A080B8CB7D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YLbH3g-EXlhQ7VJ3ZSop0rKa42U Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:43:46 -0000 SSBhbSBub3QgcHJvcG9zaW5nIGEgc29sdXRpb24gKHRoYXTigJlzIHRoZSBXR+KAmXMgam9iKSBi dXQgc2ltcGx5IHVzaW5nIG15DQppbnRlcnByZXRhdGlvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIHRv IG1vdmUgdGhlIGRpc2N1c3Npb24gZm9yd2FyZC4NCg0KWWVzLCBpdCBpcyBzdGlsbCBhIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIGZvciB0aGUgcmVhc29ucyB0aGF0IEpvZWwNCm1lbnRpb25lZCBp biBhbm90aGVyIGVtYWlsLg0KDQpPbiA3LzExLzE0LCAxMjozNyBQTSwgIk5BUElFUkFMQSwgTUFS SUEgSCIgPG1uMTkyMUBhdHQuY29tPiB3cm90ZToNCg0KPj4gPj4gSSB0aGluayBvZiBpdCB0aGlz IHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhDQo+PnBvaW50ZXIN Cj4+ID4+dG8NCj4+ID4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0 LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UNCj4+IGRlZmluZQ0KPj4gPllvdSBhcmUgdGFsa2luZyBh Ym91dCB0cmFmZmljIGVuZ2luZWVyaW5nIG9mIHBhdGhzIHRoYXQgYSBzZXJ2aWNlIGNoYWluDQo+ PiA+Y2FuIHRha2UuDQo+PiA+VGhpcyBzdXJlbHkgY291bGQgYmUgZG9uZS9hbGxvd2VkIGJ1dCB0 aGlzIGNhbm5vdCBiZSBhIHJlcXVpcmVtZW50IGZvcg0KPj4gPmFsbCB0cmFmZmljLg0KPj4gDQo+ PiBKaW0+IHRoYXTigJlzIHdoeSBJIHNhaWQgKm1pZ2h0KiAtIElPVyB5b3UgZG8gbm90IGhhdmUg dG8sIGl0cyBhDQo+PmRlcGxveW1lbnQNCj4+IGNob2ljZSBhbmQgaXMgc3VwcG9ydGVkIGJ5IHRo ZSBhcmNoaXRlY3R1cmUuDQo+DQo+WWVzLCBJIG5vdGljZWQsIGJ1dCBJIGFsc28gbm90aWNlZCB0 aGF0IHlvdSBhcmUgcHJvcG9zaW5nIGEgc29sdXRpb24NCj5iYXNlZCBvbiBpdC4NCj4NCj5Zb3Ug aGF2ZSBub3QgY29tbWVudCBvbiB0aGUgcmVzdDogaXMgaXQgc3RpbGwgInNlcnZpY2UgKnBhdGgq IGlkZW50aWZpZXIiPw0KPg0KPk1hcmlhDQo+DQo+PiA+PiBPbiA3LzExLzE0LCAxMToyNiBBTSwg Ik5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPj4gd3JvdGU6DQo+PiA+Pg0K Pj4gPj4gPkppbSwNCj4+ID4+ID4NCj4+ID4+ID5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRo ZSBkZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4+ID4+ID4ic2VydmljZSBw YXRoIGlkZW50aWZpZXIiPw0KPj4gPj4gPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxs IFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkNCj4+ID4+KHdoaWNoDQo+PiA+PiA+aXMg bXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNp c2lvbg0KPj53aGljaA0KPj4gPj4gPm5leHQtaG9wIFNGRiB0byBwaWNrLiAgSXQgaXMgYSBjZW50 cmFsaXplZCBkZWNpc2lvbi4NCj4+ID4+ID4NCj4+ID4+ID5NYXJpYQ0KPj4gPj4gPg0KPj4gPj4g Pg0KPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+IEZyb206IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj4gPj4g Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNDQo+PiA+PiA+PiBUbzogTkFQ SUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKb2VsIE0uDQo+ PiA+PiA+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K Pj4gPj4gPj4NCj4+ID4+ID4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVy c3RhbmQgd2h5IGEgc2VydmljZSBwYXRoDQo+PmlkZW50aWZpZXINCj4+ID4+ID4+IHByZXZlbnRz IGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhDQo+ PiA+PnNlcnZpY2UNCj4+ID4+ID4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVu Y2U/DQo+PiA+PiA+Pg0KPj4gPj4gPj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEs IE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4NCj4+ID4+ ID4+ID5EaXR0by4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiA+PiA+PiA+PiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ PiA+PiA+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQo+PiA+PiA+ PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4+ID4+ID4+ID4+IFRv OiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uDQo+ PkhhbHBlcm47DQo+PiA+PiBSb24NCj4+ID4+ID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+ PiA+PiA+PiA+PiBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBSZS0sDQo+PiA+PiA+PiA+ Pg0KPj4gPj4gPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVz Y3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+PiA+PiA+PmRyYWZ0Lg0KPj4gPj4gPj4gPj4NCj4+ID4+ ID4+ID4+IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBh IGhpbnQgdGhhdA0KPj50aGUNCj4+ID4+ZnVsbA0KPj4gPj4gPj4gPj5kaXN0cmlidXRlZA0KPj4g Pj4gPj4gPj4gbW9kZWwgaXMgbm90IGFsbG93ZWQuDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4g U2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2Ug Y2hhaW4NCj4+ID4+aXRzZWxmDQo+PiA+PiA+PiA+PnNob3VsZCBiZQ0KPj4gPj4gPj4gPj4gcHJv dmlkZWQgaW5zdGVhZC4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBDaGVlcnMsDQo+PiA+PiA+ PiA+PiBNZWQNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+LS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+PiA+PiA+PiA+PiA+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ID4+ID4+ID4oamd1aWNoYXIp DQo+PiA+PiA+PiA+PiA+RW52b3nDqSA6IHZlbmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxOA0K Pj4gPj4gPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJv biBQYXJrZXI7DQo+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID5PYmpldCA6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4gPj4g Pg0KPj4gPj4gPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmlj YWxseSBpcyB0aGlzDQo+PiA+PmZ1bmN0aW9uYWxpdHkNCj4+ID4+ID4+ID4+ID5wcm9oaWJpdGVk PyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKg0KPj4g Pj5TRkbigJlzDQo+PiA+PiA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxl dCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50DQo+PnRvIGENCj4+ID4+ID4+ID4+bG9va3VwDQo+ PiA+PiA+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4g dGhlIGNoYWluLCBJIGFtDQo+Pm5vdA0KPj4gPj4gPj5zdXJlDQo+PiA+PiA+PiA+Pmhvdw0KPj4g Pj4gPj4gPj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4+ID4+ID4N Cj4+ID4+ID4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8 bW4xOTIxQGF0dC5jb20+DQo+PiA+PiA+PiB3cm90ZToNCj4+ID4+ID4+ID4+ID4NCj4+ID4+ID4+ ID4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+ID4+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj4gPj5HdWljaGFyZA0KPj4g Pj4gPj4gPj4gPj4+KGpndWljaGFyKQ0KPj4gPj4gPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVs eSAxMSwgMjAxNCA5OjU0IEFNDQo+PiA+PiA+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEg SDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+ PiA+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQNCj4+QmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiBUaGVu IEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zDQo+ PnRvDQo+PiA+Pm1lDQo+PiA+PiA+PiA+PnRoYXQgaWYNCj4+ID4+ID4+ID4+ID4+PiB5b3UgYWxs b3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGDQo+Pml0 DQo+PiA+PiA+PndpbGwNCj4+ID4+ID4+ID4+dXNlDQo+PiA+PiA+PiA+PiA+Pj5mb3INCj4+ID4+ ID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBj aGFpbiB0aGVuIHlvdQ0KPj4gPj4gPj5iZXR0ZXINCj4+ID4+ID4+ID4+bWFrZQ0KPj4gPj4gPj4g Pj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2Fy ZGluZw0KPj5sb2dpYw0KPj4gPj50bw0KPj4gPj4gPj4gPj5yZWFjaA0KPj4gPj4gPj4gPj4gPj4+ dGhlDQo+PiA+PiA+PiA+PiA+Pj4gbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3 aXNlIHlvdSBhcmUgaW4gZGVlcA0KPj4gPj50cm91YmxlLg0KPj4gPj4gPj4gPj4gPj4+DQo+PiA+ PiA+PiA+PiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCINCj4+ IDxtbjE5MjFAYXR0LmNvbT4NCj4+ID4+ID4+ID4+IHdyb3RlOg0KPj4gPj4gPj4gPj4gPj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5z dGFudGlhdGVkIG9ubHkgaW4NCj4+ID4+ID4+cmVsZXZhbnQNCj4+ID4+ID4+ID4+ID4+PlNGRnMN Cj4+ID4+ID4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4gPj4gPj4gPj4gPj4+ID4N Cj4+ID4+ID4+ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4g Pj4gPj4+ID4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmltDQo+PiA+PiA+Pkd1aWNoYXJkDQo+PiA+PiA+PiA+PiA+Pj4gPj4oamd1aWNoYXIp DQo+PiA+PiA+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0N Cj4+ID4+ID4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gPj5CYWxhbmNlcnMNCj4+ID4+ID4+ID4+ID4+PiA+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+IFdlbGwgSSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4g dGhhdCBpZiBJIGhhdmUNCj4+ID4+dW5kZXJzdG9vZA0KPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+ ID4+PiA+PnByb3Bvc2FsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gY29ycmVjdGx5IGFzIGl0IHdvdWxk IHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4+ID4+c2luZ2xlDQo+PiA+PiA+PlNG DQo+PiA+PiA+PiA+PiA+Pj53aXRoaW4NCj4+ID4+ID4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4g Pj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUg aXMgbm8NCj4+d2F5IHRvDQo+PiA+PiA+Pmtub3cNCj4+ID4+ID4+ID4+YQ0KPj4gPj4gPj4gPj4g Pj4+ID4+cHJpb3JpDQo+PiA+PiA+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZG IHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueQ0KPj5naXZlbg0KPj4gPj4gPj5wb2ludA0KPj4g Pj4gPj4gPj5pbg0KPj4gPj4gPj4gPj4gPj4+dGltZS4NCj4+ID4+ID4+ID4+ID4+PiA+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBNLiBIYWxwZXJuIg0K Pj4gPj4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+PiA+PiB3cm90ZToNCj4+ID4+ID4+ ID4+ID4+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5Sb24sIHRoaW5raW5nIGFib3V0IHRoaXMs IEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvcg0KPj5wcm9ibGVtDQo+PiA+PiA+PndpdGgNCj4+ID4+ ID4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj55b3VyDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPnBy b3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gIChBbmQgSSByZWFkaWx5IGFkbWl0IEkNCj4+bWF5 DQo+PiA+Pm5vdA0KPj4gPj4gPj4gPj4gPj4+dW5kZXJzdGFuZA0KPj4gPj4gPj4gPj4gPj4+ID4+ ID5pdC4pDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5UaGUgcHJv cG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyDQo+PmZvcg0KPj4g Pj50aGUNCj4+ID4+ID4+ID4+bmV4dA0KPj4gPj4gPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0 aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQNCj4+ZGVsaXZlcnMNCj4+ID4+ID4+ dG8pLA0KPj4gPj4gPj4gPj5pbg0KPj4gPj4gPj4gPj4gPj4+ZXZlcnkNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdv cmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQNCj4+ID4+bWVhbnMNCj4+ID4+ID4+ID4+dGhhdA0K Pj4gPj4gPj4gPj4gPj4+ID4+ZXZlcnkNCj4+ID4+ID4+ID4+ID4+PiA+PiA+U0ZGIHdvdWxkIGhh dmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQNCj4+c3RhdGVmdWwNCj4+ID4+bG9h ZA0KPj4gPj4gPj4gPj4gPj4+YmFsYW5jZXIuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPkkgYWh2ZSBu byBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kDQo+Pi8gb3INCj4+ ID4+ID4+ID4+c3RhdGVmdWwuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFy Y2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGENCj4+ID4+ZnVsbCwNCj4+ID4+ ID4+ID4+Zmxvdw0KPj4gPj4gPj4gPj4gPj4+ID4+ID5zZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2Fk IGJhbGFuY2VyIHNlZW1zIHRvIG1lIHRvIGJlIGFuDQo+PiA+PiA+PiA+PmFjY2VwdGFibGUNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+aW1wb3NpdGlvbi4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID5Kb2VsDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwg Sm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkg cGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UNCj4+ID4+dGhpcw0KPj4g Pj4gPj53b3JrDQo+PiA+PiA+PiA+PiA+Pj4gPj5zZW5zaWJseQ0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuICBJIGV4cGVjdCB0aGF0DQo+ PnRoZQ0KPj4gPj4gPj5zZXJ2aWNlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBh bmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYNCj4+Y2FwYWJpbGl0aWVzLA0KPj4gPj4gPj53 aWxsDQo+PiA+PiA+PiA+PmJlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFu ZCBpbnN0YWxsZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZQ0KPj5jaGFpbnMNCj4+ID4+ID4+dG8g YmUNCj4+ID4+ID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IEJT UyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kDQo+PmVuYWJsZQ0K Pj4gPj4gPj4gPj4gPj4+c2VsZi1zZWxlY3Rpb24NCj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBmcm9t IHRoZXNlLiAgSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5DQo+PnBvbGljeQ0K Pj4gPj4gPj4gPj5kcml2ZS4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuDQo+PiA+ PmFyY2h0aWVjdHVyZQ0KPj4gPj4gPj4gPj5kcml2ZW4NCj4+ID4+ID4+ID4+ID4+PmJ5DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2Vy dmljZSBwYXRocy4NCj4+SXQNCj4+ID4+aXMNCj4+ID4+ID4+ID4+aGFyZGVyDQo+PiA+PiA+PiA+ PiA+Pj50bw0KPj4gPj4gPj4gPj4gPj4+ID4+c2VlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gaG93 IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlDQo+PmFsbG93DQo+ PiA+PiBtb3JlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNw ZWN0aXZlIEkNCj4+ZGVzY3JpYmVkDQo+PiA+PmlzDQo+PiA+PiA+PiA+Pm91dHNpZGUNCj4+ID4+ ID4+ID4+ID4+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UNCj4+ YXJlDQo+PiA+PiA+PiA+PnRhc2tlZCB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+YWdyZWUNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pm9uLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNs YWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQNCj4+YQ0KPj4gPj4gPj5jZXJ0 YWluDQo+PiA+PiA+PiA+PiA+Pj53YXkuDQo+PiA+PiA+PiA+PiA+Pj4gPj5pdA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZl cmVuY2VzLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gWW91 cnMsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gSm9lbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3Rl Og0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0 aW9uIGFib3V0IHNlcnZpY2UNCj4+ID4+IGluc3RhbmNlcw0KPj4gPj4gPj4gPj4gdGhhdA0KPj4g Pj4gPj4gPj4gPj4+ID4+bmVlZHMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+dG8NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90 ZW50aWFsbHkNCj4+IGV2ZW4NCj4+ID4+ID4+ID4+YWNyb3NzDQo+PiA+PiA+PiA+PiA+Pj5kYXRh DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2 ZSBzY29wZSwgaXMgbGFyZ2UNCj4+ID4+ZW5vdWdoDQo+PiA+PiA+PmFuZA0KPj4gPj4gPj4gPj4g Pj4+IGNvbXBsZXgNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0 byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+PiA+Pmxpa2UgYQ0KPj4gPj4gPj4gPj4g Pj4+ZGlmZmljdWx0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gSSdt IGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PiA+PiA+ PmR5bmFtaWMNCj4+ID4+ID4+ID4+ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbA0KPj5v Zg0KPj4gPj4gPj53aGljaA0KPj4gPj4gPj4gPj5hcmUNCj4+ID4+ID4+ID4+ID4+PiA+PmJpZ2dl cg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRh Ymx5IGFuZCBzdGFibHkNCj4+ID4+IGltcGxlbWVudGVkPw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5 IGlzIG1vcmUgY29tcGxpY2F0ZWQsDQo+PiA+PnRoYXQNCj4+ID4+ID4+aXMNCj4+ID4+ID4+ID4+ YQ0KPj4gPj4gPj4gPj4gPj4+Z29vZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQg aXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBbam1oQGpvZWxoYWxw ZXJuLmNvbV0NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9l bCBIYWxwZXJuIERpcmVjdDsNCj4+IG1pa2ViaWFuY0Bhb2wuY29tOw0KPj4gPj4gPj5JYW4NCj4+ ID4+ID4+ID4+ID4+PlNtaXRoOw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQNCj4+ID4+ID4+QmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1 ZS4gIEFuZCBvbmUgdGhhdCBJDQo+PndvdWxkDQo+PiA+PiA+PnByZWZlcg0KPj4gPj4gPj4gPj53 ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gPj4g Pj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQg ZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+PiA+PiA+PiA+PnJlcXVp cmVtZW50cw0KPj4gPj4gPj4gPj4gPj4+YW5kDQo+PiA+PiA+PiA+PiA+Pj4gPj4gdGhlDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGlu Zm9ybWF0aW9uIGFib3V0IHNlcnZpY2UNCj4+ID4+IGluc3RhbmNlcw0KPj4gPj4gPj4gPj50aGF0 DQo+PiA+PiA+PiA+PiA+Pj4gbmVlZHMNCj4+ID4+ID4+ID4+ID4+PiA+PiB0bw0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVu dGlhbGx5DQo+PmV2ZW4NCj4+ID4+ID4+IGFjcm9zcw0KPj4gPj4gPj4gPj4gPj4+ZGF0YQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29w ZSwgaXMgbGFyZ2UNCj4+ZW5vdWdoDQo+PiA+PiA+PmFuZA0KPj4gPj4gPj4gPj4gPj4+Y29tcGxl eA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQg aW50byBlYWNoIFNGRiBzZWVtcw0KPj4gPj5saWtlIGENCj4+ID4+ID4+ID4+ID4+PmRpZmZpY3Vs dA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBh cmtlciB3cm90ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2Yg bXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBlbmQNCj4+ID4+ID4+c2VsZWN0aW9uDQo+PiA+PiA+ PiA+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVy Zm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcw0KPj5ieQ0KPj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+ PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChw ZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZA0KPj4gPj4gc3Vic2VxdWVudGx5DQo+PiA+PiA+ PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+U0ZGcyk/DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ PiBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0bw0KPj5yZWNsYXNzaWZpY2F0aW9u Lg0KPj4gPj4gPj5BbmQNCj4+ID4+ID4+ID4+ID4+PnN1cmVseSwNCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhbmQgbm90IHJlbGVnYXRlZCB0 bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBm YXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2gNCj4+IGV2ZW4NCj4+ID4+ID4+IHRob3VnaA0K Pj4gPj4gPj4gPj4gYQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2Yg ZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kDQo+PnBlcmhhcHMNCj4+ID4+ID4+bG9jYWwNCj4+ ID4+ID4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5 KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0KPj4gPj5wb2ludHMu DQo+PiA+PiA+PiA+PlRoaXMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMg bm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0DQo+PiA+PmFsbC4NCj4+ID4+ID4+ ID4+TXkNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhp cyBhcHByb2FjaCBpcyBwcmltYXJpbHkNCj4+ID4+ZHJpdmVuDQo+PiA+PiA+PmJ5DQo+PiA+PiA+ PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kg b3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guDQo+PldpdGggYQ0KPj4gPj4gPj5nbG9i YWwNCj4+ID4+ID4+ID4+ID4+PnBhdGgNCj4+ID4+ID4+ID4+ID4+PiA+PmlkDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBh bmQNCj4+bmVlZGluZw0KPj4gPj50bw0KPj4gPj4gPj4gPj5hbHRlcg0KPj4gPj4gPj4gPj4gPj4+ dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFj aCBhbmQgZXZlcnkgYWZmZWN0ZWQNCj4+ID4+ID4+ZW5kLXRvLWVuZA0KPj4gPj4gPj4gPj4gPj4+ cGF0aC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBS b24NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206DQo+PiBzZmMNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIEpv ZWwgSGFscGVybg0KPj4gPj5EaXJlY3QNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNkYXksIEp1bHkNCj4+MTAsDQo+PiA+PiA+ PjIwMTQNCj4+ID4+ID4+ID4+IDY6MTUNCj4+ID4+ID4+ID4+ID4+PiBQTQ0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4gVG86IG1pa2ViaWFuY0Bhb2wuY29tOyBJLlNtaXRoQEY1LmNvbTsgc2ZjQGll dGYub3JnDQo+PiA+PiA+PiBTdWJqZWN0Og0KPj4gPj4gPj4gPj4gUmU6DQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFRoZSB3 YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxDQo+PiA+Pm5lZWRpbmcN Cj4+ID4+ID4+dG8NCj4+ID4+ID4+ID4+ID4+PiA+PmluZmx1ZW5jZQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24g YXQNCj4+dGhlDQo+PiA+PiA+PmV4aXQNCj4+ID4+ID4+ID4+ZnJvbQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4gU0YxLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9u cw0KPj4gPj4gPj4gPj5sb2dpY2FsbHkNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHNlcGFyYXRl IHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdw0KPj4gPj50aGV5DQo+ PiA+PiA+PiA+PiBjaG9vc2UNCj4+ID4+ID4+ID4+ID4+PnRvDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAg UE0sIG1pa2ViaWFuY0Bhb2wuY29tIHdyb3RlOg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IEkg ZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQNCj4+c3VnZ2VzdHMNCj4+ ID4+YW55DQo+PiA+PiA+PiA+PnNvcnQNCj4+ID4+ID4+ID4+ID4+Pm9mDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0 IHRoZQ0KPj4gPj5lbnRpcmUNCj4+ID4+ID4+ID4+cGF0aA0KPj4gPj4gPj4gPj4gPj4+KGFsbA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0 YW50aWF0aW9uLiAgSQ0KPj5iZWxpZXZlDQo+PiA+PiA+PnRoaXMNCj4+ID4+ID4+ID4+ID4+Pm1l YW5zDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9y IG1heWJlIHRoZSBjbGFzc2lmaWVyDQo+PiA+PiA+PmNob29zZXMgYQ0KPj4gPj4gPj4gPj5TRg0K Pj4gPj4gPj4gPj4gPj4+ID4+Q2hhaW4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhl IE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gIEluIGFueQ0KPj4gPj5jYXNlLA0K Pj4gPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNl ZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQDQo+PiA+PiB3aGVyZQ0KPj4gPj4gPj4g Pj4gU0ZJKG4pDQo+PiA+PiA+PiA+PiA+Pj4gaXMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBk ZXRlcm1pbmVkIGF0IHRoZSBTRkkobi0xKSBob3AuICBBY2NvcmRpbmcgdG8gdGhlDQo+PiA+PmRy YWZ0LA0KPj4gPj4gPj4gPj50aGlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Ig d291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldw0KPj4gU0ZQDQo+PiA+PiBh cw0KPj4gPj4gPj4gPj4gPj4+IG9wcG9zZWQNCj4+ID4+ID4+ID4+ID4+PiA+PiB0bw0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNl bGVjdGVkDQo+PiBpbnN0YW5jZQ0KPj4gPj4gb2YNCj4+ID4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDA6DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlz IGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0DQo+PmlzDQo+PiA+PiA+PiA+Pm5lY2Vz c2FyeQ0KPj4gPj4gPj4gPj4gPj4+dG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0 IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZQ0KPj4gPj51c2VkLA0K Pj4gPj4gPj4gPj5hbmQgdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBz ZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZw0KPj5TRidzDQo+PiA+PiA+PiA+Pm5l dHdvcmsNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gbG9jYXRvci4gIFRodXMsIGluc3RhbnRp YXRpb24gb2YgdGhlIFNGQyByZXN1bHRzDQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ Y3JlYXRpb24NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9u IFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+PiA+PiA+PiA+PmZvcndhcmRpbmcNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdv cmRzLCBhbiBTRlANCj4+aXMNCj4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGlu c3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0 cyByZWNsYXNzaWZpY2F0aW9uDQo+Pihvcg0KPj4gPj4gPj4gPj5ub24taW5pdGlhbA0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMg dHJhdmVyc2UgYW4NCj4+ID4+U0ZQLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNz aWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQNCj4+YnkNCj4+ID4+YQ0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNp ZGVudCB3aXRoIGENCj4+c2VydmljZQ0KPj4gPj4gPj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rp b24gb2YgYQ0KPj4gPj5uZXcNCj4+ID4+ID4+ID4+U0ZQLCBhbg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguDQo+PlRo aXMgaXMNCj4+ID4+ID4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+ID4+ID4+PnRvDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+ID4+ID4+ Pg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+Pg0KPj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+Pj4+ Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4gPj4gPj4+Pj4+ Pj4+Pi0tDQo+PiA+PiA+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4tLQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTog KkkuU21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ ICpUbzogKkpvZWwgSGFscGVybg0KPj4gPj4gPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tPixKb2VsDQo+PiA+PiA+PiA+PiBNLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+ DQo+PiA+Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20+LGh1YW5nQHNjZS5j YXJsZXRvbi5jYTxodWFuZ0BzY2UuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwg SnVseSAxMCwgMjAxNA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+PkxvYWQNCj4+ID4+ID4+ID4+QmFsYW5j ZXJzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBB Y3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1 bS1zY2FsZSBkZXBsb3ltZW50cw0KPj4oYW5kDQo+PiA+PiA+PnRoYXQgaXMNCj4+ID4+ID4+ID4+ ID4+PndoYXQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGlu IG15IHdvcmxkKSBvZiBzZXJ2aWNlDQo+PmNoYWlucyBpcw0KPj4gPj4gPj4gPj4gPj4+cHJlY29u Y2VpdmVkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4g dGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZA0KPj4gPj53aXRoDQo+PiA+PiA+PiB0aGF0DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29uY2VwdGlvbi4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50 IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YNCj4+ID4+ID4+ID4+YXNwaXJhdGlvbg0KPj4gPj4gPj4g Pj4gdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRl IGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlDQo+PiA+PiA+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gPj4g Pj4gPj4gPj4+LQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtu b3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZw0KPj4gPj50aGF0IGFuDQo+PiA+PiA+PiA+PiA+ Pj5hcmJpdHJhcnkNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIi LCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0DQo+PiA+Pmlzbid0DQo+PiA+PiA+PiA+PiA+ Pj4gPj5pbnRlbnRpb25hbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0 IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZQ0KPj5sYXN0aW5nDQo+PiA+PiA+PiA+Pmlt cGFjdHMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWls dXJlIG1pdGlnYXRpb24sDQo+PmVsYXN0aWNpdHksDQo+PiA+PiA+PiA+PmFkZHJlc3MNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlz IGEgcHJvYmxlbQ0KPj5JJ20NCj4+ID4+bm90DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcGFy dGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTog Sm9lbCBIYWxwZXJuIERpcmVjdA0KPj4gPj5bam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+ PiA+PiA+PiA+PlNlbnQ6DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOw0KPj5Kb2VsDQo+PiA+Pk0uDQo+PiA+PiA+ PiA+PiBIYWxwZXJuOw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRv bi5jYTsgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOg0KPj4gPj5bc2ZjXQ0KPj4gPj4gPj4gPj5T ZXJ2aWNlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluDQo+ PiA+PnRoaXMNCj4+ID4+ID4+ID4+cmVnYXJkLg0KPj4gPj4gPj4gPj4gPj4+SQ0KPj4gPj4gPj4g Pj4gPj4+ID4+YW0NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUg dGhlIGFyY2hpdGVjdHVyZSBvciB0aGUNCj4+c29sdXRpb24NCj4+ID4+ID4+ID4+cHJvaGliaXQN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFz aGlvbi4gSSBhbQ0KPj5vYmplY3RpbmcNCj4+ID4+dG8NCj4+ID4+ID4+ID4+SHVhbmcncw0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBz dWNoIGRlcGxveW1lbnRzDQo+PiA+PmFyZQ0KPj4gPj4gPj4gPj4gcmVxdWlyZWQNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBl YXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8NCj4+ID4+cHJvaGliaXQNCj4+ID4+ID4+c3VjaA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2Qg aWRlYSBvciBub3QNCj4+ZGVwZW5kcw0KPj4gPj4gdXBvbg0KPj4gPj4gPj4gPj4gbWFueQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhl IFdHLiBJIGhhcHBlbg0KPj50bw0KPj4gPj4gPj50aGluaw0KPj4gPj4gPj4gPj50aGF0DQo+PiA+ PiA+PiA+PiA+Pj4gPj50aGV5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkg YSBiYWQgaWRlYS4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZw0KPj4gPj5h dHRlbXB0aW5nIHRvDQo+PiA+PiA+PiA+Pmtub3cNCj4+ID4+ID4+ID4+ID4+PndoYXQNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0 LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkg ZGlzYWdyZWUuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UNCj4+ IHRlbnMNCj4+ID4+IG9mDQo+PiA+PiA+PiA+PiA+Pj5taWxsaW9ucw0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBvZg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3Mg aW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YQ0KPj4gPj4gY2VudGVyDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJl bGlldmUNCj4+dGhhdA0KPj4gPj5pbg0KPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cNCj4+ ID4+IHlvdQ0KPj4gPj4gPj4gYXJlDQo+PiA+PiA+PiA+PiBvbmx5DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gZ29pbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMg b2Ygc2VydmljZSBjaGFpbnMgd2l0aA0KPj5lcXVhbGx5DQo+PiA+PiA+PnNtYWxsDQo+PiA+PiA+ PiA+PiA+Pj4gbnVtYmVycw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2 aWNlIHBhdGhzPw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBldmVyIG5lZWQN Cj4+ID4+IG1vcmUNCj4+ID4+ID4+IHRoYW4NCj4+ID4+ID4+ID4+ID4+PiA2NEsiDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQu DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IEZyb206DQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4g W3NmYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBNLg0KPj5IYWxwZXJuDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86 DQo+PiA+PiA+PiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2E7DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMs DQo+PiA+PlBhdGhzLA0KPj4gPj4gPj5hbmQNCj4+ID4+ID4+ID4+ID4+PkxvYWQNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25l IHRyaWVzIHRvIGRlcGxveQ0KPj50aGUNCj4+ID4+ID4+ID4+ID4+PmFyY2h0aWV0dXJlDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhcnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2Vl ZCB0aGUgbGltaXRzDQo+Pm9mDQo+PiA+PiA+PnRoZWlyDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoDQo+PiA+ PmFic3VyZA0KPj4gPj4gPj4gdXNlDQo+PiA+PiA+PiA+PiBvZg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8N Cj4+ID4+d3JpdGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3Jk cyB0byBwcm9oaWJpdCBpdCwgdGhlDQo+PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj5kb2VzDQo+PiA+ PiA+PiA+PiA+Pj5wZXJtaXQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc3VjaCBhYnVzZS4N Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUGxl YXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZQ0KPj5hcmNodGllY3R1cmUNCj4+ID4+ ID4+IHBlcm1pdHMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWlu ZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvcg0KPj4gPj5yZXF1aXJlZCBieQ0KPj4gPj4gPj4gPj50 aGUNCj4+ID4+ID4+ID4+ID4+PndvcmsuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlz bid0Lg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ PiBZb3VycywgSm9lbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2Vy dmljZSBjaGFpbnMsIGl0DQo+PndpbGwNCj4+ID4+ID4+bWVhbg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUNCj4+cm91 dGluZw0KPj4gPj4gPj50YWJsZQ0KPj4gPj4gPj4gPj5vZiBhDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4g SGFscGVybiB3cm90ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0 dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLA0KPj4gPj4gZnJvbQ0KPj4gPj4gPj4x DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2 aWNlIHBhdGhzLiBJIHdvdWxkDQo+PiBob3BlDQo+PiA+PiA+PnRoYXQNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVz IGlmDQo+PiA+PnRoZXkNCj4+ID4+ID4+ID4+Y2hvb3NlDQo+PiA+PiA+PiA+PiA+Pj50bw0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxh bmNpbmcgYW5kIGluDQo+PnN0ZWFkDQo+PiA+PiA+PiA+PiBwcm92aXNpb24NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24g Ny8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIDQo+PiB3cm90ZToNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0 aGVyZSB3aWxsIGJlIGZvciBhDQo+PjQNCj4+ID4+aG9wDQo+PiA+PiA+PiA+PiBzZXJ2aWNlDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVh Y2ggaG9wPw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddICpPbg0KPj4gPj4gQmVoYWxmDQo+PiA+PiA+PiBPZg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsDQo+ PiA+PjIwMTQNCj4+ID4+ID4+ID4+MzowMw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQ TSAqVG86KiBMdWN5IHlvbmcgKkNjOioNCj4+IGptaEBqb2VsaGFscGVybi5jb207DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZzsNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb20g KlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZQ0KPj4gPj4gPj4gQ2hhaW5zLA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMNCj4+ID4+dGhl DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBt aW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlDQo+PiB1c2VkDQo+PiA+PiB0 bw0KPj4gPj4gPj4gPj4gZGVyaXZlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBu ZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZA0KPj4gdHJhbnNwb3J0Lg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBf bm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQNCj4+dG8NCj4+ID4+ID4+c2lt cGx5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBh dGggKG9yIGdyYXBoKSB0aGF0DQo+PnBhY2tldHMNCj4+ID4+ID4+bXVzdA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0 aGUNCj4+ZXhhY3QNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhh dCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yDQo+Pm9uDQo+PiA+PiA+PnRoaXMNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50 ZWQuIFRoZSBwYXRoDQo+PiA+PiA+PiA+PiBpZGVudGlmaWVyDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0DQo+PiBs b29rdXANCj4+ID4+IGNhbg0KPj4gPj4gPj4gPj4gcmVzdWx0DQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQN Cj4+ID4+IG5leHQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVs DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25nQGh1YXdlaS5jb20NCj4+ID4+ID4+ID4+IDxtYWls dG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 cm90ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkN Cj4+IHVzZQ0KPj4gPj4gb2YNCj4+ID4+ID4+IHRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUNCj4+Zm9yd2FyZGluZw0K Pj4gPj4gPj4gPj5hY3Rpb25zLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10qT24NCj4+ID4+IEJlaGFsZg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+ ID4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+PiA+PiA+PiA+PiA+Pj4gPj4gSnVseQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFv bC5jb20NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+IDxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+O2ptaEBqb2VsaGFscGVybi5jb20NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTog W3NmY10NCj4+U2VydmljZQ0KPj4gPj4gPj4gPj5DaGFpbnMsDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2Vk IGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGENCj4+c2VydmljZQ0KPj4gPj5wYXRoDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0 IGlkZW50aWZpZXIgdG8NCj4+ID4+ID4+ZGVyaXZlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZl IHRoZSBmdWxsDQo+PiBrbm93bGVkZ2UNCj4+ID4+IG9mDQo+PiA+PiA+PiA+PiBldmVyeQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluDQo+ PiBpcw0KPj4gPj4gbm90DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlm aWVkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3Vz IGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJl bHkgb24gdGhlDQo+PnBpZWNlDQo+PiA+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluZm9ybWF0aW9uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0 IGlzIHRoZSBvbmUNCj4+ID4+ID4+IHJlcXVpcmVkDQo+PiA+PiA+PiA+PiB0bw0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdA0K Pj5pbmZvcm1hdGlvbg0KPj4gPj5pcw0KPj4gPj4gPj4gPj51c2VkIHRvDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ PiBhY3Rpb25zDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3Jp ZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhDQo+PiA+PnBhcnQNCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqQ0KPj4gOiptZXJjcmVkaSA5DQo+ PiA+PiA+PiA+PiBqdWlsbGV0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6 MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNd DQo+PlNlcnZpY2UNCj4+ID4+ID4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlv bmluZyB0aGUgZGlmZmVyZW5jZQ0KPj4gPj5iZXR3ZWVuDQo+PiA+PiA+PlNGDQo+PiA+PiA+PiA+ PiBDaGFpbg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0 aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdA0KPj5pdCdzDQo+PiA+PiA+PiA+ PmNsZWFyIHRvDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0 DQo+PmV2ZXJ5b25lDQo+PiA+PiA+PmFncmVlcw0KPj4gPj4gPj4gPj5vbg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhh dCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+PiA+PiA+PndoZXRoZXINCj4+ID4+ID4+ID4+aXQgaXMN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRv IHVsdGltYXRlbHkgc3BlY2lmeQ0KPj4gPj53aGF0DQo+PiA+PiA+PiA+PnRoZSBJRA0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IHNob3VsZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2Ug KHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMNCj4+ID4+ZHJhZnQNCj4+ID4+ID4+ ID4+c2ltcGx5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUg dGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nDQo+Pm90aGVyDQo+PiA+PiA+PmRyYWZ0cw0KPj4gPj4g Pj4gPj50bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5p c21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uDQo+PiA+PiBjaGFpbg0KPj4gPj4gPj4gb3INCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBv cg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxh dHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQNCj4+d291bGQNCj4+ID4+IGhhdmUNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMg YmUgc3VwcG9ydGVkIChvcg0KPj4gPj4gbWFrZQ0KPj4gPj4gPj4gPj4gb25lDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2 b2lkIHNvbWUNCj4+ID4+ID4+IHZlbmRvcnMNCj4+ID4+ID4+ID4+IG9ubHkNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRp bmcgU0ZDLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4N Cj4+ID4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+Pg0KPj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4+ LS0NCj4+ID4+ID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4g Pj4gPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ICpGcm9tOipq bWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb20NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2pt aEBqb2VsaGFscGVybi5jb20+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNm Y0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1h aWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KPj4gPj4gPj4gKlNlbnQ6KlR1ZXNk YXksDQo+PiA+PiA+PiA+PiBKdWx5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIw MTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywNCj4+ID4+YW5kDQo+PiA+ PiA+PkxvYWQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2 ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byANCj4+Y2xlYXJseQ0KPj4gPj4gPj5h bnN3ZXINCj4+ID4+ID4+ID4+YQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIg b2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZQ0KPj4gYWJvdXQNCj4+ID4+IHRoZQ0KPj4g Pj4gPj4gPj4gPj4+IHByb3Bvc2VkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdl ZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4+ID4+ID4+IHdvcmtp bmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBp bnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPj4gPj4gPj4gaW1wcm92ZQ0KPj4gPj4gPj4gPj4gdGhl DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdo byBoYXZlIG5vdA0KPj4gcGFydGljaXBhdGVkDQo+PiA+PiBpbg0KPj4gPj4gPj4gPj50aGUNCj4+ ID4+ID4+ID4+IFdHDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2ls bCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB3b3Jr aW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3 aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIA0KPj5teQ0KPj4gPj4gPj4g Pj5wZXJzb25hbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlm IHRoYXQgaGVscHMuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBp biANCj4+bWluZA0KPj4gPj50aGF0DQo+PiA+PiA+PiA+PndoYXQNCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIA0KPj5hcmNoaXRl Y3R1cmUuDQo+PiA+PldlDQo+PiA+PiA+PmFyZQ0KPj4gPj4gPj4gPj4gbm90DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUg Zm9yIHRoZQ0KPj4gPj5lbnRpcmUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRp b24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQNCj4+ID4+IGVuY29tcGFzcw0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBv bGljeSBmdW5jdGlvbnMsDQo+PiA+PiA+PnZpcnR1YWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkNCj4+IG90aGVyDQo+ PiA+PiA+PiA+PiBhc3BlY3RzLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mg d2hpY2ggDQo+PmNsZWFybHkNCj4+ID4+IG5lZWQNCj4+ID4+ID4+IHRvDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJl IA0KPj5kZWFsdA0KPj4gPj53aXRoDQo+PiA+PiA+PiA+PmFib3ZlDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0 aW9uaW5nLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3Rs eSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSANCj4+YXJlDQo+PiA+PiA+PiBkb2luZy4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4g b3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSANCj4+cGF0aCwNCj4+ID4+ ID4+YXMgSQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBu ZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlDQo+PiA+PmFyZSBhdA0K Pj4gPj4gPj4gPj5sZWFzdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZm ZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiANCj4+YW5kDQo+PiA+PiA+PndpbGwN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWlu aW5nLiBUaGVyZSBwcm9iYWJseQ0KPj4gPj5hcmUNCj4+ID4+ID4+ID4+bW9yZS4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8g cGVybWl0IA0KPj5hbGwgb2YNCj4+ID4+ID4+ID4+dGhlc2UsDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHBy b3ZpZGVkIHRvIHRoZQ0KPj4gPj5lbmQNCj4+ID4+ID4+ID4+dXNlci4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVz ZXINCj4+ID4+ID4+cGFja2V0cywNCj4+ID4+ID4+ID4+YW5kDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFy a3MNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBj aG9vc2UgYW4gZW5kIHVzZXIgDQo+PnNlcnZpY2UNCj4+ID4+ID4+ID4+aW5zdGFuY2UNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlz IGlzIGFuIA0KPj5pbXBvcnRhbnQNCj4+ID4+ID4+ID4+c2VydmljZQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZQ0K Pj4gPj5jaGFpbmluZy4NCj4+ID4+ID4+ID4+SXQncw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cNCj4+IHNlcnZpY2UN Cj4+ID4+ID4+ID4+IGNoYWluaW5nIGlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRv bmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KPj4gPj4gPj4gPj5hcmNo dGllY3R1cmUuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICBGcm9tIGFuIGFyY2hpdGVj dHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIA0KPj5zaW1wbHkNCj4+ID4+YQ0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rp b24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZw0KPj4gcGFja2V0Lg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVy ZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgDQo+Pm9uZQ0KPj4gPj4gPj5j YW4NCj4+ID4+ID4+ID4+aGF2ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSANCj4+c2luZ2xl DQo+PiA+PiA+PnBvaW50DQo+PiA+PiA+PiA+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNvbnRhY3QNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFs bHkNCj4+ID4+ZGVsaXZlcmVkDQo+PiA+PiA+PiA+PmJ5IGENCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwg b3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IA0KPj5pbmNsdWRpbmcNCj4+ID4+ID4+b25l IG9yDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMg KGZvciBleGFtcGxlIHVzaW5nDQo+PiA+PlZSUlAtbGlrZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksDQo+PiB0 aGlzDQo+PiA+PmlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+PiA+PiA+PiA+Pm1lY2hhbmlzbXMuDQo+ PiA+PiA+PiA+PiBJdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhh dCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgDQo+PmNvbnRyb2wNCj4+ID4+ID4+ID4+bWVjaGFu aXNtcywNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25z aWJsZSBmb3Igc2NhbGUtaW4sDQo+PiA+PnNjYWxlLW91dCwNCj4+ID4+ID4+YW5kDQo+PiA+PiA+ PiA+PnZtDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBh cmNoaXRlY3R1cmFsIGltcGFjdCBvZg0KPj4gPj4gPj5wZXJtaXR0aW5nDQo+PiA+PiA+PiA+PnRo aXMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQg dG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4gPj4gPj4gPj50ZXJtaW5vbG9neQ0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUg cHJvaGliaXRpbmcgaXQuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRv bmUgYnkNCj4+ID4+ID4+c2VsZWN0aW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBh Y2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCANCj4+ZGlyZWN0DQo+PiA+ PiA+PiA+PnRyYWZmaWMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50 IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8NCj4+IHJlcXVpcmUNCj4+ID4+ID4+IHRoYXQN Cj4+ID4+ID4+ID4+YQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNl IGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSANCj4+cGxhY2UNCj4+ID4+aW4NCj4+ID4+ID4+ dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNv dXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPj4gPj4gPj5jb21iaW5lZC4gSQ0KPj4g Pj4gPj4gPj4gdGVuZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo ZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIA0KPj5zZXJ2aWNlDQo+PiA+ PiA+PiA+PmNoYWluaW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xl IHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UNCj4+ID4+Y2x1c3Rlcg0KPj4gPj4gPj5p cw0KPj4gPj4gPj4gPj5hDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4g QnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyDQo+PiBvbmUuDQo+PiA+PiA+PiBUaHVz LA0KPj4gPj4gPj4gPj4gdGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9m IHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0 cmFmZmljIHRvIA0KPj5kaWZmZXJlbnQNCj4+ID4+ID4+ID4+c2luZ3VsYXINCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZl cmVudA0KPj4gPj5wbGFjZXMNCj4+ID4+ID4+aW4NCj4+ID4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBk byBJIG1lYW4gd2hlbiBJIHRhbGsNCj4+ID4+IGFib3V0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiANCj4+ aXMNCj4+ID4+YQ0KPj4gPj4gPj4gPj4gc2VxdWVuY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIA0KPj5zdWJzZXQg b2YNCj4+ID4+ID4+ID4+cGFja2V0cy4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQg aXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZg0KPj4gPj4gPj50cmFm ZmljDQo+PiA+PiA+PiA+PmlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdldCBE UEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KPj4gPj4gPj5maXJld2FsbA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMg dG8gZ28gZGlyZWN0bHkgdG8gDQo+PnRoZQ0KPj4gPj4gPj5jYWNoZQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IHdpdGhvdXQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcg YW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3Jt YXRpb24gdG8gZGlyZWN0IHRoZQ0KPj4gPj4gPj5wYWNrZXRzLg0KPj4gPj4gPj4gQQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwg YSBzZXF1ZW5jZSANCj4+b2YNCj4+ID4+ID4+ID4+bG9jYXRpb25zDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSANCj4+ c2luZ3VsYXINCj4+ID4+b3INCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVk IHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLg0KPj4gPj5UaGV5DQo+PiA+PiA+ PiA+Pm1heSBiZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAg YWRkcmVzcy4gVGhleSBtYXkgYmUNCj4+IGFkZHJlc3NlZCBhcw0KPj4gPj4gPj4gcG9ydHMNCj4+ ID4+ID4+ID4+IG9uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhlcmUg YXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ID4+ID4+ID4+bG9jYXRpb25zDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBj aGFpbmluZw0KPj4gPj4gaW5mcmFzdHJ1Y3R1cmUNCj4+ID4+ID4+IGFuZA0KPj4gPj4gPj4gPj4g dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9tIHRo ZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSANCj4+U0ZDDQo+PiA+PiA+Pmdyb3Vw LA0KPj4gPj4gPj4gPj4gd2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8g YmUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBo aWdoIGxldmVsIGFic3RyYWN0aW9uLA0KPj4gPj50aGUNCj4+ID4+ID4+ID4+c2VydmljZQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJk aW5nLiBBbmQgd2UNCj4+IG5lZWQNCj4+ID4+dG8NCj4+ID4+ID4+IHRhbGsNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxs IHRha2UgDQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3 b3JrLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUNCj4+IHdo b2xlDQo+PiA+PiA+PiBwYXRoDQo+PiA+PiA+PiA+PiBtYXkNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlDQo+ PiA+PmRlYWxzDQo+PiA+PiA+PiA+PndpdGgNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIA0KPj5pdGVtDQo+PiA+ PigyKQ0KPj4gPj4gPj5vbg0KPj4gPj4gPj4gPj5sb2FkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+ID4+ ID4+YmVoYXZpb3JzDQo+PiA+PiA+PiA+PiB3aGljaA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIA0KPj5tZWNoYW5pc21z DQo+PiA+Pihpbg0KPj4gPj4gPj4gPj5tdWNoDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcw0KPj4gPj5sYXJnZWx5 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdl ZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gPj4gPj4gcHJvdmlzaW9uDQo+PiA+PiA+PiA+PiB3ZQ0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gdGhhdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9u IGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuDQo+PiA+PiA+PiA+PiBuZWNlc3NhcnkuDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBh IG5ldyBjaGFpbi4gQmFzZWQNCj4+IG9uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu Zm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24NCj4+ID4+ID4+cG9p bnQuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSANCj4+YWZ0 ZXIuDQo+PiA+PiA+PklmIGl0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMsIGFu ZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlDQo+PiA+PndvcmtpbmcNCj4+ID4+ ID4+ID4+IGdyb3VwLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJl IG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlDQo+PiA+PiBuZWVkZWQNCj4+ID4+ID4+IHRv DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2lu ZyBncm91cCBkaXNhZ3JlZSANCj4+d2l0aA0KPj4gPj50aGUNCj4+ID4+ID4+ID4+IGludGVudCwN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1 c3QgdG8gbWF0Y2ggdGhlDQo+PiA+PndvcmtpbmcNCj4+ID4+ID4+ID4+Z3JvdXANCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFy LCBJIGFtIG5vdA0KPj4gPj5zdXJlDQo+PiA+PiA+PiA+PndoYXQgdG8NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4g c2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+PiA+PiA+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+PiA+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ DQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPj4gPj4gc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4g Pj4gc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4gPj4gPj4+ID4+IGxpc3QN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+PiA+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNm Yw0KPj4gPj4gPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnDQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+IG1haWxpbmcNCj4+ID4+ID4+ID4+ ID4+PiA+PiBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgDQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+IG1haWxp bmcNCj4+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNA aWV0Zi5vcmcgDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID5z ZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4gPj4gPj4+ID4+IHNmY0BpZXRm Lm9yZw0KPj4gPj4gPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4gPj4+IHNmYyBt YWlsaW5nIGxpc3QNCj4+ID4+ID4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4g Pg0KPj4gPj4gPj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+PiA+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4gPj4gPnNmY0Bp ZXRmLm9yZw0KPj4gPj4gPj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+PiA+PiA+DQo+PiA+DQo+DQoNCg== From nobody Fri Jul 11 09: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 341E81B2B4D for ; Fri, 11 Jul 2014 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOe5eOM8x1Bb for ; Fri, 11 Jul 2014 09:44:30 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBB91A0A9E for ; Fri, 11 Jul 2014 09:44:29 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id d6410c35.2b991204f940.4707970.00-2498.13055030.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:44:29 +0000 (UTC) X-MXL-Hash: 53c0146d46db5cc1-e31a6ed2fcddc8772bf3cb74461c4a84917c5485 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 96410c35.0.4707901.00-2106.13054851.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:44:26 +0000 (UTC) X-MXL-Hash: 53c0146a1035d801-19493f12be16b4ab044af54a413934d69c26ccac Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGiO4o009286; Fri, 11 Jul 2014 12:44:25 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGiH1P009169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:44:19 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:43:59 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:43:58 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mikebianc@aol.com" , "mohamed.boucadair@orange.com" , "jmh@joelhalpern.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA///Q1oCAAEKp8P//yI4AgAAGqICAAAK5AIAAPrEA Date: Fri, 11 Jul 2014 16:43:58 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AFA0@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.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: [135.70.229.13] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AFA0MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=AUd_NHdVA] X-AnalysisOut: [AAA:8 a=3oc9M9_CAAAA:8 a=z9tbli-vAAAA:8 a=ABeY7kuGAAAA:8 a] X-AnalysisOut: [=qN95wPeSAAAA:8 a=48vgC7mUAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH8] X-AnalysisOut: [6SAAAA:8 a=2iG7CHfPvsQhNgXOEDQA:9 a=QEXdDO2ut3YA:10 a=JfD0] X-AnalysisOut: [Fch1gWkA:10 a=U8Ie8EnqySEA:10 a=oAXR_kdF8uMA:10 a=chC_agHS] X-AnalysisOut: [u74A:10 a=paC5pjApGzsA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA] X-AnalysisOut: [:10 a=CW8-n7UcL24ytT_W:21 a=dJ9wK53_hc4jfRg8:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:1] X-AnalysisOut: [0 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=ythFWtYqczgCejiM:2] X-AnalysisOut: [1 a=djj3HLdMdWaDtMxb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mumcCe4GwWlLdUBIz9ho2lKXJc4 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:44:38 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AFA0MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIE1pa2Ugd2FzIG1ha2luZyBmdW4gb2YgeW91ciBkZWZpbml0aW9uIG9mIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVy4oCmOg0K4oCcYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciIgdG8g cmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0g c3BlY2lmeSBzcGVjaWZpYyBpbnN0YW5jZXMiLg0KDQoNCkZyb206IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDEx LCAyMDE0IDEyOjI4IFBNDQpUbzogbWlrZWJpYW5jQGFvbC5jb207IE5BUElFUkFMQSwgTUFSSUEg SDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgUm9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KWW91ciBk ZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGlu ZyBwYXRoIHRocm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciBob3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZSBjaGFpbiBk YXRhIHN0cnVjdHVyZSBhbmQgdGhhdCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3Rh bmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMgYXJlIGF2 YWlsYWJsZSBhbmQgd2hhdGV2ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluIHBs YXkuIFdoZW4gaW5zdGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3b3Jr IHlvdSBtYXkgb3IgbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5 IHdoaWNoIG5leHQtaG9wcyBtYXkgYmUgdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1ob3Agd291 bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNlcnZpY2Ug Y2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wgLyBtZWNo YW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQoNCkZyb206ICJt aWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJpYW5jQGFv bC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4NCkRhdGU6IEZyaWRheSwgSnVseSAxMSwg MjAxNCBhdCAxMjoxOCBQTQ0KVG86IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFA YXR0LmNvbT4iIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgIm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pj4sICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPiIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PiwgInNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCg0KDQo+IEkg ZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkNCj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwg YW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQo+IGFzc2lnbiBhIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEt PlMyLT5TMw0KPiBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KDQpCeSBkZWZp bml0aW9uLCBJIHVuZGVyc3Rvb2QgYSAic2VydmljZSBwYXRoIiB0byBiZSBhbiBvcmRlcmVkIGxp c3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiAgSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91 IHVzZSBhICJzZXJ2aWNlIHBhdGggaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpj aGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0gc3BlY2lmeSBzcGVjaWZpYyBpbnN0 YW5jZXMiLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqZ3Vp Y2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48amd1aWNoYXJAY2lzY28u Y29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEgSDxt bjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4s Sm9lbCBNLiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PixSb24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRv OlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJp ZGF5LCBKdWx5IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KTWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhpcyB3 YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQph IGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdo ZW4geW91IGRlZmluZSBhDQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1p Z2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQtaG9w cyB0aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCkhv d2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1cmFs IHN0YW5kcG9pbnQgKEkNCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZ dCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhlbiBw dXNoIHRoYXQgaW5mb3JtYXRpb24gaW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxs IGhhdmUgYQ0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQg bWFwcGluZyB3b3VsZCBjb250YWluIHRoZQ0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBv ZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4dC1o b3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50cmFs aXplZA0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0g ZHluYW1pY2FsbHkgdGhyb3VnaA0Kc29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4g U28sIGdpdmVuIHRoaXMgaXQgaXMgbm90IGNvcnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2aWNl IHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkNCmFs dGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVj b21tZW5kZWQpIHRvIGRvDQpzby4NCg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1 bGx5IG1ha2UgdGhpcyBjbGVhcjoNCg0KSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRv IGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMgc2F5 IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3Bl Y2lmeQ0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJp bmF0aW9uIHRoZXJlb2YpLiBJDQphc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwx MDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1c2gg dGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJl DQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdo ZW4gdHJhZmZpYyBhcnJpdmVzDQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhl IFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5kIHRo YXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQplbmNh cHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4g TGV04oCZcyBzYXkgd2UNCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cg aGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAg dG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6MjYg QU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0 dC5jb20+PiB3cm90ZToNCg0KPkppbSwNCj4NCj5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRo ZSBkZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4ic2VydmljZSBwYXRoIGlk ZW50aWZpZXIiPw0KPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNl cyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoDQo+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5n KSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPm5leHQtaG9wIFNG RiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1hcmlhDQo+DQo+ DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogSmltIEd1aWNoYXJk IChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+OyBKb2VsIE0uDQo+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBk b27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IHByZXZl bnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBh IHNlcnZpY2UNCj4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+Pg0K Pj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0 LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4+DQo+PiA+RGl0dG8uDQo+PiA+ DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4N Cj4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+ID4+IFNlbnQ6 IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4gPj4gVG86IEppbSBHdWljaGFyZCAo amd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+PiA+ PiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gU3ViamVj dDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ PiA+Pg0KPj4gPj4gUmUtLA0KPj4gPj4NCj4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0 IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPj5kcmFmdC4NCj4+ID4+DQo+ PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBo aW50IHRoYXQgdGhlIGZ1bGwNCj4+ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+IG1vZGVsIGlzIG5vdCBh bGxvd2VkLg0KPj4gPj4NCj4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGlj YXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZg0KPj4gPj5zaG91bGQgYmUNCj4+ID4+ IHByb3ZpZGVkIGluc3RlYWQuDQo+PiA+Pg0KPj4gPj4gQ2hlZXJzLA0KPj4gPj4gTWVkDQo+PiA+ Pg0KPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4gPkRlIDogc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+ PiA+PiA+KGpndWljaGFyKQ0KPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIw MTQgMTY6MTgNCj4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJu OyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5P YmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4gPj4gPg0KPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNp ZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ug d2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+PiA+ PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVy IHBvaW50IHRvIGENCj4+ID4+bG9va3VwDQo+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8g cmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdA0KPj5zdXJlDQo+PiA+Pmhv dw0KPj4gPj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4NCj4+ID4+ ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5j b208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4gPj5B YnNvbHV0ZWx5Lg0KPj4gPj4gPj4NCj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gU2Vu dDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVSQUxB LCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gVGhl biBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0 byBtZQ0KPj4gPj50aGF0IGlmDQo+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEg ZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0KPj4g Pj4gPj4+Zm9yDQo+PiA+PiA+Pj4gYSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdp dGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UNCj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+PiBz dXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9n aWMgdG8NCj4+ID4+cmVhY2gNCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBm b3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ID4+ ID4+Pg0KPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgi IDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gPj4gd3JvdGU6DQo+ PiA+PiA+Pj4NCj4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBi ZSBpbnN0YW50aWF0ZWQgb25seSBpbg0KPj5yZWxldmFudA0KPj4gPj4gPj4+U0ZGcw0KPj4gPj4g Pj4+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ID4+ PiA+PihqZ3VpY2hhcikNCj4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQg OToyNyBBTQ0KPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4g Pj4+ID4+DQo+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0 aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29kDQo+PnRoZQ0KPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+ ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBv ZiBldmVyeSBzaW5nbGUNCj4+U0YNCj4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4+ID4+dGhlDQo+ PiA+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVy ZSBpcyBubyB3YXkgdG8NCj4+a25vdw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ID4+ ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQg YW55IGdpdmVuDQo+PnBvaW50DQo+PiA+PmluDQo+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4+ID4+ DQo+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+IHdy b3RlOg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhp cywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4+d2l0aA0KPj4gPj50aGUNCj4+ ID4+ID4+PiA+PnlvdXINCj4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0 LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4+ID4+ID4+PnVuZGVyc3RhbmQNCj4+ ID4+ID4+PiA+PiA+aXQuKQ0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+VGhlIHByb3Bv c2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+PiA+ Pm5leHQNCj4+ID4+ID4+PiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5v dCB0aGUgb25lIGl0IGRlbGl2ZXJzDQo+PnRvKSwNCj4+ID4+aW4NCj4+ID4+ID4+PmV2ZXJ5DQo+ PiA+PiA+Pj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+PiA+ Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdp dGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PmV2ZXJ5 DQo+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRp dmUgYW5kIHN0YXRlZnVsIGxvYWQNCj4+ID4+ID4+PmJhbGFuY2VyLg0KPj4gPj4gPj4+ID4+ID5J IGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9y DQo+PiA+PnN0YXRlZnVsLg0KPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1 cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsDQo+PiA+PmZsb3cNCj4+ID4+ID4+ PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBi ZSBhbg0KPj4gPj5hY2NlcHRhYmxlDQo+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiA+PiA+ Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5Zb3VycywNCj4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gPj4g Pj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFs cGVybiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMg dGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMNCj4+d29yaw0KPj4gPj4gPj4+ID4+c2Vuc2li bHkNCj4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJ IGV4cGVjdCB0aGF0IHRoZQ0KPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBh bmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPj53aWxsDQo+PiA+ PmJlDQo+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0 IHRoZSBzZXJ2aWNlIGNoYWlucw0KPj50byBiZQ0KPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+PiA+ PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBh bmQgZW5hYmxlDQo+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+IGZyb20g dGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4+ID4+ ZHJpdmUuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRv IG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4+ID4+ZHJpdmVuDQo+ PiA+PiA+Pj5ieQ0KPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVz Y3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzDQo+PiA+PmhhcmRlcg0KPj4gPj4gPj4+dG8NCj4+ ID4+ID4+PiA+PnNlZQ0KPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBp dCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+PiA+PiA+Pj4gPj4gZHluYW1pY2l0 eQ0KPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4+ID4+ ID4+DQo+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNw ZWN0aXZlIEkgZGVzY3JpYmVkIGlzDQo+PiA+Pm91dHNpZGUNCj4+ID4+ID4+Pm9mDQo+PiA+PiA+ Pj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQg aXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4+ID4+dGFza2VkIHRvDQo+PiA+PiA+Pj4gPj5hZ3Jl ZQ0KPj4gPj4gPj4+ID4+ID4+b24uDQo+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0g dGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhDQo+PmNlcnRhaW4NCj4+ID4+ID4+ PndheS4NCj4+ID4+ID4+PiA+Pml0DQo+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3Bl Y3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ ID4+PiA+PiA+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4N Cj4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+ PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQg c2VydmljZSBpbnN0YW5jZXMNCj4+ID4+IHRoYXQNCj4+ID4+ID4+PiA+Pm5lZWRzDQo+PiA+PiA+ Pj4gPj4gPj4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5k IG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ID4+YWNyb3NzDQo+PiA+PiA+Pj5kYXRh DQo+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29w ZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+IGNvbXBsZXgNCj4+ID4+ID4+PiA+ PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1z IGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1 cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1 cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PmR5bmFtaWMN Cj4+ID4+ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNl bnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPj53aGljaA0KPj4gPj5hcmUNCj4+ ID4+ID4+PiA+PmJpZ2dlcg0KPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVl biBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+DQo+ PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBj b21wbGljYXRlZCwgdGhhdA0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+Pj5nb29kDQo+PiA+PiA+Pj4g Pj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+Pj4gPj4gPj4+ DQo+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBl cm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ID4+ID4+PiBUbzog Um9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+SWFuDQo+PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+PiA+ PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+ IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PkJh bGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFy Y2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxkDQo+PnByZWZlcg0KPj4gPj53 ZQ0KPj4gPj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0 aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gPj5pbXBsZW1lbnRhdGlv bnMuDQo+PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0 IG9uIHRoZSBjb250cm9sDQo+PiA+PnJlcXVpcmVtZW50cw0KPj4gPj4gPj4+YW5kDQo+PiA+PiA+ Pj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ID4+ ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9y bWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiBuZWVk cw0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRl ZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gYWNyb3NzDQo+PiA+PiA+Pj5k YXRhDQo+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNj b3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj5jb21wbGV4DQo+PiA+PiA+Pj4g Pj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1z IGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVy ZSB0byByZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBZb3VycywN Cj4+ID4+ID4+PiA+PiA+Pj4gSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+ PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4gPj4+ ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0aGUgZW5kIHRvIGVu ZA0KPj5zZWxlY3Rpb24NCj4+ID4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGlu c3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZQ0KPj4gPj4gPj4+ID4+ Y2xhc3NpZmllcikNCj4+ID4+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkg dGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseQ0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PlNG RnMpPw0KPj4gPj4gPj4+ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQg dG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4+QW5kDQo+PiA+PiA+Pj5zdXJlbHksDQo+PiA+PiA+Pj4g Pj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQg dG8NCj4+ID4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+PiA+PiA+Pj4gPj4gPj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1 dGVkIGFwcHJvYWNoIGV2ZW4NCj4+IHRob3VnaA0KPj4gPj4gYQ0KPj4gPj4gPj4+ID4+ID4+Pj4g Z3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMNCj4+ bG9jYWwNCj4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBp cyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMuDQo+PiA+PlRo aXMNCj4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRv LWVuZCBwYXRoIGlkIGF0IGFsbC4NCj4+ID4+TXkNCj4+ID4+ID4+PiA+PiA+Pj4+IHJhdGlvbmFs ZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkgZHJpdmVuDQo+PmJ5DQo+ PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+ID4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0 aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICAgV2l0aCBhDQo+Pmdsb2JhbA0KPj4gPj4gPj4+ cGF0aA0KPj4gPj4gPj4+ID4+aWQNCj4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRl ciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvDQo+PiA+PmFsdGVyDQo+PiA+ PiA+Pj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNo IGFuZCBldmVyeSBhZmZlY3RlZA0KPj5lbmQtdG8tZW5kDQo+PiA+PiA+Pj5wYXRoLg0KPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFJvbg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g RnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QN Cj4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb20+XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwNCj4+MjAx NA0KPj4gPj4gNjoxNQ0KPj4gPj4gPj4+IFBNDQo+PiA+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJp YW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgSS5TbWl0aEBGNS5jb208bWFp bHRvOkkuU21pdGhARjUuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiBTdWJqZWN0Og0KPj4gPj4gUmU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2Yg U0YxIG5lZWRpbmcNCj4+dG8NCj4+ID4+ID4+PiA+PmluZmx1ZW5jZQ0KPj4gPj4gPj4+ID4+ID4+ Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhl DQo+PmV4aXQNCj4+ID4+ZnJvbQ0KPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPj4gPj4gPj4+ID4+ ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUg ZGlmZmVyZW50IGZ1bmN0aW9ucw0KPj4gPj5sb2dpY2FsbHkNCj4+ID4+ID4+PiA+PiA+Pj4+IHNl cGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5DQo+ PiA+PiBjaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBjb21wb3NlIHRoZW0g Zm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE9u IDcvMTAvMTQsIDY6MTAgUE0sIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9s LmNvbT4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4g dGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnkNCj4+ID4+c29ydA0KPj4gPj4gPj4+b2YN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGlj YXRlIHRoYXQgdGhlIGVudGlyZQ0KPj4gPj5wYXRoDQo+PiA+PiA+Pj4oYWxsDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVs aWV2ZQ0KPj50aGlzDQo+PiA+PiA+Pj5tZWFucw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBh dCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcg0KPj5jaG9vc2VzIGENCj4+ ID4+U0YNCj4+ID4+ID4+PiA+PkNoYWluDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBv ciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueSBjYXNlLA0KPj4gPj50aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5 bmFtaWMgU0ZQIHdoZXJlDQo+PiA+PiBTRkkobikNCj4+ID4+ID4+PiBpcw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZSBk cmFmdCwNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNv bnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQIGFzDQo+PiA+PiA+Pj4gb3Bwb3NlZA0K Pj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9y d2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YNCj4+ID4+dGhlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRvIHRoZSBu ZXR3b3JrIGl0IGlzDQo+PiA+Pm5lY2Vzc2FyeQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1 c2VkLA0KPj4gPj5hbmQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNl IHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzDQo+PiA+Pm5ldHdvcmsNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3Vs dHMgaW4gdGhlDQo+PiA+PiA+Pj5jcmVhdGlvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBhIFNl cnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3INCj4+ID4+Zm9yd2FyZGlu Zw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIg d29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBv ZiB0aGUgZGVmaW5lZCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yDQo+ PiA+Pm5vbi1pbml0aWFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3 ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gcmVj bGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGENCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBh IHNlcnZpY2UNCj4+ID4+ZnVuY3Rpb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3NpZmlj YXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3DQo+PiA+PlNGUCwgYW4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBv ciBib3RoLiBUaGlzIGlzDQo+PiA+PnJlZmVycmVkDQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+Pg0KPj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+ Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ ID4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKkZy b206ICpJLlNtaXRoQEY1LmNvbTxtYWlsdG86KkkuU21pdGhARjUuY29tPjxJLlNtaXRoQEY1LmNv bTxtYWlsdG86SS5TbWl0aEBGNS5jb20+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ICpUbzogKkpvZWwg SGFscGVybg0KPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4+LEpvZWwNCj4+ID4+IE0uDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixodWFuZ0BzY2UuY2Fy bGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVhbmdAc2NlLg0KPG1haWx0 bzpodWFuZ0BzY2UuJTBiPj4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+ PmNhPixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBK dWx5IDEwLCAyMDE0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gPj5CYWxhbmNlcnMNCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdy ZWVpbmcuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBJZiB0aGUgcG9z c2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQNCj4+dGhhdCBpcw0KPj4g Pj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkg d29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzDQo+PiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4+ID4+ ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0dXJlIGJ1 cmRlbmVkIHdpdGgNCj4+IHRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNv bWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZg0KPj4gPj5hc3BpcmF0aW9uDQo+PiA+PiB0 bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBs aWZlc3BhbiBvZiB0aGUNCj4+ID4+YXJjaGl0ZWN0dXJlDQo+PiA+PiA+Pj4tDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5n IHRoYXQgYW4NCj4+ID4+ID4+PmFyYml0cmFyeQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IG51bWJlciBp cyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNuJ3QNCj4+ID4+ID4+ PiA+PmludGVudGlvbmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVl bmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3RpbmcNCj4+ID4+aW1wYWN0cw0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3Rp Y2l0eSwNCj4+ID4+YWRkcmVzcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5k cyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj5TZW50Og0KPj4g Pj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBT bWl0aDsgSm9lbCBNLg0KPj4gPj4gSGFscGVybjsNCj4+ID4+ID4+PiA+PiA+Pj4+PiBodWFuZ0Bz Y2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0OiBSZTogW3NmY10NCj4+ID4+U2VydmljZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlv dSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzDQo+PiA+PnJlZ2FyZC4NCj4+ID4+ID4+ PkkNCj4+ID4+ID4+PiA+PmFtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhl IHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uDQo+PiA+PnByb2hpYml0DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2Jq ZWN0aW5nIHRvDQo+PiA+Pkh1YW5nJ3MNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkaW5nIG9mIG15 IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmUNCj4+ID4+IHJlcXVpcmVk DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwg SSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0DQo+PnN1Y2gNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0 aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Igbm90IGRlcGVuZHMgdXBvbg0K Pj4gPj4gbWFueQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bw0KPj50aGluaw0KPj4gPj50aGF0DQo+PiA+PiA+Pj4g Pj50aGV5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNp IGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvDQo+PiA+Pmtub3cNCj4+ID4+ID4+Pndo YXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGgg d3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmlj ZXMgdGhhdCBtYW5hZ2UgdGVucyBvZg0KPj4gPj4gPj4+bWlsbGlvbnMNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNj ZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZW52aXJvbm1l bnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbg0KPj50aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2Yg dG9tb3Jyb3cgeW91DQo+PiBhcmUNCj4+ID4+IG9ubHkNCj4+ID4+ID4+PiA+PiBnb2luZw0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3 aXRoIGVxdWFsbHkNCj4+c21hbGwNCj4+ID4+ID4+PiBudW1iZXJzDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIg bmVlZCBtb3JlDQo+PiB0aGFuDQo+PiA+PiA+Pj4gNjRLIg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBm b3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb21mb3J0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2Zj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxm IG9mIEpvZWwgTS4gSGFscGVybg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzoNCj4+ID4+ID4+Pmh1YW5nQHNj ZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+PmFuZA0KPj4gPj4gPj4+TG9hZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95 IHRoZQ0KPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxh cmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4+dGhlaXINCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJl IHN1Y2ggYWJzdXJkDQo+PiB1c2UNCj4+ID4+IG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlcnZp Y2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJj aGl0ZWN0dXJlDQo+PmRvZXMNCj4+ID4+ID4+PnBlcm1pdA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBz dWNoIGFidXNlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBQbGVh c2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVjdHVyZQ0KPj4gcGVybWl0 cw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBk ZWlzcmVkIG9yIHJlcXVpcmVkIGJ5DQo+PiA+PnRoZQ0KPj4gPj4gPj4+d29yay4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywg aXQgd2lsbA0KPj5tZWFuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBU aGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nDQo+PnRhYmxlDQo+PiA+Pm9mIGENCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2Yg ZGVwbG95bWVudHMsIGZyb20NCj4+MQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0 aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlDQo+PnRoYXQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVz IGlmIHRoZXkNCj4+ID4+Y2hvb3NlDQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkDQo+PiA+ PiBwcm92aXNpb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9l bA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8x NCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBQYXVsLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4+ ID4+IHNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5j ZXMgYXQgZWFjaCBob3A/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IE1hcmlhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0K Pj4gT2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoq IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+PiA+PjM6MDMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20+Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBt aWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpTdWJqZWN0OiogUmU6 IFtzZmNdIFNlcnZpY2UNCj4+IENoYWlucywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRo ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nLiBJwrlkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gbWFrZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUg cGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+PiA+PiBkZXJpdmUNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9y dC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMg X25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvDQo+PnNpbXBseQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkg dGhhdCBwYWNrZXRzDQo+Pm11c3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5 IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbg0KPj50 aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxl bWVudGVkLiBUaGUgcGF0aA0KPj4gPj4gaWRlbnRpZmllcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuDQo+ PiA+PiByZXN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1 YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhv cChzKS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1 bA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwg MTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g PGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4NCj4+ID4+ IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNv bSUzZT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRh dGUgb25seSB1c2Ugb2YNCj4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBh dGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZw0KPj4gPj5hY3Rpb25zLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxmDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOk9mKm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+PiAqU2VudDoqVGh1cnNkYXksDQo+PiA+PiA+ Pj4gPj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoq bWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOiptaWtlYmlhbmNAYW9sLmNvbT4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5v cmc8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1YmplY3Q6KlJlOiBbc2ZjXSBT ZXJ2aWNlDQo+PiA+PkNoYWlucywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBSZS0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRl bnRpZmllciB0bw0KPj5kZXJpdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBh Y3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBS ZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mDQo+PiA+ PiBldmVyeQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlz IG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmllZA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTRkMgZm9yd2Fy ZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0 aGUgb25lDQo+PiByZXF1aXJlZA0KPj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3Ry dWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXMNCj4+ID4+dXNl ZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJkaW5nDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gYWN0aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9y aWVudGVkIGRpc2N1c3Npb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IENoZWVycywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gTWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOmRlKm1pa2ViaWFu Y0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+ID4+IGp1aWxsZXQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzoqam1o QGpvZWxoYWxwZXJuLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmc8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7 c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+PlNGDQo+PiA+PiBDaGFpbg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdz DQo+PiA+PmNsZWFyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5 b25lDQo+PmFncmVlcw0KPj4gPj5vbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJt cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUs IHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+PndoZXRoZXINCj4+ID4+ aXQgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRv IHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0DQo+PiA+PnRoZSBJRA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNob3VsZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlm IHRoaXMgZHJhZnQNCj4+ID4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMg dG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+PmRyYWZ0cw0KPj4gPj50 bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3 YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+PiBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRo IGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcGF0aCB0bw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5l Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUg bGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAo b3IgbWFrZQ0KPj4gPj4gb25lDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0 aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+IHZlbmRvcnMNCj4+ID4+IG9ubHkN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1 cHBvcnRpbmcgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4N Cj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+ Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29t PjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbT48bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhh bHBlcm4uY29tJTNlPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmc8 bWFpbHRvOipzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9y Zz48bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUzZT4+DQo+PiAqU2VudDoqVHVl c2RheSwNCj4+ID4+IEp1bHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVj dDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQNCj4+TG9hZA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFy bHkNCj4+YW5zd2VyDQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNv bW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlDQo+PiA+PiA+Pj4gcHJvcG9zZWQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1p bmcgd2UgY2FuIGdldA0KPj4gd29ya2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBh Z3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvDQo+PiBpbXByb3ZlDQo+PiA+ PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hv IGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbg0KPj4gPj50aGUNCj4+ID4+IFdHDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGlu dGVuZHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1 dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+PiA+PnBlcnNv bmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyBy ZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdA0KPj4gPj53aGF0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBh cmNoaXRlY3R1cmUuIFdlDQo+PmFyZQ0KPj4gPj4gbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQg d291bGQgZW5jb21wYXNzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMg Y29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCj4+dmlydHVhbA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlcg0KPj4g Pj4gYXNwZWN0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZA0K Pj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0s IGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aA0KPj4gPj5hYm92ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdv cmsgd2UgYXJlDQo+PiBkb2luZy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBw YXRoLA0KPj5hcyBJDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHVuZGVyc3RhbmQNCj4+ID4+ID4+ PiA+PiA+Pj4+PiB0aGVtLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3Qg ZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0DQo+PiA+PmxlYXN0DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcg Y2FuIGFuZA0KPj53aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2Vy dmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlDQo+PiA+Pm1vcmUuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBh bGwgb2YNCj4+ID4+dGhlc2UsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFu ZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2Vk DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBz ZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQNCj4+ID4+dXNlci4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXINCj4+cGFj a2V0cywNCj4+ID4+YW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9y DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwg b3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZQ0KPj4gPj5pbnN0YW5j ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRo aXMgaXMgYW4gaW1wb3J0YW50DQo+PiA+PnNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuDQo+PiA+ Pkl0J3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJl bWVudHMgb24gaG93IHNlcnZpY2UNCj4+ID4+IGNoYWluaW5nIGlzDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KPj4gPj5h cmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEZyb20gYW4gYXJjaGl0ZWN0dXJh bCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGENCj4+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVu ZGVybHlpbmcgcGFja2V0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25l DQo+PmNhbg0KPj4gPj5oYXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoYXQNCj4+ID4+ID4+ PiA+PiA+Pj4+PiBhcHBlYXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZQ0KPj5wb2ludA0KPj4gPj5vZg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFj dHVhbGx5IGRlbGl2ZXJlZA0KPj4gPj5ieSBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlv biBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVz LCBwb3NzaWJseSBpbmNsdWRpbmcNCj4+b25lIG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNl dmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0 bHksIHRoaXMgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2 aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCj4+ID4+bWVjaGFuaXNtcy4NCj4+ID4+IEl0DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91 cyBjb250cm9sDQo+PiA+Pm1lY2hhbmlzbXMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2gg YXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsDQo+PmFuZA0KPj4g Pj52bQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0 dXJhbCBpbXBhY3Qgb2YNCj4+cGVybWl0dGluZw0KPj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+ ID4+dGVybWlub2xvZ3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcyBub3QgbGVhZA0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsg d2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5 DQo+PnNlbGVjdGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYWNrZXQgcGF0aHMgZm9yIHRo ZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0DQo+PiA+PnRyYWZmaWMNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQgbm90IHdhbnQgdG8gcmVx dWlyZQ0KPj4gdGhhdA0KPj4gPj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZp Y2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lIHBsYWNlIGluDQo+PnRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUN Cj4+Y29tYmluZWQuIEkNCj4+ID4+IHRlbmQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8NCj4+ ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29s bGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlDQo+PiA+PmNoYWluaW5n DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4g Tm90IGJlY2F1c2UgY2x1c3Rlcg0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS4NCj4+IFRo dXMsDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxv YWQgYmFsYW5jaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50DQo+ PiA+PnNpbmd1bGFyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2aWNl IGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzDQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0 YWxrIGFib3V0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZp Y2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhDQo+PiA+PiBzZXF1ZW5jZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0 IG9mDQo+PiA+PnBhY2tldHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxl bnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YNCj4+dHJhZmZpYw0KPj4gPj5pcw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0 aW9uLCBhbmQNCj4+ZmlyZXdhbGwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZm ZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRoZQ0KPj5jYWNoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHdpdGhvdXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90 aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRo ZQ0KPj5wYWNrZXRzLg0KPj4gQQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGgg aXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZg0KPj4gPj5sb2NhdGlvbnMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9ucyB3aWxsIGJl IHNpbmd1bGFyIG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1 bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleQ0KPj4gPj5tYXkgYmUNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3Nl ZCBhcw0KPj4gcG9ydHMNCj4+ID4+IG9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4g VGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ID4+bG9jYXRpb25zDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBpbmZyYXN0cnVjdHVyZQ0KPj4gYW5kDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdHJhbnNwb3J0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDDQo+Pmdy b3VwLA0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3Ry YWN0aW9uLCB0aGUNCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwg d2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0bw0KPj4gdGFsaw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdp bGwgdGFrZSBpbiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29t bWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlDQo+PiBwYXRoDQo+PiA+PiBtYXkNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0 ZWN0dXJlIGRlYWxzDQo+PiA+PndpdGgNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1 ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpDQo+Pm9uDQo+PiA+Pmxv YWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUg ZGVjaXNpb25zIGFuZA0KPj5iZWhhdmlvcnMNCj4+ID4+IHdoaWNoDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgbWVjaGFuaXNtcyAo aW4NCj4+ID4+bXVjaA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBi cmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXINCj4+IHByb3Zpc2lv bg0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFrZSBpcw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBjYW4g YmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPj4gPj4gbmVjZXNzYXJ5Lg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2Vk IG9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUg cmUtY2xhc3NpZmljYXRpb24NCj4+cG9pbnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdl IGFyZSBhZnRlci4NCj4+SWYgaXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5kIGlm IHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZw0KPj4gPj4gZ3JvdXAsDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3 b3JkcyBhcmUgbmVlZGVkDQo+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhp cy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUNCj4+ID4+IGludGVudCwN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3QgdG8g bWF0Y2ggdGhlIHdvcmtpbmcNCj4+ID4+Z3JvdXANCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdy ZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlDQo+PiA+Pndo YXQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFp bGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWls aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBz ZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYw0KPj4g Pj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjDQo+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4g Pj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBz ZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+DQo+ PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QN Cj4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID5zZmMgbWFp bGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+ PiA+Pj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+Pg0KPj4g Pj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+PiA+PiA+DQo+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+c2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg== --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AFA0MISOUT7MSGUSRCF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUgTWlrZSB3YXMgbWFraW5n IGZ1biBvZiB5b3VyIGRlZmluaXRpb24gb2Ygc2VydmljZSBwYXRoIGlkZW50aWZpZXLigKY6DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmEgc2VydmljZSBwYXRoIGlkZW50aWZp ZXImcXVvdDsgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbioNCiB0aGF0IHNwZWNpZmljYWxs eSAmcXVvdDtbZG9lcyBub3RdIHNwZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzJnF1b3Q7LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDExLCAyMDE0 IDEyOjI4IFBNPGJyPg0KPGI+VG86PC9iPiBtaWtlYmlhbmNAYW9sLmNvbTsgTkFQSUVSQUxBLCBN QVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29t OyBSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WW91ciBkZWZpbml0 aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRo IHRocm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBh dGggaWRlbnRpZmllciBob3dldmVyIHBvaW50cyB0bw0KIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEg c3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2Vz IGJhc2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZhaWxh YmxlIGFuZCB3aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxheS4g V2hlbiBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91 IG1heQ0KIG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3 aGljaCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxk IGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aCBmb3IgdGhhdCBzZXJ2aWNlIGNo YWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVyIHByb3RvY29sIC8gbWVjaGFu aXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZQ0KIGZvciB5b3UuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m cXVvdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29t PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlh bmNAYW9sLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVseSAxMSwgMjAx NCBhdCAxMjoxOCBQTTxicj4NCjxiPlRvOiA8L2I+SmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJt YWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Ij5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5JIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lv bjo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7IEkgZG9u4oCZdCB3YW50IHRvIHNwZWNpZnk8YnI+DQomZ3Q7IHNw ZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0 aGVyZW9mKS4gSTxicj4NCiZndDsgYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCc MTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0mZ3Q7UzItJmd0O1MzPGJyPg0KJmd0 OyBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yazwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PGJyPg0KPGJyPg0KQnkgZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgJnF1b3Q7 c2VydmljZSBwYXRoJnF1b3Q7IHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBp bnN0YW5jZXMuICZuYnNwO0luIHRoZSBzdGF0ZW1lbnQgYWJvdmUsIHlvdSB1c2UgYSAmcXVvdDtz ZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90OyB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWlu KiB0aGF0IHNwZWNpZmljYWxseSAmcXVvdDtbZG9lcyBub3RdIHNwZWNpZnkgc3BlY2lmaWMgaW5z dGFuY2VzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ni43NXB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5 bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86amd1 aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8 L2I+TkFQSUVSQUxBLCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+ bW4xOTIxQGF0dC5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mbHQ7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxSb24NCiBQYXJrZXIm bHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSnVseSAxMSwg MjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpNYXJpYSw8YnI+DQo8YnI+DQpJIHRoaW5r IG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgc2ltcGx5IGEg cG9pbnRlciB0bzxicj4NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0 LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGE8YnI+DQpjaGFpbiwgbGV04oCZcyBzYXkg UzEgLSZndDtTMi0mZ3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3Bl Y2lmeTxicj4NCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRv IGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZlciwgeW91IGRvICpub3QqIGhh dmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSTxicj4NCndp bGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVj dHVyYWxseSkuIFlvdTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRl bnRpZmllciB0byBwb2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+DQp0aGVuIHB1c2ggdGhhdCBp bmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhPGJy Pg0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGlu ZyB3b3VsZCBjb250YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2Yg dGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVhcm48YnI+DQp0aG9zZSBuZXh0 LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhIGNlbnRy YWxpemVkPGJyPg0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJu IHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaDxicj4NCnNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdo YXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvPGJyPg0Kc2F5IHRo YXQgdGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3Nl biBhIHByaW9yaTxicj4NCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQg c29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvPGJyPg0Kc28uPGJyPg0KPGJyPg0KTGV0 4oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjo8YnI+DQo8 YnI+DQpJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMxLSZn dDtTMi0mZ3Q7UzMuIEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBp dCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTxicj4N CnNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlv biB0aGVyZW9mKS4gSTxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEw MOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxicj4NCmFuZCB0 aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVj dHVyZXMgYXJlPGJyPg0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93IGF0IGEg Z2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlczxicj4NCndpdGggc2VydmljZSBwYXRoIGlk ZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhPGJyPg0K c3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzMgYW5k IHRoZSBpbmRleCBpbiB0aGUgU0ZDPGJyPg0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhh Y3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlPGJyPg0KYXJlIGF0 IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5l eHQtaG9wIHRvPGJyPg0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJl IFMzIGlzIHJlYWNoYWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0LCAxMToyNiBBTSwgJnF1b3Q7 TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5j b20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0ppbSw8YnI+ DQomZ3Q7PGJyPg0KJmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhlIGRlZmluaXRpb24g b2YgYSAmcXVvdDtzZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8YnI+DQomZ3Q7JnF1b3Q7c2Vydmlj ZSBwYXRoIGlkZW50aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lmIGEgc2VydmljZSBwYXRoIG1lYW5z IHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoPGJyPg0KJmd0 O2lzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwg ZGVjaXNpb24gd2hpY2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2Vu dHJhbGl6ZWQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDtNYXJpYTxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 Jmd0OyA8YnI+DQo8YnI+DQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbPGEgaHJlZj0i bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbTwvYT5d PGJyPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNPGJyPg0K Jmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyBK b2VsIE0uPGJyPg0KJmd0OyZndDsgSGFscGVybjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVu ZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXI8YnI+DQomZ3Q7Jmd0OyBwcmV2 ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQg YSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVy ZW5jZT88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiA3LzExLzE0LCAxMDo1OCBBTSwg JnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIx QGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgJmd0O0RpdHRvLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IEZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFs8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZy aWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBK aW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBl cm47IFJvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFN1Ympl Y3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgUmUtLDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgRm9yIHdoYXQgSSBjYW4gc2F5 IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlPGJyPg0KJmd0OyZn dDtkcmFmdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1h bmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhh dCB0aGUgZnVsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZGlzdHJpYnV0ZWQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBtb2RlbCBpcyBub3QgYWxsb3dlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGlj YXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 c2hvdWxkIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlkZWQgaW5zdGVhZC48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDstLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7RGUgOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hh cmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7KGpndWljaGFyKTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDtFbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0O8OAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhh bHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPYmpldCA6IFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2sgYnV0IHdoZXJlIGluIHRo ZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRl ICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0O3dpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmll ciBwb2ludCB0byBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb29rdXA8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4g dGhlIGNoYWluLCBJIGFtIG5vdDxicj4NCiZndDsmZ3Q7c3VyZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7aG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3RoZSBhcmNoaXRlY3R1cmUgcHJldmVu dHMgdGhhdD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0O09uIDcvMTEvMTQsIDk6NTggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1dGVseS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBG cm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhqZ3VpY2hhcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU08YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsg Sm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkg Li4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQgaWY8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgeW91IGFsbG93IGFuIFNGRiB0byBt YWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdDxicj4NCiZndDsmZ3Q7d2ls bDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Zm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGEgZ2l2ZW4gZmxv dyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91PGJyPg0KJmd0 OyZndDtiZXR0ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vz c2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZWFjaDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91 IGFyZSBpbiBkZWVwIHRyb3VibGUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTEvMTQsIDk6NDggQU0s ICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTky MUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg d3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDtBYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMg Y2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluPGJyPg0KJmd0OyZndDtyZWxldmFudDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NGRnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0O3doZW4gdGhleSAmcXVvdDthcnJpdmUmcXVvdDsuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBKaW08YnI+DQomZ3Q7Jmd0O0d1aWNoYXJkPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7KGpndWljaGFyKTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToy NyBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogSm9l bCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBXZWxsIEkgdGhpbmsgaXQg aXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2Q8YnI+DQomZ3Q7Jmd0 O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3Byb3Bvc2Fs PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvcnJlY3RseSBh cyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZTxicj4NCiZn dDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aXRoaW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkg c2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG88YnI+DQomZ3Q7Jmd0O2tub3c8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDtwcmlvcmk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg d2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZl bjxicj4NCiZndDsmZ3Q7cG9pbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGltZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgT24gNy8xMC8xNCwgMTE6NTMgUE0sICZxdW90O0pvZWwgTS4gSGFscGVybiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5j b208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVk IGFub3RoZXIgbWFqb3IgcHJvYmxlbTxicj4NCiZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7eW91 cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7cHJvcG9z YWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3Q8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt1bmRlcnN0YW5kPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpdC4pPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1RoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUg YXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmV4dDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBm dW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzPGJyPg0KJmd0 OyZndDt0byksPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDtzZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Ljxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtTaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0 byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zPGJyPg0KJmd0OyZndDsgJmd0OyZn dDt0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZXZlcnk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NGRiB3b3Vs ZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtiYWxhbmNlci48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0kgYWh2ZSBubyBwcm9ibGVtIGlmIHNv bWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3N0YXRlZnVsLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUg YSBmdWxsLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Zmxvdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxh bmNlciBzZWVtcyB0byBtZSB0byBiZSBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNjZXB0YWJs ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW1wb3Np dGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7WW91cnMsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtKb2VsPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTAvMTQsIDEwOjA2IFBN LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkg YW0gdHJ5aW5nIHRvIG1ha2UgdGhpczxicj4NCiZndDsmZ3Q7d29yazxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlbnNpYmx5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQg ZW52aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlPGJyPg0KJmd0OyZndDtzZXJ2aWNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGZ1bmN0aW9u cywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcyw8YnI+DQomZ3Q7 Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2JlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVk LiBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnM8YnI+DQomZ3Q7Jmd0O3RvIGJlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmVuIGJ5PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEJTUyB0b29scyB0aGF0 IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3NlbGYtc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZp Y2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZl Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGNh biBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O2J5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0 IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtoYXJkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 O3NlZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cg bW9yZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkeW5hbWlj aXR5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3Bl Y3RpdmUgSSBkZXNjcmliZWQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O291dHNpZGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90 IHNvbWV0aGluZyB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rhc2tlZCB0bzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2FncmVlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7b24uPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFNvIEkgZG8gbm90IGNsYWlt IHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYTxicj4NCiZndDsmZ3Q7Y2VydGFp bjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dheS48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0 IGRyaXZlcyBteSBwcmVmZXJlbmNlcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsgT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3Rl Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGlu c3RhbmNlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJp YnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2Fjcm9zczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBj ZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoPGJy Pg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tcGxl eDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1z IGxpa2UgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RpZmZpY3VsdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlz IG1vcmUgY29tcGxpY2F0ZWQgdGhhbjxicj4NCiZndDsmZ3Q7ZHluYW1pYzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByb3V0aW5nLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIg b3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Y8YnI+DQomZ3Q7Jmd0O3doaWNoPGJyPg0KJmd0 OyZndDsgJmd0OyZndDthcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDtiaWdnZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJs eSBpbXBsZW1lbnRlZD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUg Y29tcGxpY2F0ZWQsIHRoYXQ8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDth PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Z29vZDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2lnbiB0aGF0IGl0IGlz IHRvbyBjb21wbGljYXRlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0IDk6NDUgUE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyA8YSBo cmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPg0KbWlrZWJpYW5jQGFvbC5jb208L2E+Ozxi cj4NCiZndDsmZ3Q7SWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U21pdGg7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4NCiZndDsmZ3Q7 QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQg SSB3b3VsZDxicj4NCiZndDsmZ3Q7cHJlZmVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3ZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthY3R1 YWxseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDtpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCZWNhdXNlIGl0IGRvZXMgaGF2 ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVx dWlyZW1lbnRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YW5kPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25hbGl0eSBv ZiBTRkZzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNl IGluc3RhbmNlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3Rl bnRpYWxseSBldmVuPGJyPg0KJmd0OyZndDsgYWNyb3NzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUs IGlzIGxhcmdlIGVub3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Y29tcGxleDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8g ZWFjaCBTRkYgc2VlbXMgbGlrZSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ZGlmZmljdWx0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEpvZWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCdXQg aXQgaXMgYSBmYWlyIHF1ZXN0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIg d3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gJm5ic3A7IElzIHRoZSBl bmQgdG8gZW5kPGJyPg0KJmd0OyZndDtzZWxlY3Rpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29m PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMg YnkgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Y2xhc3Np Zmllcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBz dWJzZXF1ZW50bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O1NGRnMpPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFN1Y2ggc2VsZWN0aW9uIGlzIG5v dCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uPGJyPg0KJmd0OyZndDtBbmQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtzdXJlbHksPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhpcyBpcyBhbiBhcmNo aXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7aW1wbGVtZW50 YXRpb24mcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBNeSBvd24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJp YnV0ZWQgYXBwcm9hY2ggZXZlbjxicj4NCiZndDsmZ3Q7IHRob3VnaDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBh bmQgcGVyaGFwczxicj4NCiZndDsmZ3Q7bG9jYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDtzZWxlY3Rpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRo b3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1Ro aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBh dCBhbGwuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtNeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJhdGlvbmFsZSBmb3IgZmF2b3Jp bmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkgZHJpdmVuPGJyPg0KJmd0OyZndDtieTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2luY3JlYXNlZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJl c2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guICZuYnNwOyBXaXRoIGE8 YnI+DQomZ3Q7Jmd0O2dsb2JhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3Bh dGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFw cHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvPGJy Pg0KJmd0OyZndDsgJmd0OyZndDthbHRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZl Y3RlZDxicj4NCiZndDsmZ3Q7ZW5kLXRvLWVuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O3BhdGguPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBSb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2Yg Sm9lbCBIYWxwZXJuIERpcmVjdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2Vs aGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPl0gU2VudDogVGh1cnNk YXksIEp1bHkgMTAsPGJyPg0KJmd0OyZndDsyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgNjox NTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBQTTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVm PSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOkkuU21pdGhARjUuY29tIj4NCkkuU21pdGhARjUuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1Ympl Y3Q6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgUmU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgdGhlIGFyY2hpdGVj dHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxIG5lZWRpbmc8YnI+DQomZ3Q7Jmd0O3RvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW5mbHVlbmNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhl IGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlPGJyPg0K Jmd0OyZndDtleGl0PGJyPg0KJmd0OyZndDsgJmd0OyZndDtmcm9tPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU0YxLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zPGJy Pg0KJmd0OyZndDsgJmd0OyZndDtsb2dpY2FsbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0 aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cgdGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IGNob29zZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY29tcG9z ZSB0aGVtIGZvciAmcXVvdDtzZXJ2aWNlJnF1b3Q7IGRlbGl2ZXJ5Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWW91cnMs IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDY6MTAgUE0sIDxhIGhyZWY9Im1haWx0bzptaWtl YmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+IHdyb3RlOjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRv bid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7c29ydDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhh dCB0aGUgZW50aXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7KGFsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBT RkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlPGJyPg0KJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7bWVhbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZWl0aGVyIGF0IHRoZSBjbGFz c2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyPGJyPg0KJmd0OyZndDtjaG9vc2VzIGE8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NGPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7Q2hhaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBm aXJzdCBTRkYuIEluIGFueSBjYXNlLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTRkkobik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2Nv cmRpbmcgdG8gdGhlIGRyYWZ0LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi ZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICZxdW90O2JyYW5jaGluZyZxdW90OyB0byBhIG5l dyBTRlAgYXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgb3Bwb3NlZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaG9v c2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNG Qy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBp dCBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmVjZXNzYXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFu Y2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZCB0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1 c2luZyBTRidzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtuZXR3b3JrPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb2Nh dG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtjcmVhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYSBT ZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtmb3J3YXJkaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4g SW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24g b2YgdGhlIGRlZmluZWQgU0ZDLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBTRkMgYXJj aGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtub24taW5pdGlhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFz IHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBt YXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZp Y2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtmdW5jdGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3Vs dCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3PGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRlAsIGFu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGgu IFRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlZmVycmVkPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzICZxdW90O2JyYW5jaGluZyZxdW90 Oy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDstLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICpGcm9tOiA8YSBocmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29tIj4qSS5T bWl0aEBGNS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0 aEBGNS5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86ICpKb2VsIEhhbHBlcm48YnI+DQomZ3Q7Jmd0 OyBEaXJlY3QmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5q bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBNLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDtIYWxwZXJuJmx0OzxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZn dDssPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxl dG9uLmNhPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLiUwYiI+aHVhbmdAc2NlLjxi cj4NCjwvYT4mZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgY2FybGV0b24u PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Y2EmZ3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZDxicj4N CiZndDsmZ3Q7dGhhdCBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFp bnMgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwcmVjb25jZWl2ZWQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3 aXRoPGJyPg0KJmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcmVjb25jZXB0aW9uLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9m PGJyPg0KJmd0OyZndDsgJmd0OyZndDthc3BpcmF0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9m IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXJjaGl0ZWN0dXJlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7LTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQg aXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O2FyYml0cmFyeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBudW1iZXIgaXMgJnF1b3Q7dG9vIGZhciZxdW90Oywg eW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2ludGVudGlvbmFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gYSBsaW1pdCB0aGF0 IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtpbXBhY3RzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdh dGlvbiwgZWxhc3RpY2l0eSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FkZHJlc3M8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg c3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEpvZWwgSGFscGVy biBEaXJlY3QgWzxhIGhyZWY9Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1o LmRpcmVjdEBqb2VsaGFscGVybi5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U2VudDo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBK b2VsIE0uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSGFscGVybjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPjsN CjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gU3ViamVjdDog UmU6IFtzZmNdPGJyPg0KJmd0OyZndDsgJmd0OyZndDtTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJYW4sIEkgZG9uJ3Qg dGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3JlZ2FyZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtJPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YW08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm90IHJl cXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtwcm9oaWJpdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMg ZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0h1YW5nJ3M8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVu dHMgYXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcmVxdWlyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhleSBieSB0 aGUgYXJjaHRpZWN0dXJlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBJIGhhdmUgc2FpZCByZXBlYXRl ZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJvaGliaXQ8YnI+DQomZ3Q7Jmd0O3N1Y2g8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVw b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYW55PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhY3RvcnMgb3V0c2lkZSBv ZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bzxicj4NCiZndDsmZ3Q7dGhpbms8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDt0aGV5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRl bXB0aW5nIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDtrbm93PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7d2hhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwg NTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkaXNhZ3JlZS48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRo YXQgbWFuYWdlIHRlbnMgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDttaWxs aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFj Y2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVudHMgdG9kYXku IFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluPGJyPg0KJmd0OyZndDt0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlv dTxicj4NCiZndDsmZ3Q7IGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9ubHk8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZ29pbmc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gaGF2 ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseTxicj4NCiZndDsm Z3Q7c21hbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbnVtYmVyczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBvZiBhY3RpdmUgc2VydmljZSBwYXRocz88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZ b3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICZxdW90O25vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3Jl PGJyPg0KJmd0OyZndDsgdGhhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA2 NEsmcXVvdDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb21mb3J0Ljxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIEZyb206IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9l bCBNLiBIYWxwZXJuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwg SnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OzxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJs ZXRvbi5jYTwvYT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs PGJyPg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtMb2Fk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBObywgaXQg d2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YXJjaHRpZXR1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3Vs YXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mPGJyPg0KJmd0OyZndDt0 aGVpcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1 aXJlIHN1Y2ggYWJzdXJkPGJyPg0KJmd0OyZndDsgdXNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0 IGhvdyB0byB3cml0ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJp dCBpdCwgdGhlIGFyY2hpdGVjdHVyZTxicj4NCiZndDsmZ3Q7ZG9lczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3Blcm1pdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBhYnVzZS48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhl IGFyY2h0aWVjdHVyZTxicj4NCiZndDsmZ3Q7IHBlcm1pdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbWV0aGlu ZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnk8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dvcmsu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJdCBpc24ndC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3Vycywg Sm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5n Y2hlbmcgSHVhbmcgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgeW91IG5lZWQgdG8gc3VwcG9y dCAxMDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGw8YnI+DQomZ3Q7Jmd0O21lYW48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5n PGJyPg0KJmd0OyZndDt0YWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2YgYTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNvcmUgcm91dGVyLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hh bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDA3LzEwLzIwMTQgMDE6MTUg UE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGFyY2hp dGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgZnJvbTxicj4NCiZndDsmZ3Q7 MTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0 aHMuIEkgd291bGQgaG9wZTxicj4NCiZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv cGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlmIHRoZXk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2Nob29zZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxh bmNpbmcgYW5kIGluIHN0ZWFkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlzaW9uPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDE2MCwwMDAgc2VydmljZSBwYXRocy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJ QSBIIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF1bCw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIb3cgbWFueSBwYXRoIGlkZW50aWZp ZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3A8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZXJ2 aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBl YWNoIGhvcD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBNYXJpYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gKk9uIEJlaGFsZjxicj4NCiZndDsmZ3Q7IE9mPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzM6MDM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFBNICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+DQpqbWhAam9lbGhhbHBlcm4uY29tPC9hPjs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiAqU3Vi amVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlPGJyPg0KJmd0OyZndDsgQ2hhaW5zLDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEx1Y3ksPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91 IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndh cmRpbmcuIEnCuWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFrZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIG1p bm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0bzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IGRlcml2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIG5lZWRlZCBm b3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBi dXQgcmF0aGVyIGlzIHVzZWQgdG88YnI+DQomZ3Q7Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0 czxicj4NCiZndDsmZ3Q7bXVzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhdmVyc2UuIEJ5 IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb248YnI+ DQomZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRocmVhZCBjYW4gYmUgc2lt cGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGlkZW50 aWZpZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFu IGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyByZXN1bHQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdo dGVkKSB0cmFuc3BvcnQgbmV4dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaG9wKHMpLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMTAsIDIw MTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29t PC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25n QGh1YXdlaS5jb20lM2UiPm1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDs8L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUg b25seSB1c2Ugb2Y8YnI+DQomZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nPGJyPg0KJmd0OyZn dDsgJmd0OyZndDthY3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEx1Y3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddKk9uIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uPC9hPiBCZWhhbGY8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPZiptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5PZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpTZW50OipUaHVyc2RheSw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSnVseTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgMTAsIDIwMTQgMjowNiBBTSAqVG86PGEgaHJlZj0ibWFpbHRvOiptaWtlYmlhbmNA YW9sLmNvbSI+Km1pa2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4u Y29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb20mZ3Q7O2ptaEBqb2VsaGFscGVybi5jb208L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lM2U7c2ZjQGlldGYub3JnIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7 c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqU3ViamVjdDoq UmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0NoYWlucyw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZS0sPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBv dXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaWRl bnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bzxicj4NCiZndDsmZ3Q7 ZGVyaXZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nIGFjdGlvbnMuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVxdWlyaW5nIGEg U0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IGV2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF2YWlsYWJsZSBTRkM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3Q8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcmVxdWlyZWQvanVzdGlmaWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3Ig cG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMg c2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZv cm1hdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IHdpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHBy ZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmU8YnI+DQomZ3Q7Jmd0OyBy ZXF1aXJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dXNlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mZXIg Zm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhY3Rpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBh IHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1lZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpEZSA6KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpEZSI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZTwvYT4gbGEg cGFydDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20iPmRlKm1p a2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZn dDsgKkVudm95w6kgOiptZXJjcmVkaSA5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsganVpbGxldDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMjAxNCAyMjowMyAqw4AgOjxhIGhyZWY9Im1haWx0bzoq am1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7 c2ZjQGlldGYub3JnIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7c2ZjQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqT2JqZXQgOipSZTogW3NmY10gU2Vy dmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW5zLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuPGJyPg0KJmd0OyZndDtTRjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IENo YWluPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgU0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aD88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBz byB0aGF0IGl0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsZWFyIHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRob3Nl IG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0 IHNlZW1zIHRoYXQgZXZlcnlvbmU8YnI+DQomZ3Q7Jmd0O2FncmVlczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXNlIHRlcm1zLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvIG1lLCB0aGUgb25lIHBv aW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpczxicj4NCiZndDsmZ3Q7d2hldGhlcjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7aXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBpbnRlbnQg b2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7dGhlIElEPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiB0aGUgU0ZDIEhlYWRlcjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBzaG91bGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVyZW5jZSAodGhlIGNo YWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 c2ltcGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1i aWd1b3VzLCBhbGxvd2luZyBvdGhlcjxicj4NCiZndDsmZ3Q7ZHJhZnRzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGljdGF0ZSB0aGUgbWVjaGFuaXNt cyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbjxicj4NCiZndDsmZ3Q7IG9yPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHBhdGggdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNv bnRyb2wtcGxhbmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2 ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMg YmUgc3VwcG9ydGVkIChvciBtYWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb25lPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9p ZCBzb21lPGJyPg0KJmd0OyZndDsgdmVuZG9yczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9ubHk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBz dXBwb3J0aW5nIFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbTo8YSBocmVmPSJtYWlsdG86Kmpt aEBqb2VsaGFscGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZSI+bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJmd0OzwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86PGEgaHJlZj0ibWFpbHRvOipzZmNAaWV0Zi5vcmci PipzZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlIj5tYWlsdG86c2ZjQGlldGYub3JnJTNjc2Zj QGlldGYub3JnJmd0OzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgKlNlbnQ6KlR1ZXNkYXksPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgSnVseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgOCwgMjAxNCAq U3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQ8YnI+DQomZ3Q7Jmd0O0xv YWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1 cmUgb3V0IGhvdyB0byBjbGVhcmx5PGJyPg0KJmd0OyZndDthbnN3ZXI8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBvZiBjb21tZW50cyB0aGF0 IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBwcm9wb3NlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWVyZ2VkIGFyY2h0aWVjdHVy ZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldDxicj4NCiZndDsmZ3Q7IHdvcmtpbmc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxs IHdvcmsgdG88YnI+DQomZ3Q7Jmd0OyBpbXByb3ZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2 ZSBub3QgcGFydGljaXBhdGVkIGluPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBXRzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzY3Vzc2lvbiB3aWxs IHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JraW5nPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBncm91cCBpbnRlbmRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBl eHBsYWluIG15PGJyPg0KJmd0OyZndDsgJmd0OyZndDtwZXJzb25hbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBv cnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3doYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBh cmNoaXRlY3R1cmUuIFdlPGJyPg0KJmd0OyZndDthcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBu b3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSBlbnRpcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbHV0aW9u IGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29tcGFzczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25z LDxicj4NCiZndDsmZ3Q7dmlydHVhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFjaGluZSBh bmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBhc3BlY3RzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQ8 YnI+DQomZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhpc3QgaW4gdGhlIGxh cmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7YWJvdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZXJlIHdlIGFyZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBm dW5jdGlvbmluZyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBhcmUgbm90IGRpcmVjdGx5 IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZTxicj4NCiZndDsmZ3Q7IGRvaW5nLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIG9yZGVyIHRvIGdl dCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCw8YnI+DQomZ3Q7Jmd0O2FzIEk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVuZGVyc3RhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbSw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBU aGVyZSBhcmUgYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xlYXN0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQ8 YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVyYWN0IHdpdGgg c2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDttb3JlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHBvaW50IG9mIHRoZSBhcmNodGll Y3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlc2UsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGlj dWxhciBraW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHVzZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGFu eSBzb2x1dGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMg aXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyPGJyPg0KJmd0OyZndDtwYWNr ZXRzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBt b2RpZmllcyB0aGVtIChvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXJrczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7aW5zdGFuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIHJlY2Vp dmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9uIHRvIGJlIGFi bGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 SXQnczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJl bWVudHMgb24gaG93IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjaGFpbmluZyBpczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBh Y3Qgb24gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmNodGllY3R1cmUuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNp bXBseSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9u IHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIpIFRoZXJlIGlzIGludGVybmFsIGxv YWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmU8YnI+DQomZ3Q7Jmd0O2Nhbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7aGF2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hhdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcHBl YXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNo aXRlY3R1cmUgYXMgYSBzaW5nbGU8YnI+DQomZ3Q7Jmd0O3BvaW50PGJyPg0KJmd0OyZndDsgJmd0 OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29udGFjdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3IgYTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlz IGFjdHVhbGx5IGRlbGl2ZXJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YnkgYTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBj b2xsZWN0aW9uIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2aXJ0dWFsIG9yIHBoeXNpY2Fs IG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmc8YnI+DQomZ3Q7Jmd0O29uZSBvcjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNp bmcgVlJSUC1saWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0ZWNobmlxdWVzIHRvIHNoYXJl IGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lPGJyPg0KJmd0OyZn dDsgJmd0OyZndDttZWNoYW5pc21zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEl0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMg Y29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcyw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1v dXQsIDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDt2bTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9m IDxicj4NCiZndDsmZ3Q7cGVybWl0dGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1 bCB0aGF0IG91cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGVybWlub2xvZ3k8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGxlYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhZGVycyB0bzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Ljxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDMpIFRoZXJlIGNhbiBhbHNvIGJl IGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgPGJyPg0KJmd0OyZndDtzZWxlY3Rpbmc8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhh dCBkaXJlY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RyYWZmaWM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmU8 YnI+DQomZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSBwbGFj ZSBpbiA8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBv ZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgPGJyPg0KJmd0OyZndDtjb21iaW5l ZC4gSTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRlbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlZmVyIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgY29sbGVj dGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtjaGFpbmluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYSBzaW5nbGUgcG9pbnQg YXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIDxicj4NCiZndDsmZ3Q7aXM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdvb2QgdGVybS4gQnV0 IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS48YnI+DQomZ3Q7Jmd0OyBUaHVzLDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcG9pbnQg b2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHRvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Npbmd1bGFyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv ciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyA8YnI+DQom Z3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91 dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRo LyBTZXJ2aWNlIGNoYWluIGlzIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZXF1ZW5jZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0 byBhIHN1YnNldCBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGFja2V0cy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQg b2YgPGJyPg0KJmd0OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlv biwgYW5kIDxicj4NCiZndDsmZ3Q7ZmlyZXdhbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdo aWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgPGJyPg0KJmd0 OyZndDtjYWNoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXRob3V0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2aXNp dGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9u IHRvIGRpcmVjdCB0aGUgPGJyPg0KJmd0OyZndDtwYWNrZXRzLjxicj4NCiZndDsmZ3Q7IEE8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBh IHNlcXVlbmNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2NhdGlvbnM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5n dWxhciBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5PGJyPg0KJmd0OyZndDsgJmd0OyZndDttYXkgYmU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1h eSBiZSBhZGRyZXNzZWQgYXM8YnI+DQomZ3Q7Jmd0OyBwb3J0czxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRp ZmZlcmVudCB3YXlzIHRoYXQgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2NhdGlvbnM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBpbmZyYXN0cnVjdHVyZTxicj4NCiZndDsmZ3Q7IGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgPGJyPg0KJmd0OyZndDtncm91cCw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB3ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5lZWQgdG8gYmU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZl bCBhYnN0cmFjdGlvbiwgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQg d2UgbmVlZCB0bzxicj4NCiZndDsmZ3Q7IHRhbGs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFi b3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgJnF1 b3Q7YnV0IHRoZSB3aG9sZTxicj4NCiZndDsmZ3Q7IHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBtYXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQu JnF1b3Q7IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aXRo PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwg YXMgbm90ZWQgaW4gaXRlbSAoMikgPGJyPg0KJmd0OyZndDtvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7bG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBj YW4gYmUgZGVjaXNpb25zIGFuZCA8YnI+DQomZ3Q7Jmd0O2JlaGF2aW9yczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IHdoaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmUgaW52aXNpYmxlIHRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluPGJyPg0KJmd0OyZndDsgJmd0OyZn dDttdWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2lu ZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW52aXNp YmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyPGJyPg0KJmd0OyZndDsgcHJv dmlzaW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG1ha2UgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lm aWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYXQgd2lsbCBkaXJlY3Qg cGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24gPGJyPg0KJmd0 OyZndDtwb2ludC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuIDxi cj4NCiZndDsmZ3Q7SWYgaXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMsIGFuZCBpZiB0 aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBncm91cCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGNhbiBmaWd1cmUgb3V0IHdo YXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkPGJyPg0KJmd0OyZndDsgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3Jl ZSB3aXRoIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGludGVudCw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3Jr aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDtncm91cDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDt3aGF0IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cnkgbmV4 dC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3Vy cywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlz dCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm YzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3Qg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGxp c3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFp bGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwv YT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgc2ZjIG1haWxp bmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O3Nm YyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgc2ZjIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2ZjIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4AFA0MISOUT7MSGUSRCF_-- From nobody Fri Jul 11 09:56: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 77AF01A0AD2 for ; Fri, 11 Jul 2014 09:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCur1ZwAomUu for ; Fri, 11 Jul 2014 09:56:09 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCFC1A0AC8 for ; Fri, 11 Jul 2014 09:56:08 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 92710c35.2b994409f940.4715092.00-2445.13075193.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:56:09 +0000 (UTC) X-MXL-Hash: 53c01729225e4b9b-bddda4ddedff306c7803f523fc9ad55f237b9773 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 90710c35.0.4714806.00-2182.13074377.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 11 Jul 2014 16:55:38 +0000 (UTC) X-MXL-Hash: 53c0170a12c254b4-5d3e440cf1ce51afd823ed308be4da486f2002f1 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGtaFv020933; Fri, 11 Jul 2014 12:55:37 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6BGtRa7020753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jul 2014 12:55:32 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 11 Jul 2014 16:55:13 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 12:55:12 -0400 From: "NAPIERALA, MARIA H" To: "Jim Guichard (jguichar)" , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Ron Parker , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U346Wl2xDyU2yGQvISSwEJZuYfwEAgAC5UYCAAIXgAIAAQmiA//+8/xCAAEaxgIAABekAgAACvoCAAAP/gIAAAN0AgAADBACAAA+bgIAAAVyAgAA4uoCAAAHeAIAAA6OAgAACOQCAAB3ogIAAoFSA///CVlCAAEUrAP//vkNgAAkPaQAAAHHZAAAHbPkA///Q1oCAAEKp8P//yI4AgAA9hfD//8yhgIAAQnMQ///BAoAACANjQA== Date: Fri, 11 Jul 2014 16:55:12 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4AFC6@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.229.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=z3HyPQKE0hEA:10 a=ofMgfj31e3cA:10 a=fub1fAhg3AMA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=3oc9M9_CAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH] X-AnalysisOut: [86SAAAA:8 a=Eeye5iNQpuQCjju-TfkA:9 a=QEXdDO2ut3YA:10 a=yoo] X-AnalysisOut: [QnSbrthUA:10 a=JfD0Fch1gWkA:10 a=oAXR_kdF8uMA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=Hz7IrDYlS0cA:10 a=chC_agHSu74A:10 a=U8Ie8EnqySE] X-AnalysisOut: [A:10 a=3XJ037QrwtgA:10 a=cPP13LOZsRXvgE30:21 a=bAh258i6Guv] X-AnalysisOut: [snw-Z:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9ACtzEhdHR5IBtG-tpoEpU6-XbU Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 16:56:14 -0000 V2UgY2VydGFpbmx5IGNhbm5vdCBkZWZpbmUgYW4gYXJjaGl0ZWN0dXJlIHRoYXQgZGljdGF0ZXMg dGhhdCBhbGwgU0ZDIHBhdGhzIGFyZSB0cmFmZmljIGVuZ2luZWVyZWQuDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0 bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMjo0 NCBQTQ0KPiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tOyBKb2VsIE0uDQo+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4gDQo+IEkgYW0gbm90IHByb3Bvc2luZyBhIHNvbHV0aW9uICh0aGF04oCZcyB0aGUgV0figJlz IGpvYikgYnV0IHNpbXBseSB1c2luZyBteQ0KPiBpbnRlcnByZXRhdGlvbiBvZiB0aGUgYXJjaGl0 ZWN0dXJlIHRvIG1vdmUgdGhlIGRpc2N1c3Npb24gZm9yd2FyZC4NCj4gDQo+IFllcywgaXQgaXMg c3RpbGwgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBmb3IgdGhlIHJlYXNvbnMgdGhhdCBKb2Vs DQo+IG1lbnRpb25lZCBpbiBhbm90aGVyIGVtYWlsLg0KPiANCj4gT24gNy8xMS8xNCwgMTI6Mzcg UE0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPiA+ PiA+PiBJIHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg aXMgc2ltcGx5IGENCj4gPj5wb2ludGVyDQo+ID4+ID4+dG8NCj4gPj4gPj4gYSBkYXRhIHN0cnVj dHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5leHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdQ0KPiA+ PiBkZWZpbmUNCj4gPj4gPllvdSBhcmUgdGFsa2luZyBhYm91dCB0cmFmZmljIGVuZ2luZWVyaW5n IG9mIHBhdGhzIHRoYXQgYSBzZXJ2aWNlIGNoYWluDQo+ID4+ID5jYW4gdGFrZS4NCj4gPj4gPlRo aXMgc3VyZWx5IGNvdWxkIGJlIGRvbmUvYWxsb3dlZCBidXQgdGhpcyBjYW5ub3QgYmUgYSByZXF1 aXJlbWVudCBmb3INCj4gPj4gPmFsbCB0cmFmZmljLg0KPiA+Pg0KPiA+PiBKaW0+IHRoYXTigJlz IHdoeSBJIHNhaWQgKm1pZ2h0KiAtIElPVyB5b3UgZG8gbm90IGhhdmUgdG8sIGl0cyBhDQo+ID4+ ZGVwbG95bWVudA0KPiA+PiBjaG9pY2UgYW5kIGlzIHN1cHBvcnRlZCBieSB0aGUgYXJjaGl0ZWN0 dXJlLg0KPiA+DQo+ID5ZZXMsIEkgbm90aWNlZCwgYnV0IEkgYWxzbyBub3RpY2VkIHRoYXQgeW91 IGFyZSBwcm9wb3NpbmcgYSBzb2x1dGlvbg0KPiA+YmFzZWQgb24gaXQuDQo+ID4NCj4gPllvdSBo YXZlIG5vdCBjb21tZW50IG9uIHRoZSByZXN0OiBpcyBpdCBzdGlsbCAic2VydmljZSAqcGF0aCog aWRlbnRpZmllciI/DQo+ID4NCj4gPk1hcmlhDQo+ID4NCj4gPj4gPj4gT24gNy8xMS8xNCwgMTE6 MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4gPj4gd3JvdGU6 DQo+ID4+ID4+DQo+ID4+ID4+ID5KaW0sDQo+ID4+ID4+ID4NCj4gPj4gPj4gPkNvdWxkIHlvdSB0 ZWxsIHVzIHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAic2VydmljZSBwYXRoIiBhbmQgYQ0K PiA+PiA+PiA+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIj8NCj4gPj4gPj4gPklmIGEgc2Vydmlj ZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkNCj4g Pj4gPj4od2hpY2gNCj4gPj4gPj4gPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBp dCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24NCj4gPj53aGljaA0KPiA+PiA+PiA+bmV4dC1o b3AgU0ZGIHRvIHBpY2suICBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPiA+PiA+PiA+ DQo+ID4+ID4+ID5NYXJpYQ0KPiA+PiA+PiA+DQo+ID4+ID4+ID4NCj4gPj4gPj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ID4+ID4+ID4+IFNlbnQ6IEZyaWRh eSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTQ0KPiA+PiA+PiA+PiBUbzogTkFQSUVSQUxBLCBNQVJJ QSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBKb2VsDQo+IE0uDQo+ID4+ID4+ID4+ IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+PiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4g Pj4gPj4NCj4gPj4gPj4gPj4gSeKAmW0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJz dGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgNCj4gPj5pZGVudGlmaWVyDQo+ID4+ID4+ID4+IHByZXZl bnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBh DQo+ID4+ID4+c2VydmljZQ0KPiA+PiA+PiA+PiBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBk aWZmZXJlbmNlPw0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+PiBPbiA3LzExLzE0LCAxMDo1OCBBTSwg Ik5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPiA+PiA+PiB3cm90ZToNCj4g Pj4gPj4gPj4NCj4gPj4gPj4gPj4gPkRpdHRvLg0KPiA+PiA+PiA+PiA+DQo+ID4+ID4+ID4+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+ID4+ID4+IEZyb206IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gPj4gPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tXQ0KPiA+PiA+PiA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIw MTQgMTA6MzEgQU0NCj4gPj4gPj4gPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBO QVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4NCj4gPj5IYWxwZXJuOw0KPiA+PiA+PiBSb24NCj4g Pj4gPj4gPj4gPj4gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4gU3ViamVjdDog UkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ ID4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+IFJlLSwNCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4g Pj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFy bHkgaW4gdGhlDQo+ID4+ID4+ID4+ZHJhZnQuDQo+ID4+ID4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+ IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQg dGhhdA0KPiA+PnRoZQ0KPiA+PiA+PmZ1bGwNCj4gPj4gPj4gPj4gPj5kaXN0cmlidXRlZA0KPiA+ PiA+PiA+PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4g Pj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNl cnZpY2UgY2hhaW4NCj4gPj4gPj5pdHNlbGYNCj4gPj4gPj4gPj4gPj5zaG91bGQgYmUNCj4gPj4g Pj4gPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4g Q2hlZXJzLA0KPiA+PiA+PiA+PiA+PiBNZWQNCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4g Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiA+PiA+PiA+PiA+RGUgOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0NCj4gPj5HdWljaGFy ZA0KPiA+PiA+PiA+PiA+PiA+KGpndWljaGFyKQ0KPiA+PiA+PiA+PiA+PiA+RW52b3nDqSA6IHZl bmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxOA0KPiA+PiA+PiA+PiA+PiA+w4AgOiBOQVBJRVJB TEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4gPj4gc2ZjQGlldGYu b3JnDQo+ID4+ID4+ID4+ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+PiA+PiA+PiA+DQo+ID4+ID4+ID4+ID4+ID5P ayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcw0KPiA+ PiA+PmZ1bmN0aW9uYWxpdHkNCj4gPj4gPj4gPj4gPj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50 IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4dC1ob3BzIHRvICphbGwqDQo+ID4+ID4+U0ZG4oCZcw0K PiA+PiA+PiA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0 aCBpZGVudGlmaWVyIHBvaW50DQo+ID4+dG8gYQ0KPiA+PiA+PiA+PiA+Pmxvb2t1cA0KPiA+PiA+ PiA+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhl IGNoYWluLCBJIGFtDQo+ID4+bm90DQo+ID4+ID4+ID4+c3VyZQ0KPiA+PiA+PiA+PiA+Pmhvdw0K PiA+PiA+PiA+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPiA+PiA+PiA+ PiA+PiA+DQo+ID4+ID4+ID4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBN QVJJQSBIIg0KPiA8bW4xOTIxQGF0dC5jb20+DQo+ID4+ID4+ID4+IHdyb3RlOg0KPiA+PiA+PiA+ PiA+PiA+DQo+ID4+ID4+ID4+ID4+ID4+QWJzb2x1dGVseS4NCj4gPj4gPj4gPj4gPj4gPj4NCj4g Pj4gPj4gPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+ID4+ID4+ ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEppbQ0KPiA+PiA+Pkd1aWNoYXJkDQo+ID4+ID4+ID4+ID4+ID4+PihqZ3VpY2hhcikNCj4gPj4g Pj4gPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+ID4+ID4+ ID4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQ YXJrZXI7DQo+ID4+ID4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+PiA+PiA+Pj4gU3ViamVjdDog UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj5CYWxhbmNlcnMN Cj4gPj4gPj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFu ZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zDQo+ID4+dG8NCj4gPj4gPj5t ZQ0KPiA+PiA+PiA+PiA+PnRoYXQgaWYNCj4gPj4gPj4gPj4gPj4gPj4+IHlvdSBhbGxvdyBhbiBT RkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYNCj4gPj5pdA0KPiA+ PiA+PiA+PndpbGwNCj4gPj4gPj4gPj4gPj51c2UNCj4gPj4gPj4gPj4gPj4gPj4+Zm9yDQo+ID4+ ID4+ID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRo ZSBjaGFpbiB0aGVuIHlvdQ0KPiA+PiA+PiA+PmJldHRlcg0KPiA+PiA+PiA+PiA+Pm1ha2UNCj4g Pj4gPj4gPj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3Nh cnkgZm9yd2FyZGluZw0KPiA+PmxvZ2ljDQo+ID4+ID4+dG8NCj4gPj4gPj4gPj4gPj5yZWFjaA0K PiA+PiA+PiA+PiA+PiA+Pj50aGUNCj4gPj4gPj4gPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3Ig dGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXANCj4gPj4gPj50cm91YmxlLg0K PiA+PiA+PiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0s ICJOQVBJRVJBTEEsIE1BUklBIEgiDQo+ID4+IDxtbjE5MjFAYXR0LmNvbT4NCj4gPj4gPj4gPj4g Pj4gd3JvdGU6DQo+ID4+ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPkFic29sdXRl bHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4gPj4g Pj4gPj5yZWxldmFudA0KPiA+PiA+PiA+PiA+PiA+Pj5TRkZzDQo+ID4+ID4+ID4+ID4+ID4+PiA+ d2hlbiB0aGV5ICJhcnJpdmUiLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gPj4gPj4gPj4+ID4+IEZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+ ID4+ID4+ID4+R3VpY2hhcmQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+KGpndWljaGFyKQ0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4gPj4g Pj4gPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRm Lm9yZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4gPj5CYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0 aGFuIHRoYXQgaWYgSSBoYXZlDQo+ID4+ID4+dW5kZXJzdG9vZA0KPiA+PiA+PiA+PnRoZQ0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj5wcm9wb3NhbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gY29ycmVjdGx5 IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4gPj4gPj5zaW5n bGUNCj4gPj4gPj4gPj5TRg0KPiA+PiA+PiA+PiA+PiA+Pj53aXRoaW4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVy eSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vDQo+ID4+d2F5IHRvDQo+ID4+ID4+ID4+a25vdw0K PiA+PiA+PiA+PiA+PmENCj4gPj4gPj4gPj4gPj4gPj4+ID4+cHJpb3JpDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQg YW55DQo+ID4+Z2l2ZW4NCj4gPj4gPj4gPj5wb2ludA0KPiA+PiA+PiA+PiA+PmluDQo+ID4+ID4+ ID4+ID4+ID4+PnRpbWUuDQo+ID4+ID4+ID4+ID4+ID4+PiA+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iDQo+ID4+ID4+IDxqbWhA am9lbGhhbHBlcm4uY29tPg0KPiA+PiA+PiA+PiA+PiB3cm90ZToNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJl YWxpemVkIGFub3RoZXIgbWFqb3INCj4gPj5wcm9ibGVtDQo+ID4+ID4+ID4+d2l0aA0KPiA+PiA+ PiA+PiA+PnRoZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj55b3VyDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkgYWRtaXQgSQ0K PiA+Pm1heQ0KPiA+PiA+Pm5vdA0KPiA+PiA+PiA+PiA+PiA+Pj51bmRlcnN0YW5kDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+aXQuKQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFs YW5jZXINCj4gPj5mb3INCj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj5uZXh0DQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25l IGl0DQo+ID4+ZGVsaXZlcnMNCj4gPj4gPj4gPj50byksDQo+ID4+ID4+ID4+ID4+aW4NCj4gPj4g Pj4gPj4gPj4gPj4+ZXZlcnkNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRo YXQgZ29lcyB0aHJvdWdoIGl0Lg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2Vydmlj ZXMsIHRoYXQNCj4gPj4gPj5tZWFucw0KPiA+PiA+PiA+PiA+PnRoYXQNCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ZXZlcnkNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBh IGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZA0KPiA+PnN0YXRlZnVsDQo+ID4+ID4+bG9hZA0KPiA+ PiA+PiA+PiA+PiA+Pj5iYWxhbmNlci4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8g cHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZA0KPiA+Pi8gb3INCj4g Pj4gPj4gPj4gPj5zdGF0ZWZ1bC4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRo ZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhDQo+ID4+ID4+ZnVsbCwN Cj4gPj4gPj4gPj4gPj5mbG93DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0 ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPiA+PiA+PiA+PiA+PmFj Y2VwdGFibGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPkpvZWwNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlp bmcgdG8gbWFrZQ0KPiA+PiA+PnRoaXMNCj4gPj4gPj4gPj53b3JrDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PnNlbnNpYmx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJh dGVkIGVudmlyb25tZW50LiAgSSBleHBlY3QgdGhhdA0KPiA+PnRoZQ0KPiA+PiA+PiA+PnNlcnZp Y2UNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9i YWJseSB0aGUgU0ZGDQo+ID4+Y2FwYWJpbGl0aWVzLA0KPiA+PiA+PiA+PndpbGwNCj4gPj4gPj4g Pj4gPj5iZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxs ZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZQ0KPiA+PmNoYWlucw0KPiA+PiA+PiA+PnRvIGJlDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gQlNT IHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQNCj4gPj5lbmFibGUN Cj4gPj4gPj4gPj4gPj4gPj4+c2VsZi1zZWxlY3Rpb24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+ IGZyb20gdGhlc2UuICBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkNCj4gPj5w b2xpY3kNCj4gPj4gPj4gPj4gPj5kcml2ZS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29y ayBpbiBhbg0KPiA+PiA+PmFyY2h0aWVjdHVyZQ0KPiA+PiA+PiA+PiA+PmRyaXZlbg0KPiA+PiA+ PiA+PiA+PiA+Pj5ieQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNh dGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4NCj4gPj5JdA0KPiA+PiA+PmlzDQo+ID4+ ID4+ID4+ID4+aGFyZGVyDQo+ID4+ID4+ID4+ID4+ID4+PnRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PnNlZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0 IGNhbiBiZSBkb25lKSB3aGVuIHdlDQo+ID4+YWxsb3cNCj4gPj4gPj4gbW9yZQ0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gaW4gdGhlIG5l dHdvcmsgYmVoYXZpb3IuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkNCj4g Pj5kZXNjcmliZWQNCj4gPj4gPj5pcw0KPiA+PiA+PiA+PiA+Pm91dHNpZGUNCj4gPj4gPj4gPj4g Pj4gPj4+b2YNCj4gPj4gPj4gPj4gPj4gPj4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UNCj4g Pj5hcmUNCj4gPj4gPj4gPj4gPj50YXNrZWQgdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+YWdyZWUN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+b24uDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+PiBTbyBJ IGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0DQo+ID4+YQ0K PiA+PiA+PiA+PmNlcnRhaW4NCj4gPj4gPj4gPj4gPj4gPj4+d2F5Lg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj5pdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUg dGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+PiBKb2Vs DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gT24gNy8x MC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPiA+PiA+ PiBpbnN0YW5jZXMNCj4gPj4gPj4gPj4gPj4gdGhhdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj5uZWVk cw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkNCj4gPj4g ZXZlbg0KPiA+PiA+PiA+PiA+PmFjcm9zcw0KPiA+PiA+PiA+PiA+PiA+Pj5kYXRhDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3Bl LCBpcyBsYXJnZQ0KPiA+PiA+PmVub3VnaA0KPiA+PiA+PiA+PmFuZA0KPiA+PiA+PiA+PiA+PiA+ Pj4gY29tcGxleA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcg dG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcw0KPiA+PiA+Pmxpa2UgYQ0KPiA+PiA+PiA+ PiA+PiA+Pj5kaWZmaWN1bHQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gYXJjaGl0ZWN0dXJl IHRvIHJlYWxpemUuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRo YW4NCj4gPj4gPj4gPj5keW5hbWljDQo+ID4+ID4+ID4+ID4+ID4+PiByb3V0aW5nLA0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24s IG9yIEROUywgYWxsDQo+ID4+b2YNCj4gPj4gPj4gPj53aGljaA0KPiA+PiA+PiA+PiA+PmFyZQ0K PiA+PiA+PiA+PiA+PiA+Pj4gPj5iaWdnZXINCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBwcm9i bGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkNCj4gPj4gPj4gaW1wbGVt ZW50ZWQ/DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+ PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsDQo+ ID4+ID4+dGhhdA0KPiA+PiA+PiA+PmlzDQo+ID4+ID4+ID4+ID4+YQ0KPiA+PiA+PiA+PiA+PiA+ Pj5nb29kDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21w bGljYXRlZC4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21d DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQg OTo0NSBQTQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IFRvOiBSb24gUGFya2VyOyBKb2VsIEhh bHBlcm4gRGlyZWN0Ow0KPiA+PiBtaWtlYmlhbmNAYW9sLmNvbTsNCj4gPj4gPj4gPj5JYW4NCj4g Pj4gPj4gPj4gPj4gPj4+U21pdGg7DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYu b3JnDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4gPj4gPj5CYWxhbmNlcnMNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0 ZWN0dXJhbCBpc3N1ZS4gIEFuZCBvbmUgdGhhdCBJDQo+ID4+d291bGQNCj4gPj4gPj4gPj5wcmVm ZXINCj4gPj4gPj4gPj4gPj53ZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxv dyBhbGwgcG9zc2libGUNCj4gPj4gPj4gPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhl IGNvbnRyb2wNCj4gPj4gPj4gPj4gPj5yZXF1aXJlbWVudHMNCj4gPj4gPj4gPj4gPj4gPj4+YW5k DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiB0aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBmdW5j dGlvbmFsaXR5IG9mIFNGRnMuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2Vy dmljZQ0KPiA+PiA+PiBpbnN0YW5jZXMNCj4gPj4gPj4gPj4gPj50aGF0DQo+ID4+ID4+ID4+ID4+ ID4+PiBuZWVkcw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5DQo+ ID4+ZXZlbg0KPiA+PiA+PiA+PiBhY3Jvc3MNCj4gPj4gPj4gPj4gPj4gPj4+ZGF0YQ0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3Bl LCBpcyBsYXJnZQ0KPiA+PmVub3VnaA0KPiA+PiA+PiA+PmFuZA0KPiA+PiA+PiA+PiA+PiA+Pj5j b21wbGV4DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdl dCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4gPj4gPj5saWtlIGENCj4gPj4gPj4gPj4gPj4g Pj4+ZGlmZmljdWx0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJl YWxpemUuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+ PiBZb3VycywNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0 aW9uLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4g T24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gICBJcyB0aGUgZW5kIHRvIGVu ZA0KPiA+PiA+PiA+PnNlbGVjdGlvbg0KPiA+PiA+PiA+PiA+Pm9mDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJo YXBzDQo+ID4+YnkNCj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+Y2xhc3NpZmllcikN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUg Y2xhc3NpZmllciBhbmQNCj4gPj4gPj4gc3Vic2VxdWVudGx5DQo+ID4+ID4+ID4+ID4+dGhlDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PlNGRnMpPw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBTdWNo IHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0bw0KPiA+PnJlY2xhc3NpZmljYXRpb24uDQo+ ID4+ID4+ID4+QW5kDQo+ID4+ID4+ID4+ID4+ID4+PnN1cmVseSwNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVk IHRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3 IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaA0KPiA+PiBldmVuDQo+ID4+ID4+ ID4+IHRob3VnaA0KPiA+PiA+PiA+PiA+PiBhDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IGdy ZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZA0KPiA+PnBlcmhhcHMN Cj4gPj4gPj4gPj5sb2NhbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRl ZCBkZWNpc2lvbg0KPiA+PiA+PnBvaW50cy4NCj4gPj4gPj4gPj4gPj5UaGlzDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBw YXRoIGlkDQo+IGF0DQo+ID4+ID4+YWxsLg0KPiA+PiA+PiA+PiA+Pk15DQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmlt YXJpbHkNCj4gPj4gPj5kcml2ZW4NCj4gPj4gPj4gPj5ieQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj5p bmNyZWFzZWQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBn bG9iYWwgcGF0aCBpZCBhcHByb2FjaC4NCj4gPj5XaXRoIGENCj4gPj4gPj4gPj5nbG9iYWwNCj4g Pj4gPj4gPj4gPj4gPj4+cGF0aA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj5pZA0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBh bmQNCj4gPj5uZWVkaW5nDQo+ID4+ID4+dG8NCj4gPj4gPj4gPj4gPj5hbHRlcg0KPiA+PiA+PiA+ PiA+PiA+Pj50aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFi bGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkDQo+ID4+ID4+ID4+ZW5kLXRvLWVuZA0KPiA+ PiA+PiA+PiA+PiA+Pj5wYXRoLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBGcm9tOg0KPiA+PiBzZmMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gW3NmYy1ib3Vu Y2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuDQo+ID4+ID4+RGlyZWN0DQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2Vu dDogVGh1cnNkYXksIEp1bHkNCj4gPj4xMCwNCj4gPj4gPj4gPj4yMDE0DQo+ID4+ID4+ID4+ID4+ IDY6MTUNCj4gPj4gPj4gPj4gPj4gPj4+IFBNDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFRv OiBtaWtlYmlhbmNAYW9sLmNvbTsgSS5TbWl0aEBGNS5jb207DQo+IHNmY0BpZXRmLm9yZw0KPiA+ PiA+PiA+PiBTdWJqZWN0Og0KPiA+PiA+PiA+PiA+PiBSZToNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdh eSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjENCj4gPj4gPj5uZWVkaW5n DQo+ID4+ID4+ID4+dG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZp Y2F0aW9uIGF0DQo+ID4+dGhlDQo+ID4+ID4+ID4+ZXhpdA0KPiA+PiA+PiA+PiA+PmZyb20NCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhl IGRpZmZlcmVudCBmdW5jdGlvbnMNCj4gPj4gPj4gPj4gPj5sb2dpY2FsbHkNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVz Y3JpYmUgaG93DQo+ID4+ID4+dGhleQ0KPiA+PiA+PiA+PiA+PiBjaG9vc2UNCj4gPj4gPj4gPj4g Pj4gPj4+dG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVtIGZvciAic2Vy dmljZSIgZGVsaXZlcnkuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAgUE0sIG1pa2ViaWFuY0Bhb2wu Y29tIHdyb3RlOg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24ndCBzZWUgYW55dGhp bmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdA0KPiA+PnN1Z2dlc3RzDQo+ID4+ID4+YW55DQo+ID4+ ID4+ID4+ID4+c29ydA0KPiA+PiA+PiA+PiA+PiA+Pj5vZg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0K PiA+PiA+PmVudGlyZQ0KPiA+PiA+PiA+PiA+PnBhdGgNCj4gPj4gPj4gPj4gPj4gPj4+KGFsbA0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGlu c3RhbnRpYXRpb24uICBJDQo+ID4+YmVsaWV2ZQ0KPiA+PiA+PiA+PnRoaXMNCj4gPj4gPj4gPj4g Pj4gPj4+bWVhbnMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xh c3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcg0KPiA+PiA+PiA+PmNob29zZXMgYQ0KPiA+ PiA+PiA+PiA+PlNGDQo+ID4+ID4+ID4+ID4+ID4+PiA+PkNoYWluDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gIElu IGFueQ0KPiA+PiA+PmNhc2UsDQo+ID4+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMNCj4g U0ZQDQo+ID4+ID4+IHdoZXJlDQo+ID4+ID4+ID4+ID4+IFNGSShuKQ0KPiA+PiA+PiA+PiA+PiA+ Pj4gaXMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShu LTEpIGhvcC4gIEFjY29yZGluZyB0byB0aGUNCj4gPj4gPj5kcmFmdCwNCj4gPj4gPj4gPj4gPj50 aGlzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRl cmVkICJicmFuY2hpbmciIHRvIGENCj4gbmV3DQo+ID4+IFNGUA0KPiA+PiA+PiBhcw0KPiA+PiA+ PiA+PiA+PiA+Pj4gb3Bwb3NlZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gdG8NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVj dGVkDQo+ID4+IGluc3RhbmNlDQo+ID4+ID4+IG9mDQo+ID4+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hl biBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQNCj4gPj5pcw0KPiA+ PiA+PiA+PiA+Pm5lY2Vzc2FyeQ0KPiA+PiA+PiA+PiA+PiA+Pj50bw0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdp bGwgYmUNCj4gPj4gPj51c2VkLA0KPiA+PiA+PiA+PiA+PmFuZCB0bw0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNp bmcNCj4gPj5TRidzDQo+ID4+ID4+ID4+ID4+bmV0d29yaw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGxvY2F0b3IuICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cw0K PiA+PmluDQo+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PmNyZWF0aW9uDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlz IHVzZWQgZm9yDQo+ID4+ID4+ID4+ID4+Zm9yd2FyZGluZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQDQo+ ID4+aXMNCj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0 aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJl Y2xhc3NpZmljYXRpb24NCj4gPj4ob3INCj4gPj4gPj4gPj4gPj5ub24taW5pdGlhbA0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiAgQXMgcGFja2V0 cyB0cmF2ZXJzZSBhbg0KPiA+PiA+PlNGUCwNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBy ZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQNCj4gPj5ieQ0K PiA+PiA+PmENCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5j dGlvbiBjby1yZXNpZGVudCB3aXRoIGENCj4gPj5zZXJ2aWNlDQo+ID4+ID4+ID4+ID4+ZnVuY3Rp b24uDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVz dWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYQ0KPiA+PiA+Pm5ldw0KPiA+PiA+PiA+PiA+PlNGUCwg YW4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQg bWV0YWRhdGEsIG9yIGJvdGguDQo+ID4+VGhpcyBpcw0KPiA+PiA+PiA+PiA+PnJlZmVycmVkDQo+ ID4+ID4+ID4+ID4+ID4+PnRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXMgImJyYW5j aGluZyIuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4NCj4gPj4gPj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+ ID4+DQo+ID4+ID4+ID4+DQo+ID4+ID4+DQo+ID4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+Pj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4+ Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+PiA+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4gPj4gPj4gPj4gPj4g Pj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+ID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+LS0NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPEkuU21pdGhARjUuY29tPg0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+ID4+ID4+ID4+IERpcmVj dDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4sSm9lbA0KPiA+PiA+PiA+PiA+PiBNLg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+DQo+ID4+ID4+ID4+ ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+Pg0KPiA+Pg0KPiA+Pj4+ PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbT4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1YW5n QHNjZS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4NCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPiA+PkxvYWQNCj4gPj4gPj4gPj4gPj5CYWxh bmNlcnMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0 eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMNCj4gPj4oYW5kDQo+ID4+ID4+ID4+dGhhdCBp cw0KPiA+PiA+PiA+PiA+PiA+Pj53aGF0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBt aWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlDQo+ID4+Y2hhaW5zIGlzDQo+ ID4+ID4+ID4+ID4+ID4+PnByZWNvbmNlaXZlZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g YXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZQ0KPiBidXJkZW5lZA0KPiA+ PiA+PndpdGgNCj4gPj4gPj4gPj4gdGhhdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJl Y29uY2VwdGlvbi4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVl DQo+IG9mDQo+ID4+ID4+ID4+ID4+YXNwaXJhdGlvbg0KPiA+PiA+PiA+PiA+PiB0bw0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxp ZmVzcGFuIG9mIHRoZQ0KPiA+PiA+PiA+PiA+PmFyY2hpdGVjdHVyZQ0KPiA+PiA+PiA+PiA+PiA+ Pj4tDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdo YXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcNCj4gPj4gPj50aGF0IGFuDQo+ID4+ID4+ID4+ID4+ID4+ PmFyYml0cmFyeQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFy IiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdA0KPiA+PiA+Pmlzbid0DQo+ID4+ID4+ID4+ ID4+ID4+PiA+PmludGVudGlvbmFsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGlt aXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUNCj4gPj5sYXN0aW5nDQo+ID4+ ID4+ID4+ID4+aW1wYWN0cw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNj YWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLA0KPiA+PmVsYXN0aWNpdHksDQo+ID4+ID4+ID4+ ID4+YWRkcmVzcw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRz IG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0NCj4gPj5JJ20NCj4gPj4gPj5ub3QNCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGly ZWN0DQo+ID4+ID4+W2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KPiA+PiA+PiA+PiA+PlNl bnQ6DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1 OjA0IFBNIFRvOiBJYW4gU21pdGg7DQo+ID4+Sm9lbA0KPiA+PiA+Pk0uDQo+ID4+ID4+ID4+ID4+ IEhhbHBlcm47DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24u Y2E7IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZToNCj4gPj4gPj5bc2ZjXQ0KPiA+PiA+PiA+PiA+ PlNlcnZpY2UNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vycw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBh bGwgaW4NCj4gPj4gPj50aGlzDQo+ID4+ID4+ID4+ID4+cmVnYXJkLg0KPiA+PiA+PiA+PiA+PiA+ Pj5JDQo+ID4+ID4+ID4+ID4+ID4+PiA+PmFtDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBu b3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUNCj4gPj5zb2x1dGlvbg0K PiA+PiA+PiA+PiA+PnByb2hpYml0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3lt ZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbQ0KPiA+Pm9iamVjdGluZw0KPiA+PiA+ PnRvDQo+ID4+ID4+ID4+ID4+SHVhbmcncw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVh ZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2gNCj4gZGVwbG95bWVudHMNCj4gPj4g Pj5hcmUNCj4gPj4gPj4gPj4gPj4gcmVxdWlyZWQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFt IG5vdCB0cnlpbmcgdG8NCj4gPj4gPj5wcm9oaWJpdA0KPiA+PiA+PiA+PnN1Y2gNCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBv ciBub3QNCj4gPj5kZXBlbmRzDQo+ID4+ID4+IHVwb24NCj4gPj4gPj4gPj4gPj4gbWFueQ0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0 aGUgV0cuIEkgaGFwcGVuDQo+ID4+dG8NCj4gPj4gPj4gPj50aGluaw0KPiA+PiA+PiA+PiA+PnRo YXQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+dGhleQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g YXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkg YXZvaWRpbmcNCj4gPj4gPj5hdHRlbXB0aW5nIHRvDQo+ID4+ID4+ID4+ID4+a25vdw0KPiA+PiA+ PiA+PiA+PiA+Pj53aGF0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90 IGVwbG95YWJsZS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90 ZToNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5 IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZQ0KPiA+PiB0ZW5zDQo+ID4+ID4+IG9m DQo+ID4+ID4+ID4+ID4+ID4+Pm1pbGxpb25zDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4g b2YNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBh Y2Nlc3MgbmV0d29yayBhbmQgZGF0YQ0KPiA+PiA+PiBjZW50ZXINCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZl DQo+ID4+dGhhdA0KPiA+PiA+PmluDQo+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YNCj4gdG9tb3Jy b3cNCj4gPj4gPj4geW91DQo+ID4+ID4+ID4+IGFyZQ0KPiA+PiA+PiA+PiA+PiBvbmx5DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiBnb2luZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdG8gaGF2 ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGgNCj4gPj5lcXVhbGx5DQo+ID4+ ID4+ID4+c21hbGwNCj4gPj4gPj4gPj4gPj4gPj4+IG51bWJlcnMNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2gg bGlrZSAibm8gb25lIHdpbGwgZXZlcg0KPiBuZWVkDQo+ID4+ID4+IG1vcmUNCj4gPj4gPj4gPj4g dGhhbg0KPiA+PiA+PiA+PiA+PiA+Pj4gNjRLIg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IGZvcg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBGcm9tOg0KPiA+PiA+PiBzZmMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2Zj LWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0uDQo+ID4+SGFscGVybg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBU bzoNCj4gPj4gPj4gPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsDQo+ID4+ID4+UGF0aHMsDQo+ID4+ID4+ID4+YW5kDQo+ID4+ID4+ID4+ID4+ID4+Pkxv YWQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1l YW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRvIGRlcGxveQ0KPiA+PnRoZQ0KPiA+PiA+PiA+PiA+ PiA+Pj5hcmNodGlldHVyZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhcnRpY3VsYXJs eSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzDQo+ID4+b2YNCj4gPj4gPj4gPj50 aGVpcg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1 cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoDQo+ID4+ID4+YWJzdXJkDQo+ID4+ID4+ID4+IHVzZQ0K PiA+PiA+PiA+PiA+PiBvZg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlcnZpY2UgcGF0 aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0bw0KPiA+PiA+PndyaXRlDQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBp dCwgdGhlDQo+ID4+YXJjaGl0ZWN0dXJlDQo+ID4+ID4+ID4+ZG9lcw0KPiA+PiA+PiA+PiA+PiA+ Pj5wZXJtaXQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUGxlYXNl IGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZQ0KPiA+PmFyY2h0aWVjdHVyZQ0KPiA+PiA+ PiA+PiBwZXJtaXRzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNh eWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvcg0KPiA+PiA+PnJlcXVpcmVkIGJ5DQo+ID4+ID4+ ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PndvcmsuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4gSXQgaXNuJ3QuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdj aGVuZyBIdWFuZyB3cm90ZToNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5l ZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0DQo+ID4+d2lsbA0KPiA+PiA+PiA+ Pm1lYW4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhh dCBpcyBsYXJnZXIgdGhhbiB0aGUNCj4gPj5yb3V0aW5nDQo+ID4+ID4+ID4+dGFibGUNCj4gPj4g Pj4gPj4gPj5vZiBhDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ PiBDaGFuZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4NCj4gd3Jv dGU6DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93 cyBhIHJhbmdlIG9mDQo+IGRlcGxveW1lbnRzLA0KPiA+PiA+PiBmcm9tDQo+ID4+ID4+ID4+MQ0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2 aWNlIHBhdGhzLiBJIHdvdWxkDQo+ID4+IGhvcGUNCj4gPj4gPj4gPj50aGF0DQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxl eGl0aWVzIGlmDQo+ID4+ID4+dGhleQ0KPiA+PiA+PiA+PiA+PmNob29zZQ0KPiA+PiA+PiA+PiA+ PiA+Pj50bw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBs b2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4NCj4gPj5zdGVhZA0KPiA+PiA+PiA+PiA+PiBwcm92 aXNpb24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRo cy4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwg TUFSSUEgSA0KPiA+PiB3cm90ZToNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVs LA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhDQo+ ID4+NA0KPiA+PiA+PmhvcA0KPiA+PiA+PiA+PiA+PiBzZXJ2aWNlDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBNYXJpYQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAq T24NCj4gPj4gPj4gQmVoYWxmDQo+ID4+ID4+ID4+IE9mDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5DQo+IDEw LA0KPiA+PiA+PjIwMTQNCj4gPj4gPj4gPj4gPj4zOjAzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqDQo+ID4+IGptaEBqb2VsaGFscGVybi5j b207DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsNCj4gc2ZjQGlldGYub3JnOw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG1pa2ViaWFuY0Bhb2wuY29tICpTdWJqZWN0OiogUmU6IFtzZmNdDQo+IFNlcnZpY2UNCj4gPj4g Pj4gPj4gQ2hhaW5zLA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5 b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzDQo+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g bWFrZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRo ZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlDQo+ID4+IHVzZWQNCj4gPj4gPj4gdG8NCj4gPj4gPj4g Pj4gPj4gZGVyaXZlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBm b3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkDQo+ID4+IHRyYW5zcG9ydC4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIF9u b3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZA0KPiA+PnRvDQo+ID4+ID4+ID4+ c2ltcGx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZp Y2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQNCj4gPj5wYWNrZXRzDQo+ID4+ID4+ID4+bXVzdA0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlk ZW50aWZpZXIsIHRoZQ0KPiA+PmV4YWN0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yDQo+ID4+b24NCj4g Pj4gPj4gPj50aGlzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBi ZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZQ0KPiBwYXRoDQo+ID4+ID4+ID4+ID4+IGlkZW50 aWZpZXINCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1v cmUgdGhhbiBhIGxvb2t1cCwgdGhhdA0KPiA+PiBsb29rdXANCj4gPj4gPj4gY2FuDQo+ID4+ID4+ ID4+ID4+IHJlc3VsdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9y IG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKQ0KPiB0cmFuc3BvcnQNCj4gPj4gPj4gbmV4dA0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9u IEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbQ0KPiA+PiA+PiA+PiA+PiA8bWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 cm90ZToNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRh dGUNCj4gb25seQ0KPiA+PiB1c2UNCj4gPj4gPj4gb2YNCj4gPj4gPj4gPj4gdGhlDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUg dGhlDQo+ID4+Zm9yd2FyZGluZw0KPiA+PiA+PiA+PiA+PmFjdGlvbnMuDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uDQo+ID4+ID4+ IEJlaGFsZg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4+ID4+ID4+ID4+ID4+PiAqU2VudDoqVGh1 cnNkYXksDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBKdWx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86Km1pa2ViaWFuY0Bhb2wuY29tDQo+ID4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTogW3NmY10N Cj4gPj5TZXJ2aWNlDQo+ID4+ID4+ID4+ID4+Q2hhaW5zLA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRo ZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYQ0KPiA+PnNlcnZpY2UNCj4gPj4g Pj5wYXRoDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmpl Y3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPiA+PiA+PiA+PmRlcml2ZQ0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmlu ZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbA0KPiA+PiBrbm93bGVkZ2UNCj4gPj4gPj4g b2YNCj4gPj4gPj4gPj4gPj4gZXZlcnkNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWls YWJsZSBTRkMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhz IHdpdGhpbiBhbiBTRkMtZW5hYmxlZA0KPiBkb21haW4NCj4gPj4gaXMNCj4gPj4gPj4gbm90DQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNv bnRleHRzLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUN Cj4gPj5waWVjZQ0KPiA+PiA+Pm9mDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5m b3JtYXRpb24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0 IGlzIHRoZQ0KPiBvbmUNCj4gPj4gPj4gPj4gcmVxdWlyZWQNCj4gPj4gPj4gPj4gPj4gdG8NCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBI b3cgdGhhdA0KPiA+PmluZm9ybWF0aW9uDQo+ID4+ID4+aXMNCj4gPj4gPj4gPj4gPj51c2VkIHRv DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE1lZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRl IGxhDQo+ID4+ID4+cGFydA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5j QGFvbC5jb20NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPiAqRW52b3nDqQ0KPiA+PiA6Km1lcmNyZWRpIDkNCj4gPj4gPj4gPj4gPj4ganVp bGxldA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1o QGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXQ0KPiA+PlNl cnZpY2UNCj4gPj4gPj4gPj4gPj5DaGFpbnMsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0 aW9uaW5nIHRoZSBkaWZmZXJlbmNlDQo+ID4+ID4+YmV0d2Vlbg0KPiA+PiA+PiA+PlNGDQo+ID4+ ID4+ID4+ID4+IENoYWluDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIFNGDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0DQo+ID4+ aXQncw0KPiA+PiA+PiA+PiA+PmNsZWFyIHRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB0 aG9zZSBub3QNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRo ZSBkcmFmdCwgaXQgc2VlbXMgdGhhdA0KPiA+PmV2ZXJ5b25lDQo+ID4+ID4+ID4+YWdyZWVzDQo+ ID4+ID4+ID4+ID4+b24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJt cy4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcw0K PiA+PiA+PiA+PndoZXRoZXINCj4gPj4gPj4gPj4gPj5pdCBpcw0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNp ZnkNCj4gPj4gPj53aGF0DQo+ID4+ID4+ID4+ID4+dGhlIElEDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ IHNob3VsZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNo YWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcw0KPiA+PiA+PmRyYWZ0DQo+ID4+ID4+ID4+ID4+ c2ltcGx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0 aGF0IGFtYmlndW91cywgYWxsb3dpbmcNCj4gPj5vdGhlcg0KPiA+PiA+PiA+PmRyYWZ0cw0KPiA+ PiA+PiA+PiA+PnRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUg bWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZA0KPiBvbg0KPiA+PiA+PiBjaGFpbg0KPiA+ PiA+PiA+PiBvcg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBj aG9pY2Ugb2YgY2hhaW4gb3INCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9s LXBsYW5lLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQN Cj4gPj53b3VsZA0KPiA+PiA+PiBoYXZlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g cmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkDQo+IChvcg0KPiA+PiA+ PiBtYWtlDQo+ID4+ID4+ID4+ID4+IG9uZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkDQo+IHNvbWUNCj4gPj4g Pj4gPj4gdmVuZG9ycw0KPiA+PiA+PiA+PiA+PiBvbmx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcNCj4gU0ZD Lg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+ Pg0KPiA+PiA+PiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4N Cj4gPj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+ID4+ ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiA+PiA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+ID4+ID4+ID4+ ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPiA+PiA+PiA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+Pj4+Pj4tLQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29t PGptaEBqb2VsaGFscGVybi5jb20NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+ PiA+PiA+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4u Y29tPj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxz ZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0Bp ZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQo+ID4+ID4+ID4+ICpTZW50OipUdWVzZGF5LA0KPiA+ PiA+PiA+PiA+PiBKdWx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAq U3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPiA+PiA+PmFuZA0KPiA+PiA+ PiA+PkxvYWQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0bw0KPiA+PmNsZWFybHkNCj4g Pj4gPj4gPj5hbnN3ZXINCj4gPj4gPj4gPj4gPj5hDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUNCj4gPj4gYWJvdXQN Cj4gPj4gPj4gdGhlDQo+ID4+ID4+ID4+ID4+ID4+PiBwcm9wb3NlZA0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNh bg0KPiBnZXQNCj4gPj4gPj4gPj4gd29ya2luZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsNCj4gdG8NCj4g Pj4gPj4gPj4gaW1wcm92ZQ0KPiA+PiA+PiA+PiA+PiB0aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QNCj4gPj4gcGFy dGljaXBhdGVkDQo+ID4+ID4+IGluDQo+ID4+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+IFdH DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3Ru ZCBpdCB0aGUgd2F5IHRoZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hh dCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbg0KPiA+Pm15DQo+ID4+ID4+ID4+ ID4+cGVyc29uYWwNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2Vl IGlmIHRoYXQgaGVscHMuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRv IGtlZXAgaW4NCj4gPj5taW5kDQo+ID4+ID4+dGhhdA0KPiA+PiA+PiA+PiA+PndoYXQNCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxh bmUNCj4gPj5hcmNoaXRlY3R1cmUuDQo+ID4+ID4+V2UNCj4gPj4gPj4gPj5hcmUNCj4gPj4gPj4g Pj4gPj4gbm90DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBk ZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlDQo+ID4+ID4+ZW50aXJlDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQg d291bGQNCj4gPj4gPj4gZW5jb21wYXNzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g T1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kNCj4gZnVuY3Rpb25zLA0KPiA+PiA+ PiA+PnZpcnR1YWwNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBp bWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueQ0KPiA+PiBvdGhlcg0KPiA+PiA+PiA+PiA+PiBhc3Bl Y3RzLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoDQo+ID4+ Y2xlYXJseQ0KPiA+PiA+PiBuZWVkDQo+ID4+ID4+ID4+IHRvDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUNCj4g Pj5kZWFsdA0KPiA+PiA+PndpdGgNCj4gPj4gPj4gPj4gPj5hYm92ZQ0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g ZnVuY3Rpb25pbmcsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3Qg ZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UNCj4gPj5hcmUNCj4gPj4gPj4gPj4gZG9p bmcuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlDQo+ ID4+cGF0aCwNCj4gPj4gPj4gPj5hcyBJDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dW5kZXJzdGFuZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2lu Zy4gVGhlcmUNCj4gPj4gPj5hcmUgYXQNCj4gPj4gPj4gPj4gPj5sZWFzdA0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNp bmcgY2FuDQo+ID4+YW5kDQo+ID4+ID4+ID4+d2lsbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkNCj4g Pj4gPj5hcmUNCj4gPj4gPj4gPj4gPj5tb3JlLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdA0KPiA+PmFsbCBv Zg0KPiA+PiA+PiA+PiA+PnRoZXNlLA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJ1 dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IGJlIHVzZWQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBh bnkgc29sdXRpb24uDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlk ZWQgdG8gdGhlDQo+ID4+ID4+ZW5kDQo+ID4+ID4+ID4+ID4+dXNlci4NCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMg dXNlcg0KPiA+PiA+PiA+PnBhY2tldHMsDQo+ID4+ID4+ID4+ID4+YW5kDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IG1hcmtzDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4u KSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXINCj4gPj5zZXJ2aWNlDQo+ID4+ID4+ID4+ID4+ aW5zdGFuY2UNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1 c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4NCj4gPj5pbXBvcnRhbnQNCj4gPj4gPj4gPj4gPj5zZXJ2 aWNlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0 byBpbmNsdWRlIGluIHNlcnZpY2UNCj4gPj4gPj5jaGFpbmluZy4NCj4gPj4gPj4gPj4gPj5JdCdz DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1 aXJlbWVudHMgb24gaG93DQo+ID4+IHNlcnZpY2UNCj4gPj4gPj4gPj4gPj4gY2hhaW5pbmcgaXMN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0 dGxlIGltcGFjdCBvbiB0aGUNCj4gPj4gPj4gPj4gPj5hcmNodGllY3R1cmUuDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gIEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUg aXQgaXMNCj4gPj5zaW1wbHkNCj4gPj4gPj5hDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBz ZXJ2aWNlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5 IG1vZGlmeSB0aGUgdW5kZXJseWluZw0KPiA+PiBwYWNrZXQuDQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBp bnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywNCj4gPj5vbmUNCj4gPj4gPj4gPj5jYW4N Cj4gPj4gPj4gPj4gPj5oYXZlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhDQo+ID4+ c2luZ2xlDQo+ID4+ID4+ID4+cG9pbnQNCj4gPj4gPj4gPj4gPj5vZg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBh DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlv biwgYnV0IGlzIGFjdHVhbGx5DQo+ID4+ID4+ZGVsaXZlcmVkDQo+ID4+ID4+ID4+ID4+YnkgYQ0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlvbiBvZg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5DQo+ ID4+aW5jbHVkaW5nDQo+ID4+ID4+ID4+b25lIG9yDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcNCj4gPj4gPj5W UlJQLWxpa2UNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNo YXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksDQo+ID4+IHRoaXMNCj4gPj4gPj5pcw0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBkYXRhIHBsYW5lDQo+ID4+ID4+ID4+ID4+bWVjaGFuaXNtcy4NCj4gPj4gPj4gPj4gPj4gSXQN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNp YmxlIHRvIHZhcmlvdXMNCj4gPj5jb250cm9sDQo+ID4+ID4+ID4+ID4+bWVjaGFuaXNtcywNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZv ciBzY2FsZS1pbiwNCj4gPj4gPj5zY2FsZS1vdXQsDQo+ID4+ID4+ID4+YW5kDQo+ID4+ID4+ID4+ ID4+dm0NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUg YXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4gPj4gPj4gPj5wZXJtaXR0aW5nDQo+ID4+ID4+ID4+ ID4+dGhpcw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3 ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4gPj4gPj4gPj4gPj50ZXJtaW5vbG9neQ0K PiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBi ZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5DQo+ID4+ID4+ID4+c2VsZWN0aW5nDQo+ID4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmlu ZyB0aGF0DQo+ID4+ZGlyZWN0DQo+ID4+ID4+ID4+ID4+dHJhZmZpYw0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRv DQo+ID4+IHJlcXVpcmUNCj4gPj4gPj4gPj4gdGhhdA0KPiA+PiA+PiA+PiA+PmENCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBv bmx5IG9uZQ0KPiA+PnBsYWNlDQo+ID4+ID4+aW4NCj4gPj4gPj4gPj50aGUNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBj YXNlIHRoYXQgdGhlc2UgbWF5IGJlDQo+ID4+ID4+ID4+Y29tYmluZWQuIEkNCj4gPj4gPj4gPj4g Pj4gdGVuZA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo ZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvDQo+ID4+c2VydmljZQ0KPiA+ PiA+PiA+PiA+PmNoYWluaW5nDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBz aW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZQ0KPiA+PiA+PmNsdXN0ZXINCj4g Pj4gPj4gPj5pcw0KPiA+PiA+PiA+PiA+PmENCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUNCj4gYW5vdGhlcg0KPiA+PiBv bmUuDQo+ID4+ID4+ID4+IFRodXMsDQo+ID4+ID4+ID4+ID4+IHRoZQ0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPiA+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBk aXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0bw0KPiA+PmRpZmZlcmVudA0KPiA+ PiA+PiA+PiA+PnNpbmd1bGFyDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1 c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudA0KPiA+PiA+PnBsYWNlcw0KPiA+ PiA+PiA+PmluDQo+ID4+ID4+ID4+ID4+dGhlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbmV0d29yay4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hl biBJDQo+IHRhbGsNCj4gPj4gPj4gYWJvdXQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4NCj4gPj5pcw0K PiA+PiA+PmENCj4gPj4gPj4gPj4gPj4gc2VxdWVuY2UNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGENCj4gPj5zdWJz ZXQgb2YNCj4gPj4gPj4gPj4gPj5wYWNrZXRzLg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YNCj4gPj4g Pj4gPj50cmFmZmljDQo+ID4+ID4+ID4+ID4+aXMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQNCj4gPj4g Pj4gPj5maXJld2FsbA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlm ZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0bw0KPiA+PnRoZQ0KPiA+PiA+PiA+PmNh Y2hlDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUNCj4gPj4gPj4g Pj5wYWNrZXRzLg0KPiA+PiA+PiA+PiBBDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g c2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2UNCj4gPj5vZg0KPiA+ PiA+PiA+PiA+PmxvY2F0aW9ucw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRo ZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZQ0KPiA+PnNpbmd1bGFyDQo+ID4+ID4+ b3INCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBmdW5j dGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuDQo+ID4+ID4+VGhleQ0KPiA+PiA+PiA+PiA+Pm1heSBi ZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNz LiBUaGV5IG1heSBiZQ0KPiA+PiBhZGRyZXNzZWQgYXMNCj4gPj4gPj4gPj4gcG9ydHMNCj4gPj4g Pj4gPj4gPj4gb24NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJl IGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQNCj4gdGhlDQo+ID4+ID4+ID4+ID4+bG9jYXRp b25zDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBz ZXJ2aWNlIGNoYWluaW5nDQo+ID4+ID4+IGluZnJhc3RydWN0dXJlDQo+ID4+ID4+ID4+IGFuZA0K PiA+PiA+PiA+PiA+PiB0aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmFuc3Bv cnQuDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pj4gIEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlDQo+ ID4+U0ZDDQo+ID4+ID4+ID4+Z3JvdXAsDQo+ID4+ID4+ID4+ID4+IHdlDQo+ID4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sDQo+ID4+ ID4+dGhlDQo+ID4+ID4+ID4+ID4+c2VydmljZQ0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZQ0KPiA+PiBuZWVk DQo+ID4+ID4+dG8NCj4gPj4gPj4gPj4gdGFsaw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlDQo+ID4+aW4N Cj4gPj4gPj50aGUNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlDQo+ID4+IHdob2xl DQo+ID4+ID4+ID4+IHBhdGgNCj4gPj4gPj4gPj4gPj4gbWF5DQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJl DQo+ID4+ID4+ZGVhbHMNCj4gPj4gPj4gPj4gPj53aXRoDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluDQo+ID4+ aXRlbQ0KPiA+PiA+PigyKQ0KPiA+PiA+PiA+Pm9uDQo+ID4+ID4+ID4+ID4+bG9hZA0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRl Y2lzaW9ucyBhbmQNCj4gPj4gPj4gPj5iZWhhdmlvcnMNCj4gPj4gPj4gPj4gPj4gd2hpY2gNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nDQo+ID4+bWVjaGFuaXNtcw0KPiA+PiA+Pihpbg0KPiA+PiA+PiA+PiA+Pm11Y2gN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2lu ZyB3aXRoaW4gYSBMQU4gaXMNCj4gPj4gPj5sYXJnZWx5DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+ ID4+ID4+ID4+IHByb3Zpc2lvbg0KPiA+PiA+PiA+PiA+PiB3ZQ0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4g Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25l IGluIG1pZC1jaGFpbg0KPiB3aGVuDQo+ID4+ID4+ID4+ID4+IG5lY2Vzc2FyeS4NCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcg Y2hhaW4uIEJhc2VkDQo+ID4+IG9uDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5m b3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPiA+PiA+PiA+PnBv aW50Lg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlDQo+ ID4+YWZ0ZXIuDQo+ID4+ID4+ID4+SWYgaXQNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZQ0KPiA+PiA+Pndv cmtpbmcNCj4gPj4gPj4gPj4gPj4gZ3JvdXAsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZQ0KPiA+PiA+PiBu ZWVkZWQNCj4gPj4gPj4gPj4gdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252 ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUNCj4gPj53aXRoDQo+ID4+ID4+ dGhlDQo+ID4+ID4+ID4+ID4+IGludGVudCwNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUNCj4gPj4gPj53b3Jr aW5nDQo+ID4+ID4+ID4+ID4+Z3JvdXANCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh Z3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90DQo+ID4+ID4+c3Vy ZQ0KPiA+PiA+PiA+PiA+PndoYXQgdG8NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 cnkgbmV4dC4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiA+PiBzZmMN Cj4gPj4gPj4gPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gPj4gc2ZjDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBt YWlsaW5nDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ID4+ID4+IHNmYw0KPiA+PiA+PiA+PiA+PiA+ Pj4gPj4gbWFpbGluZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0 Zi5vcmcNCj4gPj4gPj4gPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gc2ZjDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ IGxpc3Qgc2ZjQGlldGYub3JnDQo+ID4+ID4+ID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ ID4+IHNmYw0KPiA+PiA+PiA+PiA+PiA+Pj4gbWFpbGluZw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4g bGlzdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiA+PiBzZmMNCj4gPj4gPj4gPj4gPj4gPj4+IG1haWxpbmcNCj4gPj4gPj4g Pj4gPj4gPj4+ID4+IGxpc3QNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9y Zw0KPiA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+IHNm Yw0KPiA+PiA+PiA+PiA+PiBtYWlsaW5nDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZw0KPiA+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+ID4+IHNmYw0KPiA+PiA+PiA+PiA+PiBtYWlsaW5nDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0Bp ZXRmLm9yZw0KPiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4g Pj4gPj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+Pg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYu b3JnDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4gPj4+ ID4+ID4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+DQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5n IGxpc3QNCj4gPj4gPj4gPj4gPj4gPj4+ID4+ID5zZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gPj4g Pj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiA+ PiA+PiA+PiA+Pj4gPj4NCj4gPj4gPj4gPj4gPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+ID4+ID4+ID4+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmcNCj4gPj4gPj4gPj4g Pj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gPj4gPj4gPj4+IHNmYyBtYWlsaW5nIGxp c3QNCj4gPj4gPj4gPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+PiA+PiA+PiA+PiA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gPj4gPj4gPj4gPg0K PiA+PiA+PiA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gPj4gPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gPj4gPj4gPj4gPnNm Y0BpZXRmLm9yZw0KPiA+PiA+PiA+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPj4gPj4gPg0KPiA+PiA+DQo+ID4NCg0K From nobody Fri Jul 11 10:24: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 2342F1A0AEE for ; Fri, 11 Jul 2014 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 THzWVM800f7z for ; Fri, 11 Jul 2014 10:23:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312631A0AE6 for ; Fri, 11 Jul 2014 10:23:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJW36679; Fri, 11 Jul 2014 17:23:55 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Jul 2014 18:23:51 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Fri, 11 Jul 2014 10:23:44 -0700 From: Lucy yong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHID///EV4AAP5B4AAACNtoAAAGwJAAAA+u8AAAEZogAAACsQgAAANv0AAAA3lIAADkKxEA== Date: Fri, 11 Jul 2014 17:23:44 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BF11D@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.160] 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/tDZ8Hv5Wo3ue2guxPuyWEvhti5k Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 17:24:04 -0000 SSBsaWtlIHRvIHJlc3RhdGUgbXkgb3Bpbmlvbi4NCg0KVGhlIGFyY2ggZG9jLiBzaG91bGQgbm90 IG1hbmRhdGUgb25seSB1c2Ugb2Ygc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhl IGZvcndhcmRpbmcgYWN0aW9ucywgaS5lLiB0aGUgZm9yd2FyZGluZyBsb29rdXAuDQoNCkFsdGhv dWdoIHNvbWUgc29sdXRpb24gZHJhZnQgcHJvcG9zZXMgdGhhdCBhbmQgc29tZSBwZW9wbGUgbGlr ZSBQYXVsIGFuZCBKaW0gYXMgY28tYXV0aG9yIG9mIHRoZSBkcmFmdCAobnNoKSBleHBsYWluIHRo YXQsIHRoYXQgaXMgb25lIHNvbHV0aW9uIGRlc2lnbi4gVGhlIGFyY2ggZG9jIGNsZWFybHkgc3Rh dGVzIHRoYXQgaXQgZG9lcyBub3QgcHJvcG9zZSB0aGUgc29sdXRpb25zLiANCg0KSW4gZmFjdCwg ZHJhZnQtbnVpLXNmYy1tZWNoYW5pc20gcHJvcG9zZXMgYW5vdGhlciB3YXkgdG8gaW1wbGVtZW50 IFNGQyB3aGljaCB1c2VzIGJvdGggc2VydmljZSBwYXRoIGlkZW50aWZpZXIgYW5kIFNGIElEIGlu IGZvcndhcmRpbmcgYWN0aW9ucy4NCg0KUGVvcGxlIGFsc28gcHJvcG9zZWQgdGhlIHNvbHV0aW9u IG9uIG1haWwgZGlzY3Vzc2lvbiB0aGF0IGRvZXMgbm90IHVzZSB0aGUgc2VydmljZSBwYXRoIGlk ZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcgYWN0aW9ucy4gIFNvIHdlIHNob3VsZCBu b3QgbWFrZSBhIHNvbHV0aW9uIGFzc3VtcHRpb24gaW4gYXJjaCBkb2MuDQoNCkJUVzogSU1PLCB3 ZSBzaG91bGQgc2VwYXJhdGUgdGhlIGZvcndhcmRpbmcgYWN0aW9ucyBhbmQgbG9hZCBiYWxhbmNl IGFjdGlvbnMuIExvYWQgYmFsYW5jaW5nIGRpc2N1c3NlZCBoZXJlIGhhcHBlbnMgd2hlbiBzZXZl cmFsIG5leHQgaG9wcyBleGlzdCBhZnRlciBmb3J3YXJkaW5nIGxvb2t1cC4gKHRoaXMgaXMgbm90 IGFib3V0IGxvYWQgYmFsYW5jaW5nIGFzIGEgU0YpLg0KDQpMdWN5ICANCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiBGcmlkYXksIEp1 bHkgMTEsIDIwMTQgMTE6NDQgQU0NClRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCg0KSSBhbSBub3QgcHJvcG9zaW5nIGEgc29sdXRpb24gKHRoYXTigJlzIHRoZSBX R+KAmXMgam9iKSBidXQgc2ltcGx5IHVzaW5nIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBhcmNo aXRlY3R1cmUgdG8gbW92ZSB0aGUgZGlzY3Vzc2lvbiBmb3J3YXJkLg0KDQpZZXMsIGl0IGlzIHN0 aWxsIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgZm9yIHRoZSByZWFzb25zIHRoYXQgSm9lbCBt ZW50aW9uZWQgaW4gYW5vdGhlciBlbWFpbC4NCg0KT24gNy8xMS8xNCwgMTI6MzcgUE0sICJOQVBJ RVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3JvdGU6DQoNCj4+ID4+IEkgdGhpbmsg b2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYQ0K Pj5wb2ludGVyDQo+PiA+PnRvDQo+PiA+PiBhIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMg U0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91DQo+PiBkZWZpbmUNCj4+ID5Zb3UgYXJl IHRhbGtpbmcgYWJvdXQgdHJhZmZpYyBlbmdpbmVlcmluZyBvZiBwYXRocyB0aGF0IGEgc2Vydmlj ZSANCj4+ID5jaGFpbiBjYW4gdGFrZS4NCj4+ID5UaGlzIHN1cmVseSBjb3VsZCBiZSBkb25lL2Fs bG93ZWQgYnV0IHRoaXMgY2Fubm90IGJlIGEgcmVxdWlyZW1lbnQgDQo+PiA+Zm9yIGFsbCB0cmFm ZmljLg0KPj4gDQo+PiBKaW0+IHRoYXTigJlzIHdoeSBJIHNhaWQgKm1pZ2h0KiAtIElPVyB5b3Ug ZG8gbm90IGhhdmUgdG8sIGl0cyBhDQo+PmRlcGxveW1lbnQNCj4+IGNob2ljZSBhbmQgaXMgc3Vw cG9ydGVkIGJ5IHRoZSBhcmNoaXRlY3R1cmUuDQo+DQo+WWVzLCBJIG5vdGljZWQsIGJ1dCBJIGFs c28gbm90aWNlZCB0aGF0IHlvdSBhcmUgcHJvcG9zaW5nIGEgc29sdXRpb24gDQo+YmFzZWQgb24g aXQuDQo+DQo+WW91IGhhdmUgbm90IGNvbW1lbnQgb24gdGhlIHJlc3Q6IGlzIGl0IHN0aWxsICJz ZXJ2aWNlICpwYXRoKiBpZGVudGlmaWVyIj8NCj4NCj5NYXJpYQ0KPg0KPj4gPj4gT24gNy8xMS8x NCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4NCj4+IHdy b3RlOg0KPj4gPj4NCj4+ID4+ID5KaW0sDQo+PiA+PiA+DQo+PiA+PiA+Q291bGQgeW91IHRlbGwg dXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCANCj4+ID4+ ID5hICJzZXJ2aWNlIHBhdGggaWRlbnRpZmllciI/DQo+PiA+PiA+SWYgYSBzZXJ2aWNlIHBhdGgg bWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYXByaW9yaQ0KPj4gPj4od2hp Y2gNCj4+ID4+ID5pcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNG RidzIGxvY2FsIGRlY2lzaW9uDQo+PndoaWNoDQo+PiA+PiA+bmV4dC1ob3AgU0ZGIHRvIHBpY2su ICBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPj4gPj4gPg0KPj4gPj4gPk1hcmlhDQo+ PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNj by5jb21dDQo+PiA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+ ID4+ID4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b207IEpvZWwgTS4NCj4+ID4+ID4+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0K Pj4gPj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+Pg0KPj4gPj4gPj4gSeKAmW0gc29ycnkgYnV0IEkgcmVhbGx5 IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgNCj4+aWRlbnRpZmllcg0KPj4g Pj4gPj4gcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBj YWxsaW5nIGl0IGENCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4gY2hhaW4gaWRlbnRpZmllciBtYWtl cyBhbnkgZGlmZmVyZW5jZT8NCj4+ID4+ID4+DQo+PiA+PiA+PiBPbiA3LzExLzE0LCAxMDo1OCBB TSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPg0KPj4gPj4gd3JvdGU6DQo+ PiA+PiA+Pg0KPj4gPj4gPj4gPkRpdHRvLg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20gDQo+PiA+PiA+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb21dDQo+PiA+PiA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0N Cj4+ID4+ID4+ID4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uDQo+PkhhbHBlcm47DQo+PiA+PiBSb24NCj4+ID4+ID4+ID4+IFBhcmtlcjsg c2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+PiBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBS ZS0sDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3Qg dGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gDQo+PiA+PiA+PiA+PiB0aGUNCj4+ID4+ ID4+ZHJhZnQuDQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBw YXRoIGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0DQo+PnRoZQ0KPj4gPj5mdWxs DQo+PiA+PiA+PiA+PmRpc3RyaWJ1dGVkDQo+PiA+PiA+PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dl ZC4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiBTZXZlcmFsIHZvaWNlcyBpbiB0aGlzIHRocmVh ZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSANCj4+ID4+ID4+ID4+IGNoYWluDQo+PiA+Pml0 c2VsZg0KPj4gPj4gPj4gPj5zaG91bGQgYmUNCj4+ID4+ID4+ID4+IHByb3ZpZGVkIGluc3RlYWQu DQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4gPj4gQ2hlZXJzLA0KPj4gPj4gPj4gPj4gTWVkDQo+PiA+ PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZSA6IHNm YyANCj4+ID4+ID4+ID4+ID5bbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIEppbQ0KPj5HdWljaGFyZA0KPj4gPj4gPj4gPj4gPihqZ3VpY2hhcikNCj4+ID4+ID4+ID4+ ID5FbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4IMOAIDogTkFQSUVSQUxB LCANCj4+ID4+ID4+ID4+ID5NQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+ PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4gPj4gPg0KPj4gPj4gPj4g Pj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlz DQo+PiA+PmZ1bmN0aW9uYWxpdHkNCj4+ID4+ID4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2Fu dCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byANCj4+ID4+ID4+ID4+ID4qYWxsKg0K Pj4gPj5TRkbigJlzDQo+PiA+PiA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVu IGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIA0KPj4gPj4gPj4gPj4gPnBvaW50DQo+PnRvIGENCj4+ ID4+ID4+ID4+bG9va3VwDQo+PiA+PiA+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVh Y2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIA0KPj4gPj4gPj4gPj4gPmFtDQo+Pm5vdA0K Pj4gPj4gPj5zdXJlDQo+PiA+PiA+PiA+Pmhvdw0KPj4gPj4gPj4gPj4gPnRoZSBhcmNoaXRlY3R1 cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+ID5PbiA3LzExLzE0 LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+PiA+PiA+ PiB3cm90ZToNCj4+ID4+ID4+ID4+ID4NCj4+ID4+ID4+ID4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ ID4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4+ID4+ID4+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEppbQ0KPj4gPj5HdWljaGFyZA0KPj4gPj4gPj4gPj4gPj4+KGpndWljaGFyKQ0K Pj4gPj4gPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+PiA+ PiA+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOw0KPj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+PiA+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+QmFsYW5jZXJzDQo+PiA+ PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJv cG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IA0KPj4gPj4gPj4gPj4gPj4+IHNlZW1zDQo+PnRvDQo+ PiA+Pm1lDQo+PiA+PiA+PiA+PnRoYXQgaWYNCj4+ID4+ID4+ID4+ID4+PiB5b3UgYWxsb3cgYW4g U0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgDQo+PiA+PiA+PiA+PiA+ Pj4gU0ZGDQo+Pml0DQo+PiA+PiA+PndpbGwNCj4+ID4+ID4+ID4+dXNlDQo+PiA+PiA+PiA+PiA+ Pj5mb3INCj4+ID4+ID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Yg d2l0aGluIHRoZSBjaGFpbiB0aGVuIA0KPj4gPj4gPj4gPj4gPj4+eW91DQo+PiA+PiA+PmJldHRl cg0KPj4gPj4gPj4gPj5tYWtlDQo+PiA+PiA+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3Rl IFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nDQo+PmxvZ2ljDQo+PiA+PnRvDQo+PiA+ PiA+PiA+PnJlYWNoDQo+PiA+PiA+PiA+PiA+Pj50aGUNCj4+ID4+ID4+ID4+ID4+PiBuZXh0LW5l eHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwDQo+PiA+PnRy b3VibGUuDQo+PiA+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4 IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIg0KPj4gPG1uMTkyMUBhdHQuY29tPg0KPj4gPj4gPj4g Pj4gd3JvdGU6DQo+PiA+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+QWJzb2x1dGVseSBu b3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSANCj4+ID4+ID4+ID4+ ID4+PiA+aW4NCj4+ID4+ID4+cmVsZXZhbnQNCj4+ID4+ID4+ID4+ID4+PlNGRnMNCj4+ID4+ID4+ ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4gPj4gPj4gPj4gPj4+ID4NCj4+ID4+ID4+ ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4gPj4gPj4+ID4+ IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gSmltDQo+PiA+PiA+Pkd1aWNoYXJkDQo+PiA+PiA+PiA+PiA+Pj4g Pj4oamd1aWNoYXIpDQo+PiA+PiA+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAy MDE0IDk6MjcgQU0NCj4+ID4+ID4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3Nm Y10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gPj5CYWxhbmNlcnMNCj4+ID4+ ID4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+IFdlbGwgSSB0aGluayBpdCBpcyBldmVu IHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUNCj4+ID4+dW5kZXJzdG9vZA0KPj4gPj4gPj50aGUN Cj4+ID4+ID4+ID4+ID4+PiA+PnByb3Bvc2FsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gY29ycmVjdGx5 IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4+ID4+c2luZ2xl DQo+PiA+PiA+PlNGDQo+PiA+PiA+PiA+PiA+Pj53aXRoaW4NCj4+ID4+ID4+ID4+ID4+PiA+PnRo ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBT RkYgYXMgdGhlcmUgaXMgbm8NCj4+d2F5IHRvDQo+PiA+PiA+Pmtub3cNCj4+ID4+ID4+ID4+YQ0K Pj4gPj4gPj4gPj4gPj4+ID4+cHJpb3JpDQo+PiA+PiA+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZDwrlz IGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueQ0KPj5naXZlbg0KPj4gPj4g Pj5wb2ludA0KPj4gPj4gPj4gPj5pbg0KPj4gPj4gPj4gPj4gPj4+dGltZS4NCj4+ID4+ID4+ID4+ ID4+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBN LiBIYWxwZXJuIg0KPj4gPj4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+PiA+PiB3cm90 ZToNCj4+ID4+ID4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5Sb24sIHRoaW5raW5n IGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvcg0KPj5wcm9ibGVtDQo+PiA+PiA+ PndpdGgNCj4+ID4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj55b3VyDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gIChBbmQgSSByZWFkaWx5IGFk bWl0IEkNCj4+bWF5DQo+PiA+Pm5vdA0KPj4gPj4gPj4gPj4gPj4+dW5kZXJzdGFuZA0KPj4gPj4g Pj4gPj4gPj4+ID4+ID5pdC4pDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2Vy DQo+PmZvcg0KPj4gPj50aGUNCj4+ID4+ID4+ID4+bmV4dA0KPj4gPj4gPj4gPj4gPj4+ID4+ID5z ZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQNCj4+ZGVsaXZl cnMNCj4+ID4+ID4+dG8pLA0KPj4gPj4gPj4gPj5pbg0KPj4gPj4gPj4gPj4gPj4+ZXZlcnkNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBi ZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID50 aGF0DQo+PiA+Pm1lYW5zDQo+PiA+PiA+PiA+PnRoYXQNCj4+ID4+ID4+ID4+ID4+PiA+PmV2ZXJ5 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBz ZW5zaXRpdmUgYW5kDQo+PnN0YXRlZnVsDQo+PiA+PmxvYWQNCj4+ID4+ID4+ID4+ID4+PmJhbGFu Y2VyLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBh cmUgZmxvdyBzZW5zaXRpdmUsIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID5hbmQNCj4+LyBvcg0KPj4g Pj4gPj4gPj5zdGF0ZWZ1bC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJj aGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPmJl IGENCj4+ID4+ZnVsbCwNCj4+ID4+ID4+ID4+Zmxvdw0KPj4gPj4gPj4gPj4gPj4+ID4+ID5zZW5z aXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRvIG1lIHRvIGJlIA0KPj4gPj4g Pj4gPj4gPj4+ID4+ID5hbg0KPj4gPj4gPj4gPj5hY2NlcHRhYmxlDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPmltcG9zaXRpb24uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID5Zb3VycywNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4N Cj4+ID4+ID4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVy biB3cm90ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcg aXMgdGhhdCBJIGFtIHRyeWluZyB0byANCj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBtYWtlDQo+PiA+ PnRoaXMNCj4+ID4+ID4+d29yaw0KPj4gPj4gPj4gPj4gPj4+ID4+c2Vuc2libHkNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiAgSSBleHBl Y3QgdGhhdA0KPj50aGUNCj4+ID4+ID4+c2VydmljZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IGZ1 bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZGDQo+PmNhcGFiaWxpdGllcywN Cj4+ID4+ID4+d2lsbA0KPj4gPj4gPj4gPj5iZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IG9yY2hl c3RyYXRlZCBhbmQgaW5zdGFsbGVkLiAgSSBleHBlY3QgdGhlIHNlcnZpY2UNCj4+Y2hhaW5zDQo+ PiA+PiA+PnRvIGJlDQo+PiA+PiA+PiA+PiA+Pj4gPj5kcml2ZW4gYnkNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMsIGFuZA0K Pj5lbmFibGUNCj4+ID4+ID4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4gZnJvbSB0aGVzZS4gIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseQ0K Pj5wb2xpY3kNCj4+ID4+ID4+ID4+ZHJpdmUuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBp biBhbg0KPj4gPj5hcmNodGllY3R1cmUNCj4+ID4+ID4+ID4+ZHJpdmVuDQo+PiA+PiA+PiA+PiA+ Pj5ieQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVz Y3JpYmVkIHNlcnZpY2UgcGF0aHMuDQo+Pkl0DQo+PiA+PmlzDQo+PiA+PiA+PiA+PmhhcmRlcg0K Pj4gPj4gPj4gPj4gPj4+dG8NCj4+ID4+ID4+ID4+ID4+PiA+PnNlZQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZQ0K Pj5hbGxvdw0KPj4gPj4gbW9yZQ0KPj4gPj4gPj4gPj4gPj4+ID4+IGR5bmFtaWNpdHkNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IEhhdmluZyBzYWlkIHRoYXQsIG1vc3Qgb2Yg dGhhdCBwZXJzcGVjdGl2ZSBJDQo+PmRlc2NyaWJlZA0KPj4gPj5pcw0KPj4gPj4gPj4gPj5vdXRz aWRlDQo+PiA+PiA+PiA+PiA+Pj5vZg0KPj4gPj4gPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBpdCBpcyBub3Qgc29tZXRo aW5nIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IHdlDQo+PmFyZQ0KPj4gPj4gPj4gPj50YXNrZWQg dG8NCj4+ID4+ID4+ID4+ID4+PiA+PmFncmVlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj5vbi4NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3 ZSBoYXZlIHRvIGRvIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+aXQNCj4+YQ0KPj4gPj4gPj5jZXJ0 YWluDQo+PiA+PiA+PiA+PiA+Pj53YXkuDQo+PiA+PiA+PiA+PiA+Pj4gPj5pdA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZl cmVuY2VzLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gWW91 cnMsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4gSm9lbA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3Rl Og0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0 aW9uIGFib3V0IHNlcnZpY2UNCj4+ID4+IGluc3RhbmNlcw0KPj4gPj4gPj4gPj4gdGhhdA0KPj4g Pj4gPj4gPj4gPj4+ID4+bmVlZHMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+dG8NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PnBvdGVudGlhbGx5DQo+PiBldmVuDQo+PiA+PiA+PiA+PmFj cm9zcw0KPj4gPj4gPj4gPj4gPj4+ZGF0YQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVy cyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlDQo+PiA+PmVub3VnaA0K Pj4gPj4gPj5hbmQNCj4+ID4+ID4+ID4+ID4+PiBjb21wbGV4DQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiANCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+IHNlZW1zDQo+PiA+Pmxpa2UgYQ0KPj4gPj4gPj4gPj4gPj4+ZGlm ZmljdWx0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4N Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlv dXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCANCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4gdGhhbg0KPj4gPj4gPj5keW5hbWljDQo+PiA+PiA+PiA+PiA+Pj4gcm91dGluZywNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlv biwgb3IgRE5TLCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gYWxsDQo+Pm9mDQo+PiA+PiA+Pndo aWNoDQo+PiA+PiA+PiA+PmFyZQ0KPj4gPj4gPj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJs eQ0KPj4gPj4gaW1wbGVtZW50ZWQ/DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSANCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4gY29tcGxpY2F0ZWQsDQo+PiA+PnRoYXQNCj4+ID4+ID4+aXMN Cj4+ID4+ID4+ID4+YQ0KPj4gPj4gPj4gPj4gPj4+Z29vZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ PiBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBb am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9u IFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsNCj4+IG1pa2ViaWFuY0Bhb2wuY29tOw0KPj4g Pj4gPj5JYW4NCj4+ID4+ID4+ID4+ID4+PlNtaXRoOw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBz ZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBMb2FkDQo+ PiA+PiA+PkJhbGFuY2Vycw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuICBBbmQgb25lIHRoYXQgSQ0K Pj53b3VsZA0KPj4gPj4gPj5wcmVmZXINCj4+ID4+ID4+ID4+d2UNCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj5hY3R1YWxseQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFu IHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGUNCj4+ID4+ID4+ID4+aW1wbGVtZW50YXRpb25z Lg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVm ZmVjdCBvbiB0aGUgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IGNvbnRyb2wNCj4+ID4+ID4+ID4+ cmVxdWlyZW1lbnRzDQo+PiA+PiA+PiA+PiA+Pj5hbmQNCj4+ID4+ID4+ID4+ID4+PiA+PiB0aGUN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQg b2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPj4gPj4gaW5zdGFuY2VzDQo+PiA+PiA+PiA+ PnRoYXQNCj4+ID4+ID4+ID4+ID4+PiBuZWVkcw0KPj4gPj4gPj4gPj4gPj4+ID4+IHRvDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwg cG90ZW50aWFsbHkNCj4+ZXZlbg0KPj4gPj4gPj4gYWNyb3NzDQo+PiA+PiA+PiA+PiA+Pj5kYXRh DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZl IHNjb3BlLCBpcyBsYXJnZQ0KPj5lbm91Z2gNCj4+ID4+ID4+YW5kDQo+PiA+PiA+PiA+PiA+Pj5j b21wbGV4DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQg dGhhdCBpbnRvIGVhY2ggU0ZGIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBzZWVtcw0KPj4gPj5s aWtlIGENCj4+ID4+ID4+ID4+ID4+PmRpZmZpY3VsdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiBh cmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFp ciBxdWVzdGlvbi4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBl bmQNCj4+ID4+ID4+c2VsZWN0aW9uDQo+PiA+PiA+PiA+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSANCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+IChwZXJoYXBzDQo+PmJ5DQo+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ ID4+Y2xhc3NpZmllcikNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBl cmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kDQo+PiA+PiBzdWJzZXF1ZW50bHkNCj4+ID4+ID4+ ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj5TRkZzKT8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvDQo+PnJlY2xhc3NpZmljYXRpb24u DQo+PiA+PiA+PkFuZA0KPj4gPj4gPj4gPj4gPj4+c3VyZWx5LA0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gdG8gImltcGxlbWVudGF0aW9uIi4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBm YXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2gNCj4+IGV2ZW4NCj4+ID4+ID4+IHRob3VnaA0K Pj4gPj4gPj4gPj4gYQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2Yg ZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kDQo+PnBlcmhhcHMNCj4+ID4+ID4+bG9jYWwNCj4+ ID4+ID4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5 KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+IGRlY2lzaW9uDQo+PiA+PnBvaW50cy4NCj4+ID4+ID4+ID4+VGhpcw0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGgg aWQgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBhdA0KPj4gPj5hbGwuDQo+PiA+PiA+PiA+Pk15 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBw cm9hY2ggaXMgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBwcmltYXJpbHkNCj4+ID4+ZHJpdmVu DQo+PiA+PiA+PmJ5DQo+PiA+PiA+PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guDQo+ PldpdGggYQ0KPj4gPj4gPj5nbG9iYWwNCj4+ID4+ID4+ID4+ID4+PnBhdGgNCj4+ID4+ID4+ID4+ ID4+PiA+PmlkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFp bHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQNCj4+bmVlZGluZw0KPj4gPj50bw0KPj4gPj4gPj4gPj5h bHRlcg0KPj4gPj4gPj4gPj4gPj4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBnbG9iYWwg cGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQNCj4+ID4+ID4+ZW5kLXRv LWVuZA0KPj4gPj4gPj4gPj4gPj4+cGF0aC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IEZyb206DQo+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRm Lm9yZ10gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybg0KPj4gPj5EaXJlY3QNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gU2VudDogVGh1cnNkYXks IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gSnVseQ0KPj4xMCwNCj4+ID4+ID4+MjAxNA0KPj4g Pj4gPj4gPj4gNjoxNQ0KPj4gPj4gPj4gPj4gPj4+IFBNDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ PiBUbzogbWlrZWJpYW5jQGFvbC5jb207IEkuU21pdGhARjUuY29tOyANCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gPj4gU3ViamVjdDoNCj4+ID4+ID4+ID4+IFJl Og0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNG MQ0KPj4gPj5uZWVkaW5nDQo+PiA+PiA+PnRvDQo+PiA+PiA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyBy ZWNsYXNzaWZpY2F0aW9uIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gYXQNCj4+dGhlDQo+PiA+ PiA+PmV4aXQNCj4+ID4+ID4+ID4+ZnJvbQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQgb2Yg dGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4gZnVuY3Rpb25zDQo+PiA+PiA+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+PiBob3cNCj4+ID4+dGhleQ0KPj4gPj4gPj4gPj4gY2hvb3NlDQo+ PiA+PiA+PiA+PiA+Pj50bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVtIGZv ciAic2VydmljZSIgZGVsaXZlcnkuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNv bSB3cm90ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBp biB0aGUgYXJjaCBkcmFmdCB0aGF0DQo+PnN1Z2dlc3RzDQo+PiA+PmFueQ0KPj4gPj4gPj4gPj5z b3J0DQo+PiA+PiA+PiA+PiA+Pj5vZg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBI b3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCANCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiB0aGUNCj4+ID4+ZW50aXJlDQo+PiA+PiA+PiA+PnBhdGgNCj4+ID4+ID4+ID4+ID4+ PihhbGwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBT RkMgaW5zdGFudGlhdGlvbi4gIEkNCj4+YmVsaWV2ZQ0KPj4gPj4gPj50aGlzDQo+PiA+PiA+PiA+ PiA+Pj5tZWFucw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3Np ZmllciBvciBtYXliZSB0aGUgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gY2xhc3NpZmllcg0K Pj4gPj4gPj5jaG9vc2VzIGENCj4+ID4+ID4+ID4+U0YNCj4+ID4+ID4+ID4+ID4+PiA+PkNoYWlu DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRo ZSBmaXJzdCBTRkYuICBJbiANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBhbnkNCj4+ID4+Y2Fz ZSwNCj4+ID4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9l cyBzZWVtIHRvIHByb2hpYml0IGEgbW9yZSBkeW5hbWljIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IFNGUA0KPj4gPj4gd2hlcmUNCj4+ID4+ID4+ID4+IFNGSShuKQ0KPj4gPj4gPj4gPj4gPj4+ IGlzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkg aG9wLiAgQWNjb3JkaW5nIHRvIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZQ0KPj4gPj5k cmFmdCwNCj4+ID4+ID4+ID4+dGhpcw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2aW9y IHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSANCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PiBuZXcNCj4+IFNGUA0KPj4gPj4gYXMNCj4+ID4+ID4+ID4+ID4+PiBvcHBvc2VkDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBh bmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZA0KPj4gaW5zdGFuY2UNCj4+ID4+IG9m DQo+PiA+PiA+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9mIHRo ZSBjdXJyZW50IFNGQy4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+PiBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29y ayANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gaXQNCj4+aXMNCj4+ID4+ID4+ID4+bmVjZXNz YXJ5DQo+PiA+PiA+PiA+PiA+Pj50bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3Qg dGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIA0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBiZQ0KPj4gPj51c2VkLA0KPj4gPj4gPj4gPj5hbmQgdG8NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1 c2luZw0KPj5TRidzDQo+PiA+PiA+PiA+Pm5ldHdvcmsNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gbG9jYXRvci4gIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyANCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gcmVzdWx0cw0KPj5pbg0KPj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+PmNy ZWF0aW9uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQ YXRoIChTRlApIGFuZCBpcyB1c2VkIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4+ ID4+ID4+ID4+Zm9yd2FyZGluZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRo cm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+PiBTRlANCj4+aXMNCj4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGluc3Rh bnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyBy ZWNsYXNzaWZpY2F0aW9uDQo+Pihvcg0KPj4gPj4gPj4gPj5ub24taW5pdGlhbA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4gIEFzIHBhY2tldHMgdHJh dmVyc2UgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFuDQo+PiA+PlNGUCwNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkg DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBlcmZvcm1lZA0KPj5ieQ0KPj4gPj5hDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50 IHdpdGggYQ0KPj5zZXJ2aWNlDQo+PiA+PiA+PiA+PmZ1bmN0aW9uLg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+PiBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiAN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YgYQ0KPj4gPj5uZXcNCj4+ID4+ID4+ID4+U0ZQ LCBhbg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQg bWV0YWRhdGEsIG9yIGJvdGguDQo+PlRoaXMgaXMNCj4+ID4+ID4+ID4+cmVmZXJyZWQNCj4+ID4+ ID4+ID4+ID4+PnRvDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4NCj4+ID4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+Pg0K Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pj4+Pj4tLQ0K Pj4gPj4gPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+PiA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ID4+ ID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5j b208SS5TbWl0aEBGNS5jb20+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBI YWxwZXJuDQo+PiA+PiA+PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpvZWwN Cj4+ID4+ID4+ID4+IE0uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+ PiA+Pg0KPj4gPj4gPj4gPj4gPj4+DQo+PiA+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+DQo+PiA+ Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbT4saHVhbmdAc2NlLmNhcmxldG9uLmNhPGh1 YW5nQHNjZS4NCj4+ID4+ID4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQNCj4+TG9hZA0KPj4gPj4gPj4gPj5CYWxhbmNlcnMNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IEFjdHVhbGx5LCBJIHRo aW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxv eW1lbnRzDQo+PihhbmQNCj4+ID4+ID4+dGhhdCBpcw0KPj4gPj4gPj4gPj4gPj4+d2hhdA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9m IHNlcnZpY2UNCj4+Y2hhaW5zIGlzDQo+PiA+PiA+PiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0 dXJlIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGJ1cmRlbmVkDQo+PiA+PndpdGgNCj4+ID4+ ID4+IHRoYXQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRv IGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBvZg0KPj4gPj4gPj4gPj5hc3BpcmF0aW9uDQo+PiA+PiA+PiA+PiB0bw0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3Bh biBvZiANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGUNCj4+ID4+ID4+ID4+YXJjaGl0ZWN0 dXJlDQo+PiA+PiA+PiA+PiA+Pj4tDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0 IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4gc2F5aW5nDQo+PiA+PnRoYXQgYW4NCj4+ID4+ID4+ID4+ID4+PmFyYml0cmFyeQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAt IGV2ZW4gaWYgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXQNCj4+ID4+aXNuJ3QNCj4+ID4+ ID4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxp bWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlDQo+Pmxhc3RpbmcNCj4+ID4+ ID4+ID4+aW1wYWN0cw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1v dXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwNCj4+ZWxhc3RpY2l0eSwNCj4+ID4+ID4+ID4+YWRkcmVz cw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3Mu IFRoYXQgaXMgYSBwcm9ibGVtDQo+PkknbQ0KPj4gPj5ub3QNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+PiA+PltqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbV0NCj4+ID4+ID4+ID4+U2VudDoNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7DQo+PkpvZWwNCj4+ID4+TS4N Cj4+ID4+ID4+ID4+IEhhbHBlcm47DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2Nl LmNhcmxldG9uLmNhOyBzZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+PiA+PltzZmNdDQo+PiA+ PiA+PiA+PlNlcnZpY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBh bGwgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaW4NCj4+ID4+dGhpcw0KPj4gPj4gPj4gPj5y ZWdhcmQuDQo+PiA+PiA+PiA+PiA+Pj5JDQo+PiA+PiA+PiA+PiA+Pj4gPj5hbQ0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRo ZQ0KPj5zb2x1dGlvbg0KPj4gPj4gPj4gPj5wcm9oaWJpdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtDQo+Pm9iamVjdGlu Zw0KPj4gPj50bw0KPj4gPj4gPj4gPj5IdWFuZydzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZGVwbG95bWVudHMNCj4+ID4+YXJlDQo+PiA+PiA+PiA+PiByZXF1aXJlZA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlk IHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0bw0KPj4gPj5wcm9oaWJpdA0KPj4gPj4gPj5z dWNoDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEg Z29vZCBpZGVhIG9yIG5vdA0KPj5kZXBlbmRzDQo+PiA+PiB1cG9uDQo+PiA+PiA+PiA+PiBtYW55 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBv ZiB0aGUgV0cuIEkgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gaGFwcGVuDQo+PnRvDQo+PiA+ PiA+PnRoaW5rDQo+PiA+PiA+PiA+PnRoYXQNCj4+ID4+ID4+ID4+ID4+PiA+PnRoZXkNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1 cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nDQo+PiA+PmF0dGVtcHRpbmcgdG8NCj4+ID4+ID4+ID4+ a25vdw0KPj4gPj4gPj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFu ZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90 ZToNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUg c3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZQ0KPj4gdGVucw0KPj4gPj4gb2YNCj4+ID4+ID4+ ID4+ID4+Pm1pbGxpb25zDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFu ZCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBkYXRhDQo+PiA+PiBjZW50ZXINCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkg YmVsaWV2ZQ0KPj50aGF0DQo+PiA+PmluDQo+PiA+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiANCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+PiB0b21vcnJvdw0KPj4gPj4geW91DQo+PiA+PiA+PiBhcmUNCj4+ID4+ ID4+ID4+IG9ubHkNCj4+ID4+ID4+ID4+ID4+PiA+PiBnb2luZw0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoDQo+PmVx dWFsbHkNCj4+ID4+ID4+c21hbGwNCj4+ID4+ID4+ID4+ID4+PiBudW1iZXJzDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNo IGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG5lZWQN Cj4+ID4+IG1vcmUNCj4+ID4+ID4+IHRoYW4NCj4+ID4+ID4+ID4+ID4+PiA2NEsiDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQu DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IEZyb206DQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4g W3NmYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSm9lbCBNLg0KPj5IYWxwZXJuDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86 DQo+PiA+PiA+PiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2E7DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSANCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQ2hhaW5zLA0KPj4gPj5QYXRocywNCj4+ID4+ID4+YW5kDQo+ PiA+PiA+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBObywg aXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byANCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gZGVwbG95DQo+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVk IHRoZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gbGltaXRzDQo+Pm9mDQo+PiA+PiA+PnRo ZWlyDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUg ZG9lcyBub3QgcmVxdWlyZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc3VjaA0KPj4gPj5h YnN1cmQNCj4+ID4+ID4+IHVzZQ0KPj4gPj4gPj4gPj4gb2YNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiB0bw0KPj4gPj53cml0ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUNCj4+YXJjaGl0 ZWN0dXJlDQo+PiA+PiA+PmRvZXMNCj4+ID4+ID4+ID4+ID4+PnBlcm1pdA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQg dGhlDQo+PmFyY2h0aWVjdHVyZQ0KPj4gPj4gPj4gcGVybWl0cw0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yDQo+PiA+ PnJlcXVpcmVkIGJ5DQo+PiA+PiA+PiA+PnRoZQ0KPj4gPj4gPj4gPj4gPj4+d29yay4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0s IENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5 b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQNCj4+d2lsbA0KPj4gPj4g Pj5tZWFuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0 IGlzIGxhcmdlciB0aGFuIHRoZQ0KPj5yb3V0aW5nDQo+PiA+PiA+PnRhYmxlDQo+PiA+PiA+PiA+ Pm9mIGENCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcv MTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gZGVwbG95bWVudHMsDQo+PiA+PiBmcm9tDQo+PiA+PiA+PjEN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZp Y2UgcGF0aHMuIEkgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gd291bGQNCj4+IGhvcGUN Cj4+ID4+ID4+dGhhdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUg cHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4gaWYNCj4+ID4+dGhleQ0KPj4gPj4gPj4gPj5jaG9vc2UNCj4+ID4+ID4+ID4+ID4+PnRvDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJh bGFuY2luZyBhbmQgaW4NCj4+c3RlYWQNCj4+ID4+ID4+ID4+IHByb3Zpc2lvbg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBP biA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEgNCj4+IHdyb3RlOg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJz IHRoZXJlIHdpbGwgYmUgZm9yIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhDQo+PjQN Cj4+ID4+aG9wDQo+PiA+PiA+PiA+PiBzZXJ2aWNlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJv bToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIA0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqT24NCj4+ID4+IEJlaGFsZg0KPj4gPj4gPj4gT2YNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5 IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwNCj4+ID4+MjAxNA0KPj4gPj4gPj4g Pj4zOjAzDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9uZyAq Q2M6Kg0KPj4gam1oQGpvZWxoYWxwZXJuLmNvbTsNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOyANCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb20gKlN1YmplY3Q6KiBSZTogW3Nm Y10gDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNlcnZpY2UNCj4+ID4+ID4+IENoYWlu cywNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBMdWN5LA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRyaXZlcw0KPj4gPj50aGUNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IG1ha2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTog dGhlIHBhdGggaWRlbnRpZmllciBjYW4gDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJl DQo+PiB1c2VkDQo+PiA+PiB0bw0KPj4gPj4gPj4gPj4gZGVyaXZlDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZA0KPj4gdHJh bnNwb3J0Lg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1c2VkDQo+PnRvDQo+PiA+PiA+PnNpbXBseQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBn cmFwaCkgdGhhdA0KPj5wYWNrZXRzDQo+PiA+PiA+Pm11c3QNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlDQo+PmV4 YWN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxl IHNlZW0gdG8gYmUgYXNraW5nIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3INCj4+ b24NCj4+ID4+ID4+dGhpcw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2Fu IGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBwYXRoDQo+PiA+PiA+PiA+PiBpZGVudGlmaWVyDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0DQo+PiBsb29r dXANCj4+ID4+IGNhbg0KPj4gPj4gPj4gPj4gcmVzdWx0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSANCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0DQo+PiA+PiBuZXh0DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0IDExOjA0 IEFNLCBMdWN5IHlvbmcgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdA aHVhd2VpLmNvbQ0KPj4gPj4gPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2gu IGRvYyBzaG91bGQgbm90IG1hbmRhdGUgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9u bHkNCj4+IHVzZQ0KPj4gPj4gb2YNCj4+ID4+ID4+IHRoZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUNCj4+Zm9yd2FyZGlu Zw0KPj4gPj4gPj4gPj5hY3Rpb25zLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10qT24NCj4+ID4+IEJlaGFsZg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIA0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+ PiA+PiA+PiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPj4gPj4gPj4gPj4gPj4+ID4+IEp1bHkNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86Km1pa2ViaWFu Y0Bhb2wuY29tDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA8bWFpbHRvOm1p a2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoq UmU6IFtzZmNdDQo+PlNlcnZpY2UNCj4+ID4+ID4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1l cmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhDQo+PnNlcnZpY2UNCj4+ID4+cGF0aA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2Ug dGhhdCBpZGVudGlmaWVyIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4g Pj5kZXJpdmUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25z Lg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwNCj4+IGtub3dsZWRn ZQ0KPj4gPj4gb2YNCj4+ID4+ID4+ID4+IGV2ZXJ5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4g YXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBh dGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZG9tYWluDQo+PiBpcw0KPj4gPj4gbm90DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWly ZWQvanVzdGlmaWVkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBp biB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMg c2hvdWxkIHJlbHkgb24gdGhlDQo+PnBpZWNlDQo+PiA+Pm9mDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxs DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1l bnRzOiB0aGF0IGlzIHRoZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb25lDQo+PiA+ PiA+PiByZXF1aXJlZA0KPj4gPj4gPj4gPj4gdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQNCj4+aW5mb3JtYXRpb24NCj4+ ID4+aXMNCj4+ID4+ID4+ID4+dXNlZCB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bmZlciBmb3J3YXJkaW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24u DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IENoZWVycywNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gTWVkDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSpEZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGENCj4+ID4+cGFydA0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpDQo+PiA6 Km1lcmNyZWRpIDkNCj4+ID4+ID4+ID4+IGp1aWxsZXQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tIA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9y Zw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9i amV0IDoqUmU6IFtzZmNdDQo+PlNlcnZpY2UNCj4+ID4+ID4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9u ZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZQ0KPj4gPj5iZXR3ZWVuDQo+PiA+PiA+ PlNGDQo+PiA+PiA+PiA+PiBDaGFpbg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQg U0YNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoYXQNCj4+aXQncw0KPj4gPj4gPj4gPj5jbGVhciB0bw0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHRob3NlIG5vdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdA0KPj5ldmVyeW9u ZQ0KPj4gPj4gPj5hZ3JlZXMNCj4+ID4+ID4+ID4+b24NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlc2UgdGVybXMuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwg dW5jbGVhciANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMNCj4+ID4+ID4+d2hldGhl cg0KPj4gPj4gPj4gPj5pdCBpcw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50 ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gc3BlY2lmeQ0KPj4gPj53aGF0DQo+PiA+PiA+PiA+PnRoZSBJRA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+IHNob3VsZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBj aGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aGlzDQo+PiA+PmRyYWZ0DQo+PiA+PiA+PiA+PnNpbXBseQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZw0KPj5vdGhl cg0KPj4gPj4gPj5kcmFmdHMNCj4+ID4+ID4+ID4+dG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCANCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb24NCj4+ID4+IGNoYWluDQo+PiA+PiA+PiBvcg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9y DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gcGF0aCB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0 dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdA0KPj53b3VsZA0KPj4gPj4gaGF2ZQ0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBi ZSBzdXBwb3J0ZWQgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IChvcg0KPj4gPj4gbWFr ZQ0KPj4gPj4gPj4gPj4gb25lDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVk IGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzb21lDQo+PiA+PiA+PiB2ZW5kb3JzDQo+PiA+PiA+PiA+PiBvbmx5DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBw b3J0aW5nIFNGQy4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ ID4+DQo+PiA+PiA+PiA+PiA+Pj4NCj4+ID4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4gPj4NCj4+IA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+ ID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+PiA+ PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVy bi5jb20NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcgDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3Jn Pj4NCj4+ID4+ID4+ICpTZW50OipUdWVzZGF5LA0KPj4gPj4gPj4gPj4gSnVseQ0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlu cywgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLA0KPj4gPj5hbmQNCj4+ID4+ ID4+TG9hZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZl IGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvDQo+PmNsZWFybHkNCj4+ID4+ID4+YW5z d2VyDQo+PiA+PiA+PiA+PmENCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9m IGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUNCj4+IGFib3V0DQo+PiA+PiB0aGUNCj4+ID4+ ID4+ID4+ID4+PiBwcm9wb3NlZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQg YXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGdldA0KPj4gPj4gPj4gd29ya2luZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIA0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4gPj4gaW1wcm92ZQ0KPj4gPj4gPj4gPj4g dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJz IHdobyBoYXZlIG5vdA0KPj4gcGFydGljaXBhdGVkDQo+PiA+PiBpbg0KPj4gPj4gPj4gPj50aGUN Cj4+ID4+ID4+ID4+IFdHDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24g d2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB3 b3JraW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1 dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byANCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZXhwbGFpbg0KPj5teQ0KPj4gPj4gPj4gPj5wZXJzb25hbA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMg cmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbg0KPj5taW5kDQo+PiA+PnRoYXQNCj4+ ID4+ID4+ID4+d2hhdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5p bmcgaXMgdGhlIGRhdGEgcGxhbmUNCj4+YXJjaGl0ZWN0dXJlLg0KPj4gPj5XZQ0KPj4gPj4gPj5h cmUNCj4+ID4+ID4+ID4+IG5vdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhdHRlbXB0 aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciANCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhlDQo+PiA+PmVudGlyZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBz b2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZA0KPj4gPj4gZW5jb21wYXNz DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBh bmQgcG9saWN5IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbnMsDQo+PiA+ PiA+PnZpcnR1YWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1h Z2UgbWFuYWdlbWVudCwgYW5kIG1hbnkNCj4+IG90aGVyDQo+PiA+PiA+PiA+PiBhc3BlY3RzLg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2gNCj4+Y2xlYXJseQ0KPj4g Pj4gbmVlZA0KPj4gPj4gPj4gdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3Qg aW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUNCj4+ZGVhbHQNCj4+ID4+d2l0aA0K Pj4gPj4gPj4gPj5hYm92ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBh cmUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsg DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlDQo+PmFyZQ0KPj4gPj4gPj4gZG9pbmcu DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UNCj4+cGF0aCwN Cj4+ID4+ID4+YXMgSQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+ PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBUaGVyZQ0KPj4gPj5hcmUgYXQNCj4+ID4+ID4+ID4+bGVhc3QNCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2Fk IGJhbGFuY2luZyANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2FuDQo+PmFuZA0KPj4g Pj4gPj53aWxsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2Vy dmljZSBjaGFpbmluZy4gVGhlcmUgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb2Jh Ymx5DQo+PiA+PmFyZQ0KPj4gPj4gPj4gPj5tb3JlLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQNCj4+YWxsIG9m DQo+PiA+PiA+PiA+PnRoZXNlLA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90 IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4gYmUgdXNlZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29sdXRp b24uDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byANCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlDQo+PiA+PmVuZA0KPj4gPj4gPj4gPj51c2VyLg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4g SXQgcmVjZWl2ZXMgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHVzZXINCj4+ID4+ID4+ cGFja2V0cywNCj4+ID4+ID4+ID4+YW5kDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1v ZGlmaWVzIHRoZW0gKG9yDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5k IHVzZXINCj4+c2VydmljZQ0KPj4gPj4gPj4gPj5pbnN0YW5jZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4NCj4+aW1w b3J0YW50DQo+PiA+PiA+PiA+PnNlcnZpY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2UNCj4+ID4+Y2hhaW5pbmcu DQo+PiA+PiA+PiA+Pkl0J3MNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3Ig bWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93DQo+PiBzZXJ2aWNlDQo+PiA+PiA+PiA+PiBj aGFpbmluZyBpcw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFz IHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4+ID4+ID4+ID4+YXJjaHRpZWN0dXJlLg0KPj4g Pj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAgRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVj dGl2ZSBpdCBpcw0KPj5zaW1wbHkNCj4+ID4+YQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHNl cnZpY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1v ZGlmeSB0aGUgdW5kZXJseWluZw0KPj4gcGFja2V0Lg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBs b2FkIGJhbGFuY2luZy4gVGhhdCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMsDQo+ Pm9uZQ0KPj4gPj4gPj5jYW4NCj4+ID4+ID4+ID4+aGF2ZQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB3aGF0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUg YXMgYQ0KPj5zaW5nbGUNCj4+ID4+ID4+cG9pbnQNCj4+ID4+ID4+ID4+b2YNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBh DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseQ0KPj4gPj5kZWxpdmVyZWQNCj4+ID4+ID4+ID4+YnkgYQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkNCj4+aW5jbHVkaW5n DQo+PiA+PiA+Pm9uZSBvcg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxv YWQgYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZw0KPj4gPj5WUlJQLWxpa2UNCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikg bW9zdGx5LA0KPj4gdGhpcw0KPj4gPj5pcw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSANCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcGxhbmUNCj4+ID4+ID4+ID4+bWVjaGFuaXNtcy4NCj4+ID4+ID4+ID4+IEl0 DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2li bGUgdG8gdmFyaW91cw0KPj5jb250cm9sDQo+PiA+PiA+PiA+Pm1lY2hhbmlzbXMsDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxl LWluLA0KPj4gPj5zY2FsZS1vdXQsDQo+PiA+PiA+PmFuZA0KPj4gPj4gPj4gPj52bQ0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBp bXBhY3Qgb2YNCj4+ID4+ID4+cGVybWl0dGluZw0KPj4gPj4gPj4gPj50aGlzDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwg dGhhdCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3VyDQo+PiA+PiA+PiA+PnRlcm1p bm9sb2d5DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUg bG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0KPj4gPj4gPj5zZWxlY3RpbmcNCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0 DQo+PmRpcmVjdA0KPj4gPj4gPj4gPj50cmFmZmljDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvDQo+PiByZXF1aXJl DQo+PiA+PiA+PiB0aGF0DQo+PiA+PiA+PiA+PmENCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUNCj4+cGxhY2UNCj4+ ID4+aW4NCj4+ID4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsu DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPj4gPj4gPj5j b21iaW5lZC4gSQ0KPj4gPj4gPj4gPj4gdGVuZA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvDQo+ PnNlcnZpY2UNCj4+ID4+ID4+ID4+Y2hhaW5pbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZQ0KPj4gPj5jbHVz dGVyDQo+PiA+PiA+PmlzDQo+PiA+PiA+PiA+PmENCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIA0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhbm90aGVyDQo+PiBvbmUuDQo+PiA+PiA+PiBUaHVzLA0KPj4gPj4gPj4g Pj4gdGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2Fk IGJhbGFuY2luZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvDQo+ PmRpZmZlcmVudA0KPj4gPj4gPj4gPj5zaW5ndWxhcg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50DQo+PiA+PnBs YWNlcw0KPj4gPj4gPj5pbg0KPj4gPj4gPj4gPj50aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVu IEkgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRhbGsNCj4+ID4+IGFib3V0DQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8g U2VydmljZSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4NCj4+aXMNCj4+ID4+ YQ0KPj4gPj4gPj4gPj4gc2VxdWVuY2UNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2Yg bG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhDQo+PnN1YnNldCBvZg0KPj4gPj4g Pj4gPj5wYWNrZXRzLg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFs ZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBvZg0KPj4gPj4gPj50cmFmZmljDQo+PiA+PiA+PiA+PmlzDQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIA0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQNCj4+ID4+ID4+ZmlyZXdhbGwNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdv IGRpcmVjdGx5IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj50aGUNCj4+ID4+ ID4+Y2FjaGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g VGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCANCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhlDQo+PiA+PiA+PnBhY2tldHMuDQo+PiA+PiA+PiBBDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBh IA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXF1ZW5jZQ0KPj5vZg0KPj4gPj4gPj4g Pj5sb2NhdGlvbnMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsu IFRob3NlIGxvY2F0aW9ucyB3aWxsIGJlDQo+PnNpbmd1bGFyDQo+PiA+Pm9yDQo+PiA+PiA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxv Y2F0aW9ucy4NCj4+ID4+VGhleQ0KPj4gPj4gPj4gPj5tYXkgYmUNCj4+ID4+ID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlDQo+PiBhZGRy ZXNzZWQgYXMNCj4+ID4+ID4+IHBvcnRzDQo+PiA+PiA+PiA+PiBvbg0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQg DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZQ0KPj4gPj4gPj4gPj5sb2NhdGlvbnMN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNl IGNoYWluaW5nDQo+PiA+PiBpbmZyYXN0cnVjdHVyZQ0KPj4gPj4gPj4gYW5kDQo+PiA+PiA+PiA+ PiB0aGUNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gIEZyb20g dGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlDQo+PlNGQw0KPj4gPj4gPj5ncm91 cCwNCj4+ID4+ID4+ID4+IHdlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRv IGJlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUg aGlnaCBsZXZlbCANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJzdHJhY3Rpb24sDQo+ PiA+PnRoZQ0KPj4gPj4gPj4gPj5zZXJ2aWNlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZQ0KPj4gbmVlZA0KPj4g Pj50bw0KPj4gPj4gPj4gdGFsaw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0 aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRha2UNCj4+aW4NCj4+ID4+dGhlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG5ldHdvcmsuDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRoZQ0K Pj4gd2hvbGUNCj4+ID4+ID4+IHBhdGgNCj4+ID4+ID4+ID4+IG1heQ0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyANCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlDQo+PiA+PmRlYWxzDQo+PiA+PiA+PiA+ PndpdGgNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5 cy4gRmlyc3QsIGFzIG5vdGVkIGluDQo+Pml0ZW0NCj4+ID4+KDIpDQo+PiA+PiA+Pm9uDQo+PiA+ PiA+PiA+PmxvYWQNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3Zl LCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZA0KPj4gPj4gPj5iZWhhdmlvcnMNCj4+ID4+ID4+ ID4+IHdoaWNoDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8g dGhlIHNlcnZpY2UgY2hhaW5pbmcNCj4+bWVjaGFuaXNtcw0KPj4gPj4oaW4NCj4+ID4+ID4+ID4+ bXVjaA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlk Z2luZyB3aXRoaW4gYSBMQU4gaXMNCj4+ID4+bGFyZ2VseQ0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgDQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG90aGVyDQo+PiA+PiA+PiBwcm92aXNpb24NCj4+ID4+ID4+ ID4+IHdlDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+PiB0aGF0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3Np ZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB3aGVuDQo+PiA+PiA+PiA+PiBuZWNlc3NhcnkuDQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhc2VkDQo+PiBvbg0KPj4gPj4gPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIA0KPj4gPj4gPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiByZS1jbGFzc2lmaWNhdGlvbg0KPj4gPj4gPj5wb2ludC4NCj4+ID4+ID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3Bl IHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlDQo+PmFmdGVyLg0KPj4gPj4gPj5J ZiBpdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVu dCBpcyBhY2NlcHRhYmxlIHRvIA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUNCj4+ ID4+d29ya2luZw0KPj4gPj4gPj4gPj4gZ3JvdXAsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUNCj4+ID4+IG5l ZWRlZA0KPj4gPj4gPj4gdG8NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udmV5IHRo aXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlDQo+PndpdGgNCj4+ID4+dGhlDQo+PiA+ PiA+PiA+PiBpbnRlbnQsDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4gd2Ugd2ls bCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZQ0KPj4gPj53b3JraW5nDQo+PiA+PiA+PiA+ Pmdyb3VwDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMg aXMgc3RpbGwgdW5jbGVhciwgSSBhbSANCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90 DQo+PiA+PnN1cmUNCj4+ID4+ID4+ID4+d2hhdCB0bw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+PiA+PiBzZmMNCj4+ID4+ ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qg c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiANCj4+ID4+ID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+PiA+PiBzZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiAN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4g Pj4gc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ IHNmYw0KPj4gPj4gPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+IGxpc3Qgc2ZjQGlldGYub3JnDQo+PiA+PiA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4g Pj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+IHNmYw0K Pj4gPj4gPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4g Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ ID4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ID4+ID4+ PiA+PiA+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+PiA+PiBtYWlsaW5nDQo+PiA+PiA+PiA+PiA+Pj4gPj4g bGlzdA0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+Pg0K Pj4gPj4gPj4gPj4gPj4+ID4+ID4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+ID4+IG1haWxpbmcNCj4+ID4+ ID4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcN Cj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4g Pj4NCj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QN Cj4+ID4+ID4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+ID4+ID4+ID4+PiA+PiA+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4gPj4g Pj4+ID4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4gPj4gPj4+ID4+ID5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4gPj4g Pj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gPnNmY0BpZXRmLm9y Zw0KPj4gPj4gPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4gPj4gPj4gPj4+ID4+DQo+PiA+PiA+PiA+PiA+Pj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ID4+ID4+PiA+ PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnDQo+PiA+ PiA+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+ID4+ID4+ID4+Pg0KPj4gPj4gPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4gPj4gPj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gPj4gPj4gPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+PiA+PiA+DQo+PiA+PiA+ PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+PiA+PiA+c2ZjQGlldGYub3JnDQo+ PiA+PiA+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ID4+ID4NCj4+ID4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Fri Jul 11 11:46: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 47DC51B2939 for ; Fri, 11 Jul 2014 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 7ylc9YRNCsHq for ; Fri, 11 Jul 2014 11:46:34 -0700 (PDT) Received: from omr-m05.mx.aol.com (omr-m05.mx.aol.com [64.12.143.79]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FF51A0AFE for ; Fri, 11 Jul 2014 11:46:28 -0700 (PDT) Received: from mtaout-aaf01.mx.aol.com (mtaout-aaf01.mx.aol.com [172.26.127.97]) by omr-m05.mx.aol.com (Outbound Mail Relay) with ESMTP id 76F6470000098; Fri, 11 Jul 2014 14:46:27 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aaf01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 142EA38000091; Fri, 11 Jul 2014 14:46:27 -0400 (EDT) Date: Fri, 11 Jul 2014 14:46:26 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, mn1921@att.com, mohamed.boucadair@orange.com, jmh@joelhalpern.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3365_947045922.1405104386847" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405104387; bh=1WFHCiC7IkhzbSWEQ8AO9Ar/oYIgqDg7+mY8HV05leE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=y1BbKg+yiIcJIJueZlDMkUpy5kwenDKYUNII/NHUQHBuYBQOHccsM13xj1wFgyDPY 6pvB0QIUzjpJsTpK6/EGeLLtcuMkimCCOPNpecPIFnCwaz0hDQu1uc2W50A4YEJaQd PGrefEamWlVphQ1XZpTP81Ony05bROf3CMm4X7/U= x-aol-sid: 3039ac1a7f6153c0310308c9 X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nfCxPVGRVEzfdWLvNrtdK_dnkBc Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 18:46:41 -0000 ------=_Part_3365_947045922.1405104386847 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wouldn't that be called the "service chain identifier" then? =C2=A0If the s= ervice chain is the ordered list of SFs and the service path is the ordered= list of SF instances, then I would infer that a "service path identifier" = would be an identifier for a service *path*, not a service *chain*. Again, I think this is where the confusion keeps creeping in. =C2=A0The ter= ms "chain" and "path" seem inconsistent. From: jguichar@cisco.com To: mikebianc@aol.com,mn1921@att.com,moh= amed.boucadair@orange.com,jmh@joelhalpern.com= ,Ron_Parker@affirmednetworks.com,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Your definition of service path is correct as its the forwarding path throu= gh which traffic will actually flow. The service path identifier however po= ints to the service chain data structure and that is then resolved to speci= fic instances based upon which next-hops to those instances are available and whatever load distribution = technique is in play. When instantiating the service chain into the network= you may or may not update that data structure to specify which next-hops m= ay be used (where a single next-hop would effectively nail up the service path for that service chain) or you = may simply allow some other protocol / mechanism to populate the data struc= ture for you.=20 From: "mikebianc@aol.com" Date: Friday, July 11, 2014 at 12:18 PM To: Jim Guichard , "mn1921@att.com" , "= mohamed.boucadair@orange.com" , "jmh@joelhalpern.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I think this is the root of the confusion: > I don=E2=80=99t want to specify > specific instances of S1, S2, and S3 (or some combination thereof). I > assign a service path identifier =E2=80=9C100=E2=80=9D that basically poi= nts to S1->S2->S3 > and then push this into the network By definition, I understood a "service path" to be an ordered list of speci= fic SF instances. In the statement above, you use a "service path identifi= er" to refer to a service *chain* that specifically "[does not] specify spe= cific instances". From: jguichar@cisco.com To: NAPIERALA, MARIA H,mohamed.boucadair@orange.com,Joel M. Halpern,Ron Parker,sfc@ietf.org Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Maria, I think of it this way. The service path identifier is simply a pointer to a data structure that contains SF to next-hop mappings. When you define a chain, let=E2=80=99s say S1 ->S2-> S3, you *might* when creating the SFP sp= ecify the specific next-hops that you want traffic to flow through for that SFP. However, you do *not* have to do this from an architectural standpoint (I will argue that you should but you don=E2=80=99t have to architecturally). = You could simply assign a service path identifier to point to a given SFC and then push that information into the network. At the SFF it will have a service path identifier to SFC mapping and said mapping would contain the next-hops available for each of the SF=E2=80=99s within the SFC - how you l= earn those next-hops is up to you. You could push them down from a centralized controller, configure them through CLI, learn them dynamically through some protocol exchange, whatever .. So, given this it is not correct to say that the service path means that all SF instances are chosen a priori although it is perfectly acceptable (and some would say recommended) to do so. Let=E2=80=99s take an example to hopefully make this clear: I define an SFC (let=E2=80=99s refer to it as SFC-1) S1->S2->S3. For argume= nts sake let=E2=80=99s say I want it to be fully dynamic e.g. I don=E2=80=99t w= ant to specify specific instances of S1, S2, and S3 (or some combination thereof). I assign a service path identifier =E2=80=9C100=E2=80=9D that basically point= s to S1->S2->S3 and then push this into the network so that the SFF data structures are populated with this information. Now at a given SFF, when traffic arrives with service path identifier 100, the SFF will look this up in the data structure and find that it points to S1->S2->S3 and the index in the SFC encapsulation will tell it exactly where it is in the chain. Let=E2=80=99s = say we are at S2 in the chain. The SFF will now have to resolve the next-hop to S3 and will do a lookup to determine where S3 is reachable. On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" wrote: >Jim, > >Could you tell us what is the definition of a "service path" and a >"service path identifier"? >If a service path means that all SF instances are chosen apriori (which >is my current understanding) then it is not SFF's local decision which >next-hop SFF to pick. It is a centralized decision. > >Maria > > >> -----Original Message----- >>=20 From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Friday, July 11, 2014 11:15 AM >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. >> Halpern; Ron Parker; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> I=E2=80=99m sorry but I really don=E2=80=99t understand why a service pa= th identifier >> prevents full distribution of SF next-hops or why calling it a service >> chain identifier makes any difference? >>=20 >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" wrote: >>=20 >> >Ditto. >> > >> >> -----Original Message----- >> >> From: mohamed.boucadair@orange.com >> >> [mailto:mohamed.boucadair@orange.com] >> >> Sent: Friday, July 11, 2014 10:31 AM >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron >> >> Parker; sfc@ietf.org >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> Re-, >> >> >> >> For what I can say at best this is not described clearly in the >>draft. >> >> >> >> Mandating a service path identifier is in itself a hint that the full >> >>distributed >> >> model is not allowed. >> >> >> >> Several voices in this thread indicated that the service chain itself >> >>should be >> >> provided instead. >> >> >> >> Cheers, >> >> Med >> >> >> >> >-----Message d'origine----- >> >> >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >> >> >(jguichar) >> >> >Envoy=C3=A9 : vendredi 11 juillet 2014 16:18 >> >> >=C3=80 : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;=20 sfc@ietf.org >> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >> > >> >> >Ok but where in the architecture specifically is this functionality >> >> >prohibited? If you want to distribute *all* next-hops to *all* SFF= =E2=80=99s >> >> >within the SFC domain and then let the path identifier point to a >> >>lookup >> >> >into those next-hops to reach the next SF in the chain, I am not >>sure >> >>how >> >> >the architecture prevents that? >> >> > >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" >> wrote: >> >> > >> >> >>Absolutely. >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >> >> >>>(jguichar) >> >> >>> Sent: Friday, July 11, 2014 9:54 AM >> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;=20 sfc@ietf.org >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >>> >> >> >>> Then I misunderstand the proposal ;-) .. However, it seems to me >> >>that if >> >> >>> you allow an SFF to make a decision as to which remote SFF it >>will >> >>use >> >> >>>for >> >> >>> a given flow to reach the next SF within the chain then you >>better >> >>make >> >> >>> sure that that remote SFF has the necessary forwarding logic to >> >>reach >> >> >>>the >> >> >>> next-next-SF for the chain as otherwise you are in deep trouble. >> >> >>> >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" >> >> wrote: >> >> >>> >> >> >>> >Absolutely not. Service chains can be instantiated only in >>relevant >> >> >>>SFFs >> >> >>> >when they "arrive". >> >> >>> > >> >> >>> >> -----Original Message----- >> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>Guichard >> >> >>> >>(jguichar) >> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM >> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >>> >> >> >> >>> >> Well I think it is even worse than that if I have understood >>the >> >> >>> >>proposal >> >> >>> >> correctly as it would require full knowledge of every single >>SF >> >> >>>within >> >> >>> >>the >> >> >>> >> entire SFC domain at every single SFF as there is no way to >>know >> >>a >> >> >>> >>priori >> >> >>> >> which SFC=C2=B9s a given SFF will need to service at any given >>point >> >>in >> >> >>>time. >> >> >>> >> >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" >> >> wrote: >> >> >>> >> >> >> >>> >> >Ron, thinking about this, I realized another major problem >>with >> >>the >> >> >>> >>your >> >> >>> >> >proposal as I understand it. (And I readily admit I may not >> >> >>>understand >> >> >>> >> >it.) >> >> >>> >> > >> >> >>> >> >The proposal has each SFF serve as the load balancer for the >> >>next >> >> >>> >> >service function that follows it (not the one it delivers >>to), >> >>in >> >> >>>every >> >> >>> >> >service chain that goes through it. >> >> >>> >> > >> >> >>> >> >Since it has to be able to work with all services, that means >> >>that >> >> >>> >>every >> >> >>> >> >SFF would have to be a full, flow sensitive and stateful load >> >> >>>balancer. >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and / or >> >>stateful. >> >> >>> >> >But having the architecture require that every SFF be a full, >> >>flow >> >> >>> >> >sensitive, stateful, load balancer seems to me to be an >> >>acceptable >> >> >>> >> >imposition. >> >> >>> >> > >> >> >>> >> >Yours, >> >> >>> >> >Joel >> >> >>> >> > >> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >> >>> >> >> Part of my personal view is that I am trying to make this >>work >> >> >>> >>sensibly >> >> >>> >> >> in a more orchestrated environment. I expect that the >>service >> >> >>> >> >> functions, and over time probably the SFF capabilities, >>will >> >>be >> >> >>> >> >> orchestrated and installed. I expect the service chains >>to be >> >> >>> >>driven by >> >> >>> >> >> BSS tools that define offerings to clients, and enable >> >> >>>self-selection >> >> >>> >> >> from these. I expect service paths to be heavily policy >> >>drive. >> >> >>> >> >> >> >> >>> >> >> I can see how to make all of that work in an archtiecture >> >>driven >> >> >>>by >> >> >>> >> >> initial classification to described service paths. It is >> >>harder >> >> >>>to >> >> >>> >>see >> >> >>> >> >> how to make it work (but it can be done) when we allow more >> >> >>> >> dynamicity >> >> >>> >> >> in the network behavior. >> >> >>> >> >> >> >> >>> >> >> Having said that, most of that perspective I described is >> >>outside >> >> >>>of >> >> >>> >>the >> >> >>> >> >> scope of the working group. it is not something we are >> >>tasked to >> >> >>> >>agree >> >> >>> >> >>on. >> >> >>> >> >> So I do not claim that vision means we have to do it a >>certain >> >> >>>way. >> >> >>> >>it >> >> >>> >> >> is just the perspective that drives my preferences. >> >> >>> >> >> >> >> >>> >> >> Yours, >> >> >>> >> >> Joel >> >> >>> >> >> >> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >> >>> >> >>>> For me, the amount of information about service instances >> >> that >> >> >>> >>needs >> >> >>> >> >>>>to >> >> >>> >> >>>> be widely distributed and maintained, potentially even >> >>across >> >> >>>data >> >> >>> >> >>>> centers within an administrative scope, is large enough >>and >> >> >>> complex >> >> >>> >> >>>> enough that trying to get that into each SFF seems like a >> >> >>>difficult >> >> >>> >> >>>> architecture to realize. >> >> >>> >> >>> >> >> >>> >> >>> I'm curious as to why that is more complicated than >>dynamic >> >> >>> routing, >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of >>which >> >>are >> >> >>> >>bigger >> >> >>> >> >>> problems that have been profitably and stably implemented? >> >> >>> >> >>> >> >> >>> >> >>> It also seems that if it really is more complicated, that >>is >> >>a >> >> >>>good >> >> >>> >> >>> sign that it is too complicated. >> >> >>> >> >>> >> >> >>> >> >>> ________________________________________ >> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com] >> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct;=20 mikebianc@aol.com; >>Ian >> >> >>>Smith; >> >> >>> >> >>> sfc@ietf.org >> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load >>Balancers >> >> >>> >> >>> >> >> >>> >> >>> This is an architectural issue. And one that I would >>prefer >> >>we >> >> >>> >> >>>actually >> >> >>> >> >>> decide, rather than trying to allow all possible >> >>implementations. >> >> >>> >> >>> Because it does have a major effect on the control >> >>requirements >> >> >>>and >> >> >>> >> the >> >> >>> >> >>> functionality of SFFs. >> >> >>> >> >>> >> >> >>> >> >>> For me, the amount of information about service instances >> >>that >> >> >>> needs >> >> >>> >> to >> >> >>> >> >>> be widely distributed and maintained, potentially even >> across >> >> >>>data >> >> >>> >> >>> centers within an administrative scope, is large enough >>and >> >> >>>complex >> >> >>> >> >>> enough that trying to get that into each SFF seems like a >> >> >>>difficult >> >> >>> >> >>> architecture to realize. >> >> >>> >> >>> >> >> >>> >> >>> Yours, >> >> >>> >> >>> Joel >> >> >>> >> >>> >> >> >>> >> >>> But it is a fair question. >> >> >>> >> >>> >> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >> >>> >> >>>> This is the crux of my issue. Is the end to end >>selection >> >>of >> >> >>> >> >>>> (top-level) instances performed centrally (perhaps by the >> >> >>> >>classifier) >> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently >> >>the >> >> >>> >>SFFs)? >> >> >>> >> >>>> Such selection is not equivalent to reclassification. >>And >> >> >>>surely, >> >> >>> >> >>>> this is an architectural issue and not relegated to >> >> >>> >> >>>> "implementation". >> >> >>> >> >>>> >> >> >>> >> >>>> My own view is to favor the distributed approach even >> though >> >> a >> >> >>> >> >>>> greater amount of data (chain definitions and perhaps >>local >> >> >>> >>selection >> >> >>> >> >>>> policy) is required at those distributed decision points. >> >>This >> >> >>> >> >>>> approach does not require an end-to-end path id at all. >> >>My >> >> >>> >> >>>> rationale for favoring this approach is primarily driven >>by >> >> >>> >>increased >> >> >>> >> >>>> resiliency over the global path id approach. With a >>global >> >> >>>path >> >> >>> >>id >> >> >>> >> >>>> approach, consider failure of an instance and needing to >> >>alter >> >> >>>the >> >> >>> >> >>>> global path ID table for each and every affected >>end-to-end >> >> >>>path. >> >> >>> >> >>>> >> >> >>> >> >>>> Ron >> >> >>> >> >>>> >> >> >>> >> >>>> ________________________________________ From: sfc >> >> >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern Direct >> >> >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, July 10, >>2014 >> >> 6:15 >> >> >>> PM >> >> >>> >> >>>> To: mikebianc@aol.com;=20 I.Smith@F5.com; sfc@ietf.org >> Subject: >> >> Re: >> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >> >> >>> >> >>>> >> >> >>> >> >>>> The way the architecture models the case of SF1 needing >>to >> >> >>> >>influence >> >> >>> >> >>>> the chain is that one would do reclassification at the >>exit >> >>from >> >> >>> >> >>>> SF1. >> >> >>> >> >>>> >> >> >>> >> >>>> Part of the goal is to keep the different functions >> >>logically >> >> >>> >> >>>> separate so that solutions can clearly describe how they >> >> choose >> >> >>>to >> >> >>> >> >>>> compose them for "service" delivery. >> >> >>> >> >>>> >> >> >>> >> >>>> Yours, Joel >> >> >>> >> >>>> >> >> >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> >> >>> >> >>>>> I don't see anything in the arch draft that suggests any >> >>sort >> >> >>>of >> >> >>> >> >>>>> limit. However, it does seem to indicate that the entire >> >>path >> >> >>>(all >> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe >>this >> >> >>>means >> >> >>> >> >>>>> either at the classifier or maybe the classifier >>chooses a >> >>SF >> >> >>> >>Chain >> >> >>> >> >>>>> and the NF or at the latest the first SFF. In any case, >> >>the >> >> >>> >> >>>>> language does seem to prohibit a more dynamic SFP where >> >> SFI(n) >> >> >>> is >> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to the draft, >> >>this >> >> >>> >> >>>>> behavior would be considered "branching" to a new SFP as >> >> >>> opposed >> >> >>> >> to >> >> >>> >> >>>>> choosing and then forwarding to the selected instance of >> >>the >> >> >>> >> >>>>> next-hop of the current SFC. >> >> >>> >> >>>>> >> >> >>> >> >>>>> draft-merged-sfc-architecture-00: >> >> >>> >> >>>>>> When an SFC is instantiated into the network it is >> >>necessary >> >> >>>to >> >> >>> >> >>>>>> select the specific instances of SFs that will be used, >> >>and to >> >> >>> >> >>>>>> create the service topology for that SFC using SF's >> >>network >> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC results in the >> >> >>>creation >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for >> >>forwarding >> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP is the >> >> >>> >> >>>>>> instantiation of the defined SFC. >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> The SFC architecture supports reclassification (or >> >>non-initial >> >> >>> >> >>>>>> classification) as well. As packets traverse an SFP, >> >> >>> >> >>>>>> reclassification may occur - typically performed by a >> >> >>> >> >>>>>> classification function co-resident with a service >> >>function. >> >> >>> >> >>>>>> Reclassification may result in the selection of a new >> >>SFP, an >> >> >>> >> >>>>>> update of the associated metadata, or both. This is >> >>referred >> >> >>>to >> >> >>> >> >>>>>> as "branching". >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >> >> >>> >> >> >>=20 >>>>>>>>>>>>>>------------------------------------------------------------- >>>>>>>>>>>>>>-- >> >>>>>>>>>>>>--- >> >> >>>>>>>>>>-- >> >> >>> >>>>>>>-- >> >> >>> >> >>>>>-- >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>> *From: *I.Smith@F5.com >> >> >>> >> >>>>> *To: *Joel Halpern >> Direct,Joel >> >> M. >> >> >>> >> >>>>> >> >> >>> >> >> >> >>> >> >> >> >>>>>Halpern,huang@sce.carleton.ca> >> >>> >> carleton. >> >> >>> >> >>>>>ca>,sfc@ietf.org >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >> >>Balancers >> >> >>> >> >>>>> >> >> >>> >> >>>>> Actually, I think I am disagreeing. >> >> >>> >> >>>>> >> >> >>> >> >>>>> If the possibility of medium-scale deployments (and >>that is >> >> >>>what >> >> >>> >> >>>>> 16 million flows is in my world) of service chains is >> >> >>>preconceived >> >> >>> >> >>>>> as an absurd idea, then the architecture burdened with >> that >> >> >>> >> >>>>> preconception. >> >> >>> >> >>>>> >> >> >>> >> >>>>> There has to be some point of aim, some degree of >> >>aspiration >> >> to >> >> >>> >> >>>>> scale that is appropriate for the lifespan of the >> >>architecture >> >> >>>- >> >> >>> >> >>>>> you don't have to know what it is, but by saying that an >> >> >>>arbitrary >> >> >>> >> >>>>> number is "too far", you're creating - even if it isn't >> >> >>> >>intentional >> >> >>> >> >>>>> - a limit that influences decisions that have lasting >> >>impacts >> >> >>> >> >>>>> regarding scale-out, failure mitigation, elasticity, >> >>address >> >> >>> >> >>>>> space... all kinds of things. That is a problem I'm not >> >> >>> >> >>>>> particularly eager to deal with. >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> ________________________________________ >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com] >> >>Sent: >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >> >> Halpern; >> >> >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc] >> >>Service >> >> >>> >> >>>>> Chains, Paths, and Load Balancers >> >> >>> >> >>>>> >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all in this >> >>regard. >> >> >>>I >> >> >>> >>am >> >> >>> >> >>>>> not requesting the the architecture or the solution >> >>prohibit >> >> >>> >> >>>>> deployments in the specific fashion. I am objecting to >> >>Huang's >> >> >>> >> >>>>> reading of my note as saying that such deployments are >> >> required >> >> >>> >> >>>>> they by the archtiecture. >> >> >>> >> >>>>> >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to prohibit >>such >> >> >>> >> >>>>> things. Whether they are a good idea or not depends upon >> >> many >> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to >>think >> >>that >> >> >>> >>they >> >> >>> >> >>>>> are usually a bad idea. >> >> >>> >> >>>>> >> >> >>> >> >>>>> But the archtiecture si carefully avoiding attempting to >> >>know >> >> >>>what >> >> >>> >> >>>>> is and is not eployable. >> >> >>> >> >>>>> >> >> >>> >> >>>>> Yours, Joel >> >> >>> >> >>>>> >> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >> >>> >> >>>>>> I disagree. >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> We routinely have stateful devices that manage tens of >> >> >>>millions >> >> >>> >> >>>>>> of >> >> >>> >> >>>>> concurrent flows in both access network and data center >> >> >>> >> >>>>> environments today. You can't seriously believe that in >>the >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you >> are >> >> only >> >> >>> >> going >> >> >>> >> >>>>> to have small numbers of service chains with equally >>small >> >> >>> numbers >> >> >>> >> >>>>> of active service paths? >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> Your sounds too much like "no one will ever need more >> than >> >> >>> 64K" >> >> >>> >> >>>>>> for >> >> >>> >> >>>>> comfort. >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> ________________________________________ From: sfc >> >> >>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. Halpern >> >> >>> >> >>>>> [jmh@joelhalpern.com] >> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >> >> >>>huang@sce.carleton.ca; >> >> >>> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, >>and >> >> >>>Load >> >> >>> >> >>>>>> Balancers >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> No, it will mean that if someone tries to deploy the >> >> >>>archtieture >> >> >>> >> >>>>>> particularly badly, they will exceed the limits of >>their >> >> >>> >> >>>>>> devices. The architecture does not require such absurd >> use >> >> of >> >> >>> >> >>>>>> service paths. Since I can not figure out how to write >> >> >>> >> >>>>>> architectural words to prohibit it, the architecture >>does >> >> >>>permit >> >> >>> >> >>>>>> such abuse. >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> Please do not read my saying that the archtiecture >> permits >> >> >>> >> >>>>>> something as saying it is either deisred or required by >> >>the >> >> >>>work. >> >> >>> >> >>>>>> It isn't. >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> Yours, Joel >> >> >>> >> >>>>>> >> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >> >>> >> >>>>>>> If you need to support 100 service chains, it will >>mean >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing >>table >> >>of a >> >> >>> >> >>>>>>> core router. >> >> >>> >> >>>>>>> >> >> >>> >> >>>>>>> Chang >> >> >>> >> >>>>>>> >> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >> >>> >> >>>>>>>> The architecture allows a range of deployments, from >>1 >> >> >>> >> >>>>>>>> service path to 160000 service paths. I would hope >>that >> >> >>> >> >>>>>>>> operators are prepared for the complexities if they >> >>choose >> >> >>>to >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in stead >> >> provision >> >> >>> >> >>>>>>>> 160,000 service paths. >> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> Yours, Joel >> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >> >> >>> >> >>>>>>>>> Paul, >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop >> >> service >> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Maria >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >> Of >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 >> >>3:03 >> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:*=20 jmh@joelhalpern.com; >> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >> >> >>> >> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] Service >> Chains, >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Lucy, >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the >> >> >>> >> >>>>>>>>> forwarding. I=C2=B9d >> >> >>> >> >>>>> make >> >> >>> >> >>>>>>>>> the minor change: the path identifier can be used to >> >> derive >> >> >>> >> >>>>>>>>> the needed forwarding and associated transport. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to >>simply >> >> >>> >> >>>>>>>>> identify the service path (or graph) that packets >>must >> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exact >> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on >>this >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path >> >> identifier >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can >> >> result >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) transport next >> >> >>> >> >>>>>>>>> hop(s). >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Paul >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >> >>> >> >>>>>>>>> > >> > >> >> >>> >> >>>>>>>>> wrote: >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of >> the >> >> >>> >> >>>>>>>>> service path identifier to drive the forwarding >> >>actions. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Lucy >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >> >> >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com >> >> >>> >> >>>>>>>>> >> >> >>> *Sent:*Thursday, >> >> >>> >> July >> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >> >>> >> >>>>>>>>> ;jmh@joelhalpern.com >> >> >>> >> >>>>>>>>> ;sfc@ietf.org >> >> >>> >> >>>>>>>>> *Subject:*Re: [sfc] Service >> >>Chains, >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Re-, >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a service path >> >> >>> >> >>>>>>>>> identifier. I object to use that identifier to >>derive >> >> >>> >> >>>>>>>>> forwarding actions. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of >> >> every >> >> >>> >> >>>>> available SFC >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not >> >> >>> >> >>>>> required/justified >> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of >> >> >>> >> >>>>>>>>> information >> >> >>> >> >>>>> that will >> >> >>> >> >>>>>>>>> be present in all deployments: that is the one >> required >> >> to >> >> >>> >> >>>>>>>>> structure a service chain. How that information is >> >>used to >> >> >>> >> >>>>>>>>> infer forwarding >> >> >>> >> >>>>> actions >> >> >>> >> >>>>>>>>> is a solution-oriented discussion. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Cheers, >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Med >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >> >> >>> >> >>>>> de*mikebianc@aol.com >> >> >>> >> >>>>>>>>> *Envoy=C3=A9 :*mercredi 9 >> >> juillet >> >> >>> >> >>>>>>>>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com >> >> >>> >> >>>>>>>>> ;sfc@ietf.org >> >> >>> >> >>>>>>>>> *Objet :*Re: [sfc] Service >> >>Chains, >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference between >>SF >> >> Chain >> >> >>> >> >>>>>>>>> and SF >> >> >>> >> >>>>> Path? >> >> >>> >> >>>>>>>>> Other than clarifying the definition so that it's >> >>clear to >> >> >>> >> >>>>> those not >> >> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone >>agrees >> >>on >> >> >>> >> >>>>>>>>> these terms. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear is >>whether >> >>it is >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify what >> >>the ID >> >> >>> >> >>>>>>>>> of the SFC Header >> >> >>> >> >>>>> should >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if this draft >> >>simply >> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other >>drafts >> >>to >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain >> or >> >> >>> >> >>>>>>>>> path and the choice of chain or >> >> >>> >> >>>>> path to >> >> >>> >> >>>>>>>>> be negotiated in the control-plane. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported (or make >> >> one >> >> >>> >> >>>>>>>>> required and the other optional) to avoid some >> vendors >> >> only >> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>> >> >> >>> >> >> >> >>> >> >> >>=20 >>>>>>>>>>>>>>------------------------------------------------------------- >>>>>>>>>>>>>>-- >> >>>>>>>>>>>>--- >> >> >>>>>>>>>>-- >> >> >>> >>>>>>>-- >> >> >>> >> >>>>>-- >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>>>> >> >> >>> >> >>>>>>>>> *From:*jmh@joelhalpern.com> >> >>> >> >>>>>>>>> >> >> > >> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org> >> >>> >> >>>>>>>>> > >> *Sent:*Tuesday, >> >> July >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and >>Load >> >> >>> >> >>>>>>>>> Balancers >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> I have been trying to figure out how to clearly >>answer >> >>a >> >> >>> >> >>>>>>>>> number of comments that have been made about the >> >> >>> proposed >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get >> working >> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to >> improve >> >> the >> >> >>> >> >>>>>>>>> wording so that readers who have not participated in >> >>the >> >> WG >> >> >>> >> >>>>>>>>> discussion will understnd it the way the >> >> >>> >> >>>>> working >> >> >>> >> >>>>>>>>> group intends. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain my >> >>personal >> >> >>> >> >>>>>>>>> view, and see if that helps. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> In this regard, it is important to keep in mind that >> >>what >> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. We >>are >> >> not >> >> >>> >> >>>>>>>>> attempting to define the architecture for the entire >> >> >>> >> >>>>>>>>> solution for service chaining. That would encompass >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy functions, >>virtual >> >> >>> >> >>>>>>>>> machine and image management, and many other >> >> aspects. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> As a result there are many things which clearly need >> to >> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt with >> >>above >> >> >>> >> >>>>>>>>> where we are >> >> >>> >> >>>>> functioning, >> >> >>> >> >>>>>>>>> and are not directly required by the work we are >> doing. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> In order to get to service chain vs service path, >>as I >> >> >>> >> >>>>>>>>> understand >> >> >>> >> >>>>> them, >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. There are at >> >>least >> >> >>> >> >>>>>>>>> three different ways that load balancing can and >>will >> >> >>> >> >>>>>>>>> interact with service chaining. There probably are >> >>more. >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all of >> >>these, >> >> >>> >> >>>>>>>>> but not to mandate that any particular kind >> >> >>> >> >>>>> be used >> >> >>> >> >>>>>>>>> in any solution. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to the end >> >>user. >> >> >>> >> >>>>>>>>> This is a service function. It receives user >>packets, >> >>and >> >> >>> >> >>>>>>>>> modifies them (or >> >> >>> >> >>>>> marks >> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user service >> >>instance >> >> >>> >> >>>>>>>>> to receive the users packet. This is an important >> >>service >> >> >>> >> >>>>>>>>> function to be able to include in service chaining. >> >>It's >> >> >>> >> >>>>>>>>> behavior may affect requirements on how service >> >> chaining is >> >> >>> >> >>>>>>>>> done. But it has very little impact on the >> >>archtiecture. >> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is simply a >> >> >>> >> >>>>> service >> >> >>> >> >>>>>>>>> function which may modify the underlying packet. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one >>can >> >>have >> >> >>> >> >>>>>>>>> what >> >> >>> >> >>>>> appears >> >> >>> >> >>>>>>>>> to the service chaining architecture as a single >>point >> >>of >> >> >>> >> >>>>>>>>> contact >> >> >>> >> >>>>> for a >> >> >>> >> >>>>>>>>> specific service function, but is actually delivered >> >>by a >> >> >>> >> >>>>> collection of >> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including >>one or >> >> >>> >> >>>>>>>>> several load balancers (for example using VRRP-like >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is >> >> >>> >> >>>>>>>>> invisible to the service chaining data plane >> >>mechanisms. >> >> It >> >> >>> >> >>>>>>>>> is likely that it is visible to various control >> >>mechanisms, >> >> >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out,= =20 >>and >> >>vm >> >> >>> >> >>>>>>>>> instantiation. The architectural impact of=20 >>permitting >> >>this >> >> >>> >> >>>>>>>>> is largely that we need to be careful that our >> >>terminology >> >> >>> >> >>>>>>>>> does not lead >> >> >>> >> >>>>> readers to >> >> >>> >> >>>>>>>>> think we are prohibiting it. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by=20 >>selecting >> >> >>> >> >>>>>>>>> packet paths for the service chaining that direct >> >>traffic >> >> >>> >> >>>>>>>>> to different places. We would not want to require >> that >> >>a >> >> >>> >> >>>>>>>>> given service function appear at only one place in= =20 >>the >> >> >>> >> >>>>>>>>> network. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> It is of course the case that these may be=20 >>combined. I >> >> tend >> >> >>> >> >>>>>>>>> to >> >> >>> >> >>>>> refer to >> >> >>> >> >>>>>>>>> the collection of entities that appear to service >> >>chaining >> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster= =20 >>is >> >>a >> >> >>> >> >>>>>>>>> good term. But because I do not have another one. >> Thus, >> >> the >> >> >>> >> >>>>>>>>> point of type 3 load balancing >> >> >>> >> >>>>> is to >> >> >>> >> >>>>>>>>> direct different subsets of traffic to different >> >>singular >> >> >>> >> >>>>>>>>> or clustered service functions in different places= =20 >>in >> >>the >> >> >>> >> >>>>>>>>> network. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I talk about >> >> >>> >> >>>>>>>>> service chain and service path/ Service chain is a >> >> sequence >> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset of >> >>packets. >> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of=20 >>traffic >> >>is >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, and=20 >>firewall >> >> >>> >> >>>>>>>>> while a different subset is to go directly to the=20 >>cache >> >> >>> >> >>>>> without >> >> >>> >> >>>>>>>>> visiting any other service functions. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> That is not enough information to direct the=20 >>packets. >> A >> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence of >> >>locations >> >> >>> >> >>>>>>>>> in the network. Those locations will be singular or >> >> >>> >> >>>>>>>>> clustered service function delivery locations. They >> >>may be >> >> >>> >> >>>>>>>>> addressed by IP address. They may be addressed as >> ports >> >> on >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that the >> >>locations >> >> >>> >> >>>>>>>>> may be known to the service chaining infrastructure >> and >> >> the >> >> >>> >> >>>>>>>>> transport. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>>> From the point of view of the work of the SFC=20 >>group, >> >> we >> >> >>> >> >>>>>>>>>> need to be >> >> >>> >> >>>>>>>>> able to talk about the high level abstraction, the >> >>service >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need to >> talk >> >> >>> >> >>>>>>>>> about the actual data path packets will take in the >> >> >>> >> >>>>>>>>> network. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Several of the comments have said "but the whole >> path >> >> may >> >> >>> >> >>>>>>>>> not be known at the front." This architecture deals >> >>with >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2)= =20 >>on >> >>load >> >> >>> >> >>>>>>>>> balancers above, there can be decisions and=20 >>behaviors >> >> which >> >> >>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in >> >>much >> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is largely >> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The other >> provision >> >> we >> >> >>> >> >>>>>>>>> make is >> >> >>> >> >>>>> that >> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain when >> >> necessary. >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. Based on >> >> >>> >> >>>>>>>>> information available at the re-classification=20 >>point. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> I hope that this helps explain what we are after.=20 >>If it >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the working >> >> group, >> >> >>> >> >>>>>>>>> we can figure out what additional words are needed >> to >> >> >>> >> >>>>>>>>> convey this. If the working group disagree with the >> >> intent, >> >> >>> >> >>>>>>>>> then we will of course adjust to match the working >> >>group >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure >> >>what to >> >> >>> >> >>>>>>>>> try next. >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> Yours, Joel >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> >> _______________________________________________ >> >> sfc >> >> >>> >> mailing >> >> >>> >> >>>>>>>>> list sfc@ietf.org >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>>> >> _______________________________________________ >> >> sfc >> >> >>> >> mailing >> >> >>> >> >>>>>>>>> list sfc@ietf.org >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >>> >> >>>>>>>>> >> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> >> _______________________________________________ >> >> sfc >> >> >>> >> mailing >> >> >>> >> >>>>>>>> list sfc@ietf.org >> >>https://www.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=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 ------=_Part_3365_947045922.1405104386847 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Wouldn't that be ca= lled the "service chain identifier" then?  If the service chain is the= ordered list of SFs and the service path is the ordered list of SF instanc= es, then I would infer that a "service path identifier" would be an identif= ier for a service *path*, not a service *chain*.

Again, I thi= nk this is where the confusion keeps creeping in.  The terms "chain" a= nd "path" seem inconsistent.


=


From: jguichar@cisco.com&= lt;jguichar@cisco.com>
To: mikebianc@aol.com<mikebianc@aol.= com>,mn1921@att.com<mn1921@att.com>,mohamed.boucadair@orange.com&l= t;mohamed.boucadair@orange.com>,jmh@joelhalpern.com<jmh@joelhalpern.c= om>,Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com&g= t;,sfc@ietf.org<sfc@ietf.org>
Sent: Friday, July 11, 2014Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
Your definition of service path is correct as its the forwarding path = through which traffic will actually flow. The service path identifier howev= er points to the service chain data structure and that is then resolved to = specific instances based upon which next-hops to those instances are available and whatever load distribution = technique is in play. When instantiating the service chain into the network= you may or may not update that data structure to specify which next-hops m= ay be used (where a single next-hop would effectively nail up the service path for that service chain) or you = may simply allow some other protocol / mechanism to populate the data struc= ture for you.


I think this is the root of the confusion:

> I don=E2=80=99t want to specify
> specific instances of S1, S2, and S3 (or some combination = thereof). I
> assign a service path identifier =E2=80=9C100=E2=80=9D tha= t basically points to S1->S2->S3
> and then push this into the network

By definition, I understood a "service path" to be an ordered list of speci= fic SF instances. In the statement above, you use a "service path identifi= er" to refer to a service *chain* that specifically "[does not] specify spe= cific instances".



From: jguichar@cisco.com&l= t;jguichar@cisco.com>
To: NAPIERALA, MARIA H<mn1921@a= tt.com>,mohamed.bouc= adair@orange.com<moh= amed.boucadair@orange.com>,Joel M. Halpern<jmh@joelhalpern.com>,Ron Parker<Ron_Parker@af= firmednetworks.com>,sfc@ietf.org= <sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria,

I think of it this way. The service path identifier is simply a pointer to<= br> a data structure that contains SF to next-hop mappings. When you define a chain, let=E2=80=99s say S1 ->S2-> S3, you *might* when creating the = SFP specify
the specific next-hops that you want traffic to flow through for that SFP.<= br> However, you do *not* have to do this from an architectural standpoint (I will argue that you should but you don=E2=80=99t have to architecturally). = You
could simply assign a service path identifier to point to a given SFC and then push that information into the network. At the SFF it will have a
service path identifier to SFC mapping and said mapping would contain the next-hops available for each of the SF=E2=80=99s within the SFC - how you l= earn
those next-hops is up to you. You could push them down from a centralized controller, configure them through CLI, learn them dynamically through
some protocol exchange, whatever .. So, given this it is not correct to
say that the service path means that all SF instances are chosen a priori although it is perfectly acceptable (and some would say recommended) to do<= br> so.

Let=E2=80=99s take an example to hopefully make this clear:

I define an SFC (let=E2=80=99s refer to it as SFC-1) S1->S2->S3. For = arguments
sake let=E2=80=99s say I want it to be fully dynamic e.g. I don=E2=80=99t w= ant to specify
specific instances of S1, S2, and S3 (or some combination thereof). I
assign a service path identifier =E2=80=9C100=E2=80=9D that basically point= s to S1->S2->S3
and then push this into the network so that the SFF data structures are
populated with this information. Now at a given SFF, when traffic arrives with service path identifier 100, the SFF will look this up in the data
structure and find that it points to S1->S2->S3 and the index in the = SFC
encapsulation will tell it exactly where it is in the chain. Let=E2=80=99s = say we
are at S2 in the chain. The SFF will now have to resolve the next-hop to S3 and will do a lookup to determine where S3 is reachable.

On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

>Jim,
>
>Could you tell us what is the definition of a "service path" and a
>"service path identifier"?
>If a service path means that all SF instances are chosen apriori (which=
>is my current understanding) then it is not SFF's local decision which<= br> >next-hop SFF to pick. It is a centralized decision.
>
>Maria
>
>
>> -----Original Message-----
>>

From: Jim Guichard (jguichar) [mailto= :jguichar@cisco.com]
>> Sent: Friday, July 11, 2014 11:15 AM
>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M.
>> Halpern; Ron Parker; sfc@ietf.org<= /a>
>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
>>
>> I=E2=80=99m sorry but I really don=E2=80=99t understand why a serv= ice path identifier
>> prevents full distribution of SF next-hops or why calling it a ser= vice
>> chain identifier makes any difference?
>>
>> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:
>>
>> >Ditto.
>> >
>> >> -----Original Message-----
>> >> From: moh= amed.boucadair@orange.com
>> >> [mailto:m= ohamed.boucadair@orange.com]
>> >> Sent: Friday, July 11, 2014 10:31 AM
>> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. = Halpern; Ron
>> >> Parker; sfc@ietf.org<= br class=3D""> >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balanc= ers
>> >>
>> >> Re-,
>> >>
>> >> For what I can say at best this is not described clearly = in the
>>draft.
>> >>
>> >> Mandating a service path identifier is in itself a hint t= hat the full
>> >>distributed
>> >> model is not allowed.
>> >>
>> >> Several voices in this thread indicated that the service = chain itself
>> >>should be
>> >> provided instead.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> >-----Message d'origine-----
>> >> >De : sfc [mai= lto:sfc-bounces@ietf.org] De la part de Jim Guichard
>> >> >(jguichar)
>> >> >Envoy=C3=A9 : vendredi 11 juillet 2014 16:18
>> >> >=C3=80 : NAPIERALA, MARIA H; Joel M. Halpern; Ron Par= ker; sfc@ietf.org
>> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Bal= ancers
>> >> >
>> >> >Ok but where in the architecture specifically is this= functionality
>> >> >prohibited? If you want to distribute *all* next-hops= to *all* SFF=E2=80=99s
>> >> >within the SFC domain and then let the path identifie= r point to a
>> >>lookup
>> >> >into those next-hops to reach the next SF in the chai= n, I am not
>>sure
>> >>how
>> >> >the architecture prevents that?
>> >> >
>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com>
>> wrote:
>> >> >
>> >> >>Absolutely.
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard
>> >> >>>(jguichar)
>> >> >>> Sent: Friday, July 11, 2014 9:54 AM
>> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron= Parker; sfc@ietf.org
>> >> >>> Subject: Re: [sfc] Service Chains, Paths, an= d Load Balancers
>> >> >>>
>> >> >>> Then I misunderstand the proposal ;-) .. How= ever, it seems to me
>> >>that if
>> >> >>> you allow an SFF to make a decision as to wh= ich remote SFF it
>>will
>> >>use
>> >> >>>for
>> >> >>> a given flow to reach the next SF within the= chain then you
>>better
>> >>make
>> >> >>> sure that that remote SFF has the necessary = forwarding logic to
>> >>reach
>> >> >>>the
>> >> >>> next-next-SF for the chain as otherwise you = are in deep trouble.
>> >> >>>
>> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" &l= t;mn1921@att.com>
>> >> wrote:
>> >> >>>
>> >> >>> >Absolutely not. Service chains can be in= stantiated only in
>>relevant
>> >> >>>SFFs
>> >> >>> >when they "arrive".
>> >> >>> >
>> >> >>> >> -----Original Message-----
>> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim
>>Guichard
>> >> >>> >>(jguichar)
>> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM=
>> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org
>> >> >>> >> Subject: Re: [sfc] Service Chains, = Paths, and Load Balancers
>> >> >>> >>
>> >> >>> >> Well I think it is even worse than = that if I have understood
>>the
>> >> >>> >>proposal
>> >> >>> >> correctly as it would require full = knowledge of every single
>>SF
>> >> >>>within
>> >> >>> >>the
>> >> >>> >> entire SFC domain at every single S= FF as there is no way to
>>know
>> >>a
>> >> >>> >>priori
>> >> >>> >> which SFC=C2=B9s a given SFF will n= eed to service at any given
>>point
>> >>in
>> >> >>>time.
>> >> >>> >>
>> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halp= ern" <jmh@joelhalpern.com>=
>> >> wrote:
>> >> >>> >>
>> >> >>> >> >Ron, thinking about this, I rea= lized another major problem
>>with
>> >>the
>> >> >>> >>your
>> >> >>> >> >proposal as I understand it. (A= nd I readily admit I may not
>> >> >>>understand
>> >> >>> >> >it.)
>> >> >>> >> >
>> >> >>> >> >The proposal has each SFF serve= as the load balancer for the
>> >>next
>> >> >>> >> >service function that follows i= t (not the one it delivers
>>to),
>> >>in
>> >> >>>every
>> >> >>> >> >service chain that goes through= it.
>> >> >>> >> >
>> >> >>> >> >Since it has to be able to work= with all services, that means
>> >>that
>> >> >>> >>every
>> >> >>> >> >SFF would have to be a full, fl= ow sensitive and stateful load
>> >> >>>balancer.
>> >> >>> >> >I ahve no problem if some SFF a= re flow sensitive, and / or
>> >>stateful.
>> >> >>> >> >But having the architecture req= uire that every SFF be a full,
>> >>flow
>> >> >>> >> >sensitive, stateful, load balan= cer seems to me to be an
>> >>acceptable
>> >> >>> >> >imposition.
>> >> >>> >> >
>> >> >>> >> >Yours,
>> >> >>> >> >Joel
>> >> >>> >> >
>> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. H= alpern wrote:
>> >> >>> >> >> Part of my personal view i= s that I am trying to make this
>>work
>> >> >>> >>sensibly
>> >> >>> >> >> in a more orchestrated env= ironment. I expect that the
>>service
>> >> >>> >> >> functions, and over time p= robably the SFF capabilities,
>>will
>> >>be
>> >> >>> >> >> orchestrated and installed= . I expect the service chains
>>to be
>> >> >>> >>driven by
>> >> >>> >> >> BSS tools that define offe= rings to clients, and enable
>> >> >>>self-selection
>> >> >>> >> >> from these. I expect servi= ce paths to be heavily policy
>> >>drive.
>> >> >>> >> >>
>> >> >>> >> >> I can see how to make all = of that work in an archtiecture
>> >>driven
>> >> >>>by
>> >> >>> >> >> initial classification to = described service paths. It is
>> >>harder
>> >> >>>to
>> >> >>> >>see
>> >> >>> >> >> how to make it work (but i= t can be done) when we allow more
>> >> >>> >> dynamicity
>> >> >>> >> >> in the network behavior. >> >> >>> >> >>
>> >> >>> >> >> Having said that, most of = that perspective I described is
>> >>outside
>> >> >>>of
>> >> >>> >>the
>> >> >>> >> >> scope of the working group= . it is not something we are
>> >>tasked to
>> >> >>> >>agree
>> >> >>> >> >>on.
>> >> >>> >> >> So I do not claim that vis= ion means we have to do it a
>>certain
>> >> >>>way.
>> >> >>> >>it
>> >> >>> >> >> is just the perspective th= at drives my preferences.
>> >> >>> >> >>
>> >> >>> >> >> Yours,
>> >> >>> >> >> Joel
>> >> >>> >> >>
>> >> >>> >> >> On 7/10/14, 9:58 PM, Ian S= mith wrote:
>> >> >>> >> >>>> For me, the amount= of information about service instances
>> >> that
>> >> >>> >>needs
>> >> >>> >> >>>>to
>> >> >>> >> >>>> be widely distribu= ted and maintained, potentially even
>> >>across
>> >> >>>data
>> >> >>> >> >>>> centers within an = administrative scope, is large enough
>>and
>> >> >>> complex
>> >> >>> >> >>>> enough that trying= to get that into each SFF seems like a
>> >> >>>difficult
>> >> >>> >> >>>> architecture to re= alize.
>> >> >>> >> >>>
>> >> >>> >> >>> I'm curious as to why = that is more complicated than
>>dynamic
>> >> >>> routing,
>> >> >>> >> >>> hyper-scale data cente= r orchestration, or DNS, all of
>>which
>> >>are
>> >> >>> >>bigger
>> >> >>> >> >>> problems that have bee= n profitably and stably implemented?
>> >> >>> >> >>>
>> >> >>> >> >>> It also seems that if = it really is more complicated, that
>>is
>> >>a
>> >> >>>good
>> >> >>> >> >>> sign that it is too co= mplicated.
>> >> >>> >> >>>
>> >> >>> >> >>> ______________________= __________________
>> >> >>> >> >>> From: Joel M. Halpern = [jmh@joelhalpern.com]
>> >> >>> >> >>> Sent: Thursday, July 1= 0, 2014 9:45 PM
>> >> >>> >> >>> To: Ron Parker; Joel H= alpern Direct; mikebianc@aol.com;
>>Ian
>> >> >>>Smith;
>> >> >>> >> >>> sfc@ietf.org
>> >> >>> >> >>> Subject: Re: [sfc] Ser= vice Chains, Paths, and Load
>>Balancers
>> >> >>> >> >>>
>> >> >>> >> >>> This is an architectur= al issue. And one that I would
>>prefer
>> >>we
>> >> >>> >> >>>actually
>> >> >>> >> >>> decide, rather than tr= ying to allow all possible
>> >>implementations.
>> >> >>> >> >>> Because it does have a= major effect on the control
>> >>requirements
>> >> >>>and
>> >> >>> >> the
>> >> >>> >> >>> functionality of SFFs.=
>> >> >>> >> >>>
>> >> >>> >> >>> For me, the amount of = information about service instances
>> >>that
>> >> >>> needs
>> >> >>> >> to
>> >> >>> >> >>> be widely distributed = and maintained, potentially even
>> across
>> >> >>>data
>> >> >>> >> >>> centers within an admi= nistrative scope, is large enough
>>and
>> >> >>>complex
>> >> >>> >> >>> enough that trying to = get that into each SFF seems like a
>> >> >>>difficult
>> >> >>> >> >>> architecture to realiz= e.
>> >> >>> >> >>>
>> >> >>> >> >>> Yours,
>> >> >>> >> >>> Joel
>> >> >>> >> >>>
>> >> >>> >> >>> But it is a fair quest= ion.
>> >> >>> >> >>>
>> >> >>> >> >>> On 7/10/14, 9:38 PM, R= on Parker wrote:
>> >> >>> >> >>>> This is the crux o= f my issue. Is the end to end
>>selection
>> >>of
>> >> >>> >> >>>> (top-level) instan= ces performed centrally (perhaps by the
>> >> >>> >>classifier)
>> >> >>> >> >>>> or hop-by-hop (per= haps by the classifier and subsequently
>> >>the
>> >> >>> >>SFFs)?
>> >> >>> >> >>>> Such selection is = not equivalent to reclassification.
>>And
>> >> >>>surely,
>> >> >>> >> >>>> this is an archite= ctural issue and not relegated to
>> >> >>> >> >>>> "implementation".<= br class=3D""> >> >> >>> >> >>>>
>> >> >>> >> >>>> My own view is to = favor the distributed approach even
>> though
>> >> a
>> >> >>> >> >>>> greater amount of = data (chain definitions and perhaps
>>local
>> >> >>> >>selection
>> >> >>> >> >>>> policy) is require= d at those distributed decision points.
>> >>This
>> >> >>> >> >>>> approach does not = require an end-to-end path id at all.
>> >>My
>> >> >>> >> >>>> rationale for favo= ring this approach is primarily driven
>>by
>> >> >>> >>increased
>> >> >>> >> >>>> resiliency over th= e global path id approach. With a
>>global
>> >> >>>path
>> >> >>> >>id
>> >> >>> >> >>>> approach, consider= failure of an instance and needing to
>> >>alter
>> >> >>>the
>> >> >>> >> >>>> global path ID tab= le for each and every affected
>>end-to-end
>> >> >>>path.
>> >> >>> >> >>>>
>> >> >>> >> >>>> Ron
>> >> >>> >> >>>>
>> >> >>> >> >>>> __________________= ______________________ From: sfc
>> >> >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern = Direct
>> >> >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday= , July 10,
>>2014
>> >> 6:15
>> >> >>> PM
>> >> >>> >> >>>> To: mikebianc@aol.com; I.Smith@F5.com; sfc@ietf.org
>> Subject:
>> >> Re:
>> >> >>> >> >>>> [sfc] Service Chai= ns, Paths, and Load Balancers
>> >> >>> >> >>>>
>> >> >>> >> >>>> The way the archit= ecture models the case of SF1 needing
>>to
>> >> >>> >>influence
>> >> >>> >> >>>> the chain is that = one would do reclassification at the
>>exit
>> >>from
>> >> >>> >> >>>> SF1.
>> >> >>> >> >>>>
>> >> >>> >> >>>> Part of the goal i= s to keep the different functions
>> >>logically
>> >> >>> >> >>>> separate so that s= olutions can clearly describe how they
>> >> choose
>> >> >>>to
>> >> >>> >> >>>> compose them for "= service" delivery.
>> >> >>> >> >>>>
>> >> >>> >> >>>> Yours, Joel
>> >> >>> >> >>>>
>> >> >>> >> >>>> On 7/10/14, 6:10 P= M, mikebianc@aol.com wrote:
>> >> >>> >> >>>>> I don't see an= ything in the arch draft that suggests any
>> >>sort
>> >> >>>of
>> >> >>> >> >>>>> limit. However= , it does seem to indicate that the entire
>> >>path
>> >> >>>(all
>> >> >>> >> >>>>> SFIs) must be = chosen at SFC instantiation. I believe
>>this
>> >> >>>means
>> >> >>> >> >>>>> either at the = classifier or maybe the classifier
>>chooses a
>> >>SF
>> >> >>> >>Chain
>> >> >>> >> >>>>> and the NF or = at the latest the first SFF. In any case,
>> >>the
>> >> >>> >> >>>>> language does = seem to prohibit a more dynamic SFP where
>> >> SFI(n)
>> >> >>> is
>> >> >>> >> >>>>> determined at = the SFI(n-1) hop. According to the draft,
>> >>this
>> >> >>> >> >>>>> behavior would= be considered "branching" to a new SFP as
>> >> >>> opposed
>> >> >>> >> to
>> >> >>> >> >>>>> choosing and t= hen forwarding to the selected instance of
>> >>the
>> >> >>> >> >>>>> next-hop of th= e current SFC.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> draft-merged-s= fc-architecture-00:
>> >> >>> >> >>>>>> When an SF= C is instantiated into the network it is
>> >>necessary
>> >> >>>to
>> >> >>> >> >>>>>> select the= specific instances of SFs that will be used,
>> >>and to
>> >> >>> >> >>>>>> create the= service topology for that SFC using SF's
>> >>network
>> >> >>> >> >>>>>> locator. T= hus, instantiation of the SFC results in the
>> >> >>>creation
>> >> >>> >> >>>>>> of a Servi= ce Function Path (SFP) and is used for
>> >>forwarding
>> >> >>> >> >>>>>> packets th= rough the SFC. In other words, an SFP is the
>> >> >>> >> >>>>>> instantiat= ion of the defined SFC.
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> The SFC ar= chitecture supports reclassification (or
>> >>non-initial
>> >> >>> >> >>>>>> classifica= tion) as well. As packets traverse an SFP,
>> >> >>> >> >>>>>> reclassifi= cation may occur - typically performed by a
>> >> >>> >> >>>>>> classifica= tion function co-resident with a service
>> >>function.
>> >> >>> >> >>>>>> Reclassifi= cation may result in the selection of a new
>> >>SFP, an
>> >> >>> >> >>>>>> update of = the associated metadata, or both. This is
>> >>referred
>> >> >>>to
>> >> >>> >> >>>>>> as "branch= ing".
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> >>>
>> >>
>>
>>>>>>>>>>>>>>-------------------= ------------------------------------------
>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>---
>> >> >>>>>>>>>>--
>> >> >>> >>>>>>>--
>> >> >>> >> >>>>>--
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>> *From: *I.Smith@F5.com<I.Smith@F5.com>
>> >> >>> >> >>>>> *To: *Joel Hal= pern
>> Direct<jmh.direct= @joelhalpern.com>,Joel
>> >> M.
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> >>>
>> >>
>> >>>>>Halpern<jmh@joelhalpern.com>,hu= ang@sce.carleton.ca<huang@sce.
>> >> >>> >> carleton.
>> >> >>> >> >>>>>ca>,sfc@ietf.org<sfc@ietf.org>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>> *Sent: *Thursday, July= 10, 2014
>> >> >>> >> >>>>> *Subject: *Re:= [sfc] Service Chains, Paths, and Load
>> >>Balancers
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> Actually, I th= ink I am disagreeing.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> If the possibi= lity of medium-scale deployments (and
>>that is
>> >> >>>what
>> >> >>> >> >>>>> 16 million flo= ws is in my world) of service chains is
>> >> >>>preconceived
>> >> >>> >> >>>>> as an absurd i= dea, then the architecture burdened with
>> that
>> >> >>> >> >>>>> preconception.=
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> There has to b= e some point of aim, some degree of
>> >>aspiration
>> >> to
>> >> >>> >> >>>>> scale that is = appropriate for the lifespan of the
>> >>architecture
>> >> >>>-
>> >> >>> >> >>>>> you don't have= to know what it is, but by saying that an
>> >> >>>arbitrary
>> >> >>> >> >>>>> number is "too= far", you're creating - even if it isn't
>> >> >>> >>intentional
>> >> >>> >> >>>>> - a limit that= influences decisions that have lasting
>> >>impacts
>> >> >>> >> >>>>> regarding scal= e-out, failure mitigation, elasticity,
>> >>address
>> >> >>> >> >>>>> space... all k= inds of things. That is a problem I'm not
>> >> >>> >> >>>>> particularly e= ager to deal with.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> ______________= __________________________
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> From: Joel Hal= pern Direct [jmh.direct@joelh= alpern.com]
>> >>Sent:
>> >> >>> >> >>>>> Thursday, July= 10, 2014 5:04 PM To: Ian Smith; Joel M.
>> >> Halpern;
>> >> >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: [sfc]
>> >>Service
>> >> >>> >> >>>>> Chains, Paths,= and Load Balancers
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> Ian, I don't t= hink you disagree with me at all in this
>> >>regard.
>> >> >>>I
>> >> >>> >>am
>> >> >>> >> >>>>> not requesting= the the architecture or the solution
>> >>prohibit
>> >> >>> >> >>>>> deployments in= the specific fashion. I am objecting to
>> >>Huang's
>> >> >>> >> >>>>> reading of my = note as saying that such deployments are
>> >> required
>> >> >>> >> >>>>> they by the ar= chtiecture.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> As I have said= repeatedly, I am not trying to prohibit
>>such
>> >> >>> >> >>>>> things. Whethe= r they are a good idea or not depends upon
>> >> many
>> >> >>> >> >>>>> factors outsid= e of the scope of the WG. I happen to
>>think
>> >>that
>> >> >>> >>they
>> >> >>> >> >>>>> are usually a = bad idea.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> But the archti= ecture si carefully avoiding attempting to
>> >>know
>> >> >>>what
>> >> >>> >> >>>>> is and is not = eployable.
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> Yours, Joel >> >> >>> >> >>>>>
>> >> >>> >> >>>>> On 7/10/14, 5:= 01 PM, Ian Smith wrote:
>> >> >>> >> >>>>>> I disagree= .
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> We routine= ly have stateful devices that manage tens of
>> >> >>>millions
>> >> >>> >> >>>>>> of
>> >> >>> >> >>>>> concurrent flo= ws in both access network and data center
>> >> >>> >> >>>>> environments t= oday. You can't seriously believe that in
>>the
>> >> >>> >> >>>>> Cloud/IPv6/Mob= ility/Web2.0/IoT world of tomorrow you
>> are
>> >> only
>> >> >>> >> going
>> >> >>> >> >>>>> to have small = numbers of service chains with equally
>>small
>> >> >>> numbers
>> >> >>> >> >>>>> of active serv= ice paths?
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> Your sound= s too much like "no one will ever need more
>> than
>> >> >>> 64K"
>> >> >>> >> >>>>>> for
>> >> >>> >> >>>>> comfort.
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> __________= ______________________________ From: sfc
>> >> >>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joe= l M. Halpern
>> >> >>> >> >>>>> [jmh@joelhalpern.com]
>> >> >>> >> >>>>>> Sent: Thur= sday, July 10, 2014 4:46 PM To:
>> >> >>>huan= g@sce.carleton.ca;
>> >> >>> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service Chains, P= aths,
>>and
>> >> >>>Load
>> >> >>> >> >>>>>> Balancers<= br class=3D""> >> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> No, it wil= l mean that if someone tries to deploy the
>> >> >>>archtieture
>> >> >>> >> >>>>>> particular= ly badly, they will exceed the limits of
>>their
>> >> >>> >> >>>>>> devices. T= he architecture does not require such absurd
>> use
>> >> of
>> >> >>> >> >>>>>> service pa= ths. Since I can not figure out how to write
>> >> >>> >> >>>>>> architectu= ral words to prohibit it, the architecture
>>does
>> >> >>>permit
>> >> >>> >> >>>>>> such abuse= .
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> Please do = not read my saying that the archtiecture
>> permits
>> >> >>> >> >>>>>> something = as saying it is either deisred or required by
>> >>the
>> >> >>>work.
>> >> >>> >> >>>>>> It isn't.<= br class=3D""> >> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> Yours, Joe= l
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> On 7/10/14= , 4:36 PM, Changcheng Huang wrote:
>> >> >>> >> >>>>>>> If you= need to support 100 service chains, it will
>>mean
>> >> >>> >> >>>>>>> 16,000= ,000 paths. That is larger than the routing
>>table
>> >>of a
>> >> >>> >> >>>>>>> core r= outer.
>> >> >>> >> >>>>>>>
>> >> >>> >> >>>>>>> Chang<= br class=3D""> >> >> >>> >> >>>>>>>
>> >> >>> >> >>>>>>> On 07/= 10/2014 01:15 PM, Joel M. Halpern wrote:
>> >> >>> >> >>>>>>>> Th= e architecture allows a range of deployments, from
>>1
>> >> >>> >> >>>>>>>> se= rvice path to 160000 service paths. I would hope
>>that
>> >> >>> >> >>>>>>>> op= erators are prepared for the complexities if they
>> >>choose
>> >> >>>to
>> >> >>> >> >>>>>>>> av= oid any use of local load balancing and in stead
>> >> provision
>> >> >>> >> >>>>>>>> 16= 0,000 service paths.
>> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> Yo= urs, Joel
>> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> On= 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
>> >> >>> >> >>>>>>>>>= ; Paul,
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; How many path identifiers there will be for a 4 hop
>> >> service
>> >> >>> >> >>>>>>>>>= ; chain with 20 instances at each hop?
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Maria
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; *From:*sfc [mailto:sfc-bounces@ie= tf.org] *On Behalf
>> Of
>> >> >>> >> >>>>>>>>>= ; *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014
>> >>3:03
>> >> >>> >> >>>>>>>>>= ; PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com;
>> >> >>> >> >>>>>>>>>= ; mohamed.boucadair@orange.= com; sfc@ietf.org;
>> >> >>> >> >>>>>>>>>= ; mikebianc@aol.com *Subject:* Re:= [sfc] Service
>> Chains,
>> >> >>> >> >>>>>>>>>= ; Paths, and Load Balancers
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Lucy,
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Overall I concur, as you say: a path ID drives the
>> >> >>> >> >>>>>>>>>= ; forwarding. I=C2=B9d
>> >> >>> >> >>>>> make
>> >> >>> >> >>>>>>>>>= ; the minor change: the path identifier can be used to
>> >> derive
>> >> >>> >> >>>>>>>>>= ; the needed forwarding and associated transport.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; It is _not_ the transport, but rather is used to
>>simply
>> >> >>> >> >>>>>>>>>= ; identify the service path (or graph) that packets
>>must
>> >> >>> >> >>>>>>>>>= ; traverse. By having a path identifier, the exact
>> >> >>> >> >>>>>>>>>= ; indirection that people seem to be asking for on
>>this
>> >> >>> >> >>>>>>>>>= ; thread can be simply be implemented. The path
>> >> identifier
>> >> >>> >> >>>>>>>>>= ; provides nothing more than a lookup, that lookup can
>> >> result
>> >> >>> >> >>>>>>>>>= ; in a one or more (equal or weighted) transport next
>> >> >>> >> >>>>>>>>>= ; hop(s).
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Paul
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; On Jul 10, 2014, at 11:04 AM, Lucy yong
>> >> >>> >> >>>>>>>>>= ; <lucy.yong@huawei.com
>> >> <mailto:lu= cy.yong@huawei.com>>
>> >> >>> >> >>>>>>>>>= ; wrote:
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Agree. The arch. doc should not mandate only use of
>> the
>> >> >>> >> >>>>>>>>>= ; service path identifier to drive the forwarding
>> >>actions.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Lucy
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; *From:*sfc [mailto:sfc-bounce= s@ietf.org]*On Behalf
>> >> >>> >> >>>>>>>>>= ; Of*mohamed.boucadair@o= range.com
>> >> >>> >> >>>>>>>>>= ; <mailto:mohamed.boucad= air@orange.com>
>> >> >>> *Sent:*Thursday,
>> >> >>> >> July
>> >> >>> >> >>>>>>>>>= ; 10, 2014 2:06 AM *To:*mikebianc@aol= .com
>> >> >>> >> >>>>>>>>>= ; <mailto:m= ikebianc@aol.com>;jmh@joelhalpern.com
>> >> >>> >> >>>>>>>>>= ; <mailto:jmh@jo= elhalpern.com>;sfc@ietf.org
>> >> >>> >> >>>>>>>>>= ; <mailto:sfc@ietf.org> *Subject:= *Re: [sfc] Service
>> >>Chains,
>> >> >>> >> >>>>>>>>>= ; Paths, and Load Balancers
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Re-,
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; The merged draft calls out explicitly a service path
>> >> >>> >> >>>>>>>>>= ; identifier. I object to use that identifier to
>>derive
>> >> >>> >> >>>>>>>>>= ; forwarding actions.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Requiring a SFC system to have the full knowledge of
>> >> every
>> >> >>> >> >>>>> available SFC<= br class=3D""> >> >> >>> >> >>>>>>>>>= ; forwarding paths within an SFC-enabled domain is not
>> >> >>> >> >>>>> required/justi= fied
>> >> >>> >> >>>>>>>>>= ; nor possible in various deployment contexts.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; SFC forwarding actions should rely on the piece of
>> >> >>> >> >>>>>>>>>= ; information
>> >> >>> >> >>>>> that will
>> >> >>> >> >>>>>>>>>= ; be present in all deployments: that is the one
>> required
>> >> to
>> >> >>> >> >>>>>>>>>= ; structure a service chain. How that information is
>> >>used to
>> >> >>> >> >>>>>>>>>= ; infer forwarding
>> >> >>> >> >>>>> actions
>> >> >>> >> >>>>>>>>>= ; is a solution-oriented discussion.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Cheers,
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Med
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; *De :*sfc [mailto:sfc-bounces= @ietf.org]*De la part
>> >> >>> >> >>>>> de*mikebianc@aol.com
>> >> >>> >> >>>>>>>>>= ; <mailto:mikebianc@aol.com>= *Envoy=C3=A9 :*mercredi 9
>> >> juillet
>> >> >>> >> >>>>>>>>>= ; 2014 22:03 *=C3=80 :*jmh@joelhalp= ern.com
>> >> >>> >> >>>>>>>>>= ; <mailto:jmh@jo= elhalpern.com>;sfc@ietf.org
>> >> >>> >> >>>>>>>>>= ; <mailto:sfc@ietf.org> *Objet :*= Re: [sfc] Service
>> >>Chains,
>> >> >>> >> >>>>>>>>>= ; Paths, and Load Balancers
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Is anyone still questioning the difference between
>>SF
>> >> Chain
>> >> >>> >> >>>>>>>>>= ; and SF
>> >> >>> >> >>>>> Path?
>> >> >>> >> >>>>>>>>>= ; Other than clarifying the definition so that it's
>> >>clear to
>> >> >>> >> >>>>> those not
>> >> >>> >> >>>>>>>>>= ; familiar with the draft, it seems that everyone
>>agrees
>> >>on
>> >> >>> >> >>>>>>>>>= ; these terms.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; To me, the one point that is still unclear is
>>whether
>> >>it is
>> >> >>> >> >>>>>>>>>= ; the intent of this draft to ultimately specify what
>> >>the ID
>> >> >>> >> >>>>>>>>>= ; of the SFC Header
>> >> >>> >> >>>>> should
>> >> >>> >> >>>>>>>>>= ; reference (the chain or the path), or if this draft
>> >>simply
>> >> >>> >> >>>>>>>>>= ; intends to leave that ambiguous, allowing other
>>drafts
>> >>to
>> >> >>> >> >>>>>>>>>= ; dictate the mechanisms for forwarding based on chain
>> or
>> >> >>> >> >>>>>>>>>= ; path and the choice of chain or
>> >> >>> >> >>>>> path to
>> >> >>> >> >>>>>>>>>= ; be negotiated in the control-plane.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; If the latter (ambiguous), then the draft would have
>> >> >>> >> >>>>>>>>>= ; require that both SFP and SFC be supported (or make
>> >> one
>> >> >>> >> >>>>>>>>>= ; required and the other optional) to avoid some
>> vendors
>> >> only
>> >> >>> >> >>>>>>>>>= ; supporting SFP and others only supporting SFC.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> >>>
>> >>
>>
>>>>>>>>>>>>>>-------------------= ------------------------------------------
>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>---
>> >> >>>>>>>>>>--
>> >> >>> >>>>>>>--
>> >> >>> >> >>>>>--
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>>>>
>> >> >>> >> >>>>>>>>>= ; *From:*jmh@joelhalpern.com<= ;jmh@joelhalpern.com
>> >> >>> >> >>>>>>>>>= ;
>> >> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>> >> >> >>> >> >>>>>>>>>= ; *To:*sfc@ietf.org<sfc@ietf.org
>> >> >>> >> >>>>>>>>>= ; <mailto:sfc@ietf.or= g%3csfc@ietf.org>>
>> *Sent:*Tuesday,
>> >> July
>> >> >>> >> >>>>>>>>>= ; 8, 2014 *Subject:*[sfc] Service Chains, Paths, and
>>Load
>> >> >>> >> >>>>>>>>>= ; Balancers
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; I have been trying to figure out how to clearly
>>answer
>> >>a
>> >> >>> >> >>>>>>>>>= ; number of comments that have been made about the
>> >> >>> proposed
>> >> >>> >> >>>>>>>>>= ; merged archtiecture draft. Assuming we can get
>> working
>> >> >>> >> >>>>>>>>>= ; group agreement on the intent, we will work to
>> improve
>> >> the
>> >> >>> >> >>>>>>>>>= ; wording so that readers who have not participated in
>> >>the
>> >> WG
>> >> >>> >> >>>>>>>>>= ; discussion will understnd it the way the
>> >> >>> >> >>>>> working
>> >> >>> >> >>>>>>>>>= ; group intends.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; But what do we intend? I will try to explain my
>> >>personal
>> >> >>> >> >>>>>>>>>= ; view, and see if that helps.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; In this regard, it is important to keep in mind that
>> >>what
>> >> >>> >> >>>>>>>>>= ; we are defining is the data plane architecture. We
>>are
>> >> not
>> >> >>> >> >>>>>>>>>= ; attempting to define the architecture for the entire
>> >> >>> >> >>>>>>>>>= ; solution for service chaining. That would encompass
>> >> >>> >> >>>>>>>>>= ; OSS/BSS, various control and policy functions,
>>virtual
>> >> >>> >> >>>>>>>>>= ; machine and image management, and many other
>> >> aspects.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; As a result there are many things which clearly need
>> to
>> >> >>> >> >>>>>>>>>= ; exist in the larger system, but which are dealt with
>> >>above
>> >> >>> >> >>>>>>>>>= ; where we are
>> >> >>> >> >>>>> functioning, >> >> >>> >> >>>>>>>>>= ; and are not directly required by the work we are
>> doing.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; In order to get to service chain vs service path,
>>as I
>> >> >>> >> >>>>>>>>>= ; understand
>> >> >>> >> >>>>> them,
>> >> >>> >> >>>>>>>>>= ; I need to first discuss load balancing. There are at
>> >>least
>> >> >>> >> >>>>>>>>>= ; three different ways that load balancing can and
>>will
>> >> >>> >> >>>>>>>>>= ; interact with service chaining. There probably are
>> >>more.
>> >> >>> >> >>>>>>>>>= ; The point of the archtiecture is to permit all of
>> >>these,
>> >> >>> >> >>>>>>>>>= ; but not to mandate that any particular kind
>> >> >>> >> >>>>> be used
>> >> >>> >> >>>>>>>>>= ; in any solution.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; 1) Load balancing as a service provided to the end
>> >>user.
>> >> >>> >> >>>>>>>>>= ; This is a service function. It receives user
>>packets,
>> >>and
>> >> >>> >> >>>>>>>>>= ; modifies them (or
>> >> >>> >> >>>>> marks
>> >> >>> >> >>>>>>>>>= ; them, or ...) so as to choose an end user service
>> >>instance
>> >> >>> >> >>>>>>>>>= ; to receive the users packet. This is an important
>> >>service
>> >> >>> >> >>>>>>>>>= ; function to be able to include in service chaining.
>> >>It's
>> >> >>> >> >>>>>>>>>= ; behavior may affect requirements on how service
>> >> chaining is
>> >> >>> >> >>>>>>>>>= ; done. But it has very little impact on the
>> >>archtiecture.
>> >> >>> >> >>>>>>>>>= ; From an architectural pe3rspective it is simply a
>> >> >>> >> >>>>> service
>> >> >>> >> >>>>>>>>>= ; function which may modify the underlying packet.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; 2) There is internal load balancing. That is, one
>>can
>> >>have
>> >> >>> >> >>>>>>>>>= ; what
>> >> >>> >> >>>>> appears
>> >> >>> >> >>>>>>>>>= ; to the service chaining architecture as a single
>>point
>> >>of
>> >> >>> >> >>>>>>>>>= ; contact
>> >> >>> >> >>>>> for a
>> >> >>> >> >>>>>>>>>= ; specific service function, but is actually delivered
>> >>by a
>> >> >>> >> >>>>> collection of<= br class=3D""> >> >> >>> >> >>>>>>>>>= ; virtual or physical machines, possibly including
>>one or
>> >> >>> >> >>>>>>>>>= ; several load balancers (for example using VRRP-like
>> >> >>> >> >>>>>>>>>= ; techniques to share a MAC address.) mostly, this is
>> >> >>> >> >>>>>>>>>= ; invisible to the service chaining data plane
>> >>mechanisms.
>> >> It
>> >> >>> >> >>>>>>>>>= ; is likely that it is visible to various control
>> >>mechanisms,
>> >> >>> >> >>>>>>>>>= ; such as those responsible for scale-in, scale-out,
>>and
>> >>vm
>> >> >>> >> >>>>>>>>>= ; instantiation. The architectural impact of
>>permitting
>> >>this
>> >> >>> >> >>>>>>>>>= ; is largely that we need to be careful that our
>> >>terminology
>> >> >>> >> >>>>>>>>>= ; does not lead
>> >> >>> >> >>>>> readers to
>> >> >>> >> >>>>>>>>>= ; think we are prohibiting it.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; 3) There can also be load balancing done by
>>selecting
>> >> >>> >> >>>>>>>>>= ; packet paths for the service chaining that direct
>> >>traffic
>> >> >>> >> >>>>>>>>>= ; to different places. We would not want to require
>> that
>> >>a
>> >> >>> >> >>>>>>>>>= ; given service function appear at only one place in
>>the
>> >> >>> >> >>>>>>>>>= ; network.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; It is of course the case that these may be
>>combined. I
>> >> tend
>> >> >>> >> >>>>>>>>>= ; to
>> >> >>> >> >>>>> refer to
>> >> >>> >> >>>>>>>>>= ; the collection of entities that appear to service
>> >>chaining
>> >> >>> >> >>>>>>>>>= ; as a single point as a cluster. Not because cluster
>>is
>> >>a
>> >> >>> >> >>>>>>>>>= ; good term. But because I do not have another one.
>> Thus,
>> >> the
>> >> >>> >> >>>>>>>>>= ; point of type 3 load balancing
>> >> >>> >> >>>>> is to
>> >> >>> >> >>>>>>>>>= ; direct different subsets of traffic to different
>> >>singular
>> >> >>> >> >>>>>>>>>= ; or clustered service functions in different places
>>in
>> >>the
>> >> >>> >> >>>>>>>>>= ; network.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Now with that said, what do I mean when I talk about
>> >> >>> >> >>>>>>>>>= ; service chain and service path/ Service chain is a
>> >> sequence
>> >> >>> >> >>>>>>>>>= ; of logical functions to be applied to a subset of
>> >>packets.
>> >> >>> >> >>>>>>>>>= ; It is equivalent of saying that some subset of
>>traffic
>> >>is
>> >> >>> >> >>>>>>>>>= ; to get DPI, charging, content inspection, and
>>firewall
>> >> >>> >> >>>>>>>>>= ; while a different subset is to go directly to the
>>cache
>> >> >>> >> >>>>> without
>> >> >>> >> >>>>>>>>>= ; visiting any other service functions.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; That is not enough information to direct the
>>packets.
>> A
>> >> >>> >> >>>>>>>>>= ; service path is, in some fashion, a sequence of
>> >>locations
>> >> >>> >> >>>>>>>>>= ; in the network. Those locations will be singular or
>> >> >>> >> >>>>>>>>>= ; clustered service function delivery locations. They
>> >>may be
>> >> >>> >> >>>>>>>>>= ; addressed by IP address. They may be addressed as
>> ports
>> >> on
>> >> >>> >> >>>>>>>>>= ; an SFF. There are many different ways that the
>> >>locations
>> >> >>> >> >>>>>>>>>= ; may be known to the service chaining infrastructure
>> and
>> >> the
>> >> >>> >> >>>>>>>>>= ; transport.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;> From the point of view of the work of the SFC
>>group,
>> >> we
>> >> >>> >> >>>>>>>>>= ;> need to be
>> >> >>> >> >>>>>>>>>= ; able to talk about the high level abstraction, the
>> >>service
>> >> >>> >> >>>>>>>>>= ; chain, which drives the forwarding. And we need to
>> talk
>> >> >>> >> >>>>>>>>>= ; about the actual data path packets will take in the
>> >> >>> >> >>>>>>>>>= ; network.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Several of the comments have said "but the whole
>> path
>> >> may
>> >> >>> >> >>>>>>>>>= ; not be known at the front." This architecture deals
>> >>with
>> >> >>> >> >>>>>>>>>= ; that issue in two ways. First, as noted in item (2)
>>on
>> >>load
>> >> >>> >> >>>>>>>>>= ; balancers above, there can be decisions and
>>behaviors
>> >> which
>> >> >>> >> >>>>>>>>>= ; are invisible to the service chaining mechanisms (in
>> >>much
>> >> >>> >> >>>>>>>>>= ; the same way that bridging within a LAN is largely
>> >> >>> >> >>>>>>>>>= ; invisible to routing between LANs.) The other
>> provision
>> >> we
>> >> >>> >> >>>>>>>>>= ; make is
>> >> >>> >> >>>>> that
>> >> >>> >> >>>>>>>>>= ; reclassification can be done in mid-chain when
>> >> necessary.
>> >> >>> >> >>>>>>>>>= ; That will direct packets to a new chain. Based on
>> >> >>> >> >>>>>>>>>= ; information available at the re-classification
>>point.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; I hope that this helps explain what we are after.
>>If it
>> >> >>> >> >>>>>>>>>= ; does, and if the intent is acceptable to the working
>> >> group,
>> >> >>> >> >>>>>>>>>= ; we can figure out what additional words are needed
>> to
>> >> >>> >> >>>>>>>>>= ; convey this. If the working group disagree with the
>> >> intent,
>> >> >>> >> >>>>>>>>>= ; then we will of course adjust to match the working
>> >>group
>> >> >>> >> >>>>>>>>>= ; agreements. If this is still unclear, I am not sure
>> >>what to
>> >> >>> >> >>>>>>>>>= ; try next.
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ; Yours, Joel
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;
>> _______________________________________________
>> >> sfc
>> >> >>> >> mailing
>> >> >>> >> >>>>>>>>>= ; list sfc@ietf.org <mailto:sfc@ietf.org>
>> >> >>> >> >>>>>>>>>= ; https://www.ietf.or= g/mailman/listinfo/sfc
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>>>= ;
>> _______________________________________________
>> >> sfc
>> >> >>> >> mailing
>> >> >>> >> >>>>>>>>>= ; list sfc@ietf.org <mailto:sfc@ietf.org>
>> >> >>> >> >>>>>>>>>= ; https://www.ietf.or= g/mailman/listinfo/sfc
>> >> >>> >> >>>>>>>>>= ;
>> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>> >> _______________________________________________
>> >> sfc
>> >> >>> >> mailing
>> >> >>> >> >>>>>>>> li= st sfc@ietf.org
>> >>http= s://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>>>>> >> >> >>> >> >>>>>>>
>> >> >>> >> >>>>>>> ______= _________________________________________
>> sfc
>> >> >>> >> mailing
>> >> >>> >> >>>>>>> list <= a href=3D"mailto:sfc@ietf.org">sfc@ietf.org
>> >>http= s://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>>>>
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> __________= _____________________________________
>> sfc
>> >> >>> mailing
>> >> >>> >> list
>> >> >>> >> >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>
>> >> >>> >> >>>>> ______________= _________________________________ sfc
>> >> >>> mailing
>> >> >>> >> list
>> >> >>> >> >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>
>> >> >>> >> >>>> __________________= _____________________________ sfc
>> >> mailing
>> >> >>> >> list
>> >> >>> >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>
>> >> >>> >> >>>> __________________= _____________________________ sfc
>> >> mailing
>> >> >>> >> list
>> >> >>> >> >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >> >>>>
>> >> >>> >> >>>
>> >> >>> >> >>
>> >> >>> >> >> __________________________= _____________________
>> >> >>> >> >> sfc mailing list
>> >> >>> >> >> sfc@ietf.org
>> >> >>> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >_______________________________= ________________
>> >> >>> >> >sfc mailing list
>> >> >>> >> >sfc@ietf.org
>> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc
>> >> >>> >>
>> >> >>> >> ___________________________________= ____________
>> >> >>> >> sfc mailing list
>> >> >>> >> sfc= @ietf.org
>> >> >>> >> https://www.ietf.org/mailman/listinfo/sfc
>> >> >>>
>> >> >>> ____________________________________________= ___
>> >> >>> sfc mailing list
>> >> >>> sfc@ietf.org=
>> >> >>> https://www.ietf.org/mailman/listinfo/sfc
>> >> >
>> >> >_______________________________________________
>> >> >sfc mailing 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_3365_947045922.1405104386847-- From nobody Fri Jul 11 11:56: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 BC2011A059F for ; Fri, 11 Jul 2014 11:55:53 -0700 (PDT) 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_29=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 Ig6BJw_w6nl0 for ; Fri, 11 Jul 2014 11:55:45 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8201A039C for ; Fri, 11 Jul 2014 11:55:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CB026240F13; Fri, 11 Jul 2014 11:55:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BD4CD241490; Fri, 11 Jul 2014 11:55:40 -0700 (PDT) Message-ID: <53C0332C.30309@joelhalpern.com> Date: Fri, 11 Jul 2014 14:55:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mikebianc@aol.com" , jguichar@cisco.com, mn1921@att.com, mohamed.boucadair@orange.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Ky4ChP2wpooVpMTPnqqS4TCMyVI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 18:55:53 -0000 It seems clear to me that we will need to adjust the precise wording in the document. Fine. We will do so. What I have been trying to communicate is the importance of having the level of indirection between the policy level notion of service chain and the individual service function forwarders. That level of indirection enables flexibility in deployment, adn avoids conflating data plane behavior with policy and service level descriptions. Yours, Joel On 7/11/14, 2:46 PM, mikebianc@aol.com wrote: > Wouldn't that be called the "service chain identifier" then? If the > service chain is the ordered list of SFs and the service path is the > ordered list of SF instances, then I would infer that a "service path > identifier" would be an identifier for a service *path*, not a service > *chain*. > > Again, I think this is where the confusion keeps creeping in. The terms > "chain" and "path" seem inconsistent. > > > > > > ------------------------------------------------------------------------ > *From: *jguichar@cisco.com > *To: > *mikebianc@aol.com,mn1921@att.com,mohamed.boucadair@orange.com,jmh@joelhalpern.com,Ron_Parker@affirmednetworks.com,sfc@ietf.org > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Your definition of service path is correct as its the forwarding path > through which traffic will actually flow. The service path identifier > however points to the service chain data structure and that is then > resolved to specific instances based upon which next-hops to those > instances are available and whatever load distribution technique is in > play. When instantiating the service chain into the network you may or > may not update that data structure to specify which next-hops may be > used (where a single next-hop would effectively nail up the service path > for that service chain) or you may simply allow some other protocol / > mechanism to populate the data structure for you. > > From: "mikebianc@aol.com " > > Date: Friday, July 11, 2014 at 12:18 PM > To: Jim Guichard >, > "mn1921@att.com " >, "mohamed.boucadair@orange.com > " >, "jmh@joelhalpern.com > " >, "Ron_Parker@affirmednetworks.com > " > >, "sfc@ietf.org > " > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > I think this is the root of the confusion: > >> I don’t want to specify >> specific instances of S1, S2, and S3 (or some combination thereof). I >> assign a service path identifier “100†that basically points to S1->S2->S3 >> and then push this into the network > > By definition, I understood a "service path" to be an ordered list of > specific SF instances. In the statement above, you use a "service path > identifier" to refer to a service *chain* that specifically "[does not] > specify specific instances". > > > > > ------------------------------------------------------------------------ > *From: *jguichar@cisco.com > > > *To: *NAPIERALA, MARIA H >,mohamed.boucadair@orange.com > >,Joel M. > Halpern>,Ron > Parker >,sfc@ietf.org > > > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Maria, > > I think of it this way. The service path identifier is simply a pointer to > a data structure that contains SF to next-hop mappings. When you define a > chain, let’s say S1 ->S2-> S3, you *might* when creating the SFP specify > the specific next-hops that you want traffic to flow through for that SFP. > However, you do *not* have to do this from an architectural standpoint (I > will argue that you should but you don’t have to architecturally). You > could simply assign a service path identifier to point to a given SFC and > then push that information into the network. At the SFF it will have a > service path identifier to SFC mapping and said mapping would contain the > next-hops available for each of the SF’s within the SFC - how you learn > those next-hops is up to you. You could push them down from a centralized > controller, configure them through CLI, learn them dynamically through > some protocol exchange, whatever .. So, given this it is not correct to > say that the service path means that all SF instances are chosen a priori > although it is perfectly acceptable (and some would say recommended) to do > so. > > Let’s take an example to hopefully make this clear: > > I define an SFC (let’s refer to it as SFC-1) S1->S2->S3. For arguments > sake let’s say I want it to be fully dynamic e.g. I don’t want to specify > specific instances of S1, S2, and S3 (or some combination thereof). I > assign a service path identifier “100†that basically points to S1->S2->S3 > and then push this into the network so that the SFF data structures are > populated with this information. Now at a given SFF, when traffic arrives > with service path identifier 100, the SFF will look this up in the data > structure and find that it points to S1->S2->S3 and the index in the SFC > encapsulation will tell it exactly where it is in the chain. Let’s say we > are at S2 in the chain. The SFF will now have to resolve the next-hop to > S3 and will do a lookup to determine where S3 is reachable. > > On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" > wrote: > >>Jim, >> >>Could you tell us what is the definition of a "service path" and a >>"service path identifier"? >>If a service path means that all SF instances are chosen apriori (which >>is my current understanding) then it is not SFF's local decision which >>next-hop SFF to pick. It is a centralized decision. >> >>Maria >> >> >>> -----Original Message----- >>> > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Friday, July 11, 2014 11:15 AM >>> To: NAPIERALA, MARIA H;mohamed.boucadair@orange.com ; Joel M. >>> Halpern; Ron Parker;sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I’m sorry but I really don’t understand why a service path identifier >>> prevents full distribution of SF next-hops or why calling it a service >>> chain identifier makes any difference? >>> >>> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" > wrote: >>> >>> >Ditto. >>> > >>> >> -----Original Message----- >>> >> From:mohamed.boucadair@orange.com >>> >> [mailto:mohamed.boucadair@orange.com] >>> >> Sent: Friday, July 11, 2014 10:31 AM >>> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron >>> >> Parker;sfc@ietf.org >>> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >>> >> >>> >> Re-, >>> >> >>> >> For what I can say at best this is not described clearly in the >>>draft. >>> >> >>> >> Mandating a service path identifier is in itself a hint that the full >>> >>distributed >>> >> model is not allowed. >>> >> >>> >> Several voices in this thread indicated that the service chain itself >>> >>should be >>> >> provided instead. >>> >> >>> >> Cheers, >>> >> Med >>> >> >>> >> >-----Message d'origine----- >>> >> >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard >>> >> >(jguichar) >>> >> >Envoyé : vendredi 11 juillet 2014 16:18 >>> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;sfc@ietf.org >>> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> > >>> >> >Ok but where in the architecture specifically is this functionality >>> >> >prohibited? If you want to distribute *all* next-hops to *all* SFF’s >>> >> >within the SFC domain and then let the path identifier point to a >>> >>lookup >>> >> >into those next-hops to reach the next SF in the chain, I am not >>>sure >>> >>how >>> >> >the architecture prevents that? >>> >> > >>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" > >>> wrote: >>> >> > >>> >> >>Absolutely. >>> >> >> >>> >> >>> -----Original Message----- >>> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard >>> >> >>>(jguichar) >>> >> >>> Sent: Friday, July 11, 2014 9:54 AM >>> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;sfc@ietf.org >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> >>> >>> >> >>> Then I misunderstand the proposal ;-) .. However, it seems to me >>> >>that if >>> >> >>> you allow an SFF to make a decision as to which remote SFF it >>>will >>> >>use >>> >> >>>for >>> >> >>> a given flow to reach the next SF within the chain then you >>>better >>> >>make >>> >> >>> sure that that remote SFF has the necessary forwarding logic to >>> >>reach >>> >> >>>the >>> >> >>> next-next-SF for the chain as otherwise you are in deep trouble. >>> >> >>> >>> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" > >>> >> wrote: >>> >> >>> >>> >> >>> >Absolutely not. Service chains can be instantiated only in >>>relevant >>> >> >>>SFFs >>> >> >>> >when they "arrive". >>> >> >>> > >>> >> >>> >> -----Original Message----- >>> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>Guichard >>> >> >>> >>(jguichar) >>> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM >>> >> >>> >> To: Joel M. Halpern; Ron Parker;sfc@ietf.org >>> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> >>> >> >>> >> >>> >> Well I think it is even worse than that if I have understood >>>the >>> >> >>> >>proposal >>> >> >>> >> correctly as it would require full knowledge of every single >>>SF >>> >> >>>within >>> >> >>> >>the >>> >> >>> >> entire SFC domain at every single SFF as there is no way to >>>know >>> >>a >>> >> >>> >>priori >>> >> >>> >> which SFC¹s a given SFF will need to service at any given >>>point >>> >>in >>> >> >>>time. >>> >> >>> >> >>> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" > >>> >> wrote: >>> >> >>> >> >>> >> >>> >> >Ron, thinking about this, I realized another major problem >>>with >>> >>the >>> >> >>> >>your >>> >> >>> >> >proposal as I understand it. (And I readily admit I may not >>> >> >>>understand >>> >> >>> >> >it.) >>> >> >>> >> > >>> >> >>> >> >The proposal has each SFF serve as the load balancer for the >>> >>next >>> >> >>> >> >service function that follows it (not the one it delivers >>>to), >>> >>in >>> >> >>>every >>> >> >>> >> >service chain that goes through it. >>> >> >>> >> > >>> >> >>> >> >Since it has to be able to work with all services, that means >>> >>that >>> >> >>> >>every >>> >> >>> >> >SFF would have to be a full, flow sensitive and stateful load >>> >> >>>balancer. >>> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and / or >>> >>stateful. >>> >> >>> >> >But having the architecture require that every SFF be a full, >>> >>flow >>> >> >>> >> >sensitive, stateful, load balancer seems to me to be an >>> >>acceptable >>> >> >>> >> >imposition. >>> >> >>> >> > >>> >> >>> >> >Yours, >>> >> >>> >> >Joel >>> >> >>> >> > >>> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>> >> >>> >> >> Part of my personal view is that I am trying to make this >>>work >>> >> >>> >>sensibly >>> >> >>> >> >> in a more orchestrated environment. I expect that the >>>service >>> >> >>> >> >> functions, and over time probably the SFF capabilities, >>>will >>> >>be >>> >> >>> >> >> orchestrated and installed. I expect the service chains >>>to be >>> >> >>> >>driven by >>> >> >>> >> >> BSS tools that define offerings to clients, and enable >>> >> >>>self-selection >>> >> >>> >> >> from these. I expect service paths to be heavily policy >>> >>drive. >>> >> >>> >> >> >>> >> >>> >> >> I can see how to make all of that work in an archtiecture >>> >>driven >>> >> >>>by >>> >> >>> >> >> initial classification to described service paths. It is >>> >>harder >>> >> >>>to >>> >> >>> >>see >>> >> >>> >> >> how to make it work (but it can be done) when we allow more >>> >> >>> >> dynamicity >>> >> >>> >> >> in the network behavior. >>> >> >>> >> >> >>> >> >>> >> >> Having said that, most of that perspective I described is >>> >>outside >>> >> >>>of >>> >> >>> >>the >>> >> >>> >> >> scope of the working group. it is not something we are >>> >>tasked to >>> >> >>> >>agree >>> >> >>> >> >>on. >>> >> >>> >> >> So I do not claim that vision means we have to do it a >>>certain >>> >> >>>way. >>> >> >>> >>it >>> >> >>> >> >> is just the perspective that drives my preferences. >>> >> >>> >> >> >>> >> >>> >> >> Yours, >>> >> >>> >> >> Joel >>> >> >>> >> >> >>> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >>> >> >>> >> >>>> For me, the amount of information about service instances >>> >> that >>> >> >>> >>needs >>> >> >>> >> >>>>to >>> >> >>> >> >>>> be widely distributed and maintained, potentially even >>> >>across >>> >> >>>data >>> >> >>> >> >>>> centers within an administrative scope, is large enough >>>and >>> >> >>> complex >>> >> >>> >> >>>> enough that trying to get that into each SFF seems like a >>> >> >>>difficult >>> >> >>> >> >>>> architecture to realize. >>> >> >>> >> >>> >>> >> >>> >> >>> I'm curious as to why that is more complicated than >>>dynamic >>> >> >>> routing, >>> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of >>>which >>> >>are >>> >> >>> >>bigger >>> >> >>> >> >>> problems that have been profitably and stably implemented? >>> >> >>> >> >>> >>> >> >>> >> >>> It also seems that if it really is more complicated, that >>>is >>> >>a >>> >> >>>good >>> >> >>> >> >>> sign that it is too complicated. >>> >> >>> >> >>> >>> >> >>> >> >>> ________________________________________ >>> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com ] >>> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >>> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct;mikebianc@aol.com ; >>>Ian >>> >> >>>Smith; >>> >> >>> >> >>>sfc@ietf.org >>> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>Balancers >>> >> >>> >> >>> >>> >> >>> >> >>> This is an architectural issue. And one that I would >>>prefer >>> >>we >>> >> >>> >> >>>actually >>> >> >>> >> >>> decide, rather than trying to allow all possible >>> >>implementations. >>> >> >>> >> >>> Because it does have a major effect on the control >>> >>requirements >>> >> >>>and >>> >> >>> >> the >>> >> >>> >> >>> functionality of SFFs. >>> >> >>> >> >>> >>> >> >>> >> >>> For me, the amount of information about service instances >>> >>that >>> >> >>> needs >>> >> >>> >> to >>> >> >>> >> >>> be widely distributed and maintained, potentially even >>> across >>> >> >>>data >>> >> >>> >> >>> centers within an administrative scope, is large enough >>>and >>> >> >>>complex >>> >> >>> >> >>> enough that trying to get that into each SFF seems like a >>> >> >>>difficult >>> >> >>> >> >>> architecture to realize. >>> >> >>> >> >>> >>> >> >>> >> >>> Yours, >>> >> >>> >> >>> Joel >>> >> >>> >> >>> >>> >> >>> >> >>> But it is a fair question. >>> >> >>> >> >>> >>> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>> >> >>> >> >>>> This is the crux of my issue. Is the end to end >>>selection >>> >>of >>> >> >>> >> >>>> (top-level) instances performed centrally (perhaps by the >>> >> >>> >>classifier) >>> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently >>> >>the >>> >> >>> >>SFFs)? >>> >> >>> >> >>>> Such selection is not equivalent to reclassification. >>>And >>> >> >>>surely, >>> >> >>> >> >>>> this is an architectural issue and not relegated to >>> >> >>> >> >>>> "implementation". >>> >> >>> >> >>>> >>> >> >>> >> >>>> My own view is to favor the distributed approach even >>> though >>> >> a >>> >> >>> >> >>>> greater amount of data (chain definitions and perhaps >>>local >>> >> >>> >>selection >>> >> >>> >> >>>> policy) is required at those distributed decision points. >>> >>This >>> >> >>> >> >>>> approach does not require an end-to-end path id at all. >>> >>My >>> >> >>> >> >>>> rationale for favoring this approach is primarily driven >>>by >>> >> >>> >>increased >>> >> >>> >> >>>> resiliency over the global path id approach. With a >>>global >>> >> >>>path >>> >> >>> >>id >>> >> >>> >> >>>> approach, consider failure of an instance and needing to >>> >>alter >>> >> >>>the >>> >> >>> >> >>>> global path ID table for each and every affected >>>end-to-end >>> >> >>>path. >>> >> >>> >> >>>> >>> >> >>> >> >>>> Ron >>> >> >>> >> >>>> >>> >> >>> >> >>>> ________________________________________ From: sfc >>> >> >>> >> >>>> [sfc-bounces@ietf.org ] on behalf of Joel > Halpern Direct >>> >> >>> >> >>>> [jmh.direct@joelhalpern.com ] Sent: > Thursday, July 10, >>>2014 >>> >> 6:15 >>> >> >>> PM >>> >> >>> >> >>>> To:mikebianc@aol.com ; I.Smith@F5.com > ; sfc@ietf.org >>> Subject: >>> >> Re: >>> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >>> >> >>> >> >>>> >>> >> >>> >> >>>> The way the architecture models the case of SF1 needing >>>to >>> >> >>> >>influence >>> >> >>> >> >>>> the chain is that one would do reclassification at the >>>exit >>> >>from >>> >> >>> >> >>>> SF1. >>> >> >>> >> >>>> >>> >> >>> >> >>>> Part of the goal is to keep the different functions >>> >>logically >>> >> >>> >> >>>> separate so that solutions can clearly describe how they >>> >> choose >>> >> >>>to >>> >> >>> >> >>>> compose them for "service" delivery. >>> >> >>> >> >>>> >>> >> >>> >> >>>> Yours, Joel >>> >> >>> >> >>>> >>> >> >>> >> >>>> On 7/10/14, 6:10 PM,mikebianc@aol.com wrote: >>> >> >>> >> >>>>> I don't see anything in the arch draft that suggests any >>> >>sort >>> >> >>>of >>> >> >>> >> >>>>> limit. However, it does seem to indicate that the entire >>> >>path >>> >> >>>(all >>> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe >>>this >>> >> >>>means >>> >> >>> >> >>>>> either at the classifier or maybe the classifier >>>chooses a >>> >>SF >>> >> >>> >>Chain >>> >> >>> >> >>>>> and the NF or at the latest the first SFF. In any case, >>> >>the >>> >> >>> >> >>>>> language does seem to prohibit a more dynamic SFP where >>> >> SFI(n) >>> >> >>> is >>> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to the draft, >>> >>this >>> >> >>> >> >>>>> behavior would be considered "branching" to a new SFP as >>> >> >>> opposed >>> >> >>> >> to >>> >> >>> >> >>>>> choosing and then forwarding to the selected instance of >>> >>the >>> >> >>> >> >>>>> next-hop of the current SFC. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> draft-merged-sfc-architecture-00: >>> >> >>> >> >>>>>> When an SFC is instantiated into the network it is >>> >>necessary >>> >> >>>to >>> >> >>> >> >>>>>> select the specific instances of SFs that will be used, >>> >>and to >>> >> >>> >> >>>>>> create the service topology for that SFC using SF's >>> >>network >>> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC results in the >>> >> >>>creation >>> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for >>> >>forwarding >>> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP is the >>> >> >>> >> >>>>>> instantiation of the defined SFC. >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> The SFC architecture supports reclassification (or >>> >>non-initial >>> >> >>> >> >>>>>> classification) as well. As packets traverse an SFP, >>> >> >>> >> >>>>>> reclassification may occur - typically performed by a >>> >> >>> >> >>>>>> classification function co-resident with a service >>> >>function. >>> >> >>> >> >>>>>> Reclassification may result in the selection of a new >>> >>SFP, an >>> >> >>> >> >>>>>> update of the associated metadata, or both. This is >>> >>referred >>> >> >>>to >>> >> >>> >> >>>>>> as "branching". >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>> >> >>> >>> >> >>> >>>>>>>>>>>>>>>------------------------------------------------------------- >>>>>>>>>>>>>>>-- >>> >>>>>>>>>>>>--- >>> >> >>>>>>>>>>-- >>> >> >>> >>>>>>>-- >>> >> >>> >> >>>>>-- >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>> *From:*I.Smith@F5.com > >>> >> >>> >> >>>>> *To: *Joel Halpern >>> Direct>,Joel >>> >> M. >>> >> >>> >> >>>>> >>> >> >>> >> >>> >> >>> >>> >> >>> >>>>>Halpern>,huang@sce.carleton.ca > >> >> >>> >> carleton. >>> >> >>> >> >>>>>ca>,sfc@ietf.org > >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 >>> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>> >>Balancers >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> Actually, I think I am disagreeing. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> If the possibility of medium-scale deployments (and >>>that is >>> >> >>>what >>> >> >>> >> >>>>> 16 million flows is in my world) of service chains is >>> >> >>>preconceived >>> >> >>> >> >>>>> as an absurd idea, then the architecture burdened with >>> that >>> >> >>> >> >>>>> preconception. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> There has to be some point of aim, some degree of >>> >>aspiration >>> >> to >>> >> >>> >> >>>>> scale that is appropriate for the lifespan of the >>> >>architecture >>> >> >>>- >>> >> >>> >> >>>>> you don't have to know what it is, but by saying that an >>> >> >>>arbitrary >>> >> >>> >> >>>>> number is "too far", you're creating - even if it isn't >>> >> >>> >>intentional >>> >> >>> >> >>>>> - a limit that influences decisions that have lasting >>> >>impacts >>> >> >>> >> >>>>> regarding scale-out, failure mitigation, elasticity, >>> >>address >>> >> >>> >> >>>>> space... all kinds of things. That is a problem I'm not >>> >> >>> >> >>>>> particularly eager to deal with. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> ________________________________________ >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern.com ] >>> >>Sent: >>> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. >>> >> Halpern; >>> >> >>> >> >>>>>huang@sce.carleton.ca ; sfc@ietf.org > Subject: Re: [sfc] >>> >>Service >>> >> >>> >> >>>>> Chains, Paths, and Load Balancers >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> Ian, I don't think you disagree with me at all in this >>> >>regard. >>> >> >>>I >>> >> >>> >>am >>> >> >>> >> >>>>> not requesting the the architecture or the solution >>> >>prohibit >>> >> >>> >> >>>>> deployments in the specific fashion. I am objecting to >>> >>Huang's >>> >> >>> >> >>>>> reading of my note as saying that such deployments are >>> >> required >>> >> >>> >> >>>>> they by the archtiecture. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> As I have said repeatedly, I am not trying to prohibit >>>such >>> >> >>> >> >>>>> things. Whether they are a good idea or not depends upon >>> >> many >>> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to >>>think >>> >>that >>> >> >>> >>they >>> >> >>> >> >>>>> are usually a bad idea. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> But the archtiecture si carefully avoiding attempting to >>> >>know >>> >> >>>what >>> >> >>> >> >>>>> is and is not eployable. >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> Yours, Joel >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> >> >>> >> >>>>>> I disagree. >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> We routinely have stateful devices that manage tens of >>> >> >>>millions >>> >> >>> >> >>>>>> of >>> >> >>> >> >>>>> concurrent flows in both access network and data center >>> >> >>> >> >>>>> environments today. You can't seriously believe that in >>>the >>> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you >>> are >>> >> only >>> >> >>> >> going >>> >> >>> >> >>>>> to have small numbers of service chains with equally >>>small >>> >> >>> numbers >>> >> >>> >> >>>>> of active service paths? >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> Your sounds too much like "no one will ever need more >>> than >>> >> >>> 64K" >>> >> >>> >> >>>>>> for >>> >> >>> >> >>>>> comfort. >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> ________________________________________ From: sfc >>> >> >>> >> >>>>>> [sfc-bounces@ietf.org ] on behalf of Joel M. > Halpern >>> >> >>> >> >>>>> [jmh@joelhalpern.com ] >>> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>> >> >>>huang@sce.carleton.ca ; >>> >> >>> >> >>>>>>sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, >>>and >>> >> >>>Load >>> >> >>> >> >>>>>> Balancers >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> No, it will mean that if someone tries to deploy the >>> >> >>>archtieture >>> >> >>> >> >>>>>> particularly badly, they will exceed the limits of >>>their >>> >> >>> >> >>>>>> devices. The architecture does not require such absurd >>> use >>> >> of >>> >> >>> >> >>>>>> service paths. Since I can not figure out how to write >>> >> >>> >> >>>>>> architectural words to prohibit it, the architecture >>>does >>> >> >>>permit >>> >> >>> >> >>>>>> such abuse. >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> Please do not read my saying that the archtiecture >>> permits >>> >> >>> >> >>>>>> something as saying it is either deisred or required by >>> >>the >>> >> >>>work. >>> >> >>> >> >>>>>> It isn't. >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> Yours, Joel >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>> >> >>> >> >>>>>>> If you need to support 100 service chains, it will >>>mean >>> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing >>>table >>> >>of a >>> >> >>> >> >>>>>>> core router. >>> >> >>> >> >>>>>>> >>> >> >>> >> >>>>>>> Chang >>> >> >>> >> >>>>>>> >>> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>> >> >>> >> >>>>>>>> The architecture allows a range of deployments, from >>>1 >>> >> >>> >> >>>>>>>> service path to 160000 service paths. I would hope >>>that >>> >> >>> >> >>>>>>>> operators are prepared for the complexities if they >>> >>choose >>> >> >>>to >>> >> >>> >> >>>>>>>> avoid any use of local load balancing and in stead >>> >> provision >>> >> >>> >> >>>>>>>> 160,000 service paths. >>> >> >>> >> >>>>>>>> >>> >> >>> >> >>>>>>>> Yours, Joel >>> >> >>> >> >>>>>>>> >>> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>> >> >>> >> >>>>>>>>> Paul, >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop >>> >> service >>> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Maria >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>> Of >>> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 >>> >>3:03 >>> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:*jmh@joelhalpern.com ; >>> >> >>> >> >>>>>>>>>mohamed.boucadair@orange.com ; > sfc@ietf.org ; >>> >> >>> >> >>>>>>>>>mikebianc@aol.com *Subject:* Re: [sfc] Service >>> Chains, >>> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Lucy, >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the >>> >> >>> >> >>>>>>>>> forwarding. I¹d >>> >> >>> >> >>>>> make >>> >> >>> >> >>>>>>>>> the minor change: the path identifier can be used to >>> >> derive >>> >> >>> >> >>>>>>>>> the needed forwarding and associated transport. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to >>>simply >>> >> >>> >> >>>>>>>>> identify the service path (or graph) that packets >>>must >>> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exact >>> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on >>>this >>> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path >>> >> identifier >>> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can >>> >> result >>> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) transport next >>> >> >>> >> >>>>>>>>> hop(s). >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Paul >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>> >> >>> >> >>>>>>>>> >>> >> > >>> >> >>> >> >>>>>>>>> wrote: >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of >>> the >>> >> >>> >> >>>>>>>>> service path identifier to drive the forwarding >>> >>actions. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Lucy >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf >>> >> >>> >> >>>>>>>>>Of*mohamed.boucadair@orange.com >>> >> >>> >> >>>>>>>>> >>> >> >>> *Sent:*Thursday, >>> >> >>> >> July >>> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>> >> >>> >> >>>>>>>>> ;jmh@joelhalpern.com >>> >> >>> >> >>>>>>>>> ;sfc@ietf.org >>> >> >>> >> >>>>>>>>> *Subject:*Re: [sfc] Service >>> >>Chains, >>> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Re-, >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a service path >>> >> >>> >> >>>>>>>>> identifier. I object to use that identifier to >>>derive >>> >> >>> >> >>>>>>>>> forwarding actions. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of >>> >> every >>> >> >>> >> >>>>> available SFC >>> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not >>> >> >>> >> >>>>> required/justified >>> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of >>> >> >>> >> >>>>>>>>> information >>> >> >>> >> >>>>> that will >>> >> >>> >> >>>>>>>>> be present in all deployments: that is the one >>> required >>> >> to >>> >> >>> >> >>>>>>>>> structure a service chain. How that information is >>> >>used to >>> >> >>> >> >>>>>>>>> infer forwarding >>> >> >>> >> >>>>> actions >>> >> >>> >> >>>>>>>>> is a solution-oriented discussion. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Cheers, >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Med >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part >>> >> >>> >> >>>>>de*mikebianc@aol.com >>> >> >>> >> >>>>>>>>> *Envoyé :*mercredi 9 >>> >> juillet >>> >> >>> >> >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>> >> >>> >> >>>>>>>>> ;sfc@ietf.org >>> >> >>> >> >>>>>>>>> *Objet :*Re: [sfc] Service >>> >>Chains, >>> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Is anyone still questioning the difference between >>>SF >>> >> Chain >>> >> >>> >> >>>>>>>>> and SF >>> >> >>> >> >>>>> Path? >>> >> >>> >> >>>>>>>>> Other than clarifying the definition so that it's >>> >>clear to >>> >> >>> >> >>>>> those not >>> >> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone >>>agrees >>> >>on >>> >> >>> >> >>>>>>>>> these terms. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> To me, the one point that is still unclear is >>>whether >>> >>it is >>> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify what >>> >>the ID >>> >> >>> >> >>>>>>>>> of the SFC Header >>> >> >>> >> >>>>> should >>> >> >>> >> >>>>>>>>> reference (the chain or the path), or if this draft >>> >>simply >>> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other >>>drafts >>> >>to >>> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain >>> or >>> >> >>> >> >>>>>>>>> path and the choice of chain or >>> >> >>> >> >>>>> path to >>> >> >>> >> >>>>>>>>> be negotiated in the control-plane. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have >>> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported (or make >>> >> one >>> >> >>> >> >>>>>>>>> required and the other optional) to avoid some >>> vendors >>> >> only >>> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>> >> >>> >>> >> >>> >>>>>>>>>>>>>>>------------------------------------------------------------- >>>>>>>>>>>>>>>-- >>> >>>>>>>>>>>>--- >>> >> >>>>>>>>>>-- >>> >> >>> >>>>>>>-- >>> >> >>> >> >>>>>-- >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>>>> >>> >> >>> >> >>>>>>>>> *From:*jmh@joelhalpern.com >>> >> >>> >> >>>>>>>>> >>> >> > >>> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org >>> >> >>> >> >>>>>>>>> > >>> *Sent:*Tuesday, >>> >> July >>> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and >>>Load >>> >> >>> >> >>>>>>>>> Balancers >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> I have been trying to figure out how to clearly >>>answer >>> >>a >>> >> >>> >> >>>>>>>>> number of comments that have been made about the >>> >> >>> proposed >>> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get >>> working >>> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to >>> improve >>> >> the >>> >> >>> >> >>>>>>>>> wording so that readers who have not participated in >>> >>the >>> >> WG >>> >> >>> >> >>>>>>>>> discussion will understnd it the way the >>> >> >>> >> >>>>> working >>> >> >>> >> >>>>>>>>> group intends. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain my >>> >>personal >>> >> >>> >> >>>>>>>>> view, and see if that helps. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> In this regard, it is important to keep in mind that >>> >>what >>> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. We >>>are >>> >> not >>> >> >>> >> >>>>>>>>> attempting to define the architecture for the entire >>> >> >>> >> >>>>>>>>> solution for service chaining. That would encompass >>> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy functions, >>>virtual >>> >> >>> >> >>>>>>>>> machine and image management, and many other >>> >> aspects. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> As a result there are many things which clearly need >>> to >>> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt with >>> >>above >>> >> >>> >> >>>>>>>>> where we are >>> >> >>> >> >>>>> functioning, >>> >> >>> >> >>>>>>>>> and are not directly required by the work we are >>> doing. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> In order to get to service chain vs service path, >>>as I >>> >> >>> >> >>>>>>>>> understand >>> >> >>> >> >>>>> them, >>> >> >>> >> >>>>>>>>> I need to first discuss load balancing. There are at >>> >>least >>> >> >>> >> >>>>>>>>> three different ways that load balancing can and >>>will >>> >> >>> >> >>>>>>>>> interact with service chaining. There probably are >>> >>more. >>> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all of >>> >>these, >>> >> >>> >> >>>>>>>>> but not to mandate that any particular kind >>> >> >>> >> >>>>> be used >>> >> >>> >> >>>>>>>>> in any solution. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to the end >>> >>user. >>> >> >>> >> >>>>>>>>> This is a service function. It receives user >>>packets, >>> >>and >>> >> >>> >> >>>>>>>>> modifies them (or >>> >> >>> >> >>>>> marks >>> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user service >>> >>instance >>> >> >>> >> >>>>>>>>> to receive the users packet. This is an important >>> >>service >>> >> >>> >> >>>>>>>>> function to be able to include in service chaining. >>> >>It's >>> >> >>> >> >>>>>>>>> behavior may affect requirements on how service >>> >> chaining is >>> >> >>> >> >>>>>>>>> done. But it has very little impact on the >>> >>archtiecture. >>> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is simply a >>> >> >>> >> >>>>> service >>> >> >>> >> >>>>>>>>> function which may modify the underlying packet. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one >>>can >>> >>have >>> >> >>> >> >>>>>>>>> what >>> >> >>> >> >>>>> appears >>> >> >>> >> >>>>>>>>> to the service chaining architecture as a single >>>point >>> >>of >>> >> >>> >> >>>>>>>>> contact >>> >> >>> >> >>>>> for a >>> >> >>> >> >>>>>>>>> specific service function, but is actually delivered >>> >>by a >>> >> >>> >> >>>>> collection of >>> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including >>>one or >>> >> >>> >> >>>>>>>>> several load balancers (for example using VRRP-like >>> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is >>> >> >>> >> >>>>>>>>> invisible to the service chaining data plane >>> >>mechanisms. >>> >> It >>> >> >>> >> >>>>>>>>> is likely that it is visible to various control >>> >>mechanisms, >>> >> >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, >>>and >>> >>vm >>> >> >>> >> >>>>>>>>> instantiation. The architectural impact of >>>permitting >>> >>this >>> >> >>> >> >>>>>>>>> is largely that we need to be careful that our >>> >>terminology >>> >> >>> >> >>>>>>>>> does not lead >>> >> >>> >> >>>>> readers to >>> >> >>> >> >>>>>>>>> think we are prohibiting it. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by >>>selecting >>> >> >>> >> >>>>>>>>> packet paths for the service chaining that direct >>> >>traffic >>> >> >>> >> >>>>>>>>> to different places. We would not want to require >>> that >>> >>a >>> >> >>> >> >>>>>>>>> given service function appear at only one place in >>>the >>> >> >>> >> >>>>>>>>> network. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> It is of course the case that these may be >>>combined. I >>> >> tend >>> >> >>> >> >>>>>>>>> to >>> >> >>> >> >>>>> refer to >>> >> >>> >> >>>>>>>>> the collection of entities that appear to service >>> >>chaining >>> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster >>>is >>> >>a >>> >> >>> >> >>>>>>>>> good term. But because I do not have another one. >>> Thus, >>> >> the >>> >> >>> >> >>>>>>>>> point of type 3 load balancing >>> >> >>> >> >>>>> is to >>> >> >>> >> >>>>>>>>> direct different subsets of traffic to different >>> >>singular >>> >> >>> >> >>>>>>>>> or clustered service functions in different places >>>in >>> >>the >>> >> >>> >> >>>>>>>>> network. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I talk about >>> >> >>> >> >>>>>>>>> service chain and service path/ Service chain is a >>> >> sequence >>> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset of >>> >>packets. >>> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of >>>traffic >>> >>is >>> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, and >>>firewall >>> >> >>> >> >>>>>>>>> while a different subset is to go directly to the >>>cache >>> >> >>> >> >>>>> without >>> >> >>> >> >>>>>>>>> visiting any other service functions. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> That is not enough information to direct the >>>packets. >>> A >>> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence of >>> >>locations >>> >> >>> >> >>>>>>>>> in the network. Those locations will be singular or >>> >> >>> >> >>>>>>>>> clustered service function delivery locations. They >>> >>may be >>> >> >>> >> >>>>>>>>> addressed by IP address. They may be addressed as >>> ports >>> >> on >>> >> >>> >> >>>>>>>>> an SFF. There are many different ways that the >>> >>locations >>> >> >>> >> >>>>>>>>> may be known to the service chaining infrastructure >>> and >>> >> the >>> >> >>> >> >>>>>>>>> transport. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>>> From the point of view of the work of the SFC >>>group, >>> >> we >>> >> >>> >> >>>>>>>>>> need to be >>> >> >>> >> >>>>>>>>> able to talk about the high level abstraction, the >>> >>service >>> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need to >>> talk >>> >> >>> >> >>>>>>>>> about the actual data path packets will take in the >>> >> >>> >> >>>>>>>>> network. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Several of the comments have said "but the whole >>> path >>> >> may >>> >> >>> >> >>>>>>>>> not be known at the front." This architecture deals >>> >>with >>> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) >>>on >>> >>load >>> >> >>> >> >>>>>>>>> balancers above, there can be decisions and >>>behaviors >>> >> which >>> >> >>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in >>> >>much >>> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is largely >>> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The other >>> provision >>> >> we >>> >> >>> >> >>>>>>>>> make is >>> >> >>> >> >>>>> that >>> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain when >>> >> necessary. >>> >> >>> >> >>>>>>>>> That will direct packets to a new chain. Based on >>> >> >>> >> >>>>>>>>> information available at the re-classification >>>point. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> I hope that this helps explain what we are after. >>>If it >>> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the working >>> >> group, >>> >> >>> >> >>>>>>>>> we can figure out what additional words are needed >>> to >>> >> >>> >> >>>>>>>>> convey this. If the working group disagree with the >>> >> intent, >>> >> >>> >> >>>>>>>>> then we will of course adjust to match the working >>> >>group >>> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure >>> >>what to >>> >> >>> >> >>>>>>>>> try next. >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> Yours, Joel >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> >>> _______________________________________________ >>> >> sfc >>> >> >>> >> mailing >>> >> >>> >> >>>>>>>>> listsfc@ietf.org >>> >> >>> >> >>>>>>>>>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>>> >>> _______________________________________________ >>> >> sfc >>> >> >>> >> mailing >>> >> >>> >> >>>>>>>>> listsfc@ietf.org >>> >> >>> >> >>>>>>>>>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>>>>>>> >>> >> >>> >> >>>>>>>> >>> >> >>> >> >>>>>>>> >>> _______________________________________________ >>> >> sfc >>> >> >>> >> mailing >>> >> >>> >> >>>>>>>> listsfc@ietf.org >>> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>>>>>> >>> >> >>> >> >>>>>>> >>> >> >>> >> >>>>>>> _______________________________________________ >>> sfc >>> >> >>> >> mailing >>> >> >>> >> >>>>>>> listsfc@ietf.org >>> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>>>>> >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>>> _______________________________________________ >>> sfc >>> >> >>> mailing >>> >> >>> >> list >>> >> >>> >> >>>>>>sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> _______________________________________________ sfc >>> >> >>> mailing >>> >> >>> >> list >>> >> >>> >> >>>>>sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>> >>> >> >>> >> >>>> _______________________________________________ sfc >>> >> mailing >>> >> >>> >> list >>> >> >>> >> >>>>sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>> >>> >> >>> >> >>>> _______________________________________________ sfc >>> >> mailing >>> >> >>> >> list >>> >> >>> >> >>>>sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>>> >>> >> >>> >> >>> >>> >> >>> >> >> >>> >> >>> >> >> _______________________________________________ >>> >> >>> >> >> sfc mailing list >>> >> >>> >> >>sfc@ietf.org >>> >> >>> >> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >> >>> >> >>> >> > >>> >> >>> >> >_______________________________________________ >>> >> >>> >> >sfc mailing list >>> >> >>> >> >sfc@ietf.org >>> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> >>> >> sfc mailing list >>> >> >>> >>sfc@ietf.org >>> >> >>> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >>> >>> >> >>> _______________________________________________ >>> >> >>> sfc mailing list >>> >> >>>sfc@ietf.org >>> >> >>>https://www.ietf.org/mailman/listinfo/sfc >>> >> > >>> >> >_______________________________________________ >>> >> >sfc mailing 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 Jul 11 11:57: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 5C8481A0400 for ; Fri, 11 Jul 2014 11:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 0ICnd9UctGgn for ; Fri, 11 Jul 2014 11:57:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4844D1A039C for ; Fri, 11 Jul 2014 11:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=206065; q=dns/txt; s=iport; t=1405105041; x=1406314641; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=90cY2pXVvd+KBRbl5diHlHATM0+0hErzBWZsdUU3AuU=; b=T/vM58+0CaZXpv0DLX9ITOF2c6kAmT62//hJvtitd+mAakkKrm27i2M6 WBrMjeOOOY+/1SrOJkjPkHWjcKbylMoj4l7KgnhZjIxOew+ZZvAUebrZ3 2RTgYn7oSBwTrAgRQRumgjtRffSZVxPtRfkiGNypc6SYZfWJQEawMlw0r Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFANEywFOtJV2a/2dsb2JhbABPCoJHR1JagnGsCZF4AQmHQgEZchZ1hAMBAQEDAQEBARcBCAQ+CQIOBwQCAQgRAQIBAQEBIAEGAwICAiULFAMGCAIEARIbiBMDCQgNrXuYdBMEiX2DIIFQBSAMEAoHBgoBAgSCcYFMBZYiSYQai2iININEgW9B X-IronPort-AV: E=Sophos; i="5.01,644,1400025600"; d="scan'208,217"; a="60109259" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 11 Jul 2014 18:57:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6BIvH0V007734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 18:57:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 13:57:17 -0500 From: "Jim Guichard (jguichar)" To: "mikebianc@aol.com" , "mn1921@att.com" , "mohamed.boucadair@orange.com" , "jmh@joelhalpern.com" , "Ron_Parker@affirmednetworks.com" , "sfc@ietf.org" Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AACNZ7AP//xIOAgABJ/ID//79hAIAAaeIA//+/qgA= Date: Fri, 11 Jul 2014 18:57:16 +0000 Message-ID: References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.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.180] Content-Type: multipart/alternative; boundary="_000_CFE5AA4C2D768jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lpU6vjGoTROWUyrCn7ZhI79d83I Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 18:57:30 -0000 --_000_CFE5AA4C2D768jguicharciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gYmVjYXVzZSB0aGUgc2FtZSBhYnN0cmFjdGVkIGNoYWluIG1pZ2h0IGJlIHJlZmVyZW5jZWQg d2l0aCBkaWZmZXJlbnQgcGF0aCBpZGVudGZpZXJzIGFzIHRoZSBuZXh0LWhvcHMgdGhhdCBmb3Jt IHRoZSBwYXRoIHRvIHJlYWxpemUgdGhlIGNoYWluIG1heSBiZSBkaWZmZXJlbnQgZGVwZW5kZW50 IHVwb24gcG9saWNpZXMuICBTbyBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIG1pZ2h0IHBvaW50 IHRvIFMxKEBsb2MxKS0+UzIoQGxvYzIpIHdoZXJlYXMg4oCcMTAx4oCdIG1pZ2h0IHBvaW50IHRv IFMxKEBsb2M1NSktPlMyKEBsb2M2NCkuIFRoZXkgYXJlIHRoZSBzYW1lIGNoYWluIGJ1dCBkaWZm ZXJlbnQgcGF0aHMuDQoNCkZyb206ICJtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20+IiA8bWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4N CkRhdGU6IEZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAyOjQ2IFBNDQpUbzogSmltIEd1aWNoYXJk IDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+LCAibW4xOTIx QGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzpt bjE5MjFAYXR0LmNvbT4+LCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sICJqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGptaEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IiA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCldvdWxkbid0IHRoYXQgYmUgY2FsbGVkIHRoZSAi c2VydmljZSBjaGFpbiBpZGVudGlmaWVyIiB0aGVuPyAgSWYgdGhlIHNlcnZpY2UgY2hhaW4gaXMg dGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlIG9yZGVy ZWQgbGlzdCBvZiBTRiBpbnN0YW5jZXMsIHRoZW4gSSB3b3VsZCBpbmZlciB0aGF0IGEgInNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIiB3b3VsZCBiZSBhbiBpZGVudGlmaWVyIGZvciBhIHNlcnZpY2Ug KnBhdGgqLCBub3QgYSBzZXJ2aWNlICpjaGFpbiouDQoNCkFnYWluLCBJIHRoaW5rIHRoaXMgaXMg d2hlcmUgdGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBpbi4gIFRoZSB0ZXJtcyAiY2hhaW4i IGFuZCAicGF0aCIgc2VlbSBpbmNvbnNpc3RlbnQuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNo YXJAY2lzY28uY29tPjxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bT4+DQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjxtaWtl YmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+PixtbjE5MjFAYXR0LmNvbTxt YWlsdG86bW4xOTIxQGF0dC5jb20+PG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNv bT4+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+PixqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPj4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT48Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWls dG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTZW50OiBG cmlkYXksIEp1bHkgMTEsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpZb3VyIGRlZmluaXRpb24gb2Ygc2VydmljZSBw YXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBhdGggdGhyb3VnaCB3aGljaCB0 cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGhv d2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3RydWN0dXJlIGFuZCB0aGF0 IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJhc2VkIHVwb24gd2hpY2gg bmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZhaWxhYmxlIGFuZCB3aGF0ZXZlciBs b2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxheS4gV2hlbiBpbnN0YW50aWF0aW5n IHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1heSBvciBtYXkgbm90IHVw ZGF0ZSB0aGF0IGRhdGEgc3RydWN0dXJlIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBi ZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3b3VsZCBlZmZlY3RpdmVseSBuYWlsIHVw IHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1w bHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvIG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0aGUg ZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCg0KRnJvbTogIm1pa2ViaWFuY0Bhb2wuY29tPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbT4iIDxtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNDQpUbzog SmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNv bT4+LCAibW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTkyMUBhdHQu Y29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sICJqbWhA am9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGptaEBqb2VsaGFs cGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IiA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkgdGhpbmsgdGhpcyBpcyB0 aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOg0KDQo+IEkgZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkN Cj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0 aW9uIHRoZXJlb2YpLiBJDQo+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEw MOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KPiBhbmQgdGhlbiBwdXNo IHRoaXMgaW50byB0aGUgbmV0d29yaw0KDQpCeSBkZWZpbml0aW9uLCBJIHVuZGVyc3Rvb2QgYSAi c2VydmljZSBwYXRoIiB0byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFu Y2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgInNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIiB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAi W2RvZXMgbm90XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNlcyIuDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRv OmpndWljaGFyQGNpc2NvLmNvbT48amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBj aXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86 bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sSm9lbCBNLiBIYWxwZXJuPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixSb24gUGFya2VyPFJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0DQpT dWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCg0KTWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQphIGRhdGEgc3RydWN0dXJlIHRoYXQg Y29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91IGRlZmluZSBhDQpjaGFp biwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRo ZSBTRlAgc3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRyYWZm aWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCkhvd2V2ZXIsIHlvdSBkbyAqbm90KiBo YXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQgKEkNCndpbGwg YXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVy YWxseSkuIFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVy IHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRpb24g aW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0Kc2VydmljZSBwYXRo IGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWlu IHRoZQ0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0 aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91 IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50cmFsaXplZA0KY29udHJvbGxlciwgY29u ZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0K c29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMg bm90IGNvcnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwg U0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkNCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3Rs eSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvDQpzby4N Cg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoN Cg0KSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzIt PlMzLiBGb3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxs eSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0Kc3BlY2lmaWMgaW5zdGFu Y2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQph c3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkg cG9pbnRzIHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3Jr IHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQpwb3B1bGF0ZWQgd2l0aCB0aGlz IGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzDQp3 aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1 cCBpbiB0aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5T Mi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQplbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBp dCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkgd2UNCmFyZSBh dCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBu ZXh0LWhvcCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMz IGlzIHJlYWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCg0KPkpp bSwNCj4NCj5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNl cnZpY2UgcGF0aCIgYW5kIGENCj4ic2VydmljZSBwYXRoIGlkZW50aWZpZXIiPw0KPklmIGEgc2Vy dmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkg KHdoaWNoDQo+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYn cyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPm5leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNl bnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1hcmlhDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpq Z3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUg QU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBKb2VsIE0uDQo+PiBIYWxw ZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4NCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5 IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9u IG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UNCj4+IGNoYWluIGlk ZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+Pg0KPj4gT24gNy8xMS8xNCwgMTA6NTgg QU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0 dC5jb20+PiB3cm90ZToNCj4+DQo+PiA+RGl0dG8uDQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+IFttYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAx NCAxMDozMSBBTQ0KPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEs IE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pg0KPj4gPj4gUmUtLA0KPj4g Pj4NCj4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJl ZCBjbGVhcmx5IGluIHRoZQ0KPj5kcmFmdC4NCj4+ID4+DQo+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4+ ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4gPj4NCj4+ID4+ IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNl IGNoYWluIGl0c2VsZg0KPj4gPj5zaG91bGQgYmUNCj4+ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+ PiA+Pg0KPj4gPj4gQ2hlZXJzLA0KPj4gPj4gTWVkDQo+PiA+Pg0KPj4gPj4gPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+PiA+PiA+KGpndWljaGFyKQ0KPj4g Pj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+ID4+ID7DgCA6 IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPg0KPj4gPj4gPk9r IGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0 aW9uYWxpdHkNCj4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICph bGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9t YWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50IHRvIGENCj4+ID4+bG9v a3VwDQo+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4g dGhlIGNoYWluLCBJIGFtIG5vdA0KPj5zdXJlDQo+PiA+Pmhvdw0KPj4gPj4gPnRoZSBhcmNoaXRl Y3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4NCj4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFN LCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQu Y29tPj4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPj4gPj4gPj4N Cj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJk DQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAy MDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhh bHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhl IHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZQ0KPj4gPj50aGF0IGlmDQo+ PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2gg cmVtb3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0KPj4gPj4gPj4+Zm9yDQo+PiA+PiA+Pj4g YSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5 b3UNCj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUg U0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8NCj4+ID4+cmVhY2gNCj4+ ID4+ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVy d2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IE9uIDcv MTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWls dG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+ QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBp bg0KPj5yZWxldmFudA0KPj4gPj4gPj4+U0ZGcw0KPj4gPj4gPj4+ID53aGVuIHRoZXkgImFycml2 ZSIuDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ID4+PiA+PihqZ3VpY2hhcikNCj4+ID4+ ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4gPj4gPj4+ID4+ IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4g V2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0 b29kDQo+PnRoZQ0KPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+ID4+ID4+PiA+PiBjb3JyZWN0bHkg YXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBzaW5nbGUNCj4+U0YN Cj4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gZW50aXJlIFNG QyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG8NCj4+a25v dw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMg YSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+PnBvaW50DQo+ PiA+PmluDQo+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gT24gNy8x MC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+ID4+DQo+ PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVy IG1ham9yIHByb2JsZW0NCj4+d2l0aA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1p dCBJIG1heSBub3QNCj4+ID4+ID4+PnVuZGVyc3RhbmQNCj4+ID4+ID4+PiA+PiA+aXQuKQ0KPj4g Pj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2 ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+PiA+Pm5leHQNCj4+ID4+ID4+PiA+PiA+ c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJz DQo+PnRvKSwNCj4+ID4+aW4NCj4+ID4+ID4+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2Ug Y2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0 IG1lYW5zDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPlNGRiB3 b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQN Cj4+ID4+ID4+PmJhbGFuY2VyLg0KPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBz b21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yDQo+PiA+PnN0YXRlZnVsLg0KPj4g Pj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5 IFNGRiBiZSBhIGZ1bGwsDQo+PiA+PmZsb3cNCj4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0 ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPj4gPj5hY2NlcHRhYmxl DQo+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5Zb3VycywNCj4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+ PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+ID4+ PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBt YWtlIHRoaXMNCj4+d29yaw0KPj4gPj4gPj4+ID4+c2Vuc2libHkNCj4+ID4+ID4+PiA+PiA+PiBp biBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj5z ZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5 IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPj53aWxsDQo+PiA+PmJlDQo+PiA+PiA+Pj4gPj4gPj4g b3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0K Pj50byBiZQ0KPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xz IHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlDQo+PiA+PiA+Pj5z ZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZp Y2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4+ID4+ZHJpdmUuDQo+PiA+PiA+Pj4gPj4g Pj4NCj4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29y ayBpbiBhbiBhcmNodGllY3R1cmUNCj4+ID4+ZHJpdmVuDQo+PiA+PiA+Pj5ieQ0KPj4gPj4gPj4+ ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMu IEl0IGlzDQo+PiA+PmhhcmRlcg0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PnNlZQ0KPj4gPj4g Pj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3 ZSBhbGxvdyBtb3JlDQo+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4gPj4gPj4+ID4+ID4+IGlu IHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4g SGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlz DQo+PiA+Pm91dHNpZGUNCj4+ID4+ID4+Pm9mDQo+PiA+PiA+Pj4gPj50aGUNCj4+ID4+ID4+PiA+ PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBh cmUNCj4+ID4+dGFza2VkIHRvDQo+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gPj4gPj4+ID4+ID4+b24u DQo+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2Ug aGF2ZSB0byBkbyBpdCBhDQo+PmNlcnRhaW4NCj4+ID4+ID4+PndheS4NCj4+ID4+ID4+PiA+Pml0 DQo+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkg cHJlZmVyZW5jZXMuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBZb3VycywNCj4+ ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBPbiA3 LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBGb3Ig bWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ ID4+IHRoYXQNCj4+ID4+ID4+PiA+Pm5lZWRzDQo+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+PiA+PiA+ Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlh bGx5IGV2ZW4NCj4+ID4+YWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+PiBj ZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+ PmFuZA0KPj4gPj4gPj4+IGNvbXBsZXgNCj4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRy eWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlm ZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQg aXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PmR5bmFtaWMNCj4+ID4+ID4+PiByb3V0aW5nLA0K Pj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBv ciBETlMsIGFsbCBvZg0KPj53aGljaA0KPj4gPj5hcmUNCj4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4g Pj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFi bHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEl0IGFs c28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPj5p cw0KPj4gPj5hDQo+PiA+PiA+Pj5nb29kDQo+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBp cyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4g RnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxw ZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsN Cj4+SWFuDQo+PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFu ZCBvbmUgdGhhdCBJIHdvdWxkDQo+PnByZWZlcg0KPj4gPj53ZQ0KPj4gPj4gPj4+ID4+ID4+PmFj dHVhbGx5DQo+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFs bG93IGFsbCBwb3NzaWJsZQ0KPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+ IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+PiA+ PnJlcXVpcmVtZW50cw0KPj4gPj4gPj4+YW5kDQo+PiA+PiA+Pj4gPj4gdGhlDQo+PiA+PiA+Pj4g Pj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2Ug aW5zdGFuY2VzDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiBuZWVkcw0KPj4gPj4gPj4+ID4+IHRvDQo+ PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90 ZW50aWFsbHkgZXZlbg0KPj4gYWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+ IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gN Cj4+YW5kDQo+PiA+PiA+Pj5jb21wbGV4DQo+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRy eWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlm ZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4g Pj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+Pj4gSm9l bA0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1 ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5 OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUg Y3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBlbmQNCj4+c2VsZWN0aW9uDQo+PiA+Pm9m DQo+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRy YWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4g Pj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJz ZXF1ZW50bHkNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj5TRkZzKT8NCj4+ID4+ID4+PiA+PiA+Pj4+ IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+ PkFuZA0KPj4gPj4gPj4+c3VyZWx5LA0KPj4gPj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNo aXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+PiAi aW1wbGVtZW50YXRpb24iLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE15 IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiB0 aG91Z2gNCj4+ID4+IGENCj4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEg KGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+PmxvY2FsDQo+PiA+PiA+Pj4gPj5zZWxl Y3Rpb24NCj4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlz dHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0KPj4gPj5UaGlzDQo+PiA+PiA+Pj4gPj4gPj4+PiBh cHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+ PiA+Pk15DQo+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBw cm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0KPj5ieQ0KPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+ PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJv YWNoLiBXaXRoIGENCj4+Z2xvYmFsDQo+PiA+PiA+Pj5wYXRoDQo+PiA+PiA+Pj4gPj5pZA0KPj4g Pj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2Ug YW5kIG5lZWRpbmcgdG8NCj4+ID4+YWx0ZXINCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+ Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkDQo+PmVu ZC10by1lbmQNCj4+ID4+ID4+PnBhdGguDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4gUm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+ Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBv biBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0KPj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5d IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPj4yMDE0DQo+PiA+PiA2OjE1DQo+PiA+PiA+Pj4g UE0NCj4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+OyBJLlNtaXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6DQo+PiA+PiBSZToNCj4+ ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUg YXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZw0KPj50bw0KPj4gPj4g Pj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUg d291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUNCj4+ZXhpdA0KPj4gPj5mcm9tDQo+PiA+ PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4g UGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+PiA+ PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMg Y2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+ID4+IGNob29zZQ0KPj4gPj4gPj4+dG8N Cj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0K Pj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+ Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJp YW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiB3cm90ZToNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dl c3RzIGFueQ0KPj4gPj5zb3J0DQo+PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0 LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlDQo+PiA+ PnBhdGgNCj4+ID4+ID4+PihhbGwNCj4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNo b3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlDQo+PnRoaXMNCj4+ID4+ID4+Pm1l YW5zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJl IHRoZSBjbGFzc2lmaWVyDQo+PmNob29zZXMgYQ0KPj4gPj5TRg0KPj4gPj4gPj4+ID4+Q2hhaW4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0 IFNGRi4gSW4gYW55IGNhc2UsDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdl IGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNG SShuKQ0KPj4gPj4gPj4+IGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUg U0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LA0KPj4gPj50aGlzDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBh IG5ldyBTRlAgYXMNCj4+ID4+ID4+PiBvcHBvc2VkDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBp bnN0YW5jZSBvZg0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUg Y3VycmVudCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFm dC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBh biBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ID4+bmVjZXNz YXJ5DQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmlj IGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsDQo+PiA+PmFuZCB0bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVz aW5nIFNGJ3MNCj4+ID4+bmV0d29yaw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVz LCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4+ID4+ID4+PmNyZWF0 aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlAp IGFuZCBpcyB1c2VkIGZvcg0KPj4gPj5mb3J3YXJkaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBh Y2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUg c3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4+ID4+bm9uLWluaXRpYWwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2Ug YW4gU0ZQLA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAt IHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNh dGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPj4gPj5mdW5jdGlvbi4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBz ZWxlY3Rpb24gb2YgYSBuZXcNCj4+ID4+U0ZQLCBhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRh dGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4+ID4+cmVm ZXJyZWQNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0t LQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPG1haWx0 bzoqSS5TbWl0aEBGNS5jb20+PEkuU21pdGhARjUuY29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+PiBEaXJlY3Q8am1oLmRp cmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4s Sm9lbA0KPj4gPj4gTS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+ Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2Nl LmNhcmxldG9uLmNhPjxodWFuZ0BzY2UuDQo+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+PiA+PiA+ Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpU aHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+ID4+QmFsYW5jZXJzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJ IGFtIGRpc2FncmVlaW5nLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g SWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PnRo YXQgaXMNCj4+ID4+ID4+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dz IGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4gPj4gPj4+cHJlY29uY2Vp dmVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hp dGVjdHVyZSBidXJkZW5lZCB3aXRoDQo+PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29u Y2VwdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhh cyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YNCj4+ID4+YXNwaXJhdGlv bg0KPj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRl IGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlDQo+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj4+LQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0 IGJ5IHNheWluZyB0aGF0IGFuDQo+PiA+PiA+Pj5hcmJpdHJhcnkNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0 DQo+PiA+PiA+Pj4gPj5pbnRlbnRpb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0 aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nDQo+PiA+PmltcGFjdHMN Cj4+ID4+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRp b24sIGVsYXN0aWNpdHksDQo+PiA+PmFkZHJlc3MNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4u LiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ U2VudDoNCj4+ID4+ID4+PiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBN IFRvOiBJYW4gU21pdGg7IEpvZWwgTS4NCj4+ID4+IEhhbHBlcm47DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdDQo+PiA+ PlNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwgSSBkb24n dCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcw0KPj4gPj5yZWdhcmQu DQo+PiA+PiA+Pj5JDQo+PiA+PiA+Pj4gPj5hbQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1 ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbg0KPj4gPj5wcm9oaWJp dA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9u LiBJIGFtIG9iamVjdGluZyB0bw0KPj4gPj5IdWFuZydzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVh ZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlDQo+PiA+ PiByZXF1aXJlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJl cGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdA0KPj5zdWNoDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBl bmRzIHVwb24NCj4+ID4+IG1hbnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUg b2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8NCj4+dGhpbmsNCj4+ID4+dGhhdA0K Pj4gPj4gPj4+ID4+dGhleQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlk ZWEuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0 aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bw0KPj4gPj5rbm93DQo+ PiA+PiA+Pj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwg SWFuIFNtaXRoIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0 ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YNCj4+ID4+ID4+Pm1pbGxpb25zDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBp biBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4N Cj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9U IHdvcmxkIG9mIHRvbW9ycm93IHlvdQ0KPj4gYXJlDQo+PiA+PiBvbmx5DQo+PiA+PiA+Pj4gPj4g Z29pbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2Vydmlj ZSBjaGFpbnMgd2l0aCBlcXVhbGx5DQo+PnNtYWxsDQo+PiA+PiA+Pj4gbnVtYmVycw0KPj4gPj4g Pj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUg d2lsbCBldmVyIG5lZWQgbW9yZQ0KPj4gdGhhbg0KPj4gPj4gPj4+IDY0SyINCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gZm9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5d IG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBbam1oQGpv ZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86DQo+PiA+PiA+ Pj5odWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJq ZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPj5hbmQNCj4+ID4+ID4+Pkxv YWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVz IHRvIGRlcGxveSB0aGUNCj4+ID4+ID4+PmFyY2h0aWV0dXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ IHBhcnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mDQo+PnRo ZWlyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBu b3QgcmVxdWlyZSBzdWNoIGFic3VyZA0KPj4gdXNlDQo+PiA+PiBvZg0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3Jp dGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBp dCwgdGhlIGFyY2hpdGVjdHVyZQ0KPj5kb2VzDQo+PiA+PiA+Pj5wZXJtaXQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUN Cj4+IHBlcm1pdHMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBpdCBp cyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieQ0KPj4gPj50aGUNCj4+ID4+ID4+Pndvcmsu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3Rl Og0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2Vydmlj ZSBjaGFpbnMsIGl0IHdpbGwNCj4+bWVhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAw MCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZw0KPj50YWJsZQ0KPj4gPj5v ZiBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVy biB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBh IHJhbmdlIG9mIGRlcGxveW1lbnRzLCBmcm9tDQo+PjENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBz ZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZQ0KPj50aGF0 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNv bXBsZXhpdGllcyBpZiB0aGV5DQo+PiA+PmNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBz dGVhZA0KPj4gPj4gcHJvdmlzaW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2 aWNlIHBhdGhzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4g WW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBh IDQgaG9wDQo+PiA+PiBzZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGgg MjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpP biBCZWhhbGYNCj4+IE9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVs cSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4zOjAzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqU3Vi amVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiBDaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElE IGRyaXZlcyB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4g Pj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNo YW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0bw0KPj4gPj4gZGVyaXZlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRl ZCB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPj5z aW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAo b3IgZ3JhcGgpIHRoYXQgcGFja2V0cw0KPj5tdXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRy YXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBm b3Igb24NCj4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBs eSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4+ID4+IGlkZW50aWZpZXINCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgbG9v a3VwIGNhbg0KPj4gPj4gcmVzdWx0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9y IG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBob3AocykuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IFBhdWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5j b20+DQo+PiA+PiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFn cmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZg0KPj4gdGhl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZl IHRoZSBmb3J3YXJkaW5nDQo+PiA+PmFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSpPbiBCZWhhbGYNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0K Pj4gPj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+ID4+PiA+PiBKdWx5DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbTxtYWls dG86Km1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1p a2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNl cnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFJlLSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g VGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVu dGlmaWVyIHRvDQo+PmRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFj dGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJl cXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+ IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMg bm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJk aW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRo ZSBvbmUNCj4+IHJlcXVpcmVkDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1 Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2Vk IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBhY3Rpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3Jp ZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5j QGFvbC5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20+ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPj4gPj4ganVpbGxldA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhA am9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBx dWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+PlNGDQo+PiA+PiBDaGFpbg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24g c28gdGhhdCBpdCdzDQo+PiA+PmNsZWFyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVt cyB0aGF0IGV2ZXJ5b25lDQo+PmFncmVlcw0KPj4gPj5vbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+Pndo ZXRoZXINCj4+ID4+aXQgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0 aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0DQo+PiA+PnRoZSBJRA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNo b3VsZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUg cGF0aCksIG9yIGlmIHRoaXMgZHJhZnQNCj4+ID4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+PmRy YWZ0cw0KPj4gPj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5p c21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+PiBvcg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gcGF0aCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBj b250cm9sLXBsYW5lLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJl IHN1cHBvcnRlZCAob3IgbWFrZQ0KPj4gPj4gb25lDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJl cXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+IHZlbmRvcnMN Cj4+ID4+IG9ubHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90 aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0t DQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9l bGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpU bzoqc2ZjQGlldGYub3JnPG1haWx0bzoqc2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5v cmclM2NzZmNAaWV0Zi5vcmc+Pg0KPj4gKlNlbnQ6KlR1ZXNkYXksDQo+PiA+PiBKdWx5DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kDQo+PkxvYWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBiZWVu IHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+PmFuc3dlcg0KPj4gPj5hDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBt YWRlIGFib3V0IHRoZQ0KPj4gPj4gPj4+IHByb3Bvc2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4+IHdvcmtp bmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQs IHdlIHdpbGwgd29yayB0bw0KPj4gaW1wcm92ZQ0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQg aW4NCj4+ID4+dGhlDQo+PiA+PiBXRw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNzaW9u IHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2lu Zw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkg d2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4gPj5wZXJzb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQg dG8ga2VlcCBpbiBtaW5kIHRoYXQNCj4+ID4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZQ0KPj5hcmUN Cj4+ID4+IG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0 aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNv bHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29tcGFzcw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5j dGlvbnMsDQo+PnZpcnR1YWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1h Z2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXINCj4+ID4+IGFzcGVjdHMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFy ZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdp dGgNCj4+ID4+YWJvdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBh cmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZQ0KPj4gZG9pbmcuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRv IGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCwNCj4+YXMgSQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcu IFRoZXJlIGFyZSBhdA0KPj4gPj5sZWFzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBk aWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQNCj4+d2lsbA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHBy b2JhYmx5IGFyZQ0KPj4gPj5tb3JlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQg b2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIG9mDQo+PiA+PnRoZXNlLA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxh ciBraW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpbiBhbnkgc29sdXRpb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUg ZW5kDQo+PiA+PnVzZXIuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNl IGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+PnBhY2tldHMsDQo+PiA+PmFuZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IG1h cmtzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3Nl IGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4+ID4+aW5zdGFuY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj4g Pj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8g aW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLg0KPj4gPj5JdCdzDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+ PiA+PiBjaGFpbmluZyBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFz IHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4+ID4+YXJjaHRpZWN0dXJlLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNp bXBseSBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMikgVGhlcmUgaXMgaW50 ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZQ0KPj5jYW4NCj4+ID4+aGF2ZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUg YXMgYSBzaW5nbGUNCj4+cG9pbnQNCj4+ID4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29u dGFjdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNw ZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4+ID4+ YnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+ Pm9uZSBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChm b3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5p cXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5l DQo+PiA+Pm1lY2hhbmlzbXMuDQo+PiA+PiBJdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBs aWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4gPj5tZWNoYW5p c21zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZv ciBzY2FsZS1pbiwgc2NhbGUtb3V0LA0KPj5hbmQNCj4+ID4+dm0NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+PnBlcm1p dHRpbmcNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQg d2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyDQo+PiA+PnRlcm1pbm9sb2d5DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJz IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUg Y2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0KPj5zZWxlY3RpbmcNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0 IGRpcmVjdA0KPj4gPj50cmFmZmljDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVu dCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmUNCj4+IHRoYXQNCj4+ID4+YQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBv bmx5IG9uZSBwbGFjZSBpbg0KPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2Yg Y291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlDQo+PmNvbWJpbmVkLiBJDQo+PiA+PiB0 ZW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIg dG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhh dCBhcHBlYXIgdG8gc2VydmljZQ0KPj4gPj5jaGFpbmluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXINCj4+ aXMNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNl IEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuDQo+PiBUaHVzLA0KPj4gPj4gdGhlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4+ ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQg c3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudA0KPj4gPj5zaW5ndWxhcg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50 IHBsYWNlcw0KPj5pbg0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGgg dGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4g aXMgYQ0KPj4gPj4gc2VxdWVuY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBm dW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZg0KPj4gPj5wYWNrZXRzLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUg c3Vic2V0IG9mDQo+PnRyYWZmaWMNCj4+ID4+aXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8g Z2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kDQo+PmZpcmV3YWxsDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBk aXJlY3RseSB0byB0aGUNCj4+Y2FjaGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBu b3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUNCj4+cGFja2V0cy4NCj4+IEENCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEg c2VxdWVuY2Ugb2YNCj4+ID4+bG9jYXRpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRo ZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlv bnMuIFRoZXkNCj4+ID4+bWF5IGJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3NlZCBi eSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXMNCj4+IHBvcnRzDQo+PiA+PiBv bg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVu dCB3YXlzIHRoYXQgdGhlDQo+PiA+PmxvY2F0aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBt YXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUNCj4+IGFu ZA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9m IHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQw0KPj5ncm91cCwNCj4+ID4+IHdlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRvIGJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUg dG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlDQo+PiA+PnNlcnZp Y2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2Fy ZGluZy4gQW5kIHdlIG5lZWQgdG8NCj4+IHRhbGsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJv dXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRo ZSB3aG9sZQ0KPj4gcGF0aA0KPj4gPj4gbWF5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBi ZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscw0KPj4gPj53aXRo DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBh cyBub3RlZCBpbiBpdGVtICgyKQ0KPj5vbg0KPj4gPj5sb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+YmVoYXZp b3JzDQo+PiA+PiB3aGljaA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+PiA+Pm11Y2gNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlz IGxhcmdlbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0 d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+PiBwcm92aXNpb24NCj4+ID4+IHdlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdo ZW4NCj4+ID4+IG5lY2Vzc2FyeS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRp cmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uDQo+PnBv aW50Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhv cGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgYWZ0ZXIuDQo+PklmIGl0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFi bGUgdG8gdGhlIHdvcmtpbmcNCj4+ID4+IGdyb3VwLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZA0KPj4gdG8N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3Vw IGRpc2FncmVlIHdpdGggdGhlDQo+PiA+PiBpbnRlbnQsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nDQo+PiA+ Pmdyb3VwDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZQ0KPj4gPj53aGF0IHRvDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGlu Zw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+ Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4g Pj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWls aW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+ PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+ PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+ Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+ID4+PiA+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ ID4+ID4NCj4+ID4+ID4+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+ ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+Pg0KPj4gPj4g Pj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+IHNmYyBtYWlsaW5nIGxp c3QNCj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPg0KPj4g Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMg bWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_CFE5AA4C2D768jguicharciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A6C326662632A4A86681D0B524F1363@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5ObyBiZWNhdXNl IHRoZSBzYW1lIGFic3RyYWN0ZWQgY2hhaW4gbWlnaHQgYmUgcmVmZXJlbmNlZCB3aXRoIGRpZmZl cmVudCBwYXRoIGlkZW50ZmllcnMgYXMgdGhlIG5leHQtaG9wcyB0aGF0IGZvcm0gdGhlIHBhdGgg dG8gcmVhbGl6ZSB0aGUgY2hhaW4gbWF5IGJlIGRpZmZlcmVudCBkZXBlbmRlbnQgdXBvbiBwb2xp Y2llcy4gJm5ic3A7U28gcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSBtaWdodCBwb2ludCB0byBT MShAbG9jMSktJmd0O1MyKEBsb2MyKSB3aGVyZWFzDQog4oCcMTAx4oCdIG1pZ2h0IHBvaW50IHRv IFMxKEBsb2M1NSktJmd0O1MyKEBsb2M2NCkuIFRoZXkgYXJlIHRoZSBzYW1lIGNoYWluIGJ1dCBk aWZmZXJlbnQgcGF0aHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQt c2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGlu OyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVj NGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90Ozxh IGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wu Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z cGFuPkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAyOjQ2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+SmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWls dG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5q bWhAam9lbGhhbHBlcm4uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bh bj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJjb3Vy aWVyIG5ldyxtb25vc3BhY2UiIHNpemU9IjIiPg0KPGRpdj5Xb3VsZG4ndCB0aGF0IGJlIGNhbGxl ZCB0aGUgJnF1b3Q7c2VydmljZSBjaGFpbiBpZGVudGlmaWVyJnF1b3Q7IHRoZW4/ICZuYnNwO0lm IHRoZSBzZXJ2aWNlIGNoYWluIGlzIHRoZSBvcmRlcmVkIGxpc3Qgb2YgU0ZzIGFuZCB0aGUgc2Vy dmljZSBwYXRoIGlzIHRoZSBvcmRlcmVkIGxpc3Qgb2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291 bGQgaW5mZXIgdGhhdCBhICZxdW90O3NlcnZpY2UgcGF0aCBpZGVudGlmaWVyJnF1b3Q7IHdvdWxk IGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZQ0KICpwYXRoKiwgbm90IGEgc2VydmljZSAq Y2hhaW4qLjwvZGl2Pg0KPGRpdj48YnI+DQpBZ2FpbiwgSSB0aGluayB0aGlzIGlzIHdoZXJlIHRo ZSBjb25mdXNpb24ga2VlcHMgY3JlZXBpbmcgaW4uICZuYnNwO1RoZSB0ZXJtcyAmcXVvdDtjaGFp biZxdW90OyBhbmQgJnF1b3Q7cGF0aCZxdW90OyBzZWVtIGluY29uc2lzdGVudC48YnI+DQo8YnI+ DQo8YnI+DQo8L2Rpdj4NCjwvZm9udD4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8aHIgc3R5bGU9ImJvcmRlcjowO2hlaWdodDoxcHg7Y29sb3I6Izk5OTtiYWNrZ3Jv dW5kLWNvbG9yOiM5OTk7d2lkdGg6MTAwJTttYXJnaW46MCAwIDlweCAwO3BhZGRpbmc6MDsiPg0K PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFy QGNpc2NvLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1 aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+Jmd0Oyw8YSBocmVmPSJt YWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZsdDs8YSBocmVmPSJtYWls dG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssPGEgaHJl Zj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZndDss PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6 IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KPGJyPg0KPGRp dj5Zb3VyIGRlZmluaXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBm b3J3YXJkaW5nIHBhdGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4g VGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNl IGNoYWluIGRhdGEgc3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lm aWMgaW5zdGFuY2VzIGJhc2VkIHVwb24gd2hpY2gNCiBuZXh0LWhvcHMgdG8gdGhvc2UgaW5zdGFu Y2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1 ZSBpcyBpbiBwbGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0 aGUgbmV0d29yayB5b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUg dG8gc3BlY2lmeSB3aGljaCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5l eHQtaG9wDQogd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0 aGF0IHNlcnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJv dG9jb2wgLyBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3Uu DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tIiBjbGFzcz0iIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSIgY2xhc3M9IiI+bWlrZWJpYW5j QGFvbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIiBjbGFzcz0iIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4 IFBNPGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIi PlRvOiA8L3NwYW4+SmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lz Y28uY29tIiBjbGFzcz0iIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIiBjbGFzcz0iIj5tbjE5MjFAYXR0LmNvbTwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSIgY2xhc3M9IiI+bW4xOTIxQGF0 dC5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSIgY2xhc3M9IiI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiBjbGFz cz0iIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiBjbGFzcz0iIj5qbWhAam9lbGhhbHBlcm4uY29t PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIGNsYXNz PSIiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSIgY2xhc3M9IiI+Um9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tIiBjbGFzcz0iIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIGNsYXNz PSIiPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj48 Zm9udCBmYWNlPSJjb3VyaWVyIG5ldyxtb25vc3BhY2UiIHNpemU9IjIiPg0KPGRpdj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IGFsdG8tZm9udCwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgd2hp dGUtc3BhY2U6IHByZS13cmFwOyI+SSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRoZSBjb25m dXNpb246PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFsdG8t Zm9udCwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+PGJy Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFsdG8tZm9u dCwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+Jmd0OyBJ IGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IGFs dG8tZm9udCwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFsdG8tZm9udCwgYXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+Jmd0OyBzcGVjaWZpYyBpbnN0YW5jZXMgb2Yg UzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRpb24gdGhlcmVvZikuIEk8L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogYWx0by1mb250LCBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyB3 aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYWx0by1m b250LCBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij4mZ3Q7 IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxs eSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBhbHRvLWZvbnQsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3Jh cDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhbHRvLWZvbnQsIGFyaWFsOyBmb250LXNp emU6IDE0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPiZndDsgYW5kIHRoZW4gcHVzaCB0aGlz IGludG8gdGhlIG5ldHdvcms8L3NwYW4+PGJyPg0KPGJyPg0KQnkgZGVmaW5pdGlvbiwgSSB1bmRl cnN0b29kIGEgJnF1b3Q7c2VydmljZSBwYXRoJnF1b3Q7IHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBv ZiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIEluIHRoZSBzdGF0ZW1lbnQgYWJvdmUsIHlvdSB1c2Ug YSAmcXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90OyB0byByZWZlciB0byBhIHNlcnZp Y2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAmcXVvdDtbZG9lcyBub3RdIHNwZWNpZnkgc3Bl Y2lmaWMgaW5zdGFuY2VzJnF1b3Q7Ljxicj4NCjxicj4NCjwvZGl2Pg0KPC9mb250Pg0KPGRpdiBj bGFzcz0iIj48L2Rpdj4NCjxicj4NCjxicj4NCjxicj4NCjxociBzdHlsZT0iYm9yZGVyOjA7aGVp Z2h0OjFweDtjb2xvcjojOTk5O2JhY2tncm91bmQtY29sb3I6Izk5OTt3aWR0aDoxMDAlO21hcmdp bjowIDAgOXB4IDA7cGFkZGluZzowOyI+DQo8Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8YSBocmVmPSJtYWls dG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi PlRvOiA8L2I+TkFQSUVSQUxBLCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0 LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mbHQ7PGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxSb24NCiBQ YXJrZXImbHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20i PlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSnVs eSAxMSwgMjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQo8dGl0bGU+PC90aXRsZT4NCk1h cmlhLDxicj4NCjxicj4NCkkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvPGJyPg0KYSBkYXRhIHN0cnVjdHVyZSB0 aGF0IGNvbnRhaW5zIFNGIHRvIG5leHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUgYTxi cj4NCmNoYWluLCBsZXTigJlzIHNheSBTMSAtJmd0O1MyLSZndDsgUzMsIHlvdSAqbWlnaHQqIHdo ZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5PGJyPg0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0 aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC48YnI+DQpI b3dldmVyLCB5b3UgZG8gKm5vdCogaGF2ZSB0byBkbyB0aGlzIGZyb20gYW4gYXJjaGl0ZWN0dXJh bCBzdGFuZHBvaW50IChJPGJyPg0Kd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlvdSBk b27igJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91PGJyPg0KY291bGQgc2ltcGx5IGFz c2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFu ZDxicj4NCnRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdvcmsuIEF0IHRo ZSBTRkYgaXQgd2lsbCBoYXZlIGE8YnI+DQpzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMg bWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4gdGhlPGJyPg0KbmV4dC1ob3Bz IGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlv dSBsZWFybjxicj4NCnRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNo IHRoZW0gZG93biBmcm9tIGEgY2VudHJhbGl6ZWQ8YnI+DQpjb250cm9sbGVyLCBjb25maWd1cmUg dGhlbSB0aHJvdWdoIENMSSwgbGVhcm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoPGJyPg0Kc29t ZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90 IGNvcnJlY3QgdG88YnI+DQpzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxs IFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGEgcHJpb3JpPGJyPg0KYWx0aG91Z2ggaXQgaXMgcGVy ZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxkIHNheSByZWNvbW1lbmRlZCkgdG8gZG88 YnI+DQpzby48YnI+DQo8YnI+DQpMZXTigJlzIHRha2UgYW4gZXhhbXBsZSB0byBob3BlZnVsbHkg bWFrZSB0aGlzIGNsZWFyOjxicj4NCjxicj4NCkkgZGVmaW5lIGFuIFNGQyAobGV04oCZcyByZWZl ciB0byBpdCBhcyBTRkMtMSkgUzEtJmd0O1MyLSZndDtTMy4gRm9yIGFyZ3VtZW50czxicj4NCnNh a2UgbGV04oCZcyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKA mXQgd2FudCB0byBzcGVjaWZ5PGJyPg0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5k IFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJPGJyPg0KYXNzaWduIGEgc2Vydmlj ZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0m Z3Q7UzItJmd0O1MzPGJyPg0KYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28g dGhhdCB0aGUgU0ZGIGRhdGEgc3RydWN0dXJlcyBhcmU8YnI+DQpwb3B1bGF0ZWQgd2l0aCB0aGlz IGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzPGJy Pg0Kd2l0aCBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAxMDAsIHRoZSBTRkYgd2lsbCBsb29rIHRo aXMgdXAgaW4gdGhlIGRhdGE8YnI+DQpzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMg dG8gUzEtJmd0O1MyLSZndDtTMyBhbmQgdGhlIGluZGV4IGluIHRoZSBTRkM8YnI+DQplbmNhcHN1 bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV0 4oCZcyBzYXkgd2U8YnI+DQphcmUgYXQgUzIgaW4gdGhlIGNoYWluLiBUaGUgU0ZGIHdpbGwgbm93 IGhhdmUgdG8gcmVzb2x2ZSB0aGUgbmV4dC1ob3AgdG88YnI+DQpTMyBhbmQgd2lsbCBkbyBhIGxv b2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMgcmVhY2hhYmxlLjxicj4NCjxicj4NCk9uIDcv MTEvMTQsIDExOjI2IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQomZ3Q7SmltLDxicj4NCiZndDs8YnI+DQomZ3Q7Q291bGQgeW91IHRlbGwgdXMg d2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICZxdW90O3NlcnZpY2UgcGF0aCZxdW90OyBhbmQg YTxicj4NCiZndDsmcXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90Oz88YnI+DQomZ3Q7 SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4g YXByaW9yaSAod2hpY2g8YnI+DQomZ3Q7aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0aGVu IGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaDxicj4NCiZndDtuZXh0LWhvcCBT RkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi48YnI+DQomZ3Q7PGJyPg0K Jmd0O01hcmlhPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IDxicj4NCjxiciBjbGFzcz0iIj4NCkZyb206IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpIFs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29t Ij5tYWlsdG86amd1aWNoYXJAY2lzY28uY29tPC9hPl08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IEpvZWwgTS48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSeKAmW0g c29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0 aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2U8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE9uIDcvMTEvMTQsIDEw OjU4IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7RGl0dG8uPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgRnJv bTogPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg WzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT5dPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEs IE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUkU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBSZS0sPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJs eSBpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2RyYWZ0LjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgTWFuZGF0aW5nIGEg c2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxs PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtkaXN0cmlidXRlZDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IG1vZGVsIGlzIG5vdCBhbGxvd2VkLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgU2V2ZXJhbCB2 b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4gaXRz ZWxmPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtzaG91bGQgYmU8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwcm92aWRlZCBpbnN0ZWFkLjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgQ2hlZXJzLDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1lZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Oy0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtEZSA6IHNm YyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsoamd1aWNoYXIpPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0O0Vudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTg8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7w4AgOiBOQVBJRVJBTEEsIE1BUklBIEg7 IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 O09iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtPayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVj aWZpY2FsbHkgaXMgdGhpcyBmdW5jdGlvbmFsaXR5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0O3Byb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4 dC1ob3BzIHRvICphbGwqIFNGRuKAmXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVy IHBvaW50IHRvIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvb2t1cDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFj aCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDtzdXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtob3c8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0PzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7T24gNy8xMS8xNCwgOTo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBI JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29t PC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDtBYnNvbHV0ZWx5LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IEZyb206IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGpndWljaGFyKTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkg MTEsIDIwMTQgOTo1NCBBTTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAu LiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dGhhdCBpZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB5b3Ug YWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDt1c2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtmb3I8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYSBnaXZlbiBmbG93IHRv IHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3U8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0O2JldHRlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWFrZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdXJlIHRoYXQgdGhhdCBy ZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG88YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlYWNoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGlu IGRlZXAgdHJvdWJsZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMS8x NCwgOTo0OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0O0Fic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVk IG9ubHkgaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3JlbGV2YW50PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U0ZGczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7d2hlbiB0aGV5ICZxdW90O2Fycml2ZSZxdW90Oy48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7R3VpY2hhcmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsoamd1aWNoYXIpPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAx NCA5OjI3IEFNPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFdlbGwgSSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRo YW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dGhlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7cHJvcG9z YWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Y29ycmVjdGx5IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2lu Z2xlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtTRjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O3dpdGhpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUgU0ZG IGFzIHRoZXJlIGlzIG5vIHdheSB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7a25vdzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3ByaW9yaTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBu ZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtwb2ludDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0aW1lLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgJnF1b3Q7Sm9lbCBNLiBI YWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1o QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDtSb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvciBw cm9ibGVtPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3aXRoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDt5b3VyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtwcm9wb3NhbCBhcyBJIHVuZGVyc3RhbmQgaXQuIChBbmQgSSByZWFkaWx5 IGFkbWl0IEkgbWF5IG5vdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O3VuZGVyc3RhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0O2l0Lik8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBh cyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDtuZXh0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQg ZGVsaXZlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RvKSw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2luPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ZXZlcnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0O3NlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NpbmNlIGl0IGhh cyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnM8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtldmVyeTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBm dWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2JhbGFuY2VyLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7SSBhaHZlIG5vIHByb2JsZW0gaWYg c29tZSBTRkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7c3RhdGVmdWwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtCdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWly ZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDtmbG93PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtzZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1zIHRvIG1lIHRv IGJlIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthY2NlcHRhYmxlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpbXBvc2l0 aW9uLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtZb3Vycyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0O0pvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFs cGVybiB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsgUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0 cnlpbmcgdG8gbWFrZSB0aGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3b3JrPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2Vuc2libHk8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg aW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gSSBleHBlY3QgdGhhdCB0aGU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0O3NlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1l IHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7d2ls bDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgb3JjaGVzdHJhdGVkIGFu ZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWluczxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7dG8gYmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDtkcml2ZW4gYnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsgQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0 byBjbGllbnRzLCBhbmQgZW5hYmxlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7c2VsZi1zZWxlY3Rpb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2Vydmlj ZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ZHJpdmUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3 b3JrIGluIGFuIGFyY2h0aWVjdHVyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZHJp dmVuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Ynk8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg aW5pdGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQgaXM8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhcmRlcjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2VlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1 dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGR5bmFtaWNpdHk8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW4gdGhl IG5ldHdvcmsgYmVoYXZpb3IuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIG1vc3Qgb2Yg dGhhdCBwZXJzcGVjdGl2ZSBJIGRlc2NyaWJlZCBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7b3V0c2lkZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O29mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5n IHdlIGFyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGFza2VkIHRvPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YWdyZWU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDtv bi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBk byBpdCBhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtjZXJ0YWluPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7d2F5LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZl IHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBZb3Vycyw8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgSm9l bDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2Ug aW5zdGFuY2VzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgdGhhdDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O25lZWRzPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDt0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5l ZCwgcG90ZW50aWFsbHkgZXZlbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNyb3Nz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGF0YTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBl bm91Z2g8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2FuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjb21wbGV4PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5 aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXJj aGl0ZWN0dXJlIHRvIHJlYWxpemUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSSdtIGN1cmlvdXMgYXMg dG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDtkeW5hbWljPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHJv dXRpbmcsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBv ciBETlMsIGFsbCBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7d2hpY2g8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2FyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O2JpZ2dlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4g cHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVudGVkPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEl0 IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7aXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtnb29kPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZyb206IEpv ZWwgTS4gSGFscGVybiBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBq b2VsaGFscGVybi5jb208L2E+XTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQgOTo0NSBQTTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7 IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+DQptaWtlYmlhbmNAYW9sLmNvbTwv YT47PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtJYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtTbWl0aDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtCYWxhbmNl cnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFu ZCBvbmUgdGhhdCBJIHdvdWxkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtwcmVmZXI8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3dlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FjdHVhbGx5PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWNp ZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGU8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2ltcGxlbWVudGF0aW9ucy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJlY2F1c2UgaXQg ZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDtyZXF1aXJlbWVudHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDthbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNl cnZpY2UgaW5zdGFuY2VzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG5lZWRzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBi ZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBhY3Jvc3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDtkYXRhPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJh dGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDthbmQ8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtjb21wbGV4PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtl IGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtkaWZmaWN1bHQ8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFlv dXJzLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgSm9lbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJ1dCBpdCBpcyBhIGZhaXIg cXVlc3Rpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBh cmtlciB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiBJ cyB0aGUgZW5kIHRvIGVuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7c2VsZWN0aW9uPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDtvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICh0b3AtbGV2ZWwpIGluc3Rh bmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZTxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsYXNzaWZpZXIpPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2Vx dWVudGx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtTRkZzKT88YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9uLjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7QW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7c3VyZWx5LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJh bCBpc3N1ZSBhbmQgbm90IHJlbGVnYXRlZCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O2ltcGxlbWVu dGF0aW9uJnF1b3Q7LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTXkgb3duIHZpZXcgaXMg dG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyB0aG91Z2g8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHM8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2xvY2FsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2VsZWN0aW9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcG9saWN5KSBp cyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDtUaGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBwcm9hY2ggZG9lcyBu b3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7TXk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRo aXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Ynk8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbmNy ZWFzZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFw cHJvYWNoLiBXaXRoIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2dsb2JhbDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNo LCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDthbHRlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O3RoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZv ciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ZW5kLXRvLWVu ZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGguPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBSb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJl Y3RAam9lbGhhbHBlcm4uY29tPC9hPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsyMDE0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgNjoxNTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBQTTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOkkuU21pdGhARjUuY29tIj4NCkkuU21pdGhARjUuY29t PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IFN1YmplY3Q6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgUmU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgdGhlIGFyY2hp dGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxIG5lZWRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O3RvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7aW5mbHVlbmNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRv IHJlY2xhc3NpZmljYXRpb24gYXQgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtleGl0PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtmcm9tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU0YxLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZm ZXJlbnQgZnVuY3Rpb25zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtsb2dpY2FsbHk8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNj cmliZSBob3cgdGhleTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGNob29zZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Y29tcG9zZSB0aGVtIGZvciAmcXVvdDtzZXJ2aWNlJnF1b3Q7IGRlbGl2ZXJ5LjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIDcvMTAvMTQsIDY6MTAgUE0sIDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+ bWlrZWJpYW5jQGFvbC5jb208L2E+IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHNl ZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7c29ydDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0O29mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpbWl0LiBIb3dldmVyLCBpdCBkb2Vz IHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDtwYXRoPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 KGFsbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFu dGlhdGlvbi4gSSBiZWxpZXZlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGlzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7bWVhbnM8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg ZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyPGJyIGNsYXNz PSIiPg0KJmd0OyZndDtjaG9vc2VzIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NG PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Q2hh aW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJz dCBTRkYuIEluIGFueSBjYXNlLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHlu YW1pYyBTRlAgd2hlcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTRkkobik8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaXM8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRy YWZ0LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICZxdW90O2JyYW5jaGluZyZxdW90OyB0byBh IG5ldyBTRlAgYXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg b3Bwb3NlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRv IHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1 cmUtMDA6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQg aW50byB0aGUgbmV0d29yayBpdCBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmVj ZXNzYXJ5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0 aGF0IHdpbGwgYmUgdXNlZCw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZCB0bzxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0 IFNGQyB1c2luZyBTRidzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtuZXR3b3JrPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBT RkMgcmVzdWx0cyBpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDtjcmVhdGlvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9u IFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDtmb3J3YXJkaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXRzIHRocm91Z2ggdGhlIFNG Qy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlu c3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3Np ZmljYXRpb24gKG9yPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtub24taW5pdGlhbDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMg dHJhdmVyc2UgYW4gU0ZQLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBt YXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtmdW5jdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtTRlAsIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXM8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlZmVycmVkPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzICZxdW90 O2JyYW5jaGluZyZxdW90Oy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDstLS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICpGcm9tOiA8YSBocmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29t Ij4qSS5TbWl0aEBGNS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+ SS5TbWl0aEBGNS5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86ICpKb2VsIEhhbHBl cm48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBEaXJlY3QmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 LEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDtIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRv bi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPiZsdDtodWFuZ0BzY2UuPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNhcmxldG9uLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0O2NhJmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0JhbGFuY2VyczxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5n LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkg b2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3Ro YXQgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZp Y2UgY2hhaW5zIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 cHJlY29uY2VpdmVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRo ZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoYXQ8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcHJlY29uY2VwdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3Jl ZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXNwaXJhdGlvbjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMg YXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2FyY2hpdGVjdHVyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0Oy08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgeW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0 IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQgYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDthcmJpdHJhcnk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbnVtYmVyIGlzICZx dW90O3RvbyBmYXImcXVvdDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNuJ3Q8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbnRlbnRp b25hbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9u cyB0aGF0IGhhdmUgbGFzdGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW1wYWN0 czxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRp b24sIGVsYXN0aWNpdHksPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthZGRyZXNzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBw cm9ibGVtIEknbSBub3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRl YWwgd2l0aC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFs8YSBocmVm PSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tPC9hPl08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NlbnQ6PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsg Sm9lbCBNLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEhhbHBlcm47PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNj ZS5jYXJsZXRvbi5jYTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7U2VydmljZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWFuLCBJIGRvbid0IHRo aW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDtyZWdhcmQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7STxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0O2FtPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0 ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cHJv aGliaXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hp b24uIEkgYW0gb2JqZWN0aW5nIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtIdWFu ZydzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBz dWNoIGRlcGxveW1lbnRzIGFyZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHJlcXVp cmVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBh bSBub3QgdHJ5aW5nIHRvIHByb2hpYml0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDtzdWNoPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3Qg ZGVwZW5kcyB1cG9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbWFueTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBw ZW4gdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3RoaW5rPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDt0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7dGhleTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgdGhlIGFyY2h0aWVjdHVyZSBz aSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7a25vdzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O3doYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZTo8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZGlzYWdyZWUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0 aGF0IG1hbmFnZSB0ZW5zIG9mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7bWlsbGlvbnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXI8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5 IGJlbGlldmUgdGhhdCBpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3U8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBvbmx5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IGdvaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2 aWNlIGNoYWlucyB3aXRoIGVxdWFsbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O3NtYWxsPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG51bWJlcnM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAmcXVvdDtubyBv bmUgd2lsbCBldmVyIG5lZWQgbW9yZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoYW48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgNjRLJnF1b3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29tZm9ydC48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2Vs aGFscGVybi5jb208L2E+XTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0Bz Y2UuY2FybGV0b24uY2E8L2E+OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YW5kPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7TG9hZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg QmFsYW5jZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm8s IGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FyY2h0aWV0dXJlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxp bWl0cyBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dGhlaXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHVzZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IG9mPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3Qg ZmlndXJlIG91dCBob3cgdG8gd3JpdGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVy YWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0O2RvZXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtw ZXJtaXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Y2ggYWJ1c2UuPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0 aGF0IHRoZSBhcmNodGllY3R1cmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwZXJtaXRzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVk IG9yIHJlcXVpcmVkIGJ5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3b3JrLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSXQgaXNuJ3QuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWW91cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hh aW5zLCBpdCB3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDttZWFuPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGlu ZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dGFibGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O29mIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3JlIHJvdXRlci48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYW5nPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0 IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZy b208YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg c2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0O3RoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0 b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDtjaG9vc2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDt0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdm9pZCBhbnkg dXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHByb3Zpc2lvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAx NjAsMDAwIHNlcnZpY2UgcGF0aHMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MDYg UE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFBhdWwsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3 aWxsIGJlIGZvciBhIDQgaG9wPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgc2Vydmlj ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5j ZXMgYXQgZWFjaCBob3A/PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFyaWE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8 YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dICpPbiBCZWhhbGY8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBPZjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDszOjAz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5IHlvbmcgKkNj OiogPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpvZWxoYWxwZXJu LmNvbTwvYT47PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4gKlN1YmplY3Q6KiBSZTogW3NmY10g U2VydmljZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IENoYWlucyw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5 LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2 ZXMgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nLiBJwrlk PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG88YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkZXJpdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3Bv cnQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1 c2VkIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtzaW1wbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBh Y2tldHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O211c3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFj dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaXJlY3Rpb24gdGhhdCBwZW9w bGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGlzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBp bXBsZW1lbnRlZC4gVGhlIHBhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpZGVu dGlmaWVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5n IG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgcmVzdWx0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBh IG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQ8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhvcChzKS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OyI+bWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFncmVlLiBUaGUgYXJjaC4g ZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2FjdGlvbnMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTHVjeTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24iPm1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10qT248L2E+IEJlaGFsZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPk9mKm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKlNlbnQ6KlRodXJzZGF5LDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdWx5PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxMCwgMjAxNCAyOjA2IEFNICpUbzo8YSBocmVmPSJt YWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tIj4qbWlrZWJpYW5jQGFvbC5jb208L2E+PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tJmd0OztqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb20m Z3Q7O2ptaEBqb2VsaGFscGVybi5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRm Lm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2ZjXSBT ZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgUmUtLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkg YSBzZXJ2aWNlIHBhdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZp ZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG88YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O2Rlcml2ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBh Y3Rpb25zLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVs bCBrbm93bGVkZ2Ugb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBldmVyeTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUgU0ZDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVkL2p1c3RpZmllZDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0 cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBw aWVjZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhhdCB3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgcmVxdWlyZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0 bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RydWN0dXJlIGEgc2VydmljZSBj aGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O3VzZWQgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndh cmRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWN0aW9uczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENo ZWVycyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRGUgOipzZmMgWzxhIGhyZWY9Im1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10q RGU8L2E+IGxhIHBhcnQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRlKm1pa2Vi aWFuY0Bhb2wuY29tIj5kZSptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1h aWx0bzptaWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7ICpFbnZvecOpIDoqbWVyY3JlZGkgOTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGp1aWxsZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDIwMTQgMjI6MDMgKsOAIDo8YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFs cGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29tPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJmd0Oztz ZmNAaWV0Zi5vcmciPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJmd0OztzZmNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICpPYmpldCA6KlJlOiBb c2ZjXSBTZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O1NGPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgQ2hhaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBTRjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBQYXRoPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXIg dGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQnczxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Y2xlYXIgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhvc2Ugbm90PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwg aXQgc2VlbXMgdGhhdCBldmVyeW9uZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YWdyZWVzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlc2UgdGVybXMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBp cyBzdGlsbCB1bmNsZWFyIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt3aGV0aGVyPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDtpdCBpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt0aGUgSUQ8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBTRkMgSGVhZGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNob3Vs ZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVmZXJlbmNlICh0aGUgY2hhaW4g b3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRyYWZ0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDtzaW1wbHk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZHMgdG8g bGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDtkcmFmdHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RvPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5n IGJhc2VkIG9uIGNoYWluPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgb3I8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3I8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgcGF0aCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUg bmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgbGF0dGVy IChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0 ZWQgKG9yIG1ha2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmU8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwp IHRvIGF2b2lkIHNvbWU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB2ZW5kb3JzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgb25seTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0t PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0t PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICpGcm9tOjxhIGhyZWY9Im1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJmd0OyI+bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJmd0OzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86PGEgaHJlZj0ibWFpbHRvOipzZmNAaWV0Zi5vcmciPipz ZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJmd0OyI+bWFpbHRvOnNmY0BpZXRmLm9y ZyUzY3NmY0BpZXRmLm9yZyZndDs8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICpTZW50 OipUdWVzZGF5LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtMb2FkPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCYWxhbmNlcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhhdmUgYmVlbiB0 cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 YW5zd2VyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBh Ym91dCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJv cG9zZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGllY3R1 cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB3b3Jr aW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBhZ3JlZW1lbnQgb24g dGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgaW1wcm92 ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRp Y2lwYXRlZCBpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgV0c8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgd29ya2luZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5k cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFp biBteTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGVyc29uYWw8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0 dXJlLiBXZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7YXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgbm90PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdHRlbXB0aW5n IHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3 b3VsZCBlbmNvbXBhc3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1Ms IHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucyw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O3ZpcnR1YWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hpbmUgYW5k IGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgYXNwZWN0cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0 aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgdG88YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBi dXQgd2hpY2ggYXJlIGRlYWx0IHdpdGg8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fi b3ZlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGVyZSB3ZSBhcmU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyBkb2luZy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0byBnZXQgdG8gc2Vy dmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDthcyBJPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoZW0sPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDtsZWFzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhy ZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDt3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7bW9yZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXNlLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBiZSB1c2VkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp biBhbnkgc29sdXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNl IHByb3ZpZGVkIHRvIHRoZSBlbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2VydmljZSBmdW5j dGlvbi4gSXQgcmVjZWl2ZXMgdXNlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7cGFja2V0cyw8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbW9kaWZpZXMgdGhlbSAob3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFya3M8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3Nl IGFuIGVuZCB1c2VyIHNlcnZpY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3Rh bmNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2Vy cyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDtzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0 byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy48YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O0l0J3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJl aGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgY2hhaW5pbmcgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXJjaHRpZWN0dXJlLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBp cyBzaW1wbHkgYTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBh Y2tldC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhh dCBpcywgb25lPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtjYW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2hhdmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQ8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYXBwZWFyczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDtwb2ludDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhY3Q8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg Zm9yIGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljIHNlcnZpY2Ug ZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2J5IGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9z c2libHkgaW5jbHVkaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtvbmUgb3I8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxl IHVzaW5nIFZSUlAtbGlrZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGVjaG5p cXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcg ZGF0YSBwbGFuZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21lY2hhbmlzbXMsPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1p biwgc2NhbGUtb3V0LCA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2FuZDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dm08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3Rh bnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiA8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O3Blcm1pdHRpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJl IGNhcmVmdWwgdGhhdCBvdXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rlcm1pbm9s b2d5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFkPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlYWRlcnMgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxz byBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7c2VsZWN0 aW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0aHMgZm9yIHRo ZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDt0cmFmZmljPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJl bnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgdGhhdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25s eSBvbmUgcGxhY2UgaW4gPGJyIGNsYXNzPSIiPg0KJmd0OyZndDt0aGU8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgb2YgY291cnNlIHRo ZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Y29tYmluZWQu IEk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0ZW5kPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBh cHBlYXIgdG8gc2VydmljZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hhaW5pbmc8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEg Y2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O2lzPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDthPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVGh1cyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IG9mIHR5cGUg MyBsb2FkIGJhbGFuY2luZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyB0bzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8g ZGlmZmVyZW50PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDtzaW5ndWxhcjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25z IGluIGRpZmZlcmVudCBwbGFjZXMgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDtpbjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBuZXR3b3JrLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4g d2hlbiBJIHRhbGsgYWJvdXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZp Y2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgc2VxdWVuY2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2Y8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3BhY2tldHMuPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vi c2V0IG9mIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7dHJhZmZpYzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7aXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBE UEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0O2ZpcmV3YWxsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGlsZSBhIGRp ZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Y2FjaGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91dDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7cGFja2V0cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBBPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFz aGlvbiwgYSBzZXF1ZW5jZSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRp b25zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yay4gVGhv c2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4g VGhleTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5IGJlPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUg YWRkcmVzc2VkIGFzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgcG9ydHM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW4g U0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmU8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydC48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Z3JvdXAsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZn dDsgd2U8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRvIGJlPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhp Z2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 c2VydmljZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdoaWNoIGRy aXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyB0YWxrPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYm91dCB0aGUgYWN0dWFs IGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMg aGF2ZSBzYWlkICZxdW90O2J1dCB0aGUgd2hvbGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwYXRo PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbWF5PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hp dGVjdHVyZSBkZWFsczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2l0aDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3Qs IGFzIG5vdGVkIGluIGl0ZW0gKDIpIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7b248YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyIGNsYXNz PSIiPg0KJmd0OyZndDtiZWhhdmlvcnM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3 aGljaDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlzaWJsZSB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7bXVjaDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHNhbWUg d2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRo ZSBvdGhlcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHByb3Zpc2lvbjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHdlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtl IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW48YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWNlc3NhcnkuPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJh c2VkIG9uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhdmFp bGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7cG9p bnQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJl IGFmdGVyLiA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0O0lmIGl0PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRo ZSB3b3JraW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgZ3JvdXAsPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9u YWwgd29yZHMgYXJlIG5lZWRlZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRvPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAg ZGlzYWdyZWUgd2l0aCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbnRlbnQs PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2YgY291cnNl IGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Z3JvdXA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFncmVlbWVudHMuIElm IHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZTxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7d2hhdCB0bzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5 IG5leHQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYzxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpz ZmNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IHNmYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBtYWlsaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBzZmM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBzZmM8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gc2ZjPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IHNmYzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtz ZmMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj PC9hPjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N CnNmYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CFE5AA4C2D768jguicharciscocom_-- From nobody Fri Jul 11 12:28: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 063F11B295B for ; Fri, 11 Jul 2014 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[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 qkNfYO1o2CBl for ; Fri, 11 Jul 2014 12:28:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71C61B2953 for ; Fri, 11 Jul 2014 12:28:06 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-c3-53bfe5f64437 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E8.20.25146.6F5EFB35; Fri, 11 Jul 2014 15:26:14 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 11 Jul 2014 15:27:59 -0400 From: Eric Gray To: "NAPIERALA, MARIA H" , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8UZCMEh16X6U6IZxiYl3h/CpuXlPYAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgQCAAAEnAIAAAakAgAADFoCAAADNgIAABIYAgAADigCAAATCAIABKX+A//+9qOCAAEnKAIABfQsw Date: Fri, 11 Jul 2014 19:27:58 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com>, , <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com>, <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLrHW/fb0/3BBo+fyVssnadu8fHUGyaL jZPbGC0Ov33KbnHh6VRmiycPtrI7sHm8uPKM2eNl/xxGjym/N7J6LFnyk8nj3JTvjB4tz06y BbBFcdmkpOZklqUW6dslcGXMmXGKsWBTXMXLI8+ZGhgXeXcxcnJICJhIXOu8ygxhi0lcuLee rYuRi0NI4CijxN1D96Cc5YwSe35dYwGpYhPQkDh2Zy0jSEJEoJNRYlfXGWYQh1mgm1Fi9+uL jCBVwgI2Ejf/XWEFsUUEbCU6dsxlhuhYxShxfP9xdpAEi4CqxL7VD8HG8gr4SvRvOc8Mse8l p8T+la/AijgFoiRe/3jFBmIzAl34/dQaJhCbWUBc4taT+UwQlwtILNlzHuoLUYmXj/+xQtiK Evv6p7ND1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI0dp cWpZbrqR4SZGYPQdk2Bz3MG44JPlIUYBDkYlHl6FlH3BQqyJZcWVuYcYpTlYlMR5NavnBQsJ pCeWpGanphakFsUXleakFh9iZOLglGpgjDxqcPSxZkjDwXvbazLMcvdOdDk6f/HNS9ulqyVj LW1yVb8rmD/q+ifxwuiPkYzuobkq70qPW1nN5DU/5L/fe1PB/FNTHtxt+nN88pfXUzNP3fp6 92CcvOFpsX9PM+cvNeU7JS+ZYhd1jD1qn4PIPqdfJq1pK+8Hb7R4cGvNn7rQ0Kn+zad0pJVY ijMSDbWYi4oTARzFE3efAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/W39odEGf5GZfHydI4Y3ECe7ERm0 Cc: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 19:28:10 -0000 Maria, So many fundamental problems. What to do? I didn't suggest "leaving it to implementation." I merely suggested that e= ach IETF working group needs to focus on a set of problems they can solve in a reaso= nable amount of time, without having to boil any oceans. Joel suggested an architectural approach that would allow any form of distr= ibution you might want, without requiring every solution to support all possibiliti= es, and without impacting the ability of solutions to be optimized for whatever dep= loyment scenario may apply in any specific case. Working out ways to optimize your particular deployment model seems to be y= our problem (with support from your suppliers - whoever they might be) and - it= seems to me - the burden of making sure that the standards we define allows optim= ization for that deployment falls on you (and them). Meanwhile, other providers and other vendors may seek to ensure that whatev= er we define allows at least some degree of optimization for their deployments= . This is the process. Is the architectural proposal Joel came up with sufficient as a starting po= int? -- Eric -----Original Message----- From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=20 Sent: Thursday, July 10, 2014 12:29 PM To: Eric Gray; Jim Guichard (jguichar); Ron Parker Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Importance: High Eric, > Load distribution is not the same as service function chaining and -=20 > while there may be problems to solve in this area - why would we=20 > assume that SFC is supposed to solve them? Because this is the fundamental problem in service chaining in virtualized = environments. =20 I would be cautious to leave it just to implementation because if fundament= als are wrong implementation might not be able to help. > I think SFC should be more concerned about ensuring that function=20 > chaining solutions do not preclude load distribution. How would you ensure it? >=20 > -- > Eric >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA=20 > H > Sent: Thursday, July 10, 2014 12:02 PM > To: Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > One of the main problems in "service chains" is how to implement a=20 > service that is conceptually one hop but scaled horizontally as 10 or=20 > 100 different VMs. > So, IMO, if we are not addressing this problem than what are we solving. >=20 > Maria >=20 > > -----Original Message----- > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > Sent: Wednesday, July 09, 2014 6:17 PM > > To: Ron Parker > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, > MARIA H; > > sfc@ietf.org > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > I should clarify that my statement was made as a personal opinion=20 > > and it is up to the WG to evaluate if there exists anything at the=20 > > architectural level that is new and therefore needs to be addressed. > > > > Sent from my iPhone > > > > > On Jul 9, 2014, at 6:01 PM, "Ron Parker" > > wrote: > > > > > > Jim, > > > > > > Respectfully, I'm not comfortable with that. While it is easy to sa= y that > > this is a layered problem and that load balancing belongs at a lower=20 > > level, it seems to me that load balancing of the service functions=20 > > (not load balancer as a service function) should be an explicit > consideration of the SFC > > architecture. I say this not only from a scale perspective, but also= with > > resiliency in mind. > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > > Sent: Wednesday, July 09, 2014 5:48 PM > > > To: Ron Parker > > > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; > > NAPIERALA, MARIA H > > > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > > > > > I would say that's implementation. > > > > > > Sent from my iPhone > > > > > >> On Jul 9, 2014, at 5:31 PM, "Ron Parker" > > wrote: > > >> > > >> Agreed. But is that in scope for SFC or out of scope for SFC? > > >> > > >> -----Original Message----- > > >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >> Sent: Wednesday, July 09, 2014 5:29 PM > > >> To: Ron Parker > > >> Cc: NAPIERALA, MARIA H; Joel M. Halpern; > > mohamed.boucadair@orange.com; > > >> sfc@ietf.org > > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >> > > >> Well of course not; in that case you load balance up a level=20 > > >> between > > those nodes and then locally. > > >> > > >> Sent from my iPhone > > >> > > >>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" > > wrote: > > >>> > > >>> Jim, > > >>> > > >>> There may not be a single node through which all of the=20 > > >>> instances can > > be reached (at some reasonable limit of L2 or L3 hops). > > >>> > > >>> Ron > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim=20 > > >>> Guichard > > >>> (jguichar) > > >>> Sent: Wednesday, July 09, 2014 5:12 PM > > >>> To: NAPIERALA, MARIA H > > >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > > >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >>> > > >>> At the node through which the 20 instances are reachable. IOW=20 > > >>> you > > don't have to individually address packets to each and every instance. > > >>> > > >>> Sent from my iPhone > > >>> > > >>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" > > wrote: > > >>>> > > >>>> Hi Jim, > > >>>> > > >>>> When you say "locally", where is it? > > >>>> > > >>>> Maria > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > > >>>>> Sent: Wednesday, July 09, 2014 5:06 PM > > >>>>> To: NAPIERALA, MARIA H > > >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; > sfc@ietf.org > > >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > > >>>>> > > >>>>> Hi Maria, > > >>>>> > > >>>>> Absolutely and categorically no! If you have 20 instances at=20 > > >>>>> each hop then you can choose to load balance among them=20 > > >>>>> locally resulting in exactly 4 paths. What Joel is saying is=20 > > >>>>> that if for some very odd and certainly not recommended reason=20 > > >>>>> you want to treat each instance separately then the=20 > > >>>>> architecture does not > > prevent it. > > >>>>> > > >>>>> Sent from my iPhone > > >>>>> > > >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" > > > > >>>>> wrote: > > >>>>> > > >>>>>>> I am saying that if the 20 virtual firewalls are deployed=20 > > >>>>>>> separately, then the service chaining infrastructure would=20 > > >>>>>>> treat them as such, and would use distinct service paths. > > >>>>>> > > >>>>>> If I have a 4 hop service chain with 20 instances at each=20 > > >>>>>> hop, then I have > > >>>>> to globally manage 160,000 service paths (for one chain)?=20 > > >>>>> Well, we have yet to see a solution that work this way and scales= .. > > >>>>>> > > >>>>>> Maria > > >>>>>> > > >>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: > > >>>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 > > >>>>>>>> instances > > >>>>>>> somewhere in the middle of a chain. Are you saying that you=20 > > >>>>>>> will decide (make a load balancing decision) at the entry to=20 > > >>>>>>> the chain which of those > > >>>>> 20 > > >>>>>>> firewalls will be used by a particular flow? > > >>>>>>>> > > >>>>>>>> Maria > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 > > >>>>>>>>> Halpern > > >>>>> Direct > > >>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM > > >>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; > > >>>>>>> sfc@ietf.org > > >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load=20 > > >>>>>>>>> Balancers > > >>>>>>>>> > > >>>>>>>>> The archtiecture allows for this local decision, while=20 > > >>>>>>>>> still having the global decision that is directing the traffi= c. > > >>>>>>>>> That is, the global decision directs the traffic to places=20 > > >>>>>>>>> in the network. Those places may be singular or clusters. > > >>>>>>>>> If they are clusters, those clusters can use any number of=20 > > >>>>>>>>> algorithms to distribute the traffic internally, without=20 > > >>>>>>>>> any effect on service chaining. (And yes, this can be=20 > > >>>>>>>>> done in such a way that return traffic, if delivered=20 > > >>>>>>>>> globally to the same place, can then be delivered to the=20 > > >>>>>>>>> right internal > > >>>>>>>>> state.) > > >>>>>>>>> > > >>>>>>>>> The definition of the service path is about how service=20 > > >>>>>>>>> chaining will direct the traffic. it is not about how the=20 > > >>>>>>>>> internal load balancing is doen, as there are MANY ways to=20 > > >>>>>>>>> do that, and they can give the same external interface. > > >>>>>>>>> > > >>>>>>>>> We could write the architecture pretending that it always=20 > > >>>>>>>>> addresses singular instances, but knowing that reality=20 > > >>>>>>>>> would allow load balanced clusters at those locations. =20 > > >>>>>>>>> But that would be a misleading architectural description=20 > > >>>>>>>>> and might be read to outlaw some solutions that fall=20 > > >>>>>>>>> within the goal the WG > > wishes to meet. > > >>>>>>>>> > > >>>>>>>>> Yours, > > >>>>>>>>> Joel > > >>>>>>>>> > > >>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: > > >>>>>>>>>>> [Med] I still disagree that an ordered list of locators=20 > > >>>>>>>>>>> can be > > >>>>>>> determined > > >>>>>>>>> in > > >>>>>>>>>>> advance for all deployments. I suggest that SFC=20 > > >>>>>>>>>>> forwarding be based > > >>>>>>> on > > >>>>>>>>> the > > >>>>>>>>>>> service chain itself (characterized as an order list of=20 > > >>>>>>>>>>> service function identifiers). This is more compliant=20 > > >>>>>>>>>>> with the > > LB constraints above: > > >>>>>>>>> deciding > > >>>>>>>>>>> which locator to use for a given flow will be a local=20 > > >>>>>>>>>>> decision not a centralized one. > > >>>>>>>>>> > > >>>>>>>>>> Absolutely. I cannot imagine how else it can be done. > > >>>>>>>>>> > > >>>>>>>>>> Maria > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> sfc mailing list > > >>>>>>>>> sfc@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> sfc mailing list > > >>>>>>>> sfc@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> sfc mailing list > > >>>>>> sfc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >> > > >> _______________________________________________ > > >> sfc mailing 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 From nobody Fri Jul 11 13:18: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 4B0C01B2D22 for ; Fri, 11 Jul 2014 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 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, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 YWIVEVc43g55 for ; Fri, 11 Jul 2014 13:17:49 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398721B2D1F for ; Fri, 11 Jul 2014 13:17:49 -0700 (PDT) Received: from mtaout-aaf02.mx.aol.com (mtaout-aaf02.mx.aol.com [172.26.127.98]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id 33FCE702921B2; Fri, 11 Jul 2014 16:17:48 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aaf02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id DB6A338000090; Fri, 11 Jul 2014 16:17:47 -0400 (EDT) Date: Fri, 11 Jul 2014 16:17:47 -0400 From: "mikebianc@aol.com" To: jmh@joelhalpern.com, Myo.Zarny@gs.com, jguichar@cisco.com, mn1921@att.com, Ron_Parker@affirmednetworks.com, sfc@ietf.org Message-ID: <511749097.3496.1405109867600.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <53C01227.9030909@joelhalpern.com> References: <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <790796536.3071.1405094577796.JavaMail.tomcat@mgs-aad01.mail.aol.com> <1236229119.3129.1405095908893.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53C01227.9030909@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3495_519811699.1405109867599" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405109868; bh=PLMAMpHLSp3RnEqGwzMsT//LG0XbEb5ygU+cUoih/Xw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=0cfQUxo5hUDyKWhqsM4iXFtt2Ww4DzneB57lG4cNrNjLm/Pe3tVGpJQJG+NQ7eitL Zk1BWhl+eAlY4//MmXkwJhHSSirAVhMBpwVYNREVuOOkn9F5cUP1LRrkwAFZzS7txj 7aXZK8Sty0t/2qiHHRetlVAJRhT0gZrGzjBSmzDw= x-aol-sid: 3039ac1a7f6253c0466b157b X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qHcAfgUYqX8hd1vxBUcHHbG84lg Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Jul 2014 20:17:58 -0000 ------=_Part_3495_519811699.1405109867599 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable yeah, that's pretty much the way I also understand the concepts. What I take exception to is the inconsistent terminology. =C2=A0Specificall= y, defining an SFP as a list of instances, but then calling something a ser= vice path identifier that does not necessarily reference a list of instance= s. =C2=A0It feels like there's a level of indirection missing. (fwiw, this = inconsistency is not necessarily present in the draft, but has been in this= thread). I have probably read over the merged arch draft way more than is probably h= ealthy. =C2=A0I have a few comments/questions: 1. I like the phrases: =C2=A0 "The SFC encapsulation provides explicit information used to identif= y the SFP" =C2=A0 and =C2=A0 "The SFF determines the appropriate SF the traffic should be forward= ed to via information contained in the SFC encapsulation" =C2=A0 because they allows for the encapsulation to include a path-id or ch= ain-id or whatever it may be (see other drafts). =C2=A0 It specifically does NOT dictate that the SFP-id or SFC-id be in the= encapsulation, only that something in it is used to figure out what to do = next.=C2=A0 2. In 4.3.1, the phrase, "and if needed forwarded to another SF associated = with that SFF". =C2=A0=C2=A0 =C2=A0Does this mean the next SF in the chain?= =C2=A0The next sentence says, "If there is another hop" which leads me to = ask, What is a hop? =C2=A0Is it a SF, SFI, or SFF? =C2=A0=C2=A0 =C2=A0Sound= s like a hop is an SFF. =C2=A0Or it the SFF as the "SFC next-hop" for an SF= is analagous to the router as the BGP next-hop for a prefix. 3. It seems that the SFP is created on-the-fly as needed by the classifier.= =C2=A0Does this introduce a race condition if the path-id is used in the e= ncapsulation such that the NF and SFF will not be able to perform the looku= p until they are informed of this new SFP? 4. Branching.=C2=A0 =C2=A0If "instantiation of the SFC results in the creat= ion of a Service Function Path (SFP)" and if a SF reclassifies and "alters = the service path, to SFP B", then does that mean that a new SFP is created = on-the-fly? 5. After exhaustively reading and re-reading the definitions, I believe tha= t the definition of SFP in the definitions section is completely inline wit= h the uses in most of the rest of the draft where the SFP is NOT a predeter= mined specific list of instances, but rather more generally "the instantiat= ion of an SFC".=C2=A0 =C2=A0However, the explanation of SFP in section 2.3 = seems to be in restrictive in comparison to the rest of the draft and in co= nflict with many of the comments in this email thread. > =C2=A0 When an SFC is instantiated into the network it is necessary to> = =C2=A0 select the specific instances of SFs that will be used, and to creat= e =C2=A0=C2=A0> =C2=A0 the service topology for that SFC using SF's network= locator. =C2=A0Thus,> =C2=A0 instantiation of the SFC results in the creat= ion of a Service> =C2=A0 Function Path (SFP) To me, this very clearly indicates that it is necessary to choose all SFIs = in the chain on instantiation, thus eliminating the possibility of having a= more distributed or dynamic distribution to SFIs without branching. 6. Item 4.8.3 (referenced below) seems in conflict with 2.3 (referenced abo= ve): > 4.8. SFC Control Plane > 3. =C2=A0Selection of specific SF instances for a requested SFC, either > =C2=A0 =C2=A0 statically (using specific SF instances) or dynamically (us= ing > =C2=A0 =C2=A0 service explicit SF instances at the time of delivering tra= ffic > =C2=A0 =C2=A0 to the SF).(this text is also repeated in the 4.8 leading p= aragraph) From: jmh@joelhalpern.com To: mikebianc@aol.com,,,,, Sent: Friday, July 11, 2014 Subject: Re: [sfc] Service Chains, Paths, and Load Balancers The way the draft uses the terms, and the way most discussions outside=20 the IETF SFC working group use the term, a service function chain is=20 something that you would discuss a policy about. Certain traffic from=20 certain users is supposed to receive a certain sequence of services, the=20 service chain. At the policy level, that does not care where in the network that is=20 delivered. So as to allow control a level of influence, and to have=20 flexibility to have multiple representations in the network of that=20 policy construct, we have the intermediate notion of service function=20 path. If the control system does not need to apply any influence, then=20 it uses one service path for the service chain. If it needs a level of=20 control, it instantiates a suitable number of service paths in the=20 control system, and rules for how those are used. Then, the mapping in the SFF is based on that path, so as to enable the=20 influence of the control system. While still allowing several other=20 layers of traffic management as discussed. Yours, Joel On 7/11/14, 12:25 PM, mikebianc@aol.com wrote: > I meant as a design principle when everything is working. I was trying > to come up with a concise example of configuring a network such that it > does not work that would be analogous to configuring SFC such that "that > remote SFF has the necessary forwarding logic to reach the next-next-SF". > > > > > > ------------------------------------------------------------------------ > * From: *Myo.Zarny@gs.com> *To:> *'mikebianc@aol.com','jguichar@cisco.com','mn1921@att.com','jmh@joelhalpern.com','Ron_Parker@affirme= dnetworks.com','sfc@ietf.org'> *Sent: *Friday, July 11, 2014> *Subject: *RE: [sfc] Service Chains, Path= s, and Load Balancers>> I don=E2=80=99t understand. (I=E2=80=99m sure I=E2= =80=99m misunderstanding=E2=80=A6)>> Your backend servers could go down, be= unreachable or be unable to> server more.>> Route health injection (RHI) i= s a perfectly fine, accepted, way of> indicating the health of the backend = services to the network. You=E2=80=99re not> saying that=E2=80=99s wrong, a= re you?>> **>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of> *mik= ebianc@aol.com > *Sent:* 11 July 2014 12:03 PM> *= To:* jguichar@cisco.com ; mn1921@att.com> ; jmh@joelhalpern.com> ; Ron_P= arker@affirmednetworks.com> ; sfc@i= etf.org > *Subject:* Re: [sfc] Service Chains, Paths, = and Load Balancers>> heh. well, if it did not, then you should not do it li= ke that. e.g. I'm> not going to configure real servers on a server load bal= ancer that are> not reachable. e.g. I'm not going to configure my BGP to an= nounce> prefixes for which I cannot provide connectivity. If you do things = like> that, then you are doing it wrong.>>>> ------------------------------= ------------------------------------------>> *From: *jguichar@cisco.com >> *To: *N= APIERALA, MARIA H>,Joel M.> Halpern<= jmh@joelhalpern.com >,Ron> Parker >,sfc@ietf.org>= >> *Sent: *Friday,= July 11, 2014> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balanc= ers>> Then I misunderstand the proposal ;-) .. However, it seems to me that= if> you allow an SFF to make a decision as to which remote SFF it will use= for> a given flow to reach the next SF within the chain then you better ma= ke> sure that that remote SFF has the necessary forwarding logic to reach t= he> next-next-SF for the chain as otherwise you are in deep trouble.>> On 7= /11/14, 9:48 AM, "NAPIERALA, MARIA H" > wrote:>> >Absolutely not. Service chains can be instantiated only in = relevant SFFs> >when they "arrive".> >> >> -----Original Message-----> = >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard> >>= (jguichar)> >> Sent: Friday, July 11, 2014 9:27 AM> >> To: Joel M. Halper= n; Ron Parker; sfc@ietf.org > >> Subject: Re: [sfc] S= ervice Chains, Paths, and Load Balancers> >>> >> Well I think it is even = worse than that if I have understood the> >>proposal> >> correctly as it = would require full knowledge of every single SF within> >>the> >> entire = SFC domain at every single SFF as there is no way to know a> >>priori> >>= which SFC=C2=B9s a given SFF will need to service at any given point in ti= me.> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" = > wrote:> >>> >> >Ron, thinking about this, = I realized another major problem with the> >>your> >> >proposal as I unde= rstand it. (And I readily admit I may not understand> >> >it.)> >> >> >>= >The proposal has each SFF serve as the load balancer for the next> >> >s= ervice function that follows it (not the one it delivers to), in every> >>= >service chain that goes through it.> >> >> >> >Since it has to be able = to work with all services, that means that> >>every> >> >SFF would have t= o be a full, flow sensitive and stateful load balancer.> >> >I ahve no pro= blem if some SFF are flow sensitive, and / or stateful.> >> >But having th= e architecture require that every SFF be a full, flow> >> >sensitive, stat= eful, load balancer seems to me to be an acceptable> >> >imposition.> >> = >> >> >Yours,> >> >Joel> >> >> >> >On 7/10/14, 10:06 PM, Joel M. Halper= n wrote:> >> >> Part of my personal view is that I am trying to make this = work> >>sensibly> >> >> in a more orchestrated environment. I expect that= the service> >> >> functions, and over time probably the SFF capabilities= , will be> >> >> orchestrated and installed. I expect the service chains t= o be> >>driven by> >> >> BSS tools that define offerings to clients, and = enable self-selection> >> >> from these. I expect service paths to be heav= ily policy drive.> >> >>> >> >> I can see how to make all of that work in= an archtiecture driven by> >> >> initial classification to described serv= ice paths. It is harder to> >>see> >> >> how to make it work (but it can = be done) when we allow more> >> dynamicity> >> >> in the network behavior= .> >> >>> >> >> Having said that, most of that perspective I described is= outside of> >>the> >> >> scope of the working group. it is not something= we are tasked to> >>agree> >> >>on.> >> >> So I do not claim that visio= n means we have to do it a certain way.> >>it> >> >> is just the perspect= ive that drives my preferences.> >> >>> >> >> Yours,> >> >> Joel> >> >>= > >> >> On 7/10/14, 9:58 PM, Ian Smith wrote:> >> >>>> For me, the amount= of information about service instances that> >>needs> >> >>>>to> >> >>>= > be widely distributed and maintained, potentially even across data> >> >= >>> centers within an administrative scope, is large enough and complex> >= > >>>> enough that trying to get that into each SFF seems like a difficult>= >> >>>> architecture to realize.> >> >>>> >> >>> I'm curious as to why = that is more complicated than dynamic routing,> >> >>> hyper-scale data ce= nter orchestration, or DNS, all of which are> >>bigger> >> >>> problems t= hat have been profitably and stably implemented?> >> >>>> >> >>> It also = seems that if it really is more complicated, that is a good> >> >>> sign t= hat it is too complicated.> >> >>>> >> >>> ______________________________= __________> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com> ]> >> >>> Sent: Thursday, July 10, 2014 9:45 PM> >> >>> = To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com> ; Ian Smith;> >> >>> sfc@ietf.org > >> >>> Su= bject: Re: [sfc] Service Chains, Paths, and Load Balancers> >> >>>> >> >>= > This is an architectural issue. And one that I would prefer we> >> >>>ac= tually> >> >>> decide, rather than trying to allow all possible implementa= tions.> >> >>> Because it does have a major effect on the control requirem= ents and> >> the> >> >>> functionality of SFFs.> >> >>>> >> >>> For me,= the amount of information about service instances that needs> >> to> >> = >>> be widely distributed and maintained, potentially even across data> >>= >>> centers within an administrative scope, is large enough and complex> = >> >>> enough that trying to get that into each SFF seems like a difficult>= >> >>> architecture to realize.> >> >>>> >> >>> Yours,> >> >>> Joel> = >> >>>> >> >>> But it is a fair question.> >> >>>> >> >>> On 7/10/14, 9:= 38 PM, Ron Parker wrote:> >> >>>> This is the crux of my issue. Is the end= to end selection of> >> >>>> (top-level) instances performed centrally (p= erhaps by the> >>classifier)> >> >>>> or hop-by-hop (perhaps by the class= ifier and subsequently the> >>SFFs)?> >> >>>> Such selection is not equiv= alent to reclassification. And surely,> >> >>>> this is an architectural i= ssue and not relegated to> >> >>>> "implementation".> >> >>>>> >> >>>> M= y own view is to favor the distributed approach even though a> >> >>>> gre= ater amount of data (chain definitions and perhaps local> >>selection> >>= >>>> policy) is required at those distributed decision points. This> >> >= >>> approach does not require an end-to-end path id at all. My> >> >>>> ra= tionale for favoring this approach is primarily driven by> >>increased> >= > >>>> resiliency over the global path id approach. With a global path> >>= id> >> >>>> approach, consider failure of an instance and needing to alter= the> >> >>>> global path ID table for each and every affected end-to-end = path.> >> >>>>> >> >>>> Ron> >> >>>>> >> >>>> _________________________= _______________ From: sfc> >> >>>> [sfc-bounces@ietf.org ] on behalf> of Joel Halpern Direct> >> >>>> [jmh.direct@joelh= alpern.com> ] Sent: Thursday, July 10, 2= 014 6:15 PM> >> >>>> To: mikebianc@aol.com ;> I.= Smith@F5.com ; sfc@ietf.org> S= ubject: Re:> >> >>>> [sfc] Service Chains, Paths, and Load Balancers> >> = >>>>> >> >>>> The way the architecture models the case of SF1 needing to> = >>influence> >> >>>> the chain is that one would do reclassification at t= he exit from> >> >>>> SF1.> >> >>>>> >> >>>> Part of the goal is to keep= the different functions logically> >> >>>> separate so that solutions can= clearly describe how they choose to> >> >>>> compose them for "service" d= elivery.> >> >>>>> >> >>>> Yours, Joel> >> >>>>> >> >>>> On 7/10/14, 6:= 10 PM, mikebianc@aol.com> wrote:> >> >>>>> I do= n't see anything in the arch draft that suggests any sort of> >> >>>>> lim= it. However, it does seem to indicate that the entire path (all> >> >>>>> = SFIs) must be chosen at SFC instantiation. I believe this means> >> >>>>> = either at the classifier or maybe the classifier chooses a SF> >>Chain> >= > >>>>> and the NF or at the latest the first SFF. In any case, the> >> >>= >>> language does seem to prohibit a more dynamic SFP where SFI(n) is> >> = >>>>> determined at the SFI(n-1) hop. According to the draft, this> >> >>>= >> behavior would be considered "branching" to a new SFP as opposed> >> to= > >> >>>>> choosing and then forwarding to the selected instance of the> = >> >>>>> next-hop of the current SFC.> >> >>>>>> >> >>>>> draft-merged-sf= c-architecture-00:> >> >>>>>> When an SFC is instantiated into the network= it is necessary to> >> >>>>>> select the specific instances of SFs that w= ill be used, and to> >> >>>>>> create the service topology for that SFC us= ing SF's network> >> >>>>>> locator. Thus, instantiation of the SFC result= s in the creation> >> >>>>>> of a Service Function Path (SFP) and is used = for forwarding> >> >>>>>> packets through the SFC. In other words, an SFP = is the> >> >>>>>> instantiation of the defined SFC.> >> >>>>>>> >> >>>>>= > The SFC architecture supports reclassification (or non-initial> >> >>>>>= > classification) as well. As packets traverse an SFP,> >> >>>>>> reclassi= fication may occur - typically performed by a> >> >>>>>> classification fu= nction co-resident with a service function.> >> >>>>>> Reclassification ma= y result in the selection of a new SFP, an> >> >>>>>> update of the associ= ated metadata, or both. This is referred to> >> >>>>>> as "branching".> >= > >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >>> >>>>>>>--------------------= ------------------------------------------------> >>>>>>>--> >> >>>>>--> = >> >>>>>> >> >>>>>> >> >>>>>> >> >>> *From: *I.Smith@F5.com >> >> >>>>> *To: *Joel Halpe= rn Direct >,= Joel M.> >> >>>>>> >> >>>>>Halpern >,huang@sce.carleton.ca> >> carleton.> >> >>>>>ca>,sfc@ietf.org >> >> >>>>>> >> >>>>>> >= > >>>>>> >> >>> *Sent: *Thursday, July 10, 2014> >> >>>>> *Subject: *Re: = [sfc] Service Chains, Paths, and Load Balancers> >> >>>>>> >> >>>>> Actua= lly, I think I am disagreeing.> >> >>>>>> >> >>>>> If the possibility of = medium-scale deployments (and that is what> >> >>>>> 16 million flows is i= n my world) of service chains is preconceived> >> >>>>> as an absurd idea,= then the architecture burdened with that> >> >>>>> preconception.> >> >>= >>>> >> >>>>> There has to be some point of aim, some degree of aspiration= to> >> >>>>> scale that is appropriate for the lifespan of the architectu= re -> >> >>>>> you don't have to know what it is, but by saying that an ar= bitrary> >> >>>>> number is "too far", you're creating - even if it isn't>= >>intentional> >> >>>>> - a limit that influences decisions that have la= sting impacts> >> >>>>> regarding scale-out, failure mitigation, elasticit= y, address> >> >>>>> space... all kinds of things. That is a problem I'm n= ot> >> >>>>> particularly eager to deal with.> >> >>>>>> >> >>>>>> >> >= >>>>> >> >>>>>> >> >>>>> ________________________________________> >> >>= >>>> >> >>>>>> >> >>>>> From: Joel Halpern Direct [jmh.direct@joelhalpern= .com> ] Sent:> >> >>>>> Thursday, July = 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;> >> >>>>> huang@sce.carle= ton.ca ;> sfc@ietf.org = Subject: Re: [sfc] Service> >> >>>>> Chains, Paths, and Load Balancers> >= > >>>>>> >> >>>>> Ian, I don't think you disagree with me at all in this r= egard. I> >>am> >> >>>>> not requesting the the architecture or the solut= ion prohibit> >> >>>>> deployments in the specific fashion. I am objecting= to Huang's> >> >>>>> reading of my note as saying that such deployments a= re required> >> >>>>> they by the archtiecture.> >> >>>>>> >> >>>>> As I= have said repeatedly, I am not trying to prohibit such> >> >>>>> things. = Whether they are a good idea or not depends upon many> >> >>>>> factors ou= tside of the scope of the WG. I happen to think that> >>they> >> >>>>> ar= e usually a bad idea.> >> >>>>>> >> >>>>> But the archtiecture si careful= ly avoiding attempting to know what> >> >>>>> is and is not eployable.> >= > >>>>>> >> >>>>> Yours, Joel> >> >>>>>> >> >>>>> On 7/10/14, 5:01 PM, I= an Smith wrote:> >> >>>>>> I disagree.> >> >>>>>>> >> >>>>>> We routinel= y have stateful devices that manage tens of millions> >> >>>>>> of> >> >>= >>> concurrent flows in both access network and data center> >> >>>>> envi= ronments today. You can't seriously believe that in the> >> >>>>> Cloud/IP= v6/Mobility/Web2.0/IoT world of tomorrow you are only> >> going> >> >>>>>= to have small numbers of service chains with equally small numbers> >> >>= >>> of active service paths?> >> >>>>>>> >> >>>>>> Your sounds too much l= ike "no one will ever need more than 64K"> >> >>>>>> for> >> >>>>> comfor= t.> >> >>>>>>> >> >>>>>>> >> >>>>>> ____________________________________= ____ From: sfc> >> >>>>>> [sfc-bounces@ietf.org ] on> behalf of Joel M. Halpern> >> >>>>> [jmh@joelhalpern.com ]> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To:= > huang@sce.carleton.ca ;> >> >>>>>> sfc@iet= f.org Subject: Re: [sfc] Service> Chains, Paths, and = Load> >> >>>>>> Balancers> >> >>>>>>> >> >>>>>> No, it will mean that if= someone tries to deploy the archtieture> >> >>>>>> particularly badly, th= ey will exceed the limits of their> >> >>>>>> devices. The architecture do= es not require such absurd use of> >> >>>>>> service paths. Since I can no= t figure out how to write> >> >>>>>> architectural words to prohibit it, t= he architecture does permit> >> >>>>>> such abuse.> >> >>>>>>> >> >>>>>>= Please do not read my saying that the archtiecture permits> >> >>>>>> som= ething as saying it is either deisred or required by the work.> >> >>>>>> = It isn't.> >> >>>>>>> >> >>>>>> Yours, Joel> >> >>>>>>> >> >>>>>> On 7/= 10/14, 4:36 PM, Changcheng Huang wrote:> >> >>>>>>> If you need to support= 100 service chains, it will mean> >> >>>>>>> 16,000,000 paths. That is la= rger than the routing table of a> >> >>>>>>> core router.> >> >>>>>>>> >= > >>>>>>> Chang> >> >>>>>>>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. H= alpern wrote:> >> >>>>>>>> The architecture allows a range of deployments,= from 1> >> >>>>>>>> service path to 160000 service paths. I would hope th= at> >> >>>>>>>> operators are prepared for the complexities if they choose= to> >> >>>>>>>> avoid any use of local load balancing and in stead provis= ion> >> >>>>>>>> 160,000 service paths.> >> >>>>>>>>> >> >>>>>>>> Yours,= Joel> >> >>>>>>>>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H w= rote:> >> >>>>>>>>> Paul,> >> >>>>>>>>>> >> >>>>>>>>> How many path iden= tifiers there will be for a 4 hop service> >> >>>>>>>>> chain with 20 inst= ances at each hop?> >> >>>>>>>>>> >> >>>>>>>>> Maria> >> >>>>>>>>>> >> = >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of> >> >>>>>= >>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03> >> >>>>>>>>= > PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com> ;> >> >>>>>>>>> mohamed.boucadair@orange.com> ; sfc@ietf.org ;> >> >>>>>>>>> mikebianc@ao= l.com *Subject:*> Re: [sfc] Service Chains,> >>= >>>>>>>>> Paths, and Load Balancers> >> >>>>>>>>>> >> >>>>>>>>> Lucy,> = >> >>>>>>>>>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives = the> >> >>>>>>>>> forwarding. I=C2=B9d> >> >>>>> make> >> >>>>>>>>> the = minor change: the path identifier can be used to derive> >> >>>>>>>>> the = needed forwarding and associated transport.> >> >>>>>>>>>> >> >>>>>>>>> I= t is _not_ the transport, but rather is used to simply> >> >>>>>>>>> ident= ify the service path (or graph) that packets must> >> >>>>>>>>> traverse. = By having a path identifier, the exact> >> >>>>>>>>> indirection that peop= le seem to be asking for on this> >> >>>>>>>>> thread can be simply be imp= lemented. The path identifier> >> >>>>>>>>> provides nothing more than a l= ookup, that lookup can result> >> >>>>>>>>> in a one or more (equal or wei= ghted) transport next> >> >>>>>>>>> hop(s).> >> >>>>>>>>>> >> >>>>>>>>> = Paul> >> >>>>>>>>>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>= >> >>>>>>>>> >>> >> >>>>>>>>> wro= te:> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> Agree. The = arch. doc should not mandate only use of the> >> >>>>>>>>> service path id= entifier to drive the forwarding actions.> >> >>>>>>>>>> >> >>>>>>>>> Luc= y> >> >>>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On= Behalf> >> >>>>>>>>> Of*mohamed.boucadair@orange.com> > >> >>>>>>>>> = *Sent:*Thursday,> >> July> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@a= ol.com> > >> >>>>>>>>> ;jmh@joelhalpern.com> > >> >>>>>>>>> ;sfc@ietf.org> > >> >>>>>>>>> *Subject:*Re: [sfc] Service Chains,> >> >>>>>>>>> Paths= , and Load Balancers> >> >>>>>>>>>> >> >>>>>>>>> Re-,> >> >>>>>>>>>> >>= >>>>>>>>> The merged draft calls out explicitly a service path> >> >>>>>>= >>> identifier. I object to use that identifier to derive> >> >>>>>>>>> fo= rwarding actions.> >> >>>>>>>>>> >> >>>>>>>>> Requiring a SFC system to h= ave the full knowledge of every> >> >>>>> available SFC> >> >>>>>>>>> for= warding paths within an SFC-enabled domain is not> >> >>>>> required/justi= fied> >> >>>>>>>>> nor possible in various deployment contexts.> >> >>>>>= >>>>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of> >>= >>>>>>>>> information> >> >>>>> that will> >> >>>>>>>>> be present in al= l deployments: that is the one required to> >> >>>>>>>>> structure a servi= ce chain. How that information is used to> >> >>>>>>>>> infer forwarding> = >> >>>>> actions> >> >>>>>>>>> is a solution-oriented discussion.> >> >>= >>>>>>>> >> >>>>>>>>> Cheers,> >> >>>>>>>>>> >> >>>>>>>>> Med> >> >>>>>= >>>>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part> >>= >>>>> de*mikebianc@aol.com > >> >>>>>>>>> *Envoy=C3=A9 :*mercredi 9 juillet> >> >>>>>>>>> 2= 014 22:03 *=C3=80 :*jmh@joelhalpern.com> > >> = >>>>>>>>> ;sfc@ietf.org> >= >> >>>>>>>>> *Objet :*Re: [sfc] Service Chains,> >= > >>>>>>>>> Paths, and Load Balancers> >> >>>>>>>>>> >> >>>>>>>>> Is anyo= ne still questioning the difference between SF Chain> >> >>>>>>>>> and SF>= >> >>>>> Path?> >> >>>>>>>>> Other than clarifying the definition so tha= t it's clear to> >> >>>>> those not> >> >>>>>>>>> familiar with the draft= , it seems that everyone agrees on> >> >>>>>>>>> these terms.> >> >>>>>>>= >>> >> >>>>>>>>> To me, the one point that is still unclear is whether it = is> >> >>>>>>>>> the intent of this draft to ultimately specify what the I= D> >> >>>>>>>>> of the SFC Header> >> >>>>> should> >> >>>>>>>>> referen= ce (the chain or the path), or if this draft simply> >> >>>>>>>>> intends = to leave that ambiguous, allowing other drafts to> >> >>>>>>>>> dictate th= e mechanisms for forwarding based on chain or> >> >>>>>>>>> path and the c= hoice of chain or> >> >>>>> path to> >> >>>>>>>>> be negotiated in the co= ntrol-plane.> >> >>>>>>>>>> >> >>>>>>>>> If the latter (ambiguous), then = the draft would have> >> >>>>>>>>> require that both SFP and SFC be suppor= ted (or make one> >> >>>>>>>>> required and the other optional) to avoid s= ome vendors only> >> >>>>>>>>> supporting SFP and others only supporting S= FC.> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>> >>> >>>>>>>----------------= ----------------------------------------------------> >>>>>>>--> >> >>>>>= --> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>>> >> >>>>>>>>> *From:*jmh@= joelhalpern.com> >> >>>>>>>>>> >> >> >>>>>>>>> *To:*sfc@ietf.org >> >>>>>>>>>> > *Sent:*Tuesday, July> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Servic= e Chains, Paths, and Load> >> >>>>>>>>> Balancers> >> >>>>>>>>>> >> >>>>= >>>>> I have been trying to figure out how to clearly answer a> >> >>>>>>>= >> number of comments that have been made about the proposed> >> >>>>>>>>>= merged archtiecture draft. Assuming we can get working> >> >>>>>>>>> grou= p agreement on the intent, we will work to improve the> >> >>>>>>>>> wordi= ng so that readers who have not participated in the WG> >> >>>>>>>>> discu= ssion will understnd it the way the> >> >>>>> working> >> >>>>>>>>> group= intends.> >> >>>>>>>>>> >> >>>>>>>>> But what do we intend? I will try t= o explain my personal> >> >>>>>>>>> view, and see if that helps.> >> >>>>= >>>>>> >> >>>>>>>>> In this regard, it is important to keep in mind that w= hat> >> >>>>>>>>> we are defining is the data plane architecture. We are n= ot> >> >>>>>>>>> attempting to define the architecture for the entire> >>= >>>>>>>>> solution for service chaining. That would encompass> >> >>>>>>>= >> OSS/BSS, various control and policy functions, virtual> >> >>>>>>>>> ma= chine and image management, and many other aspects.> >> >>>>>>>>>> >> >>>= >>>>>> As a result there are many things which clearly need to> >> >>>>>>>= >> exist in the larger system, but which are dealt with above> >> >>>>>>>>= > where we are> >> >>>>> functioning,> >> >>>>>>>>> and are not directly = required by the work we are doing.> >> >>>>>>>>>> >> >>>>>>>>> In order t= o get to service chain vs service path, as I> >> >>>>>>>>> understand> >>= >>>>> them,> >> >>>>>>>>> I need to first discuss load balancing. There a= re at least> >> >>>>>>>>> three different ways that load balancing can and= will> >> >>>>>>>>> interact with service chaining. There probably are mor= e.> >> >>>>>>>>> The point of the archtiecture is to permit all of these,>= >> >>>>>>>>> but not to mandate that any particular kind> >> >>>>> be us= ed> >> >>>>>>>>> in any solution.> >> >>>>>>>>>> >> >>>>>>>>> 1) Load ba= lancing as a service provided to the end user.> >> >>>>>>>>> This is a ser= vice function. It receives user packets, and> >> >>>>>>>>> modifies them (= or> >> >>>>> marks> >> >>>>>>>>> them, or ...) so as to choose an end use= r service instance> >> >>>>>>>>> to receive the users packet. This is an i= mportant service> >> >>>>>>>>> function to be able to include in service c= haining. It's> >> >>>>>>>>> behavior may affect requirements on how servic= e chaining is> >> >>>>>>>>> done. But it has very little impact on the arc= htiecture.> >> >>>>>>>>> From an architectural pe3rspective it is simply a= > >> >>>>> service> >> >>>>>>>>> function which may modify the underlying= packet.> >> >>>>>>>>>> >> >>>>>>>>> 2) There is internal load balancing.= That is, one can have> >> >>>>>>>>> what> >> >>>>> appears> >> >>>>>>>>= > to the service chaining architecture as a single point of> >> >>>>>>>>> = contact> >> >>>>> for a> >> >>>>>>>>> specific service function, but is a= ctually delivered by a> >> >>>>> collection of> >> >>>>>>>>> virtual or p= hysical machines, possibly including one or> >> >>>>>>>>> several load bal= ancers (for example using VRRP-like> >> >>>>>>>>> techniques to share a MA= C address.) mostly, this is> >> >>>>>>>>> invisible to the service chainin= g data plane mechanisms. It> >> >>>>>>>>> is likely that it is visible to = various control mechanisms,> >> >>>>>>>>> such as those responsible for sc= ale-in, scale-out, and vm> >> >>>>>>>>> instantiation. The architectural i= mpact of permitting this> >> >>>>>>>>> is largely that we need to be caref= ul that our terminology> >> >>>>>>>>> does not lead> >> >>>>> readers to>= >> >>>>>>>>> think we are prohibiting it.> >> >>>>>>>>>> >> >>>>>>>>> 3= ) There can also be load balancing done by selecting> >> >>>>>>>>> packet = paths for the service chaining that direct traffic> >> >>>>>>>>> to differ= ent places. We would not want to require that a> >> >>>>>>>>> given servic= e function appear at only one place in the> >> >>>>>>>>> network.> >> >>>= >>>>>>> >> >>>>>>>>> It is of course the case that these may be combined. = I tend> >> >>>>>>>>> to> >> >>>>> refer to> >> >>>>>>>>> the collection = of entities that appear to service chaining> >> >>>>>>>>> as a single poin= t as a cluster. Not because cluster is a> >> >>>>>>>>> good term. But beca= use I do not have another one. Thus, the> >> >>>>>>>>> point of type 3 loa= d balancing> >> >>>>> is to> >> >>>>>>>>> direct different subsets of tra= ffic to different singular> >> >>>>>>>>> or clustered service functions in= different places in the> >> >>>>>>>>> network.> >> >>>>>>>>>> >> >>>>>>= >>> Now with that said, what do I mean when I talk about> >> >>>>>>>>> ser= vice chain and service path/ Service chain is a sequence> >> >>>>>>>>> of = logical functions to be applied to a subset of packets.> >> >>>>>>>>> It i= s equivalent of saying that some subset of traffic is> >> >>>>>>>>> to get= DPI, charging, content inspection, and firewall> >> >>>>>>>>> while a dif= ferent subset is to go directly to the cache> >> >>>>> without> >> >>>>>>= >>> visiting any other service functions.> >> >>>>>>>>>> >> >>>>>>>>> Tha= t is not enough information to direct the packets. A> >> >>>>>>>>> service= path is, in some fashion, a sequence of locations> >> >>>>>>>>> in the ne= twork. Those locations will be singular or> >> >>>>>>>>> clustered service= function delivery locations. They may be> >> >>>>>>>>> addressed by IP ad= dress. They may be addressed as ports on> >> >>>>>>>>> an SFF. There are m= any different ways that the locations> >> >>>>>>>>> may be known to the se= rvice chaining infrastructure and the> >> >>>>>>>>> transport.> >> >>>>>>= >>>> >> >>>>>>>>>> From the point of view of the work of the SFC group, we= > >> >>>>>>>>>> need to be> >> >>>>>>>>> able to talk about the high leve= l abstraction, the service> >> >>>>>>>>> chain, which drives the forwardin= g. And we need to talk> >> >>>>>>>>> about the actual data path packets wi= ll take in the> >> >>>>>>>>> network.> >> >>>>>>>>>> >> >>>>>>>>> Severa= l of the comments have said "but the whole path may> >> >>>>>>>>> not be k= nown at the front." This architecture deals with> >> >>>>>>>>> that issue = in two ways. First, as noted in item (2) on load> >> >>>>>>>>> balancers a= bove, there can be decisions and behaviors which> >> >>>>>>>>> are invisib= le to the service chaining mechanisms (in much> >> >>>>>>>>> the same way = that bridging within a LAN is largely> >> >>>>>>>>> invisible to routing b= etween LANs.) The other provision we> >> >>>>>>>>> make is> >> >>>>> that= > >> >>>>>>>>> reclassification can be done in mid-chain when necessary.> = >> >>>>>>>>> That will direct packets to a new chain. Based on> >> >>>>>>= >>> information available at the re-classification point.> >> >>>>>>>>>> = >> >>>>>>>>> I hope that this helps explain what we are after. If it> >> >= >>>>>>>> does, and if the intent is acceptable to the working group,> >> >= >>>>>>>> we can figure out what additional words are needed to> >> >>>>>>>= >> convey this. If the working group disagree with the intent,> >> >>>>>>>= >> then we will of course adjust to match the working group> >> >>>>>>>>> = agreements. If this is still unclear, I am not sure what to> >> >>>>>>>>> = try next.> >> >>>>>>>>>> >> >>>>>>>>> Yours, Joel> >> >>>>>>>>>> >> >>>= >>>>>> _______________________________________________ sfc> >> mailing> >= > >>>>>>>>> list sfc@ietf.org > = >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc> >> >>>>>>>>>> >>= >>>>>>>>> _______________________________________________ sfc> >> mailing= > >> >>>>>>>>> list sfc@ietf.org > >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc> >> >>>>>>>>>>= >> >>>>>>>>> >> >>>>>>>> _______________________________________________= sfc> >> mailing> >> >>>>>>>> list sfc@ietf.org > ht= tps://www.ietf.org/mailman/listinfo/sfc> >> >>>>>>>>> >> >>>>>>>> >> >>>= >>>> _______________________________________________ sfc> >> mailing> >> = >>>>>>> list sfc@ietf.org > https://www.ietf.org/mailm= an/listinfo/sfc> >> >>>>>>>> >> >>>>>>> >> >>>>>> ______________________= _________________________ sfc mailing> >> list> >> >>>>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc> >> >>>>>>>= >> >>>>>> >> >>>>> _______________________________________________ sfc m= ailing> >> list> >> >>>>> sfc@ietf.org > https://www= .ietf.org/mailman/listinfo/sfc> >> >>>>> >> >>>> ________________________= _______________________ sfc mailing> >> list> >> >>>> sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc> >> >>>>> >> >= >>> _______________________________________________ sfc mailing> >> list> = >> >>>> sfc@ietf.org > https://www.ietf.org/mailman/l= istinfo/sfc> >> >>>>> >> >>>> >> >>> >> >> ____________________________= ___________________> >> >> sfc mailing list> >> >> sfc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/sfc> >> >>> >>= >> >> >_______________________________________________> >> >sfc mailing = list> >> >sfc@ietf.org > >> >https://www.ietf.org/ma= ilman/listinfo/sfc> >>> >> ______________________________________________= _> >> sfc mailing list> >> sfc@ietf.org > >> https:= //www.ietf.org/mailman/listinfo/sfc>> _____________________________________= __________> sfc mailing list> sfc@ietf.org > https://w= ww.ietf.org/mailman/listinfo/sfc>>>> ______________________________________= _________> sfc mailing list> sfc@ietf.org> https://www.ietf.org/mailman/lis= tinfo/sfc> ------=_Part_3495_519811699.1405109867599 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
yeah= , that's pretty much the way I also understand the concepts.

What I take exception to is the inconsist= ent terminology.  Specifically, defining an SFP as a list of instances= , but then calling something a service path identifier that does not necess= arily reference a list of instances.  It feels like there's a level of= indirection missing. (fwiw, this inconsistency is not necessarily present = in the draft, but has been in this thread).

I have probably read over the merged arch draft way more t= han is probably healthy.  I have a few comments/questions:
<= font face=3D"courier new, monospace">1. I like the phrases:
  "The SFC encapsulation provi= des explicit information used to identify the SFP"
  and
  "The SFF determines the appropriate SF the tra= ffic should be forwarded to via information contained in the SFC encapsulat= ion"
  because = they allows for the encapsulation to include a path-id or chain-id or whate= ver it may be (see other drafts).
  It specifically does NOT dictate that the SFP-id or SF= C-id be in the encapsulation, only that something in it is used to figure o= ut what to do next. 

2. In 4.3= .1, the phrase, "and if needed forwarded to another SF associated with that= SFF".  
   Does this mean the next SF in the chain?  The next s= entence says, "If there is another hop" which leads me to ask, What is a ho= p?  Is it a SF, SFI, or SFF?  
   Sounds like a hop is an SFF.  Or= it the SFF as the "SFC next-hop" for an SF is analagous to the router as t= he BGP next-hop for a prefix.

3. It seems that the SFP is created on-the-fly as needed by the classifi= er.  Does this introduce a race condition if the path-id is used in th= e encapsulation such that the NF and SFF will not be able to perform the lo= okup until they are informed of this new SFP?

4. Branching.
   If "instantiation of the SFC results in the c= reation of a Service Function Path (SFP)" and if a SF reclassifies and "alt= ers the service path, to SFP B", then does that mean that a new SFP is crea= ted on-the-fly?
=
5. After exhaustively reading and re-reading the definitions, = I believe that the definition of SFP in the definitions section is complete= ly inline with the uses in most of the rest of the draft where the SFP is N= OT a predetermined specific list of instances, but rather more generally "t= he instantiation of an SFC".
   However, the explanation of SFP in section 2.3 se= ems to be in restrictive in comparison to the rest of the draft and in conf= lict with many of the comments in this email thread.

>   When an SFC is instantiated in= to the network it is necessary to
>   select the specific instances of SFs that wil= l be used, and to create   
>   the service topology for that SFC using S= F's network locator.  Thus,
>   instantiation of the SFC results in the creati= on of a Service
= >   Function Path (SFP)

To me, this very clearly indicates that it is necessary to choose all = SFIs in the chain on instantiation, thus eliminating the possibility of hav= ing a more distributed or dynamic distribution to SFIs without branching.

6. Item 4.8.3 (referenced be= low) seems in conflict with 2.3 (referenced above):
> 4.8. SFC Control Plane
= > 3.  Selection of specific S= F instances for a requested SFC, either
>     statically (using specific SF instan= ces) or dynamically (using
>     service explicit SF instances at the time of deli= vering traffic
> =     to the SF).
(this text is also repeated in the 4.8 leading parag= raph)

=


<= /font>



F= rom: jmh@joelhalpern.com<jmh@joelhalpern.com>
To: mikeb= ianc@aol.com<mikebianc@aol.com>,<Myo.Zarny@gs.com>,<jguichar= @cisco.com>,<mn1921@att.com>,<Ron_Parker@affirmednetworks.com&g= t;,<sfc@ietf.org>
Sent: Friday, July 11, 2014
Subject= : Re: [sfc] Service Chains, Paths, and Load Balancers

</t= itle>The way the draft uses the terms, and the way most discussions outside= <br>the IETF SFC working group use the term, a service function chain is <= br>something that you would discuss a policy about. Certain traffic from <= br>certain users is supposed to receive a certain sequence of services, the= <br>service chain.<br><br>At the policy level, that does not care where in= the network that is <br>delivered. So as to allow control a level of infl= uence, and to have <br>flexibility to have multiple representations in the = network of that <br>policy construct, we have the intermediate notion of se= rvice function <br>path. If the control system does not need to apply any = influence, then <br>it uses one service path for the service chain. If it = needs a level of <br>control, it instantiates a suitable number of service = paths in the <br>control system, and rules for how those are used.<br><br>T= hen, the mapping in the SFF is based on that path, so as to enable the <br>= influence of the control system. While still allowing several other <br>la= yers of traffic management as discussed.<br><br>Yours,<br>Joel<br><br>On 7/= 11/14, 12:25 PM, <a href=3D"mailto:mikebianc@aol.com">mikebianc@aol.com</a>= wrote:<br>> I meant as a design principle when everything is working. = I was trying<br>> to come up with a concise example of configuring a net= work such that it<br>> does not work that would be analogous to configur= ing SFC such that "that<br>> remote SFF has the necessary forwarding log= ic to reach the next-next-SF".<br>><br>><br>><br>><br>><br>&= gt; -----------------------------------------------------------------------= -<br>> *<br><br class=3D"">From: *Myo.Zarny@gs.com<Myo.Zarny@gs.com&g= t;<br class=3D"">> *To:<br class=3D"">> *'mikebianc@aol.com'<mikeb= ianc@aol.com>,'jguichar@cisco.com'<jguichar@cisco.com>,'mn1921@att= .com'<mn1921@att.com>,'jmh@joelhalpern.com'<jmh@joelhalpern.com>= ;,'Ron_Parker@affirmednetworks.com'<Ron_Parker@affirmednetworks.com>,= 'sfc@ietf.org'<sfc@ietf.org><br class=3D"">> *Sent: *Friday, July = 11, 2014<br class=3D"">> *Subject: *RE: [sfc] Service Chains, Paths, and= Load Balancers<br class=3D"">><br class=3D"">> I don=E2=80=99t under= stand. (I=E2=80=99m sure I=E2=80=99m misunderstanding=E2=80=A6)<br class=3D= "">><br class=3D"">> Your backend servers could go down, be unreachab= le or be unable to<br class=3D"">> server more.<br class=3D"">><br cl= ass=3D"">> Route health injection (RHI) is a perfectly fine, accepted, w= ay of<br class=3D"">> indicating the health of the backend services to t= he network. You=E2=80=99re not<br class=3D"">> saying that=E2=80=99s wro= ng, are you?<br class=3D"">><br class=3D"">> **<br class=3D"">><br= class=3D"">> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of<br = class=3D"">> *mikebianc@aol.com <mailto:mikebianc@aol.com><br clas= s=3D"">> *Sent:* 11 July 2014 12:03 PM<br class=3D"">> *To:* jguichar= @cisco.com <mailto:jguichar@cisco.com>; mn1921@att.com<br class=3D"">= > <mailto:mn1921@att.com>; jmh@joelhalpern.com<br class=3D"">> = <mailto:jmh@joelhalpern.com>; Ron_Parker@affirmednetworks.com<br clas= s=3D"">> <mailto:Ron_Parker@affirmednetworks.com>; sfc@ietf.org &l= t;mailto:sfc@ietf.org><br class=3D"">> *Subject:* Re: [sfc] Service C= hains, Paths, and Load Balancers<br class=3D"">><br class=3D"">> heh.= well, if it did not, then you should not do it like that. e.g. I'm<br clas= s=3D"">> not going to configure real servers on a server load balancer t= hat are<br class=3D"">> not reachable. e.g. I'm not going to configure m= y BGP to announce<br class=3D"">> prefixes for which I cannot provide co= nnectivity. If you do things like<br class=3D"">> that, then you are doi= ng it wrong.<br class=3D"">><br class=3D"">><br class=3D"">><br cl= ass=3D"">> -------------------------------------------------------------= -----------<br class=3D"">><br class=3D"">> *From: *jguichar@cisco.co= m<jguichar@cisco.com<br class=3D"">> <mailto:jguichar@cisco.com%3c= jguichar@cisco.com>><br class=3D"">> *To: *NAPIERALA, MARIA H<m= n1921@att.com <mailto:mn1921@att.com>>,Joel M.<br class=3D"">> = Halpern<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>,Ron<b= r class=3D"">> Parker<Ron_Parker@affirmednetworks.com<br class=3D"">&= gt; <mailto:Ron_Parker@affirmednetworks.com>>,sfc@ietf.org<br clas= s=3D"">> <mailto:sfc@ietf.org><sfc@ietf.org <mailto:sfc@ietf= .org>><br class=3D"">> *Sent: *Friday, July 11, 2014<br class=3D""= >> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers<br cla= ss=3D"">><br class=3D"">> Then I misunderstand the proposal ;-) .. Ho= wever, it seems to me that if<br class=3D"">> you allow an SFF to make a= decision as to which remote SFF it will use for<br class=3D"">> a given= flow to reach the next SF within the chain then you better make<br class= =3D"">> sure that that remote SFF has the necessary forwarding logic to = reach the<br class=3D"">> next-next-SF for the chain as otherwise you ar= e in deep trouble.<br class=3D"">><br class=3D"">> On 7/11/14, 9:48 A= M, "NAPIERALA, MARIA H" <mn1921@att.com<br class=3D"">> <mailto:mn= 1921@att.com>> wrote:<br class=3D"">><br class=3D"">> >Abso= lutely not. Service chains can be instantiated only in relevant SFFs<br cla= ss=3D"">> >when they "arrive".<br class=3D"">> ><br class=3D"= ">> >> -----Original Message-----<br class=3D"">> >><br= class=3D"">><br class=3D"">> From: sfc [mailto:sfc-bounces@ietf.org]= On Behalf Of Jim Guichard<br class=3D"">> >>(jguichar)<br class= =3D"">> >> Sent: Friday, July 11, 2014 9:27 AM<br class=3D"">>= >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org <mailto:sfc@iet= f.org><br class=3D"">> >> Subject: Re: [sfc] Service Chains, P= aths, and Load Balancers<br class=3D"">> >><br class=3D"">> &= gt;> Well I think it is even worse than that if I have understood the<br= class=3D"">> >>proposal<br class=3D"">> >> correctly a= s it would require full knowledge of every single SF within<br class=3D"">&= gt; >>the<br class=3D"">> >> entire SFC domain at every si= ngle SFF as there is no way to know a<br class=3D"">> >>priori<br= class=3D"">> >> which SFC=C2=B9s a given SFF will need to servic= e at any given point in time.<br class=3D"">> >><br class=3D"">&g= t; >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <jmh@joelhalpern.co= m<br class=3D"">> <mailto:jmh@joelhalpern.com>> wrote:<br class= =3D"">> >><br class=3D"">> >> >Ron, thinking about t= his, I realized another major problem with the<br class=3D"">> >>= your<br class=3D"">> >> >proposal as I understand it. (And I r= eadily admit I may not understand<br class=3D"">> >> >it.)<br = class=3D"">> >> ><br class=3D"">> >> >The proposa= l has each SFF serve as the load balancer for the next<br class=3D"">> = >> >service function that follows it (not the one it delivers to),= in every<br class=3D"">> >> >service chain that goes through = it.<br class=3D"">> >> ><br class=3D"">> >> >Sinc= e it has to be able to work with all services, that means that<br class=3D"= ">> >>every<br class=3D"">> >> >SFF would have to be= a full, flow sensitive and stateful load balancer.<br class=3D"">> >= ;> >I ahve no problem if some SFF are flow sensitive, and / or statef= ul.<br class=3D"">> >> >But having the architecture require th= at every SFF be a full, flow<br class=3D"">> >> >sensitive, st= ateful, load balancer seems to me to be an acceptable<br class=3D"">> &= gt;> >imposition.<br class=3D"">> >> ><br class=3D"">>= ; >> >Yours,<br class=3D"">> >> >Joel<br class=3D"">= > >> ><br class=3D"">> >> >On 7/10/14, 10:06 PM, = Joel M. Halpern wrote:<br class=3D"">> >> >> Part of my per= sonal view is that I am trying to make this work<br class=3D"">> >&g= t;sensibly<br class=3D"">> >> >> in a more orchestrated env= ironment. I expect that the service<br class=3D"">> >> >> f= unctions, and over time probably the SFF capabilities, will be<br class=3D"= ">> >> >> orchestrated and installed. I expect the service = chains to be<br class=3D"">> >>driven by<br class=3D"">> >= > >> BSS tools that define offerings to clients, and enable self-s= election<br class=3D"">> >> >> from these. I expect service= paths to be heavily policy drive.<br class=3D"">> >> >><br= class=3D"">> >> >> I can see how to make all of that work = in an archtiecture driven by<br class=3D"">> >> >> initial = classification to described service paths. It is harder to<br class=3D"">&g= t; >>see<br class=3D"">> >> >> how to make it work (= but it can be done) when we allow more<br class=3D"">> >> dynamic= ity<br class=3D"">> >> >> in the network behavior.<br class= =3D"">> >> >><br class=3D"">> >> >> Having = said that, most of that perspective I described is outside of<br class=3D""= >> >>the<br class=3D"">> >> >> scope of the worki= ng group. it is not something we are tasked to<br class=3D"">> >>= agree<br class=3D"">> >> >>on.<br class=3D"">> >>= >> So I do not claim that vision means we have to do it a certain wa= y.<br class=3D"">> >>it<br class=3D"">> >> >> is = just the perspective that drives my preferences.<br class=3D"">> >&g= t; >><br class=3D"">> >> >> Yours,<br class=3D"">>= >> >> Joel<br class=3D"">> >> >><br class=3D"= ">> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote:<br class=3D= "">> >> >>>> For me, the amount of information about = service instances that<br class=3D"">> >>needs<br class=3D"">>= >> >>>>to<br class=3D"">> >> >>>>= be widely distributed and maintained, potentially even across data<br clas= s=3D"">> >> >>>> centers within an administrative sco= pe, is large enough and complex<br class=3D"">> >> >>>&g= t; enough that trying to get that into each SFF seems like a difficult<br c= lass=3D"">> >> >>>> architecture to realize.<br class= =3D"">> >> >>><br class=3D"">> >> >>>= I'm curious as to why that is more complicated than dynamic routing,<br cl= ass=3D"">> >> >>> hyper-scale data center orchestration,= or DNS, all of which are<br class=3D"">> >>bigger<br class=3D"">= > >> >>> problems that have been profitably and stably i= mplemented?<br class=3D"">> >> >>><br class=3D"">> &= gt;> >>> It also seems that if it really is more complicated, t= hat is a good<br class=3D"">> >> >>> sign that it is too= complicated.<br class=3D"">> >> >>><br class=3D"">> = >> >>> ________________________________________<br class=3D= "">> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com<b= r class=3D"">> <mailto:jmh@joelhalpern.com>]<br class=3D"">> &= gt;> >>> Sent: Thursday, July 10, 2014 9:45 PM<br class=3D"">&g= t; >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@ao= l.com<br class=3D"">> <mailto:mikebianc@aol.com>; Ian Smith;<br cl= ass=3D"">> >> >>> sfc@ietf.org <mailto:sfc@ietf.org&g= t;<br class=3D"">> >> >>> Subject: Re: [sfc] Service Cha= ins, Paths, and Load Balancers<br class=3D"">> >> >>><br= class=3D"">> >> >>> This is an architectural issue. And= one that I would prefer we<br class=3D"">> >> >>>actual= ly<br class=3D"">> >> >>> decide, rather than trying to = allow all possible implementations.<br class=3D"">> >> >>&g= t; Because it does have a major effect on the control requirements and<br c= lass=3D"">> >> the<br class=3D"">> >> >>> func= tionality of SFFs.<br class=3D"">> >> >>><br class=3D"">= > >> >>> For me, the amount of information about service= instances that needs<br class=3D"">> >> to<br class=3D"">> &= gt;> >>> be widely distributed and maintained, potentially even= across data<br class=3D"">> >> >>> centers within an ad= ministrative scope, is large enough and complex<br class=3D"">> >>= ; >>> enough that trying to get that into each SFF seems like a di= fficult<br class=3D"">> >> >>> architecture to realize.<= br class=3D"">> >> >>><br class=3D"">> >> >= >> Yours,<br class=3D"">> >> >>> Joel<br class=3D"= ">> >> >>><br class=3D"">> >> >>> But= it is a fair question.<br class=3D"">> >> >>><br class= =3D"">> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:<br= class=3D"">> >> >>>> This is the crux of my issue. I= s the end to end selection of<br class=3D"">> >> >>>>= (top-level) instances performed centrally (perhaps by the<br class=3D"">&g= t; >>classifier)<br class=3D"">> >> >>>> or ho= p-by-hop (perhaps by the classifier and subsequently the<br class=3D"">>= >>SFFs)?<br class=3D"">> >> >>>> Such selecti= on is not equivalent to reclassification. And surely,<br class=3D"">> &= gt;> >>>> this is an architectural issue and not relegated t= o<br class=3D"">> >> >>>> "implementation".<br class= =3D"">> >> >>>><br class=3D"">> >> >>= >> My own view is to favor the distributed approach even though a<br = class=3D"">> >> >>>> greater amount of data (chain de= finitions and perhaps local<br class=3D"">> >>selection<br class= =3D"">> >> >>>> policy) is required at those distribu= ted decision points. This<br class=3D"">> >> >>>> app= roach does not require an end-to-end path id at all. My<br class=3D"">> = >> >>>> rationale for favoring this approach is primaril= y driven by<br class=3D"">> >>increased<br class=3D"">> >&= gt; >>>> resiliency over the global path id approach. With a gl= obal path<br class=3D"">> >>id<br class=3D"">> >> >&= gt;>> approach, consider failure of an instance and needing to alter = the<br class=3D"">> >> >>>> global path ID table for = each and every affected end-to-end path.<br class=3D"">> >> >&= gt;>><br class=3D"">> >> >>>> Ron<br class=3D""= >> >> >>>><br class=3D"">> >> >>>&= gt; ________________________________________ From: sfc<br class=3D"">> = >> >>>> [sfc-bounces@ietf.org <mailto:sfc-bounces@ietf= .org>] on behalf<br class=3D"">> of Joel Halpern Direct<br class=3D""= >> >> >>>> [jmh.direct@joelhalpern.com<br class=3D"">= > <mailto:jmh.direct@joelhalpern.com>] Sent: Thursday, July 10, 20= 14 6:15 PM<br class=3D"">> >> >>>> To: mikebianc@aol.= com <mailto:mikebianc@aol.com>;<br class=3D"">> I.Smith@F5.com <= ;mailto:I.Smith@F5.com>; sfc@ietf.org<br class=3D"">> <mailto:sfc@= ietf.org> Subject: Re:<br class=3D"">> >> >>>> [sf= c] Service Chains, Paths, and Load Balancers<br class=3D"">> >> &= gt;>>><br class=3D"">> >> >>>> The way the a= rchitecture models the case of SF1 needing to<br class=3D"">> >>i= nfluence<br class=3D"">> >> >>>> the chain is that on= e would do reclassification at the exit from<br class=3D"">> >> &= gt;>>> SF1.<br class=3D"">> >> >>>><br class= =3D"">> >> >>>> Part of the goal is to keep the diffe= rent functions logically<br class=3D"">> >> >>>> sepa= rate so that solutions can clearly describe how they choose to<br class=3D"= ">> >> >>>> compose them for "service" delivery.<br c= lass=3D"">> >> >>>><br class=3D"">> >> >= >>> Yours, Joel<br class=3D"">> >> >>>><br c= lass=3D"">> >> >>>> On 7/10/14, 6:10 PM, mikebianc@ao= l.com<br class=3D"">> <mailto:mikebianc@aol.com> wrote:<br class= =3D"">> >> >>>>> I don't see anything in the arch = draft that suggests any sort of<br class=3D"">> >> >>>&g= t;> limit. However, it does seem to indicate that the entire path (all<b= r class=3D"">> >> >>>>> SFIs) must be chosen at SF= C instantiation. I believe this means<br class=3D"">> >> >>= >>> either at the classifier or maybe the classifier chooses a SF<= br class=3D"">> >>Chain<br class=3D"">> >> >>>= >> and the NF or at the latest the first SFF. In any case, the<br cla= ss=3D"">> >> >>>>> language does seem to prohibit = a more dynamic SFP where SFI(n) is<br class=3D"">> >> >>>= ;>> determined at the SFI(n-1) hop. According to the draft, this<br c= lass=3D"">> >> >>>>> behavior would be considered = "branching" to a new SFP as opposed<br class=3D"">> >> to<br clas= s=3D"">> >> >>>>> choosing and then forwarding to = the selected instance of the<br class=3D"">> >> >>>>&= gt; next-hop of the current SFC.<br class=3D"">> >> >>>&= gt;><br class=3D"">> >> >>>>> draft-merged-sfc-= architecture-00:<br class=3D"">> >> >>>>>> When= an SFC is instantiated into the network it is necessary to<br class=3D"">&= gt; >> >>>>>> select the specific instances of SFs= that will be used, and to<br class=3D"">> >> >>>>>= ;> create the service topology for that SFC using SF's network<br class= =3D"">> >> >>>>>> locator. Thus, instantiation = of the SFC results in the creation<br class=3D"">> >> >>>= ;>>> of a Service Function Path (SFP) and is used for forwarding<b= r class=3D"">> >> >>>>>> packets through the SF= C. In other words, an SFP is the<br class=3D"">> >> >>>&= gt;>> instantiation of the defined SFC.<br class=3D"">> >> = >>>>>><br class=3D"">> >> >>>>>&= gt; The SFC architecture supports reclassification (or non-initial<br class= =3D"">> >> >>>>>> classification) as well. As p= ackets traverse an SFP,<br class=3D"">> >> >>>>>&g= t; reclassification may occur - typically performed by a<br class=3D"">>= >> >>>>>> classification function co-resident wit= h a service function.<br class=3D"">> >> >>>>>>= Reclassification may result in the selection of a new SFP, an<br class=3D"= ">> >> >>>>>> update of the associated metadata= , or both. This is referred to<br class=3D"">> >> >>>>= ;>> as "branching".<br class=3D"">> >> >>>>>= <br class=3D"">> >> >>>>><br class=3D"">> >= > >>>>><br class=3D"">> >> >>>>>= <br class=3D"">> >><br class=3D"">> >>>>>>&= gt;--------------------------------------------------------------------<br = class=3D"">> >>>>>>>--<br class=3D"">> >>= ; >>>>>--<br class=3D"">> >> >>>>><= br class=3D"">> >> >>>>><br class=3D"">> >&= gt; >>>>><br class=3D"">> >> >>> *From: *= I.Smith@F5.com<I.Smith@F5.com<br class=3D"">> <mailto:*I.Smith@F5.= com%3cI.Smith@F5.com>><br class=3D"">> >> >>>>&= gt; *To: *Joel Halpern Direct<jmh.direct@joelhalpern.com<br class=3D"">&= gt; <mailto:jmh.direct@joelhalpern.com>>,Joel M.<br class=3D"">>= ; >> >>>>><br class=3D"">> >> >>>&= gt;>Halpern<jmh@joelhalpern.com<br class=3D"">> <mailto:jmh@joe= lhalpern.com>>,huang@sce.carleton.ca<br class=3D"">> <mailto:hu= ang@sce.carleton.ca><huang@sce.<br class=3D"">> <mailto:huang@s= ce.%0b>>> carleton.<br class=3D"">> >> >>>>&= gt;ca>,sfc@ietf.org <mailto:sfc@ietf.org><sfc@ietf.org<br class= =3D"">> <mailto:sfc@ietf.org>><br class=3D"">> >> >= ;>>>><br class=3D"">> >> >>>>><br clas= s=3D"">> >> >>>>><br class=3D"">> >> >= ;>> *Sent: *Thursday, July 10, 2014<br class=3D"">> >> >= >>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balan= cers<br class=3D"">> >> >>>>><br class=3D"">> = >> >>>>> Actually, I think I am disagreeing.<br class= =3D"">> >> >>>>><br class=3D"">> >> >= >>>> If the possibility of medium-scale deployments (and that i= s what<br class=3D"">> >> >>>>> 16 million flows i= s in my world) of service chains is preconceived<br class=3D"">> >&g= t; >>>>> as an absurd idea, then the architecture burdened w= ith that<br class=3D"">> >> >>>>> preconception.<b= r class=3D"">> >> >>>>><br class=3D"">> >&g= t; >>>>> There has to be some point of aim, some degree of a= spiration to<br class=3D"">> >> >>>>> scale that i= s appropriate for the lifespan of the architecture -<br class=3D"">> &g= t;> >>>>> you don't have to know what it is, but by sayin= g that an arbitrary<br class=3D"">> >> >>>>> numbe= r is "too far", you're creating - even if it isn't<br class=3D"">> >= >intentional<br class=3D"">> >> >>>>> - a limit= that influences decisions that have lasting impacts<br class=3D"">> &g= t;> >>>>> regarding scale-out, failure mitigation, elasti= city, address<br class=3D"">> >> >>>>> space... al= l kinds of things. That is a problem I'm not<br class=3D"">> >> &= gt;>>>> particularly eager to deal with.<br class=3D"">> &g= t;> >>>>><br class=3D"">> >> >>>>&g= t;<br class=3D"">> >> >>>>><br class=3D"">> &g= t;> >>>>><br class=3D"">> >> >>>>&g= t; ________________________________________<br class=3D"">> >> &g= t;>>>><br class=3D"">> >> >>>>><br cla= ss=3D"">> >> >>>>> From: Joel Halpern Direct [jmh.= direct@joelhalpern.com<br class=3D"">> <mailto:jmh.direct@joelhalpern= .com>] Sent:<br class=3D"">> >> >>>>> Thursday,= July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;<br class=3D"">> = >> >>>>> huang@sce.carleton.ca <mailto:huang@sce.ca= rleton.ca>;<br class=3D"">> sfc@ietf.org <mailto:sfc@ietf.org> = Subject: Re: [sfc] Service<br class=3D"">> >> >>>>>= ; Chains, Paths, and Load Balancers<br class=3D"">> >> >>&g= t;>><br class=3D"">> >> >>>>> Ian, I don't t= hink you disagree with me at all in this regard. I<br class=3D"">> >= >am<br class=3D"">> >> >>>>> not requesting the= the architecture or the solution prohibit<br class=3D"">> >> >= ;>>>> deployments in the specific fashion. I am objecting to Hu= ang's<br class=3D"">> >> >>>>> reading of my note = as saying that such deployments are required<br class=3D"">> >> &= gt;>>>> they by the archtiecture.<br class=3D"">> >> = >>>>><br class=3D"">> >> >>>>> As I= have said repeatedly, I am not trying to prohibit such<br class=3D"">> = >> >>>>> things. Whether they are a good idea or not = depends upon many<br class=3D"">> >> >>>>> factors= outside of the scope of the WG. I happen to think that<br class=3D"">> = >>they<br class=3D"">> >> >>>>> are usually= a bad idea.<br class=3D"">> >> >>>>><br class=3D"= ">> >> >>>>> But the archtiecture si carefully avo= iding attempting to know what<br class=3D"">> >> >>>>= > is and is not eployable.<br class=3D"">> >> >>>>= ><br class=3D"">> >> >>>>> Yours, Joel<br class= =3D"">> >> >>>>><br class=3D"">> >> >= >>>> On 7/10/14, 5:01 PM, Ian Smith wrote:<br class=3D"">> = >> >>>>>> I disagree.<br class=3D"">> >> = >>>>>><br class=3D"">> >> >>>>>&= gt; We routinely have stateful devices that manage tens of millions<br clas= s=3D"">> >> >>>>>> of<br class=3D"">> >&= gt; >>>>> concurrent flows in both access network and data c= enter<br class=3D"">> >> >>>>> environments today.= You can't seriously believe that in the<br class=3D"">> >> >&= gt;>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are on= ly<br class=3D"">> >> going<br class=3D"">> >> >>= >>> to have small numbers of service chains with equally small num= bers<br class=3D"">> >> >>>>> of active service pa= ths?<br class=3D"">> >> >>>>>><br class=3D"">&g= t; >> >>>>>> Your sounds too much like "no one wil= l ever need more than 64K"<br class=3D"">> >> >>>>>= ;> for<br class=3D"">> >> >>>>> comfort.<br cla= ss=3D"">> >> >>>>>><br class=3D"">> >>= ; >>>>>><br class=3D"">> >> >>>>>= ;> ________________________________________ From: sfc<br class=3D"">>= >> >>>>>> [sfc-bounces@ietf.org <mailto:sfc-bo= unces@ietf.org>] on<br class=3D"">> behalf of Joel M. Halpern<br clas= s=3D"">> >> >>>>> [jmh@joelhalpern.com <mailto:= jmh@joelhalpern.com>]<br class=3D"">> >> >>>>>&= gt; Sent: Thursday, July 10, 2014 4:46 PM To:<br class=3D"">> huang@sce.= carleton.ca <mailto:huang@sce.carleton.ca>;<br class=3D"">> >&= gt; >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> Subje= ct: Re: [sfc] Service<br class=3D"">> Chains, Paths, and Load<br class= =3D"">> >> >>>>>> Balancers<br class=3D"">> = >> >>>>>><br class=3D"">> >> >>>= ;>>> No, it will mean that if someone tries to deploy the archtiet= ure<br class=3D"">> >> >>>>>> particularly badl= y, they will exceed the limits of their<br class=3D"">> >> >&g= t;>>>> devices. The architecture does not require such absurd u= se of<br class=3D"">> >> >>>>>> service paths. = Since I can not figure out how to write<br class=3D"">> >> >&g= t;>>>> architectural words to prohibit it, the architecture doe= s permit<br class=3D"">> >> >>>>>> such abuse.<= br class=3D"">> >> >>>>>><br class=3D"">> &= gt;> >>>>>> Please do not read my saying that the arch= tiecture permits<br class=3D"">> >> >>>>>> some= thing as saying it is either deisred or required by the work.<br class=3D""= >> >> >>>>>> It isn't.<br class=3D"">> >= > >>>>>><br class=3D"">> >> >>>>= >> Yours, Joel<br class=3D"">> >> >>>>>><= br class=3D"">> >> >>>>>> On 7/10/14, 4:36 PM, = Changcheng Huang wrote:<br class=3D"">> >> >>>>>&g= t;> If you need to support 100 service chains, it will mean<br class=3D"= ">> >> >>>>>>> 16,000,000 paths. That is lar= ger than the routing table of a<br class=3D"">> >> >>>&g= t;>>> core router.<br class=3D"">> >> >>>>&g= t;>><br class=3D"">> >> >>>>>>> Chang<= br class=3D"">> >> >>>>>>><br class=3D"">>= ; >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Ha= lpern wrote:<br class=3D"">> >> >>>>>>>> = The architecture allows a range of deployments, from 1<br class=3D"">> = >> >>>>>>>> service path to 160000 service pa= ths. I would hope that<br class=3D"">> >> >>>>>>= ;>> operators are prepared for the complexities if they choose to<br = class=3D"">> >> >>>>>>>> avoid any use of= local load balancing and in stead provision<br class=3D"">> >> &= gt;>>>>>>> 160,000 service paths.<br class=3D"">> = >> >>>>>>>><br class=3D"">> >> >= >>>>>>> Yours, Joel<br class=3D"">> >> >&= gt;>>>>>><br class=3D"">> >> >>>>&g= t;>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:<br class=3D""= >> >> >>>>>>>>> Paul,<br class=3D"">&g= t; >> >>>>>>>>><br class=3D"">> >&= gt; >>>>>>>>> How many path identifiers there wi= ll be for a 4 hop service<br class=3D"">> >> >>>>>= >>>> chain with 20 instances at each hop?<br class=3D"">> &= gt;> >>>>>>>>><br class=3D"">> >> &= gt;>>>>>>>> Maria<br class=3D"">> >> >= >>>>>>>><br class=3D"">> >> >>>&= gt;>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf= Of<br class=3D"">> >> >>>>>>>>> *Paul= Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03<br class=3D"">> >= ;> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joe= lhalpern.com<br class=3D"">> <mailto:jmh@joelhalpern.com>;<br clas= s=3D"">> >> >>>>>>>>> mohamed.boucadai= r@orange.com<br class=3D"">> <mailto:mohamed.boucadair@orange.com>= ; sfc@ietf.org <mailto:sfc@ietf.org>;<br class=3D"">> >> &g= t;>>>>>>>> mikebianc@aol.com <mailto:mikebianc@a= ol.com> *Subject:*<br class=3D"">> Re: [sfc] Service Chains,<br class= =3D"">> >> >>>>>>>>> Paths, and Load B= alancers<br class=3D"">> >> >>>>>>>>><= br class=3D"">> >> >>>>>>>>> Lucy,<br = class=3D"">> >> >>>>>>>>><br class=3D"= ">> >> >>>>>>>>> Overall I concur, as = you say: a path ID drives the<br class=3D"">> >> >>>>= >>>>> forwarding. I=C2=B9d<br class=3D"">> >> >= >>>> make<br class=3D"">> >> >>>>>>= >>> the minor change: the path identifier can be used to derive<br= class=3D"">> >> >>>>>>>>> the needed = forwarding and associated transport.<br class=3D"">> >> >>&= gt;>>>>>><br class=3D"">> >> >>>>&g= t;>>>> It is _not_ the transport, but rather is used to simply<= br class=3D"">> >> >>>>>>>>> identify = the service path (or graph) that packets must<br class=3D"">> >> = >>>>>>>>> traverse. By having a path identifier,= the exact<br class=3D"">> >> >>>>>>>>>= ; indirection that people seem to be asking for on this<br class=3D"">> = >> >>>>>>>>> thread can be simply be impl= emented. The path identifier<br class=3D"">> >> >>>>&= gt;>>>> provides nothing more than a lookup, that lookup can re= sult<br class=3D"">> >> >>>>>>>>> in a= one or more (equal or weighted) transport next<br class=3D"">> >>= ; >>>>>>>>> hop(s).<br class=3D"">> >>= >>>>>>>>><br class=3D"">> >> >>= >>>>>>> Paul<br class=3D"">> >> >>>= >>>>>><br class=3D"">> >> >>>>>&= gt;>>> On Jul 10, 2014, at 11:04 AM, Lucy yong<br class=3D"">> = >> >>>>>>>>> <lucy.yong@huawei.com <= ;mailto:lucy.yong@huawei.com<br class=3D"">> <mailto:lucy.yong@huawei= .com%20%3cmailto:lucy.yong@huawei.com>>><br class=3D"">> >&= gt; >>>>>>>>> wrote:<br class=3D"">> >>= ; >>>>>>>>><br class=3D"">> >> >>= ;>>>>>>><br class=3D"">> >> >>>>= >>>>><br class=3D"">> >> >>>>>>&= gt;>> Agree. The arch. doc should not mandate only use of the<br clas= s=3D"">> >> >>>>>>>>> service path ide= ntifier to drive the forwarding actions.<br class=3D"">> >> >&= gt;>>>>>>><br class=3D"">> >> >>>&g= t;>>>>> Lucy<br class=3D"">> >> >>>>&g= t;>>>><br class=3D"">> >> >>>>>>>= ;>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf<br class=3D"">= > >> >>>>>>>>> Of*mohamed.boucadair@or= ange.com<br class=3D"">> <mailto:Of*mohamed.boucadair@orange.com><= br class=3D"">> >> >>>>>>>>> <mailt= o:mohamed.boucadair@orange.com> *Sent:*Thursday,<br class=3D"">> >= ;> July<br class=3D"">> >> >>>>>>>>>= ; 10, 2014 2:06 AM *To:*mikebianc@aol.com<br class=3D"">> <mailto:mik= ebianc@aol.com><br class=3D"">> >> >>>>>>>= ;>> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com<br class=3D"= ">> <mailto:jmh@joelhalpern.com><br class=3D"">> >> >= >>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@iet= f.org<br class=3D"">> <mailto:sfc@ietf.org><br class=3D"">> &g= t;> >>>>>>>>> <mailto:sfc@ietf.org> *Su= bject:*Re: [sfc] Service Chains,<br class=3D"">> >> >>>&= gt;>>>>> Paths, and Load Balancers<br class=3D"">> >&= gt; >>>>>>>>><br class=3D"">> >> >&= gt;>>>>>>> Re-,<br class=3D"">> >> >>&= gt;>>>>>><br class=3D"">> >> >>>>&g= t;>>>> The merged draft calls out explicitly a service path<br = class=3D"">> >> >>>>>>>>> identifier. = I object to use that identifier to derive<br class=3D"">> >> >= >>>>>>>> forwarding actions.<br class=3D"">> &g= t;> >>>>>>>>><br class=3D"">> >> &g= t;>>>>>>>> Requiring a SFC system to have the full = knowledge of every<br class=3D"">> >> >>>>> availa= ble SFC<br class=3D"">> >> >>>>>>>>> f= orwarding paths within an SFC-enabled domain is not<br class=3D"">> >= ;> >>>>> required/justified<br class=3D"">> >> = >>>>>>>>> nor possible in various deployment con= texts.<br class=3D"">> >> >>>>>>>>><br= class=3D"">> >> >>>>>>>>> SFC forward= ing actions should rely on the piece of<br class=3D"">> >> >&g= t;>>>>>>> information<br class=3D"">> >> >= ;>>>> that will<br class=3D"">> >> >>>>&g= t;>>>> be present in all deployments: that is the one required = to<br class=3D"">> >> >>>>>>>>> struct= ure a service chain. How that information is used to<br class=3D"">> &g= t;> >>>>>>>>> infer forwarding<br class=3D"">= > >> >>>>> actions<br class=3D"">> >> &g= t;>>>>>>>> is a solution-oriented discussion.<br cl= ass=3D"">> >> >>>>>>>>><br class=3D"">= > >> >>>>>>>>> Cheers,<br class=3D"">&= gt; >> >>>>>>>>><br class=3D"">> >= > >>>>>>>>> Med<br class=3D"">> >> = >>>>>>>>><br class=3D"">> >> >>&= gt;>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la p= art<br class=3D"">> >> >>>>> de*mikebianc@aol.com = <mailto:de*mikebianc@aol.com><br class=3D"">> >> >>&g= t;>>>>>> <mailto:mikebianc@aol.com> *Envoy=C3=A9 :*= mercredi 9 juillet<br class=3D"">> >> >>>>>>>= ;>> 2014 22:03 *=C3=80 :*jmh@joelhalpern.com<br class=3D"">> <m= ailto:jmh@joelhalpern.com><br class=3D"">> >> >>>>= >>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org<br cla= ss=3D"">> <mailto:sfc@ietf.org><br class=3D"">> >> >&= gt;>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [s= fc] Service Chains,<br class=3D"">> >> >>>>>>&g= t;>> Paths, and Load Balancers<br class=3D"">> >> >>&= gt;>>>>>><br class=3D"">> >> >>>>&g= t;>>>> Is anyone still questioning the difference between SF Ch= ain<br class=3D"">> >> >>>>>>>>> and S= F<br class=3D"">> >> >>>>> Path?<br class=3D"">>= ; >> >>>>>>>>> Other than clarifying the = definition so that it's clear to<br class=3D"">> >> >>>&= gt;> those not<br class=3D"">> >> >>>>>>>= >> familiar with the draft, it seems that everyone agrees on<br class= =3D"">> >> >>>>>>>>> these terms.<br c= lass=3D"">> >> >>>>>>>>><br class=3D""= >> >> >>>>>>>>> To me, the one point t= hat is still unclear is whether it is<br class=3D"">> >> >>= >>>>>>> the intent of this draft to ultimately specify= what the ID<br class=3D"">> >> >>>>>>>>&= gt; of the SFC Header<br class=3D"">> >> >>>>> sho= uld<br class=3D"">> >> >>>>>>>>> refer= ence (the chain or the path), or if this draft simply<br class=3D"">> &= gt;> >>>>>>>>> intends to leave that ambiguou= s, allowing other drafts to<br class=3D"">> >> >>>>&g= t;>>>> dictate the mechanisms for forwarding based on chain or<= br class=3D"">> >> >>>>>>>>> path and = the choice of chain or<br class=3D"">> >> >>>>> pa= th to<br class=3D"">> >> >>>>>>>>> be = negotiated in the control-plane.<br class=3D"">> >> >>>&= gt;>>>>><br class=3D"">> >> >>>>>&g= t;>>> If the latter (ambiguous), then the draft would have<br clas= s=3D"">> >> >>>>>>>>> require that bot= h SFP and SFC be supported (or make one<br class=3D"">> >> >&g= t;>>>>>>> required and the other optional) to avoid so= me vendors only<br class=3D"">> >> >>>>>>>&g= t;> supporting SFP and others only supporting SFC.<br class=3D"">> &= gt;> >>>>>>>>><br class=3D"">> >> &= gt;>>>>>>>><br class=3D"">> >> >>&g= t;>><br class=3D"">> >><br class=3D"">> >>>>= ;>>>--------------------------------------------------------------= ------<br class=3D"">> >>>>>>>--<br class=3D"">>= ; >> >>>>>--<br class=3D"">> >> >>>= ;>><br class=3D"">> >> >>>>><br class=3D"">&= gt; >> >>>>><br class=3D"">> >> >>>= ;>>>><br class=3D"">> >> >>>>>>>= >> *From:*jmh@joelhalpern.com<br class=3D"">> <mailto:jmh@joelh= alpern.com><jmh@joelhalpern.com<br class=3D"">> <mailto:jmh@joe= lhalpern.com%0b>>> >>>>>>>>><br class= =3D"">> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>><br = class=3D"">> >> >>>>>>>>> *To:*sfc@iet= f.org <mailto:sfc@ietf.org><sfc@ietf.org<br class=3D"">> <ma= ilto:sfc@ietf.org%0b>>> >>>>>>>>><br cl= ass=3D"">> <mailto:sfc@ietf.org%3csfc@ietf.org>> *Sent:*Tuesday= , July<br class=3D"">> >> >>>>>>>>> 8,= 2014 *Subject:*[sfc] Service Chains, Paths, and Load<br class=3D"">> &= gt;> >>>>>>>>> Balancers<br class=3D"">> = >> >>>>>>>>><br class=3D"">> >> = >>>>>>>>> I have been trying to figure out how t= o clearly answer a<br class=3D"">> >> >>>>>>>= ;>> number of comments that have been made about the proposed<br clas= s=3D"">> >> >>>>>>>>> merged archtiect= ure draft. Assuming we can get working<br class=3D"">> >> >>= ;>>>>>>> group agreement on the intent, we will work t= o improve the<br class=3D"">> >> >>>>>>>>= > wording so that readers who have not participated in the WG<br class= =3D"">> >> >>>>>>>>> discussion will u= nderstnd it the way the<br class=3D"">> >> >>>>> w= orking<br class=3D"">> >> >>>>>>>>> gr= oup intends.<br class=3D"">> >> >>>>>>>>&= gt;<br class=3D"">> >> >>>>>>>>> But w= hat do we intend? I will try to explain my personal<br class=3D"">> >= ;> >>>>>>>>> view, and see if that helps.<br = class=3D"">> >> >>>>>>>>><br class=3D"= ">> >> >>>>>>>>> In this regard, it is= important to keep in mind that what<br class=3D"">> >> >>&= gt;>>>>>> we are defining is the data plane architecture.= We are not<br class=3D"">> >> >>>>>>>>&g= t; attempting to define the architecture for the entire<br class=3D"">> = >> >>>>>>>>> solution for service chainin= g. That would encompass<br class=3D"">> >> >>>>>&g= t;>>> OSS/BSS, various control and policy functions, virtual<br cl= ass=3D"">> >> >>>>>>>>> machine and im= age management, and many other aspects.<br class=3D"">> >> >&g= t;>>>>>>><br class=3D"">> >> >>>>= ;>>>>> As a result there are many things which clearly need = to<br class=3D"">> >> >>>>>>>>> exist = in the larger system, but which are dealt with above<br class=3D"">> &g= t;> >>>>>>>>> where we are<br class=3D"">>= >> >>>>> functioning,<br class=3D"">> >> &= gt;>>>>>>>> and are not directly required by the wo= rk we are doing.<br class=3D"">> >> >>>>>>>&= gt;><br class=3D"">> >> >>>>>>>>> I= n order to get to service chain vs service path, as I<br class=3D"">> &= gt;> >>>>>>>>> understand<br class=3D"">> = >> >>>>> them,<br class=3D"">> >> >>&= gt;>>>>>> I need to first discuss load balancing. There a= re at least<br class=3D"">> >> >>>>>>>>&g= t; three different ways that load balancing can and will<br class=3D"">>= >> >>>>>>>>> interact with service chain= ing. There probably are more.<br class=3D"">> >> >>>>= >>>>> The point of the archtiecture is to permit all of thes= e,<br class=3D"">> >> >>>>>>>>> but no= t to mandate that any particular kind<br class=3D"">> >> >>= >>> be used<br class=3D"">> >> >>>>>>&= gt;>> in any solution.<br class=3D"">> >> >>>>&= gt;>>>><br class=3D"">> >> >>>>>>&g= t;>> 1) Load balancing as a service provided to the end user.<br clas= s=3D"">> >> >>>>>>>>> This is a servic= e function. It receives user packets, and<br class=3D"">> >> >= >>>>>>>> modifies them (or<br class=3D"">> >= > >>>>> marks<br class=3D"">> >> >>>&g= t;>>>>> them, or ...) so as to choose an end user service in= stance<br class=3D"">> >> >>>>>>>>> to= receive the users packet. This is an important service<br class=3D"">> = >> >>>>>>>>> function to be able to inclu= de in service chaining. It's<br class=3D"">> >> >>>>&= gt;>>>> behavior may affect requirements on how service chainin= g is<br class=3D"">> >> >>>>>>>>> done= . But it has very little impact on the archtiecture.<br class=3D"">> &g= t;> >>>>>>>>> From an architectural pe3rspect= ive it is simply a<br class=3D"">> >> >>>>> servic= e<br class=3D"">> >> >>>>>>>>> functio= n which may modify the underlying packet.<br class=3D"">> >> >= >>>>>>>><br class=3D"">> >> >>>&= gt;>>>>> 2) There is internal load balancing. That is, one c= an have<br class=3D"">> >> >>>>>>>>> w= hat<br class=3D"">> >> >>>>> appears<br class=3D""= >> >> >>>>>>>>> to the service chainin= g architecture as a single point of<br class=3D"">> >> >>&g= t;>>>>>> contact<br class=3D"">> >> >>>= ;>> for a<br class=3D"">> >> >>>>>>>&g= t;> specific service function, but is actually delivered by a<br class= =3D"">> >> >>>>> collection of<br class=3D"">> = >> >>>>>>>>> virtual or physical machines= , possibly including one or<br class=3D"">> >> >>>>&g= t;>>>> several load balancers (for example using VRRP-like<br c= lass=3D"">> >> >>>>>>>>> techniques to= share a MAC address.) mostly, this is<br class=3D"">> >> >>= ;>>>>>>> invisible to the service chaining data plane = mechanisms. It<br class=3D"">> >> >>>>>>>>= ;> is likely that it is visible to various control mechanisms,<br class= =3D"">> >> >>>>>>>>> such as those res= ponsible for scale-in, scale-out, and vm<br class=3D"">> >> >&= gt;>>>>>>> instantiation. The architectural impact of = permitting this<br class=3D"">> >> >>>>>>>&g= t;> is largely that we need to be careful that our terminology<br class= =3D"">> >> >>>>>>>>> does not lead<br = class=3D"">> >> >>>>> readers to<br class=3D"">>= ; >> >>>>>>>>> think we are prohibiting i= t.<br class=3D"">> >> >>>>>>>>><br cla= ss=3D"">> >> >>>>>>>>> 3) There can al= so be load balancing done by selecting<br class=3D"">> >> >>= ;>>>>>>> packet paths for the service chaining that di= rect traffic<br class=3D"">> >> >>>>>>>>&= gt; to different places. We would not want to require that a<br class=3D"">= > >> >>>>>>>>> given service function = appear at only one place in the<br class=3D"">> >> >>>&g= t;>>>>> network.<br class=3D"">> >> >>>&g= t;>>>>><br class=3D"">> >> >>>>>>= ;>>> It is of course the case that these may be combined. I tend<b= r class=3D"">> >> >>>>>>>>> to<br clas= s=3D"">> >> >>>>> refer to<br class=3D"">> >= ;> >>>>>>>>> the collection of entities that = appear to service chaining<br class=3D"">> >> >>>>>= ;>>>> as a single point as a cluster. Not because cluster is a<= br class=3D"">> >> >>>>>>>>> good term= . But because I do not have another one. Thus, the<br class=3D"">> >= > >>>>>>>>> point of type 3 load balancing<br= class=3D"">> >> >>>>> is to<br class=3D"">> &= gt;> >>>>>>>>> direct different subsets of tr= affic to different singular<br class=3D"">> >> >>>>&g= t;>>>> or clustered service functions in different places in th= e<br class=3D"">> >> >>>>>>>>> network= .<br class=3D"">> >> >>>>>>>>><br clas= s=3D"">> >> >>>>>>>>> Now with that sa= id, what do I mean when I talk about<br class=3D"">> >> >>&= gt;>>>>>> service chain and service path/ Service chain i= s a sequence<br class=3D"">> >> >>>>>>>>&= gt; of logical functions to be applied to a subset of packets.<br class=3D"= ">> >> >>>>>>>>> It is equivalent of s= aying that some subset of traffic is<br class=3D"">> >> >>&= gt;>>>>>> to get DPI, charging, content inspection, and f= irewall<br class=3D"">> >> >>>>>>>>> w= hile a different subset is to go directly to the cache<br class=3D"">> = >> >>>>> without<br class=3D"">> >> >>= >>>>>>> visiting any other service functions.<br class= =3D"">> >> >>>>>>>>><br class=3D"">>= ; >> >>>>>>>>> That is not enough informa= tion to direct the packets. A<br class=3D"">> >> >>>>= >>>>> service path is, in some fashion, a sequence of locati= ons<br class=3D"">> >> >>>>>>>>> in th= e network. Those locations will be singular or<br class=3D"">> >>= >>>>>>>>> clustered service function delivery l= ocations. They may be<br class=3D"">> >> >>>>>>= >>> addressed by IP address. They may be addressed as ports on<br = class=3D"">> >> >>>>>>>>> an SFF. Ther= e are many different ways that the locations<br class=3D"">> >> &= gt;>>>>>>>> may be known to the service chaining in= frastructure and the<br class=3D"">> >> >>>>>>&= gt;>> transport.<br class=3D"">> >> >>>>>>= ;>>><br class=3D"">> >> >>>>>>>>= >> From the point of view of the work of the SFC group, we<br class= =3D"">> >> >>>>>>>>>> need to be<br= class=3D"">> >> >>>>>>>>> able to tal= k about the high level abstraction, the service<br class=3D"">> >>= ; >>>>>>>>> chain, which drives the forwarding. = And we need to talk<br class=3D"">> >> >>>>>>&g= t;>> about the actual data path packets will take in the<br class=3D"= ">> >> >>>>>>>>> network.<br class=3D"= ">> >> >>>>>>>>><br class=3D"">> &= gt;> >>>>>>>>> Several of the comments have s= aid "but the whole path may<br class=3D"">> >> >>>>&g= t;>>>> not be known at the front." This architecture deals with= <br class=3D"">> >> >>>>>>>>> that iss= ue in two ways. First, as noted in item (2) on load<br class=3D"">> >= ;> >>>>>>>>> balancers above, there can be de= cisions and behaviors which<br class=3D"">> >> >>>>&g= t;>>>> are invisible to the service chaining mechanisms (in muc= h<br class=3D"">> >> >>>>>>>>> the sam= e way that bridging within a LAN is largely<br class=3D"">> >> &g= t;>>>>>>>> invisible to routing between LANs.) The = other provision we<br class=3D"">> >> >>>>>>>= ;>> make is<br class=3D"">> >> >>>>> that<br= class=3D"">> >> >>>>>>>>> reclassific= ation can be done in mid-chain when necessary.<br class=3D"">> >>= >>>>>>>>> That will direct packets to a new cha= in. Based on<br class=3D"">> >> >>>>>>>>&= gt; information available at the re-classification point.<br class=3D"">>= ; >> >>>>>>>>><br class=3D"">> >&g= t; >>>>>>>>> I hope that this helps explain what= we are after. If it<br class=3D"">> >> >>>>>>&= gt;>> does, and if the intent is acceptable to the working group,<br = class=3D"">> >> >>>>>>>>> we can figur= e out what additional words are needed to<br class=3D"">> >> >= >>>>>>>> convey this. If the working group disagree= with the intent,<br class=3D"">> >> >>>>>>>= >> then we will of course adjust to match the working group<br class= =3D"">> >> >>>>>>>>> agreements. If th= is is still unclear, I am not sure what to<br class=3D"">> >> >= ;>>>>>>>> try next.<br class=3D"">> >> &g= t;>>>>>>>><br class=3D"">> >> >>>= ;>>>>>> Yours, Joel<br class=3D"">> >> >>= >>>>>>><br class=3D"">> >> >>>>&= gt;>>>> _______________________________________________ sfc<br = class=3D"">> >> mailing<br class=3D"">> >> >>>= >>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> <= mailto:sfc@ietf.org><br class=3D"">> >> >>>>>&g= t;>>> https://www.ietf.org/mailman/listinfo/sfc<br class=3D"">>= >> >>>>>>>>><br class=3D"">> >>= ; >>>>>>>>> ____________________________________= ___________ sfc<br class=3D"">> >> mailing<br class=3D"">> &g= t;> >>>>>>>>> list sfc@ietf.org <mailto:sf= c@ietf.org> <mailto:sfc@ietf.org><br class=3D"">> >> >= ;>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc= <br class=3D"">> >> >>>>>>>>><br class= =3D"">> >> >>>>>>>><br class=3D"">> &= gt;> >>>>>>>> __________________________________= _____________ sfc<br class=3D"">> >> mailing<br class=3D"">> = >> >>>>>>>> list sfc@ietf.org <mailto:sfc@= ietf.org><br class=3D"">> https://www.ietf.org/mailman/listinfo/sfc<b= r class=3D"">> >> >>>>>>>><br class=3D"">= > >> >>>>>>><br class=3D"">> >> &g= t;>>>>>> _______________________________________________ = sfc<br class=3D"">> >> mailing<br class=3D"">> >> >&= gt;>>>>> list sfc@ietf.org <mailto:sfc@ietf.org><br cl= ass=3D"">> https://www.ietf.org/mailman/listinfo/sfc<br class=3D"">> = >> >>>>>>><br class=3D"">> >> >>= ;>>>><br class=3D"">> >> >>>>>> ___= ____________________________________________ sfc mailing<br class=3D"">>= >> list<br class=3D"">> >> >>>>>> sfc@i= etf.org <mailto:sfc@ietf.org><br class=3D"">> https://www.ietf.org= /mailman/listinfo/sfc<br class=3D"">> >> >>>>>>= <br class=3D"">> >> >>>>><br class=3D"">> >= > >>>>> _______________________________________________ s= fc mailing<br class=3D"">> >> list<br class=3D"">> >> &= gt;>>>> sfc@ietf.org <mailto:sfc@ietf.org><br class=3D"">= > https://www.ietf.org/mailman/listinfo/sfc<br class=3D"">> >>= >>>><br class=3D"">> >> >>>> ___________= ____________________________________ sfc mailing<br class=3D"">> >&g= t; list<br class=3D"">> >> >>>> sfc@ietf.org <mail= to:sfc@ietf.org><br class=3D"">> https://www.ietf.org/mailman/listinf= o/sfc<br class=3D"">> >> >>>><br class=3D"">> >= ;> >>>> _______________________________________________ sfc = mailing<br class=3D"">> >> list<br class=3D"">> >> >= >>> sfc@ietf.org <mailto:sfc@ietf.org><br class=3D"">> ht= tps://www.ietf.org/mailman/listinfo/sfc<br class=3D"">> >> >&g= t;>><br class=3D"">> >> >>><br class=3D"">> &g= t;> >><br class=3D"">> >> >> _____________________= __________________________<br class=3D"">> >> >> sfc mailin= g list<br class=3D"">> >> >> sfc@ietf.org <mailto:sfc@ie= tf.org><br class=3D"">> >> >> https://www.ietf.org/mailm= an/listinfo/sfc<br class=3D"">> >> >><br class=3D"">> &= gt;> ><br class=3D"">> >> >_____________________________= __________________<br class=3D"">> >> >sfc mailing list<br cla= ss=3D"">> >> >sfc@ietf.org <mailto:sfc@ietf.org><br clas= s=3D"">> >> >https://www.ietf.org/mailman/listinfo/sfc<br clas= s=3D"">> >><br class=3D"">> >> ________________________= _______________________<br class=3D"">> >> sfc mailing list<br cl= ass=3D"">> >> sfc@ietf.org <mailto:sfc@ietf.org><br class= =3D"">> >> https://www.ietf.org/mailman/listinfo/sfc<br class=3D"= ">><br class=3D"">> _______________________________________________<b= r class=3D"">> sfc mailing list<br class=3D"">> sfc@ietf.org <mail= to:sfc@ietf.org><br class=3D"">> https://www.ietf.org/mailman/listinf= o/sfc<br class=3D"">><br class=3D"">><br class=3D"">><br class=3D"= ">> _______________________________________________<br class=3D"">> s= fc mailing list<br class=3D"">> sfc@ietf.org<br class=3D"">> https://= www.ietf.org/mailman/listinfo/sfc<br class=3D"">><br class=3D""> ------=_Part_3495_519811699.1405109867599-- From nobody Fri Jul 11 18:35:47 2014 Return-Path: <sbarkai@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040541A0AB6 for <sfc@ietfa.amsl.com>; Fri, 11 Jul 2014 18:35:44 -0700 (PDT) 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 xGld58-TK4Zz for <sfc@ietfa.amsl.com>; Fri, 11 Jul 2014 18:35:39 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08A81A0123 for <sfc@ietf.org>; Fri, 11 Jul 2014 18:35:39 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id z6so599225yhz.22 for <sfc@ietf.org>; Fri, 11 Jul 2014 18:35:39 -0700 (PDT) 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=1hTjERuapPLYwURjw6dV/4RiUejWy5tdg79CD+TZEWo=; b=kHbO+Az6bEdLJHff987bdK8+3jwsY4YwA3KsdXTHdufpVFpRRvdIGEJDCAITNc/UGJ bJRrp8W57WEw7maiLFGrjf2rKBwovc1yEX7ftUX/P3MZi5oA0ySYqsbZ1ikjPQVnt8RZ zaEm16LqraUp2eTNMdJPKj6VtaXTsOObo17vB63PhKJC+qrQlOoopCXrEvW/hBnOnXVQ zPqdDdq0D0mc7vNqe1uLHomjy68YN9i0MleNuyaze3U8yGu0Wkg0/NMH4p+6qc4JdaRX brT7A9tTiNQPfqCwo0cjWNUsabMxzHEUo3jaFc3G7MXN5rFCd7HFw+c0n+vFAsLSPYTQ 7ENQ== X-Received: by 10.236.36.45 with SMTP id v33mr3720028yha.129.1405128938975; Fri, 11 Jul 2014 18:35:38 -0700 (PDT) Received: from [192.168.1.102] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id c58sm8512616yho.27.2014.07.11.18.35.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 18:35:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon <sbarkai@gmail.com> X-Mailer: iPhone Mail (11D257) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se> Date: Fri, 11 Jul 2014 18:35:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se> To: Eric Gray <eric.gray@ericsson.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MWQ8IH99AMtp3SI405DKoeh0GUE Cc: "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 01:35:44 -0000 Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates, t= hen all is left is for the architecture to emerge these SFFs as one distribu= ted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environmen= ts both in terms of capacity and in term of the functional procedures. No ce= ntralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: >=20 > Maria, >=20 > So many fundamental problems. What to do? >=20 > I didn't suggest "leaving it to implementation." I merely suggested that e= ach IETF > working group needs to focus on a set of problems they can solve in a reas= onable > amount of time, without having to boil any oceans. >=20 > Joel suggested an architectural approach that would allow any form of dist= ribution > you might want, without requiring every solution to support all possibilit= ies, and > without impacting the ability of solutions to be optimized for whatever de= ployment > scenario may apply in any specific case. >=20 > Working out ways to optimize your particular deployment model seems to be y= our > problem (with support from your suppliers - whoever they might be) and - i= t seems > to me - the burden of making sure that the standards we define allows opti= mization > for that deployment falls on you (and them). >=20 > Meanwhile, other providers and other vendors may seek to ensure that whate= ver > we define allows at least some degree of optimization for their deployment= s. >=20 > This is the process. >=20 > Is the architectural proposal Joel came up with sufficient as a starting p= oint? >=20 > -- > Eric >=20 > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=20 > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High >=20 > Eric, >=20 >> Load distribution is not the same as service function chaining and -=20 >> while there may be problems to solve in this area - why would we=20 >> assume that SFC is supposed to solve them? >=20 > Because this is the fundamental problem in service chaining in virtualized= environments. =20 > I would be cautious to leave it just to implementation because if fundamen= tals are wrong implementation might not be able to help. >=20 >> I think SFC should be more concerned about ensuring that function=20 >> chaining solutions do not preclude load distribution. >=20 > How would you ensure it? >=20 >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA=20 >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>=20 >> One of the main problems in "service chains" is how to implement a=20 >> service that is conceptually one hop but scaled horizontally as 10 or=20 >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >>=20 >> Maria >>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> I should clarify that my statement was made as a personal opinion=20 >>> and it is up to the WG to evaluate if there exists anything at the=20 >>> architectural level that is new and therefore needs to be addressed. >>>=20 >>> Sent from my iPhone >>>=20 >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>>=20 >>>> Jim, >>>>=20 >>>> Respectfully, I'm not comfortable with that. While it is easy to say t= hat >>> this is a layered problem and that load balancing belongs at a lower=20 >>> level, it seems to me that load balancing of the service functions=20 >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also w= ith >>> resiliency in mind. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> I would say that's implementation. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>=20 >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> Well of course not; in that case you load balance up a level=20 >>>>> between >>> those nodes and then locally. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>>=20 >>>>>> Jim, >>>>>>=20 >>>>>> There may not be a single node through which all of the=20 >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim=20 >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> At the node through which the 20 instances are reachable. IOW=20 >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>>=20 >>>>>>> Hi Jim, >>>>>>>=20 >>>>>>> When you say "locally", where is it? >>>>>>>=20 >>>>>>> Maria >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>=20 >>>>>>>> Hi Maria, >>>>>>>>=20 >>>>>>>> Absolutely and categorically no! If you have 20 instances at=20 >>>>>>>> each hop then you can choose to load balance among them=20 >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is=20 >>>>>>>> that if for some very odd and certainly not recommended reason=20 >>>>>>>> you want to treat each instance separately then the=20 >>>>>>>> architecture does not >>> prevent it. >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed=20 >>>>>>>>>> separately, then the service chaining infrastructure would=20 >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>>=20 >>>>>>>>> If I have a 4 hop service chain with 20 instances at each=20 >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)?=20 >>>>>>>> Well, we have yet to see a solution that work this way and scales..= >>>>>>>>>=20 >>>>>>>>> Maria >>>>>>>>>=20 >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall=20 >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you=20 >>>>>>>>>> will decide (make a load balancing decision) at the entry to=20 >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>>=20 >>>>>>>>>>> Maria >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=20 >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load=20 >>>>>>>>>>>> Balancers >>>>>>>>>>>>=20 >>>>>>>>>>>> The archtiecture allows for this local decision, while=20 >>>>>>>>>>>> still having the global decision that is directing the traffic.= >>>>>>>>>>>> That is, the global decision directs the traffic to places=20 >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of=20 >>>>>>>>>>>> algorithms to distribute the traffic internally, without=20 >>>>>>>>>>>> any effect on service chaining. (And yes, this can be=20 >>>>>>>>>>>> done in such a way that return traffic, if delivered=20 >>>>>>>>>>>> globally to the same place, can then be delivered to the=20 >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>>=20 >>>>>>>>>>>> The definition of the service path is about how service=20 >>>>>>>>>>>> chaining will direct the traffic. it is not about how the=20 >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to=20 >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>>=20 >>>>>>>>>>>> We could write the architecture pretending that it always=20 >>>>>>>>>>>> addresses singular instances, but knowing that reality=20 >>>>>>>>>>>> would allow load balanced clusters at those locations. =20 >>>>>>>>>>>> But that would be a misleading architectural description=20 >>>>>>>>>>>> and might be read to outlaw some solutions that fall=20 >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators=20 >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC=20 >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of=20 >>>>>>>>>>>>>> service function identifiers). This is more compliant=20 >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local=20 >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Maria >>>>>>>>>>>>=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 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 11 19:14:15 2014 Return-Path: <kegray@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B701A00F8 for <sfc@ietfa.amsl.com>; Fri, 11 Jul 2014 19:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.363 X-Spam-Level: X-Spam-Status: No, score=-12.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 SezdV4IEuV5r for <sfc@ietfa.amsl.com>; Fri, 11 Jul 2014 19:14:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299291A00DC for <sfc@ietf.org>; Fri, 11 Jul 2014 19:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7956; q=dns/txt; s=iport; t=1405131252; x=1406340852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cZ0LXQL3WNud1cUz08bIPu/lJGCCjRQMi5vFCjgqOaw=; b=M7MCGtO/8Nj089+5/EbASP53cv/DjNy3/9Z2x4m6b/lzpFoGIc2lDP14 xjwK5nc4Oa2KoayUvLVAmz2xt44JUNnv8cmruitULhV7xV9+mrUoS9LrC Vy9ZZw9NqfAIEKrtmMD7HOLV7jnhWkNGYM8kKcT3ArmLy8HRUgbTS26qP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEGZwFOtJA2D/2dsb2JhbABZgw5Sg0u+QQyHQQEZcRZ1hAMBAQEDAQEBATE6CwUHBAIBBgIOAwQBAQEEIwUCAiULFAkIAgQOBQkSiB8IDZFJnCEImDwXgSiNPTEYGwcGgm06gRYBBJsFgUqSUoNEgW4 X-IronPort-AV: E=Sophos;i="5.01,647,1400025600"; d="scan'208";a="339495476" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2014 02:14:11 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6C2EB56012861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Jul 2014 02:14:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 21:14:10 -0500 From: "Ken Gray (kegray)" <kegray@cisco.com> To: Qin Wu <bill.wu@huawei.com> Thread-Topic: draft-wu-pce-traffic-steering-sfc-04 Thread-Index: AQHPmxzb7qK3d3xA0EGKphRP2OMpJ5uXBEZAgASzb2U= Date: Sat, 12 Jul 2014 02:14:10 +0000 Message-ID: <3F7F9B7F-2100-4873-9246-06747CF87CE9@cisco.com> References: <CFE21C68.39402%kegray@cisco.com>, <B8F9A780D330094D99AF023C5877DABA84580AA2@nkgeml501-mbs.china.huawei.com> In-Reply-To: <B8F9A780D330094D99AF023C5877DABA84580AA2@nkgeml501-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lJeee3MBhojm1db_hv9JNSBgH0o Cc: Dhruv Dhody <dhruv.dhody@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com> Subject: Re: [sfc] draft-wu-pce-traffic-steering-sfc-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 02:14:14 -0000 SSdtIG5vdCBjb252aW5jZWQgdGhhdCB5b3UgbmVlZCB0aGF0LCB0byBiZSBob25lc3QuICBJdCBz ZWVtcyB0aGF0IHRoZSBuZWVkIGZvciBleHRlbnNpb25zIGlzIHRpZWQgdG8gdGhlIGFzc3VtcHRp b24gdGhhdCB5b3UgbmVlZCBzb21lIHNvcnQgb2Ygc3BlY2lhbCBsYWJlbCB0byBpbmRpY2F0ZSB0 aGF0IGFuIG92ZXJsYXkgaW5zdGFuY2UgKExTUCwgU1IgU0lELCBldGMpIHdhcyBjcmVhdGVkIHRv IGJlIGEgc2VydmljZSBwYXRoIC0gYnV0IEkganVzdCBkb24ndCBzZWUgdGhhdCBhcyBhIHJlcXVp cmVtZW50LiAgSXRzIGFscmVhZHkgbGFiZWxlZCAoYXMgdHVubmVseCBvciBTSUQgdmFsdWUgeSBv ciBOZXh0SG9weikgYW5kIHRoZSBhc3NvY2lhdGlvbiBhcyBhIFNQIGNhbiBiZSBtYWludGFpbmVk IGVsc2V3aGVyZSAobGlrZSBzZmMgY29udHJvbC9tYW5hZ2VtZW50IGFwcCkuICBUbyBtZSwgaXQg c2VlbXMgbW9yZSBvZiBhIGNvbnZlbmllbmNlIHRoYW4gYSBuZWNlc3NpdHkuDQoNClNlbnQgZnJv bSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgOCwgMjAxNCwgYXQgMTA6MzUgUE0sICJRaW4gV3UiIDxi aWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gTm90IG9ubHkgaW5kaWNhdGUgaXQgaXMg YW4gU0ZQLCBidXQgYWxzbyB5b3UgbmVlZCB0byB0ZWxsIGNsYXNzaWZpZXIgd2hpY2ggc2Vydmlj ZSBmdW5jdGlvbiBwYXRoIHlvdSBuZWVkIHRvIGluc3RhbnRpYXRlPw0KPiBXaXRob3V0IHNlcnZp Y2UgZnVuY3Rpb24gcGF0aCBJRCwgaG93IGRvIHlvdSBrbm93IHdoaWNoIHBhdGggeW91IG5lZWQg dG8gY3JlYXRlLCB3aGljaCBwYXRoIHlvdSBuZWVkIHRvIHVwZGF0ZSAsd2hpY2ggcGF0aCB5b3Ug bmVlZCB0byBkZWxldGU/DQo+IA0KPiBSZWdhcmRpbmcgd2hlcmUgdG8gcHV0IFNGUCwgSSB0aGlu ayBhdCBsZWFzdCBjbGFzc2lmaWVyIHNob3VsZCBtYWludGFpbiBwYXRoIGluZm9ybWF0aW9uIHdo aWNoIHVzZSBTRlAgSUQgdG8gZGlzdGluY3Qgb25lIHBhdGggZnJvbSBhbm90aGVyLA0KPiBZb3Ug bWF5IHB1dCBpdCBpbnRvIHdoYXRldmVyIG92ZXJsYXkgaGVhZGVyIHlvdSB3YW50IHRvIHVzZS4g SWYgeW91IHRoaW5rIGl0IGlzIGEgYnVyZGVuLCB5b3UgY2FuIGNob29zZSBub3QgcHV0IGl0IGlu dG8gdGhlIG92ZXJsYXkgaGVhZGVyIGFuZCANCj4gdXNlIG90aGVyIHNpZ25hbGluZyB0byBzZXR1 cCBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGgsIGUuZy4sIHlvdSBoYXZlIFNETiBjb250cm9sbGVyIG9y IHlvdSBoYXZlIE5NUy9PU1MsIE5NUy9PU1Mgd2lsbCB0cmFuc2xhdGUgU2VydmljZSBmdW5jdGlv biBjaGFpbg0KPiBpbnRvIHBhdGggaW5mb3JtYXRpb24gYmFzZWQgb24gU0ZQIElEIGFuZCBwb3B1 bGF0ZSBzdWNoIHBhdGggaW5mb3JtYXRpb24gd2l0aCBTRlAgSUQgdG8gZWFjaCBwYXJ0aWNpcGF0 aW5nIG5vZGUgaW4gdGhlIHNlcnZpY2UgY2hhaW4uDQo+IEFsbCBpbiBhbGwsIGFzIEkgY2xhcmlm aWVkIGVhcmxpZXIsIFNGUCBJRCBiYXNlZCBzb2x1dGlvbiBkb2Vzbid0IGNvdXBsZSB3aXRoIHRo ZSBzaWduYWxpbmcgeW91IGFyZSB1c2VkLg0KPiANCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAtLS0t LdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3Jh eUBjaXNjby5jb21dIA0KPiC3osvNyrG85DogMjAxNMTqN9TCOcjVIDEwOjI0DQo+IMrVvP7Iyzog UWluIFd1OyBSb24gUGFya2VyOyBMaW5kYSBEdW5iYXI7ICdzZmNAaWV0Zi5vcmcnDQo+INb3zOI6 IFJFOiBkcmFmdC13dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1zZmMtMDQNCj4gDQo+IEkgaGFkIGEg Y291cGxlIHF1ZXN0aW9ucyBvbiB0aGlzIKGtDQo+IA0KPiBJZiB0aGUgcG9pbnQgaXMgdGhhdCBh IFBDRSBjb3VsZCBjb21wdXRlIHRoZSBwYXRoIGJhc2VkIG9uIGEgcG9saWN5LCB3ZSdyZSBwcm9i YWJseSBhbGwgaW4gYWdyZWVtZW50LiBXaGVyZSBJIGdldCBsb3N0IGlzIGluIHRoZSBuZWVkIGZv ciB0aGUgVExWIGV4dGVuc2lvbiB0byBpbmRpY2F0ZSBpdCdzIGFuIFNGUC4gIFRoYXQgZmFjdCB3 b3VsZCwgSU1PLCBiZSBtYW5hZ2VkIGF0IGEgaGlnaGVyIGxldmVsIC0gYXMgaXQgd291bGQgYmUg Zm9yIGFueSBvdmVybGF5IGNvbnN0cnVjdCAoVlhMQU4sIEdSRSwgeW91ci1mYXZvcml0ZS1vdmVy bGF5LWVuY2FwLWhlcmUpLiAgSXQgYXBwZWFycyBhbiB1bm5lY2Vzc2FyeSBpbmZvcm1hdGlvbmFs IGJ1cmRlbiwgSU1PLiAgQ2FuIHlvdSBleHBsYWluIGhvdyB5b3UgZW52aXNpb24gdGhpcyBiZWlu ZyB1c2VkPw0KPiANCj4+IE9uIDcvNy8xNCA5OjEyIEFNLCAiUWluIFd1IiA8YmlsbC53dUBodWF3 ZWkuY29tPiB3cm90ZToNCj4+IA0KPj4gUm9uOg0KPj4gV2UgYWxzbyBoYXZlIGRyYWZ0IHRvIGRp c2N1c3MgaG93IHRvIGluc3RhbnRpYXRlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCANCj4+IHVzaW5n IFBDRS1pbml0aWF0ZSBMU1AgaW5zdGFudGlhdGlvbi4NCj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0wNA0KPj4gSXQgc3VwcG9y dHMgZHluYW1pYyBjcmVhdGlvbiBhbmQgZGVsZXRpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRo Lg0KPj4gWW91ciBtYXkgY2hlY2sgb3V0Lg0KPj4gDQo+PiBSZWdhcmRzIQ0KPj4gLVFpbg0KPj4g LS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFJvbiBQYXJrZXINCj4+ILeiy83KsbzkOiAyMDE0xOo31MI3yNUgMjA6NTIN Cj4+IMrVvP7IyzogTGluZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0KPj4g1vfM4jogUmU6IFtz ZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1kdW5iYXItc2ZjLWZ1 bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQo+PiANCj4+IExpbmRhICYgQW5keSwNCj4+ IA0KPj4gVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIuICAgSSdtIGhhcHB5IHRvIHNl ZSBtb3JlIHdvcmsgb24gdGhlDQo+PiAiY2hhaW4tdG8tcGF0aCIgdG9waWMuICAgSSBhZ3JlZSB3 aXRoIGFsbCBvZiB5b3VyIGFuYWx5c2lzIHJlZ2FyZGluZw0KPj4gcHJvcy9jb25zIG9mIHZhcmlv dXMgYXBwcm9hY2hlcy4gICAgIEVuY2Fwc3VsYXRpb24gYW5kIENvbnRyb2wgUGxhbmUgd2lsbA0K Pj4gYmUgZGVwZW5kZW50IG9uIG91ciBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucyBpbiB0aGlzIGFy ZWEuICAgVGhlIGVsdXNpdmUNCj4+IHRoaW5nIGZvciBhbGwgb2YgdXMsIGFzIGEgZ3JvdXAsIGlz IHRvIGNvbWUgdG8gc29tZSBjb25jbHVzaW9ucyENCj4+IA0KPj4gIFJvbg0KPj4gDQo+PiANCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1bmJhcg0KPj4gU2VudDogRnJpZGF5 LCBKdWx5IDA0LCAyMDE0IDQ6NDkgUE0NCj4+IFRvOiAnc2ZjQGlldGYub3JnJw0KPj4gU3ViamVj dDogW3NmY10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1kdW5i YXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQo+PiANCj4+IEhpLA0KPj4g DQo+PiBUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgZnJhbWV3b3JrIG9mIHByb3RlY3Rpb24gYW5k IHJlc3RvcmF0aW9uIG9mDQo+PiAgU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29t ZSBpbnN0YW5jZXMgb24gdGhlIHBhdGggZmFpbCBvcg0KPj4gIG5lZWQgdG8gYmUgcmVwbGFjZWQu DQo+PiANCj4+IEFwcHJlY2lhdGUgdG8gaGVhciB5b3VyIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25z Lg0KPj4gDQo+PiBMaW5kYSAmIEFuZHkNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj4+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMzAsIDIwMTQgMTE6MjUg QU0NCj4+IFRvOiBBbmRyZXcgRy4gTWFsaXM7IExpbmRhIER1bmJhcjsgQW5kcmV3IEcuIE1hbGlz OyBMaW5kYSBEdW5iYXINCj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IN Cj4+IGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCj4+ IA0KPj4gDQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5z dGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBMaW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj4+IHJlcG9zaXRv cnkuDQo+PiANCj4+IE5hbWU6ICAgICAgICBkcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMt cmVzdG9yYXRpb24NCj4+IFJldmlzaW9uOiAgICAwMA0KPj4gVGl0bGU6ICAgICAgICBGcmFtZXdv cmsgZm9yIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIFJlc3RvcmF0aW9uDQo+PiBEb2N1bWVu dCBkYXRlOiAgICAyMDE0LTA0LTI5DQo+PiBHcm91cDogICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPj4gUGFnZXM6ICAgICAgICAxMg0KPj4gVVJMOiAgICAgICAgICAgIA0KPj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFu Y2VzLXJlc3QNCj4+IG9yYQ0KPj4gdGlvbi0wMC50eHQNCj4+IFN0YXR1czogICAgICAgICANCj4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWR1bmJhci1zZmMtZnVuLWlu c3RhbmNlcy1yZXN0b3JhDQo+PiB0aW8NCj4+IG4vDQo+PiBIdG1saXplZDogICAgICAgDQo+PiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMt cmVzdG9yYXRpb24tMA0KPj4gMA0KPj4gDQo+PiANCj4+IEFic3RyYWN0Og0KPj4gIFRoaXMgZHJh ZnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24g b2YNCj4+ICBTZXJ2aWNlIENoYWluIEluc3RhbmNlIFBhdGggd2hlbiBzb21lIGluc3RhbmNlcyBv biB0aGUgcGF0aCBmYWlsIG9yDQo+PiAgbmVlZCB0byBiZSByZXBsYWNlZC4NCj4+IA0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCANCj4+IHRvb2xzLmlldGYub3Jn Lg0KPj4gDQo+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4g c2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQo= From nobody Sat Jul 12 07:15:30 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730511B28CE for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eXvbmBpKaDxQ for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 07:15:24 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACABE1A03B9 for <sfc@ietf.org>; Sat, 12 Jul 2014 07:15:24 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id ED10D53E12; Sat, 12 Jul 2014 07:13:27 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 12 Jul 2014 07:13:27.921 -0700 x-echoworx-msg-id: 4a8eb190-38bc-435b-9706-ee10d7b0704f x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 710; Sat, 12 Jul 2014 07:13:27 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id CB5EF53E12; Sat, 12 Jul 2014 07:13:27 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 07:15:23 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Sharon <sbarkai@gmail.com>, Eric Gray <eric.gray@ericsson.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKYCAgAABkICAAAXiAIABxGYAgABmtQCAAF191w== Date: Sat, 12 Jul 2014 14:15:23 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com> In-Reply-To: <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/p0rYbOrXGWZ5kRJZbbElXvXkqlU Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "sfc@ietf.org" <sfc@ietf.org>, "NAPIERALA, MARIA H" <mn1921@att.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 14:15:27 -0000 Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Sat Jul 12 07:28:00 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8EE1B28EB for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 07:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 Kl_-7aDpZcXa for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 07:27:53 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FE61A0103 for <sfc@ietf.org>; Sat, 12 Jul 2014 07:27:53 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id D9BB953E1C; Sat, 12 Jul 2014 07:27:51 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 12 Jul 2014 07:27:51.819 -0700 x-echoworx-msg-id: 8057d09c-db2a-4831-b548-e7afac3b8225 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 797; Sat, 12 Jul 2014 07:27:51 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id AF04653E1C; Sat, 12 Jul 2014 07:27:51 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 07:27:52 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Lucy yong <lucy.yong@huawei.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuY4UOwgAD+dgCAAEJogIAAEcsAgAACqYCAAAXpAIAAAr6AgAAD/4CAAADcAIAAAwUAgAAPmoCAAAFcgP//wGdrgAB6MgCAAAOjgIAAAjgAgAAd6YCAAKBUgIAABfOAgAABjQCAAAFTAIAABWsAgAADjwCAAAfRAIAABG2AgAADYACAAAfYAIAACM0AgAABWYCAAAG3AIAAAb2AgAALNQCAAOpWxQ== Date: Sat, 12 Jul 2014 14:27:52 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6363@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE588EF.2D565%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE58BE8.2D5A2%jguichar@cisco.com>, <2691CE0099834E4A9C5044EEC662BB9D453BF11D@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BF11D@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BdLS-Dx8QT6d0b7WB_pMzEsJrTU Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 14:28:00 -0000 Hi, Lucy. I've heard next hop mentioned many times and I'm not sure that the term is = really valid here. There seems to be an assumption that routing is implic= itly involved, but it is possible that the service overlay resides on a pur= ely switched infrastructure. Even if the service overlay resides on a rou= ted infrastructure, that routing is abstracted in the typical layered fashi= on. For SFC, the issue is to select the next SFF or select the next SFI. = Once that selection is made, routing takes over. But knowing that SFF-B= could serve as a backup to SFF-A is above the routing layer (or at least c= ould be in some implementations). Perhaps we could introduce a term like = next-service-hop or next-SFC-hop to make this distinction? Ron ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.c= om] Sent: Friday, July 11, 2014 1:23 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I like to restate my opinion. The arch doc. should not mandate only use of service path identifier to dri= ve the forwarding actions, i.e. the forwarding lookup. Although some solution draft proposes that and some people like Paul and Ji= m as co-author of the draft (nsh) explain that, that is one solution design= . The arch doc clearly states that it does not propose the solutions. In fact, draft-nui-sfc-mechanism proposes another way to implement SFC whic= h uses both service path identifier and SF ID in forwarding actions. People also proposed the solution on mail discussion that does not use the = service path identifier to drive the forwarding actions. So we should not = make a solution assumption in arch doc. BTW: IMO, we should separate the forwarding actions and load balance action= s. Load balancing discussed here happens when several next hops exist after= forwarding lookup. (this is not about load balancing as a SF). Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, July 11, 2014 11:44 AM To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. Halpern; Ron = Parker; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I am not proposing a solution (that=92s the WG=92s job) but simply using my= interpretation of the architecture to move the discussion forward. Yes, it is still a service path identifier for the reasons that Joel mentio= ned in another email. On 7/11/14, 12:37 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote: >> >> I think of it this way. The service path identifier is simply a >>pointer >> >>to >> >> a data structure that contains SF to next-hop mappings. When you >> define >> >You are talking about traffic engineering of paths that a service >> >chain can take. >> >This surely could be done/allowed but this cannot be a requirement >> >for all traffic. >> >> Jim> that=92s why I said *might* - IOW you do not have to, its a >>deployment >> choice and is supported by the architecture. > >Yes, I noticed, but I also noticed that you are proposing a solution >based on it. > >You have not comment on the rest: is it still "service *path* identifier"? > >Maria > >> >> On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> wrote: >> >> >> >> >Jim, >> >> > >> >> >Could you tell us what is the definition of a "service path" and >> >> >a "service path identifier"? >> >> >If a service path means that all SF instances are chosen apriori >> >>(which >> >> >is my current understanding) then it is not SFF's local decision >>which >> >> >next-hop SFF to pick. It is a centralized decision. >> >> > >> >> >Maria >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> >> Sent: Friday, July 11, 2014 11:15 AM >> >> >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. >> >> >> Halpern; Ron Parker; sfc@ietf.org >> >> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >> >> I=92m sorry but I really don=92t understand why a service path >>identifier >> >> >> prevents full distribution of SF next-hops or why calling it a >> >>service >> >> >> chain identifier makes any difference? >> >> >> >> >> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> >> wrote: >> >> >> >> >> >> >Ditto. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: mohamed.boucadair@orange.com >> >> >> >> [mailto:mohamed.boucadair@orange.com] >> >> >> >> Sent: Friday, July 11, 2014 10:31 AM >> >> >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. >>Halpern; >> >> Ron >> >> >> >> Parker; sfc@ietf.org >> >> >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >> >> >> >> Re-, >> >> >> >> >> >> >> >> For what I can say at best this is not described clearly in >> >> >> >> the >> >> >>draft. >> >> >> >> >> >> >> >> Mandating a service path identifier is in itself a hint that >>the >> >>full >> >> >> >>distributed >> >> >> >> model is not allowed. >> >> >> >> >> >> >> >> Several voices in this thread indicated that the service >> >> >> >> chain >> >>itself >> >> >> >>should be >> >> >> >> provided instead. >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Med >> >> >> >> >> >> >> >> >-----Message d'origine----- De : sfc >> >> >> >> >[mailto:sfc-bounces@ietf.org] De la part de Jim >>Guichard >> >> >> >> >(jguichar) >> >> >> >> >Envoy=E9 : vendredi 11 juillet 2014 16:18 =C0 : NAPIERALA, >> >> >> >> >MARIA H; Joel M. Halpern; Ron Parker; >> sfc@ietf.org >> >> >> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> > >> >> >> >> >Ok but where in the architecture specifically is this >> >>functionality >> >> >> >> >prohibited? If you want to distribute *all* next-hops to >> >> >> >> >*all* >> >>SFF=92s >> >> >> >> >within the SFC domain and then let the path identifier >> >> >> >> >point >>to a >> >> >> >>lookup >> >> >> >> >into those next-hops to reach the next SF in the chain, I >> >> >> >> >am >>not >> >> >>sure >> >> >> >>how >> >> >> >> >the architecture prevents that? >> >> >> >> > >> >> >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> >> >> wrote: >> >> >> >> > >> >> >> >> >>Absolutely. >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >> >>Guichard >> >> >> >> >>>(jguichar) >> >> >> >> >>> Sent: Friday, July 11, 2014 9:54 AM >> >> >> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; >> >> sfc@ietf.org >> >> >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load >>Balancers >> >> >> >> >>> >> >> >> >> >>> Then I misunderstand the proposal ;-) .. However, it >> >> >> >> >>> seems >>to >> >>me >> >> >> >>that if >> >> >> >> >>> you allow an SFF to make a decision as to which remote >> >> >> >> >>> SFF >>it >> >> >>will >> >> >> >>use >> >> >> >> >>>for >> >> >> >> >>> a given flow to reach the next SF within the chain then >> >> >> >> >>>you >> >> >>better >> >> >> >>make >> >> >> >> >>> sure that that remote SFF has the necessary forwarding >>logic >> >>to >> >> >> >>reach >> >> >> >> >>>the >> >> >> >> >>> next-next-SF for the chain as otherwise you are in deep >> >>trouble. >> >> >> >> >>> >> >> >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" >> <mn1921@att.com> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>> >Absolutely not. Service chains can be instantiated only >> >> >> >> >>> >in >> >> >>relevant >> >> >> >> >>>SFFs >> >> >> >> >>> >when they "arrive". >> >> >> >> >>> > >> >> >> >> >>> >> -----Original Message----- >> >> >> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> >> >> >> >>> >> Jim >> >> >>Guichard >> >> >> >> >>> >>(jguichar) >> >> >> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM >> >> >> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >> >> >> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load >> >>Balancers >> >> >> >> >>> >> >> >> >> >> >>> >> Well I think it is even worse than that if I have >> >>understood >> >> >>the >> >> >> >> >>> >>proposal >> >> >> >> >>> >> correctly as it would require full knowledge of every >> >>single >> >> >>SF >> >> >> >> >>>within >> >> >> >> >>> >>the >> >> >> >> >>> >> entire SFC domain at every single SFF as there is no >>way to >> >> >>know >> >> >> >>a >> >> >> >> >>> >>priori >> >> >> >> >>> >> which SFC=B9s a given SFF will need to service at any >>given >> >> >>point >> >> >> >>in >> >> >> >> >>>time. >> >> >> >> >>> >> >> >> >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" >> >> <jmh@joelhalpern.com> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >> >>> >> >Ron, thinking about this, I realized another major >>problem >> >> >>with >> >> >> >>the >> >> >> >> >>> >>your >> >> >> >> >>> >> >proposal as I understand it. (And I readily admit I >>may >> >>not >> >> >> >> >>>understand >> >> >> >> >>> >> >it.) >> >> >> >> >>> >> > >> >> >> >> >>> >> >The proposal has each SFF serve as the load balancer >>for >> >>the >> >> >> >>next >> >> >> >> >>> >> >service function that follows it (not the one it >>delivers >> >> >>to), >> >> >> >>in >> >> >> >> >>>every >> >> >> >> >>> >> >service chain that goes through it. >> >> >> >> >>> >> > >> >> >> >> >>> >> >Since it has to be able to work with all services, >> >> >> >> >>> >> >that >> >>means >> >> >> >>that >> >> >> >> >>> >>every >> >> >> >> >>> >> >SFF would have to be a full, flow sensitive and >>stateful >> >>load >> >> >> >> >>>balancer. >> >> >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, >> >> >> >> >>> >> >and >>/ or >> >> >> >>stateful. >> >> >> >> >>> >> >But having the architecture require that every SFF >> >> >> >> >>> >> >be a >> >>full, >> >> >> >>flow >> >> >> >> >>> >> >sensitive, stateful, load balancer seems to me to be >> >> >> >> >>> >> >an >> >> >> >>acceptable >> >> >> >> >>> >> >imposition. >> >> >> >> >>> >> > >> >> >> >> >>> >> >Yours, >> >> >> >> >>> >> >Joel >> >> >> >> >>> >> > >> >> >> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >> >> >> >>> >> >> Part of my personal view is that I am trying to >> >> >> >> >>> >> >> make >> >>this >> >> >>work >> >> >> >> >>> >>sensibly >> >> >> >> >>> >> >> in a more orchestrated environment. I expect that >>the >> >> >>service >> >> >> >> >>> >> >> functions, and over time probably the SFF >>capabilities, >> >> >>will >> >> >> >>be >> >> >> >> >>> >> >> orchestrated and installed. I expect the service >>chains >> >> >>to be >> >> >> >> >>> >>driven by >> >> >> >> >>> >> >> BSS tools that define offerings to clients, and >>enable >> >> >> >> >>>self-selection >> >> >> >> >>> >> >> from these. I expect service paths to be heavily >>policy >> >> >> >>drive. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> I can see how to make all of that work in an >> >>archtiecture >> >> >> >>driven >> >> >> >> >>>by >> >> >> >> >>> >> >> initial classification to described service paths. >>It >> >>is >> >> >> >>harder >> >> >> >> >>>to >> >> >> >> >>> >>see >> >> >> >> >>> >> >> how to make it work (but it can be done) when we >>allow >> >> more >> >> >> >> >>> >> dynamicity >> >> >> >> >>> >> >> in the network behavior. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Having said that, most of that perspective I >>described >> >>is >> >> >> >>outside >> >> >> >> >>>of >> >> >> >> >>> >>the >> >> >> >> >>> >> >> scope of the working group. it is not something >> >> >> >> >>> >> >> we >>are >> >> >> >>tasked to >> >> >> >> >>> >>agree >> >> >> >> >>> >> >>on. >> >> >> >> >>> >> >> So I do not claim that vision means we have to do >> >> >> >> >>> >> >>it >>a >> >> >>certain >> >> >> >> >>>way. >> >> >> >> >>> >>it >> >> >> >> >>> >> >> is just the perspective that drives my preferences. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Yours, >> >> >> >> >>> >> >> Joel >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >> >> >> >>> >> >>>> For me, the amount of information about service >> >> instances >> >> >> >> that >> >> >> >> >>> >>needs >> >> >> >> >>> >> >>>>to >> >> >> >> >>> >> >>>> be widely distributed and maintained, >> >> >> >> >>> >> >>>>potentially >> even >> >> >> >>across >> >> >> >> >>>data >> >> >> >> >>> >> >>>> centers within an administrative scope, is large >> >>enough >> >> >>and >> >> >> >> >>> complex >> >> >> >> >>> >> >>>> enough that trying to get that into each SFF >> >> >> >> >>> >> >>>> seems >> >>like a >> >> >> >> >>>difficult >> >> >> >> >>> >> >>>> architecture to realize. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> I'm curious as to why that is more complicated >> >> >> >> >>> >> >>> than >> >> >>dynamic >> >> >> >> >>> routing, >> >> >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, >> >> >> >> >>> >> >>> all >>of >> >> >>which >> >> >> >>are >> >> >> >> >>> >>bigger >> >> >> >> >>> >> >>> problems that have been profitably and stably >> >> implemented? >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> It also seems that if it really is more >> >> >> >> >>> >> >>> complicated, >> >>that >> >> >>is >> >> >> >>a >> >> >> >> >>>good >> >> >> >> >>> >> >>> sign that it is too complicated. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> ________________________________________ >> >> >> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com] >> >> >> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >> >> >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; >> mikebianc@aol.com; >> >> >>Ian >> >> >> >> >>>Smith; >> >> >> >> >>> >> >>> sfc@ietf.org >> >> >> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and >> >> >> >> >>> >> >>> Load >> >> >>Balancers >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> This is an architectural issue. And one that I >>would >> >> >>prefer >> >> >> >>we >> >> >> >> >>> >> >>>actually >> >> >> >> >>> >> >>> decide, rather than trying to allow all possible >> >> >> >>implementations. >> >> >> >> >>> >> >>> Because it does have a major effect on the >> >> >> >> >>> >> >>> control >> >> >> >>requirements >> >> >> >> >>>and >> >> >> >> >>> >> the >> >> >> >> >>> >> >>> functionality of SFFs. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> For me, the amount of information about service >> >> instances >> >> >> >>that >> >> >> >> >>> needs >> >> >> >> >>> >> to >> >> >> >> >>> >> >>> be widely distributed and maintained, potentially >>even >> >> >> across >> >> >> >> >>>data >> >> >> >> >>> >> >>> centers within an administrative scope, is large >>enough >> >> >>and >> >> >> >> >>>complex >> >> >> >> >>> >> >>> enough that trying to get that into each SFF >> >> >> >> >>> >> >>> seems >> >>like a >> >> >> >> >>>difficult >> >> >> >> >>> >> >>> architecture to realize. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> Yours, >> >> >> >> >>> >> >>> Joel >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> But it is a fair question. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >> >> >> >>> >> >>>> This is the crux of my issue. Is the end to end >> >> >>selection >> >> >> >>of >> >> >> >> >>> >> >>>> (top-level) instances performed centrally >> >> >> >> >>> >> >>>> (perhaps >>by >> >>the >> >> >> >> >>> >>classifier) >> >> >> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and >> >> subsequently >> >> >> >>the >> >> >> >> >>> >>SFFs)? >> >> >> >> >>> >> >>>> Such selection is not equivalent to >>reclassification. >> >> >>And >> >> >> >> >>>surely, >> >> >> >> >>> >> >>>> this is an architectural issue and not relegated >> >> >> >> >>> >> >>>> to "implementation". >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> My own view is to favor the distributed approach >> even >> >> >> though >> >> >> >> a >> >> >> >> >>> >> >>>> greater amount of data (chain definitions and >>perhaps >> >> >>local >> >> >> >> >>> >>selection >> >> >> >> >>> >> >>>> policy) is required at those distributed >> >> >> >> >>> >> >>>> decision >> >>points. >> >> >> >>This >> >> >> >> >>> >> >>>> approach does not require an end-to-end path id >> >> >> >> >>> >> >>>> at >> >>all. >> >> >> >>My >> >> >> >> >>> >> >>>> rationale for favoring this approach is >> >> >> >> >>> >> >>>> primarily >> >>driven >> >> >>by >> >> >> >> >>> >>increased >> >> >> >> >>> >> >>>> resiliency over the global path id approach. >>With a >> >> >>global >> >> >> >> >>>path >> >> >> >> >>> >>id >> >> >> >> >>> >> >>>> approach, consider failure of an instance and >>needing >> >>to >> >> >> >>alter >> >> >> >> >>>the >> >> >> >> >>> >> >>>> global path ID table for each and every affected >> >> >>end-to-end >> >> >> >> >>>path. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Ron >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> ________________________________________ From: >> sfc >> >> >> >> >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern >> >>Direct >> >> >> >> >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, >> >> >> >> >>> >> >>>> July >>10, >> >> >>2014 >> >> >> >> 6:15 >> >> >> >> >>> PM >> >> >> >> >>> >> >>>> To: mikebianc@aol.com; I.Smith@F5.com; >> >> >> >> >>> >> >>>> sfc@ietf.org >> >> >> Subject: >> >> >> >> Re: >> >> >> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> The way the architecture models the case of SF1 >> >>needing >> >> >>to >> >> >> >> >>> >>influence >> >> >> >> >>> >> >>>> the chain is that one would do reclassification >> >> >> >> >>> >> >>>> at >>the >> >> >>exit >> >> >> >>from >> >> >> >> >>> >> >>>> SF1. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Part of the goal is to keep the different >> >> >> >> >>> >> >>>> functions >> >> >> >>logically >> >> >> >> >>> >> >>>> separate so that solutions can clearly describe >> >> >> >> >>> >> >>>> how >> >>they >> >> >> >> choose >> >> >> >> >>>to >> >> >> >> >>> >> >>>> compose them for "service" delivery. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Yours, Joel >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> >> >> >> >>> >> >>>>> I don't see anything in the arch draft that >>suggests >> >>any >> >> >> >>sort >> >> >> >> >>>of >> >> >> >> >>> >> >>>>> limit. However, it does seem to indicate that >> >> >> >> >>> >> >>>>> the >> >>entire >> >> >> >>path >> >> >> >> >>>(all >> >> >> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I >>believe >> >> >>this >> >> >> >> >>>means >> >> >> >> >>> >> >>>>> either at the classifier or maybe the >> >> >> >> >>> >> >>>>> classifier >> >> >>chooses a >> >> >> >>SF >> >> >> >> >>> >>Chain >> >> >> >> >>> >> >>>>> and the NF or at the latest the first SFF. In >> >> >> >> >>> >> >>>>> any >> >>case, >> >> >> >>the >> >> >> >> >>> >> >>>>> language does seem to prohibit a more dynamic >> >> >> >> >>> >> >>>>> SFP >> >> where >> >> >> >> SFI(n) >> >> >> >> >>> is >> >> >> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to >> >> >> >> >>> >> >>>>> the >> >>draft, >> >> >> >>this >> >> >> >> >>> >> >>>>> behavior would be considered "branching" to a >> >> >> >> >>> >> >>>>> new >> SFP >> >> as >> >> >> >> >>> opposed >> >> >> >> >>> >> to >> >> >> >> >>> >> >>>>> choosing and then forwarding to the selected >> instance >> >> of >> >> >> >>the >> >> >> >> >>> >> >>>>> next-hop of the current SFC. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> draft-merged-sfc-architecture-00: >> >> >> >> >>> >> >>>>>> When an SFC is instantiated into the network >> >> >> >> >>> >> >>>>>> it >>is >> >> >> >>necessary >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>> select the specific instances of SFs that will >> >> >> >> >>> >> >>>>>> be >> >>used, >> >> >> >>and to >> >> >> >> >>> >> >>>>>> create the service topology for that SFC using >>SF's >> >> >> >>network >> >> >> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC >> >> >> >> >>> >> >>>>>> results >>in >> >>the >> >> >> >> >>>creation >> >> >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used >> >> >> >> >>> >> >>>>>> for >> >> >> >>forwarding >> >> >> >> >>> >> >>>>>> packets through the SFC. In other words, an >> >> >> >> >>> >> >>>>>> SFP >>is >> >>the >> >> >> >> >>> >> >>>>>> instantiation of the defined SFC. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> The SFC architecture supports reclassification >>(or >> >> >> >>non-initial >> >> >> >> >>> >> >>>>>> classification) as well. As packets traverse >> >> >> >> >>> >> >>>>>> an >> >>SFP, >> >> >> >> >>> >> >>>>>> reclassification may occur - typically >> >> >> >> >>> >> >>>>>> performed >>by >> >>a >> >> >> >> >>> >> >>>>>> classification function co-resident with a >>service >> >> >> >>function. >> >> >> >> >>> >> >>>>>> Reclassification may result in the selection >> >> >> >> >>> >> >>>>>> of a >> >>new >> >> >> >>SFP, an >> >> >> >> >>> >> >>>>>> update of the associated metadata, or both. >>This is >> >> >> >>referred >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>> as "branching". >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>>>>>>>>>>>>>>------------------------------------------------------ >>>>>>>>>>>>>>>>>>--- >>>>>>>>>>>>>>>>>>-- >> >>>>>>>>>>>>>>>>-- >> >> >>>>>>>>>>>>>>-- >> >> >> >>>>>>>>>>>>--- >> >> >> >> >>>>>>>>>>-- >> >> >> >> >>> >>>>>>>-- >> >> >> >> >>> >> >>>>>-- >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>> *From: *I.Smith@F5.com<I.Smith@F5.com> >> >> >> >> >>> >> >>>>> *To: *Joel Halpern >> >> >> Direct<jmh.direct@joelhalpern.com>,Joel >> >> >> >> M. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>Halpern<jmh@joelhalpern.com>,huang@sce.carleton.ca<huang@sce. >> >> >> >> >>> >> carleton. >> >> >> >> >>> >> >>>>>ca>,sfc@ietf.org<sfc@ietf.org> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 >> >> >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and >>Load >> >> >> >>Balancers >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Actually, I think I am disagreeing. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> If the possibility of medium-scale deployments >>(and >> >> >>that is >> >> >> >> >>>what >> >> >> >> >>> >> >>>>> 16 million flows is in my world) of service >>chains is >> >> >> >> >>>preconceived >> >> >> >> >>> >> >>>>> as an absurd idea, then the architecture >> >> >> >> >>> >> >>>>> burdened >> >>with >> >> >> that >> >> >> >> >>> >> >>>>> preconception. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> There has to be some point of aim, some degree >> >> >> >> >>> >> >>>>> of >> >> >> >>aspiration >> >> >> >> to >> >> >> >> >>> >> >>>>> scale that is appropriate for the lifespan of >> >> >> >> >>> >> >>>>> the >> >> >> >>architecture >> >> >> >> >>>- >> >> >> >> >>> >> >>>>> you don't have to know what it is, but by >> >> >> >> >>> >> >>>>> saying >> >>that an >> >> >> >> >>>arbitrary >> >> >> >> >>> >> >>>>> number is "too far", you're creating - even if >> >> >> >> >>> >> >>>>> it >> >>isn't >> >> >> >> >>> >>intentional >> >> >> >> >>> >> >>>>> - a limit that influences decisions that have >>lasting >> >> >> >>impacts >> >> >> >> >>> >> >>>>> regarding scale-out, failure mitigation, >>elasticity, >> >> >> >>address >> >> >> >> >>> >> >>>>> space... all kinds of things. That is a problem >>I'm >> >>not >> >> >> >> >>> >> >>>>> particularly eager to deal with. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> ________________________________________ >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> From: Joel Halpern Direct >> >>[jmh.direct@joelhalpern.com] >> >> >> >>Sent: >> >> >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; >>Joel >> >>M. >> >> >> >> Halpern; >> >> >> >> >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: >> >>[sfc] >> >> >> >>Service >> >> >> >> >>> >> >>>>> Chains, Paths, and Load Balancers >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all >> >> >> >> >>> >> >>>>> in >> >>this >> >> >> >>regard. >> >> >> >> >>>I >> >> >> >> >>> >>am >> >> >> >> >>> >> >>>>> not requesting the the architecture or the >>solution >> >> >> >>prohibit >> >> >> >> >>> >> >>>>> deployments in the specific fashion. I am >>objecting >> >>to >> >> >> >>Huang's >> >> >> >> >>> >> >>>>> reading of my note as saying that such >> >> >> >> >>> >> >>>>> deployments >> >>are >> >> >> >> required >> >> >> >> >>> >> >>>>> they by the archtiecture. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to >> >>prohibit >> >> >>such >> >> >> >> >>> >> >>>>> things. Whether they are a good idea or not >>depends >> >> upon >> >> >> >> many >> >> >> >> >>> >> >>>>> factors outside of the scope of the WG. I >> >> >> >> >>> >> >>>>> happen >>to >> >> >>think >> >> >> >>that >> >> >> >> >>> >>they >> >> >> >> >>> >> >>>>> are usually a bad idea. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> But the archtiecture si carefully avoiding >> >>attempting to >> >> >> >>know >> >> >> >> >>>what >> >> >> >> >>> >> >>>>> is and is not eployable. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Yours, Joel >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >> >> >> >>> >> >>>>>> I disagree. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> We routinely have stateful devices that manage >> tens >> >> of >> >> >> >> >>>millions >> >> >> >> >>> >> >>>>>> of >> >> >> >> >>> >> >>>>> concurrent flows in both access network and >> >> >> >> >>> >> >>>>> data >> >> center >> >> >> >> >>> >> >>>>> environments today. You can't seriously believe >>that >> >>in >> >> >>the >> >> >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of >> >> >> >> >>> >> >>>>> tomorrow >> >> you >> >> >> are >> >> >> >> only >> >> >> >> >>> >> going >> >> >> >> >>> >> >>>>> to have small numbers of service chains with >>equally >> >> >>small >> >> >> >> >>> numbers >> >> >> >> >>> >> >>>>> of active service paths? >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Your sounds too much like "no one will ever >> >> >> >> >>> >> >>>>>> need >> >> more >> >> >> than >> >> >> >> >>> 64K" >> >> >> >> >>> >> >>>>>> for >> >> >> >> >>> >> >>>>> comfort. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> ________________________________________ >> From: >> >> sfc >> >> >> >> >>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. >>Halpern >> >> >> >> >>> >> >>>>> [jmh@joelhalpern.com] >> >> >> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >> >> >> >> >>>huang@sce.carleton.ca; >> >> >> >> >>> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service >> >> >> >> >>> >> >>>>>> Chains, >> >>Paths, >> >> >>and >> >> >> >> >>>Load >> >> >> >> >>> >> >>>>>> Balancers >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> No, it will mean that if someone tries to >> >> >> >> >>> >> >>>>>> deploy >>the >> >> >> >> >>>archtieture >> >> >> >> >>> >> >>>>>> particularly badly, they will exceed the >> >> >> >> >>> >> >>>>>> limits >>of >> >> >>their >> >> >> >> >>> >> >>>>>> devices. The architecture does not require >> >> >> >> >>> >> >>>>>> such >> >>absurd >> >> >> use >> >> >> >> of >> >> >> >> >>> >> >>>>>> service paths. Since I can not figure out how >> >> >> >> >>> >> >>>>>> to >> >>write >> >> >> >> >>> >> >>>>>> architectural words to prohibit it, the >>architecture >> >> >>does >> >> >> >> >>>permit >> >> >> >> >>> >> >>>>>> such abuse. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Please do not read my saying that the >>archtiecture >> >> >> permits >> >> >> >> >>> >> >>>>>> something as saying it is either deisred or >> >>required by >> >> >> >>the >> >> >> >> >>>work. >> >> >> >> >>> >> >>>>>> It isn't. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >> >> >> >>> >> >>>>>>> If you need to support 100 service chains, it >>will >> >> >>mean >> >> >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the >>routing >> >> >>table >> >> >> >>of a >> >> >> >> >>> >> >>>>>>> core router. >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> Chang >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >> >> >> >>> >> >>>>>>>> The architecture allows a range of >> >> >> >> >>> >> >>>>>>>> deployments, >> >> from >> >> >>1 >> >> >> >> >>> >> >>>>>>>> service path to 160000 service paths. I >> >> >> >> >>> >> >>>>>>>> would >> hope >> >> >>that >> >> >> >> >>> >> >>>>>>>> operators are prepared for the complexities >> >> >> >> >>> >> >>>>>>>> if >> >>they >> >> >> >>choose >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in >>stead >> >> >> >> provision >> >> >> >> >>> >> >>>>>>>> 160,000 service paths. >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H >> wrote: >> >> >> >> >>> >> >>>>>>>>> Paul, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> How many path identifiers there will be for >> >> >> >> >>> >> >>>>>>>>> a >>4 >> >>hop >> >> >> >> service >> >> >> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Maria >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] >> >> >> >> >>> >> >>>>>>>>> *On >> >> Behalf >> >> >> Of >> >> >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July >> >> >> >> >>> >> >>>>>>>>> 10, >> >>2014 >> >> >> >>3:03 >> >> >> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* >> jmh@joelhalpern.com; >> >> >> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >> >> >> >> >>> >> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] >> >> >> >> >>> >> >>>>>>>>> Service >> >> >> Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Lucy, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID >> >> >> >> >>> >> >>>>>>>>> drives >> >>the >> >> >> >> >>> >> >>>>>>>>> forwarding. I=B9d >> >> >> >> >>> >> >>>>> make >> >> >> >> >>> >> >>>>>>>>> the minor change: the path identifier can >> >> >> >> >>> >> >>>>>>>>> be >> used >> >> to >> >> >> >> derive >> >> >> >> >>> >> >>>>>>>>> the needed forwarding and associated >> transport. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is >> >> >> >> >>> >> >>>>>>>>> used >>to >> >> >>simply >> >> >> >> >>> >> >>>>>>>>> identify the service path (or graph) that >>packets >> >> >>must >> >> >> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the >>exact >> >> >> >> >>> >> >>>>>>>>> indirection that people seem to be asking >> >> >> >> >>> >> >>>>>>>>> for >>on >> >> >>this >> >> >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The >> >> >> >> >>> >> >>>>>>>>> path >> >> >> >> identifier >> >> >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that >> lookup >> >> can >> >> >> >> result >> >> >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) >> >> >> >> >>> >> >>>>>>>>> transport >> >> next >> >> >> >> >>> >> >>>>>>>>> hop(s). >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Paul >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >> >> >> >>> >> >>>>>>>>> <lucy.yong@huawei.com >> >> >> >> <mailto:lucy.yong@huawei.com>> >> >> >> >> >>> >> >>>>>>>>> wrote: >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate >> >> >> >> >>> >> >>>>>>>>> only >> use >> >> of >> >> >> the >> >> >> >> >>> >> >>>>>>>>> service path identifier to drive the >>forwarding >> >> >> >>actions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Lucy >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On >> >> Behalf >> >> >> >> >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com >> >> >> >> >>> >> >>>>>>>>> <mailto:mohamed.boucadair@orange.com> >> >> >> >> >>> *Sent:*Thursday, >> >> >> >> >>> >> July >> >> >> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >> >> >> >>> >> >>>>>>>>> >> >> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Subject:*Re: [sfc] >>Service >> >> >> >>Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Re-, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a >>service >> >>path >> >> >> >> >>> >> >>>>>>>>> identifier. I object to use that identifier >> >> >> >> >>> >> >>>>>>>>> to >> >> >>derive >> >> >> >> >>> >> >>>>>>>>> forwarding actions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full >> knowledge >> >> of >> >> >> >> every >> >> >> >> >>> >> >>>>> available SFC >> >> >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled >> >> >> >> >>> >> >>>>>>>>> domain >> is >> >> not >> >> >> >> >>> >> >>>>> required/justified >> >> >> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the >>piece >> >>of >> >> >> >> >>> >> >>>>>>>>> information >> >> >> >> >>> >> >>>>> that will >> >> >> >> >>> >> >>>>>>>>> be present in all deployments: that is the >> >> >> >> >>> >> >>>>>>>>> one >> >> >> required >> >> >> >> to >> >> >> >> >>> >> >>>>>>>>> structure a service chain. How that >>information >> >>is >> >> >> >>used to >> >> >> >> >>> >> >>>>>>>>> infer forwarding >> >> >> >> >>> >> >>>>> actions >> >> >> >> >>> >> >>>>>>>>> is a solution-oriented discussion. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Cheers, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Med >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De >> >> >> >> >>> >> >>>>>>>>> la >> >>part >> >> >> >> >>> >> >>>>> de*mikebianc@aol.com >> >> >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com> *Envoy=E9 >> :*mercredi 9 >> >> >> >> juillet >> >> >> >> >>> >> >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] >>Service >> >> >> >>Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference >> >>between >> >> >>SF >> >> >> >> Chain >> >> >> >> >>> >> >>>>>>>>> and SF >> >> >> >> >>> >> >>>>> Path? >> >> >> >> >>> >> >>>>>>>>> Other than clarifying the definition so >> >> >> >> >>> >> >>>>>>>>> that >>it's >> >> >> >>clear to >> >> >> >> >>> >> >>>>> those not >> >> >> >> >>> >> >>>>>>>>> familiar with the draft, it seems that >>everyone >> >> >>agrees >> >> >> >>on >> >> >> >> >>> >> >>>>>>>>> these terms. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear >> >> >> >> >>> >> >>>>>>>>> is >> >> >>whether >> >> >> >>it is >> >> >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately >> >> >> >> >>> >> >>>>>>>>> specify >> >>what >> >> >> >>the ID >> >> >> >> >>> >> >>>>>>>>> of the SFC Header >> >> >> >> >>> >> >>>>> should >> >> >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if >> >> >> >> >>> >> >>>>>>>>> this >> >>draft >> >> >> >>simply >> >> >> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing >>other >> >> >>drafts >> >> >> >>to >> >> >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based >> >> >> >> >>> >> >>>>>>>>> on >> >> chain >> >> >> or >> >> >> >> >>> >> >>>>>>>>> path and the choice of chain or >> >> >> >> >>> >> >>>>> path to >> >> >> >> >>> >> >>>>>>>>> be negotiated in the control-plane. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft >>would >> >> have >> >> >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported >> >> >> >> >>> >> >>>>>>>>> (or >> >> make >> >> >> >> one >> >> >> >> >>> >> >>>>>>>>> required and the other optional) to avoid >> >> >> >> >>> >> >>>>>>>>> some >> >> >> vendors >> >> >> >> only >> >> >> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>>>>>>>>>>>>>>------------------------------------------------------ >>>>>>>>>>>>>>>>>>--- >>>>>>>>>>>>>>>>>>-- >> >>>>>>>>>>>>>>>>-- >> >> >>>>>>>>>>>>>>-- >> >> >> >>>>>>>>>>>>--- >> >> >> >> >>>>>>>>>>-- >> >> >> >> >>> >>>>>>>-- >> >> >> >> >>> >> >>>>>-- >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> *From:*jmh@joelhalpern.com<jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>> >> >> >> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org<sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org>> >> >> >> *Sent:*Tuesday, >> >> >> >> July >> >> >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, >> >>and >> >> >>Load >> >> >> >> >>> >> >>>>>>>>> Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> I have been trying to figure out how to >>clearly >> >> >>answer >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> number of comments that have been made >> about >> >> the >> >> >> >> >>> proposed >> >> >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can >> >> >> >> >>> >> >>>>>>>>> get >> >> >> working >> >> >> >> >>> >> >>>>>>>>> group agreement on the intent, we will work >> >> >> >> >>> >> >>>>>>>>> to >> >> >> improve >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> wording so that readers who have not >> participated >> >> in >> >> >> >>the >> >> >> >> WG >> >> >> >> >>> >> >>>>>>>>> discussion will understnd it the way the >> >> >> >> >>> >> >>>>> working >> >> >> >> >>> >> >>>>>>>>> group intends. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> But what do we intend? I will try to >> >> >> >> >>> >> >>>>>>>>> explain >>my >> >> >> >>personal >> >> >> >> >>> >> >>>>>>>>> view, and see if that helps. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> In this regard, it is important to keep in >>mind >> >>that >> >> >> >>what >> >> >> >> >>> >> >>>>>>>>> we are defining is the data plane >>architecture. >> >>We >> >> >>are >> >> >> >> not >> >> >> >> >>> >> >>>>>>>>> attempting to define the architecture for >> >> >> >> >>> >> >>>>>>>>> the >> >>entire >> >> >> >> >>> >> >>>>>>>>> solution for service chaining. That would >> >> encompass >> >> >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy >> >> >> >> >>> >> >>>>>>>>> functions, >> >> >>virtual >> >> >> >> >>> >> >>>>>>>>> machine and image management, and many >> other >> >> >> >> aspects. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> As a result there are many things which >>clearly >> >> need >> >> >> to >> >> >> >> >>> >> >>>>>>>>> exist in the larger system, but which are >>dealt >> >>with >> >> >> >>above >> >> >> >> >>> >> >>>>>>>>> where we are >> >> >> >> >>> >> >>>>> functioning, >> >> >> >> >>> >> >>>>>>>>> and are not directly required by the work >> >> >> >> >>> >> >>>>>>>>> we >>are >> >> >> doing. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> In order to get to service chain vs service >>path, >> >> >>as I >> >> >> >> >>> >> >>>>>>>>> understand >> >> >> >> >>> >> >>>>> them, >> >> >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. >> >> >> >> >>> >> >>>>>>>>> There >> >>are at >> >> >> >>least >> >> >> >> >>> >> >>>>>>>>> three different ways that load balancing >> >> >> >> >>> >> >>>>>>>>> can >>and >> >> >>will >> >> >> >> >>> >> >>>>>>>>> interact with service chaining. There >> >> >> >> >>> >> >>>>>>>>> probably >> >>are >> >> >> >>more. >> >> >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit >>all of >> >> >> >>these, >> >> >> >> >>> >> >>>>>>>>> but not to mandate that any particular kind >> >> >> >> >>> >> >>>>> be used >> >> >> >> >>> >> >>>>>>>>> in any solution. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to >> >> >> >> >>> >> >>>>>>>>> the >> >>end >> >> >> >>user. >> >> >> >> >>> >> >>>>>>>>> This is a service function. It receives >> >> >> >> >>> >> >>>>>>>>> user >> >> >>packets, >> >> >> >>and >> >> >> >> >>> >> >>>>>>>>> modifies them (or >> >> >> >> >>> >> >>>>> marks >> >> >> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user >>service >> >> >> >>instance >> >> >> >> >>> >> >>>>>>>>> to receive the users packet. This is an >>important >> >> >> >>service >> >> >> >> >>> >> >>>>>>>>> function to be able to include in service >> >>chaining. >> >> >> >>It's >> >> >> >> >>> >> >>>>>>>>> behavior may affect requirements on how >> service >> >> >> >> chaining is >> >> >> >> >>> >> >>>>>>>>> done. But it has very little impact on the >> >> >> >>archtiecture. >> >> >> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is >>simply >> >>a >> >> >> >> >>> >> >>>>> service >> >> >> >> >>> >> >>>>>>>>> function which may modify the underlying >> packet. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That >> >> >> >> >>> >> >>>>>>>>> is, >>one >> >> >>can >> >> >> >>have >> >> >> >> >>> >> >>>>>>>>> what >> >> >> >> >>> >> >>>>> appears >> >> >> >> >>> >> >>>>>>>>> to the service chaining architecture as a >>single >> >> >>point >> >> >> >>of >> >> >> >> >>> >> >>>>>>>>> contact >> >> >> >> >>> >> >>>>> for a >> >> >> >> >>> >> >>>>>>>>> specific service function, but is actually >> >>delivered >> >> >> >>by a >> >> >> >> >>> >> >>>>> collection of >> >> >> >> >>> >> >>>>>>>>> virtual or physical machines, possibly >>including >> >> >>one or >> >> >> >> >>> >> >>>>>>>>> several load balancers (for example using >> >>VRRP-like >> >> >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, >> this >> >>is >> >> >> >> >>> >> >>>>>>>>> invisible to the service chaining data >> >> >> >> >>> >> >>>>>>>>> plane >> >> >> >>mechanisms. >> >> >> >> It >> >> >> >> >>> >> >>>>>>>>> is likely that it is visible to various >>control >> >> >> >>mechanisms, >> >> >> >> >>> >> >>>>>>>>> such as those responsible for scale-in, >> >>scale-out, >> >> >>and >> >> >> >>vm >> >> >> >> >>> >> >>>>>>>>> instantiation. The architectural impact of >> >> >>permitting >> >> >> >>this >> >> >> >> >>> >> >>>>>>>>> is largely that we need to be careful that >> >> >> >> >>> >> >>>>>>>>> our >> >> >> >>terminology >> >> >> >> >>> >> >>>>>>>>> does not lead >> >> >> >> >>> >> >>>>> readers to >> >> >> >> >>> >> >>>>>>>>> think we are prohibiting it. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by >> >> >>selecting >> >> >> >> >>> >> >>>>>>>>> packet paths for the service chaining that >>direct >> >> >> >>traffic >> >> >> >> >>> >> >>>>>>>>> to different places. We would not want to >> require >> >> >> that >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> given service function appear at only one >>place >> >>in >> >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> It is of course the case that these may be >> >> >>combined. I >> >> >> >> tend >> >> >> >> >>> >> >>>>>>>>> to >> >> >> >> >>> >> >>>>> refer to >> >> >> >> >>> >> >>>>>>>>> the collection of entities that appear to >>service >> >> >> >>chaining >> >> >> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because >> >>cluster >> >> >>is >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> good term. But because I do not have >> >> >> >> >>> >> >>>>>>>>> another >> one. >> >> >> Thus, >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> point of type 3 load balancing >> >> >> >> >>> >> >>>>> is to >> >> >> >> >>> >> >>>>>>>>> direct different subsets of traffic to >>different >> >> >> >>singular >> >> >> >> >>> >> >>>>>>>>> or clustered service functions in different >> >>places >> >> >>in >> >> >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I >> >> >> >> >>> >> >>>>>>>>> talk >> >> about >> >> >> >> >>> >> >>>>>>>>> service chain and service path/ Service >> >> >> >> >>> >> >>>>>>>>> chain >>is >> >>a >> >> >> >> sequence >> >> >> >> >>> >> >>>>>>>>> of logical functions to be applied to a >>subset of >> >> >> >>packets. >> >> >> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset >> >> >> >> >>> >> >>>>>>>>> of >> >> >>traffic >> >> >> >>is >> >> >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, >> >> >> >> >>> >> >>>>>>>>> and >> >> >>firewall >> >> >> >> >>> >> >>>>>>>>> while a different subset is to go directly >> >> >> >> >>> >> >>>>>>>>> to >>the >> >> >>cache >> >> >> >> >>> >> >>>>> without >> >> >> >> >>> >> >>>>>>>>> visiting any other service functions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> That is not enough information to direct >> >> >> >> >>> >> >>>>>>>>> the >> >> >>packets. >> >> >> A >> >> >> >> >>> >> >>>>>>>>> service path is, in some fashion, a >> >> >> >> >>> >> >>>>>>>>> sequence >>of >> >> >> >>locations >> >> >> >> >>> >> >>>>>>>>> in the network. Those locations will be >>singular >> >>or >> >> >> >> >>> >> >>>>>>>>> clustered service function delivery locations. >> >>They >> >> >> >>may be >> >> >> >> >>> >> >>>>>>>>> addressed by IP address. They may be >> addressed as >> >> >> ports >> >> >> >> on >> >> >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that >> >> >> >> >>> >> >>>>>>>>> the >> >> >> >>locations >> >> >> >> >>> >> >>>>>>>>> may be known to the service chaining >> >> infrastructure >> >> >> and >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> transport. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>>> From the point of view of the work of the >>SFC >> >> >>group, >> >> >> >> we >> >> >> >> >>> >> >>>>>>>>>> need to be >> >> >> >> >>> >> >>>>>>>>> able to talk about the high level >> >> >> >> >>> >> >>>>>>>>> abstraction, >> >>the >> >> >> >>service >> >> >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we >> need >> >>to >> >> >> talk >> >> >> >> >>> >> >>>>>>>>> about the actual data path packets will >> >> >> >> >>> >> >>>>>>>>> take >>in >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Several of the comments have said "but the >> whole >> >> >> path >> >> >> >> may >> >> >> >> >>> >> >>>>>>>>> not be known at the front." This >> >> >> >> >>> >> >>>>>>>>> architecture >> >>deals >> >> >> >>with >> >> >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in >>item >> >>(2) >> >> >>on >> >> >> >>load >> >> >> >> >>> >> >>>>>>>>> balancers above, there can be decisions and >> >> >>behaviors >> >> >> >> which >> >> >> >> >>> >> >>>>>>>>> are invisible to the service chaining >>mechanisms >> >>(in >> >> >> >>much >> >> >> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is >> >>largely >> >> >> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The >> >> >> >> >>> >> >>>>>>>>> other >> >> >> provision >> >> >> >> we >> >> >> >> >>> >> >>>>>>>>> make is >> >> >> >> >>> >> >>>>> that >> >> >> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain >> >> >> >> >>> >> >>>>>>>>> when >> >> >> >> necessary. >> >> >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. >> >> >> >> >>> >> >>>>>>>>> Based >> on >> >> >> >> >>> >> >>>>>>>>> information available at the >> >> >> >> >>> >> >>>>>>>>> re-classification >> >> >>point. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> I hope that this helps explain what we are >>after. >> >> >>If it >> >> >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to >> >> >> >> >>> >> >>>>>>>>> the >> >>working >> >> >> >> group, >> >> >> >> >>> >> >>>>>>>>> we can figure out what additional words are >> >> needed >> >> >> to >> >> >> >> >>> >> >>>>>>>>> convey this. If the working group disagree >>with >> >>the >> >> >> >> intent, >> >> >> >> >>> >> >>>>>>>>> then we will of course adjust to match the >> >>working >> >> >> >>group >> >> >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am >> >> >> >> >>> >> >>>>>>>>> not >> >>sure >> >> >> >>what to >> >> >> >> >>> >> >>>>>>>>> try next. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >> >> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >> >> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>> list sfc@ietf.org >> >> >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> >> >> _______________________________________________ >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>> list sfc@ietf.org >> >> >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> >> >> _______________________________________________ >> >> >> sfc >> >> >> >> >>> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>>>> sfc@ietf.org >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> _______________________________________________ >> >> sfc >> >> >> >> >>> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>>> sfc@ietf.org >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> >> _______________________________________________ >> >> sfc >> >> >> >> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>> sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> >> _______________________________________________ >> >> sfc >> >> >> >> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>> sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> _______________________________________________ >> >> >> >> >>> >> >> sfc mailing list >> >> >> >> >>> >> >> sfc@ietf.org >> >> >> >> >>> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >> >> >>> >> > >> >> >> >> >>> >> >_______________________________________________ >> >> >> >> >>> >> >sfc mailing list >> >> >> >> >>> >> >sfc@ietf.org >> >> >> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >> >>> >> _______________________________________________ >> >> >> >> >>> >> sfc mailing list >> >> >> >> >>> >> sfc@ietf.org >> >> >> >> >>> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >>> _______________________________________________ >> >> >> >> >>> sfc mailing list >> >> >> >> >>> sfc@ietf.org >> >> >> >> >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> > >> >> >> >> >_______________________________________________ >> >> >> >> >sfc mailing list >> >> >> >> >sfc@ietf.org >> >> >> >> >https://www.ietf.org/mailman/listinfo/sfc >> >> > >> > > _______________________________________________ sfc mailing 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 Sat Jul 12 08:59:45 2014 Return-Path: <I.Smith@f5.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CFB1B2AC9 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.652 X-Spam-Level: X-Spam-Status: No, score=-7.652 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.651, 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 2Wjjq7k_ckpw for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 08:59:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925321B2AC5 for <sfc@ietf.org>; Sat, 12 Jul 2014 08:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405180776; x=1436716776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Phiyoj0L2naeOaGGVtg0/PSKEcwoGlKx4OQouEJlETw=; b=maDOErzZwP2/mtYncX2uAkYmAeznEVtDfyy1Tdd32/BYp771m5LPpgZF u26Co8LRebxiHZvwxyAhU/Nh7PrFw8PyhnvumEgvOL1KgwIac4PWRNjN6 qUAHxcbpHYmfVrGU1tSdAFjnN4hH/fyG/QRjFm65WnYxiVpLDsL81D7HP 4=; X-IronPort-AV: E=Sophos;i="5.01,649,1400025600"; d="scan'208";a="121604176" X-IPAS-Result: AqcEABBbwVPAqArr/2dsb2JhbABZg2BawREjCodDAYEmdYQDAQEBAQIBAQEBCywrCQsFBwQCAQgRAQMBAQEKFAkHIQYLFAMGCAIEAQ0FCBOIEwMJFb9kDYcoEwSNHoFWJgYrBwIEgyeBFgWWcoIcjWiCHolbgW9B Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 12 Jul 2014 15:59:34 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Sat, 12 Jul 2014 08:59:33 -0700 From: Ian Smith <I.Smith@F5.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Sharon <sbarkai@gmail.com>, Eric Gray <eric.gray@ericsson.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigCAAATDAIABKX+AgAABkICAAAXiAIABxGYAgABmtQCAANRKgP//pzgm Date: Sat, 12 Jul 2014 15:59:33 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tpbwHW4SVz5SVL7Vyvw_RS0EcP4 Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 15:59:41 -0000 I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)=0A= =0A= =0A= ________________________________________=0A= From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]=0A= Sent: Saturday, July 12, 2014 10:15 AM=0A= To: Sharon; Eric Gray=0A= Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= Sharon,=0A= =0A= One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing.=0A= =0A= Ron=0A= =0A= ________________________________________=0A= From: Sharon [sbarkai@gmail.com]=0A= Sent: Friday, July 11, 2014 9:35 PM=0A= To: Eric Gray=0A= Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org=0A= Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= =0A= Looks like it's almost there, no?=0A= =0A= If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:=0A= =0A= - classify and map the flow to the right subscriber-serviceChain=0A= =0A= - map the chain links to the SFFs signed up to execute an SF hop=0A= =0A= - carry the context and work flow as meta data between SFFs=0A= =0A= Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.=0A= =0A= The way I read the docs it's almost there.=0A= =0A= --szb=0A= =0A= > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote:= =0A= >=0A= > Maria,=0A= >=0A= > So many fundamental problems. What to do?=0A= >=0A= > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF=0A= > working group needs to focus on a set of problems they can solve in a rea= sonable=0A= > amount of time, without having to boil any oceans.=0A= >=0A= > Joel suggested an architectural approach that would allow any form of dis= tribution=0A= > you might want, without requiring every solution to support all possibili= ties, and=0A= > without impacting the ability of solutions to be optimized for whatever d= eployment=0A= > scenario may apply in any specific case.=0A= >=0A= > Working out ways to optimize your particular deployment model seems to be= your=0A= > problem (with support from your suppliers - whoever they might be) and - = it seems=0A= > to me - the burden of making sure that the standards we define allows opt= imization=0A= > for that deployment falls on you (and them).=0A= >=0A= > Meanwhile, other providers and other vendors may seek to ensure that what= ever=0A= > we define allows at least some degree of optimization for their deploymen= ts.=0A= >=0A= > This is the process.=0A= >=0A= > Is the architectural proposal Joel came up with sufficient as a starting = point?=0A= >=0A= > --=0A= > Eric=0A= >=0A= > -----Original Message-----=0A= > From: NAPIERALA, MARIA H [mailto:mn1921@att.com]=0A= > Sent: Thursday, July 10, 2014 12:29 PM=0A= > To: Eric Gray; Jim Guichard (jguichar); Ron Parker=0A= > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org=0A= > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers=0A= > Importance: High=0A= >=0A= > Eric,=0A= >=0A= >> Load distribution is not the same as service function chaining and -=0A= >> while there may be problems to solve in this area - why would we=0A= >> assume that SFC is supposed to solve them?=0A= >=0A= > Because this is the fundamental problem in service chaining in virtualize= d environments.=0A= > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help.=0A= >=0A= >> I think SFC should be more concerned about ensuring that function=0A= >> chaining solutions do not preclude load distribution.=0A= >=0A= > How would you ensure it?=0A= >=0A= >>=0A= >> --=0A= >> Eric=0A= >>=0A= >> -----Original Message-----=0A= >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA=0A= >> H=0A= >> Sent: Thursday, July 10, 2014 12:02 PM=0A= >> To: Jim Guichard (jguichar); Ron Parker=0A= >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org=0A= >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>=0A= >> One of the main problems in "service chains" is how to implement a=0A= >> service that is conceptually one hop but scaled horizontally as 10 or=0A= >> 100 different VMs.=0A= >> So, IMO, if we are not addressing this problem than what are we solving.= =0A= >>=0A= >> Maria=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >>> Sent: Wednesday, July 09, 2014 6:17 PM=0A= >>> To: Ron Parker=0A= >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA,=0A= >> MARIA H;=0A= >>> sfc@ietf.org=0A= >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>=0A= >>> I should clarify that my statement was made as a personal opinion=0A= >>> and it is up to the WG to evaluate if there exists anything at the=0A= >>> architectural level that is new and therefore needs to be addressed.=0A= >>>=0A= >>> Sent from my iPhone=0A= >>>=0A= >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"=0A= >>>> <Ron_Parker@affirmednetworks.com> wrote:=0A= >>>>=0A= >>>> Jim,=0A= >>>>=0A= >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that=0A= >>> this is a layered problem and that load balancing belongs at a lower=0A= >>> level, it seems to me that load balancing of the service functions=0A= >>> (not load balancer as a service function) should be an explicit=0A= >> consideration of the SFC=0A= >>> architecture. I say this not only from a scale perspective, but also= with=0A= >>> resiliency in mind.=0A= >>>>=0A= >>>> Ron=0A= >>>>=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >>>> Sent: Wednesday, July 09, 2014 5:48 PM=0A= >>>> To: Ron Parker=0A= >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org;=0A= >>> NAPIERALA, MARIA H=0A= >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>=0A= >>>> I would say that's implementation.=0A= >>>>=0A= >>>> Sent from my iPhone=0A= >>>>=0A= >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"=0A= >>> <Ron_Parker@affirmednetworks.com> wrote:=0A= >>>>>=0A= >>>>> Agreed. But is that in scope for SFC or out of scope for SFC?=0A= >>>>>=0A= >>>>> -----Original Message-----=0A= >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >>>>> Sent: Wednesday, July 09, 2014 5:29 PM=0A= >>>>> To: Ron Parker=0A= >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;=0A= >>> mohamed.boucadair@orange.com;=0A= >>>>> sfc@ietf.org=0A= >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>=0A= >>>>> Well of course not; in that case you load balance up a level=0A= >>>>> between=0A= >>> those nodes and then locally.=0A= >>>>>=0A= >>>>> Sent from my iPhone=0A= >>>>>=0A= >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"=0A= >>> <Ron_Parker@affirmednetworks.com> wrote:=0A= >>>>>>=0A= >>>>>> Jim,=0A= >>>>>>=0A= >>>>>> There may not be a single node through which all of the=0A= >>>>>> instances can=0A= >>> be reached (at some reasonable limit of L2 or L3 hops).=0A= >>>>>>=0A= >>>>>> Ron=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> -----Original Message-----=0A= >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim=0A= >>>>>> Guichard=0A= >>>>>> (jguichar)=0A= >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM=0A= >>>>>> To: NAPIERALA, MARIA H=0A= >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org=0A= >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>>=0A= >>>>>> At the node through which the 20 instances are reachable. IOW=0A= >>>>>> you=0A= >>> don't have to individually address packets to each and every instance.= =0A= >>>>>>=0A= >>>>>> Sent from my iPhone=0A= >>>>>>=0A= >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H"=0A= >>> <mn1921@att.com> wrote:=0A= >>>>>>>=0A= >>>>>>> Hi Jim,=0A= >>>>>>>=0A= >>>>>>> When you say "locally", where is it?=0A= >>>>>>>=0A= >>>>>>> Maria=0A= >>>>>>>=0A= >>>>>>>> -----Original Message-----=0A= >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM=0A= >>>>>>>> To: NAPIERALA, MARIA H=0A= >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com;=0A= >> sfc@ietf.org=0A= >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers=0A= >>>>>>>>=0A= >>>>>>>> Hi Maria,=0A= >>>>>>>>=0A= >>>>>>>> Absolutely and categorically no! If you have 20 instances at=0A= >>>>>>>> each hop then you can choose to load balance among them=0A= >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is=0A= >>>>>>>> that if for some very odd and certainly not recommended reason=0A= >>>>>>>> you want to treat each instance separately then the=0A= >>>>>>>> architecture does not=0A= >>> prevent it.=0A= >>>>>>>>=0A= >>>>>>>> Sent from my iPhone=0A= >>>>>>>>=0A= >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H"=0A= >>> <mn1921@att.com>=0A= >>>>>>>> wrote:=0A= >>>>>>>>=0A= >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed=0A= >>>>>>>>>> separately, then the service chaining infrastructure would=0A= >>>>>>>>>> treat them as such, and would use distinct service paths.=0A= >>>>>>>>>=0A= >>>>>>>>> If I have a 4 hop service chain with 20 instances at each=0A= >>>>>>>>> hop, then I have=0A= >>>>>>>> to globally manage 160,000 service paths (for one chain)?=0A= >>>>>>>> Well, we have yet to see a solution that work this way and scales.= .=0A= >>>>>>>>>=0A= >>>>>>>>> Maria=0A= >>>>>>>>>=0A= >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote:=0A= >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall=0A= >>>>>>>>>>> instances=0A= >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you=0A= >>>>>>>>>> will decide (make a load balancing decision) at the entry to=0A= >>>>>>>>>> the chain which of those=0A= >>>>>>>> 20=0A= >>>>>>>>>> firewalls will be used by a particular flow?=0A= >>>>>>>>>>>=0A= >>>>>>>>>>> Maria=0A= >>>>>>>>>>>=0A= >>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel=0A= >>>>>>>>>>>> Halpern=0A= >>>>>>>> Direct=0A= >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM=0A= >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com;=0A= >>>>>>>>>> sfc@ietf.org=0A= >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load=0A= >>>>>>>>>>>> Balancers=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> The archtiecture allows for this local decision, while=0A= >>>>>>>>>>>> still having the global decision that is directing the traffic= .=0A= >>>>>>>>>>>> That is, the global decision directs the traffic to places=0A= >>>>>>>>>>>> in the network. Those places may be singular or clusters.=0A= >>>>>>>>>>>> If they are clusters, those clusters can use any number of=0A= >>>>>>>>>>>> algorithms to distribute the traffic internally, without=0A= >>>>>>>>>>>> any effect on service chaining. (And yes, this can be=0A= >>>>>>>>>>>> done in such a way that return traffic, if delivered=0A= >>>>>>>>>>>> globally to the same place, can then be delivered to the=0A= >>>>>>>>>>>> right internal=0A= >>>>>>>>>>>> state.)=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> The definition of the service path is about how service=0A= >>>>>>>>>>>> chaining will direct the traffic. it is not about how the=0A= >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to=0A= >>>>>>>>>>>> do that, and they can give the same external interface.=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> We could write the architecture pretending that it always=0A= >>>>>>>>>>>> addresses singular instances, but knowing that reality=0A= >>>>>>>>>>>> would allow load balanced clusters at those locations.=0A= >>>>>>>>>>>> But that would be a misleading architectural description=0A= >>>>>>>>>>>> and might be read to outlaw some solutions that fall=0A= >>>>>>>>>>>> within the goal the WG=0A= >>> wishes to meet.=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Yours,=0A= >>>>>>>>>>>> Joel=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote:=0A= >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators=0A= >>>>>>>>>>>>>> can be=0A= >>>>>>>>>> determined=0A= >>>>>>>>>>>> in=0A= >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC=0A= >>>>>>>>>>>>>> forwarding be based=0A= >>>>>>>>>> on=0A= >>>>>>>>>>>> the=0A= >>>>>>>>>>>>>> service chain itself (characterized as an order list of=0A= >>>>>>>>>>>>>> service function identifiers). This is more compliant=0A= >>>>>>>>>>>>>> with the=0A= >>> LB constraints above:=0A= >>>>>>>>>>>> deciding=0A= >>>>>>>>>>>>>> which locator to use for a given flow will be a local=0A= >>>>>>>>>>>>>> decision not a centralized one.=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done.=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>> Maria=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= >>>> 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= From nobody Sat Jul 12 09:08:37 2014 Return-Path: <sbarkai@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815091B2B6E for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 09:08:34 -0700 (PDT) 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 JnsPQKeDZgnt for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 09:08:31 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B4E1A090D for <sfc@ietf.org>; Sat, 12 Jul 2014 09:08:30 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id c41so943167yho.33 for <sfc@ietf.org>; Sat, 12 Jul 2014 09:08:30 -0700 (PDT) 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=behoepDj3huHFMdPejRXaL5tPpnTuw4f8McwVNanBi0=; b=JCHKsXSMN3WpjvI2kjY8o3CkxtOPCFmVUA5DUtC7feETgsTglgPUQ995JNioxrGttH 3AqrWN28YXnXitx7PfVBjUYIfBxfxhvqnyzxk5uDYiNT70i02rkrYfH6+6RU4lMEjrps L2zNNljrMdf9MjctS1XcNr/KxLs0uJhKHAe9/JooB1iZgB6BYQ+BIv/YzYmgXcQWyLt8 SN9gOq6/XKt2CCPAEPPo8ldmIWsXAWNBx0U/b8iFG3aoO1oUnEwT9vD63BT73S5oEFeW 1ftjCmZyu6oHMW0wIPccxZuMfe7sPTb64POBM8cYEFMsqXNmH+eE0vTEAVkFmbqQgX6V B5JQ== X-Received: by 10.236.90.209 with SMTP id e57mr9906781yhf.135.1405181310175; Sat, 12 Jul 2014 09:08:30 -0700 (PDT) Received: from [192.168.1.102] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id a36sm11611428yho.48.2014.07.12.09.08.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 09:08:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon <sbarkai@gmail.com> X-Mailer: iPhone Mail (11D257) In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local> Date: Sat, 12 Jul 2014 09:08:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <B984B1C0-6599-4383-B318-19CA3AEBF88E@gmail.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se> <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local> To: Ron Parker <Ron_Parker@affirmednetworks.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UX5t3XJtKlMy72mjJ3dbhOSDkMU Cc: "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 16:08:34 -0000 Agree 100% Ron. Thanks for that. And to achieve that we need to assume there's a way to expose and act upon t= hese KPIs globally. So this can be by orchestration, or by a key-value store in the underlay. Th= ese specifics can be left out or referenced, depends on the authors wishes. T= he global architecture and desired mode of operation will be clear and open-= interoperable.=20 --szb > On Jul 12, 2014, at 7:15 AM, Ron Parker <Ron_Parker@affirmednetworks.com> w= rote: >=20 > Sharon, >=20 > One more item I'd add -- load balance amongst the SFFs in an overall hiera= rchical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abstr= act service functions {A, B, C} and 2 distinct SFFs reach some number of A i= nstances, each, 2 distinct SFFs reach some number of B instances, each, etc.= Let's further say that one of the SFF's that reaches instances of A sees= that the last of its A instances has gone down. The top-level load balanc= ing must now avoid that SFF for purposes of invoking service function A (i.e= ., with different procedures, potentially for existing flows vs new flows). = Additionally, it may be beneficial for those SFF's to communicate informat= ion back to the top level path selection logic (i.e., classifier) with infor= mation that can be used for weighted load balancing. >=20 > Ron >=20 > ________________________________________ > From: Sharon [sbarkai@gmail.com] > Sent: Friday, July 11, 2014 9:35 PM > To: Eric Gray > Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halpe= rn; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >=20 > Looks like it's almost there, no? >=20 > If each SFF behaves like a typical load-balancer for the SFs it aggregates= , then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: >=20 > - classify and map the flow to the right subscriber-serviceChain >=20 > - map the chain links to the SFFs signed up to execute an SF hop >=20 > - carry the context and work flow as meta data between SFFs >=20 > Such a system unbundles proprietary service nodes for virtualized environm= ents both in terms of capacity and in term of the functional procedures. No c= entralized static setup needed. >=20 > The way I read the docs it's almost there. >=20 > --szb >=20 >> On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: >>=20 >> Maria, >>=20 >> So many fundamental problems. What to do? >>=20 >> I didn't suggest "leaving it to implementation." I merely suggested that= each IETF >> working group needs to focus on a set of problems they can solve in a rea= sonable >> amount of time, without having to boil any oceans. >>=20 >> Joel suggested an architectural approach that would allow any form of dis= tribution >> you might want, without requiring every solution to support all possibili= ties, and >> without impacting the ability of solutions to be optimized for whatever d= eployment >> scenario may apply in any specific case. >>=20 >> Working out ways to optimize your particular deployment model seems to be= your >> problem (with support from your suppliers - whoever they might be) and - i= t seems >> to me - the burden of making sure that the standards we define allows opt= imization >> for that deployment falls on you (and them). >>=20 >> Meanwhile, other providers and other vendors may seek to ensure that what= ever >> we define allows at least some degree of optimization for their deploymen= ts. >>=20 >> This is the process. >>=20 >> Is the architectural proposal Joel came up with sufficient as a starting p= oint? >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: NAPIERALA, MARIA H [mailto:mn1921@att.com] >> Sent: Thursday, July 10, 2014 12:29 PM >> To: Eric Gray; Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >> Importance: High >>=20 >> Eric, >>=20 >>> Load distribution is not the same as service function chaining and - >>> while there may be problems to solve in this area - why would we >>> assume that SFC is supposed to solve them? >>=20 >> Because this is the fundamental problem in service chaining in virtualize= d environments. >> I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. >>=20 >>> I think SFC should be more concerned about ensuring that function >>> chaining solutions do not preclude load distribution. >>=20 >> How would you ensure it? >>=20 >>>=20 >>> -- >>> Eric >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >>> H >>> Sent: Thursday, July 10, 2014 12:02 PM >>> To: Jim Guichard (jguichar); Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>=20 >>> One of the main problems in "service chains" is how to implement a >>> service that is conceptually one hop but scaled horizontally as 10 or >>> 100 different VMs. >>> So, IMO, if we are not addressing this problem than what are we solving.= >>>=20 >>> Maria >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 6:17 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >>> MARIA H; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>=20 >>>> I should clarify that my statement was made as a personal opinion >>>> and it is up to the WG to evaluate if there exists anything at the >>>> architectural level that is new and therefore needs to be addressed. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>=20 >>>>> Jim, >>>>>=20 >>>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>>> this is a layered problem and that load balancing belongs at a lower >>>> level, it seems to me that load balancing of the service functions >>>> (not load balancer as a service function) should be an explicit >>> consideration of the SFC >>>> architecture. I say this not only from a scale perspective, but also= with >>>> resiliency in mind. >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>>> To: Ron Parker >>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>>> NAPIERALA, MARIA H >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>=20 >>>>> I would say that's implementation. >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>>=20 >>>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>>> To: Ron Parker >>>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>>> mohamed.boucadair@orange.com; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>=20 >>>>>> Well of course not; in that case you load balance up a level >>>>>> between >>>> those nodes and then locally. >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>>>=20 >>>>>>> Jim, >>>>>>>=20 >>>>>>> There may not be a single node through which all of the >>>>>>> instances can >>>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>>> To: NAPIERALA, MARIA H >>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>=20 >>>>>>> At the node through which the 20 instances are reachable. IOW >>>>>>> you >>>> don't have to individually address packets to each and every instance. >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>>> <mn1921@att.com> wrote: >>>>>>>>=20 >>>>>>>> Hi Jim, >>>>>>>>=20 >>>>>>>> When you say "locally", where is it? >>>>>>>>=20 >>>>>>>> Maria >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>>> To: NAPIERALA, MARIA H >>>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >>> sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>>>=20 >>>>>>>>> Hi Maria, >>>>>>>>>=20 >>>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>>> each hop then you can choose to load balance among them >>>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>>> you want to treat each instance separately then the >>>>>>>>> architecture does not >>>> prevent it. >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>>> <mn1921@att.com> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>>>=20 >>>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>>> hop, then I have >>>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>>>=20 >>>>>>>>>> Maria >>>>>>>>>>=20 >>>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>>> instances >>>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>>> the chain which of those >>>>>>>>> 20 >>>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>>>=20 >>>>>>>>>>>> Maria >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>>> Halpern >>>>>>>>> Direct >>>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>>> Balancers >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>>> right internal >>>>>>>>>>>>> state.) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>>> within the goal the WG >>>> wishes to meet. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>>> can be >>>>>>>>>>> determined >>>>>>>>>>>>> in >>>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>>> forwarding be based >>>>>>>>>>> on >>>>>>>>>>>>> the >>>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>>> with the >>>> LB constraints above: >>>>>>>>>>>>> deciding >>>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Maria >>>>>>>>>>>>>=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 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Jul 12 10:43:59 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E271A0ACC for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 10:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 CBnYeN99z3xP for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 10:43:54 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45B71A038F for <sfc@ietf.org>; Sat, 12 Jul 2014 10:43:53 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id A5B2553DF0; Sat, 12 Jul 2014 10:41:56 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 12 Jul 2014 10:41:56.648 -0700 x-echoworx-msg-id: 10fc7579-1a91-44a1-badf-49dba17427d0 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 732; Sat, 12 Jul 2014 10:41:56 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 8691653DF0; Sat, 12 Jul 2014 10:41:56 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 10:43:52 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Ian Smith <I.Smith@F5.com>, Sharon <sbarkai@gmail.com>, Eric Gray <eric.gray@ericsson.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKYCAgAABkICAAAXiAIABxGYAgABmtQCAAF1914AAk+iA//+lj1k= Date: Sat, 12 Jul 2014 17:43:52 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pN740dVLf2BiX1JuMbvDpROdepE Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 17:43:57 -0000 Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing 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 Sat Jul 12 11:43:24 2014 Return-Path: <I.Smith@f5.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAAD1B2B47 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 nxAeXBTnRVlJ for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 11:43:18 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D651B2B45 for <sfc@ietf.org>; Sat, 12 Jul 2014 11:43:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="121497133" X-IPAS-Result: AiAHADD7RVPAqArr/2dsb2JhbAAXQoJCf4ZHtlcXhzWBN3SCJQEBAQECAQEBAQsMARI4BgMLBQcEAgEIEQEDAQEBChYBBgchBgsUAwYIAgQOBQgTh00DCRWKV7ojDYcJF4xTgUImBgcgBAcCBAODG4EUBJRxgX+MYoF/hw+BcIFq Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Jul 2014 18:43:16 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Sat, 12 Jul 2014 11:43:15 -0700 From: Ian Smith <I.Smith@F5.com> To: Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigCAAATDAIABKX+AgAABkICAAAXiAIABxGYAgABmtQCAANRKgP//pzgmgACTCAD//5s/Vw== Date: Sat, 12 Jul 2014 18:43:15 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83F3F4SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hrUEcL5PxxY_tYSm4j73TIZQLys Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 18:43:22 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83F3F4SEAEMBX02olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmmm... That seems to me to be to be excessively fusing over language. I think of 'next hop' as the nomenclature in any network where there is, li= terally, a next hop decision. In common usage of their respective communit= ies of expertise there are Ethernet next hops, IP next hops, service next h= ops, and application next hops; it is contextual and no particular context = owns it, as I'm sure the aviation and circuit radio and mathematics communi= ties would happily argue. In an overlay network context you are unaware of the underlay so just as th= e Ethernet hops are transparent to an IP ping and the IPv4 hops are transpa= rent to my he.net tunnel broker IPv6 connections, the hypothetical 'SFC pin= g' is going to ignore the underlay network and only show the SFIs in the sp= ecified service function path. But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote= : Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A83F3F4SEAEMBX02olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad= ding-left: 4pt; border-left: #800000 2px solid; } --></style> </head> <body> <div> <p dir=3D"ltr">Hmmm...   That seems to me to be to be excessively= fusing over language.</p> <p dir=3D"ltr">I think of 'next hop' as the nomenclature in any network whe= re there is, literally, a next hop decision.  In common usage of their= respective communities of expertise there are Ethernet next hops, IP next = hops, service next hops, and application next hops; it is contextual and no particular context owns it, as I'm sure= the aviation and circuit radio and mathematics communities would happily a= rgue.</p> <p dir=3D"ltr">In an overlay network context you are unaware of the underla= y so just as the Ethernet hops are transparent to an IP ping and the IPv4 h= ops are transparent to my he.net tunnel broker IPv6 connections, the hypoth= etical 'SFC ping' is going to ignore the underlay network and only show the SFIs in the specified service funct= ion path. </p> <p dir=3D"ltr">But the actual point I was trying to make is that there is a= consistent semantic difference between 'selecting a decider' which is what= you do if you make a next- hop selection amongst SNFs and/or SFFs, and 'se= lecting an actor' which is what you do when you make a next hop selection amongst SFIs, and you should differe= ntiate between them.</p> <div class=3D"x_quote">On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@a= ffirmednetworks.com> wrote:<br type=3D"attribution"> </div> </div> <font size=3D"2"><span style=3D"font-size:10pt;"> <div class=3D"PlainText">Ian,<br> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com>= wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com">mailto:mn1= 921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-boun= ces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br= > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA,<= br> >> MARIA H;<br> >>> sfc@ietf.org<br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@iet= f.org;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> mohamed.boucadair@orange.com;<br> >>>>> sfc@ietf.org<br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= >mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org<br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <mn1921@att.com> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@ora= nge.com;<br> >> sfc@ietf.org<br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <mn1921@att.com><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Joel= <br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; mo= hamed.boucadair@orange.com;<br> >>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><b= r> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> sfc@ietf.org<br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> sfc@ietf.org<br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> sfc@ietf.org<br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">= https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> sfc@ietf.org<br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">http= s://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> sfc@ietf.org<br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.= ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > sfc@ietf.org<br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf= .org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> sfc@ietf.org<br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/= mailman/listinfo/sfc</a><br> </div> </span></font> </body> </html> --_000_419417C345CA5F48BF45F0A23955A0634A83F3F4SEAEMBX02olympu_-- From nobody Sat Jul 12 11:47:39 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE2B1B2B47 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 11:47:37 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cWLJ7Sa3MedP for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 11:47:32 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982CF1B2B45 for <sfc@ietf.org>; Sat, 12 Jul 2014 11:47:32 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 5E0A753DFE; Sat, 12 Jul 2014 11:45:35 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 12 Jul 2014 11:45:35.329 -0700 x-echoworx-msg-id: 2460dc13-354b-4a12-955c-151261f236bd x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 654; Sat, 12 Jul 2014 11:45:35 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 389F853DFE; Sat, 12 Jul 2014 11:45:35 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 11:47:31 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Ian Smith <I.Smith@F5.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RNROcP1iMe0Gd7tWYPd8OFpuXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKYCAgAABkICAAAXiAIABxGYAgABmtQCAAF1914AAk+iA//+lj1mAAIgtgP//i0D/ Date: Sat, 12 Jul 2014 18:47:30 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IQEkp3eM6DNGEbpUToc-HcsIBqg Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 18:47:37 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543MBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see your point. But even selecting an actor (SFI) could, itself be an a= bstraction as in the "clustered SFI". The perceived SFI, at the service ov= erlay layer, could in actuality be another load balancing stage in-built to= the cluster's functionality, thereby selecting the ultimate actor. Ron ________________________________ From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 2:43 PM To: Ron Parker Cc: NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.boucadair@= orange.com; Joel M. Halpern; Jim Guichard (jguichar) Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hmmm... That seems to me to be to be excessively fusing over language. I think of 'next hop' as the nomenclature in any network where there is, li= terally, a next hop decision. In common usage of their respective communit= ies of expertise there are Ethernet next hops, IP next hops, service next h= ops, and application next hops; it is contextual and no particular context = owns it, as I'm sure the aviation and circuit radio and mathematics communi= ties would happily argue. In an overlay network context you are unaware of the underlay so just as th= e Ethernet hops are transparent to an IP ping and the IPv4 hops are transpa= rent to my he.net tunnel broker IPv6 connections, the hypothetical 'SFC pin= g' is going to ignore the underlay network and only show the SFIs in the sp= ecified service function path. But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote= : Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543MBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style> <!-- .EmailQuote =09{margin-left:1pt; =09padding-left:4pt; =09border-left:#800000 2px solid} --> </style><style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">I see your point.   But even selecting an actor (SFI) could, it= self be an abstraction as in the "clustered SFI".  The perce= ived SFI, at the service overlay layer, could in actuality be another load balancing stage in-built to the cluster's functionality, t= hereby selecting the ultimate actor. <div><br> </div> <div>   Ron</div> <div><br> <div><br> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <hr tabindex=3D"-1"> <div id=3D"divRpF723682" style=3D"direction: ltr;"><font face=3D"Tahoma" si= ze=3D"2" color=3D"#000000"><b>From:</b> Ian Smith [I.Smith@F5.com]<br> <b>Sent:</b> Saturday, July 12, 2014 2:43 PM<br> <b>To:</b> Ron Parker<br> <b>Cc:</b> NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.bou= cadair@orange.com; Joel M. Halpern; Jim Guichard (jguichar)<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers<br> </font><br> </div> <div></div> <div> <div> <p dir=3D"ltr">Hmmm...   That seems to me to be to be excessively= fusing over language.</p> <p dir=3D"ltr">I think of 'next hop' as the nomenclature in any network whe= re there is, literally, a next hop decision.  In common usage of their= respective communities of expertise there are Ethernet next hops, IP next = hops, service next hops, and application next hops; it is contextual and no particular context owns it, as I'm sure= the aviation and circuit radio and mathematics communities would happily a= rgue.</p> <p dir=3D"ltr">In an overlay network context you are unaware of the underla= y so just as the Ethernet hops are transparent to an IP ping and the IPv4 h= ops are transparent to my he.net tunnel broker IPv6 connections, the hypoth= etical 'SFC ping' is going to ignore the underlay network and only show the SFIs in the specified service funct= ion path. </p> <p dir=3D"ltr">But the actual point I was trying to make is that there is a= consistent semantic difference between 'selecting a decider' which is what= you do if you make a next- hop selection amongst SNFs and/or SFFs, and 'se= lecting an actor' which is what you do when you make a next hop selection amongst SFIs, and you should differe= ntiate between them.</p> <div class=3D"x_quote">On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@a= ffirmednetworks.com> wrote:<br type=3D"attribution"> </div> </div> <font size=3D"2"><span style=3D"font-size:10pt"> <div class=3D"PlainText">Ian,<br> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com>= wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com" target=3D"= _blank">mailto:mn1921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blan= k">mailto:sfc-bounces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br= > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA,<= br> >> MARIA H;<br> >>> sfc@ietf.org<br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@iet= f.org;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> mohamed.boucadair@orange.com;<br> >>>>> sfc@ietf.org<br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org<br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <mn1921@att.com> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]= <br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@ora= nge.com;<br> >> sfc@ietf.org<br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <mn1921@att.com><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>]= On Behalf Of Joel<br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; mo= hamed.boucadair@orange.com;<br> >>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/list= info/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> sfc@ietf.org<br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc= </a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> sfc@ietf.org<br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> sfc@ietf.org<br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> sfc@ietf.org<br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> sfc@ietf.org<br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > sfc@ietf.org<br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> sfc@ietf.org<br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sfc</a><br> </div> </span></font></div> </div> </div> </div> </div> </body> </html> --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543MBX021W3CA2exch_-- From nobody Sat Jul 12 12:50:59 2014 Return-Path: <linda.dunbar@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3161A0303 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Bbglod-6nkZF for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:50:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B961A0331 for <sfc@ietf.org>; Sat, 12 Jul 2014 12:50:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHC94929; Sat, 12 Jul 2014 19:50:51 +0000 (GMT) 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; Sat, 12 Jul 2014 20:50:50 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Sat, 12 Jul 2014 12:50:37 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: =?ks_c_5601-1987?B?wMy9wsDN?= <seungiklee@etri.re.kr>, Linda Dunbar <linda.dunbar@huawei.com> Thread-Topic: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPZJC6YzxU2L8LkkGYvHb27F5SspuQyUGggAQxhuCAAOlkYIAGyTkQ Date: Sat, 12 Jul 2014 19:50:36 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D98D14@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8AE5FE@MBX021-W3-CA-2.exch021.domain.local> <2EDFB4D974E4AC45B641E2B5F734E6C21CD18203@SMTP1.etri.info> In-Reply-To: <2EDFB4D974E4AC45B641E2B5F734E6C21CD18203@SMTP1.etri.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.90] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D98D14dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/W4gYpdUhFA_EmauhfvDBZTyfYd8 Cc: "'sfc@ietf.org'" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 19:50:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D14dfweml701chmchi_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 U2V1bmctaWssDQoNClRoYW5rcyBmb3IgcmVhZGluZyB0aGUgZHJhZnQgYW5kIHRoZSBjb21tZW50 cy4NCg0KU29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlIGR1ZSB0byB0cmF2ZWxpbmcgYWJy b2FkLg0KDQpBbnN3ZXJzIGFyZSBpbnNlcnRlZCBiZWxvdzoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogwMy9wsDNIFttYWlsdG86c2V1bmdpa2xlZUBldHJpLnJlLmtyXQ0K U2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDExOjMxIFBNDQpUbzogTGluZGEgRHVuYmFyDQpD YzogUm9uIFBhcmtlcjsgJ3NmY0BpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlv bi0wMC50eHQNCg0KTGluZGEsDQoNCkFsc28gZ2xhZCB0byBzZWUgdGhpcyBpbiBhY3RpdmUuDQoN CjEuIFJlZ2FyZGluZyB0ZXJtaW5vbG9naWVzOiAic2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBj b21wb25lbnQiIGFuZCAic2VydmljZSBjaGFpbiBpbnN0YW5jZSBwYXRoIiwgd2hhdCBkaWZmZXJl bmNlcyBkbyB5b3UgaGF2ZSBpbiB5b3VyIG1pbmQgY29tcGFyaW5nIHdpdGggInNlcnZpY2UgZnVu Y3Rpb24gaW5zdGFuY2UiIGFuZCAic2VydmljZSBmdW5jdGlvbiBwYXRoIiwgcmVzcGVjdGl2ZWx5 Pw0KDQogICAgICBbTGluZGFdIFNlcnZpY2UgQ2hhaW4gSW5zdGFuY2UgcGF0aCBpcyB0aGUgInNl cXVlbmNlIG9mIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIiwgd2hlcmVhcyB0aGUgIlNlcnZp Y2UgRnVuY3Rpb24gcGF0aCIgaXMgYSAic2VxdWVuY2Ugb2YgU2VydmljZSBGdW5jdGlvbnMiIGF0 IGZ1bmN0aW9uYWwgbGV2ZWwuDQogICAgICBPbmUgc2VydmljZSBmdW5jdGlvbiBjb3VsZCBoYXZl IG11bHRpcGxlIGlkZW50aWNhbCBpbnN0YW5jZXMsIHBvdGVudGlhbGx5IGF0dGFjaGVkIHRvIGRp ZmZlcmVudCBTRkYgbm9kZXMuDQogICAgICBBdCBmdW5jdGlvbmFsIGxldmVsLCB0aGUgb3JkZXIg b2Ygc2VydmljZSBmdW5jdGlvbnMsIGUuZy4gQ2hhaW4jMSB7czEsIHM0LCBzNn0sIENoYWluIzJ7 czQsIHM3fSwgaXMgaW1wb3J0YW50LCBidXQgdmVyeSBvZnRlbiB3aGljaCBpbnN0YW5jZSBvZiB0 aGUgU2VydmljZSBGdW5jdGlvbiChsHMxobEgaXMgc2VsZWN0ZWQgZm9yIHRoZSBDaGFpbiAjMSBp cyBub3QuIEl0IGlzIGFsc28gcG9zc2libGUgdGhhdCBtdWx0aXBsZSBpbnN0YW5jZXMgb2Ygb25l IHNlcnZpY2UgZnVuY3Rpb24gY2FuIGJlIHJlYWNoZWQgYnkgZGlmZmVyZW50IG5ldHdvcmsgbm9k ZXMuIFRoZSBhY3R1YWwgaW5zdGFuY2Ugc2VsZWN0ZWQgZm9yIGEgc2VydmljZSBjaGFpbiBpcyBj YWxsZWQgobBTZXJ2aWNlIENoYWluIEluc3RhbmNlIFBhdGihsS4NCg0KMi4gSXQgc2VlbXMgdG8g bWUgdGhhdCB5b3VyIHRleHQgaXMgYWJvdXQgZHluYW1pYyB1cGRhdGUgb2YgU0ZDIHJhdGhlciB0 aGFuIHJlc3RvcmF0aW9uIGZyb20gZmFpbHVyZS4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCiAgICAg IFtMaW5kYV0gVGhlIKGwaW5zdGFuY2UgZmFpbHVyZaGxIHJlcXVpcmVzIHRoZSB1cGRhdGUgb2Yg dGhlIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2UgUGF0aC4gWWVzLCB0aGVyZSBjb3VsZCBiZSBv dGhlciByZWFzb25zIHRvIHRyaWdnZXIgdGhlIHVwZGF0ZSBvZiB0aGUgc2VydmljZSBmdW5jdGlv biBpbnN0YW5jZXMgcGF0aCwgc3VjaCBhcyBhZG1pbmlzdHJhdGl2ZSByZWFzb25zLCB1dGlsaXph dGlvbiwgZXRjLg0KDQoNClJlZ2FyZHMsDQpTZXVuZy1pay4NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFJvbiBQYXJrZXINCj4gU2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDk6NTIg UE0NCj4gVG86IExpbmRhIER1bmJhcjsgJ3NmY0BpZXRmLm9yZycNCj4gU3ViamVjdDogUmU6IFtz ZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4tDQo+ IGluc3RhbmNlcy1yZXN0b3JhdGlvbi0wMC50eHQNCj4NCj4gTGluZGEgJiBBbmR5LA0KPg0KPiBU aGFua3MgZm9yIHB1dHRpbmcgdGhpcyB0b2dldGhlci4gICBJJ20gaGFwcHkgdG8gc2VlIG1vcmUg d29yayBvbiB0aGUNCj4gImNoYWluLXRvLXBhdGgiIHRvcGljLiAgIEkgYWdyZWUgd2l0aCBhbGwg b2YgeW91ciBhbmFseXNpcyByZWdhcmRpbmcNCj4gcHJvcy9jb25zIG9mIHZhcmlvdXMgYXBwcm9h Y2hlcy4gICAgIEVuY2Fwc3VsYXRpb24gYW5kIENvbnRyb2wgUGxhbmUgd2lsbA0KPiBiZSBkZXBl bmRlbnQgb24gb3VyIGFyY2hpdGVjdHVyYWwgZGVjaXNpb25zIGluIHRoaXMgYXJlYS4gICBUaGUg ZWx1c2l2ZQ0KPiB0aGluZyBmb3IgYWxsIG9mIHVzLCBhcyBhIGdyb3VwLCBpcyB0byBjb21lIHRv IHNvbWUgY29uY2x1c2lvbnMhDQo+DQo+ICAgIFJvbg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIExpbmRhIER1bmJhcg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMDQsIDIwMTQgNDo0 OSBQTQ0KPiBUbzogJ3NmY0BpZXRmLm9yZycNCj4gU3ViamVjdDogW3NmY10gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1mdW4tDQo+IGluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMC50eHQNCj4NCj4gSGksDQo+DQo+IFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRo ZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCj4gICAgU2Vydmlj ZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24gdGhlIHBhdGggZmFp bCBvcg0KPiAgICBuZWVkIHRvIGJlIHJlcGxhY2VkLg0KPg0KPiBBcHByZWNpYXRlIHRvIGhlYXIg eW91ciBjb21tZW50cyBvciBzdWdnZXN0aW9ucy4NCj4NCj4gTGluZGEgJiBBbmR5DQo+DQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAzMCwgMjAxNCAxMToyNSBBTQ0K PiBUbzogQW5kcmV3IEcuIE1hbGlzOyBMaW5kYSBEdW5iYXI7IEFuZHJldyBHLiBNYWxpczsgTGlu ZGEgRHVuYmFyDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt ZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLQ0KPiByZXN0b3JhdGlvbi0wMC50eHQNCj4NCj4NCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+IGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1y ZXN0b3JhdGlvbi0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBM aW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPg0KPiBO YW1lOiAgICAgICAgIGRyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy1yZXN0b3JhdGlvbg0K PiBSZXZpc2lvbjogICAgIDAwDQo+IFRpdGxlOiAgICAgICAgICAgICAgICBGcmFtZXdvcmsgZm9y IFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2VzIFJlc3RvcmF0aW9uDQo+IERvY3VtZW50IGRhdGU6 ICAgICAgICAyMDE0LTA0LTI5DQo+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAgICAgICAgICAgIDEyDQo+IFVSTDogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kdW5iYXItc2ZjLWZ1bi0N Cj4gaW5zdGFuY2VzLXJlc3RvcmF0aW9uLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLXNmYy1mdW4tDQo+IGluc3Rh bmNlcy1yZXN0b3JhdGlvbi8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWR1bmJhci1zZmMtZnVuLWluc3RhbmNlcy0NCj4gcmVzdG9yYXRpb24tMDAN Cj4NCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdv cmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gb2YNCj4gICAgU2VydmljZSBDaGFpbiBJ bnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMgb24gdGhlIHBhdGggZmFpbCBvcg0KPiAg ICBuZWVkIHRvIGJlIHJlcGxhY2VkLg0KPg0KPg0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQN Cj4gdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5n IGxpc3QNCj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D14dfweml701chmchi_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dks_c_5601= -1987"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:= #800000 2px solid; } --></style> </head> <body> <font face=3D"Consolas" size=3D"2"><span style=3D"font-size:10.5pt;"> <div>Seung-ik, </div> <div> </div> <div>Thanks for reading the draft and the comments. </div> <div> </div> <div>Sorry for the delayed response due to traveling abroad. </div> <div><font face=3D"Times New Roman"> </font></div> <div>Answers are inserted below:</div> <div><font face=3D"Times New Roman"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>-----Original Message-----<br> From: <font face=3D"Batang">=C0=CC=BD=C2=C0=CD</font> [<a href=3D"mailto:se= ungiklee@etri.re.kr">mailto:seungiklee@etri.re.kr</a>] <br> Sent: Monday, July 07, 2014 11:31 PM<br> To: Linda Dunbar<br> Cc: Ron Parker; 'sfc@ietf.org'<br> Subject: RE: New Version Notification for draft-dunbar-sfc-fun-instances-re= storation-00.txt</div> <div><font face=3D"Times New Roman"> </font></div> <div>Linda,</div> <div> </div> <div>Also glad to see this in active.</div> <div> </div> <div>1. Regarding terminologies: "service function instance component&= quot; and "service chain instance path", what differences do you = have in your mind comparing with "service function instance" and = "service function path", respectively?</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] Service C= hain Instance path is the "sequence of service function instances"= ;, whereas the "Service Function path" is a "sequence of Ser= vice Functions" at functional level. </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">One service funct= ion could have multiple identical instances, potentially attached to differ= ent SFF nodes. </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">At functional lev= el, 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 = =A1=B0s1=A1=B1 is selected for the Chain #1 is not. It is also possible that multiple instances of one service function can be = reached by different network nodes. The actual instance selected for a serv= ice chain is called =A1=B0Service Chain Instance Path=A1=B1.</font></div> <div><font face=3D"Times New Roman"> </font></div> <div>2. It seems to me that your text is about dynamic update of SFC rather= than restoration from failure. What do you think?</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] The =A1= =B0instance failure=A1=B1 requires the update of the Service Function Insta= nce Path. Yes, there could be other reasons to trigger the update of the se= rvice function instances path, such as administrative reasons, utilization, etc. </font></div> <div><font face=3D"Times New Roman"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>Regards,</div> <div>Seung-ik.</div> <div> </div> <div>> -----Original Message-----</div> <div>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bou= nces@ietf.org</a>] On Behalf Of Ron Parker</div> <div>> Sent: Monday, July 07, 2014 9:52 PM</div> <div>> To: Linda Dunbar; 'sfc@ietf.org'</div> <div>> Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-= fun- </div> <div>> instances-restoration-00.txt</div> <div>> </div> <div>> Linda & Andy,</div> <div>> </div> <div>> Thanks for putting this together.   I'm happy to see mo= re work on the</div> <div>> "chain-to-path" topic.   I agree with all of = your analysis regarding</div> <div>> pros/cons of various approaches.     Encapsul= ation and Control Plane will</div> <div>> be dependent on our architectural decisions in this area. &n= bsp; The elusive</div> <div>> thing for all of us, as a group, is to come to some conclusions!<= /div> <div>> </div> <div>>    Ron</div> <div>> </div> <div>> </div> <div>> -----Original Message-----</div> <div>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bou= nces@ietf.org</a>] On Behalf Of Linda Dunbar</div> <div>> Sent: Friday, July 04, 2014 4:49 PM</div> <div>> To: 'sfc@ietf.org'</div> <div>> Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-= fun- </div> <div>> instances-restoration-00.txt</div> <div>> </div> <div>> Hi,</div> <div>> </div> <div>> This draft describes the framework of protection and restoration = of</div> <div>>    Service Chain Instance Path when some instances= on the path fail or</div> <div>>    need to be replaced.</div> <div>> </div> <div>> Appreciate to hear your comments or suggestions.</div> <div>> </div> <div>> Linda & Andy</div> <div>> </div> <div>> -----Original Message-----</div> <div>> From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts= @ietf.org</a> [<a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-= drafts@ietf.org</a>]</div> <div>> Sent: Wednesday, April 30, 2014 11:25 AM</div> <div>> To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar<= /div> <div>> Subject: New Version Notification for draft-dunbar-sfc-fun-instan= ces- </div> <div>> restoration-00.txt</div> <div>> </div> <div>> </div> <div>> A new version of I-D, </div> <div>> draft-dunbar-sfc-fun-instances-restoration-00.txt</div> <div>> has been successfully submitted by Linda Dunbar and posted to the= IETF </div> <div>> repository.</div> <div>> </div> <div>> Name:         draft-dunba= r-sfc-fun-instances-restoration</div> <div>> Revision:     00</div> <div>> Title:          = ;      Framework for Service Function Instances Re= storation</div> <div>> Document date:        2014-04-= 29</div> <div>> Group:          = ;      Individual Submission</div> <div>> Pages:          = ;      12</div> <div>> URL:          &= nbsp; <a href=3D"http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-"= >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-</a></div> <div>> instances-restoration-00.txt</div> <div>> Status:         <a href= =3D"https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-">https://datatra= cker.ietf.org/doc/draft-dunbar-sfc-fun-</a></div> <div>> instances-restoration/</div> <div>> Htmlized:       <a href=3D"http://t= ools.ietf.org/html/draft-dunbar-sfc-fun-instances-">http://tools.ietf.org/h= tml/draft-dunbar-sfc-fun-instances-</a></div> <div>> restoration-00</div> <div>> </div> <div>> </div> <div>> Abstract:</div> <div>>    This draft describes the framework of protectio= n and restoration of</div> <div>>    Service Chain Instance Path when some instances= on the path fail or</div> <div>>    need to be replaced.</div> <div>> </div> <div>> </div> <div>> </div> <div>> </div> <div>> Please note that it may take a couple of minutes from the time of= </div> <div>> submission until the htmlized version and diff are available at <= /div> <div>> tools.ietf.org.</div> <div>> </div> <div>> The IETF Secretariat</div> <div>> </div> <div>> _______________________________________________</div> <div>> sfc mailing list</div> <div>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></div> <div>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www= .ietf.org/mailman/listinfo/sfc</a></div> <div>> </div> <div>> _______________________________________________</div> <div>> sfc mailing list</div> <div>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></div> <div>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www= .ietf.org/mailman/listinfo/sfc</a></div> <div><font face=3D"Times New Roman"> </font></div> </span></font> </body> </html> --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D14dfweml701chmchi_-- From nobody Sat Jul 12 12:51:18 2014 Return-Path: <linda.dunbar@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5981A0303 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 D24xsJVz2kH8 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:50:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA1C1A033C for <sfc@ietf.org>; Sat, 12 Jul 2014 12:50:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX01406; Sat, 12 Jul 2014 19:50:52 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 12 Jul 2014 20:50:51 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Sat, 12 Jul 2014 12:50:38 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: "Ken Gray (kegray)" <kegray@cisco.com>, Linda Dunbar <linda.dunbar@huawei.com>, "'sfc@ietf.org'" <sfc@ietf.org> Thread-Topic: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPmvyXNnB3Xo9JN0+E/lYgsNPsd5ucRLyA Date: Sat, 12 Jul 2014 19:50:37 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D98D1B@dfweml701-chm.china.huawei.com> References: <CFE1D467.39387%kegray@cisco.com> In-Reply-To: <CFE1D467.39387%kegray@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.90] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D98D1Bdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xN6AYApy5jVmcfzsGOGpobMdI9U Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 19:50:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D1Bdfweml701chmchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ken, Thank you very much for the comments and suggestions. Replies are inserted below: -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Tuesday, July 08, 2014 5:33 PM To: Linda Dunbar; 'sfc@ietf.org' Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-in= stances-restoration-00.txt Hi, guys. I found the document a little confusing (could be me). I think you're tryi= ng to describe elasticity, but I don't think it connects well. A comment fairly common for the flurry of drafts that just came out =8A you= r SFIC is a new item not in any of the main documents. If we're to expand = our lexicon even for local discussion, I think the term Component is unnece= ssary. Instance is fine. [Linda] Thanks for the suggestion. I will use the "instance" instead.= For a service function with different functional instantiations, e.g. one = instantiation applies policy-set-A (NAT44-A) and other applies policy-set-B= (NAT44-B), they are considered as two different service functions." In the definition and throughout the document, I think you mix simple elast= icity and the function of a load_balancer/ADC (an SFF with non-publicly vis= ible instances behind it) with directly addressable instances of the same f= unction as well as overlook anycast IP for stateless functions. So, your s= cenarios need to be much more explicit, IMO, so they can be validated. [Linda] What is your definition of "simple elasticity"? On routers/switches, ECMP is commonly used to describe balancing amon= g multiple links, whereas ADC have very different connotation, most often r= eferring to balancing based on L4-L7 context. Since SFF is more likely to = be a forwarding device, I would prefer to avoid using "ADC" terminology to = refer SFF balancing among multiple instances of one same function directly= attached. Those instances in the draft can be publicly visible. For the on= es not publicly visible, it is internal decision with the SFF. In section 4.1 the scenario described in "It is also possible to have multi= ple identical SFICs attached to one Service Function Forwarder (SFF) node, = especially in a Network Function Virtualization (NFV) environment where eac= h SFIC is a virtual service function instance with limited capacity." seems= unlikely to me. It seems that it would be more likely that solution to th= e problem described would be to spawn the SFC with more resources instead o= f more instances UNLESS you are getting down to the ultimate resource limit= of bandwidth out of a NIC (10G limit) in which case you would probably dro= p back to a load balancing scenario? [Linda] The scenario in my mind is that there could be multiple vFW i= nstances instantiated on VMs attached to a ToR (the SFF). Each vFW instance= only has 1G throughput. Why it is not possible? A minor nit to the section " At the functional level, the order of service = functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which S= FIC of the Service Function "s1" is selected for the Chain #1 is not." If it's a stateful function, it probably does matter. [Linda] Thanks for pointing out this. For the stateful service functi= on, I should add that the instances selected for a chain should not be chan= ged for a flow. On " The benefit of encoding the exact path in every data packet is less co= ntention when there the Service Chain Instance Path changes.", I would have= to say that the benefits I see in encoding the path are that the traversed= path is captured in the flow for debugging and other use and you are passi= ng metadata along with it (optionally). I don't see how the path encoding = helps with contention if the path changes. Can you explain what you mean b= y contention and how this mitigates? [Linda] If the Controller sends the updated steering criteria for the= updated instance path directly to the relevant SFF nodes, we might need a = mechanism to guarantee that all relevant SFF nodes have installed the updat= ed steering policies before packets arrive. Another approach is to drop packets (like MPLS FRR approach)until all= SFF nodes complete installing the updated steering criteria. On " However, there are major drawbacks, such as - extra packet header fields are needed to carry the exact instance path, t= hat can increase the likelihood of packet fragmentation due to MTU size, an= d - extra encapsulation processing load at the head end Service Chain classif= ier node.", I'D venture that this is a bit speculative and perhaps temporal= (limited to some scenarios and the capabilities of existing hardware). We= have endured header expansion and encapsulation changes before, what makes= this one so hard to cope with in the long term or are you only talking abo= ut short term (in which case, is it major)? For " Packet fragmentation and reassembly is very processor and memory inte= nsive. Good practice is to avoid packet fragmentation and reassembly as muc= h as possible. Carry an exact instance path in every packet might be possib= le if service function instances can be represented by compact labels, simi= lar to the MPLS label stack.", I think our our IPv6 brethren might find tha= t a parochial view. Generally, for most of section 4, it seems to me that the problems describe= d are essentially handled by elasticity controls, and abstraction (e.g. any= cast IP or a load balance function). The entities are normally managed (op= en source tools are available) in a feedback loop =8A in short, this is a v= ery addressable and well known problem with existing products and methodolo= gies to mitigate, are you suggesting a unique solution or the general scena= rio of how elasticity works =8A if the latter, I think you need to make tha= t clear? [Linda] What do you mean by "elasticity controls"? When multiple ins= tances are attached to different SFFs, it is "global LB". Section 5 displays the amount of detail that these simple abstractions shou= ld actually hide from classification and that we made explicit example of i= n earlier documents (these things shouldn't cause an explosion in the numbe= r of discrete service chains). That is kind of amplified in the earlier te= xt " If each Service Function has a large number of SFICs, it scales better i= f the Service Chain classifier only identifies the service chain at the fun= ctional level, and there is another entity managing the detailed service in= stance path." Can you explain this in more depth? This is where I think you're actually = trying to describe what we discussed as "should be avoided and unnecessary"= =8Athat is the explosion of paths in the face of elasticity. Section 6, Are you talking about discretely addressable functions or non? If non, and the SFF is responsible for "distribution", the numbering of the= instances is really irrelevant and is again a back end elasticity function= known only to the SFF =8A and, to me, it's really unlikely that you would = track or move a discrete element from behind one SFF that provides such a d= istribution function to another and still consider it the same element. Ra= ther, it is "one of many". On 7/4/14 4:48 PM, "Linda Dunbar" <linda.dunbar@huawei.com<mailto:linda.dun= bar@huawei.com>> wrote: >Hi, > >This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > >Appreciate to hear your comments or suggestions. > >Linda & Andy > >-----Original Message----- >From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:in= ternet-drafts@ietf.org] >Sent: Wednesday, April 30, 2014 11:25 AM >To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >Subject: New Version Notification for >draft-dunbar-sfc-fun-instances-restoration-00.txt > > >A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt >has been successfully submitted by Linda Dunbar and posted to the IETF >repository. > >Name: draft-dunbar-sfc-fun-instances-restoration >Revision: 00 >Title: Framework for Service Function Instances Restoration >Document date: 2014-04-29 >Group: Individual Submission >Pages: 12 >URL: >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-rest >ora >tion-00.txt >Status: >https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restora >tio >n/ >Htmlized: >http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-0 >0 > > >Abstract: > This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > > > > > >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<mailto:sfc@ietf.org> >https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D1Bdfweml701chmchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:= #800000 2px solid; } --></style> </head> <body> <font face=3D"Consolas" size=3D"2"><span style=3D"font-size:10.5pt;"> <div><font color=3D"#002060">Ken, </font></div> <div><font color=3D"#002060"> </font></div> <div><font color=3D"#002060">Thank you very much for the comments and sugge= stions. </font></div> <div><font color=3D"#002060"> </font></div> <div><font color=3D"#002060">Replies are inserted below: </font></div> <div><font face=3D"Times New Roman"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>-----Original Message-----<br> From: Ken Gray (kegray) [<a href=3D"mailto:kegray@cisco.com">mailto:kegray@= cisco.com</a>] <br> Sent: Tuesday, July 08, 2014 5:33 PM<br> To: Linda Dunbar; 'sfc@ietf.org'<br> Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-in= stances-restoration-00.txt</div> <div><font face=3D"Times New Roman"> </font></div> <div>Hi, guys.</div> <div> </div> <div>I found the document a little confusing (could be me).  I think y= ou're trying to describe elasticity, but I don't think it connects well.</d= iv> <div> </div> <div>A comment fairly common for the flurry of drafts that just came out = =8A your SFIC is a new item not in any of the main documents.  If we'r= e to expand our lexicon even for local discussion, I think the term Compone= nt is unnecessary.  Instance is fine.</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font face=3D"Calibri" size=3D"2" color= =3D"#002060"><span style=3D"font-size:11pt;">[Linda] Thanks for the suggest= ion. I will use the "instance" instead. For a service function wi= th different functional instantiations, e.g. one instantiation applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions."</span></font></= div> <div style=3D"padding-left:36pt;"><font face=3D"Times New Roman"> </fo= nt></div> <div><font face=3D"Times New Roman"> </font></div> <div>In the definition and throughout the document, I think you mix simple = elasticity and the function of a load_balancer/ADC (an SFF with non-publicl= y visible instances behind it) with directly addressable instances of the s= ame function as well as overlook anycast IP for stateless functions.  So, your scenarios need to be muc= h more explicit, IMO, so they can be validated.</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font face=3D"Calibri" size=3D"2" color= =3D"#002060"><span style=3D"font-size:11pt;">[Linda] What is your definitio= n of "simple elasticity"? </span></font></div> <div style=3D"padding-left:36pt;"><font face=3D"Calibri" size=3D"2" color= =3D"#002060"><span style=3D"font-size:11pt;">On routers/switches, ECMP is c= ommonly used to describe balancing among multiple links, whereas ADC have v= ery different connotation, most often referring to balancing  based on L4-L7 context. Since SFF is more likely to be a= forwarding device, I would prefer to avoid using "ADC" terminolo= gy to refer SFF balancing among multiple instances of one same function di= rectly attached. Those instances in the draft can be publicly visible. For the ones not publicly visible, it is internal deci= sion with the SFF. </span></font></div> <div style=3D"padding-left:36pt;"><font face=3D"Calibri" size=3D"2" color= =3D"#002060"><span style=3D"font-size:11pt;"> </span></font></div> <div style=3D"padding-left:36pt;"><font face=3D"Calibri" size=3D"2" color= =3D"#002060"><span style=3D"font-size:11pt;"> </span></font></div> <div><font face=3D"Times New Roman"> </font></div> <div>In section 4.1 the scenario described in "It is also possible to = have multiple identical SFICs attached to one Service Function Forwarder (S= FF) node, especially in a Network Function Virtualization (NFV) environment= where each SFIC is a virtual service function instance with limited capacity." seems unlikely to me.  = It seems that it would be more likely that solution to the problem describe= d would be to spawn the SFC with more resources instead of more instances U= NLESS you are getting down to the ultimate resource limit of bandwidth out of a NIC (10G limit) in which case you woul= d probably drop back to a load balancing scenario?</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] The scena= rio in my mind is that there could be multiple vFW instances instantiated o= n VMs attached to a ToR (the SFF). Each vFW instance only has 1G throughput= . </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">Why it is not pos= sible? </font></div> <div><font face=3D"Times New Roman"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>A minor nit to the section " At the functional level, the order o= f service functions, e.g.</div> <div>Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often wh= ich SFIC of the Service Function "s1" is selected for the Chain #= 1 is not."</div> <div>If it's a stateful function, it probably does matter.</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] Thanks fo= r pointing out this. For the stateful service function, I should add that t= he instances selected for a chain should not be changed for a flow. </font>= </div> <div><font face=3D"Times New Roman"> </font></div> <div>On " The benefit of encoding the exact path in every data packet = is less contention when there the Service Chain Instance Path changes."= ;, I would have to say that the benefits I see in encoding the path are tha= t the traversed path is captured in the flow for debugging and other use and you are passing metadata along with it (opt= ionally).  I don't see how the path encoding helps with contention if = the path changes.  Can you explain what you mean by contention and how= this mitigates?</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] If the Co= ntroller sends the updated steering criteria for the updated instance path = directly to the relevant SFF nodes, we might need a mechanism to guarantee = that all relevant SFF nodes have installed the updated steering policies before packets arrive. </font></div> <div style=3D"padding-left:36pt;"><font face=3D"Times New Roman" color=3D"#= 002060"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">Another approach = is to drop packets (like MPLS FRR approach)until all SFF nodes complete ins= talling the updated steering criteria. </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060"> </font></di= v> <div style=3D"padding-left:36pt;"><font color=3D"#002060"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>On " However, there are major drawbacks, such as</div> <div>- extra packet header fields are needed to carry the exact instance pa= th, that can increase the likelihood of packet fragmentation due to MTU siz= e, and</div> <div>- extra encapsulation processing load at the head end Service Chain cl= assifier node.", I'D venture that this is a bit speculative and perhap= s temporal (limited to some scenarios and the capabilities of existing hard= ware).  We have endured header expansion and encapsulation changes before, what makes this one so hard to cope with = in the long term or are you only talking about short term (in which case, i= s it major)?</div> <div> </div> <div>For " Packet fragmentation and reassembly is very processor and m= emory intensive. Good practice is to avoid packet fragmentation and reassem= bly as much as possible. Carry an exact instance path in every packet might= be possible if service function instances can be represented by compact labels, similar to the MPLS label stack."= ;, I think our our IPv6 brethren might find that a parochial view.</div> <div> </div> <div> </div> <div>Generally, for most of section 4, it seems to me that the problems des= cribed are essentially handled by elasticity controls, and abstraction (e.g= . anycast IP or a load balance function).  The entities are normally m= anaged (open source tools are available) in a feedback loop =8A in short, this is a very addressable and well known = problem with existing products and methodologies to mitigate, are you sugge= sting a unique solution or the general scenario of how elasticity works =8A= if the latter, I think you need to make that clear?</div> <div><font face=3D"Times New Roman"> </font></div> <div style=3D"padding-left:36pt;"><font color=3D"#002060">[Linda] What do y= ou mean by "elasticity controls"? When multiple instances are at= tached to different SFFs, it is "global LB". </font></div> <div style=3D"padding-left:36pt;"><font face=3D"Times New Roman" color=3D"#= 002060"> </font></div> <div><font face=3D"Times New Roman"> </font></div> <div>Section 5 displays the amount of detail that these simple abstractions= should actually hide from classification and that we made explicit example= of in earlier documents (these things shouldn't cause an explosion in the = number of discrete service chains).  That is kind of amplified in the earlier text</div> <div> </div> <div> " If each Service Function has a large number of SFICs, it scale= s better if the Service Chain classifier only identifies the service chain = at the functional level, and there is another entity managing the detailed = service instance path."</div> <div> </div> <div>Can you explain this in more depth?  This is where I think you're= actually trying to describe what we discussed as "should be avoided a= nd unnecessary" =8Athat is the explosion of paths in the face of elast= icity.</div> <div> </div> <div>Section 6, Are you talking about discretely addressable functions or n= on?</div> <div>If non, and the SFF is responsible for "distribution", the n= umbering of the instances is really irrelevant and is again a back end elas= ticity function known only to the SFF =8A and, to me, it's really unlikely = that you would track or move a discrete element from behind one SFF that provides such a distribution function to another a= nd still consider it the same element.  Rather, it is "one of man= y".</div> <div> </div> <div>On 7/4/14 4:48 PM, "Linda Dunbar" <<a href=3D"mailto:lind= a.dunbar@huawei.com">linda.dunbar@huawei.com</a>> wrote:</div> <div> </div> <div>>Hi,</div> <div>></div> <div>>This draft describes the framework of protection and restoration o= f</div> <div>>   Service Chain Instance Path when some instances on th= e path fail or</div> <div>>   need to be replaced.</div> <div>></div> <div>>Appreciate to hear your comments or suggestions.</div> <div>></div> <div>>Linda & Andy</div> <div>></div> <div>>-----Original Message-----</div> <div>>From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@= ietf.org</a> [<a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-d= rafts@ietf.org</a>]</div> <div>>Sent: Wednesday, April 30, 2014 11:25 AM</div> <div>>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar</= div> <div>>Subject: New Version Notification for</div> <div>>draft-dunbar-sfc-fun-instances-restoration-00.txt</div> <div>></div> <div>></div> <div>>A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-0= 0.txt</div> <div>>has been successfully submitted by Linda Dunbar and posted to the = IETF </div> <div>>repository.</div> <div>></div> <div>>Name:          draft-= dunbar-sfc-fun-instances-restoration</div> <div>>Revision:      00</div> <div>>Title:         Framework f= or Service Function Instances Restoration</div> <div>>Document date: 2014-04-29</div> <div>>Group:         Individual = Submission</div> <div>>Pages:         12</div> <div>>URL:          &n= bsp; </div> <div>><a href=3D"http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fu= n-instances-rest">http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-= instances-rest</a></div> <div>>ora</div> <div>>tion-00.txt</div> <div>>Status:         </div> <div>><a href=3D"https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-i= nstances-restora">https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-ins= tances-restora</a></div> <div>>tio</div> <div>>n/</div> <div>>Htmlized:       </div> <div>><a href=3D"http://tools.ietf.org/html/draft-dunbar-sfc-fun-instanc= es-restoration-0">http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances= -restoration-0</a></div> <div>>0</div> <div>></div> <div>></div> <div>>Abstract:</div> <div>>   This draft describes the framework of protection and = restoration of</div> <div>>   Service Chain Instance Path when some instances on th= e path fail or</div> <div>>   need to be replaced.</div> <div>></div> <div>>           =        </div> <div>>        </div> <div>></div> <div>></div> <div>>Please note that it may take a couple of minutes from the time of = </div> <div>>submission until the htmlized version and diff are available at </= div> <div>>tools.ietf.org.</div> <div>></div> <div>>The IETF Secretariat</div> <div>></div> <div>>_______________________________________________</div> <div>>sfc mailing list</div> <div>><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></div> <div>><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.= ietf.org/mailman/listinfo/sfc</a></div> <div><font face=3D"Times New Roman"> </font></div> <div><font face=3D"Times New Roman"> </font></div> </span></font> </body> </html> --_000_4A95BA014132FF49AE685FAB4B9F17F645D98D1Bdfweml701chmchi_-- From nobody Sat Jul 12 12:52:29 2014 Return-Path: <I.Smith@f5.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47D1A0303 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.651 X-Spam-Level: X-Spam-Status: No, score=-7.651 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.651, 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 vgKBwA22d2Nr for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 12:52:20 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1DA1A0331 for <sfc@ietf.org>; Sat, 12 Jul 2014 12:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1405194742; x=1436730742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UFc6CthlzPTa2L101lzNYuLA0mx1uOw2w2COykKhCtU=; b=Q6uUGf7JbPe2jRLVrTRJymEYJjTlHdONofNBOOMsTnK3afHQPQIJnZby 3YUVs6P5OVLxrlBuS106PsR3zlwZpmMKFalPwHW4V/q85HGXUL5OZSbh4 sRrUzFGYqUGTI5Xr7ujQhaeM6slunhuC/9FPXd7axrgdX4aPcswCz2AsW o=; X-IronPort-AV: E=Sophos;i="5.01,650,1400025600"; d="scan'208,217";a="121616999" X-IPAS-Result: ArEEAAuRwVPAqArr/2dsb2JhbABZgkeBGVrBGhgBCYdDAYEndYQDAQEBAQIBAQEBCwwBSgYDBgUFBwQCAQgRAQMBAQEKFgEGByEGCxQDBggCBA4FCBOIEwMJFb9aDYcoF40egVYmBiEGBAYBAgQDgySBFgWKIoxRghuNaoIdiVqBb0E Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 12 Jul 2014 19:52:20 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Sat, 12 Jul 2014 12:52:17 -0700 From: Ian Smith <I.Smith@F5.com> To: Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigCAAATDAIABKX+AgAABkICAAAXiAIABxGYAgABmtQCAANRKgP//pzgmgACTCAD//5s/V4AAdokA//+a9dE= Date: Sat, 12 Jul 2014 19:52:17 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A83F50E@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6543@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A83F50ESEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6KIJew4bFCKN1RyHjY3jEF1ELnY Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 19:52:26 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A83F50ESEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perhaps, although as a practical matter, I probably would not embed a load = balancer into an SFI - either the load balancers _is_ and SFI, and it makes= a selection of opaque resources; or it is an SFI, and it makes a selection= of other SFIs; or it is an SFF. In most cases the difference between the = first and the last is strictly semantic because the outcome is the same - t= he SFP includes only the SF* that is a virtual server abstracting a destina= tion for a pool of resources. ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Saturday, July 12, 2014 2:47 PM To: Ian Smith Cc: NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.boucadair@= orange.com; Joel M. Halpern; Jim Guichard (jguichar) Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I see your point. But even selecting an actor (SFI) could, itself be an a= bstraction as in the "clustered SFI". The perceived SFI, at the service ov= erlay layer, could in actuality be another load balancing stage in-built to= the cluster's functionality, thereby selecting the ultimate actor. Ron ________________________________ From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 2:43 PM To: Ron Parker Cc: NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.boucadair@= orange.com; Joel M. Halpern; Jim Guichard (jguichar) Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Hmmm... That seems to me to be to be excessively fusing over language. I think of 'next hop' as the nomenclature in any network where there is, li= terally, a next hop decision. In common usage of their respective communit= ies of expertise there are Ethernet next hops, IP next hops, service next h= ops, and application next hops; it is contextual and no particular context = owns it, as I'm sure the aviation and circuit radio and mathematics communi= ties would happily argue. In an overlay network context you are unaware of the underlay so just as th= e Ethernet hops are transparent to an IP ping and the IPv4 hops are transpa= rent to my he.net tunnel broker IPv6 connections, the hypothetical 'SFC pin= g' is going to ignore the underlay network and only show the SFIs in the sp= ecified service function path. But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote= : Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A83F50ESEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style>=0A= <!--=0A= .EmailQuote=0A= {margin-left:1pt;=0A= padding-left:4pt;=0A= border-left:#800000 2px solid}=0A= -->=0A= </style><style type=3D"text/css" id=3D"owaParaStyle">=0A= <!--=0A= -->=0A= P {margin-top:0;margin-bottom:0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Perhaps, although as a practical matter, I probably would not embed = a load balancer into an SFI - either the load balancers _is_ and SFI, and i= t makes a selection of opaque resources; or it is an SFI, and it makes a selection of other SFIs; or it is an SFF.&= nbsp; In most cases the difference between the first and the last is strict= ly semantic because the outcome is the same - the SFP includes only the SF*= that is a virtual server abstracting a destination for a pool of resources.<br> <br> <br> <br> <br> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <hr tabindex=3D"-1"> <div style=3D"direction: ltr;" id=3D"divRpF618227"><font color=3D"#000000" = face=3D"Tahoma" size=3D"2"><b>From:</b> Ron Parker [Ron_Parker@affirmednetw= orks.com]<br> <b>Sent:</b> Saturday, July 12, 2014 2:47 PM<br> <b>To:</b> Ian Smith<br> <b>Cc:</b> NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.bou= cadair@orange.com; Joel M. Halpern; Jim Guichard (jguichar)<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers<br> </font><br> </div> <div></div> <div> <div style=3D"direction:ltr; font-family:Tahoma; color:#000000; font-size:1= 0pt">I see your point.   But even selecting an actor (SFI) could, itse= lf be an abstraction as in the "clustered SFI".  The perceiv= ed SFI, at the service overlay layer, could in actuality be another load balancing stage in-built to the cluster's functionality, t= hereby selecting the ultimate actor. <div><br> </div> <div>   Ron</div> <div><br> <div><br> <div style=3D"font-family:Times New Roman; color:#000000; font-size:16px"> <hr tabindex=3D"-1"> <div id=3D"divRpF723682" style=3D"direction:ltr"><font color=3D"#000000" fa= ce=3D"Tahoma" size=3D"2"><b>From:</b> Ian Smith [I.Smith@F5.com]<br> <b>Sent:</b> Saturday, July 12, 2014 2:43 PM<br> <b>To:</b> Ron Parker<br> <b>Cc:</b> NAPIERALA, MARIA H; Sharon; Eric Gray; sfc@ietf.org; mohamed.bou= cadair@orange.com; Joel M. Halpern; Jim Guichard (jguichar)<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers<br> </font><br> </div> <div></div> <div> <div> <p dir=3D"ltr">Hmmm...   That seems to me to be to be excessively= fusing over language.</p> <p dir=3D"ltr">I think of 'next hop' as the nomenclature in any network whe= re there is, literally, a next hop decision.  In common usage of their= respective communities of expertise there are Ethernet next hops, IP next = hops, service next hops, and application next hops; it is contextual and no particular context owns it, as I'm sure= the aviation and circuit radio and mathematics communities would happily a= rgue.</p> <p dir=3D"ltr">In an overlay network context you are unaware of the underla= y so just as the Ethernet hops are transparent to an IP ping and the IPv4 h= ops are transparent to my he.net tunnel broker IPv6 connections, the hypoth= etical 'SFC ping' is going to ignore the underlay network and only show the SFIs in the specified service funct= ion path. </p> <p dir=3D"ltr">But the actual point I was trying to make is that there is a= consistent semantic difference between 'selecting a decider' which is what= you do if you make a next- hop selection amongst SNFs and/or SFFs, and 'se= lecting an actor' which is what you do when you make a next hop selection amongst SFIs, and you should differe= ntiate between them.</p> <div class=3D"x_quote">On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@a= ffirmednetworks.com> wrote:<br type=3D"attribution"> </div> </div> <font size=3D"2"><span style=3D"font-size:10pt"> <div class=3D"PlainText">Ian,<br> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com>= wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com" target=3D"= _blank">mailto:mn1921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blan= k">mailto:sfc-bounces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org<br= > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA,<= br> >> MARIA H;<br> >>> sfc@ietf.org<br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@iet= f.org;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> mohamed.boucadair@orange.com;<br> >>>>> sfc@ietf.org<br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <Ron_Parker@affirmednetworks.com> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com;= sfc@ietf.org<br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <mn1921@att.com> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]= <br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@ora= nge.com;<br> >> sfc@ietf.org<br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <mn1921@att.com><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>]= On Behalf Of Joel<br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; mo= hamed.boucadair@orange.com;<br> >>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> sfc@ietf.org<br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/list= info/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> sfc@ietf.org<br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc= </a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> sfc@ietf.org<br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> sfc@ietf.org<br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> sfc@ietf.org<br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> sfc@ietf.org<br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > sfc@ietf.org<br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> sfc@ietf.org<br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sfc</a><br> </div> </span></font></div> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_419417C345CA5F48BF45F0A23955A0634A83F50ESEAEMBX02olympu_-- From nobody Sat Jul 12 15:23:04 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13461A0AC3 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 15:23:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 F1wuPD8vgwh5 for <sfc@ietfa.amsl.com>; Sat, 12 Jul 2014 15:22:55 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC881A04C2 for <sfc@ietf.org>; Sat, 12 Jul 2014 15:22:55 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id EBF5D53DEE; Sat, 12 Jul 2014 15:22:52 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 12 Jul 2014 15:22:52.883 -0700 x-echoworx-msg-id: c46ecd09-51fa-40cd-bdcb-ef6fe056dbf1 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 37; Sat, 12 Jul 2014 15:22:52 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id BE0FE53DEE; Sat, 12 Jul 2014 15:22:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Sat, 12 Jul 2014 15:22:54 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Linda Dunbar <linda.dunbar@huawei.com>, "Ken Gray (kegray)" <kegray@cisco.com>, "'sfc@ietf.org'" <sfc@ietf.org> Thread-Topic: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt Thread-Index: AQHPmvyXNnB3Xo9JN0+E/lYgsNPsd5ucRLyAgADD7EA= Date: Sat, 12 Jul 2014 22:22:53 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B65EE@MBX021-W3-CA-2.exch021.domain.local> References: <CFE1D467.39387%kegray@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645D98D1B@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D98D1B@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B65EEMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QQc__esDDX3YeUEdY7kGAOXinyM Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 12 Jul 2014 22:23:02 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B65EEMBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Linda, I think you are expressing some assumptions around SFF that are definitely = shared by some, but not all of the participants on this thread: "The scenario in my mind is that there could be multiple vFW instances inst= antiated on VMs attached to a ToR (the SFF)" It is totally natural that all of us bring different assumptions and percep= tions to the problem space and this is why we have these lengthy but ultima= tely constructive threads :). Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Saturday, July 12, 2014 3:51 PM To: Ken Gray (kegray); Linda Dunbar; 'sfc@ietf.org' Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-in= stances-restoration-00.txt Ken, Thank you very much for the comments and suggestions. Replies are inserted below: -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Tuesday, July 08, 2014 5:33 PM To: Linda Dunbar; 'sfc@ietf.org' Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-in= stances-restoration-00.txt Hi, guys. I found the document a little confusing (could be me). I think you're tryi= ng to describe elasticity, but I don't think it connects well. A comment fairly common for the flurry of drafts that just came out =A9 you= r SFIC is a new item not in any of the main documents. If we're to expand = our lexicon even for local discussion, I think the term Component is unnece= ssary. Instance is fine. [Linda] Thanks for the suggestion. I will use the "instance" instead. For a= service function with different functional instantiations, e.g. one instan= tiation applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT4= 4-B), they are considered as two different service functions." In the definition and throughout the document, I think you mix simple elast= icity and the function of a load_balancer/ADC (an SFF with non-publicly vis= ible instances behind it) with directly addressable instances of the same f= unction as well as overlook anycast IP for stateless functions. So, your s= cenarios need to be much more explicit, IMO, so they can be validated. [Linda] What is your definition of "simple elasticity"? On routers/switches, ECMP is commonly used to describe balancing among mult= iple links, whereas ADC have very different connotation, most often referri= ng to balancing based on L4-L7 context. Since SFF is more likely to be a f= orwarding device, I would prefer to avoid using "ADC" terminology to refer = SFF balancing among multiple instances of one same function directly attach= ed. Those instances in the draft can be publicly visible. For the ones not = publicly visible, it is internal decision with the SFF. In section 4.1 the scenario described in "It is also possible to have multi= ple identical SFICs attached to one Service Function Forwarder (SFF) node, = especially in a Network Function Virtualization (NFV) environment where eac= h SFIC is a virtual service function instance with limited capacity." seems= unlikely to me. It seems that it would be more likely that solution to th= e problem described would be to spawn the SFC with more resources instead o= f more instances UNLESS you are getting down to the ultimate resource limit= of bandwidth out of a NIC (10G limit) in which case you would probably dro= p back to a load balancing scenario? [Linda] The scenario in my mind is that there could be multiple vFW instanc= es instantiated on VMs attached to a ToR (the SFF). Each vFW instance only = has 1G throughput. Why it is not possible? A minor nit to the section " At the functional level, the order of service = functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which S= FIC of the Service Function "s1" is selected for the Chain #1 is not." If it's a stateful function, it probably does matter. [Linda] Thanks for pointing out this. For the stateful service function, I = should add that the instances selected for a chain should not be changed fo= r a flow. On " The benefit of encoding the exact path in every data packet is less co= ntention when there the Service Chain Instance Path changes.", I would have= to say that the benefits I see in encoding the path are that the traversed= path is captured in the flow for debugging and other use and you are passi= ng metadata along with it (optionally). I don't see how the path encoding = helps with contention if the path changes. Can you explain what you mean b= y contention and how this mitigates? [Linda] If the Controller sends the updated steering criteria for the updat= ed instance path directly to the relevant SFF nodes, we might need a mechan= ism to guarantee that all relevant SFF nodes have installed the updated ste= ering policies before packets arrive. Another approach is to drop packets (like MPLS FRR approach)until all SFF n= odes complete installing the updated steering criteria. On " However, there are major drawbacks, such as - extra packet header fields are needed to carry the exact instance path, t= hat can increase the likelihood of packet fragmentation due to MTU size, an= d - extra encapsulation processing load at the head end Service Chain classif= ier node.", I'D venture that this is a bit speculative and perhaps temporal= (limited to some scenarios and the capabilities of existing hardware). We= have endured header expansion and encapsulation changes before, what makes= this one so hard to cope with in the long term or are you only talking abo= ut short term (in which case, is it major)? For " Packet fragmentation and reassembly is very processor and memory inte= nsive. Good practice is to avoid packet fragmentation and reassembly as muc= h as possible. Carry an exact instance path in every packet might be possib= le if service function instances can be represented by compact labels, simi= lar to the MPLS label stack.", I think our our IPv6 brethren might find tha= t a parochial view. Generally, for most of section 4, it seems to me that the problems describe= d are essentially handled by elasticity controls, and abstraction (e.g. any= cast IP or a load balance function). The entities are normally managed (op= en source tools are available) in a feedback loop =A9 in short, this is a v= ery addressable and well known problem with existing products and methodolo= gies to mitigate, are you suggesting a unique solution or the general scena= rio of how elasticity works =A9 if the latter, I think you need to make tha= t clear? [Linda] What do you mean by "elasticity controls"? When multiple instances = are attached to different SFFs, it is "global LB". Section 5 displays the amount of detail that these simple abstractions shou= ld actually hide from classification and that we made explicit example of i= n earlier documents (these things shouldn't cause an explosion in the numbe= r of discrete service chains). That is kind of amplified in the earlier te= xt " If each Service Function has a large number of SFICs, it scales better if= the Service Chain classifier only identifies the service chain at the func= tional level, and there is another entity managing the detailed service ins= tance path." Can you explain this in more depth? This is where I think you're actually = trying to describe what we discussed as "should be avoided and unnecessary"= =A9that is the explosion of paths in the face of elasticity. Section 6, Are you talking about discretely addressable functions or non? If non, and the SFF is responsible for "distribution", the numbering of the= instances is really irrelevant and is again a back end elasticity function= known only to the SFF =A9 and, to me, it's really unlikely that you would = track or move a discrete element from behind one SFF that provides such a d= istribution function to another and still consider it the same element. Ra= ther, it is "one of many". On 7/4/14 4:48 PM, "Linda Dunbar" <linda.dunbar@huawei.com<mailto:linda.dun= bar@huawei.com>> wrote: >Hi, > >This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > >Appreciate to hear your comments or suggestions. > >Linda & Andy > >-----Original Message----- >From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:in= ternet-drafts@ietf.org] >Sent: Wednesday, April 30, 2014 11:25 AM >To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >Subject: New Version Notification for >draft-dunbar-sfc-fun-instances-restoration-00.txt > > >A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt >has been successfully submitted by Linda Dunbar and posted to the IETF >repository. > >Name: draft-dunbar-sfc-fun-instances-restoration >Revision: 00 >Title: Framework for Service Function Instances Restoration >Document date: 2014-04-29 >Group: Individual Submission >Pages: 12 >URL: >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-rest >ora >tion-00.txt >Status: >https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restora >tio >n/ >Htmlized: >http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-0 >0 > > >Abstract: > This draft describes the framework of protection and restoration of > Service Chain Instance Path when some instances on the path fail or > need to be replaced. > > > > > >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<mailto:sfc@ietf.org> >https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B65EEMBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face =09{font-family:Wingdings; =09panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face =09{font-family:"Cambria Math"; =09panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face =09{font-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face =09{font-family:Consolas; =09panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal =09{margin:0in; =09margin-bottom:.0001pt; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink =09{mso-style-priority:99; =09color:blue; =09text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed =09{mso-style-priority:99; =09color:purple; =09text-decoration:underline;} p.emailquote, li.emailquote, div.emailquote =09{mso-style-name:emailquote; =09mso-margin-top-alt:auto; =09margin-right:0in; =09mso-margin-bottom-alt:auto; =09margin-left:1.0pt; =09border:none; =09padding:0in; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} span.EmailStyle18 =09{mso-style-type:personal-reply; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} .MsoChpDefault =09{mso-style-type:export-only; =09font-size:10.0pt;} @page WordSection1 =09{size:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 =09{page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I think you are expressin= g some assumptions around SFF that are definitely shared by some, but not a= ll of the participants on this thread:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">“The scenario in my mind is that there could be multi= ple vFW instances instantiated on VMs attached to a ToR (the SFF)”<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">It is totally natural that all of us bring different assump= tions and perceptions to the problem space and this is why we have these le= ngthy but ultimately constructive threads </span><span style=3D"font-size:10.5pt;font-family:Wingdings;color:#002060"= >J</span><span style=3D"font-size:10.5pt;font-family:Consolas;color:#002060= ">.</span><span style=3D"font-size:11.0pt;font-family:"Calibri",&= quot;sans-serif";color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">   Ron<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [m= ailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Linda Dunbar<br> <b>Sent:</b> Saturday, July 12, 2014 3:51 PM<br> <b>To:</b> Ken Gray (kegray); Linda Dunbar; 'sfc@ietf.org'<br> <b>Subject:</b> Re: [sfc] FW: New Version Notification for draft-dunbar-sfc= -fun-instances-restoration-00.txt<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">Ken, </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060"> </span><span style=3D"font-size:10.5pt;font-family:Co= nsolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">Thank you very much for the comments and suggestions. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060"> </span><span style=3D"font-size:10.5pt;font-family:Co= nsolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">Replies are inserted below: </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">-----Original Message-----<br> From: Ken Gray (kegray) [<a href=3D"mailto:kegray@cisco.com">mailto:kegray@= cisco.com</a>] <br> Sent: Tuesday, July 08, 2014 5:33 PM<br> To: Linda Dunbar; 'sfc@ietf.org'<br> Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-in= stances-restoration-00.txt<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Hi, guys.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">I found the document a little confusing (could be me).  I think you'= re trying to describe elasticity, but I don't think it connects well.<o:p><= /o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">A comment fairly common for the flurry of drafts that just came out =A9 y= our SFIC is a new item not in any of the main documents.  If we're to = expand our lexicon even for local discussion, I think the term Component is unnecessary.  Instance is fine.<o:p></o= :p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">[Linda] Thanks for the su= ggestion. I will use the "instance" instead. For a service functi= on with different functional instantiations, e.g. one instantiation applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), t= hey are considered as two different service functions."</span><span st= yle=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">In the definition and throughout the document, I think you mix simple ela= sticity and the function of a load_balancer/ADC (an SFF with non-publicly v= isible instances behind it) with directly addressable instances of the same function as well as overlook anycast IP = for stateless functions.  So, your scenarios need to be much more expl= icit, IMO, so they can be validated.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">[Linda] What is your defi= nition of "simple elasticity"? </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060">On routers/switches, ECMP= is commonly used to describe balancing among multiple links, whereas ADC h= ave very different connotation, most often referring to balancing  based on L4-L7 context. Since SFF is more likely to be a f= orwarding device, I would prefer to avoid using "ADC" terminology= to refer SFF balancing among multiple instances of one same function direc= tly attached. Those instances in the draft can be publicly visible. For the ones not publicly visible, it is internal dec= ision with the SFF. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060"> </span><span style= =3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#002060"> </span><span style= =3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">In section 4.1 the scenario described in "It is also possible to hav= e multiple identical SFICs attached to one Service Function Forwarder (SFF)= node, especially in a Network Function Virtualization (NFV) environment where each SFIC is a virtual service function instance w= ith limited capacity." seems unlikely to me.  It seems that it wo= uld be more likely that solution to the problem described would be to spawn= the SFC with more resources instead of more instances UNLESS you are getting down to the ultimate resource limit of ba= ndwidth out of a NIC (10G limit) in which case you would probably drop back= to a load balancing scenario?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">[Linda] The scenario in my mind is that there could be mult= iple vFW instances instantiated on VMs attached to a ToR (the SFF). Each vF= W instance only has 1G throughput. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">Why it is not possible? </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">A minor nit to the section " At the functional level, the order of s= ervice functions, e.g.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which= SFIC of the Service Function "s1" is selected for the Chain #1 i= s not."<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">If it's a stateful function, it probably does matter.<o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">[Linda] Thanks for pointing out this. For the stateful serv= ice function, I should add that the instances selected for a chain should n= ot be changed for a flow. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">On " The benefit of encoding the exact path in every data packet is = less contention when there the Service Chain Instance Path changes.", = I would have to say that the benefits I see in encoding the path are that the traversed path is captured in the flow for = debugging and other use and you are passing metadata along with it (optiona= lly).  I don't see how the path encoding helps with contention if the = path changes.  Can you explain what you mean by contention and how this mitigates?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">[Linda] If the Controller sends the updated steering criter= ia for the updated instance path directly to the relevant SFF nodes, we mig= ht need a mechanism to guarantee that all relevant SFF nodes have installed the updated steering policies before= packets arrive. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;color:#002060"> = ;</span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></= span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">Another approach is to drop packets (like MPLS FRR approach= )until all SFF nodes complete installing the updated steering criteria. </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060"> </span><span style=3D"font-size:10.5pt;font-family:Co= nsolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">On " However, there are major drawbacks, such as<o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">- extra packet header fields are needed to carry the exact instance path,= that can increase the likelihood of packet fragmentation due to MTU size, = and<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">- extra encapsulation processing load at the head end Service Chain class= ifier node.", I'D venture that this is a bit speculative and perhaps t= emporal (limited to some scenarios and the capabilities of existing hardware).  We have endured header expansion= and encapsulation changes before, what makes this one so hard to cope with= in the long term or are you only talking about short term (in which case, = is it major)?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">For " Packet fragmentation and reassembly is very processor and memo= ry intensive. Good practice is to avoid packet fragmentation and reassembly= as much as possible. Carry an exact instance path in every packet might be possible if service function instances can b= e represented by compact labels, similar to the MPLS label stack.", I = think our our IPv6 brethren might find that a parochial view.<o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Generally, for most of section 4, it seems to me that the problems descri= bed are essentially handled by elasticity controls, and abstraction (e.g. a= nycast IP or a load balance function).  The entities are normally managed (open source tools are available) in a f= eedback loop =A9 in short, this is a very addressable and well known proble= m with existing products and methodologies to mitigate, are you suggesting = a unique solution or the general scenario of how elasticity works =A9 if the latter, I think you need to make that c= lear?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ;color:#002060">[Linda] What do you mean by "elasticity controls"= ? When multiple instances are attached to different SFFs, it is "globa= l LB". </span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></s= pan></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;color:#002060"> = ;</span><span style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></= span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Section 5 displays the amount of detail that these simple abstractions sh= ould actually hide from classification and that we made explicit example of= in earlier documents (these things shouldn't cause an explosion in the number of discrete service chains).&nb= sp; That is kind of amplified in the earlier text<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">" If each Service Function has a large number of SFICs, it scales be= tter if the Service Chain classifier only identifies the service chain at t= he functional level, and there is another entity managing the detailed service instance path."<o:p></o:p></span= ></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Can you explain this in more depth?  This is where I think you're ac= tually trying to describe what we discussed as "should be avoided and = unnecessary" =A9that is the explosion of paths in the face of elasticity.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">Section 6, Are you talking about discretely addressable functions or non?= <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">If non, and the SFF is responsible for "distribution", the numb= ering of the instances is really irrelevant and is again a back end elastic= ity function known only to the SFF =A9 and, to me, it's really unlikely that you would track or move a discrete element from = behind one SFF that provides such a distribution function to another and st= ill consider it the same element.  Rather, it is "one of many&quo= t;.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">On 7/4/14 4:48 PM, "Linda Dunbar" <<a href=3D"mailto:linda.d= unbar@huawei.com">linda.dunbar@huawei.com</a>> wrote:<o:p></o:p></span><= /p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= "> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Hi,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>This draft describes the framework of protection and restoration of<o= :p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>   Service Chain Instance Path when some instances on the p= ath fail or<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>   need to be replaced.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Appreciate to hear your comments or suggestions.<o:p></o:p></span></p= > </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Linda & Andy<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>-----Original Message-----<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>From: <a href=3D"mailto:internet-drafts@ietf.org"> internet-drafts@ietf.org</a> [<a href=3D"mailto:internet-drafts@ietf.org">m= ailto:internet-drafts@ietf.org</a>]<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Sent: Wednesday, April 30, 2014 11:25 AM<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar<o:p>= </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Subject: New Version Notification for<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>draft-dunbar-sfc-fun-instances-restoration-00.txt<o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.t= xt<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>has been successfully submitted by Linda Dunbar and posted to the IET= F <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>repository.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Name:          draft-dun= bar-sfc-fun-instances-restoration<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Revision:      00<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Title:         Framework for = Service Function Instances Restoration<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Document date: 2014-04-29<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Group:         Individual Sub= mission<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Pages:         12<o:p></o:p><= /span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>URL:           = ; <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><a href=3D"http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-i= nstances-rest">http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-ins= tances-rest</a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>ora<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>tion-00.txt<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Status:         <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><a href=3D"https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-inst= ances-restora">https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instan= ces-restora</a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>tio<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>n/<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Htmlized:       <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><a href=3D"http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-= restoration-0">http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-re= storation-0</a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>0<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Abstract:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>   This draft describes the framework of protection and res= toration of<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>   Service Chain Instance Path when some instances on the p= ath fail or<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>   need to be replaced.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>           &nb= sp;      <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>        <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>Please note that it may take a couple of minutes from the time of <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>submission until the htmlized version and diff are available at <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>tools.ietf.org.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>The IETF Secretariat<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>_______________________________________________<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">>sfc mailing list<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><o:p></o:p></span></p= > </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:Consolas= ">><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.iet= f.org/mailman/listinfo/sfc</a><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt"> </span><span = style=3D"font-size:10.5pt;font-family:Consolas"><o:p></o:p></span></p> </div> </div> </body> </html> --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B65EEMBX021W3CA2exch_-- From nobody Sun Jul 13 18:24:59 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C949D1A0218 for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 18:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ToL4d5tnlDX6 for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 18:24:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2135A1A023F for <sfc@ietf.org>; Sun, 13 Jul 2014 18:24:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX74620; Mon, 14 Jul 2014 01:24:51 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 02:24:50 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 09:24:39 +0800 From: Qin Wu <bill.wu@huawei.com> To: "Ken Gray (kegray)" <kegray@cisco.com> Thread-Topic: draft-wu-pce-traffic-steering-sfc-04 Thread-Index: AQHPmxzb7qK3d3xA0EGKphRP2OMpJ5uXBEZAgASzb2WAAxMCMA== Date: Mon, 14 Jul 2014 01:24:39 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA84582517@nkgeml501-mbs.china.huawei.com> References: <CFE21C68.39402%kegray@cisco.com>, <B8F9A780D330094D99AF023C5877DABA84580AA2@nkgeml501-mbs.china.huawei.com> <3F7F9B7F-2100-4873-9246-06747CF87CE9@cisco.com> In-Reply-To: <3F7F9B7F-2100-4873-9246-06747CF87CE9@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IHxl3k-XQ3Zgh2fy0l56g6G6YkI Cc: Dhruv Dhody <dhruv.dhody@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com>, Linda Dunbar <linda.dunbar@huawei.com> Subject: Re: [sfc] draft-wu-pce-traffic-steering-sfc-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 01:24:56 -0000 SGksIEtlbjoNCkp1c3QgdG8gY2xhcmlmeSwgd2hhdCB3ZSBwcm9wb3NlZCBpbiBkcmFmdC13dS1w Y2UtdHJhZmZpYy1zdGVlcmluZy1zZmMtMDQgaXMgbm90IHJlbGF0ZWQgdG8gc2VnbWVudCByb3V0 aW5nIG9yIHNvdXJjZSByb3V0aW5nIGJhc2VkIGFwcHJvYWNoLg0KVG8gaWRlbnRpZnkgYSBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluLCB5b3UgbmVlZCBhIGNoYWluIElEIG9yIHNlcnZpY2UgZnVuY3Rp b24gbWFwIGluZGV4IHByb3Bvc2VkIGluIGJvdWNhZGlyIGZyYW1ld29yayBkcmFmdC4NClRvIGlk ZW50aWZ5IGEgc2VydmljZSBmdW5jdGlvbiBwYXRoLCB5b3UgY2FuIHVzZSBhIHNldCBvZiBsb2Nh dG9ycyBhbmQgZWFjaCBsb2NhdG9yIGNvcnJlc3BvbmRpbmcgdG8gZWFjaCBzZXJ2aWNlIGZ1bmN0 aW9uIGZvciBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4uDQpEZXBlbmRpbmcgb24gd2hh dCB0aGUgSUQgb2YgdGhlIFNGQyBIZWFkZXIgc2hvdWxkIHJlZmVyZW5jZSAodGhlIGNoYWluIG9y IHRoZSBwYXRoKSwgc2VlIE1pa2UncyBjb21tZW50DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDIyMjIuaHRtbA0KDQpQQ0UgY2FuIHJldHVybiBj b3JyZXNwb25kaW5nIHRvIElEIChlaXRoZXIgcGF0aCBJRCBvciBjaGFpbiBJRCkgdG8gdGhlIGNs YXNzaWZpZXIgYW5kIGVzdGFibGlzaA0KVGhlIG1hcHBpbmcgYmV0d2VlbiBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWluIGFuZCBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGguDQpTbyB0aGUgU0ZQIElEIHByb3Bv c2VkIGluIGRyYWZ0LXd1LXBjZS10cmFmZmljLXN0ZWVyaW5nLXNmYy0wNCBjYW4gYmUgdGhhdCBw YXRoIElEIG9yIGNoYWluIElELiBJbiBteSBvcGluaW9uLCBjaGFpbiBJRCBtYXkgYmUgbW9yZSBh cHByb3ByaWF0ZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBjaXNjby5jb21dIA0Kt6LLzcqxvOQ6 IDIwMTTE6jfUwjEyyNUgMTA6MTQNCsrVvP7IyzogUWluIFd1DQqzrcvNOiBSb24gUGFya2VyOyBM aW5kYSBEdW5iYXI7IHNmY0BpZXRmLm9yZzsgRGhydXYgRGhvZHkNCtb3zOI6IFJlOiBkcmFmdC13 dS1wY2UtdHJhZmZpYy1zdGVlcmluZy1zZmMtMDQNCg0KSSdtIG5vdCBjb252aW5jZWQgdGhhdCB5 b3UgbmVlZCB0aGF0LCB0byBiZSBob25lc3QuICBJdCBzZWVtcyB0aGF0IHRoZSBuZWVkIGZvciBl eHRlbnNpb25zIGlzIHRpZWQgdG8gdGhlIGFzc3VtcHRpb24gdGhhdCB5b3UgbmVlZCBzb21lIHNv cnQgb2Ygc3BlY2lhbCBsYWJlbCB0byBpbmRpY2F0ZSB0aGF0IGFuIG92ZXJsYXkgaW5zdGFuY2Ug KExTUCwgU1IgU0lELCBldGMpIHdhcyBjcmVhdGVkIHRvIGJlIGEgc2VydmljZSBwYXRoIC0gYnV0 IEkganVzdCBkb24ndCBzZWUgdGhhdCBhcyBhIHJlcXVpcmVtZW50LiAgSXRzIGFscmVhZHkgbGFi ZWxlZCAoYXMgdHVubmVseCBvciBTSUQgdmFsdWUgeSBvciBOZXh0SG9weikgYW5kIHRoZSBhc3Nv Y2lhdGlvbiBhcyBhIFNQIGNhbiBiZSBtYWludGFpbmVkIGVsc2V3aGVyZSAobGlrZSBzZmMgY29u dHJvbC9tYW5hZ2VtZW50IGFwcCkuICBUbyBtZSwgaXQgc2VlbXMgbW9yZSBvZiBhIGNvbnZlbmll bmNlIHRoYW4gYSBuZWNlc3NpdHkuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwg OCwgMjAxNCwgYXQgMTA6MzUgUE0sICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3Rl Og0KPiANCj4gTm90IG9ubHkgaW5kaWNhdGUgaXQgaXMgYW4gU0ZQLCBidXQgYWxzbyB5b3UgbmVl ZCB0byB0ZWxsIGNsYXNzaWZpZXIgd2hpY2ggc2VydmljZSBmdW5jdGlvbiBwYXRoIHlvdSBuZWVk IHRvIGluc3RhbnRpYXRlPw0KPiBXaXRob3V0IHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBJRCwgaG93 IGRvIHlvdSBrbm93IHdoaWNoIHBhdGggeW91IG5lZWQgdG8gY3JlYXRlLCB3aGljaCBwYXRoIHlv dSBuZWVkIHRvIHVwZGF0ZSAsd2hpY2ggcGF0aCB5b3UgbmVlZCB0byBkZWxldGU/DQo+IA0KPiBS ZWdhcmRpbmcgd2hlcmUgdG8gcHV0IFNGUCwgSSB0aGluayBhdCBsZWFzdCBjbGFzc2lmaWVyIHNo b3VsZCANCj4gbWFpbnRhaW4gcGF0aCBpbmZvcm1hdGlvbiB3aGljaCB1c2UgU0ZQIElEIHRvIGRp c3RpbmN0IG9uZSBwYXRoIGZyb20gDQo+IGFub3RoZXIsIFlvdSBtYXkgcHV0IGl0IGludG8gd2hh dGV2ZXIgb3ZlcmxheSBoZWFkZXIgeW91IHdhbnQgdG8gdXNlLiANCj4gSWYgeW91IHRoaW5rIGl0 IGlzIGEgYnVyZGVuLCB5b3UgY2FuIGNob29zZSBub3QgcHV0IGl0IGludG8gdGhlIG92ZXJsYXkg aGVhZGVyIGFuZCB1c2Ugb3RoZXIgc2lnbmFsaW5nIHRvIHNldHVwIHNlcnZpY2UgZnVuY3Rpb24g cGF0aCwgZS5nLiwgeW91IGhhdmUgU0ROIGNvbnRyb2xsZXIgb3IgeW91IGhhdmUgTk1TL09TUywg Tk1TL09TUyB3aWxsIHRyYW5zbGF0ZSBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGludG8gcGF0aCBp bmZvcm1hdGlvbiBiYXNlZCBvbiBTRlAgSUQgYW5kIHBvcHVsYXRlIHN1Y2ggcGF0aCBpbmZvcm1h dGlvbiB3aXRoIFNGUCBJRCB0byBlYWNoIHBhcnRpY2lwYXRpbmcgbm9kZSBpbiB0aGUgc2Vydmlj ZSBjaGFpbi4NCj4gQWxsIGluIGFsbCwgYXMgSSBjbGFyaWZpZWQgZWFybGllciwgU0ZQIElEIGJh c2VkIHNvbHV0aW9uIGRvZXNuJ3QgY291cGxlIHdpdGggdGhlIHNpZ25hbGluZyB5b3UgYXJlIHVz ZWQuDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+ yMs6IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj4gt6LLzcqx vOQ6IDIwMTTE6jfUwjnI1SAxMDoyNA0KPiDK1bz+yMs6IFFpbiBXdTsgUm9uIFBhcmtlcjsgTGlu ZGEgRHVuYmFyOyAnc2ZjQGlldGYub3JnJw0KPiDW98ziOiBSRTogZHJhZnQtd3UtcGNlLXRyYWZm aWMtc3RlZXJpbmctc2ZjLTA0DQo+IA0KPiBJIGhhZCBhIGNvdXBsZSBxdWVzdGlvbnMgb24gdGhp cyChrQ0KPiANCj4gSWYgdGhlIHBvaW50IGlzIHRoYXQgYSBQQ0UgY291bGQgY29tcHV0ZSB0aGUg cGF0aCBiYXNlZCBvbiBhIHBvbGljeSwgd2UncmUgcHJvYmFibHkgYWxsIGluIGFncmVlbWVudC4g V2hlcmUgSSBnZXQgbG9zdCBpcyBpbiB0aGUgbmVlZCBmb3IgdGhlIFRMViBleHRlbnNpb24gdG8g aW5kaWNhdGUgaXQncyBhbiBTRlAuICBUaGF0IGZhY3Qgd291bGQsIElNTywgYmUgbWFuYWdlZCBh dCBhIGhpZ2hlciBsZXZlbCAtIGFzIGl0IHdvdWxkIGJlIGZvciBhbnkgb3ZlcmxheSBjb25zdHJ1 Y3QgKFZYTEFOLCBHUkUsIHlvdXItZmF2b3JpdGUtb3ZlcmxheS1lbmNhcC1oZXJlKS4gIEl0IGFw cGVhcnMgYW4gdW5uZWNlc3NhcnkgaW5mb3JtYXRpb25hbCBidXJkZW4sIElNTy4gIENhbiB5b3Ug ZXhwbGFpbiBob3cgeW91IGVudmlzaW9uIHRoaXMgYmVpbmcgdXNlZD8NCj4gDQo+PiBPbiA3Lzcv MTQgOToxMiBBTSwgIlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+ IFJvbjoNCj4+IFdlIGFsc28gaGF2ZSBkcmFmdCB0byBkaXNjdXNzIGhvdyB0byBpbnN0YW50aWF0 ZSBzZXJ2aWNlIGZ1bmN0aW9uIA0KPj4gcGF0aCB1c2luZyBQQ0UtaW5pdGlhdGUgTFNQIGluc3Rh bnRpYXRpb24uDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1wY2UtdHJh ZmZpYy1zdGVlcmluZy1zZmMtMDQNCj4+IEl0IHN1cHBvcnRzIGR5bmFtaWMgY3JlYXRpb24gYW5k IGRlbGV0aW9uIG9mIHNlcnZpY2UgZnVuY3Rpb24gcGF0aC4NCj4+IFlvdXIgbWF5IGNoZWNrIG91 dC4NCj4+IA0KPj4gUmVnYXJkcyENCj4+IC1RaW4NCj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4g t6K8/sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb24gUGFya2Vy DQo+PiC3osvNyrG85DogMjAxNMTqN9TCN8jVIDIwOjUyDQo+PiDK1bz+yMs6IExpbmRhIER1bmJh cjsgJ3NmY0BpZXRmLm9yZycNCj4+INb3zOI6IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIA0KPj4gZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0aW9u LTAwLnR4dA0KPj4gDQo+PiBMaW5kYSAmIEFuZHksDQo+PiANCj4+IFRoYW5rcyBmb3IgcHV0dGlu ZyB0aGlzIHRvZ2V0aGVyLiAgIEknbSBoYXBweSB0byBzZWUgbW9yZSB3b3JrIG9uIHRoZQ0KPj4g ImNoYWluLXRvLXBhdGgiIHRvcGljLiAgIEkgYWdyZWUgd2l0aCBhbGwgb2YgeW91ciBhbmFseXNp cyByZWdhcmRpbmcNCj4+IHByb3MvY29ucyBvZiB2YXJpb3VzIGFwcHJvYWNoZXMuICAgICBFbmNh cHN1bGF0aW9uIGFuZCBDb250cm9sIFBsYW5lIHdpbGwNCj4+IGJlIGRlcGVuZGVudCBvbiBvdXIg YXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgaW4gdGhpcyBhcmVhLiAgIFRoZSBlbHVzaXZlDQo+PiB0 aGluZyBmb3IgYWxsIG9mIHVzLCBhcyBhIGdyb3VwLCBpcyB0byBjb21lIHRvIHNvbWUgY29uY2x1 c2lvbnMhDQo+PiANCj4+ICBSb24NCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMaW5kYSBEdW5iYXINCj4+IFNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA0OjQ5IFBN DQo+PiBUbzogJ3NmY0BpZXRmLm9yZycNCj4+IFN1YmplY3Q6IFtzZmNdIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIA0KPj4gZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJl c3RvcmF0aW9uLTAwLnR4dA0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gVGhpcyBkcmFmdCBkZXNjcmli ZXMgdGhlIGZyYW1ld29yayBvZiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBvZiAgDQo+PiBT ZXJ2aWNlIENoYWluIEluc3RhbmNlIFBhdGggd2hlbiBzb21lIGluc3RhbmNlcyBvbiB0aGUgcGF0 aCBmYWlsIG9yICANCj4+IG5lZWQgdG8gYmUgcmVwbGFjZWQuDQo+PiANCj4+IEFwcHJlY2lhdGUg dG8gaGVhciB5b3VyIGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zLg0KPj4gDQo+PiBMaW5kYSAmIEFu ZHkNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+IFNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMzAsIDIwMTQgMTE6MjUgQU0NCj4+IFRvOiBBbmRyZXcgRy4g TWFsaXM7IExpbmRhIER1bmJhcjsgQW5kcmV3IEcuIE1hbGlzOyBMaW5kYSBEdW5iYXINCj4+IFN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1kdW5iYXItc2Zj LWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24tMDAudHh0DQo+PiANCj4+IA0KPj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIA0KPj4gZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3RvcmF0 aW9uLTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBE dW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgDQo+PiBJRVRGIHJlcG9zaXRvcnkuDQo+PiANCj4+IE5h bWU6ICAgICAgICBkcmFmdC1kdW5iYXItc2ZjLWZ1bi1pbnN0YW5jZXMtcmVzdG9yYXRpb24NCj4+ IFJldmlzaW9uOiAgICAwMA0KPj4gVGl0bGU6ICAgICAgICBGcmFtZXdvcmsgZm9yIFNlcnZpY2Ug RnVuY3Rpb24gSW5zdGFuY2VzIFJlc3RvcmF0aW9uDQo+PiBEb2N1bWVudCBkYXRlOiAgICAyMDE0 LTA0LTI5DQo+PiBHcm91cDogICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFnZXM6 ICAgICAgICAxMg0KPj4gVVJMOiAgICAgICAgICAgIA0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlDQo+PiBzdA0K Pj4gb3JhDQo+PiB0aW9uLTAwLnR4dA0KPj4gU3RhdHVzOiAgICAgICAgIA0KPj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJl c3RvDQo+PiByYQ0KPj4gdGlvDQo+PiBuLw0KPj4gSHRtbGl6ZWQ6ICAgICAgIA0KPj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLXNmYy1mdW4taW5zdGFuY2VzLXJlc3Rv cmF0aW9uDQo+PiAtMA0KPj4gMA0KPj4gDQo+PiANCj4+IEFic3RyYWN0Og0KPj4gIFRoaXMgZHJh ZnQgZGVzY3JpYmVzIHRoZSBmcmFtZXdvcmsgb2YgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24g b2YgIA0KPj4gU2VydmljZSBDaGFpbiBJbnN0YW5jZSBQYXRoIHdoZW4gc29tZSBpbnN0YW5jZXMg b24gdGhlIHBhdGggZmFpbCBvciAgDQo+PiBuZWVkIHRvIGJlIHJlcGxhY2VkLg0KPj4gDQo+PiAN Cj4+IA0KPj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IA0KPj4gdG9vbHMuaWV0Zi5v cmcuDQo+PiANCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+ PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAN Cg== From nobody Sun Jul 13 20:30:17 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF90A1A02A0 for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 20:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 aLpZzCvhDQMO for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 20:30:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784301A029D for <sfc@ietf.org>; Sun, 13 Jul 2014 20:30:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHD73340; Mon, 14 Jul 2014 03:30:00 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 04:29:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 11:29:54 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "Ron_Parker@affirmednetworks.com" <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: Redefine the SFP//RE: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WI7utfJ2LekG5x1cj4qbXj5uYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHID///EV4P//g6sAgAAEboCAAANgAIAAB9gAgAAGp4CAAAK6AIAAJooA//vLYaA= Date: Mon, 14 Jul 2014 03:29:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VVInFcYBhKgMoLzH7WpF2C9X_Hk Subject: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 03:30:14 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAgaW4gdGhlIGFyY2gg ZHJhZnQgaXMgYSBiaXQgY29uZnVzaW5nLCBqdXN0IGFzIHdoYXQgeW91IGhhZCBwb2ludGVkIG91 dC4NCg0KDQoNCkluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBTRlAgYXMgYW4gaW5zdGFudGlhdGlv biBvZiBhbiBTRkMgaW4gdGhlIG5ldHdvcmsgc2hvdWxkIGJlIOKAnGFuIG9yZGVyZWQgbGlzdCBv ZiBzZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0oc2VlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEpLiBPZiBjb3Vyc2UsIGhv dyB0byByZXByZXNlbnQgdGhlIFNGUCBpbiB0aGUgZGF0YSBwYWNrZXQgaXMgYW5vdGhlciB0aGlu ZyAoZS5nLiwgZWl0aGVyIHRocm91Z2ggYSBwYXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBsYWJl bCBzdGFjaykuIEhlcmUgdGhlIHNlcnZpY2Ugbm9kZSBtZWFucyB0aGUgZGV2aWNlIHdoaWNoIGNv bnRhaW5zIHRoZSBTRkYgYW5kIHRoZSBORiBjb21wb25lbnRzIG1hbmRhdG9yaWx5IHdoaWxlIGNv bnRhaW5pbmcgdGhlIFNGIGFuZCBTRiBwcm94eSBjb21wb25lbnRzIG9wdGlvbmFsbHkuIFRoZSBz ZXJ2aWNlIG5vZGUgY291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aCBtdWx0aXBsZSBT RiBpbnN0YW5jZXMgYW5kIHRob3NlIFNGIGluc3RhbmNlcyBjb3VsZCBiZSBvZiB0aGUgc2FtZSBT RiB0eXBlIG9yIG5vdC4gIEluIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBTRiBp bnN0YW5jZXMgb2YgdGhlIHNhbWUgU0YgdHlwZSAoZS5nLiwgU0YgWCkgYXJlIGF0dGFjaGVkIHRv IGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlIGNvdWxkIGRpc3RyaWJ1dGUg dGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBpbnN0YW5jZXMgb2Yg U0YgWCB0eXBlIGxvY2FsbHkuIE1lYW53aGlsZSwgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHNlcnZp Y2Ugbm9kZXMgd2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoaWNoIGFyZSBlbWJl ZGRlZCBvciBhdHRhY2hlZCB3aXRoIHRoZSBTRiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgU0YgdHlw ZS4gSW4gdGhpcyB3YXksIHRoZSBTRiBsb2FkLWJhbGFuY2luZyB3b3VsZCBiZSBtYWRlIHZlcnkg ZmxleGlibGUuDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wuY29t DQpTZW50OiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2IEFNDQpUbzogamd1aWNoYXJAY2lz Y28uY29tOyBtbjE5MjFAYXR0LmNvbTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgam1o QGpvZWxoYWxwZXJuLmNvbTsgUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCg0KV291bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNlIGNoYWlu IGlkZW50aWZpZXIiIHRoZW4/ICBJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBs aXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNG IGluc3RhbmNlcywgdGhlbiBJIHdvdWxkIGluZmVyIHRoYXQgYSAic2VydmljZSBwYXRoIGlkZW50 aWZpZXIiIHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBh IHNlcnZpY2UgKmNoYWluKi4NCg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29u ZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGluLiAgVGhlIHRlcm1zICJjaGFpbiIgYW5kICJwYXRoIiBz ZWVtIGluY29uc2lzdGVudC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IG1pa2ViaWFuY0Bhb2wu Y29tPG1pa2ViaWFuY0Bhb2wuY29tPixtbjE5MjFAYXR0LmNvbTxtbjE5MjFAYXR0LmNvbT4sbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPixq bWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2VsaGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4sc2ZjQGlldGYu b3JnPHNmY0BpZXRmLm9yZzxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2NtaWtlYmlhbmNAYW9s LmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21uMTkyMUBhdHQuY29tJTNlLG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTNlLGptaEBqb2Vs aGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJTNlLHNmY0BpZXRm Lm9yZyUzY3NmY0BpZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQNClN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K WW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9y d2FyZGluZyBwYXRoIHRocm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRo ZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBob3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZSBj aGFpbiBkYXRhIHN0cnVjdHVyZSBhbmQgdGhhdCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmlj IGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMg YXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlz IGluIHBsYXkuIFdoZW4gaW5zdGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBu ZXR3b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBz cGVjaWZ5IHdoaWNoIG5leHQtaG9wcyBtYXkgYmUgdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1o b3Agd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNl cnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wg LyBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQoNCkZy b206ICJtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJp YW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPj4NCkRhdGU6IEZyaWRheSwgSnVs eSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KVG86IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28u Y29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzpt bjE5MjFAYXR0LmNvbT4iIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Piwg Im1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPj4sICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PiwgInNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KDQpJIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCg0K PiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5DQo+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwg UzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KPiBhc3NpZ24gYSBz ZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRv IFMxLT5TMi0+UzMNCj4gYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsNCg0KQnkg ZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJl ZCBsaXN0IG9mIHNwZWNpZmljIFNGIGluc3RhbmNlcy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwg eW91IHVzZSBhICJzZXJ2aWNlIHBhdGggaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2aWNl ICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0gc3BlY2lmeSBzcGVjaWZpYyBp bnN0YW5jZXMiLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBq Z3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48amd1aWNoYXJAY2lz Y28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEg SDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Pj4sSm9lbCBNLiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+PixSb24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDog RnJpZGF5LCBKdWx5IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KTWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhp cyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRv DQphIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3Mu IFdoZW4geW91IGRlZmluZSBhDQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3Ug Km1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQt aG9wcyB0aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4N Ckhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHN0YW5kcG9pbnQgKEkNCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u 4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBh IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhl biBwdXNoIHRoYXQgaW5mb3JtYXRpb24gaW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3 aWxsIGhhdmUgYQ0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNh aWQgbWFwcGluZyB3b3VsZCBjb250YWluIHRoZQ0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFj aCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4 dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50 cmFsaXplZA0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRo ZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0Kc29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIg Li4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90IGNvcnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2 aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkN CmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkg cmVjb21tZW5kZWQpIHRvIGRvDQpzby4NCg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9w ZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoNCg0KSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVy IHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMg c2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8g c3BlY2lmeQ0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNv bWJpbmF0aW9uIHRoZXJlb2YpLiBJDQphc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDi gJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1 c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMg YXJlDQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYs IHdoZW4gdHJhZmZpYyBhcnJpdmVzDQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwg dGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5k IHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQpl bmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFp bi4gTGV04oCZcyBzYXkgd2UNCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBu b3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29r dXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6 MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIx QGF0dC5jb20+PiB3cm90ZToNCg0KPkppbSwNCj4NCj5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlz IHRoZSBkZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4ic2VydmljZSBwYXRo IGlkZW50aWZpZXIiPw0KPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3Rh bmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoDQo+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5k aW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPm5leHQtaG9w IFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1hcmlhDQo+ DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogSmltIEd1aWNo YXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBGcmlk YXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+OyBKb2VsIE0uDQo+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxs eSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IHBy ZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBp dCBhIHNlcnZpY2UNCj4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+ Pg0KPj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFA YXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4+DQo+PiA+RGl0dG8uDQo+ PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4NCj4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+ID4+IFNl bnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4gPj4gVG86IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+ PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gU3Vi amVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+PiA+Pg0KPj4gPj4gUmUtLA0KPj4gPj4NCj4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBi ZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPj5kcmFmdC4NCj4+ID4+ DQo+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYg YSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4+ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+IG1vZGVsIGlzIG5v dCBhbGxvd2VkLg0KPj4gPj4NCj4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGlu ZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZg0KPj4gPj5zaG91bGQgYmUNCj4+ ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+PiA+Pg0KPj4gPj4gQ2hlZXJzLA0KPj4gPj4gTWVkDQo+ PiA+Pg0KPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4gPkRlIDogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJk DQo+PiA+PiA+KGpndWljaGFyKQ0KPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0 IDIwMTQgMTY6MTgNCj4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxw ZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPj4gPj4gPg0KPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNw ZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5 b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+ PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlm aWVyIHBvaW50IHRvIGENCj4+ID4+bG9va3VwDQo+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMg dG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdA0KPj5zdXJlDQo+PiA+ Pmhvdw0KPj4gPj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4NCj4+ ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0 dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4g Pj5BYnNvbHV0ZWx5Lg0KPj4gPj4gPj4NCj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4g U2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVS QUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4g VGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVt cyB0byBtZQ0KPj4gPj50aGF0IGlmDQo+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtl IGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0K Pj4gPj4gPj4+Zm9yDQo+PiA+PiA+Pj4gYSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNG IHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UNCj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+ PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcg bG9naWMgdG8NCj4+ID4+cmVhY2gNCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1T RiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ ID4+ID4+Pg0KPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gPj4gd3JvdGU6 DQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNh biBiZSBpbnN0YW50aWF0ZWQgb25seSBpbg0KPj5yZWxldmFudA0KPj4gPj4gPj4+U0ZGcw0KPj4g Pj4gPj4+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ ID4+PiA+PihqZ3VpY2hhcikNCj4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIw MTQgOToyNyBBTQ0KPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g Pj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhh biB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29kDQo+PnRoZQ0KPj4gPj4gPj4+ID4+cHJvcG9zYWwN Cj4+ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRn ZSBvZiBldmVyeSBzaW5nbGUNCj4+U0YNCj4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4+ID4+dGhl DQo+PiA+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0 aGVyZSBpcyBubyB3YXkgdG8NCj4+a25vdw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2Ug YXQgYW55IGdpdmVuDQo+PnBvaW50DQo+PiA+PmluDQo+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4+ ID4+DQo+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4i IDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+ IHdyb3RlOg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQg dGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4+d2l0aA0KPj4gPj50aGUN Cj4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5k IGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4+ID4+ID4+PnVuZGVyc3RhbmQN Cj4+ID4+ID4+PiA+PiA+aXQuKQ0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+VGhlIHBy b3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+ PiA+Pm5leHQNCj4+ID4+ID4+PiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQg KG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzDQo+PnRvKSwNCj4+ID4+aW4NCj4+ID4+ID4+PmV2ZXJ5 DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+ PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3Jr IHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PmV2 ZXJ5DQo+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5z aXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQNCj4+ID4+ID4+PmJhbGFuY2VyLg0KPj4gPj4gPj4+ID4+ ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAv IG9yDQo+PiA+PnN0YXRlZnVsLg0KPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRl Y3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsDQo+PiA+PmZsb3cNCj4+ID4+ ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0 byBiZSBhbg0KPj4gPj5hY2NlcHRhYmxlDQo+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiA+ PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5Zb3VycywNCj4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4g Pj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4g SGFscGVybiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcg aXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMNCj4+d29yaw0KPj4gPj4gPj4+ID4+c2Vu c2libHkNCj4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50 LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25z LCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPj53aWxsDQo+ PiA+PmJlDQo+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhw ZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0KPj50byBiZQ0KPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+ PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRz LCBhbmQgZW5hYmxlDQo+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+IGZy b20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4+ ID4+ZHJpdmUuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93 IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4+ID4+ZHJpdmVu DQo+PiA+PiA+Pj5ieQ0KPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8g ZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzDQo+PiA+PmhhcmRlcg0KPj4gPj4gPj4+dG8N Cj4+ID4+ID4+PiA+PnNlZQ0KPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1 dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+PiA+PiA+Pj4gPj4gZHluYW1p Y2l0eQ0KPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4+ ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBl cnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzDQo+PiA+Pm91dHNpZGUNCj4+ID4+ID4+Pm9mDQo+PiA+ PiA+Pj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4g aXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4+ID4+dGFza2VkIHRvDQo+PiA+PiA+Pj4gPj5h Z3JlZQ0KPj4gPj4gPj4+ID4+ID4+b24uDQo+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xh aW0gdGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhDQo+PmNlcnRhaW4NCj4+ID4+ ID4+PndheS4NCj4+ID4+ID4+PiA+Pml0DQo+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVy c3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ ID4+ID4+PiA+PiA+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiA+PiA+Pj4gPj4g Pj4NCj4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6 DQo+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJv dXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ID4+IHRoYXQNCj4+ID4+ID4+PiA+Pm5lZWRzDQo+PiA+ PiA+Pj4gPj4gPj4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQg YW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ID4+YWNyb3NzDQo+PiA+PiA+Pj5k YXRhDQo+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBz Y29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+IGNvbXBsZXgNCj4+ID4+ID4+ PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNl ZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRl Y3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSSdt IGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PmR5bmFt aWMNCj4+ID4+ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRh IGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPj53aGljaA0KPj4gPj5hcmUN Cj4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUg YmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+ DQo+PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9y ZSBjb21wbGljYXRlZCwgdGhhdA0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+Pj5nb29kDQo+PiA+PiA+ Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+Pj4gPj4g Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4g U2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ID4+ID4+PiBU bzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb208bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+SWFuDQo+PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+ PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4g Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFu IGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxkDQo+PnByZWZlcg0KPj4g Pj53ZQ0KPj4gPj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwg cmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gPj5pbXBsZW1lbnRh dGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZm ZWN0IG9uIHRoZSBjb250cm9sDQo+PiA+PnJlcXVpcmVtZW50cw0KPj4gPj4gPj4+YW5kDQo+PiA+ PiA+Pj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGlu Zm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiBu ZWVkcw0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmli dXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gYWNyb3NzDQo+PiA+PiA+ Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZl IHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj5jb21wbGV4DQo+PiA+PiA+ Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNl ZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVj dHVyZSB0byByZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBZb3Vy cywNCj4+ID4+ID4+PiA+PiA+Pj4gSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4g Pj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4g Pj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBl bmQNCj4+c2VsZWN0aW9uDQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBp bnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+ID4+PiA+ PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5 IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj5T RkZzKT8NCj4+ID4+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50 IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+PkFuZA0KPj4gPj4gPj4+c3VyZWx5LA0KPj4gPj4gPj4+ ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVk IHRvDQo+PiA+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPj4gPj4gPj4+ID4+ID4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmli dXRlZCBhcHByb2FjaCBldmVuDQo+PiB0aG91Z2gNCj4+ID4+IGENCj4+ID4+ID4+PiA+PiA+Pj4+ IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+ PmxvY2FsDQo+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkg aXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0KPj4gPj5U aGlzDQo+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10 by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+PiA+Pk15DQo+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25h bGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0KPj5ieQ0K Pj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIg dGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGENCj4+Z2xvYmFsDQo+PiA+PiA+Pj5w YXRoDQo+PiA+PiA+Pj4gPj5pZA0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVy IGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcgdG8NCj4+ID4+YWx0ZXINCj4+ID4+ ID4+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2gg YW5kIGV2ZXJ5IGFmZmVjdGVkDQo+PmVuZC10by1lbmQNCj4+ID4+ID4+PnBhdGguDQo+PiA+PiA+ Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBG cm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0K Pj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPj4yMDE0 DQo+PiA+PiA2OjE1DQo+PiA+PiA+Pj4gUE0NCj4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlh bmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBJLlNtaXRoQEY1LmNvbTxtYWls dG86SS5TbWl0aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ IFN1YmplY3Q6DQo+PiA+PiBSZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBT RjEgbmVlZGluZw0KPj50bw0KPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+ PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUN Cj4+ZXhpdA0KPj4gPj5mcm9tDQo+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4gPj4g Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBk aWZmZXJlbnQgZnVuY3Rpb25zDQo+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ID4+Pj4gc2Vw YXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+ ID4+IGNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBm b3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gT24g Ny8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0 aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueQ0KPj4gPj5zb3J0DQo+PiA+PiA+Pj5vZg0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNh dGUgdGhhdCB0aGUgZW50aXJlDQo+PiA+PnBhdGgNCj4+ID4+ID4+PihhbGwNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxp ZXZlDQo+PnRoaXMNCj4+ID4+ID4+Pm1lYW5zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0 IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyDQo+PmNob29zZXMgYQ0KPj4g Pj5TRg0KPj4gPj4gPj4+ID4+Q2hhaW4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9y IGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsDQo+PiA+PnRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHlu YW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNGSShuKQ0KPj4gPj4gPj4+IGlzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRy YWZ0LA0KPj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29u c2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4+ID4+ID4+PiBvcHBvc2VkDQo+ PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3 YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZg0KPj4gPj50aGUNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5l dHdvcmsgaXQgaXMNCj4+ID4+bmVjZXNzYXJ5DQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVz ZWQsDQo+PiA+PmFuZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2Ug dG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MNCj4+ID4+bmV0d29yaw0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0 cyBpbiB0aGUNCj4+ID4+ID4+PmNyZWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2Vy dmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4gPj5mb3J3YXJkaW5n DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3 b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9m IHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4+ ID4+bm9uLWluaXRpYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdl bGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNs YXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEg c2VydmljZQ0KPj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNh dGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4+ID4+U0ZQLCBhbg0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9y IGJvdGguIFRoaXMgaXMNCj4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4g Pj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+ Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4g Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqRnJv bTogKkkuU21pdGhARjUuY29tPG1haWx0bzoqSS5TbWl0aEBGNS5jb20+PEkuU21pdGhARjUuY29t PG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBI YWxwZXJuDQo+PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPj4gPj4gTS4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBlcm48am1oQGpv ZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5nQHNjZS5jYXJs ZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0BzY2UuDQo8bWFpbHRv Omh1YW5nQHNjZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Y2E+LHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PiA+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3Jl ZWluZy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3Nz aWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj50aGF0IGlzDQo+PiA+ PiA+Pj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3 b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMNCj4+ID4+ID4+PnByZWNvbmNlaXZlZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVy ZGVuZWQgd2l0aA0KPj4gdGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29t ZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mDQo+PiA+PmFzcGlyYXRpb24NCj4+ID4+IHRv DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxp ZmVzcGFuIG9mIHRoZQ0KPj4gPj5hcmNoaXRlY3R1cmUNCj4+ID4+ID4+Pi0NCj4+ID4+ID4+PiA+ PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcg dGhhdCBhbg0KPj4gPj4gPj4+YXJiaXRyYXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlz ICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPj4gPj4gPj4+ ID4+aW50ZW50aW9uYWwNCj4+ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVu Y2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZw0KPj4gPj5pbXBhY3RzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGlj aXR5LA0KPj4gPj5hZGRyZXNzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRz IG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+ IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+PlNlbnQ6DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNt aXRoOyBKb2VsIE0uDQo+PiA+PiBIYWxwZXJuOw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNj ZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0KPj4gPj5TZXJ2aWNlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91 IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXMNCj4+ID4+cmVnYXJkLg0KPj4gPj4gPj4+ SQ0KPj4gPj4gPj4+ID4+YW0NCj4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUg dGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ID4+cHJvaGliaXQNCj4+ID4+ID4+ PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmpl Y3RpbmcgdG8NCj4+ID4+SHVhbmcncw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkg bm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPj4gPj4gcmVxdWlyZWQN Cj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJ IGFtIG5vdCB0cnlpbmcgdG8gcHJvaGliaXQNCj4+c3VjaA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRo aW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uDQo+ PiA+PiBtYW55DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29w ZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+PnRoaW5rDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+ PnRoZXkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kg Y2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG8NCj4+ID4+a25vdw0KPj4gPj4gPj4+d2hh dA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNl cyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+PiA+PiA+Pj5taWxsaW9ucw0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nl c3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXINCj4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVu dHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluDQo+PnRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0 b21vcnJvdyB5b3UNCj4+IGFyZQ0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ID4+IGdvaW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdp dGggZXF1YWxseQ0KPj5zbWFsbA0KPj4gPj4gPj4+IG51bWJlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBu ZWVkIG1vcmUNCj4+IHRoYW4NCj4+ID4+ID4+PiA2NEsiDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGZv cg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYg b2YgSm9lbCBNLiBIYWxwZXJuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5j b208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50 OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4gPj4gPj4+aHVhbmdAc2Nl LmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywNCj4+YW5kDQo+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kg dGhlDQo+PiA+PiA+Pj5hcmNodGlldHVyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFy bHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPj50aGVpcg0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUg c3VjaCBhYnN1cmQNCj4+IHVzZQ0KPj4gPj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2Vydmlj ZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNo aXRlY3R1cmUNCj4+ZG9lcw0KPj4gPj4gPj4+cGVybWl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1 Y2ggYWJ1c2UuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFz ZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiBwZXJtaXRz DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRl aXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4+ID4+dGhlDQo+PiA+PiA+Pj53b3JrLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZToNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBp dCB3aWxsDQo+Pm1lYW4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRo YXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcNCj4+dGFibGUNCj4+ID4+b2YgYQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBk ZXBsb3ltZW50cywgZnJvbQ0KPj4xDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRo IHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGUNCj4+dGhhdA0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMg aWYgdGhleQ0KPj4gPj5jaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4g YXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQNCj4+ID4+ IHByb3Zpc2lvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2Vs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0 LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFBhdWwsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcA0KPj4g Pj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNl cyBhdCBlYWNoIGhvcD8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gTWFyaWENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmDQo+ PiBPZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50Oiog VGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ID4+MzowMw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBQTSAqVG86KiBMdWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1p a2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gKlN1YmplY3Q6KiBSZTog W3NmY10gU2VydmljZQ0KPj4gQ2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywg YW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEx1Y3ksDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ID4+ID4+PiA+PiA+ Pj4+PiBtYWtlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBw YXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG8NCj4+ID4+IGRlcml2ZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0 Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBf bm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8NCj4+c2ltcGx5DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0 aGF0IHBhY2tldHMNCj4+bXVzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkg aGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0aGUgZXhhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uDQo+PnRo aXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVt ZW50ZWQuIFRoZSBwYXRoDQo+PiA+PiBpZGVudGlmaWVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4NCj4+ ID4+IHJlc3VsdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhIG9uZSBvciBtb3JlIChlcXVh bCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9w KHMpLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAx MCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8 bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPg0KPj4gPj4g PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT48bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29t JTNlPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0 ZSBvbmx5IHVzZSBvZg0KPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+PiA+PmFjdGlvbnMuDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiBCZWhhbGYNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gPj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+ID4+ PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOipt aWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9y ZzxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNl cnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFJlLSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g VGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVu dGlmaWVyIHRvDQo+PmRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFj dGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJl cXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+ IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMg bm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJk aW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRo ZSBvbmUNCj4+IHJlcXVpcmVkDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1 Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2Vk IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBhY3Rpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3Jp ZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5j QGFvbC5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20+ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPj4gPj4ganVpbGxldA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhA am9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+O3NmY0BpZXRmLm9yZzxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtz ZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3Jn PiAqT2JqZXQgOipSZTogW3NmY10gU2VydmljZQ0KPj4gPj5DaGFpbnMsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRo ZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4+U0YNCj4+ID4+IENoYWluDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuZCBTRg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MN Cj4+ID4+Y2xlYXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlv bmUNCj4+YWdyZWVzDQo+PiA+Pm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1z Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwg dGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+d2hldGhlcg0KPj4gPj5p dCBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8g dWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQNCj4+ID4+dGhlIElEDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYg dGhpcyBkcmFmdA0KPj4gPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0 byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXINCj4+ZHJhZnRzDQo+PiA+PnRv DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndh cmRpbmcgYmFzZWQgb24gY2hhaW4NCj4+IG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGgg YW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBs YXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChv ciBtYWtlDQo+PiA+PiBvbmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRo ZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZQ0KPj4gdmVuZG9ycw0KPj4gPj4gb25seQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3Vw cG9ydGluZyBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0K Pj4NCj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4+Pj4+Pj4+ LS0tDQo+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+ PiA+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiAqRnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20+ PGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhA am9lbGhhbHBlcm4uY29tPjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFs cGVybi5jb20lM2U+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxt YWlsdG86KnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3Jn PjxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4+ICpTZW50OipUdWVz ZGF5LA0KPj4gPj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0 Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj5Mb2FkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJs eQ0KPj5hbnN3ZXINCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29t bWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUNCj4+ID4+ID4+PiBwcm9wb3NlZA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWlu ZyB3ZSBjYW4gZ2V0DQo+PiB3b3JraW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFn cmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+IGltcHJvdmUNCj4+ID4+ IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8g aGF2ZSBub3QgcGFydGljaXBhdGVkIGluDQo+PiA+PnRoZQ0KPj4gPj4gV0cNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHdvcmtpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50 ZW5kcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0 IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkNCj4+ID4+cGVyc29u YWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJl Z2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0DQo+PiA+PndoYXQNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFy Y2hpdGVjdHVyZS4gV2UNCj4+YXJlDQo+PiA+PiBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3 b3VsZCBlbmNvbXBhc3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBj b250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KPj52aXJ0dWFsDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+PiA+ PiBhc3BlY3RzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkDQo+ PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwg YnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoDQo+PiA+PmFib3ZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29y ayB3ZSBhcmUNCj4+IGRvaW5nLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBh dGgsDQo+PmFzIEkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoZW0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBk aXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQNCj4+ID4+bGVhc3QNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBj YW4gYW5kDQo+PndpbGwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2 aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUNCj4+ID4+bW9yZS4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gcGVybWl0IGFs bCBvZg0KPj4gPj50aGVzZSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5k YXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGJlIHVzZWQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNl cnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZA0KPj4gPj51c2VyLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlcg0KPj5wYWNr ZXRzLA0KPj4gPj5hbmQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3IN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBtYXJrcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBv ciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlDQo+PiA+Pmluc3RhbmNl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhp cyBpcyBhbiBpbXBvcnRhbnQNCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBm dW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4NCj4+ID4+ SXQncw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVt ZW50cyBvbiBob3cgc2VydmljZQ0KPj4gPj4gY2hhaW5pbmcgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiA+PmFy Y2h0aWVjdHVyZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gRnJvbSBhbiBhcmNoaXRlY3R1cmFs IHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5k ZXJseWluZyBwYWNrZXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUN Cj4+Y2FuDQo+PiA+PmhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4gPj4gPj4+ ID4+ID4+Pj4+IGFwcGVhcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlDQo+PnBvaW50DQo+PiA+Pm9mDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0 dWFsbHkgZGVsaXZlcmVkDQo+PiA+PmJ5IGENCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9u IG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMs IHBvc3NpYmx5IGluY2x1ZGluZw0KPj5vbmUgb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2 ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3Rs eSwgdGhpcyBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0KPj4gPj5tZWNoYW5pc21zLg0KPj4gPj4gSXQNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3Vz IGNvbnRyb2wNCj4+ID4+bWVjaGFuaXNtcywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBh cyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwNCj4+YW5kDQo+PiA+ PnZtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1 cmFsIGltcGFjdCBvZg0KPj5wZXJtaXR0aW5nDQo+PiA+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4g Pj50ZXJtaW5vbG9neQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3 ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkN Cj4+c2VsZWN0aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhl IHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+ID4+dHJhZmZpYw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1 aXJlDQo+PiB0aGF0DQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2Vydmlj ZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4NCj4+dGhlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0K Pj5jb21iaW5lZC4gSQ0KPj4gPj4gdGVuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xs ZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UNCj4+ID4+Y2hhaW5pbmcN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBO b3QgYmVjYXVzZSBjbHVzdGVyDQo+PmlzDQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Z29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLg0KPj4gVGh1 cywNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9h ZCBiYWxhbmNpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQNCj4+ ID4+c2luZ3VsYXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2Ug ZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMNCj4+aW4NCj4+ID4+dGhlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRh bGsgYWJvdXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2Vydmlj ZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGENCj4+ID4+IHNlcXVlbmNlDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQg b2YNCj4+ID4+cGFja2V0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVu dCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZg0KPj50cmFmZmljDQo+PiA+PmlzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rp b24sIGFuZA0KPj5maXJld2FsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZl cmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlDQo+PmNhY2hlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gd2l0aG91dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3Ro ZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhl DQo+PnBhY2tldHMuDQo+PiBBDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBp cywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+PiA+PmxvY2F0aW9ucw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUg c2luZ3VsYXIgb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVu Y3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5DQo+PiA+Pm1heSBiZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2Vk IGFzDQo+PiBwb3J0cw0KPj4gPj4gb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBU aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZQ0KPj4gPj5sb2NhdGlvbnMNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5n IGluZnJhc3RydWN0dXJlDQo+PiBhbmQNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMNCj4+Z3Jv dXAsDQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJh Y3Rpb24sIHRoZQ0KPj4gPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3 aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvDQo+PiB0YWxrDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2ls bCB0YWtlIGluIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUNCj4+IHBhdGgNCj4+ID4+IG1heQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRl Y3R1cmUgZGVhbHMNCj4+ID4+d2l0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3Vl IGluIHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikNCj4+b24NCj4+ID4+bG9h ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBk ZWNpc2lvbnMgYW5kDQo+PmJlaGF2aW9ycw0KPj4gPj4gd2hpY2gNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChp bg0KPj4gPj5tdWNoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJy aWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu dmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gcHJvdmlzaW9u DQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gdGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBi ZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuDQo+PiA+PiBuZWNlc3NhcnkuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQg b24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSBy ZS1jbGFzc2lmaWNhdGlvbg0KPj5wb2ludC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2Ug YXJlIGFmdGVyLg0KPj5JZiBpdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYg dGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nDQo+PiA+PiBncm91cCwNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdv cmRzIGFyZSBuZWVkZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlz LiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZQ0KPj4gPj4gaW50ZW50LA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBt YXRjaCB0aGUgd29ya2luZw0KPj4gPj5ncm91cA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZ3Jl ZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUNCj4+ID4+d2hh dCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWls aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxp bmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNm Yw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+ PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBzZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIHNmYw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+ PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNm Yw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4gPj4gPj4+ID4+ID4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4g Pj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+ PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPnNmYyBtYWls aW5nIGxpc3QNCj4+ID4+ID4+PiA+PiA+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+PiA+PiA+Pj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ ID4+PiA+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+DQo+PiA+ PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+ID4+ID4NCj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID5zZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglm b250LWZhbWlseTrlrovkvZM7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+ 5qC85byPIjsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUt bmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQwNjIy NDc4MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI0 ODg2NDM1OCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+BrDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjEuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWUgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9m IHRoZSBTRlAgaW4gdGhlIGFyY2ggZHJhZnQgaXMgYSBiaXQgY29uZnVzaW5nLCBqdXN0IGFzIHdo YXQgeW91IGhhZCBwb2ludGVkIG91dC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbXkgdW5kZXJzdGFu ZGluZywgdGhlIFNGUCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUgbmV0d29y ayBzaG91bGQgYmUg4oCcYW4gb3JkZXJlZCBsaXN0IG9mIHNlcnZpY2Ugbm9kZXMgYW5kIFNGIElE c+KAnShzZWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNoLTAx Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNm Yy1hcmNoLTAxPC9hPikuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQIGluIHRo ZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRoZXIgdGhyb3VnaCBhIHBh dGggaWQgb3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVyZSB0aGUgc2VydmljZSBu b2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNGRiBhbmQgdGhlIE5GIGNv bXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUgU0YgYW5kIFNGIHByb3h5 IGNvbXBvbmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBiZSBhdHRhY2hl ZCBvciBlbWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBhbmQgdGhvc2UgU0YgaW5z dGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90LiAmbmJzcDtJbiB0aGUg Y2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNG IHR5cGUgKGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdpdmVuIHNlcnZpY2Ugbm9kZSwg dGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBkaXN0cmlidXRlIHRoZSB0cmFmZmljIHdoaWNoIG5lZWRz IFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzIG9mIFNGIFggdHlwZSBsb2NhbGx5LiBNZWFu d2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzIHdpdGhpbiBhIGdpdmVu IFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3IgYXR0YWNoZWQgd2l0aCB0 aGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5LCB0aGUgU0Yg bG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZSB2ZXJ5IGZsZXhpYmxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+bWlrZWJpYW5jQGFvbC5jb208 YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTTxicj4NCjxi PlRvOjwvYj4gamd1aWNoYXJAY2lzY28uY29tOyBtbjE5MjFAYXR0LmNvbTsgbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgUm9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbTsgc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+V291bGRuJ3QgdGhhdCBiZSBjYWxsZWQg dGhlICZxdW90O3NlcnZpY2UgY2hhaW4gaWRlbnRpZmllciZxdW90OyB0aGVuPyAmbmJzcDtJZiB0 aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZp Y2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywNCiB0aGVuIEkgd291 bGQgaW5mZXIgdGhhdCBhICZxdW90O3NlcnZpY2UgcGF0aCBpZGVudGlmaWVyJnF1b3Q7IHdvdWxk IGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBhIHNlcnZpY2UgKmNo YWluKi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBz IGNyZWVwaW5nIGluLiAmbmJzcDtUaGUgdGVybXMgJnF1b3Q7Y2hhaW4mcXVvdDsgYW5kICZxdW90 O3BhdGgmcXVvdDsgc2VlbSBpbmNvbnNpc3RlbnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjYuNzVwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5 OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTog PC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86amd1aWNoYXJA Y2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb20mbHQ7amd1 aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFuY0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29tJTNj bW4xOTIxQGF0dC5jb20lM2UsbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20lM2Usam1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFs cGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5taWtl YmlhbmNAYW9sLmNvbSZsdDttaWtlYmlhbmNAYW9sLmNvbSZndDssbW4xOTIxQGF0dC5jb20mbHQ7 bW4xOTIxQGF0dC5jb20mZ3Q7LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mbHQ7bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDssam1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9l bGhhbHBlcm4uY29tJmd0OyxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20mZ3Q7LHNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIg ZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBhdGggaXMgY29ycmVjdCBhcyBpdHMgdGhlIGZvcndhcmRp bmcgcGF0aCB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgaG93ZXZlciBwb2ludHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4g ZGF0YSBzdHJ1Y3R1cmUNCiBhbmQgdGhhdCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmljIGlu c3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMgYXJl IGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGlu IHBsYXkuIFdoZW4gaW5zdGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3 b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZQ0KIHRvIHNw ZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBiZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhv cCB3b3VsZCBlZmZlY3RpdmVseSBuYWlsIHVwIHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2Vy dmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAv IG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0aGUgZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5t aWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVseSAx MSwgMjAxNCBhdCAxMjoxOCBQTTxicj4NCjxiPlRvOiA8L2I+SmltIEd1aWNoYXJkICZsdDs8YSBo cmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5j b208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhy ZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywgJnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYu NzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRoZSBjb25mdXNpb246PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgSSBkb27igJl0IHdhbnQg dG8gc3BlY2lmeTxicj4NCiZndDsgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMz IChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJPGJyPg0KJmd0OyBhc3NpZ24gYSBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMx LSZndDtTMi0mZ3Q7UzM8YnI+DQomZ3Q7IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3 b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJyPg0KQnkgZGVmaW5pdGlv biwgSSB1bmRlcnN0b29kIGEgJnF1b3Q7c2VydmljZSBwYXRoJnF1b3Q7IHRvIGJlIGFuIG9yZGVy ZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIEluIHRoZSBzdGF0ZW1lbnQgYWJvdmUs IHlvdSB1c2UgYSAmcXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90OyB0byByZWZlciB0 byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAmcXVvdDtbZG9lcyBub3RdIHNw ZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2 Ljc1cHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9 IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206IDwvc3Bhbj4NCjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+ amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+TkFQSUVSQUxB LCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5j b208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+ bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxSb24NCiBQYXJrZXImbHQ7PGEgaHJlZj0i bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSnVseSAxMSwgMjAxNDxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnM8YnI+DQo8YnI+DQpNYXJpYSw8YnI+DQo8YnI+DQpJIHRoaW5rIG9mIGl0IHRoaXMg d2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgc2ltcGx5IGEgcG9pbnRlciB0bzxi cj4NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5n cy4gV2hlbiB5b3UgZGVmaW5lIGE8YnI+DQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLSZndDtTMi0m Z3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeTxicj4NCnRo ZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRvIGZsb3cgdGhyb3Vn aCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZlciwgeW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhp cyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSTxicj4NCndpbGwgYXJndWUgdGhh dCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlv dTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBw b2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+DQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1hdGlvbiBp bnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhPGJyPg0Kc2VydmljZSBw YXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250 YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3 aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVhcm48YnI+DQp0aG9zZSBuZXh0LWhvcHMgaXMgdXAg dG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhIGNlbnRyYWxpemVkPGJyPg0K Y29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1p Y2FsbHkgdGhyb3VnaDxicj4NCnNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNv LCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvPGJyPg0Kc2F5IHRoYXQgdGhlIHNlcnZp Y2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhIHByaW9yaTxi cj4NCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBz YXkgcmVjb21tZW5kZWQpIHRvIGRvPGJyPg0Kc28uPGJyPg0KPGJyPg0KTGV04oCZcyB0YWtlIGFu IGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjo8YnI+DQo8YnI+DQpJIGRlZmlu ZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMxLSZndDtTMi0mZ3Q7UzMu IEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxs eSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTxicj4NCnNwZWNpZmljIGlu c3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4g STxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJh c2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxicj4NCmFuZCB0aGVuIHB1c2ggdGhp cyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlPGJy Pg0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93IGF0IGEgZ2l2ZW4gU0ZGLCB3 aGVuIHRyYWZmaWMgYXJyaXZlczxicj4NCndpdGggc2VydmljZSBwYXRoIGlkZW50aWZpZXIgMTAw LCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhPGJyPg0Kc3RydWN0dXJlIGFu ZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzMgYW5kIHRoZSBpbmRleCBp biB0aGUgU0ZDPGJyPg0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhhY3RseSB3aGVyZSBp dCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlPGJyPg0KYXJlIGF0IFMyIGluIHRoZSBj aGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9wIHRvPGJy Pg0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNo YWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0LCAxMToyNiBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBN QVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBh dHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0ppbSw8YnI+DQomZ3Q7PGJyPg0K Jmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAmcXVvdDtz ZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8YnI+DQomZ3Q7JnF1b3Q7c2VydmljZSBwYXRoIGlkZW50 aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNG IGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoPGJyPg0KJmd0O2lzIG15IGN1cnJl bnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hp Y2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVj aXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDtNYXJpYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyA8YnI+DQo8 YnI+DQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbPGEgaHJlZj0ibWFpbHRvOmpndWlj aGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbTwvYT5dPGJyPg0KJmd0OyZn dDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNPGJyPg0KJmd0OyZndDsgVG86 IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyBKb2VsIE0uPGJyPg0K Jmd0OyZndDsgSGFscGVybjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5 IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXI8YnI+DQomZ3Q7Jmd0OyBwcmV2ZW50cyBmdWxsIGRp c3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlPGJy Pg0KJmd0OyZndDsgY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT88YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiA3LzExLzE0LCAxMDo1OCBBTSwgJnF1b3Q7TkFQSUVS QUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1u MTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg Jmd0O0RpdHRvLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206IDxhIGhy ZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNCAxMDozMSBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhp cyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlPGJyPg0KJmd0OyZndDtkcmFmdC48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1hbmRhdGluZyBhIHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZGlzdHJpYnV0ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBt b2RlbCBpcyBub3QgYWxsb3dlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRo ZSBzZXJ2aWNlIGNoYWluIGl0c2VsZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2hvdWxkIGJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlkZWQgaW5zdGVhZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDst LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RGUg OiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQ8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7KGpndWljaGFyKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtF bnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0O8OAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQ YXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1 cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtwcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQt aG9wcyB0byAqYWxsKiBTRkbigJlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3dpdGhpbiB0 aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBh PGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb29rdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJ IGFtIG5vdDxicj4NCiZndDsmZ3Q7c3VyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aG93PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0O3RoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD88YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcv MTEvMTQsIDk6NTggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0 OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1dGVseS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyhqZ3VpY2hhcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxw ZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwg aXQgc2VlbXMgdG8gbWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQgaWY8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgeW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNp b24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdDxicj4NCiZndDsmZ3Q7d2lsbDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7dXNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Zm9yPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0 aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91PGJyPg0KJmd0OyZndDtiZXR0ZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJk aW5nIGxvZ2ljIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZWFjaDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVw IHRyb3VibGUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTEvMTQsIDk6NDggQU0sICZxdW90O05BUElF UkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5t bjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDtBYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3Rh bnRpYXRlZCBvbmx5IGluPGJyPg0KJmd0OyZndDtyZWxldmFudDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O1NGRnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0O3doZW4gdGhleSAmcXVvdDthcnJpdmUmcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBKaW08YnI+DQomZ3Q7Jmd0O0d1aWNoYXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7KGpndWljaGFyKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJu OyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3Jz ZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2Q8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3Byb3Bvc2FsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCBy ZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZTxicj4NCiZndDsmZ3Q7U0Y8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aXRoaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBh cyB0aGVyZSBpcyBubyB3YXkgdG88YnI+DQomZ3Q7Jmd0O2tub3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtwcmlvcmk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgd2hpY2ggU0ZDwrlz IGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbjxicj4NCiZndDsm Z3Q7cG9pbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7dGltZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gNy8x MC8xNCwgMTE6NTMgUE0sICZxdW90O0pvZWwgTS4gSGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFq b3IgcHJvYmxlbTxicj4NCiZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7eW91cjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7cHJvcG9zYWwgYXMgSSB1bmRl cnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt1bmRlcnN0YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpdC4pPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0O1RoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQg YmFsYW5jZXIgZm9yIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmV4dDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBmdW5jdGlvbiB0aGF0 IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzPGJyPg0KJmd0OyZndDt0byksPGJy Pg0KJmd0OyZndDsgJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtz ZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtTaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGgg YWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZXZlcnk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NGRiB3b3VsZCBoYXZlIHRvIGJl IGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtiYWxhbmNlci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0O0kgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBm bG93IHNlbnNpdGl2ZSwgYW5kIC8gb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3N0YXRlZnVsLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7QnV0IGhhdmlu ZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Zmxvdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0 byBtZSB0byBiZSBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNjZXB0YWJsZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW1wb3NpdGlvbi48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7WW91cnMsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtKb2VsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhh bHBlcm4gd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRv IG1ha2UgdGhpczxicj4NCiZndDsmZ3Q7d29yazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O3NlbnNpYmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQu IEkgZXhwZWN0IHRoYXQgdGhlPGJyPg0KJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGZ1bmN0aW9ucywgYW5kIG92ZXIg dGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcyw8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2JlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0 aGUgc2VydmljZSBjaGFpbnM8YnI+DQomZ3Q7Jmd0O3RvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmVuIGJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZl cmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O3NlbGYtc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8g YmUgaGVhdmlseSBwb2xpY3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGNhbiBzZWUgaG93IHRv IG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2RyaXZlbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2J5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluaXRpYWwg Y2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtoYXJkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBob3cgdG8gbWFr ZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cgbW9yZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkeW5hbWljaXR5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIHRoZSBuZXR3 b3JrIGJlaGF2aW9yLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNj cmliZWQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O291dHNpZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3 ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rhc2tlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2FncmVlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7b24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9u IG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYTxicj4NCiZndDsmZ3Q7Y2VydGFpbjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dheS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDtpdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBw cmVmZXJlbmNlcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBt ZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDtuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1h aW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fjcm9zczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhp biBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoPGJyPg0KJmd0OyZndDth bmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tcGxleDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGVub3Vn aCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RpZmZpY3VsdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVy ZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxp Y2F0ZWQgdGhhbjxicj4NCiZndDsmZ3Q7ZHluYW1pYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyByb3V0aW5nLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlv biwgb3IgRE5TLCBhbGwgb2Y8YnI+DQomZ3Q7Jmd0O3doaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZn dDthcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtiaWdnZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRl ZD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQs IHRoYXQ8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Z29vZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGlj YXRlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBK b2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUg UE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyA8YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPg0KbWlrZWJpYW5jQGFvbC5jb208L2E+Ozxicj4NCiZndDsmZ3Q7 SWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U21pdGg7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4NCiZndDsmZ3Q7QmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg VGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZDxicj4N CiZndDsmZ3Q7cHJlZmVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3ZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthY3R1YWxseTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZGVjaWRl LCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVm ZmVjdCBvbiB0aGUgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVxdWlyZW1lbnRzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25hbGl0eSBvZiBTRkZzLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZv ciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVu PGJyPg0KJmd0OyZndDsgYWNyb3NzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVu b3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Y29tcGxleDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2Vl bXMgbGlrZSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBh cmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBmYWly IHF1ZXN0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg VGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBlbmQ8YnI+DQomZ3Q7 Jmd0O3NlbGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAodG9wLWxldmVsKSBp bnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtjbGFzc2lmaWVyKTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGhvcC1i eS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7U0ZGcyk/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVj bGFzc2lmaWNhdGlvbi48YnI+DQomZ3Q7Jmd0O0FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0O3N1cmVseSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5k IG5vdCByZWxlZ2F0ZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtpbXBsZW1lbnRhdGlvbiZxdW90Oy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVu PGJyPg0KJmd0OyZndDsgdGhvdWdoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdyZWF0 ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzPGJyPg0KJmd0 OyZndDtsb2NhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3Nl bGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVj aXNpb24gcG9pbnRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7VGhpczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoIGRv ZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0IGFsbC48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O015PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlz IHByaW1hcmlseSBkcml2ZW48YnI+DQomZ3Q7Jmd0O2J5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW5jcmVhc2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVzaWxpZW5jeSBvdmVyIHRoZSBn bG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0aCBhPGJyPg0KJmd0OyZndDtnbG9iYWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBv ZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWx0ZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBnbG9iYWwgcGF0aCBJ RCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQ8YnI+DQomZ3Q7Jmd0O2VuZC10by1l bmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwYXRoLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUm9u PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206 IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3Q8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBb PGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpv ZWxoYWxwZXJuLmNvbTwvYT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLDxicj4NCiZndDsmZ3Q7 MjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IDY6MTU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgUE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Ij5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+ DQpJLlNtaXRoQEY1LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IFJlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNG MSBuZWVkaW5nPGJyPg0KJmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2luZmx1ZW5jZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBk byByZWNsYXNzaWZpY2F0aW9uIGF0IHRoZTxicj4NCiZndDsmZ3Q7ZXhpdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ZnJvbTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNGMS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8g a2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9naWNh bGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUg aG93IHRoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjaG9vc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbXBvc2UgdGhlbSBmb3IgJnF1b3Q7c2VydmljZSZx dW90OyBkZWxpdmVyeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0 LCA2OjEwIFBNLCA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFy Y2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NvcnQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaW1pdC4gSG93ZXZl ciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7cGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhhbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVsaWV2 ZTxicj4NCiZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O21l YW5zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3Np Zmllcjxicj4NCiZndDsmZ3Q7Y2hvb3NlcyBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O0NoYWluPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJv aGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU0ZJ KG4pPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldGVy bWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJl ZCAmcXVvdDticmFuY2hpbmcmcXVvdDsgdG8gYSBuZXcgU0ZQIGFzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IG9wcG9zZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0 byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0 LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2hlbiBhbiBTRkMgaXMg aW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O25lY2Vzc2FyeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVz ZWQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDthbmQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNyZWF0ZSB0aGUg c2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Ynczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bmV0d29yazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBv ZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Y3JlYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlAp IGFuZCBpcyB1c2VkIGZvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Zm9yd2FyZGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMg dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNz aWZpY2F0aW9uIChvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bm9uLWluaXRpYWw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZv cm1lZCBieSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVu dCB3aXRoIGEgc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZnVuY3Rpb24uPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5l dzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U0ZQLCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdXBkYXRlIG9mIHRo ZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiBUaGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtyZWZlcnJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhcyAmcXVvdDticmFuY2hpbmcmcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqRnJvbTogPGEgaHJl Zj0ibWFpbHRvOipJLlNtaXRoQEY1LmNvbSI+KkkuU21pdGhARjUuY29tPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPkkuU21pdGhARjUuY29tPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg KlRvOiAqSm9lbCBIYWxwZXJuPGJyPg0KJmd0OyZndDsgRGlyZWN0Jmx0OzxhIGhyZWY9Im1haWx0 bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208 L2E+Jmd0OyxKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7SGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpodWFuZ0Bz Y2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOmh1YW5nQHNjZS4lMGIiPmh1YW5nQHNjZS48YnI+DQo8L2E+Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNhcmxldG9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2NhJmd0Oyw8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTdWJqZWN0OiAq UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O0JhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFt IGRpc2FncmVlaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVk aXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQ8YnI+DQomZ3Q7Jmd0O3RoYXQgaXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2IG1pbGxpb24gZmxvd3Mg aXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7cHJlY29uY2VpdmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0 aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aDxicj4NCiZndDsmZ3Q7IHRoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcHJlY29uY2VwdGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgaGFzIHRvIGJlIHNv bWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXNw aXJhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMg YXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2FyY2hpdGVjdHVyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Oy08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgeW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQg YW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthcmJpdHJhcnk8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg bnVtYmVyIGlzICZxdW90O3RvbyBmYXImcXVvdDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYg aXQgaXNuJ3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbnRl bnRpb25hbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0 IGhhdmUgbGFzdGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW1wYWN0czxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdh cmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksPGJyPg0KJmd0 OyZndDsgJmd0OyZndDthZGRyZXNzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGlu Z3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGVhZ2Vy IHRvIGRlYWwgd2l0aC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFs8YSBocmVmPSJtYWlsdG86 am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9h Pl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NlbnQ6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IEhhbHBlcm47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24u Y2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7U2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1l IGF0IGFsbCBpbiB0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZWdhcmQuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7STxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2FtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0 dXJlIG9yIHRoZSBzb2x1dGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cHJvaGliaXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDtIdWFuZydzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90 ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IHJlcXVpcmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHBy b2hpYml0PGJyPg0KJmd0OyZndDtzdWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5ncy4gV2hldGhlciB0aGV5IGFy ZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg bWFueTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBo YXBwZW4gdG88YnI+DQomZ3Q7Jmd0O3RoaW5rPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7dGhleTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh cmUgdXN1YWxseSBhIGJhZCBpZGVhLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgdGhlIGFyY2h0aWVj dHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7a25vdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2Vs PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZTo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEkgZGlzYWdyZWUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2Ugcm91 dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7bWlsbGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50 ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGll dmUgdGhhdCBpbjxicj4NCiZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENsb3VkL0lQdjYvTW9iaWxpdHkv V2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3U8YnI+DQomZ3Q7Jmd0OyBhcmU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IGdvaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNl IGNoYWlucyB3aXRoIGVxdWFsbHk8YnI+DQomZ3Q7Jmd0O3NtYWxsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IG51bWJlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2UgcGF0 aHM/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAm cXVvdDtubyBvbmUgd2lsbCBldmVyIG5lZWQgbW9yZTxicj4NCiZndDsmZ3Q7IHRoYW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgNjRLJnF1b3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3I8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY29tZm9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbPGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aHVhbmdA c2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7TG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUg dHJpZXMgdG8gZGVwbG95IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2Fy Y2h0aWV0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNl ZWQgdGhlIGxpbWl0cyBvZjxicj4NCiZndDsmZ3Q7dGhlaXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMu IFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZDxicj4NCiZndDsm Z3Q7IHVzZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBh dGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmU8YnI+ DQomZ3Q7Jmd0O2RvZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwZXJtaXQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHN1Y2ggYWJ1c2UuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGxlYXNl IGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0 OyBwZXJtaXRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBk ZWlzcmVkIG9yIHJlcXVpcmVkIGJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3b3JrLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXNuJ3QuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3 aWxsPGJyPg0KJmd0OyZndDttZWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYsMDAwLDAwMCBwYXRocy4g VGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZzxicj4NCiZndDsmZ3Q7dGFibGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O29mIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3JlIHJvdXRlci48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2Yg ZGVwbG95bWVudHMsIGZyb208YnI+DQomZ3Q7Jmd0OzE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vy dmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGU8YnI+DQomZ3Q7 Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3Ig dGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5PGJyPg0KJmd0OyZndDsgJmd0OyZndDtjaG9vc2U8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh dm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNjAsMDAwIHNl cnZpY2UgcGF0aHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlv dXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcv MTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFBhdWwsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQg aG9wPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFyaWE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d ICpPbiBCZWhhbGY8YnI+DQomZ3Q7Jmd0OyBPZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlBh dWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDszOjAzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5 IHlvbmcgKkNjOiogPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpv ZWxoYWxwZXJuLmNvbTwvYT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZTxi cj4NCiZndDsmZ3Q7IENoYWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBMdWN5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nLiBJwrlkPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2U8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50 aWZpZXIgY2FuIGJlIHVzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkZXJpdmU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0 cmFuc3BvcnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvPGJyPg0K Jmd0OyZndDtzaW1wbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5IHRoZSBzZXJ2 aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHM8YnI+DQomZ3Q7Jmd0O211c3Q8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIs IHRoZSBleGFjdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaXJlY3Rpb24gdGhhdCBwZW9w bGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uPGJyPg0KJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBh dGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpZGVudGlmaWVyPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2Fu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcmVzdWx0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp biBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhvcChzKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25n PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0Bo dWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJTNlIj5tYWlsdG86bHVj eS55b25nQGh1YXdlaS5jb20mZ3Q7PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdy b3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWdyZWUuIFRo ZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mPGJyPg0KJmd0OyZndDsg dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBk cml2ZSB0aGUgZm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWN0aW9ucy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbPGEg aHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiI+bWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSpPbjwvYT4gQmVoYWxmPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+T2YqbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAqU2VudDoqVGh1cnNkYXksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IEp1bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEwLCAyMDE0IDI6MDYgQU0g KlRvOjxhIGhyZWY9Im1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20iPiptaWtlYmlhbmNAYW9sLmNv bTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tJmd0OztqbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZyI+ bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86 c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBh dGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0 aGF0IGlkZW50aWZpZXIgdG88YnI+DQomZ3Q7Jmd0O2Rlcml2ZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZm9yd2FyZGluZyBhY3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVs bCBrbm93bGVkZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBldmVyeTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdmFp bGFibGUgU0ZDPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhp biBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVkL2p1c3RpZmll ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95 bWVudCBjb250ZXh0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBv Zjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB3aWxs PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czog dGhhdCBpcyB0aGUgb25lPGJyPg0KJmd0OyZndDsgcmVxdWlyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RydWN0dXJlIGEgc2VydmljZSBjaGFp bi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZWQgdG88 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndhcmRpbmc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWN0aW9u czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNz aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENo ZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBN ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRGUg OipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUiPm1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10qRGU8L2E+IGxhIHBhcnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tIj5kZSptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20i Pm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7ICpFbnZvecOpIDoqbWVyY3JlZGkgOTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGp1aWxsZXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIw MTQgMjI6MDMgKsOAIDo8YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3Jn PC9hPiZndDsgKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O0NoYWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJcyBh bnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsm Z3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYW5kIFNGPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGg/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlciB0 aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtjbGVhciB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lPGJyPg0K Jmd0OyZndDthZ3JlZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29uPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0aGVzZSB0ZXJtcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIg aXM8YnI+DQomZ3Q7Jmd0O3doZXRoZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0IGlzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVs eSBzcGVjaWZ5IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZSBJRDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgb2YgdGhlIFNGQyBIZWFkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2hvdWxkPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRo aXMgZHJhZnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXI8YnI+ DQomZ3Q7Jmd0O2RyYWZ0czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24g Y2hhaW48YnI+DQomZ3Q7Jmd0OyBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCBhbmQg dGhlIGNob2ljZSBvZiBjaGFpbiBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIHRvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBsYXR0ZXIgKGFtYmln dW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IG9uZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQg YW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZTxicj4NCiZndDsmZ3Q7IHZlbmRv cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz dXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDstLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKkZyb206PGEgaHJlZj0ibWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tIj4qam1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i PmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUz Y2ptaEBqb2VsaGFscGVybi5jb20lM2UiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbSZndDs8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRv OjxhIGhyZWY9Im1haWx0bzoqc2ZjQGlldGYub3JnIj4qc2ZjQGlldGYub3JnPC9hPiZsdDs8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9y ZyUzZSI+bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyZndDs8L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7ICpTZW50OipUdWVzZGF5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kPGJyPg0KJmd0OyZndDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseTxicj4N CiZndDsmZ3Q7YW5zd2VyPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJvcG9zZWQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBn ZXQ8YnI+DQomZ3Q7Jmd0OyB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBh Z3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvPGJyPg0KJmd0OyZndDsgaW1w cm92ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgV0c8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5kcy48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgd2hh dCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7cGVyc29uYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYg dGhhdCBoZWxwcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBh cmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZTxicj4NCiZndDsm Z3Q7YXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhh dCB3b3VsZCBlbmNvbXBhc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlv dXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucyw8YnI+DQomZ3Q7Jmd0O3ZpcnR1YWw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBt YW55IG90aGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYXNwZWN0cy48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUg bWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkPGJyPg0KJmd0OyZndDsgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJl IGRlYWx0IHdpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fib3ZlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3aGVyZSB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBh cmU8YnI+DQomZ3Q7Jmd0OyBkb2luZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2 aWNlIHBhdGgsPGJyPg0KJmd0OyZndDthcyBJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRl cnN0YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8g Zmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDtsZWFzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWUgZGlmZmVyZW50IHdh eXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHBy b2JhYmx5IGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bW9yZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXNlLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSB1c2Vk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhbnkgc29sdXRpb24uPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMg YSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQg cmVjZWl2ZXMgdXNlcjxicj4NCiZndDsmZ3Q7cGFja2V0cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kaWZpZXMgdGhlbSAob3I8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg bWFya3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hv b3NlIGFuIGVuZCB1c2VyIHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3RhbmNlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMg aXMgYW4gaW1wb3J0YW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBj aGFpbmluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0l0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgY2hhaW5pbmcgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRv bmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7YXJjaHRpZWN0dXJlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNo aXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRl cmx5aW5nIHBhY2tldC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25l PGJyPg0KJmd0OyZndDtjYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhdmU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyPg0K Jmd0OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNvbnRhY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNw ZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2J5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVk aW5nPGJyPg0KJmd0OyZndDtvbmUgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldmVyYWwg bG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0 aGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgZGF0YSBwbGFuZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGlrZWx5 IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O21lY2hhbmlzbXMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIHRob3NlIHJl c3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCA8YnI+DQomZ3Q7Jmd0O2FuZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dm08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRp b24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiA8YnI+DQomZ3Q7Jmd0O3Blcm1pdHRpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxh cmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXI8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3Rlcm1pbm9sb2d5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHJlYWRlcnMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFy ZSBwcm9oaWJpdGluZyBpdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IDxi cj4NCiZndDsmZ3Q7c2VsZWN0aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0 aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2Vz LiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlPGJyPg0KJmd0OyZndDsgdGhhdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBm dW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gPGJyPg0KJmd0OyZndDt0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhl c2UgbWF5IGJlIDxicj4NCiZndDsmZ3Q7Y29tYmluZWQuIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB0ZW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBl YXIgdG8gc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hhaW5pbmc8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2Ug Y2x1c3RlciA8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5v dGhlciBvbmUuPGJyPg0KJmd0OyZndDsgVGh1cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBpcyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBz dWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaW5n dWxhcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b25zIGluIGRpZmZlcmVudCBwbGFjZXMgPGJyPg0KJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwg d2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgc2VxdWVuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGxv Z2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2Y8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3BhY2tldHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFs ZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIDxicj4NCiZndDsmZ3Q7dHJhZmZpYzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBE UEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnI+DQomZ3Q7Jmd0O2ZpcmV3 YWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMg dG8gZ28gZGlyZWN0bHkgdG8gdGhlIDxicj4NCiZndDsmZ3Q7Y2FjaGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91 dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVu Y3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIDxicj4NCiZndDsm Z3Q7cGFja2V0cy48YnI+DQomZ3Q7Jmd0OyBBPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2 aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29y ay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhl eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5IGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh ZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzPGJyPg0KJmd0 OyZndDsgcG9ydHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkg YmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmU8YnI+DQomZ3Q7 Jmd0OyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZD IDxicj4NCiZndDsmZ3Q7Z3JvdXAsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh YmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdo aWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG88YnI+DQomZ3Q7Jmd0OyB0 YWxrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBw YWNrZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJh bCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICZxdW90O2J1dCB0aGUgd2hvbGU8YnI+DQomZ3Q7 Jmd0OyBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWF5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBk ZWFsczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIDxicj4N CiZndDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyPg0K Jmd0OyZndDtiZWhhdmlvcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3aGljaDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNo YW5pc21zIChpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bXVjaDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFO cy4pIFRoZSBvdGhlcjxicj4NCiZndDsmZ3Q7IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IHdlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlIGlzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlk LWNoYWluIHdoZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWNlc3NhcnkuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJh c2VkIG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQg dGhlIHJlLWNsYXNzaWZpY2F0aW9uIDxicj4NCiZndDsmZ3Q7cG9pbnQuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBob3BlIHRoYXQgdGhpcyBoZWxw cyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiA8YnI+DQomZ3Q7Jmd0O0lmIGl0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRv IHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgZ3JvdXAsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZDxicj4NCiZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXkgdGhp cy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBpbnRlbnQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2Yg Y291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Z3JvdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2hhdCB0bzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5IG5leHQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5n PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1h aWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h Pjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9NKGEML512MBSchi_-- From nobody Sun Jul 13 21:26:57 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC61A02E0 for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 21:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fHTJH56sBfgs for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 21:26:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0E81A02E9 for <sfc@ietf.org>; Sun, 13 Jul 2014 21:26:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJY03135; Mon, 14 Jul 2014 04:26:42 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 05:26:40 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 12:26:34 +0800 From: Qin Wu <bill.wu@huawei.com> To: "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "Ron_Parker@affirmednetworks.com" <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8YfQfWuVGhxUuCtLkqflW3N5uYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHID///EV4P//g6sAgAAEboCAAANgAIAAB9gAgAAGp4CAAAK6AIAAJooA//uz1aA= Date: Mon, 14 Jul 2014 04:26:33 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA845828FC@nkgeml501-mbs.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA845828FCnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rd-xLbEtd3MyedJNZb5_9lcBvlw Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 04:26:55 -0000 --_000_B8F9A780D330094D99AF023C5877DABA845828FCnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhhY3RseSwgaXQgc2hvdWxkIGJlIOKAnXNlcnZpY2UgY2hhaW4gaWRlbnRpZmllcuKAnS4NCg0K 5Y+R5Lu25Lq6OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIG1pa2Vi aWFuY0Bhb2wuY29tDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMTLml6UgMjo0Ng0K5pS25Lu2 5Lq6OiBqZ3VpY2hhckBjaXNjby5jb207IG1uMTkyMUBhdHQuY29tOyBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tOyBzZmNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCldvdWxkbid0IHRoYXQgYmUgY2FsbGVkIHRo ZSAic2VydmljZSBjaGFpbiBpZGVudGlmaWVyIiB0aGVuPyAgSWYgdGhlIHNlcnZpY2UgY2hhaW4g aXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlIG9y ZGVyZWQgbGlzdCBvZiBTRiBpbnN0YW5jZXMsIHRoZW4gSSB3b3VsZCBpbmZlciB0aGF0IGEgInNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIiB3b3VsZCBiZSBhbiBpZGVudGlmaWVyIGZvciBhIHNlcnZp Y2UgKnBhdGgqLCBub3QgYSBzZXJ2aWNlICpjaGFpbiouDQoNCkFnYWluLCBJIHRoaW5rIHRoaXMg aXMgd2hlcmUgdGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBpbi4gIFRoZSB0ZXJtcyAiY2hh aW4iIGFuZCAicGF0aCIgc2VlbSBpbmNvbnNpc3RlbnQuDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRnJvbTogamd1aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNpc2Nv LmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29tPj4NClRv OiBtaWtlYmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9sLmNvbT4sbW4xOTIxQGF0dC5jb208bW4x OTIxQGF0dC5jb20+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4sam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tPixS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb20+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t JTNjbWlrZWJpYW5jQGFvbC5jb20lM2UsbW4xOTIxQGF0dC5jb20lM2NtbjE5MjFAYXR0LmNvbSUz ZSxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTNjbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSUzZSxqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZSxSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJTNjUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbSUzZSxzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5 IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCllvdXIgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBhdGggaXMgY29ycmVj dCBhcyBpdHMgdGhlIGZvcndhcmRpbmcgcGF0aCB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBh Y3R1YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaG93ZXZlciBwb2ludHMg dG8gdGhlIHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1cmUgYW5kIHRoYXQgaXMgdGhlbiByZXNv bHZlZCB0byBzcGVjaWZpYyBpbnN0YW5jZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0LWhvcHMgdG8g dGhvc2UgaW5zdGFuY2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0 aW9uIHRlY2huaXF1ZSBpcyBpbiBwbGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2Ug Y2hhaW4gaW50byB0aGUgbmV0d29yayB5b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0 YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3aGljaCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJl IGEgc2luZ2xlIG5leHQtaG9wIHdvdWxkIGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2Ug cGF0aCBmb3IgdGhhdCBzZXJ2aWNlIGNoYWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21l IG90aGVyIHByb3RvY29sIC8gbWVjaGFuaXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVy ZSBmb3IgeW91Lg0KDQpGcm9tOiAibWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPiIgPG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQpE YXRlOiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgYXQgMTI6MTggUE0NClRvOiBKaW0gR3VpY2hhcmQg PGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4sICJtbjE5MjFA YXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+IiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1u MTkyMUBhdHQuY29tPj4sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiwgImptaEBqb2VsaGFscGVybi5j b208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LCAiUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4iIDxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t Pj4sICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KSSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRo ZSBjb25mdXNpb246DQoNCj4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0KPiBzcGVjaWZpYyBp bnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRpb24gdGhlcmVvZiku IEkNCj4gYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFz aWNhbGx5IHBvaW50cyB0byBTMS0+UzItPlMzDQo+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRo ZSBuZXR3b3JrDQoNCkJ5IGRlZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICJzZXJ2aWNlIHBhdGgi IHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIEluIHRoZSBz dGF0ZW1lbnQgYWJvdmUsIHlvdSB1c2UgYSAic2VydmljZSBwYXRoIGlkZW50aWZpZXIiIHRvIHJl ZmVyIHRvIGEgc2VydmljZSAqY2hhaW4qIHRoYXQgc3BlY2lmaWNhbGx5ICJbZG9lcyBub3RdIHNw ZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzIi4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogamd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5j b20+PGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4NClRvOiBO QVBJRVJBTEEsIE1BUklBIEg8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4s bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT48bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4+LEpvZWwgTS4gSGFscGVybjxqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sUm9uIFBhcmtlcjxSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPj4NClNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNA0KU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCk1hcmlhLA0KDQpJ IHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgc2lt cGx5IGEgcG9pbnRlciB0bw0KYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5l eHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUgYQ0KY2hhaW4sIGxldOKAmXMgc2F5IFMx IC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUgU0ZQIHNwZWNpZnkNCnRo ZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRvIGZsb3cgdGhyb3Vn aCBmb3IgdGhhdCBTRlAuDQpIb3dldmVyLCB5b3UgZG8gKm5vdCogaGF2ZSB0byBkbyB0aGlzIGZy b20gYW4gYXJjaGl0ZWN0dXJhbCBzdGFuZHBvaW50IChJDQp3aWxsIGFyZ3VlIHRoYXQgeW91IHNo b3VsZCBidXQgeW91IGRvbuKAmXQgaGF2ZSB0byBhcmNoaXRlY3R1cmFsbHkpLiBZb3UNCmNvdWxk IHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBwb2ludCB0byBhIGdp dmVuIFNGQyBhbmQNCnRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdvcmsu IEF0IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGENCnNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIFNG QyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQgY29udGFpbiB0aGUNCm5leHQtaG9wcyBh dmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3Ug bGVhcm4NCnRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRoZW0g ZG93biBmcm9tIGEgY2VudHJhbGl6ZWQNCmNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91 Z2ggQ0xJLCBsZWFybiB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2gNCnNvbWUgcHJvdG9jb2wgZXhj aGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvDQpz YXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUg Y2hvc2VuIGEgcHJpb3JpDQphbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAoYW5k IHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0byBkbw0Kc28uDQoNCkxldOKAmXMgdGFrZSBh biBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6DQoNCkkgZGVmaW5lIGFuIFNG QyAobGV04oCZcyByZWZlciB0byBpdCBhcyBTRkMtMSkgUzEtPlMyLT5TMy4gRm9yIGFyZ3VtZW50 cw0Kc2FrZSBsZXTigJlzIHNheSBJIHdhbnQgaXQgdG8gYmUgZnVsbHkgZHluYW1pYyBlLmcuIEkg ZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkNCnNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFu ZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KYXNzaWduIGEgc2VydmljZSBw YXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0+UzIt PlMzDQphbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yayBzbyB0aGF0IHRoZSBTRkYg ZGF0YSBzdHJ1Y3R1cmVzIGFyZQ0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93 IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlcw0Kd2l0aCBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciAxMDAsIHRoZSBTRkYgd2lsbCBsb29rIHRoaXMgdXAgaW4gdGhlIGRhdGENCnN0 cnVjdHVyZSBhbmQgZmluZCB0aGF0IGl0IHBvaW50cyB0byBTMS0+UzItPlMzIGFuZCB0aGUgaW5k ZXggaW4gdGhlIFNGQw0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhhY3RseSB3aGVyZSBp dCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlDQphcmUgYXQgUzIgaW4gdGhlIGNoYWlu LiBUaGUgU0ZGIHdpbGwgbm93IGhhdmUgdG8gcmVzb2x2ZSB0aGUgbmV4dC1ob3AgdG8NClMzIGFu ZCB3aWxsIGRvIGEgbG9va3VwIHRvIGRldGVybWluZSB3aGVyZSBTMyBpcyByZWFjaGFibGUuDQoN Ck9uIDcvMTEvMTQsIDExOjI2IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5j b208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQoNCj5KaW0sDQo+DQo+Q291bGQgeW91 IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCBh DQo+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIj8NCj5JZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0 aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhcHJpb3JpICh3aGljaA0KPmlzIG15IGN1 cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24g d2hpY2gNCj5uZXh0LWhvcCBTRkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lv bi4NCj4NCj5NYXJpYQ0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+DQoN CkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29t XQ0KPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNDQo+PiBUbzogTkFQSUVS QUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9lbCBNLg0KPj4gSGFscGVybjsgUm9uIFBhcmtlcjsg c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBJ4oCZbSBz b3JyeSBidXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBhIHNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyDQo+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMg b3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlDQo+PiBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFu eSBkaWZmZXJlbmNlPw0KPj4NCj4+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBN QVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+ Pg0KPj4gPkRpdHRvLg0KPj4gPg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb21dDQo+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4+ID4+ IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0u IEhhbHBlcm47IFJvbg0KPj4gPj4gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4NCj4+ID4+IFJlLSwNCj4+ID4+DQo+PiA+PiBGb3Igd2hh dCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0aGUN Cj4+ZHJhZnQuDQo+PiA+Pg0KPj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50aWZp ZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxsDQo+PiA+PmRpc3RyaWJ1dGVkDQo+ PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4+ID4+DQo+PiA+PiBTZXZlcmFsIHZvaWNlcyBp biB0aGlzIHRocmVhZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGYNCj4+ ID4+c2hvdWxkIGJlDQo+PiA+PiBwcm92aWRlZCBpbnN0ZWFkLg0KPj4gPj4NCj4+ID4+IENoZWVy cywNCj4+ID4+IE1lZA0KPj4gPj4NCj4+ID4+ID4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4+ID4+ID5EZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIEppbSBHdWljaGFyZA0KPj4gPj4gPihqZ3VpY2hhcikNCj4+ID4+ID5FbnZvecOpIDogdmVu ZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4DQo+PiA+PiA+w4AgOiBOQVBJRVJBTEEsIE1BUklB IEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4NCj4+ID4+ID5PayBidXQgd2hlcmUgaW4gdGhl IGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcyBmdW5jdGlvbmFsaXR5DQo+PiA+PiA+ cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8g KmFsbCogU0ZG4oCZcw0KPj4gPj4gPndpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQg dGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhDQo+PiA+Pmxvb2t1cA0KPj4gPj4gPmludG8g dGhvc2UgbmV4dC1ob3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBu b3QNCj4+c3VyZQ0KPj4gPj5ob3cNCj4+ID4+ID50aGUgYXJjaGl0ZWN0dXJlIHByZXZlbnRzIHRo YXQ/DQo+PiA+PiA+DQo+PiA+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFMQSwgTUFS SUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQo+PiB3cm90ZToN Cj4+ID4+ID4NCj4+ID4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ID4+DQo+PiA+PiA+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPj4gPj4gPj4+KGpndWlj aGFyKQ0KPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+PiA+ PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2Vy OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ ID4+Pg0KPj4gPj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4g SG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4+ID4+dGhhdCBpZg0KPj4gPj4gPj4+IHlvdSBhbGxv dyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYgaXQNCj4+ d2lsbA0KPj4gPj51c2UNCj4+ID4+ID4+PmZvcg0KPj4gPj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byBy ZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91DQo+PmJldHRlcg0KPj4g Pj5tYWtlDQo+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vz c2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvDQo+PiA+PnJlYWNoDQo+PiA+PiA+Pj50aGUNCj4+ID4+ ID4+PiBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBk ZWVwIHRyb3VibGUuDQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCAi TkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29t Pj4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBT ZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4+cmVsZXZhbnQNCj4+ ID4+ID4+PlNGRnMNCj4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4gPj4gPj4+ID4N Cj4+ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4+ID4+IEZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+ Pkd1aWNoYXJkDQo+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gPj4gU2VudDogRnJp ZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxw ZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IFdlbGwgSSB0aGluayBpdCBp cyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZA0KPj50aGUNCj4+ID4+ ID4+PiA+PnByb3Bvc2FsDQo+PiA+PiA+Pj4gPj4gY29ycmVjdGx5IGFzIGl0IHdvdWxkIHJlcXVp cmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlDQo+PlNGDQo+PiA+PiA+Pj53aXRoaW4N Cj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5 IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5IHRvDQo+Pmtub3cNCj4+ID4+YQ0KPj4gPj4g Pj4+ID4+cHJpb3JpDQo+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwg bmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbg0KPj5wb2ludA0KPj4gPj5pbg0KPj4gPj4gPj4+ dGltZS4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAi Sm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4+DQo+PiA+PiB3cm90ZToNCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+ID5Sb24s IHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpvciBwcm9ibGVtDQo+ PndpdGgNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj55b3VyDQo+PiA+PiA+Pj4gPj4gPnByb3Bvc2Fs IGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90DQo+PiA+ PiA+Pj51bmRlcnN0YW5kDQo+PiA+PiA+Pj4gPj4gPml0LikNCj4+ID4+ID4+PiA+PiA+DQo+PiA+ PiA+Pj4gPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFs YW5jZXIgZm9yIHRoZQ0KPj4gPj5uZXh0DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24g dGhhdCBmb2xsb3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj50byksDQo+PiA+Pmlu DQo+PiA+PiA+Pj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0 aHJvdWdoIGl0Lg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+U2luY2UgaXQgaGFzIHRv IGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFucw0KPj4gPj50aGF0 DQo+PiA+PiA+Pj4gPj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBh IGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkDQo+PiA+PiA+Pj5iYWxhbmNl ci4NCj4+ID4+ID4+PiA+PiA+SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBTRkYgYXJlIGZsb3cg c2Vuc2l0aXZlLCBhbmQgLyBvcg0KPj4gPj5zdGF0ZWZ1bC4NCj4+ID4+ID4+PiA+PiA+QnV0IGhh dmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLA0K Pj4gPj5mbG93DQo+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5j ZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+ID4+YWNjZXB0YWJsZQ0KPj4gPj4gPj4+ID4+ID5p bXBvc2l0aW9uLg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+WW91cnMsDQo+PiA+PiA+ Pj4gPj4gPkpvZWwNCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPk9uIDcvMTAvMTQsIDEw OjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBt eSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZSB0aGlzDQo+PndvcmsN Cj4+ID4+ID4+PiA+PnNlbnNpYmx5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3Ry YXRlZCBlbnZpcm9ubWVudC4gSSBleHBlY3QgdGhhdCB0aGUNCj4+c2VydmljZQ0KPj4gPj4gPj4+ ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxp dGllcywNCj4+d2lsbA0KPj4gPj5iZQ0KPj4gPj4gPj4+ID4+ID4+IG9yY2hlc3RyYXRlZCBhbmQg aW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMNCj4+dG8gYmUNCj4+ID4+ID4+ PiA+PmRyaXZlbiBieQ0KPj4gPj4gPj4+ID4+ID4+IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZl cmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZQ0KPj4gPj4gPj4+c2VsZi1zZWxlY3Rpb24NCj4+ ID4+ID4+PiA+PiA+PiBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhl YXZpbHkgcG9saWN5DQo+PiA+PmRyaXZlLg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4g Pj4gSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRpZWN0 dXJlDQo+PiA+PmRyaXZlbg0KPj4gPj4gPj4+YnkNCj4+ID4+ID4+PiA+PiA+PiBpbml0aWFsIGNs YXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBpcw0KPj4gPj5oYXJk ZXINCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj5zZWUNCj4+ID4+ID4+PiA+PiA+PiBob3cgdG8g bWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cgbW9yZQ0KPj4g Pj4gPj4+ID4+IGR5bmFtaWNpdHkNCj4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhh dmlvci4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IEhhdmluZyBzYWlkIHRoYXQs IG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJIGRlc2NyaWJlZCBpcw0KPj4gPj5vdXRzaWRlDQo+ PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4gc2NvcGUgb2YgdGhl IHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+PiA+PnRhc2tlZCB0 bw0KPj4gPj4gPj4+ID4+YWdyZWUNCj4+ID4+ID4+PiA+PiA+Pm9uLg0KPj4gPj4gPj4+ID4+ID4+ IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYQ0K Pj5jZXJ0YWluDQo+PiA+PiA+Pj53YXkuDQo+PiA+PiA+Pj4gPj5pdA0KPj4gPj4gPj4+ID4+ID4+ IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4g Pj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+PiA+PiA+Pj4gPj4gPj4gSm9l bA0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwg SWFuIFNtaXRoIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9m IGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PiB0aGF0DQo+PiA+PiA+ Pj4gPj5uZWVkcw0KPj4gPj4gPj4+ID4+ID4+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4gYmUgd2lk ZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuDQo+PiA+PmFj cm9zcw0KPj4gPj4gPj4+ZGF0YQ0KPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4g YWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaA0KPj5hbmQNCj4+ID4+ID4+PiBj b21wbGV4DQo+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQg aW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+ID4+PmRpZmZpY3VsdA0KPj4gPj4gPj4+ ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+ PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0 ZWQgdGhhbg0KPj5keW5hbWljDQo+PiA+PiA+Pj4gcm91dGluZywNCj4+ID4+ID4+PiA+PiA+Pj4g aHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2YNCj4+ d2hpY2gNCj4+ID4+YXJlDQo+PiA+PiA+Pj4gPj5iaWdnZXINCj4+ID4+ID4+PiA+PiA+Pj4gcHJv YmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVudGVkPw0K Pj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYg aXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQNCj4+aXMNCj4+ID4+YQ0KPj4gPj4g Pj4+Z29vZA0KPj4gPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVk Lg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4+IEZyb206IEpvZWwgTS4gSGFs cGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+ PiA+PiA+Pj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUgUE0NCj4+ ID4+ID4+PiA+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1pa2Vi aWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47DQo+Pklhbg0KPj4gPj4gPj4+ U21pdGg7DQo+PiA+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZA0KPj5CYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3Vs ZA0KPj5wcmVmZXINCj4+ID4+d2UNCj4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPj4gPj4gPj4+ ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGUN Cj4+ID4+aW1wbGVtZW50YXRpb25zLg0KPj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRvZXMg aGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPj4gPj5yZXF1aXJlbWVudHMNCj4+ ID4+ID4+PmFuZA0KPj4gPj4gPj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+PiBmdW5jdGlvbmFs aXR5IG9mIFNGRnMuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwg dGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcw0KPj4gPj50 aGF0DQo+PiA+PiA+Pj4gbmVlZHMNCj4+ID4+ID4+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+PiBi ZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ IGFjcm9zcw0KPj4gPj4gPj4+ZGF0YQ0KPj4gPj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdpdGhpbiBh biBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+ Y29tcGxleA0KPj4gPj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQg aW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+ID4+PmRpZmZpY3VsdA0KPj4gPj4gPj4+ ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ID4+ID4+PiA+PiA+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ID4+ID4+ PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtl ciB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUu IElzIHRoZSBlbmQgdG8gZW5kDQo+PnNlbGVjdGlvbg0KPj4gPj5vZg0KPj4gPj4gPj4+ID4+ID4+ Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkg dGhlDQo+PiA+PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5 LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5DQo+PiA+PnRo ZQ0KPj4gPj4gPj4+ID4+U0ZGcyk/DQo+PiA+PiA+Pj4gPj4gPj4+PiBTdWNoIHNlbGVjdGlvbiBp cyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9uLg0KPj5BbmQNCj4+ID4+ID4+PnN1 cmVseSwNCj4+ID4+ID4+PiA+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBh bmQgbm90IHJlbGVnYXRlZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4N Cj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBNeSBvd24gdmlldyBpcyB0byBm YXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbg0KPj4gdGhvdWdoDQo+PiA+PiBhDQo+ PiA+PiA+Pj4gPj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9u cyBhbmQgcGVyaGFwcw0KPj5sb2NhbA0KPj4gPj4gPj4+ID4+c2VsZWN0aW9uDQo+PiA+PiA+Pj4g Pj4gPj4+PiBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9u IHBvaW50cy4NCj4+ID4+VGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3Qg cmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLg0KPj4gPj5NeQ0KPj4gPj4gPj4+ ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmls eSBkcml2ZW4NCj4+YnkNCj4+ID4+ID4+PiA+PmluY3JlYXNlZA0KPj4gPj4gPj4+ID4+ID4+Pj4g cmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0aCBhDQo+Pmds b2JhbA0KPj4gPj4gPj4+cGF0aA0KPj4gPj4gPj4+ID4+aWQNCj4+ID4+ID4+PiA+PiA+Pj4+IGFw cHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvDQo+ PiA+PmFsdGVyDQo+PiA+PiA+Pj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElE IHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZA0KPj5lbmQtdG8tZW5kDQo+PiA+PiA+ Pj5wYXRoLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFJvbg0KPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwg SGFscGVybiBEaXJlY3QNCj4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XSBTZW50OiBUaHVyc2RheSwg SnVseSAxMCwNCj4+MjAxNA0KPj4gPj4gNjoxNQ0KPj4gPj4gPj4+IFBNDQo+PiA+PiA+Pj4gPj4g Pj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgSS5T bWl0aEBGNS5jb208bWFpbHRvOkkuU21pdGhARjUuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0Og0KPj4gPj4gUmU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2Rl bHMgdGhlIGNhc2Ugb2YgU0YxIG5lZWRpbmcNCj4+dG8NCj4+ID4+ID4+PiA+PmluZmx1ZW5jZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xhc3Np ZmljYXRpb24gYXQgdGhlDQo+PmV4aXQNCj4+ID4+ZnJvbQ0KPj4gPj4gPj4+ID4+ID4+Pj4gU0Yx Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwg aXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucw0KPj4gPj5sb2dpY2FsbHkNCj4+ID4+ ID4+PiA+PiA+Pj4+IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2Ny aWJlIGhvdyB0aGV5DQo+PiA+PiBjaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+ PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ID4+ID4+PiA+PiA+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAgUE0sIG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbT4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24ndCBz ZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnkNCj4+ID4+c29y dA0KPj4gPj4gPj4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwgaXQgZG9l cyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZQ0KPj4gPj5wYXRoDQo+PiA+PiA+Pj4o YWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3Rh bnRpYXRpb24uIEkgYmVsaWV2ZQ0KPj50aGlzDQo+PiA+PiA+Pj5tZWFucw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcg0K Pj5jaG9vc2VzIGENCj4+ID4+U0YNCj4+ID4+ID4+PiA+PkNoYWluDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueSBjYXNl LA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJv aGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlDQo+PiA+PiBTRkkobikNCj4+ID4+ID4+PiBp cw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gQWNj b3JkaW5nIHRvIHRoZSBkcmFmdCwNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2 aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcgU0ZQIGFzDQo+PiA+ PiA+Pj4gb3Bwb3NlZA0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY2hvb3Np bmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2YNCj4+ID4+ dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNo aXRlY3R1cmUtMDA6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRp YXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+PiA+Pm5lY2Vzc2FyeQ0KPj4gPj4gPj4+dG8N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0Zz IHRoYXQgd2lsbCBiZSB1c2VkLA0KPj4gPj5hbmQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY3Jl YXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzDQo+PiA+Pm5l dHdvcmsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBv ZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlDQo+PiA+PiA+Pj5jcmVhdGlvbg0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3IN Cj4+ID4+Zm9yd2FyZGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhl IFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g aW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3Np ZmljYXRpb24gKG9yDQo+PiA+Pm5vbi1pbml0aWFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNz aWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9y bWVkIGJ5IGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rpb24gY28t cmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UNCj4+ID4+ZnVuY3Rpb24uDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3 DQo+PiA+PlNGUCwgYW4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lh dGVkIG1ldGFkYXRhLCBvciBib3RoLiBUaGlzIGlzDQo+PiA+PnJlZmVycmVkDQo+PiA+PiA+Pj50 bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+Pg0KPj4+Pj4+Pj4+Pj4+Pj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ID4+ID4+Pj4+Pj4+ Pj4tLQ0KPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNvbTxtYWlsdG86KkkuU21pdGhARjUuY29t PjxJLlNtaXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+ICpUbzogKkpvZWwgSGFscGVybg0KPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4+LEpvZWwNCj4+ID4+IE0uDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4gPj4+ Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ PixodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVh bmdAc2NlLg0KPG1haWx0bzpodWFuZ0BzY2UuJTBiPj4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4+ ID4+ID4+PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqU2Vu dDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlN1YmplY3Q6 ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gPj5CYWxhbmNl cnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEFjdHVhbGx5LCBJIHRo aW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+PiBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQN Cj4+dGhhdCBpcw0KPj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IDE2IG1pbGxpb24g Zmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzDQo+PiA+PiA+Pj5wcmVj b25jZWl2ZWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUg YXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGgNCj4+IHRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBw cmVjb25jZXB0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhl cmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZg0KPj4gPj5hc3Bp cmF0aW9uDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9w cmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4+ID4+YXJjaGl0ZWN0dXJlDQo+PiA+PiA+ Pj4tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlz LCBidXQgYnkgc2F5aW5nIHRoYXQgYW4NCj4+ID4+ID4+PmFyYml0cmFyeQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQg aXNuJ3QNCj4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxp bWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3RpbmcNCj4+ID4+aW1w YWN0cw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0 aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4+ID4+YWRkcmVzcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNw YWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3QNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFtqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XQ0K Pj4gPj5TZW50Og0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6 MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLg0KPj4gPj4gSGFscGVybjsNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5j YT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0OiBSZTogW3NmY10N Cj4+ID4+U2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSWFuLCBJ IGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzDQo+PiA+PnJl Z2FyZC4NCj4+ID4+ID4+PkkNCj4+ID4+ID4+PiA+PmFtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbm90 IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uDQo+PiA+PnBy b2hpYml0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZh c2hpb24uIEkgYW0gb2JqZWN0aW5nIHRvDQo+PiA+Pkh1YW5nJ3MNCj4+ID4+ID4+PiA+PiA+Pj4+ PiByZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmUN Cj4+ID4+IHJlcXVpcmVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhleSBieSB0aGUgYXJjaHRpZWN0 dXJlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQXMgSSBoYXZlIHNh aWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0DQo+PnN1Y2gNCj4+ID4+ ID4+PiA+PiA+Pj4+PiB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Igbm90 IGRlcGVuZHMgdXBvbg0KPj4gPj4gbWFueQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0 c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bw0KPj50aGluaw0KPj4gPj50 aGF0DQo+PiA+PiA+Pj4gPj50aGV5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBi YWQgaWRlYS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEJ1dCB0aGUg YXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvDQo+PiA+Pmtu b3cNCj4+ID4+ID4+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95 YWJsZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2Vs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAx IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZl IHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZg0KPj4gPj4gPj4+bWlsbGlvbnMN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZs b3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhh dCBpbg0KPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIu MC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91DQo+PiBhcmUNCj4+ID4+IG9ubHkNCj4+ID4+ID4+ PiA+PiBnb2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBz ZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkNCj4+c21hbGwNCj4+ID4+ID4+PiBudW1iZXJzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5v IG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlDQo+PiB0aGFuDQo+PiA+PiA+Pj4gNjRLIg0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBmb3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb21mb3J0Lg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFtq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzoNCj4+ ID4+ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNh PjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+PmFuZA0KPj4gPj4g Pj4+TG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUg dHJpZXMgdG8gZGVwbG95IHRoZQ0KPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YN Cj4+dGhlaXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBk b2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkDQo+PiB1c2UNCj4+ID4+IG9mDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0 byB3cml0ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hp Yml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlDQo+PmRvZXMNCj4+ID4+ID4+PnBlcm1pdA0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVj dHVyZQ0KPj4gcGVybWl0cw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5n IGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5DQo+PiA+PnRoZQ0KPj4gPj4gPj4+ d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcg d3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBz ZXJ2aWNlIGNoYWlucywgaXQgd2lsbA0KPj5tZWFuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAxNiww MDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nDQo+PnRhYmxlDQo+ PiA+Pm9mIGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBI YWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxs b3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20NCj4+MQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlDQo+ PnRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0 aGUgY29tcGxleGl0aWVzIGlmIHRoZXkNCj4+ID4+Y2hvb3NlDQo+PiA+PiA+Pj50bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5k IGluIHN0ZWFkDQo+PiA+PiBwcm92aXNpb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAw IHNlcnZpY2UgcGF0aHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUg Zm9yIGEgNCBob3ANCj4+ID4+IHNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4g d2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gKk9uIEJlaGFsZg0KPj4gT2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4g KHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+PiA+PjM6MDMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVy bi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4+IENoYWlucywNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBh dGggSUQgZHJpdmVzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nLiBJwrlk DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlu b3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+PiA+PiBkZXJp dmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBhc3Nv Y2lhdGVkIHRyYW5zcG9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRv DQo+PnNpbXBseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBw YXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzDQo+Pm11c3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNr aW5nIGZvciBvbg0KPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUg c2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aA0KPj4gPj4gaWRlbnRpZmllcg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhh dCBsb29rdXAgY2FuDQo+PiA+PiByZXN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBv bmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmcNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4NCj4+ID4+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PG1haWx0bzpsdWN5 LnlvbmdAaHVhd2VpLmNvbSUzZT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBz aG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YNCj4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZw0KPj4g Pj5hY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBMdWN5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpG cm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVoYWxmDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOk9m Km1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+PiAqU2VudDoqVGh1 cnNkYXksDQo+PiA+PiA+Pj4gPj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAx NCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOiptaWtlYmlhbmNAYW9sLmNv bT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPjtzZmNAaWV0Zi5vcmc8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYu b3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1Ympl Y3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiA+PkNoYWlucywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBz ZXJ2aWNlIHBhdGgNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3Qg dG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPj5kZXJpdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25v d2xlZGdlIG9mDQo+PiA+PiBldmVyeQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWlsYWJsZSBTRkMN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVu YWJsZWQgZG9tYWluIGlzIG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmll ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3lt ZW50IGNvbnRleHRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRo YXQgd2lsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3lt ZW50czogdGhhdCBpcyB0aGUgb25lDQo+PiByZXF1aXJlZA0KPj4gPj4gdG8NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRp b24gaXMNCj4+ID4+dXNlZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJk aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp cyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSpEZSBsYSBwYXJ0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb208bWFp bHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+ID4+IGp1aWxsZXQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmc8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFp bHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5z LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGls bCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+PlNGDQo+PiA+PiBDaGFpbg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRp b24gc28gdGhhdCBpdCdzDQo+PiA+PmNsZWFyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ug bm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBz ZWVtcyB0aGF0IGV2ZXJ5b25lDQo+PmFncmVlcw0KPj4gPj5vbg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzDQo+ PndoZXRoZXINCj4+ID4+aXQgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBv ZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0DQo+PiA+PnRoZSBJRA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+ IHNob3VsZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0 aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQNCj4+ID4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+ PmRyYWZ0cw0KPj4gPj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNo YW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+PiBvcg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gcGF0aCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRo ZSBjb250cm9sLXBsYW5lLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBo YXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZD IGJlIHN1cHBvcnRlZCAob3IgbWFrZQ0KPj4gPj4gb25lDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+IHZlbmRv cnMNCj4+ID4+IG9ubHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5k IG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0N Cj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+ Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhA am9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbT48bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRv OipzZmNAaWV0Zi5vcmc8bWFpbHRvOipzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9y ZyUzY3NmY0BpZXRmLm9yZz48bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUzZT4+ DQo+PiAqU2VudDoqVHVlc2RheSwNCj4+ID4+IEp1bHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g OCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQNCj4+TG9h ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBv dXQgaG93IHRvIGNsZWFybHkNCj4+YW5zd2VyDQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlDQo+PiA+ PiA+Pj4gcHJvcG9zZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVy ZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldA0KPj4gd29ya2luZw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvDQo+ PiBpbXByb3ZlDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0 aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbg0KPj4gPj50aGUNCj4+ID4+ IFdHDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQg dGhlIHdheSB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWlu IG15DQo+PiA+PnBlcnNvbmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUg aWYgdGhhdCBoZWxwcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhh dA0KPj4gPj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0 aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlDQo+PmFyZQ0KPj4gPj4gbm90DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9y IHRoZSBlbnRpcmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24gZm9yIHNlcnZpY2Ug Y2hhaW5pbmcuIFRoYXQgd291bGQgZW5jb21wYXNzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9T Uy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCj4+dmlydHVhbA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQg bWFueSBvdGhlcg0KPj4gPj4gYXNwZWN0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNo IGNsZWFybHkgbmVlZA0KPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhl IGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aA0KPj4gPj5hYm92ZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmdW5j dGlvbmluZywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVx dWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlDQo+PiBkb2luZy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hh aW4gdnMgc2VydmljZSBwYXRoLA0KPj5hcyBJDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHVuZGVy c3RhbmQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJ IG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0DQo+PiA+ PmxlYXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZlcmVudCB3YXlzIHRoYXQg bG9hZCBiYWxhbmNpbmcgY2FuIGFuZA0KPj53aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu dGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlDQo+PiA+Pm1v cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJl IGlzIHRvIHBlcm1pdCBhbGwgb2YNCj4+ID4+dGhlc2UsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBiZSB1c2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBi YWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQNCj4+ID4+dXNlci4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2Vp dmVzIHVzZXINCj4+cGFja2V0cywNCj4+ID4+YW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1v ZGlmaWVzIHRoZW0gKG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vydmlj ZQ0KPj4gPj5pbnN0YW5jZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1 c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50DQo+PiA+PnNlcnZpY2UNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2Ug Y2hhaW5pbmcuDQo+PiA+Pkl0J3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5 IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4+ID4+IGNoYWluaW5nIGlzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0 IG9uIHRoZQ0KPj4gPj5hcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEZyb20g YW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGENCj4+ID4+ID4+PiA+ PiA+Pj4+PiBzZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHdoaWNoIG1h eSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2lu Zy4gVGhhdCBpcywgb25lDQo+PmNhbg0KPj4gPj5oYXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHdoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcHBlYXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZQ0KPj5wb2lu dA0KPj4gPj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gZm9yIGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5j dGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZA0KPj4gPj5ieSBhDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gY29sbGVjdGlvbiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXJ0dWFsIG9yIHBo eXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcNCj4+b25lIG9yDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZS UlAtbGlrZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFD IGFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNp YmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCj4+ID4+bWVjaGFuaXNtcy4N Cj4+ID4+IEl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZp c2libGUgdG8gdmFyaW91cyBjb250cm9sDQo+PiA+Pm1lY2hhbmlzbXMsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWluLCBzY2FsZS1v dXQsDQo+PmFuZA0KPj4gPj52bQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9u LiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4+cGVybWl0dGluZw0KPj4gPj50aGlzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVm dWwgdGhhdCBvdXINCj4+ID4+dGVybWlub2xvZ3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9l cyBub3QgbGVhZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJh bGFuY2luZyBkb25lIGJ5DQo+PnNlbGVjdGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYWNr ZXQgcGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0DQo+PiA+PnRyYWZm aWMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ugd291bGQg bm90IHdhbnQgdG8gcmVxdWlyZQ0KPj4gdGhhdA0KPj4gPj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lIHBsYWNlIGluDQo+ PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhh dCB0aGVzZSBtYXkgYmUNCj4+Y29tYmluZWQuIEkNCj4+ID4+IHRlbmQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNl DQo+PiA+PmNoYWluaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50 IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3Rlcg0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90 aGVyIG9uZS4NCj4+IFRodXMsDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9p bnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMg dG8gZGlmZmVyZW50DQo+PiA+PnNpbmd1bGFyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9yIGNs dXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzDQo+PmluDQo+PiA+ PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8g SSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2Ug Y2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhDQo+PiA+PiBzZXF1ZW5j ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBs aWVkIHRvIGEgc3Vic2V0IG9mDQo+PiA+PnBhY2tldHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YNCj4+dHJhZmZp Yw0KPj4gPj5pcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywg Y29udGVudCBpbnNwZWN0aW9uLCBhbmQNCj4+ZmlyZXdhbGwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvIHRoZQ0KPj5j YWNoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRp b24gdG8gZGlyZWN0IHRoZQ0KPj5wYWNrZXRzLg0KPj4gQQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZg0KPj4gPj5s b2NhdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3NlIGxv Y2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0 ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleQ0KPj4gPj5tYXkg YmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkg bWF5IGJlIGFkZHJlc3NlZCBhcw0KPj4gcG9ydHMNCj4+ID4+IG9uDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ ID4+bG9jYXRpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUg c2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZQ0KPj4gYW5kDQo+PiA+PiB0aGUNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBv ZiB0aGUgU0ZDDQo+Pmdyb3VwLA0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5l ZWQgdG8gYmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBo aWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUNCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0 bw0KPj4gdGFsaw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEg cGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0 d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2 ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlDQo+PiBwYXRoDQo+ PiA+PiBtYXkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9u dC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzDQo+PiA+PndpdGgNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIp DQo+Pm9uDQo+PiA+PmxvYWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3Zl LCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZA0KPj5iZWhhdmlvcnMNCj4+ID4+IHdoaWNoDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5p bmcgbWVjaGFuaXNtcyAoaW4NCj4+ID4+bXVjaA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUg c2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBUaGUgb3Ro ZXINCj4+IHByb3Zpc2lvbg0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFrZSBp cw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVjbGFz c2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPj4gPj4gbmVjZXNzYXJ5 Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBu ZXcgY2hhaW4uIEJhc2VkIG9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGF2 YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24NCj4+cG9pbnQuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMg ZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4NCj4+SWYgaXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUgd29ya2luZw0K Pj4gPj4gZ3JvdXAsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdo YXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkDQo+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUN Cj4+ID4+IGludGVudCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNv dXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcNCj4+ID4+Z3JvdXANCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5v dCBzdXJlDQo+PiA+PndoYXQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2Vs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+ PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMNCj4+ID4+ID4+PiA+ PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IHNmYw0KPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4g Pj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBs aXN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBsaXN0DQo+PiA+ PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+IHNm YyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4g Pj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPnNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+ID4+Pg0KPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+DQo+PiA+PiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0 DQo+PiA+PiA+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCg== --_000_B8F9A780D330094D99AF023C5877DABA845828FCnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4w cHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi 5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4YWN0bHksIGl0IHNob3Vs ZCBiZSDigJ1zZXJ2aWNlIGNoYWluIGlkZW50aWZpZXLigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5taWtlYmlhbmNAYW9sLmNvbTxicj4NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8 c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTI8L3NwYW4+ 5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAyOjQ2PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGpndWljaGFyQGNp c2NvLmNvbTsgbW4xOTIxQGF0dC5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGpt aEBqb2VsaGFscGVybi5jb207IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb207IHNmY0Bp ZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+V291bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICZxdW90O3NlcnZpY2UgY2hhaW4gaWRl bnRpZmllciZxdW90OyB0aGVuPyAmbmJzcDtJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3Jk ZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0 IG9mIFNGIGluc3RhbmNlcywNCiB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICZxdW90O3NlcnZp Y2UgcGF0aCBpZGVudGlmaWVyJnF1b3Q7IHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2Vy dmljZSAqcGF0aCosIG5vdCBhIHNlcnZpY2UgKmNoYWluKi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KQWdhaW4sIEkgdGhpbmsgdGhp cyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGluLiAmbmJzcDtUaGUgdGVy bXMgJnF1b3Q7Y2hhaW4mcXVvdDsgYW5kICZxdW90O3BhdGgmcXVvdDsgc2VlbSBpbmNvbnNpc3Rl bnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdDt0ZXh0LWFsaWdu OmNlbnRlciI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUi IG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVO LVVTIj48YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb20mbHQ7amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+ DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFu Y0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxQGF0dC5jb20lM2UsbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Usam1o QGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2Zj QGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5taWtlYmlhbmNAYW9sLmNvbSZsdDttaWtlYmlhbmNA YW9sLmNvbSZndDssbW4xOTIxQGF0dC5jb20mbHQ7bW4xOTIxQGF0dC5jb20mZ3Q7LG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20mbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDss am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyxSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20m Z3Q7LHNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwv Yj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYu NzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBhdGgg aXMgY29ycmVjdCBhcyBpdHMgdGhlIGZvcndhcmRpbmcgcGF0aCB0aHJvdWdoIHdoaWNoIHRyYWZm aWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaG93ZXZl ciBwb2ludHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1cmUNCiBhbmQgdGhhdCBp cyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5l eHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMgYXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIgbG9h ZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluIHBsYXkuIFdoZW4gaW5zdGFudGlhdGluZyB0 aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1cGRh dGUgdGhhdCBkYXRhIHN0cnVjdHVyZQ0KIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBi ZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3b3VsZCBlZmZlY3RpdmVseSBuYWlsIHVw IHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1w bHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvIG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0aGUg ZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTTxicj4NCjxi PlRvOiA8L2I+SmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1u MTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssICZxdW90 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29t PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBq b2VsaGFscGVybi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+ JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB0aGluayB0aGlzIGlzIHRoZSByb290 IG9mIHRoZSBjb25mdXNpb246PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZndDsgSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTxicj4NCiZndDsgc3BlY2lm aWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJl b2YpLiBJPGJyPg0KJmd0OyBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDi gJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8YnI+DQomZ3Q7IGFu ZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KPGJyPg0KQnkgZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgJnF1b3Q7c2Vy dmljZSBwYXRoJnF1b3Q7IHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBpbnN0 YW5jZXMuIEluIHRoZSBzdGF0ZW1lbnQgYWJvdmUsIHlvdSB1c2UgYSAmcXVvdDtzZXJ2aWNlIHBh dGggaWRlbnRpZmllciZxdW90OyB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNw ZWNpZmljYWxseSAmcXVvdDtbZG9lcyBub3RdIHNwZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzJnF1 b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIi IHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8 YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+ Jmd0Ozxicj4NCjxiPlRvOiA8L2I+TkFQSUVSQUxBLCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0 bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ Jmd0OyxSb24NCiBQYXJrZXImbHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Oyw8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9i PkZyaWRheSwgSnVseSAxMSwgMjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpNYXJpYSw8 YnI+DQo8YnI+DQpJIHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgaXMgc2ltcGx5IGEgcG9pbnRlciB0bzxicj4NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBj b250YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGE8YnI+DQpj aGFpbiwgbGV04oCZcyBzYXkgUzEgLSZndDtTMi0mZ3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNy ZWF0aW5nIHRoZSBTRlAgc3BlY2lmeTxicj4NCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5 b3Ugd2FudCB0cmFmZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZl ciwgeW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3Rh bmRwb2ludCAoSTxicj4NCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZ dCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24g YSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBwb2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+ DQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZG IGl0IHdpbGwgaGF2ZSBhPGJyPg0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBp bmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFp bGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVh cm48YnI+DQp0aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVt IGRvd24gZnJvbSBhIGNlbnRyYWxpemVkPGJyPg0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0g dGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaDxicj4NCnNvbWUgcHJv dG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3Jy ZWN0IHRvPGJyPg0Kc2F5IHRoYXQgdGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBp bnN0YW5jZXMgYXJlIGNob3NlbiBhIHByaW9yaTxicj4NCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3Rs eSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvPGJyPg0K c28uPGJyPg0KPGJyPg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2Ug dGhpcyBjbGVhcjo8YnI+DQo8YnI+DQpJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8g aXQgYXMgU0ZDLTEpIFMxLSZndDtTMi0mZ3Q7UzMuIEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxl dOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdh bnQgdG8gc3BlY2lmeTxicj4NCnNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAo b3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSTxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1My LSZndDtTMzxicj4NCmFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQg dGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlPGJyPg0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZv cm1hdGlvbi4gTm93IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlczxicj4NCndp dGggc2VydmljZSBwYXRoIGlkZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVw IGluIHRoZSBkYXRhPGJyPg0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMx LSZndDtTMi0mZ3Q7UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDPGJyPg0KZW5jYXBzdWxhdGlv biB3aWxsIHRlbGwgaXQgZXhhY3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMg c2F5IHdlPGJyPg0KYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZl IHRvIHJlc29sdmUgdGhlIG5leHQtaG9wIHRvPGJyPg0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAg dG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0 LCAxMToyNiBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KJmd0O0ppbSw8YnI+DQomZ3Q7PGJyPg0KJmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdoYXQg aXMgdGhlIGRlZmluaXRpb24gb2YgYSAmcXVvdDtzZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8YnI+ DQomZ3Q7JnF1b3Q7c2VydmljZSBwYXRoIGlkZW50aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lmIGEg c2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlv cmkgKHdoaWNoPGJyPg0KJmd0O2lzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBp cyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZGIHRv IHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDtN YXJpYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyA8YnI+DQo8YnI+DQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKSBbPGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpndWlj aGFyQGNpc2NvLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAy MDE0IDExOjE1IEFNPGJyPg0KJmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+OyBKb2VsIE0uPGJyPg0KJmd0OyZndDsgSGFscGVybjsgUm9uIFBhcmtl cjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEnigJltIHNvcnJ5IGJ1dCBJ IHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXI8 YnI+DQomZ3Q7Jmd0OyBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMg b3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgY2hhaW4gaWRlbnRpZmll ciBtYWtlcyBhbnkgZGlmZmVyZW5jZT88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiA3 LzExLzE0LCAxMDo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgJmd0O0RpdHRvLjxicj4NCiZndDsmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+XTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFBhcmtlcjsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Rm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkg aW4gdGhlPGJyPg0KJmd0OyZndDtkcmFmdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGlu IGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZGlzdHJp YnV0ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtb2RlbCBpcyBub3QgYWxsb3dlZC48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNldmVyYWwgdm9pY2VzIGlu IHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7c2hvdWxkIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlk ZWQgaW5zdGVhZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDstLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RGUgOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEg cGFydCBkZSBKaW0gR3VpY2hhcmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7KGpndWljaGFy KTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtFbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxl dCAyMDE0IDE2OjE4PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O8OAIDogTkFQSUVSQUxBLCBN QVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtP YmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVu Y3Rpb25hbGl0eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9oaWJpdGVkPyBJZiB5b3Ug d2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0O3dpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQg dGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb29r dXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVh Y2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdDxicj4NCiZndDsmZ3Q7c3VyZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3RoZSBh cmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTEvMTQsIDk6NTggQU0sICZxdW90O05BUElF UkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5t bjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1dGVseS48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEpp bSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhqZ3VpY2hhcik8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDEx LCAyMDE0IDk6NTQgQU08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IE5B UElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoZW4gSSBtaXN1bmRlcnN0YW5k IHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3RoYXQgaWY8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgeW91 IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBp dDxicj4NCiZndDsmZ3Q7d2lsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Zm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWlu IHRoZW4geW91PGJyPg0KJmd0OyZndDtiZXR0ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21ha2U8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VyZSB0aGF0IHRoYXQgcmVtb3Rl IFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtyZWFjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFp biBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRyb3VibGUuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9u IDcvMTEvMTQsIDk6NDggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDtBYnNvbHV0ZWx5IG5v dC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluPGJyPg0KJmd0OyZn dDtyZWxldmFudDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NGRnM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O3doZW4gdGhleSAmcXVvdDthcnJpdmUm cXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTog c2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKaW08YnI+DQomZ3Q7Jmd0O0d1aWNoYXJk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7KGpndWljaGFyKTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgOToyNyBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVy c3Rvb2Q8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0O3Byb3Bvc2FsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2 ZXJ5IHNpbmdsZTxicj4NCiZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDt3aXRoaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZW50aXJlIFNG QyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG88YnI+DQom Z3Q7Jmd0O2tub3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtwcmlvcmk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBz ZXJ2aWNlIGF0IGFueSBnaXZlbjxicj4NCiZndDsmZ3Q7cG9pbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGltZS48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gNy8xMC8xNCwgMTE6NTMgUE0sICZxdW90O0pvZWwg TS4gSGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i PmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91 dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJvYmxlbTxicj4NCiZndDsmZ3Q7d2l0 aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7eW91cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBh ZG1pdCBJIG1heSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt1bmRlcnN0 YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpdC4p PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1RoZSBwcm9wb3NhbCBo YXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7bmV4dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0 IGRlbGl2ZXJzPGJyPg0KJmd0OyZndDt0byksPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJv dWdoIGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtTaW5jZSBp dCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zPGJy Pg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0O1NGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5k IHN0YXRlZnVsIGxvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtiYWxhbmNl ci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0kgYWh2 ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3I8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3N0YXRlZnVsLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUg dGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Zmxvdzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBz dGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7YWNjZXB0YWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7aW1wb3NpdGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7WW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O09u IDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFBhcnQgb2YgbXkgcGVyc29u YWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpczxicj4NCiZndDsmZ3Q7d29y azxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlbnNpYmx5PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIGEg bW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlPGJyPg0KJmd0 OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFi aWxpdGllcyw8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2JlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IG9yY2hlc3Ry YXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnM8YnI+DQomZ3Q7 Jmd0O3RvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZHJp dmVuIGJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJs ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3NlbGYtc2VsZWN0aW9uPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGZyb20gdGhl c2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3k8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2RyaXZlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBh biBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2J5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVk IHNlcnZpY2UgcGF0aHMuIEl0IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtoYXJkZXI8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRv bmUpIHdoZW4gd2UgYWxsb3cgbW9yZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBkeW5hbWljaXR5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCBt b3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O291dHNpZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzY29wZSBvZiB0aGUgd29ya2lu ZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3Rhc2tlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fn cmVlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 b24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYTxi cj4NCiZndDsmZ3Q7Y2VydGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dh eS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyBqdXN0IHRo ZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgT24gNy8xMC8xNCwgOTo1OCBQ TSwgSWFuIFNtaXRoIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlv biBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtuZWVkczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7dG88YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fjcm9zczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O2RhdGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwg aXMgbGFyZ2UgZW5vdWdoPGJyPg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgY29tcGxleDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBp bnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O2RpZmZpY3VsdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEknbSBjdXJpb3Vz IGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbjxicj4NCiZndDsmZ3Q7ZHlu YW1pYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyByb3V0aW5nLDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlwZXIt c2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2Y8YnI+DQomZ3Q7 Jmd0O3doaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtiaWdnZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHBy b2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBJdCBhbHNvIHNlZW1zIHRoYXQgaWYg aXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQ8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Z29v ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUgUE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRvOiBSb24gUGFya2VyOyBKb2VsIEhh bHBlcm4gRGlyZWN0OyA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPg0KbWlrZWJp YW5jQGFvbC5jb208L2E+Ozxicj4NCiZndDsmZ3Q7SWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7U21pdGg7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZDxicj4NCiZndDsmZ3Q7QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlz c3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZDxicj4NCiZndDsmZ3Q7cHJlZmVyPGJyPg0KJmd0OyZn dDsgJmd0OyZndDt3ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDthY3R1YWxseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxs b3cgYWxsIHBvc3NpYmxlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbXBsZW1lbnRhdGlvbnMuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBC ZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7cmVxdWlyZW1lbnRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRo ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgZnVuY3Rpb25hbGl0eSBvZiBTRkZzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1h dGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBuZWVkczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFu ZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuPGJyPg0KJmd0OyZndDsgYWNyb3NzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRt aW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Y29tcGxleDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5aW5n IHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZ b3Vycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDk6 MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1 ZS4gSXMgdGhlIGVuZCB0byBlbmQ8YnI+DQomZ3Q7Jmd0O3NlbGVjdGlvbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxs eSAocGVyaGFwcyBieSB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDtjbGFzc2lmaWVyKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNz aWZpZXIgYW5kIHN1YnNlcXVlbnRseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7U0ZGcyk/PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU3VjaCBzZWxl Y3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi48YnI+DQomZ3Q7Jmd0 O0FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3N1cmVseSw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGlz IGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmcXVv dDtpbXBsZW1lbnRhdGlvbiZxdW90Oy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE15IG93biB2aWV3IGlzIHRvIGZhdm9y IHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuPGJyPg0KJmd0OyZndDsgdGhvdWdoPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRl ZmluaXRpb25zIGFuZCBwZXJoYXBzPGJyPg0KJmd0OyZndDtsb2NhbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlbGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBvbGljeSkgaXMgcmVx dWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7VGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVu ZCBwYXRoIGlkIGF0IGFsbC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O015PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmF0aW9uYWxl IGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseSBkcml2ZW48YnI+DQomZ3Q7 Jmd0O2J5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW5jcmVh c2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0 aCBhPGJyPg0KJmd0OyZndDtnbG9iYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aWQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWx0ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkg YWZmZWN0ZWQ8YnI+DQomZ3Q7Jmd0O2VuZC10by1lbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDtwYXRoLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUm9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxm IG9mIEpvZWwgSGFscGVybiBEaXJlY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBbPGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT5dIFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDEwLDxicj4NCiZndDsmZ3Q7MjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IDY6MTU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgUE08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUbzogPGEg aHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxh IGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+DQpJLlNtaXRoQEY1LmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBT dWJqZWN0Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFJlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoZSBhcmNo aXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNGMSBuZWVkaW5nPGJyPg0KJmd0OyZndDt0bzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2luZmx1ZW5jZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0IHRoZTxi cj4NCiZndDsmZ3Q7ZXhpdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZnJvbTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNGMS48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9u czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9naWNhbGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2VwYXJhdGUgc28gdGhhdCBz b2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBjaG9vc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNv bXBvc2UgdGhlbSBmb3IgJnF1b3Q7c2VydmljZSZxdW90OyBkZWxpdmVyeS48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFlv dXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA2OjEwIFBNLCA8YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg SSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NvcnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBsaW1pdC4gSG93ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRl IHRoYXQgdGhlIGVudGlyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGF0aDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhhbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0ZJcykgbXVzdCBiZSBjaG9zZW4g YXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVsaWV2ZTxicj4NCiZndDsmZ3Q7dGhpczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O21lYW5zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVpdGhlciBhdCB0aGUg Y2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcjxicj4NCiZndDsmZ3Q7Y2hvb3NlcyBh PGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O0NoYWluPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0 aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdo ZXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU0ZJKG4pPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldGVybWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4g QWNjb3JkaW5nIHRvIHRoZSBkcmFmdCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAmcXVvdDticmFuY2hpbmcmcXVvdDsgdG8g YSBuZXcgU0ZQIGFzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG9wcG9zZWQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg Y2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2Y8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXh0LWhvcCBvZiB0aGUgY3VycmVu dCBTRkMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAw Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdv cmsgaXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25lY2Vzc2FyeTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZWxlY3QgdGhlIHNwZWNpZmljIGlu c3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDth bmQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBT RkMgdXNpbmcgU0Ynczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmV0d29yazxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Y3JlYXRpb248YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9m IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Zm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFja2V0cyB0aHJvdWdoIHRoZSBT RkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnN0YW50aWF0 aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgU0ZD IGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9uIChvcjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7bm9uLWluaXRpYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxs LiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRp b24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBhPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFz c2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ZnVuY3Rpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWNsYXNzaWZpY2F0aW9uIG1heSBy ZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U0ZQ LCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBi b3RoLiBUaGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZWZlcnJlZDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyAmcXVvdDticmFuY2hpbmcm cXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7LS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAqRnJvbTogPGEgaHJlZj0ibWFpbHRvOipJLlNtaXRoQEY1LmNvbSI+ KkkuU21pdGhARjUuY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPkku U21pdGhARjUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRvOiAqSm9lbCBIYWxwZXJuPGJyPg0KJmd0 OyZndDsgRGlyZWN0Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNv bSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxKb2VsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgTS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7SGFscGVybiZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5j YXJsZXRvbi5jYTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS4lMGIiPmh1YW5nQHNj ZS48YnI+DQo8L2E+Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNhcmxl dG9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0O2NhJmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqU2VudDogKlRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0JhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQ8 YnI+DQomZ3Q7Jmd0O3RoYXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3 aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2Ug Y2hhaW5zIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7cHJlY29uY2VpdmVk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVu ZWQgd2l0aDxicj4NCiZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJlY29uY2VwdGlvbi48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3Jl ZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXNwaXJhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3Bh biBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FyY2hpdGVjdHVyZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Oy08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgeW91IGRvbid0IGhhdmUgdG8ga25vdyB3 aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQgYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDthcmJpdHJhcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbnVtYmVyIGlzICZxdW90O3RvbyBmYXImcXVv dDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgaXNuJ3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbnRlbnRpb25hbDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIGEgbGltaXQg dGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7aW1wYWN0czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1p dGlnYXRpb24sIGVsYXN0aWNpdHksPGJyPg0KJmd0OyZndDsgJmd0OyZndDthZGRyZXNzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBu b3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIEhh bHBlcm4gRGlyZWN0IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20i PmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1Nl bnQ6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0 aDsgSm9lbCBNLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEhhbHBlcm47PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwv YT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1Ympl Y3Q6IFJlOiBbc2ZjXTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U2VydmljZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWFuLCBJIGRv bid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0aGlzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtyZWdhcmQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7STxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2FtPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5v dCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7cHJvaGliaXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGVwbG95bWVudHMgaW4gdGhlIHNwZWNp ZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDtIdWFu ZydzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxv eW1lbnRzIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHJlcXVpcmVkPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXkg YnkgdGhlIGFyY2h0aWVjdHVyZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQXMgSSBoYXZlIHNhaWQgcmVw ZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0PGJyPg0KJmd0OyZndDtzdWNoPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5k cyB1cG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFueTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmYWN0b3JzIG91dHNp ZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG88YnI+DQomZ3Q7Jmd0O3RoaW5r PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7dGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCdXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcg YXR0ZW1wdGluZyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7a25vdzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYW5kIGlzIG5vdCBlcGxveWFibGUu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAv MTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZGlzYWdyZWUuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNl cyB0aGF0IG1hbmFnZSB0ZW5zIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 bWlsbGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90 aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzIHRv ZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUgdGhhdCBpbjxicj4NCiZndDsmZ3Q7dGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJv dyB5b3U8YnI+DQomZ3Q7Jmd0OyBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGdvaW5nPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRv IGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHk8YnI+DQom Z3Q7Jmd0O3NtYWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG51bWJlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAmcXVvdDtubyBvbmUgd2lsbCBldmVyIG5lZWQg bW9yZTxicj4NCiZndDsmZ3Q7IHRoYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgNjRLJnF1b3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29tZm9ydC48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBGcm9tOiBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9m IEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2Uu Y2FybGV0b24uY2E8L2E+Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 TG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm8s IGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FyY2h0aWV0dXJlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0 aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZjxicj4NCiZndDsm Z3Q7dGhlaXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3Qg cmVxdWlyZSBzdWNoIGFic3VyZDxicj4NCiZndDsmZ3Q7IHVzZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJl IG91dCBob3cgdG8gd3JpdGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJv aGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmU8YnI+DQomZ3Q7Jmd0O2RvZXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwZXJtaXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Y2ggYWJ1c2UuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0 IHRoZSBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0OyBwZXJtaXRzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb21l dGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3 b3JrLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXNuJ3QuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91 cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA0OjM2IFBNLCBD aGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1 cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsPGJyPg0KJmd0OyZndDttZWFuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91 dGluZzxicj4NCiZndDsmZ3Q7dGFibGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29mIGE8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjb3JlIHJvdXRlci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IENoYW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0IDAx OjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBh cmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb208YnI+DQomZ3Q7 Jmd0OzE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNl IHBhdGhzLiBJIHdvdWxkIGhvcGU8YnI+DQomZ3Q7Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5PGJy Pg0KJmd0OyZndDsgJmd0OyZndDtjaG9vc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQg YmFsYW5jaW5nIGFuZCBpbiBzdGVhZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHByb3Zpc2lvbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwg TUFSSUEgSCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdWwsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IG1hbnkgcGF0aCBpZGVu dGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgaG9wPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMg YXQgZWFjaCBob3A/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgTWFyaWE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGY8YnI+DQomZ3Q7Jmd0OyBP Zjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZndDszOjAzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5IHlvbmcgKkNjOiogPGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpvZWxoYWxwZXJuLmNvbTwvYT47PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4g KlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZTxicj4NCiZndDsmZ3Q7IENoYWlucyw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5LDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE92ZXJhbGwgSSBjb25jdXIsIGFz IHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBm b3J3YXJkaW5nLiBJwrlkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBkZXJpdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBuZWVk ZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9y dCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvPGJyPg0KJmd0OyZndDtzaW1wbHk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBh Y2tldHM8YnI+DQomZ3Q7Jmd0O211c3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNl LiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9u PGJyPg0KJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJl IHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBp ZGVudGlmaWVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUg dGhhbiBhIGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcmVz dWx0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3 ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhvcChzKS48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDEw LCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2Vp LmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tJTNlIj5tYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7PC9hPiZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5k YXRlIG9ubHkgdXNlIG9mPGJyPg0KJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7YWN0aW9ucy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSpPbiI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbjwvYT4gQmVoYWxmPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqU2VudDoqVGh1cnNkYXksPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDEwLCAyMDE0IDI6MDYgQU0gKlRvOjxhIGhyZWY9Im1haWx0bzoqbWlrZWJp YW5jQGFvbC5jb20iPiptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxw ZXJuLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJmd0OztqbWhAam9lbGhhbHBlcm4uY29t PC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20m Z3Q7O3NmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1Ympl Y3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2Fs bHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG88YnI+DQomZ3Q7 Jmd0O2Rlcml2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBhY3Rpb25zLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVpcmlu ZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2Y8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBldmVyeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUgU0ZDPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMg bm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlcXVpcmVkL2p1c3RpZmllZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRkMgZm9yd2FyZGluZyBhY3Rp b25zIHNob3VsZCByZWx5IG9uIHRoZSBwaWVjZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aW5mb3JtYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi ZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lPGJyPg0KJmd0OyZn dDsgcmVxdWlyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlu ZmVyIGZvcndhcmRpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWN0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRGUgOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10qRGUiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGU8L2E+ IGxhIHBhcnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tIj5k ZSptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbTwv YT4mZ3Q7ICpFbnZvecOpIDoqbWVyY3JlZGkgOTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGp1aWxs ZXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTQgMjI6MDMgKsOAIDo8YSBocmVmPSJtYWls dG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKk9iamV0IDoqUmU6IFtzZmNd IFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0NoYWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhl IGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIFNGPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGg/PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRp b24gc28gdGhhdCBpdCdzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtjbGVhciB0bzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 aG9zZSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0 LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lPGJyPg0KJmd0OyZndDthZ3JlZXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O29uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVzZSB0ZXJtcy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUbyBtZSwgdGhlIG9u ZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXM8YnI+DQomZ3Q7Jmd0O3doZXRoZXI8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaW50 ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3RoZSBJRDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgdGhlIFNGQyBIZWFk ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgc2hvdWxkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlcmVuY2UgKHRo ZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50ZW5kcyB0byBsZWF2ZSB0aGF0 IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXI8YnI+DQomZ3Q7Jmd0O2RyYWZ0czxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpY3RhdGUgdGhlIG1lY2hh bmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW48YnI+DQomZ3Q7Jmd0OyBvcjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBwYXRoIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBuZWdvdGlhdGVkIGluIHRo ZSBjb250cm9sLXBsYW5lLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxk IGhhdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQg U0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9uZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8g YXZvaWQgc29tZTxicj4NCiZndDsmZ3Q7IHZlbmRvcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBv bmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9u bHkgc3VwcG9ydGluZyBTRkMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206PGEgaHJlZj0ibWFpbHRv OipqbWhAam9lbGhhbHBlcm4uY29tIj4qam1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mbHQ7PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UiPm1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSZndDs8L2E+Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRvOjxhIGhyZWY9Im1haWx0bzoqc2ZjQGlldGYu b3JnIj4qc2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUzZSI+bWFpbHRvOnNmY0BpZXRmLm9yZyUz Y3NmY0BpZXRmLm9yZyZndDs8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICpTZW50OipUdWVzZGF5LDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIw MTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kPGJyPg0KJmd0OyZn dDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhhdmUgYmVlbiB0cnlpbmcgdG8g ZmlndXJlIG91dCBob3cgdG8gY2xlYXJseTxicj4NCiZndDsmZ3Q7YW5zd2VyPGJyPg0KJmd0OyZn dDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBudW1iZXIgb2YgY29tbWVudHMg dGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgcHJvcG9zZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGll Y3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQ8YnI+DQomZ3Q7Jmd0OyB3b3JraW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ug d2lsbCB3b3JrIHRvPGJyPg0KJmd0OyZndDsgaW1wcm92ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hv IGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgV0c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc2N1c3Npb24g d2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ya2luZzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5kcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkg dG8gZXhwbGFpbiBteTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGVyc29uYWw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMg aW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxh bmUgYXJjaGl0ZWN0dXJlLiBXZTxicj4NCiZndDsmZ3Q7YXJlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUg YXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1 dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3M8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0 aW9ucyw8YnI+DQomZ3Q7Jmd0O3ZpcnR1YWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hp bmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgYXNwZWN0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBu ZWVkPGJyPg0KJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRo ZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGg8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2Fib3ZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGVyZSB3ZSBhcmU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZnVuY3Rpb25pbmcsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgYXJlIG5vdCBkaXJl Y3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyBkb2luZy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0 byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsPGJyPg0KJmd0OyZndDthcyBJ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2lu Zy4gVGhlcmUgYXJlIGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDtsZWFzdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4g YW5kPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcmFjdCB3 aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bW9yZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBwb2ludCBvZiB0aGUgYXJj aHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXNl LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBh cnRpY3VsYXIga2luZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSB1c2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp biBhbnkgc29sdXRpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBl bmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBU aGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlcjxicj4NCiZndDsmZ3Q7 cGFja2V0cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbW9kaWZpZXMgdGhlbSAob3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFya3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2U8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3RhbmNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBy ZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50PGJyPg0KJmd0OyZn dDsgJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBi ZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O0l0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVx dWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgY2hhaW5pbmcg aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUg aW1wYWN0IG9uIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXJjaHRpZWN0dXJlLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBp cyBzaW1wbHkgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5j dGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyKSBUaGVyZSBpcyBpbnRlcm5h bCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lPGJyPg0KJmd0OyZndDtjYW48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2hhdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoYXQ8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YXBwZWFyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcg YXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyPg0KJmd0OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRhY3Q8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9y IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1 dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2J5IGE8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY29sbGVjdGlvbiBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlydHVhbCBvciBwaHlz aWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nPGJyPg0KJmd0OyZndDtvbmUgb3I8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxl IHVzaW5nIFZSUlAtbGlrZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGVjaG5pcXVlcyB0byBz aGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJp b3VzIGNvbnRyb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21lY2hhbmlzbXMsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2Nh bGUtb3V0LCA8YnI+DQomZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dm08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFj dCBvZiA8YnI+DQomZ3Q7Jmd0O3Blcm1pdHRpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNh cmVmdWwgdGhhdCBvdXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rlcm1pbm9sb2d5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRlcnMgdG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxz byBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IDxicj4NCiZndDsmZ3Q7c2VsZWN0aW5nPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5n IHRoYXQgZGlyZWN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1 aXJlPGJyPg0KJmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUg cGxhY2UgaW4gPGJyPg0KJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdv cmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQg aXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2UgbWF5IGJlIDxicj4NCiZndDsmZ3Q7Y29t YmluZWQuIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0ZW5kPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNv bGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7Y2hhaW5pbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBv aW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3RlciA8YnI+DQomZ3Q7Jmd0O2lzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnb29kIHRlcm0u IEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuPGJyPg0KJmd0OyZndDsgVGh1 cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBv aW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyB0bzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVy ZW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaW5ndWxhcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMgPGJy Pg0KJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsg YWJvdXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2Ug cGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2VxdWVuY2U8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxp ZWQgdG8gYSBzdWJzZXQgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3BhY2tldHMuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vi c2V0IG9mIDxicj4NCiZndDsmZ3Q7dHJhZmZpYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3Bl Y3Rpb24sIGFuZCA8YnI+DQomZ3Q7Jmd0O2ZpcmV3YWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlIDxicj4N CiZndDsmZ3Q7Y2FjaGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1h dGlvbiB0byBkaXJlY3QgdGhlIDxicj4NCiZndDsmZ3Q7cGFja2V0cy48YnI+DQomZ3Q7Jmd0OyBB PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlv biwgYSBzZXF1ZW5jZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUg c2luZ3VsYXIgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1 bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5 IGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhl eSBtYXkgYmUgYWRkcmVzc2VkIGFzPGJyPg0KJmd0OyZndDsgcG9ydHM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW4gU0ZGLiBUaGVyZSBhcmUgbWFu eSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25z PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgaW5mcmFzdHJ1Y3R1cmU8YnI+DQomZ3Q7Jmd0OyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQg b2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIDxicj4NCiZndDsmZ3Q7Z3JvdXAsPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRv IGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2gg bGV2ZWwgYWJzdHJhY3Rpb24sIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2VydmljZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4g QW5kIHdlIG5lZWQgdG88YnI+DQomZ3Q7Jmd0OyB0YWxrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlk ICZxdW90O2J1dCB0aGUgd2hvbGU8YnI+DQomZ3Q7Jmd0OyBwYXRoPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgbWF5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgYmUga25vd24gYXQgdGhlIGZy b250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFsczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmly c3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIDxicj4NCiZndDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJhbGFuY2VycyBhYm92ZSwgdGhl cmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyPg0KJmd0OyZndDtiZWhhdmlvcnM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB3aGljaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlzaWJs ZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bXVjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJp ZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlu dmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcjxicj4NCiZndDsmZ3Q7 IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBtYWtlIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xh c3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBuZWNlc3NhcnkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGly ZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIDxicj4N CiZndDsmZ3Q7cG9pbnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVy LiA8YnI+DQomZ3Q7Jmd0O0lmIGl0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzLCBhbmQg aWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgZ3JvdXAsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91 dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZDxicj4NCiZndDsmZ3Q7IHRvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlz YWdyZWUgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbnRlbnQsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUg d29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Z3JvdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2hhdCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5 IG5leHQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg WW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBs aXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gJmx0Ozxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNmYzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlz dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNm Yzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDtzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNm YyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjPC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA845828FCnkgeml501mbschi_-- From nobody Sun Jul 13 23:29:19 2014 Return-Path: <smkumar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229DA1A0314 for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 23:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 7k2W4xn1GQku for <sfc@ietfa.amsl.com>; Sun, 13 Jul 2014 23:29:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07841A0312 for <sfc@ietf.org>; Sun, 13 Jul 2014 23:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8303; q=dns/txt; s=iport; t=1405319354; x=1406528954; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CRdb15ARoiWmwVQryFlaBTI43eUpKvZGtaXXl7ima6s=; b=Z3gDK/5ly2EJeXpUr3mUVweO1Y7rxvr1DFFfPg88GVX5gNm+jpJnzAVv 8Qa7rxlgAileaeWiZpwirDV4wBOvwtX82oN0njtveTReqpNERLRM7lNPU Dz9WD3nQjWqKbOTwoNcZhmDrsYiruji/XfZt6CW2+I5nq7UxawTE5VYhE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAA54w1OtJV2T/2dsb2JhbABPCoMOUlrBOwqHQwGBFRZ1hAMBAQEEAQEBCywrCRcEAgEIEQEDAQEBHgkHJwsUAwYIAgQBEhuIJw3HCBMEjm8FXgaEPQWWc4Qbi2qIM4NEgW9B X-IronPort-AV: E=Sophos;i="5.01,656,1400025600"; d="scan'208";a="339560760" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jul 2014 06:29:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6E6TCve023719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 06:29:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.251]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 01:29:12 -0500 From: "Surendra Kumar (smkumar)" <smkumar@cisco.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8U9/X8IoHsa0W7snejDHkJF5uYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHfAIAAA6OAgAACOACAAB3pgIAAoFSAgAAF84CAAAIIgIAAA1sAgAACzACAAArlAIAABJ8AgAANqQCAAAUJgIADnHsA Date: Mon, 14 Jul 2014 06:29:11 +0000 Message-ID: <CFE8BF2D.4BD67%smkumar@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BFECE5.8080207@joelhalpern.com> <53BFF20E.60900@joelhalpern.com> <53BFFF12.4060700@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AE5A@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C00EC1.9040502@joelhalpern.com> In-Reply-To: <53C00EC1.9040502@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.91.86] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F78C691FCD2D3478855EE85E25CEA0B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vWEhtcteCP65_TcBd9D3gMPoPaI Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 06:29:17 -0000 Well stated. Architecturally, it (SFC vs. SFP) is a very good abstraction to bake in. In the simplest case, an SFC may map 1:1 to an SFP and that is fine. However, this should not limit implementation flexibility that can be had by providing a level of indirection between SFC and SFP. Implementations can then exploit this indirection to suit the use cases while conforming to the architecture. As a *simplistic* example, a given service chain may be instantiated with a different SFP at each classifier (assume there is no SFP explosion). This serves to identify where classification was performed or where SFC is originated. Similar effect can be achieved in other ways as well but implementations are provided a choice. Surendra. On 7/11/14 9:20 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote: >If one declares that every SFC is realized by only one SFP (i.e each >service chain is always realized by only one directive to the network >forwarders, which then make choices based on that directive), then >indeed the SFP does not add value. I would call what results from such >an equivalence and SFP, but if we were to accept such a limit, we could >call it either one. > >However, we also indicated we want to allow a degree of central >arbitrarition and central control of traffic distribution. So we need a >layer of indirection to represent that. The SFP represents the decision >by the control plane and entry as to which initial subset is to be used. > This does not prevent there from being further load balancing (as >discussed in the emails) within that envelop. > >If there is no SFP distinct from the SFC then there is no envelop. > >Yours, >Joel > >On 7/11/14, 12:02 PM, NAPIERALA, MARIA H wrote: >> Joel, >> >> I saw your latest e-mail but I am responding to this one because it is >>more comprehensive. >> >> I have a hard time understanding why an SFF will not have ability to >>resolve an SFC to the set of next SFFs. Then what kind of "forwarder" is >>it if it cannot deal with next-hops. >> Second, if we do it as you suggest, what is the definition of a service >>path and why it is even needed? For me a service path is more of an >>abstract concept that is meant to denote one actual path (among many) >>that a service chain traffic will take. >> >> Maria >> >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>Direct >>> Sent: Friday, July 11, 2014 11:13 AM >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Jim Guichard (jguichar); Ron >>> Parker; sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> In order to allow for SFFs which do not have ability to resolve an SFC >>> to the set of next SFFs, we need to do one level of mapping from the >>> abstract SFC to the more resolved SFP. >>> In addition to allowing for a range of SFF deployments, this also >>>allows >>> for a degree of centralized traffic control to be used in conjunction >>> with the distributed behavior you are requesting. If we only used an >>> identifier of the service chain in the packet we would be prohibiting >>> that important alternative deployment. >>> >>> The SFF still has the ability to map the SFP to the transport >>> information, which allows it to have a collection of next SFFs which it >>> uses for redundancy or load balancing. >>> >>> If we structure it this way, we can allow the SFF to have a collection >>> of next-SFFs for a given SFP. And we can allow it to pick one, or to >>> balance as it chooses subject to the constraint that a given flow must >>> continue to use a given next-SFF as long as that is available. >>> >>> If we write it that way, the architecture will not mandate full load >>> balancing. It will allow that a given SFF uses a single next-SFF hope. >>> Or that it does whatever degree of load balncing it chooses among >>>the >>> set of next-SFF it is aware of for use with a given service path (SFP). >>> Whether that knowledge of next-SFFs is static or dynamic, >>>provisioned >>> or discovered, is outside the scope of the architecture, and probably >>> outside the scope of any solution this WG develops. >>> >>> Can you live with this compromise? >>> (If so, and if the WG is comfortable with this, Carlos and I can add >>> this to the slides for presentation in Toronto, and then add text to >>>the >>> next version of the document.) >>> >>> Yours, >>> Joel >>> >>> On 7/11/14, 10:56 AM, NAPIERALA, MARIA H wrote: >>>> >>>>> Just to check, I am going to get pedantic. >>>> >>>> NP >>>> >>>>> We have SFF-X, is supporting (possibly via local load balancing) some >>>>> collection of local service function instances. >>>>> When packets on a given service function path (SFP-Y) arrive, they >>>>>are >>>>> processed by theose service functions, and SFF-X then has to forward >>>>>the >>>>> packets (with suitable transport) to a next SFF, who may locally >>>>>balance >>>>> among his service function instances. >>>> >>>> Similar comment to Med's (I will use his expression as it does >>>>reflect it >>> correctly): "if packets bound to a given Service Function Chain >>>arrive", etc. >>>> This applies to the text below also. >>>> >>>>> For SFF-X handling SFP-Y, the next SFF is (possibly generically) >>>>>SFF-Z. >>>>> >>>>> We consider first the state at time T0 when a packet arrives as >>>>>SFF-X on >>>>> SFP-Y with no prior special state in SFF-X (obviously, there is some >>>>> state about SFP-Y, as we do not want policy lookups at packet >>>>>handling >>>>> times.) At this time T0, there exist in the network SFF-Z1 and >>>>>SFF-Z2. >>>>> If I understand your request, you want SFF-X to pick one of >>>>>those two >>>>> SFF, say SFF-Z1. >>>> >>>> Yes. >>>> >>>>> And send all the packets for SFP-Y on to SFF-Z1. Even >>>> >>>> This could be per-destination load balancing, for example, to get a >>>>better >>> load distribution. >>>> >>>>> if SFF-Z3 is added to the network, all packets for all flows using >>>>>SFP-Y >>>>> at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1. The only >>>> >>>> Existing flows go to SFF-Z1. New flows may go to SFF-Z3. >>>> >>>>> time SFF-X would change that is if discovered or was told that SFF-Z1 >>>>> was down or unreachable. In that case, it would pick a new one from >>>>> among the known choices. >>>> >>>> Yes. >>>> >>>>> Maria, if that is what you would like, I believe that either is >>>>> currently allowed by the architecture or can easily be added. And I >>>>>am >>>>> happy to do so. I believe we can describe that in the resilience and >>>>> failure recovery section that we need to add. >>>> >>>> OK. >>>> >>>>> But I want to be really sure that is what you want. I don't think >>>>>that >>>>> meets Ron's request. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/11/14, 10:07 AM, NAPIERALA, MARIA H wrote: >>>>>> Joel, >>>>>> >>>>>>> Hmm. Would it meet your goals Maria if all packets that arrived at >>>>>>> SFF-X with SFP-Y were (after local SF processing) forwarded to some >>>>>>> specific SFF-Z? Where SFF-Z was selected when the first packet >>>>>>>with >>>>>>> SFP-Y arrived at SFF-X? >>>>>> >>>>>> Yes. >>>>>>> >>>>>>> While that is more easily met, that does not seem likely to produce >>> the >>>>>>> scale flexibility you asked for. And if SFF-X may forward packets >>>>>>>with >>>>>> >>>>>> Why not? >>>>>> >>>>>>> SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have >>>>>>>the >>>>>>> capability to ensure that a given flow continues to go to the same >>> next >>>>>>> SFF even when SFF-Z3 is added to the mix. >>>>>> >>>>>> Precisely. >>>>>> >>>>>> >>>>>>> On 7/11/14, 9:48 AM, NAPIERALA, MARIA H wrote: >>>>>>>> Absolutely not. Service chains can be instantiated only in >>>>>>>>relevant >>> SFFs >>>>>>> when they "arrive". >>>>>>>> >>>>>>> ... >>>>>> >>> >>> _______________________________________________ >>> sfc mailing 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 Jul 14 05:47:27 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38701A03DA for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 15ZJJJoST2GM for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 05:47:11 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7211A03D7 for <sfc@ietf.org>; Mon, 14 Jul 2014 05:47:11 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 15AAB53E3B; Mon, 14 Jul 2014 05:47:06 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 05:47:05.962 -0700 x-echoworx-msg-id: 8484c952-f50c-426b-a270-379ca7433b76 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 828; Mon, 14 Jul 2014 05:47:05 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id C7C6253E3B; Mon, 14 Jul 2014 05:47:05 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 05:47:11 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mn1921@att.com" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPnxPwyzuGCqEbZEOLLO5CYOxADJuff48Q Date: Mon, 14 Jul 2014 12:47:10 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7CMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9SeUcpx0wQ_1bD1SCIOxWXYJCG8 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 12:47:23 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7CMBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WGlhb2h1LA0KDQpUaGUgbWVhbmluZyBvZiB0aGUgU0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQg bGVhc3QgdG8gbWUg4oCTIGFuIGFic3RyYWN0IGlkZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9m IHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIChpLmUuLCBTRlAgSUQgMSA9IHtTRi1BLTEsIFNG LUItMywgU0YtQy0yfSkuICAgIEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFi ZWwgc3RhY2vigJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVl bmNlIG9mIG5ldHdvcmsgbG9jYXRpb25zLiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxl YXN0IHRvIG1lLCB0aGF0IHRoZXJlIGlzIGEgY2VudHJhbCBwb2ludCBvZiBzZWxlY3Rpb24gZm9y IHRoaXMgZW5kIHRvIGVuZCBzZXF1ZW5jZSAoYmFycmluZyByZWNsYXNzaWZpY2F0aW9uLCBvZiBj b3Vyc2UpLiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQgaW1wbGljYXRpb24uICAg IEkgaGF2ZSBiZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRyYWwgcG9pbnQgbWV0aG9k b2xvZ3kgZHVlIHRvIHJlYWwtd29ybGQgY29tcGxleGl0aWVzIG9mIGR5bmFtaWMgc2NhbGUgYW5k IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMuDQoNCkFuIGFsdGVybmF0aXZlIGFw cHJvYWNoIGlzIHRvIHN0aWxsIHVzZSBjZW50cmFsIHNlbGVjdGlvbiB0byBzZWxlY3QgdGhlIGNo YWluIG9mIGFic3RyYWN0IHNlcnZpY2UgZnVuY3Rpb25zIChpLmUuLCBTRkMgSUQgMSA9IHtTRi1B LCBTRi1CLCBTRi1DfSksIGJ1dCBhbGxvdyB0aGUgYWN0dWFsIGluc3RhbmNlIHNlbGVjdGlvbiB0 byBiZSBkaXN0cmlidXRlZCwgcmVhbGl6ZWQgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkZz Lg0KDQpHaXZlbiBhIHRvcG9sb2d5IGxpa2U6DQoNCkNsYXNzaWZpZXIgLS0tLS0tLSAgU0ZGLTEg LS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTMtLS0t LS0tLS0tLS0tLS0tLS0tU0ZGLTQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICBTRkYtQS0xICAgICAgIFNGRi1BLTIg ICAgICAgU1NGLUItMSAgICAgICAgU0ZGLUItMiAgICAgICAgIFNGRi1DLTEgICAgICAgU0ZGLUMt MiAgICAgICAgICAgICAgICAgICBTRkYtQS0zDQoNCkFuZCBhc3N1bWluZyBhIG5ld2x5IHJlY29n bml6ZWQgZmxvdywgdGhlIHNlcXVlbmNlIGNvdWxkIGdvIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoN CjEgQ2xhc3NpZmllciBzZWxlY3RzIGNoYWluIFNGQyBJRCAxIHtTRi1BLCBTRi1CLCBTRi1DfQ0K MiBDbGFzc2lmaWVyIHNlbGVjdHMgU0ZGLTEgYXMgaG9zdGluZyBhdCBsZWFzdCBvbmUgaW5zdGFu Y2Ugb2YgU0YtQQ0KMyBDbGFzc2lmaWVyIGVuY2Fwc3VsYXRlcyBwYWNrZXQgaW5kaWNhdGluZyBj aGFpbiBJRCA9IDEsIHNlcnZpY2UgaW5kZXggPSAxDQo0IENsYXNzaWZpZXIgcHJvZ3Jlc3NlcyBw YWNrZXQgdG8gU0ZGLTENCjUgU0ZGLTEsIHNlZWluZyBjaGFpbiBJRD0xLCBzZXJ2aWNlIGluZGV4 PTEsIGNob29zZXMgU0ZGLUEtMiBhbW9uZ3N0IGl0cyBhdmFpbGFibGUgaW5zdGFuY2VzIG9mIFNG LUENCjYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTENCjcgU0ZGLUEtMSBzZW5kcyBwYWNr ZXQgYmFjayB0byBTRkYtMQ0KOCBTRkYtMSBpbmNyZW1lbnRzIHNlcnZpY2UgaW5kZXggdG8gMg0K OCBTRkYtMSBzZWxlY3RzIFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9m IFNGLUINCjkgU0ZGLTEgcHJvZ3Jlc3NlcyBwYWNrZXQgdG8gU0ZGLTINCjEwIHByb2Nlc3MgcmVw ZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMsIGFzIHRoZSBlZ3Jlc3MgYm9yZGVyLCBwcm9ncmVz c2VzIHRoZSBwYWNrZXQgcGVyIHJvdXRpbmcgdGFibGUNCg0KVGhhbmtzLg0KDQoNCiAgIFJvbg0K DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg WHV4aWFvaHUNClNlbnQ6IFN1bmRheSwgSnVseSAxMywgMjAxNCAxMTozMCBQTQ0KVG86IG1pa2Vi aWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207IG1uMTkyMUBhdHQuY29tOyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBSb24gUGFya2VyOyBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQoNCkFncmVlIHRoYXQgdGhlIGN1 cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGluIHRoZSBhcmNoIGRyYWZ0IGlzIGEgYml0IGNv bmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBoYWQgcG9pbnRlZCBvdXQuDQoNCg0KDQpJbiBteSB1 bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRo ZSBuZXR3b3JrIHNob3VsZCBiZSDigJxhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBh bmQgU0YgSURz4oCdKHNlZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJp bmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxKS4gT2YgY291cnNlLCBob3cgdG8gcmVwcmVzZW50IHRo ZSBTRlAgaW4gdGhlIGRhdGEgcGFja2V0IGlzIGFub3RoZXIgdGhpbmcgKGUuZy4sIGVpdGhlciB0 aHJvdWdoIGEgcGF0aCBpZCBvciB0aHJvdWdoIGFuIE1QTFMgbGFiZWwgc3RhY2spLiBIZXJlIHRo ZSBzZXJ2aWNlIG5vZGUgbWVhbnMgdGhlIGRldmljZSB3aGljaCBjb250YWlucyB0aGUgU0ZGIGFu ZCB0aGUgTkYgY29tcG9uZW50cyBtYW5kYXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBh bmQgU0YgcHJveHkgY29tcG9uZW50cyBvcHRpb25hbGx5LiBUaGUgc2VydmljZSBub2RlIGNvdWxk IGJlIGF0dGFjaGVkIG9yIGVtYmVkZGVkIHdpdGggbXVsdGlwbGUgU0YgaW5zdGFuY2VzIGFuZCB0 aG9zZSBTRiBpbnN0YW5jZXMgY291bGQgYmUgb2YgdGhlIHNhbWUgU0YgdHlwZSBvciBub3QuICBJ biB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBz YW1lIFNGIHR5cGUgKGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdpdmVuIHNlcnZpY2Ug bm9kZSwgdGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBkaXN0cmlidXRlIHRoZSB0cmFmZmljIHdoaWNo IG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzIG9mIFNGIFggdHlwZSBsb2NhbGx5 LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzIHdpdGhpbiBh IGdpdmVuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3IgYXR0YWNoZWQg d2l0aCB0aGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5LCB0 aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZSB2ZXJ5IGZsZXhpYmxlLg0KDQoNCkJl c3QgcmVnYXJkcywNCg0KWGlhb2h1DQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20+DQpTZW50OiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2IEFNDQpUbzogamd1 aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNv bTxtYWlsdG86bW4xOTIxQGF0dC5jb20+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgam1oQGpvZWxoYWxwZXJuLmNvbTxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+OyBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpXb3VsZG4ndCB0aGF0IGJlIGNhbGxlZCB0aGUg InNlcnZpY2UgY2hhaW4gaWRlbnRpZmllciIgdGhlbj8gIElmIHRoZSBzZXJ2aWNlIGNoYWluIGlz IHRoZSBvcmRlcmVkIGxpc3Qgb2YgU0ZzIGFuZCB0aGUgc2VydmljZSBwYXRoIGlzIHRoZSBvcmRl cmVkIGxpc3Qgb2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICJzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciIgd291bGQgYmUgYW4gaWRlbnRpZmllciBmb3IgYSBzZXJ2aWNl ICpwYXRoKiwgbm90IGEgc2VydmljZSAqY2hhaW4qLg0KDQpBZ2FpbiwgSSB0aGluayB0aGlzIGlz IHdoZXJlIHRoZSBjb25mdXNpb24ga2VlcHMgY3JlZXBpbmcgaW4uICBUaGUgdGVybXMgImNoYWlu IiBhbmQgInBhdGgiIHNlZW0gaW5jb25zaXN0ZW50Lg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogamd1aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNpc2NvLmNvbTxt YWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29tPj4NClRvOiBtaWtl YmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9sLmNvbT4sbW4xOTIxQGF0dC5jb208bW4xOTIxQGF0 dC5jb20+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4sam1oQGpvZWxoYWxwZXJuLmNvbTxqbWhAam9lbGhhbHBlcm4uY29tPixSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNjbWlr ZWJpYW5jQGFvbC5jb20lM2UsbW4xOTIxQGF0dC5jb20lM2NtbjE5MjFAYXR0LmNvbSUzZSxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTNjbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUz ZSxqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZSxSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tJTNjUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUz ZSxzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAy MDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCllvdXIgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBhdGggaXMgY29ycmVjdCBhcyBp dHMgdGhlIGZvcndhcmRpbmcgcGF0aCB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBhY3R1YWxs eSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaG93ZXZlciBwb2ludHMgdG8gdGhl IHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1cmUgYW5kIHRoYXQgaXMgdGhlbiByZXNvbHZlZCB0 byBzcGVjaWZpYyBpbnN0YW5jZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0LWhvcHMgdG8gdGhvc2Ug aW5zdGFuY2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRl Y2huaXF1ZSBpcyBpbiBwbGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4g aW50byB0aGUgbmV0d29yayB5b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1 Y3R1cmUgdG8gc3BlY2lmeSB3aGljaCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2lu Z2xlIG5leHQtaG9wIHdvdWxkIGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aCBm b3IgdGhhdCBzZXJ2aWNlIGNoYWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVy IHByb3RvY29sIC8gbWVjaGFuaXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZSBmb3Ig eW91Lg0KDQpGcm9tOiAibWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t PiIgPG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQpEYXRlOiBG cmlkYXksIEp1bHkgMTEsIDIwMTQgYXQgMTI6MTggUE0NClRvOiBKaW0gR3VpY2hhcmQgPGpndWlj aGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4sICJtbjE5MjFAYXR0LmNv bTxtYWlsdG86bW4xOTIxQGF0dC5jb20+IiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBh dHQuY29tPj4sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiwgImptaEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+LCAiUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWls dG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4iIDxSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sICJz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCg0KSSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRoZSBjb25m dXNpb246DQoNCj4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0KPiBzcGVjaWZpYyBpbnN0YW5j ZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRpb24gdGhlcmVvZikuIEkNCj4g YXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5 IHBvaW50cyB0byBTMS0+UzItPlMzDQo+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3 b3JrDQoNCkJ5IGRlZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICJzZXJ2aWNlIHBhdGgiIHRvIGJl IGFuIG9yZGVyZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIEluIHRoZSBzdGF0ZW1l bnQgYWJvdmUsIHlvdSB1c2UgYSAic2VydmljZSBwYXRoIGlkZW50aWZpZXIiIHRvIHJlZmVyIHRv IGEgc2VydmljZSAqY2hhaW4qIHRoYXQgc3BlY2lmaWNhbGx5ICJbZG9lcyBub3RdIHNwZWNpZnkg c3BlY2lmaWMgaW5zdGFuY2VzIi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjxqZ3Vp Y2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQpUbzogTkFQSUVSQUxB LCBNQVJJQSBIPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+PixKb2VsIE0uIEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+LFJvbiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+ DQpTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpNYXJpYSwNCg0KSSB0aGluayBv ZiBpdCB0aGlzIHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBv aW50ZXIgdG8NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBt YXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGENCmNoYWluLCBsZXTigJlzIHNheSBTMSAtPlMyLT4g UzMsIHlvdSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5DQp0aGUgc3BlY2lm aWMgbmV4dC1ob3BzIHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91Z2ggZm9yIHRo YXQgU0ZQLg0KSG93ZXZlciwgeW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFy Y2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSQ0Kd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0 IHlvdSBkb27igJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91DQpjb3VsZCBzaW1wbHkg YXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMg YW5kDQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUg U0ZGIGl0IHdpbGwgaGF2ZSBhDQpzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMgbWFwcGlu ZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4gdGhlDQpuZXh0LWhvcHMgYXZhaWxhYmxl IGZvciBlYWNoIG9mIHRoZSBTRuKAmXMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuDQp0 aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJv bSBhIGNlbnRyYWxpemVkDQpjb250cm9sbGVyLCBjb25maWd1cmUgdGhlbSB0aHJvdWdoIENMSSwg bGVhcm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoDQpzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3 aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bw0Kc2F5IHRoYXQg dGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBh IHByaW9yaQ0KYWx0aG91Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdv dWxkIHNheSByZWNvbW1lbmRlZCkgdG8gZG8NCnNvLg0KDQpMZXTigJlzIHRha2UgYW4gZXhhbXBs ZSB0byBob3BlZnVsbHkgbWFrZSB0aGlzIGNsZWFyOg0KDQpJIGRlZmluZSBhbiBTRkMgKGxldOKA mXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMxLT5TMi0+UzMuIEZvciBhcmd1bWVudHMNCnNha2Ug bGV04oCZcyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKAmXQg d2FudCB0byBzcGVjaWZ5DQpzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9y IHNvbWUgY29tYmluYXRpb24gdGhlcmVvZikuIEkNCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KYW5k IHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEgc3Ry dWN0dXJlcyBhcmUNCnBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBhdCBhIGdp dmVuIFNGRiwgd2hlbiB0cmFmZmljIGFycml2ZXMNCndpdGggc2VydmljZSBwYXRoIGlkZW50aWZp ZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhDQpzdHJ1Y3R1cmUg YW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5TMyBhbmQgdGhlIGluZGV4IGluIHRo ZSBTRkMNCmVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0IGV4YWN0bHkgd2hlcmUgaXQgaXMgaW4g dGhlIGNoYWluLiBMZXTigJlzIHNheSB3ZQ0KYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNG RiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9wIHRvDQpTMyBhbmQgd2lsbCBk byBhIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMgcmVhY2hhYmxlLg0KDQpPbiA3LzEx LzE0LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0 bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KDQo+SmltLA0KPg0KPkNvdWxkIHlvdSB0ZWxsIHVz IHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAic2VydmljZSBwYXRoIiBhbmQgYQ0KPiJzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciI/DQo+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwg U0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYXByaW9yaSAod2hpY2gNCj5pcyBteSBjdXJyZW50IHVu ZGVyc3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoDQo+ bmV4dC1ob3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uDQo+DQo+ TWFyaWENCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pg0KDQpGcm9tOiBK aW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+IFNl bnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTQ0KPj4gVG86IE5BUElFUkFMQSwgTUFS SUEgSDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT47IEpvZWwgTS4NCj4+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gSeKAmW0gc29ycnkgYnV0 IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmll cg0KPj4gcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBj YWxsaW5nIGl0IGEgc2VydmljZQ0KPj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVy ZW5jZT8NCj4+DQo+PiBPbiA3LzExLzE0LCAxMDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIg PG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPj4NCj4+ID5E aXR0by4NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9t OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0K Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+PiA+PiBUbzogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJu OyBSb24NCj4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+PiBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4+ID4+DQo+PiA+PiBSZS0sDQo+PiA+Pg0KPj4gPj4gRm9yIHdoYXQgSSBjYW4g c2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+PmRyYWZ0 Lg0KPj4gPj4NCj4+ID4+IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGlu IGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbA0KPj4gPj5kaXN0cmlidXRlZA0KPj4gPj4gbW9k ZWwgaXMgbm90IGFsbG93ZWQuDQo+PiA+Pg0KPj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0 aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4gaXRzZWxmDQo+PiA+PnNob3Vs ZCBiZQ0KPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4NCj4+ID4+DQo+PiA+PiBDaGVlcnMsDQo+PiA+ PiBNZWQNCj4+ID4+DQo+PiA+PiA+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiA+PiA+ RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0g R3VpY2hhcmQNCj4+ID4+ID4oamd1aWNoYXIpDQo+PiA+PiA+RW52b3nDqSA6IHZlbmRyZWRpIDEx IGp1aWxsZXQgMjAxNCAxNjoxOA0KPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2Vs IE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+PiA+DQo+PiA+PiA+T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRl Y3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eQ0KPj4gPj4gPnByb2hpYml0 ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4dC1ob3BzIHRvICphbGwqIFNG RuKAmXMNCj4+ID4+ID53aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRo IGlkZW50aWZpZXIgcG9pbnQgdG8gYQ0KPj4gPj5sb29rdXANCj4+ID4+ID5pbnRvIHRob3NlIG5l eHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+PnN1 cmUNCj4+ID4+aG93DQo+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPj4g Pj4gPg0KPj4gPj4gPk9uIDcvMTEvMTQsIDk6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxt bjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gd3JvdGU6DQo+PiA+PiA+ DQo+PiA+PiA+PkFic29sdXRlbHkuDQo+PiA+PiA+Pg0KPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gR3VpY2hhcmQNCj4+ID4+ID4+PihqZ3VpY2hhcikNCj4+ ID4+ID4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4gPj4gPj4+IFRv OiBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4NCj4+ ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIs IGl0IHNlZW1zIHRvIG1lDQo+PiA+PnRoYXQgaWYNCj4+ID4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZG IHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0DQo+PndpbGwNCj4+ ID4+dXNlDQo+PiA+PiA+Pj5mb3INCj4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhl IG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPj5iZXR0ZXINCj4+ID4+bWFrZQ0K Pj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9y d2FyZGluZyBsb2dpYyB0bw0KPj4gPj5yZWFjaA0KPj4gPj4gPj4+dGhlDQo+PiA+PiA+Pj4gbmV4 dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0cm91 YmxlLg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElFUkFM QSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQo+PiA+ PiB3cm90ZToNCj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID5BYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBj aGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluDQo+PnJlbGV2YW50DQo+PiA+PiA+Pj5T RkZzDQo+PiA+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4NCj4+ID4+ID4+PiA+DQo+PiA+PiA+ Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+PiA+PiBGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj5HdWljaGFy ZA0KPj4gPj4gPj4+ID4+KGpndWljaGFyKQ0KPj4gPj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVs eSAxMSwgMjAxNCA5OjI3IEFNDQo+PiA+PiA+Pj4gPj4gVG86IEpvZWwgTS4gSGFscGVybjsgUm9u IFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4g U3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3 b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2QNCj4+dGhlDQo+PiA+PiA+Pj4gPj5w cm9wb3NhbA0KPj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwg a25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZQ0KPj5TRg0KPj4gPj4gPj4+d2l0aGluDQo+PiA+PiA+ Pj4gPj50aGUNCj4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUg U0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0bw0KPj5rbm93DQo+PiA+PmENCj4+ID4+ID4+PiA+PnBy aW9yaQ0KPj4gPj4gPj4+ID4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8g c2VydmljZSBhdCBhbnkgZ2l2ZW4NCj4+cG9pbnQNCj4+ID4+aW4NCj4+ID4+ID4+PnRpbWUuDQo+ PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4g SGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ Pg0KPj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiA+Um9uLCB0aGlua2lu ZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3IgcHJvYmxlbQ0KPj53aXRoDQo+ PiA+PnRoZQ0KPj4gPj4gPj4+ID4+eW91cg0KPj4gPj4gPj4+ID4+ID5wcm9wb3NhbCBhcyBJIHVu ZGVyc3RhbmQgaXQuIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdA0KPj4gPj4gPj4+dW5k ZXJzdGFuZA0KPj4gPj4gPj4+ID4+ID5pdC4pDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZv ciB0aGUNCj4+ID4+bmV4dA0KPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9s bG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnMNCj4+dG8pLA0KPj4gPj5pbg0KPj4gPj4g Pj4+ZXZlcnkNCj4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBp dC4NCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxl IHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnMNCj4+ID4+dGhhdA0KPj4gPj4g Pj4+ID4+ZXZlcnkNCj4+ID4+ID4+PiA+PiA+U0ZGIHdvdWxkIGhhdmUgdG8gYmUgYSBmdWxsLCBm bG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPj4gPj4gPj4+YmFsYW5jZXIuDQo+PiA+ PiA+Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2 ZSwgYW5kIC8gb3INCj4+ID4+c3RhdGVmdWwuDQo+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhl IGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCwNCj4+ID4+Zmxv dw0KPj4gPj4gPj4+ID4+ID5zZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1z IHRvIG1lIHRvIGJlIGFuDQo+PiA+PmFjY2VwdGFibGUNCj4+ID4+ID4+PiA+PiA+aW1wb3NpdGlv bi4NCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPj4gPj4gPj4+ID4+ID5K b2VsDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwg Sm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkgcGVyc29u YWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcw0KPj53b3JrDQo+PiA+PiA+ Pj4gPj5zZW5zaWJseQ0KPj4gPj4gPj4+ID4+ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52 aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlDQo+PnNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+PiBm dW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsDQo+ PndpbGwNCj4+ID4+YmUNCj4+ID4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxl ZC4gSSBleHBlY3QgdGhlIHNlcnZpY2UgY2hhaW5zDQo+PnRvIGJlDQo+PiA+PiA+Pj4gPj5kcml2 ZW4gYnkNCj4+ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRv IGNsaWVudHMsIGFuZCBlbmFibGUNCj4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+PiA+PiA+Pj4g Pj4gPj4gZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBv bGljeQ0KPj4gPj5kcml2ZS4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IEkgY2Fu IHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZQ0KPj4g Pj5kcml2ZW4NCj4+ID4+ID4+PmJ5DQo+PiA+PiA+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNh dGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQgaXMNCj4+ID4+aGFyZGVyDQo+PiA+ PiA+Pj50bw0KPj4gPj4gPj4+ID4+c2VlDQo+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQg d29yayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmUNCj4+ID4+ID4+PiA+ PiBkeW5hbWljaXR5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsgYmVoYXZpb3IuDQo+ PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9m IHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXMNCj4+ID4+b3V0c2lkZQ0KPj4gPj4gPj4+ b2YNCj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+IHNjb3BlIG9mIHRoZSB3b3JraW5n IGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZQ0KPj4gPj50YXNrZWQgdG8NCj4+ID4+ ID4+PiA+PmFncmVlDQo+PiA+PiA+Pj4gPj4gPj5vbi4NCj4+ID4+ID4+PiA+PiA+PiBTbyBJIGRv IG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGENCj4+Y2VydGFp bg0KPj4gPj4gPj4+d2F5Lg0KPj4gPj4gPj4+ID4+aXQNCj4+ID4+ID4+PiA+PiA+PiBpcyBqdXN0 IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+ID4+ID4+PiA+ PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPj4gPj4gPj4+ID4+ID4+IEpvZWwNCj4+ID4+ ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0 aCB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1h dGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlcw0KPj4gPj4gdGhhdA0KPj4gPj4gPj4+ID4+bmVl ZHMNCj4+ID4+ID4+PiA+PiA+Pj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBkaXN0 cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gPj5hY3Jvc3MNCj4+ ID4+ID4+PmRhdGENCj4+ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0 cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj4gY29tcGxleA0K Pj4gPj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFj aCBTRkYgc2VlbXMgbGlrZSBhDQo+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4+ IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ ID4+PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4N Cj4+ZHluYW1pYw0KPj4gPj4gPj4+IHJvdXRpbmcsDQo+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNj YWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mDQo+PndoaWNoDQo+ PiA+PmFyZQ0KPj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiA+PiA+Pj4gPj4gPj4+IHByb2JsZW1zIHRo YXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8NCj4+ID4+ID4+ PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSXQgYWxzbyBzZWVtcyB0aGF0IGlmIGl0IHJlYWxs eSBpcyBtb3JlIGNvbXBsaWNhdGVkLCB0aGF0DQo+PmlzDQo+PiA+PmENCj4+ID4+ID4+Pmdvb2QN Cj4+ID4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4NCj4+ID4+ ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2pt aEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj4gPj4+ ID4+ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiA+PiA+Pj4g Pj4gPj4+IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9s LmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPj5JYW4NCj4+ID4+ID4+PlNtaXRoOw0K Pj4gPj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQNCj4+QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IFRo aXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQNCj4+cHJl ZmVyDQo+PiA+PndlDQo+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+ID4+ID4+PiA+PiA+Pj4g ZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlDQo+PiA+Pmlt cGxlbWVudGF0aW9ucy4NCj4+ID4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBt YWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+ID4+cmVxdWlyZW1lbnRzDQo+PiA+PiA+Pj5h bmQNCj4+ID4+ID4+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBT RkZzLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ID4+dGhhdA0KPj4g Pj4gPj4+IG5lZWRzDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5 IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuDQo+PiBhY3Jvc3MN Cj4+ID4+ID4+PmRhdGENCj4+ID4+ID4+PiA+PiA+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5p c3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaA0KPj5hbmQNCj4+ID4+ID4+PmNvbXBsZXgN Cj4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFj aCBTRkYgc2VlbXMgbGlrZSBhDQo+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4g YXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4g Pj4+IFlvdXJzLA0KPj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+ PiA+Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+PiA+PiA+Pj4gPj4gPj4+ DQo+PiA+PiA+Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6 DQo+PiA+PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiBJcyB0aGUg ZW5kIHRvIGVuZA0KPj5zZWxlY3Rpb24NCj4+ID4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+ICh0b3At bGV2ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZQ0KPj4g Pj4gPj4+ID4+Y2xhc3NpZmllcikNCj4+ID4+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBl cmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseQ0KPj4gPj50aGUNCj4+ID4+ ID4+PiA+PlNGRnMpPw0KPj4gPj4gPj4+ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVx dWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4+QW5kDQo+PiA+PiA+Pj5zdXJlbHksDQo+ PiA+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCBy ZWxlZ2F0ZWQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+PiA+PiA+ Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhl IGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4NCj4+IHRob3VnaA0KPj4gPj4gYQ0KPj4gPj4gPj4+ ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBl cmhhcHMNCj4+bG9jYWwNCj4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+Pj4g cG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMu DQo+PiA+PlRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUg YW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0IGFsbC4NCj4+ID4+TXkNCj4+ID4+ID4+PiA+PiA+Pj4+ IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkgZHJpdmVu DQo+PmJ5DQo+PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+ID4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVu Y3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBwcm9hY2guIFdpdGggYQ0KPj5nbG9iYWwNCj4+ ID4+ID4+PnBhdGgNCj4+ID4+ID4+PiA+PmlkDQo+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwg Y29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0bw0KPj4gPj5hbHRl cg0KPj4gPj4gPj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBm b3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQNCj4+ZW5kLXRvLWVuZA0KPj4gPj4gPj4+cGF0aC4N Cj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4+ID4+ID4+PiA+PiA+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIEZyb206IHNmYw0KPj4gPj4gPj4+ID4+ID4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4g RGlyZWN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs DQo+PjIwMTQNCj4+ID4+IDY6MTUNCj4+ID4+ID4+PiBQTQ0KPj4gPj4gPj4+ID4+ID4+Pj4gVG86 IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IEkuU21pdGhARjUu Y29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gU3ViamVjdDoNCj4+ID4+IFJlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBj YXNlIG9mIFNGMSBuZWVkaW5nDQo+PnRvDQo+PiA+PiA+Pj4gPj5pbmZsdWVuY2UNCj4+ID4+ID4+ PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9u IGF0IHRoZQ0KPj5leGl0DQo+PiA+PmZyb20NCj4+ID4+ID4+PiA+PiA+Pj4+IFNGMS4NCj4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtl ZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4+ID4+bG9naWNhbGx5DQo+PiA+PiA+Pj4gPj4g Pj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cg dGhleQ0KPj4gPj4gY2hvb3NlDQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9z ZSB0aGVtIGZvciAic2VydmljZSIgZGVsaXZlcnkuDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+IHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRo aW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55DQo+PiA+PnNvcnQNCj4+ID4+ ID4+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0 byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUNCj4+ID4+cGF0aA0KPj4gPj4gPj4+KGFsbA0KPj4g Pj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0aW9u LiBJIGJlbGlldmUNCj4+dGhpcw0KPj4gPj4gPj4+bWVhbnMNCj4+ID4+ID4+PiA+PiA+Pj4+PiBl aXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXINCj4+Y2hvb3Nl cyBhDQo+PiA+PlNGDQo+PiA+PiA+Pj4gPj5DaGFpbg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFuZCB0 aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSwNCj4+ID4+ dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEg bW9yZSBkeW5hbWljIFNGUCB3aGVyZQ0KPj4gPj4gU0ZJKG4pDQo+PiA+PiA+Pj4gaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+PiBkZXRlcm1pbmVkIGF0IHRoZSBTRkkobi0xKSBob3AuIEFjY29yZGluZyB0 byB0aGUgZHJhZnQsDQo+PiA+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlvciB3b3Vs ZCBiZSBjb25zaWRlcmVkICJicmFuY2hpbmciIHRvIGEgbmV3IFNGUCBhcw0KPj4gPj4gPj4+IG9w cG9zZWQNCj4+ID4+ID4+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNob29zaW5nIGFuZCB0 aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVjdGVkIGluc3RhbmNlIG9mDQo+PiA+PnRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJl LTAwOg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50 byB0aGUgbmV0d29yayBpdCBpcw0KPj4gPj5uZWNlc3NhcnkNCj4+ID4+ID4+PnRvDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdp bGwgYmUgdXNlZCwNCj4+ID4+YW5kIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUg c2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Yncw0KPj4gPj5uZXR3b3JrDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGxvY2F0b3IuIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNG QyByZXN1bHRzIGluIHRoZQ0KPj4gPj4gPj4+Y3JlYXRpb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g b2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+PiA+PmZv cndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIElu IG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGluc3RhbnRp YXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9u IChvcg0KPj4gPj5ub24taW5pdGlhbA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlv bikgYXMgd2VsbC4gQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBh DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50 IHdpdGggYSBzZXJ2aWNlDQo+PiA+PmZ1bmN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBSZWNs YXNzaWZpY2F0aW9uIG1heSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldw0KPj4gPj5T RlAsIGFuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRh ZGF0YSwgb3IgYm90aC4gVGhpcyBpcw0KPj4gPj5yZWZlcnJlZA0KPj4gPj4gPj4+dG8NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gYXMgImJyYW5jaGluZyIuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4NCj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb208bWFpbHRvOipJLlNtaXRoQEY1LmNvbT48SS5TbWl0 aEBGNS5jb208bWFpbHRvOkkuU21pdGhARjUuY29tPj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86 ICpKb2VsIEhhbHBlcm4NCj4+IERpcmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+PixKb2VsDQo+PiA+PiBNLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+ID4+Pj4+SGFscGVy bjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4saHVhbmdA c2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+PGh1YW5nQHNjZS4N CjxtYWlsdG86aHVhbmdAc2NlLiUwYj4+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+PiA+PiA+Pj4g Pj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVy c2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4gPj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+ID4+QmFsYW5jZXJzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFt IGRpc2FncmVlaW5nLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYg dGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PnRoYXQg aXMNCj4+ID4+ID4+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlz IGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4gPj4gPj4+cHJlY29uY2VpdmVk DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVj dHVyZSBidXJkZW5lZCB3aXRoDQo+PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29uY2Vw dGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0 byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YNCj4+ID4+YXNwaXJhdGlvbg0K Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZv ciB0aGUgbGlmZXNwYW4gb2YgdGhlDQo+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gPj4gPj4+LQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5 IHNheWluZyB0aGF0IGFuDQo+PiA+PiA+Pj5hcmJpdHJhcnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBu dW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+ PiA+PiA+Pj4gPj5pbnRlbnRpb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0 IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSBsYXN0aW5nDQo+PiA+PmltcGFjdHMNCj4+ ID4+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24s IGVsYXN0aWNpdHksDQo+PiA+PmFkZHJlc3MNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBh bGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBqb2Vs aGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+U2Vu dDoNCj4+ID4+ID4+PiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRv OiBJYW4gU21pdGg7IEpvZWwgTS4NCj4+ID4+IEhhbHBlcm47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g aHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdDQo+PiA+PlNl cnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwgSSBkb24ndCB0 aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcw0KPj4gPj5yZWdhcmQuDQo+ PiA+PiA+Pj5JDQo+PiA+PiA+Pj4gPj5hbQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1ZXN0 aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbg0KPj4gPj5wcm9oaWJpdA0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJ IGFtIG9iamVjdGluZyB0bw0KPj4gPj5IdWFuZydzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGlu ZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlDQo+PiA+PiBy ZXF1aXJlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVh dGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdA0KPj5zdWNoDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRz IHVwb24NCj4+ID4+IG1hbnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2Yg dGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8NCj4+dGhpbmsNCj4+ID4+dGhhdA0KPj4g Pj4gPj4+ID4+dGhleQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0aWVj dHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bw0KPj4gPj5rbm93DQo+PiA+ PiA+Pj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFu IFNtaXRoIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1 bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YNCj4+ID4+ID4+Pm1pbGxpb25zDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBi b3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGVu dmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4NCj4+ dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9UIHdv cmxkIG9mIHRvbW9ycm93IHlvdQ0KPj4gYXJlDQo+PiA+PiBvbmx5DQo+PiA+PiA+Pj4gPj4gZ29p bmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBj aGFpbnMgd2l0aCBlcXVhbGx5DQo+PnNtYWxsDQo+PiA+PiA+Pj4gbnVtYmVycw0KPj4gPj4gPj4+ ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUgd2ls bCBldmVyIG5lZWQgbW9yZQ0KPj4gdGhhbg0KPj4gPj4gPj4+IDY0SyINCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gZm9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIG9u IGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBbam1oQGpvZWxo YWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86DQo+PiA+PiA+Pj5o dWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPj5hbmQNCj4+ID4+ID4+PkxvYWQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRv IGRlcGxveSB0aGUNCj4+ID4+ID4+PmFyY2h0aWV0dXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBh cnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mDQo+PnRoZWly DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3Qg cmVxdWlyZSBzdWNoIGFic3VyZA0KPj4gdXNlDQo+PiA+PiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+ PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGUN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwg dGhlIGFyY2hpdGVjdHVyZQ0KPj5kb2VzDQo+PiA+PiA+Pj5wZXJtaXQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gc3VjaCBhYnVzZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUNCj4+ IHBlcm1pdHMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBpdCBpcyBl aXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieQ0KPj4gPj50aGUNCj4+ID4+ID4+PndvcmsuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBj aGFpbnMsIGl0IHdpbGwNCj4+bWVhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBw YXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZw0KPj50YWJsZQ0KPj4gPj5vZiBh DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJh bmdlIG9mIGRlcGxveW1lbnRzLCBmcm9tDQo+PjENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2 aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZQ0KPj50aGF0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBs ZXhpdGllcyBpZiB0aGV5DQo+PiA+PmNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVh ZA0KPj4gPj4gcHJvdmlzaW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNl IHBhdGhzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gWW91 cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9u IDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQg aG9wDQo+PiA+PiBzZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAg aW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBC ZWhhbGYNCj4+IE9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkg KlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gPj4zOjAzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqU3ViamVj dDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiBDaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRy aXZlcyB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+IG1ha2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5n ZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0bw0KPj4gPj4gZGVyaXZlDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0 cmFuc3BvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPj5zaW1w bHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3Ig Z3JhcGgpIHRoYXQgcGFja2V0cw0KPj5tdXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZl cnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Ig b24NCj4+dGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBi ZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4+ID4+IGlkZW50aWZpZXINCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3Vw IGNhbg0KPj4gPj4gcmVzdWx0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1v cmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBob3AocykuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFBhdWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g T24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ DQo+PiA+PiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPjxtYWlsdG86bHVjeS55b25nQGh1 YXdlaS5jb20lM2U+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3cm90ZToNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5v dCBtYW5kYXRlIG9ubHkgdXNlIG9mDQo+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcNCj4+ID4+YWN0aW9u cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzpPZiptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+PiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0K Pj4gPj4gPj4+ID4+IEp1bHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBB TSAqVG86Km1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+O2ptaEBqb2VsaGFs cGVybi5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNlO2ptaEBqb2VsaGFscGVybi5jb20+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2Zj QGlldGYub3JnPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZz4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTog W3NmY10gU2VydmljZQ0KPj4gPj5DaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBw YXRoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0 aGF0IGlkZW50aWZpZXIgdG8NCj4+ZGVyaXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndh cmRpbmcgYWN0aW9ucy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBv Zg0KPj4gPj4gZXZlcnkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRv bWFpbiBpcyBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250 ZXh0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU0ZD IGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2YNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24NCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0IHdpbGwN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRo YXQgaXMgdGhlIG9uZQ0KPj4gcmVxdWlyZWQNCj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzDQo+ PiA+PnVzZWQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPj4g Pj4gPj4+ID4+ID4+Pj4+IGFjdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1 dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGEg cGFydA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzpkZSpt aWtlYmlhbmNAYW9sLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlh bmNAYW9sLmNvbT4gKkVudm95w6kgOiptZXJjcmVkaSA5DQo+PiA+PiBqdWlsbGV0DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86KmptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tJTNlO3NmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNA aWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiA+PkNoYWlucywNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rp b25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0KPj5TRg0KPj4gPj4gQ2hhaW4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW5kIFNGDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRo YXQgaXQncw0KPj4gPj5jbGVhciB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRob3NlIG5vdA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhh dCBldmVyeW9uZQ0KPj5hZ3JlZXMNCj4+ID4+b24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhl c2UgdGVybXMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcw0KPj53aGV0aGVy DQo+PiA+Pml0IGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBpbnRlbnQgb2YgdGhpcyBk cmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdA0KPj4gPj50aGUgSUQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4+ID4+ID4+PiA+PiA+Pj4+PiBzaG91bGQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgp LCBvciBpZiB0aGlzIGRyYWZ0DQo+PiA+PnNpbXBseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlcg0KPj5kcmFmdHMN Cj4+ID4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBm b3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbg0KPj4gb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IHBh dGggdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJv bC1wbGFuZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g SWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgaGF2ZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBw b3J0ZWQgKG9yIG1ha2UNCj4+ID4+IG9uZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJl ZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lDQo+PiB2ZW5kb3JzDQo+PiA+ PiBvbmx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMg b25seSBzdXBwb3J0aW5nIFNGQy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4N Cj4+ID4+DQo+Pg0KPj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+ Pj4+Pj4+Pj4tLS0NCj4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzoqam1oQGpvZWxoYWxw ZXJuLmNvbT48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSUzY2ptaEBqb2VsaGFscGVybi5jb20+PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbSUzZT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGll dGYub3JnPG1haWx0bzoqc2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNA aWV0Zi5vcmc+PG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmclM2U+Pg0KPj4gKlNl bnQ6KlR1ZXNkYXksDQo+PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIwMTQg KlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+PkxvYWQNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0 byBjbGVhcmx5DQo+PmFuc3dlcg0KPj4gPj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJl ciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPj4gPj4gPj4+IHBy b3Bvc2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQu IEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4+IHdvcmtpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Z3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPj4gaW1wcm92 ZQ0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFk ZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4NCj4+ID4+dGhlDQo+PiA+PiBXRw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkg dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBn cm91cCBpbnRlbmRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4g Pj5wZXJzb25hbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQg aGVscHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElu IHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQNCj4+ID4+ d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEg cGxhbmUgYXJjaGl0ZWN0dXJlLiBXZQ0KPj5hcmUNCj4+ID4+IG5vdA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50 aXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5n LiBUaGF0IHdvdWxkIGVuY29tcGFzcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2 YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQo+PnZpcnR1YWwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3Ro ZXINCj4+ID4+IGFzcGVjdHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVhcmx5 IG5lZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIg c3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgNCj4+ID4+YWJvdmUNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcs DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5 IHRoZSB3b3JrIHdlIGFyZQ0KPj4gZG9pbmcuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNl cnZpY2UgcGF0aCwNCj4+YXMgSQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRv IGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdA0KPj4gPj5sZWFzdA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFs YW5jaW5nIGNhbiBhbmQNCj4+d2lsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFjdCB3 aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZQ0KPj4gPj5tb3JlLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBw ZXJtaXQgYWxsIG9mDQo+PiA+PnRoZXNlLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90 IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g YmUgdXNlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5n IGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgZW5kDQo+PiA+PnVzZXIuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2Vy DQo+PnBhY2tldHMsDQo+PiA+PmFuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0 aGVtIChvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4+ID4+ aW5zdGFuY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFj a2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj4gPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5n Lg0KPj4gPj5JdCdzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3Qg cmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+PiA+PiBjaGFpbmluZyBpcw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUN Cj4+ID4+YXJjaHRpZWN0dXJlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hp dGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5 IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQg aXMsIG9uZQ0KPj5jYW4NCj4+ID4+aGF2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0aGUg c2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUNCj4+cG9pbnQNCj4+ID4+ b2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZv ciBhDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1 dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4+ID4+YnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNv bGxlY3Rpb24gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBt YWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+Pm9uZSBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNz LikgbW9zdGx5LCB0aGlzIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+PiA+Pm1lY2hhbmlzbXMuDQo+PiA+PiBJ dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbA0KPj4gPj5tZWNoYW5pc21zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LA0KPj5h bmQNCj4+ID4+dm0NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFy Y2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+PnBlcm1pdHRpbmcNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQg b3VyDQo+PiA+PnRlcm1pbm9sb2d5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxl YWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcg ZG9uZSBieQ0KPj5zZWxlY3RpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhz IGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdA0KPj4gPj50cmFmZmljDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50 IHRvIHJlcXVpcmUNCj4+IHRoYXQNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZl biBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSBwbGFjZSBpbg0KPj50aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2Ug bWF5IGJlDQo+PmNvbWJpbmVkLiBJDQo+PiA+PiB0ZW5kDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gc2VydmljZQ0KPj4gPj5j aGFpbmluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNs dXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXINCj4+aXMNCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUu DQo+PiBUaHVzLA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5 cGUgMyBsb2FkIGJhbGFuY2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZl cmVudA0KPj4gPj5zaW5ndWxhcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQg c2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcw0KPj5pbg0KPj4gPj50aGUNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3 aGVuIEkgdGFsayBhYm91dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluIGFu ZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYQ0KPj4gPj4gc2VxdWVuY2UNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBh IHN1YnNldCBvZg0KPj4gPj5wYWNrZXRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBl cXVpdmFsZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mDQo+PnRyYWZmaWMNCj4+ID4+ aXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQg aW5zcGVjdGlvbiwgYW5kDQo+PmZpcmV3YWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxl IGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUNCj4+Y2FjaGUNCj4+ ID4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5n IGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRp cmVjdCB0aGUNCj4+cGFja2V0cy4NCj4+IEENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vydmlj ZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4+ID4+bG9jYXRpb25z DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMg d2lsbCBiZSBzaW5ndWxhciBvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2Vy dmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4+ID4+bWF5IGJlDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBh ZGRyZXNzZWQgYXMNCj4+IHBvcnRzDQo+PiA+PiBvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh biBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+PiA+PmxvY2F0 aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUNCj4+IGFuZA0KPj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNG Qw0KPj5ncm91cCwNCj4+ID4+IHdlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRvIGJl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZl bCBhYnN0cmFjdGlvbiwgdGhlDQo+PiA+PnNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Y2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG8NCj4+IHRh bGsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFj a2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2Yg dGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRoZSB3aG9sZQ0KPj4gcGF0aA0KPj4gPj4gbWF5 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlz IGFyY2hpdGVjdHVyZSBkZWFscw0KPj4gPj53aXRoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo YXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKQ0KPj5vbg0K Pj4gPj5sb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUg Y2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+YmVoYXZpb3JzDQo+PiA+PiB3aGljaA0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hh bmlzbXMgKGluDQo+PiA+Pm11Y2gNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUgd2F5 IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+PiBw cm92aXNpb24NCj4+ID4+IHdlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+PiB0aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRp b24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4+ID4+IG5lY2Vzc2FyeS4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWlu LiBCYXNlZCBvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUg YXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uDQo+PnBvaW50Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4g d2hhdCB3ZSBhcmUgYWZ0ZXIuDQo+PklmIGl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMs IGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcNCj4+ID4+IGdy b3VwLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0 aW9uYWwgd29yZHMgYXJlIG5lZWRlZA0KPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29u dmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlDQo+PiA+PiBp bnRlbnQsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRq dXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nDQo+PiA+Pmdyb3VwDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZQ0K Pj4gPj53aGF0IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gc2ZjDQo+PiA+PiA+Pj4g Pj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGlu Zw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBz ZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBs aXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4g Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4g Pj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gc2ZjDQo+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ ID4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+PiBzZmMgbWFpbGlu ZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+PiA+PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+ c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4gPj4gPj4+ID4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4g Pj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+ Pj4NCj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPg0KPj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4g PnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7CMBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFp blRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6U2ltU3VuO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWlu ZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5QbGFpblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlNlZ29lIFVJIiwic2Fucy1zZXJpZiI7fQ0K cC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5bGUtbmFtZTrmibnms6jmoYbmlofmnKw7DQoJbXNv LXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1 bjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pys Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KcC5IVE1MLCBsaS5IVE1MLCBkaXYuSFRNTA0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCDpooTorr7moLzlvI8iOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTpT aW1TdW47fQ0KcC5hMCwgbGkuYTAsIGRpdi5hMA0KCXttc28tc3R5bGUtbmFtZTrnuq/mlofmnKw7 DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1 bjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3NjIzODM3NjsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAwNDgwOTI1OCA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlhpYW9odSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBtZWFuaW5nIG9mIHRoZSBTRlAgSUQgaXMg cHJldHR5IGNsZWFyLCBhdCBsZWFzdCB0byBtZSDigJMgYW4gYWJzdHJhY3QgaWRlbnRpdHkgZm9y IHRoZSBleGFjdCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgKGkuZS4sIFNGUCBJ RCAxID0ge1NGLUEtMSwNCiBTRi1CLTMsIFNGLUMtMn0pLiZuYnNwOyZuYnNwOyZuYnNwOyBJbiBz b21lIHdheXMsIGl0IGlzIGEgY29sbGFwc2VkIOKAnGxhYmVsIHN0YWNr4oCdIOKAkyB0aGVyZSBp cyBhIHNpbmdsZSB0YWcgaW1wbHlpbmcgc29tZSBzZXF1ZW5jZSBvZiBuZXR3b3JrIGxvY2F0aW9u cy4mbmJzcDsmbmJzcDsgQnV0LCB0aGlzIGFsc28gaW1wbGllcywgYXQgbGVhc3QgdG8gbWUsIHRo YXQgdGhlcmUgaXMgYSBjZW50cmFsIHBvaW50IG9mIHNlbGVjdGlvbiBmb3IgdGhpcyBlbmQgdG8g ZW5kIHNlcXVlbmNlIChiYXJyaW5nDQogcmVjbGFzc2lmaWNhdGlvbiwgb2YgY291cnNlKS4mbmJz cDsmbmJzcDsgSSwgZm9yIG9uZSwgYW0gcXVlc3Rpb25pbmcgdGhhdCBpbXBsaWNhdGlvbi4mbmJz cDsmbmJzcDsmbmJzcDsgSSBoYXZlIGJlZW4gdW5jb21mb3J0YWJsZSB3aXRoIHRoYXQgY2VudHJh bCBwb2ludCBtZXRob2RvbG9neSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2YgZHlu YW1pYyBzY2FsZSBhbmQgdGltZWxpbmVzcyBvZiByZWFjdGlvbiB0byBmYWlsdXJlcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzIHRvIHN0aWxsIHVzZSBjZW50cmFsIHNlbGVj dGlvbiB0byBzZWxlY3QgdGhlIGNoYWluIG9mIGFic3RyYWN0IHNlcnZpY2UgZnVuY3Rpb25zIChp LmUuLCBTRkMgSUQgMSA9IHtTRi1BLCBTRi1CLCBTRi1DfSksIGJ1dCBhbGxvdw0KIHRoZSBhY3R1 YWwgaW5zdGFuY2Ugc2VsZWN0aW9uIHRvIGJlIGRpc3RyaWJ1dGVkLCByZWFsaXplZCBieSB0aGUg Y2xhc3NpZmllciBhbmQgdGhlIFNGRnMuJm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdpdmVuIGEg dG9wb2xvZ3kgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNsYXNzaWZpZXIgLS0tLS0tLSZuYnNwOyBTRkYtMSAt LS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMiAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0t LS0tLS0tLS0tLS0tLS1TRkYtNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7U0ZGLUEtMSZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDtTRkYtQS0yJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO1NTRi1CLTEmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0ZGLUItMiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTRkYtQy0xJm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NGRi1DLTImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0ZGLUEtMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGFzc3VtaW5n IGEgbmV3bHkgcmVjb2duaXplZCBmbG93LCB0aGUgc2VxdWVuY2UgY291bGQgZ28gc29tZXRoaW5n IGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEgQ2xhc3NpZmllciBzZWxlY3RzIGNoYWluIFNGQyBJRCAx IHtTRi1BLCBTRi1CLCBTRi1DfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yIENsYXNz aWZpZXIgc2VsZWN0cyBTRkYtMSBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBT Ri1BPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjMgQ2xhc3NpZmllciBlbmNhcHN1bGF0 ZXMgcGFja2V0IGluZGljYXRpbmcgY2hhaW4gSUQgPSAxLCBzZXJ2aWNlIGluZGV4ID0gMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj40IENsYXNzaWZpZXIgcHJvZ3Jlc3NlcyBwYWNrZXQg dG8gU0ZGLTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NSBTRkYtMSwgc2VlaW5nIGNo YWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3QgaXRzIGF2 YWlsYWJsZSBpbnN0YW5jZXMgb2YgU0YtQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj42 IFNGRi0xIHNlbmRzIHBhY2tldCB0byBTRkYtQS0xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjcgU0ZGLUEtMSBzZW5kcyBwYWNrZXQgYmFjayB0byBTRkYtMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj44IFNGRi0xIGluY3JlbWVudHMgc2VydmljZSBpbmRleCB0byAyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjggU0ZGLTEgc2VsZWN0cyBTRkYtMiBhcyBob3N0aW5n IGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1CPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjkgU0ZGLTEgcHJvZ3Jlc3NlcyBwYWNrZXQgdG8gU0ZGLTI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+MTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBTRkYtMywgYXMg dGhlIGVncmVzcyBib3JkZXIsIHByb2dyZXNzZXMgdGhlIHBhY2tldCBwZXIgcm91dGluZyB0YWJs ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WHV4aWFvaHU8YnI+DQo8Yj5TZW50OjwvYj4gU3Vu ZGF5LCBKdWx5IDEzLCAyMDE0IDExOjMwIFBNPGJyPg0KPGI+VG86PC9iPiBtaWtlYmlhbmNAYW9s LmNvbTsgamd1aWNoYXJAY2lzY28uY29tOyBtbjE5MjFAYXR0LmNvbTsgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgUm9uIFBhcmtlcjsgc2ZjQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkFncmVlIHRoYXQgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGluIHRoZSBhcmNo IGRyYWZ0IGlzIGEgYml0IGNvbmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBoYWQgcG9pbnRlZCBv dXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JbiBteSB1 bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRo ZSBuZXR3b3JrIHNob3VsZCBiZSDigJxhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBh bmQgU0YgSURz4oCdKHNlZTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDE8L2E+ KS4gT2YgY291cnNlLCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4gdGhlIGRhdGEgcGFja2V0 IGlzIGFub3RoZXIgdGhpbmcgKGUuZy4sIGVpdGhlciB0aHJvdWdoIGEgcGF0aCBpZCBvciB0aHJv dWdoIGFuIE1QTFMgbGFiZWwgc3RhY2spLiBIZXJlIHRoZSBzZXJ2aWNlIG5vZGUgbWVhbnMgdGhl IGRldmljZSB3aGljaCBjb250YWlucyB0aGUgU0ZGIGFuZCB0aGUgTkYgY29tcG9uZW50cyBtYW5k YXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBhbmQgU0YgcHJveHkgY29tcG9uZW50cyBv cHRpb25hbGx5LiBUaGUgc2VydmljZSBub2RlIGNvdWxkIGJlIGF0dGFjaGVkIG9yIGVtYmVkZGVk IHdpdGggbXVsdGlwbGUgU0YgaW5zdGFuY2VzIGFuZCB0aG9zZSBTRiBpbnN0YW5jZXMgY291bGQg YmUgb2YgdGhlIHNhbWUgU0YgdHlwZSBvciBub3QuICZuYnNwO0luIHRoZSBjYXNlIHdoZXJlIHRo ZXJlIGFyZSBtdWx0aXBsZSBTRiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgU0YgdHlwZSAoZS5nLiwg U0YgWCkgYXJlIGF0dGFjaGVkIHRvIGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBu b2RlIGNvdWxkIGRpc3RyaWJ1dGUgdGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0 aG9zZSBTRiBpbnN0YW5jZXMgb2YgU0YgWCB0eXBlIGxvY2FsbHkuIE1lYW53aGlsZSwgdGhlcmUg bWF5IGJlIG11bHRpcGxlIHNlcnZpY2Ugbm9kZXMgd2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQg ZG9tYWluIHdoaWNoIGFyZSBlbWJlZGRlZCBvciBhdHRhY2hlZCB3aXRoIHRoZSBTRiBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgU0YgdHlwZS4gSW4gdGhpcyB3YXksIHRoZSBTRiBsb2FkLWJhbGFuY2lu ZyB3b3VsZCBiZSBtYWRlIHZlcnkgZmxleGlibGUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2 IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5q Z3VpY2hhckBjaXNjby5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPg0K bW4xOTIxQGF0dC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT47IDxhIGhyZWY9 Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj4NClJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V291 bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICZxdW90O3NlcnZpY2UgY2hhaW4gaWRlbnRpZmllciZx dW90OyB0aGVuPyAmbmJzcDtJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBsaXN0 IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mDQogU0Yg aW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICZxdW90O3NlcnZpY2UgcGF0aCBp ZGVudGlmaWVyJnF1b3Q7IHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0 aCosIG5vdCBhIHNlcnZpY2UgKmNoYWluKi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQpBZ2FpbiwgSSB0aGlu ayB0aGlzIGlzIHdoZXJlIHRoZSBjb25mdXNpb24ga2VlcHMgY3JlZXBpbmcgaW4uICZuYnNwO1Ro ZSB0ZXJtcyAmcXVvdDtjaGFpbiZxdW90OyBhbmQgJnF1b3Q7cGF0aCZxdW90OyBzZWVtIGluY29u c2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBz dHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Im1haWx0 bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2Nv LmNvbSZsdDtqZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+PGEgaHJl Zj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNjbWlrZWJpYW5jQGFvbC5jb20lM2UsbW4xOTIx QGF0dC5jb20lM2NtbjE5MjFAYXR0LmNvbSUzZSxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t JTNjbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzZSxqbWhAam9lbGhhbHBlcm4uY29tJTNj am1oQGpvZWxoYWxwZXJuLmNvbSUzZSxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJTNj Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzZSxzZmNAaWV0Zi5vcmclM2NzZmNAaWV0 Zi5vcmciPm1pa2ViaWFuY0Bhb2wuY29tJmx0O21pa2ViaWFuY0Bhb2wuY29tJmd0OyxtbjE5MjFA YXR0LmNvbSZsdDttbjE5MjFAYXR0LmNvbSZndDssbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSZsdDttb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0OyxqbWhAam9lbGhhbHBlcm4uY29t Jmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7LFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20mbHQ7Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSZndDssc2ZjQGlldGYub3JnJmx0 O3NmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSnVseSAxMSwg MjAxNDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPllvdXIgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBh dGggaXMgY29ycmVjdCBhcyBpdHMgdGhlIGZvcndhcmRpbmcgcGF0aCB0aHJvdWdoIHdoaWNoIHRy YWZmaWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaG93 ZXZlciBwb2ludHMgdG8gdGhlIHNlcnZpY2UNCiBjaGFpbiBkYXRhIHN0cnVjdHVyZSBhbmQgdGhh dCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNo IG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMgYXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIg bG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluIHBsYXkuIFdoZW4gaW5zdGFudGlhdGlu ZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1 cGRhdGUNCiB0aGF0IGRhdGEgc3RydWN0dXJlIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1h eSBiZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3b3VsZCBlZmZlY3RpdmVseSBuYWls IHVwIHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBz aW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvIG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0 aGUgZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVw dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZxdW90OzxhIGhyZWY9Im1haWx0bzptaWtl YmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+RnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNPGJyPg0KPGI+VG86 IDwvYj5KaW0gR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20i PmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW4xOTIx QGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1u MTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxo YWxwZXJuLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mcXVv dDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20i PlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ni43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5JIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjYuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jmd0OyBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5 PGJyPg0KJmd0OyBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUg Y29tYmluYXRpb24gdGhlcmVvZikuIEk8YnI+DQomZ3Q7IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZn dDtTMzxicj4NCiZndDsgYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcms8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCjxicj4NCkJ5IGRlZmlu aXRpb24sIEkgdW5kZXJzdG9vZCBhICZxdW90O3NlcnZpY2UgcGF0aCZxdW90OyB0byBiZSBhbiBv cmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFi b3ZlLCB5b3UgdXNlIGEgJnF1b3Q7c2VydmljZSBwYXRoIGlkZW50aWZpZXImcXVvdDsgdG8gcmVm ZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgJnF1b3Q7W2RvZXMgbm90 XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNlcyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCjxociBzaXplPSIx IiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6Izk5OTk5OSIgYWxpZ249ImNl bnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFy QGNpc2NvLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1 aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFMQSwgTUFSSUEg SCZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZn dDssPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssSm9l bCBNLiBIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDssUm9uDQogUGFya2VyJmx0OzxhIGhyZWY9Im1haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz PGJyPg0KPGJyPg0KTWFyaWEsPGJyPg0KPGJyPg0KSSB0aGluayBvZiBpdCB0aGlzIHdheS4gVGhl IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50ZXIgdG88YnI+DQphIGRh dGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4g eW91IGRlZmluZSBhPGJyPg0KY2hhaW4sIGxldDxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+ cyBzYXkgUzEgLSZndDtTMi0mZ3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBT RlAgc3BlY2lmeTxicj4NCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFm ZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZlciwgeW91IGRvICpu b3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSTxi cj4NCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9uPHNwYW4gbGFuZz0iWkgt Q04iPuKAmTwvc3Bhbj50IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91PGJyPg0KY291bGQg c2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2 ZW4gU0ZDIGFuZDxicj4NCnRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdv cmsuIEF0IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGE8YnI+DQpzZXJ2aWNlIHBhdGggaWRlbnRpZmll ciB0byBTRkMgbWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4gdGhlPGJyPg0K bmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0Y8c3BhbiBsYW5nPSJaSC1DTiI+ 4oCZPC9zcGFuPnMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuPGJyPg0KdGhvc2UgbmV4 dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50 cmFsaXplZDxicj4NCmNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91Z2ggQ0xJLCBsZWFy biB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2g8YnI+DQpzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3 aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bzxicj4NCnNheSB0 aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9z ZW4gYSBwcmlvcmk8YnI+DQphbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAoYW5k IHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0byBkbzxicj4NCnNvLjxicj4NCjxicj4NCkxl dDxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1 bGx5IG1ha2UgdGhpcyBjbGVhcjo8YnI+DQo8YnI+DQpJIGRlZmluZSBhbiBTRkMgKGxldDxzcGFu IGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyByZWZlciB0byBpdCBhcyBTRkMtMSkgUzEtJmd0O1My LSZndDtTMy4gRm9yIGFyZ3VtZW50czxicj4NCnNha2UgbGV0PHNwYW4gbGFuZz0iWkgtQ04iPuKA mTwvc3Bhbj5zIHNheSBJIHdhbnQgaXQgdG8gYmUgZnVsbHkgZHluYW1pYyBlLmcuIEkgZG9uPHNw YW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj50IHdhbnQgdG8gc3BlY2lmeTxicj4NCnNwZWNpZmlj IGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9m KS4gSTxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDxzcGFuIGxhbmc9IlpI LUNOIj7igJw8L3NwYW4+MTAwPHNwYW4gbGFuZz0iWkgtQ04iPuKAnTwvc3Bhbj4gdGhhdCBiYXNp Y2FsbHkgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8YnI+DQphbmQgdGhlbiBwdXNoIHRoaXMg aW50byB0aGUgbmV0d29yayBzbyB0aGF0IHRoZSBTRkYgZGF0YSBzdHJ1Y3R1cmVzIGFyZTxicj4N CnBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBhdCBhIGdpdmVuIFNGRiwgd2hl biB0cmFmZmljIGFycml2ZXM8YnI+DQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwg dGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YTxicj4NCnN0cnVjdHVyZSBhbmQg ZmluZCB0aGF0IGl0IHBvaW50cyB0byBTMS0mZ3Q7UzItJmd0O1MzIGFuZCB0aGUgaW5kZXggaW4g dGhlIFNGQzxicj4NCmVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0IGV4YWN0bHkgd2hlcmUgaXQg aXMgaW4gdGhlIGNoYWluLiBMZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgc2F5IHdl PGJyPg0KYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJl c29sdmUgdGhlIG5leHQtaG9wIHRvPGJyPg0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0 ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS48YnI+DQo8YnI+DQpPbiA3LzExLzE0LCAxMToy NiBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0K Jmd0O0ppbSw8YnI+DQomZ3Q7PGJyPg0KJmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhl IGRlZmluaXRpb24gb2YgYSAmcXVvdDtzZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8YnI+DQomZ3Q7 JnF1b3Q7c2VydmljZSBwYXRoIGlkZW50aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lmIGEgc2Vydmlj ZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdo aWNoPGJyPg0KJmd0O2lzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3Qg U0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZGIHRvIHBpY2su IEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDtNYXJpYTxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7Jmd0OyA8YnI+DQo8YnI+DQpGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFy KSBbPGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEx OjE1IEFNPGJyPg0KJmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+OyBKb2VsIE0uPGJyPg0KJmd0OyZndDsgSGFscGVybjsgUm9uIFBhcmtlcjsgPGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7 IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vyczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEk8c3BhbiBsYW5nPSJaSC1DTiI+4oCZ PC9zcGFuPm0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3Nw YW4+dCB1bmRlcnN0YW5kIHdoeSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyPGJyPg0KJmd0OyZn dDsgcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBjYWxs aW5nIGl0IGEgc2VydmljZTxicj4NCiZndDsmZ3Q7IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55 IGRpZmZlcmVuY2U/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gNy8xMS8xNCwgMTA6 NTggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7ICZndDtEaXR0by48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBbPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBN LiBIYWxwZXJuOyBSb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBQYXJrZXI7IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFJlLSw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEZvciB3aGF0IEkg Y2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZTxicj4N CiZndDsmZ3Q7ZHJhZnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBo aW50IHRoYXQgdGhlIGZ1bGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Rpc3RyaWJ1dGVkPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgbW9kZWwgaXMgbm90IGFsbG93ZWQuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZXZlcmFsIHZvaWNlcyBpbiB0aGlzIHRocmVh ZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGY8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3Nob3VsZCBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHByb3ZpZGVkIGluc3RlYWQu PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBDaGVlcnMsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgTWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0O0RlIDogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGUgSmlt IEd1aWNoYXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyhqZ3VpY2hhcik8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RW52b3k8c3BhbiBsYW5nPSJaSC1DTiI+w6k8L3NwYW4+IDogdmVu ZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O8OA IDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNh bGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9o aWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxs KiBTRkY8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlm aWVyIHBvaW50IHRvIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvb2t1cDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtpbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBp biB0aGUgY2hhaW4sIEkgYW0gbm90PGJyPg0KJmd0OyZndDtzdXJlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtob3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7dGhlIGFyY2hpdGVjdHVyZSBwcmV2 ZW50cyB0aGF0Pzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7T24gNy8xMS8xNCwgOTo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9h PiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDtBYnNvbHV0ZWx5Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IEZyb206IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGpndWljaGFyKTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzogTkFQSUVSQUxBLCBNQVJJQSBI OyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDst KSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdCBp Zjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB5b3UgYWxsb3cgYW4gU0ZGIHRv IG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0PGJyPg0KJmd0OyZndDt3 aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDt1c2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDtmb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYSBnaXZlbiBm bG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3U8YnI+DQom Z3Q7Jmd0O2JldHRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWFrZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVj ZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlYWNoPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5 b3UgYXJlIGluIGRlZXAgdHJvdWJsZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMS8xNCwgOTo0OCBB TSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4x OTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O0Fic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlu cyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW48YnI+DQomZ3Q7Jmd0O3JlbGV2YW50PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U0ZGczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7d2hlbiB0aGV5ICZxdW90O2Fycml2ZSZxdW90Oy48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIEppbTxicj4NCiZndDsmZ3Q7R3VpY2hhcmQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsoamd1aWNoYXIpPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5 OjI3IEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBK b2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFdlbGwgSSB0aGluayBp dCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZDxicj4NCiZndDsm Z3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7cHJvcG9z YWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgY29ycmVjdGx5 IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlPGJyPg0K Jmd0OyZndDtTRjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dpdGhpbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVy eSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0bzxicj4NCiZndDsmZ3Q7a25vdzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0O3ByaW9yaTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB3aGljaCBTRkM8c3BhbiBsYW5nPSJaSC1DTiI+wrk8L3NwYW4+cyBhIGdpdmVuIFNGRiB3aWxs IG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW48YnI+DQomZ3Q7Jmd0O3BvaW50PGJyPg0KJmd0 OyZndDsgJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RpbWUu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAm cXVvdDtKb2VsIE0uIEhhbHBlcm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1JvbiwgdGhp bmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW08YnI+DQom Z3Q7Jmd0O3dpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3lvdXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0O3Byb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFuZCBJ IHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7dW5kZXJzdGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7aXQuKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtUaGUg cHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvciB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25leHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0O3NlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0IChub3Qg dGhlIG9uZSBpdCBkZWxpdmVyczxicj4NCiZndDsmZ3Q7dG8pLDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7aW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtldmVyeTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBjaGFpbiB0aGF0 IGdvZXMgdGhyb3VnaCBpdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhh dCBtZWFuczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtTRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vu c2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7YmFsYW5jZXIuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDtJIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFu ZCAvIG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzdGF0ZWZ1bC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0J1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVy ZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2Zsb3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O3Nl bnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FjY2VwdGFibGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0O2ltcG9zaXRpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0O1lvdXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Sm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDtPbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBQYXJ0IG9m IG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXM8YnI+DQom Z3Q7Jmd0O3dvcms8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtz ZW5zaWJseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRo ZTxicj4NCiZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhl IFNGRiBjYXBhYmlsaXRpZXMsPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDtiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZpY2UgY2hhaW5z PGJyPg0KJmd0OyZndDt0byBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0O2RyaXZlbiBieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMs IGFuZCBlbmFibGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtzZWxmLXNlbGVj dGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkgcG9saWN5 PGJyPg0KJmd0OyZndDsgJmd0OyZndDtkcml2ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsgSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0 IHdvcmsgaW4gYW4gYXJjaHRpZWN0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtkcml2ZW48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRv IGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aGFy ZGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtzZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0 IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgZHluYW1pY2l0eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yayBiZWhhdmlvci48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgSGF2aW5nIHNh aWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtvdXRzaWRlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgc2NvcGUgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDt0YXNrZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDthZ3JlZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0O29uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRv IGRvIGl0IGE8YnI+DQomZ3Q7Jmd0O2NlcnRhaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDt3YXkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 aXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg aXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFlvdXJzLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKb2VsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IE9uIDcvMTAv MTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBGb3IgbWUsIHRoZSBhbW91bnQgb2Yg aW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7bmVlZHM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRp YWxseSBldmVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDthY3Jvc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtkYXRhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRp dmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNvbXBsZXg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBlbm91Z2ggdGhhdCB0cnlpbmcgdG8g Z2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDtkaWZmaWN1bHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBJ J20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW48YnI+DQom Z3Q7Jmd0O2R5bmFtaWM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcm91dGlu Zyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9m PGJyPg0KJmd0OyZndDt3aGljaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXJlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YmlnZ2VyPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm9ibGVtcyB0aGF0IGhh dmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSXQgYWxzbyBzZWVt cyB0aGF0IGlmIGl0IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNhdGVkLCB0aGF0PGJyPg0KJmd0OyZn dDtpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O2dvb2Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogSm9lbCBNLiBIYWxwZXJuIFs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT5dPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzogUm9uIFBhcmtl cjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Ij4NCm1pa2ViaWFuY0Bhb2wuY29tPC9hPjs8YnI+DQomZ3Q7Jmd0O0lhbjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NtaXRoOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQ8YnI+DQomZ3Q7Jmd0O0JhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoaXMgaXMgYW4gYXJjaGl0 ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQ8YnI+DQomZ3Q7Jmd0O3ByZWZlcjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YWN0dWFsbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5 aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW1wbGVtZW50 YXRpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRy b2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlcXVpcmVtZW50czxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGb3IgbWUsIHRoZSBhbW91bnQg b2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbmVlZHM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGJlIHdpZGVseSBkaXN0 cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbjxicj4NCiZndDsmZ3Q7IGFj cm9zczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNlbnRlcnMgd2l0 aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2g8YnI+DQomZ3Q7Jmd0 O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2NvbXBsZXg8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGVub3VnaCB0 aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RpZmZpY3VsdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYXJjaGl0ZWN0dXJlIHRvIHJl YWxpemUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiA3 LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaXMgdGhlIGNydXgg b2YgbXkgaXNzdWUuIElzIHRoZSBlbmQgdG8gZW5kPGJyPg0KJmd0OyZndDtzZWxlY3Rpb248YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1l ZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7Y2xhc3NpZmllcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5 IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Ro ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O1NGRnMpPzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uPGJy Pg0KJmd0OyZndDtBbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtzdXJlbHks PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgJnF1b3Q7aW1wbGVtZW50YXRpb24mcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBNeSBvd24gdmlldyBp cyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbjxicj4NCiZndDsmZ3Q7IHRo b3VnaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBncmVhdGVyIGFtb3VudCBvZiBkYXRh IChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwczxicj4NCiZndDsmZ3Q7bG9jYWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtzZWxlY3Rpb248YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwb2xp Y3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFu IGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtNeTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkgZHJpdmVu PGJyPg0KJmd0OyZndDtieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0O2luY3JlYXNlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBhdGggaWQgYXBw cm9hY2guIFdpdGggYTxicj4NCiZndDsmZ3Q7Z2xvYmFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7cGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0O2lkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5k IG5lZWRpbmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FsdGVyPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2gg YW5kIGV2ZXJ5IGFmZmVjdGVkPGJyPg0KJmd0OyZndDtlbmQtdG8tZW5kPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7cGF0aC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFJvbjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBbPGEgaHJl Zj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d IG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpq bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208L2E+ XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCw8YnI+DQomZ3Q7Jmd0OzIwMTQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyA2OjE1PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFBNPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgVG86IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5j b208L2E+OyA8YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPg0KSS5TbWl0aEBGNS5jb208 L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyZndDsgU3ViamVjdDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBSZTo8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlIHdh eSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZzxicj4NCiZn dDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbmZs dWVuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlv biBhdCB0aGU8YnI+DQomZ3Q7Jmd0O2V4aXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Zyb208YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBTRjEuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVu dCBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvZ2ljYWxseTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcGFyYXRl IHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgY2hvb3NlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBjb21wb3NlIHRoZW0gZm9yICZxdW90O3NlcnZpY2UmcXVvdDsgZGVsaXZlcnkuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNjoxMCBQTSwgPGEgaHJl Zj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4gd3JvdGU6 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3Vn Z2VzdHMgYW55PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzb3J0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0 byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3BhdGg8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsoYWxsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNGSXMpIG11c3Qg YmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0aW9uLiBJIGJlbGlldmU8YnI+DQomZ3Q7Jmd0O3Ro aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDttZWFuczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlaXRo ZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXI8YnI+DQomZ3Q7Jmd0 O2Nob29zZXMgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgdGhlIE5GIG9yIGF0IHRo ZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEgbW9yZSBkeW5h bWljIFNGUCB3aGVyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNGSShuKTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXRlcm1pbmVkIGF0IHRoZSBTRkko bi0xKSBob3AuIEFjY29yZGluZyB0byB0aGUgZHJhZnQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0 aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgJnF1b3Q7YnJhbmNoaW5n JnF1b3Q7IHRvIGEgbmV3IFNGUCBhczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBvcHBvc2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVjdGVkIGlu c3RhbmNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV4dC1ob3Agb2Yg dGhlIGN1cnJlbnQgU0ZDLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hp dGVjdHVyZS0wMDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRv IHRoZSBuZXR3b3JrIGl0IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtuZWNlc3Nhcnk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VsZWN0IHRoZSBz cGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7YW5kIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kg Zm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25ldHdvcms8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGxvY2F0b3IuIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRz IGluIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2NyZWF0aW9uPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3I8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2ZvcndhcmRpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhY2tldHMgdGhy b3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3I8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25vbi1pbml0aWFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlv bikgYXMgd2VsbC4gQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWNs YXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY2xhc3NpZmljYXRpb24gZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2U8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Z1bmN0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVjbGFzc2lmaWNh dGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O1NGUCwgYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRh ZGF0YSwgb3IgYm90aC4gVGhpcyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVmZXJyZWQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgJnF1b3Q7 YnJhbmNoaW5nJnF1b3Q7Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKkZyb206IDxhIGhyZWY9Im1haWx0bzoqSS5TbWl0 aEBGNS5jb20iPipJLlNtaXRoQEY1LmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOkkuU21pdGhA RjUuY29tIj5JLlNtaXRoQEY1LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzogKkpvZWwgSGFscGVy bjxicj4NCiZndDsmZ3Q7IERpcmVjdCZsdDs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2Vs aGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPiZndDssSm9lbDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IE0uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O0hh bHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5o dWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuJTBi Ij5odWFuZ0BzY2UuPGJyPg0KPC9hPiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBjYXJsZXRvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDtjYSZndDssPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKlNlbnQ6ICpUaHVy c2RheSwgSnVseSAxMCwgMjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDtCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWluZy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3lt ZW50cyAoYW5kPGJyPg0KJmd0OyZndDt0aGF0IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7d2hhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBv ZiBzZXJ2aWNlIGNoYWlucyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3By ZWNvbmNlaXZlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0 dXJlIGJ1cmRlbmVkIHdpdGg8YnI+DQomZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByZWNvbmNlcHRp b24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwg c29tZSBkZWdyZWUgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FzcGlyYXRpb248YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0 aGUgbGlmZXNwYW4gb2YgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmNoaXRlY3R1cmU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDstPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHlvdSBkb24ndCBoYXZl IHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7YXJiaXRyYXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBpcyAmcXVvdDt0 b28gZmFyJnF1b3Q7LCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW50ZW50aW9uYWw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg LSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3Rpbmc8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2ltcGFjdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnYXJkaW5nIHNjYWxlLW91dCwg ZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWRk cmVzczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJv YmxlbSBJJ20gbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJv bTogSm9lbCBIYWxwZXJuIERpcmVjdCBbPGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhh bHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtTZW50Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRv OiBJYW4gU21pdGg7IEpvZWwgTS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIYWxwZXJuOzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2Fy bGV0b24uY2E8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3Jn PC9hPiBTdWJqZWN0OiBSZTogW3NmY108YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NlcnZpY2U8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVnYXJkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O0k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDthbTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRp b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Byb2hpYml0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlcGxveW1lbnRzIGlu IHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0bzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7SHVhbmcnczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQg c3VjaCBkZXBsb3ltZW50cyBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyByZXF1aXJlZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFzIEkgaGF2 ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdDxicj4NCiZndDsm Z3Q7c3VjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Ig bm90IGRlcGVuZHMgdXBvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1hbnk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFj dG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvPGJyPg0KJmd0 OyZndDt0aGluazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIHVzdWFsbHkgYSBiYWQg aWRlYS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5 IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2tub3c8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGFuZCBpcyBub3Qg ZXBsb3lhYmxlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRp c2FncmVlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRl ZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0O21pbGxpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25jdXJyZW50IGZs b3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVudmly b25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW48YnI+DQom Z3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQg b2YgdG9tb3Jyb3cgeW91PGJyPg0KJmd0OyZndDsgYXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg b25seTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBnb2luZzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVh bGx5PGJyPg0KJmd0OyZndDtzbWFsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBudW1iZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgJnF1b3Q7bm8gb25lIHdpbGwg ZXZlciBuZWVkIG1vcmU8YnI+DQomZ3Q7Jmd0OyB0aGFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IDY0SyZxdW90Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbWZvcnQu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbPGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIG9u IGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYSI+ aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocyw8YnI+DQomZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0O0xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRvIGRlcGxveSB0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthcmNodGlldHVyZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2Y8 YnI+DQomZ3Q7Jmd0O3RoZWlyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJl IGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQ8YnI+DQomZ3Q7Jmd0OyB1c2U8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4g bm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmFsIHdv cmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlPGJyPg0KJmd0OyZndDtkb2VzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7cGVybWl0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNo IGFidXNlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBkbyBub3QgcmVhZCBteSBz YXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlPGJyPg0KJmd0OyZndDsgcGVybWl0czxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc29tZXRoaW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJl ZCBieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzbid0Ljxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwg NDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB5b3Ug bmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbDxicj4NCiZndDsmZ3Q7 bWVhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRo YW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7Jmd0O3RhYmxlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtv ZiBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29yZSByb3V0ZXIuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBDaGFuZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gMDcv MTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCBmcm9t PGJyPg0KJmd0OyZndDsxPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aCB0byAxNjAw MDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlPGJyPg0KJmd0OyZndDt0aGF0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMg aWYgdGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hvb3NlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXZvaWQgYW55IHVzZSBvZiBs b2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBw cm92aXNpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA0OjA2IFBNLCBO QVBJRVJBTEEsIE1BUklBIEggd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsLDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBtYW55 IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNoYWluIHdpdGggMjAg aW5zdGFuY2VzIGF0IGVhY2ggaG9wPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE1hcmlhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSAqT24gQmVoYWxmPGJyPg0K Jmd0OyZndDsgT2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpQYXVsIFF1aW5uIChwYXVscSkg KlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Mzow Mzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIDxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj4NCmptaEBqb2VsaGFscGVybi5jb208L2E+ Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Ow0KPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFv bC5jb208L2E+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyBDaGFp bnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTHVjeSw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdmVyYWxsIEkg Y29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZm9yd2FyZGluZy4gSTxzcGFuIGxhbmc9IlpILUNOIj7CuTwvc3Bhbj5kPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG1ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBw YXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkZXJp dmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNz b2NpYXRlZCB0cmFuc3BvcnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2Vk IHRvPGJyPg0KJmd0OyZndDtzaW1wbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZ5 IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHM8YnI+DQomZ3Q7Jmd0O211 c3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlk ZW50aWZpZXIsIHRoZSBleGFjdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaXJlY3Rpb24g dGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uPGJyPg0KJmd0OyZndDt0aGlzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRl ZC4gVGhlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpZGVudGlmaWVyPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCBs b29rdXAgY2FuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcmVzdWx0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5l eHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhvcChzKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwg THVjeSB5b25nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1 Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJTNlIj5t YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg QWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNlIG9mPGJyPg0K Jmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWN0aW9u cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMdWN5 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206 KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiI+bWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSpPbjwvYT4gQmVoYWxmPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+T2YqbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAqU2VudDoqVGh1cnNkYXksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEwLCAyMDE0 IDI6MDYgQU0gKlRvOjxhIGhyZWY9Im1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20iPiptaWtlYmlh bmNAYW9sLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWls dG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tJmd0OztqbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0Bp ZXRmLm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNl PGJyPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBz ZXJ2aWNlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZXIuIEkgb2JqZWN0 IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG88YnI+DQomZ3Q7Jmd0O2Rlcml2ZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBhY3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2 ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBldmVyeTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhdmFpbGFibGUgU0ZDPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nIHBh dGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVk L2p1c3RpZmllZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9yIHBvc3NpYmxlIGluIHZhcmlv dXMgZGVwbG95bWVudCBjb250ZXh0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRo ZSBwaWVjZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhhdCB3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBwcmVzZW50IGluIGFsbCBkZXBs b3ltZW50czogdGhhdCBpcyB0aGUgb25lPGJyPg0KJmd0OyZndDsgcmVxdWlyZWQ8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RydWN0dXJlIGEgc2Vy dmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3VzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndhcmRpbmc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYWN0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBzb2x1dGlvbi1vcmllbnRl ZCBkaXNjdXNzaW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAqRGUgOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUi Pm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGU8L2E+IGxhIHBhcnQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tIj5kZSptaWtlYmlhbmNAYW9sLmNvbTwv YT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7ICpFbnZveTxzcGFuIGxh bmc9IlpILUNOIj7DqTwvc3Bhbj4gOiptZXJjcmVkaSA5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg anVpbGxldDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMjAxNCAyMjowMyAqw4AgOjxhIGhyZWY9 Im1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFscGVybi5jb208L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20lM2U7c2ZjQGlldGYub3JnIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7c2Zj QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqT2JqZXQgOipSZTog W3NmY10gU2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW5zLDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElzIGFueW9uZSBzdGlsbCBxdWVzdGlvbmlu ZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuPGJyPg0KJmd0OyZndDtTRjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IENoYWluPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgU0Y8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0 aD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVm aW5pdGlvbiBzbyB0aGF0IGl0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsZWFyIHRvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRob3NlIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFtaWxpYXIgd2l0aCB0aGUg ZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmU8YnI+DQomZ3Q7Jmd0O2FncmVlczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXNlIHRlcm1zLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvIG1lLCB0 aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpczxicj4NCiZndDsmZ3Q7d2hldGhl cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hhdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dGhlIElEPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiB0aGUgU0ZD IEhlYWRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBzaG91bGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVyZW5j ZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7c2ltcGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlbmRzIHRvIGxlYXZl IHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlcjxicj4NCiZndDsmZ3Q7ZHJhZnRzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGljdGF0ZSB0aGUg bWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbjxicj4NCiZndDsmZ3Q7IG9y PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9y PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHBhdGggdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIG5lZ290aWF0ZWQg aW4gdGhlIGNvbnRyb2wtcGxhbmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQg d291bGQgaGF2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZSB0aGF0IGJvdGggU0ZQ IGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb25l PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFs KSB0byBhdm9pZCBzb21lPGJyPg0KJmd0OyZndDsgdmVuZG9yczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IG9ubHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhl cnMgb25seSBzdXBwb3J0aW5nIFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbTo8YSBocmVmPSJt YWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUz ZSI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJmd0Ozwv YT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86PGEgaHJlZj0ibWFpbHRvOipzZmNA aWV0Zi5vcmciPipzZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlIj5tYWlsdG86c2ZjQGlldGYu b3JnJTNjc2ZjQGlldGYub3JnJmd0OzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgKlNlbnQ6KlR1ZXNk YXksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSnVseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg OCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQ8YnI+DQom Z3Q7Jmd0O0xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBiZWVuIHRyeWlu ZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5PGJyPg0KJmd0OyZndDthbnN3ZXI8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBvZiBjb21t ZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBwcm9wb3NlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWVyZ2VkIGFy Y2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldDxicj4NCiZndDsmZ3Q7IHdvcmtp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50 LCB3ZSB3aWxsIHdvcmsgdG88YnI+DQomZ3Q7Jmd0OyBpbXByb3ZlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JkaW5nIHNvIHRoYXQgcmVhZGVy cyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBXRzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzY3Vz c2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JraW5nPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBpbnRlbmRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxs IHRyeSB0byBleHBsYWluIG15PGJyPg0KJmd0OyZndDsgJmd0OyZndDtwZXJzb25hbDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoaXMgcmVnYXJkLCBp dCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3doYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0 YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlPGJyPg0KJmd0OyZndDthcmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF0dGVtcHRpbmcgdG8gZGVmaW5l IHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29tcGFzczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kg ZnVuY3Rpb25zLDxicj4NCiZndDsmZ3Q7dmlydHVhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXI8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBhc3BlY3RzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVh cmx5IG5lZWQ8YnI+DQomZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhpc3Qg aW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7YWJvdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZXJlIHdlIGFyZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBmdW5jdGlvbmluZyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBhcmUgbm90 IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZTxicj4NCiZndDsmZ3Q7IGRvaW5n Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIG9y ZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCw8YnI+DQomZ3Q7Jmd0 O2FzIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVuZGVyc3RhbmQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbSw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFs YW5jaW5nLiBUaGVyZSBhcmUgYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xlYXN0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5n IGNhbiBhbmQ8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVy YWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDttb3JlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHBvaW50IG9mIHRo ZSBhcmNodGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dGhlc2UsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBh bnkgcGFydGljdWxhciBraW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHVzZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGluIGFueSBzb2x1dGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8g dGhlIGVuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyPGJyPg0KJmd0 OyZndDtwYWNrZXRzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBtb2RpZmllcyB0aGVtIChvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXJrczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2Vydmlj ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW5zdGFuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9u IHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7SXQnczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3IgbWF5IGFmZmVj dCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjaGFp bmluZyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxp dHRsZSBpbXBhY3Qgb24gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmNodGllY3R1cmUuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZl IGl0IGlzIHNpbXBseSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Ljxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIpIFRoZXJlIGlzIGlu dGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmU8YnI+DQomZ3Q7Jmd0O2Nhbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7aGF2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hhdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhcHBlYXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byB0aGUgc2VydmljZSBjaGFp bmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGU8YnI+DQomZ3Q7Jmd0O3BvaW50PGJyPg0KJmd0 OyZndDsgJmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29udGFjdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBmb3IgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BlY2lmaWMgc2VydmljZSBmdW5jdGlv biwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YnkgYTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBjb2xsZWN0aW9uIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2aXJ0dWFsIG9y IHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmc8YnI+DQomZ3Q7Jmd0O29uZSBv cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4 YW1wbGUgdXNpbmcgVlJSUC1saWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0ZWNobmlxdWVz IHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lPGJy Pg0KJmd0OyZndDsgJmd0OyZndDttZWNoYW5pc21zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEl0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRv IHZhcmlvdXMgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcyw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxlLWlu LCBzY2FsZS1vdXQsIDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDt2bTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVjdHVyYWwg aW1wYWN0IG9mIDxicj4NCiZndDsmZ3Q7cGVybWl0dGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8g YmUgY2FyZWZ1bCB0aGF0IG91cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGVybWlub2xvZ3k8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGxlYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhZGVycyB0bzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Ljxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDMpIFRoZXJlIGNh biBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgPGJyPg0KJmd0OyZndDtzZWxlY3Rpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hh aW5pbmcgdGhhdCBkaXJlY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RyYWZmaWM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRv IHJlcXVpcmU8YnI+DQomZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5 IG9uZSBwbGFjZSBpbiA8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bmV0d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgPGJyPg0KJmd0OyZn dDtjb21iaW5lZC4gSTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRlbmQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVyIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtjaGFpbmluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYSBzaW5n bGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIDxicj4NCiZndDsmZ3Q7 aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdvb2Qg dGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS48YnI+DQomZ3Q7Jmd0 OyBUaHVzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHRvPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBk aWZmZXJlbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Npbmd1bGFyPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNl cyA8YnI+DQomZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkg dGFsayBhYm91dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBjaGFpbiBhbmQgc2Vy dmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZXF1 ZW5jZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgbG9naWNhbCBmdW5jdGlvbnMgdG8gYmUg YXBwbGllZCB0byBhIHN1YnNldCBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGFja2V0cy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29t ZSBzdWJzZXQgb2YgPGJyPg0KJmd0OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDtp czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQg aW5zcGVjdGlvbiwgYW5kIDxicj4NCiZndDsmZ3Q7ZmlyZXdhbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUg PGJyPg0KJmd0OyZndDtjYWNoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXRob3V0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhdCBpcyBub3QgZW5vdWdoIGlu Zm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgPGJyPg0KJmd0OyZndDtwYWNrZXRzLjxicj4NCiZndDsm Z3Q7IEE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBm YXNoaW9uLCBhIHNlcXVlbmNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2NhdGlvbnM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2ls bCBiZSBzaW5ndWxhciBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2x1c3RlcmVkIHNlcnZp Y2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDttYXkgYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNz LiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXM8YnI+DQomZ3Q7Jmd0OyBwb3J0czxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBTRkYuIFRoZXJlIGFy ZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2Nh dGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heSBiZSBrbm93biB0byB0aGUgc2Vydmlj ZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZTxicj4NCiZndDsmZ3Q7IGFuZDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0Ljxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIHRoZSBw b2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgPGJyPg0KJmd0OyZndDtncm91cCw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5l ZWQgdG8gYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFibGUgdG8gdGFsayBhYm91dCB0aGUg aGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJk aW5nLiBBbmQgd2UgbmVlZCB0bzxicj4NCiZndDsmZ3Q7IHRhbGs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRo ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZl IHNhaWQgJnF1b3Q7YnV0IHRoZSB3aG9sZTxicj4NCiZndDsmZ3Q7IHBhdGg8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBtYXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBiZSBrbm93biBhdCB0 aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDt3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGlzc3VlIGluIHR3byB3YXlz LiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgPGJyPg0KJmd0OyZndDtvbjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7bG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmFsYW5jZXJzIGFib3Zl LCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCA8YnI+DQomZ3Q7Jmd0O2JlaGF2aW9yczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHdoaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmUgaW52 aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluPGJyPg0KJmd0OyZn dDsgJmd0OyZndDttdWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc2FtZSB3YXkgdGhh dCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyPGJyPg0KJmd0 OyZndDsgcHJvdmlzaW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG1ha2UgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg cmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYXQgd2ls bCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb248YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24g PGJyPg0KJmd0OyZndDtwb2ludC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUg YWZ0ZXIuIDxicj4NCiZndDsmZ3Q7SWYgaXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMs IGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmc8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBncm91cCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGNhbiBmaWd1 cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkPGJyPg0KJmd0OyZndDsgdG88 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91 cCBkaXNhZ3JlZSB3aXRoIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGludGVudCw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNo IHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDtncm91cDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBz dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0cnkgbmV4dC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9h PiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h Pjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg c2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgc2ZjIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h Pjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmM8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7CMBX021W3CA2exch_-- From nobody Mon Jul 14 06:12:57 2014 Return-Path: <lucy.yong@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8891A03C5 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fda9TfWd7yli for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:12:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FAA1A03C9 for <sfc@ietf.org>; Mon, 14 Jul 2014 06:12:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA37865; Mon, 14 Jul 2014 13:12:45 +0000 (GMT) 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; Mon, 14 Jul 2014 14:12:44 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 06:12:35 -0700 From: Lucy yong <lucy.yong@huawei.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8ZtSqAftugz0CPuFwsDNNeGpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHID///EV4AAP5B4AAACNtoAAAGwJAAAA+u8AAAEZogAAACsQgAAANv0AAAA3lIAADkKxEAAfSjcAAFL52eA= Date: Mon, 14 Jul 2014 13:12:35 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BF5C1@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF05@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE588EF.2D565%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AF71@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE58BE8.2D5A2%jguichar@cisco.com>, <2691CE0099834E4A9C5044EEC662BB9D453BF11D@dfweml701-chm.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6363@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6363@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.109] 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/XvgY9DEM5v-B5EoxL4DHtHt2evw Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 13:12:55 -0000 Hi Ron, Agree, when there are multiple founded next hops (after lookup), use of a L= B to select one of the next hops may occur in the two cases mentioned below= .=20 Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Saturday, July 12, 2014 9:28 AM To: Lucy yong; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Hi, Lucy. I've heard next hop mentioned many times and I'm not sure that the term is = really valid here. There seems to be an assumption that routing is implic= itly involved, but it is possible that the service overlay resides on a pur= ely switched infrastructure. Even if the service overlay resides on a rou= ted infrastructure, that routing is abstracted in the typical layered fashi= on. For SFC, the issue is to select the next SFF or select the next SFI. = Once that selection is made, routing takes over. But knowing that SFF-B= could serve as a backup to SFF-A is above the routing layer (or at least c= ould be in some implementations). Perhaps we could introduce a term like = next-service-hop or next-SFC-hop to make this distinction? Ron ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Lucy yong [lucy.yong@huawei.c= om] Sent: Friday, July 11, 2014 1:23 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I like to restate my opinion. The arch doc. should not mandate only use of service path identifier to dri= ve the forwarding actions, i.e. the forwarding lookup. Although some solution draft proposes that and some people like Paul and Ji= m as co-author of the draft (nsh) explain that, that is one solution design= . The arch doc clearly states that it does not propose the solutions. In fact, draft-nui-sfc-mechanism proposes another way to implement SFC whic= h uses both service path identifier and SF ID in forwarding actions. People also proposed the solution on mail discussion that does not use the = service path identifier to drive the forwarding actions. So we should not = make a solution assumption in arch doc. BTW: IMO, we should separate the forwarding actions and load balance action= s. Load balancing discussed here happens when several next hops exist after= forwarding lookup. (this is not about load balancing as a SF). Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, July 11, 2014 11:44 AM To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. Halpern; Ron = Parker; sfc@ietf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers I am not proposing a solution (that's the WG's job) but simply using my int= erpretation of the architecture to move the discussion forward. Yes, it is still a service path identifier for the reasons that Joel mentio= ned in another email. On 7/11/14, 12:37 PM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote: >> >> I think of it this way. The service path identifier is simply a >>pointer >> >>to >> >> a data structure that contains SF to next-hop mappings. When you >> define >> >You are talking about traffic engineering of paths that a service >> >chain can take. >> >This surely could be done/allowed but this cannot be a requirement >> >for all traffic. >> >> Jim> that's why I said *might* - IOW you do not have to, its a >>deployment >> choice and is supported by the architecture. > >Yes, I noticed, but I also noticed that you are proposing a solution >based on it. > >You have not comment on the rest: is it still "service *path* identifier"? > >Maria > >> >> On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> wrote: >> >> >> >> >Jim, >> >> > >> >> >Could you tell us what is the definition of a "service path" and >> >> >a "service path identifier"? >> >> >If a service path means that all SF instances are chosen apriori >> >>(which >> >> >is my current understanding) then it is not SFF's local decision >>which >> >> >next-hop SFF to pick. It is a centralized decision. >> >> > >> >> >Maria >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> >> >> Sent: Friday, July 11, 2014 11:15 AM >> >> >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; Joel M. >> >> >> Halpern; Ron Parker; sfc@ietf.org >> >> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >> >> I'm sorry but I really don't understand why a service path >>identifier >> >> >> prevents full distribution of SF next-hops or why calling it a >> >>service >> >> >> chain identifier makes any difference? >> >> >> >> >> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> >> wrote: >> >> >> >> >> >> >Ditto. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: mohamed.boucadair@orange.com >> >> >> >> [mailto:mohamed.boucadair@orange.com] >> >> >> >> Sent: Friday, July 11, 2014 10:31 AM >> >> >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. >>Halpern; >> >> Ron >> >> >> >> Parker; sfc@ietf.org >> >> >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >> >> >> >> Re-, >> >> >> >> >> >> >> >> For what I can say at best this is not described clearly in >> >> >> >> the >> >> >>draft. >> >> >> >> >> >> >> >> Mandating a service path identifier is in itself a hint that >>the >> >>full >> >> >> >>distributed >> >> >> >> model is not allowed. >> >> >> >> >> >> >> >> Several voices in this thread indicated that the service >> >> >> >> chain >> >>itself >> >> >> >>should be >> >> >> >> provided instead. >> >> >> >> >> >> >> >> Cheers, >> >> >> >> Med >> >> >> >> >> >> >> >> >-----Message d'origine----- De : sfc >> >> >> >> >[mailto:sfc-bounces@ietf.org] De la part de Jim >>Guichard >> >> >> >> >(jguichar) >> >> >> >> >Envoy=E9 : vendredi 11 juillet 2014 16:18 =C0 : NAPIERALA, >> >> >> >> >MARIA H; Joel M. Halpern; Ron Parker; >> sfc@ietf.org >> >> >> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> > >> >> >> >> >Ok but where in the architecture specifically is this >> >>functionality >> >> >> >> >prohibited? If you want to distribute *all* next-hops to >> >> >> >> >*all* >> >>SFF's >> >> >> >> >within the SFC domain and then let the path identifier >> >> >> >> >point >>to a >> >> >> >>lookup >> >> >> >> >into those next-hops to reach the next SF in the chain, I >> >> >> >> >am >>not >> >> >>sure >> >> >> >>how >> >> >> >> >the architecture prevents that? >> >> >> >> > >> >> >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> >> >> >> wrote: >> >> >> >> > >> >> >> >> >>Absolutely. >> >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >> >>Guichard >> >> >> >> >>>(jguichar) >> >> >> >> >>> Sent: Friday, July 11, 2014 9:54 AM >> >> >> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; >> >> sfc@ietf.org >> >> >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load >>Balancers >> >> >> >> >>> >> >> >> >> >>> Then I misunderstand the proposal ;-) .. However, it >> >> >> >> >>> seems >>to >> >>me >> >> >> >>that if >> >> >> >> >>> you allow an SFF to make a decision as to which remote >> >> >> >> >>> SFF >>it >> >> >>will >> >> >> >>use >> >> >> >> >>>for >> >> >> >> >>> a given flow to reach the next SF within the chain then >> >> >> >> >>>you >> >> >>better >> >> >> >>make >> >> >> >> >>> sure that that remote SFF has the necessary forwarding >>logic >> >>to >> >> >> >>reach >> >> >> >> >>>the >> >> >> >> >>> next-next-SF for the chain as otherwise you are in deep >> >>trouble. >> >> >> >> >>> >> >> >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" >> <mn1921@att.com> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>> >Absolutely not. Service chains can be instantiated only >> >> >> >> >>> >in >> >> >>relevant >> >> >> >> >>>SFFs >> >> >> >> >>> >when they "arrive". >> >> >> >> >>> > >> >> >> >> >>> >> -----Original Message----- >> >> >> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> >> >> >> >>> >> Jim >> >> >>Guichard >> >> >> >> >>> >>(jguichar) >> >> >> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM >> >> >> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >> >> >> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load >> >>Balancers >> >> >> >> >>> >> >> >> >> >> >>> >> Well I think it is even worse than that if I have >> >>understood >> >> >>the >> >> >> >> >>> >>proposal >> >> >> >> >>> >> correctly as it would require full knowledge of every >> >>single >> >> >>SF >> >> >> >> >>>within >> >> >> >> >>> >>the >> >> >> >> >>> >> entire SFC domain at every single SFF as there is no >>way to >> >> >>know >> >> >> >>a >> >> >> >> >>> >>priori >> >> >> >> >>> >> which SFC=B9s a given SFF will need to service at any >>given >> >> >>point >> >> >> >>in >> >> >> >> >>>time. >> >> >> >> >>> >> >> >> >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" >> >> <jmh@joelhalpern.com> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >> >>> >> >Ron, thinking about this, I realized another major >>problem >> >> >>with >> >> >> >>the >> >> >> >> >>> >>your >> >> >> >> >>> >> >proposal as I understand it. (And I readily admit I >>may >> >>not >> >> >> >> >>>understand >> >> >> >> >>> >> >it.) >> >> >> >> >>> >> > >> >> >> >> >>> >> >The proposal has each SFF serve as the load balancer >>for >> >>the >> >> >> >>next >> >> >> >> >>> >> >service function that follows it (not the one it >>delivers >> >> >>to), >> >> >> >>in >> >> >> >> >>>every >> >> >> >> >>> >> >service chain that goes through it. >> >> >> >> >>> >> > >> >> >> >> >>> >> >Since it has to be able to work with all services, >> >> >> >> >>> >> >that >> >>means >> >> >> >>that >> >> >> >> >>> >>every >> >> >> >> >>> >> >SFF would have to be a full, flow sensitive and >>stateful >> >>load >> >> >> >> >>>balancer. >> >> >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, >> >> >> >> >>> >> >and >>/ or >> >> >> >>stateful. >> >> >> >> >>> >> >But having the architecture require that every SFF >> >> >> >> >>> >> >be a >> >>full, >> >> >> >>flow >> >> >> >> >>> >> >sensitive, stateful, load balancer seems to me to be >> >> >> >> >>> >> >an >> >> >> >>acceptable >> >> >> >> >>> >> >imposition. >> >> >> >> >>> >> > >> >> >> >> >>> >> >Yours, >> >> >> >> >>> >> >Joel >> >> >> >> >>> >> > >> >> >> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >> >> >> >> >>> >> >> Part of my personal view is that I am trying to >> >> >> >> >>> >> >> make >> >>this >> >> >>work >> >> >> >> >>> >>sensibly >> >> >> >> >>> >> >> in a more orchestrated environment. I expect that >>the >> >> >>service >> >> >> >> >>> >> >> functions, and over time probably the SFF >>capabilities, >> >> >>will >> >> >> >>be >> >> >> >> >>> >> >> orchestrated and installed. I expect the service >>chains >> >> >>to be >> >> >> >> >>> >>driven by >> >> >> >> >>> >> >> BSS tools that define offerings to clients, and >>enable >> >> >> >> >>>self-selection >> >> >> >> >>> >> >> from these. I expect service paths to be heavily >>policy >> >> >> >>drive. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> I can see how to make all of that work in an >> >>archtiecture >> >> >> >>driven >> >> >> >> >>>by >> >> >> >> >>> >> >> initial classification to described service paths. >>It >> >>is >> >> >> >>harder >> >> >> >> >>>to >> >> >> >> >>> >>see >> >> >> >> >>> >> >> how to make it work (but it can be done) when we >>allow >> >> more >> >> >> >> >>> >> dynamicity >> >> >> >> >>> >> >> in the network behavior. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Having said that, most of that perspective I >>described >> >>is >> >> >> >>outside >> >> >> >> >>>of >> >> >> >> >>> >>the >> >> >> >> >>> >> >> scope of the working group. it is not something >> >> >> >> >>> >> >> we >>are >> >> >> >>tasked to >> >> >> >> >>> >>agree >> >> >> >> >>> >> >>on. >> >> >> >> >>> >> >> So I do not claim that vision means we have to do >> >> >> >> >>> >> >>it >>a >> >> >>certain >> >> >> >> >>>way. >> >> >> >> >>> >>it >> >> >> >> >>> >> >> is just the perspective that drives my preferences. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Yours, >> >> >> >> >>> >> >> Joel >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >> >> >> >> >>> >> >>>> For me, the amount of information about service >> >> instances >> >> >> >> that >> >> >> >> >>> >>needs >> >> >> >> >>> >> >>>>to >> >> >> >> >>> >> >>>> be widely distributed and maintained, >> >> >> >> >>> >> >>>>potentially >> even >> >> >> >>across >> >> >> >> >>>data >> >> >> >> >>> >> >>>> centers within an administrative scope, is large >> >>enough >> >> >>and >> >> >> >> >>> complex >> >> >> >> >>> >> >>>> enough that trying to get that into each SFF >> >> >> >> >>> >> >>>> seems >> >>like a >> >> >> >> >>>difficult >> >> >> >> >>> >> >>>> architecture to realize. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> I'm curious as to why that is more complicated >> >> >> >> >>> >> >>> than >> >> >>dynamic >> >> >> >> >>> routing, >> >> >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, >> >> >> >> >>> >> >>> all >>of >> >> >>which >> >> >> >>are >> >> >> >> >>> >>bigger >> >> >> >> >>> >> >>> problems that have been profitably and stably >> >> implemented? >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> It also seems that if it really is more >> >> >> >> >>> >> >>> complicated, >> >>that >> >> >>is >> >> >> >>a >> >> >> >> >>>good >> >> >> >> >>> >> >>> sign that it is too complicated. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> ________________________________________ >> >> >> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com] >> >> >> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >> >> >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; >> mikebianc@aol.com; >> >> >>Ian >> >> >> >> >>>Smith; >> >> >> >> >>> >> >>> sfc@ietf.org >> >> >> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and >> >> >> >> >>> >> >>> Load >> >> >>Balancers >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> This is an architectural issue. And one that I >>would >> >> >>prefer >> >> >> >>we >> >> >> >> >>> >> >>>actually >> >> >> >> >>> >> >>> decide, rather than trying to allow all possible >> >> >> >>implementations. >> >> >> >> >>> >> >>> Because it does have a major effect on the >> >> >> >> >>> >> >>> control >> >> >> >>requirements >> >> >> >> >>>and >> >> >> >> >>> >> the >> >> >> >> >>> >> >>> functionality of SFFs. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> For me, the amount of information about service >> >> instances >> >> >> >>that >> >> >> >> >>> needs >> >> >> >> >>> >> to >> >> >> >> >>> >> >>> be widely distributed and maintained, potentially >>even >> >> >> across >> >> >> >> >>>data >> >> >> >> >>> >> >>> centers within an administrative scope, is large >>enough >> >> >>and >> >> >> >> >>>complex >> >> >> >> >>> >> >>> enough that trying to get that into each SFF >> >> >> >> >>> >> >>> seems >> >>like a >> >> >> >> >>>difficult >> >> >> >> >>> >> >>> architecture to realize. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> Yours, >> >> >> >> >>> >> >>> Joel >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> But it is a fair question. >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >> >> >> >> >>> >> >>>> This is the crux of my issue. Is the end to end >> >> >>selection >> >> >> >>of >> >> >> >> >>> >> >>>> (top-level) instances performed centrally >> >> >> >> >>> >> >>>> (perhaps >>by >> >>the >> >> >> >> >>> >>classifier) >> >> >> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and >> >> subsequently >> >> >> >>the >> >> >> >> >>> >>SFFs)? >> >> >> >> >>> >> >>>> Such selection is not equivalent to >>reclassification. >> >> >>And >> >> >> >> >>>surely, >> >> >> >> >>> >> >>>> this is an architectural issue and not relegated >> >> >> >> >>> >> >>>> to "implementation". >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> My own view is to favor the distributed approach >> even >> >> >> though >> >> >> >> a >> >> >> >> >>> >> >>>> greater amount of data (chain definitions and >>perhaps >> >> >>local >> >> >> >> >>> >>selection >> >> >> >> >>> >> >>>> policy) is required at those distributed >> >> >> >> >>> >> >>>> decision >> >>points. >> >> >> >>This >> >> >> >> >>> >> >>>> approach does not require an end-to-end path id >> >> >> >> >>> >> >>>> at >> >>all. >> >> >> >>My >> >> >> >> >>> >> >>>> rationale for favoring this approach is >> >> >> >> >>> >> >>>> primarily >> >>driven >> >> >>by >> >> >> >> >>> >>increased >> >> >> >> >>> >> >>>> resiliency over the global path id approach. >>With a >> >> >>global >> >> >> >> >>>path >> >> >> >> >>> >>id >> >> >> >> >>> >> >>>> approach, consider failure of an instance and >>needing >> >>to >> >> >> >>alter >> >> >> >> >>>the >> >> >> >> >>> >> >>>> global path ID table for each and every affected >> >> >>end-to-end >> >> >> >> >>>path. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Ron >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> ________________________________________ From: >> sfc >> >> >> >> >>> >> >>>> [sfc-bounces@ietf.org] on behalf of Joel Halpern >> >>Direct >> >> >> >> >>> >> >>>> [jmh.direct@joelhalpern.com] Sent: Thursday, >> >> >> >> >>> >> >>>> July >>10, >> >> >>2014 >> >> >> >> 6:15 >> >> >> >> >>> PM >> >> >> >> >>> >> >>>> To: mikebianc@aol.com; I.Smith@F5.com; >> >> >> >> >>> >> >>>> sfc@ietf.org >> >> >> Subject: >> >> >> >> Re: >> >> >> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> The way the architecture models the case of SF1 >> >>needing >> >> >>to >> >> >> >> >>> >>influence >> >> >> >> >>> >> >>>> the chain is that one would do reclassification >> >> >> >> >>> >> >>>> at >>the >> >> >>exit >> >> >> >>from >> >> >> >> >>> >> >>>> SF1. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Part of the goal is to keep the different >> >> >> >> >>> >> >>>> functions >> >> >> >>logically >> >> >> >> >>> >> >>>> separate so that solutions can clearly describe >> >> >> >> >>> >> >>>> how >> >>they >> >> >> >> choose >> >> >> >> >>>to >> >> >> >> >>> >> >>>> compose them for "service" delivery. >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> Yours, Joel >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com wrote: >> >> >> >> >>> >> >>>>> I don't see anything in the arch draft that >>suggests >> >>any >> >> >> >>sort >> >> >> >> >>>of >> >> >> >> >>> >> >>>>> limit. However, it does seem to indicate that >> >> >> >> >>> >> >>>>> the >> >>entire >> >> >> >>path >> >> >> >> >>>(all >> >> >> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I >>believe >> >> >>this >> >> >> >> >>>means >> >> >> >> >>> >> >>>>> either at the classifier or maybe the >> >> >> >> >>> >> >>>>> classifier >> >> >>chooses a >> >> >> >>SF >> >> >> >> >>> >>Chain >> >> >> >> >>> >> >>>>> and the NF or at the latest the first SFF. In >> >> >> >> >>> >> >>>>> any >> >>case, >> >> >> >>the >> >> >> >> >>> >> >>>>> language does seem to prohibit a more dynamic >> >> >> >> >>> >> >>>>> SFP >> >> where >> >> >> >> SFI(n) >> >> >> >> >>> is >> >> >> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to >> >> >> >> >>> >> >>>>> the >> >>draft, >> >> >> >>this >> >> >> >> >>> >> >>>>> behavior would be considered "branching" to a >> >> >> >> >>> >> >>>>> new >> SFP >> >> as >> >> >> >> >>> opposed >> >> >> >> >>> >> to >> >> >> >> >>> >> >>>>> choosing and then forwarding to the selected >> instance >> >> of >> >> >> >>the >> >> >> >> >>> >> >>>>> next-hop of the current SFC. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> draft-merged-sfc-architecture-00: >> >> >> >> >>> >> >>>>>> When an SFC is instantiated into the network >> >> >> >> >>> >> >>>>>> it >>is >> >> >> >>necessary >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>> select the specific instances of SFs that will >> >> >> >> >>> >> >>>>>> be >> >>used, >> >> >> >>and to >> >> >> >> >>> >> >>>>>> create the service topology for that SFC using >>SF's >> >> >> >>network >> >> >> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC >> >> >> >> >>> >> >>>>>> results >>in >> >>the >> >> >> >> >>>creation >> >> >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used >> >> >> >> >>> >> >>>>>> for >> >> >> >>forwarding >> >> >> >> >>> >> >>>>>> packets through the SFC. In other words, an >> >> >> >> >>> >> >>>>>> SFP >>is >> >>the >> >> >> >> >>> >> >>>>>> instantiation of the defined SFC. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> The SFC architecture supports reclassification >>(or >> >> >> >>non-initial >> >> >> >> >>> >> >>>>>> classification) as well. As packets traverse >> >> >> >> >>> >> >>>>>> an >> >>SFP, >> >> >> >> >>> >> >>>>>> reclassification may occur - typically >> >> >> >> >>> >> >>>>>> performed >>by >> >>a >> >> >> >> >>> >> >>>>>> classification function co-resident with a >>service >> >> >> >>function. >> >> >> >> >>> >> >>>>>> Reclassification may result in the selection >> >> >> >> >>> >> >>>>>> of a >> >>new >> >> >> >>SFP, an >> >> >> >> >>> >> >>>>>> update of the associated metadata, or both. >>This is >> >> >> >>referred >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>> as "branching". >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>>>>>>>>>>>>>>------------------------------------------------------ >>>>>>>>>>>>>>>>>>--- >>>>>>>>>>>>>>>>>>-- >> >>>>>>>>>>>>>>>>-- >> >> >>>>>>>>>>>>>>-- >> >> >> >>>>>>>>>>>>--- >> >> >> >> >>>>>>>>>>-- >> >> >> >> >>> >>>>>>>-- >> >> >> >> >>> >> >>>>>-- >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>> *From: *I.Smith@F5.com<I.Smith@F5.com> >> >> >> >> >>> >> >>>>> *To: *Joel Halpern >> >> >> Direct<jmh.direct@joelhalpern.com>,Joel >> >> >> >> M. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>Halpern<jmh@joelhalpern.com>,huang@sce.carleton.ca<huang@sce. >> >> >> >> >>> >> carleton. >> >> >> >> >>> >> >>>>>ca>,sfc@ietf.org<sfc@ietf.org> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 >> >> >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and >>Load >> >> >> >>Balancers >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Actually, I think I am disagreeing. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> If the possibility of medium-scale deployments >>(and >> >> >>that is >> >> >> >> >>>what >> >> >> >> >>> >> >>>>> 16 million flows is in my world) of service >>chains is >> >> >> >> >>>preconceived >> >> >> >> >>> >> >>>>> as an absurd idea, then the architecture >> >> >> >> >>> >> >>>>> burdened >> >>with >> >> >> that >> >> >> >> >>> >> >>>>> preconception. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> There has to be some point of aim, some degree >> >> >> >> >>> >> >>>>> of >> >> >> >>aspiration >> >> >> >> to >> >> >> >> >>> >> >>>>> scale that is appropriate for the lifespan of >> >> >> >> >>> >> >>>>> the >> >> >> >>architecture >> >> >> >> >>>- >> >> >> >> >>> >> >>>>> you don't have to know what it is, but by >> >> >> >> >>> >> >>>>> saying >> >>that an >> >> >> >> >>>arbitrary >> >> >> >> >>> >> >>>>> number is "too far", you're creating - even if >> >> >> >> >>> >> >>>>> it >> >>isn't >> >> >> >> >>> >>intentional >> >> >> >> >>> >> >>>>> - a limit that influences decisions that have >>lasting >> >> >> >>impacts >> >> >> >> >>> >> >>>>> regarding scale-out, failure mitigation, >>elasticity, >> >> >> >>address >> >> >> >> >>> >> >>>>> space... all kinds of things. That is a problem >>I'm >> >>not >> >> >> >> >>> >> >>>>> particularly eager to deal with. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> ________________________________________ >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> From: Joel Halpern Direct >> >>[jmh.direct@joelhalpern.com] >> >> >> >>Sent: >> >> >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; >>Joel >> >>M. >> >> >> >> Halpern; >> >> >> >> >>> >> >>>>> huang@sce.carleton.ca; sfc@ietf.org Subject: Re: >> >>[sfc] >> >> >> >>Service >> >> >> >> >>> >> >>>>> Chains, Paths, and Load Balancers >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all >> >> >> >> >>> >> >>>>> in >> >>this >> >> >> >>regard. >> >> >> >> >>>I >> >> >> >> >>> >>am >> >> >> >> >>> >> >>>>> not requesting the the architecture or the >>solution >> >> >> >>prohibit >> >> >> >> >>> >> >>>>> deployments in the specific fashion. I am >>objecting >> >>to >> >> >> >>Huang's >> >> >> >> >>> >> >>>>> reading of my note as saying that such >> >> >> >> >>> >> >>>>> deployments >> >>are >> >> >> >> required >> >> >> >> >>> >> >>>>> they by the archtiecture. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to >> >>prohibit >> >> >>such >> >> >> >> >>> >> >>>>> things. Whether they are a good idea or not >>depends >> >> upon >> >> >> >> many >> >> >> >> >>> >> >>>>> factors outside of the scope of the WG. I >> >> >> >> >>> >> >>>>> happen >>to >> >> >>think >> >> >> >>that >> >> >> >> >>> >>they >> >> >> >> >>> >> >>>>> are usually a bad idea. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> But the archtiecture si carefully avoiding >> >>attempting to >> >> >> >>know >> >> >> >> >>>what >> >> >> >> >>> >> >>>>> is and is not eployable. >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> Yours, Joel >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >> >> >> >> >>> >> >>>>>> I disagree. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> We routinely have stateful devices that manage >> tens >> >> of >> >> >> >> >>>millions >> >> >> >> >>> >> >>>>>> of >> >> >> >> >>> >> >>>>> concurrent flows in both access network and >> >> >> >> >>> >> >>>>> data >> >> center >> >> >> >> >>> >> >>>>> environments today. You can't seriously believe >>that >> >>in >> >> >>the >> >> >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of >> >> >> >> >>> >> >>>>> tomorrow >> >> you >> >> >> are >> >> >> >> only >> >> >> >> >>> >> going >> >> >> >> >>> >> >>>>> to have small numbers of service chains with >>equally >> >> >>small >> >> >> >> >>> numbers >> >> >> >> >>> >> >>>>> of active service paths? >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Your sounds too much like "no one will ever >> >> >> >> >>> >> >>>>>> need >> >> more >> >> >> than >> >> >> >> >>> 64K" >> >> >> >> >>> >> >>>>>> for >> >> >> >> >>> >> >>>>> comfort. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> ________________________________________ >> From: >> >> sfc >> >> >> >> >>> >> >>>>>> [sfc-bounces@ietf.org] on behalf of Joel M. >>Halpern >> >> >> >> >>> >> >>>>> [jmh@joelhalpern.com] >> >> >> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >> >> >> >> >>>huang@sce.carleton.ca; >> >> >> >> >>> >> >>>>>> sfc@ietf.org Subject: Re: [sfc] Service >> >> >> >> >>> >> >>>>>> Chains, >> >>Paths, >> >> >>and >> >> >> >> >>>Load >> >> >> >> >>> >> >>>>>> Balancers >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> No, it will mean that if someone tries to >> >> >> >> >>> >> >>>>>> deploy >>the >> >> >> >> >>>archtieture >> >> >> >> >>> >> >>>>>> particularly badly, they will exceed the >> >> >> >> >>> >> >>>>>> limits >>of >> >> >>their >> >> >> >> >>> >> >>>>>> devices. The architecture does not require >> >> >> >> >>> >> >>>>>> such >> >>absurd >> >> >> use >> >> >> >> of >> >> >> >> >>> >> >>>>>> service paths. Since I can not figure out how >> >> >> >> >>> >> >>>>>> to >> >>write >> >> >> >> >>> >> >>>>>> architectural words to prohibit it, the >>architecture >> >> >>does >> >> >> >> >>>permit >> >> >> >> >>> >> >>>>>> such abuse. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Please do not read my saying that the >>archtiecture >> >> >> permits >> >> >> >> >>> >> >>>>>> something as saying it is either deisred or >> >>required by >> >> >> >>the >> >> >> >> >>>work. >> >> >> >> >>> >> >>>>>> It isn't. >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >> >> >> >> >>> >> >>>>>>> If you need to support 100 service chains, it >>will >> >> >>mean >> >> >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the >>routing >> >> >>table >> >> >> >>of a >> >> >> >> >>> >> >>>>>>> core router. >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> Chang >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >> >> >> >> >>> >> >>>>>>>> The architecture allows a range of >> >> >> >> >>> >> >>>>>>>> deployments, >> >> from >> >> >>1 >> >> >> >> >>> >> >>>>>>>> service path to 160000 service paths. I >> >> >> >> >>> >> >>>>>>>> would >> hope >> >> >>that >> >> >> >> >>> >> >>>>>>>> operators are prepared for the complexities >> >> >> >> >>> >> >>>>>>>> if >> >>they >> >> >> >>choose >> >> >> >> >>>to >> >> >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in >>stead >> >> >> >> provision >> >> >> >> >>> >> >>>>>>>> 160,000 service paths. >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H >> wrote: >> >> >> >> >>> >> >>>>>>>>> Paul, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> How many path identifiers there will be for >> >> >> >> >>> >> >>>>>>>>> a >>4 >> >>hop >> >> >> >> service >> >> >> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Maria >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] >> >> >> >> >>> >> >>>>>>>>> *On >> >> Behalf >> >> >> Of >> >> >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July >> >> >> >> >>> >> >>>>>>>>> 10, >> >>2014 >> >> >> >>3:03 >> >> >> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* >> jmh@joelhalpern.com; >> >> >> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com; sfc@ietf.org; >> >> >> >> >>> >> >>>>>>>>> mikebianc@aol.com *Subject:* Re: [sfc] >> >> >> >> >>> >> >>>>>>>>> Service >> >> >> Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Lucy, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID >> >> >> >> >>> >> >>>>>>>>> drives >> >>the >> >> >> >> >>> >> >>>>>>>>> forwarding. I=B9d >> >> >> >> >>> >> >>>>> make >> >> >> >> >>> >> >>>>>>>>> the minor change: the path identifier can >> >> >> >> >>> >> >>>>>>>>> be >> used >> >> to >> >> >> >> derive >> >> >> >> >>> >> >>>>>>>>> the needed forwarding and associated >> transport. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is >> >> >> >> >>> >> >>>>>>>>> used >>to >> >> >>simply >> >> >> >> >>> >> >>>>>>>>> identify the service path (or graph) that >>packets >> >> >>must >> >> >> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the >>exact >> >> >> >> >>> >> >>>>>>>>> indirection that people seem to be asking >> >> >> >> >>> >> >>>>>>>>> for >>on >> >> >>this >> >> >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The >> >> >> >> >>> >> >>>>>>>>> path >> >> >> >> identifier >> >> >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that >> lookup >> >> can >> >> >> >> result >> >> >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) >> >> >> >> >>> >> >>>>>>>>> transport >> >> next >> >> >> >> >>> >> >>>>>>>>> hop(s). >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Paul >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >> >> >> >> >>> >> >>>>>>>>> <lucy.yong@huawei.com >> >> >> >> <mailto:lucy.yong@huawei.com>> >> >> >> >> >>> >> >>>>>>>>> wrote: >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate >> >> >> >> >>> >> >>>>>>>>> only >> use >> >> of >> >> >> the >> >> >> >> >>> >> >>>>>>>>> service path identifier to drive the >>forwarding >> >> >> >>actions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Lucy >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On >> >> Behalf >> >> >> >> >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com >> >> >> >> >>> >> >>>>>>>>> <mailto:mohamed.boucadair@orange.com> >> >> >> >> >>> *Sent:*Thursday, >> >> >> >> >>> >> July >> >> >> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >> >> >> >> >>> >> >>>>>>>>> >> >> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Subject:*Re: [sfc] >>Service >> >> >> >>Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Re-, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a >>service >> >>path >> >> >> >> >>> >> >>>>>>>>> identifier. I object to use that identifier >> >> >> >> >>> >> >>>>>>>>> to >> >> >>derive >> >> >> >> >>> >> >>>>>>>>> forwarding actions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full >> knowledge >> >> of >> >> >> >> every >> >> >> >> >>> >> >>>>> available SFC >> >> >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled >> >> >> >> >>> >> >>>>>>>>> domain >> is >> >> not >> >> >> >> >>> >> >>>>> required/justified >> >> >> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the >>piece >> >>of >> >> >> >> >>> >> >>>>>>>>> information >> >> >> >> >>> >> >>>>> that will >> >> >> >> >>> >> >>>>>>>>> be present in all deployments: that is the >> >> >> >> >>> >> >>>>>>>>> one >> >> >> required >> >> >> >> to >> >> >> >> >>> >> >>>>>>>>> structure a service chain. How that >>information >> >>is >> >> >> >>used to >> >> >> >> >>> >> >>>>>>>>> infer forwarding >> >> >> >> >>> >> >>>>> actions >> >> >> >> >>> >> >>>>>>>>> is a solution-oriented discussion. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Cheers, >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Med >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De >> >> >> >> >>> >> >>>>>>>>> la >> >>part >> >> >> >> >>> >> >>>>> de*mikebianc@aol.com >> >> >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com> *Envoy=E9 >> :*mercredi 9 >> >> >> >> juillet >> >> >> >> >>> >> >>>>>>>>> 2014 22:03 *=C0 :*jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] >>Service >> >> >> >>Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference >> >>between >> >> >>SF >> >> >> >> Chain >> >> >> >> >>> >> >>>>>>>>> and SF >> >> >> >> >>> >> >>>>> Path? >> >> >> >> >>> >> >>>>>>>>> Other than clarifying the definition so >> >> >> >> >>> >> >>>>>>>>> that >>it's >> >> >> >>clear to >> >> >> >> >>> >> >>>>> those not >> >> >> >> >>> >> >>>>>>>>> familiar with the draft, it seems that >>everyone >> >> >>agrees >> >> >> >>on >> >> >> >> >>> >> >>>>>>>>> these terms. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear >> >> >> >> >>> >> >>>>>>>>> is >> >> >>whether >> >> >> >>it is >> >> >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately >> >> >> >> >>> >> >>>>>>>>> specify >> >>what >> >> >> >>the ID >> >> >> >> >>> >> >>>>>>>>> of the SFC Header >> >> >> >> >>> >> >>>>> should >> >> >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if >> >> >> >> >>> >> >>>>>>>>> this >> >>draft >> >> >> >>simply >> >> >> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing >>other >> >> >>drafts >> >> >> >>to >> >> >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based >> >> >> >> >>> >> >>>>>>>>> on >> >> chain >> >> >> or >> >> >> >> >>> >> >>>>>>>>> path and the choice of chain or >> >> >> >> >>> >> >>>>> path to >> >> >> >> >>> >> >>>>>>>>> be negotiated in the control-plane. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft >>would >> >> have >> >> >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported >> >> >> >> >>> >> >>>>>>>>> (or >> >> make >> >> >> >> one >> >> >> >> >>> >> >>>>>>>>> required and the other optional) to avoid >> >> >> >> >>> >> >>>>>>>>> some >> >> >> vendors >> >> >> >> only >> >> >> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >>>>>>>>>>>>>>>>>>------------------------------------------------------ >>>>>>>>>>>>>>>>>>--- >>>>>>>>>>>>>>>>>>-- >> >>>>>>>>>>>>>>>>-- >> >> >>>>>>>>>>>>>>-- >> >> >> >>>>>>>>>>>>--- >> >> >> >> >>>>>>>>>>-- >> >> >> >> >>> >>>>>>>-- >> >> >> >> >>> >> >>>>>-- >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> *From:*jmh@joelhalpern.com<jmh@joelhalpern.com >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com>> >> >> >> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org<sfc@ietf.org >> >> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org>> >> >> >> *Sent:*Tuesday, >> >> >> >> July >> >> >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, >> >> >> >> >>> >> >>>>>>>>> Paths, >> >>and >> >> >>Load >> >> >> >> >>> >> >>>>>>>>> Balancers >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> I have been trying to figure out how to >>clearly >> >> >>answer >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> number of comments that have been made >> about >> >> the >> >> >> >> >>> proposed >> >> >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can >> >> >> >> >>> >> >>>>>>>>> get >> >> >> working >> >> >> >> >>> >> >>>>>>>>> group agreement on the intent, we will work >> >> >> >> >>> >> >>>>>>>>> to >> >> >> improve >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> wording so that readers who have not >> participated >> >> in >> >> >> >>the >> >> >> >> WG >> >> >> >> >>> >> >>>>>>>>> discussion will understnd it the way the >> >> >> >> >>> >> >>>>> working >> >> >> >> >>> >> >>>>>>>>> group intends. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> But what do we intend? I will try to >> >> >> >> >>> >> >>>>>>>>> explain >>my >> >> >> >>personal >> >> >> >> >>> >> >>>>>>>>> view, and see if that helps. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> In this regard, it is important to keep in >>mind >> >>that >> >> >> >>what >> >> >> >> >>> >> >>>>>>>>> we are defining is the data plane >>architecture. >> >>We >> >> >>are >> >> >> >> not >> >> >> >> >>> >> >>>>>>>>> attempting to define the architecture for >> >> >> >> >>> >> >>>>>>>>> the >> >>entire >> >> >> >> >>> >> >>>>>>>>> solution for service chaining. That would >> >> encompass >> >> >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy >> >> >> >> >>> >> >>>>>>>>> functions, >> >> >>virtual >> >> >> >> >>> >> >>>>>>>>> machine and image management, and many >> other >> >> >> >> aspects. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> As a result there are many things which >>clearly >> >> need >> >> >> to >> >> >> >> >>> >> >>>>>>>>> exist in the larger system, but which are >>dealt >> >>with >> >> >> >>above >> >> >> >> >>> >> >>>>>>>>> where we are >> >> >> >> >>> >> >>>>> functioning, >> >> >> >> >>> >> >>>>>>>>> and are not directly required by the work >> >> >> >> >>> >> >>>>>>>>> we >>are >> >> >> doing. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> In order to get to service chain vs service >>path, >> >> >>as I >> >> >> >> >>> >> >>>>>>>>> understand >> >> >> >> >>> >> >>>>> them, >> >> >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. >> >> >> >> >>> >> >>>>>>>>> There >> >>are at >> >> >> >>least >> >> >> >> >>> >> >>>>>>>>> three different ways that load balancing >> >> >> >> >>> >> >>>>>>>>> can >>and >> >> >>will >> >> >> >> >>> >> >>>>>>>>> interact with service chaining. There >> >> >> >> >>> >> >>>>>>>>> probably >> >>are >> >> >> >>more. >> >> >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit >>all of >> >> >> >>these, >> >> >> >> >>> >> >>>>>>>>> but not to mandate that any particular kind >> >> >> >> >>> >> >>>>> be used >> >> >> >> >>> >> >>>>>>>>> in any solution. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to >> >> >> >> >>> >> >>>>>>>>> the >> >>end >> >> >> >>user. >> >> >> >> >>> >> >>>>>>>>> This is a service function. It receives >> >> >> >> >>> >> >>>>>>>>> user >> >> >>packets, >> >> >> >>and >> >> >> >> >>> >> >>>>>>>>> modifies them (or >> >> >> >> >>> >> >>>>> marks >> >> >> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user >>service >> >> >> >>instance >> >> >> >> >>> >> >>>>>>>>> to receive the users packet. This is an >>important >> >> >> >>service >> >> >> >> >>> >> >>>>>>>>> function to be able to include in service >> >>chaining. >> >> >> >>It's >> >> >> >> >>> >> >>>>>>>>> behavior may affect requirements on how >> service >> >> >> >> chaining is >> >> >> >> >>> >> >>>>>>>>> done. But it has very little impact on the >> >> >> >>archtiecture. >> >> >> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is >>simply >> >>a >> >> >> >> >>> >> >>>>> service >> >> >> >> >>> >> >>>>>>>>> function which may modify the underlying >> packet. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That >> >> >> >> >>> >> >>>>>>>>> is, >>one >> >> >>can >> >> >> >>have >> >> >> >> >>> >> >>>>>>>>> what >> >> >> >> >>> >> >>>>> appears >> >> >> >> >>> >> >>>>>>>>> to the service chaining architecture as a >>single >> >> >>point >> >> >> >>of >> >> >> >> >>> >> >>>>>>>>> contact >> >> >> >> >>> >> >>>>> for a >> >> >> >> >>> >> >>>>>>>>> specific service function, but is actually >> >>delivered >> >> >> >>by a >> >> >> >> >>> >> >>>>> collection of >> >> >> >> >>> >> >>>>>>>>> virtual or physical machines, possibly >>including >> >> >>one or >> >> >> >> >>> >> >>>>>>>>> several load balancers (for example using >> >>VRRP-like >> >> >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, >> this >> >>is >> >> >> >> >>> >> >>>>>>>>> invisible to the service chaining data >> >> >> >> >>> >> >>>>>>>>> plane >> >> >> >>mechanisms. >> >> >> >> It >> >> >> >> >>> >> >>>>>>>>> is likely that it is visible to various >>control >> >> >> >>mechanisms, >> >> >> >> >>> >> >>>>>>>>> such as those responsible for scale-in, >> >>scale-out, >> >> >>and >> >> >> >>vm >> >> >> >> >>> >> >>>>>>>>> instantiation. The architectural impact of >> >> >>permitting >> >> >> >>this >> >> >> >> >>> >> >>>>>>>>> is largely that we need to be careful that >> >> >> >> >>> >> >>>>>>>>> our >> >> >> >>terminology >> >> >> >> >>> >> >>>>>>>>> does not lead >> >> >> >> >>> >> >>>>> readers to >> >> >> >> >>> >> >>>>>>>>> think we are prohibiting it. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by >> >> >>selecting >> >> >> >> >>> >> >>>>>>>>> packet paths for the service chaining that >>direct >> >> >> >>traffic >> >> >> >> >>> >> >>>>>>>>> to different places. We would not want to >> require >> >> >> that >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> given service function appear at only one >>place >> >>in >> >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> It is of course the case that these may be >> >> >>combined. I >> >> >> >> tend >> >> >> >> >>> >> >>>>>>>>> to >> >> >> >> >>> >> >>>>> refer to >> >> >> >> >>> >> >>>>>>>>> the collection of entities that appear to >>service >> >> >> >>chaining >> >> >> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because >> >>cluster >> >> >>is >> >> >> >>a >> >> >> >> >>> >> >>>>>>>>> good term. But because I do not have >> >> >> >> >>> >> >>>>>>>>> another >> one. >> >> >> Thus, >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> point of type 3 load balancing >> >> >> >> >>> >> >>>>> is to >> >> >> >> >>> >> >>>>>>>>> direct different subsets of traffic to >>different >> >> >> >>singular >> >> >> >> >>> >> >>>>>>>>> or clustered service functions in different >> >>places >> >> >>in >> >> >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I >> >> >> >> >>> >> >>>>>>>>> talk >> >> about >> >> >> >> >>> >> >>>>>>>>> service chain and service path/ Service >> >> >> >> >>> >> >>>>>>>>> chain >>is >> >>a >> >> >> >> sequence >> >> >> >> >>> >> >>>>>>>>> of logical functions to be applied to a >>subset of >> >> >> >>packets. >> >> >> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset >> >> >> >> >>> >> >>>>>>>>> of >> >> >>traffic >> >> >> >>is >> >> >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, >> >> >> >> >>> >> >>>>>>>>> and >> >> >>firewall >> >> >> >> >>> >> >>>>>>>>> while a different subset is to go directly >> >> >> >> >>> >> >>>>>>>>> to >>the >> >> >>cache >> >> >> >> >>> >> >>>>> without >> >> >> >> >>> >> >>>>>>>>> visiting any other service functions. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> That is not enough information to direct >> >> >> >> >>> >> >>>>>>>>> the >> >> >>packets. >> >> >> A >> >> >> >> >>> >> >>>>>>>>> service path is, in some fashion, a >> >> >> >> >>> >> >>>>>>>>> sequence >>of >> >> >> >>locations >> >> >> >> >>> >> >>>>>>>>> in the network. Those locations will be >>singular >> >>or >> >> >> >> >>> >> >>>>>>>>> clustered service function delivery locations. >> >>They >> >> >> >>may be >> >> >> >> >>> >> >>>>>>>>> addressed by IP address. They may be >> addressed as >> >> >> ports >> >> >> >> on >> >> >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that >> >> >> >> >>> >> >>>>>>>>> the >> >> >> >>locations >> >> >> >> >>> >> >>>>>>>>> may be known to the service chaining >> >> infrastructure >> >> >> and >> >> >> >> the >> >> >> >> >>> >> >>>>>>>>> transport. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>>> From the point of view of the work of the >>SFC >> >> >>group, >> >> >> >> we >> >> >> >> >>> >> >>>>>>>>>> need to be >> >> >> >> >>> >> >>>>>>>>> able to talk about the high level >> >> >> >> >>> >> >>>>>>>>> abstraction, >> >>the >> >> >> >>service >> >> >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we >> need >> >>to >> >> >> talk >> >> >> >> >>> >> >>>>>>>>> about the actual data path packets will >> >> >> >> >>> >> >>>>>>>>> take >>in >> >>the >> >> >> >> >>> >> >>>>>>>>> network. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Several of the comments have said "but the >> whole >> >> >> path >> >> >> >> may >> >> >> >> >>> >> >>>>>>>>> not be known at the front." This >> >> >> >> >>> >> >>>>>>>>> architecture >> >>deals >> >> >> >>with >> >> >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in >>item >> >>(2) >> >> >>on >> >> >> >>load >> >> >> >> >>> >> >>>>>>>>> balancers above, there can be decisions and >> >> >>behaviors >> >> >> >> which >> >> >> >> >>> >> >>>>>>>>> are invisible to the service chaining >>mechanisms >> >>(in >> >> >> >>much >> >> >> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is >> >>largely >> >> >> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The >> >> >> >> >>> >> >>>>>>>>> other >> >> >> provision >> >> >> >> we >> >> >> >> >>> >> >>>>>>>>> make is >> >> >> >> >>> >> >>>>> that >> >> >> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain >> >> >> >> >>> >> >>>>>>>>> when >> >> >> >> necessary. >> >> >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. >> >> >> >> >>> >> >>>>>>>>> Based >> on >> >> >> >> >>> >> >>>>>>>>> information available at the >> >> >> >> >>> >> >>>>>>>>> re-classification >> >> >>point. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> I hope that this helps explain what we are >>after. >> >> >>If it >> >> >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to >> >> >> >> >>> >> >>>>>>>>> the >> >>working >> >> >> >> group, >> >> >> >> >>> >> >>>>>>>>> we can figure out what additional words are >> >> needed >> >> >> to >> >> >> >> >>> >> >>>>>>>>> convey this. If the working group disagree >>with >> >>the >> >> >> >> intent, >> >> >> >> >>> >> >>>>>>>>> then we will of course adjust to match the >> >>working >> >> >> >>group >> >> >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am >> >> >> >> >>> >> >>>>>>>>> not >> >>sure >> >> >> >>what to >> >> >> >> >>> >> >>>>>>>>> try next. >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> Yours, Joel >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >> >> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >> >> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>>> >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>>> >> >> >> _______________________________________________ >> >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>>> list sfc@ietf.org >> >> >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>>> >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>>> >> >> _______________________________________________ >> >> >> sfc >> >> >> >> >>> >> mailing >> >> >> >> >>> >> >>>>>>> list sfc@ietf.org >> >> >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>>> >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>>> >> >> _______________________________________________ >> >> >> sfc >> >> >> >> >>> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>>>> sfc@ietf.org >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>>>> >> >> >> >> >>> >> >>>>> >> >> >> >> >>> >> >>>>> >> _______________________________________________ >> >> sfc >> >> >> >> >>> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>>> sfc@ietf.org >> >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> >> _______________________________________________ >> >> sfc >> >> >> >> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>> sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>>> >> _______________________________________________ >> >> sfc >> >> >> >> mailing >> >> >> >> >>> >> list >> >> >> >> >>> >> >>>> sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >>>> >> >> >> >> >>> >> >>> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> _______________________________________________ >> >> >> >> >>> >> >> sfc mailing list >> >> >> >> >>> >> >> sfc@ietf.org >> >> >> >> >>> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >> >> >>> >> > >> >> >> >> >>> >> >_______________________________________________ >> >> >> >> >>> >> >sfc mailing list >> >> >> >> >>> >> >sfc@ietf.org >> >> >> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >> >>> >> _______________________________________________ >> >> >> >> >>> >> sfc mailing list >> >> >> >> >>> >> sfc@ietf.org >> >> >> >> >>> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >>> >> >> >> >> >>> _______________________________________________ >> >> >> >> >>> sfc mailing list >> >> >> >> >>> sfc@ietf.org >> >> >> >> >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> > >> >> >> >> >_______________________________________________ >> >> >> >> >sfc mailing list >> >> >> >> >sfc@ietf.org >> >> >> >> >https://www.ietf.org/mailman/listinfo/sfc >> >> > >> > > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing 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 Jul 14 06:23:19 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEAA1A03FD for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4d_VbtgWFOe for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:23:05 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EBC1A0402 for <sfc@ietf.org>; Mon, 14 Jul 2014 06:23:00 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 4b9d3c35.2ba30c22c940.532451.00-2430.1451325.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 13:23:00 +0000 (UTC) X-MXL-Hash: 53c3d9b42612ee31-0c0cf01524fe0ab4658c5639d8dae533a7f49cb4 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 159d3c35.0.531383.00-2224.1448285.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 13:21:22 +0000 (UTC) X-MXL-Hash: 53c3d952393c2b85-c32b9c7fc74c758bb459176510fe67888bc9df3e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EDLK1d005551; Mon, 14 Jul 2014 09:21:21 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EDLABL005309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 09:21:16 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 13:20:45 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 09:20:45 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPnxP2r8yqZz2iY0W2vBcLoMvbGZufyFoA///EO1A= Date: Mon, 14 Jul 2014 13:20:44 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.189.13] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4B75BMISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kf9lR3kD c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=NBQWWW_Ur4AA:10 a=ofMgfj31e3cA:10 a=WSxxlw8Htv4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=3oc9M9_CAAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a] X-AnalysisOut: [=ABeY7kuGAAAA:8 a=qN95wPeSAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH8] X-AnalysisOut: [6SAAAA:8 a=DFfxSxkeMmh5ZRVhUtYA:9 a=QEXdDO2ut3YA:10 a=lZB8] X-AnalysisOut: [15dzVvQA:10 a=U8Ie8EnqySEA:10 a=JfD0Fch1gWkA:10 a=Hz7IrDYl] X-AnalysisOut: [S0cA:10 a=oAXR_kdF8uMA:10 a=chC_agHSu74A:10 a=paC5pjApGzsA] X-AnalysisOut: [:10 a=dv4VLj67Ab_vCbWl:21 a=IXrOuyp4yaJnRfuk:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=2iG7CHfPvsQhNgXOEDQA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=Sf_gFPzhefAA:10 a=TVKtMSKLzcC5TX4I:21 a=8L5Z2dDG1Hl] X-AnalysisOut: [v8IEY:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4JBAgoQXhxyimEo6gdVvbBCH72g Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 13:23:17 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4B75BMISOUT7MSGUSRCF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGUgbWVhbmluZyBvZiB0aGUgU0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8g bWUg4oCTIGFuIGFic3RyYWN0IGlkZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9mIHNlcnZpY2Ug ZnVuY3Rpb24gaW5zdGFuY2VzIChpLmUuLCBTRlAgSUQgMSA9IHtTRi1BLTEsIFNGLUItMywgU0Yt Qy0yfSkuICAgIEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFiZWwgc3RhY2vi gJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5l dHdvcmsgbG9jYXRpb25zLiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxlYXN0IHRvIG1l LCB0aGF0IHRoZXJlIGlzIGEgY2VudHJhbCBwb2ludCBvZiBzZWxlY3Rpb24gZm9yIHRoaXMgZW5k IHRvIGVuZCBzZXF1ZW5jZSAoYmFycmluZyByZWNsYXNzaWZpY2F0aW9uLCBvZiBjb3Vyc2UpLiAg IEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQgaW1wbGljYXRpb24uICAgIEkgaGF2ZSBi ZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRyYWwgcG9pbnQgbWV0aG9kb2xvZ3kgZHVl IHRvIHJlYWwtd29ybGQgY29tcGxleGl0aWVzIG9mIGR5bmFtaWMgc2NhbGUgYW5kIHRpbWVsaW5l c3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMuDQoNCjxNYXJpYT4gSSBhZ3JlZS4gSXQgc2hvdWxk IG5vdCBiZSBtYW5kYXRlZCBieSB0aGUgU0ZDIGFyY2hpdGVjdHVyZSB0aGF0IHNvbWV0aGluZyBj YWxsZWQg4oCcc2VydmljZSBmdW5jdGlvbiBwYXRoIElE4oCdIGlzIGNhcnJpZWQgaW4gdGhlIHBh Y2tldCwgYmVjYXVzZSBpdCBpcyBub3QgbmVjZXNzYXJ5IG9yIHRoZSBvbmx5IHdheSB0byBpbXBs ZW1lbnQgc2VydmljZSBjaGFpbmluZy4gVGhlcmUgbWlnaHQgc29sdXRpb25zIHRoYXQgd291bGQg ZG8gdGhhdCBidXQgaXQgY2Fubm90IGFuZCBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZC4N Cg0KTWFyaWENCg0KQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNlIGNlbnRy YWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0aGUgY2hhaW4gb2YgYWJzdHJhY3Qgc2VydmljZSBmdW5j dGlvbnMgKGkuZS4sIFNGQyBJRCAxID0ge1NGLUEsIFNGLUIsIFNGLUN9KSwgYnV0IGFsbG93IHRo ZSBhY3R1YWwgaW5zdGFuY2Ugc2VsZWN0aW9uIHRvIGJlIGRpc3RyaWJ1dGVkLCByZWFsaXplZCBi eSB0aGUgY2xhc3NpZmllciBhbmQgdGhlIFNGRnMuDQoNCkdpdmVuIGEgdG9wb2xvZ3kgbGlrZToN Cg0KQ2xhc3NpZmllciAtLS0tLS0tICBTRkYtMSAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMiAt LS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0tLS0tLS0tLS0tLS0tLS1TRkYtNA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgIFNGRi1BLTEgICAgICAgU0ZGLUEtMiAgICAgICBTU0YtQi0xICAgICAgICBTRkYtQi0y ICAgICAgICAgU0ZGLUMtMSAgICAgICBTRkYtQy0yICAgICAgICAgICAgICAgICAgIFNGRi1BLTMN Cg0KQW5kIGFzc3VtaW5nIGEgbmV3bHkgcmVjb2duaXplZCBmbG93LCB0aGUgc2VxdWVuY2UgY291 bGQgZ28gc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KMSBDbGFzc2lmaWVyIHNlbGVjdHMgY2hhaW4g U0ZDIElEIDEge1NGLUEsIFNGLUIsIFNGLUN9DQoyIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBh cyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1BDQozIENsYXNzaWZpZXIgZW5j YXBzdWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2VydmljZSBpbmRleCA9 IDENCjQgQ2xhc3NpZmllciBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMQ0KNSBTRkYtMSwgc2Vl aW5nIGNoYWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3Qg aXRzIGF2YWlsYWJsZSBpbnN0YW5jZXMgb2YgU0YtQQ0KNiBTRkYtMSBzZW5kcyBwYWNrZXQgdG8g U0ZGLUEtMQ0KNyBTRkYtQS0xIHNlbmRzIHBhY2tldCBiYWNrIHRvIFNGRi0xDQo4IFNGRi0xIGlu Y3JlbWVudHMgc2VydmljZSBpbmRleCB0byAyDQo4IFNGRi0xIHNlbGVjdHMgU0ZGLTIgYXMgaG9z dGluZyBhdCBsZWFzdCBvbmUgaW5zdGFuY2Ugb2YgU0YtQg0KOSBTRkYtMSBwcm9ncmVzc2VzIHBh Y2tldCB0byBTRkYtMg0KMTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBTRkYtMywg YXMgdGhlIGVncmVzcyBib3JkZXIsIHByb2dyZXNzZXMgdGhlIHBhY2tldCBwZXIgcm91dGluZyB0 YWJsZQ0KDQpUaGFua3MuDQoNCg0KICAgUm9uDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KU2VudDogU3VuZGF5LCBKdWx5 IDEzLCAyMDE0IDExOjMwIFBNDQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPjsgamd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+ OyBtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+OyBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgam1oQGpv ZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvbiBQYXJrZXI7IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3NmY10gUmVkZWZpbmUg dGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoN Cg0KQWdyZWUgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAgaW4gdGhlIGFy Y2ggZHJhZnQgaXMgYSBiaXQgY29uZnVzaW5nLCBqdXN0IGFzIHdoYXQgeW91IGhhZCBwb2ludGVk IG91dC4NCg0KDQoNCkluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBTRlAgYXMgYW4gaW5zdGFudGlh dGlvbiBvZiBhbiBTRkMgaW4gdGhlIG5ldHdvcmsgc2hvdWxkIGJlIOKAnGFuIG9yZGVyZWQgbGlz dCBvZiBzZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0oc2VlIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEpLiBPZiBjb3Vyc2Us IGhvdyB0byByZXByZXNlbnQgdGhlIFNGUCBpbiB0aGUgZGF0YSBwYWNrZXQgaXMgYW5vdGhlciB0 aGluZyAoZS5nLiwgZWl0aGVyIHRocm91Z2ggYSBwYXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBs YWJlbCBzdGFjaykuIEhlcmUgdGhlIHNlcnZpY2Ugbm9kZSBtZWFucyB0aGUgZGV2aWNlIHdoaWNo IGNvbnRhaW5zIHRoZSBTRkYgYW5kIHRoZSBORiBjb21wb25lbnRzIG1hbmRhdG9yaWx5IHdoaWxl IGNvbnRhaW5pbmcgdGhlIFNGIGFuZCBTRiBwcm94eSBjb21wb25lbnRzIG9wdGlvbmFsbHkuIFRo ZSBzZXJ2aWNlIG5vZGUgY291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aCBtdWx0aXBs ZSBTRiBpbnN0YW5jZXMgYW5kIHRob3NlIFNGIGluc3RhbmNlcyBjb3VsZCBiZSBvZiB0aGUgc2Ft ZSBTRiB0eXBlIG9yIG5vdC4gIEluIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBT RiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgU0YgdHlwZSAoZS5nLiwgU0YgWCkgYXJlIGF0dGFjaGVk IHRvIGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlIGNvdWxkIGRpc3RyaWJ1 dGUgdGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBpbnN0YW5jZXMg b2YgU0YgWCB0eXBlIGxvY2FsbHkuIE1lYW53aGlsZSwgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHNl cnZpY2Ugbm9kZXMgd2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoaWNoIGFyZSBl bWJlZGRlZCBvciBhdHRhY2hlZCB3aXRoIHRoZSBTRiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgU0Yg dHlwZS4gSW4gdGhpcyB3YXksIHRoZSBTRiBsb2FkLWJhbGFuY2luZyB3b3VsZCBiZSBtYWRlIHZl cnkgZmxleGlibGUuDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQpGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIG1pa2ViaWFuY0Bhb2wu Y29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NClNlbnQ6IFNhdHVyZGF5LCBKdWx5IDEyLCAy MDE0IDI6NDYgQU0NClRvOiBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2Nv LmNvbT47IG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCldvdWxkbid0 IHRoYXQgYmUgY2FsbGVkIHRoZSAic2VydmljZSBjaGFpbiBpZGVudGlmaWVyIiB0aGVuPyAgSWYg dGhlIHNlcnZpY2UgY2hhaW4gaXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2 aWNlIHBhdGggaXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRiBpbnN0YW5jZXMsIHRoZW4gSSB3b3Vs ZCBpbmZlciB0aGF0IGEgInNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIiB3b3VsZCBiZSBhbiBpZGVu dGlmaWVyIGZvciBhIHNlcnZpY2UgKnBhdGgqLCBub3QgYSBzZXJ2aWNlICpjaGFpbiouDQoNCkFn YWluLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUgdGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBp bi4gIFRoZSB0ZXJtcyAiY2hhaW4iIGFuZCAicGF0aCIgc2VlbSBpbmNvbnNpc3RlbnQuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208 amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBj aXNjby5jb20+Pg0KVG86IG1pa2ViaWFuY0Bhb2wuY29tPG1pa2ViaWFuY0Bhb2wuY29tPixtbjE5 MjFAYXR0LmNvbTxtbjE5MjFAYXR0LmNvbT4sbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPixqbWhAam9lbGhhbHBlcm4uY29tPGptaEBqb2Vs aGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZzxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20lM2NtaWtlYmlhbmNAYW9sLmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21u MTkyMUBhdHQuY29tJTNlLG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tJTNlLGptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBl cm4uY29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tJTNlLHNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQpTZW50 OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQNClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KWW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2Ug cGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoIHRocm91Z2ggd2hpY2gg dHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBo b3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZSBjaGFpbiBkYXRhIHN0cnVjdHVyZSBhbmQgdGhh dCBpcyB0aGVuIHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNo IG5leHQtaG9wcyB0byB0aG9zZSBpbnN0YW5jZXMgYXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2ZXIg bG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluIHBsYXkuIFdoZW4gaW5zdGFudGlhdGlu ZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3b3JrIHlvdSBtYXkgb3IgbWF5IG5vdCB1 cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5IHdoaWNoIG5leHQtaG9wcyBtYXkg YmUgdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1ob3Agd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1 cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNlcnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2lt cGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wgLyBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhl IGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQoNCkZyb206ICJtaWtlYmlhbmNAYW9sLmNvbTxtYWls dG86bWlrZWJpYW5jQGFvbC5jb20+IiA8bWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPj4NCkRhdGU6IEZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KVG86 IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5j b20+PiwgIm1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4iIDxtbjE5MjFAYXR0 LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LCAiam1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sICJSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiIg PFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb20+PiwgInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpJIHRoaW5rIHRoaXMgaXMg dGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCg0KPiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5 DQo+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5h dGlvbiB0aGVyZW9mKS4gSQ0KPiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwx MDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMNCj4gYW5kIHRoZW4gcHVz aCB0aGlzIGludG8gdGhlIG5ldHdvcmsNCg0KQnkgZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEg InNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJlZCBsaXN0IG9mIHNwZWNpZmljIFNGIGluc3Rh bmNlcy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91IHVzZSBhICJzZXJ2aWNlIHBhdGggaWRl bnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkg Iltkb2VzIG5vdF0gc3BlY2lmeSBzcGVjaWZpYyBpbnN0YW5jZXMiLg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogamd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20+PGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28u Y29tPj4NClRvOiBOQVBJRVJBTEEsIE1BUklBIEg8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTky MUBhdHQuY29tPj4sbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT48bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LEpvZWwgTS4gSGFscGVybjxqbWhAam9lbGhh bHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sUm9uIFBhcmtlcjxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPj4sc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNA0KU3ViamVj dDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoN Ck1hcmlhLA0KDQpJIHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgaXMgc2ltcGx5IGEgcG9pbnRlciB0bw0KYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRh aW5zIFNGIHRvIG5leHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUgYQ0KY2hhaW4sIGxl dOKAmXMgc2F5IFMxIC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUgU0ZQ IHNwZWNpZnkNCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFmZmljIHRv IGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBTRlAuDQpIb3dldmVyLCB5b3UgZG8gKm5vdCogaGF2ZSB0 byBkbyB0aGlzIGZyb20gYW4gYXJjaGl0ZWN0dXJhbCBzdGFuZHBvaW50IChJDQp3aWxsIGFyZ3Vl IHRoYXQgeW91IHNob3VsZCBidXQgeW91IGRvbuKAmXQgaGF2ZSB0byBhcmNoaXRlY3R1cmFsbHkp LiBZb3UNCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBw b2ludCB0byBhIGdpdmVuIFNGQyBhbmQNCnRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8g dGhlIG5ldHdvcmsuIEF0IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGENCnNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQgY29udGFpbiB0aGUN Cm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNG QyAtIGhvdyB5b3UgbGVhcm4NCnRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3Vs ZCBwdXNoIHRoZW0gZG93biBmcm9tIGEgY2VudHJhbGl6ZWQNCmNvbnRyb2xsZXIsIGNvbmZpZ3Vy ZSB0aGVtIHRocm91Z2ggQ0xJLCBsZWFybiB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2gNCnNvbWUg cHJvdG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBj b3JyZWN0IHRvDQpzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGlu c3RhbmNlcyBhcmUgY2hvc2VuIGEgcHJpb3JpDQphbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNj ZXB0YWJsZSAoYW5kIHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0byBkbw0Kc28uDQoNCkxl dOKAmXMgdGFrZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6DQoNCkkg ZGVmaW5lIGFuIFNGQyAobGV04oCZcyByZWZlciB0byBpdCBhcyBTRkMtMSkgUzEtPlMyLT5TMy4g Rm9yIGFyZ3VtZW50cw0Kc2FrZSBsZXTigJlzIHNheSBJIHdhbnQgaXQgdG8gYmUgZnVsbHkgZHlu YW1pYyBlLmcuIEkgZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkNCnNwZWNpZmljIGluc3RhbmNlcyBv ZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KYXNzaWdu IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50 cyB0byBTMS0+UzItPlMzDQphbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yayBzbyB0 aGF0IHRoZSBTRkYgZGF0YSBzdHJ1Y3R1cmVzIGFyZQ0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZv cm1hdGlvbi4gTm93IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlcw0Kd2l0aCBz ZXJ2aWNlIHBhdGggaWRlbnRpZmllciAxMDAsIHRoZSBTRkYgd2lsbCBsb29rIHRoaXMgdXAgaW4g dGhlIGRhdGENCnN0cnVjdHVyZSBhbmQgZmluZCB0aGF0IGl0IHBvaW50cyB0byBTMS0+UzItPlMz IGFuZCB0aGUgaW5kZXggaW4gdGhlIFNGQw0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhh Y3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlDQphcmUgYXQgUzIg aW4gdGhlIGNoYWluLiBUaGUgU0ZGIHdpbGwgbm93IGhhdmUgdG8gcmVzb2x2ZSB0aGUgbmV4dC1o b3AgdG8NClMzIGFuZCB3aWxsIGRvIGEgbG9va3VwIHRvIGRldGVybWluZSB3aGVyZSBTMyBpcyBy ZWFjaGFibGUuDQoNCk9uIDcvMTEvMTQsIDExOjI2IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8 bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQoNCj5KaW0sDQo+ DQo+Q291bGQgeW91IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICJzZXJ2aWNl IHBhdGgiIGFuZCBhDQo+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIj8NCj5JZiBhIHNlcnZpY2Ug cGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhcHJpb3JpICh3aGlj aA0KPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9j YWwgZGVjaXNpb24gd2hpY2gNCj5uZXh0LWhvcCBTRkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFs aXplZCBkZWNpc2lvbi4NCj4NCj5NYXJpYQ0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+DQoNCkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNo YXJAY2lzY28uY29tXQ0KPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNDQo+ PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9lbCBNLg0KPj4gSGFscGVybjsg Um9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0 OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ DQo+PiBJ4oCZbSBzb3JyeSBidXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBhIHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyDQo+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBT RiBuZXh0LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlDQo+PiBjaGFpbiBpZGVudGlm aWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0KPj4NCj4+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAi TkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29t Pj4gd3JvdGU6DQo+Pg0KPj4gPkRpdHRvLg0KPj4gPg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb21dDQo+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6 MzEgQU0NCj4+ID4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbg0KPj4gPj4gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4NCj4+ID4+IFJlLSwNCj4+ID4+DQo+ PiA+PiBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xl YXJseSBpbiB0aGUNCj4+ZHJhZnQuDQo+PiA+Pg0KPj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBw YXRoIGlkZW50aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxsDQo+PiA+PmRp c3RyaWJ1dGVkDQo+PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4+ID4+DQo+PiA+PiBTZXZl cmFsIHZvaWNlcyBpbiB0aGlzIHRocmVhZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSBjaGFp biBpdHNlbGYNCj4+ID4+c2hvdWxkIGJlDQo+PiA+PiBwcm92aWRlZCBpbnN0ZWFkLg0KPj4gPj4N Cj4+ID4+IENoZWVycywNCj4+ID4+IE1lZA0KPj4gPj4NCj4+ID4+ID4tLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4+ID4+ID5EZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZA0KPj4gPj4gPihqZ3VpY2hhcikNCj4+ID4+ID5F bnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4DQo+PiA+PiA+w4AgOiBOQVBJ RVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4NCj4+ID4+ID5PayBidXQg d2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcyBmdW5jdGlvbmFs aXR5DQo+PiA+PiA+cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBu ZXh0LWhvcHMgdG8gKmFsbCogU0ZG4oCZcw0KPj4gPj4gPndpdGhpbiB0aGUgU0ZDIGRvbWFpbiBh bmQgdGhlbiBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhDQo+PiA+Pmxvb2t1cA0K Pj4gPj4gPmludG8gdGhvc2UgbmV4dC1ob3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBj aGFpbiwgSSBhbSBub3QNCj4+c3VyZQ0KPj4gPj5ob3cNCj4+ID4+ID50aGUgYXJjaGl0ZWN0dXJl IHByZXZlbnRzIHRoYXQ/DQo+PiA+PiA+DQo+PiA+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5B UElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+ DQo+PiB3cm90ZToNCj4+ID4+ID4NCj4+ID4+ID4+QWJzb2x1dGVseS4NCj4+ID4+ID4+DQo+PiA+ PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPj4g Pj4gPj4+KGpndWljaGFyKQ0KPj4gPj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5 OjU0IEFNDQo+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJu OyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+ PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9w b3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4+ID4+dGhhdCBpZg0KPj4gPj4g Pj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90 ZSBTRkYgaXQNCj4+d2lsbA0KPj4gPj51c2UNCj4+ID4+ID4+PmZvcg0KPj4gPj4gPj4+IGEgZ2l2 ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91DQo+ PmJldHRlcg0KPj4gPj5tYWtlDQo+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBo YXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvDQo+PiA+PnJlYWNoDQo+PiA+PiA+ Pj50aGUNCj4+ID4+ID4+PiBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2Ug eW91IGFyZSBpbiBkZWVwIHRyb3VibGUuDQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBPbiA3LzExLzE0 LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1u MTkyMUBhdHQuY29tPj4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gPkFic29s dXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4+ cmVsZXZhbnQNCj4+ID4+ID4+PlNGRnMNCj4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0K Pj4gPj4gPj4+ID4NCj4+ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPj4+ID4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmltDQo+Pkd1aWNoYXJkDQo+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4g Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4+ID4+ID4+PiA+PiBUbzog Sm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IFdlbGwg SSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZA0K Pj50aGUNCj4+ID4+ID4+PiA+PnByb3Bvc2FsDQo+PiA+PiA+Pj4gPj4gY29ycmVjdGx5IGFzIGl0 IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlDQo+PlNGDQo+PiA+ PiA+Pj53aXRoaW4NCj4+ID4+ID4+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9t YWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5IHRvDQo+Pmtub3cNCj4+ ID4+YQ0KPj4gPj4gPj4+ID4+cHJpb3JpDQo+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZDwrlzIGEgZ2l2 ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbg0KPj5wb2ludA0KPj4gPj5p bg0KPj4gPj4gPj4+dGltZS4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQs IDExOjUzIFBNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+PiA+PiB3cm90ZToNCj4+ID4+ID4+PiA+Pg0KPj4gPj4g Pj4+ID4+ID5Sb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBtYWpv ciBwcm9ibGVtDQo+PndpdGgNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj55b3VyDQo+PiA+PiA+Pj4g Pj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBt YXkgbm90DQo+PiA+PiA+Pj51bmRlcnN0YW5kDQo+PiA+PiA+Pj4gPj4gPml0LikNCj4+ID4+ID4+ PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMg dGhlIGxvYWQgYmFsYW5jZXIgZm9yIHRoZQ0KPj4gPj5uZXh0DQo+PiA+PiA+Pj4gPj4gPnNlcnZp Y2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj50 byksDQo+PiA+PmluDQo+PiA+PiA+Pj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWlu IHRoYXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+U2lu Y2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdCBtZWFu cw0KPj4gPj50aGF0DQo+PiA+PiA+Pj4gPj5ldmVyeQ0KPj4gPj4gPj4+ID4+ID5TRkYgd291bGQg aGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkDQo+PiA+ PiA+Pj5iYWxhbmNlci4NCj4+ID4+ID4+PiA+PiA+SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBT RkYgYXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcg0KPj4gPj5zdGF0ZWZ1bC4NCj4+ID4+ID4+ PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYg YmUgYSBmdWxsLA0KPj4gPj5mbG93DQo+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWws IGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+ID4+YWNjZXB0YWJsZQ0KPj4g Pj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+WW91 cnMsDQo+PiA+PiA+Pj4gPj4gPkpvZWwNCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPk9u IDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4g Pj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZSB0 aGlzDQo+PndvcmsNCj4+ID4+ID4+PiA+PnNlbnNpYmx5DQo+PiA+PiA+Pj4gPj4gPj4gaW4gYSBt b3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVudC4gSSBleHBlY3QgdGhhdCB0aGUNCj4+c2Vydmlj ZQ0KPj4gPj4gPj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUg U0ZGIGNhcGFiaWxpdGllcywNCj4+d2lsbA0KPj4gPj5iZQ0KPj4gPj4gPj4+ID4+ID4+IG9yY2hl c3RyYXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMNCj4+dG8g YmUNCj4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPj4gPj4gPj4+ID4+ID4+IEJTUyB0b29scyB0aGF0 IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZQ0KPj4gPj4gPj4+c2VsZi1z ZWxlY3Rpb24NCj4+ID4+ID4+PiA+PiA+PiBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBh dGhzIHRvIGJlIGhlYXZpbHkgcG9saWN5DQo+PiA+PmRyaXZlLg0KPj4gPj4gPj4+ID4+ID4+DQo+ PiA+PiA+Pj4gPj4gPj4gSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4g YW4gYXJjaHRpZWN0dXJlDQo+PiA+PmRyaXZlbg0KPj4gPj4gPj4+YnkNCj4+ID4+ID4+PiA+PiA+ PiBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBp cw0KPj4gPj5oYXJkZXINCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj5zZWUNCj4+ID4+ID4+PiA+ PiA+PiBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxs b3cgbW9yZQ0KPj4gPj4gPj4+ID4+IGR5bmFtaWNpdHkNCj4+ID4+ID4+PiA+PiA+PiBpbiB0aGUg bmV0d29yayBiZWhhdmlvci4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IEhhdmlu ZyBzYWlkIHRoYXQsIG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJIGRlc2NyaWJlZCBpcw0KPj4g Pj5vdXRzaWRlDQo+PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4g c2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+ PiA+PnRhc2tlZCB0bw0KPj4gPj4gPj4+ID4+YWdyZWUNCj4+ID4+ID4+PiA+PiA+Pm9uLg0KPj4g Pj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUg dG8gZG8gaXQgYQ0KPj5jZXJ0YWluDQo+PiA+PiA+Pj53YXkuDQo+PiA+PiA+Pj4gPj5pdA0KPj4g Pj4gPj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZl cmVuY2VzLg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+PiA+PiA+ Pj4gPj4gPj4gSm9lbA0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gT24gNy8xMC8x NCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0 aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PiB0 aGF0DQo+PiA+PiA+Pj4gPj5uZWVkcw0KPj4gPj4gPj4+ID4+ID4+Pj50bw0KPj4gPj4gPj4+ID4+ ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBl dmVuDQo+PiA+PmFjcm9zcw0KPj4gPj4gPj4+ZGF0YQ0KPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVy cyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaA0KPj5hbmQN Cj4+ID4+ID4+PiBjb21wbGV4DQo+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcg dG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+ID4+PmRpZmZpY3Vs dA0KPj4gPj4gPj4+ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiA+PiA+Pj4g Pj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1v cmUgY29tcGxpY2F0ZWQgdGhhbg0KPj5keW5hbWljDQo+PiA+PiA+Pj4gcm91dGluZywNCj4+ID4+ ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5T LCBhbGwgb2YNCj4+d2hpY2gNCj4+ID4+YXJlDQo+PiA+PiA+Pj4gPj5iaWdnZXINCj4+ID4+ID4+ PiA+PiA+Pj4gcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGlt cGxlbWVudGVkPw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBJdCBhbHNvIHNl ZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsIHRoYXQNCj4+aXMNCj4+ ID4+YQ0KPj4gPj4gPj4+Z29vZA0KPj4gPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQgaXQgaXMgdG9v IGNvbXBsaWNhdGVkLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4+IEZyb206 IEpvZWwgTS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT5dDQo+PiA+PiA+Pj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDk6NDUgUE0NCj4+ID4+ID4+PiA+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBE aXJlY3Q7IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47DQo+Pklh bg0KPj4gPj4gPj4+U21pdGg7DQo+PiA+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj5CYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25l IHRoYXQgSSB3b3VsZA0KPj5wcmVmZXINCj4+ID4+d2UNCj4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxs eQ0KPj4gPj4gPj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBh bGwgcG9zc2libGUNCj4+ID4+aW1wbGVtZW50YXRpb25zLg0KPj4gPj4gPj4+ID4+ID4+PiBCZWNh dXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPj4gPj5yZXF1 aXJlbWVudHMNCj4+ID4+ID4+PmFuZA0KPj4gPj4gPj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+ PiBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4g Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3Rh bmNlcw0KPj4gPj50aGF0DQo+PiA+PiA+Pj4gbmVlZHMNCj4+ID4+ID4+PiA+PiB0bw0KPj4gPj4g Pj4+ID4+ID4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlh bGx5IGV2ZW4NCj4+IGFjcm9zcw0KPj4gPj4gPj4+ZGF0YQ0KPj4gPj4gPj4+ID4+ID4+PiBjZW50 ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFu ZA0KPj4gPj4gPj4+Y29tcGxleA0KPj4gPj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcg dG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGENCj4+ID4+ID4+PmRpZmZpY3Vs dA0KPj4gPj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+ PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlv bi4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQ TSwgUm9uIFBhcmtlciB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXgg b2YgbXkgaXNzdWUuIElzIHRoZSBlbmQgdG8gZW5kDQo+PnNlbGVjdGlvbg0KPj4gPj5vZg0KPj4g Pj4gPj4+ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkg KHBlcmhhcHMgYnkgdGhlDQo+PiA+PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4gPj4gPj4+ID4+ID4+ Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVu dGx5DQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+U0ZGcyk/DQo+PiA+PiA+Pj4gPj4gPj4+PiBTdWNo IHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9uLg0KPj5BbmQN Cj4+ID4+ID4+PnN1cmVseSwNCj4+ID4+ID4+PiA+PiA+Pj4+IHRoaXMgaXMgYW4gYXJjaGl0ZWN0 dXJhbCBpc3N1ZSBhbmQgbm90IHJlbGVnYXRlZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxl bWVudGF0aW9uIi4NCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBNeSBvd24g dmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbg0KPj4gdGhvdWdo DQo+PiA+PiBhDQo+PiA+PiA+Pj4gPj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFp biBkZWZpbml0aW9ucyBhbmQgcGVyaGFwcw0KPj5sb2NhbA0KPj4gPj4gPj4+ID4+c2VsZWN0aW9u DQo+PiA+PiA+Pj4gPj4gPj4+PiBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1 dGVkIGRlY2lzaW9uIHBvaW50cy4NCj4+ID4+VGhpcw0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9h Y2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLg0KPj4gPj5N eQ0KPj4gPj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNo IGlzIHByaW1hcmlseSBkcml2ZW4NCj4+YnkNCj4+ID4+ID4+PiA+PmluY3JlYXNlZA0KPj4gPj4g Pj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4g V2l0aCBhDQo+Pmdsb2JhbA0KPj4gPj4gPj4+cGF0aA0KPj4gPj4gPj4+ID4+aWQNCj4+ID4+ID4+ PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBu ZWVkaW5nIHRvDQo+PiA+PmFsdGVyDQo+PiA+PiA+Pj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+IGds b2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZA0KPj5lbmQtdG8t ZW5kDQo+PiA+PiA+Pj5wYXRoLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ IFJvbg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+PiBb c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVo YWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0 QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XSBTZW50 OiBUaHVyc2RheSwgSnVseSAxMCwNCj4+MjAxNA0KPj4gPj4gNjoxNQ0KPj4gPj4gPj4+IFBNDQo+ PiA+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPjsgSS5TbWl0aEBGNS5jb208bWFpbHRvOkkuU21pdGhARjUuY29tPjsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0Og0KPj4gPj4gUmU6DQo+PiA+PiA+ Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFRoZSB3YXkgdGhlIGFyY2hp dGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxIG5lZWRpbmcNCj4+dG8NCj4+ID4+ID4+PiA+ PmluZmx1ZW5jZQ0KPj4gPj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxk IGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlDQo+PmV4aXQNCj4+ID4+ZnJvbQ0KPj4gPj4gPj4+ ID4+ID4+Pj4gU0YxLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQg b2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucw0KPj4gPj5sb2dp Y2FsbHkNCj4+ID4+ID4+PiA+PiA+Pj4+IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBj bGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5DQo+PiA+PiBjaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+ PiA+Pj4gPj4gPj4+PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ID4+ ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE9uIDcvMTAvMTQsIDY6MTAgUE0sIG1pa2ViaWFuY0Bh b2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBh bnkNCj4+ID4+c29ydA0KPj4gPj4gPj4+b2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93 ZXZlciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZQ0KPj4gPj5wYXRo DQo+PiA+PiA+Pj4oYWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4g YXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVsaWV2ZQ0KPj50aGlzDQo+PiA+PiA+Pj5tZWFucw0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUg Y2xhc3NpZmllcg0KPj5jaG9vc2VzIGENCj4+ID4+U0YNCj4+ID4+ID4+PiA+PkNoYWluDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYu IEluIGFueSBjYXNlLA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2Vz IHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlDQo+PiA+PiBTRkkobikN Cj4+ID4+ID4+PiBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShu LTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwNCj4+ID4+dGhpcw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcg U0ZQIGFzDQo+PiA+PiA+Pj4gb3Bwb3NlZA0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQgaW5zdGFu Y2Ugb2YNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJl bnQgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVy Z2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZD IGlzIGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+PiA+Pm5lY2Vzc2FyeQ0K Pj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0 YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLA0KPj4gPj5hbmQgdG8NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBT RidzDQo+PiA+Pm5ldHdvcmsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gbG9jYXRvci4gVGh1cywgaW5z dGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlDQo+PiA+PiA+Pj5jcmVhdGlvbg0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQg aXMgdXNlZCBmb3INCj4+ID4+Zm9yd2FyZGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRz IHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBv cnRzIHJlY2xhc3NpZmljYXRpb24gKG9yDQo+PiA+Pm5vbi1pbml0aWFsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNG UCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBp Y2FsbHkgcGVyZm9ybWVkIGJ5IGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24g ZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UNCj4+ID4+ZnVuY3Rpb24uDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0 aW9uIG9mIGEgbmV3DQo+PiA+PlNGUCwgYW4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gdXBkYXRlIG9m IHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiBUaGlzIGlzDQo+PiA+PnJlZmVycmVk DQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNvbTxtYWlsdG86Kkku U21pdGhARjUuY29tPjxJLlNtaXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+ICpUbzogKkpvZWwgSGFscGVybg0KPj4gRGlyZWN0PGptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4+LEpvZWwN Cj4+ID4+IE0uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+ PiA+Pg0KPj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+PixodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNjZS5jYXJs ZXRvbi5jYT48aHVhbmdAc2NlLg0KPG1haWx0bzpodWFuZ0BzY2UuJTBiPj4+ID4+ID4+PiA+PiBj YXJsZXRvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0K Pj4gPj5CYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEFj dHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+PiBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxlIGRlcGxv eW1lbnRzIChhbmQNCj4+dGhhdCBpcw0KPj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+ IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzDQo+ PiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRl YSwgdGhlbiB0aGUgYXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGgNCj4+IHRoYXQNCj4+ID4+ID4+ PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBv Zg0KPj4gPj5hc3BpcmF0aW9uDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRo YXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4+ID4+YXJjaGl0ZWN0 dXJlDQo+PiA+PiA+Pj4tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25v dyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQgYW4NCj4+ID4+ID4+PmFyYml0cmFyeQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAt IGV2ZW4gaWYgaXQgaXNuJ3QNCj4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxhc3Rp bmcNCj4+ID4+aW1wYWN0cw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQs IGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4+ID4+YWRkcmVzcw0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVt IEknbSBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3 aXRoLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2VsIEhhbHBlcm4gRGly ZWN0IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFs cGVybi5jb20+XQ0KPj4gPj5TZW50Og0KPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLg0KPj4gPj4gSGFscGVybjsN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24uY2E8bWFpbHRvOmh1YW5nQHNj ZS5jYXJsZXRvbi5jYT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0 OiBSZTogW3NmY10NCj4+ID4+U2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbiB0 aGlzDQo+PiA+PnJlZ2FyZC4NCj4+ID4+ID4+PkkNCj4+ID4+ID4+PiA+PmFtDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhlIHNvbHV0 aW9uDQo+PiA+PnByb2hpYml0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhl IHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRvDQo+PiA+Pkh1YW5nJ3MNCj4+ID4+ ID4+PiA+PiA+Pj4+PiByZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBs b3ltZW50cyBhcmUNCj4+ID4+IHJlcXVpcmVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhleSBieSB0 aGUgYXJjaHRpZWN0dXJlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g QXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0DQo+ PnN1Y2gNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29k IGlkZWEgb3Igbm90IGRlcGVuZHMgdXBvbg0KPj4gPj4gbWFueQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bw0KPj50 aGluaw0KPj4gPj50aGF0DQo+PiA+PiA+Pj4gPj50aGV5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJl IHVzdWFsbHkgYSBiYWQgaWRlYS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5n IHRvDQo+PiA+Pmtub3cNCj4+ID4+ID4+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQg aXMgbm90IGVwbG95YWJsZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3 LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkg ZGlzYWdyZWUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJv dXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZg0KPj4gPj4g Pj4+bWlsbGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+PiBj b25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5 IGJlbGlldmUgdGhhdCBpbg0KPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01v YmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91DQo+PiBhcmUNCj4+ID4+IG9u bHkNCj4+ID4+ID4+PiA+PiBnb2luZw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwg bnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkNCj4+c21hbGwNCj4+ID4+ID4+ PiBudW1iZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBt dWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlDQo+PiB0aGFuDQo+PiA+PiA+Pj4g NjRLIg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb21mb3J0 Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNm Yw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0KPj4gPj4gPj4+ ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pl0NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0 NiBQTSBUbzoNCj4+ID4+ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2Nl LmNhcmxldG9uLmNhPjsNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+ PmFuZA0KPj4gPj4gPj4+TG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0 IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IHRoZQ0KPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRo ZSBsaW1pdHMgb2YNCj4+dGhlaXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFy Y2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkDQo+PiB1c2UNCj4+ID4+IG9m DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1 cmUgb3V0IGhvdyB0byB3cml0ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdv cmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlDQo+PmRvZXMNCj4+ID4+ID4+PnBl cm1pdA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQg dGhlIGFyY2h0aWVjdHVyZQ0KPj4gcGVybWl0cw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhp bmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJlcXVpcmVkIGJ5DQo+PiA+PnRo ZQ0KPj4gPj4gPj4+d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5n Y2hlbmcgSHVhbmcgd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBz dXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbA0KPj5tZWFuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5n DQo+PnRhYmxlDQo+PiA+Pm9mIGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQ TSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNo aXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZyb20NCj4+MQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3 b3VsZCBob3BlDQo+PnRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHBy ZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlmIHRoZXkNCj4+ID4+Y2hvb3NlDQo+PiA+PiA+ Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBi YWxhbmNpbmcgYW5kIGluIHN0ZWFkDQo+PiA+PiBwcm92aXNpb24NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBI IHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRo ZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4+ID4+IHNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPj4gT2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g KlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+PiA+ PjM6MDMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGpt aEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Ow0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4+IENoYWlucywNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5LA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5 b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3 YXJkaW5nLiBJwrlkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRv DQo+PiA+PiBkZXJpdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJk aW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9ydC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhl ciBpcyB1c2VkIHRvDQo+PnNpbXBseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0 aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzDQo+Pm11c3QNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhl IGV4YWN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNl ZW0gdG8gYmUgYXNraW5nIGZvciBvbg0KPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo cmVhZCBjYW4gYmUgc2ltcGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aA0KPj4gPj4gaWRlbnRp Zmllcg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBh IGxvb2t1cCwgdGhhdCBsb29rdXAgY2FuDQo+PiA+PiByZXN1bHQNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0IDExOjA0IEFNLCBMdWN5IHlv bmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbT4NCj4+ID4+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUzZT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhl IGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YNCj4+IHRoZQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9y d2FyZGluZw0KPj4gPj5hY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gQmVo YWxmDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+ PiAqU2VudDoqVGh1cnNkYXksDQo+PiA+PiA+Pj4gPj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOiptaWtl YmlhbmNAYW9sLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNA YW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7 am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmc8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l M2U7c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4gKlN1YmplY3Q6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiA+PkNoYWlucywNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4 cGxpY2l0bHkgYSBzZXJ2aWNlIHBhdGgNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmll ci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPj5kZXJpdmUNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUg dGhlIGZ1bGwga25vd2xlZGdlIG9mDQo+PiA+PiBldmVyeQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGF2 YWlsYWJsZSBTRkMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRo aW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVp cmVkL2p1c3RpZmllZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFy aW91cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRo ZSBwaWVjZSBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGlu IGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lDQo+PiByZXF1aXJlZA0KPj4gPj4gdG8N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRo YXQgaW5mb3JtYXRpb24gaXMNCj4+ID4+dXNlZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bmZlciBmb3J3YXJkaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWVkDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5j QGFvbC5jb208bWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+ ID4+IGp1aWxsZXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhA am9lbGhhbHBlcm4uY29tPG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmc8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UN Cj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElz IGFueW9uZSBzdGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+PlNGDQo+ PiA+PiBDaGFpbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ID4+ID4+PiA+PiA+ Pj4+PiBQYXRoPw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFuIGNsYXJpZnlpbmcg dGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzDQo+PiA+PmNsZWFyIHRvDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gdGhvc2Ugbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhl IGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lDQo+PmFncmVlcw0KPj4gPj5vbg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1 bmNsZWFyIGlzDQo+PndoZXRoZXINCj4+ID4+aXQgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0DQo+PiA+ PnRoZSBJRA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4gPj4g Pj4+ID4+ID4+Pj4+IHNob3VsZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRo ZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJhZnQNCj4+ID4+c2ltcGx5DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93 aW5nIG90aGVyDQo+PmRyYWZ0cw0KPj4gPj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0 YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+PiBvcg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gcGF0aCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdv dGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBk cmFmdCB3b3VsZCBoYXZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3Ro IFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZQ0KPj4gPj4gb25lDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNv bWUNCj4+IHZlbmRvcnMNCj4+ID4+IG9ubHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9y dGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+ Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+ PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbT48bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlPj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmc8bWFpbHRvOipzZmNAaWV0Zi5vcmc+PHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz48bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0Bp ZXRmLm9yZyUzZT4+DQo+PiAqU2VudDoqVHVlc2RheSwNCj4+ID4+IEp1bHkNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LCBhbmQNCj4+TG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBoYXZlIGJlZW4gdHJ5aW5n IHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkNCj4+YW5zd2VyDQo+PiA+PmENCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJv dXQgdGhlDQo+PiA+PiA+Pj4gcHJvcG9zZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2Vk IGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldA0KPj4gd29ya2luZw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2ls bCB3b3JrIHRvDQo+PiBpbXByb3ZlDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbg0KPj4g Pj50aGUNCj4+ID4+IFdHDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1 bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRy eSB0byBleHBsYWluIG15DQo+PiA+PnBlcnNvbmFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZp ZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVw IGluIG1pbmQgdGhhdA0KPj4gPj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFyZSBk ZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlDQo+PmFyZQ0KPj4gPj4g bm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24g Zm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQgZW5jb21wYXNzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywN Cj4+dmlydHVhbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5h Z2VtZW50LCBhbmQgbWFueSBvdGhlcg0KPj4gPj4gYXNwZWN0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkg dGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZA0KPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aA0KPj4g Pj5hYm92ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW5kIGFyZSBub3Qg ZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlDQo+PiBkb2luZy4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRv IHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLA0KPj5hcyBJDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHVuZGVyc3RhbmQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUg YXJlIGF0DQo+PiA+PmxlYXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRpZmZlcmVu dCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZA0KPj53aWxsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkg YXJlDQo+PiA+Pm1vcmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUg YXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YNCj4+ID4+dGhlc2UsDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFu eSBzb2x1dGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQNCj4+ ID4+dXNlci4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rp b24uIEl0IHJlY2VpdmVzIHVzZXINCj4+cGFja2V0cywNCj4+ID4+YW5kDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5k IHVzZXIgc2VydmljZQ0KPj4gPj5pbnN0YW5jZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBy ZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gaW1wb3J0YW50DQo+PiA+PnNlcnZp Y2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRl IGluIHNlcnZpY2UgY2hhaW5pbmcuDQo+PiA+Pkl0J3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4+ID4+IGNo YWluaW5nIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVyeSBs aXR0bGUgaW1wYWN0IG9uIHRoZQ0KPj4gPj5hcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IEZyb20gYW4gYXJjaGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGEN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0 aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBs b2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lDQo+PmNhbg0KPj4gPj5oYXZlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHdoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcHBlYXJzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNp bmdsZQ0KPj5wb2ludA0KPj4gPj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMg c2VydmljZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZA0KPj4gPj5ieSBhDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlvbiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2 aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcNCj4+b25lIG9y DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBiYWxhbmNlcnMgKGZvciBleGFt cGxlIHVzaW5nIFZSUlAtbGlrZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRv IHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCj4+ID4+ bWVjaGFuaXNtcy4NCj4+ID4+IEl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0 aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sDQo+PiA+Pm1lY2hhbmlzbXMsDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9yIHNjYWxl LWluLCBzY2FsZS1vdXQsDQo+PmFuZA0KPj4gPj52bQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4+cGVybWl0dGluZw0K Pj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVk IHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+ID4+dGVybWlub2xvZ3kNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZG9lcyBub3QgbGVhZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxz byBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5DQo+PnNlbGVjdGluZw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBwYWNrZXQgcGF0aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0 DQo+PiA+PnRyYWZmaWMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNl cy4gV2Ugd291bGQgbm90IHdhbnQgdG8gcmVxdWlyZQ0KPj4gdGhhdA0KPj4gPj5hDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25l IHBsYWNlIGluDQo+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBvZiBjb3Vyc2Ug dGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUNCj4+Y29tYmluZWQuIEkNCj4+ID4+IHRlbmQNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVh ciB0byBzZXJ2aWNlDQo+PiA+PmNoYWluaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEg c2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3Rlcg0KPj5pcw0KPj4g Pj5hDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBu b3QgaGF2ZSBhbm90aGVyIG9uZS4NCj4+IFRodXMsDQo+PiA+PiB0aGUNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gaXMgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRz IG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50DQo+PiA+PnNpbmd1bGFyDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2Vz DQo+PmluDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNh aWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhDQo+ PiA+PiBzZXF1ZW5jZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9u cyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0IG9mDQo+PiA+PnBhY2tldHMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQg b2YNCj4+dHJhZmZpYw0KPj4gPj5pcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJ LCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQNCj4+ZmlyZXdhbGwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5 IHRvIHRoZQ0KPj5jYWNoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91 Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZQ0KPj5wYWNrZXRzLg0KPj4gQQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5j ZSBvZg0KPj4gPj5sb2NhdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdv cmsuIFRob3NlIGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhl eQ0KPj4gPj5tYXkgYmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFk ZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBhcw0KPj4gcG9ydHMNCj4+ID4+IG9uDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMg dGhhdCB0aGUNCj4+ID4+bG9jYXRpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBr bm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZQ0KPj4gYW5kDQo+PiA+ PiB0aGUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBv ZiB0aGUgd29yayBvZiB0aGUgU0ZDDQo+Pmdyb3VwLA0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxr IGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGUNCj4+ID4+c2VydmljZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBB bmQgd2UgbmVlZCB0bw0KPj4gdGFsaw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUg YWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xl DQo+PiBwYXRoDQo+PiA+PiBtYXkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3du IGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzDQo+PiA+PndpdGgNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVk IGluIGl0ZW0gKDIpDQo+Pm9uDQo+PiA+PmxvYWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFs YW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZA0KPj5iZWhhdmlvcnMNCj4+ ID4+IHdoaWNoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNl cnZpY2UgY2hhaW5pbmcgbWVjaGFuaXNtcyAoaW4NCj4+ID4+bXVjaA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2Vs eQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExB TnMuKSBUaGUgb3RoZXINCj4+IHByb3Zpc2lvbg0KPj4gPj4gd2UNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbWFrZSBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPj4g Pj4gbmVjZXNzYXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBh Y2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu Zm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24NCj4+cG9pbnQuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0 IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4NCj4+SWYgaXQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0 aGUgd29ya2luZw0KPj4gPj4gZ3JvdXAsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBm aWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkDQo+PiB0bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdy ZWUgd2l0aCB0aGUNCj4+ID4+IGludGVudCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3 ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmcNCj4+ID4+Z3JvdXAN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNs ZWFyLCBJIGFtIG5vdCBzdXJlDQo+PiA+PndoYXQgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dHJ5IG5leHQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPj4gc2ZjDQo+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBs aXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxp c3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMN Cj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IHNmYw0KPj4gPj4gPj4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiBs aXN0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiA+PiA+Pj4gbWFp bGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ ID4+ID4+PiA+PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ID4+ID4+PiA+PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+ PiBsaXN0DQo+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4+PiA+ PiA+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4g Pj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPg0K Pj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4gPj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gPnNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+ PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4g Pj4gPj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+DQo+PiA+PiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID5zZmMg bWFpbGluZyBsaXN0DQo+PiA+PiA+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5n IGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4B75BMISOUT7MSGUSRCF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0 IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2Ut MToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3Vu O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBs aS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNp bVN1bjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBw dDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEu MHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hh cg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1p bHk6U2ltU3VuO30NCnAuYSwgbGkuYSwgZGl2LmENCgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG 5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDp ooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAuSFRNTCwg bGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsN Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLmEwLCBsaS5hMCwgZGl2LmEw DQoJe21zby1zdHlsZS1uYW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pys IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG1lYW5pbmcgb2Yg dGhlIFNGUCBJRCBpcyBwcmV0dHkgY2xlYXIsIGF0IGxlYXN0IHRvIG1lIOKAkyBhbiBhYnN0cmFj dCBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNl cyAoaS5lLiwgU0ZQIElEIDEgPSB7U0YtQS0xLA0KIFNGLUItMywgU0YtQy0yfSkuJm5ic3A7Jm5i c3A7Jm5ic3A7IEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFiZWwgc3RhY2vi gJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5l dHdvcmsgbG9jYXRpb25zLiZuYnNwOyZuYnNwOyBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBs ZWFzdCB0byBtZSwgdGhhdCB0aGVyZSBpcyBhIGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0aW9uIGZv ciB0aGlzIGVuZCB0byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcNCiByZWNsYXNzaWZpY2F0aW9uLCBv ZiBjb3Vyc2UpLiZuYnNwOyZuYnNwOyBJLCBmb3Igb25lLCBhbSBxdWVzdGlvbmluZyB0aGF0IGlt cGxpY2F0aW9uLiZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgYmVlbiB1bmNvbWZvcnRhYmxlIHdp dGggdGhhdCBjZW50cmFsIHBvaW50IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdvcmxkIGNvbXBs ZXhpdGllcyBvZiBkeW5hbWljIHNjYWxlIGFuZCB0aW1lbGluZXNzIG9mIHJlYWN0aW9uIHRvIGZh aWx1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jmx0O01hcmlhJmd0OyBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJl IG1hbmRhdGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgc29tZXRoaW5nIGNhbGxlZCDi gJxzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggSUTigJ0gaXMgY2FycmllZCBpbiB0aGUgcGFja2V0LCBi ZWNhdXNlIGl0IGlzDQogbm90IG5lY2Vzc2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVtZW50 IHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxkIGRvIHRo YXQgYnV0IGl0IGNhbm5vdCBhbmQgZG9lc27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NYXJpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwg dXNlIGNlbnRyYWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0aGUgY2hhaW4gb2YgYWJzdHJhY3Qgc2Vy dmljZSBmdW5jdGlvbnMgKGkuZS4sIFNGQyBJRCAxID0ge1NGLUEsIFNGLUIsIFNGLUN9KSwgYnV0 IGFsbG93DQogdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQs IHJlYWxpemVkIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGcy4mbmJzcDsmbmJzcDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+R2l2ZW4gYSB0b3BvbG9neSBsaWtlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xhc3NpZmllciAtLS0t LS0tJm5ic3A7IFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0yIC0tLS0tLS0tLS0tLS0t LS0tLS0tIFNGRi0zLS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtTRkYtQS0xJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwO1NGRi1BLTImbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7U1NGLUItMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT RkYtQi0yJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NG Ri1DLTEmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U0ZGLUMtMiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRkYtQS0zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5jZSBj b3VsZCBnbyBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSBDbGFzc2lmaWVyIHNlbGVj dHMgY2hhaW4gU0ZDIElEIDEge1NGLUEsIFNGLUIsIFNGLUN9PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjIgQ2xhc3NpZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3RpbmcgYXQgbGVhc3Qg b25lIGluc3RhbmNlIG9mIFNGLUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MyBDbGFz c2lmaWVyIGVuY2Fwc3VsYXRlcyBwYWNrZXQgaW5kaWNhdGluZyBjaGFpbiBJRCA9IDEsIHNlcnZp Y2UgaW5kZXggPSAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQgQ2xhc3NpZmllciBw cm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj41 IFNGRi0xLCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2VydmljZSBpbmRleD0xLCBjaG9vc2VzIFNGRi1B LTIgYW1vbmdzdCBpdHMgYXZhaWxhYmxlIGluc3RhbmNlcyBvZiBTRi1BPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+NyBTRkYtQS0xIHNlbmRzIHBhY2tldCBiYWNrIHRvIFNGRi0x PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjggU0ZGLTEgaW5jcmVtZW50cyBzZXJ2aWNl IGluZGV4IHRvIDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+OCBTRkYtMSBzZWxlY3Rz IFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+OSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xMCBwcm9jZXNzIHJlcGVhdHMgcGVyIGFib3Zl IHVudGlsIFNGRi0zLCBhcyB0aGUgZWdyZXNzIGJvcmRlciwgcHJvZ3Jlc3NlcyB0aGUgcGFja2V0 IHBlciByb3V0aW5nIHRhYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJl Zj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5YdXhpYW9odTxicj4NCjxiPlNlbnQ6PC9iPiBT dW5kYXksIEp1bHkgMTMsIDIwMTQgMTE6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJt YWlsdG86amd1aWNoYXJAY2lzY28uY29tIj4NCmpndWljaGFyQGNpc2NvLmNvbTwvYT47IDxhIGhy ZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+OyA8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBq b2VsaGFscGVybi5jb208L2E+OyBSb24gUGFya2VyOw0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBSZWRlZmlu ZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5BZ3JlZSB0aGF0IHRoZSBjdXJyZW50IGRlZmluaXRpb24gb2Yg dGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJpdCBjb25mdXNpbmcsIGp1c3QgYXMgd2hh dCB5b3UgaGFkIHBvaW50ZWQgb3V0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIFNGUCBhcyBhbiBpbnN0YW50aWF0 aW9uIG9mIGFuIFNGQyBpbiB0aGUgbmV0d29yayBzaG91bGQgYmUg4oCcYW4gb3JkZXJlZCBsaXN0 IG9mIHNlcnZpY2Ugbm9kZXMgYW5kIFNGIElEc+KAnShzZWU8L3NwYW4+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1h cmNoLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJh c2VkLXNmYy1hcmNoLTAxPC9hPikuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQ IGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRoZXIgdGhyb3Vn aCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVyZSB0aGUgc2Vy dmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNGRiBhbmQgdGhl IE5GIGNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUgU0YgYW5kIFNG IHByb3h5IGNvbXBvbmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBiZSBh dHRhY2hlZCBvciBlbWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBhbmQgdGhvc2Ug U0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90LiAmbmJzcDtJ biB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBz YW1lIFNGIHR5cGUgKGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdpdmVuIHNlcnZpY2Ug bm9kZSwgdGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBkaXN0cmlidXRlIHRoZSB0cmFmZmljIHdoaWNo IG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzIG9mIFNGIFggdHlwZSBsb2NhbGx5 LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzIHdpdGhpbiBh IGdpdmVuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3IgYXR0YWNoZWQg d2l0aCB0aGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5LCB0 aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZSB2ZXJ5IGZsZXhpYmxlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBzZmMgWzxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXks IEp1bHkgMTIsIDIwMTQgMjo0NiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRv Om1uMTkyMUBhdHQuY29tIj4NCm1uMTkyMUBhdHQuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVy bi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bSI+DQpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPldvdWxkbid0IHRoYXQgYmUgY2FsbGVkIHRoZSAmcXVvdDtzZXJ2aWNl IGNoYWluIGlkZW50aWZpZXImcXVvdDsgdGhlbj8gJm5ic3A7SWYgdGhlIHNlcnZpY2UgY2hhaW4g aXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlIG9y ZGVyZWQgbGlzdCBvZg0KIFNGIGluc3RhbmNlcywgdGhlbiBJIHdvdWxkIGluZmVyIHRoYXQgYSAm cXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90OyB3b3VsZCBiZSBhbiBpZGVudGlmaWVy IGZvciBhIHNlcnZpY2UgKnBhdGgqLCBub3QgYSBzZXJ2aWNlICpjaGFpbiouPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PGJyPg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNy ZWVwaW5nIGluLiAmbmJzcDtUaGUgdGVybXMgJnF1b3Q7Y2hhaW4mcXVvdDsgYW5kICZxdW90O3Bh dGgmcXVvdDsgc2VlbSBpbmNvbnNpc3RlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9 IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0K PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28u Y29tIj5qZ3VpY2hhckBjaXNjby5jb20mbHQ7amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+ DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFu Y0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxQGF0dC5jb20lM2UsbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Usam1o QGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2Zj QGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5taWtlYmlhbmNAYW9sLmNvbSZsdDttaWtlYmlhbmNA YW9sLmNvbSZndDssbW4xOTIxQGF0dC5jb20mbHQ7bW4xOTIxQGF0dC5jb20mZ3Q7LG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20mbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDss am1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyxSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20m Z3Q7LHNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwv Yj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYu NzVwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Zb3VyIGRlZmlu aXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBh dGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlDQogY2hhaW4gZGF0 YSBzdHJ1Y3R1cmUgYW5kIHRoYXQgaXMgdGhlbiByZXNvbHZlZCB0byBzcGVjaWZpYyBpbnN0YW5j ZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0LWhvcHMgdG8gdGhvc2UgaW5zdGFuY2VzIGFyZSBhdmFp bGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBpcyBpbiBwbGF5 LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0aGUgbmV0d29yayB5 b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlDQogdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5 IHdoaWNoIG5leHQtaG9wcyBtYXkgYmUgdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1ob3Agd291 bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0aGF0IHNlcnZpY2Ug Y2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wgLyBtZWNo YW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2 Ljc1cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9s LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAx MjoxOCBQTTxicj4NCjxiPlRvOiA8L2I+SmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86 amd1aWNoYXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb208L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRo ZSBjb25mdXNpb246PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZndDsgSSBkb27i gJl0IHdhbnQgdG8gc3BlY2lmeTxicj4NCiZndDsgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBT MiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJPGJyPg0KJmd0OyBhc3Np Z24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9p bnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8YnI+DQomZ3Q7IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRv IHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 YnI+DQo8YnI+DQpCeSBkZWZpbml0aW9uLCBJIHVuZGVyc3Rvb2QgYSAmcXVvdDtzZXJ2aWNlIHBh dGgmcXVvdDsgdG8gYmUgYW4gb3JkZXJlZCBsaXN0IG9mIHNwZWNpZmljIFNGIGluc3RhbmNlcy4g SW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91IHVzZSBhICZxdW90O3NlcnZpY2UgcGF0aCBpZGVu dGlmaWVyJnF1b3Q7IHRvIHJlZmVyIHRvIGEgc2VydmljZSAqY2hhaW4qIHRoYXQgc3BlY2lmaWNh bGx5ICZxdW90O1tkb2VzIG5vdF0gc3BlY2lmeSBzcGVjaWZpYyBpbnN0YW5jZXMmcXVvdDsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJv dHRvbTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9y OiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJtYWlsdG86amd1aWNoYXJA Y2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86IDwv Yj5OQVBJRVJBTEEsIE1BUklBIEgmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5t bjE5MjFAYXR0LmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZsdDs8YSBocmVmPSJt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT4mZ3Q7LEpvZWwgTS4gSGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LFJvbg0KIFBhcmtlciZs dDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+RnJpZGF5LCBKdWx5IDExLCAy MDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCjxicj4NCk1hcmlhLDxicj4NCjxicj4NCkkgdGhpbmsg b2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYSBw b2ludGVyIHRvPGJyPg0KYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5leHQt aG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUgYTxicj4NCmNoYWluLCBsZXQ8c3BhbiBsYW5n PSJaSC1DTiI+4oCZPC9zcGFuPnMgc2F5IFMxIC0mZ3Q7UzItJmd0OyBTMywgeW91ICptaWdodCog d2hlbiBjcmVhdGluZyB0aGUgU0ZQIHNwZWNpZnk8YnI+DQp0aGUgc3BlY2lmaWMgbmV4dC1ob3Bz IHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91Z2ggZm9yIHRoYXQgU0ZQLjxicj4N Ckhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1 cmFsIHN0YW5kcG9pbnQgKEk8YnI+DQp3aWxsIGFyZ3VlIHRoYXQgeW91IHNob3VsZCBidXQgeW91 IGRvbjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+dCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxs eSkuIFlvdTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmll ciB0byBwb2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+DQp0aGVuIHB1c2ggdGhhdCBpbmZvcm1h dGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhPGJyPg0Kc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3Vs ZCBjb250YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG PHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5zIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBs ZWFybjxicj4NCnRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRo ZW0gZG93biBmcm9tIGEgY2VudHJhbGl6ZWQ8YnI+DQpjb250cm9sbGVyLCBjb25maWd1cmUgdGhl bSB0aHJvdWdoIENMSSwgbGVhcm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoPGJyPg0Kc29tZSBw cm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90IGNv cnJlY3QgdG88YnI+DQpzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNG IGluc3RhbmNlcyBhcmUgY2hvc2VuIGEgcHJpb3JpPGJyPg0KYWx0aG91Z2ggaXQgaXMgcGVyZmVj dGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxkIHNheSByZWNvbW1lbmRlZCkgdG8gZG88YnI+ DQpzby48YnI+DQo8YnI+DQpMZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgdGFrZSBh biBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6PGJyPg0KPGJyPg0KSSBkZWZp bmUgYW4gU0ZDIChsZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgcmVmZXIgdG8gaXQg YXMgU0ZDLTEpIFMxLSZndDtTMi0mZ3Q7UzMuIEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxldDxz cGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5IGR5 bmFtaWMgZS5nLiBJIGRvbjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+dCB3YW50IHRvIHNw ZWNpZnk8YnI+DQpzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUg Y29tYmluYXRpb24gdGhlcmVvZikuIEk8YnI+DQphc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciA8c3BhbiBsYW5nPSJaSC1DTiI+4oCcPC9zcGFuPjEwMDxzcGFuIGxhbmc9IlpILUNOIj7i gJ08L3NwYW4+IHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0mZ3Q7UzItJmd0O1MzPGJyPg0K YW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEg c3RydWN0dXJlcyBhcmU8YnI+DQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cg YXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzPGJyPg0Kd2l0aCBzZXJ2aWNlIHBh dGggaWRlbnRpZmllciAxMDAsIHRoZSBTRkYgd2lsbCBsb29rIHRoaXMgdXAgaW4gdGhlIGRhdGE8 YnI+DQpzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtT MyBhbmQgdGhlIGluZGV4IGluIHRoZSBTRkM8YnI+DQplbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBp dCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV0PHNwYW4gbGFuZz0iWkgtQ04i PuKAmTwvc3Bhbj5zIHNheSB3ZTxicj4NCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYg d2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bzxicj4NClMzIGFuZCB3aWxs IGRvIGEgbG9va3VwIHRvIGRldGVybWluZSB3aGVyZSBTMyBpcyByZWFjaGFibGUuPGJyPg0KPGJy Pg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCiZndDtKaW0sPGJyPg0KJmd0Ozxicj4NCiZndDtDb3VsZCB5b3Ug dGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgJnF1b3Q7c2VydmljZSBwYXRoJnF1 b3Q7IGFuZCBhPGJyPg0KJmd0OyZxdW90O3NlcnZpY2UgcGF0aCBpZGVudGlmaWVyJnF1b3Q7Pzxi cj4NCiZndDtJZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJl IGNob3NlbiBhcHJpb3JpICh3aGljaDxicj4NCiZndDtpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRp bmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoPGJyPg0KJmd0O25l eHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLjxicj4NCiZn dDs8YnI+DQomZ3Q7TWFyaWE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgPGJyPg0KPGJyPg0KRnJvbTogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikgWzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20i Pm1haWx0bzpqZ3VpY2hhckBjaXNjby5jb208L2E+XTxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZyaWRh eSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTTxicj4NCiZndDsmZ3Q7IFRvOiBOQVBJRVJBTEEsIE1B UklBIEg7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgSm9lbCBNLjxicj4NCiZndDsmZ3Q7IEhhbHBl cm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJPHNw YW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5tIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb248c3BhbiBs YW5nPSJaSC1DTiI+4oCZPC9zcGFuPnQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGggaWRl bnRpZmllcjxicj4NCiZndDsmZ3Q7IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5l eHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyBjaGFpbiBp ZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7RGl0dG8uPGJyPg0KJmd0 OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT5dPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJB TEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg UGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBSZS0sPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQg Y2xlYXJseSBpbiB0aGU8YnI+DQomZ3Q7Jmd0O2RyYWZ0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50aWZp ZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDtkaXN0cmlidXRlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1vZGVsIGlzIG5vdCBhbGxvd2Vk Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU2V2ZXJhbCB2 b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4gaXRz ZWxmPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaG91bGQgYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBwcm92aWRlZCBpbnN0ZWFkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1lZDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Oy0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtEZSA6IHNmYyBbPGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDso amd1aWNoYXIpPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O0Vudm95PHNwYW4gbGFuZz0iWkgt Q04iPsOpPC9zcGFuPiA6IHZlbmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxODxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDvDgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJu OyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2JqZXQgOiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09rIGJ1dCB3aGVyZSBpbiB0aGUgYXJj aGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxs KiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZGPHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5zPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3dpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBs ZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDts b29rdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW50byB0aG9zZSBuZXh0LWhvcHMgdG8g cmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdDxicj4NCiZndDsmZ3Q7c3Vy ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3Ro ZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTEvMTQsIDk6NTggQU0sICZxdW90O05B UElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29t Ij5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1dGVs eS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IEppbSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhqZ3VpY2hh cik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5 IDExLCAyMDE0IDk6NTQgQU08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86 IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoZW4gSSBtaXN1bmRlcnN0 YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3RoYXQgaWY8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg eW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNG RiBpdDxicj4NCiZndDsmZ3Q7d2lsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Zm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNo YWluIHRoZW4geW91PGJyPg0KJmd0OyZndDtiZXR0ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21h a2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VyZSB0aGF0IHRoYXQgcmVt b3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtyZWFjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBuZXh0LW5leHQtU0YgZm9yIHRoZSBj aGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRyb3VibGUuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IE9uIDcvMTEvMTQsIDk6NDggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDtBYnNvbHV0ZWx5 IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluPGJyPg0KJmd0 OyZndDtyZWxldmFudDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NGRnM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O3doZW4gdGhleSAmcXVvdDthcnJp dmUmcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJv bTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKaW08YnI+DQomZ3Q7Jmd0O0d1aWNo YXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7KGpndWljaGFy KTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlk YXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZlIHVu ZGVyc3Rvb2Q8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O3Byb3Bvc2FsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9m IGV2ZXJ5IHNpbmdsZTxicj4NCiZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDt3aXRoaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZW50aXJl IFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG88YnI+ DQomZ3Q7Jmd0O2tub3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtwcmlvcmk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgd2hpY2ggU0ZDPHNwYW4gbGFuZz0iWkgtQ04iPsK5PC9zcGFu PnMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuPGJyPg0KJmd0 OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDt0aW1lLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiA3 LzEwLzE0LCAxMTo1MyBQTSwgJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDtSb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhlciBt YWpvciBwcm9ibGVtPGJyPg0KJmd0OyZndDt3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt5b3VyPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9wb3NhbCBhcyBJIHVu ZGVyc3RhbmQgaXQuIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3VuZGVyc3RhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O2l0Lik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9h ZCBiYWxhbmNlciBmb3IgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtuZXh0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZXJ2aWNlIGZ1bmN0aW9uIHRo YXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnM8YnI+DQomZ3Q7Jmd0O3RvKSw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 O3NlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0 aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtldmVyeTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7U0ZGIHdvdWxkIGhhdmUgdG8g YmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2JhbGFuY2VyLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBTRkYgYXJl IGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c3RhdGVmdWwu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtCdXQgaGF2 aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsPGJy Pg0KJmd0OyZndDsgJmd0OyZndDtmbG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDtzZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNlZW1z IHRvIG1lIHRvIGJlIGFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDthY2NlcHRhYmxlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpbXBvc2l0aW9uLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtZb3Vycyw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0pvZWw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4g SGFscGVybiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsgUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcg dG8gbWFrZSB0aGlzPGJyPg0KJmd0OyZndDt3b3JrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7c2Vuc2libHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9ubWVu dC4gSSBleHBlY3QgdGhhdCB0aGU8YnI+DQomZ3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgZnVuY3Rpb25zLCBhbmQgb3Zl ciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLDxicj4NCiZndDsmZ3Q7d2lsbDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsgb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0 IHRoZSBzZXJ2aWNlIGNoYWluczxicj4NCiZndDsmZ3Q7dG8gYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtkcml2ZW4gYnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9m ZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7c2VsZi1zZWxlY3Rpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsgZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0 byBiZSBoZWF2aWx5IHBvbGljeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmUuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEkgY2FuIHNlZSBob3cg dG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ZHJpdmVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Ynk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW5pdGlh bCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQgaXM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2hhcmRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2VlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGhvdyB0byBt YWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGR5bmFtaWNpdHk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW4gdGhlIG5l dHdvcmsgYmVoYXZpb3IuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJIGRl c2NyaWJlZCBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b3V0c2lkZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5n IHdlIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGFza2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YWdyZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDtvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNp b24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhPGJyPg0KJmd0OyZndDtjZXJ0YWluPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7d2F5Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15 IHByZWZlcmVuY2VzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRm9y IG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O25lZWRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQg bWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNyb3Nz PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGF0YTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNlbnRlcnMgd2l0 aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2g8YnI+DQomZ3Q7Jmd0 O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjb21wbGV4PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZW5v dWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXJjaGl0ZWN0 dXJlIHRvIHJlYWxpemUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21w bGljYXRlZCB0aGFuPGJyPg0KJmd0OyZndDtkeW5hbWljPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IHJvdXRpbmcsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0 aW9uLCBvciBETlMsIGFsbCBvZjxicj4NCiZndDsmZ3Q7d2hpY2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2FyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2JpZ2dl cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxlbWVu dGVkPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRl ZCwgdGhhdDxicj4NCiZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtnb29kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBs aWNhdGVkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZyb206 IEpvZWwgTS4gSGFscGVybiBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmpt aEBqb2VsaGFscGVybi5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0 NSBQTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IDxhIGhyZWY9Im1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbSI+DQptaWtlYmlhbmNAYW9sLmNvbTwvYT47PGJyPg0KJmd0OyZn dDtJYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtTbWl0aDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkPGJyPg0KJmd0OyZndDtCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxkPGJy Pg0KJmd0OyZndDtwcmVmZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3dlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FjdHVhbGx5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWNp ZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2ltcGxlbWVudGF0aW9ucy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3Ig ZWZmZWN0IG9uIHRoZSBjb250cm9sPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZXF1aXJlbWVudHM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Rm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2Vz PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7IG5lZWRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2 ZW48YnI+DQomZ3Q7Jmd0OyBhY3Jvc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDtkYXRhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2Ug ZW5vdWdoPGJyPg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDtjb21wbGV4PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBz ZWVtcyBsaWtlIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtkaWZmaWN1bHQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFlvdXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSm9lbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJ1dCBpdCBpcyBhIGZh aXIgcXVlc3Rpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZTo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiBJcyB0aGUgZW5kIHRvIGVuZDxicj4NCiZn dDsmZ3Q7c2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICh0b3AtbGV2ZWwp IGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsYXNzaWZpZXIpPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb3IgaG9w LWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDtTRkZzKT88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byBy ZWNsYXNzaWZpY2F0aW9uLjxicj4NCiZndDsmZ3Q7QW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7c3VyZWx5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZSBh bmQgbm90IHJlbGVnYXRlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O2ltcGxlbWVudGF0aW9uJnF1b3Q7Ljxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2 ZW48YnI+DQomZ3Q7Jmd0OyB0aG91Z2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZ3Jl YXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHM8YnI+DQom Z3Q7Jmd0O2xvY2FsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 c2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBk ZWNpc2lvbiBwb2ludHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtUaGlzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBwcm9hY2gg ZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7TXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2gg aXMgcHJpbWFyaWx5IGRyaXZlbjxicj4NCiZndDsmZ3Q7Ynk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbmNyZWFzZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXNpbGllbmN5IG92ZXIgdGhl IGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGE8YnI+DQomZ3Q7Jmd0O2dsb2JhbDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJl IG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDthbHRl cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdsb2JhbCBwYXRo IElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZDxicj4NCiZndDsmZ3Q7ZW5kLXRv LWVuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGguPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBS b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJv bTogc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tPC9hPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsPGJyPg0KJmd0OyZn dDsyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgNjoxNTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBQTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOkkuU21pdGhARjUuY29t Ij4NCkkuU21pdGhARjUuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgUmU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2Yg U0YxIG5lZWRpbmc8YnI+DQomZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7aW5mbHVlbmNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxk IGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlPGJyPg0KJmd0OyZndDtleGl0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDtmcm9tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU0YxLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUGFydCBvZiB0aGUgZ29hbCBpcyB0 byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2dp Y2FsbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmli ZSBob3cgdGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGNob29zZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY29tcG9zZSB0aGVtIGZvciAmcXVvdDtzZXJ2aWNl JnF1b3Q7IGRlbGl2ZXJ5Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAv MTQsIDY6MTAgUE0sIDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5j QGFvbC5jb208L2E+IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUg YXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c29ydDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpbWl0LiBIb3dl dmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGFsbDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxp ZXZlPGJyPg0KJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 bWVhbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFz c2lmaWVyPGJyPg0KJmd0OyZndDtjaG9vc2VzIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NGPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueSBjYXNlLDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBw cm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBT Rkkobik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV0 ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRl cmVkICZxdW90O2JyYW5jaGluZyZxdW90OyB0byBhIG5ldyBTRlAgYXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgb3Bwb3NlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5n IHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJh ZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaGVuIGFuIFNGQyBp cyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7bmVjZXNzYXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUg dXNlZCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRlIHRo ZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtuZXR3b3JrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9u IG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDtjcmVhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNG UCkgYW5kIGlzIHVzZWQgZm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtmb3J3YXJkaW5nPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBp cyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xh c3NpZmljYXRpb24gKG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtub24taW5pdGlhbDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQ LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVy Zm9ybWVkIGJ5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lk ZW50IHdpdGggYSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtmdW5jdGlvbi48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEg bmV3PGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRlAsIGFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1cGRhdGUgb2Yg dGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3JlZmVycmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFzICZxdW90O2JyYW5jaGluZyZxdW90Oy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpGcm9tOiA8YSBo cmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29tIj4qSS5TbWl0aEBGNS5jb208L2E+Jmx0OzxhIGhy ZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb208L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAqVG86ICpKb2VsIEhhbHBlcm48YnI+DQomZ3Q7Jmd0OyBEaXJlY3QmbHQ7PGEgaHJlZj0ibWFp bHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNv bTwvYT4mZ3Q7LEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDtIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOmh1YW5n QHNjZS5jYXJsZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPiZsdDs8YSBocmVmPSJt YWlsdG86aHVhbmdAc2NlLiUwYiI+aHVhbmdAc2NlLjxicj4NCjwvYT4mZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgY2FybGV0b24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Y2EmZ3Q7LDxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1YmplY3Q6 ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFjdHVhbGx5LCBJIHRoaW5rIEkg YW0gZGlzYWdyZWVpbmcuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBt ZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZDxicj4NCiZndDsmZ3Q7dGhhdCBpczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYgbWlsbGlvbiBmbG93 cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtwcmVjb25jZWl2ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYW4gYWJzdXJkIGlkZWEs IHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoPGJyPg0KJmd0OyZndDsgdGhhdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBwcmVjb25jZXB0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBoYXMgdG8gYmUg c29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDth c3BpcmF0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2NhbGUgdGhhdCBp cyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7YXJjaGl0ZWN0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7LTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhh dCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FyYml0cmFyeTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBudW1iZXIgaXMgJnF1b3Q7dG9vIGZhciZxdW90OywgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBp ZiBpdCBpc24ndDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2lu dGVudGlvbmFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRo YXQgaGF2ZSBsYXN0aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbXBhY3RzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJl Z2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2FkZHJlc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRo aW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFybHkgZWFn ZXIgdG8gZGVhbCB3aXRoLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgWzxhIGhyZWY9Im1haWx0 bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208 L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U2VudDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsIE0uPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgSGFscGVybjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRv bi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gU3ViamVjdDogUmU6IFtzZmNdPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGgg bWUgYXQgYWxsIGluIHRoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlZ2FyZC48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7YW08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRl Y3R1cmUgb3IgdGhlIHNvbHV0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDtwcm9oaWJpdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3Rpbmcg dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0h1YW5nJ3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhZGluZyBvZiBteSBu b3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgcmVxdWlyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8g cHJvaGliaXQ8YnI+DQomZ3Q7Jmd0O3N1Y2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmdzLiBXaGV0aGVyIHRoZXkg YXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBtYW55PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhlIFdHLiBJ IGhhcHBlbiB0bzxicj4NCiZndDsmZ3Q7dGhpbms8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGV5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB0aGUgYXJjaHRp ZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtrbm93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7d2hhdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpv ZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdyb3Rl Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSBkaXNhZ3JlZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBy b3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2Y8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDttaWxsaW9uczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2Y8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNl bnRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVs aWV2ZSB0aGF0IGluPGJyPg0KJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2xvdWQvSVB2Ni9Nb2JpbGl0 eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdTxicj4NCiZndDsmZ3Q7IGFyZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IG9ubHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgZ29pbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZp Y2UgY2hhaW5zIHdpdGggZXF1YWxseTxicj4NCiZndDsmZ3Q7c21hbGw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbnVtYmVyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBhY3RpdmUgc2VydmljZSBw YXRocz88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtl ICZxdW90O25vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlPGJyPg0KJmd0OyZndDsgdGhhbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA2NEsmcXVvdDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZv cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBjb21mb3J0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT5dPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRv Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzpodWFu Z0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT47PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsPGJyPg0KJmd0OyZndDthbmQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9u ZSB0cmllcyB0byBkZXBsb3kgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 YXJjaHRpZXR1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxsIGV4 Y2VlZCB0aGUgbGltaXRzIG9mPGJyPg0KJmd0OyZndDt0aGVpcjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV2aWNl cy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkPGJyPg0KJmd0 OyZndDsgdXNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2Ug cGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZTxi cj4NCiZndDsmZ3Q7ZG9lczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3Blcm1p dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc3VjaCBhYnVzZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVh c2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVjdHVyZTxicj4NCiZndDsm Z3Q7IHBlcm1pdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVy IGRlaXNyZWQgb3IgcmVxdWlyZWQgYnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpc24ndC48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0 IHdpbGw8YnI+DQomZ3Q7Jmd0O21lYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNiwwMDAsMDAwIHBhdGhz LiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nPGJyPg0KJmd0OyZndDt0YWJsZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7b2YgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcmUgcm91dGVyLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hhbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBv ZiBkZXBsb3ltZW50cywgZnJvbTxicj4NCiZndDsmZ3Q7MTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz ZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZTxicj4NCiZn dDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZv ciB0aGUgY29tcGxleGl0aWVzIGlmIHRoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Nob29zZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgcHJvdmlzaW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2MCwwMDAg c2VydmljZSBwYXRocy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg WW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24g Ny8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUGF1bCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEg NCBob3A8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD88YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJpYTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0gKk9uIEJlaGFsZjxicj4NCiZndDsmZ3Q7IE9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAq UGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OzM6MDM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBNICpUbzoqIEx1 Y3kgeW9uZyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+DQpqbWhA am9lbGhhbHBlcm4uY29tPC9hPjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNl PGJyPg0KJmd0OyZndDsgQ2hhaW5zLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEx1Y3ksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcuIEk8c3BhbiBsYW5nPSJaSC1D TiI+wrk8L3NwYW4+ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUg bWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgZGVyaXZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgbmVlZGVk IGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Ljxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQs IGJ1dCByYXRoZXIgaXMgdXNlZCB0bzxicj4NCiZndDsmZ3Q7c2ltcGx5PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNr ZXRzPGJyPg0KJmd0OyZndDttdXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cmF2ZXJzZS4g QnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0aGUgZXhhY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbjxi cj4NCiZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWFkIGNhbiBiZSBz aW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgaWRl bnRpZmllcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZXMgbm90aGluZyBtb3JlIHRo YW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHJlc3Vs dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2Vp Z2h0ZWQpIHRyYW5zcG9ydCBuZXh0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob3AocykuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF1bDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAxMCwg MjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5j b208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbSUzZSI+bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OzwvYT4mZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0 ZSBvbmx5IHVzZSBvZjxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg c2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmc8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2FjdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgTHVjeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10qT24iPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT248L2E+IEJlaGFsZjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9mKm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPm1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKlNlbnQ6KlRodXJzZGF5LDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdWx5PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAxMCwgMjAxNCAyOjA2IEFNICpUbzo8YSBocmVmPSJtYWlsdG86Km1pa2ViaWFu Y0Bhb2wuY29tIj4qbWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNlO2ptaEBqb2VsaGFscGVy bi5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSZndDs7am1oQGpvZWxoYWxwZXJuLmNvbTwv YT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmciPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJmd0 OztzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICpTdWJqZWN0 OipSZTogW3NmY10gU2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW5zLDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlLSw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxz IG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp ZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvPGJyPg0KJmd0OyZn dDtkZXJpdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcgYWN0aW9ucy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZXF1aXJpbmcg YSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXZhaWxhYmxlIFNGQzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5v dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyByZXF1aXJlZC9qdXN0aWZpZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5v ciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0ZDIGZvcndhcmRpbmcgYWN0aW9u cyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlu Zm9ybWF0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgd2lsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUg cHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZTxicj4NCiZndDsmZ3Q7 IHJlcXVpcmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDt1c2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZl ciBmb3J3YXJkaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFjdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlz IGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkRlIDoqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddKkRlIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlPC9hPiBs YSBwYXJ0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZSptaWtlYmlhbmNAYW9sLmNvbSI+ZGUq bWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb208L2E+ Jmd0OyAqRW52b3k8c3BhbiBsYW5nPSJaSC1DTiI+w6k8L3NwYW4+IDoqbWVyY3JlZGkgOTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IGp1aWxsZXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTQg MjI6MDMgKsOAIDo8YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhAam9l bGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9h PiZndDsgKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0No YWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJcyBhbnlv bmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsmZ3Q7 U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YW5kIFNGPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFBhdGg/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlciB0aGFu IGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtjbGVhciB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lPGJyPg0KJmd0 OyZndDthZ3JlZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29uPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGVzZSB0ZXJtcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXM8 YnI+DQomZ3Q7Jmd0O3doZXRoZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0IGlzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBz cGVjaWZ5IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZSBJRDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgb2YgdGhlIFNGQyBIZWFkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2hvdWxkPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMg ZHJhZnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXI8YnI+DQom Z3Q7Jmd0O2RyYWZ0czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hh aW48YnI+DQomZ3Q7Jmd0OyBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCBhbmQgdGhl IGNob2ljZSBvZiBjaGFpbiBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91 cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJl cXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IG9uZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQgYW5k IHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZTxicj4NCiZndDsmZ3Q7IHZlbmRvcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBw b3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDstLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgKkZyb206PGEgaHJlZj0ibWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tIj4qam1oQGpvZWxo YWxwZXJuLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmpt aEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2pt aEBqb2VsaGFscGVybi5jb20lM2UiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpv ZWxoYWxwZXJuLmNvbSZndDs8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRvOjxh IGhyZWY9Im1haWx0bzoqc2ZjQGlldGYub3JnIj4qc2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUz ZSI+bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyZndDs8L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7ICpTZW50OipUdWVzZGF5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kPGJyPg0KJmd0OyZndDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBC YWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseTxicj4NCiZn dDsmZ3Q7YW5zd2VyPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJvcG9zZWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQ8 YnI+DQomZ3Q7Jmd0OyB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBhZ3Jl ZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvPGJyPg0KJmd0OyZndDsgaW1wcm92 ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29y ZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgV0c8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5kcy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgd2hhdCBk byB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7cGVyc29uYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYgdGhh dCBoZWxwcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBhcmUg ZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZTxicj4NCiZndDsmZ3Q7 YXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh dHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3 b3VsZCBlbmNvbXBhc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlvdXMg Y29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucyw8YnI+DQomZ3Q7Jmd0O3ZpcnR1YWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55 IG90aGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYXNwZWN0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFu eSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkPGJyPg0KJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRl YWx0IHdpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fib3ZlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB3aGVyZSB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmU8 YnI+DQomZ3Q7Jmd0OyBkb2luZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNl IHBhdGgsPGJyPg0KJmd0OyZndDthcyBJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0 YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZW0sPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8gZmly c3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDtsZWFzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWUgZGlmZmVyZW50IHdheXMg dGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2Jh Ymx5IGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bW9yZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXNlLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnV0IG5v dCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSB1c2VkPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhbnkgc29sdXRpb24uPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBz ZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVj ZWl2ZXMgdXNlcjxicj4NCiZndDsmZ3Q7cGFja2V0cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fu ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kaWZpZXMgdGhlbSAob3I8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFy a3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3Nl IGFuIGVuZCB1c2VyIHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3RhbmNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMg YW4gaW1wb3J0YW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFp bmluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0l0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgY2hhaW5pbmcgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvbmUu IEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7YXJjaHRpZWN0dXJlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNoaXRl Y3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5 aW5nIHBhY2tldC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25lPGJy Pg0KJmd0OyZndDtjYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhdmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyPg0KJmd0 OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNvbnRhY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNp ZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQ8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2J5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5n PGJyPg0KJmd0OyZndDtvbmUgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldmVyYWwgbG9h ZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlz IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgZGF0YSBwbGFuZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBJdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGlrZWx5IHRo YXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O21lY2hhbmlzbXMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIHRob3NlIHJlc3Bv bnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCA8YnI+DQomZ3Q7Jmd0O2FuZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dm08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24u IFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiA8YnI+DQomZ3Q7Jmd0O3Blcm1pdHRpbmc8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxhcmdl bHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O3Rlcm1pbm9sb2d5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFkPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHJlYWRlcnMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFyZSBw cm9oaWJpdGluZyBpdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IDxicj4N CiZndDsmZ3Q7c2VsZWN0aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0aHMg Zm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDt0cmFmZmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2VzLiBX ZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlPGJyPg0KJmd0OyZndDsgdGhhdDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBmdW5j dGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gPGJyPg0KJmd0OyZndDt0aGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2Ug bWF5IGJlIDxicj4NCiZndDsmZ3Q7Y29tYmluZWQuIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0 ZW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIg dG8gc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hhaW5pbmc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1 c3RlciA8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhl ciBvbmUuPGJyPg0KJmd0OyZndDsgVGh1cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpcyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBzdWJz ZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaW5ndWxh cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25z IGluIGRpZmZlcmVudCBwbGFjZXMgPGJyPg0KJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hh dCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNl cnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgc2VxdWVuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGxvZ2lj YWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2Y8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3BhY2tldHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFsZW50 IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIDxicj4NCiZndDsmZ3Q7dHJhZmZpYzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBEUEks IGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnI+DQomZ3Q7Jmd0O2ZpcmV3YWxs PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8g Z28gZGlyZWN0bHkgdG8gdGhlIDxicj4NCiZndDsmZ3Q7Y2FjaGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91dDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVuY3Rp b25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo YXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIDxicj4NCiZndDsmZ3Q7 cGFja2V0cy48YnI+DQomZ3Q7Jmd0OyBBPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNl IHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yay4g VGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhleTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5IGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZGRy ZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzPGJyPg0KJmd0OyZn dDsgcG9ydHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkgYmUg a25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmU8YnI+DQomZ3Q7Jmd0 OyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDIDxi cj4NCiZndDsmZ3Q7Z3JvdXAsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYmxl IHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdoaWNo IGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG88YnI+DQomZ3Q7Jmd0OyB0YWxr PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNr ZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJhbCBv ZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICZxdW90O2J1dCB0aGUgd2hvbGU8YnI+DQomZ3Q7Jmd0 OyBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWF5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBkZWFs czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhh dCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIDxicj4NCiZn dDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyPg0KJmd0 OyZndDtiZWhhdmlvcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3aGljaDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5p c21zIChpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bXVjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4p IFRoZSBvdGhlcjxicj4NCiZndDsmZ3Q7IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHdlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNo YWluIHdoZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWNlc3NhcnkuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2Vk IG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhl IHJlLWNsYXNzaWZpY2F0aW9uIDxicj4NCiZndDsmZ3Q7cG9pbnQuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBl eHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiA8YnI+DQomZ3Q7Jmd0O0lmIGl0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRo ZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgZ3JvdXAsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRl ZDxicj4NCiZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXkgdGhpcy4g SWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBpbnRlbnQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2YgY291 cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Z3Jv dXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwg dW5jbGVhciwgSSBhbSBub3Qgc3VyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2hhdCB0bzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5IG5leHQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg c2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFp bHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNm Yzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0 bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxp c3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4B75BMISOUT7MSGUSRCF_-- From nobody Mon Jul 14 06:31:21 2014 Return-Path: <lucy.yong@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA861A04C8 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Gv9_zESu0dmr for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 06:31:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3300B1A04BA for <sfc@ietf.org>; Mon, 14 Jul 2014 06:31:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA39712; Mon, 14 Jul 2014 13:31:07 +0000 (GMT) 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; Mon, 14 Jul 2014 14:31:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 06:30:48 -0700 From: Lucy yong <lucy.yong@huawei.com> To: "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HTo8BuVuTyW0ugIx3qXYbOUpugA2oA//+NmKA= Date: Mon, 14 Jul 2014 13:30:48 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.109] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453BF5FBdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CaOz5-TTssRv8oGXh4Ciy9askJg Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 13:31:19 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453BF5FBdfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ucXVlciB3aGF0IE1hcmlhIHNheXMuDQoNCkx1Y3kNCg0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOQVBJRVJBTEEsIE1BUklBIEgNClNlbnQ6 IE1vbmRheSwgSnVseSAxNCwgMjAxNCA4OjIxIEFNDQpUbzogUm9uIFBhcmtlcjsgWHV4aWFvaHU7 IG1pa2ViaWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb207IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KDQoNClRoZSBtZWFuaW5nIG9mIHRoZSBTRlAgSUQgaXMgcHJldHR5 IGNsZWFyLCBhdCBsZWFzdCB0byBtZSDigJMgYW4gYWJzdHJhY3QgaWRlbnRpdHkgZm9yIHRoZSBl eGFjdCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgKGkuZS4sIFNGUCBJRCAxID0g e1NGLUEtMSwgU0YtQi0zLCBTRi1DLTJ9KS4gICAgSW4gc29tZSB3YXlzLCBpdCBpcyBhIGNvbGxh cHNlZCDigJxsYWJlbCBzdGFja+KAnSDigJMgdGhlcmUgaXMgYSBzaW5nbGUgdGFnIGltcGx5aW5n IHNvbWUgc2VxdWVuY2Ugb2YgbmV0d29yayBsb2NhdGlvbnMuICAgQnV0LCB0aGlzIGFsc28gaW1w bGllcywgYXQgbGVhc3QgdG8gbWUsIHRoYXQgdGhlcmUgaXMgYSBjZW50cmFsIHBvaW50IG9mIHNl bGVjdGlvbiBmb3IgdGhpcyBlbmQgdG8gZW5kIHNlcXVlbmNlIChiYXJyaW5nIHJlY2xhc3NpZmlj YXRpb24sIG9mIGNvdXJzZSkuICAgSSwgZm9yIG9uZSwgYW0gcXVlc3Rpb25pbmcgdGhhdCBpbXBs aWNhdGlvbi4gICAgSSBoYXZlIGJlZW4gdW5jb21mb3J0YWJsZSB3aXRoIHRoYXQgY2VudHJhbCBw b2ludCBtZXRob2RvbG9neSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2YgZHluYW1p YyBzY2FsZSBhbmQgdGltZWxpbmVzcyBvZiByZWFjdGlvbiB0byBmYWlsdXJlcy4NCg0KPE1hcmlh PiBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0 dXJlIHRoYXQgc29tZXRoaW5nIGNhbGxlZCDigJxzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggSUTigJ0g aXMgY2FycmllZCBpbiB0aGUgcGFja2V0LCBiZWNhdXNlIGl0IGlzIG5vdCBuZWNlc3Nhcnkgb3Ig dGhlIG9ubHkgd2F5IHRvIGltcGxlbWVudCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBtaWdodCBz b2x1dGlvbnMgdGhhdCB3b3VsZCBkbyB0aGF0IGJ1dCBpdCBjYW5ub3QgYW5kIGRvZXNu4oCZdCBu ZWVkIHRvIGJlIG1hbmRhdGVkLg0KDQpNYXJpYQ0KDQpBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCBp cyB0byBzdGlsbCB1c2UgY2VudHJhbCBzZWxlY3Rpb24gdG8gc2VsZWN0IHRoZSBjaGFpbiBvZiBh YnN0cmFjdCBzZXJ2aWNlIGZ1bmN0aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwg U0YtQ30pLCBidXQgYWxsb3cgdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlz dHJpYnV0ZWQsIHJlYWxpemVkIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGcy4NCg0KR2l2 ZW4gYSB0b3BvbG9neSBsaWtlOg0KDQpDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0tLS0tLS0t LS0tLS0tLS0tLS0tIFNGRi0yIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0zLS0tLS0tLS0tLS0t LS0tLS0tLVNGRi00DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgU0ZGLUEtMSAgICAgICBTRkYtQS0yICAgICAgIFNT Ri1CLTEgICAgICAgIFNGRi1CLTIgICAgICAgICBTRkYtQy0xICAgICAgIFNGRi1DLTIgICAgICAg ICAgICAgICAgICAgU0ZGLUEtMw0KDQpBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZs b3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBnbyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQoxIENsYXNz aWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwgU0YtQiwgU0YtQ30NCjIgQ2xhc3Np ZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNG LUENCjMgQ2xhc3NpZmllciBlbmNhcHN1bGF0ZXMgcGFja2V0IGluZGljYXRpbmcgY2hhaW4gSUQg PSAxLCBzZXJ2aWNlIGluZGV4ID0gMQ0KNCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRv IFNGRi0xDQo1IFNGRi0xLCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2VydmljZSBpbmRleD0xLCBjaG9v c2VzIFNGRi1BLTIgYW1vbmdzdCBpdHMgYXZhaWxhYmxlIGluc3RhbmNlcyBvZiBTRi1BDQo2IFNG Ri0xIHNlbmRzIHBhY2tldCB0byBTRkYtQS0xDQo3IFNGRi1BLTEgc2VuZHMgcGFja2V0IGJhY2sg dG8gU0ZGLTENCjggU0ZGLTEgaW5jcmVtZW50cyBzZXJ2aWNlIGluZGV4IHRvIDINCjggU0ZGLTEg c2VsZWN0cyBTRkYtMiBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1CDQo5 IFNGRi0xIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0yDQoxMCBwcm9jZXNzIHJlcGVhdHMgcGVy IGFib3ZlIHVudGlsIFNGRi0zLCBhcyB0aGUgZWdyZXNzIGJvcmRlciwgcHJvZ3Jlc3NlcyB0aGUg cGFja2V0IHBlciByb3V0aW5nIHRhYmxlDQoNClRoYW5rcy4NCg0KDQogICBSb24NCg0KDQpGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1 DQpTZW50OiBTdW5kYXksIEp1bHkgMTMsIDIwMTQgMTE6MzAgUE0NClRvOiBtaWtlYmlhbmNAYW9s LmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRv OmpndWljaGFyQGNpc2NvLmNvbT47IG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNv bT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCg0KDQpBZ3JlZSB0aGF0IHRoZSBjdXJyZW50IGRlZmluaXRpb24g b2YgdGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJpdCBjb25mdXNpbmcsIGp1c3QgYXMg d2hhdCB5b3UgaGFkIHBvaW50ZWQgb3V0Lg0KDQoNCg0KSW4gbXkgdW5kZXJzdGFuZGluZywgdGhl IFNGUCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUgbmV0d29yayBzaG91bGQg YmUg4oCcYW4gb3JkZXJlZCBsaXN0IG9mIHNlcnZpY2Ugbm9kZXMgYW5kIFNGIElEc+KAnShzZWUg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMt YXJjaC0wMSkuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQIGluIHRoZSBkYXRh IHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRoZXIgdGhyb3VnaCBhIHBhdGggaWQg b3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVyZSB0aGUgc2VydmljZSBub2RlIG1l YW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNGRiBhbmQgdGhlIE5GIGNvbXBvbmVu dHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUgU0YgYW5kIFNGIHByb3h5IGNvbXBv bmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBiZSBhdHRhY2hlZCBvciBl bWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBhbmQgdGhvc2UgU0YgaW5zdGFuY2Vz IGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90LiAgSW4gdGhlIGNhc2Ugd2hlcmUg dGhlcmUgYXJlIG11bHRpcGxlIFNGIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlIChlLmcu LCBTRiBYKSBhcmUgYXR0YWNoZWQgdG8gYSBnaXZlbiBzZXJ2aWNlIG5vZGUsIHRoZSBzZXJ2aWNl IG5vZGUgY291bGQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB3aGljaCBuZWVkcyBTRiBYIGFtb25n IHRob3NlIFNGIGluc3RhbmNlcyBvZiBTRiBYIHR5cGUgbG9jYWxseS4gTWVhbndoaWxlLCB0aGVy ZSBtYXkgYmUgbXVsdGlwbGUgc2VydmljZSBub2RlcyB3aXRoaW4gYSBnaXZlbiBTRkMtZW5hYmxl ZCBkb21haW4gd2hpY2ggYXJlIGVtYmVkZGVkIG9yIGF0dGFjaGVkIHdpdGggdGhlIFNGIGluc3Rh bmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlLiBJbiB0aGlzIHdheSwgdGhlIFNGIGxvYWQtYmFsYW5j aW5nIHdvdWxkIGJlIG1hZGUgdmVyeSBmbGV4aWJsZS4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClhp YW9odQ0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KU2VudDog U2F0dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTQ0KVG86IGpndWljaGFyQGNpc2NvLmNvbTxt YWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgbW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBh dHQuY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT47IGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+OyBSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCg0KV291bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNlIGNoYWluIGlk ZW50aWZpZXIiIHRoZW4/ICBJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBsaXN0 IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGIGlu c3RhbmNlcywgdGhlbiBJIHdvdWxkIGluZmVyIHRoYXQgYSAic2VydmljZSBwYXRoIGlkZW50aWZp ZXIiIHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBhIHNl cnZpY2UgKmNoYWluKi4NCg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVz aW9uIGtlZXBzIGNyZWVwaW5nIGluLiAgVGhlIHRlcm1zICJjaGFpbiIgYW5kICJwYXRoIiBzZWVt IGluY29uc2lzdGVudC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IGpndWljaGFyQGNpc2NvLmNvbTxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbT4+DQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWlr ZWJpYW5jQGFvbC5jb20+LG1uMTkyMUBhdHQuY29tPG1uMTkyMUBhdHQuY29tPixtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2Vs aGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbT4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdv cmtzLmNvbTxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPixzZmNAaWV0Zi5vcmc8c2Zj QGlldGYub3JnPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFuY0Bhb2wuY29tJTNl LG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxQGF0dC5jb20lM2UsbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Usam1oQGpvZWxoYWxwZXJu LmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2ZjQGlldGYub3JnJTNj c2ZjQGlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNA0KU3ViamVjdDogUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpZb3VyIGRl ZmluaXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5n IHBhdGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRh dGEgc3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFu Y2VzIGJhc2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZh aWxhYmxlIGFuZCB3aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxh eS4gV2hlbiBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsg eW91IG1heSBvciBtYXkgbm90IHVwZGF0ZSB0aGF0IGRhdGEgc3RydWN0dXJlIHRvIHNwZWNpZnkg d2hpY2ggbmV4dC1ob3BzIG1heSBiZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3b3Vs ZCBlZmZlY3RpdmVseSBuYWlsIHVwIHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2VydmljZSBj aGFpbikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvIG1lY2hh bmlzbSB0byBwb3B1bGF0ZSB0aGUgZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCg0KRnJvbTogIm1p a2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4iIDxtaWtlYmlhbmNAYW9s LmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDExLCAy MDE0IGF0IDEyOjE4IFBNDQpUbzogSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFp bHRvOmpndWljaGFyQGNpc2NvLmNvbT4+LCAibW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBh dHQuY29tPiIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LCAibW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4sICJqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+IiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWls dG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQoNCkkgdGhpbmsgdGhpcyBpcyB0aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOg0KDQo+IEkgZG9u 4oCZdCB3YW50IHRvIHNwZWNpZnkNCj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5k IFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQo+IGFzc2lnbiBhIHNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMy LT5TMw0KPiBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KDQpCeSBkZWZpbml0 aW9uLCBJIHVuZGVyc3Rvb2QgYSAic2VydmljZSBwYXRoIiB0byBiZSBhbiBvcmRlcmVkIGxpc3Qg b2Ygc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNl IGEgInNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIiB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWlu KiB0aGF0IHNwZWNpZmljYWxseSAiW2RvZXMgbm90XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNl cyIuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqZ3VpY2hhckBj aXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48amd1aWNoYXJAY2lzY28uY29tPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFA YXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sSm9lbCBN LiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ PixSb24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBK dWx5IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCg0KTWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRo ZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQphIGRhdGEg c3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91 IGRlZmluZSBhDQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1pZ2h0KiB3 aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0 IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCkhvd2V2ZXIs IHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1cmFsIHN0YW5k cG9pbnQgKEkNCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZl IHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2Ug cGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhlbiBwdXNoIHRo YXQgaW5mb3JtYXRpb24gaW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUg YQ0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGlu ZyB3b3VsZCBjb250YWluIHRoZQ0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUg U0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4dC1ob3BzIGlz IHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50cmFsaXplZA0K Y29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1p Y2FsbHkgdGhyb3VnaA0Kc29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdp dmVuIHRoaXMgaXQgaXMgbm90IGNvcnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGgg bWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkNCmFsdGhvdWdo IGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5k ZWQpIHRvIGRvDQpzby4NCg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1h a2UgdGhpcyBjbGVhcjoNCg0KSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFz IFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMgc2F5IEkgd2Fu dCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0K c3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9u IHRoZXJlb2YpLiBJDQphc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0g dGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1c2ggdGhpcyBp bnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQpwb3B1 bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJh ZmZpYyBhcnJpdmVzDQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3 aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQg cG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQplbmNhcHN1bGF0 aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZ cyBzYXkgd2UNCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0 byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0 ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICJO QVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+ PiB3cm90ZToNCg0KPkppbSwNCj4NCj5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZp bml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4ic2VydmljZSBwYXRoIGlkZW50aWZp ZXIiPw0KPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUg Y2hvc2VuIGFwcmlvcmkgKHdoaWNoDQo+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0aGVu IGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPm5leHQtaG9wIFNGRiB0byBw aWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1hcmlhDQo+DQo+DQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogSmltIEd1aWNoYXJkIChqZ3Vp Y2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBGcmlkYXksIEp1bHkg MTEsIDIwMTQgMTE6MTUgQU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBK b2VsIE0uDQo+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0 IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IHByZXZlbnRzIGZ1 bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZp Y2UNCj4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+Pg0KPj4gT24g Ny8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxt YWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4+DQo+PiA+RGl0dG8uDQo+PiA+DQo+PiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+ID4+IFNlbnQ6IEZyaWRh eSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNo YXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+PiA+PiBQYXJr ZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gU3ViamVjdDogUkU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pg0K Pj4gPj4gUmUtLA0KPj4gPj4NCj4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMg aXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPj5kcmFmdC4NCj4+ID4+DQo+PiA+PiBN YW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRo YXQgdGhlIGZ1bGwNCj4+ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2Vk Lg0KPj4gPj4NCj4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0 aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZg0KPj4gPj5zaG91bGQgYmUNCj4+ID4+IHByb3Zp ZGVkIGluc3RlYWQuDQo+PiA+Pg0KPj4gPj4gQ2hlZXJzLA0KPj4gPj4gTWVkDQo+PiA+Pg0KPj4g Pj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4gPkRlIDogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+PiA+PiA+ KGpndWljaGFyKQ0KPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6 MTgNCj4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5PYmpldCA6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g Pj4gPg0KPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxs eSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0 byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+PiA+PiA+d2l0 aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50 IHRvIGENCj4+ID4+bG9va3VwDQo+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2gg dGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdA0KPj5zdXJlDQo+PiA+Pmhvdw0KPj4g Pj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4NCj4+ID4+ID5PbiA3 LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFp bHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4gPj5BYnNvbHV0 ZWx5Lg0KPj4gPj4gPj4NCj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSmltIEd1aWNoYXJkDQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gU2VudDogRnJp ZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gVGhlbiBJIG1p c3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZQ0K Pj4gPj50aGF0IGlmDQo+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNp b24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0KPj4gPj4gPj4+ Zm9yDQo+PiA+PiA+Pj4gYSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0 aGUgY2hhaW4gdGhlbiB5b3UNCj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+PiBzdXJlIHRo YXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8N Cj4+ID4+cmVhY2gNCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3IgdGhl IGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ID4+ID4+Pg0K Pj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5 MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gPj4gd3JvdGU6DQo+PiA+PiA+ Pj4NCj4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0 YW50aWF0ZWQgb25seSBpbg0KPj5yZWxldmFudA0KPj4gPj4gPj4+U0ZGcw0KPj4gPj4gPj4+ID53 aGVuIHRoZXkgImFycml2ZSIuDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ID4+PiA+Pihq Z3VpY2hhcikNCj4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBB TQ0KPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ DQo+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlm IEkgaGF2ZSB1bmRlcnN0b29kDQo+PnRoZQ0KPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+ID4+ID4+ PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBldmVy eSBzaW5nbGUNCj4+U0YNCj4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+ Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBu byB3YXkgdG8NCj4+a25vdw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ID4+ID4+PiA+ PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdp dmVuDQo+PnBvaW50DQo+PiA+PmluDQo+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4+ID4+DQo+PiA+ PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+IHdyb3RlOg0K Pj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSBy ZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4+d2l0aA0KPj4gPj50aGUNCj4+ID4+ID4+ PiA+PnlvdXINCj4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5k IEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4+ID4+ID4+PnVuZGVyc3RhbmQNCj4+ID4+ID4+ PiA+PiA+aXQuKQ0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhh cyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+PiA+Pm5leHQN Cj4+ID4+ID4+PiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUg b25lIGl0IGRlbGl2ZXJzDQo+PnRvKSwNCj4+ID4+aW4NCj4+ID4+ID4+PmV2ZXJ5DQo+PiA+PiA+ Pj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+PiA+Pj4gPj4g Pg0KPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxs IHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PmV2ZXJ5DQo+PiA+ PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5k IHN0YXRlZnVsIGxvYWQNCj4+ID4+ID4+PmJhbGFuY2VyLg0KPj4gPj4gPj4+ID4+ID5JIGFodmUg bm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yDQo+PiA+ PnN0YXRlZnVsLg0KPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVx dWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsDQo+PiA+PmZsb3cNCj4+ID4+ID4+PiA+PiA+ c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0K Pj4gPj5hY2NlcHRhYmxlDQo+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiA+PiA+Pj4gPj4g Pg0KPj4gPj4gPj4+ID4+ID5Zb3VycywNCj4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gPj4gPj4+ID4+ ID4NCj4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJ IGFtIHRyeWluZyB0byBtYWtlIHRoaXMNCj4+d29yaw0KPj4gPj4gPj4+ID4+c2Vuc2libHkNCj4+ ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVj dCB0aGF0IHRoZQ0KPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3Zl ciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPj53aWxsDQo+PiA+PmJlDQo+ PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBz ZXJ2aWNlIGNoYWlucw0KPj50byBiZQ0KPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+PiA+PiA+Pj4g Pj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5h YmxlDQo+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2Uu IEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4+ID4+ZHJpdmUu DQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2Ug YWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4+ID4+ZHJpdmVuDQo+PiA+PiA+ Pj5ieQ0KPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVk IHNlcnZpY2UgcGF0aHMuIEl0IGlzDQo+PiA+PmhhcmRlcg0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+ PiA+PnNlZQ0KPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4g YmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4g Pj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4+ID4+ID4+DQo+ PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZl IEkgZGVzY3JpYmVkIGlzDQo+PiA+Pm91dHNpZGUNCj4+ID4+ID4+Pm9mDQo+PiA+PiA+Pj4gPj50 aGUNCj4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90 IHNvbWV0aGluZyB3ZSBhcmUNCj4+ID4+dGFza2VkIHRvDQo+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4g Pj4gPj4+ID4+ID4+b24uDQo+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2 aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhDQo+PmNlcnRhaW4NCj4+ID4+ID4+PndheS4N Cj4+ID4+ID4+PiA+Pml0DQo+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUg dGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+ PiA+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+ Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2Vydmlj ZSBpbnN0YW5jZXMNCj4+ID4+IHRoYXQNCj4+ID4+ID4+PiA+Pm5lZWRzDQo+PiA+PiA+Pj4gPj4g Pj4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50 YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ID4+YWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+ PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMg bGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+IGNvbXBsZXgNCj4+ID4+ID4+PiA+PiA+Pj4+ IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2Ug YQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8g cmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlvdXMg YXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PmR5bmFtaWMNCj4+ID4+ ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBv cmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPj53aGljaA0KPj4gPj5hcmUNCj4+ID4+ID4+ PiA+PmJpZ2dlcg0KPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9m aXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+ Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGlj YXRlZCwgdGhhdA0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+Pj5nb29kDQo+PiA+PiA+Pj4gPj4gPj4+ IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+ PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1 cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBh cmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPjsNCj4+SWFuDQo+PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+PiA+PiA+Pj4g c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PkJhbGFuY2Vy cw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVj dHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxkDQo+PnByZWZlcg0KPj4gPj53ZQ0KPj4g Pj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRo YW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+ PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRo ZSBjb250cm9sDQo+PiA+PnJlcXVpcmVtZW50cw0KPj4gPj4gPj4+YW5kDQo+PiA+PiA+Pj4gPj4g dGhlDQo+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ID4+ID4+PiA+ PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9u IGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiBuZWVkcw0KPj4g Pj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQg bWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gYWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+ PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBp cyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj5jb21wbGV4DQo+PiA+PiA+Pj4gPj4gPj4+ IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2Ug YQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVyZSB0byBy ZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4+ID4+ ID4+PiA+PiA+Pj4gSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBCdXQg aXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+ PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+ Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBlbmQNCj4+c2Vs ZWN0aW9uDQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMg cGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+ID4+PiA+PmNsYXNzaWZp ZXIpDQo+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFz c2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj5TRkZzKT8NCj4+ ID4+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xh c3NpZmljYXRpb24uDQo+PkFuZA0KPj4gPj4gPj4+c3VyZWx5LA0KPj4gPj4gPj4+ID4+ID4+Pj4g dGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+PiA+ PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHBy b2FjaCBldmVuDQo+PiB0aG91Z2gNCj4+ID4+IGENCj4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIg YW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+PmxvY2FsDQo+ PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWly ZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0KPj4gPj5UaGlzDQo+PiA+ PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0 aCBpZCBhdCBhbGwuDQo+PiA+Pk15DQo+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZh dm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0KPj5ieQ0KPj4gPj4gPj4+ ID4+aW5jcmVhc2VkDQo+PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2Jh bCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGENCj4+Z2xvYmFsDQo+PiA+PiA+Pj5wYXRoDQo+PiA+ PiA+Pj4gPj5pZA0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUg b2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcgdG8NCj4+ID4+YWx0ZXINCj4+ID4+ID4+PnRoZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5 IGFmZmVjdGVkDQo+PmVuZC10by1lbmQNCj4+ID4+ID4+PnBhdGguDQo+PiA+PiA+Pj4gPj4gPj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMN Cj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0KPj4gPj4gPj4+ ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpv ZWxoYWxwZXJuLmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPj4yMDE0DQo+PiA+PiA2 OjE1DQo+PiA+PiA+Pj4gUE0NCj4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNv bTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBJLlNtaXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0 aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6 DQo+PiA+PiBSZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGlu Zw0KPj50bw0KPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hh aW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUNCj4+ZXhpdA0K Pj4gPj5mcm9tDQo+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQg ZnVuY3Rpb25zDQo+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28g dGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+ID4+IGNob29z ZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZp Y2UiIGRlbGl2ZXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJz LCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8xNCwg NjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiB3cm90 ZToNCj4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBk cmFmdCB0aGF0IHN1Z2dlc3RzIGFueQ0KPj4gPj5zb3J0DQo+PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0 aGUgZW50aXJlDQo+PiA+PnBhdGgNCj4+ID4+ID4+PihhbGwNCj4+ID4+ID4+PiA+PiA+Pj4+PiBT RklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlDQo+PnRo aXMNCj4+ID4+ID4+Pm1lYW5zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFz c2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyDQo+PmNob29zZXMgYQ0KPj4gPj5TRg0KPj4g Pj4gPj4+ID4+Q2hhaW4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBs YXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAg d2hlcmUNCj4+ID4+IFNGSShuKQ0KPj4gPj4gPj4+IGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0 ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LA0KPj4g Pj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAi YnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4+ID4+ID4+PiBvcHBvc2VkDQo+PiA+PiA+Pj4g Pj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRv IHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZg0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBu ZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQg aXMNCj4+ID4+bmVjZXNzYXJ5DQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxl Y3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsDQo+PiA+ PmFuZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kg Zm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MNCj4+ID4+bmV0d29yaw0KPj4gPj4gPj4+ID4+ID4+Pj4+ PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUN Cj4+ID4+ID4+PmNyZWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5j dGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4gPj5mb3J3YXJkaW5nDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4g U0ZQIGlzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZp bmVkIFNGQy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNG QyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4+ID4+bm9uLWlu aXRpYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBh Y2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0 aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0K Pj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkg cmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4+ID4+U0ZQLCBhbg0KPj4gPj4gPj4+ ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRo aXMgaXMNCj4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFz ICJicmFuY2hpbmciLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0t DQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21p dGhARjUuY29tPG1haWx0bzoqSS5TbWl0aEBGNS5jb20+PEkuU21pdGhARjUuY29tPG1haWx0bzpJ LlNtaXRoQEY1LmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+ PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9l bGhhbHBlcm4uY29tPj4sSm9lbA0KPj4gPj4gTS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4g Pj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxt YWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0BzY2UuDQo8bWFpbHRvOmh1YW5nQHNj ZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Y2E+LHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkDQo+PiA+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWluZy4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBv ZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj50aGF0IGlzDQo+PiA+PiA+Pj53aGF0 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Yg c2VydmljZSBjaGFpbnMgaXMNCj4+ID4+ID4+PnByZWNvbmNlaXZlZA0KPj4gPj4gPj4+ID4+ID4+ Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0 aA0KPj4gdGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBv ZiBhaW0sIHNvbWUgZGVncmVlIG9mDQo+PiA+PmFzcGlyYXRpb24NCj4+ID4+IHRvDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9m IHRoZQ0KPj4gPj5hcmNoaXRlY3R1cmUNCj4+ID4+ID4+Pi0NCj4+ID4+ID4+PiA+PiA+Pj4+PiB5 b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbg0K Pj4gPj4gPj4+YXJiaXRyYXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFy IiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPj4gPj4gPj4+ID4+aW50ZW50 aW9uYWwNCj4+ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lz aW9ucyB0aGF0IGhhdmUgbGFzdGluZw0KPj4gPj5pbXBhY3RzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LA0KPj4g Pj5hZGRyZXNzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5n cy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3Vs YXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEZy b206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0 bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+PlNlbnQ6DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2Vs IE0uDQo+PiA+PiBIYWxwZXJuOw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRv bi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsgc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0KPj4gPj5TZXJ2aWNlDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVl IHdpdGggbWUgYXQgYWxsIGluIHRoaXMNCj4+ID4+cmVnYXJkLg0KPj4gPj4gPj4+SQ0KPj4gPj4g Pj4+ID4+YW0NCj4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hp dGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ID4+cHJvaGliaXQNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG8N Cj4+ID4+SHVhbmcncw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBz YXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPj4gPj4gcmVxdWlyZWQNCj4+ID4+ID4+ PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0 cnlpbmcgdG8gcHJvaGliaXQNCj4+c3VjaA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hl dGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uDQo+PiA+PiBtYW55 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUg V0cuIEkgaGFwcGVuIHRvDQo+PnRoaW5rDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PnRoZXkNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5 IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG8NCj4+ID4+a25vdw0KPj4gPj4gPj4+d2hhdA0KPj4gPj4g Pj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1h bmFnZSB0ZW5zIG9mDQo+PiA+PiA+Pj5taWxsaW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0K Pj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29y ayBhbmQgZGF0YSBjZW50ZXINCj4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXku IFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluDQo+PnRoZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5 b3UNCj4+IGFyZQ0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ID4+IGdvaW5nDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxs eQ0KPj5zbWFsbA0KPj4gPj4gPj4+IG51bWJlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+PiBvZiBhY3Rp dmUgc2VydmljZSBwYXRocz8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUN Cj4+IHRoYW4NCj4+ID4+ID4+PiA2NEsiDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4g Pj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBN LiBIYWxwZXJuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb208bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2Rh eSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9u LmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywNCj4+YW5kDQo+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBO bywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+PiA+ PiA+Pj5hcmNodGlldHVyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHks IHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPj50aGVpcg0KPj4gPj4gPj4+ID4+ID4+ Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1 cmQNCj4+IHVzZQ0KPj4gPj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4g U2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmUN Cj4+ZG9lcw0KPj4gPj4gPj4+cGVybWl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2Uu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3Qg cmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiBwZXJtaXRzDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3Ig cmVxdWlyZWQgYnkNCj4+ID4+dGhlDQo+PiA+PiA+Pj53b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ PiBJdCBpc24ndC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91 cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8x MC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsDQo+ Pm1lYW4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFy Z2VyIHRoYW4gdGhlIHJvdXRpbmcNCj4+dGFibGUNCj4+ID4+b2YgYQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gY29yZSByb3V0ZXIuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gQ2hhbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBP biAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50 cywgZnJvbQ0KPj4xDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAw MCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGUNCj4+dGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleQ0K Pj4gPj5jaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55 IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQNCj4+ID4+IHByb3Zpc2lv bg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBN LCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWws DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEhvdyBtYW55 IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcA0KPj4gPj4gc2Vydmlj ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNo IGhvcD8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFy aWENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206 KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmDQo+PiBPZg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXks IEp1bHkgMTAsIDIwMTQNCj4+ID4+MzowMw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAqVG86 KiBMdWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bh b2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2Vy dmljZQ0KPj4gQ2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEx1Y3ksDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE92 ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBtYWtl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50 aWZpZXIgY2FuIGJlIHVzZWQgdG8NCj4+ID4+IGRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUg dHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8NCj4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tl dHMNCj4+bXVzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEg cGF0aCBpZGVudGlmaWVyLCB0aGUgZXhhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJl Y3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uDQo+PnRoaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRo ZSBwYXRoDQo+PiA+PiBpZGVudGlmaWVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVz IG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4NCj4+ID4+IHJlc3Vs dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWln aHRlZCkgdHJhbnNwb3J0IG5leHQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwg YXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25n QGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPg0KPj4gPj4gPG1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbT48bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJTNlPj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVz ZSBvZg0KPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+PiA+PmFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpPbiBCZWhhbGYNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPg0KPj4gPj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+ID4+PiA+PiBKdWx5 DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNA YW9sLmNvbTxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZzxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdl ZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRv DQo+PmRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBh IFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+IGV2ZXJ5DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBm b3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlv bnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu Zm9ybWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+ IHJlcXVpcmVkDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBz ZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2VkIHRvDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBh Y3Rpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlz Y3Vzc2lvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Q2hlZXJzLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBN ZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoq c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZv ecOpIDoqbWVyY3JlZGkgOQ0KPj4gPj4ganVpbGxldA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAy MDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBl cm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+O3NmY0BpZXRmLm9yZzxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5v cmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQg OipSZTogW3NmY10gU2VydmljZQ0KPj4gPj5DaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4NCj4+U0YNCj4+ID4+IENoYWluDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFu ZCBTRg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90 aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4+ID4+Y2xl YXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUNCj4+YWdy ZWVzDQo+PiA+Pm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBw b2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+d2hldGhlcg0KPj4gPj5pdCBpcw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVs eSBzcGVjaWZ5IHdoYXQNCj4+ID4+dGhlIElEDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRo ZSBTRkMgSGVhZGVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFm dA0KPj4gPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0 aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXINCj4+ZHJhZnRzDQo+PiA+PnRvDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFz ZWQgb24gY2hhaW4NCj4+IG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBj aG9pY2Ugb2YgY2hhaW4gb3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIgKGFt YmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlDQo+ PiA+PiBvbmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBv cHRpb25hbCkgdG8gYXZvaWQgc29tZQ0KPj4gdmVuZG9ycw0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBT RkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4NCj4+Pj4+ Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+ PiA+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pi0t DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToq am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20+PGptaEBqb2Vs aGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBl cm4uY29tPjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20l M2U+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxtYWlsdG86KnNm Y0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPjxtYWlsdG86 c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4+ICpTZW50OipUdWVzZGF5LA0KPj4g Pj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj5Mb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseQ0KPj5hbnN3 ZXINCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29tbWVudHMgdGhh dCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUNCj4+ID4+ID4+PiBwcm9wb3NlZA0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4g Z2V0DQo+PiB3b3JraW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBv biB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+IGltcHJvdmUNCj4+ID4+IHRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3Qg cGFydGljaXBhdGVkIGluDQo+PiA+PnRoZQ0KPj4gPj4gV0cNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHdvcmtpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8g d2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkNCj4+ID4+cGVyc29uYWwNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQg aXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0DQo+PiA+PndoYXQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVy ZS4gV2UNCj4+YXJlDQo+PiA+PiBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGlu ZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNv bXBhc3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFu ZCBwb2xpY3kgZnVuY3Rpb25zLA0KPj52aXJ0dWFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1h Y2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+PiA+PiBhc3BlY3Rz Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJl c3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkDQo+PiB0bw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNo IGFyZSBkZWFsdCB3aXRoDQo+PiA+PmFib3ZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJl IHdlIGFyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUN Cj4+IGRvaW5nLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsDQo+PmFz IEkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+ IHRoZW0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxv YWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQNCj4+ID4+bGVhc3QNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kDQo+ PndpbGwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWlu aW5nLiBUaGVyZSBwcm9iYWJseSBhcmUNCj4+ID4+bW9yZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZg0KPj4g Pj50aGVzZSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQg YW55IHBhcnRpY3VsYXIga2luZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGJlIHVzZWQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJv dmlkZWQgdG8gdGhlIGVuZA0KPj4gPj51c2VyLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlz IGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlcg0KPj5wYWNrZXRzLA0KPj4g Pj5hbmQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4+ID4+ID4+ PiA+PiA+Pj4+PiBtYXJrcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBvciAuLi4pIHNv IGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlDQo+PiA+Pmluc3RhbmNlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBp bXBvcnRhbnQNCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0 byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4NCj4+ID4+SXQncw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBo b3cgc2VydmljZQ0KPj4gPj4gY2hhaW5pbmcgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9u ZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiA+PmFyY2h0aWVjdHVy ZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVj dGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBw YWNrZXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIp IFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUNCj4+Y2FuDQo+ PiA+PmhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+ IGFwcGVhcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcg YXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlDQo+PnBvaW50DQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVs aXZlcmVkDQo+PiA+PmJ5IGENCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5 IGluY2x1ZGluZw0KPj5vbmUgb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2Fk IGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBp cw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5p bmcgZGF0YSBwbGFuZQ0KPj4gPj5tZWNoYW5pc21zLg0KPj4gPj4gSXQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wN Cj4+ID4+bWVjaGFuaXNtcywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSBy ZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwNCj4+YW5kDQo+PiA+PnZtDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFj dCBvZg0KPj5wZXJtaXR0aW5nDQo+PiA+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMg bGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4gPj50ZXJtaW5v bG9neQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJv aGliaXRpbmcgaXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkNCj4+c2VsZWN0 aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+ID4+dHJhZmZpYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlDQo+PiB0 aGF0DQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlv biBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4NCj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPj5jb21iaW5l ZC4gSQ0KPj4gPj4gdGVuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHJlZmVyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9m IGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UNCj4+ID4+Y2hhaW5pbmcNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVz ZSBjbHVzdGVyDQo+PmlzDQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJt LiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLg0KPj4gVGh1cywNCj4+ID4+ IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNp bmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXJl Y3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQNCj4+ID4+c2luZ3Vs YXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25z IGluIGRpZmZlcmVudCBwbGFjZXMNCj4+aW4NCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRoLyBT ZXJ2aWNlIGNoYWluIGlzIGENCj4+ID4+IHNlcXVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YNCj4+ID4+ cGFja2V0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlp bmcgdGhhdCBzb21lIHN1YnNldCBvZg0KPj50cmFmZmljDQo+PiA+PmlzDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0K Pj5maXJld2FsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJz ZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlDQo+PmNhY2hlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4g d2l0aG91dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2Vydmlj ZSBmdW5jdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlDQo+PnBhY2tl dHMuDQo+PiBBDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29t ZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+PiA+PmxvY2F0aW9ucw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIg b3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVs aXZlcnkgbG9jYXRpb25zLiBUaGV5DQo+PiA+Pm1heSBiZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzDQo+PiBw b3J0cw0KPj4gPj4gb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUg bWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZQ0KPj4gPj5sb2NhdGlvbnMNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3Ry dWN0dXJlDQo+PiBhbmQNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmFuc3Bv cnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9t IHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMNCj4+Z3JvdXAsDQo+PiA+ PiB3ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRo ZQ0KPj4gPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3aGljaCBkcml2 ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvDQo+PiB0YWxrDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGlu IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZl IHNhaWQgImJ1dCB0aGUgd2hvbGUNCj4+IHBhdGgNCj4+ID4+IG1heQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVh bHMNCj4+ID4+d2l0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3 YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikNCj4+b24NCj4+ID4+bG9hZA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMg YW5kDQo+PmJlaGF2aW9ycw0KPj4gPj4gd2hpY2gNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJl IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbg0KPj4gPj5t dWNoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdp dGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0 byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gcHJvdmlzaW9uDQo+PiA+PiB3 ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhh dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGlu IG1pZC1jaGFpbiB3aGVuDQo+PiA+PiBuZWNlc3NhcnkuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lm aWNhdGlvbg0KPj5wb2ludC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVy Lg0KPj5JZiBpdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVu dCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nDQo+PiA+PiBncm91cCwNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSBu ZWVkZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUg d29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZQ0KPj4gPj4gaW50ZW50LA0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUg d29ya2luZw0KPj4gPj5ncm91cA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZ3JlZW1lbnRzLiBJ ZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1cmUNCj4+ID4+d2hhdCB0bw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4g PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4g Pj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+PiA+Pj4gbWFp bGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBzZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNm Yw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4g bWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+ PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ ID4+ID4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4g Pj4NCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QN Cj4+ID4+ID4+PiA+PiA+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+ Pj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+ Pj4gPj4NCj4+ID4+ID4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gPj4gPj4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiBz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiBz ZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQo+PiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4+ID4+ID4NCj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID5zZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_2691CE0099834E4A9C5044EEC662BB9D453BF5FBdfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJ cGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFp blRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6U2ltU3VuO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWlu ZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5QbGFpblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlNlZ29lIFVJIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglm b250LWZhbWlseTpTaW1TdW47fQ0KcC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5bGUtbmFtZTrm ibnms6jmoYbmlofmnKw7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTpTaW1TdW47fQ0K cC5IVE1MLCBsaS5IVE1MLCBkaXYuSFRNTA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7m oLzlvI8iOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofm nKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aW h+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuYTAsIGxpLmEw LCBkaXYuYTANCgl7bXNvLXN0eWxlLW5hbWU657qv5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLn uq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Db25xdWVyIHdoYXQgTWFyaWEgc2F5cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+THVjeTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5OQVBJRVJBTEEsIE1BUklBIEg8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDE0 LCAyMDE0IDg6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvbiBQYXJrZXI7IFh1eGlhb2h1OyBtaWtl YmlhbmNAYW9sLmNvbTsgamd1aWNoYXJAY2lzY28uY29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG1lYW5pbmcgb2YgdGhlIFNG UCBJRCBpcyBwcmV0dHkgY2xlYXIsIGF0IGxlYXN0IHRvIG1lIOKAkyBhbiBhYnN0cmFjdCBpZGVu dGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcyAoaS5l LiwgU0ZQIElEIDEgPSB7U0YtQS0xLA0KIFNGLUItMywgU0YtQy0yfSkuJm5ic3A7Jm5ic3A7Jm5i c3A7IEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFiZWwgc3RhY2vigJ0g4oCT IHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5ldHdvcmsg bG9jYXRpb25zLiZuYnNwOyZuYnNwOyBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBsZWFzdCB0 byBtZSwgdGhhdCB0aGVyZSBpcyBhIGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0aW9uIGZvciB0aGlz IGVuZCB0byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcNCiByZWNsYXNzaWZpY2F0aW9uLCBvZiBjb3Vy c2UpLiZuYnNwOyZuYnNwOyBJLCBmb3Igb25lLCBhbSBxdWVzdGlvbmluZyB0aGF0IGltcGxpY2F0 aW9uLiZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgYmVlbiB1bmNvbWZvcnRhYmxlIHdpdGggdGhh dCBjZW50cmFsIHBvaW50IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdvcmxkIGNvbXBsZXhpdGll cyBvZiBkeW5hbWljIHNjYWxlIGFuZCB0aW1lbGluZXNzIG9mIHJlYWN0aW9uIHRvIGZhaWx1cmVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jmx0O01hcmlhJmd0OyBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRh dGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgc29tZXRoaW5nIGNhbGxlZCDigJxzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGggSUTigJ0gaXMgY2FycmllZCBpbiB0aGUgcGFja2V0LCBiZWNhdXNl IGl0IGlzDQogbm90IG5lY2Vzc2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVtZW50IHNlcnZp Y2UgY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxkIGRvIHRoYXQgYnV0 IGl0IGNhbm5vdCBhbmQgZG9lc27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N YXJpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNlIGNl bnRyYWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0aGUgY2hhaW4gb2YgYWJzdHJhY3Qgc2VydmljZSBm dW5jdGlvbnMgKGkuZS4sIFNGQyBJRCAxID0ge1NGLUEsIFNGLUIsIFNGLUN9KSwgYnV0IGFsbG93 DQogdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQsIHJlYWxp emVkIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGcy4mbmJzcDsmbmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+R2l2ZW4gYSB0b3BvbG9neSBsaWtlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xhc3NpZmllciAtLS0tLS0tJm5i c3A7IFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0yIC0tLS0tLS0tLS0tLS0tLS0tLS0t IFNGRi0zLS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtTRkYtQS0xJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwO1NGRi1BLTImbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 U1NGLUItMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRkYtQi0y Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NGRi1DLTEm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U0ZGLUMtMiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRkYtQS0zPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B bmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBn byBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSBDbGFzc2lmaWVyIHNlbGVjdHMgY2hh aW4gU0ZDIElEIDEge1NGLUEsIFNGLUIsIFNGLUN9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjIgQ2xhc3NpZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGlu c3RhbmNlIG9mIFNGLUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MyBDbGFzc2lmaWVy IGVuY2Fwc3VsYXRlcyBwYWNrZXQgaW5kaWNhdGluZyBjaGFpbiBJRCA9IDEsIHNlcnZpY2UgaW5k ZXggPSAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjQgQ2xhc3NpZmllciBwcm9ncmVz c2VzIHBhY2tldCB0byBTRkYtMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj41IFNGRi0x LCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2VydmljZSBpbmRleD0xLCBjaG9vc2VzIFNGRi1BLTIgYW1v bmdzdCBpdHMgYXZhaWxhYmxlIGluc3RhbmNlcyBvZiBTRi1BPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+NyBTRkYtQS0xIHNlbmRzIHBhY2tldCBiYWNrIHRvIFNGRi0xPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjggU0ZGLTEgaW5jcmVtZW50cyBzZXJ2aWNlIGluZGV4 IHRvIDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+OCBTRkYtMSBzZWxlY3RzIFNGRi0y IGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+OSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xMCBwcm9jZXNzIHJlcGVhdHMgcGVyIGFib3ZlIHVudGls IFNGRi0zLCBhcyB0aGUgZWdyZXNzIGJvcmRlciwgcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciBy b3V0aW5nIHRhYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbPGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5YdXhpYW9odTxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXks IEp1bHkgMTMsIDIwMTQgMTE6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86 amd1aWNoYXJAY2lzY28uY29tIj4NCmpndWljaGFyQGNpc2NvLmNvbTwvYT47IDxhIGhyZWY9Im1h aWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFs cGVybi5jb208L2E+OyBSb24gUGFya2VyOw0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBSZWRlZmluZSB0aGUg U0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZSB0aGF0IHRo ZSBjdXJyZW50IGRlZmluaXRpb24gb2YgdGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJp dCBjb25mdXNpbmcsIGp1c3QgYXMgd2hhdCB5b3UgaGFkIHBvaW50ZWQgb3V0LiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbXkgdW5kZXJzdGFuZGlu ZywgdGhlIFNGUCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUgbmV0d29yayBz aG91bGQgYmUg4oCcYW4gb3JkZXJlZCBsaXN0IG9mIHNlcnZpY2Ugbm9kZXMgYW5kIFNGIElEc+KA nShzZWU8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJh c2VkLXNmYy1hcmNoLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJp bmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxPC9hPikuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2Vu dCB0aGUgU0ZQIGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRo ZXIgdGhyb3VnaCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVy ZSB0aGUgc2VydmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNG RiBhbmQgdGhlIE5GIGNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUg U0YgYW5kIFNGIHByb3h5IGNvbXBvbmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBj b3VsZCBiZSBhdHRhY2hlZCBvciBlbWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBh bmQgdGhvc2UgU0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90 LiAmbmJzcDtJbiB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2Vz IG9mIHRoZSBzYW1lIFNGIHR5cGUgKGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdpdmVu IHNlcnZpY2Ugbm9kZSwgdGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBkaXN0cmlidXRlIHRoZSB0cmFm ZmljIHdoaWNoIG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzIG9mIFNGIFggdHlw ZSBsb2NhbGx5LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVz IHdpdGhpbiBhIGdpdmVuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3Ig YXR0YWNoZWQgd2l0aCB0aGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRo aXMgd2F5LCB0aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZSB2ZXJ5IGZsZXhpYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlhpYW9odTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMg WzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gU2F0 dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1uMTkyMUBhdHQuY29tIj4NCm1uMTkyMUBhdHQuY29tPC9hPjsgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2Vs aGFscGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdv cmtzLmNvbSI+DQpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPldvdWxkbid0IHRoYXQgYmUgY2FsbGVkIHRoZSAmcXVvdDtzZXJ2aWNlIGNoYWluIGlkZW50 aWZpZXImcXVvdDsgdGhlbj8gJm5ic3A7SWYgdGhlIHNlcnZpY2UgY2hhaW4gaXMgdGhlIG9yZGVy ZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlIG9yZGVyZWQgbGlzdCBv ZiBTRiBpbnN0YW5jZXMsIHRoZW4gSSB3b3VsZA0KIGluZmVyIHRoYXQgYSAmcXVvdDtzZXJ2aWNl IHBhdGggaWRlbnRpZmllciZxdW90OyB3b3VsZCBiZSBhbiBpZGVudGlmaWVyIGZvciBhIHNlcnZp Y2UgKnBhdGgqLCBub3QgYSBzZXJ2aWNlICpjaGFpbiouPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUg Y29uZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGluLiAmbmJzcDtUaGUgdGVybXMgJnF1b3Q7Y2hhaW4m cXVvdDsgYW5kICZxdW90O3BhdGgmcXVvdDsgc2VlbSBpbmNvbnNpc3RlbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJv dHRvbTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRl PSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPkZy b206IDwvYj48YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lz Y28uY29tIj5qZ3VpY2hhckBjaXNjby5jb20mbHQ7amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8 YnI+DQo8Yj5UbzogPC9iPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2Vi aWFuY0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxQGF0dC5jb20lM2UsbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Us am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Us c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnIj5taWtlYmlhbmNAYW9sLmNvbSZsdDttaWtlYmlh bmNAYW9sLmNvbSZndDssbW4xOTIxQGF0dC5jb20mbHQ7bW4xOTIxQGF0dC5jb20mZ3Q7LG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZn dDssam1oQGpvZWxoYWxwZXJuLmNvbSZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20mZ3Q7LHNmY0BpZXRmLm9yZyZsdDtzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6 IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0 Ij5Zb3VyIGRlZmluaXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBm b3J3YXJkaW5nIHBhdGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4g VGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNl IGNoYWluIGRhdGEgc3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4NCiByZXNvbHZlZCB0byBzcGVj aWZpYyBpbnN0YW5jZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0LWhvcHMgdG8gdGhvc2UgaW5zdGFu Y2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1 ZSBpcyBpbiBwbGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0 aGUgbmV0d29yayB5b3UgbWF5IG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUg dG8gc3BlY2lmeSB3aGljaA0KIG5leHQtaG9wcyBtYXkgYmUgdXNlZCAod2hlcmUgYSBzaW5nbGUg bmV4dC1ob3Agd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoIGZvciB0 aGF0IHNlcnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJv dG9jb2wgLyBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3Uu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZxdW90OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJp YW5jQGFvbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBK dWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNPGJyPg0KPGI+VG86IDwvYj5KaW0gR3VpY2hhcmQgJmx0 OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwv YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQu Y29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFA YXR0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVvdDsNCiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ni43NXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhl IGNvbmZ1c2lvbjo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5PGJyPg0K Jmd0OyBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmlu YXRpb24gdGhlcmVvZikuIEk8YnI+DQomZ3Q7IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxi cj4NCiZndDsgYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcms8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjxicj4NCkJ5IGRlZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICZxdW90O3NlcnZp Y2UgcGF0aCZxdW90OyB0byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFu Y2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgJnF1b3Q7c2VydmljZSBwYXRo IGlkZW50aWZpZXImcXVvdDsgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVj aWZpY2FsbHkgJnF1b3Q7W2RvZXMgbm90XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNlcyZxdW90 Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9 IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50ZXIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjYuNzVwdCI+PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20i PmpndWljaGFyQGNpc2NvLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2Nv LmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5UbzogPC9iPk5BUElFUkFM QSwgTUFSSUEgSCZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQu Y29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiZndDssSm9lbCBNLiBIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssUm9uDQogUGFya2VyJmx0OzxhIGhyZWY9 Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5Sb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6IDwvYj5GcmlkYXksIEp1bHkgMTEsIDIwMTQ8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzPGJyPg0KPGJyPg0KTWFyaWEsPGJyPg0KPGJyPg0KSSB0aGluayBvZiBpdCB0aGlz IHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50ZXIgdG88 YnI+DQphIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGlu Z3MuIFdoZW4geW91IGRlZmluZSBhPGJyPg0KY2hhaW4sIGxldDxzcGFuIGxhbmc9IlpILUNOIj7i gJk8L3NwYW4+cyBzYXkgUzEgLSZndDtTMi0mZ3Q7IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0 aW5nIHRoZSBTRlAgc3BlY2lmeTxicj4NCnRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ug d2FudCB0cmFmZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdCBTRlAuPGJyPg0KSG93ZXZlciwg eW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRw b2ludCAoSTxicj4NCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9uPHNwYW4g bGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj50IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91PGJy Pg0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50 IHRvIGEgZ2l2ZW4gU0ZDIGFuZDxicj4NCnRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8g dGhlIG5ldHdvcmsuIEF0IHRoZSBTRkYgaXQgd2lsbCBoYXZlIGE8YnI+DQpzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciB0byBTRkMgbWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4g dGhlPGJyPg0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0Y8c3BhbiBsYW5n PSJaSC1DTiI+4oCZPC9zcGFuPnMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuPGJyPg0K dGhvc2UgbmV4dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZy b20gYSBjZW50cmFsaXplZDxicj4NCmNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91Z2gg Q0xJLCBsZWFybiB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2g8YnI+DQpzb21lIHByb3RvY29sIGV4 Y2hhbmdlLCB3aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bzxi cj4NCnNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2Vz IGFyZSBjaG9zZW4gYSBwcmlvcmk8YnI+DQphbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0 YWJsZSAoYW5kIHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0byBkbzxicj4NCnNvLjxicj4N Cjxicj4NCkxldDxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyB0YWtlIGFuIGV4YW1wbGUg dG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjo8YnI+DQo8YnI+DQpJIGRlZmluZSBhbiBTRkMg KGxldDxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyByZWZlciB0byBpdCBhcyBTRkMtMSkg UzEtJmd0O1MyLSZndDtTMy4gRm9yIGFyZ3VtZW50czxicj4NCnNha2UgbGV0PHNwYW4gbGFuZz0i WkgtQ04iPuKAmTwvc3Bhbj5zIHNheSBJIHdhbnQgaXQgdG8gYmUgZnVsbHkgZHluYW1pYyBlLmcu IEkgZG9uPHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj50IHdhbnQgdG8gc3BlY2lmeTxicj4N CnNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlv biB0aGVyZW9mKS4gSTxicj4NCmFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDxzcGFu IGxhbmc9IlpILUNOIj7igJw8L3NwYW4+MTAwPHNwYW4gbGFuZz0iWkgtQ04iPuKAnTwvc3Bhbj4g dGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8YnI+DQphbmQgdGhlbiBw dXNoIHRoaXMgaW50byB0aGUgbmV0d29yayBzbyB0aGF0IHRoZSBTRkYgZGF0YSBzdHJ1Y3R1cmVz IGFyZTxicj4NCnBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBhdCBhIGdpdmVu IFNGRiwgd2hlbiB0cmFmZmljIGFycml2ZXM8YnI+DQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YTxicj4NCnN0cnVj dHVyZSBhbmQgZmluZCB0aGF0IGl0IHBvaW50cyB0byBTMS0mZ3Q7UzItJmd0O1MzIGFuZCB0aGUg aW5kZXggaW4gdGhlIFNGQzxicj4NCmVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0IGV4YWN0bHkg d2hlcmUgaXQgaXMgaW4gdGhlIGNoYWluLiBMZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFu PnMgc2F5IHdlPGJyPg0KYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBo YXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9wIHRvPGJyPg0KUzMgYW5kIHdpbGwgZG8gYSBsb29r dXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS48YnI+DQo8YnI+DQpPbiA3LzEx LzE0LCAxMToyNiBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KJmd0O0ppbSw8YnI+DQomZ3Q7PGJyPg0KJmd0O0NvdWxkIHlvdSB0ZWxsIHVzIHdo YXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAmcXVvdDtzZXJ2aWNlIHBhdGgmcXVvdDsgYW5kIGE8 YnI+DQomZ3Q7JnF1b3Q7c2VydmljZSBwYXRoIGlkZW50aWZpZXImcXVvdDs/PGJyPg0KJmd0O0lm IGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFw cmlvcmkgKHdoaWNoPGJyPg0KJmd0O2lzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykgdGhlbiBp dCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2g8YnI+DQomZ3Q7bmV4dC1ob3AgU0ZG IHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uPGJyPg0KJmd0Ozxicj4NCiZn dDtNYXJpYTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyA8YnI+DQo8YnI+DQpGcm9tOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKSBbPGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+bWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDEx LCAyMDE0IDExOjE1IEFNPGJyPg0KJmd0OyZndDsgVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgPGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+OyBKb2VsIE0uPGJyPg0KJmd0OyZndDsgSGFscGVybjsgUm9uIFBh cmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEk8c3BhbiBsYW5nPSJa SC1DTiI+4oCZPC9zcGFuPm0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbjxzcGFuIGxhbmc9IlpILUNO Ij7igJk8L3NwYW4+dCB1bmRlcnN0YW5kIHdoeSBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyPGJy Pg0KJmd0OyZndDsgcHJldmVudHMgZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9y IHdoeSBjYWxsaW5nIGl0IGEgc2VydmljZTxicj4NCiZndDsmZ3Q7IGNoYWluIGlkZW50aWZpZXIg bWFrZXMgYW55IGRpZmZlcmVuY2U/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gNy8x MS8xNCwgMTA6NTggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDtEaXR0by48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBbPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i Pm1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU08YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFSSUEg SDsgSm9lbCBNLiBIYWxwZXJuOyBSb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBQYXJrZXI7IDxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IFJlLSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEZv ciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGlu IHRoZTxicj4NCiZndDsmZ3Q7ZHJhZnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBp dHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Rpc3RyaWJ1 dGVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbW9kZWwgaXMgbm90IGFsbG93ZWQuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZXZlcmFsIHZvaWNlcyBpbiB0 aGlzIHRocmVhZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGY8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3Nob3VsZCBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHByb3ZpZGVk IGluc3RlYWQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBD aGVlcnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O0RlIDogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBh cnQgZGUgSmltIEd1aWNoYXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyhqZ3VpY2hhcik8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RW52b3k8c3BhbiBsYW5nPSJaSC1DTiI+w6k8L3Nw YW4+IDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0O8OAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJr ZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUg c3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDtwcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9w cyB0byAqYWxsKiBTRkY8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0 aCBpZGVudGlmaWVyIHBvaW50IHRvIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvb2t1cDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUg bmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90PGJyPg0KJmd0OyZndDtzdXJlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtob3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7dGhlIGFyY2hpdGVj dHVyZSBwcmV2ZW50cyB0aGF0Pzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T24gNy8xMS8xNCwgOTo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBN QVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBh dHQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDtBYnNvbHV0ZWx5Ljxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IEZyb206IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmltIEd1aWNo YXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGpndWljaGFyKTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQg OTo1NCBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzogTkFQSUVSQUxB LCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHBy b3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7dGhhdCBpZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyB5b3UgYWxsb3cg YW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0byB3aGljaCByZW1vdGUgU0ZGIGl0PGJyPg0K Jmd0OyZndDt3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDt1c2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtmb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg YSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5 b3U8YnI+DQomZ3Q7Jmd0O2JldHRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWFrZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhh cyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3JlYWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90 aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMS8x NCwgOTo0OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O0Fic29sdXRlbHkgbm90LiBTZXJ2 aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW48YnI+DQomZ3Q7Jmd0O3JlbGV2 YW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U0ZGczxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7d2hlbiB0aGV5ICZxdW90O2Fycml2ZSZxdW90Oy48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEppbTxicj4NCiZndDsmZ3Q7R3VpY2hhcmQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsoamd1aWNoYXIpPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNCA5OjI3IEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFdlbGwg SSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9vZDxi cj4NCiZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7cHJvcG9zYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Y29ycmVjdGx5IGFzIGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2lu Z2xlPGJyPg0KJmd0OyZndDtTRjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dp dGhpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBlbnRpcmUgU0ZDIGRvbWFp biBhdCBldmVyeSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0bzxicj4NCiZndDsmZ3Q7 a25vdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O3ByaW9yaTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB3aGljaCBTRkM8c3BhbiBsYW5nPSJaSC1DTiI+wrk8L3NwYW4+cyBhIGdpdmVu IFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW48YnI+DQomZ3Q7Jmd0O3BvaW50 PGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O3RpbWUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIDcvMTAvMTQsIDEx OjUzIFBNLCAmcXVvdDtKb2VsIE0uIEhhbHBlcm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 O1JvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2Js ZW08YnI+DQomZ3Q7Jmd0O3dpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3lvdXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O3Byb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBp dC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7dW5kZXJzdGFuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7aXQuKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDtUaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2Vy IGZvciB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25leHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O3NlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dz IGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVyczxicj4NCiZndDsmZ3Q7dG8pLDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7aW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtldmVyeTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBj aGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2 aWNlcywgdGhhdCBtZWFuczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtTRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGws IGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bCBsb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7YmFsYW5jZXIuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtJIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5z aXRpdmUsIGFuZCAvIG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzdGF0ZWZ1bC48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0J1dCBoYXZpbmcgdGhlIGFy Y2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGEgZnVsbCw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2Zsb3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0O3NlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8g YmUgYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FjY2VwdGFibGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O2ltcG9zaXRpb24uPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1lvdXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Sm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDtPbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdy b3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRo aXM8YnI+DQomZ3Q7Jmd0O3dvcms8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDtzZW5zaWJseTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVj dCB0aGF0IHRoZTxicj4NCiZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJv YmFibHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZp Y2UgY2hhaW5zPGJyPg0KJmd0OyZndDt0byBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlbiBieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRv IGNsaWVudHMsIGFuZCBlbmFibGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtz ZWxmLXNlbGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZp bHkgcG9saWN5PGJyPg0KJmd0OyZndDsgJmd0OyZndDtkcml2ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFs bCBvZiB0aGF0IHdvcmsgaW4gYW4gYXJjaHRpZWN0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtk cml2ZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtieTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbml0aWFsIGNsYXNzaWZp Y2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdCBpczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7aGFyZGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtzZWU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaG93IHRvIG1ha2UgaXQgd29y ayAoYnV0IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93IG1vcmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZHluYW1pY2l0eTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29yayBiZWhh dmlvci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg SGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlz PGJyPg0KJmd0OyZndDsgJmd0OyZndDtvdXRzaWRlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg c2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDt0YXNrZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDthZ3JlZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0O29uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3 ZSBoYXZlIHRvIGRvIGl0IGE8YnI+DQomZ3Q7Jmd0O2NlcnRhaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDt3YXkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7aXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5j ZXMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFlv dXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBGb3IgbWUsIHRoZSBh bW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7bmVlZHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVk LCBwb3RlbnRpYWxseSBldmVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDthY3Jvc3M8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtkYXRhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRt aW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNvbXBsZXg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBlbm91Z2ggdGhhdCB0 cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcyBsaWtlIGE8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtkaWZmaWN1bHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRo YW48YnI+DQomZ3Q7Jmd0O2R5bmFtaWM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgcm91dGluZyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIERO UywgYWxsIG9mPGJyPg0KJmd0OyZndDt3aGljaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YmlnZ2VyPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm9ibGVt cyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSXQg YWxzbyBzZWVtcyB0aGF0IGlmIGl0IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNhdGVkLCB0aGF0PGJy Pg0KJmd0OyZndDtpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O2dvb2Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogSm9lbCBNLiBI YWxwZXJuIFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUbzog Um9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tIj4NCm1pa2ViaWFuY0Bhb2wuY29tPC9hPjs8YnI+DQomZ3Q7Jmd0O0lhbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NtaXRoOzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQ8YnI+DQomZ3Q7Jmd0O0JhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoaXMgaXMg YW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQ8YnI+DQomZ3Q7Jmd0 O3ByZWZlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YWN0dWFsbHk8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGRlY2lkZSwgcmF0aGVy IHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 aW1wbGVtZW50YXRpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24g dGhlIGNvbnRyb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlcXVpcmVtZW50czxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGb3IgbWUsIHRo ZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbmVl ZHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGJlIHdp ZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbjxicj4NCiZn dDsmZ3Q7IGFjcm9zczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGNl bnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2g8YnI+ DQomZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2NvbXBsZXg8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2Ug YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RpZmZpY3VsdDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYXJjaGl0ZWN0 dXJlIHRvIHJlYWxpemUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlv bi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaXMg dGhlIGNydXggb2YgbXkgaXNzdWUuIElzIHRoZSBlbmQgdG8gZW5kPGJyPg0KJmd0OyZndDtzZWxl Y3Rpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgKHRvcC1sZXZlbCkgaW5zdGFuY2Vz IHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Y2xhc3NpZmllcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBvciBob3AtYnktaG9wIChw ZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHk8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O1NG RnMpPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmlj YXRpb24uPGJyPg0KJmd0OyZndDtBbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDtzdXJlbHksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVs ZWdhdGVkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7aW1wbGVtZW50YXRpb24mcXVvdDsuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBNeSBv d24gdmlldyBpcyB0byBmYXZvciB0aGUgZGlzdHJpYnV0ZWQgYXBwcm9hY2ggZXZlbjxicj4NCiZn dDsmZ3Q7IHRob3VnaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBncmVhdGVyIGFtb3Vu dCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVyaGFwczxicj4NCiZndDsmZ3Q7bG9j YWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtzZWxlY3Rpb248 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBv aW50cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCBkb2VzIG5vdCBy ZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDtNeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHJhdGlvbmFsZSBmb3IgZmF2b3JpbmcgdGhpcyBhcHByb2FjaCBpcyBwcmltYXJp bHkgZHJpdmVuPGJyPg0KJmd0OyZndDtieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2luY3JlYXNlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBh dGggaWQgYXBwcm9hY2guIFdpdGggYTxicj4NCiZndDsmZ3Q7Z2xvYmFsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7cGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2lkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5z dGFuY2UgYW5kIG5lZWRpbmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FsdGVyPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZ2xvYmFsIHBhdGggSUQgdGFibGUg Zm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkPGJyPg0KJmd0OyZndDtlbmQtdG8tZW5kPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7cGF0aC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFJvbjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9 Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVy bi5jb208L2E+XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCw8YnI+DQomZ3Q7Jmd0OzIwMTQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyA2OjE1PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IFBNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJp YW5jQGFvbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPg0KSS5TbWl0 aEBGNS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBSZTo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGlu Zzxicj4NCiZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDtpbmZsdWVuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFz c2lmaWNhdGlvbiBhdCB0aGU8YnI+DQomZ3Q7Jmd0O2V4aXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2Zyb208YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBTRjEuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhl IGRpZmZlcmVudCBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvZ2ljYWxseTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdyB0aGV5 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgY2hvb3NlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBjb21wb3NlIHRoZW0gZm9yICZxdW90O3NlcnZpY2UmcXVvdDsgZGVs aXZlcnkuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNjoxMCBQ TSwgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwv YT4gd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0 IHRoYXQgc3VnZ2VzdHMgYW55PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzb3J0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGltaXQuIEhvd2V2ZXIsIGl0IGRv ZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3BhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsoYWxsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNG SXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0aW9uLiBJIGJlbGlldmU8YnI+DQom Z3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDttZWFuczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXI8YnI+ DQomZ3Q7Jmd0O2Nob29zZXMgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgdGhlIE5G IG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsPGJyPg0KJmd0OyZn dDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEg bW9yZSBkeW5hbWljIFNGUCB3aGVyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNGSShuKTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXRlcm1pbmVkIGF0 IHRoZSBTRkkobi0xKSBob3AuIEFjY29yZGluZyB0byB0aGUgZHJhZnQsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgJnF1b3Q7 YnJhbmNoaW5nJnF1b3Q7IHRvIGEgbmV3IFNGUCBhczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBvcHBvc2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNl bGVjdGVkIGluc3RhbmNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV4 dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZDLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1tZXJnZWQt c2ZjLWFyY2hpdGVjdHVyZS0wMDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gYW4gU0ZDIGlzIGluc3RhbnRp YXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtuZWNlc3Nh cnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vs ZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7YW5kIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjcmVhdGUgdGhlIHNlcnZpY2Ug dG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25l dHdvcms8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxvY2F0b3IuIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNG QyByZXN1bHRzIGluIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2NyZWF0 aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMg dXNlZCBmb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2ZvcndhcmRpbmc8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBh Y2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlv biAob3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O25vbi1pbml0aWFsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFz c2lmaWNhdGlvbikgYXMgd2VsbC4gQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQgYnkg YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgY2xhc3NpZmljYXRpb24gZnVuY3Rpb24gY28tcmVzaWRlbnQgd2l0aCBh IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Z1bmN0aW9uLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVj bGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O1NGUCwgYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVwZGF0ZSBvZiB0aGUgYXNzb2Np YXRlZCBtZXRhZGF0YSwgb3IgYm90aC4gVGhpcyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVm ZXJyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YXMgJnF1b3Q7YnJhbmNoaW5nJnF1b3Q7Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKkZyb206IDxhIGhyZWY9Im1haWx0 bzoqSS5TbWl0aEBGNS5jb20iPipJLlNtaXRoQEY1LmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRv OkkuU21pdGhARjUuY29tIj5JLlNtaXRoQEY1LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzogKkpv ZWwgSGFscGVybjxicj4NCiZndDsmZ3Q7IERpcmVjdCZsdDs8YSBocmVmPSJtYWlsdG86am1oLmRp cmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPiZndDss Sm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE0uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0O0hhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmpt aEBqb2VsaGFscGVybi5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxl dG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpodWFu Z0BzY2UuJTBiIj5odWFuZ0BzY2UuPGJyPg0KPC9hPiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBjYXJsZXRvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDtjYSZndDssPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKlNl bnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDogKlJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDtC YWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3Jl ZWluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2Fs ZSBkZXBsb3ltZW50cyAoYW5kPGJyPg0KJmd0OyZndDt0aGF0IGlzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7d2hhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15 IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O3ByZWNvbmNlaXZlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUg YXJjaGl0ZWN0dXJlIGJ1cmRlbmVkIHdpdGg8YnI+DQomZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBy ZWNvbmNlcHRpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50 IG9mIGFpbSwgc29tZSBkZWdyZWUgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FzcGlyYXRpb248 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzY2FsZSB0aGF0IGlzIGFwcHJvcHJp YXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmNoaXRl Y3R1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDstPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHlvdSBk b24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyB0aGF0IGFuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YXJiaXRyYXJ5PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlciBp cyAmcXVvdDt0b28gZmFyJnF1b3Q7LCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW50ZW50aW9uYWw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIGxh c3Rpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2ltcGFjdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnYXJkaW5nIHNj YWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7YWRkcmVzczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0 IGlzIGEgcHJvYmxlbSBJJ20gbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFs IHdpdGguPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbPGEgaHJlZj0ibWFpbHRvOmptaC5kaXJl Y3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT5dPGJyPg0K Jmd0OyZndDsgJmd0OyZndDtTZW50Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1 OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIYWxw ZXJuOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhIj5odWFu Z0BzY2UuY2FybGV0b24uY2E8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2Zj QGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTogW3NmY108YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1Nl cnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwg aW4gdGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVnYXJkLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0O0k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDthbTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0 aGUgc29sdXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Byb2hpYml0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlcGxv eW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9iamVjdGluZyB0bzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7SHVhbmcnczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWFkaW5nIG9mIG15IG5vdGUgYXMgc2F5 aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyByZXF1 aXJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byBwcm9oaWJpdDxi cj4NCiZndDsmZ3Q7c3VjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29k IGlkZWEgb3Igbm90IGRlcGVuZHMgdXBvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1hbnk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRv PGJyPg0KJmd0OyZndDt0aGluazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJlIHVzdWFs bHkgYSBiYWQgaWRlYS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IHRoZSBhcmNodGllY3R1cmUgc2kg Y2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2tu b3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGFu ZCBpcyBub3QgZXBsb3lhYmxlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJIGRpc2FncmVlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIHJvdXRpbmVseSBo YXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgdGVucyBvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O21pbGxpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25j dXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgY2VudGVyPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGVudmlyb25tZW50cyB0b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQg aW48YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9J b1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91PGJyPg0KJmd0OyZndDsgYXJlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgb25seTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBnb2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMg d2l0aCBlcXVhbGx5PGJyPg0KJmd0OyZndDtzbWFsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBudW1iZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgJnF1b3Q7bm8g b25lIHdpbGwgZXZlciBuZWVkIG1vcmU8YnI+DQomZ3Q7Jmd0OyB0aGFuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IDY0SyZxdW90Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNvbWZvcnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBb PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJs ZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocyw8YnI+DQomZ3Q7Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0O0xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBpZiBzb21lb25lIHRyaWVzIHRv IGRlcGxveSB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthcmNodGlldHVy ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBs aW1pdHMgb2Y8YnI+DQomZ3Q7Jmd0O3RoZWlyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXZpY2VzLiBUaGUgYXJj aGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQ8YnI+DQomZ3Q7Jmd0OyB1c2U8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBwYXRocy4gU2lu Y2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcmNoaXRl Y3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlPGJyPg0KJmd0OyZn dDtkb2VzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7cGVybWl0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzdWNoIGFidXNlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBkbyBub3Qg cmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlPGJyPg0KJmd0OyZndDsgcGVybWl0 czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc29tZXRoaW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBv ciByZXF1aXJlZCBieTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzbid0Ljxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24g Ny8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2lsbDxicj4N CiZndDsmZ3Q7bWVhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMg bGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7Jmd0O3RhYmxlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtvZiBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29yZSByb3V0ZXIuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGFuZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1l bnRzLCBmcm9tPGJyPg0KJmd0OyZndDsxPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0 aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlPGJyPg0KJmd0OyZndDt0aGF0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21w bGV4aXRpZXMgaWYgdGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hvb3NlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXZvaWQgYW55 IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBwcm92aXNpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYwLDAwMCBzZXJ2aWNlIHBh dGhzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9l bDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA0 OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBQYXVsLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNoYWlu IHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1hcmlhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSAqT24gQmVo YWxmPGJyPg0KJmd0OyZndDsgT2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpQYXVsIFF1aW5u IChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7MzowMzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUE0gKlRvOiogTHVjeSB5b25nICpD YzoqIDxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj4NCmptaEBqb2VsaGFscGVy bi5jb208L2E+Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Ow0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlr ZWJpYW5jQGFvbC5jb208L2E+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7 Jmd0OyBDaGFpbnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg THVjeSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP dmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZy4gSTxzcGFuIGxhbmc9IlpILUNOIj7CuTwvc3Bh bj5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG1ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtaW5vciBjaGFu Z2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBkZXJpdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBuZWVkZWQgZm9yd2FyZGlu ZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhl ciBpcyB1c2VkIHRvPGJyPg0KJmd0OyZndDtzaW1wbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHM8YnI+DQom Z3Q7Jmd0O211c3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYXZlcnNlLiBCeSBoYXZpbmcg YSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5k aXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uPGJyPg0KJmd0OyZn dDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBp bXBsZW1lbnRlZC4gVGhlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpZGVudGlmaWVyPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1 cCwgdGhhdCBsb29rdXAgY2FuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgcmVzdWx0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJh bnNwb3J0IG5leHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhvcChzKS48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDEwLCAyMDE0LCBhdCAx MTowNCBBTSwgTHVjeSB5b25nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tJTNlIj5tYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7PC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgdXNl IG9mPGJyPg0KJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBh dGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7YWN0aW9ucy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBMdWN5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgKkZyb206KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiI+ bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbjwvYT4gQmVoYWxmPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSI+T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+ bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqU2VudDoqVGh1cnNkYXksPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDEwLCAyMDE0IDI6MDYgQU0gKlRvOjxhIGhyZWY9Im1haWx0bzoqbWlrZWJpYW5jQGFvbC5jb20i PiptaWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tJmd0OztqbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3JnPC9hPiZndDsgKlN1YmplY3Q6KlJlOiBbc2Zj XSBTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtDaGFpbnMsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxp Y2l0bHkgYSBzZXJ2aWNlIHBhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZXIu IEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG88YnI+DQomZ3Q7Jmd0O2Rlcml2ZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yd2FyZGluZyBhY3Rpb25zLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVpcmluZyBhIFNGQyBzeXN0 ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBl dmVyeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhdmFpbGFibGUgU0ZDPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3 YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlcXVpcmVkL2p1c3RpZmllZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9yIHBvc3NpYmxl IGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCBy ZWx5IG9uIHRoZSBwaWVjZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb248 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhhdCB3aWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBwcmVzZW50IGlu IGFsbCBkZXBsb3ltZW50czogdGhhdCBpcyB0aGUgb25lPGJyPg0KJmd0OyZndDsgcmVxdWlyZWQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RydWN0 dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQgaW5mb3JtYXRpb24gaXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3VzZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZmVyIGZvcndhcmRp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgYWN0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYSBzb2x1dGlv bi1vcmllbnRlZCBkaXNjdXNzaW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAqRGUgOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10qRGUiPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGU8L2E+IGxhIHBhcnQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tIj5kZSptaWtlYmlhbmNA YW9sLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7ICpFbnZv eTxzcGFuIGxhbmc9IlpILUNOIj7DqTwvc3Bhbj4gOiptZXJjcmVkaSA5PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsganVpbGxldDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMjAxNCAyMjowMyAqw4Ag OjxhIGhyZWY9Im1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFscGVybi5j b208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSZndDs7c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqT2Jq ZXQgOipSZTogW3NmY10gU2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW5zLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElzIGFueW9uZSBzdGlsbCBx dWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuPGJyPg0KJmd0OyZndDtTRjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IENoYWluPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgU0Y8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgUGF0aD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE90aGVyIHRoYW4gY2xhcmlmeWlu ZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsZWFy IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRob3NlIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmFtaWxpYXIg d2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmU8YnI+DQomZ3Q7Jmd0O2FncmVl czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXNl IHRlcm1zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpczxicj4NCiZndDsm Z3Q7d2hldGhlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNwZWNpZnkgd2hh dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlIElEPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv ZiB0aGUgU0ZDIEhlYWRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzaG91bGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7c2ltcGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlbmRz IHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlcjxicj4NCiZndDsmZ3Q7ZHJh ZnRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlj dGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbjxicj4NCiZn dDsmZ3Q7IG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIGFuZCB0aGUgY2hvaWNlIG9m IGNoYWluIG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGggdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIG5l Z290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0 aGUgZHJhZnQgd291bGQgaGF2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZSB0aGF0 IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgb25lPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlZCBhbmQgdGhlIG90aGVy IG9wdGlvbmFsKSB0byBhdm9pZCBzb21lPGJyPg0KJmd0OyZndDsgdmVuZG9yczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IG9ubHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1cHBvcnRpbmcgU0ZQ IGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Oy0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbTo8 YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhAam9lbGhhbHBlcm4uY29t PC9hPiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxw ZXJuLmNvbSUzZSI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4u Y29tJmd0OzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqVG86PGEgaHJlZj0ibWFp bHRvOipzZmNAaWV0Zi5vcmciPipzZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlIj5tYWlsdG86 c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJmd0OzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgKlNl bnQ6KlR1ZXNkYXksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgSnVseTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQ8YnI+DQomZ3Q7Jmd0O0xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJhbGFuY2Vyczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBi ZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5PGJyPg0KJmd0OyZndDthbnN3 ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJl ciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwcm9wb3NlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldDxicj4NCiZndDsm Z3Q7IHdvcmtpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIGFncmVlbWVudCBvbiB0 aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG88YnI+DQomZ3Q7Jmd0OyBpbXByb3ZlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JkaW5nIHNvIHRo YXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluPGJyPg0KJmd0OyZndDsgJmd0 OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBXRzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3Jr aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBpbnRlbmRzLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB3aGF0IGRvIHdlIGludGVu ZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15PGJyPg0KJmd0OyZndDsgJmd0OyZndDtwZXJzb25h bDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoaXMg cmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3doYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGFyZSBkZWZpbmluZyBp cyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuIFdlPGJyPg0KJmd0OyZndDthcmU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF0dGVtcHRpbmcg dG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxkIGVuY29t cGFzczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFu ZCBwb2xpY3kgZnVuY3Rpb25zLDxicj4NCiZndDsmZ3Q7dmlydHVhbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5kIG1hbnkgb3RoZXI8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhc3BlY3RzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3 aGljaCBjbGVhcmx5IG5lZWQ8YnI+DQomZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgd2l0aDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWJvdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZXJl IHdlIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmluZyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZTxicj4NCiZndDsm Z3Q7IGRvaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0aCw8YnI+ DQomZ3Q7Jmd0O2FzIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVuZGVyc3RhbmQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlbSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNz IGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xlYXN0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQg YmFsYW5jaW5nIGNhbiBhbmQ8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkgYXJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDttb3JlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHBv aW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7dGhlc2UsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXQgbm90IHRvIG1hbmRh dGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHVzZWQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGluIGFueSBzb2x1dGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJv dmlkZWQgdG8gdGhlIGVuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlci48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2Vy PGJyPg0KJmd0OyZndDtwYWNrZXRzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YW5kPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBtb2RpZmllcyB0aGVtIChvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXJrczxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVz ZXIgc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW5zdGFuY2U8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRh bnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBzZXJ2aWNlIGNoYWluaW5nLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7SXQnczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3Ig bWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBjaGFpbmluZyBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9uZS4gQnV0IGl0IGhh cyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDthcmNodGll Y3R1cmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUz cnNwZWN0aXZlIGl0IGlzIHNpbXBseSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0 Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIpIFRo ZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmU8YnI+DQomZ3Q7Jmd0 O2Nhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aGF2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg d2hhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhcHBlYXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byB0aGUgc2Vy dmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGU8YnI+DQomZ3Q7Jmd0O3BvaW50 PGJyPg0KJmd0OyZndDsgJmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29udGFj dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBmb3IgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BlY2lmaWMgc2Vydmlj ZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IGRlbGl2ZXJlZDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7YnkgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBjb2xsZWN0aW9uIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2 aXJ0dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmc8YnI+DQomZ3Q7 Jmd0O29uZSBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2V2ZXJhbCBsb2FkIGJhbGFuY2Vy cyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIHRoaXMgaXM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRh IHBsYW5lPGJyPg0KJmd0OyZndDsgJmd0OyZndDttZWNoYW5pc21zLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IEl0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2 aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNt cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9y IHNjYWxlLWluLCBzY2FsZS1vdXQsIDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0 OyZndDt2bTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hp dGVjdHVyYWwgaW1wYWN0IG9mIDxicj4NCiZndDsmZ3Q7cGVybWl0dGluZzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGFyZ2VseSB0aGF0IHdl IG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGVybWlu b2xvZ3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGxlYWQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVh ZGVycyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmsgd2UgYXJlIHByb2hpYml0aW5n IGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDMp IFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkgPGJyPg0KJmd0OyZndDtz ZWxlY3Rpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhY2tldCBwYXRocyBmb3IgdGhlIHNl cnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RyYWZmaWM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5v dCB3YW50IHRvIHJlcXVpcmU8YnI+DQomZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDthPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVh ciBhdCBvbmx5IG9uZSBwbGFjZSBpbiA8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBJdCBpcyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUgPGJy Pg0KJmd0OyZndDtjb21iaW5lZC4gSTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRlbmQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZmVyIHRvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVhciB0byBzZXJ2aWNl PGJyPg0KJmd0OyZndDsgJmd0OyZndDtjaGFpbmluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIDxicj4N CiZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyIG9uZS48YnI+ DQomZ3Q7Jmd0OyBUaHVzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJh ZmZpYyB0byBkaWZmZXJlbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Npbmd1bGFyPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVy ZW50IHBsYWNlcyA8YnI+DQomZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVh biB3aGVuIEkgdGFsayBhYm91dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBjaGFp biBhbmQgc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBzZXF1ZW5jZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgbG9naWNhbCBmdW5jdGlv bnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cGFj a2V0cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5n IHRoYXQgc29tZSBzdWJzZXQgb2YgPGJyPg0KJmd0OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gZ2V0IERQSSwgY2hhcmdpbmcs IGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5kIDxicj4NCiZndDsmZ3Q7ZmlyZXdhbGw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3Rs eSB0byB0aGUgPGJyPg0KJmd0OyZndDtjYWNoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXRob3V0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhdCBpcyBub3Qg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRpcmVjdCB0aGUgPGJyPg0KJmd0OyZndDtwYWNrZXRzLjxi cj4NCiZndDsmZ3Q7IEE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZpY2UgcGF0aCBpcywg aW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2Nh dGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2Nh dGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2x1c3Rl cmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5PGJyPg0KJmd0OyZn dDsgJmd0OyZndDttYXkgYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBieSBJ UCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXM8YnI+DQomZ3Q7Jmd0OyBwb3J0czxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBTRkYu IFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtsb2NhdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heSBiZSBrbm93biB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZTxicj4NCiZndDsmZ3Q7IGFuZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0 Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBG cm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgPGJyPg0KJmd0OyZn dDtncm91cCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG5lZWQgdG8gYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFibGUgdG8gdGFsayBh Ym91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFpbiwgd2hpY2ggZHJpdmVzIHRo ZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0bzxicj4NCiZndDsmZ3Q7IHRhbGs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0 YWtlIGluIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZXZlcmFsIG9mIHRoZSBjb21t ZW50cyBoYXZlIHNhaWQgJnF1b3Q7YnV0IHRoZSB3aG9sZTxicj4NCiZndDsmZ3Q7IHBhdGg8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBiZSBr bm93biBhdCB0aGUgZnJvbnQuJnF1b3Q7IFRoaXMgYXJjaGl0ZWN0dXJlIGRlYWxzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDt3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGlzc3VlIGlu IHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikgPGJyPg0KJmd0OyZndDtvbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmFsYW5j ZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCA8YnI+DQomZ3Q7Jmd0O2JlaGF2 aW9yczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdoaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluPGJy Pg0KJmd0OyZndDsgJmd0OyZndDttdWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgc2Ft ZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMgbGFyZ2VseTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVy PGJyPg0KJmd0OyZndDsgcHJvdmlzaW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2UgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG5lY2Vzc2FyeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb248YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3Np ZmljYXRpb24gPGJyPg0KJmd0OyZndDtwb2ludC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hh dCB3ZSBhcmUgYWZ0ZXIuIDxicj4NCiZndDsmZ3Q7SWYgaXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGRvZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBncm91cCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdl IGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkPGJyPg0KJmd0 OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnZleSB0aGlzLiBJZiB0aGUgd29y a2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGludGVu dCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0 IHRvIG1hdGNoIHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDtncm91cDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJ IGFtIG5vdCBzdXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0IHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB0cnkgbmV4dC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZmM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0 Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGll dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2ZjPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYu b3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3NmYyBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D453BF5FBdfweml701chmchi_-- From nobody Mon Jul 14 07:39:16 2014 Return-Path: <jmh.direct@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51A51A05C0 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 07:39:15 -0700 (PDT) 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_29=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 7phe285mCVXf for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 07:39:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3181A0537 for <sfc@ietf.org>; Mon, 14 Jul 2014 07:39:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C29DF24730C; Mon, 14 Jul 2014 07:39:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 99BEC247305; Mon, 14 Jul 2014 07:39:01 -0700 (PDT) Message-ID: <53C3EB85.2040405@joelhalpern.com> Date: Mon, 14 Jul 2014 10:39:01 -0400 From: Joel Halpern Direct <jmh.direct@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8Y2xyH8F2O6EWgoziDQNyUZql54 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 14:39:15 -0000 Can we first figure out what we mean by a service path? Once we have that, I believe we can work out what we want the architecture to require of solutions in terms of carrying information in the packet. But since folks have been reading the existing definitions and coming to different meanings, and have been noting correctly contradictions in the words we chose for the existing definition, I would really appreciated it if folks would comment on the definition of service function path that I sent to the list. Yours, Joel On 7/14/14, 9:30 AM, Lucy yong wrote: > Conquer what Maria says. > > Lucy > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *NAPIERALA, MARIA H > *Sent:* Monday, July 14, 2014 8:21 AM > *To:* Ron Parker; Xuxiaohu; mikebianc@aol.com; jguichar@cisco.com; > mohamed.boucadair@orange.com; jmh@joelhalpern.com; sfc@ietf.org > *Subject:* Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and > Load Balancers > > The meaning of the SFP ID is pretty clear, at least to me – an abstract > identity for the exact set of service function instances (i.e., SFP ID 1 > = {SF-A-1, SF-B-3, SF-C-2}). In some ways, it is a collapsed “label > stack†– there is a single tag implying some sequence of network > locations. But, this also implies, at least to me, that there is a > central point of selection for this end to end sequence (barring > reclassification, of course). I, for one, am questioning that > implication. I have been uncomfortable with that central point > methodology due to real-world complexities of dynamic scale and > timeliness of reaction to failures. > > <Maria> I agree. It should not be mandated by the SFC architecture that > something called “service function path ID†is carried in the packet, > because it is not necessary or the only way to implement service > chaining. There might solutions that would do that but it cannot and > doesn’t need to be mandated. > > Maria > > An alternative approach is to still use central selection to select the > chain of abstract service functions (i.e., SFC ID 1 = {SF-A, SF-B, > SF-C}), but allow the actual instance selection to be distributed, > realized by the classifier and the SFFs. > > Given a topology like: > > Classifier ------- SFF-1 -------------------- SFF-2 > -------------------- SFF-3-------------------SFF-4 > > | | > | | | > | | > > SFF-A-1 SFF-A-2 SSF-B-1 > SFF-B-2 SFF-C-1 SFF-C-2 SFF-A-3 > > And assuming a newly recognized flow, the sequence could go something > like this: > > 1 Classifier selects chain SFC ID 1 {SF-A, SF-B, SF-C} > > 2 Classifier selects SFF-1 as hosting at least one instance of SF-A > > 3 Classifier encapsulates packet indicating chain ID = 1, service index = 1 > > 4 Classifier progresses packet to SFF-1 > > 5 SFF-1, seeing chain ID=1, service index=1, chooses SFF-A-2 amongst its > available instances of SF-A > > 6 SFF-1 sends packet to SFF-A-1 > > 7 SFF-A-1 sends packet back to SFF-1 > > 8 SFF-1 increments service index to 2 > > 8 SFF-1 selects SFF-2 as hosting at least one instance of SF-B > > 9 SFF-1 progresses packet to SFF-2 > > 10 process repeats per above until SFF-3, as the egress border, > progresses the packet per routing table > > Thanks. > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Xuxiaohu > *Sent:* Sunday, July 13, 2014 11:30 PM > *To:* mikebianc@aol.com <mailto:mikebianc@aol.com>; jguichar@cisco.com > <mailto:jguichar@cisco.com>; mn1921@att.com <mailto:mn1921@att.com>; > mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>; > jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>; Ron Parker; > sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load > Balancers > > Agree that the current definition of the SFP in the arch draft is a bit confusing, just as what you had pointed out. > > > > In my understanding, the SFP as an instantiation of an SFC in the network should be “an ordered list of service nodes and SF IDsâ€(see http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01). Of course, how to represent the SFP in the data packet is another thing (e.g., either through a path id or through an MPLS label stack). Here the service node means the device which contains the SFF and the NF components mandatorily while containing the SF and SF proxy components optionally. The service node could be attached or embedded with multiple SF instances and those SF instances could be of the same SF type or not. In the case where there are multiple SF instances of the same SF type (e.g., SF X) are attached to a given service node, the service node could distribute the traffic which needs SF X among those SF instances of SF X type locally. Meanwhile, there may be multiple service nodes within a given SFC-enabled domain which are embedded or attached with the SF instance s of the same SF type. In this way, the SF load-balancing would be made very flexible. > > Best regards, > > Xiaohu > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of > *mikebianc@aol.com <mailto:mikebianc@aol.com> > *Sent:* Saturday, July 12, 2014 2:46 AM > *To:* jguichar@cisco.com <mailto:jguichar@cisco.com>; mn1921@att.com > <mailto:mn1921@att.com>; mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>; jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>; Ron_Parker@affirmednetworks.com > <mailto:Ron_Parker@affirmednetworks.com>; sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers > > Wouldn't that be called the "service chain identifier" then? If the > service chain is the ordered list of SFs and the service path is the > ordered list of SF instances, then I would infer that a "service path > identifier" would be an identifier for a service *path*, not a service > *chain*. > > > Again, I think this is where the confusion keeps creeping in. The terms > "chain" and "path" seem inconsistent. > > ------------------------------------------------------------------------ > > *From: *jguichar@cisco.com<jguichar@cisco.com > <mailto:jguichar@cisco.com%3cjguichar@cisco.com>> > *To: > *mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>,mohamed.boucadair@orange.com<mohamed.boucadair@orange.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com>,sfc@ietf.org<sfc@ietf.org > <mailto:mikebianc@aol.com%3cmikebianc@aol.com%3e,mn1921@att.com%3cmn1921@att.com%3e,mohamed.boucadair@orange.com%3cmohamed.boucadair@orange.com%3e,jmh@joelhalpern.com%3cjmh@joelhalpern.com%3e,Ron_Parker@affirmednetworks.com%3cRon_Parker@affirmednetworks.com%3e,sfc@ietf.org%3csfc@ietf.org>> > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Your definition of service path is correct as its the forwarding path > through which traffic will actually flow. The service path identifier > however points to the service chain data structure and that is then > resolved to specific instances based upon which next-hops to those > instances are available and whatever load distribution technique is in > play. When instantiating the service chain into the network you may or > may not update that data structure to specify which next-hops may be > used (where a single next-hop would effectively nail up the service path > for that service chain) or you may simply allow some other protocol / > mechanism to populate the data structure for you. > > *From: *"mikebianc@aol.com <mailto:mikebianc@aol.com>" > <mikebianc@aol.com <mailto:mikebianc@aol.com>> > *Date: *Friday, July 11, 2014 at 12:18 PM > *To: *Jim Guichard <jguichar@cisco.com <mailto:jguichar@cisco.com>>, > "mn1921@att.com <mailto:mn1921@att.com>" <mn1921@att.com > <mailto:mn1921@att.com>>, "mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>>, "jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>" <jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>>, "Ron_Parker@affirmednetworks.com > <mailto:Ron_Parker@affirmednetworks.com>" > <Ron_Parker@affirmednetworks.com > <mailto:Ron_Parker@affirmednetworks.com>>, "sfc@ietf.org > <mailto:sfc@ietf.org>" <sfc@ietf.org <mailto:sfc@ietf.org>> > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > I think this is the root of the confusion: > >> I don’t want to specify >> specific instances of S1, S2, and S3 (or some combination thereof). I >> assign a service path identifier “100†that basically points to S1->S2->S3 >> and then push this into the network > > By definition, I understood a "service path" to be an ordered list of > specific SF instances. In the statement above, you use a "service path > identifier" to refer to a service *chain* that specifically "[does not] > specify specific instances". > > ------------------------------------------------------------------------ > > *From: *jguichar@cisco.com > <mailto:jguichar@cisco.com><jguichar@cisco.com <mailto:jguichar@cisco.com>> > *To: *NAPIERALA, MARIA H<mn1921@att.com > <mailto:mn1921@att.com>>,mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com><mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>>,Joel M. > Halpern<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>,Ron > Parker<Ron_Parker@affirmednetworks.com > <mailto:Ron_Parker@affirmednetworks.com>>,sfc@ietf.org > <mailto:sfc@ietf.org><sfc@ietf.org <mailto:sfc@ietf.org>> > *Sent: *Friday, July 11, 2014 > *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers > > Maria, > > I think of it this way. The service path identifier is simply a pointer to > a data structure that contains SF to next-hop mappings. When you define a > chain, let’s say S1 ->S2-> S3, you *might* when creating the SFP specify > the specific next-hops that you want traffic to flow through for that SFP. > However, you do *not* have to do this from an architectural standpoint (I > will argue that you should but you don’t have to architecturally). You > could simply assign a service path identifier to point to a given SFC and > then push that information into the network. At the SFF it will have a > service path identifier to SFC mapping and said mapping would contain the > next-hops available for each of the SF’s within the SFC - how you learn > those next-hops is up to you. You could push them down from a centralized > controller, configure them through CLI, learn them dynamically through > some protocol exchange, whatever .. So, given this it is not correct to > say that the service path means that all SF instances are chosen a priori > although it is perfectly acceptable (and some would say recommended) to do > so. > > Let’s take an example to hopefully make this clear: > > I define an SFC (let’s refer to it as SFC-1) S1->S2->S3. For arguments > sake let’s say I want it to be fully dynamic e.g. I don’t want to specify > specific instances of S1, S2, and S3 (or some combination thereof). I > assign a service path identifier “100†that basically points to S1->S2->S3 > and then push this into the network so that the SFF data structures are > populated with this information. Now at a given SFF, when traffic arrives > with service path identifier 100, the SFF will look this up in the data > structure and find that it points to S1->S2->S3 and the index in the SFC > encapsulation will tell it exactly where it is in the chain. Let’s say we > are at S2 in the chain. The SFF will now have to resolve the next-hop to > S3 and will do a lookup to determine where S3 is reachable. > > On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com > <mailto:mn1921@att.com>> wrote: > > >Jim, > > > >Could you tell us what is the definition of a "service path" and a > >"service path identifier"? > >If a service path means that all SF instances are chosen apriori (which > >is my current understanding) then it is not SFF's local decision which > >next-hop SFF to pick. It is a centralized decision. > > > >Maria > > > > > >> -----Original Message----- > >> > > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > >> Sent: Friday, July 11, 2014 11:15 AM > >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>; Joel M. > >> Halpern; Ron Parker; sfc@ietf.org <mailto:sfc@ietf.org> > >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> > >> I’m sorry but I really don’t understand why a service path identifier > >> prevents full distribution of SF next-hops or why calling it a service > >> chain identifier makes any difference? > >> > >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com > <mailto:mn1921@att.com>> wrote: > >> > >> >Ditto. > >> > > >> >> -----Original Message----- > >> >> From: mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com> > >> >> [mailto:mohamed.boucadair@orange.com] > >> >> Sent: Friday, July 11, 2014 10:31 AM > >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron > >> >> Parker; sfc@ietf.org <mailto:sfc@ietf.org> > >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > >> >> > >> >> Re-, > >> >> > >> >> For what I can say at best this is not described clearly in the > >>draft. > >> >> > >> >> Mandating a service path identifier is in itself a hint that the full > >> >>distributed > >> >> model is not allowed. > >> >> > >> >> Several voices in this thread indicated that the service chain itself > >> >>should be > >> >> provided instead. > >> >> > >> >> Cheers, > >> >> Med > >> >> > >> >> >-----Message d'origine----- > >> >> >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard > >> >> >(jguichar) > >> >> >Envoyé : vendredi 11 juillet 2014 16:18 > >> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; > sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers > >> >> > > >> >> >Ok but where in the architecture specifically is this functionality > >> >> >prohibited? If you want to distribute *all* next-hops to *all* SFF’s > >> >> >within the SFC domain and then let the path identifier point to a > >> >>lookup > >> >> >into those next-hops to reach the next SF in the chain, I am not > >>sure > >> >>how > >> >> >the architecture prevents that? > >> >> > > >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com > <mailto:mn1921@att.com>> > >> wrote: > >> >> > > >> >> >>Absolutely. > >> >> >> > >> >> >>> -----Original Message----- > >> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard > >> >> >>>(jguichar) > >> >> >>> Sent: Friday, July 11, 2014 9:54 AM > >> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; > sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> >> >>> > >> >> >>> Then I misunderstand the proposal ;-) .. However, it seems to me > >> >>that if > >> >> >>> you allow an SFF to make a decision as to which remote SFF it > >>will > >> >>use > >> >> >>>for > >> >> >>> a given flow to reach the next SF within the chain then you > >>better > >> >>make > >> >> >>> sure that that remote SFF has the necessary forwarding logic to > >> >>reach > >> >> >>>the > >> >> >>> next-next-SF for the chain as otherwise you are in deep trouble. > >> >> >>> > >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <mn1921@att.com > <mailto:mn1921@att.com>> > >> >> wrote: > >> >> >>> > >> >> >>> >Absolutely not. Service chains can be instantiated only in > >>relevant > >> >> >>>SFFs > >> >> >>> >when they "arrive". > >> >> >>> > > >> >> >>> >> -----Original Message----- > >> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim > >>Guichard > >> >> >>> >>(jguichar) > >> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM > >> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org > <mailto:sfc@ietf.org> > >> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers > >> >> >>> >> > >> >> >>> >> Well I think it is even worse than that if I have understood > >>the > >> >> >>> >>proposal > >> >> >>> >> correctly as it would require full knowledge of every single > >>SF > >> >> >>>within > >> >> >>> >>the > >> >> >>> >> entire SFC domain at every single SFF as there is no way to > >>know > >> >>a > >> >> >>> >>priori > >> >> >>> >> which SFC¹s a given SFF will need to service at any given > >>point > >> >>in > >> >> >>>time. > >> >> >>> >> > >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> > >> >> wrote: > >> >> >>> >> > >> >> >>> >> >Ron, thinking about this, I realized another major problem > >>with > >> >>the > >> >> >>> >>your > >> >> >>> >> >proposal as I understand it. (And I readily admit I may not > >> >> >>>understand > >> >> >>> >> >it.) > >> >> >>> >> > > >> >> >>> >> >The proposal has each SFF serve as the load balancer for the > >> >>next > >> >> >>> >> >service function that follows it (not the one it delivers > >>to), > >> >>in > >> >> >>>every > >> >> >>> >> >service chain that goes through it. > >> >> >>> >> > > >> >> >>> >> >Since it has to be able to work with all services, that means > >> >>that > >> >> >>> >>every > >> >> >>> >> >SFF would have to be a full, flow sensitive and stateful load > >> >> >>>balancer. > >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and / or > >> >>stateful. > >> >> >>> >> >But having the architecture require that every SFF be a full, > >> >>flow > >> >> >>> >> >sensitive, stateful, load balancer seems to me to be an > >> >>acceptable > >> >> >>> >> >imposition. > >> >> >>> >> > > >> >> >>> >> >Yours, > >> >> >>> >> >Joel > >> >> >>> >> > > >> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: > >> >> >>> >> >> Part of my personal view is that I am trying to make this > >>work > >> >> >>> >>sensibly > >> >> >>> >> >> in a more orchestrated environment. I expect that the > >>service > >> >> >>> >> >> functions, and over time probably the SFF capabilities, > >>will > >> >>be > >> >> >>> >> >> orchestrated and installed. I expect the service chains > >>to be > >> >> >>> >>driven by > >> >> >>> >> >> BSS tools that define offerings to clients, and enable > >> >> >>>self-selection > >> >> >>> >> >> from these. I expect service paths to be heavily policy > >> >>drive. > >> >> >>> >> >> > >> >> >>> >> >> I can see how to make all of that work in an archtiecture > >> >>driven > >> >> >>>by > >> >> >>> >> >> initial classification to described service paths. It is > >> >>harder > >> >> >>>to > >> >> >>> >>see > >> >> >>> >> >> how to make it work (but it can be done) when we allow more > >> >> >>> >> dynamicity > >> >> >>> >> >> in the network behavior. > >> >> >>> >> >> > >> >> >>> >> >> Having said that, most of that perspective I described is > >> >>outside > >> >> >>>of > >> >> >>> >>the > >> >> >>> >> >> scope of the working group. it is not something we are > >> >>tasked to > >> >> >>> >>agree > >> >> >>> >> >>on. > >> >> >>> >> >> So I do not claim that vision means we have to do it a > >>certain > >> >> >>>way. > >> >> >>> >>it > >> >> >>> >> >> is just the perspective that drives my preferences. > >> >> >>> >> >> > >> >> >>> >> >> Yours, > >> >> >>> >> >> Joel > >> >> >>> >> >> > >> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: > >> >> >>> >> >>>> For me, the amount of information about service instances > >> >> that > >> >> >>> >>needs > >> >> >>> >> >>>>to > >> >> >>> >> >>>> be widely distributed and maintained, potentially even > >> >>across > >> >> >>>data > >> >> >>> >> >>>> centers within an administrative scope, is large enough > >>and > >> >> >>> complex > >> >> >>> >> >>>> enough that trying to get that into each SFF seems like a > >> >> >>>difficult > >> >> >>> >> >>>> architecture to realize. > >> >> >>> >> >>> > >> >> >>> >> >>> I'm curious as to why that is more complicated than > >>dynamic > >> >> >>> routing, > >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of > >>which > >> >>are > >> >> >>> >>bigger > >> >> >>> >> >>> problems that have been profitably and stably implemented? > >> >> >>> >> >>> > >> >> >>> >> >>> It also seems that if it really is more complicated, that > >>is > >> >>a > >> >> >>>good > >> >> >>> >> >>> sign that it is too complicated. > >> >> >>> >> >>> > >> >> >>> >> >>> ________________________________________ > >> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>] > >> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM > >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com > <mailto:mikebianc@aol.com>; > >>Ian > >> >> >>>Smith; > >> >> >>> >> >>> sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load > >>Balancers > >> >> >>> >> >>> > >> >> >>> >> >>> This is an architectural issue. And one that I would > >>prefer > >> >>we > >> >> >>> >> >>>actually > >> >> >>> >> >>> decide, rather than trying to allow all possible > >> >>implementations. > >> >> >>> >> >>> Because it does have a major effect on the control > >> >>requirements > >> >> >>>and > >> >> >>> >> the > >> >> >>> >> >>> functionality of SFFs. > >> >> >>> >> >>> > >> >> >>> >> >>> For me, the amount of information about service instances > >> >>that > >> >> >>> needs > >> >> >>> >> to > >> >> >>> >> >>> be widely distributed and maintained, potentially even > >> across > >> >> >>>data > >> >> >>> >> >>> centers within an administrative scope, is large enough > >>and > >> >> >>>complex > >> >> >>> >> >>> enough that trying to get that into each SFF seems like a > >> >> >>>difficult > >> >> >>> >> >>> architecture to realize. > >> >> >>> >> >>> > >> >> >>> >> >>> Yours, > >> >> >>> >> >>> Joel > >> >> >>> >> >>> > >> >> >>> >> >>> But it is a fair question. > >> >> >>> >> >>> > >> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: > >> >> >>> >> >>>> This is the crux of my issue. Is the end to end > >>selection > >> >>of > >> >> >>> >> >>>> (top-level) instances performed centrally (perhaps by the > >> >> >>> >>classifier) > >> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently > >> >>the > >> >> >>> >>SFFs)? > >> >> >>> >> >>>> Such selection is not equivalent to reclassification. > >>And > >> >> >>>surely, > >> >> >>> >> >>>> this is an architectural issue and not relegated to > >> >> >>> >> >>>> "implementation". > >> >> >>> >> >>>> > >> >> >>> >> >>>> My own view is to favor the distributed approach even > >> though > >> >> a > >> >> >>> >> >>>> greater amount of data (chain definitions and perhaps > >>local > >> >> >>> >>selection > >> >> >>> >> >>>> policy) is required at those distributed decision points. > >> >>This > >> >> >>> >> >>>> approach does not require an end-to-end path id at all. > >> >>My > >> >> >>> >> >>>> rationale for favoring this approach is primarily driven > >>by > >> >> >>> >>increased > >> >> >>> >> >>>> resiliency over the global path id approach. With a > >>global > >> >> >>>path > >> >> >>> >>id > >> >> >>> >> >>>> approach, consider failure of an instance and needing to > >> >>alter > >> >> >>>the > >> >> >>> >> >>>> global path ID table for each and every affected > >>end-to-end > >> >> >>>path. > >> >> >>> >> >>>> > >> >> >>> >> >>>> Ron > >> >> >>> >> >>>> > >> >> >>> >> >>>> ________________________________________ From: sfc > >> >> >>> >> >>>> [sfc-bounces@ietf.org <mailto:sfc-bounces@ietf.org>] > on behalf of Joel Halpern Direct > >> >> >>> >> >>>> [jmh.direct@joelhalpern.com > <mailto:jmh.direct@joelhalpern.com>] Sent: Thursday, July 10, > >>2014 > >> >> 6:15 > >> >> >>> PM > >> >> >>> >> >>>> To: mikebianc@aol.com <mailto:mikebianc@aol.com>; > I.Smith@F5.com <mailto:I.Smith@F5.com>; sfc@ietf.org <mailto:sfc@ietf.org> > >> Subject: > >> >> Re: > >> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers > >> >> >>> >> >>>> > >> >> >>> >> >>>> The way the architecture models the case of SF1 needing > >>to > >> >> >>> >>influence > >> >> >>> >> >>>> the chain is that one would do reclassification at the > >>exit > >> >>from > >> >> >>> >> >>>> SF1. > >> >> >>> >> >>>> > >> >> >>> >> >>>> Part of the goal is to keep the different functions > >> >>logically > >> >> >>> >> >>>> separate so that solutions can clearly describe how they > >> >> choose > >> >> >>>to > >> >> >>> >> >>>> compose them for "service" delivery. > >> >> >>> >> >>>> > >> >> >>> >> >>>> Yours, Joel > >> >> >>> >> >>>> > >> >> >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com > <mailto:mikebianc@aol.com> wrote: > >> >> >>> >> >>>>> I don't see anything in the arch draft that suggests any > >> >>sort > >> >> >>>of > >> >> >>> >> >>>>> limit. However, it does seem to indicate that the entire > >> >>path > >> >> >>>(all > >> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe > >>this > >> >> >>>means > >> >> >>> >> >>>>> either at the classifier or maybe the classifier > >>chooses a > >> >>SF > >> >> >>> >>Chain > >> >> >>> >> >>>>> and the NF or at the latest the first SFF. In any case, > >> >>the > >> >> >>> >> >>>>> language does seem to prohibit a more dynamic SFP where > >> >> SFI(n) > >> >> >>> is > >> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to the draft, > >> >>this > >> >> >>> >> >>>>> behavior would be considered "branching" to a new SFP as > >> >> >>> opposed > >> >> >>> >> to > >> >> >>> >> >>>>> choosing and then forwarding to the selected instance of > >> >>the > >> >> >>> >> >>>>> next-hop of the current SFC. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> draft-merged-sfc-architecture-00: > >> >> >>> >> >>>>>> When an SFC is instantiated into the network it is > >> >>necessary > >> >> >>>to > >> >> >>> >> >>>>>> select the specific instances of SFs that will be used, > >> >>and to > >> >> >>> >> >>>>>> create the service topology for that SFC using SF's > >> >>network > >> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC results in the > >> >> >>>creation > >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for > >> >>forwarding > >> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP is the > >> >> >>> >> >>>>>> instantiation of the defined SFC. > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> The SFC architecture supports reclassification (or > >> >>non-initial > >> >> >>> >> >>>>>> classification) as well. As packets traverse an SFP, > >> >> >>> >> >>>>>> reclassification may occur - typically performed by a > >> >> >>> >> >>>>>> classification function co-resident with a service > >> >>function. > >> >> >>> >> >>>>>> Reclassification may result in the selection of a new > >> >>SFP, an > >> >> >>> >> >>>>>> update of the associated metadata, or both. This is > >> >>referred > >> >> >>>to > >> >> >>> >> >>>>>> as "branching". > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> > >> >> >>> > >> >> > >> > >>>>>>>>>>>>>>------------------------------------------------------------- > >>>>>>>>>>>>>>-- > >> >>>>>>>>>>>>--- > >> >> >>>>>>>>>>-- > >> >> >>> >>>>>>>-- > >> >> >>> >> >>>>>-- > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>> *From: *I.Smith@F5.com > <mailto:*I.Smith@F5.com><I.Smith@F5.com <mailto:I.Smith@F5.com>> > >> >> >>> >> >>>>> *To: *Joel Halpern > >> Direct<jmh.direct@joelhalpern.com > <mailto:jmh.direct@joelhalpern.com>>,Joel > >> >> M. > >> >> >>> >> >>>>> > >> >> >>> >> > >> >> >>> > >> >> > >> >>>>>Halpern<jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>>,huang@sce.carleton.ca > <mailto:huang@sce.carleton.ca><huang@sce. > <mailto:huang@sce.%0b>>> >> >>> >> carleton. > >> >> >>> >> >>>>>ca>,sfc@ietf.org <mailto:sfc@ietf.org><sfc@ietf.org > <mailto:sfc@ietf.org>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 > >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load > >> >>Balancers > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> Actually, I think I am disagreeing. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> If the possibility of medium-scale deployments (and > >>that is > >> >> >>>what > >> >> >>> >> >>>>> 16 million flows is in my world) of service chains is > >> >> >>>preconceived > >> >> >>> >> >>>>> as an absurd idea, then the architecture burdened with > >> that > >> >> >>> >> >>>>> preconception. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> There has to be some point of aim, some degree of > >> >>aspiration > >> >> to > >> >> >>> >> >>>>> scale that is appropriate for the lifespan of the > >> >>architecture > >> >> >>>- > >> >> >>> >> >>>>> you don't have to know what it is, but by saying that an > >> >> >>>arbitrary > >> >> >>> >> >>>>> number is "too far", you're creating - even if it isn't > >> >> >>> >>intentional > >> >> >>> >> >>>>> - a limit that influences decisions that have lasting > >> >>impacts > >> >> >>> >> >>>>> regarding scale-out, failure mitigation, elasticity, > >> >>address > >> >> >>> >> >>>>> space... all kinds of things. That is a problem I'm not > >> >> >>> >> >>>>> particularly eager to deal with. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> ________________________________________ > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> From: Joel Halpern Direct > [jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>] > >> >>Sent: > >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. > >> >> Halpern; > >> >> >>> >> >>>>> huang@sce.carleton.ca > <mailto:huang@sce.carleton.ca>; sfc@ietf.org <mailto:sfc@ietf.org> > Subject: Re: [sfc] > >> >>Service > >> >> >>> >> >>>>> Chains, Paths, and Load Balancers > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all in this > >> >>regard. > >> >> >>>I > >> >> >>> >>am > >> >> >>> >> >>>>> not requesting the the architecture or the solution > >> >>prohibit > >> >> >>> >> >>>>> deployments in the specific fashion. I am objecting to > >> >>Huang's > >> >> >>> >> >>>>> reading of my note as saying that such deployments are > >> >> required > >> >> >>> >> >>>>> they by the archtiecture. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to prohibit > >>such > >> >> >>> >> >>>>> things. Whether they are a good idea or not depends upon > >> >> many > >> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to > >>think > >> >>that > >> >> >>> >>they > >> >> >>> >> >>>>> are usually a bad idea. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> But the archtiecture si carefully avoiding attempting to > >> >>know > >> >> >>>what > >> >> >>> >> >>>>> is and is not eployable. > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> Yours, Joel > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: > >> >> >>> >> >>>>>> I disagree. > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> We routinely have stateful devices that manage tens of > >> >> >>>millions > >> >> >>> >> >>>>>> of > >> >> >>> >> >>>>> concurrent flows in both access network and data center > >> >> >>> >> >>>>> environments today. You can't seriously believe that in > >>the > >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you > >> are > >> >> only > >> >> >>> >> going > >> >> >>> >> >>>>> to have small numbers of service chains with equally > >>small > >> >> >>> numbers > >> >> >>> >> >>>>> of active service paths? > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> Your sounds too much like "no one will ever need more > >> than > >> >> >>> 64K" > >> >> >>> >> >>>>>> for > >> >> >>> >> >>>>> comfort. > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> ________________________________________ From: sfc > >> >> >>> >> >>>>>> [sfc-bounces@ietf.org > <mailto:sfc-bounces@ietf.org>] on behalf of Joel M. Halpern > >> >> >>> >> >>>>> [jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>] > >> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: > >> >> >>>huang@sce.carleton.ca <mailto:huang@sce.carleton.ca>; > >> >> >>> >> >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> Subject: Re: > [sfc] Service Chains, Paths, > >>and > >> >> >>>Load > >> >> >>> >> >>>>>> Balancers > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> No, it will mean that if someone tries to deploy the > >> >> >>>archtieture > >> >> >>> >> >>>>>> particularly badly, they will exceed the limits of > >>their > >> >> >>> >> >>>>>> devices. The architecture does not require such absurd > >> use > >> >> of > >> >> >>> >> >>>>>> service paths. Since I can not figure out how to write > >> >> >>> >> >>>>>> architectural words to prohibit it, the architecture > >>does > >> >> >>>permit > >> >> >>> >> >>>>>> such abuse. > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> Please do not read my saying that the archtiecture > >> permits > >> >> >>> >> >>>>>> something as saying it is either deisred or required by > >> >>the > >> >> >>>work. > >> >> >>> >> >>>>>> It isn't. > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> Yours, Joel > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: > >> >> >>> >> >>>>>>> If you need to support 100 service chains, it will > >>mean > >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing > >>table > >> >>of a > >> >> >>> >> >>>>>>> core router. > >> >> >>> >> >>>>>>> > >> >> >>> >> >>>>>>> Chang > >> >> >>> >> >>>>>>> > >> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: > >> >> >>> >> >>>>>>>> The architecture allows a range of deployments, from > >>1 > >> >> >>> >> >>>>>>>> service path to 160000 service paths. I would hope > >>that > >> >> >>> >> >>>>>>>> operators are prepared for the complexities if they > >> >>choose > >> >> >>>to > >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in stead > >> >> provision > >> >> >>> >> >>>>>>>> 160,000 service paths. > >> >> >>> >> >>>>>>>> > >> >> >>> >> >>>>>>>> Yours, Joel > >> >> >>> >> >>>>>>>> > >> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: > >> >> >>> >> >>>>>>>>> Paul, > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop > >> >> service > >> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Maria > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf > >> Of > >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 > >> >>3:03 > >> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com>; > >> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com > <mailto:mohamed.boucadair@orange.com>; sfc@ietf.org <mailto:sfc@ietf.org>; > >> >> >>> >> >>>>>>>>> mikebianc@aol.com <mailto:mikebianc@aol.com> > *Subject:* Re: [sfc] Service > >> Chains, > >> >> >>> >> >>>>>>>>> Paths, and Load Balancers > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Lucy, > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the > >> >> >>> >> >>>>>>>>> forwarding. I¹d > >> >> >>> >> >>>>> make > >> >> >>> >> >>>>>>>>> the minor change: the path identifier can be used to > >> >> derive > >> >> >>> >> >>>>>>>>> the needed forwarding and associated transport. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to > >>simply > >> >> >>> >> >>>>>>>>> identify the service path (or graph) that packets > >>must > >> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exact > >> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on > >>this > >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path > >> >> identifier > >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can > >> >> result > >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) transport next > >> >> >>> >> >>>>>>>>> hop(s). > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Paul > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong > >> >> >>> >> >>>>>>>>> <lucy.yong@huawei.com <mailto:lucy.yong@huawei.com> > >> >> <mailto:lucy.yong@huawei.com> <mailto:lucy.yong@huawei.com%3e>> > >> >> >>> >> >>>>>>>>> wrote: > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of > >> the > >> >> >>> >> >>>>>>>>> service path identifier to drive the forwarding > >> >>actions. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Lucy > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf > >> >> >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com > <mailto:Of*mohamed.boucadair@orange.com> > >> >> >>> >> >>>>>>>>> <mailto:mohamed.boucadair@orange.com> > >> >> >>> *Sent:*Thursday, > >> >> >>> >> July > >> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com > <mailto:*mikebianc@aol.com> > >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com > <mailto:mikebianc@aol.com%3e;jmh@joelhalpern.com> > >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org > <mailto:jmh@joelhalpern.com%3e;sfc@ietf.org> > >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Subject:*Re: [sfc] Service > >> >>Chains, > >> >> >>> >> >>>>>>>>> Paths, and Load Balancers > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Re-, > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a service path > >> >> >>> >> >>>>>>>>> identifier. I object to use that identifier to > >>derive > >> >> >>> >> >>>>>>>>> forwarding actions. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of > >> >> every > >> >> >>> >> >>>>> available SFC > >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not > >> >> >>> >> >>>>> required/justified > >> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of > >> >> >>> >> >>>>>>>>> information > >> >> >>> >> >>>>> that will > >> >> >>> >> >>>>>>>>> be present in all deployments: that is the one > >> required > >> >> to > >> >> >>> >> >>>>>>>>> structure a service chain. How that information is > >> >>used to > >> >> >>> >> >>>>>>>>> infer forwarding > >> >> >>> >> >>>>> actions > >> >> >>> >> >>>>>>>>> is a solution-oriented discussion. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Cheers, > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Med > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la part > >> >> >>> >> >>>>> de*mikebianc@aol.com <mailto:de*mikebianc@aol.com> > >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com> *Envoyé :*mercredi 9 > >> >> juillet > >> >> >>> >> >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com > <mailto:*jmh@joelhalpern.com> > >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org > <mailto:jmh@joelhalpern.com%3e;sfc@ietf.org> > >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service > >> >>Chains, > >> >> >>> >> >>>>>>>>> Paths, and Load Balancers > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference between > >>SF > >> >> Chain > >> >> >>> >> >>>>>>>>> and SF > >> >> >>> >> >>>>> Path? > >> >> >>> >> >>>>>>>>> Other than clarifying the definition so that it's > >> >>clear to > >> >> >>> >> >>>>> those not > >> >> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone > >>agrees > >> >>on > >> >> >>> >> >>>>>>>>> these terms. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear is > >>whether > >> >>it is > >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify what > >> >>the ID > >> >> >>> >> >>>>>>>>> of the SFC Header > >> >> >>> >> >>>>> should > >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if this draft > >> >>simply > >> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other > >>drafts > >> >>to > >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain > >> or > >> >> >>> >> >>>>>>>>> path and the choice of chain or > >> >> >>> >> >>>>> path to > >> >> >>> >> >>>>>>>>> be negotiated in the control-plane. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have > >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported (or make > >> >> one > >> >> >>> >> >>>>>>>>> required and the other optional) to avoid some > >> vendors > >> >> only > >> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>> > >> >> >>> >> > >> >> >>> > >> >> > >> > >>>>>>>>>>>>>>------------------------------------------------------------- > >>>>>>>>>>>>>>-- > >> >>>>>>>>>>>>--- > >> >> >>>>>>>>>>-- > >> >> >>> >>>>>>>-- > >> >> >>> >> >>>>>-- > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>>>> > >> >> >>> >> >>>>>>>>> *From:*jmh@joelhalpern.com > <mailto:*jmh@joelhalpern.com><jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com> > >> >> >>> >> >>>>>>>>> > >> >> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com> > <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com%3e>> > >> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org > <mailto:*sfc@ietf.org><sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org> > <mailto:sfc@ietf.org%3csfc@ietf.org%3e>> > >> *Sent:*Tuesday, > >> >> July > >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and > >>Load > >> >> >>> >> >>>>>>>>> Balancers > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> I have been trying to figure out how to clearly > >>answer > >> >>a > >> >> >>> >> >>>>>>>>> number of comments that have been made about the > >> >> >>> proposed > >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get > >> working > >> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to > >> improve > >> >> the > >> >> >>> >> >>>>>>>>> wording so that readers who have not participated in > >> >>the > >> >> WG > >> >> >>> >> >>>>>>>>> discussion will understnd it the way the > >> >> >>> >> >>>>> working > >> >> >>> >> >>>>>>>>> group intends. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain my > >> >>personal > >> >> >>> >> >>>>>>>>> view, and see if that helps. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> In this regard, it is important to keep in mind that > >> >>what > >> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. We > >>are > >> >> not > >> >> >>> >> >>>>>>>>> attempting to define the architecture for the entire > >> >> >>> >> >>>>>>>>> solution for service chaining. That would encompass > >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy functions, > >>virtual > >> >> >>> >> >>>>>>>>> machine and image management, and many other > >> >> aspects. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> As a result there are many things which clearly need > >> to > >> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt with > >> >>above > >> >> >>> >> >>>>>>>>> where we are > >> >> >>> >> >>>>> functioning, > >> >> >>> >> >>>>>>>>> and are not directly required by the work we are > >> doing. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> In order to get to service chain vs service path, > >>as I > >> >> >>> >> >>>>>>>>> understand > >> >> >>> >> >>>>> them, > >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. There are at > >> >>least > >> >> >>> >> >>>>>>>>> three different ways that load balancing can and > >>will > >> >> >>> >> >>>>>>>>> interact with service chaining. There probably are > >> >>more. > >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all of > >> >>these, > >> >> >>> >> >>>>>>>>> but not to mandate that any particular kind > >> >> >>> >> >>>>> be used > >> >> >>> >> >>>>>>>>> in any solution. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to the end > >> >>user. > >> >> >>> >> >>>>>>>>> This is a service function. It receives user > >>packets, > >> >>and > >> >> >>> >> >>>>>>>>> modifies them (or > >> >> >>> >> >>>>> marks > >> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user service > >> >>instance > >> >> >>> >> >>>>>>>>> to receive the users packet. This is an important > >> >>service > >> >> >>> >> >>>>>>>>> function to be able to include in service chaining. > >> >>It's > >> >> >>> >> >>>>>>>>> behavior may affect requirements on how service > >> >> chaining is > >> >> >>> >> >>>>>>>>> done. But it has very little impact on the > >> >>archtiecture. > >> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is simply a > >> >> >>> >> >>>>> service > >> >> >>> >> >>>>>>>>> function which may modify the underlying packet. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one > >>can > >> >>have > >> >> >>> >> >>>>>>>>> what > >> >> >>> >> >>>>> appears > >> >> >>> >> >>>>>>>>> to the service chaining architecture as a single > >>point > >> >>of > >> >> >>> >> >>>>>>>>> contact > >> >> >>> >> >>>>> for a > >> >> >>> >> >>>>>>>>> specific service function, but is actually delivered > >> >>by a > >> >> >>> >> >>>>> collection of > >> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including > >>one or > >> >> >>> >> >>>>>>>>> several load balancers (for example using VRRP-like > >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is > >> >> >>> >> >>>>>>>>> invisible to the service chaining data plane > >> >>mechanisms. > >> >> It > >> >> >>> >> >>>>>>>>> is likely that it is visible to various control > >> >>mechanisms, > >> >> >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, > >>and > >> >>vm > >> >> >>> >> >>>>>>>>> instantiation. The architectural impact of > >>permitting > >> >>this > >> >> >>> >> >>>>>>>>> is largely that we need to be careful that our > >> >>terminology > >> >> >>> >> >>>>>>>>> does not lead > >> >> >>> >> >>>>> readers to > >> >> >>> >> >>>>>>>>> think we are prohibiting it. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by > >>selecting > >> >> >>> >> >>>>>>>>> packet paths for the service chaining that direct > >> >>traffic > >> >> >>> >> >>>>>>>>> to different places. We would not want to require > >> that > >> >>a > >> >> >>> >> >>>>>>>>> given service function appear at only one place in > >>the > >> >> >>> >> >>>>>>>>> network. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> It is of course the case that these may be > >>combined. I > >> >> tend > >> >> >>> >> >>>>>>>>> to > >> >> >>> >> >>>>> refer to > >> >> >>> >> >>>>>>>>> the collection of entities that appear to service > >> >>chaining > >> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster > >>is > >> >>a > >> >> >>> >> >>>>>>>>> good term. But because I do not have another one. > >> Thus, > >> >> the > >> >> >>> >> >>>>>>>>> point of type 3 load balancing > >> >> >>> >> >>>>> is to > >> >> >>> >> >>>>>>>>> direct different subsets of traffic to different > >> >>singular > >> >> >>> >> >>>>>>>>> or clustered service functions in different places > >>in > >> >>the > >> >> >>> >> >>>>>>>>> network. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I talk about > >> >> >>> >> >>>>>>>>> service chain and service path/ Service chain is a > >> >> sequence > >> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset of > >> >>packets. > >> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of > >>traffic > >> >>is > >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, and > >>firewall > >> >> >>> >> >>>>>>>>> while a different subset is to go directly to the > >>cache > >> >> >>> >> >>>>> without > >> >> >>> >> >>>>>>>>> visiting any other service functions. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> That is not enough information to direct the > >>packets. > >> A > >> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence of > >> >>locations > >> >> >>> >> >>>>>>>>> in the network. Those locations will be singular or > >> >> >>> >> >>>>>>>>> clustered service function delivery locations. They > >> >>may be > >> >> >>> >> >>>>>>>>> addressed by IP address. They may be addressed as > >> ports > >> >> on > >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that the > >> >>locations > >> >> >>> >> >>>>>>>>> may be known to the service chaining infrastructure > >> and > >> >> the > >> >> >>> >> >>>>>>>>> transport. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>>> From the point of view of the work of the SFC > >>group, > >> >> we > >> >> >>> >> >>>>>>>>>> need to be > >> >> >>> >> >>>>>>>>> able to talk about the high level abstraction, the > >> >>service > >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need to > >> talk > >> >> >>> >> >>>>>>>>> about the actual data path packets will take in the > >> >> >>> >> >>>>>>>>> network. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Several of the comments have said "but the whole > >> path > >> >> may > >> >> >>> >> >>>>>>>>> not be known at the front." This architecture deals > >> >>with > >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) > >>on > >> >>load > >> >> >>> >> >>>>>>>>> balancers above, there can be decisions and > >>behaviors > >> >> which > >> >> >>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in > >> >>much > >> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is largely > >> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The other > >> provision > >> >> we > >> >> >>> >> >>>>>>>>> make is > >> >> >>> >> >>>>> that > >> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain when > >> >> necessary. > >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. Based on > >> >> >>> >> >>>>>>>>> information available at the re-classification > >>point. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> I hope that this helps explain what we are after. > >>If it > >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the working > >> >> group, > >> >> >>> >> >>>>>>>>> we can figure out what additional words are needed > >> to > >> >> >>> >> >>>>>>>>> convey this. If the working group disagree with the > >> >> intent, > >> >> >>> >> >>>>>>>>> then we will of course adjust to match the working > >> >>group > >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure > >> >>what to > >> >> >>> >> >>>>>>>>> try next. > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> Yours, Joel > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> > >> _______________________________________________ > >> >> sfc > >> >> >>> >> mailing > >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> > <mailto:sfc@ietf.org> > >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>>> > >> _______________________________________________ > >> >> sfc > >> >> >>> >> mailing > >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> > <mailto:sfc@ietf.org> > >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>>>>>>> > >> >> >>> >> >>>>>>>> > >> >> >>> >> >>>>>>>> > >> _______________________________________________ > >> >> sfc > >> >> >>> >> mailing > >> >> >>> >> >>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> > >> >>https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>>>>>> > >> >> >>> >> >>>>>>> > >> >> >>> >> >>>>>>> _______________________________________________ > >> sfc > >> >> >>> >> mailing > >> >> >>> >> >>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> > >> >>https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>>>>> > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>>> _______________________________________________ > >> sfc > >> >> >>> mailing > >> >> >>> >> list > >> >> >>> >> >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>>>> > >> >> >>> >> >>>>> > >> >> >>> >> >>>>> _______________________________________________ sfc > >> >> >>> mailing > >> >> >>> >> list > >> >> >>> >> >>>>> sfc@ietf.org <mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>> > >> >> >>> >> >>>> _______________________________________________ sfc > >> >> mailing > >> >> >>> >> list > >> >> >>> >> >>>> sfc@ietf.org <mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>> > >> >> >>> >> >>>> _______________________________________________ sfc > >> >> mailing > >> >> >>> >> list > >> >> >>> >> >>>> sfc@ietf.org <mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >>>> > >> >> >>> >> >>> > >> >> >>> >> >> > >> >> >>> >> >> _______________________________________________ > >> >> >>> >> >> sfc mailing list > >> >> >>> >> >> sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> >> >> https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> >> > >> >> >>> >> > > >> >> >>> >> >_______________________________________________ > >> >> >>> >> >sfc mailing list > >> >> >>> >> >sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> >> > >> >> >>> >> _______________________________________________ > >> >> >>> >> sfc mailing list > >> >> >>> >> sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> >> https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> sfc mailing list > >> >> >>> sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> https://www.ietf.org/mailman/listinfo/sfc > >> >> > > >> >> >_______________________________________________ > >> >> >sfc mailing list > >> >> >sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org <mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 14 08:00:13 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7C1A0A8E for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 CdYnBC7SW32f for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:00:03 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50651A063A for <sfc@ietf.org>; Mon, 14 Jul 2014 08:00:03 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 4216953E0D; Mon, 14 Jul 2014 07:59:58 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 07:59:58.222 -0700 x-echoworx-msg-id: 015920e6-cc23-41f7-aac6-f3c51b847556 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 74; Mon, 14 Jul 2014 07:59:58 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 16F3553E0D; Mon, 14 Jul 2014 07:59:58 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 08:00:02 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "jguichar@cisco.com" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2fdGB3ecdgo20an/XQiFB0eg5ugGT2A//+MLWA= Date: Mon, 14 Jul 2014 15:00:01 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> In-Reply-To: <53C3EB85.2040405@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gb018S0XoyCVjDVZ-TEZFGOA2Ns Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:00:11 -0000 SGksIEpvZWwsDQoNCkkgcXVvdGUgZnJvbSB0aGUgdGhlIG1lcmdlZCBhcmNoaXRlY3R1cmUgZHJh ZnQ6DQoNCjxiZWdpbiBxdW90YXRpb24+DQpTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpOiAg QSBzZXJ2aWNlIEZ1bmN0aW9uIGNoYWluIGRlZmluZXMgYW4NCiAgICAgICAgb3JkZXJlZCBzZXQg b2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBtdXN0IGJlIGFwcGxpZWQgdG8gcGFja2V0cw0KICAg ICAgICBhbmQvb3IgZnJhbWVzIHNlbGVjdGVkIGFzIGEgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9u LiAgVGhlDQogICAgICAgIGltcGxpZWQgb3JkZXIgbWF5IG5vdCBiZSBhIGxpbmVhciBwcm9ncmVz c2lvbiBhcyB0aGUNCiAgICAgICAgYXJjaGl0ZWN0dXJlIGFsbG93cyBmb3Igbm9kZXMgdGhhdCBj b3B5IHRvIG1vcmUgdGhhbiBvbmUgYnJhbmNoLg0KICAgICAgICBUaGUgdGVybSBzZXJ2aWNlIGNo YWluIGlzIG9mdGVuIHVzZWQgYXMgc2hvcnRoYW5kIGZvciBzZXJ2aWNlDQogICAgICAgIGZ1bmN0 aW9uIGNoYWluLg0KDQogICBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCk6ICBUaGUgaW5zdGFu dGlhdGlvbiBvZiBhbiBTRkMgaW4gdGhlDQogICAgICAgIG5ldHdvcmsuICBQYWNrZXRzIGZvbGxv dyBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBmcm9tIGENCiAgICAgICAgY2xhc3NpZmllciB0aHJv dWdoIHRoZSByZXF1aXNpdGUgc2VydmljZSBmdW5jdGlvbnMNCg0KV2hlbiBhbiBTRkMgaXMgaW5z dGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVjZXNzYXJ5IHRvDQogICBzZWxlY3Qg dGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0byBj cmVhdGUNCiAgIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5l dHdvcmsgbG9jYXRvci4gIFRodXMsDQogICBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0 cyBpbiB0aGUgY3JlYXRpb24gb2YgYSBTZXJ2aWNlDQogIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5k IGlzIHVzZWQgZm9yIGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdoIHRoZQ0KICAgU0ZDLiAgSW4g b3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBT RkMuDQoNCihTZWN0aW9uIDQuMyBTRkYpDQpTRlAgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpcyBh c3NvY2lhdGVkIHdpdGggYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KICAgdGhhdCBpcyB1c2Vk IHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGFuIFNGUC4gIA0KPGVuZCBxdW90YXRpb24+DQoNCg0KTXkg cmVhZGluZyBvZiB0aGUgU2VjdGlvbiA0LjMsIGdpdmVuIHRoZSBkZWZpbml0aW9ucyBwcmVzZW50 ZWQgYmVmb3JlIGl0LCBpcyB0aGF0IGFuIGVuZC10by1lbmQgZnVsbHkgaW5zdGFudGlhdGVkIHBh dGggaXMgc2VsZWN0ZWQgYW5kIHRoZW4gdXNlZCB0byBzdGVlciB0cmFmZmljIHRvIHRoZSByZXF1 aXNpdGUgU0ZGJ3MgYW5kIFNGJ3MuICAgV2hpbGUgdGhvc2UgZGVmaW5pdGlvbnMgY291bGQgc3Rp bGwgYXBwbHksIGV2ZW4gaW4gYSBkaXN0cmlidXRlZCBpbnN0YW5jZSBhc3NpZ25tZW50IGFwcHJv YWNoLCB0aGUgY29udGV4dCBhcm91bmQgdGhvc2UgZGVmaW5pdGlvbnMgY2hhbmdlLiAgIEEgcGFy dGljdWxhciBmbG93IHdvdWxkLCBpbmRlZWQgc3RpbGwgZm9sbG93IHNvbWUgcGFydGljdWxhciBw YXRoLCBidXQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0byBhc3NvY2lhdGUgYSBwYXRoIElEIHRv IGl0IGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvIChsYXRlcikgYnVpbGQgYSBjb250cm9s IHBsYW5lIGFyb3VuZCBkaXN0cmlidXRpb24gb2YgdGhpcyBwYXRoIElEIGFuZCBtYWludGVuYW5j ZSBvZiB0aG9zZSBwYXRoIElEcyBpbiB0aGUgZmFjZSBvZiBpbmV2aXRhYmxlIGZhaWx1cmVzLg0K DQpJIGFtIGV4cGxvcmluZyB0aGUgYWx0ZXJuYXRpdmUgd2hlcmUgZm9yd2FyZGluZyBpcyBwZXJm b3JtZWQgYmFzZWQgb24gdGhlIGFic3RyYWN0IFNGQyBJRCB3aXRob3V0IHJlcXVpcmluZyB0aGUg Y29uY2VwdCBvZiBhIGNlbnRyYWxseSBrbm93biBTRlAgdG8gZXhpc3QgYXQgYWxsLiAgIEluIHRo aXMgYWx0ZXJuYXRpdmUgYXBwcm9hY2gsIHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gaXMgZGlzdHJp YnV0ZWQgdG8gdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkYncy4gICBBbnkgZGVzaXJlZCBwb2xp Y3kgdXNlZCB0byBmbGF2b3IgaW5zdGFuY2Ugc2VsZWN0aW9uIGlzIHN0aWxsIHN1cHBvcnRlZCwg YnV0IHN1Y2ggcG9saWN5IHdvdWxkLCBpbmRlZWQsIG5lZWQgdG8gYmUgYXZhaWxhYmxlIHRvIHRo ZSBpbnZvbHZlZCBlbnRpdGllcy4gICBUaGlzIHdvdWxkIGFsc28gYmUgYW4gZXhjZWxsZW50IHVz ZSBvZiBtZXRhZGF0YSB3aGVyZSB0aGUgaW5pdGlhbCBpbmdyZXNzIG5vZGUgY291bGQgYWRkIG9u ZSBvciBtb3JlIHBpZWNlcyBvZiBtZXRhZGF0YSB0aGF0IGRvd25zdHJlYW0gbm9kZXMgY291bGQg bWFrZSB1c2Ugb2YgaW4gdGhlaXIgcG9saWN5IGRlY2lzaW9ucy4NCg0KICAgIFJvbg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFttYWls dG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dIA0KU2VudDogTW9uZGF5LCBKdWx5IDE0LCAy MDE0IDEwOjM5IEFNDQpUbzogTHVjeSB5b25nOyBOQVBJRVJBTEEsIE1BUklBIEg7IFJvbiBQYXJr ZXI7IFh1eGlhb2h1OyBtaWtlYmlhbmNAYW9sLmNvbTsgamd1aWNoYXJAY2lzY28uY29tOyBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KQ2FuIHdlIGZpcnN0IGZpZ3VyZSBvdXQg d2hhdCB3ZSBtZWFuIGJ5IGEgc2VydmljZSBwYXRoPw0KT25jZSB3ZSBoYXZlIHRoYXQsIEkgYmVs aWV2ZSB3ZSBjYW4gd29yayBvdXQgd2hhdCB3ZSB3YW50IHRoZSANCmFyY2hpdGVjdHVyZSB0byBy ZXF1aXJlIG9mIHNvbHV0aW9ucyBpbiB0ZXJtcyBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiBpbiAN CnRoZSBwYWNrZXQuICBCdXQgc2luY2UgZm9sa3MgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIGV4aXN0 aW5nIGRlZmluaXRpb25zIA0KYW5kIGNvbWluZyB0byBkaWZmZXJlbnQgbWVhbmluZ3MsIGFuZCBo YXZlIGJlZW4gbm90aW5nIGNvcnJlY3RseSANCmNvbnRyYWRpY3Rpb25zIGluIHRoZSB3b3JkcyB3 ZSBjaG9zZSBmb3IgdGhlIGV4aXN0aW5nIGRlZmluaXRpb24sIEkgDQp3b3VsZCByZWFsbHkgYXBw cmVjaWF0ZWQgaXQgaWYgZm9sa3Mgd291bGQgY29tbWVudCBvbiB0aGUgZGVmaW5pdGlvbiBvZiAN CnNlcnZpY2UgZnVuY3Rpb24gcGF0aCB0aGF0IEkgc2VudCB0byB0aGUgbGlzdC4NCg0KWW91cnMs DQpKb2VsDQoNCk9uIDcvMTQvMTQsIDk6MzAgQU0sIEx1Y3kgeW9uZyB3cm90ZToNCj4gQ29ucXVl ciB3aGF0IE1hcmlhIHNheXMuDQo+DQo+IEx1Y3kNCj4NCj4gKkZyb206KnNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpOQVBJRVJBTEEsIE1BUklBIEgNCj4g KlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMTQgODoyMSBBTQ0KPiAqVG86KiBSb24gUGFya2Vy OyBYdXhpYW9odTsgbWlrZWJpYW5jQGFvbC5jb207IGpndWljaGFyQGNpc2NvLmNvbTsNCj4gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYu b3JnDQo+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZA0KPiBMb2FkIEJhbGFuY2Vycw0KPg0KPiBUaGUgbWVhbmluZyBv ZiB0aGUgU0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8gbWUg4oCTIGFuIGFic3Ry YWN0DQo+IGlkZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9mIHNlcnZpY2UgZnVuY3Rpb24gaW5z dGFuY2VzIChpLmUuLCBTRlAgSUQgMQ0KPiA9IHtTRi1BLTEsIFNGLUItMywgU0YtQy0yfSkuICAg IEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFiZWwNCj4gc3RhY2vigJ0g4oCT IHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5ldHdvcmsN Cj4gbG9jYXRpb25zLiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxlYXN0IHRvIG1lLCB0 aGF0IHRoZXJlIGlzIGENCj4gY2VudHJhbCBwb2ludCBvZiBzZWxlY3Rpb24gZm9yIHRoaXMgZW5k IHRvIGVuZCBzZXF1ZW5jZSAoYmFycmluZw0KPiByZWNsYXNzaWZpY2F0aW9uLCBvZiBjb3Vyc2Up LiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQNCj4gaW1wbGljYXRpb24uICAgIEkg aGF2ZSBiZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRyYWwgcG9pbnQNCj4gbWV0aG9k b2xvZ3kgZHVlIHRvIHJlYWwtd29ybGQgY29tcGxleGl0aWVzIG9mIGR5bmFtaWMgc2NhbGUgYW5k DQo+IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMuDQo+DQo+IDxNYXJpYT4gSSBh Z3JlZS4gSXQgc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBieSB0aGUgU0ZDIGFyY2hpdGVjdHVyZSB0 aGF0DQo+IHNvbWV0aGluZyBjYWxsZWQg4oCcc2VydmljZSBmdW5jdGlvbiBwYXRoIElE4oCdIGlz IGNhcnJpZWQgaW4gdGhlIHBhY2tldCwNCj4gYmVjYXVzZSBpdCBpcyBub3QgbmVjZXNzYXJ5IG9y IHRoZSBvbmx5IHdheSB0byBpbXBsZW1lbnQgc2VydmljZQ0KPiBjaGFpbmluZy4gVGhlcmUgbWln aHQgc29sdXRpb25zIHRoYXQgd291bGQgZG8gdGhhdCBidXQgaXQgY2Fubm90IGFuZA0KPiBkb2Vz buKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZC4NCj4NCj4gTWFyaWENCj4NCj4gQW4gYWx0ZXJuYXRp dmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNlIGNlbnRyYWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0 aGUNCj4gY2hhaW4gb2YgYWJzdHJhY3Qgc2VydmljZSBmdW5jdGlvbnMgKGkuZS4sIFNGQyBJRCAx ID0ge1NGLUEsIFNGLUIsDQo+IFNGLUN9KSwgYnV0IGFsbG93IHRoZSBhY3R1YWwgaW5zdGFuY2Ug c2VsZWN0aW9uIHRvIGJlIGRpc3RyaWJ1dGVkLA0KPiByZWFsaXplZCBieSB0aGUgY2xhc3NpZmll ciBhbmQgdGhlIFNGRnMuDQo+DQo+IEdpdmVuIGEgdG9wb2xvZ3kgbGlrZToNCj4NCj4gQ2xhc3Np ZmllciAtLS0tLS0tICBTRkYtMSAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0tLS0tLS0tLS0tLS0tLS1TRkYtNA0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8DQo+ICAgICAgICAgICAgICB8ICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgIFNGRi1BLTEg ICAgICAgU0ZGLUEtMiAgICAgICBTU0YtQi0xDQo+IFNGRi1CLTIgICAgICAgICBTRkYtQy0xICAg ICAgIFNGRi1DLTIgICAgICAgICAgICAgICAgICAgU0ZGLUEtMw0KPg0KPiBBbmQgYXNzdW1pbmcg YSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBnbyBzb21ldGhpbmcN Cj4gbGlrZSB0aGlzOg0KPg0KPiAxIENsYXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7 U0YtQSwgU0YtQiwgU0YtQ30NCj4NCj4gMiBDbGFzc2lmaWVyIHNlbGVjdHMgU0ZGLTEgYXMgaG9z dGluZyBhdCBsZWFzdCBvbmUgaW5zdGFuY2Ugb2YgU0YtQQ0KPg0KPiAzIENsYXNzaWZpZXIgZW5j YXBzdWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2VydmljZSBpbmRleCA9 IDENCj4NCj4gNCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xDQo+DQo+IDUg U0ZGLTEsIHNlZWluZyBjaGFpbiBJRD0xLCBzZXJ2aWNlIGluZGV4PTEsIGNob29zZXMgU0ZGLUEt MiBhbW9uZ3N0IGl0cw0KPiBhdmFpbGFibGUgaW5zdGFuY2VzIG9mIFNGLUENCj4NCj4gNiBTRkYt MSBzZW5kcyBwYWNrZXQgdG8gU0ZGLUEtMQ0KPg0KPiA3IFNGRi1BLTEgc2VuZHMgcGFja2V0IGJh Y2sgdG8gU0ZGLTENCj4NCj4gOCBTRkYtMSBpbmNyZW1lbnRzIHNlcnZpY2UgaW5kZXggdG8gMg0K Pg0KPiA4IFNGRi0xIHNlbGVjdHMgU0ZGLTIgYXMgaG9zdGluZyBhdCBsZWFzdCBvbmUgaW5zdGFu Y2Ugb2YgU0YtQg0KPg0KPiA5IFNGRi0xIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0yDQo+DQo+ IDEwIHByb2Nlc3MgcmVwZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMsIGFzIHRoZSBlZ3Jlc3Mg Ym9yZGVyLA0KPiBwcm9ncmVzc2VzIHRoZSBwYWNrZXQgcGVyIHJvdXRpbmcgdGFibGUNCj4NCj4g VGhhbmtzLg0KPg0KPiAgICAgUm9uDQo+DQo+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqWHV4aWFvaHUNCj4gKlNlbnQ6KiBTdW5kYXksIEp1 bHkgMTMsIDIwMTQgMTE6MzAgUE0NCj4gKlRvOiogbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbQ0KPiA8bWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbT47IG1uMTkyMUBhdHQuY29tIDxtYWlsdG86bW4xOTIxQGF0dC5jb20+Ow0KPiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT47DQo+IGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPjsgUm9uIFBhcmtlcjsNCj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K PiAqU3ViamVjdDoqIFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkDQo+IEJhbGFuY2Vycw0KPg0KPiBBZ3JlZSB0aGF0IHRoZSBjdXJyZW50 IGRlZmluaXRpb24gb2YgdGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJpdCBjb25mdXNp bmcsIGp1c3QgYXMgd2hhdCB5b3UgaGFkIHBvaW50ZWQgb3V0Lg0KPg0KPg0KPg0KPiBJbiBteSB1 bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRo ZSBuZXR3b3JrIHNob3VsZCBiZSDigJxhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBh bmQgU0YgSURz4oCdKHNlZSAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3By aW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMSkuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0 aGUgU0ZQIGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRoZXIg dGhyb3VnaCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVyZSB0 aGUgc2VydmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNGRiBh bmQgdGhlIE5GIGNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUgU0Yg YW5kIFNGIHByb3h5IGNvbXBvbmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3Vs ZCBiZSBhdHRhY2hlZCBvciBlbWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBhbmQg dGhvc2UgU0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90LiAg SW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIFNGIGluc3RhbmNlcyBvZiB0aGUg c2FtZSBTRiB0eXBlIChlLmcuLCBTRiBYKSBhcmUgYXR0YWNoZWQgdG8gYSBnaXZlbiBzZXJ2aWNl IG5vZGUsIHRoZSBzZXJ2aWNlIG5vZGUgY291bGQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB3aGlj aCBuZWVkcyBTRiBYIGFtb25nIHRob3NlIFNGIGluc3RhbmNlcyBvZiBTRiBYIHR5cGUgbG9jYWxs eS4gTWVhbndoaWxlLCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc2VydmljZSBub2RlcyB3aXRoaW4g YSBnaXZlbiBTRkMtZW5hYmxlZCBkb21haW4gd2hpY2ggYXJlIGVtYmVkZGVkIG9yIGF0dGFjaGVk IHdpdGggdGhlIFNGDQogIGluc3RhbmNlDQpzIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMg d2F5LCB0aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZSB2ZXJ5IGZsZXhpYmxlLg0K Pg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IFhpYW9odQ0KPg0KPiAqRnJvbToqc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4gKm1pa2ViaWFuY0Bhb2wuY29t IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+DQo+ICpTZW50OiogU2F0dXJkYXksIEp1bHkgMTIs IDIwMTQgMjo0NiBBTQ0KPiAqVG86KiBqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNvbQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tDQo+IDxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT47IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4gPG1haWx0bzpSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPg0KPiBXb3VsZG4ndCB0aGF0IGJlIGNhbGxlZCB0aGUgInNlcnZp Y2UgY2hhaW4gaWRlbnRpZmllciIgdGhlbj8gIElmIHRoZQ0KPiBzZXJ2aWNlIGNoYWluIGlzIHRo ZSBvcmRlcmVkIGxpc3Qgb2YgU0ZzIGFuZCB0aGUgc2VydmljZSBwYXRoIGlzIHRoZQ0KPiBvcmRl cmVkIGxpc3Qgb2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICJzZXJ2 aWNlIHBhdGgNCj4gaWRlbnRpZmllciIgd291bGQgYmUgYW4gaWRlbnRpZmllciBmb3IgYSBzZXJ2 aWNlICpwYXRoKiwgbm90IGEgc2VydmljZQ0KPiAqY2hhaW4qLg0KPg0KPg0KPiBBZ2FpbiwgSSB0 aGluayB0aGlzIGlzIHdoZXJlIHRoZSBjb25mdXNpb24ga2VlcHMgY3JlZXBpbmcgaW4uICBUaGUg dGVybXMNCj4gImNoYWluIiBhbmQgInBhdGgiIHNlZW0gaW5jb25zaXN0ZW50Lg0KPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4NCj4gKkZyb206ICpqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJAY2lz Y28uY29tDQo+IDxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29t Pj4NCj4gKlRvOg0KPiAqbWlrZWJpYW5jQGFvbC5jb208bWlrZWJpYW5jQGFvbC5jb20+LG1uMTky MUBhdHQuY29tPG1uMTkyMUBhdHQuY29tPixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxo YWxwZXJuLmNvbT4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnDQo+IDxtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20lM2NtaWtlYmlhbmNAYW9sLmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUz Y21uMTkyMUBhdHQuY29tJTNlLG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tJTNlLGptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhh bHBlcm4uY29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2NSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tJTNlLHNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQo+ ICpTZW50OiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0DQo+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+DQo+IFlvdXIgZGVmaW5p dGlvbiBvZiBzZXJ2aWNlIHBhdGggaXMgY29ycmVjdCBhcyBpdHMgdGhlIGZvcndhcmRpbmcgcGF0 aA0KPiB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2Vydmlj ZSBwYXRoIGlkZW50aWZpZXINCj4gaG93ZXZlciBwb2ludHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4g ZGF0YSBzdHJ1Y3R1cmUgYW5kIHRoYXQgaXMgdGhlbg0KPiByZXNvbHZlZCB0byBzcGVjaWZpYyBp bnN0YW5jZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0LWhvcHMgdG8gdGhvc2UNCj4gaW5zdGFuY2Vz IGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBp cyBpbg0KPiBwbGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0 aGUgbmV0d29yayB5b3UgbWF5IG9yDQo+IG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1 cmUgdG8gc3BlY2lmeSB3aGljaCBuZXh0LWhvcHMgbWF5IGJlDQo+IHVzZWQgKHdoZXJlIGEgc2lu Z2xlIG5leHQtaG9wIHdvdWxkIGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aA0K PiBmb3IgdGhhdCBzZXJ2aWNlIGNoYWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90 aGVyIHByb3RvY29sIC8NCj4gbWVjaGFuaXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVy ZSBmb3IgeW91Lg0KPg0KPiAqRnJvbTogKiJtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPiINCj4gPG1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20+Pg0KPiAqRGF0ZTogKkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KPiAq VG86ICpKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT4+LA0KPiAibW4xOTIxQGF0dC5jb20gPG1haWx0bzptbjE5MjFAYXR0LmNvbT4iIDxt bjE5MjFAYXR0LmNvbQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sICJtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4i IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA8bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4gPG1haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiINCj4gPFJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20NCj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4s ICJzZmNAaWV0Zi5vcmcNCj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPj4NCj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4NCj4gSSB0aGluayB0aGlzIGlzIHRoZSBy b290IG9mIHRoZSBjb25mdXNpb246DQo+DQo+PiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5DQo+ PiBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRp b24gdGhlcmVvZikuIEkNCj4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEw MOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KPj4gYW5kIHRoZW4gcHVz aCB0aGlzIGludG8gdGhlIG5ldHdvcmsNCj4NCj4gQnkgZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29k IGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJlZCBsaXN0IG9mDQo+IHNwZWNpZmljIFNG IGluc3RhbmNlcy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91IHVzZSBhICJzZXJ2aWNlIHBh dGgNCj4gaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVj aWZpY2FsbHkgIltkb2VzIG5vdF0NCj4gc3BlY2lmeSBzcGVjaWZpYyBpbnN0YW5jZXMiLg0KPg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gKkZyb206ICpqZ3VpY2hhckBjaXNjby5jb20NCj4gPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PGpndWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWlj aGFyQGNpc2NvLmNvbT4+DQo+ICpUbzogKk5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNv bQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bQ0KPiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4s Sm9lbCBNLg0KPiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPj4sUm9uDQo+IFBhcmtlcjxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t DQo+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9y Zw0KPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPj4NCj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkgMTEsIDIwMTQNCj4gKlN1YmplY3Q6ICpSZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4NCj4gTWFy aWEsDQo+DQo+IEkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQo+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250 YWlucyBTRiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGENCj4gY2hhaW4s IGxldOKAmXMgc2F5IFMxIC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUg U0ZQIHNwZWNpZnkNCj4gdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRyYWZm aWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCj4gSG93ZXZlciwgeW91IGRvICpub3Qq IGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludCAoSQ0KPiB3 aWxsIGFyZ3VlIHRoYXQgeW91IHNob3VsZCBidXQgeW91IGRvbuKAmXQgaGF2ZSB0byBhcmNoaXRl Y3R1cmFsbHkpLiBZb3UNCj4gY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KPiB0aGVuIHB1c2ggdGhhdCBpbmZv cm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhDQo+IHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291 bGQgY29udGFpbiB0aGUNCj4gbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bi gJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KPiB0aG9zZSBuZXh0LWhvcHMgaXMg dXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhIGNlbnRyYWxpemVkDQo+ IGNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91Z2ggQ0xJLCBsZWFybiB0aGVtIGR5bmFt aWNhbGx5IHRocm91Z2gNCj4gc29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28s IGdpdmVuIHRoaXMgaXQgaXMgbm90IGNvcnJlY3QgdG8NCj4gc2F5IHRoYXQgdGhlIHNlcnZpY2Ug cGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhIHByaW9yaQ0KPiBh bHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAoYW5kIHNvbWUgd291bGQgc2F5IHJl Y29tbWVuZGVkKSB0byBkbw0KPiBzby4NCj4NCj4gTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8g aG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoNCj4NCj4gSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlz IHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQo+IHNha2Ug bGV04oCZcyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKAmXQg d2FudCB0byBzcGVjaWZ5DQo+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAo b3Igc29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KPiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMN Cj4gYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRh dGEgc3RydWN0dXJlcyBhcmUNCj4gcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93 IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlcw0KPiB3aXRoIHNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0K PiBzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5TMyBhbmQgdGhl IGluZGV4IGluIHRoZSBTRkMNCj4gZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQgZXhhY3RseSB3 aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5IHdlDQo+IGFyZSBhdCBTMiBpbiB0 aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0 bw0KPiBTMyBhbmQgd2lsbCBkbyBhIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMgcmVh Y2hhYmxlLg0KPg0KPiBPbiA3LzExLzE0LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIg PG1uMTkyMUBhdHQuY29tDQo+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4NCj4g ID5KaW0sDQo+ICA+DQo+ICA+Q291bGQgeW91IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlv biBvZiBhICJzZXJ2aWNlIHBhdGgiIGFuZCBhDQo+ICA+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVy Ij8NCj4gID5JZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJl IGNob3NlbiBhcHJpb3JpICh3aGljaA0KPiAgPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZykg dGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2gNCj4gID5uZXh0LWhvcCBT RkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi4NCj4gID4NCj4gID5NYXJp YQ0KPiAgPg0KPiAgPg0KPiAgPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4+DQo+ DQo+IEZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28u Y29tXQ0KPiAgPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNDQo+ICA+PiBU bzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IDxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEpvZWwgTS4NCj4gID4+IEhhbHBl cm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gID4+ IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPiAgPj4NCj4gID4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVy c3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4gID4+IHByZXZlbnRzIGZ1bGwg ZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UN Cj4gID4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+ICA+Pg0KPiAg Pj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0 LmNvbQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+ICA+Pg0KPiAgPj4gPkRp dHRvLg0KPiAgPj4gPg0KPiAgPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4+ ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPG1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiAgPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tXQ0KPiAgPj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMx IEFNDQo+ICA+PiA+PiBUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IE5BUElFUkFMQSwgTUFS SUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24NCj4gID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3Jn IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiAgPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ICA+PiA+Pg0KPiAgPj4gPj4g UmUtLA0KPiAgPj4gPj4NCj4gID4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMg aXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPiAgPj5kcmFmdC4NCj4gID4+ID4+DQo+ ICA+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYg YSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4gID4+ID4+ZGlzdHJpYnV0ZWQNCj4gID4+ID4+IG1vZGVs IGlzIG5vdCBhbGxvd2VkLg0KPiAgPj4gPj4NCj4gID4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRo aXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZg0KPiAgPj4g Pj5zaG91bGQgYmUNCj4gID4+ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+ICA+PiA+Pg0KPiAgPj4g Pj4gQ2hlZXJzLA0KPiAgPj4gPj4gTWVkDQo+ICA+PiA+Pg0KPiAgPj4gPj4gPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiAgPj4gPj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+ICA+PiA+PiA+KGpndWljaGFy KQ0KPiAgPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4g ID4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFy a2VyOw0KPiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+PiA+T2Jq ZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4gID4+ID4+ID4NCj4gID4+ID4+ID5PayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBz cGVjaWZpY2FsbHkgaXMgdGhpcyBmdW5jdGlvbmFsaXR5DQo+ICA+PiA+PiA+cHJvaGliaXRlZD8g SWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZG4oCZ cw0KPiAgPj4gPj4gPndpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhlbiBsZXQgdGhlIHBhdGgg aWRlbnRpZmllciBwb2ludCB0byBhDQo+ICA+PiA+Pmxvb2t1cA0KPiAgPj4gPj4gPmludG8gdGhv c2UgbmV4dC1ob3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBub3QN Cj4gID4+c3VyZQ0KPiAgPj4gPj5ob3cNCj4gID4+ID4+ID50aGUgYXJjaGl0ZWN0dXJlIHByZXZl bnRzIHRoYXQ/DQo+ICA+PiA+PiA+DQo+ICA+PiA+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5B UElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tDQo+IDxtYWlsdG86bW4xOTIxQGF0dC5j b20+Pg0KPiAgPj4gd3JvdGU6DQo+ICA+PiA+PiA+DQo+ICA+PiA+PiA+PkFic29sdXRlbHkuDQo+ ICA+PiA+PiA+Pg0KPiAgPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICA+ PiA+PiA+Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKaW0gR3VpY2hhcmQNCj4gID4+ID4+ID4+PihqZ3VpY2hhcikNCj4gID4+ID4+ID4+PiBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPiAgPj4gPj4gPj4+IFRvOiBOQVBJ RVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4gc2ZjQGlldGYu b3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiAgPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiAgPj4gPj4gPj4+ DQo+ICA+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBI b3dldmVyLCBpdCBzZWVtcyB0byBtZQ0KPiAgPj4gPj50aGF0IGlmDQo+ICA+PiA+PiA+Pj4geW91 IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBp dA0KPiAgPj53aWxsDQo+ICA+PiA+PnVzZQ0KPiAgPj4gPj4gPj4+Zm9yDQo+ICA+PiA+PiA+Pj4g YSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5 b3UNCj4gID4+YmV0dGVyDQo+ICA+PiA+Pm1ha2UNCj4gID4+ID4+ID4+PiBzdXJlIHRoYXQgdGhh dCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8NCj4gID4+ ID4+cmVhY2gNCj4gID4+ID4+ID4+PnRoZQ0KPiAgPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3Ig dGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4gID4+ID4+ ID4+Pg0KPiAgPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4gID4+ID4+ IHdyb3RlOg0KPiAgPj4gPj4gPj4+DQo+ICA+PiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2 aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4gID4+cmVsZXZhbnQNCj4g ID4+ID4+ID4+PlNGRnMNCj4gID4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPiAgPj4g Pj4gPj4+ID4NCj4gID4+ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAg Pj4gPj4gPj4+ID4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSmltDQo+ICA+Pkd1aWNoYXJkDQo+ICA+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+ ICA+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4gID4+ ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcN Cj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+PiA+Pj4gPj4gU3ViamVjdDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ICA+PiA+PiA+ Pj4gPj4NCj4gID4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFu IHRoYXQgaWYgSSBoYXZlIHVuZGVyc3Rvb2QNCj4gID4+dGhlDQo+ICA+PiA+PiA+Pj4gPj5wcm9w b3NhbA0KPiAgPj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwg a25vd2xlZGdlIG9mIGV2ZXJ5IHNpbmdsZQ0KPiAgPj5TRg0KPiAgPj4gPj4gPj4+d2l0aGluDQo+ ICA+PiA+PiA+Pj4gPj50aGUNCj4gID4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBl dmVyeSBzaW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheSB0bw0KPiAgPj5rbm93DQo+ICA+PiA+ PmENCj4gID4+ID4+ID4+PiA+PnByaW9yaQ0KPiAgPj4gPj4gPj4+ID4+IHdoaWNoIFNGQ8K5cyBh IGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4NCj4gID4+cG9pbnQN Cj4gID4+ID4+aW4NCj4gID4+ID4+ID4+PnRpbWUuDQo+ICA+PiA+PiA+Pj4gPj4NCj4gID4+ID4+ ID4+PiA+PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFscGVybiINCj4gPGptaEBq b2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gID4+ID4+IHdy b3RlOg0KPiAgPj4gPj4gPj4+ID4+DQo+ICA+PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJv dXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4gID4+d2l0aA0KPiAg Pj4gPj50aGUNCj4gID4+ID4+ID4+PiA+PnlvdXINCj4gID4+ID4+ID4+PiA+PiA+cHJvcG9zYWwg YXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4gID4+ ID4+ID4+PnVuZGVyc3RhbmQNCj4gID4+ID4+ID4+PiA+PiA+aXQuKQ0KPiAgPj4gPj4gPj4+ID4+ ID4NCj4gID4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0 aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+ICA+PiA+Pm5leHQNCj4gID4+ID4+ID4+PiA+PiA+ c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJz DQo+ICA+PnRvKSwNCj4gID4+ID4+aW4NCj4gID4+ID4+ID4+PmV2ZXJ5DQo+ICA+PiA+PiA+Pj4g Pj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+ICA+PiA+PiA+Pj4gPj4g Pg0KPiAgPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGgg YWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+ICA+PiA+PnRoYXQNCj4gID4+ID4+ID4+PiA+PmV2 ZXJ5DQo+ICA+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBz ZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQNCj4gID4+ID4+ID4+PmJhbGFuY2VyLg0KPiAgPj4g Pj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRp dmUsIGFuZCAvIG9yDQo+ICA+PiA+PnN0YXRlZnVsLg0KPiAgPj4gPj4gPj4+ID4+ID5CdXQgaGF2 aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsDQo+ ICA+PiA+PmZsb3cNCj4gID4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBi YWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPiAgPj4gPj5hY2NlcHRhYmxlDQo+ICA+PiA+ PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+ICA+PiA+PiA+Pj4gPj4gPg0KPiAgPj4gPj4gPj4+ID4+ ID5Zb3VycywNCj4gID4+ID4+ID4+PiA+PiA+Sm9lbA0KPiAgPj4gPj4gPj4+ID4+ID4NCj4gID4+ ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToN Cj4gID4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFt IHRyeWluZyB0byBtYWtlIHRoaXMNCj4gID4+d29yaw0KPiAgPj4gPj4gPj4+ID4+c2Vuc2libHkN Cj4gID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJ IGV4cGVjdCB0aGF0IHRoZQ0KPiAgPj5zZXJ2aWNlDQo+ICA+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rp b25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPiAgPj53 aWxsDQo+ICA+PiA+PmJlDQo+ICA+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0 YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0KPiAgPj50byBiZQ0KPiAgPj4gPj4g Pj4+ID4+ZHJpdmVuIGJ5DQo+ICA+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5l IG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlDQo+ICA+PiA+PiA+Pj5zZWxmLXNlbGVj dGlvbg0KPiAgPj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0 aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4gID4+ID4+ZHJpdmUuDQo+ICA+PiA+PiA+Pj4gPj4g Pj4NCj4gID4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQg d29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4gID4+ID4+ZHJpdmVuDQo+ICA+PiA+PiA+Pj5ieQ0K PiAgPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNl cnZpY2UgcGF0aHMuIEl0IGlzDQo+ICA+PiA+PmhhcmRlcg0KPiAgPj4gPj4gPj4+dG8NCj4gID4+ ID4+ID4+PiA+PnNlZQ0KPiAgPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1 dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+ICA+PiA+PiA+Pj4gPj4gZHlu YW1pY2l0eQ0KPiAgPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPiAg Pj4gPj4gPj4+ID4+ID4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9z dCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzDQo+ICA+PiA+Pm91dHNpZGUNCj4g ID4+ID4+ID4+Pm9mDQo+ICA+PiA+PiA+Pj4gPj50aGUNCj4gID4+ID4+ID4+PiA+PiA+PiBzY29w ZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4gID4+ ID4+dGFza2VkIHRvDQo+ICA+PiA+PiA+Pj4gPj5hZ3JlZQ0KPiAgPj4gPj4gPj4+ID4+ID4+b24u DQo+ICA+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMg d2UgaGF2ZSB0byBkbyBpdCBhDQo+ICA+PmNlcnRhaW4NCj4gID4+ID4+ID4+PndheS4NCj4gID4+ ID4+ID4+PiA+Pml0DQo+ICA+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUg dGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+ICA+PiA+PiA+Pj4gPj4gPj4NCj4gID4+ID4+ ID4+PiA+PiA+PiBZb3VycywNCj4gID4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+ICA+PiA+PiA+Pj4g Pj4gPj4NCj4gID4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGgg d3JvdGU6DQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3Jt YXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4gID4+ID4+IHRoYXQNCj4gID4+ID4+ID4+ PiA+Pm5lZWRzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBi ZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4g ID4+ID4+YWNyb3NzDQo+ICA+PiA+PiA+Pj5kYXRhDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBjZW50 ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+ICA+ PmFuZA0KPiAgPj4gPj4gPj4+IGNvbXBsZXgNCj4gID4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0 aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPiAgPj4g Pj4gPj4+ZGlmZmljdWx0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVh bGl6ZS4NCj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlv dXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+ICA+PmR5bmFtaWMN Cj4gID4+ID4+ID4+PiByb3V0aW5nLA0KPiAgPj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBk YXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPiAgPj53aGljaA0KPiAg Pj4gPj5hcmUNCj4gID4+ID4+ID4+PiA+PmJpZ2dlcg0KPiAgPj4gPj4gPj4+ID4+ID4+PiBwcm9i bGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+ ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhh dCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPiAgPj5pcw0KPiAgPj4g Pj5hDQo+ICA+PiA+PiA+Pj5nb29kDQo+ICA+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBp cyB0b28gY29tcGxpY2F0ZWQuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ICA+PiA+PiA+Pj4gPj4g Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+ID4+ID4+ PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tDQo+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+ICA+PiA+PiA+Pj4gPj4gPj4+IFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUgUE0NCj4gID4+ID4+ID4+PiA+PiA+Pj4gVG86IFJv biBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1pa2ViaWFuY0Bhb2wuY29tDQo+IDxtYWls dG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPiAgPj5JYW4NCj4gID4+ID4+ID4+PlNtaXRoOw0KPiAg Pj4gPj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+ PiA+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkDQo+ICA+PkJhbGFuY2Vycw0KPiAgPj4gPj4gPj4+ID4+ID4+Pg0KPiAgPj4gPj4g Pj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJ IHdvdWxkDQo+ICA+PnByZWZlcg0KPiAgPj4gPj53ZQ0KPiAgPj4gPj4gPj4+ID4+ID4+PmFjdHVh bGx5DQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFs bG93IGFsbCBwb3NzaWJsZQ0KPiAgPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9s DQo+ICA+PiA+PnJlcXVpcmVtZW50cw0KPiAgPj4gPj4gPj4+YW5kDQo+ICA+PiA+PiA+Pj4gPj4g dGhlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4gID4+ID4+ ID4+PiA+PiA+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGlu Zm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+ICA+PiA+PnRoYXQNCj4gID4+ID4+ ID4+PiBuZWVkcw0KPiAgPj4gPj4gPj4+ID4+IHRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdp ZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPiAgPj4g YWNyb3NzDQo+ICA+PiA+PiA+Pj5kYXRhDQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0 aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4gID4+YW5kDQo+ ICA+PiA+PiA+Pj5jb21wbGV4DQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWlu ZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPiAgPj4gPj4gPj4+ZGlm ZmljdWx0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4gID4+ID4+ID4+ PiA+PiA+Pj4gSm9lbA0KPiAgPj4gPj4gPj4+ID4+ID4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+PiBC dXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pg0KPiAgPj4gPj4g Pj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0 byBlbmQNCj4gID4+c2VsZWN0aW9uDQo+ICA+PiA+Pm9mDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiAo dG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUN Cj4gID4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3At YnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkNCj4gID4+ ID4+dGhlDQo+ICA+PiA+PiA+Pj4gPj5TRkZzKT8NCj4gID4+ID4+ID4+PiA+PiA+Pj4+IFN1Y2gg c2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+ICA+PkFu ZA0KPiAgPj4gPj4gPj4+c3VyZWx5LA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBh cmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+ICA+PiA+PiA+Pj4gPj4g Pj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4gID4+ID4+ID4+ PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2Fj aCBldmVuDQo+ICA+PiB0aG91Z2gNCj4gID4+ID4+IGENCj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdy ZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+ICA+ PmxvY2FsDQo+ICA+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4gID4+ID4+ID4+PiA+PiA+Pj4+IHBv bGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0K PiAgPj4gPj5UaGlzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1 aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+ICA+PiA+Pk15DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFy aWx5IGRyaXZlbg0KPiAgPj5ieQ0KPiAgPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+ICA+PiA+PiA+ Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBX aXRoIGENCj4gID4+Z2xvYmFsDQo+ICA+PiA+PiA+Pj5wYXRoDQo+ICA+PiA+PiA+Pj4gPj5pZA0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5z dGFuY2UgYW5kIG5lZWRpbmcgdG8NCj4gID4+ID4+YWx0ZXINCj4gID4+ID4+ID4+PnRoZQ0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5 IGFmZmVjdGVkDQo+ICA+PmVuZC10by1lbmQNCj4gID4+ID4+ID4+PnBhdGguDQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBGcm9tOiBzZmMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRm Lm9yZyA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0NCj4gb24gYmVoYWxmIG9mIEpvZWwg SGFscGVybiBEaXJlY3QNCj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGlyZWN0QGpvZWxoYWxw ZXJuLmNvbQ0KPiA8bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0gU2VudDogVGh1 cnNkYXksIEp1bHkgMTAsDQo+ICA+PjIwMTQNCj4gID4+ID4+IDY6MTUNCj4gID4+ID4+ID4+PiBQ TQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gVG86IG1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+Ow0KPiBJLlNtaXRoQEY1LmNvbSA8bWFpbHRvOkkuU21pdGhARjUuY29t Pjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiAgPj4gU3ViamVjdDoNCj4g ID4+ID4+IFJlOg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNG MSBuZWVkaW5nDQo+ICA+PnRvDQo+ICA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UNCj4gID4+ID4+ID4+ PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9u IGF0IHRoZQ0KPiAgPj5leGl0DQo+ICA+PiA+PmZyb20NCj4gID4+ID4+ID4+PiA+PiA+Pj4+IFNG MS4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRo ZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4gID4+ID4+bG9naWNh bGx5DQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4g Y2xlYXJseSBkZXNjcmliZSBob3cgdGhleQ0KPiAgPj4gPj4gY2hvb3NlDQo+ICA+PiA+PiA+Pj50 bw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVtIGZvciAic2VydmljZSIgZGVsaXZl cnkuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gWW91cnMsIEpv ZWwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0 LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbQ0KPiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t PiB3cm90ZToNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0 aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueQ0KPiAgPj4gPj5zb3J0DQo+ICA+PiA+PiA+ Pj5vZg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0g dG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlDQo+ICA+PiA+PnBhdGgNCj4gID4+ID4+ID4+Pihh bGwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5z dGFudGlhdGlvbi4gSSBiZWxpZXZlDQo+ICA+PnRoaXMNCj4gID4+ID4+ID4+Pm1lYW5zDQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBj bGFzc2lmaWVyDQo+ICA+PmNob29zZXMgYQ0KPiAgPj4gPj5TRg0KPiAgPj4gPj4gPj4+ID4+Q2hh aW4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhl IGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsDQo+ICA+PiA+PnRoZQ0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hl cmUNCj4gID4+ID4+IFNGSShuKQ0KPiAgPj4gPj4gPj4+IGlzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0 LA0KPiAgPj4gPj50aGlzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUg Y29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4gID4+ID4+ID4+PiBvcHBv c2VkDQo+ICA+PiA+PiA+Pj4gPj4gdG8NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBh bmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZg0KPiAgPj4gPj50 aGUNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQt c2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMg aXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4gID4+ID4+bmVjZXNzYXJ5 DQo+ICA+PiA+PiA+Pj50bw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNp ZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsDQo+ICA+PiA+PmFuZCB0bw0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRo YXQgU0ZDIHVzaW5nIFNGJ3MNCj4gID4+ID4+bmV0d29yaw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUN Cj4gID4+ID4+ID4+PmNyZWF0aW9uDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2Vydmlj ZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPiAgPj4gPj5mb3J3YXJkaW5n DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhl ciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0 aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNh dGlvbiAob3INCj4gID4+ID4+bm9uLWluaXRpYWwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xh c3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBw ZXJmb3JtZWQgYnkgYQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5j dGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPiAgPj4gPj5mdW5jdGlvbi4NCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxl Y3Rpb24gb2YgYSBuZXcNCj4gID4+ID4+U0ZQLCBhbg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiB1 cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4gID4+ ID4+cmVmZXJyZWQNCj4gID4+ID4+ID4+PnRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJi cmFuY2hpbmciLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4NCj4gID4+ID4+ID4+Pg0KPiAgPj4gPj4NCj4gID4+DQo+ICA+Pj4+Pj4+Pj4+Pj4+Pi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPiAgPj4gPj4g Pj4+Pj4+Pj4+Pi0tDQo+ICA+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4tLQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUu Y29tDQo+IDxtYWlsdG86KkkuU21pdGhARjUuY29tPjxJLlNtaXRoQEY1LmNvbSA8bWFpbHRvOkku U21pdGhARjUuY29tPj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4N Cj4gID4+IERpcmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbQ0KPiA8bWFpbHRvOmptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPiAgPj4gPj4gTS4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+DQo+ICA+PiA+PiA+Pj4NCj4gID4+ID4+DQo+ICA+PiA+ Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PixodWFuZ0BzY2UuY2FybGV0b24uY2ENCj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0 b24uY2E+PGh1YW5nQHNjZS4NCj4gPG1haWx0bzpodWFuZ0BzY2UuJTBiPj4+ID4+ID4+PiA+PiBj YXJsZXRvbi4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZw0KPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIw MTQNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ICA+PiA+PkJhbGFuY2Vycw0KPiAgPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNh Z3JlZWluZy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElm IHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPiAgPj50 aGF0IGlzDQo+ICA+PiA+PiA+Pj53aGF0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlv biBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMNCj4gID4+ID4+ID4+ PnByZWNvbmNlaXZlZA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0 aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aA0KPiAgPj4gdGhhdA0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUg ZGVncmVlIG9mDQo+ICA+PiA+PmFzcGlyYXRpb24NCj4gID4+ID4+IHRvDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRo ZQ0KPiAgPj4gPj5hcmNoaXRlY3R1cmUNCj4gID4+ID4+ID4+Pi0NCj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhh dCBhbg0KPiAgPj4gPj4gPj4+YXJiaXRyYXJ5DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVy IGlzICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPiAgPj4g Pj4gPj4+ID4+aW50ZW50aW9uYWwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhh dCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZw0KPiAgPj4gPj5pbXBhY3Rz DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRp Z2F0aW9uLCBlbGFzdGljaXR5LA0KPiAgPj4gPj5hZGRyZXNzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5v dA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGgu DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IEZy b206IEpvZWwgSGFscGVybiBEaXJlY3QNCj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIDxt YWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XQ0KPiAgPj4gPj5TZW50Og0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBT bWl0aDsgSm9lbCBNLg0KPiAgPj4gPj4gSGFscGVybjsNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBo dWFuZ0BzY2UuY2FybGV0b24uY2ENCj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0K PiAgPj4gPj5TZXJ2aWNlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRo aXMNCj4gID4+ID4+cmVnYXJkLg0KPiAgPj4gPj4gPj4+SQ0KPiAgPj4gPj4gPj4+ID4+YW0NCj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBv ciB0aGUgc29sdXRpb24NCj4gID4+ID4+cHJvaGliaXQNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBk ZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG8NCj4g ID4+ID4+SHVhbmcncw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBh cyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPiAgPj4gPj4gcmVxdWlyZWQNCj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRl ZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJvaGliaXQNCj4gID4+c3VjaA0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVw ZW5kcyB1cG9uDQo+ICA+PiA+PiBtYW55DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBv dXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+ICA+PnRoaW5rDQo+ ICA+PiA+PnRoYXQNCj4gID4+ID4+ID4+PiA+PnRoZXkNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBh cmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0 dGVtcHRpbmcgdG8NCj4gID4+ID4+a25vdw0KPiAgPj4gPj4gPj4+d2hhdA0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVm dWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+ICA+PiA+PiA+Pj5taWxsaW9ucw0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQg Zmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXINCj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2 ZSB0aGF0IGluDQo+ICA+PnRoZQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9i aWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3UNCj4gID4+IGFyZQ0KPiAgPj4g Pj4gb25seQ0KPiAgPj4gPj4gPj4+ID4+IGdvaW5nDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdG8g aGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseQ0KPiAgPj5z bWFsbA0KPiAgPj4gPj4gPj4+IG51bWJlcnMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBvZiBhY3Rp dmUgc2VydmljZSBwYXRocz8NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVk IG1vcmUNCj4gID4+IHRoYW4NCj4gID4+ID4+ID4+PiA2NEsiDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IGZvcg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZw0KPiA8bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT5dDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDQ6NDYgUE0gVG86DQo+ICA+PiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2EgPG1haWx0bzpo dWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0KPiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsDQo+ICA+PmFuZA0KPiAgPj4gPj4gPj4+TG9hZA0KPiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiBCYWxhbmNlcnMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95 IHRoZQ0KPiAgPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFy dGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4gID4+dGhl aXINCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2Vz IG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkDQo+ICA+PiB1c2UNCj4gID4+ID4+IG9mDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0 IGhvdyB0byB3cml0ZQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFsIHdvcmRz IHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlDQo+ICA+PmRvZXMNCj4gID4+ID4+ID4+ PnBlcm1pdA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkg c2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVjdHVyZQ0KPiAgPj4gcGVybWl0cw0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIHJl cXVpcmVkIGJ5DQo+ICA+PiA+PnRoZQ0KPiAgPj4gPj4gPj4+d29yay4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gSXQgaXNuJ3QuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IFlvdXJzLCBKb2VsDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6 DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2 aWNlIGNoYWlucywgaXQgd2lsbA0KPiAgPj5tZWFuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAx NiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nDQo+ICA+PnRh YmxlDQo+ICA+PiA+Pm9mIGENCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAv MjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMsIGZy b20NCj4gID4+MQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAw MDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCBob3BlDQo+ICA+PnRoYXQNCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlm IHRoZXkNCj4gID4+ID4+Y2hvb3NlDQo+ICA+PiA+PiA+Pj50bw0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFk DQo+ICA+PiA+PiBwcm92aXNpb24NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNl cnZpY2UgcGF0aHMuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdy b3RlOg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZp ZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4gID4+ID4+IHNlcnZpY2UNCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlh DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpG cm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPiAgPj4g T2YNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoq IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+ICA+PiA+PjM6MDMNCj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gUE0gKlRvOiogTHVjeSB5b25nICpDYzoqIGptaEBqb2VsaGFscGVybi5jb20NCj4g PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPg0KPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+ICA+PiBDaGFpbnMsDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFs bCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZlcyB0aGUNCj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG1h a2UNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGgg aWRlbnRpZmllciBjYW4gYmUgdXNlZCB0bw0KPiAgPj4gPj4gZGVyaXZlDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3Bv cnQuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPiAgPj5z aW1wbHkNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0 aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0cw0KPiAgPj5tdXN0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRv IGJlIGFza2luZyBmb3Igb24NCj4gID4+dGhpcw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4gID4+ID4+IGlk ZW50aWZpZXINCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3Jl IHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbg0KPiAgPj4gPj4gcmVzdWx0DQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0 cmFuc3BvcnQgbmV4dA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEw LCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IDxsdWN5LnlvbmdAaHVhd2VpLmNvbSA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPg0KPiAg Pj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4gPG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbSUzZT4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2gu IGRvYyBzaG91bGQgbm90IG1hbmRhdGUgb25seSB1c2Ugb2YNCj4gID4+IHRoZQ0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9y d2FyZGluZw0KPiAgPj4gPj5hY3Rpb25zLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10qT24gQmVoYWxmDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPG1haWx0bzpPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+DQo+ICA+PiA+PiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPiAgPj4gPj4g Pj4+ID4+IEp1bHkNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAq VG86Km1pa2ViaWFuY0Bhb2wuY29tDQo+IDxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9l bGhhbHBlcm4uY29tDQo+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3Nm Y0BpZXRmLm9yZz4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5v cmc+ICpTdWJqZWN0OipSZTogW3NmY10gU2VydmljZQ0KPiAgPj4gPj5DaGFpbnMsDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmUtLA0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRy YWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoDQo+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGlkZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8N Cj4gID4+ZGVyaXZlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9u cy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g UmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZg0KPiAg Pj4gPj4gZXZlcnkNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVk IGRvbWFpbiBpcyBub3QNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQN Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95 bWVudCBjb250ZXh0cy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGll Y2Ugb2YNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24NCj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiB0aGF0IHdpbGwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2Vu dCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZQ0KPiAgPj4gcmVxdWlyZWQNCj4g ID4+ID4+IHRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNlcnZpY2Ug Y2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzDQo+ICA+PiA+PnVzZWQgdG8NCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IGFjdGlvbnMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1dGlvbi1vcmllbnRl ZCBkaXNjdXNzaW9uLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10q RGUgbGEgcGFydA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tIDxt YWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPiAgPj4gPj4g anVpbGxldA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBq b2VsaGFscGVybi5jb20NCj4gPG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5v cmcNCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZz4NCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBb c2ZjXSBTZXJ2aWNlDQo+ICA+PiA+PkNoYWlucywNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRp ZmZlcmVuY2UgYmV0d2Vlbg0KPiAgPj5TRg0KPiAgPj4gPj4gQ2hhaW4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYW5kIFNGDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNv IHRoYXQgaXQncw0KPiAgPj4gPj5jbGVhciB0bw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRob3Nl IG5vdA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwg aXQgc2VlbXMgdGhhdCBldmVyeW9uZQ0KPiAgPj5hZ3JlZXMNCj4gID4+ID4+b24NCj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlc2UgdGVybXMuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQgaXMg c3RpbGwgdW5jbGVhciBpcw0KPiAgPj53aGV0aGVyDQo+ICA+PiA+Pml0IGlzDQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1bHRpbWF0ZWx5IHNw ZWNpZnkgd2hhdA0KPiAgPj4gPj50aGUgSUQNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2Yg dGhlIFNGQyBIZWFkZXINCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzaG91bGQNCj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0 aGlzIGRyYWZ0DQo+ICA+PiA+PnNpbXBseQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRl bmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlcg0KPiAgPj5kcmFmdHMN Cj4gID4+ID4+dG8NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFu aXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFpbg0KPiAgPj4gb3INCj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcg0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgbmVnb3Rp YXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0 aGUgZHJhZnQgd291bGQgaGF2ZQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRo YXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2UNCj4gID4+ID4+IG9uZQ0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFs KSB0byBhdm9pZCBzb21lDQo+ICA+PiB2ZW5kb3JzDQo+ICA+PiA+PiBvbmx5DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5n IFNGQy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+DQo+ICA+PiA+PiA+Pj4N Cj4gID4+ID4+DQo+ICA+Pg0KPiAgPj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+Pj4+Pj4+Pj4+Pj4+ Pi0tDQo+ICA+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4gID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPiAgPj4g Pj4gPj4+ID4+Pj4+Pj4tLQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipq bWhAam9lbGhhbHBlcm4uY29tDQo+IDxtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20+PGptaEBq b2VsaGFscGVybi5jb20NCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPg0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNj am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbSUzZT4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2Zj QGlldGYub3JnDQo+IDxtYWlsdG86KnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnIDxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRm Lm9yZyUzY3NmY0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5v cmclM2U+Pg0KPiAgPj4gKlNlbnQ6KlR1ZXNkYXksDQo+ICA+PiA+PiBKdWx5DQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kDQo+ICA+PkxvYWQNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJz DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkg aGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+ICA+PmFuc3dl cg0KPiAgPj4gPj5hDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50 cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPiAgPj4gPj4gPj4+IHByb3Bvc2VkDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3Vt aW5nIHdlIGNhbiBnZXQNCj4gID4+IHdvcmtpbmcNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Z3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPiAgPj4gaW1w cm92ZQ0KPiAgPj4gPj4gdGhlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28g dGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4NCj4gID4+ID4+dGhlDQo+ ICA+PiA+PiBXRw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5k ZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRlbmQ/ IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPiAgPj4gPj5wZXJzb25hbA0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBp dCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQNCj4gID4+ID4+d2hhdA0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJj aGl0ZWN0dXJlLiBXZQ0KPiAgPj5hcmUNCj4gID4+ID4+IG5vdA0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50 aXJlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWlu aW5nLiBUaGF0IHdvdWxkIGVuY29tcGFzcw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1Mv QlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQo+ICA+PnZpcnR1YWwN Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwg YW5kIG1hbnkgb3RoZXINCj4gID4+ID4+IGFzcGVjdHMuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55 IHRoaW5ncyB3aGljaCBjbGVhcmx5IG5lZWQNCj4gID4+IHRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdp dGgNCj4gID4+ID4+YWJvdmUNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJl DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZQ0K PiAgPj4gZG9pbmcuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2UgcGF0 aCwNCj4gID4+YXMgSQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gdGhlbSwNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVk IHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdA0KPiAgPj4gPj5s ZWFzdA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0 IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQNCj4gID4+d2lsbA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IGFyZQ0K PiAgPj4gPj5tb3JlLg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhl IGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIG9mDQo+ICA+PiA+PnRoZXNlLA0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxh ciBraW5kDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbiBhbnkgc29sdXRpb24uDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92 aWRlZCB0byB0aGUgZW5kDQo+ICA+PiA+PnVzZXIuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+ICA+PnBhY2tl dHMsDQo+ICA+PiA+PmFuZA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVt IChvcg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIHNlcnZpY2UNCj4g ID4+ID4+aW5zdGFuY2UNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUg dXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPiAgPj4gPj5zZXJ2aWNlDQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5jbHVkZSBpbiBz ZXJ2aWNlIGNoYWluaW5nLg0KPiAgPj4gPj5JdCdzDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlDQo+ICA+PiA+ PiBjaGFpbmluZyBpcw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFz IHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4gID4+ID4+YXJjaHRpZWN0dXJlLg0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0 IGlzIHNpbXBseSBhDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBh Y2tldC4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZQ0KPiAg Pj5jYW4NCj4gID4+ID4+aGF2ZQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gYXBwZWFycw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUNCj4gID4+cG9pbnQN Cj4gID4+ID4+b2YNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGZvciBhDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNl cnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQNCj4gID4+ID4+YnkgYQ0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+ ICA+Pm9uZSBvcg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5j ZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2UNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0aGlzIGlzDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBkYXRhIHBsYW5lDQo+ICA+PiA+Pm1lY2hhbmlzbXMuDQo+ICA+PiA+PiBJdA0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMg Y29udHJvbA0KPiAgPj4gPj5tZWNoYW5pc21zLA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBz dWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LA0KPiAgPj5h bmQNCj4gID4+ID4+dm0NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4g VGhlIGFyY2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+ICA+PnBlcm1pdHRpbmcNCj4gID4+ID4+dGhp cw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBi ZSBjYXJlZnVsIHRoYXQgb3VyDQo+ICA+PiA+PnRlcm1pbm9sb2d5DQo+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRv DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGluZyBpdC4N Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykg VGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0KPiAgPj5zZWxlY3RpbmcN Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBj aGFpbmluZyB0aGF0IGRpcmVjdA0KPiAgPj4gPj50cmFmZmljDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJlcXVpcmUN Cj4gID4+IHRoYXQNCj4gID4+ID4+YQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBz ZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhciBhdCBvbmx5IG9uZSBwbGFjZSBpbg0KPiAgPj50aGUNCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRo YXQgdGhlc2UgbWF5IGJlDQo+ICA+PmNvbWJpbmVkLiBJDQo+ICA+PiA+PiB0ZW5kDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVmZXIgdG8NCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBh cHBlYXIgdG8gc2VydmljZQ0KPiAgPj4gPj5jaGFpbmluZw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0ZXIN Cj4gID4+aXMNCj4gID4+ID4+YQ0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0u IEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciBvbmUuDQo+ICA+PiBUaHVzLA0KPiAg Pj4gPj4gdGhlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBsb2Fk IGJhbGFuY2luZw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVu dA0KPiAgPj4gPj5zaW5ndWxhcg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcw0KPiAgPj5pbg0KPiAgPj4g Pj50aGUNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlk LCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91dA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBzZXJ2aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYQ0K PiAgPj4gPj4gc2VxdWVuY2UNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBm dW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZg0KPiAgPj4gPj5wYWNrZXRzLg0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0aGF0 IHNvbWUgc3Vic2V0IG9mDQo+ICA+PnRyYWZmaWMNCj4gID4+ID4+aXMNCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVjdGlvbiwgYW5k DQo+ICA+PmZpcmV3YWxsDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVy ZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUNCj4gID4+Y2FjaGUNCj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5n IGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9u IHRvIGRpcmVjdCB0aGUNCj4gID4+cGFja2V0cy4NCj4gID4+IEENCj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YN Cj4gID4+ID4+bG9jYXRpb25zDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3 b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSBzaW5ndWxhciBvcg0KPiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMu IFRoZXkNCj4gID4+ID4+bWF5IGJlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3Nl ZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgYXMNCj4gID4+IHBvcnRzDQo+ ICA+PiA+PiBvbg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBt YW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+ICA+PiA+PmxvY2F0aW9ucw0KPiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5m cmFzdHJ1Y3R1cmUNCj4gID4+IGFuZA0KPiAgPj4gPj4gdGhlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRyYW5zcG9ydC4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhl IFNGQw0KPiAgPj5ncm91cCwNCj4gID4+ID4+IHdlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ PiBuZWVkIHRvIGJlDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91 dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlDQo+ICA+PiA+PnNlcnZpY2UNCj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4g QW5kIHdlIG5lZWQgdG8NCj4gID4+IHRhbGsNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJv dXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gdGhlDQo+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2Fp ZCAiYnV0IHRoZSB3aG9sZQ0KPiAgPj4gcGF0aA0KPiAgPj4gPj4gbWF5DQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVy ZSBkZWFscw0KPiAgPj4gPj53aXRoDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoYXQgaXNz dWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKQ0KPiAgPj5vbg0KPiAg Pj4gPj5sb2FkDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhl cmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4gID4+YmVoYXZpb3JzDQo+ICA+PiA+PiB3aGljaA0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNo YWluaW5nIG1lY2hhbmlzbXMgKGluDQo+ICA+PiA+Pm11Y2gNCj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHkN Cj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBM QU5zLikgVGhlIG90aGVyDQo+ICA+PiBwcm92aXNpb24NCj4gID4+ID4+IHdlDQo+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0DQo+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlk LWNoYWluIHdoZW4NCj4gID4+ID4+IG5lY2Vzc2FyeS4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBvbg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNs YXNzaWZpY2F0aW9uDQo+ICA+PnBvaW50Lg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hh dCB3ZSBhcmUgYWZ0ZXIuDQo+ICA+PklmIGl0DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRv ZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcNCj4gID4+ ID4+IGdyb3VwLA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91dCB3 aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5lZWRlZA0KPiAgPj4gdG8NCj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdp dGggdGhlDQo+ICA+PiA+PiBpbnRlbnQsDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4g d2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSB3b3JraW5nDQo+ICA+PiA+Pmdy b3VwDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZQ0KPiAgPj4gPj53aGF0IHRvDQo+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+ID4+IHNmYw0KPiAgPj4gPj4gPj4+ID4+ IG1haWxpbmcNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAg Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+ ID4+IHNmYw0KPiAgPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IDxtYWlsdG86c2Zj QGlldGYub3JnPg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiA+PiBzZmMN Cj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gbGlzdCBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4gc2ZjDQo+ICA+PiA+ PiA+Pj4gPj4gbWFpbGluZw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4gc2ZjDQo+ICA+PiA+PiA+Pj4gbWFpbGlu Zw0KPiAgPj4gPj4gPj4+ID4+IGxpc3QNCj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYu b3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gc2ZjDQo+ICA+PiA+PiA+Pj4gbWFpbGluZw0KPiAgPj4gPj4gPj4+ ID4+IGxpc3QNCj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ICA+PiA+PiBtYWlsaW5nDQo+ ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4gID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPiAgPj4gPj4g bWFpbGluZw0KPiAgPj4gPj4gPj4+ID4+IGxpc3QNCj4gID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ICA+PiA+PiA+Pj4gPj4g Pj4+DQo+ICA+PiA+PiA+Pj4gPj4gPj4NCj4gID4+ID4+ID4+PiA+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4gPj4gPj4+ID4+ID4+IHNm YyBtYWlsaW5nIGxpc3QNCj4gID4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+ICA+PiA+PiA+Pj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gID4+ID4+ID4+PiA+PiA+Pg0KPiAgPj4gPj4gPj4+ID4+ID4N Cj4gID4+ID4+ID4+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gID4+ID4+ID4+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4gPj4gPj4+ ID4+ID5zZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+PiA+Pj4gPj4g Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+PiA+PiA+Pj4g Pj4NCj4gID4+ID4+ID4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiAgPj4gPj4gPj4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gID4+ID4+ID4+ PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICA+PiA+PiA+Pj4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gID4+ID4+ID4+Pg0K PiAgPj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICA+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4gPj4gPj4+IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gID4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAgPj4gPj4gPg0KPiAgPj4gPj4gPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiA+PiA+c2ZjIG1h aWxpbmcgbGlzdA0KPiAgPj4gPj4gPnNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4gID4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAg Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg== From nobody Mon Jul 14 08:12:27 2014 Return-Path: <jguichar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481611A0A87 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 dI4PUM0k6nJX for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:12:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A61D1A07AB for <sfc@ietf.org>; Mon, 14 Jul 2014 08:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85566; q=dns/txt; s=iport; t=1405350739; x=1406560339; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GU8AawwGC+MQzph8PKtk23m5ytLv7rm8McY0kARktUg=; b=Mq9WAK5VTuR05JrbAe5gt2fM5VlrbcmGhfRul8MJ9D6dm+GCF8FkWBFK 9zYxkXm/afWciFiVbu5Z5fX12pEdEg3gQU4WaNVfzUGKdNQBK8vfRebPI dFA1h616hLcZvpJlkb7CaRCp9pVUiiudPUXrmqUboVgWfQKvxWV/jTP+o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAJ3yw1OtJV2Z/2dsb2JhbABPAQmDDlJagnGsIJI2CodDARl8FnWEAwEBAQQBAQEXAQgEDTECBwIVBAIBBgIRAQIBAQEBAgIjAwICAiULFAECBggCBAEQAhuIEwMRDZQQnCiXXxeBLIhSgyCBUQEELAULFgwCAgKCcYFMAQSWKkmEG4FKiiCININEQYEuQQ X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208";a="339881545" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2014 15:12:16 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6EFCGPf001850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 15:12:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 10:12:16 -0500 From: "Jim Guichard (jguichar)" <jguichar@cisco.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2fhe0Et9lFor0W50lebJdLndpuf97aAgAAF3oD//8AygA== Date: Mon, 14 Jul 2014 15:12:15 +0000 Message-ID: <CFE96A4C.2E4AC%jguichar@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> 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.180] Content-Type: text/plain; charset="utf-8" Content-ID: <7BA28C9486525B4DA3C3ABC7AEDAD427@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Jnaqy8UsQd0DUneZ8hX0OU6AOY0 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:12:26 -0000 UXVlc3Rpb246IHdoZXJlIGV4YWN0bHkgZG9lcyBpdCBzcGVjaWZ5IHRoYXQgdGhlIFNGUCAqbXVz dCogYmUNCnByZS1pbnN0YW50aWF0ZWQ/IFdoYXQgZXhhY3RseSBpcyB3cm9uZyB3aXRoIHRoZSB3 b3JkaW5nIOKAnFdoZW4gYW4gU0ZDIGlzDQppbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBp dCBpcyBuZWNlc3NhcnkgdG8gc2VsZWN0IHRoZSBzcGVjaWZpYw0KaW5zdGFuY2VzIG9mIFNGcyB0 aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IN CnRoYXQgU0ZDIHVzaW5nIFNG4oCZcyBuZXR3b3JrIGxvY2F0b3Jz4oCdPyBMZXTigJlzIHRyeSB0 byBiZSBzcGVjaWZpYyByYXRoZXINCnRoYW4gZGFuY2luZyBhcm91bmQgdGhlIHdvcmRpbmcuDQoN Ck9uIDcvMTQvMTQsIDExOjAwIEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20+IHdyb3RlOg0KDQo+SGksIEpvZWwsDQo+DQo+SSBxdW90ZSBmcm9tIHRoZSB0 aGUgbWVyZ2VkIGFyY2hpdGVjdHVyZSBkcmFmdDoNCj4NCj48YmVnaW4gcXVvdGF0aW9uPg0KPlNl cnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQyk6ICBBIHNlcnZpY2UgRnVuY3Rpb24gY2hhaW4gZGVm aW5lcyBhbg0KPiAgICAgICAgb3JkZXJlZCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBt dXN0IGJlIGFwcGxpZWQgdG8gcGFja2V0cw0KPiAgICAgICAgYW5kL29yIGZyYW1lcyBzZWxlY3Rl ZCBhcyBhIHJlc3VsdCBvZiBjbGFzc2lmaWNhdGlvbi4gIFRoZQ0KPiAgICAgICAgaW1wbGllZCBv cmRlciBtYXkgbm90IGJlIGEgbGluZWFyIHByb2dyZXNzaW9uIGFzIHRoZQ0KPiAgICAgICAgYXJj aGl0ZWN0dXJlIGFsbG93cyBmb3Igbm9kZXMgdGhhdCBjb3B5IHRvIG1vcmUgdGhhbiBvbmUgYnJh bmNoLg0KPiAgICAgICAgVGhlIHRlcm0gc2VydmljZSBjaGFpbiBpcyBvZnRlbiB1c2VkIGFzIHNo b3J0aGFuZCBmb3Igc2VydmljZQ0KPiAgICAgICAgZnVuY3Rpb24gY2hhaW4uDQo+DQo+ICAgU2Vy dmljZSBGdW5jdGlvbiBQYXRoIChTRlApOiAgVGhlIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGlu IHRoZQ0KPiAgICAgICAgbmV0d29yay4gIFBhY2tldHMgZm9sbG93IGEgc2VydmljZSBmdW5jdGlv biBwYXRoIGZyb20gYQ0KPiAgICAgICAgY2xhc3NpZmllciB0aHJvdWdoIHRoZSByZXF1aXNpdGUg c2VydmljZSBmdW5jdGlvbnMNCj4NCj5XaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0 aGUgbmV0d29yayBpdCBpcyBuZWNlc3NhcnkgdG8NCj4gICBzZWxlY3QgdGhlIHNwZWNpZmljIGlu c3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0byBjcmVhdGUNCj4gICB0aGUg c2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0YncyBuZXR3b3JrIGxvY2F0b3Iu ICBUaHVzLA0KPiAgIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluIHRoZSBjcmVh dGlvbiBvZiBhIFNlcnZpY2UNCj4gIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9y IGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdoIHRoZQ0KPiAgIFNGQy4gIEluIG90aGVyIHdvcmRz LCBhbiBTRlAgaXMgdGhlIGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPg0KPihT ZWN0aW9uIDQuMyBTRkYpDQo+U0ZQIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRl ZCB3aXRoIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4gICB0aGF0IGlzIHVzZWQgdG8gdW5p cXVlbHkgaWRlbnRpZnkgYW4gU0ZQLg0KPjxlbmQgcXVvdGF0aW9uPg0KPg0KPg0KPk15IHJlYWRp bmcgb2YgdGhlIFNlY3Rpb24gNC4zLCBnaXZlbiB0aGUgZGVmaW5pdGlvbnMgcHJlc2VudGVkIGJl Zm9yZSBpdCwNCj5pcyB0aGF0IGFuIGVuZC10by1lbmQgZnVsbHkgaW5zdGFudGlhdGVkIHBhdGgg aXMgc2VsZWN0ZWQgYW5kIHRoZW4gdXNlZA0KPnRvIHN0ZWVyIHRyYWZmaWMgdG8gdGhlIHJlcXVp c2l0ZSBTRkYncyBhbmQgU0Yncy4gICBXaGlsZSB0aG9zZQ0KPmRlZmluaXRpb25zIGNvdWxkIHN0 aWxsIGFwcGx5LCBldmVuIGluIGEgZGlzdHJpYnV0ZWQgaW5zdGFuY2UgYXNzaWdubWVudA0KPmFw cHJvYWNoLCB0aGUgY29udGV4dCBhcm91bmQgdGhvc2UgZGVmaW5pdGlvbnMgY2hhbmdlLiAgIEEg cGFydGljdWxhcg0KPmZsb3cgd291bGQsIGluZGVlZCBzdGlsbCBmb2xsb3cgc29tZSBwYXJ0aWN1 bGFyIHBhdGgsIGJ1dCB0aGVyZSB3b3VsZCBiZQ0KPm5vIG5lZWQgdG8gYXNzb2NpYXRlIGEgcGF0 aCBJRCB0byBpdCBhbmQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0bw0KPihsYXRlcikgYnVpbGQg YSBjb250cm9sIHBsYW5lIGFyb3VuZCBkaXN0cmlidXRpb24gb2YgdGhpcyBwYXRoIElEIGFuZA0K Pm1haW50ZW5hbmNlIG9mIHRob3NlIHBhdGggSURzIGluIHRoZSBmYWNlIG9mIGluZXZpdGFibGUg ZmFpbHVyZXMuDQo+DQo+SSBhbSBleHBsb3JpbmcgdGhlIGFsdGVybmF0aXZlIHdoZXJlIGZvcndh cmRpbmcgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZQ0KPmFic3RyYWN0IFNGQyBJRCB3aXRob3V0 IHJlcXVpcmluZyB0aGUgY29uY2VwdCBvZiBhIGNlbnRyYWxseSBrbm93biBTRlAgdG8NCj5leGlz dCBhdCBhbGwuICAgSW4gdGhpcyBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgdGhlIGluc3RhbmNlIHNl bGVjdGlvbiBpcw0KPmRpc3RyaWJ1dGVkIHRvIHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGJ3Mu ICAgQW55IGRlc2lyZWQgcG9saWN5IHVzZWQgdG8NCj5mbGF2b3IgaW5zdGFuY2Ugc2VsZWN0aW9u IGlzIHN0aWxsIHN1cHBvcnRlZCwgYnV0IHN1Y2ggcG9saWN5IHdvdWxkLA0KPmluZGVlZCwgbmVl ZCB0byBiZSBhdmFpbGFibGUgdG8gdGhlIGludm9sdmVkIGVudGl0aWVzLiAgIFRoaXMgd291bGQg YWxzbw0KPmJlIGFuIGV4Y2VsbGVudCB1c2Ugb2YgbWV0YWRhdGEgd2hlcmUgdGhlIGluaXRpYWwg aW5ncmVzcyBub2RlIGNvdWxkIGFkZA0KPm9uZSBvciBtb3JlIHBpZWNlcyBvZiBtZXRhZGF0YSB0 aGF0IGRvd25zdHJlYW0gbm9kZXMgY291bGQgbWFrZSB1c2Ugb2YgaW4NCj50aGVpciBwb2xpY3kg ZGVjaXNpb25zLg0KPg0KPiAgICBSb24NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxw ZXJuLmNvbV0NCj5TZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6MzkgQU0NCj5UbzogTHVj eSB5b25nOyBOQVBJRVJBTEEsIE1BUklBIEg7IFJvbiBQYXJrZXI7IFh1eGlhb2h1Ow0KPm1pa2Vi aWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207DQo+am1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnDQo+U3ViamVjdDogUmU6 IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkDQo+QmFsYW5jZXJzDQo+DQo+Q2FuIHdlIGZpcnN0IGZpZ3VyZSBvdXQgd2hhdCB3ZSBtZWFu IGJ5IGEgc2VydmljZSBwYXRoPw0KPk9uY2Ugd2UgaGF2ZSB0aGF0LCBJIGJlbGlldmUgd2UgY2Fu IHdvcmsgb3V0IHdoYXQgd2Ugd2FudCB0aGUNCj5hcmNoaXRlY3R1cmUgdG8gcmVxdWlyZSBvZiBz b2x1dGlvbnMgaW4gdGVybXMgb2YgY2FycnlpbmcgaW5mb3JtYXRpb24gaW4NCj50aGUgcGFja2V0 LiAgQnV0IHNpbmNlIGZvbGtzIGhhdmUgYmVlbiByZWFkaW5nIHRoZSBleGlzdGluZyBkZWZpbml0 aW9ucw0KPmFuZCBjb21pbmcgdG8gZGlmZmVyZW50IG1lYW5pbmdzLCBhbmQgaGF2ZSBiZWVuIG5v dGluZyBjb3JyZWN0bHkNCj5jb250cmFkaWN0aW9ucyBpbiB0aGUgd29yZHMgd2UgY2hvc2UgZm9y IHRoZSBleGlzdGluZyBkZWZpbml0aW9uLCBJDQo+d291bGQgcmVhbGx5IGFwcHJlY2lhdGVkIGl0 IGlmIGZvbGtzIHdvdWxkIGNvbW1lbnQgb24gdGhlIGRlZmluaXRpb24gb2YNCj5zZXJ2aWNlIGZ1 bmN0aW9uIHBhdGggdGhhdCBJIHNlbnQgdG8gdGhlIGxpc3QuDQo+DQo+WW91cnMsDQo+Sm9lbA0K Pg0KPk9uIDcvMTQvMTQsIDk6MzAgQU0sIEx1Y3kgeW9uZyB3cm90ZToNCj4+IENvbnF1ZXIgd2hh dCBNYXJpYSBzYXlzLg0KPj4NCj4+IEx1Y3kNCj4+DQo+PiAqRnJvbToqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKk5BUElFUkFMQSwNCj4+TUFSSUEgSA0K Pj4gKlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMTQgODoyMSBBTQ0KPj4gKlRvOiogUm9uIFBh cmtlcjsgWHV4aWFvaHU7IG1pa2ViaWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207DQo+ PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNA aWV0Zi5vcmcNCj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj4gTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBUaGUg bWVhbmluZyBvZiB0aGUgU0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8gbWUg4oCT IGFuIGFic3RyYWN0DQo+PiBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1 bmN0aW9uIGluc3RhbmNlcyAoaS5lLiwgU0ZQIElEIDENCj4+ID0ge1NGLUEtMSwgU0YtQi0zLCBT Ri1DLTJ9KS4gICAgSW4gc29tZSB3YXlzLCBpdCBpcyBhIGNvbGxhcHNlZCDigJxsYWJlbA0KPj4g c3RhY2vigJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNl IG9mIG5ldHdvcmsNCj4+IGxvY2F0aW9ucy4gICBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBs ZWFzdCB0byBtZSwgdGhhdCB0aGVyZSBpcyBhDQo+PiBjZW50cmFsIHBvaW50IG9mIHNlbGVjdGlv biBmb3IgdGhpcyBlbmQgdG8gZW5kIHNlcXVlbmNlIChiYXJyaW5nDQo+PiByZWNsYXNzaWZpY2F0 aW9uLCBvZiBjb3Vyc2UpLiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQNCj4+IGlt cGxpY2F0aW9uLiAgICBJIGhhdmUgYmVlbiB1bmNvbWZvcnRhYmxlIHdpdGggdGhhdCBjZW50cmFs IHBvaW50DQo+PiBtZXRob2RvbG9neSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2Yg ZHluYW1pYyBzY2FsZSBhbmQNCj4+IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMu DQo+Pg0KPj4gPE1hcmlhPiBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5IHRo ZSBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQNCj4+IHNvbWV0aGluZyBjYWxsZWQg4oCcc2VydmljZSBm dW5jdGlvbiBwYXRoIElE4oCdIGlzIGNhcnJpZWQgaW4gdGhlIHBhY2tldCwNCj4+IGJlY2F1c2Ug aXQgaXMgbm90IG5lY2Vzc2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVtZW50IHNlcnZpY2UN Cj4+IGNoYWluaW5nLiBUaGVyZSBtaWdodCBzb2x1dGlvbnMgdGhhdCB3b3VsZCBkbyB0aGF0IGJ1 dCBpdCBjYW5ub3QgYW5kDQo+PiBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZC4NCj4+DQo+ PiBNYXJpYQ0KPj4NCj4+IEFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzIHRvIHN0aWxsIHVzZSBj ZW50cmFsIHNlbGVjdGlvbiB0byBzZWxlY3QgdGhlDQo+PiBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2 aWNlIGZ1bmN0aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwNCj4+IFNGLUN9KSwg YnV0IGFsbG93IHRoZSBhY3R1YWwgaW5zdGFuY2Ugc2VsZWN0aW9uIHRvIGJlIGRpc3RyaWJ1dGVk LA0KPj4gcmVhbGl6ZWQgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkZzLg0KPj4NCj4+IEdp dmVuIGEgdG9wb2xvZ3kgbGlrZToNCj4+DQo+PiBDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0t LS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0yDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0t LS0tLS0tLS0tLS0tLS0tLS1TRkYtNA0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgIHwNCj4+ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICAgIFNGRi1BLTEgICAgICAgU0ZGLUEtMiAg ICAgICBTU0YtQi0xDQo+PiBTRkYtQi0yICAgICAgICAgU0ZGLUMtMSAgICAgICBTRkYtQy0yICAg ICAgICAgICAgICAgICAgIFNGRi1BLTMNCj4+DQo+PiBBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNv Z25pemVkIGZsb3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBnbyBzb21ldGhpbmcNCj4+IGxpa2UgdGhp czoNCj4+DQo+PiAxIENsYXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwgU0Yt QiwgU0YtQ30NCj4+DQo+PiAyIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBhcyBob3N0aW5nIGF0 IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1BDQo+Pg0KPj4gMyBDbGFzc2lmaWVyIGVuY2Fwc3Vs YXRlcyBwYWNrZXQgaW5kaWNhdGluZyBjaGFpbiBJRCA9IDEsIHNlcnZpY2UgaW5kZXgNCj4+PSAx DQo+Pg0KPj4gNCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xDQo+Pg0KPj4g NSBTRkYtMSwgc2VlaW5nIGNoYWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYt QS0yIGFtb25nc3QgaXRzDQo+PiBhdmFpbGFibGUgaW5zdGFuY2VzIG9mIFNGLUENCj4+DQo+PiA2 IFNGRi0xIHNlbmRzIHBhY2tldCB0byBTRkYtQS0xDQo+Pg0KPj4gNyBTRkYtQS0xIHNlbmRzIHBh Y2tldCBiYWNrIHRvIFNGRi0xDQo+Pg0KPj4gOCBTRkYtMSBpbmNyZW1lbnRzIHNlcnZpY2UgaW5k ZXggdG8gMg0KPj4NCj4+IDggU0ZGLTEgc2VsZWN0cyBTRkYtMiBhcyBob3N0aW5nIGF0IGxlYXN0 IG9uZSBpbnN0YW5jZSBvZiBTRi1CDQo+Pg0KPj4gOSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tldCB0 byBTRkYtMg0KPj4NCj4+IDEwIHByb2Nlc3MgcmVwZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMs IGFzIHRoZSBlZ3Jlc3MgYm9yZGVyLA0KPj4gcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciByb3V0 aW5nIHRhYmxlDQo+Pg0KPj4gVGhhbmtzLg0KPj4NCj4+ICAgICBSb24NCj4+DQo+PiAqRnJvbToq c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKlh1eGlhb2h1 DQo+PiAqU2VudDoqIFN1bmRheSwgSnVseSAxMywgMjAxNCAxMTozMCBQTQ0KPj4gKlRvOiogbWlr ZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IGpndWljaGFyQGNpc2Nv LmNvbQ0KPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNvbSA8bWFp bHRvOm1uMTkyMUBhdHQuY29tPjsNCj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsNCj4+IGptaEBqb2VsaGFscGVybi5j b20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtlcjsNCj4+IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICpTdWJqZWN0OiogW3NmY10gUmVkZWZpbmUg dGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+IEJhbGFuY2Vy cw0KPj4NCj4+IEFncmVlIHRoYXQgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGlu IHRoZSBhcmNoIGRyYWZ0IGlzIGEgYml0DQo+PmNvbmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBo YWQgcG9pbnRlZCBvdXQuDQo+Pg0KPj4NCj4+DQo+PiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUg U0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZQ0KPj5uZXR3b3JrIHNob3Vs ZCBiZSDigJxhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBhbmQgU0YgSURz4oCdKHNl ZQ0KPj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2Vk LXNmYy1hcmNoLTAxKS4gT2YNCj4+Y291cnNlLCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4g dGhlIGRhdGEgcGFja2V0IGlzIGFub3RoZXIgdGhpbmcNCj4+KGUuZy4sIGVpdGhlciB0aHJvdWdo IGEgcGF0aCBpZCBvciB0aHJvdWdoIGFuIE1QTFMgbGFiZWwgc3RhY2spLiBIZXJlDQo+PnRoZSBz ZXJ2aWNlIG5vZGUgbWVhbnMgdGhlIGRldmljZSB3aGljaCBjb250YWlucyB0aGUgU0ZGIGFuZCB0 aGUgTkYNCj4+Y29tcG9uZW50cyBtYW5kYXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBh bmQgU0YgcHJveHkgY29tcG9uZW50cw0KPj5vcHRpb25hbGx5LiBUaGUgc2VydmljZSBub2RlIGNv dWxkIGJlIGF0dGFjaGVkIG9yIGVtYmVkZGVkIHdpdGggbXVsdGlwbGUNCj4+U0YgaW5zdGFuY2Vz IGFuZCB0aG9zZSBTRiBpbnN0YW5jZXMgY291bGQgYmUgb2YgdGhlIHNhbWUgU0YgdHlwZSBvciBu b3QuDQo+PiBJbiB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2Vz IG9mIHRoZSBzYW1lIFNGIHR5cGUNCj4+KGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdp dmVuIHNlcnZpY2Ugbm9kZSwgdGhlIHNlcnZpY2Ugbm9kZQ0KPj5jb3VsZCBkaXN0cmlidXRlIHRo ZSB0cmFmZmljIHdoaWNoIG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzDQo+Pm9m IFNGIFggdHlwZSBsb2NhbGx5LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2 aWNlIG5vZGVzDQo+PndpdGhpbiBhIGdpdmVuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUg ZW1iZWRkZWQgb3IgYXR0YWNoZWQgd2l0aA0KPj50aGUgU0YNCj4gIGluc3RhbmNlDQo+cyBvZiB0 aGUgc2FtZSBTRiB0eXBlLiBJbiB0aGlzIHdheSwgdGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxk IGJlIG1hZGUNCj52ZXJ5IGZsZXhpYmxlLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBY aWFvaHUNCj4+DQo+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpP biBCZWhhbGYgT2YNCj4+ICptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPg0KPj4gKlNlbnQ6KiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2IEFNDQo+PiAqVG86 KiBqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFA YXR0LmNvbQ0KPj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGptaEBq b2VsaGFscGVybi5jb20NCj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbT47IHNmY0BpZXRmLm9yZw0KPj48bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICpT dWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5j ZXJzDQo+Pg0KPj4gV291bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNlIGNoYWluIGlk ZW50aWZpZXIiIHRoZW4/ICBJZiB0aGUNCj4+IHNlcnZpY2UgY2hhaW4gaXMgdGhlIG9yZGVyZWQg bGlzdCBvZiBTRnMgYW5kIHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlDQo+PiBvcmRlcmVkIGxpc3Qg b2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICJzZXJ2aWNlIHBhdGgN Cj4+IGlkZW50aWZpZXIiIHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0 aCosIG5vdCBhIHNlcnZpY2UNCj4+ICpjaGFpbiouDQo+Pg0KPj4NCj4+IEFnYWluLCBJIHRoaW5r IHRoaXMgaXMgd2hlcmUgdGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBpbi4gIFRoZSB0ZXJt cw0KPj4gImNoYWluIiBhbmQgInBhdGgiIHNlZW0gaW5jb25zaXN0ZW50Lg0KPj4NCj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4NCj4+ICpGcm9tOiAqamd1aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNp c2NvLmNvbQ0KPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5j b20+Pg0KPj4gKlRvOg0KPj4gDQo+PiptaWtlYmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9sLmNv bT4sbW4xOTIxQGF0dC5jb208bW4xOTIxQGF0dC5jb20+LG1vaGENCj4+bWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2VsaGFscGVybi5j bw0KPj5tPGptaEBqb2VsaGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208Um9uX1BhcmtlckBhZmZpcm1lDQo+PmRuZXR3b3Jrcy5jb20+LHNmY0BpZXRmLm9yZzxzZmNA aWV0Zi5vcmcNCj4+IA0KPj48bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNjbWlrZWJpYW5jQGFv bC5jb20lM2UsbW4xOTIxQGF0dC5jb20lM2NtbjE5MjFADQo+PmF0dC5jb20lM2UsbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2UNCj4+ LGptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlLFJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcw0KPj4uY29tJTNjUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bSUzZSxzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+Pg0KPj4gKlNlbnQ6ICpGcmlkYXksIEp1 bHkgMTEsIDIwMTQNCj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gWW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2Ug cGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoDQo+PiB0aHJvdWdoIHdo aWNoIHRyYWZmaWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZp ZXINCj4+IGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3RydWN0dXJl IGFuZCB0aGF0IGlzIHRoZW4NCj4+IHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNl ZCB1cG9uIHdoaWNoIG5leHQtaG9wcyB0byB0aG9zZQ0KPj4gaW5zdGFuY2VzIGFyZSBhdmFpbGFi bGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBpcyBpbg0KPj4gcGxh eS4gV2hlbiBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsg eW91IG1heSBvcg0KPj4gbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVj aWZ5IHdoaWNoIG5leHQtaG9wcyBtYXkgYmUNCj4+IHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQt aG9wIHdvdWxkIGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aA0KPj4gZm9yIHRo YXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90 b2NvbCAvDQo+PiBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5 b3UuDQo+Pg0KPj4gKkZyb206ICoibWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNA YW9sLmNvbT4iDQo+PiA8bWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4+DQo+PiAqRGF0ZTogKkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KPj4gKlRv OiAqSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20+PiwNCj4+ICJtbjE5MjFAYXR0LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1u MTkyMUBhdHQuY29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sICJtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPj4sICJqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj4sICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tDQo+PiA8bWFp bHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+Ig0KPj4gPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20NCj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbT4+LCAic2ZjQGlldGYub3JnDQo+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBJIHRoaW5rIHRo aXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCj4+DQo+Pj4gSSBkb27igJl0IHdhbnQg dG8gc3BlY2lmeQ0KPj4+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Ig c29tZSBjb21iaW5hdGlvbiB0aGVyZW9mKS4gSQ0KPj4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8NCj4+PlMxLT5TMi0+ UzMNCj4+PiBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KPj4NCj4+IEJ5IGRl ZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICJzZXJ2aWNlIHBhdGgiIHRvIGJlIGFuIG9yZGVyZWQg bGlzdCBvZg0KPj4gc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3Zl LCB5b3UgdXNlIGEgInNlcnZpY2UgcGF0aA0KPj4gaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBz ZXJ2aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0NCj4+IHNwZWNpZnkg c3BlY2lmaWMgaW5zdGFuY2VzIi4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiAqRnJv bTogKmpndWljaGFyQGNpc2NvLmNvbQ0KPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PGpn dWljaGFyQGNpc2NvLmNvbQ0KPj48bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQo+PiAqVG86 ICpOQVBJRVJBTEEsIE1BUklBIEg8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0 dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LEpvZWwgTS4NCj4+IEhhbHBlcm48 am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixSb24NCj4+ IFBhcmtlcjxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tDQo+PiA8bWFpbHRvOlJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86c2Zj QGlldGYub3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gKlNlbnQ6 ICpGcmlkYXksIEp1bHkgMTEsIDIwMTQNCj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gTWFyaWEsDQo+Pg0KPj4g SSB0aGluayBvZiBpdCB0aGlzIHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNp bXBseSBhIHBvaW50ZXINCj4+dG8NCj4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBT RiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lDQo+PmENCj4+IGNoYWluLCBs ZXTigJlzIHNheSBTMSAtPlMyLT4gUzMsIHlvdSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNG UCBzcGVjaWZ5DQo+PiB0aGUgc3BlY2lmaWMgbmV4dC1ob3BzIHRoYXQgeW91IHdhbnQgdHJhZmZp YyB0byBmbG93IHRocm91Z2ggZm9yIHRoYXQNCj4+U0ZQLg0KPj4gSG93ZXZlciwgeW91IGRvICpu b3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludA0KPj4o SQ0KPj4gd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlvdSBkb27igJl0IGhhdmUgdG8g YXJjaGl0ZWN0dXJhbGx5KS4gWW91DQo+PiBjb3VsZCBzaW1wbHkgYXNzaWduIGEgc2VydmljZSBw YXRoIGlkZW50aWZpZXIgdG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMNCj4+YW5kDQo+PiB0aGVuIHB1 c2ggdGhhdCBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwg aGF2ZSBhDQo+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMgbWFwcGluZyBhbmQgc2Fp ZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4NCj4+dGhlDQo+PiBuZXh0LWhvcHMgYXZhaWxhYmxlIGZv ciBlYWNoIG9mIHRoZSBTRuKAmXMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuDQo+PiB0 aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJv bSBhDQo+PmNlbnRyYWxpemVkDQo+PiBjb250cm9sbGVyLCBjb25maWd1cmUgdGhlbSB0aHJvdWdo IENMSSwgbGVhcm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoDQo+PiBzb21lIHByb3RvY29sIGV4 Y2hhbmdlLCB3aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bw0K Pj4gc2F5IHRoYXQgdGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMg YXJlIGNob3NlbiBhDQo+PnByaW9yaQ0KPj4gYWx0aG91Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2Vw dGFibGUgKGFuZCBzb21lIHdvdWxkIHNheSByZWNvbW1lbmRlZCkgdG8NCj4+ZG8NCj4+IHNvLg0K Pj4NCj4+IExldOKAmXMgdGFrZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xl YXI6DQo+Pg0KPj4gSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0x KSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQo+PiBzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBp dCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8NCj4+c3BlY2lmeQ0K Pj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0 aW9uIHRoZXJlb2YpLiBJDQo+PiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwx MDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvDQo+PlMxLT5TMi0+UzMNCj4+IGFuZCB0aGVu IHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVy ZXMgYXJlDQo+PiBwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZl biBTRkYsIHdoZW4gdHJhZmZpYw0KPj5hcnJpdmVzDQo+PiB3aXRoIHNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0KPj4gc3Ry dWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRl eCBpbiB0aGUgU0ZDDQo+PiBlbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJl IGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkNCj4+d2UNCj4+IGFyZSBhdCBTMiBpbiB0 aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0 bw0KPj4gUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJl YWNoYWJsZS4NCj4+DQo+PiBPbiA3LzExLzE0LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEg SCIgPG1uMTkyMUBhdHQuY29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+ Pg0KPj4gID5KaW0sDQo+PiAgPg0KPj4gID5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBk ZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4+ICA+InNlcnZpY2UgcGF0aCBp ZGVudGlmaWVyIj8NCj4+ICA+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5z dGFuY2VzIGFyZSBjaG9zZW4gYXByaW9yaQ0KPj4od2hpY2gNCj4+ICA+aXMgbXkgY3VycmVudCB1 bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0K Pj4gID5uZXh0LWhvcCBTRkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi4N Cj4+ICA+DQo+PiAgPk1hcmlhDQo+PiAgPg0KPj4gID4NCj4+ICA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gID4+DQo+Pg0KPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikg W21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+PiAgPj4gU2VudDogRnJpZGF5LCBKdWx5IDEx LCAyMDE0IDExOjE1IEFNDQo+PiAgPj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPjsgSm9lbCBNLg0KPj4gID4+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZyA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ICA+Pg0KPj4gID4+IEnigJltIHNv cnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoDQo+ PmlkZW50aWZpZXINCj4+ICA+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0 LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYQ0KPj5zZXJ2aWNlDQo+PiAgPj4gY2hhaW4gaWRlbnRp ZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT8NCj4+ICA+Pg0KPj4gID4+IE9uIDcvMTEvMTQsIDEw OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86 bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4+ICA+Pg0KPj4gID4+ID5EaXR0by4NCj4+ICA+PiA+ DQo+PiAgPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiA+PiBGcm9tOiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+DQo+PiAgPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tXQ0KPj4gID4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4g ID4+ID4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBK b2VsIE0uDQo+PkhhbHBlcm47IFJvbg0KPj4gID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+ID4+DQo+PiAgPj4gPj4g UmUtLA0KPj4gID4+ID4+DQo+PiAgPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhp cyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+PiAgPj5kcmFmdC4NCj4+ICA+PiA+ Pg0KPj4gID4+ID4+IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0 c2VsZiBhIGhpbnQgdGhhdCB0aGUNCj4+ZnVsbA0KPj4gID4+ID4+ZGlzdHJpYnV0ZWQNCj4+ICA+ PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4+ICA+PiA+Pg0KPj4gID4+ID4+IFNldmVyYWwg dm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluDQo+ Pml0c2VsZg0KPj4gID4+ID4+c2hvdWxkIGJlDQo+PiAgPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4N Cj4+ICA+PiA+Pg0KPj4gID4+ID4+IENoZWVycywNCj4+ICA+PiA+PiBNZWQNCj4+ICA+PiA+Pg0K Pj4gID4+ID4+ID4tLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ICA+PiA+PiA+RGUgOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0NCj4+R3Vp Y2hhcmQNCj4+ICA+PiA+PiA+KGpndWljaGFyKQ0KPj4gID4+ID4+ID5FbnZvecOpIDogdmVuZHJl ZGkgMTEganVpbGxldCAyMDE0IDE2OjE4DQo+PiAgPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJ QSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+PiBzZmNAaWV0Zi5vcmcgPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4gPg0KPj4gID4+ID4+ID5P ayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcw0KPj5m dW5jdGlvbmFsaXR5DQo+PiAgPj4gPj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3Ry aWJ1dGUgKmFsbCogbmV4dC1ob3BzIHRvICphbGwqDQo+PlNGRuKAmXMNCj4+ICA+PiA+PiA+d2l0 aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50 IHRvDQo+PmENCj4+ICA+PiA+Pmxvb2t1cA0KPj4gID4+ID4+ID5pbnRvIHRob3NlIG5leHQtaG9w cyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+PiAgPj5zdXJl DQo+PiAgPj4gPj5ob3cNCj4+ICA+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0 Pw0KPj4gID4+ID4+ID4NCj4+ICA+PiA+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFM QSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4N Cj4+ICA+PiB3cm90ZToNCj4+ICA+PiA+PiA+DQo+PiAgPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPj4g ID4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiAg Pj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSmltDQo+Pkd1aWNoYXJkDQo+PiAgPj4gPj4gPj4+KGpndWljaGFyKQ0KPj4gID4+ID4+ ID4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4gID4+ID4+ID4+PiBU bzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g ID4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9z YWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zDQo+PnRvIG1lDQo+PiAgPj4gPj50aGF0IGlmDQo+ PiAgPj4gPj4gPj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdo aWNoIHJlbW90ZSBTRkYgaXQNCj4+ICA+PndpbGwNCj4+ICA+PiA+PnVzZQ0KPj4gID4+ID4+ID4+ PmZvcg0KPj4gID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0 aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPj4gID4+YmV0dGVyDQo+PiAgPj4gPj5tYWtlDQo+PiAg Pj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9y d2FyZGluZyBsb2dpYw0KPj50bw0KPj4gID4+ID4+cmVhY2gNCj4+ICA+PiA+PiA+Pj50aGUNCj4+ ICA+PiA+PiA+Pj4gbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBh cmUgaW4gZGVlcA0KPj50cm91YmxlLg0KPj4gID4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiBPbiA3 LzExLzE0LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+ IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gID4+ID4+IHdyb3RlOg0KPj4gID4+ID4+ID4+ Pg0KPj4gID4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBp bnN0YW50aWF0ZWQgb25seSBpbg0KPj4gID4+cmVsZXZhbnQNCj4+ICA+PiA+PiA+Pj5TRkZzDQo+ PiAgPj4gPj4gPj4+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+PiAgPj4gPj4gPj4+ID4NCj4+ICA+ PiA+PiA+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiA+PiA+Pj4gPj4g RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0N Cj4+ICA+Pkd1aWNoYXJkDQo+PiAgPj4gPj4gPj4+ID4+KGpndWljaGFyKQ0KPj4gID4+ID4+ID4+ PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4gID4+ID4+ID4+PiA+ PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+IDxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj5CYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4g Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0 aGF0IGlmIEkgaGF2ZQ0KPj51bmRlcnN0b29kDQo+PiAgPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj5w cm9wb3NhbA0KPj4gID4+ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBm dWxsIGtub3dsZWRnZSBvZiBldmVyeQ0KPj5zaW5nbGUNCj4+ICA+PlNGDQo+PiAgPj4gPj4gPj4+ d2l0aGluDQo+PiAgPj4gPj4gPj4+ID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMg ZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5DQo+PnRvDQo+PiAg Pj5rbm93DQo+PiAgPj4gPj5hDQo+PiAgPj4gPj4gPj4+ID4+cHJpb3JpDQo+PiAgPj4gPj4gPj4+ ID4+IHdoaWNoIFNGQ8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkg Z2l2ZW4NCj4+ICA+PnBvaW50DQo+PiAgPj4gPj5pbg0KPj4gID4+ID4+ID4+PnRpbWUuDQo+PiAg Pj4gPj4gPj4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9l bCBNLiBIYWxwZXJuIg0KPj4gPGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPj4NCj4+ICA+PiA+PiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1h am9yDQo+PnByb2JsZW0NCj4+ICA+PndpdGgNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+ PnlvdXINCj4+ICA+PiA+PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFu ZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkNCj4+bm90DQo+PiAgPj4gPj4gPj4+dW5kZXJzdGFuZA0K Pj4gID4+ID4+ID4+PiA+PiA+aXQuKQ0KPj4gID4+ID4+ID4+PiA+PiA+DQo+PiAgPj4gPj4gPj4+ ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2Vy IGZvcg0KPj50aGUNCj4+ICA+PiA+Pm5leHQNCj4+ICA+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVu Y3Rpb24gdGhhdCBmb2xsb3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj4gID4+dG8p LA0KPj4gID4+ID4+aW4NCj4+ICA+PiA+PiA+Pj5ldmVyeQ0KPj4gID4+ID4+ID4+PiA+PiA+c2Vy dmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4+ICA+PiA+PiA+Pj4gPj4gPg0KPj4g ID4+ID4+ID4+PiA+PiA+U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBz ZXJ2aWNlcywgdGhhdA0KPj5tZWFucw0KPj4gID4+ID4+dGhhdA0KPj4gID4+ID4+ID4+PiA+PmV2 ZXJ5DQo+PiAgPj4gPj4gPj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cg c2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bA0KPj5sb2FkDQo+PiAgPj4gPj4gPj4+YmFsYW5jZXIuDQo+ PiAgPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBz ZW5zaXRpdmUsIGFuZCAvDQo+Pm9yDQo+PiAgPj4gPj5zdGF0ZWZ1bC4NCj4+ICA+PiA+PiA+Pj4g Pj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJl IGENCj4+ZnVsbCwNCj4+ICA+PiA+PmZsb3cNCj4+ICA+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwg c3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+ICA+PiA+PmFj Y2VwdGFibGUNCj4+ICA+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiAgPj4gPj4gPj4+ID4+ ID4NCj4+ICA+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPj4gID4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4g ID4+ID4+ID4+PiA+PiA+DQo+PiAgPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwg Sm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBl cnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlDQo+PnRoaXMNCj4+ICA+Pndv cmsNCj4+ICA+PiA+PiA+Pj4gPj5zZW5zaWJseQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1v cmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj4gID4+c2Vy dmljZQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFi bHkgdGhlIFNGRiBjYXBhYmlsaXRpZXMsDQo+PiAgPj53aWxsDQo+PiAgPj4gPj5iZQ0KPj4gID4+ ID4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNl cnZpY2UgY2hhaW5zDQo+PiAgPj50byBiZQ0KPj4gID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPj4g ID4+ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVu dHMsIGFuZCBlbmFibGUNCj4+ICA+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gID4+ID4+ID4+ PiA+PiA+PiBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkg cG9saWN5DQo+PiAgPj4gPj5kcml2ZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4gSSBjYW4gc2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4NCj4+ YXJjaHRpZWN0dXJlDQo+PiAgPj4gPj5kcml2ZW4NCj4+ICA+PiA+PiA+Pj5ieQ0KPj4gID4+ID4+ ID4+PiA+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBh dGhzLiBJdA0KPj5pcw0KPj4gID4+ID4+aGFyZGVyDQo+PiAgPj4gPj4gPj4+dG8NCj4+ICA+PiA+ PiA+Pj4gPj5zZWUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0 IGl0IGNhbiBiZSBkb25lKSB3aGVuIHdlIGFsbG93DQo+Pm1vcmUNCj4+ICA+PiA+PiA+Pj4gPj4g ZHluYW1pY2l0eQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhh dCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkDQo+PmlzDQo+PiAgPj4gPj5v dXRzaWRlDQo+PiAgPj4gPj4gPj4+b2YNCj4+ICA+PiA+PiA+Pj4gPj50aGUNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcg d2UgYXJlDQo+PiAgPj4gPj50YXNrZWQgdG8NCj4+ICA+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gID4+ ID4+ID4+PiA+PiA+Pm9uLg0KPj4gID4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0 aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGENCj4+ICA+PmNlcnRhaW4NCj4+ICA+ PiA+PiA+Pj53YXkuDQo+PiAgPj4gPj4gPj4+ID4+aXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4gaXMg anVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiAgPj4g Pj4gPj4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPj4gID4+ID4+ID4+PiA+ PiA+PiBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+IE9uIDcv MTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBG b3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPj5pbnN0YW5j ZXMNCj4+ICA+PiA+PiB0aGF0DQo+PiAgPj4gPj4gPj4+ID4+bmVlZHMNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+PnRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFu ZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseQ0KPj5ldmVuDQo+PiAgPj4gPj5hY3Jvc3MNCj4+ICA+ PiA+PiA+Pj5kYXRhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRt aW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlDQo+PmVub3VnaA0KPj4gID4+YW5kDQo+PiAgPj4g Pj4gPj4+IGNvbXBsZXgNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcg dG8gZ2V0IHRoYXQgaW50byBlYWNoIFNGRiBzZWVtcw0KPj5saWtlIGENCj4+ICA+PiA+PiA+Pj5k aWZmaWN1bHQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBJJ20gY3VyaW91cyBh cyB0byB3aHkgdGhhdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4NCj4+ICA+PmR5bmFtaWMNCj4+ ICA+PiA+PiA+Pj4gcm91dGluZywNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRh dGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mDQo+PiAgPj53aGljaA0KPj4g ID4+ID4+YXJlDQo+PiAgPj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBw cm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkNCj4+aW1wbGVtZW50 ZWQ/DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gSXQgYWxzbyBz ZWVtcyB0aGF0IGlmIGl0IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNhdGVkLA0KPj50aGF0DQo+PiAg Pj5pcw0KPj4gID4+ID4+YQ0KPj4gID4+ID4+ID4+Pmdvb2QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9l bGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1pa2Vi aWFuY0Bhb2wuY29tDQo+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+ICA+Pklhbg0K Pj4gID4+ID4+ID4+PlNtaXRoOw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+ICA+PkJhbGFuY2Vycw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0 ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQNCj4+ICA+PnByZWZlcg0KPj4gID4+ ID4+d2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gID4+ ID4+aW1wbGVtZW50YXRpb25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2Vz IGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+ICA+PiA+PnJlcXVpcmVtZW50 cw0KPj4gID4+ID4+ID4+PmFuZA0KPj4gID4+ID4+ID4+PiA+PiB0aGUNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAg Pj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQg c2VydmljZQ0KPj5pbnN0YW5jZXMNCj4+ICA+PiA+PnRoYXQNCj4+ICA+PiA+PiA+Pj4gbmVlZHMN Cj4+ICA+PiA+PiA+Pj4gPj4gdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0 cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gID4+IGFjcm9zcw0K Pj4gID4+ID4+ID4+PmRhdGENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFu IGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZQ0KPj5lbm91Z2gNCj4+ICA+PmFuZA0KPj4g ID4+ID4+ID4+PmNvbXBsZXgNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWlu ZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+Pmxpa2UgYQ0KPj4gID4+ID4+ID4+ PmRpZmZpY3VsdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUu DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiAg Pj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdy b3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUu IElzIHRoZSBlbmQgdG8gZW5kDQo+PiAgPj5zZWxlY3Rpb24NCj4+ICA+PiA+Pm9mDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkg KHBlcmhhcHMNCj4+YnkgdGhlDQo+PiAgPj4gPj4gPj4+ID4+Y2xhc3NpZmllcikNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFu ZA0KPj5zdWJzZXF1ZW50bHkNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PlNGRnMpPw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRv IHJlY2xhc3NpZmljYXRpb24uDQo+PiAgPj5BbmQNCj4+ICA+PiA+PiA+Pj5zdXJlbHksDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3Qg cmVsZWdhdGVkIHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlz IHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiAgPj4gdGhvdWdoDQo+ PiAgPj4gPj4gYQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEg KGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+PiAgPj5sb2NhbA0KPj4gID4+ID4+ID4+ PiA+PnNlbGVjdGlvbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQg YXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24NCj4+cG9pbnRzLg0KPj4gID4+ID4+VGhpcw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRv LWVuZCBwYXRoIGlkIGF0DQo+PmFsbC4NCj4+ICA+PiA+Pk15DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseQ0KPj5k cml2ZW4NCj4+ICA+PmJ5DQo+PiAgPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0 aCBhDQo+PiAgPj5nbG9iYWwNCj4+ICA+PiA+PiA+Pj5wYXRoDQo+PiAgPj4gPj4gPj4+ID4+aWQN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBp bnN0YW5jZSBhbmQNCj4+bmVlZGluZyB0bw0KPj4gID4+ID4+YWx0ZXINCj4+ICA+PiA+PiA+Pj50 aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBh bmQgZXZlcnkgYWZmZWN0ZWQNCj4+ICA+PmVuZC10by1lbmQNCj4+ICA+PiA+PiA+Pj5wYXRoLg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtz ZmMtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0NCj4+IG9u IGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gW2pt aC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsDQo+PiAgPj4yMDE0DQo+PiAgPj4gPj4g NjoxNQ0KPj4gID4+ID4+ID4+PiBQTQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlh bmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+IEkuU21pdGhARjUuY29t IDxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmcNCj4+PG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+PiAgPj4gU3ViamVjdDoNCj4+ICA+PiA+PiBSZToNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJj aGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjENCj4+bmVlZGluZw0KPj4gID4+dG8NCj4+ ICA+PiA+PiA+Pj4gPj5pbmZsdWVuY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4g aXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdA0KPj50aGUNCj4+ICA+PmV4 aXQNCj4+ICA+PiA+PmZyb20NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRv IGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4+ICA+PiA+PmxvZ2ljYWxseQ0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRl c2NyaWJlIGhvdw0KPj50aGV5DQo+PiAgPj4gPj4gY2hvb3NlDQo+PiAgPj4gPj4gPj4+dG8NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2Vs DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0 LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbQ0KPj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4gd3JvdGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGlu IHRoZSBhcmNoIGRyYWZ0IHRoYXQNCj4+c3VnZ2VzdHMgYW55DQo+PiAgPj4gPj5zb3J0DQo+PiAg Pj4gPj4gPj4+b2YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRv ZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KPj5lbnRpcmUNCj4+ICA+PiA+PnBhdGgNCj4+ ICA+PiA+PiA+Pj4oYWxsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hv c2VuIGF0IFNGQyBpbnN0YW50aWF0aW9uLiBJIGJlbGlldmUNCj4+ICA+PnRoaXMNCj4+ICA+PiA+ PiA+Pj5tZWFucw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBlaXRoZXIgYXQgdGhlIGNsYXNzaWZp ZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXINCj4+ICA+PmNob29zZXMgYQ0KPj4gID4+ID4+U0YN Cj4+ICA+PiA+PiA+Pj4gPj5DaGFpbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5G IG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55DQo+PmNhc2UsDQo+PiAgPj4g Pj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hp Yml0IGEgbW9yZSBkeW5hbWljIFNGUA0KPj53aGVyZQ0KPj4gID4+ID4+IFNGSShuKQ0KPj4gID4+ ID4+ID4+PiBpcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXRlcm1pbmVkIGF0IHRoZSBTRkko bi0xKSBob3AuIEFjY29yZGluZyB0byB0aGUNCj4+ZHJhZnQsDQo+PiAgPj4gPj50aGlzDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGlu ZyIgdG8gYSBuZXcNCj4+U0ZQIGFzDQo+PiAgPj4gPj4gPj4+IG9wcG9zZWQNCj4+ICA+PiA+PiA+ Pj4gPj4gdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2Fy ZGluZyB0byB0aGUgc2VsZWN0ZWQNCj4+aW5zdGFuY2Ugb2YNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJj aGl0ZWN0dXJlLTAwOg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5z dGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ICA+PiA+Pm5lY2Vzc2FyeQ0KPj4g ID4+ID4+ID4+PnRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmlj IGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlDQo+PnVzZWQsDQo+PiAgPj4gPj5hbmQgdG8N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3Ig dGhhdCBTRkMgdXNpbmcgU0Yncw0KPj4gID4+ID4+bmV0d29yaw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4gbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4N Cj4+dGhlDQo+PiAgPj4gPj4gPj4+Y3JlYXRpb24NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9m IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4gID4+ID4+ Zm9yd2FyZGluZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBT RkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMNCj4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBw b3J0cyByZWNsYXNzaWZpY2F0aW9uIChvcg0KPj4gID4+ID4+bm9uLWluaXRpYWwNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZl cnNlIGFuDQo+PlNGUCwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24g bWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZA0KPj5ieSBhDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2Vydmlj ZQ0KPj4gID4+ID4+ZnVuY3Rpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBSZWNsYXNzaWZp Y2F0aW9uIG1heSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhDQo+Pm5ldw0KPj4gID4+ID4+ U0ZQLCBhbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVk IG1ldGFkYXRhLCBvciBib3RoLiBUaGlzIGlzDQo+PiAgPj4gPj5yZWZlcnJlZA0KPj4gID4+ID4+ ID4+PnRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+ PiA+Pj4NCj4+ICA+PiA+Pg0KPj4gID4+DQo+PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4tLQ0KPj4gID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ICA+PiA+Pj4+Pj4+Pj4+Pj4t LS0NCj4+ICA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ICA+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ ICpGcm9tOiAqSS5TbWl0aEBGNS5jb20NCj4+IDxtYWlsdG86KkkuU21pdGhARjUuY29tPjxJLlNt aXRoQEY1LmNvbSA8bWFpbHRvOkkuU21pdGhARjUuY29tPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+PiAgPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tDQo+PiA8bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPj4g ID4+ID4+IE0uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+DQo+PiAg Pj4gPj4gPj4+DQo+PiAgPj4gPj4NCj4+ICA+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJu LmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4saHVhbmdAc2NlLmNhcmxldG9u LmNhDQo+PiA8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVhbmdAc2NlLg0KPj4gPG1h aWx0bzpodWFuZ0BzY2UuJTBiPj4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5v cmcNCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZA0KPj4gID4+ID4+QmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJp bGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj4gID4+dGhhdCBpcw0KPj4g ID4+ID4+ID4+PndoYXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBp cyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgDQo+PmlzDQo+PiAgPj4gPj4gPj4+cHJl Y29uY2VpdmVkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVu IHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgDQo+PndpdGgNCj4+ICA+PiB0aGF0DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwg c29tZSBkZWdyZWUgb2YNCj4+ICA+PiA+PmFzcGlyYXRpb24NCj4+ICA+PiA+PiB0bw0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNw YW4gb2YgdGhlDQo+PiAgPj4gPj5hcmNoaXRlY3R1cmUNCj4+ICA+PiA+PiA+Pj4tDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5 IHNheWluZyANCj4+dGhhdCBhbg0KPj4gID4+ID4+ID4+PmFyYml0cmFyeQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlm IGl0IA0KPj5pc24ndA0KPj4gID4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSAN Cj4+bGFzdGluZw0KPj4gID4+ID4+aW1wYWN0cw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWdh cmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksDQo+PiAgPj4g Pj5hZGRyZXNzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0 aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSANCj4+bm90DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxw ZXJuIERpcmVjdA0KPj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oLmRp cmVjdEBqb2VsaGFscGVybi5jb20+XQ0KPj4gID4+ID4+U2VudDoNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2Vs IA0KPj5NLg0KPj4gID4+ID4+IEhhbHBlcm47DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5n QHNjZS5jYXJsZXRvbi5jYQ0KPj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBzZmNA aWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW3NmY10NCj4+ ICA+PiA+PlNlcnZpY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4g DQo+PnRoaXMNCj4+ICA+PiA+PnJlZ2FyZC4NCj4+ICA+PiA+PiA+Pj5JDQo+PiAgPj4gPj4gPj4+ ID4+YW0NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNo aXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uDQo+PiAgPj4gPj5wcm9oaWJpdA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmpl Y3RpbmcgDQo+PnRvDQo+PiAgPj4gPj5IdWFuZydzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJl YWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIA0KPj5hcmUN Cj4+ICA+PiA+PiByZXF1aXJlZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBh cmNodGllY3R1cmUuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byANCj4+cHJv aGliaXQNCj4+ICA+PnN1Y2gNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVy IHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIA0KPj51cG9uDQo+PiAgPj4gPj4g bWFueQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3Bl IG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8NCj4+ICA+PnRoaW5rDQo+PiAgPj4gPj50aGF0DQo+PiAg Pj4gPj4gPj4+ID4+dGhleQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJh ZCBpZGVhLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBC dXQgdGhlIGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgDQo+PmF0dGVtcHRpbmcg dG8NCj4+ICA+PiA+Pmtub3cNCj4+ICA+PiA+PiA+Pj53aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3Jv dGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRl ZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UgDQo+PnRlbnMgb2YNCj4+ICA+PiA+PiA+Pj5taWxsaW9u cw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29u Y3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIA0KPj5jZW50ZXIN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2Vy aW91c2x5IGJlbGlldmUgDQo+PnRoYXQgaW4NCj4+ICA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91 DQo+PiAgPj4gYXJlDQo+PiAgPj4gPj4gb25seQ0KPj4gID4+ID4+ID4+PiA+PiBnb2luZw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFp bnMgd2l0aCBlcXVhbGx5DQo+PiAgPj5zbWFsbA0KPj4gID4+ID4+ID4+PiBudW1iZXJzDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNo IGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCANCj4+bW9yZQ0KPj4gID4+IHRoYW4NCj4+ICA+ PiA+PiA+Pj4gNjRLIg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBb c2ZjLWJvdW5jZXNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBv biBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhA am9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0K Pj4gID4+ID4+ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYSA8bWFpbHRvOmh1YW5nQHNjZS5jYXJs ZXRvbi5jYT47DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0KPj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhz LA0KPj4gID4+YW5kDQo+PiAgPj4gPj4gPj4+TG9hZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4g QmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IA0KPj50 aGUNCj4+ICA+PiA+PiA+Pj5hcmNodGlldHVyZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFy dGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4+ICA+PnRo ZWlyDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRv ZXMgbm90IHJlcXVpcmUgc3VjaCANCj4+YWJzdXJkDQo+PiAgPj4gdXNlDQo+PiAgPj4gPj4gb2YN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBm aWd1cmUgb3V0IGhvdyB0byANCj4+d3JpdGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hp dGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSANCj4+YXJjaGl0ZWN0dXJlDQo+PiAg Pj5kb2VzDQo+PiAgPj4gPj4gPj4+cGVybWl0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNo IGFidXNlLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiAg Pj4gcGVybWl0cw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBp dCBpcyBlaXRoZXIgZGVpc3JlZCBvciANCj4+cmVxdWlyZWQgYnkNCj4+ICA+PiA+PnRoZQ0KPj4g ID4+ID4+ID4+PndvcmsuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAv MTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGwN Cj4+ICA+Pm1lYW4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBU aGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nDQo+PiAgPj50YWJsZQ0KPj4gID4+ID4+b2Yg YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUg UE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhl IGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgDQo+PmZyb20NCj4+ ICA+PjENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBz ZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIA0KPj5ob3BlDQo+PiAgPj50aGF0DQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMg aWYgDQo+PnRoZXkNCj4+ICA+PiA+PmNob29zZQ0KPj4gID4+ID4+ID4+PnRvDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5k IGluIA0KPj5zdGVhZA0KPj4gID4+ID4+IHByb3Zpc2lvbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5B UElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWws DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g SG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgDQo+PmhvcA0K Pj4gID4+ID4+IHNlcnZpY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGgg MjAgaW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSAqT24gDQo+PkJlaGFsZg0KPj4gID4+IE9mDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAs IA0KPj4yMDE0DQo+PiAgPj4gPj4zOjAzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAq VG86KiBMdWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPjsNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT47IHNmY0BpZXRmLm9yZyANCj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4NCj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4+ICA+PiBDaGFpbnMsDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVy YWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIA0KPj50aGUNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gbWFrZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTog dGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgDQo+PnVzZWQgdG8NCj4+ICA+PiA+PiBkZXJpdmUN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNz b2NpYXRlZCB0cmFuc3BvcnQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBp cyB1c2VkIHRvDQo+PiAgPj5zaW1wbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50 aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IA0KPj5wYWNrZXRzDQo+PiAgPj5t dXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0 aCBpZGVudGlmaWVyLCB0aGUgZXhhY3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGly ZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbg0KPj4gID4+dGhpcw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVt ZW50ZWQuIFRoZSBwYXRoDQo+PiAgPj4gPj4gaWRlbnRpZmllcg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgDQo+Pmxv b2t1cCBjYW4NCj4+ICA+PiA+PiByZXN1bHQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu IGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgDQo+Pm5leHQNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAx MTowNCBBTSwgTHVjeSB5b25nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25n QGh1YXdlaS5jb20gDQo+PjxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+DQo+PiAgPj4gPj4g PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNv bSUzZT4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4g ZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IA0KPj51c2Ugb2YNCj4+ICA+PiB0aGUNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRo ZSBmb3J3YXJkaW5nDQo+PiAgPj4gPj5hY3Rpb25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddKk9uIA0KPj5CZWhhbGYNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86T2YqbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ICA+PiA+PiA+Pj4gKlNlbnQ6KlRo dXJzZGF5LA0KPj4gID4+ID4+ID4+PiA+PiBKdWx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb20NCj4+IDxtYWlsdG86Km1p a2ViaWFuY0Bhb2wuY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtl YmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzptaWtlYmlhbmNA YW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1YmplY3Q6KlJlOiBbc2ZjXSANCj4+U2Vy dmljZQ0KPj4gID4+ID4+Q2hhaW5zLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNp dGx5IGEgc2VydmljZSANCj4+cGF0aA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRp Zmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPj4gID4+ZGVyaXZlDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEg U0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIA0KPj5rbm93bGVkZ2Ugb2YNCj4+ICA+PiA+PiBl dmVyeQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21h aW4gDQo+PmlzIG5vdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxv eW1lbnQgY29udGV4dHMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUg cGllY2UgDQo+Pm9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0IHdpbGwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+ICA+PiBy ZXF1aXJlZA0KPj4gID4+ID4+IHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1 cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiANCj4+aXMNCj4+ICA+PiA+ PnVzZWQgdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aXMgYSBzb2x1dGlvbi1vcmllbnRlZCBkaXNjdXNzaW9uLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGEgDQo+PnBhcnQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzpkZSptaWtlYmlhbmNAYW9sLmNv bT4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPj4gID4+ID4+IGp1aWxsZXQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1h aWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA8bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiAg Pj4gPj5DaGFpbnMsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQg QmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIA0KPj5i ZXR3ZWVuDQo+PiAgPj5TRg0KPj4gID4+ID4+IENoYWluDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhbmQgU0YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0 IA0KPj5pdCdzDQo+PiAgPj4gPj5jbGVhciB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9z ZSBub3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0 LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lDQo+PiAgPj5hZ3JlZXMNCj4+ICA+PiA+Pm9uDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0 aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+ICA+PndoZXRoZXINCj4+ICA+PiA+Pml0IGlzDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0 aW1hdGVseSBzcGVjaWZ5IA0KPj53aGF0DQo+PiAgPj4gPj50aGUgSUQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNo b3VsZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3Ig dGhlIHBhdGgpLCBvciBpZiB0aGlzIA0KPj5kcmFmdA0KPj4gID4+ID4+c2ltcGx5DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxv d2luZyBvdGhlcg0KPj4gID4+ZHJhZnRzDQo+PiAgPj4gPj50bw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiAN Cj4+Y2hhaW4NCj4+ICA+PiBvcg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQg dGhlIGNob2ljZSBvZiBjaGFpbiBvcg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBs YW5lLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIA0KPj5o YXZlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5k IFNGQyBiZSBzdXBwb3J0ZWQgKG9yIA0KPj5tYWtlDQo+PiAgPj4gPj4gb25lDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9p ZCBzb21lDQo+PiAgPj4gdmVuZG9ycw0KPj4gID4+ID4+IG9ubHkNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+Pg0KPj4gID4+ID4+ID4+Pg0K Pj4gID4+ID4+DQo+PiAgPj4NCj4+ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pi0tDQo+PiAgPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4g ID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4tLQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4g PG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ICA+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29t Pg0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUz ZT4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZw0KPj4gPG1h aWx0bzoqc2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRm Lm9yZz4NCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4+ICA+ PiAqU2VudDoqVHVlc2RheSwNCj4+ICA+PiA+PiBKdWx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIA0KPj5h bmQNCj4+ICA+PkxvYWQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2 ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+PiAgPj5hbnN3ZXIN Cj4+ICA+PiA+PmENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50 cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPj4gID4+ID4+ID4+PiBwcm9wb3NlZA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNz dW1pbmcgd2UgY2FuIGdldA0KPj4gID4+IHdvcmtpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+ICA+ PiBpbXByb3ZlDQo+PiAgPj4gPj4gdGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3Jk aW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgDQo+PnBhcnRpY2lwYXRlZCBpbg0KPj4g ID4+ID4+dGhlDQo+PiAgPj4gPj4gV0cNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1 c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gd29ya2luZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQg d2hhdCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4gID4+ID4+cGVy c29uYWwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBo ZWxwcy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCANCj4+ dGhhdA0KPj4gID4+ID4+d2hhdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRl ZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gDQo+PldlDQo+PiAgPj5hcmUN Cj4+ICA+PiA+PiBub3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8g ZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSANCj4+ZW50aXJlDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCAN Cj4+ZW5jb21wYXNzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3Vz IGNvbnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsDQo+PiAgPj52aXJ0dWFsDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBv dGhlcg0KPj4gID4+ID4+IGFzcGVjdHMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdz IHdoaWNoIGNsZWFybHkgDQo+Pm5lZWQNCj4+ICA+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZXhpc3QgaW4gdGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgDQo+ PndpdGgNCj4+ICA+PiA+PmFib3ZlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3 ZSBhcmUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3 ZSBhcmUNCj4+ICA+PiBkb2luZy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBz ZXJ2aWNlIA0KPj5wYXRoLA0KPj4gID4+YXMgSQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dW5kZXJzdGFuZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJl IA0KPj5hcmUgYXQNCj4+ICA+PiA+PmxlYXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQNCj4+ICA+Pndp bGwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFp bmluZy4gVGhlcmUgcHJvYmFibHkgDQo+PmFyZQ0KPj4gID4+ID4+bW9yZS4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1p dCBhbGwgDQo+Pm9mDQo+PiAgPj4gPj50aGVzZSwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNv bHV0aW9uLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgDQo+ PmVuZA0KPj4gID4+ID4+dXNlci4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMg YSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+PiAgPj5wYWNrZXRzLA0KPj4g ID4+ID4+YW5kDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBtYXJrcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgDQo+PnNlcnZpY2UNCj4+ ICA+PiA+Pmluc3RhbmNlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRo ZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4gDQo+PmltcG9ydGFudA0KPj4gID4+ID4+c2Vydmlj ZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNs dWRlIGluIHNlcnZpY2UgDQo+PmNoYWluaW5nLg0KPj4gID4+ID4+SXQncw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNl cnZpY2UNCj4+ICA+PiA+PiBjaGFpbmluZyBpcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiAgPj4gPj5hcmNo dGllY3R1cmUuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVy YWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseSANCj4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBzZXJ2aWNlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkg bW9kaWZ5IHRoZSB1bmRlcmx5aW5nIHBhY2tldC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJh bGFuY2luZy4gVGhhdCBpcywgDQo+Pm9uZQ0KPj4gID4+Y2FuDQo+PiAgPj4gPj5oYXZlDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVh cnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFy Y2hpdGVjdHVyZSBhcyBhIHNpbmdsZQ0KPj4gID4+cG9pbnQNCj4+ICA+PiA+Pm9mDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb250YWN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBh DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBi dXQgaXMgYWN0dWFsbHkgDQo+PmRlbGl2ZXJlZA0KPj4gID4+ID4+YnkgYQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXJ0 dWFsIG9yIHBoeXNpY2FsIG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcNCj4+ICA+Pm9uZSBv cg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9y IGV4YW1wbGUgdXNpbmcgDQo+PlZSUlAtbGlrZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCANCj4+dGhpcyBpcw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIGRhdGEgcGxhbmUNCj4+ICA+PiA+Pm1lY2hhbmlzbXMuDQo+PiAgPj4gPj4gSXQNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFy aW91cyBjb250cm9sDQo+PiAgPj4gPj5tZWNoYW5pc21zLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIA0KPj5zY2FsZS1v dXQsDQo+PiAgPj5hbmQNCj4+ICA+PiA+PnZtDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBp bnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4+ICA+PnBlcm1pdHRp bmcNCj4+ICA+PiA+PnRoaXMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkg dGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+ICA+PiA+PnRlcm1pbm9sb2d5 DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdl IGFyZSBwcm9oaWJpdGluZyBpdC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBk b25lIGJ5DQo+PiAgPj5zZWxlY3RpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tl dCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCANCj4+ZGlyZWN0DQo+PiAgPj4g Pj50cmFmZmljDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2Vz LiBXZSB3b3VsZCBub3Qgd2FudCB0byANCj4+cmVxdWlyZQ0KPj4gID4+IHRoYXQNCj4+ICA+PiA+ PmENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBw ZWFyIGF0IG9ubHkgb25lIHBsYWNlIA0KPj5pbg0KPj4gID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1h eSBiZQ0KPj4gID4+Y29tYmluZWQuIEkNCj4+ICA+PiA+PiB0ZW5kDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIg dG8gDQo+PnNlcnZpY2UNCj4+ICA+PiA+PmNoYWluaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIA0KPj5jbHVz dGVyDQo+PiAgPj5pcw0KPj4gID4+ID4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29v ZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgDQo+Pm9uZS4NCj4+ICA+ PiBUaHVzLA0KPj4gID4+ID4+IHRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9pbnQg b2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJh ZmZpYyB0byBkaWZmZXJlbnQNCj4+ICA+PiA+PnNpbmd1bGFyDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IA0KPj5w bGFjZXMNCj4+ICA+PmluDQo+PiAgPj4gPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG5ldHdvcmsuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayAN Cj4+YWJvdXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNl cnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiANCj4+aXMgYQ0KPj4gID4+ID4+IHNlcXVlbmNlDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBs aWVkIHRvIGEgc3Vic2V0IA0KPj5vZg0KPj4gID4+ID4+cGFja2V0cy4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQg b2YNCj4+ICA+PnRyYWZmaWMNCj4+ICA+PiA+PmlzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQNCj4+ICA+PmZp cmV3YWxsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJz ZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gDQo+PnRoZQ0KPj4gID4+Y2FjaGUNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gd2l0aG91dA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcg YW55IG90aGVyIHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlv biB0byBkaXJlY3QgdGhlDQo+PiAgPj5wYWNrZXRzLg0KPj4gID4+IEENCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNl IG9mDQo+PiAgPj4gPj5sb2NhdGlvbnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRo ZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSANCj4+c2luZ3VsYXIgb3INCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5 IGxvY2F0aW9ucy4gDQo+PlRoZXkNCj4+ICA+PiA+Pm1heSBiZQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCAN Cj4+YXMNCj4+ICA+PiBwb3J0cw0KPj4gID4+ID4+IG9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+PiAg Pj4gPj5sb2NhdGlvbnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0 byB0aGUgc2VydmljZSBjaGFpbmluZyANCj4+aW5mcmFzdHJ1Y3R1cmUNCj4+ICA+PiBhbmQNCj4+ ICA+PiA+PiB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gRnJvbSB0 aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDDQo+PiAgPj5ncm91cCwNCj4+ ICA+PiA+PiB3ZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBh YnN0cmFjdGlvbiwgDQo+PnRoZQ0KPj4gID4+ID4+c2VydmljZQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQg DQo+PnRvDQo+PiAgPj4gdGFsaw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhl IGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4gDQo+PnRoZQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNh aWQgImJ1dCB0aGUgd2hvbGUNCj4+ICA+PiBwYXRoDQo+PiAgPj4gPj4gbWF5DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRl Y3R1cmUgDQo+PmRlYWxzDQo+PiAgPj4gPj53aXRoDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSANCj4+KDIp DQo+PiAgPj5vbg0KPj4gID4+ID4+bG9hZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFs YW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZA0KPj4gID4+YmVoYXZpb3Jz DQo+PiAgPj4gPj4gd2hpY2gNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2li bGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgDQo+Pm1lY2hhbmlzbXMgKGluDQo+PiAgPj4gPj5t dWNoDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2lu ZyB3aXRoaW4gYSBMQU4gaXMgDQo+PmxhcmdlbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gID4+IHBy b3Zpc2lvbg0KPj4gID4+ID4+IHdlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlz DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4+ICA+PiA+ PiBuZWNlc3NhcnkuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0 IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIA0KPj5vbg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0K Pj4gID4+cG9pbnQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIA0K Pj5hZnRlci4NCj4+ICA+PklmIGl0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBh bmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSANCj4+d29ya2luZw0KPj4gID4+ ID4+IGdyb3VwLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQg d2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSANCj4+bmVlZGVkDQo+PiAgPj4gdG8NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNh Z3JlZSB3aXRoIA0KPj50aGUNCj4+ICA+PiA+PiBpbnRlbnQsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgDQo+Pndv cmtpbmcNCj4+ICA+PiA+Pmdyb3VwDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZ3JlZW1l bnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IA0KPj5zdXJlDQo+PiAgPj4g Pj53aGF0IHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9l bA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ICA+PiA+PiBzZmMNCj4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+IHNmYw0KPj4gID4+ID4+ ID4+PiA+PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiBzZmMNCj4+ICA+PiA+ PiA+Pj4gPj4gbWFpbGluZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+IHNmYw0KPj4gID4+ID4+ ID4+PiA+PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiBzZmMNCj4+ICA+PiA+PiA+Pj4g bWFpbGluZw0KPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiAgPj4gPj4gPj4+IG1haWxpbmcN Cj4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ PiAgPj4gPj4gbWFpbGluZw0KPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHNmYw0KPj4gID4+ID4+IG1haWxpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiAgPj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g ID4+ID4+ID4+PiA+PiA+Pg0KPj4gID4+ID4+ID4+PiA+PiA+DQo+PiAgPj4gPj4gPj4+ID4+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+ ID4+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ID4+ID4+PiA+PiA+c2ZjQGlldGYub3Jn IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+ Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ICA+PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ID4+ID4+PiA+PiBzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+DQo+PiAgPj4gPj4g Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAg Pj4gPj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ICA+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4NCj4+ICA+PiA+PiA+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiA+c2ZjIG1haWxp bmcgbGlzdA0KPj4gID4+ID4+ID5zZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiAgPj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAg Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCg0K From nobody Mon Jul 14 08:19:45 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E341A0A89 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 W5tOTehvGwGD for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:19:31 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C675E1A0A82 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:19:31 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 5FBB753E2C; Mon, 14 Jul 2014 08:19:26 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 08:19:26.322 -0700 x-echoworx-msg-id: 847bbca5-d86a-4d2b-b8e2-0812a909672c x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 896; Mon, 14 Jul 2014 08:19:26 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 3471753E2C; Mon, 14 Jul 2014 08:19:26 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 08:19:31 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2fdGB3ecdgo20an/XQiFB0eg5ugGT2A//+MLWCAAH0cgP//iwdg Date: Mon, 14 Jul 2014 15:19:30 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> In-Reply-To: <CFE96A4C.2E4AC%jguichar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZJBjPT8pg7HbnQP8eQOeMuTDN3A Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:19:38 -0000 SmltLA0KDQpJIGFtIG5vdCB3b3Jkc21pdGhpbmcgaGVyZSwgYnV0IHJhdGhlciBxdWVzdGlvbmlu ZyBzb21lIGZ1bmRhbWVudGFsIGFzc3VtcHRpb25zLg0KDQpUaGUgdmVyeSBleGlzdGVuY2Ugb2Yg dGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBjb25jZXB0IGlzIGZ1bmRhbWVudGFsIHRvIHRoZSBh cmNoaXRlY3R1cmUuICAgIEFzIGFuIGFuYWxvZ3ksIGluIGEgdHJhZGl0aW9uYWwgTDMgcm91dGVk IG5ldHdvcmsgKGV4Y2VwdGluZyBvYnNjdXJlIHNvdXJjZSByb3V0aW5nIG9wdGlvbnMpLCBvbmUg Y291bGQgc3RpbGwgb2JzZXJ2ZSB0aGF0IGEgcGFydGljdWxhciBmbG93IGlzIGZvbGxvd2luZyBh IHBhcnRpY3VsYXIgcGF0aCB0aHJvdWdoIHRoZSBuZXR3b3JrLCBidXQgdGhhdCBpcyBpbmNpZGVu dGFsIHRvIHRoZSBhcmNoaXRlY3R1cmUgcmF0aGVyIHRoYW4gZnVuZGFtZW50YWwgdG8gdGhlIGFy Y2hpdGVjdHVyZS4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXSAN ClNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAxMToxMiBBTQ0KVG86IFJvbiBQYXJrZXI7IEpv ZWwgSGFscGVybiBEaXJlY3Q7IEx1Y3kgeW9uZzsgTkFQSUVSQUxBLCBNQVJJQSBIOyBYdXhpYW9o dTsgbWlrZWJpYW5jQGFvbC5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGptaEBq b2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFJlZGVmaW5l IHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K DQpRdWVzdGlvbjogd2hlcmUgZXhhY3RseSBkb2VzIGl0IHNwZWNpZnkgdGhhdCB0aGUgU0ZQICpt dXN0KiBiZQ0KcHJlLWluc3RhbnRpYXRlZD8gV2hhdCBleGFjdGx5IGlzIHdyb25nIHdpdGggdGhl IHdvcmRpbmcg4oCcV2hlbiBhbiBTRkMgaXMNCmluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3Jr IGl0IGlzIG5lY2Vzc2FyeSB0byBzZWxlY3QgdGhlIHNwZWNpZmljDQppbnN0YW5jZXMgb2YgU0Zz IHRoYXQgd2lsbCBiZSB1c2VkLCBhbmQgdG8gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZv cg0KdGhhdCBTRkMgdXNpbmcgU0bigJlzIG5ldHdvcmsgbG9jYXRvcnPigJ0/IExldOKAmXMgdHJ5 IHRvIGJlIHNwZWNpZmljIHJhdGhlcg0KdGhhbiBkYW5jaW5nIGFyb3VuZCB0aGUgd29yZGluZy4N Cg0KT24gNy8xNC8xNCwgMTE6MDAgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCj5IaSwgSm9lbCwNCj4NCj5JIHF1b3RlIGZyb20gdGhl IHRoZSBtZXJnZWQgYXJjaGl0ZWN0dXJlIGRyYWZ0Og0KPg0KPjxiZWdpbiBxdW90YXRpb24+DQo+ U2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKTogIEEgc2VydmljZSBGdW5jdGlvbiBjaGFpbiBk ZWZpbmVzIGFuDQo+ICAgICAgICBvcmRlcmVkIHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0 IG11c3QgYmUgYXBwbGllZCB0byBwYWNrZXRzDQo+ICAgICAgICBhbmQvb3IgZnJhbWVzIHNlbGVj dGVkIGFzIGEgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9uLiAgVGhlDQo+ICAgICAgICBpbXBsaWVk IG9yZGVyIG1heSBub3QgYmUgYSBsaW5lYXIgcHJvZ3Jlc3Npb24gYXMgdGhlDQo+ICAgICAgICBh cmNoaXRlY3R1cmUgYWxsb3dzIGZvciBub2RlcyB0aGF0IGNvcHkgdG8gbW9yZSB0aGFuIG9uZSBi cmFuY2guDQo+ICAgICAgICBUaGUgdGVybSBzZXJ2aWNlIGNoYWluIGlzIG9mdGVuIHVzZWQgYXMg c2hvcnRoYW5kIGZvciBzZXJ2aWNlDQo+ICAgICAgICBmdW5jdGlvbiBjaGFpbi4NCj4NCj4gICBT ZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCk6ICBUaGUgaW5zdGFudGlhdGlvbiBvZiBhbiBTRkMg aW4gdGhlDQo+ICAgICAgICBuZXR3b3JrLiAgUGFja2V0cyBmb2xsb3cgYSBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGggZnJvbSBhDQo+ICAgICAgICBjbGFzc2lmaWVyIHRocm91Z2ggdGhlIHJlcXVpc2l0 ZSBzZXJ2aWNlIGZ1bmN0aW9ucw0KPg0KPldoZW4gYW4gU0ZDIGlzIGluc3RhbnRpYXRlZCBpbnRv IHRoZSBuZXR3b3JrIGl0IGlzIG5lY2Vzc2FyeSB0bw0KPiAgIHNlbGVjdCB0aGUgc3BlY2lmaWMg aW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZQ0KPiAgIHRo ZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcmsgbG9jYXRv ci4gIFRodXMsDQo+ICAgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlIGNy ZWF0aW9uIG9mIGEgU2VydmljZQ0KPiAgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBm b3IgZm9yd2FyZGluZyBwYWNrZXRzIHRocm91Z2ggdGhlDQo+ICAgU0ZDLiAgSW4gb3RoZXIgd29y ZHMsIGFuIFNGUCBpcyB0aGUgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+DQo+ KFNlY3Rpb24gNC4zIFNGRikNCj5TRlAgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpcyBhc3NvY2lh dGVkIHdpdGggYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KPiAgIHRoYXQgaXMgdXNlZCB0byB1 bmlxdWVseSBpZGVudGlmeSBhbiBTRlAuDQo+PGVuZCBxdW90YXRpb24+DQo+DQo+DQo+TXkgcmVh ZGluZyBvZiB0aGUgU2VjdGlvbiA0LjMsIGdpdmVuIHRoZSBkZWZpbml0aW9ucyBwcmVzZW50ZWQg YmVmb3JlIGl0LA0KPmlzIHRoYXQgYW4gZW5kLXRvLWVuZCBmdWxseSBpbnN0YW50aWF0ZWQgcGF0 aCBpcyBzZWxlY3RlZCBhbmQgdGhlbiB1c2VkDQo+dG8gc3RlZXIgdHJhZmZpYyB0byB0aGUgcmVx dWlzaXRlIFNGRidzIGFuZCBTRidzLiAgIFdoaWxlIHRob3NlDQo+ZGVmaW5pdGlvbnMgY291bGQg c3RpbGwgYXBwbHksIGV2ZW4gaW4gYSBkaXN0cmlidXRlZCBpbnN0YW5jZSBhc3NpZ25tZW50DQo+ YXBwcm9hY2gsIHRoZSBjb250ZXh0IGFyb3VuZCB0aG9zZSBkZWZpbml0aW9ucyBjaGFuZ2UuICAg QSBwYXJ0aWN1bGFyDQo+ZmxvdyB3b3VsZCwgaW5kZWVkIHN0aWxsIGZvbGxvdyBzb21lIHBhcnRp Y3VsYXIgcGF0aCwgYnV0IHRoZXJlIHdvdWxkIGJlDQo+bm8gbmVlZCB0byBhc3NvY2lhdGUgYSBw YXRoIElEIHRvIGl0IGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvDQo+KGxhdGVyKSBidWls ZCBhIGNvbnRyb2wgcGxhbmUgYXJvdW5kIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIHBhdGggSUQgYW5k DQo+bWFpbnRlbmFuY2Ugb2YgdGhvc2UgcGF0aCBJRHMgaW4gdGhlIGZhY2Ugb2YgaW5ldml0YWJs ZSBmYWlsdXJlcy4NCj4NCj5JIGFtIGV4cGxvcmluZyB0aGUgYWx0ZXJuYXRpdmUgd2hlcmUgZm9y d2FyZGluZyBpcyBwZXJmb3JtZWQgYmFzZWQgb24gdGhlDQo+YWJzdHJhY3QgU0ZDIElEIHdpdGhv dXQgcmVxdWlyaW5nIHRoZSBjb25jZXB0IG9mIGEgY2VudHJhbGx5IGtub3duIFNGUCB0bw0KPmV4 aXN0IGF0IGFsbC4gICBJbiB0aGlzIGFsdGVybmF0aXZlIGFwcHJvYWNoLCB0aGUgaW5zdGFuY2Ug c2VsZWN0aW9uIGlzDQo+ZGlzdHJpYnV0ZWQgdG8gdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkYn cy4gICBBbnkgZGVzaXJlZCBwb2xpY3kgdXNlZCB0bw0KPmZsYXZvciBpbnN0YW5jZSBzZWxlY3Rp b24gaXMgc3RpbGwgc3VwcG9ydGVkLCBidXQgc3VjaCBwb2xpY3kgd291bGQsDQo+aW5kZWVkLCBu ZWVkIHRvIGJlIGF2YWlsYWJsZSB0byB0aGUgaW52b2x2ZWQgZW50aXRpZXMuICAgVGhpcyB3b3Vs ZCBhbHNvDQo+YmUgYW4gZXhjZWxsZW50IHVzZSBvZiBtZXRhZGF0YSB3aGVyZSB0aGUgaW5pdGlh bCBpbmdyZXNzIG5vZGUgY291bGQgYWRkDQo+b25lIG9yIG1vcmUgcGllY2VzIG9mIG1ldGFkYXRh IHRoYXQgZG93bnN0cmVhbSBub2RlcyBjb3VsZCBtYWtlIHVzZSBvZiBpbg0KPnRoZWlyIHBvbGlj eSBkZWNpc2lvbnMuDQo+DQo+ICAgIFJvbg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+RnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbbWFpbHRvOmptaC5kaXJlY3RAam9lbGhh bHBlcm4uY29tXQ0KPlNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAxMDozOSBBTQ0KPlRvOiBM dWN5IHlvbmc7IE5BUElFUkFMQSwgTUFSSUEgSDsgUm9uIFBhcmtlcjsgWHV4aWFvaHU7DQo+bWlr ZWJpYW5jQGFvbC5jb207IGpndWljaGFyQGNpc2NvLmNvbTsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTsNCj5qbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBS ZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQNCj5CYWxhbmNlcnMNCj4NCj5DYW4gd2UgZmlyc3QgZmlndXJlIG91dCB3aGF0IHdlIG1l YW4gYnkgYSBzZXJ2aWNlIHBhdGg/DQo+T25jZSB3ZSBoYXZlIHRoYXQsIEkgYmVsaWV2ZSB3ZSBj YW4gd29yayBvdXQgd2hhdCB3ZSB3YW50IHRoZQ0KPmFyY2hpdGVjdHVyZSB0byByZXF1aXJlIG9m IHNvbHV0aW9ucyBpbiB0ZXJtcyBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiBpbg0KPnRoZSBwYWNr ZXQuICBCdXQgc2luY2UgZm9sa3MgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIGV4aXN0aW5nIGRlZmlu aXRpb25zDQo+YW5kIGNvbWluZyB0byBkaWZmZXJlbnQgbWVhbmluZ3MsIGFuZCBoYXZlIGJlZW4g bm90aW5nIGNvcnJlY3RseQ0KPmNvbnRyYWRpY3Rpb25zIGluIHRoZSB3b3JkcyB3ZSBjaG9zZSBm b3IgdGhlIGV4aXN0aW5nIGRlZmluaXRpb24sIEkNCj53b3VsZCByZWFsbHkgYXBwcmVjaWF0ZWQg aXQgaWYgZm9sa3Mgd291bGQgY29tbWVudCBvbiB0aGUgZGVmaW5pdGlvbiBvZg0KPnNlcnZpY2Ug ZnVuY3Rpb24gcGF0aCB0aGF0IEkgc2VudCB0byB0aGUgbGlzdC4NCj4NCj5Zb3VycywNCj5Kb2Vs DQo+DQo+T24gNy8xNC8xNCwgOTozMCBBTSwgTHVjeSB5b25nIHdyb3RlOg0KPj4gQ29ucXVlciB3 aGF0IE1hcmlhIHNheXMuDQo+Pg0KPj4gTHVjeQ0KPj4NCj4+ICpGcm9tOipzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqTkFQSUVSQUxBLA0KPj5NQVJJQSBI DQo+PiAqU2VudDoqIE1vbmRheSwgSnVseSAxNCwgMjAxNCA4OjIxIEFNDQo+PiAqVG86KiBSb24g UGFya2VyOyBYdXhpYW9odTsgbWlrZWJpYW5jQGFvbC5jb207IGpndWljaGFyQGNpc2NvLmNvbTsN Cj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGptaEBqb2VsaGFscGVybi5jb207IHNm Y0BpZXRmLm9yZw0KPj4gKlN1YmplY3Q6KiBSZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6 IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kDQo+PiBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IFRo ZSBtZWFuaW5nIG9mIHRoZSBTRlAgSUQgaXMgcHJldHR5IGNsZWFyLCBhdCBsZWFzdCB0byBtZSDi gJMgYW4gYWJzdHJhY3QNCj4+IGlkZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9mIHNlcnZpY2Ug ZnVuY3Rpb24gaW5zdGFuY2VzIChpLmUuLCBTRlAgSUQgMQ0KPj4gPSB7U0YtQS0xLCBTRi1CLTMs IFNGLUMtMn0pLiAgICBJbiBzb21lIHdheXMsIGl0IGlzIGEgY29sbGFwc2VkIOKAnGxhYmVsDQo+ PiBzdGFja+KAnSDigJMgdGhlcmUgaXMgYSBzaW5nbGUgdGFnIGltcGx5aW5nIHNvbWUgc2VxdWVu Y2Ugb2YgbmV0d29yaw0KPj4gbG9jYXRpb25zLiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0 IGxlYXN0IHRvIG1lLCB0aGF0IHRoZXJlIGlzIGENCj4+IGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0 aW9uIGZvciB0aGlzIGVuZCB0byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcNCj4+IHJlY2xhc3NpZmlj YXRpb24sIG9mIGNvdXJzZSkuICAgSSwgZm9yIG9uZSwgYW0gcXVlc3Rpb25pbmcgdGhhdA0KPj4g aW1wbGljYXRpb24uICAgIEkgaGF2ZSBiZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRy YWwgcG9pbnQNCj4+IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdvcmxkIGNvbXBsZXhpdGllcyBv ZiBkeW5hbWljIHNjYWxlIGFuZA0KPj4gdGltZWxpbmVzcyBvZiByZWFjdGlvbiB0byBmYWlsdXJl cy4NCj4+DQo+PiA8TWFyaWE+IEkgYWdyZWUuIEl0IHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgYnkg dGhlIFNGQyBhcmNoaXRlY3R1cmUgdGhhdA0KPj4gc29tZXRoaW5nIGNhbGxlZCDigJxzZXJ2aWNl IGZ1bmN0aW9uIHBhdGggSUTigJ0gaXMgY2FycmllZCBpbiB0aGUgcGFja2V0LA0KPj4gYmVjYXVz ZSBpdCBpcyBub3QgbmVjZXNzYXJ5IG9yIHRoZSBvbmx5IHdheSB0byBpbXBsZW1lbnQgc2Vydmlj ZQ0KPj4gY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxkIGRvIHRoYXQg YnV0IGl0IGNhbm5vdCBhbmQNCj4+IGRvZXNu4oCZdCBuZWVkIHRvIGJlIG1hbmRhdGVkLg0KPj4N Cj4+IE1hcmlhDQo+Pg0KPj4gQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNl IGNlbnRyYWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0aGUNCj4+IGNoYWluIG9mIGFic3RyYWN0IHNl cnZpY2UgZnVuY3Rpb25zIChpLmUuLCBTRkMgSUQgMSA9IHtTRi1BLCBTRi1CLA0KPj4gU0YtQ30p LCBidXQgYWxsb3cgdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0 ZWQsDQo+PiByZWFsaXplZCBieSB0aGUgY2xhc3NpZmllciBhbmQgdGhlIFNGRnMuDQo+Pg0KPj4g R2l2ZW4gYSB0b3BvbG9neSBsaWtlOg0KPj4NCj4+IENsYXNzaWZpZXIgLS0tLS0tLSAgU0ZGLTEg LS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTINCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0z LS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00DQo+Pg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgfA0KPj4gICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+Pg0KPj4gICAgICAgICAgICAgICAgICAgICAgU0ZGLUEtMSAgICAgICBTRkYtQS0y ICAgICAgIFNTRi1CLTENCj4+IFNGRi1CLTIgICAgICAgICBTRkYtQy0xICAgICAgIFNGRi1DLTIg ICAgICAgICAgICAgICAgICAgU0ZGLUEtMw0KPj4NCj4+IEFuZCBhc3N1bWluZyBhIG5ld2x5IHJl Y29nbml6ZWQgZmxvdywgdGhlIHNlcXVlbmNlIGNvdWxkIGdvIHNvbWV0aGluZw0KPj4gbGlrZSB0 aGlzOg0KPj4NCj4+IDEgQ2xhc3NpZmllciBzZWxlY3RzIGNoYWluIFNGQyBJRCAxIHtTRi1BLCBT Ri1CLCBTRi1DfQ0KPj4NCj4+IDIgQ2xhc3NpZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3Rpbmcg YXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUENCj4+DQo+PiAzIENsYXNzaWZpZXIgZW5jYXBz dWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2VydmljZSBpbmRleA0KPj49 IDENCj4+DQo+PiA0IENsYXNzaWZpZXIgcHJvZ3Jlc3NlcyBwYWNrZXQgdG8gU0ZGLTENCj4+DQo+ PiA1IFNGRi0xLCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2VydmljZSBpbmRleD0xLCBjaG9vc2VzIFNG Ri1BLTIgYW1vbmdzdCBpdHMNCj4+IGF2YWlsYWJsZSBpbnN0YW5jZXMgb2YgU0YtQQ0KPj4NCj4+ IDYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTENCj4+DQo+PiA3IFNGRi1BLTEgc2VuZHMg cGFja2V0IGJhY2sgdG8gU0ZGLTENCj4+DQo+PiA4IFNGRi0xIGluY3JlbWVudHMgc2VydmljZSBp bmRleCB0byAyDQo+Pg0KPj4gOCBTRkYtMSBzZWxlY3RzIFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVh c3Qgb25lIGluc3RhbmNlIG9mIFNGLUINCj4+DQo+PiA5IFNGRi0xIHByb2dyZXNzZXMgcGFja2V0 IHRvIFNGRi0yDQo+Pg0KPj4gMTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBTRkYt MywgYXMgdGhlIGVncmVzcyBib3JkZXIsDQo+PiBwcm9ncmVzc2VzIHRoZSBwYWNrZXQgcGVyIHJv dXRpbmcgdGFibGUNCj4+DQo+PiBUaGFua3MuDQo+Pg0KPj4gICAgIFJvbg0KPj4NCj4+ICpGcm9t OipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqWHV4aWFv aHUNCj4+ICpTZW50OiogU3VuZGF5LCBKdWx5IDEzLCAyMDE0IDExOjMwIFBNDQo+PiAqVG86KiBt aWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsgamd1aWNoYXJAY2lz Y28uY29tDQo+PiA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT47IG1uMTkyMUBhdHQuY29tIDxt YWlsdG86bW4xOTIxQGF0dC5jb20+Ow0KPj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+Ow0KPj4gam1oQGpvZWxoYWxwZXJu LmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBSb24gUGFya2VyOw0KPj4gc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gKlN1YmplY3Q6KiBbc2ZjXSBSZWRlZmlu ZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gQmFsYW5j ZXJzDQo+Pg0KPj4gQWdyZWUgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAg aW4gdGhlIGFyY2ggZHJhZnQgaXMgYSBiaXQNCj4+Y29uZnVzaW5nLCBqdXN0IGFzIHdoYXQgeW91 IGhhZCBwb2ludGVkIG91dC4NCj4+DQo+Pg0KPj4NCj4+IEluIG15IHVuZGVyc3RhbmRpbmcsIHRo ZSBTRlAgYXMgYW4gaW5zdGFudGlhdGlvbiBvZiBhbiBTRkMgaW4gdGhlDQo+Pm5ldHdvcmsgc2hv dWxkIGJlIOKAnGFuIG9yZGVyZWQgbGlzdCBvZiBzZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0o c2VlDQo+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFz ZWQtc2ZjLWFyY2gtMDEpLiBPZg0KPj5jb3Vyc2UsIGhvdyB0byByZXByZXNlbnQgdGhlIFNGUCBp biB0aGUgZGF0YSBwYWNrZXQgaXMgYW5vdGhlciB0aGluZw0KPj4oZS5nLiwgZWl0aGVyIHRocm91 Z2ggYSBwYXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBsYWJlbCBzdGFjaykuIEhlcmUNCj4+dGhl IHNlcnZpY2Ugbm9kZSBtZWFucyB0aGUgZGV2aWNlIHdoaWNoIGNvbnRhaW5zIHRoZSBTRkYgYW5k IHRoZSBORg0KPj5jb21wb25lbnRzIG1hbmRhdG9yaWx5IHdoaWxlIGNvbnRhaW5pbmcgdGhlIFNG IGFuZCBTRiBwcm94eSBjb21wb25lbnRzDQo+Pm9wdGlvbmFsbHkuIFRoZSBzZXJ2aWNlIG5vZGUg Y291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aCBtdWx0aXBsZQ0KPj5TRiBpbnN0YW5j ZXMgYW5kIHRob3NlIFNGIGluc3RhbmNlcyBjb3VsZCBiZSBvZiB0aGUgc2FtZSBTRiB0eXBlIG9y IG5vdC4NCj4+IEluIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBTRiBpbnN0YW5j ZXMgb2YgdGhlIHNhbWUgU0YgdHlwZQ0KPj4oZS5nLiwgU0YgWCkgYXJlIGF0dGFjaGVkIHRvIGEg Z2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlDQo+PmNvdWxkIGRpc3RyaWJ1dGUg dGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBpbnN0YW5jZXMNCj4+ b2YgU0YgWCB0eXBlIGxvY2FsbHkuIE1lYW53aGlsZSwgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHNl cnZpY2Ugbm9kZXMNCj4+d2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdoaWNoIGFy ZSBlbWJlZGRlZCBvciBhdHRhY2hlZCB3aXRoDQo+PnRoZSBTRg0KPiAgaW5zdGFuY2UNCj5zIG9m IHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5LCB0aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291 bGQgYmUgbWFkZQ0KPnZlcnkgZmxleGlibGUuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+ IFhpYW9odQ0KPj4NCj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g Kk9uIEJlaGFsZiBPZg0KPj4gKm1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20+DQo+PiAqU2VudDoqIFNhdHVyZGF5LCBKdWx5IDEyLCAyMDE0IDI6NDYgQU0NCj4+ICpU bzoqIGpndWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT47IG1uMTky MUBhdHQuY29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgam1o QGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPjsgc2ZjQGlldGYub3JnDQo+PjxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4g KlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+DQo+PiBXb3VsZG4ndCB0aGF0IGJlIGNhbGxlZCB0aGUgInNlcnZpY2UgY2hhaW4g aWRlbnRpZmllciIgdGhlbj8gIElmIHRoZQ0KPj4gc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJl ZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUNCj4+IG9yZGVyZWQgbGlz dCBvZiBTRiBpbnN0YW5jZXMsIHRoZW4gSSB3b3VsZCBpbmZlciB0aGF0IGEgInNlcnZpY2UgcGF0 aA0KPj4gaWRlbnRpZmllciIgd291bGQgYmUgYW4gaWRlbnRpZmllciBmb3IgYSBzZXJ2aWNlICpw YXRoKiwgbm90IGEgc2VydmljZQ0KPj4gKmNoYWluKi4NCj4+DQo+Pg0KPj4gQWdhaW4sIEkgdGhp bmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGluLiAgVGhlIHRl cm1zDQo+PiAiY2hhaW4iIGFuZCAicGF0aCIgc2VlbSBpbmNvbnNpc3RlbnQuDQo+Pg0KPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pg0KPj4gKkZyb206ICpqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJA Y2lzY28uY29tDQo+PiA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFyQGNpc2Nv LmNvbT4+DQo+PiAqVG86DQo+PiANCj4+Km1pa2ViaWFuY0Bhb2wuY29tPG1pa2ViaWFuY0Bhb2wu Y29tPixtbjE5MjFAYXR0LmNvbTxtbjE5MjFAYXR0LmNvbT4sbW9oYQ0KPj5tZWQuYm91Y2FkYWly QG9yYW5nZS5jb208bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4sam1oQGpvZWxoYWxwZXJu LmNvDQo+Pm08am1oQGpvZWxoYWxwZXJuLmNvbT4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtz LmNvbTxSb25fUGFya2VyQGFmZmlybWUNCj4+ZG5ldHdvcmtzLmNvbT4sc2ZjQGlldGYub3JnPHNm Y0BpZXRmLm9yZw0KPj4gDQo+PjxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2NtaWtlYmlhbmNA YW9sLmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21uMTkyMUANCj4+YXR0LmNvbSUzZSxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tJTNjbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzZQ0K Pj4sam1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzDQo+Pi5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tJTNlLHNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4+DQo+PiAqU2VudDogKkZyaWRheSwg SnVseSAxMSwgMjAxNA0KPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBZb3VyIGRlZmluaXRpb24gb2Ygc2Vydmlj ZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBhdGgNCj4+IHRocm91Z2gg d2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRp Zmllcg0KPj4gaG93ZXZlciBwb2ludHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1 cmUgYW5kIHRoYXQgaXMgdGhlbg0KPj4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJh c2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlDQo+PiBpbnN0YW5jZXMgYXJlIGF2YWls YWJsZSBhbmQgd2hhdGV2ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluDQo+PiBw bGF5LiBXaGVuIGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0aGUgbmV0d29y ayB5b3UgbWF5IG9yDQo+PiBtYXkgbm90IHVwZGF0ZSB0aGF0IGRhdGEgc3RydWN0dXJlIHRvIHNw ZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBiZQ0KPj4gdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4 dC1ob3Agd291bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoDQo+PiBmb3Ig dGhhdCBzZXJ2aWNlIGNoYWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVyIHBy b3RvY29sIC8NCj4+IG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0aGUgZGF0YSBzdHJ1Y3R1cmUgZm9y IHlvdS4NCj4+DQo+PiAqRnJvbTogKiJtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPiINCj4+IDxtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPj4NCj4+ICpEYXRlOiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNDQo+PiAq VG86ICpKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT4+LA0KPj4gIm1uMTkyMUBhdHQuY29tIDxtYWlsdG86bW4xOTIxQGF0dC5jb20+IiA8 bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgIm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+PiwgImptaEBqb2VsaGFscGVybi5jb20NCj4+IDxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+IDxt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4iDQo+PiA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPj4sICJzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IEkgdGhpbmsg dGhpcyBpcyB0aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOg0KPj4NCj4+PiBJIGRvbuKAmXQgd2Fu dCB0byBzcGVjaWZ5DQo+Pj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChv ciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQo+Pj4gYXNzaWduIGEgc2VydmljZSBwYXRo IGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0bw0KPj4+UzEtPlMy LT5TMw0KPj4+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrDQo+Pg0KPj4gQnkg ZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJl ZCBsaXN0IG9mDQo+PiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIEluIHRoZSBzdGF0ZW1lbnQgYWJv dmUsIHlvdSB1c2UgYSAic2VydmljZSBwYXRoDQo+PiBpZGVudGlmaWVyIiB0byByZWZlciB0byBh IHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAiW2RvZXMgbm90XQ0KPj4gc3BlY2lm eSBzcGVjaWZpYyBpbnN0YW5jZXMiLg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+ICpG cm9tOiAqamd1aWNoYXJAY2lzY28uY29tDQo+PiA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48 amd1aWNoYXJAY2lzY28uY29tDQo+PjxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4NCj4+ICpU bzogKk5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbQ0KPj4gPG1haWx0bzptbjE5MjFA YXR0LmNvbT4+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT48bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4g PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sSm9lbCBNLg0KPj4gSGFscGVy bjxqbWhAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LFJvbg0K Pj4gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+IDxtYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9yZw0KPj4gPG1haWx0bzpz ZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiAqU2Vu dDogKkZyaWRheSwgSnVseSAxMSwgMjAxNA0KPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBNYXJpYSwNCj4+DQo+ PiBJIHRoaW5rIG9mIGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMg c2ltcGx5IGEgcG9pbnRlcg0KPj50bw0KPj4gYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5z IFNGIHRvIG5leHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUNCj4+YQ0KPj4gY2hhaW4s IGxldOKAmXMgc2F5IFMxIC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUg U0ZQIHNwZWNpZnkNCj4+IHRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFm ZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdA0KPj5TRlAuDQo+PiBIb3dldmVyLCB5b3UgZG8g Km5vdCogaGF2ZSB0byBkbyB0aGlzIGZyb20gYW4gYXJjaGl0ZWN0dXJhbCBzdGFuZHBvaW50DQo+ PihJDQo+PiB3aWxsIGFyZ3VlIHRoYXQgeW91IHNob3VsZCBidXQgeW91IGRvbuKAmXQgaGF2ZSB0 byBhcmNoaXRlY3R1cmFsbHkpLiBZb3UNCj4+IGNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNl IHBhdGggaWRlbnRpZmllciB0byBwb2ludCB0byBhIGdpdmVuIFNGQw0KPj5hbmQNCj4+IHRoZW4g cHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdvcmsuIEF0IHRoZSBTRkYgaXQgd2ls bCBoYXZlIGENCj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBz YWlkIG1hcHBpbmcgd291bGQgY29udGFpbg0KPj50aGUNCj4+IG5leHQtaG9wcyBhdmFpbGFibGUg Zm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVhcm4NCj4+ IHRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRoZW0gZG93biBm cm9tIGENCj4+Y2VudHJhbGl6ZWQNCj4+IGNvbnRyb2xsZXIsIGNvbmZpZ3VyZSB0aGVtIHRocm91 Z2ggQ0xJLCBsZWFybiB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2gNCj4+IHNvbWUgcHJvdG9jb2wg ZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRv DQo+PiBzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNl cyBhcmUgY2hvc2VuIGENCj4+cHJpb3JpDQo+PiBhbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNj ZXB0YWJsZSAoYW5kIHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0bw0KPj5kbw0KPj4gc28u DQo+Pg0KPj4gTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBj bGVhcjoNCj4+DQo+PiBJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZD LTEpIFMxLT5TMi0+UzMuIEZvciBhcmd1bWVudHMNCj4+IHNha2UgbGV04oCZcyBzYXkgSSB3YW50 IGl0IHRvIGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKAmXQgd2FudCB0bw0KPj5zcGVjaWZ5 DQo+PiBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmlu YXRpb24gdGhlcmVvZikuIEkNCj4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKA nDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8NCj4+UzEtPlMyLT5TMw0KPj4gYW5kIHRo ZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEgc3RydWN0 dXJlcyBhcmUNCj4+IHBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBhdCBhIGdp dmVuIFNGRiwgd2hlbiB0cmFmZmljDQo+PmFycml2ZXMNCj4+IHdpdGggc2VydmljZSBwYXRoIGlk ZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhDQo+PiBz dHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5TMyBhbmQgdGhlIGlu ZGV4IGluIHRoZSBTRkMNCj4+IGVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0IGV4YWN0bHkgd2hl cmUgaXQgaXMgaW4gdGhlIGNoYWluLiBMZXTigJlzIHNheQ0KPj53ZQ0KPj4gYXJlIGF0IFMyIGlu IHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9w IHRvDQo+PiBTMyBhbmQgd2lsbCBkbyBhIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMg cmVhY2hhYmxlLg0KPj4NCj4+IE9uIDcvMTEvMTQsIDExOjI2IEFNLCAiTkFQSUVSQUxBLCBNQVJJ QSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToN Cj4+DQo+PiAgPkppbSwNCj4+ICA+DQo+PiAgPkNvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhl IGRlZmluaXRpb24gb2YgYSAic2VydmljZSBwYXRoIiBhbmQgYQ0KPj4gID4ic2VydmljZSBwYXRo IGlkZW50aWZpZXIiPw0KPj4gID5JZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBp bnN0YW5jZXMgYXJlIGNob3NlbiBhcHJpb3JpDQo+Pih3aGljaA0KPj4gID5pcyBteSBjdXJyZW50 IHVuZGVyc3RhbmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNo DQo+PiAgPm5leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9u Lg0KPj4gID4NCj4+ICA+TWFyaWENCj4+ICA+DQo+PiAgPg0KPj4gID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiAgPj4NCj4+DQo+PiBGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFy KSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4+ICA+PiBTZW50OiBGcmlkYXksIEp1bHkg MTEsIDIwMTQgMTE6MTUgQU0NCj4+ICA+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+OyBKb2VsIE0uDQo+PiAgPj4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3Jn IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+DQo+PiAgPj4gSeKAmW0g c29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgN Cj4+aWRlbnRpZmllcg0KPj4gID4+IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5l eHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhDQo+PnNlcnZpY2UNCj4+ICA+PiBjaGFpbiBpZGVu dGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0KPj4gID4+DQo+PiAgPj4gT24gNy8xMS8xNCwg MTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbQ0KPj4gPG1haWx0 bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPj4gID4+DQo+PiAgPj4gPkRpdHRvLg0KPj4gID4+ ID4NCj4+ICA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gID4+ID4+IEZyb206 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4NCj4+ICA+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb21dDQo+PiAgPj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+ PiAgPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7 IEpvZWwgTS4NCj4+SGFscGVybjsgUm9uDQo+PiAgPj4gPj4gUGFya2VyOyBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4NCj4+ICA+PiA+ PiBSZS0sDQo+PiAgPj4gPj4NCj4+ICA+PiA+PiBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0 aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0aGUNCj4+ICA+PmRyYWZ0Lg0KPj4gID4+ ID4+DQo+PiAgPj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgaW4g aXRzZWxmIGEgaGludCB0aGF0IHRoZQ0KPj5mdWxsDQo+PiAgPj4gPj5kaXN0cmlidXRlZA0KPj4g ID4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4gID4+ID4+DQo+PiAgPj4gPj4gU2V2ZXJh bCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4N Cj4+aXRzZWxmDQo+PiAgPj4gPj5zaG91bGQgYmUNCj4+ICA+PiA+PiBwcm92aWRlZCBpbnN0ZWFk Lg0KPj4gID4+ID4+DQo+PiAgPj4gPj4gQ2hlZXJzLA0KPj4gID4+ID4+IE1lZA0KPj4gID4+ID4+ DQo+PiAgPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gID4+ID4+ID5EZSA6 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEppbQ0KPj5H dWljaGFyZA0KPj4gID4+ID4+ID4oamd1aWNoYXIpDQo+PiAgPj4gPj4gPkVudm95w6kgOiB2ZW5k cmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+ICA+PiA+PiA+w4AgOiBOQVBJRVJBTEEsIE1B UklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4+IHNmY0BpZXRmLm9yZyA8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ICA+PiA+PiA+DQo+PiAgPj4gPj4g Pk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzDQo+ PmZ1bmN0aW9uYWxpdHkNCj4+ICA+PiA+PiA+cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlz dHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCoNCj4+U0ZG4oCZcw0KPj4gID4+ID4+ID53 aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlkZW50aWZpZXIgcG9p bnQgdG8NCj4+YQ0KPj4gID4+ID4+bG9va3VwDQo+PiAgPj4gPj4gPmludG8gdGhvc2UgbmV4dC1o b3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBub3QNCj4+ICA+PnN1 cmUNCj4+ICA+PiA+Pmhvdw0KPj4gID4+ID4+ID50aGUgYXJjaGl0ZWN0dXJlIHByZXZlbnRzIHRo YXQ/DQo+PiAgPj4gPj4gPg0KPj4gID4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVS QUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+ Pg0KPj4gID4+IHdyb3RlOg0KPj4gID4+ID4+ID4NCj4+ICA+PiA+PiA+PkFic29sdXRlbHkuDQo+ PiAgPj4gPj4gPj4NCj4+ICA+PiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ICA+PiA+PiA+Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ICA+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiAgPj4g Pj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+PiAgPj4gPj4gPj4+ IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4+ IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+PiA+Pj4gU3ViamVj dDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ PiAgPj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRoZSBwcm9w b3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMNCj4+dG8gbWUNCj4+ICA+PiA+PnRoYXQgaWYN Cj4+ICA+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8g d2hpY2ggcmVtb3RlIFNGRiBpdA0KPj4gID4+d2lsbA0KPj4gID4+ID4+dXNlDQo+PiAgPj4gPj4g Pj4+Zm9yDQo+PiAgPj4gPj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3 aXRoaW4gdGhlIGNoYWluIHRoZW4geW91DQo+PiAgPj5iZXR0ZXINCj4+ICA+PiA+Pm1ha2UNCj4+ ICA+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBm b3J3YXJkaW5nIGxvZ2ljDQo+PnRvDQo+PiAgPj4gPj5yZWFjaA0KPj4gID4+ID4+ID4+PnRoZQ0K Pj4gID4+ID4+ID4+PiBuZXh0LW5leHQtU0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91 IGFyZSBpbiBkZWVwDQo+PnRyb3VibGUuDQo+PiAgPj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+IE9u IDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbQ0K Pj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQo+PiAgPj4gPj4gd3JvdGU6DQo+PiAgPj4gPj4g Pj4+DQo+PiAgPj4gPj4gPj4+ID5BYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJl IGluc3RhbnRpYXRlZCBvbmx5IGluDQo+PiAgPj5yZWxldmFudA0KPj4gID4+ID4+ID4+PlNGRnMN Cj4+ICA+PiA+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4NCj4+ICA+PiA+PiA+Pj4gPg0KPj4g ID4+ID4+ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gID4+ID4+ID4+PiA+ PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpp bQ0KPj4gID4+R3VpY2hhcmQNCj4+ICA+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+PiAgPj4gPj4g Pj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjI3IEFNDQo+PiAgPj4gPj4gPj4+ ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4gPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PkJhbGFuY2Vycw0KPj4gID4+ID4+ID4+ PiA+Pg0KPj4gID4+ID4+ID4+PiA+PiBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFu IHRoYXQgaWYgSSBoYXZlDQo+PnVuZGVyc3Rvb2QNCj4+ICA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+ PnByb3Bvc2FsDQo+PiAgPj4gPj4gPj4+ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJl IGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5DQo+PnNpbmdsZQ0KPj4gID4+U0YNCj4+ICA+PiA+PiA+ Pj53aXRoaW4NCj4+ICA+PiA+PiA+Pj4gPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gZW50aXJlIFNG QyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkNCj4+dG8NCj4+ ICA+Pmtub3cNCj4+ICA+PiA+PmENCj4+ICA+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ICA+PiA+PiA+ Pj4gPj4gd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFu eSBnaXZlbg0KPj4gID4+cG9pbnQNCj4+ICA+PiA+PmluDQo+PiAgPj4gPj4gPj4+dGltZS4NCj4+ ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJK b2VsIE0uIEhhbHBlcm4iDQo+PiA8am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+Pg0KPj4gID4+ID4+IHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+Pg0KPj4gID4+ ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIg bWFqb3INCj4+cHJvYmxlbQ0KPj4gID4+d2l0aA0KPj4gID4+ID4+dGhlDQo+PiAgPj4gPj4gPj4+ ID4+eW91cg0KPj4gID4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAo QW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heQ0KPj5ub3QNCj4+ICA+PiA+PiA+Pj51bmRlcnN0YW5k DQo+PiAgPj4gPj4gPj4+ID4+ID5pdC4pDQo+PiAgPj4gPj4gPj4+ID4+ID4NCj4+ICA+PiA+PiA+ Pj4gPj4gPlRoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQgYmFsYW5j ZXIgZm9yDQo+PnRoZQ0KPj4gID4+ID4+bmV4dA0KPj4gID4+ID4+ID4+PiA+PiA+c2VydmljZSBm dW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzDQo+PiAgPj50 byksDQo+PiAgPj4gPj5pbg0KPj4gID4+ID4+ID4+PmV2ZXJ5DQo+PiAgPj4gPj4gPj4+ID4+ID5z ZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4gID4+ID4+ID4+PiA+PiA+DQo+ PiAgPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxs IHNlcnZpY2VzLCB0aGF0DQo+Pm1lYW5zDQo+PiAgPj4gPj50aGF0DQo+PiAgPj4gPj4gPj4+ID4+ ZXZlcnkNCj4+ICA+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxv dyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsDQo+PmxvYWQNCj4+ICA+PiA+PiA+Pj5iYWxhbmNlci4N Cj4+ICA+PiA+PiA+Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93 IHNlbnNpdGl2ZSwgYW5kIC8NCj4+b3INCj4+ICA+PiA+PnN0YXRlZnVsLg0KPj4gID4+ID4+ID4+ PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYg YmUgYQ0KPj5mdWxsLA0KPj4gID4+ID4+Zmxvdw0KPj4gID4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZl LCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPj4gID4+ID4+ YWNjZXB0YWJsZQ0KPj4gID4+ID4+ID4+PiA+PiA+aW1wb3NpdGlvbi4NCj4+ICA+PiA+PiA+Pj4g Pj4gPg0KPj4gID4+ID4+ID4+PiA+PiA+WW91cnMsDQo+PiAgPj4gPj4gPj4+ID4+ID5Kb2VsDQo+ PiAgPj4gPj4gPj4+ID4+ID4NCj4+ICA+PiA+PiA+Pj4gPj4gPk9uIDcvMTAvMTQsIDEwOjA2IFBN LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkg cGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UNCj4+dGhpcw0KPj4gID4+ d29yaw0KPj4gID4+ID4+ID4+PiA+PnNlbnNpYmx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+IGluIGEg bW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlDQo+PiAgPj5z ZXJ2aWNlDQo+PiAgPj4gPj4gPj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9i YWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcywNCj4+ICA+PndpbGwNCj4+ICA+PiA+PmJlDQo+PiAg Pj4gPj4gPj4+ID4+ID4+IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0aGUg c2VydmljZSBjaGFpbnMNCj4+ICA+PnRvIGJlDQo+PiAgPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+ PiAgPj4gPj4gPj4+ID4+ID4+IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3MgdG8gY2xp ZW50cywgYW5kIGVuYWJsZQ0KPj4gID4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+PiAgPj4gPj4g Pj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmls eSBwb2xpY3kNCj4+ICA+PiA+PmRyaXZlLg0KPj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbg0K Pj5hcmNodGllY3R1cmUNCj4+ICA+PiA+PmRyaXZlbg0KPj4gID4+ID4+ID4+PmJ5DQo+PiAgPj4g Pj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2Ug cGF0aHMuIEl0DQo+PmlzDQo+PiAgPj4gPj5oYXJkZXINCj4+ICA+PiA+PiA+Pj50bw0KPj4gID4+ ID4+ID4+PiA+PnNlZQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBob3cgdG8gbWFrZSBpdCB3b3JrIChi dXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cNCj4+bW9yZQ0KPj4gID4+ID4+ID4+PiA+ PiBkeW5hbWljaXR5DQo+PiAgPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9y Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4gID4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0 aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQNCj4+aXMNCj4+ICA+PiA+ Pm91dHNpZGUNCj4+ICA+PiA+PiA+Pj5vZg0KPj4gID4+ID4+ID4+PiA+PnRoZQ0KPj4gID4+ID4+ ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGlu ZyB3ZSBhcmUNCj4+ICA+PiA+PnRhc2tlZCB0bw0KPj4gID4+ID4+ID4+PiA+PmFncmVlDQo+PiAg Pj4gPj4gPj4+ID4+ID4+b24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWlt IHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYQ0KPj4gID4+Y2VydGFpbg0KPj4g ID4+ID4+ID4+PndheS4NCj4+ICA+PiA+PiA+Pj4gPj5pdA0KPj4gID4+ID4+ID4+PiA+PiA+PiBp cyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+PiAgPj4gPj4gPj4+ ID4+ID4+IEpvZWwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gT24g Ny8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlDQo+Pmluc3Rh bmNlcw0KPj4gID4+ID4+IHRoYXQNCj4+ICA+PiA+PiA+Pj4gPj5uZWVkcw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+dG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQg YW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5DQo+PmV2ZW4NCj4+ICA+PiA+PmFjcm9zcw0KPj4g ID4+ID4+ID4+PmRhdGENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBh ZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UNCj4+ZW5vdWdoDQo+PiAgPj5hbmQNCj4+ICA+ PiA+PiA+Pj4gY29tcGxleA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWlu ZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+Pmxpa2UgYQ0KPj4gID4+ID4+ID4+ PmRpZmZpY3VsdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXpl Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3Vz IGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbg0KPj4gID4+ZHluYW1pYw0K Pj4gID4+ID4+ID4+PiByb3V0aW5nLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUg ZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2YNCj4+ICA+PndoaWNoDQo+ PiAgPj4gPj5hcmUNCj4+ICA+PiA+PiA+Pj4gPj5iaWdnZXINCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseQ0KPj5pbXBsZW1l bnRlZD8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBJdCBhbHNv IHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQsDQo+PnRoYXQNCj4+ ICA+PmlzDQo+PiAgPj4gPj5hDQo+PiAgPj4gPj4gPj4+Z29vZA0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBq b2VsaGFscGVybi5jb20NCj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiAgPj4g Pj4gPj4+ID4+ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+PiAg Pj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlr ZWJpYW5jQGFvbC5jb20NCj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPj4gID4+SWFu DQo+PiAgPj4gPj4gPj4+U21pdGg7DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBSZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gID4+QmFsYW5jZXJzDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNo aXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZA0KPj4gID4+cHJlZmVyDQo+PiAg Pj4gPj53ZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlDQo+PiAg Pj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBCZWNhdXNlIGl0IGRv ZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPj4gID4+ID4+cmVxdWlyZW1l bnRzDQo+PiAgPj4gPj4gPj4+YW5kDQo+PiAgPj4gPj4gPj4+ID4+IHRoZQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91 dCBzZXJ2aWNlDQo+Pmluc3RhbmNlcw0KPj4gID4+ID4+dGhhdA0KPj4gID4+ID4+ID4+PiBuZWVk cw0KPj4gID4+ID4+ID4+PiA+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gYmUgd2lkZWx5IGRp c3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVuDQo+PiAgPj4gYWNyb3Nz DQo+PiAgPj4gPj4gPj4+ZGF0YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gY2VudGVycyB3aXRoaW4g YW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlDQo+PmVub3VnaA0KPj4gID4+YW5kDQo+ PiAgPj4gPj4gPj4+Y29tcGxleA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5 aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4+bGlrZSBhDQo+PiAgPj4gPj4g Pj4+ZGlmZmljdWx0DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6 ZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIg d3JvdGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1 ZS4gSXMgdGhlIGVuZCB0byBlbmQNCj4+ICA+PnNlbGVjdGlvbg0KPj4gID4+ID4+b2YNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxs eSAocGVyaGFwcw0KPj5ieSB0aGUNCj4+ICA+PiA+PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIg YW5kDQo+PnN1YnNlcXVlbnRseQ0KPj4gID4+ID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+U0ZGcyk/ DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQg dG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4+ICA+PkFuZA0KPj4gID4+ID4+ID4+PnN1cmVseSwNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5v dCByZWxlZ2F0ZWQgdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcg aXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4NCj4+ICA+PiB0aG91Z2gN Cj4+ICA+PiA+PiBhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0 YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHMNCj4+ICA+PmxvY2FsDQo+PiAgPj4gPj4g Pj4+ID4+c2VsZWN0aW9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJl ZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0KPj5wb2ludHMuDQo+PiAgPj4gPj5UaGlz DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQt dG8tZW5kIHBhdGggaWQgYXQNCj4+YWxsLg0KPj4gID4+ID4+TXkNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5DQo+ PmRyaXZlbg0KPj4gID4+YnkNCj4+ICA+PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBX aXRoIGENCj4+ICA+Pmdsb2JhbA0KPj4gID4+ID4+ID4+PnBhdGgNCj4+ICA+PiA+PiA+Pj4gPj5p ZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFu IGluc3RhbmNlIGFuZA0KPj5uZWVkaW5nIHRvDQo+PiAgPj4gPj5hbHRlcg0KPj4gID4+ID4+ID4+ PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNo IGFuZCBldmVyeSBhZmZlY3RlZA0KPj4gID4+ZW5kLXRvLWVuZA0KPj4gID4+ID4+ID4+PnBhdGgu DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g W3NmYy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPj4g b24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBb am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20NCj4+IDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFs cGVybi5jb20+XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwNCj4+ICA+PjIwMTQNCj4+ICA+PiA+ PiA2OjE1DQo+PiAgPj4gPj4gPj4+IFBNDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gVG86IG1pa2Vi aWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPj4gSS5TbWl0aEBGNS5j b20gPG1haWx0bzpJLlNtaXRoQEY1LmNvbT47IHNmY0BpZXRmLm9yZw0KPj48bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+ICA+PiBTdWJqZWN0Og0KPj4gID4+ID4+IFJlOg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBh cmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNGMQ0KPj5uZWVkaW5nDQo+PiAgPj50bw0K Pj4gID4+ID4+ID4+PiA+PmluZmx1ZW5jZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHRoZSBjaGFp biBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0DQo+PnRoZQ0KPj4gID4+ ZXhpdA0KPj4gID4+ID4+ZnJvbQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFNGMS4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMg dG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucw0KPj4gID4+ID4+bG9naWNhbGx5DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkg ZGVzY3JpYmUgaG93DQo+PnRoZXkNCj4+ICA+PiA+PiBjaG9vc2UNCj4+ICA+PiA+PiA+Pj50bw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5 Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gWW91cnMsIEpv ZWwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IE9uIDcvMTAv MTQsIDY6MTAgUE0sIG1pa2ViaWFuY0Bhb2wuY29tDQo+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcg aW4gdGhlIGFyY2ggZHJhZnQgdGhhdA0KPj5zdWdnZXN0cyBhbnkNCj4+ICA+PiA+PnNvcnQNCj4+ ICA+PiA+PiA+Pj5vZg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBsaW1pdC4gSG93ZXZlciwgaXQg ZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlDQo+PmVudGlyZQ0KPj4gID4+ID4+cGF0aA0K Pj4gID4+ID4+ID4+PihhbGwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBj aG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVsaWV2ZQ0KPj4gID4+dGhpcw0KPj4gID4+ ID4+ID4+Pm1lYW5zDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3Np ZmllciBvciBtYXliZSB0aGUgY2xhc3NpZmllcg0KPj4gID4+Y2hvb3NlcyBhDQo+PiAgPj4gPj5T Rg0KPj4gID4+ID4+ID4+PiA+PkNoYWluDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUg TkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkNCj4+Y2FzZSwNCj4+ICA+ PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJv aGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQDQo+PndoZXJlDQo+PiAgPj4gPj4gU0ZJKG4pDQo+PiAg Pj4gPj4gPj4+IGlzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNG SShuLTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZQ0KPj5kcmFmdCwNCj4+ICA+PiA+PnRoaXMNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNo aW5nIiB0byBhIG5ldw0KPj5TRlAgYXMNCj4+ICA+PiA+PiA+Pj4gb3Bwb3NlZA0KPj4gID4+ID4+ ID4+PiA+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3 YXJkaW5nIHRvIHRoZSBzZWxlY3RlZA0KPj5pbnN0YW5jZSBvZg0KPj4gID4+ID4+dGhlDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1h cmNoaXRlY3R1cmUtMDA6DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBXaGVuIGFuIFNGQyBpcyBp bnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpcw0KPj4gID4+ID4+bmVjZXNzYXJ5DQo+ PiAgPj4gPj4gPj4+dG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlbGVjdCB0aGUgc3BlY2lm aWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUNCj4+dXNlZCwNCj4+ICA+PiA+PmFuZCB0 bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZv ciB0aGF0IFNGQyB1c2luZyBTRidzDQo+PiAgPj4gPj5uZXR3b3JrDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBp bg0KPj50aGUNCj4+ICA+PiA+PiA+Pj5jcmVhdGlvbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4g b2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+PiAgPj4g Pj5mb3J3YXJkaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhl IFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcw0KPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1 cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yDQo+PiAgPj4gPj5ub24taW5pdGlhbA0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJh dmVyc2UgYW4NCj4+U0ZQLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlv biBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkDQo+PmJ5IGENCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2 aWNlDQo+PiAgPj4gPj5mdW5jdGlvbi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3Np ZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGENCj4+bmV3DQo+PiAgPj4g Pj5TRlAsIGFuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0 ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4+ICA+PiA+PnJlZmVycmVkDQo+PiAgPj4g Pj4gPj4+dG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+Pg0KPj4gID4+ ID4+ID4+Pg0KPj4gID4+ID4+DQo+PiAgPj4NCj4+ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiAgPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gID4+ID4+Pj4+Pj4+Pj4+ Pi0tLQ0KPj4gID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4gID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4gKkZyb206ICpJLlNtaXRoQEY1LmNvbQ0KPj4gPG1haWx0bzoqSS5TbWl0aEBGNS5jb20+PEku U21pdGhARjUuY29tIDxtYWlsdG86SS5TbWl0aEBGNS5jb20+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4NCj4+ICA+PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFs cGVybi5jb20NCj4+IDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+PixKb2VsDQo+ PiAgPj4gPj4gTS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ ICA+PiA+PiA+Pj4NCj4+ICA+PiA+Pg0KPj4gID4+ID4+Pj4+SGFscGVybjxqbWhAam9lbGhhbHBl cm4uY29tDQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixodWFuZ0BzY2UuY2FybGV0 b24uY2ENCj4+IDxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0BzY2UuDQo+PiA8 bWFpbHRvOmh1YW5nQHNjZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PmNhPixzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRm Lm9yZw0KPj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkDQo+PiAgPj4gPj5CYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWluZy4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3Np YmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+PiAgPj50aGF0IGlzDQo+ PiAgPj4gPj4gPj4+d2hhdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dz IGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyANCj4+aXMNCj4+ICA+PiA+PiA+Pj5w cmVjb25jZWl2ZWQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXMgYW4gYWJzdXJkIGlkZWEsIHRo ZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCANCj4+d2l0aA0KPj4gID4+IHRoYXQNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gcHJlY29uY2VwdGlvbi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWlt LCBzb21lIGRlZ3JlZSBvZg0KPj4gID4+ID4+YXNwaXJhdGlvbg0KPj4gID4+ID4+IHRvDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZl c3BhbiBvZiB0aGUNCj4+ICA+PiA+PmFyY2hpdGVjdHVyZQ0KPj4gID4+ID4+ID4+Pi0NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQg Ynkgc2F5aW5nIA0KPj50aGF0IGFuDQo+PiAgPj4gPj4gPj4+YXJiaXRyYXJ5DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIsIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4g aWYgaXQgDQo+Pmlzbid0DQo+PiAgPj4gPj4gPj4+ID4+aW50ZW50aW9uYWwNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZl IA0KPj5sYXN0aW5nDQo+PiAgPj4gPj5pbXBhY3RzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJl Z2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4+ICA+ PiA+PmFkZHJlc3MNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9m IHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIA0KPj5ub3QNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBGcm9tOiBKb2VsIEhh bHBlcm4gRGlyZWN0DQo+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWgu ZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+PiAgPj4gPj5TZW50Og0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpv ZWwgDQo+Pk0uDQo+PiAgPj4gPj4gSGFscGVybjsNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gaHVh bmdAc2NlLmNhcmxldG9uLmNhDQo+PiA8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47IHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0K Pj4gID4+ID4+U2VydmljZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBp biANCj4+dGhpcw0KPj4gID4+ID4+cmVnYXJkLg0KPj4gID4+ID4+ID4+PkkNCj4+ICA+PiA+PiA+ Pj4gPj5hbQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFy Y2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ICA+PiA+PnByb2hpYml0DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9uLiBJIGFtIG9i amVjdGluZyANCj4+dG8NCj4+ICA+PiA+Pkh1YW5nJ3MNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgDQo+PmFy ZQ0KPj4gID4+ID4+IHJlcXVpcmVkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhl IGFyY2h0aWVjdHVyZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIA0KPj5w cm9oaWJpdA0KPj4gID4+c3VjaA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGluZ3MuIFdoZXRo ZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Igbm90IGRlcGVuZHMgDQo+PnVwb24NCj4+ICA+PiA+ PiBtYW55DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2Nv cGUgb2YgdGhlIFdHLiBJIGhhcHBlbiB0bw0KPj4gID4+dGhpbmsNCj4+ICA+PiA+PnRoYXQNCj4+ ICA+PiA+PiA+Pj4gPj50aGV5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEg YmFkIGlkZWEuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyANCj4+YXR0ZW1wdGlu ZyB0bw0KPj4gID4+ID4+a25vdw0KPj4gID4+ID4+ID4+PndoYXQNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3Rh dGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSANCj4+dGVucyBvZg0KPj4gID4+ID4+ID4+Pm1pbGxp b25zDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBj b25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRhdGEgDQo+PmNlbnRl cg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBz ZXJpb3VzbHkgYmVsaWV2ZSANCj4+dGhhdCBpbg0KPj4gID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5 b3UNCj4+ICA+PiBhcmUNCj4+ICA+PiA+PiBvbmx5DQo+PiAgPj4gPj4gPj4+ID4+IGdvaW5nDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNo YWlucyB3aXRoIGVxdWFsbHkNCj4+ICA+PnNtYWxsDQo+PiAgPj4gPj4gPj4+IG51bWJlcnMNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11 Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIA0KPj5tb3JlDQo+PiAgPj4gdGhhbg0KPj4g ID4+ID4+ID4+PiA2NEsiDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gY29tZm9ydC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IFtzZmMtYm91bmNlc0BpZXRmLm9yZw0KPj4gPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5d IG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2pt aEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDQ6NDYgUE0gVG86 DQo+PiAgPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhIDxtYWlsdG86aHVhbmdAc2NlLmNh cmxldG9uLmNhPjsNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRv OnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6DQo+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsDQo+PiAgPj5hbmQNCj4+ICA+PiA+PiA+Pj5Mb2FkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ PiBCYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgDQo+ PnRoZQ0KPj4gID4+ID4+ID4+PmFyY2h0aWV0dXJlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBw YXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPj4gID4+ dGhlaXINCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUg ZG9lcyBub3QgcmVxdWlyZSBzdWNoIA0KPj5hYnN1cmQNCj4+ICA+PiB1c2UNCj4+ICA+PiA+PiBv Zg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90 IGZpZ3VyZSBvdXQgaG93IHRvIA0KPj53cml0ZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJj aGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIA0KPj5hcmNoaXRlY3R1cmUNCj4+ ICA+PmRvZXMNCj4+ICA+PiA+PiA+Pj5wZXJtaXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1 Y2ggYWJ1c2UuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUNCj4+ ICA+PiBwZXJtaXRzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMgc2F5aW5n IGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yIA0KPj5yZXF1aXJlZCBieQ0KPj4gID4+ID4+dGhlDQo+ PiAgPj4gPj4gPj4+d29yay4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXJzLCBKb2Vs DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8x MC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBzdXBwb3J0IDEwMCBzZXJ2aWNlIGNoYWlucywgaXQgd2ls bA0KPj4gID4+bWVhbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMu IFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcNCj4+ICA+PnRhYmxlDQo+PiAgPj4gPj5v ZiBhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMTox NSBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBU aGUgYXJjaGl0ZWN0dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCANCj4+ZnJvbQ0K Pj4gID4+MQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggdG8gMTYwMDAw IHNlcnZpY2UgcGF0aHMuIEkgd291bGQgDQo+PmhvcGUNCj4+ICA+PnRoYXQNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4gb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNvbXBsZXhpdGll cyBpZiANCj4+dGhleQ0KPj4gID4+ID4+Y2hvb3NlDQo+PiAgPj4gPj4gPj4+dG8NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBh bmQgaW4gDQo+PnN0ZWFkDQo+PiAgPj4gPj4gcHJvdmlzaW9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwg TkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1 bCwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCANCj4+aG9w DQo+PiAgPj4gPj4gc2VydmljZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0 aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddICpPbiANCj4+QmVoYWxmDQo+PiAgPj4gT2YNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAx MCwgDQo+PjIwMTQNCj4+ICA+PiA+PjM6MDMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBN ICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20+Ow0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPjsgc2ZjQGlldGYub3JnIA0KPj48bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPg0KPj4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZQ0KPj4gID4+IENoYWlucywNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5LA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE92 ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgDQo+PnRoZQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiBtYWtlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdl OiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSANCj4+dXNlZCB0bw0KPj4gID4+ID4+IGRlcml2 ZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG5lZWRlZCBmb3J3YXJkaW5nIGFuZCBh c3NvY2lhdGVkIHRyYW5zcG9ydC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVy IGlzIHVzZWQgdG8NCj4+ICA+PnNpbXBseQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRl bnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgDQo+PnBhY2tldHMNCj4+ICA+ Pm11c3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBw YXRoIGlkZW50aWZpZXIsIHRoZSBleGFjdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5k aXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uDQo+PiAgPj50aGlz DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBs ZW1lbnRlZC4gVGhlIHBhdGgNCj4+ICA+PiA+PiBpZGVudGlmaWVyDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwgdGhhdCANCj4+ bG9va3VwIGNhbg0KPj4gID4+ID4+IHJlc3VsdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9ydCANCj4+bmV4dA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPbiBKdWwgMTAsIDIwMTQsIGF0 IDExOjA0IEFNLCBMdWN5IHlvbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5Lnlv bmdAaHVhd2VpLmNvbSANCj4+PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4NCj4+ICA+PiA+ PiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tJTNlPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNo LiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgDQo+PnVzZSBvZg0KPj4gID4+IHRoZQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUg dGhlIGZvcndhcmRpbmcNCj4+ICA+PiA+PmFjdGlvbnMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gDQo+PkJlaGFsZg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gPG1haWx0bzpPZiptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gID4+ID4+ID4+PiAqU2VudDoq VGh1cnNkYXksDQo+PiAgPj4gPj4gPj4+ID4+IEp1bHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0KPj4gPG1haWx0bzoq bWlrZWJpYW5jQGFvbC5jb20+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1p a2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tJTNlO2ptaEBqb2VsaGFscGVybi5jb20+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPj4gPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZz4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIA0KPj5T ZXJ2aWNlDQo+PiAgPj4gPj5DaGFpbnMsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxp Y2l0bHkgYSBzZXJ2aWNlIA0KPj5wYXRoDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVu dGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+PiAgPj5kZXJpdmUN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcg YSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwgDQo+Pmtub3dsZWRnZSBvZg0KPj4gID4+ID4+ IGV2ZXJ5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRv bWFpbiANCj4+aXMgbm90DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVpcmVkL2p1c3RpZmll ZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZhcmlvdXMgZGVw bG95bWVudCBjb250ZXh0cy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNob3VsZCByZWx5IG9uIHRo ZSBwaWVjZSANCj4+b2YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZQ0KPj4gID4+ IHJlcXVpcmVkDQo+PiAgPj4gPj4gdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVj dHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIA0KPj5pcw0KPj4gID4+ ID4+dXNlZCB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSANCj4+cGFydA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wu Y29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4gKkVudm95w6kgOiptZXJjcmVkaSA5DQo+PiAgPj4gPj4ganVpbGxldA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8 bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ ICA+PiA+PkNoYWlucywNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgDQo+ PmJldHdlZW4NCj4+ICA+PlNGDQo+PiAgPj4gPj4gQ2hhaW4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuZCBTRg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRo YXQgDQo+Pml0J3MNCj4+ICA+PiA+PmNsZWFyIHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRo b3NlIG5vdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJh ZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUNCj4+ICA+PmFncmVlcw0KPj4gID4+ID4+b24NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50 IHRoYXQgaXMgc3RpbGwgdW5jbGVhciBpcw0KPj4gID4+d2hldGhlcg0KPj4gID4+ID4+aXQgaXMN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1 bHRpbWF0ZWx5IHNwZWNpZnkgDQo+PndoYXQNCj4+ICA+PiA+PnRoZSBJRA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g c2hvdWxkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBv ciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgDQo+PmRyYWZ0DQo+PiAgPj4gPj5zaW1wbHkNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFs bG93aW5nIG90aGVyDQo+PiAgPj5kcmFmdHMNCj4+ICA+PiA+PnRvDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9u IA0KPj5jaGFpbg0KPj4gID4+IG9yDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFu ZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wt cGxhbmUuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gSWYgdGhlIGxhdHRlciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQgDQo+ PmhhdmUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBh bmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgDQo+Pm1ha2UNCj4+ICA+PiA+PiBvbmUNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2 b2lkIHNvbWUNCj4+ICA+PiB2ZW5kb3JzDQo+PiAgPj4gPj4gb25seQ0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZD Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+DQo+PiAgPj4gPj4gPj4+ DQo+PiAgPj4gPj4NCj4+ICA+Pg0KPj4gIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+LS0NCj4+ICA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiAgPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+ PiAgPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiAgPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pi0tDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipqbWhAam9lbGhhbHBlcm4uY29tDQo+ PiA8bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gID4+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5j b20+DQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29t JTNlPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnDQo+PiA8 bWFpbHRvOipzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGll dGYub3JnPg0KPj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmclM2U+Pg0KPj4g ID4+ICpTZW50OipUdWVzZGF5LA0KPj4gID4+ID4+IEp1bHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgDQo+ PmFuZA0KPj4gID4+TG9hZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBo YXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHkNCj4+ICA+PmFuc3dl cg0KPj4gID4+ID4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbnVtYmVyIG9mIGNvbW1l bnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlDQo+PiAgPj4gPj4gPj4+IHByb3Bvc2Vk DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBB c3N1bWluZyB3ZSBjYW4gZ2V0DQo+PiAgPj4gd29ya2luZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPj4g ID4+IGltcHJvdmUNCj4+ICA+PiA+PiB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdv cmRpbmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCANCj4+cGFydGljaXBhdGVkIGluDQo+ PiAgPj4gPj50aGUNCj4+ICA+PiA+PiBXRw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlz Y3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiB3b3JraW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1 dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+PiAgPj4gPj5w ZXJzb25hbA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0 IGhlbHBzLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIA0K Pj50aGF0DQo+PiAgPj4gPj53aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUg ZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiANCj4+V2UNCj4+ICA+PmFy ZQ0KPj4gID4+ID4+IG5vdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0 byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIA0KPj5lbnRpcmUNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5nLiBUaGF0IHdvdWxk IA0KPj5lbmNvbXBhc3MNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9TUy9CU1MsIHZhcmlv dXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCj4+ICA+PnZpcnR1YWwNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55 IG90aGVyDQo+PiAgPj4gPj4gYXNwZWN0cy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGlu Z3Mgd2hpY2ggY2xlYXJseSANCj4+bmVlZA0KPj4gID4+IHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCAN Cj4+d2l0aA0KPj4gID4+ID4+YWJvdmUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJl IHdlIGFyZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3Jr IHdlIGFyZQ0KPj4gID4+IGRvaW5nLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZz IHNlcnZpY2UgDQo+PnBhdGgsDQo+PiAgPj5hcyBJDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB1bmRlcnN0YW5kDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhl cmUgDQo+PmFyZSBhdA0KPj4gID4+ID4+bGVhc3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRocmVlIGRpZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZA0KPj4gID4+ d2lsbA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNo YWluaW5nLiBUaGVyZSBwcm9iYWJseSANCj4+YXJlDQo+PiAgPj4gPj5tb3JlLg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMgdG8gcGVy bWl0IGFsbCANCj4+b2YNCj4+ICA+PiA+PnRoZXNlLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhbnkg c29sdXRpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSAN Cj4+ZW5kDQo+PiAgPj4gPj51c2VyLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBp cyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXINCj4+ICA+PnBhY2tldHMsDQo+ PiAgPj4gPj5hbmQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9y DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciANCj4+c2VydmljZQ0K Pj4gID4+ID4+aW5zdGFuY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUg dGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiANCj4+aW1wb3J0YW50DQo+PiAgPj4gPj5zZXJ2 aWNlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGlu Y2x1ZGUgaW4gc2VydmljZSANCj4+Y2hhaW5pbmcuDQo+PiAgPj4gPj5JdCdzDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cg c2VydmljZQ0KPj4gID4+ID4+IGNoYWluaW5nIGlzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4+ICA+PiA+PmFy Y2h0aWVjdHVyZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEZyb20gYW4gYXJjaGl0ZWN0 dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IA0KPj5hDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IHNlcnZpY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHdoaWNoIG1h eSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQg YmFsYW5jaW5nLiBUaGF0IGlzLCANCj4+b25lDQo+PiAgPj5jYW4NCj4+ICA+PiA+PmhhdmUNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoYXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBw ZWFycw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcg YXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlDQo+PiAgPj5wb2ludA0KPj4gID4+ID4+b2YNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZm9y IGENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24s IGJ1dCBpcyBhY3R1YWxseSANCj4+ZGVsaXZlcmVkDQo+PiAgPj4gPj5ieSBhDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZp cnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZw0KPj4gID4+b25l IG9yDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChm b3IgZXhhbXBsZSB1c2luZyANCj4+VlJSUC1saWtlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIA0KPj50aGlzIGlz DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hh aW5pbmcgZGF0YSBwbGFuZQ0KPj4gID4+ID4+bWVjaGFuaXNtcy4NCj4+ICA+PiA+PiBJdA0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2 YXJpb3VzIGNvbnRyb2wNCj4+ICA+PiA+Pm1lY2hhbmlzbXMsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgDQo+PnNjYWxl LW91dCwNCj4+ICA+PmFuZA0KPj4gID4+ID4+dm0NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZg0KPj4gID4+cGVybWl0 dGluZw0KPj4gID4+ID4+dGhpcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2Vs eSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4gID4+ID4+dGVybWlub2xv Z3kNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsg d2UgYXJlIHByb2hpYml0aW5nIGl0Lg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5n IGRvbmUgYnkNCj4+ICA+PnNlbGVjdGluZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFj a2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IA0KPj5kaXJlY3QNCj4+ICA+ PiA+PnRyYWZmaWMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFj ZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIA0KPj5yZXF1aXJlDQo+PiAgPj4gdGhhdA0KPj4gID4+ ID4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBh cHBlYXIgYXQgb25seSBvbmUgcGxhY2UgDQo+PmluDQo+PiAgPj50aGUNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhlc2Ug bWF5IGJlDQo+PiAgPj5jb21iaW5lZC4gSQ0KPj4gID4+ID4+IHRlbmQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFwcGVh ciB0byANCj4+c2VydmljZQ0KPj4gID4+ID4+Y2hhaW5pbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgDQo+PmNs dXN0ZXINCj4+ICA+PmlzDQo+PiAgPj4gPj5hDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBn b29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5vdGhlciANCj4+b25lLg0KPj4g ID4+IFRodXMsDQo+PiAgPj4gPj4gdGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2lu dCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0 cmFmZmljIHRvIGRpZmZlcmVudA0KPj4gID4+ID4+c2luZ3VsYXINCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgDQo+ PnBsYWNlcw0KPj4gID4+aW4NCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbmV0d29yay4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4gSSB0YWxr IA0KPj5hYm91dA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQg c2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIA0KPj5pcyBhDQo+PiAgPj4gPj4gc2VxdWVuY2UN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFw cGxpZWQgdG8gYSBzdWJzZXQgDQo+Pm9mDQo+PiAgPj4gPj5wYWNrZXRzLg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNl dCBvZg0KPj4gID4+dHJhZmZpYw0KPj4gID4+ID4+aXMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KPj4gID4+ ZmlyZXdhbGwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1 YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byANCj4+dGhlDQo+PiAgPj5jYWNoZQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGlu ZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0 aW9uIHRvIGRpcmVjdCB0aGUNCj4+ICA+PnBhY2tldHMuDQo+PiAgPj4gQQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVu Y2Ugb2YNCj4+ICA+PiA+PmxvY2F0aW9ucw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4g dGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9ucyB3aWxsIGJlIA0KPj5zaW5ndWxhciBvcg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZl cnkgbG9jYXRpb25zLiANCj4+VGhleQ0KPj4gID4+ID4+bWF5IGJlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2Vk IA0KPj5hcw0KPj4gID4+IHBvcnRzDQo+PiAgPj4gPj4gb24NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+ ICA+PiA+PmxvY2F0aW9ucw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3du IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIA0KPj5pbmZyYXN0cnVjdHVyZQ0KPj4gID4+IGFuZA0K Pj4gID4+ID4+IHRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9t IHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMNCj4+ICA+Pmdyb3VwLA0K Pj4gID4+ID4+IHdlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVs IGFic3RyYWN0aW9uLCANCj4+dGhlDQo+PiAgPj4gPj5zZXJ2aWNlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVl ZCANCj4+dG8NCj4+ICA+PiB0YWxrDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0 aGUgYWN0dWFsIGRhdGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiANCj4+dGhlDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUg c2FpZCAiYnV0IHRoZSB3aG9sZQ0KPj4gID4+IHBhdGgNCj4+ICA+PiA+PiBtYXkNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hp dGVjdHVyZSANCj4+ZGVhbHMNCj4+ICA+PiA+PndpdGgNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtIA0KPj4o MikNCj4+ICA+Pm9uDQo+PiAgPj4gPj5sb2FkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBi YWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kDQo+PiAgPj5iZWhhdmlv cnMNCj4+ICA+PiA+PiB3aGljaA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlz aWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyANCj4+bWVjaGFuaXNtcyAoaW4NCj4+ICA+PiA+ Pm11Y2gNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRn aW5nIHdpdGhpbiBhIExBTiBpcyANCj4+bGFyZ2VseQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+PiAgPj4g cHJvdmlzaW9uDQo+PiAgPj4gPj4gd2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2Ug aXMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPj4gID4+ ID4+IG5lY2Vzc2FyeS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJl Y3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgDQo+Pm9uDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9u DQo+PiAgPj5wb2ludC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUg DQo+PmFmdGVyLg0KPj4gID4+SWYgaXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMs IGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIA0KPj53b3JraW5nDQo+PiAg Pj4gPj4gZ3JvdXAsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJlIG91 dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIA0KPj5uZWVkZWQNCj4+ICA+PiB0bw0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRp c2FncmVlIHdpdGggDQo+PnRoZQ0KPj4gID4+ID4+IGludGVudCwNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSANCj4+ d29ya2luZw0KPj4gID4+ID4+Z3JvdXANCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVl bWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3QgDQo+PnN1cmUNCj4+ICA+ PiA+PndoYXQgdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBK b2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+ICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gID4+ID4+IHNmYw0KPj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgPj4gPj4gc2ZjDQo+PiAgPj4g Pj4gPj4+ID4+IG1haWxpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ICA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+IHNmYw0KPj4gID4+ ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgPj4gc2ZjDQo+PiAgPj4g Pj4gPj4+ID4+IG1haWxpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+IHNmYw0KPj4gID4+ID4+ID4+ PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ID4+IGxpc3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ICA+PiA+PiA+Pj4gbWFpbGlu Zw0KPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMN Cj4+ICA+PiA+PiBtYWlsaW5nDQo+PiAgPj4gPj4gPj4+ID4+IGxpc3QNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2ZjDQo+PiAgPj4gPj4gbWFpbGluZw0KPj4gID4+ID4+ID4+PiA+PiBsaXN0 DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ PiAgPj4gPj4gPj4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+ID4NCj4+ICA+PiA+PiA+Pj4gPj4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgPj4g Pj4gPj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ID5zZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+Pg0KPj4gID4+ID4+ ID4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gID4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+IHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICA+PiA+PiA+Pj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4NCj4+ICA+PiA+ PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ ICA+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPg0KPj4gID4+ID4+ID5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+ID5zZmMgbWFp bGluZyBsaXN0DQo+PiAgPj4gPj4gPnNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4N Cj4+ICA+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ ICA+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0K DQo= From nobody Mon Jul 14 08:22:56 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F41A0A8C for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:22:55 -0700 (PDT) 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 m5LZRnXum-d1 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:22:54 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601E01A0A86 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:22:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4102324730C for <sfc@ietf.org>; Mon, 14 Jul 2014 08:22:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BA89724678D for <sfc@ietf.org>; Mon, 14 Jul 2014 08:22:53 -0700 (PDT) Message-ID: <53C3F5CD.5080105@joelhalpern.com> Date: Mon, 14 Jul 2014 11:22:53 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" <sfc@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_4fPSsbFuNT7lyVMMwqaW81Vz30 Subject: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:22:55 -0000 In an earlier email I said: The way the draft uses the terms, and the way most discussions outside the IETF SFC working group use the term, a service function chain is something that you would discuss a policy about. Certain traffic from certain users is supposed to receive a certain sequence of services, the service chain. At the policy level, that does not care where in the network that is delivered. So as to allow control a level of influence, and to have flexibility to have multiple representations in the network of that policy construct, we have the intermediate notion of service function path. If the control system does not need to apply any influence, then it uses one service path for the service chain. If it needs a level of control, it instantiates a suitable number of service paths in the control system, and rules for how those are used. Then, the mapping in the SFF is based on that path, so as to enable the influence of the control system. While still allowing several other layers of traffic management as discussed. Yours, Joel To rephrase this a bit (and then if folks agree on the concept, we can pick the wording): The SFP provides a level of indirection between the fully abstract notion of service path as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF instance selection authority that is delegated to the network. Yours, Joel From nobody Mon Jul 14 08:23:35 2014 Return-Path: <jguichar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABD91A0A92 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 iqTpnZ8wu6Jy for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:23:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE1B1A0A86 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89832; q=dns/txt; s=iport; t=1405351404; x=1406561004; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zHi3Uq25++sbLxG4ZihHnUvkE7frpgv6n+QBfqhxGSQ=; b=k26WuMBBhRSiChhItXQAM+2JiFjCwWS+9qiikjWpsHwx9DTa0w0PYuuB CRc3zBQdeVRXsRPfmakSNQ3SgDQkvRwu0+R6+SS2bJ/5UkUj3cbs68dol BI39mVD76JPOsQYn+PxVBrjAM/sUQn2YU86Nil0v97Ncv4VQSvBSJtHFF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAL70w1OtJV2b/2dsb2JhbABPAQmDDlJagnGsIJI2CodDARl8FnWEAwEBAQMBAQEBFwEIBA0xAgcCFQQCAQYCEQECAQEBAQICIwMCAgIlCxQBAgYIAgQBEAIbiBMDCQgNlAOcKJdgF4EsiFKDIIFRAQQkCAULFgwCAgKCcYFMAQSWKkmEG4FKiiCININEQYEuQQ X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208";a="60679248" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 14 Jul 2014 15:23:21 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6EFNLGj029249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 15:23:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 10:23:21 -0500 From: "Jim Guichard (jguichar)" <jguichar@cisco.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2fhe0Et9lFor0W50lebJdLndpuf97aAgAAF3oD//8AygIAART8A//+92QA= Date: Mon, 14 Jul 2014 15:23:20 +0000 Message-ID: <CFE96D52.2E4D6%jguichar@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> 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.180] Content-Type: text/plain; charset="utf-8" Content-ID: <2CD2AACD423FD640BA9D5B08ADC80C17@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/M-SB0ueHFdhLhmvtX1qRTFyYtKA Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:23:32 -0000 TXkgcG9pbnQgUm9uIGlzIHRoYXQgc2V2ZXJhbCB0aW1lcyBpdCBoYXMgYmVlbiBhc3NlcnRlZCB0 aGF0IHRoZSBTRlAgbmVlZHMNCnRvIGJlIHByZS1pbnN0YW50aWF0ZWQ7IGFnYWluLCB3aGVyZSBk b2VzIGl0IHNheSB0aGF0IGFzIEkgY2Fu4oCZdCBzZWUgaXQ/DQoNCk9uIDcvMTQvMTQsIDExOjE5 IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3Rl Og0KDQo+SmltLA0KPg0KPkkgYW0gbm90IHdvcmRzbWl0aGluZyBoZXJlLCBidXQgcmF0aGVyIHF1 ZXN0aW9uaW5nIHNvbWUgZnVuZGFtZW50YWwNCj5hc3N1bXB0aW9ucy4NCj4NCj5UaGUgdmVyeSBl eGlzdGVuY2Ugb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBjb25jZXB0IGlzIGZ1bmRhbWVu dGFsIHRvDQo+dGhlIGFyY2hpdGVjdHVyZS4gICAgQXMgYW4gYW5hbG9neSwgaW4gYSB0cmFkaXRp b25hbCBMMyByb3V0ZWQgbmV0d29yaw0KPihleGNlcHRpbmcgb2JzY3VyZSBzb3VyY2Ugcm91dGlu ZyBvcHRpb25zKSwgb25lIGNvdWxkIHN0aWxsIG9ic2VydmUgdGhhdA0KPmEgcGFydGljdWxhciBm bG93IGlzIGZvbGxvd2luZyBhIHBhcnRpY3VsYXIgcGF0aCB0aHJvdWdoIHRoZSBuZXR3b3JrLCBi dXQNCj50aGF0IGlzIGluY2lkZW50YWwgdG8gdGhlIGFyY2hpdGVjdHVyZSByYXRoZXIgdGhhbiBm dW5kYW1lbnRhbCB0byB0aGUNCj5hcmNoaXRlY3R1cmUuDQo+DQo+ICAgUm9uDQo+DQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBb bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj5TZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQg MTE6MTIgQU0NCj5UbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgTHVjeSB5b25n OyBOQVBJRVJBTEEsIE1BUklBIEg7DQo+WHV4aWFvaHU7IG1pa2ViaWFuY0Bhb2wuY29tOyBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOw0KPmptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRm Lm9yZw0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2VydmljZSBD aGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPkJhbGFuY2Vycw0KPg0KPlF1ZXN0aW9uOiB3aGVyZSBl eGFjdGx5IGRvZXMgaXQgc3BlY2lmeSB0aGF0IHRoZSBTRlAgKm11c3QqIGJlDQo+cHJlLWluc3Rh bnRpYXRlZD8gV2hhdCBleGFjdGx5IGlzIHdyb25nIHdpdGggdGhlIHdvcmRpbmcg4oCcV2hlbiBh biBTRkMgaXMNCj5pbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpcyBuZWNlc3Nhcnkg dG8gc2VsZWN0IHRoZSBzcGVjaWZpYw0KPmluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVz ZWQsIGFuZCB0byBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yDQo+dGhhdCBTRkMgdXNp bmcgU0bigJlzIG5ldHdvcmsgbG9jYXRvcnPigJ0/IExldOKAmXMgdHJ5IHRvIGJlIHNwZWNpZmlj IHJhdGhlcg0KPnRoYW4gZGFuY2luZyBhcm91bmQgdGhlIHdvcmRpbmcuDQo+DQo+T24gNy8xNC8x NCwgMTE6MDAgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bT4NCj53cm90ZToNCj4NCj4+SGksIEpvZWwsDQo+Pg0KPj5JIHF1b3RlIGZyb20gdGhlIHRoZSBt ZXJnZWQgYXJjaGl0ZWN0dXJlIGRyYWZ0Og0KPj4NCj4+PGJlZ2luIHF1b3RhdGlvbj4NCj4+U2Vy dmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKTogIEEgc2VydmljZSBGdW5jdGlvbiBjaGFpbiBkZWZp bmVzIGFuDQo+PiAgICAgICAgb3JkZXJlZCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBt dXN0IGJlIGFwcGxpZWQgdG8gcGFja2V0cw0KPj4gICAgICAgIGFuZC9vciBmcmFtZXMgc2VsZWN0 ZWQgYXMgYSByZXN1bHQgb2YgY2xhc3NpZmljYXRpb24uICBUaGUNCj4+ICAgICAgICBpbXBsaWVk IG9yZGVyIG1heSBub3QgYmUgYSBsaW5lYXIgcHJvZ3Jlc3Npb24gYXMgdGhlDQo+PiAgICAgICAg YXJjaGl0ZWN0dXJlIGFsbG93cyBmb3Igbm9kZXMgdGhhdCBjb3B5IHRvIG1vcmUgdGhhbiBvbmUg YnJhbmNoLg0KPj4gICAgICAgIFRoZSB0ZXJtIHNlcnZpY2UgY2hhaW4gaXMgb2Z0ZW4gdXNlZCBh cyBzaG9ydGhhbmQgZm9yIHNlcnZpY2UNCj4+ICAgICAgICBmdW5jdGlvbiBjaGFpbi4NCj4+DQo+ PiAgIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKTogIFRoZSBpbnN0YW50aWF0aW9uIG9mIGFu IFNGQyBpbiB0aGUNCj4+ICAgICAgICBuZXR3b3JrLiAgUGFja2V0cyBmb2xsb3cgYSBzZXJ2aWNl IGZ1bmN0aW9uIHBhdGggZnJvbSBhDQo+PiAgICAgICAgY2xhc3NpZmllciB0aHJvdWdoIHRoZSBy ZXF1aXNpdGUgc2VydmljZSBmdW5jdGlvbnMNCj4+DQo+PldoZW4gYW4gU0ZDIGlzIGluc3RhbnRp YXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzIG5lY2Vzc2FyeSB0bw0KPj4gICBzZWxlY3QgdGhl IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0byBjcmVh dGUNCj4+ICAgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MgbmV0 d29yayBsb2NhdG9yLiAgVGh1cywNCj4+ICAgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3Vs dHMgaW4gdGhlIGNyZWF0aW9uIG9mIGEgU2VydmljZQ0KPj4gIEZ1bmN0aW9uIFBhdGggKFNGUCkg YW5kIGlzIHVzZWQgZm9yIGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdoIHRoZQ0KPj4gICBTRkMu ICBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZSBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZp bmVkIFNGQy4NCj4+DQo+PihTZWN0aW9uIDQuMyBTRkYpDQo+PlNGUCBmb3J3YXJkaW5nIGluZm9y bWF0aW9uIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyDQo+PiAg IHRoYXQgaXMgdXNlZCB0byB1bmlxdWVseSBpZGVudGlmeSBhbiBTRlAuDQo+PjxlbmQgcXVvdGF0 aW9uPg0KPj4NCj4+DQo+Pk15IHJlYWRpbmcgb2YgdGhlIFNlY3Rpb24gNC4zLCBnaXZlbiB0aGUg ZGVmaW5pdGlvbnMgcHJlc2VudGVkIGJlZm9yZSBpdCwNCj4+aXMgdGhhdCBhbiBlbmQtdG8tZW5k IGZ1bGx5IGluc3RhbnRpYXRlZCBwYXRoIGlzIHNlbGVjdGVkIGFuZCB0aGVuIHVzZWQNCj4+dG8g c3RlZXIgdHJhZmZpYyB0byB0aGUgcmVxdWlzaXRlIFNGRidzIGFuZCBTRidzLiAgIFdoaWxlIHRo b3NlDQo+PmRlZmluaXRpb25zIGNvdWxkIHN0aWxsIGFwcGx5LCBldmVuIGluIGEgZGlzdHJpYnV0 ZWQgaW5zdGFuY2UgYXNzaWdubWVudA0KPj5hcHByb2FjaCwgdGhlIGNvbnRleHQgYXJvdW5kIHRo b3NlIGRlZmluaXRpb25zIGNoYW5nZS4gICBBIHBhcnRpY3VsYXINCj4+ZmxvdyB3b3VsZCwgaW5k ZWVkIHN0aWxsIGZvbGxvdyBzb21lIHBhcnRpY3VsYXIgcGF0aCwgYnV0IHRoZXJlIHdvdWxkIGJl DQo+Pm5vIG5lZWQgdG8gYXNzb2NpYXRlIGEgcGF0aCBJRCB0byBpdCBhbmQgdGhlcmUgd291bGQg YmUgbm8gbmVlZCB0bw0KPj4obGF0ZXIpIGJ1aWxkIGEgY29udHJvbCBwbGFuZSBhcm91bmQgZGlz dHJpYnV0aW9uIG9mIHRoaXMgcGF0aCBJRCBhbmQNCj4+bWFpbnRlbmFuY2Ugb2YgdGhvc2UgcGF0 aCBJRHMgaW4gdGhlIGZhY2Ugb2YgaW5ldml0YWJsZSBmYWlsdXJlcy4NCj4+DQo+PkkgYW0gZXhw bG9yaW5nIHRoZSBhbHRlcm5hdGl2ZSB3aGVyZSBmb3J3YXJkaW5nIGlzIHBlcmZvcm1lZCBiYXNl ZCBvbiB0aGUNCj4+YWJzdHJhY3QgU0ZDIElEIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBjb25jZXB0 IG9mIGEgY2VudHJhbGx5IGtub3duIFNGUCB0bw0KPj5leGlzdCBhdCBhbGwuICAgSW4gdGhpcyBh bHRlcm5hdGl2ZSBhcHByb2FjaCwgdGhlIGluc3RhbmNlIHNlbGVjdGlvbiBpcw0KPj5kaXN0cmli dXRlZCB0byB0aGUgY2xhc3NpZmllciBhbmQgdGhlIFNGRidzLiAgIEFueSBkZXNpcmVkIHBvbGlj eSB1c2VkIHRvDQo+PmZsYXZvciBpbnN0YW5jZSBzZWxlY3Rpb24gaXMgc3RpbGwgc3VwcG9ydGVk LCBidXQgc3VjaCBwb2xpY3kgd291bGQsDQo+PmluZGVlZCwgbmVlZCB0byBiZSBhdmFpbGFibGUg dG8gdGhlIGludm9sdmVkIGVudGl0aWVzLiAgIFRoaXMgd291bGQgYWxzbw0KPj5iZSBhbiBleGNl bGxlbnQgdXNlIG9mIG1ldGFkYXRhIHdoZXJlIHRoZSBpbml0aWFsIGluZ3Jlc3Mgbm9kZSBjb3Vs ZCBhZGQNCj4+b25lIG9yIG1vcmUgcGllY2VzIG9mIG1ldGFkYXRhIHRoYXQgZG93bnN0cmVhbSBu b2RlcyBjb3VsZCBtYWtlIHVzZSBvZiBpbg0KPj50aGVpciBwb2xpY3kgZGVjaXNpb25zLg0KPj4N Cj4+ICAgIFJvbg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206 IEpvZWwgSGFscGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0N Cj4+U2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDEwOjM5IEFNDQo+PlRvOiBMdWN5IHlvbmc7 IE5BUElFUkFMQSwgTUFSSUEgSDsgUm9uIFBhcmtlcjsgWHV4aWFvaHU7DQo+Pm1pa2ViaWFuY0Bh b2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207 DQo+PmptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW3Nm Y10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQN Cj4+QmFsYW5jZXJzDQo+Pg0KPj5DYW4gd2UgZmlyc3QgZmlndXJlIG91dCB3aGF0IHdlIG1lYW4g YnkgYSBzZXJ2aWNlIHBhdGg/DQo+Pk9uY2Ugd2UgaGF2ZSB0aGF0LCBJIGJlbGlldmUgd2UgY2Fu IHdvcmsgb3V0IHdoYXQgd2Ugd2FudCB0aGUNCj4+YXJjaGl0ZWN0dXJlIHRvIHJlcXVpcmUgb2Yg c29sdXRpb25zIGluIHRlcm1zIG9mIGNhcnJ5aW5nIGluZm9ybWF0aW9uIGluDQo+PnRoZSBwYWNr ZXQuICBCdXQgc2luY2UgZm9sa3MgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIGV4aXN0aW5nIGRlZmlu aXRpb25zDQo+PmFuZCBjb21pbmcgdG8gZGlmZmVyZW50IG1lYW5pbmdzLCBhbmQgaGF2ZSBiZWVu IG5vdGluZyBjb3JyZWN0bHkNCj4+Y29udHJhZGljdGlvbnMgaW4gdGhlIHdvcmRzIHdlIGNob3Nl IGZvciB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiwgSQ0KPj53b3VsZCByZWFsbHkgYXBwcmVjaWF0 ZWQgaXQgaWYgZm9sa3Mgd291bGQgY29tbWVudCBvbiB0aGUgZGVmaW5pdGlvbiBvZg0KPj5zZXJ2 aWNlIGZ1bmN0aW9uIHBhdGggdGhhdCBJIHNlbnQgdG8gdGhlIGxpc3QuDQo+Pg0KPj5Zb3VycywN Cj4+Sm9lbA0KPj4NCj4+T24gNy8xNC8xNCwgOTozMCBBTSwgTHVjeSB5b25nIHdyb3RlOg0KPj4+ IENvbnF1ZXIgd2hhdCBNYXJpYSBzYXlzLg0KPj4+DQo+Pj4gTHVjeQ0KPj4+DQo+Pj4gKkZyb206 KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpOQVBJRVJB TEEsDQo+Pj5NQVJJQSBIDQo+Pj4gKlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMTQgODoyMSBB TQ0KPj4+ICpUbzoqIFJvbiBQYXJrZXI7IFh1eGlhb2h1OyBtaWtlYmlhbmNAYW9sLmNvbTsgamd1 aWNoYXJAY2lzY28uY29tOw0KPj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGptaEBq b2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KPj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFJl ZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj4+IExvYWQg QmFsYW5jZXJzDQo+Pj4NCj4+PiBUaGUgbWVhbmluZyBvZiB0aGUgU0ZQIElEIGlzIHByZXR0eSBj bGVhciwgYXQgbGVhc3QgdG8gbWUg4oCTIGFuIGFic3RyYWN0DQo+Pj4gaWRlbnRpdHkgZm9yIHRo ZSBleGFjdCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgKGkuZS4sIFNGUCBJRA0K Pj4+MQ0KPj4+ID0ge1NGLUEtMSwgU0YtQi0zLCBTRi1DLTJ9KS4gICAgSW4gc29tZSB3YXlzLCBp dCBpcyBhIGNvbGxhcHNlZCDigJxsYWJlbA0KPj4+IHN0YWNr4oCdIOKAkyB0aGVyZSBpcyBhIHNp bmdsZSB0YWcgaW1wbHlpbmcgc29tZSBzZXF1ZW5jZSBvZiBuZXR3b3JrDQo+Pj4gbG9jYXRpb25z LiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxlYXN0IHRvIG1lLCB0aGF0IHRoZXJlIGlz IGENCj4+PiBjZW50cmFsIHBvaW50IG9mIHNlbGVjdGlvbiBmb3IgdGhpcyBlbmQgdG8gZW5kIHNl cXVlbmNlIChiYXJyaW5nDQo+Pj4gcmVjbGFzc2lmaWNhdGlvbiwgb2YgY291cnNlKS4gICBJLCBm b3Igb25lLCBhbSBxdWVzdGlvbmluZyB0aGF0DQo+Pj4gaW1wbGljYXRpb24uICAgIEkgaGF2ZSBi ZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRyYWwgcG9pbnQNCj4+PiBtZXRob2RvbG9n eSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2YgZHluYW1pYyBzY2FsZSBhbmQNCj4+ PiB0aW1lbGluZXNzIG9mIHJlYWN0aW9uIHRvIGZhaWx1cmVzLg0KPj4+DQo+Pj4gPE1hcmlhPiBJ IGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0dXJl IHRoYXQNCj4+PiBzb21ldGhpbmcgY2FsbGVkIOKAnHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBJROKA nSBpcyBjYXJyaWVkIGluIHRoZSBwYWNrZXQsDQo+Pj4gYmVjYXVzZSBpdCBpcyBub3QgbmVjZXNz YXJ5IG9yIHRoZSBvbmx5IHdheSB0byBpbXBsZW1lbnQgc2VydmljZQ0KPj4+IGNoYWluaW5nLiBU aGVyZSBtaWdodCBzb2x1dGlvbnMgdGhhdCB3b3VsZCBkbyB0aGF0IGJ1dCBpdCBjYW5ub3QgYW5k DQo+Pj4gZG9lc27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQuDQo+Pj4NCj4+PiBNYXJpYQ0KPj4+ DQo+Pj4gQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNlIGNlbnRyYWwgc2Vs ZWN0aW9uIHRvIHNlbGVjdCB0aGUNCj4+PiBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNlIGZ1bmN0 aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwNCj4+PiBTRi1DfSksIGJ1dCBhbGxv dyB0aGUgYWN0dWFsIGluc3RhbmNlIHNlbGVjdGlvbiB0byBiZSBkaXN0cmlidXRlZCwNCj4+PiBy ZWFsaXplZCBieSB0aGUgY2xhc3NpZmllciBhbmQgdGhlIFNGRnMuDQo+Pj4NCj4+PiBHaXZlbiBh IHRvcG9sb2d5IGxpa2U6DQo+Pj4NCj4+PiBDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0tLS0t LS0tLS0tLS0tLS0tLS0tIFNGRi0yDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTMtLS0t LS0tLS0tLS0tLS0tLS0tU0ZGLTQNCj4+Pg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgIHwNCj4+PiAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+Pj4NCj4+PiAgICAgICAgICAgICAgICAgICAgICBTRkYtQS0xICAgICAgIFNGRi1B LTIgICAgICAgU1NGLUItMQ0KPj4+IFNGRi1CLTIgICAgICAgICBTRkYtQy0xICAgICAgIFNGRi1D LTIgICAgICAgICAgICAgICAgICAgU0ZGLUEtMw0KPj4+DQo+Pj4gQW5kIGFzc3VtaW5nIGEgbmV3 bHkgcmVjb2duaXplZCBmbG93LCB0aGUgc2VxdWVuY2UgY291bGQgZ28gc29tZXRoaW5nDQo+Pj4g bGlrZSB0aGlzOg0KPj4+DQo+Pj4gMSBDbGFzc2lmaWVyIHNlbGVjdHMgY2hhaW4gU0ZDIElEIDEg e1NGLUEsIFNGLUIsIFNGLUN9DQo+Pj4NCj4+PiAyIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBh cyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1BDQo+Pj4NCj4+PiAzIENsYXNz aWZpZXIgZW5jYXBzdWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2Vydmlj ZSBpbmRleA0KPj4+PSAxDQo+Pj4NCj4+PiA0IENsYXNzaWZpZXIgcHJvZ3Jlc3NlcyBwYWNrZXQg dG8gU0ZGLTENCj4+Pg0KPj4+IDUgU0ZGLTEsIHNlZWluZyBjaGFpbiBJRD0xLCBzZXJ2aWNlIGlu ZGV4PTEsIGNob29zZXMgU0ZGLUEtMiBhbW9uZ3N0DQo+Pj5pdHMNCj4+PiBhdmFpbGFibGUgaW5z dGFuY2VzIG9mIFNGLUENCj4+Pg0KPj4+IDYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTEN Cj4+Pg0KPj4+IDcgU0ZGLUEtMSBzZW5kcyBwYWNrZXQgYmFjayB0byBTRkYtMQ0KPj4+DQo+Pj4g OCBTRkYtMSBpbmNyZW1lbnRzIHNlcnZpY2UgaW5kZXggdG8gMg0KPj4+DQo+Pj4gOCBTRkYtMSBz ZWxlY3RzIFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUINCj4+ Pg0KPj4+IDkgU0ZGLTEgcHJvZ3Jlc3NlcyBwYWNrZXQgdG8gU0ZGLTINCj4+Pg0KPj4+IDEwIHBy b2Nlc3MgcmVwZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMsIGFzIHRoZSBlZ3Jlc3MgYm9yZGVy LA0KPj4+IHByb2dyZXNzZXMgdGhlIHBhY2tldCBwZXIgcm91dGluZyB0YWJsZQ0KPj4+DQo+Pj4g VGhhbmtzLg0KPj4+DQo+Pj4gICAgIFJvbg0KPj4+DQo+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpYdXhpYW9odQ0KPj4+ICpTZW50Oiog U3VuZGF5LCBKdWx5IDEzLCAyMDE0IDExOjMwIFBNDQo+Pj4gKlRvOiogbWlrZWJpYW5jQGFvbC5j b20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbQ0KPj4+IDxt YWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgbW4xOTIxQGF0dC5jb20gPG1haWx0bzptbjE5MjFA YXR0LmNvbT47DQo+Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8bWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+Ow0KPj4+IGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtlcjsNCj4+PiBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gKlN1YmplY3Q6KiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQ Ly9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4+IEJhbGFuY2Vycw0KPj4+ DQo+Pj4gQWdyZWUgdGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAgaW4gdGhl IGFyY2ggZHJhZnQgaXMgYSBiaXQNCj4+PmNvbmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBoYWQg cG9pbnRlZCBvdXQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhl IFNGUCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUNCj4+Pm5ldHdvcmsgc2hv dWxkIGJlIOKAnGFuIG9yZGVyZWQgbGlzdCBvZiBzZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0o c2VlDQo+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJh c2VkLXNmYy1hcmNoLTAxKS4gT2YNCj4+PmNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQ IGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nDQo+Pj4oZS5nLiwgZWl0aGVyIHRo cm91Z2ggYSBwYXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBsYWJlbCBzdGFjaykuIEhlcmUNCj4+ PnRoZSBzZXJ2aWNlIG5vZGUgbWVhbnMgdGhlIGRldmljZSB3aGljaCBjb250YWlucyB0aGUgU0ZG IGFuZCB0aGUgTkYNCj4+PmNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0 aGUgU0YgYW5kIFNGIHByb3h5IGNvbXBvbmVudHMNCj4+Pm9wdGlvbmFsbHkuIFRoZSBzZXJ2aWNl IG5vZGUgY291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aCBtdWx0aXBsZQ0KPj4+U0Yg aW5zdGFuY2VzIGFuZCB0aG9zZSBTRiBpbnN0YW5jZXMgY291bGQgYmUgb2YgdGhlIHNhbWUgU0Yg dHlwZSBvciBub3QuDQo+Pj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIFNG IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlDQo+Pj4oZS5nLiwgU0YgWCkgYXJlIGF0dGFj aGVkIHRvIGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlDQo+Pj5jb3VsZCBk aXN0cmlidXRlIHRoZSB0cmFmZmljIHdoaWNoIG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5z dGFuY2VzDQo+Pj5vZiBTRiBYIHR5cGUgbG9jYWxseS4gTWVhbndoaWxlLCB0aGVyZSBtYXkgYmUg bXVsdGlwbGUgc2VydmljZSBub2Rlcw0KPj4+d2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQgZG9t YWluIHdoaWNoIGFyZSBlbWJlZGRlZCBvciBhdHRhY2hlZCB3aXRoDQo+Pj50aGUgU0YNCj4+ICBp bnN0YW5jZQ0KPj5zIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5LCB0aGUgU0YgbG9h ZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZQ0KPj52ZXJ5IGZsZXhpYmxlLg0KPj4+DQo+Pj4gQmVz dCByZWdhcmRzLA0KPj4+DQo+Pj4gWGlhb2h1DQo+Pj4NCj4+PiAqRnJvbToqc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4+PiAqbWlrZWJpYW5jQGFvbC5j b20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCj4+PiAqU2VudDoqIFNhdHVyZGF5LCBKdWx5 IDEyLCAyMDE0IDI6NDYgQU0NCj4+PiAqVG86KiBqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNvbQ0KPj4+IDxtYWlsdG86bW4xOTIxQGF0 dC5jb20+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gPG1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+ PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+OyBzZmNAaWV0Zi5vcmcN Cj4+PjxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4NCj4+PiBXb3VsZG4ndCB0 aGF0IGJlIGNhbGxlZCB0aGUgInNlcnZpY2UgY2hhaW4gaWRlbnRpZmllciIgdGhlbj8gIElmIHRo ZQ0KPj4+IHNlcnZpY2UgY2hhaW4gaXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5kIHRoZSBz ZXJ2aWNlIHBhdGggaXMgdGhlDQo+Pj4gb3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywgdGhl biBJIHdvdWxkIGluZmVyIHRoYXQgYSAic2VydmljZSBwYXRoDQo+Pj4gaWRlbnRpZmllciIgd291 bGQgYmUgYW4gaWRlbnRpZmllciBmb3IgYSBzZXJ2aWNlICpwYXRoKiwgbm90IGEgc2VydmljZQ0K Pj4+ICpjaGFpbiouDQo+Pj4NCj4+Pg0KPj4+IEFnYWluLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUg dGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBpbi4gIFRoZQ0KPj4+dGVybXMNCj4+PiAiY2hh aW4iIGFuZCAicGF0aCIgc2VlbSBpbmNvbnNpc3RlbnQuDQo+Pj4NCj4+PiANCj4+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+DQo+Pj4gKkZyb206ICpqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJAY2lz Y28uY29tDQo+Pj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5j b20+Pg0KPj4+ICpUbzoNCj4+PiANCj4+PiptaWtlYmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9s LmNvbT4sbW4xOTIxQGF0dC5jb208bW4xOTIxQGF0dC5jb20+LG1vaA0KPj4+YQ0KPj4+bWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2Vs aGFscGVybi5jDQo+Pj5vDQo+Pj5tPGptaEBqb2VsaGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBhZmZpcm0NCj4+PmUNCj4+PmRuZXR3b3Jrcy5j b20+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4+PiANCj4+PjxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20lM2NtaWtlYmlhbmNAYW9sLmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21uMTkyMQ0K Pj4+QA0KPj4+YXR0LmNvbSUzZSxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTNjbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzDQo+Pj5lDQo+Pj4sam1oQGpvZWxoYWxwZXJuLmNvbSUz Y2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmsNCj4+PnMN Cj4+Pi5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJTNlLHNmY0BpZXRmLm9y ZyUzY3NmY0BpZXRmLm9yZz4+DQo+Pj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkgMTEsIDIwMTQNCj4+ PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPj4+DQo+Pj4gWW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3Jy ZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoDQo+Pj4gdGhyb3VnaCB3aGljaCB0cmFmZmlj IHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyDQo+Pj4gaG93 ZXZlciBwb2ludHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1cmUgYW5kIHRoYXQg aXMgdGhlbg0KPj4+IHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdo aWNoIG5leHQtaG9wcyB0byB0aG9zZQ0KPj4+IGluc3RhbmNlcyBhcmUgYXZhaWxhYmxlIGFuZCB3 aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4NCj4+PiBwbGF5LiBXaGVu IGluc3RhbnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0aGUgbmV0d29yayB5b3UgbWF5 IG9yDQo+Pj4gbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5IHdo aWNoIG5leHQtaG9wcyBtYXkgYmUNCj4+PiB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3 b3VsZCBlZmZlY3RpdmVseSBuYWlsIHVwIHRoZSBzZXJ2aWNlDQo+Pj5wYXRoDQo+Pj4gZm9yIHRo YXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90 b2NvbCAvDQo+Pj4gbWVjaGFuaXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZSBmb3Ig eW91Lg0KPj4+DQo+Pj4gKkZyb206ICoibWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlh bmNAYW9sLmNvbT4iDQo+Pj4gPG1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20+Pg0KPj4+ICpEYXRlOiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNDQo+ Pj4gKlRvOiAqSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hh ckBjaXNjby5jb20+PiwNCj4+PiAibW4xOTIxQGF0dC5jb20gPG1haWx0bzptbjE5MjFAYXR0LmNv bT4iIDxtbjE5MjFAYXR0LmNvbQ0KPj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgIm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tDQo+Pj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiINCj4+PiA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPj4+IDxtYWlsdG86Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4+LCAic2ZjQGlldGYub3JnDQo+Pj4gPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IiA8c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4+PiAqU3ViamVj dDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K Pj4+DQo+Pj4gSSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRoZSBjb25mdXNpb246DQo+Pj4N Cj4+Pj4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0KPj4+PiBzcGVjaWZpYyBpbnN0YW5jZXMg b2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRpb24gdGhlcmVvZikuIEkNCj4+Pj4g YXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5 IHBvaW50cyB0bw0KPj4+PlMxLT5TMi0+UzMNCj4+Pj4gYW5kIHRoZW4gcHVzaCB0aGlzIGludG8g dGhlIG5ldHdvcmsNCj4+Pg0KPj4+IEJ5IGRlZmluaXRpb24sIEkgdW5kZXJzdG9vZCBhICJzZXJ2 aWNlIHBhdGgiIHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZg0KPj4+IHNwZWNpZmljIFNGIGluc3Rh bmNlcy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91IHVzZSBhICJzZXJ2aWNlIHBhdGgNCj4+ PiBpZGVudGlmaWVyIiB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmlj YWxseSAiW2RvZXMgbm90XQ0KPj4+IHNwZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzIi4NCj4+Pg0K Pj4+IA0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiAqRnJvbTogKmpndWljaGFyQGNpc2Nv LmNvbQ0KPj4+IDxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjxqZ3VpY2hhckBjaXNjby5jb20N Cj4+PjxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPj4NCj4+PiAqVG86ICpOQVBJRVJBTEEsIE1B UklBIEg8bW4xOTIxQGF0dC5jb20NCj4+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT48bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LEpvZWwgTS4NCj4+PiBIYWxwZXJuPGptaEBqb2VsaGFs cGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sUm9uDQo+Pj4gUGFya2VyPFJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmcNCj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz48c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4+PiAqU2VudDogKkZyaWRh eSwgSnVseSAxMSwgMjAxNA0KPj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4NCj4+PiBNYXJpYSwNCj4+Pg0KPj4+IEkg dGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1w bHkgYSBwb2ludGVyDQo+Pj50bw0KPj4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBT RiB0byBuZXh0LWhvcCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lDQo+Pj5hDQo+Pj4gY2hhaW4s IGxldOKAmXMgc2F5IFMxIC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUg U0ZQDQo+Pj5zcGVjaWZ5DQo+Pj4gdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50 IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0DQo+Pj5TRlAuDQo+Pj4gSG93ZXZlciwg eW91IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRw b2ludA0KPj4+KEkNCj4+PiB3aWxsIGFyZ3VlIHRoYXQgeW91IHNob3VsZCBidXQgeW91IGRvbuKA mXQgaGF2ZSB0byBhcmNoaXRlY3R1cmFsbHkpLiBZb3UNCj4+PiBjb3VsZCBzaW1wbHkgYXNzaWdu IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMNCj4+PmFu ZA0KPj4+IHRoZW4gcHVzaCB0aGF0IGluZm9ybWF0aW9uIGludG8gdGhlIG5ldHdvcmsuIEF0IHRo ZSBTRkYgaXQgd2lsbCBoYXZlIGENCj4+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMg bWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4NCj4+PnRoZQ0KPj4+IG5leHQt aG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhlIFNG4oCZcyB3aXRoaW4gdGhlIFNGQyAtIGhv dyB5b3UgbGVhcm4NCj4+PiB0aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQg cHVzaCB0aGVtIGRvd24gZnJvbSBhDQo+Pj5jZW50cmFsaXplZA0KPj4+IGNvbnRyb2xsZXIsIGNv bmZpZ3VyZSB0aGVtIHRocm91Z2ggQ0xJLCBsZWFybiB0aGVtIGR5bmFtaWNhbGx5IHRocm91Z2gN Cj4+PiBzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3aGF0ZXZlciAuLiBTbywgZ2l2ZW4gdGhpcyBp dCBpcyBub3QgY29ycmVjdCB0bw0KPj4+IHNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMg dGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYQ0KPj4+cHJpb3JpDQo+Pj4gYWx0aG91 Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxkIHNheSByZWNvbW1l bmRlZCkgdG8NCj4+PmRvDQo+Pj4gc28uDQo+Pj4NCj4+PiBMZXTigJlzIHRha2UgYW4gZXhhbXBs ZSB0byBob3BlZnVsbHkgbWFrZSB0aGlzIGNsZWFyOg0KPj4+DQo+Pj4gSSBkZWZpbmUgYW4gU0ZD IChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRz DQo+Pj4gc2FrZSBsZXTigJlzIHNheSBJIHdhbnQgaXQgdG8gYmUgZnVsbHkgZHluYW1pYyBlLmcu IEkgZG9u4oCZdCB3YW50IHRvDQo+Pj5zcGVjaWZ5DQo+Pj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9m IFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQo+Pj4gYXNz aWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBv aW50cyB0bw0KPj4+UzEtPlMyLT5TMw0KPj4+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBu ZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQo+Pj4gcG9wdWxhdGVk IHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMN Cj4+PmFycml2ZXMNCj4+PiB3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNG RiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0KPj4+IHN0cnVjdHVyZSBhbmQgZmluZCB0 aGF0IGl0IHBvaW50cyB0byBTMS0+UzItPlMzIGFuZCB0aGUgaW5kZXggaW4gdGhlDQo+Pj5TRkMN Cj4+PiBlbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRo ZSBjaGFpbi4gTGV04oCZcyBzYXkNCj4+PndlDQo+Pj4gYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4g VGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJlc29sdmUgdGhlIG5leHQtaG9wDQo+Pj50bw0KPj4+ IFMzIGFuZCB3aWxsIGRvIGEgbG9va3VwIHRvIGRldGVybWluZSB3aGVyZSBTMyBpcyByZWFjaGFi bGUuDQo+Pj4NCj4+PiBPbiA3LzExLzE0LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIg PG1uMTkyMUBhdHQuY29tDQo+Pj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPj4+ DQo+Pj4gID5KaW0sDQo+Pj4gID4NCj4+PiAgPkNvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhl IGRlZmluaXRpb24gb2YgYSAic2VydmljZSBwYXRoIiBhbmQgYQ0KPj4+ICA+InNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIj8NCj4+PiAgPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNG IGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkNCj4+Pih3aGljaA0KPj4+ICA+aXMgbXkgY3Vy cmVudCB1bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbg0K Pj4+d2hpY2gNCj4+PiAgPm5leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVk IGRlY2lzaW9uLg0KPj4+ICA+DQo+Pj4gID5NYXJpYQ0KPj4+ICA+DQo+Pj4gID4NCj4+PiAgPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiAgPj4NCj4+Pg0KPj4+IEZyb206IEppbSBH dWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPj4+ICA+PiBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+PiAgPj4gVG86IE5BUElFUkFM QSwgTUFSSUEgSDsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IEpvZWwgTS4NCj4+PiAgPj4gSGFscGVybjsgUm9u IFBhcmtlcjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiBTdWJq ZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4+PiAgPj4NCj4+PiAgPj4gSeKAmW0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJz dGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgNCj4+PmlkZW50aWZpZXINCj4+PiAgPj4gcHJldmVudHMg ZnVsbCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBjYWxsaW5nIGl0IGENCj4+ PnNlcnZpY2UNCj4+PiAgPj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT8N Cj4+PiAgPj4NCj4+PiAgPj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbQ0KPj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToN Cj4+PiAgPj4NCj4+PiAgPj4gPkRpdHRvLg0KPj4+ICA+PiA+DQo+Pj4gID4+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gID4+ID4+IEZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+Pj4g ID4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+PiAgPj4gPj4g U2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+Pj4gID4+ID4+IFRvOiBKaW0g R3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uDQo+Pj5IYWxw ZXJuOyBSb24NCj4+PiAgPj4gPj4gUGFya2VyOyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+Pj4gID4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ICA+PiA+Pg0KPj4+ICA+PiA+PiBSZS0sDQo+Pj4g ID4+ID4+DQo+Pj4gID4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90 IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPj4+ICA+PmRyYWZ0Lg0KPj4+ICA+PiA+Pg0KPj4+ ICA+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYg YSBoaW50IHRoYXQgdGhlDQo+Pj5mdWxsDQo+Pj4gID4+ID4+ZGlzdHJpYnV0ZWQNCj4+PiAgPj4g Pj4gbW9kZWwgaXMgbm90IGFsbG93ZWQuDQo+Pj4gID4+ID4+DQo+Pj4gID4+ID4+IFNldmVyYWwg dm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluDQo+ Pj5pdHNlbGYNCj4+PiAgPj4gPj5zaG91bGQgYmUNCj4+PiAgPj4gPj4gcHJvdmlkZWQgaW5zdGVh ZC4NCj4+PiAgPj4gPj4NCj4+PiAgPj4gPj4gQ2hlZXJzLA0KPj4+ICA+PiA+PiBNZWQNCj4+PiAg Pj4gPj4NCj4+PiAgPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+ICA+PiA+ PiA+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBK aW0NCj4+Pkd1aWNoYXJkDQo+Pj4gID4+ID4+ID4oamd1aWNoYXIpDQo+Pj4gID4+ID4+ID5FbnZv ecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE2OjE4DQo+Pj4gID4+ID4+ID7DgCA6IE5B UElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPj4+IHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4gPj4gPk9iamV0IDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gID4+ID4+ ID4NCj4+PiAgPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmlj YWxseSBpcyB0aGlzDQo+Pj5mdW5jdGlvbmFsaXR5DQo+Pj4gID4+ID4+ID5wcm9oaWJpdGVkPyBJ ZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKg0KPj4+U0ZG 4oCZcw0KPj4+ICA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUg cGF0aCBpZGVudGlmaWVyIHBvaW50IHRvDQo+Pj5hDQo+Pj4gID4+ID4+bG9va3VwDQo+Pj4gID4+ ID4+ID5pbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hh aW4sIEkgYW0NCj4+Pm5vdA0KPj4+ICA+PnN1cmUNCj4+PiAgPj4gPj5ob3cNCj4+PiAgPj4gPj4g PnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+PiAgPj4gPj4gPg0KPj4+ICA+PiA+ PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQu Y29tDQo+Pj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQo+Pj4gID4+IHdyb3RlOg0KPj4+ICA+ PiA+PiA+DQo+Pj4gID4+ID4+ID4+QWJzb2x1dGVseS4NCj4+PiAgPj4gPj4gPj4NCj4+PiAgPj4g Pj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gID4+ID4+ID4+PiBGcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj4+R3Vp Y2hhcmQNCj4+PiAgPj4gPj4gPj4+KGpndWljaGFyKQ0KPj4+ICA+PiA+PiA+Pj4gU2VudDogRnJp ZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+PiAgPj4gPj4gPj4+IFRvOiBOQVBJRVJBTEEs IE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4+PiBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+PiAgPj4gPj4gPj4+ DQo+Pj4gID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4u IEhvd2V2ZXIsIGl0IHNlZW1zDQo+Pj50byBtZQ0KPj4+ICA+PiA+PnRoYXQgaWYNCj4+PiAgPj4g Pj4gPj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJl bW90ZSBTRkYNCj4+Pml0DQo+Pj4gID4+d2lsbA0KPj4+ICA+PiA+PnVzZQ0KPj4+ICA+PiA+PiA+ Pj5mb3INCj4+PiAgPj4gPj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3 aXRoaW4gdGhlIGNoYWluIHRoZW4geW91DQo+Pj4gID4+YmV0dGVyDQo+Pj4gID4+ID4+bWFrZQ0K Pj4+ICA+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2Fy eSBmb3J3YXJkaW5nIGxvZ2ljDQo+Pj50bw0KPj4+ICA+PiA+PnJlYWNoDQo+Pj4gID4+ID4+ID4+ PnRoZQ0KPj4+ICA+PiA+PiA+Pj4gbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3 aXNlIHlvdSBhcmUgaW4gZGVlcA0KPj4+dHJvdWJsZS4NCj4+PiAgPj4gPj4gPj4+DQo+Pj4gID4+ ID4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIx QGF0dC5jb20NCj4+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+PiAgPj4gPj4gd3JvdGU6 DQo+Pj4gID4+ID4+ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2aWNl IGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9ubHkgaW4NCj4+PiAgPj5yZWxldmFudA0KPj4+ ICA+PiA+PiA+Pj5TRkZzDQo+Pj4gID4+ID4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4+ ICA+PiA+PiA+Pj4gPg0KPj4+ICA+PiA+PiA+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PiAgPj4gPj4gPj4+ID4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+Pj4gID4+R3VpY2hhcmQNCj4+PiAgPj4gPj4gPj4+ID4+ KGpndWljaGFyKQ0KPj4+ICA+PiA+PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0 IDk6MjcgQU0NCj4+PiAgPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJr ZXI7IHNmY0BpZXRmLm9yZw0KPj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+ Pj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQN Cj4+PkJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4gPj4NCj4+PiAgPj4gPj4gPj4+ID4+IFdlbGwg SSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUNCj4+PnVuZGVyc3Rv b2QNCj4+PiAgPj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+PiAgPj4gPj4gPj4+ ID4+IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5 DQo+Pj5zaW5nbGUNCj4+PiAgPj5TRg0KPj4+ICA+PiA+PiA+Pj53aXRoaW4NCj4+PiAgPj4gPj4g Pj4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBz aW5nbGUgU0ZGIGFzIHRoZXJlIGlzIG5vIHdheQ0KPj4+dG8NCj4+PiAgPj5rbm93DQo+Pj4gID4+ ID4+YQ0KPj4+ICA+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+PiAgPj4gPj4gPj4+ID4+IHdoaWNoIFNG Q8K5cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4NCj4+PiAg Pj5wb2ludA0KPj4+ICA+PiA+PmluDQo+Pj4gID4+ID4+ID4+PnRpbWUuDQo+Pj4gID4+ID4+ID4+ PiA+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhh bHBlcm4iDQo+Pj4gPGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPj4NCj4+PiAgPj4gPj4gd3JvdGU6DQo+Pj4gID4+ID4+ID4+PiA+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9y DQo+Pj5wcm9ibGVtDQo+Pj4gID4+d2l0aA0KPj4+ICA+PiA+PnRoZQ0KPj4+ICA+PiA+PiA+Pj4g Pj55b3VyDQo+Pj4gID4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAo QW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heQ0KPj4+bm90DQo+Pj4gID4+ID4+ID4+PnVuZGVyc3Rh bmQNCj4+PiAgPj4gPj4gPj4+ID4+ID5pdC4pDQo+Pj4gID4+ID4+ID4+PiA+PiA+DQo+Pj4gID4+ ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBi YWxhbmNlciBmb3INCj4+PnRoZQ0KPj4+ICA+PiA+Pm5leHQNCj4+PiAgPj4gPj4gPj4+ID4+ID5z ZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQNCj4+PmRlbGl2 ZXJzDQo+Pj4gID4+dG8pLA0KPj4+ICA+PiA+PmluDQo+Pj4gID4+ID4+ID4+PmV2ZXJ5DQo+Pj4g ID4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdvZXMgdGhyb3VnaCBpdC4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4NCj4+PiAgPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJs ZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0DQo+Pj5tZWFucw0KPj4+ICA+PiA+PnRo YXQNCj4+PiAgPj4gPj4gPj4+ID4+ZXZlcnkNCj4+PiAgPj4gPj4gPj4+ID4+ID5TRkYgd291bGQg aGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBzdGF0ZWZ1bA0KPj4+bG9hZA0K Pj4+ICA+PiA+PiA+Pj5iYWxhbmNlci4NCj4+PiAgPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJv YmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvDQo+Pj5vcg0KPj4+ICA+ PiA+PnN0YXRlZnVsLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVj dHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGENCj4+PmZ1bGwsDQo+Pj4gID4+ID4+Zmxv dw0KPj4+ICA+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIg c2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+PiAgPj4gPj5hY2NlcHRhYmxlDQo+Pj4gID4+ID4+ID4+ PiA+PiA+aW1wb3NpdGlvbi4NCj4+PiAgPj4gPj4gPj4+ID4+ID4NCj4+PiAgPj4gPj4gPj4+ID4+ ID5Zb3VycywNCj4+PiAgPj4gPj4gPj4+ID4+ID5Kb2VsDQo+Pj4gID4+ID4+ID4+PiA+PiA+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0 aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UNCj4+PnRoaXMNCj4+PiAgPj53b3JrDQo+Pj4gID4+ID4+ ID4+PiA+PnNlbnNpYmx5DQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJh dGVkIGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj4+ICA+PnNlcnZpY2UNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+IGZ1bmN0aW9ucywgYW5kIG92ZXIgdGltZSBwcm9iYWJseSB0aGUgU0ZG DQo+Pj5jYXBhYmlsaXRpZXMsDQo+Pj4gID4+d2lsbA0KPj4+ICA+PiA+PmJlDQo+Pj4gID4+ID4+ ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZp Y2UNCj4+PmNoYWlucw0KPj4+ICA+PnRvIGJlDQo+Pj4gID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBj bGllbnRzLCBhbmQgZW5hYmxlDQo+Pj4gID4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+Pj4gID4+ ID4+ID4+PiA+PiA+PiBmcm9tIHRoZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhl YXZpbHkNCj4+PnBvbGljeQ0KPj4+ICA+PiA+PmRyaXZlLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3 b3JrIGluIGFuDQo+Pj5hcmNodGllY3R1cmUNCj4+PiAgPj4gPj5kcml2ZW4NCj4+PiAgPj4gPj4g Pj4+YnkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVz Y3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0DQo+Pj5pcw0KPj4+ICA+PiA+PmhhcmRlcg0KPj4+ICA+ PiA+PiA+Pj50bw0KPj4+ICA+PiA+PiA+Pj4gPj5zZWUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IGhv dyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdw0KPj4+ bW9yZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4g aW4gdGhlIG5ldHdvcmsgYmVoYXZpb3IuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkg ZGVzY3JpYmVkDQo+Pj5pcw0KPj4+ICA+PiA+Pm91dHNpZGUNCj4+PiAgPj4gPj4gPj4+b2YNCj4+ PiAgPj4gPj4gPj4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29y a2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4+PiAgPj4gPj50YXNrZWQg dG8NCj4+PiAgPj4gPj4gPj4+ID4+YWdyZWUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+b24uDQo+Pj4g ID4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBo YXZlIHRvIGRvIGl0IGENCj4+PiAgPj5jZXJ0YWluDQo+Pj4gID4+ID4+ID4+PndheS4NCj4+PiAg Pj4gPj4gPj4+ID4+aXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0 aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gSm9lbA0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTgg UE0sIElhbiBTbWl0aCB3cm90ZToNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUg YW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UNCj4+Pmluc3RhbmNlcw0KPj4+ICA+ PiA+PiB0aGF0DQo+Pj4gID4+ID4+ID4+PiA+Pm5lZWRzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ dG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWlu dGFpbmVkLCBwb3RlbnRpYWxseQ0KPj4+ZXZlbg0KPj4+ICA+PiA+PmFjcm9zcw0KPj4+ICA+PiA+ PiA+Pj5kYXRhDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWlu aXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZQ0KPj4+ZW5vdWdoDQo+Pj4gID4+YW5kDQo+Pj4gID4+ ID4+ID4+PiBjb21wbGV4DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWlu ZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+Pj5saWtlIGENCj4+PiAgPj4gPj4g Pj4+ZGlmZmljdWx0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGFyY2hpdGVjdHVyZSB0byByZWFs aXplLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1 cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+Pj4gID4+ZHlu YW1pYw0KPj4+ICA+PiA+PiA+Pj4gcm91dGluZywNCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBoeXBl ci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPj4+ICA+ PndoaWNoDQo+Pj4gID4+ID4+YXJlDQo+Pj4gID4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJs eQ0KPj4+aW1wbGVtZW50ZWQ/DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0 ZWQsDQo+Pj50aGF0DQo+Pj4gID4+aXMNCj4+PiAgPj4gPj5hDQo+Pj4gID4+ID4+ID4+Pmdvb2QN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEZyb206 IEpvZWwgTS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT5dDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRvOiBSb24gUGFya2Vy OyBKb2VsIEhhbHBlcm4gRGlyZWN0Ow0KPj4+bWlrZWJpYW5jQGFvbC5jb20NCj4+PiA8bWFpbHRv Om1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+PiAgPj5JYW4NCj4+PiAgPj4gPj4gPj4+U21pdGg7DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkDQo+Pj4gID4+QmFsYW5jZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFu ZCBvbmUgdGhhdCBJIHdvdWxkDQo+Pj4gID4+cHJlZmVyDQo+Pj4gID4+ID4+d2UNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gZGVjaWRlLCByYXRo ZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlDQo+Pj4gID4+ID4+aW1wbGVtZW50 YXRpb25zLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFq b3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+Pj4gID4+ID4+cmVxdWlyZW1lbnRzDQo+Pj4gID4+ ID4+ID4+PmFuZA0KPj4+ICA+PiA+PiA+Pj4gPj4gdGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4g ZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZp Y2UNCj4+Pmluc3RhbmNlcw0KPj4+ICA+PiA+PnRoYXQNCj4+PiAgPj4gPj4gPj4+IG5lZWRzDQo+ Pj4gID4+ID4+ID4+PiA+PiB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0 cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkNCj4+PmV2ZW4NCj4+PiAgPj4gYWNy b3NzDQo+Pj4gID4+ID4+ID4+PmRhdGENCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdp dGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UNCj4+PmVub3VnaA0KPj4+ICA+ PmFuZA0KPj4+ICA+PiA+PiA+Pj5jb21wbGV4DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdo IHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4+Pmxpa2UgYQ0K Pj4+ICA+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1 cmUgdG8gcmVhbGl6ZS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+IFlvdXJzLA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5 OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBUaGlzIGlz IHRoZSBjcnV4IG9mIG15IGlzc3VlLiBJcyB0aGUgZW5kIHRvIGVuZA0KPj4+ICA+PnNlbGVjdGlv bg0KPj4+ICA+PiA+Pm9mDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3Rh bmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzDQo+Pj5ieSB0aGUNCj4+PiAgPj4gPj4g Pj4+ID4+Y2xhc3NpZmllcikNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAo cGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQNCj4+PnN1YnNlcXVlbnRseQ0KPj4+ICA+PiA+ PnRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj5TRkZzKT8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gU3Vj aCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8NCj4+PnJlY2xhc3NpZmljYXRpb24uDQo+ Pj4gID4+QW5kDQo+Pj4gID4+ID4+ID4+PnN1cmVseSwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g dGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBk aXN0cmlidXRlZCBhcHByb2FjaA0KPj4+ZXZlbg0KPj4+ICA+PiB0aG91Z2gNCj4+PiAgPj4gPj4g YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBk ZWZpbml0aW9ucyBhbmQNCj4+PnBlcmhhcHMNCj4+PiAgPj5sb2NhbA0KPj4+ICA+PiA+PiA+Pj4g Pj5zZWxlY3Rpb24NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBpcyByZXF1aXJlZCBh dCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0KPj4+cG9pbnRzLg0KPj4+ICA+PiA+PlRoaXMN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQt dG8tZW5kIHBhdGggaWQgYXQNCj4+PmFsbC4NCj4+PiAgPj4gPj5NeQ0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5 DQo+Pj5kcml2ZW4NCj4+PiAgPj5ieQ0KPj4+ICA+PiA+PiA+Pj4gPj5pbmNyZWFzZWQNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gcmVzaWxpZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHBy b2FjaC4gV2l0aCBhDQo+Pj4gID4+Z2xvYmFsDQo+Pj4gID4+ID4+ID4+PnBhdGgNCj4+PiAgPj4g Pj4gPj4+ID4+aWQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZh aWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kDQo+Pj5uZWVkaW5nIHRvDQo+Pj4gID4+ID4+YWx0ZXIN Cj4+PiAgPj4gPj4gPj4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElE IHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZA0KPj4+ICA+PmVuZC10by1lbmQNCj4+ PiAgPj4gPj4gPj4+cGF0aC4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4gUm9uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPl0NCj4+PiBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20NCj4+PiA8 bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0gU2VudDogVGh1cnNkYXksIEp1bHkg MTAsDQo+Pj4gID4+MjAxNA0KPj4+ICA+PiA+PiA2OjE1DQo+Pj4gID4+ID4+ID4+PiBQTQ0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlh bmNAYW9sLmNvbT47DQo+Pj4gSS5TbWl0aEBGNS5jb20gPG1haWx0bzpJLlNtaXRoQEY1LmNvbT47 IHNmY0BpZXRmLm9yZw0KPj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+IFN1YmplY3Q6 DQo+Pj4gID4+ID4+IFJlOg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRo ZSBjYXNlIG9mIFNGMQ0KPj4+bmVlZGluZw0KPj4+ICA+PnRvDQo+Pj4gID4+ID4+ID4+PiA+Pmlu Zmx1ZW5jZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291 bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdA0KPj4+dGhlDQo+Pj4gID4+ZXhpdA0KPj4+ICA+PiA+ PmZyb20NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhl IGRpZmZlcmVudCBmdW5jdGlvbnMNCj4+PiAgPj4gPj5sb2dpY2FsbHkNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUg aG93DQo+Pj50aGV5DQo+Pj4gID4+ID4+IGNob29zZQ0KPj4+ICA+PiA+PiA+Pj50bw0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gWW91cnMsIEpvZWwN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8x NCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20NCj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tPiB3cm90ZToNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5n IGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQNCj4+PnN1Z2dlc3RzIGFueQ0KPj4+ICA+PiA+PnNvcnQN Cj4+PiAgPj4gPj4gPj4+b2YNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVy LCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUNCj4+PmVudGlyZQ0KPj4+ICA+PiA+ PnBhdGgNCj4+PiAgPj4gPj4gPj4+KGFsbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykg bXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uIEkNCj4+PmJlbGlldmUNCj4+PiAg Pj50aGlzDQo+Pj4gID4+ID4+ID4+Pm1lYW5zDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBlaXRo ZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXINCj4+PiAgPj5jaG9v c2VzIGENCj4+PiAgPj4gPj5TRg0KPj4+ICA+PiA+PiA+Pj4gPj5DaGFpbg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIElu IGFueQ0KPj4+Y2FzZSwNCj4+PiAgPj4gPj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGxh bmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlANCj4+PndoZXJl DQo+Pj4gID4+ID4+IFNGSShuKQ0KPj4+ICA+PiA+PiA+Pj4gaXMNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZQ0K Pj4+ZHJhZnQsDQo+Pj4gID4+ID4+dGhpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZp b3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldw0KPj4+U0ZQIGFzDQo+ Pj4gID4+ID4+ID4+PiBvcHBvc2VkDQo+Pj4gID4+ID4+ID4+PiA+PiB0bw0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQN Cj4+Pmluc3RhbmNlIG9mDQo+Pj4gID4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBu ZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8g dGhlIG5ldHdvcmsgaXQgaXMNCj4+PiAgPj4gPj5uZWNlc3NhcnkNCj4+PiAgPj4gPj4gPj4+dG8N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBv ZiBTRnMgdGhhdCB3aWxsIGJlDQo+Pj51c2VkLA0KPj4+ICA+PiA+PmFuZCB0bw0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMg dXNpbmcNCj4+PlNGJ3MNCj4+PiAgPj4gPj5uZXR3b3JrDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4NCj4+ PnRoZQ0KPj4+ICA+PiA+PiA+Pj5jcmVhdGlvbg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9m IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4+ICA+PiA+ PmZvcndhcmRpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhl IFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcw0KPj4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBTRkMuDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVy ZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9uIChvcg0KPj4+ICA+PiA+Pm5vbi1pbml0aWFsDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tl dHMgdHJhdmVyc2UgYW4NCj4+PlNGUCwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNz aWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQNCj4+PmJ5IGENCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3 aXRoIGEgc2VydmljZQ0KPj4+ICA+PiA+PmZ1bmN0aW9uLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGENCj4+ Pm5ldw0KPj4+ICA+PiA+PlNGUCwgYW4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUg b2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgDQo+Pj5pcw0KPj4+ICA+ PiA+PnJlZmVycmVkDQo+Pj4gID4+ID4+ID4+PnRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4g YXMgImJyYW5jaGluZyIuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4+ICA+PiA+PiA+Pj4gPj4NCj4+PiAgPj4gPj4gPj4+DQo+Pj4gID4+ID4+DQo+Pj4gID4+ DQo+Pj4gIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+LS0NCj4+PiAgPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4+ICA+PiA+Pj4+Pj4+Pj4+Pj4t LS0NCj4+PiAgPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+Pj4gID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+LS0NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tDQo+Pj4gPG1haWx0bzoqSS5TbWl0aEBGNS5j b20+PEkuU21pdGhARjUuY29tIDxtYWlsdG86SS5TbWl0aEBGNS5jb20+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+Pj4gID4+IERpcmVjdDxqbWguZGlyZWN0 QGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+ PixKb2VsDQo+Pj4gID4+ID4+IE0uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+ PiA+Pj4gPj4NCj4+PiAgPj4gPj4gPj4+DQo+Pj4gID4+ID4+DQo+Pj4gID4+ID4+Pj4+SGFscGVy bjxqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4s aHVhbmdAc2NlLmNhcmxldG9uLmNhDQo+Pj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+ PGh1YW5nQHNjZS4NCj4+PiA8bWFpbHRvOmh1YW5nQHNjZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxl dG9uLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnIDxtYWlsdG86c2Zj QGlldGYub3JnPjxzZmNAaWV0Zi5vcmcNCj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVs eSAxMCwgMjAxNA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgDQo+Pj5Mb2FkDQo+Pj4gID4+ID4+QmFsYW5jZXJz DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFs bHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWluZy4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVkaXVtLXNjYWxl IGRlcGxveW1lbnRzIChhbmQNCj4+PiAgPj50aGF0IGlzDQo+Pj4gID4+ID4+ID4+PndoYXQNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IDE2IG1pbGxpb24gZmxvd3MgaXMgaW4gbXkgd29ybGQpIG9m IHNlcnZpY2UgY2hhaW5zIA0KPj4+aXMNCj4+PiAgPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0 dXJlIGJ1cmRlbmVkIA0KPj4+d2l0aA0KPj4+ICA+PiB0aGF0DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBwcmVjb25jZXB0aW9uLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdy ZWUgb2YNCj4+PiAgPj4gPj5hc3BpcmF0aW9uDQo+Pj4gID4+ID4+IHRvDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2Yg dGhlDQo+Pj4gID4+ID4+YXJjaGl0ZWN0dXJlDQo+Pj4gID4+ID4+ID4+Pi0NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNh eWluZyANCj4+PnRoYXQgYW4NCj4+PiAgPj4gPj4gPj4+YXJiaXRyYXJ5DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlm IGl0IA0KPj4+aXNuJ3QNCj4+PiAgPj4gPj4gPj4+ID4+aW50ZW50aW9uYWwNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2 ZSANCj4+Pmxhc3RpbmcNCj4+PiAgPj4gPj5pbXBhY3RzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiByZWdhcmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIA0KPj4+ZWxhc3RpY2l0 eSwNCj4+PiAgPj4gPj5hZGRyZXNzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzcGFjZS4uLiBh bGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxlbSANCj4+PkknbSANCj4+Pm5vdA0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QNCj4+PiBbam1oLmRpcmVjdEBq b2VsaGFscGVybi5jb20gPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+Pj4g ID4+ID4+U2VudDoNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgDQo+Pj5Kb2VsIA0KPj4+TS4NCj4+PiAgPj4gPj4g SGFscGVybjsNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYQ0K Pj4+IDxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsgc2ZjQGlldGYub3JnIDxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0KPj4+ICA+PiA+PlNlcnZpY2UN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwg SSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gDQo+Pj50aGlzDQo+ Pj4gID4+ID4+cmVnYXJkLg0KPj4+ICA+PiA+PiA+Pj5JDQo+Pj4gID4+ID4+ID4+PiA+PmFtDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVy ZSBvciB0aGUgc29sdXRpb24NCj4+PiAgPj4gPj5wcm9oaWJpdA0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gDQo+Pj5vYmpl Y3RpbmcgDQo+Pj50bw0KPj4+ICA+PiA+Pkh1YW5nJ3MNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIA0KPj4+ YXJlDQo+Pj4gID4+ID4+IHJlcXVpcmVkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5 IHRoZSBhcmNodGllY3R1cmUuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRv IA0KPj4+cHJvaGliaXQNCj4+PiAgPj5zdWNoDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGlu Z3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Igbm90IA0KPj4+ZGVwZW5kcyANCj4+ PnVwb24NCj4+PiAgPj4gPj4gbWFueQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBv dXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+Pj4gID4+dGhpbmsN Cj4+PiAgPj4gPj50aGF0DQo+Pj4gID4+ID4+ID4+PiA+PnRoZXkNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5 IGF2b2lkaW5nIA0KPj4+YXR0ZW1wdGluZyB0bw0KPj4+ICA+PiA+Pmtub3cNCj4+PiAgPj4gPj4g Pj4+d2hhdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMgYW5kIGlzIG5vdCBlcGxveWFibGUu DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMs IEpvZWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBP biA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5h Z2UgDQo+Pj50ZW5zIG9mDQo+Pj4gID4+ID4+ID4+Pm1pbGxpb25zDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4gb2YNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4g Ym90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSANCj4+PmNlbnRlcg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUg DQo+Pj50aGF0IGluDQo+Pj4gID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9J UHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgDQo+Pj55b3UNCj4+PiAg Pj4gYXJlDQo+Pj4gID4+ID4+IG9ubHkNCj4+PiAgPj4gPj4gPj4+ID4+IGdvaW5nDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMg d2l0aCANCj4+PmVxdWFsbHkNCj4+PiAgPj5zbWFsbA0KPj4+ICA+PiA+PiA+Pj4gbnVtYmVycw0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0 b28gbXVjaCBsaWtlICJubyBvbmUgd2lsbCBldmVyIG5lZWQgDQo+Pj5tb3JlDQo+Pj4gID4+IHRo YW4NCj4+PiAgPj4gPj4gPj4+IDY0SyINCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gW3NmYy1ib3VuY2VzQGlldGYub3JnDQo+Pj4gPG1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbT5dDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNDo0NiBQTSBUbzoNCj4+PiAgPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhIDxt YWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0KPj4+IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywNCj4+PiAgPj5hbmQNCj4+PiAgPj4gPj4gPj4+TG9hZA0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNv bWVvbmUgdHJpZXMgdG8gZGVwbG95IA0KPj4+dGhlDQo+Pj4gID4+ID4+ID4+PmFyY2h0aWV0dXJl DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwg ZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4+PiAgPj50aGVpcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IGRldmljZXMuIFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIA0KPj4+ YWJzdXJkDQo+Pj4gID4+IHVzZQ0KPj4+ICA+PiA+PiBvZg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byANCj4+ PndyaXRlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBw cm9oaWJpdCBpdCwgdGhlIA0KPj4+YXJjaGl0ZWN0dXJlDQo+Pj4gID4+ZG9lcw0KPj4+ICA+PiA+ PiA+Pj5wZXJtaXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUGxlYXNlIGRvIG5v dCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmUNCj4+PiAgPj4gcGVybWl0cw0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVy IGRlaXNyZWQgb3IgDQo+Pj5yZXF1aXJlZCBieQ0KPj4+ICA+PiA+PnRoZQ0KPj4+ICA+PiA+PiA+ Pj53b3JrLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQs IDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCANCj4+Pndp bGwNCj4+PiAgPj5tZWFuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0 aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcNCj4+PiAgPj50YWJsZQ0KPj4+ICA+ PiA+Pm9mIGENCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEw LzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMs IA0KPj4+ZnJvbQ0KPj4+ICA+PjENCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2Ug cGF0aCB0byAxNjAwMDAgc2VydmljZSBwYXRocy4gSSB3b3VsZCANCj4+PmhvcGUNCj4+PiAgPj50 aGF0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZv ciB0aGUgY29tcGxleGl0aWVzIGlmIA0KPj4+dGhleQ0KPj4+ICA+PiA+PmNob29zZQ0KPj4+ICA+ PiA+PiA+Pj50bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBs b2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4gDQo+Pj5zdGVhZA0KPj4+ICA+PiA+PiBwcm92aXNp b24NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3Vy cywgSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZToNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVy cyB0aGVyZSB3aWxsIGJlIGZvciBhIA0KPj4+NCANCj4+PmhvcA0KPj4+ICA+PiA+PiBzZXJ2aWNl DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQg ZWFjaCBob3A/DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBNYXJpYQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSAqT24gDQo+Pj5CZWhhbGYNCj4+PiAgPj4gT2YNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIA0KPj4+MjAx NA0KPj4+ICA+PiA+PjM6MDMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBM dWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT47DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 IHNmY0BpZXRmLm9yZyANCj4+PjxtYWlsdG86c2ZjQGlldGYub3JnPjsNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Pg0KPj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4+PiAgPj4gQ2hhaW5zLA0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ks DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIA0KPj4+dGhl DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZy4gScK5ZA0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBtaW5v ciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIA0KPj4+dXNlZCB0bw0KPj4+ICA+ PiA+PiBkZXJpdmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZvcndh cmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9y dCwgYnV0IHJhdGhlciBpcyB1c2VkIA0KPj4+dG8NCj4+PiAgPj5zaW1wbHkNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhh dCANCj4+PnBhY2tldHMNCj4+PiAgPj5tdXN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIA0KPj4+ZXhhY3QNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRv IGJlIGFza2luZyBmb3IgDQo+Pj5vbg0KPj4+ICA+PnRoaXMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBsZW1lbnRlZC4gVGhlIHBhdGgNCj4+ PiAgPj4gPj4gaWRlbnRpZmllcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVz IG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IA0KPj4+bG9va3VwIGNhbg0KPj4+ICA+ PiA+PiByZXN1bHQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhIG9uZSBvciBtb3Jl IChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IA0KPj4+bmV4dA0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0s IEx1Y3kgeW9uZw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2Vp LmNvbSANCj4+PjxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+DQo+Pj4gID4+ID4+IDxtYWls dG86bHVjeS55b25nQGh1YXdlaS5jb20+IDxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20lM2U+ Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4g ZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IA0KPj4+dXNlIG9mDQo+Pj4gID4+IHRoZQ0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZl IHRoZSBmb3J3YXJkaW5nDQo+Pj4gID4+ID4+YWN0aW9ucy4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT24gDQo+Pj5CZWhhbGYNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gPG1haWx0 bzpPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+PiAgPj4gPj4g Pj4+ICpTZW50OipUaHVyc2RheSwNCj4+PiAgPj4gPj4gPj4+ID4+IEp1bHkNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb20N Cj4+PiA8bWFpbHRvOiptaWtlYmlhbmNAYW9sLmNvbT4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4g PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGll dGYub3JnDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZz4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKlN1Ympl Y3Q6KlJlOiBbc2ZjXSANCj4+PlNlcnZpY2UNCj4+PiAgPj4gPj5DaGFpbnMsDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmUtLA0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1l cmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIA0KPj4+c2VydmljZSANCj4+PnBhdGgN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2Ug dGhhdCBpZGVudGlmaWVyIHRvDQo+Pj4gID4+ZGVyaXZlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBoYXZl IHRoZSBmdWxsIA0KPj4+a25vd2xlZGdlIG9mDQo+Pj4gID4+ID4+IGV2ZXJ5DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Zm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIA0KPj4+aXMgbm90 DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRl eHRzLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgDQo+Pj5waWVj ZSANCj4+Pm9mDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+PiAgPj4g cmVxdWlyZWQNCj4+PiAgPj4gPj4gdG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1 Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCANCj4+PmluZm9ybWF0aW9uIA0KPj4+aXMN Cj4+PiAgPj4gPj51c2VkIHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9y d2FyZGluZw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYWN0aW9ucw0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE1lZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIA0KPj4+ cGFydA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0 bzpkZSptaWtlYmlhbmNAYW9sLmNvbT4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+PiAgPj4gPj4g anVpbGxldA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1o QGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNA aWV0Zi5vcmcNCj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3Jn Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2Jq ZXQgOipSZTogW3NmY10gDQo+Pj5TZXJ2aWNlDQo+Pj4gID4+ID4+Q2hhaW5zLA0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBz dGlsbCBxdWVzdGlvbmluZyB0aGUgZGlmZmVyZW5jZSANCj4+PmJldHdlZW4NCj4+PiAgPj5TRg0K Pj4+ICA+PiA+PiBDaGFpbg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBP dGhlciB0aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCANCj4+Pml0J3MNCj4+ PiAgPj4gPj5jbGVhciB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhvc2Ugbm90DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1z IHRoYXQgZXZlcnlvbmUNCj4+PiAgPj5hZ3JlZXMNCj4+PiAgPj4gPj5vbg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBp cyBzdGlsbCB1bmNsZWFyIGlzDQo+Pj4gID4+d2hldGhlcg0KPj4+ICA+PiA+Pml0IGlzDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGlt YXRlbHkgc3BlY2lmeSANCj4+PndoYXQNCj4+PiAgPj4gPj50aGUgSUQNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g c2hvdWxkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4g b3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIA0KPj4+ZHJhZnQNCj4+PiAgPj4gPj5zaW1wbHkNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3Vz LCBhbGxvd2luZyBvdGhlcg0KPj4+ICA+PmRyYWZ0cw0KPj4+ICA+PiA+PnRvDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBi YXNlZCBvbiANCj4+PmNoYWluDQo+Pj4gID4+IG9yDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gcGF0aCB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4g dGhlIGNvbnRyb2wtcGxhbmUuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMpLCB0aGVuIHRoZSBk cmFmdCANCj4+PndvdWxkIA0KPj4+aGF2ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJl cXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgDQo+Pj5tYWtlDQo+ Pj4gID4+ID4+IG9uZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0 aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4+PiAgPj4gdmVuZG9ycw0KPj4+ICA+ PiA+PiBvbmx5DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5k IG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4NCj4+PiAgPj4gPj4NCj4+PiAgPj4NCj4+ PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4tLQ0KPj4+ICA+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+Pj4gID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0K Pj4+ICA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+PiAgPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipqbWhAam9lbGhhbHBl cm4uY29tDQo+Pj4gPG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT48am1oQGpvZWxoYWxwZXJu LmNvbQ0KPj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhA am9lbGhhbHBlcm4uY29tPg0KPj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBq b2VsaGFscGVybi5jb20lM2U+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2Zj QGlldGYub3JnDQo+Pj4gPG1haWx0bzoqc2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNA aWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+DQo+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNA aWV0Zi5vcmclM2U+Pg0KPj4+ICA+PiAqU2VudDoqVHVlc2RheSwNCj4+PiAgPj4gPj4gSnVseQ0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgDQo+Pj5hbmQNCj4+PiAgPj5Mb2FkDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gQmFsYW5jZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBo b3cgdG8gY2xlYXJseQ0KPj4+ICA+PmFuc3dlcg0KPj4+ICA+PiA+PmENCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91 dCANCj4+PnRoZQ0KPj4+ICA+PiA+PiA+Pj4gcHJvcG9zZWQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0DQo+ Pj4gID4+IHdvcmtpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBhZ3JlZW1l bnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvDQo+Pj4gID4+IGltcHJvdmUNCj4+PiAg Pj4gPj4gdGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd29yZGluZyBzbyB0aGF0IHJl YWRlcnMgd2hvIGhhdmUgbm90IA0KPj4+cGFydGljaXBhdGVkIGluDQo+Pj4gID4+ID4+dGhlDQo+ Pj4gID4+ID4+IFdHDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxs IHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2lu Zw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBk byB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4+ICA+PiA+PnBlcnNvbmFs DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBz Lg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIA0KPj4+bWluZCAN Cj4+PnRoYXQNCj4+PiAgPj4gPj53aGF0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug YXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIA0KPj4+YXJjaGl0ZWN0dXJlLiANCj4+Pldl DQo+Pj4gID4+YXJlDQo+Pj4gID4+ID4+IG5vdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSANCj4+PmVudGly ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWlu aW5nLiBUaGF0IHdvdWxkIA0KPj4+ZW5jb21wYXNzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KPj4+ICA+ PnZpcnR1YWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBt YW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlcg0KPj4+ICA+PiA+PiBhc3BlY3RzLg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMgYSByZXN1 bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIA0KPj4+Y2xlYXJseSANCj4+Pm5lZWQNCj4+ PiAgPj4gdG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2Vy IHN5c3RlbSwgYnV0IHdoaWNoIGFyZSANCj4+PmRlYWx0IA0KPj4+d2l0aA0KPj4+ICA+PiA+PmFi b3ZlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh bmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSANCj4+PmFyZQ0KPj4+ ICA+PiBkb2luZy4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZpY2Ug DQo+Pj5wYXRoLA0KPj4+ICA+PmFzIEkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRl cnN0YW5kDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSAN Cj4+PmFyZSBhdA0KPj4+ICA+PiA+PmxlYXN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gDQo+Pj5hbmQNCj4+ PiAgPj53aWxsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2 aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSANCj4+PmFyZQ0KPj4+ICA+PiA+Pm1vcmUuDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUg aXMgdG8gcGVybWl0IGFsbCANCj4+Pm9mDQo+Pj4gID4+ID4+dGhlc2UsDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2lu ZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmUgdXNlZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2VydmljZSBw cm92aWRlZCB0byB0aGUgDQo+Pj5lbmQNCj4+PiAgPj4gPj51c2VyLg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2Vy DQo+Pj4gID4+cGFja2V0cywNCj4+PiAgPj4gPj5hbmQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFya3MNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBh biBlbmQgdXNlciANCj4+PnNlcnZpY2UNCj4+PiAgPj4gPj5pbnN0YW5jZQ0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiAN Cj4+PmltcG9ydGFudA0KPj4+ICA+PiA+PnNlcnZpY2UNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSANCj4+PmNoYWlu aW5nLg0KPj4+ICA+PiA+Pkl0J3MNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlv ciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZQ0KPj4+ICA+PiA+PiBjaGFp bmluZyBpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvbmUuIEJ1dCBpdCBoYXMgdmVy eSBsaXR0bGUgaW1wYWN0IG9uIHRoZQ0KPj4+ICA+PiA+PmFyY2h0aWVjdHVyZS4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0 IGlzIA0KPj4+c2ltcGx5IA0KPj4+YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhl IHVuZGVybHlpbmcgDQo+Pj5wYWNrZXQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFu Y2luZy4gVGhhdCBpcywgDQo+Pj5vbmUNCj4+PiAgPj5jYW4NCj4+PiAgPj4gPj5oYXZlDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXBw ZWFycw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5n IGFyY2hpdGVjdHVyZSBhcyBhIA0KPj4+c2luZ2xlDQo+Pj4gID4+cG9pbnQNCj4+PiAgPj4gPj5v Zg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IGZvciBhDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2Vydmlj ZSBmdW5jdGlvbiwgYnV0IGlzIGFjdHVhbGx5IA0KPj4+ZGVsaXZlcmVkDQo+Pj4gID4+ID4+Ynkg YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlvbiBvZg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IA0KPj4+ aW5jbHVkaW5nDQo+Pj4gID4+b25lIG9yDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2 ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgDQo+Pj5WUlJQLWxpa2UNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJl c3MuKSBtb3N0bHksIA0KPj4+dGhpcyBpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu dmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBkYXRhIHBsYW5lDQo+Pj4gID4+ID4+bWVj aGFuaXNtcy4NCj4+PiAgPj4gPj4gSXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBs aWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4+ICA+PiA+Pm1l Y2hhbmlzbXMsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNw b25zaWJsZSBmb3Igc2NhbGUtaW4sIA0KPj4+c2NhbGUtb3V0LA0KPj4+ICA+PmFuZA0KPj4+ICA+ PiA+PnZtDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFy Y2hpdGVjdHVyYWwgaW1wYWN0IG9mDQo+Pj4gID4+cGVybWl0dGluZw0KPj4+ICA+PiA+PnRoaXMN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBi ZSBjYXJlZnVsIHRoYXQgb3VyDQo+Pj4gID4+ID4+dGVybWlub2xvZ3kNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFk ZXJzIHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhpbmsgd2UgYXJlIHByb2hpYml0 aW5nIGl0Lg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0KPj4+ ICA+PnNlbGVjdGluZw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBm b3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCANCj4+PmRpcmVjdA0KPj4+ICA+PiA+PnRyYWZm aWMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3 b3VsZCBub3Qgd2FudCB0byANCj4+PnJlcXVpcmUNCj4+PiAgPj4gdGhhdA0KPj4+ICA+PiA+PmEN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVh ciBhdCBvbmx5IG9uZSANCj4+PnBsYWNlIA0KPj4+aW4NCj4+PiAgPj50aGUNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQg dGhlc2UgbWF5IGJlDQo+Pj4gID4+Y29tYmluZWQuIEkNCj4+PiAgPj4gPj4gdGVuZA0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0 bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVz IHRoYXQgYXBwZWFyIHRvIA0KPj4+c2VydmljZQ0KPj4+ICA+PiA+PmNoYWluaW5nDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3Qg YmVjYXVzZSANCj4+PmNsdXN0ZXINCj4+PiAgPj5pcw0KPj4+ICA+PiA+PmENCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5v dGhlciANCj4+Pm9uZS4NCj4+PiAgPj4gVGh1cywNCj4+PiAgPj4gPj4gdGhlDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQgYmFsYW5jaW5nDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBpcyB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVj dCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIA0KPj4+ZGlmZmVyZW50DQo+Pj4gID4+ ID4+c2luZ3VsYXINCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVyZWQgc2Vy dmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IA0KPj4+cGxhY2VzDQo+Pj4gID4+aW4NCj4+PiAg Pj4gPj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGgg dGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayANCj4+PmFib3V0DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRoLyBTZXJ2 aWNlIGNoYWluIA0KPj4+aXMgYQ0KPj4+ICA+PiA+PiBzZXF1ZW5jZQ0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJz ZXQgDQo+Pj5vZg0KPj4+ICA+PiA+PnBhY2tldHMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZg0KPj4+ICA+ PnRyYWZmaWMNCj4+PiAgPj4gPj5pcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdl dCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KPj4+ICA+PmZpcmV3YWxs DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlz IHRvIGdvIGRpcmVjdGx5IHRvIA0KPj4+dGhlDQo+Pj4gID4+Y2FjaGUNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHdpdGhvdXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBh bnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRp b24gdG8gZGlyZWN0IHRoZQ0KPj4+ICA+PnBhY2tldHMuDQo+Pj4gID4+IEENCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1 ZW5jZSBvZg0KPj4+ICA+PiA+PmxvY2F0aW9ucw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluIHRoZSBuZXR3b3JrLiBUaG9zZSBsb2NhdGlvbnMgd2lsbCBiZSANCj4+PnNpbmd1bGFyIG9y DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24g ZGVsaXZlcnkgbG9jYXRpb25zLiANCj4+PlRoZXkNCj4+PiAgPj4gPj5tYXkgYmUNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUg YWRkcmVzc2VkIA0KPj4+YXMNCj4+PiAgPj4gcG9ydHMNCj4+PiAgPj4gPj4gb24NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlz IHRoYXQgdGhlDQo+Pj4gID4+ID4+bG9jYXRpb25zDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIA0KPj4+aW5mcmFzdHJ1Y3R1 cmUNCj4+PiAgPj4gYW5kDQo+Pj4gID4+ID4+IHRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRyYW5zcG9ydC4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMNCj4+PiAgPj5ncm91cCwNCj4+PiAgPj4gPj4gd2UNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8g dGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgDQo+Pj50aGUNCj4+PiAgPj4g Pj5zZXJ2aWNlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdoaWNoIGRyaXZl cyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIA0KPj4+bmVlZCANCj4+PnRvDQo+Pj4gID4+IHRhbGsN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBw YWNrZXRzIHdpbGwgdGFrZSANCj4+PmluIA0KPj4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gbmV0d29yay4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAiYnV0IHRo ZSANCj4+Pndob2xlDQo+Pj4gID4+IHBhdGgNCj4+PiAgPj4gPj4gbWF5DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4iIFRoaXMgYXJjaGl0ZWN0 dXJlIA0KPj4+ZGVhbHMNCj4+PiAgPj4gPj53aXRoDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIA0KPj4+aXRlbSAN Cj4+PigyKQ0KPj4+ICA+Pm9uDQo+Pj4gID4+ID4+bG9hZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQNCj4+PiAg Pj5iZWhhdmlvcnMNCj4+PiAgPj4gPj4gd2hpY2gNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBhcmUgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIA0KPj4+bWVjaGFuaXNtcyAo aW4NCj4+PiAgPj4gPj5tdWNoDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIHNhbWUg d2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIA0KPj4+bGFyZ2VseQ0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRo ZSBvdGhlcg0KPj4+ICA+PiBwcm92aXNpb24NCj4+PiAgPj4gPj4gd2UNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGF0DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBjYW4gYmUgZG9uZSBpbiBt aWQtY2hhaW4gd2hlbg0KPj4+ICA+PiA+PiBuZWNlc3NhcnkuDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCAN Cj4+Pm9uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxl IGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPj4+ICA+PnBvaW50Lg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhp cyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIA0KPj4+YWZ0ZXIuDQo+Pj4gID4+SWYgaXQNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2Nl cHRhYmxlIHRvIHRoZSANCj4+PndvcmtpbmcNCj4+PiAgPj4gPj4gZ3JvdXAsDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRz IGFyZSANCj4+Pm5lZWRlZA0KPj4+ICA+PiB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSANCj4+PndpdGggDQo+ Pj50aGUNCj4+PiAgPj4gPj4gaW50ZW50LA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRo ZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0IHRvIG1hdGNoIHRoZSANCj4+PndvcmtpbmcNCj4+ PiAgPj4gPj5ncm91cA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElm IHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3QgDQo+Pj5zdXJlDQo+Pj4gID4+ID4+d2hh dCB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj4gID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gID4+ID4+IHNmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ICA+PiA+PiBzZmMN Cj4+PiAgPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBs aXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiA8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiAg Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiAg Pj4gPj4gc2ZjDQo+Pj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4g Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiAgPj4gc2ZjDQo+Pj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+ICA+PiBzZmMNCj4+PiAgPj4gPj4gPj4+IG1haWxpbmcNCj4+PiAgPj4gPj4gPj4+ ID4+IGxpc3QNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIHNmYw0KPj4+ICA+PiA+PiA+Pj4gbWFpbGluZw0KPj4+ICA+PiA+PiA+Pj4g Pj4gbGlzdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4+ICA+PiA+PiBt YWlsaW5nDQo+Pj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBzZmMNCj4+PiAgPj4gPj4gbWFpbGluZw0KPj4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4g ID4+ID4+ID4+PiA+PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4NCj4+PiAgPj4gPj4g Pj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+ICA+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+PiAgPj4gPj4gPj4+ID4+ID5z ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiA+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4gPj4gPj4+ID4+ DQo+Pj4gID4+ID4+ID4+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+ICA+PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ICA+PiA+ PiA+Pj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+ Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4g Pj4gPj4+DQo+Pj4gID4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+ICA+PiA+PiA+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ICA+PiA+ PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4gPj4gPg0K Pj4+ICA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiAgPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+PiAgPj4gPj4gPnNmY0BpZXRmLm9y ZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+DQo+DQoNCg== From nobody Mon Jul 14 08:29:56 2014 Return-Path: <tom.taylor.stds@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07221A0A96 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_29=0.6, 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 Rmcg5jXdF2NP for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:29:46 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDC51A0A91 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:29:46 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id eb12so4337131oac.8 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fe3ow5tBNw4ccHXtBVTMQ3i6beHLFACGrsoifoCmXxw=; b=AaOSLWit19ODOZ0wDSP5V8bsQkGbX31DkHdOjXERgCJ9pbthoais4MPT7Fdef+EhAw 2v0LntNEBNeTfp8HQv6gPEwFPeauPaTbEg3jU+/ZLDlyY8XYXDkw7yS6RUxDyjaaOFZ5 y7kEeV5sDuLEtdpYnmX/Bp/K0P77RONnLuiwhD0v5eFTaJ4tTwlS2j5fofIFkvrAlse/ r1j6rWdE9NXxh311wDATPWuGTDwfYiXJJFnxOHeGdglRBlviF6EF6f/0T4lyv0PRCaAm t8MYyeJIXh40tL2pFYzDZFGcNlFJqmUT17C/0yU+bfa5jIvcYVau8iIwEvKJV9eaVJW3 bdOA== X-Received: by 10.182.91.4 with SMTP id ca4mr18930493obb.26.1405351785264; Mon, 14 Jul 2014 08:29:45 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id at4sm23720492obc.29.2014.07.14.08.29.43 for <sfc@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 08:29:44 -0700 (PDT) Message-ID: <53C3F766.5010708@gmail.com> Date: Mon, 14 Jul 2014 11:29:42 -0400 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> In-Reply-To: <CFE96A4C.2E4AC%jguichar@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6dR_Pv-fZS5UHfYqXWMu01RaUq0 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:29:51 -0000 What is wrong with that wording is that it assumes that at the point of instantiation there is perfect knowledge of SF availability and reachability. APONF proposes to supply that information, BTW. However, the design is less resilient than one in which SF Forwarding can make decisions at each service hop. Tom Taylor On 14/07/2014 11:12 AM, Jim Guichard (jguichar) wrote: > Question: where exactly does it specify that the SFP *must* be > pre-instantiated? What exactly is wrong with the wording “When an SFC is > instantiated into the network it is necessary to select the specific > instances of SFs that will be used, and to create the service topology for > that SFC using SF’s network locatorsâ€? Let’s try to be specific rather > than dancing around the wording. > > On 7/14/14, 11:00 AM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wrote: > >> Hi, Joel, >> >> I quote from the the merged architecture draft: >> >> <begin quotation> >> Service Function Chain (SFC): A service Function chain defines an >> ordered set of service functions that must be applied to packets >> and/or frames selected as a result of classification. The >> implied order may not be a linear progression as the >> architecture allows for nodes that copy to more than one branch. >> The term service chain is often used as shorthand for service >> function chain. >> >> Service Function Path (SFP): The instantiation of an SFC in the >> network. Packets follow a service function path from a >> classifier through the requisite service functions >> >> When an SFC is instantiated into the network it is necessary to >> select the specific instances of SFs that will be used, and to create >> the service topology for that SFC using SF's network locator. Thus, >> instantiation of the SFC results in the creation of a Service >> Function Path (SFP) and is used for forwarding packets through the >> SFC. In other words, an SFP is the instantiation of the defined SFC. >> >> (Section 4.3 SFF) >> SFP forwarding information is associated with a service path identifier >> that is used to uniquely identify an SFP. >> <end quotation> >> >> >> My reading of the Section 4.3, given the definitions presented before it, >> is that an end-to-end fully instantiated path is selected and then used >> to steer traffic to the requisite SFF's and SF's. While those >> definitions could still apply, even in a distributed instance assignment >> approach, the context around those definitions change. A particular >> flow would, indeed still follow some particular path, but there would be >> no need to associate a path ID to it and there would be no need to >> (later) build a control plane around distribution of this path ID and >> maintenance of those path IDs in the face of inevitable failures. >> >> I am exploring the alternative where forwarding is performed based on the >> abstract SFC ID without requiring the concept of a centrally known SFP to >> exist at all. In this alternative approach, the instance selection is >> distributed to the classifier and the SFF's. Any desired policy used to >> flavor instance selection is still supported, but such policy would, >> indeed, need to be available to the involved entities. This would also >> be an excellent use of metadata where the initial ingress node could add >> one or more pieces of metadata that downstream nodes could make use of in >> their policy decisions. >> >> Ron >> >> >> -----Original Message----- >> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >> Sent: Monday, July 14, 2014 10:39 AM >> To: Lucy yong; NAPIERALA, MARIA H; Ron Parker; Xuxiaohu; >> mikebianc@aol.com; jguichar@cisco.com; mohamed.boucadair@orange.com; >> jmh@joelhalpern.com; sfc@ietf.org >> Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load >> Balancers >> >> Can we first figure out what we mean by a service path? >> Once we have that, I believe we can work out what we want the >> architecture to require of solutions in terms of carrying information in >> the packet. But since folks have been reading the existing definitions >> and coming to different meanings, and have been noting correctly >> contradictions in the words we chose for the existing definition, I >> would really appreciated it if folks would comment on the definition of >> service function path that I sent to the list. >> >> Yours, >> Joel >> >> On 7/14/14, 9:30 AM, Lucy yong wrote: >>> Conquer what Maria says. >>> >>> Lucy >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *NAPIERALA, >>> MARIA H >>> *Sent:* Monday, July 14, 2014 8:21 AM >>> *To:* Ron Parker; Xuxiaohu; mikebianc@aol.com; jguichar@cisco.com; >>> mohamed.boucadair@orange.com; jmh@joelhalpern.com; sfc@ietf.org >>> *Subject:* Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and >>> Load Balancers >>> >>> The meaning of the SFP ID is pretty clear, at least to me – an abstract >>> identity for the exact set of service function instances (i.e., SFP ID 1 >>> = {SF-A-1, SF-B-3, SF-C-2}). In some ways, it is a collapsed “label >>> stack†– there is a single tag implying some sequence of network >>> locations. But, this also implies, at least to me, that there is a >>> central point of selection for this end to end sequence (barring >>> reclassification, of course). I, for one, am questioning that >>> implication. I have been uncomfortable with that central point >>> methodology due to real-world complexities of dynamic scale and >>> timeliness of reaction to failures. >>> >>> <Maria> I agree. It should not be mandated by the SFC architecture that >>> something called “service function path ID†is carried in the packet, >>> because it is not necessary or the only way to implement service >>> chaining. There might solutions that would do that but it cannot and >>> doesn’t need to be mandated. >>> >>> Maria >>> >>> An alternative approach is to still use central selection to select the >>> chain of abstract service functions (i.e., SFC ID 1 = {SF-A, SF-B, >>> SF-C}), but allow the actual instance selection to be distributed, >>> realized by the classifier and the SFFs. >>> >>> Given a topology like: >>> >>> Classifier ------- SFF-1 -------------------- SFF-2 >>> -------------------- SFF-3-------------------SFF-4 >>> >>> | | >>> | | | >>> | | >>> >>> SFF-A-1 SFF-A-2 SSF-B-1 >>> SFF-B-2 SFF-C-1 SFF-C-2 SFF-A-3 >>> >>> And assuming a newly recognized flow, the sequence could go something >>> like this: >>> >>> 1 Classifier selects chain SFC ID 1 {SF-A, SF-B, SF-C} >>> >>> 2 Classifier selects SFF-1 as hosting at least one instance of SF-A >>> >>> 3 Classifier encapsulates packet indicating chain ID = 1, service index >>> = 1 >>> >>> 4 Classifier progresses packet to SFF-1 >>> >>> 5 SFF-1, seeing chain ID=1, service index=1, chooses SFF-A-2 amongst its >>> available instances of SF-A >>> >>> 6 SFF-1 sends packet to SFF-A-1 >>> >>> 7 SFF-A-1 sends packet back to SFF-1 >>> >>> 8 SFF-1 increments service index to 2 >>> >>> 8 SFF-1 selects SFF-2 as hosting at least one instance of SF-B >>> >>> 9 SFF-1 progresses packet to SFF-2 >>> >>> 10 process repeats per above until SFF-3, as the egress border, >>> progresses the packet per routing table >>> >>> Thanks. >>> >>> Ron >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Xuxiaohu >>> *Sent:* Sunday, July 13, 2014 11:30 PM >>> *To:* mikebianc@aol.com <mailto:mikebianc@aol.com>; jguichar@cisco.com >>> <mailto:jguichar@cisco.com>; mn1921@att.com <mailto:mn1921@att.com>; >>> mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>; >>> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>; Ron Parker; >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> *Subject:* [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load >>> Balancers >>> >>> Agree that the current definition of the SFP in the arch draft is a bit >>> confusing, just as what you had pointed out. >>> >>> >>> >>> In my understanding, the SFP as an instantiation of an SFC in the >>> network should be “an ordered list of service nodes and SF IDsâ€(see >>> http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01). Of >>> course, how to represent the SFP in the data packet is another thing >>> (e.g., either through a path id or through an MPLS label stack). Here >>> the service node means the device which contains the SFF and the NF >>> components mandatorily while containing the SF and SF proxy components >>> optionally. The service node could be attached or embedded with multiple >>> SF instances and those SF instances could be of the same SF type or not. >>> In the case where there are multiple SF instances of the same SF type >>> (e.g., SF X) are attached to a given service node, the service node >>> could distribute the traffic which needs SF X among those SF instances >>> of SF X type locally. Meanwhile, there may be multiple service nodes >>> within a given SFC-enabled domain which are embedded or attached with >>> the SF >> instance >> s of the same SF type. In this way, the SF load-balancing would be made >> very flexible. >>> >>> Best regards, >>> >>> Xiaohu >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of >>> *mikebianc@aol.com <mailto:mikebianc@aol.com> >>> *Sent:* Saturday, July 12, 2014 2:46 AM >>> *To:* jguichar@cisco.com <mailto:jguichar@cisco.com>; mn1921@att.com >>> <mailto:mn1921@att.com>; mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>; jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>; Ron_Parker@affirmednetworks.com >>> <mailto:Ron_Parker@affirmednetworks.com>; sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Wouldn't that be called the "service chain identifier" then? If the >>> service chain is the ordered list of SFs and the service path is the >>> ordered list of SF instances, then I would infer that a "service path >>> identifier" would be an identifier for a service *path*, not a service >>> *chain*. >>> >>> >>> Again, I think this is where the confusion keeps creeping in. The terms >>> "chain" and "path" seem inconsistent. >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *jguichar@cisco.com<jguichar@cisco.com >>> <mailto:jguichar@cisco.com%3cjguichar@cisco.com>> >>> *To: >>> >>> *mikebianc@aol.com<mikebianc@aol.com>,mn1921@att.com<mn1921@att.com>,moha >>> med.boucadair@orange.com<mohamed.boucadair@orange.com>,jmh@joelhalpern.co >>> m<jmh@joelhalpern.com>,Ron_Parker@affirmednetworks.com<Ron_Parker@affirme >>> dnetworks.com>,sfc@ietf.org<sfc@ietf.org >>> >>> <mailto:mikebianc@aol.com%3cmikebianc@aol.com%3e,mn1921@att.com%3cmn1921@ >>> att.com%3e,mohamed.boucadair@orange.com%3cmohamed.boucadair@orange.com%3e >>> ,jmh@joelhalpern.com%3cjmh@joelhalpern.com%3e,Ron_Parker@affirmednetworks >>> .com%3cRon_Parker@affirmednetworks.com%3e,sfc@ietf.org%3csfc@ietf.org>> >>> *Sent: *Friday, July 11, 2014 >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Your definition of service path is correct as its the forwarding path >>> through which traffic will actually flow. The service path identifier >>> however points to the service chain data structure and that is then >>> resolved to specific instances based upon which next-hops to those >>> instances are available and whatever load distribution technique is in >>> play. When instantiating the service chain into the network you may or >>> may not update that data structure to specify which next-hops may be >>> used (where a single next-hop would effectively nail up the service path >>> for that service chain) or you may simply allow some other protocol / >>> mechanism to populate the data structure for you. >>> >>> *From: *"mikebianc@aol.com <mailto:mikebianc@aol.com>" >>> <mikebianc@aol.com <mailto:mikebianc@aol.com>> >>> *Date: *Friday, July 11, 2014 at 12:18 PM >>> *To: *Jim Guichard <jguichar@cisco.com <mailto:jguichar@cisco.com>>, >>> "mn1921@att.com <mailto:mn1921@att.com>" <mn1921@att.com >>> <mailto:mn1921@att.com>>, "mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>>, "jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>" <jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>>, "Ron_Parker@affirmednetworks.com >>> <mailto:Ron_Parker@affirmednetworks.com>" >>> <Ron_Parker@affirmednetworks.com >>> <mailto:Ron_Parker@affirmednetworks.com>>, "sfc@ietf.org >>> <mailto:sfc@ietf.org>" <sfc@ietf.org <mailto:sfc@ietf.org>> >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I think this is the root of the confusion: >>> >>>> I don’t want to specify >>>> specific instances of S1, S2, and S3 (or some combination thereof). I >>>> assign a service path identifier “100†that basically points to >>>> S1->S2->S3 >>>> and then push this into the network >>> >>> By definition, I understood a "service path" to be an ordered list of >>> specific SF instances. In the statement above, you use a "service path >>> identifier" to refer to a service *chain* that specifically "[does not] >>> specify specific instances". >>> >>> ------------------------------------------------------------------------ >>> >>> *From: *jguichar@cisco.com >>> <mailto:jguichar@cisco.com><jguichar@cisco.com >>> <mailto:jguichar@cisco.com>> >>> *To: *NAPIERALA, MARIA H<mn1921@att.com >>> <mailto:mn1921@att.com>>,mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com><mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>>,Joel M. >>> Halpern<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>,Ron >>> Parker<Ron_Parker@affirmednetworks.com >>> <mailto:Ron_Parker@affirmednetworks.com>>,sfc@ietf.org >>> <mailto:sfc@ietf.org><sfc@ietf.org <mailto:sfc@ietf.org>> >>> *Sent: *Friday, July 11, 2014 >>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> Maria, >>> >>> I think of it this way. The service path identifier is simply a pointer >>> to >>> a data structure that contains SF to next-hop mappings. When you define >>> a >>> chain, let’s say S1 ->S2-> S3, you *might* when creating the SFP specify >>> the specific next-hops that you want traffic to flow through for that >>> SFP. >>> However, you do *not* have to do this from an architectural standpoint >>> (I >>> will argue that you should but you don’t have to architecturally). You >>> could simply assign a service path identifier to point to a given SFC >>> and >>> then push that information into the network. At the SFF it will have a >>> service path identifier to SFC mapping and said mapping would contain >>> the >>> next-hops available for each of the SF’s within the SFC - how you learn >>> those next-hops is up to you. You could push them down from a >>> centralized >>> controller, configure them through CLI, learn them dynamically through >>> some protocol exchange, whatever .. So, given this it is not correct to >>> say that the service path means that all SF instances are chosen a >>> priori >>> although it is perfectly acceptable (and some would say recommended) to >>> do >>> so. >>> >>> Let’s take an example to hopefully make this clear: >>> >>> I define an SFC (let’s refer to it as SFC-1) S1->S2->S3. For arguments >>> sake let’s say I want it to be fully dynamic e.g. I don’t want to >>> specify >>> specific instances of S1, S2, and S3 (or some combination thereof). I >>> assign a service path identifier “100†that basically points to >>> S1->S2->S3 >>> and then push this into the network so that the SFF data structures are >>> populated with this information. Now at a given SFF, when traffic >>> arrives >>> with service path identifier 100, the SFF will look this up in the data >>> structure and find that it points to S1->S2->S3 and the index in the SFC >>> encapsulation will tell it exactly where it is in the chain. Let’s say >>> we >>> are at S2 in the chain. The SFF will now have to resolve the next-hop to >>> S3 and will do a lookup to determine where S3 is reachable. >>> >>> On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <mn1921@att.com >>> <mailto:mn1921@att.com>> wrote: >>> >>> >Jim, >>> > >>> >Could you tell us what is the definition of a "service path" and a >>> >"service path identifier"? >>> >If a service path means that all SF instances are chosen apriori >>> (which >>> >is my current understanding) then it is not SFF's local decision which >>> >next-hop SFF to pick. It is a centralized decision. >>> > >>> >Maria >>> > >>> > >>> >> -----Original Message----- >>> >> >>> >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> >> Sent: Friday, July 11, 2014 11:15 AM >>> >> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>; Joel M. >>> >> Halpern; Ron Parker; sfc@ietf.org <mailto:sfc@ietf.org> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> >>> >> I’m sorry but I really don’t understand why a service path >>> identifier >>> >> prevents full distribution of SF next-hops or why calling it a >>> service >>> >> chain identifier makes any difference? >>> >> >>> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com >>> <mailto:mn1921@att.com>> wrote: >>> >> >>> >> >Ditto. >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com> >>> >> >> [mailto:mohamed.boucadair@orange.com] >>> >> >> Sent: Friday, July 11, 2014 10:31 AM >>> >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. >>> Halpern; Ron >>> >> >> Parker; sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers >>> >> >> >>> >> >> Re-, >>> >> >> >>> >> >> For what I can say at best this is not described clearly in the >>> >>draft. >>> >> >> >>> >> >> Mandating a service path identifier is in itself a hint that the >>> full >>> >> >>distributed >>> >> >> model is not allowed. >>> >> >> >>> >> >> Several voices in this thread indicated that the service chain >>> itself >>> >> >>should be >>> >> >> provided instead. >>> >> >> >>> >> >> Cheers, >>> >> >> Med >>> >> >> >>> >> >> >-----Message d'origine----- >>> >> >> >De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim >>> Guichard >>> >> >> >(jguichar) >>> >> >> >Envoyé : vendredi 11 juillet 2014 16:18 >>> >> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> >> > >>> >> >> >Ok but where in the architecture specifically is this >>> functionality >>> >> >> >prohibited? If you want to distribute *all* next-hops to *all* >>> SFF’s >>> >> >> >within the SFC domain and then let the path identifier point to >>> a >>> >> >>lookup >>> >> >> >into those next-hops to reach the next SF in the chain, I am not >>> >>sure >>> >> >>how >>> >> >> >the architecture prevents that? >>> >> >> > >>> >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com >>> <mailto:mn1921@att.com>> >>> >> wrote: >>> >> >> > >>> >> >> >>Absolutely. >>> >> >> >> >>> >> >> >>> -----Original Message----- >>> >> >> >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>> Guichard >>> >> >> >>>(jguichar) >>> >> >> >>> Sent: Friday, July 11, 2014 9:54 AM >>> >> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >> >> >>> >>> >> >> >>> Then I misunderstand the proposal ;-) .. However, it seems >>> to me >>> >> >>that if >>> >> >> >>> you allow an SFF to make a decision as to which remote SFF it >>> >>will >>> >> >>use >>> >> >> >>>for >>> >> >> >>> a given flow to reach the next SF within the chain then you >>> >>better >>> >> >>make >>> >> >> >>> sure that that remote SFF has the necessary forwarding logic >>> to >>> >> >>reach >>> >> >> >>>the >>> >> >> >>> next-next-SF for the chain as otherwise you are in deep >>> trouble. >>> >> >> >>> >>> >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <mn1921@att.com >>> <mailto:mn1921@att.com>> >>> >> >> wrote: >>> >> >> >>> >>> >> >> >>> >Absolutely not. Service chains can be instantiated only in >>> >>relevant >>> >> >> >>>SFFs >>> >> >> >>> >when they "arrive". >>> >> >> >>> > >>> >> >> >>> >> -----Original Message----- >>> >> >> >>> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>> >>Guichard >>> >> >> >>> >>(jguichar) >>> >> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM >>> >> >> >>> >> To: Joel M. Halpern; Ron Parker; sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> >> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load >>> Balancers >>> >> >> >>> >> >>> >> >> >>> >> Well I think it is even worse than that if I have >>> understood >>> >>the >>> >> >> >>> >>proposal >>> >> >> >>> >> correctly as it would require full knowledge of every >>> single >>> >>SF >>> >> >> >>>within >>> >> >> >>> >>the >>> >> >> >>> >> entire SFC domain at every single SFF as there is no way >>> to >>> >>know >>> >> >>a >>> >> >> >>> >>priori >>> >> >> >>> >> which SFC¹s a given SFF will need to service at any given >>> >>point >>> >> >>in >>> >> >> >>>time. >>> >> >> >>> >> >>> >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" >>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> >>> >> >> wrote: >>> >> >> >>> >> >>> >> >> >>> >> >Ron, thinking about this, I realized another major >>> problem >>> >>with >>> >> >>the >>> >> >> >>> >>your >>> >> >> >>> >> >proposal as I understand it. (And I readily admit I may >>> not >>> >> >> >>>understand >>> >> >> >>> >> >it.) >>> >> >> >>> >> > >>> >> >> >>> >> >The proposal has each SFF serve as the load balancer for >>> the >>> >> >>next >>> >> >> >>> >> >service function that follows it (not the one it delivers >>> >>to), >>> >> >>in >>> >> >> >>>every >>> >> >> >>> >> >service chain that goes through it. >>> >> >> >>> >> > >>> >> >> >>> >> >Since it has to be able to work with all services, that >>> means >>> >> >>that >>> >> >> >>> >>every >>> >> >> >>> >> >SFF would have to be a full, flow sensitive and stateful >>> load >>> >> >> >>>balancer. >>> >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and / >>> or >>> >> >>stateful. >>> >> >> >>> >> >But having the architecture require that every SFF be a >>> full, >>> >> >>flow >>> >> >> >>> >> >sensitive, stateful, load balancer seems to me to be an >>> >> >>acceptable >>> >> >> >>> >> >imposition. >>> >> >> >>> >> > >>> >> >> >>> >> >Yours, >>> >> >> >>> >> >Joel >>> >> >> >>> >> > >>> >> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote: >>> >> >> >>> >> >> Part of my personal view is that I am trying to make >>> this >>> >>work >>> >> >> >>> >>sensibly >>> >> >> >>> >> >> in a more orchestrated environment. I expect that the >>> >>service >>> >> >> >>> >> >> functions, and over time probably the SFF capabilities, >>> >>will >>> >> >>be >>> >> >> >>> >> >> orchestrated and installed. I expect the service chains >>> >>to be >>> >> >> >>> >>driven by >>> >> >> >>> >> >> BSS tools that define offerings to clients, and enable >>> >> >> >>>self-selection >>> >> >> >>> >> >> from these. I expect service paths to be heavily policy >>> >> >>drive. >>> >> >> >>> >> >> >>> >> >> >>> >> >> I can see how to make all of that work in an >>> archtiecture >>> >> >>driven >>> >> >> >>>by >>> >> >> >>> >> >> initial classification to described service paths. It >>> is >>> >> >>harder >>> >> >> >>>to >>> >> >> >>> >>see >>> >> >> >>> >> >> how to make it work (but it can be done) when we allow >>> more >>> >> >> >>> >> dynamicity >>> >> >> >>> >> >> in the network behavior. >>> >> >> >>> >> >> >>> >> >> >>> >> >> Having said that, most of that perspective I described >>> is >>> >> >>outside >>> >> >> >>>of >>> >> >> >>> >>the >>> >> >> >>> >> >> scope of the working group. it is not something we are >>> >> >>tasked to >>> >> >> >>> >>agree >>> >> >> >>> >> >>on. >>> >> >> >>> >> >> So I do not claim that vision means we have to do it a >>> >>certain >>> >> >> >>>way. >>> >> >> >>> >>it >>> >> >> >>> >> >> is just the perspective that drives my preferences. >>> >> >> >>> >> >> >>> >> >> >>> >> >> Yours, >>> >> >> >>> >> >> Joel >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote: >>> >> >> >>> >> >>>> For me, the amount of information about service >>> instances >>> >> >> that >>> >> >> >>> >>needs >>> >> >> >>> >> >>>>to >>> >> >> >>> >> >>>> be widely distributed and maintained, potentially >>> even >>> >> >>across >>> >> >> >>>data >>> >> >> >>> >> >>>> centers within an administrative scope, is large >>> enough >>> >>and >>> >> >> >>> complex >>> >> >> >>> >> >>>> enough that trying to get that into each SFF seems >>> like a >>> >> >> >>>difficult >>> >> >> >>> >> >>>> architecture to realize. >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> I'm curious as to why that is more complicated than >>> >>dynamic >>> >> >> >>> routing, >>> >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of >>> >>which >>> >> >>are >>> >> >> >>> >>bigger >>> >> >> >>> >> >>> problems that have been profitably and stably >>> implemented? >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> It also seems that if it really is more complicated, >>> that >>> >>is >>> >> >>a >>> >> >> >>>good >>> >> >> >>> >> >>> sign that it is too complicated. >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> ________________________________________ >>> >> >> >>> >> >>> From: Joel M. Halpern [jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>] >>> >> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM >>> >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; mikebianc@aol.com >>> <mailto:mikebianc@aol.com>; >>> >>Ian >>> >> >> >>>Smith; >>> >> >> >>> >> >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load >>> >>Balancers >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> This is an architectural issue. And one that I would >>> >>prefer >>> >> >>we >>> >> >> >>> >> >>>actually >>> >> >> >>> >> >>> decide, rather than trying to allow all possible >>> >> >>implementations. >>> >> >> >>> >> >>> Because it does have a major effect on the control >>> >> >>requirements >>> >> >> >>>and >>> >> >> >>> >> the >>> >> >> >>> >> >>> functionality of SFFs. >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> For me, the amount of information about service >>> instances >>> >> >>that >>> >> >> >>> needs >>> >> >> >>> >> to >>> >> >> >>> >> >>> be widely distributed and maintained, potentially even >>> >> across >>> >> >> >>>data >>> >> >> >>> >> >>> centers within an administrative scope, is large >>> enough >>> >>and >>> >> >> >>>complex >>> >> >> >>> >> >>> enough that trying to get that into each SFF seems >>> like a >>> >> >> >>>difficult >>> >> >> >>> >> >>> architecture to realize. >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> Yours, >>> >> >> >>> >> >>> Joel >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> But it is a fair question. >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote: >>> >> >> >>> >> >>>> This is the crux of my issue. Is the end to end >>> >>selection >>> >> >>of >>> >> >> >>> >> >>>> (top-level) instances performed centrally (perhaps >>> by the >>> >> >> >>> >>classifier) >>> >> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and >>> subsequently >>> >> >>the >>> >> >> >>> >>SFFs)? >>> >> >> >>> >> >>>> Such selection is not equivalent to reclassification. >>> >>And >>> >> >> >>>surely, >>> >> >> >>> >> >>>> this is an architectural issue and not relegated to >>> >> >> >>> >> >>>> "implementation". >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> My own view is to favor the distributed approach even >>> >> though >>> >> >> a >>> >> >> >>> >> >>>> greater amount of data (chain definitions and perhaps >>> >>local >>> >> >> >>> >>selection >>> >> >> >>> >> >>>> policy) is required at those distributed decision >>> points. >>> >> >>This >>> >> >> >>> >> >>>> approach does not require an end-to-end path id at >>> all. >>> >> >>My >>> >> >> >>> >> >>>> rationale for favoring this approach is primarily >>> driven >>> >>by >>> >> >> >>> >>increased >>> >> >> >>> >> >>>> resiliency over the global path id approach. With a >>> >>global >>> >> >> >>>path >>> >> >> >>> >>id >>> >> >> >>> >> >>>> approach, consider failure of an instance and >>> needing to >>> >> >>alter >>> >> >> >>>the >>> >> >> >>> >> >>>> global path ID table for each and every affected >>> >>end-to-end >>> >> >> >>>path. >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> Ron >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> ________________________________________ From: sfc >>> >> >> >>> >> >>>> [sfc-bounces@ietf.org <mailto:sfc-bounces@ietf.org>] >>> on behalf of Joel Halpern Direct >>> >> >> >>> >> >>>> [jmh.direct@joelhalpern.com >>> <mailto:jmh.direct@joelhalpern.com>] Sent: Thursday, July 10, >>> >>2014 >>> >> >> 6:15 >>> >> >> >>> PM >>> >> >> >>> >> >>>> To: mikebianc@aol.com <mailto:mikebianc@aol.com>; >>> I.Smith@F5.com <mailto:I.Smith@F5.com>; sfc@ietf.org >>> <mailto:sfc@ietf.org> >>> >> Subject: >>> >> >> Re: >>> >> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> The way the architecture models the case of SF1 >>> needing >>> >>to >>> >> >> >>> >>influence >>> >> >> >>> >> >>>> the chain is that one would do reclassification at >>> the >>> >>exit >>> >> >>from >>> >> >> >>> >> >>>> SF1. >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> Part of the goal is to keep the different functions >>> >> >>logically >>> >> >> >>> >> >>>> separate so that solutions can clearly describe how >>> they >>> >> >> choose >>> >> >> >>>to >>> >> >> >>> >> >>>> compose them for "service" delivery. >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> Yours, Joel >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> On 7/10/14, 6:10 PM, mikebianc@aol.com >>> <mailto:mikebianc@aol.com> wrote: >>> >> >> >>> >> >>>>> I don't see anything in the arch draft that >>> suggests any >>> >> >>sort >>> >> >> >>>of >>> >> >> >>> >> >>>>> limit. However, it does seem to indicate that the >>> entire >>> >> >>path >>> >> >> >>>(all >>> >> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation. I believe >>> >>this >>> >> >> >>>means >>> >> >> >>> >> >>>>> either at the classifier or maybe the classifier >>> >>chooses a >>> >> >>SF >>> >> >> >>> >>Chain >>> >> >> >>> >> >>>>> and the NF or at the latest the first SFF. In any >>> case, >>> >> >>the >>> >> >> >>> >> >>>>> language does seem to prohibit a more dynamic SFP >>> where >>> >> >> SFI(n) >>> >> >> >>> is >>> >> >> >>> >> >>>>> determined at the SFI(n-1) hop. According to the >>> draft, >>> >> >>this >>> >> >> >>> >> >>>>> behavior would be considered "branching" to a new >>> SFP as >>> >> >> >>> opposed >>> >> >> >>> >> to >>> >> >> >>> >> >>>>> choosing and then forwarding to the selected >>> instance of >>> >> >>the >>> >> >> >>> >> >>>>> next-hop of the current SFC. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> draft-merged-sfc-architecture-00: >>> >> >> >>> >> >>>>>> When an SFC is instantiated into the network it is >>> >> >>necessary >>> >> >> >>>to >>> >> >> >>> >> >>>>>> select the specific instances of SFs that will be >>> used, >>> >> >>and to >>> >> >> >>> >> >>>>>> create the service topology for that SFC using SF's >>> >> >>network >>> >> >> >>> >> >>>>>> locator. Thus, instantiation of the SFC results in >>> the >>> >> >> >>>creation >>> >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for >>> >> >>forwarding >>> >> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP is >>> the >>> >> >> >>> >> >>>>>> instantiation of the defined SFC. >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> The SFC architecture supports reclassification (or >>> >> >>non-initial >>> >> >> >>> >> >>>>>> classification) as well. As packets traverse an >>> SFP, >>> >> >> >>> >> >>>>>> reclassification may occur - typically performed >>> by a >>> >> >> >>> >> >>>>>> classification function co-resident with a service >>> >> >>function. >>> >> >> >>> >> >>>>>> Reclassification may result in the selection of a >>> new >>> >> >>SFP, an >>> >> >> >>> >> >>>>>> update of the associated metadata, or both. This is >>> >> >>referred >>> >> >> >>>to >>> >> >> >>> >> >>>>>> as "branching". >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>> >> >> >>> >>> >> >> >>> >> >>> >>>>>>>>>>>>>>>>> ----------------------------------------------------------- >>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>-- >>> >> >>>>>>>>>>>>--- >>> >> >> >>>>>>>>>>-- >>> >> >> >>> >>>>>>>-- >>> >> >> >>> >> >>>>>-- >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>> *From: *I.Smith@F5.com >>> <mailto:*I.Smith@F5.com><I.Smith@F5.com <mailto:I.Smith@F5.com>> >>> >> >> >>> >> >>>>> *To: *Joel Halpern >>> >> Direct<jmh.direct@joelhalpern.com >>> <mailto:jmh.direct@joelhalpern.com>>,Joel >>> >> >> M. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>> >> >> >>> >>> >> >> >>> >> >>>>>Halpern<jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>>,huang@sce.carleton.ca >>> <mailto:huang@sce.carleton.ca><huang@sce. >>> <mailto:huang@sce.%0b>>> >> >>> >> carleton. >>> >> >> >>> >> >>>>>ca>,sfc@ietf.org <mailto:sfc@ietf.org><sfc@ietf.org >>> <mailto:sfc@ietf.org>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>> *Sent: *Thursday, July 10, 2014 >>> >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load >>> >> >>Balancers >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> Actually, I think I am disagreeing. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> If the possibility of medium-scale deployments (and >>> >>that is >>> >> >> >>>what >>> >> >> >>> >> >>>>> 16 million flows is in my world) of service chains >>> is >>> >> >> >>>preconceived >>> >> >> >>> >> >>>>> as an absurd idea, then the architecture burdened >>> with >>> >> that >>> >> >> >>> >> >>>>> preconception. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> There has to be some point of aim, some degree of >>> >> >>aspiration >>> >> >> to >>> >> >> >>> >> >>>>> scale that is appropriate for the lifespan of the >>> >> >>architecture >>> >> >> >>>- >>> >> >> >>> >> >>>>> you don't have to know what it is, but by saying >>> that an >>> >> >> >>>arbitrary >>> >> >> >>> >> >>>>> number is "too far", you're creating - even if it >>> isn't >>> >> >> >>> >>intentional >>> >> >> >>> >> >>>>> - a limit that influences decisions that have >>> lasting >>> >> >>impacts >>> >> >> >>> >> >>>>> regarding scale-out, failure mitigation, elasticity, >>> >> >>address >>> >> >> >>> >> >>>>> space... all kinds of things. That is a problem I'm >>> not >>> >> >> >>> >> >>>>> particularly eager to deal with. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> ________________________________________ >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> From: Joel Halpern Direct >>> [jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>] >>> >> >>Sent: >>> >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel >>> M. >>> >> >> Halpern; >>> >> >> >>> >> >>>>> huang@sce.carleton.ca >>> <mailto:huang@sce.carleton.ca>; sfc@ietf.org <mailto:sfc@ietf.org> >>> Subject: Re: [sfc] >>> >> >>Service >>> >> >> >>> >> >>>>> Chains, Paths, and Load Balancers >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all in >>> this >>> >> >>regard. >>> >> >> >>>I >>> >> >> >>> >>am >>> >> >> >>> >> >>>>> not requesting the the architecture or the solution >>> >> >>prohibit >>> >> >> >>> >> >>>>> deployments in the specific fashion. I am objecting >>> to >>> >> >>Huang's >>> >> >> >>> >> >>>>> reading of my note as saying that such deployments >>> are >>> >> >> required >>> >> >> >>> >> >>>>> they by the archtiecture. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to >>> prohibit >>> >>such >>> >> >> >>> >> >>>>> things. Whether they are a good idea or not depends >>> upon >>> >> >> many >>> >> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to >>> >>think >>> >> >>that >>> >> >> >>> >>they >>> >> >> >>> >> >>>>> are usually a bad idea. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> But the archtiecture si carefully avoiding >>> attempting to >>> >> >>know >>> >> >> >>>what >>> >> >> >>> >> >>>>> is and is not eployable. >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> Yours, Joel >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote: >>> >> >> >>> >> >>>>>> I disagree. >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> We routinely have stateful devices that manage >>> tens of >>> >> >> >>>millions >>> >> >> >>> >> >>>>>> of >>> >> >> >>> >> >>>>> concurrent flows in both access network and data >>> center >>> >> >> >>> >> >>>>> environments today. You can't seriously believe >>> that in >>> >>the >>> >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you >>> >> are >>> >> >> only >>> >> >> >>> >> going >>> >> >> >>> >> >>>>> to have small numbers of service chains with equally >>> >>small >>> >> >> >>> numbers >>> >> >> >>> >> >>>>> of active service paths? >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> Your sounds too much like "no one will ever need >>> more >>> >> than >>> >> >> >>> 64K" >>> >> >> >>> >> >>>>>> for >>> >> >> >>> >> >>>>> comfort. >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> ________________________________________ From: sfc >>> >> >> >>> >> >>>>>> [sfc-bounces@ietf.org >>> <mailto:sfc-bounces@ietf.org>] on behalf of Joel M. Halpern >>> >> >> >>> >> >>>>> [jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>] >>> >> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: >>> >> >> >>>huang@sce.carleton.ca <mailto:huang@sce.carleton.ca>; >>> >> >> >>> >> >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> Subject: Re: >>> [sfc] Service Chains, Paths, >>> >>and >>> >> >> >>>Load >>> >> >> >>> >> >>>>>> Balancers >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> No, it will mean that if someone tries to deploy >>> the >>> >> >> >>>archtieture >>> >> >> >>> >> >>>>>> particularly badly, they will exceed the limits of >>> >>their >>> >> >> >>> >> >>>>>> devices. The architecture does not require such >>> absurd >>> >> use >>> >> >> of >>> >> >> >>> >> >>>>>> service paths. Since I can not figure out how to >>> write >>> >> >> >>> >> >>>>>> architectural words to prohibit it, the >>> architecture >>> >>does >>> >> >> >>>permit >>> >> >> >>> >> >>>>>> such abuse. >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> Please do not read my saying that the archtiecture >>> >> permits >>> >> >> >>> >> >>>>>> something as saying it is either deisred or >>> required by >>> >> >>the >>> >> >> >>>work. >>> >> >> >>> >> >>>>>> It isn't. >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> Yours, Joel >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote: >>> >> >> >>> >> >>>>>>> If you need to support 100 service chains, it will >>> >>mean >>> >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing >>> >>table >>> >> >>of a >>> >> >> >>> >> >>>>>>> core router. >>> >> >> >>> >> >>>>>>> >>> >> >> >>> >> >>>>>>> Chang >>> >> >> >>> >> >>>>>>> >>> >> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote: >>> >> >> >>> >> >>>>>>>> The architecture allows a range of deployments, >>> from >>> >>1 >>> >> >> >>> >> >>>>>>>> service path to 160000 service paths. I would >>> hope >>> >>that >>> >> >> >>> >> >>>>>>>> operators are prepared for the complexities if >>> they >>> >> >>choose >>> >> >> >>>to >>> >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in >>> stead >>> >> >> provision >>> >> >> >>> >> >>>>>>>> 160,000 service paths. >>> >> >> >>> >> >>>>>>>> >>> >> >> >>> >> >>>>>>>> Yours, Joel >>> >> >> >>> >> >>>>>>>> >>> >> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote: >>> >> >> >>> >> >>>>>>>>> Paul, >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> How many path identifiers there will be for a 4 >>> hop >>> >> >> service >>> >> >> >>> >> >>>>>>>>> chain with 20 instances at each hop? >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Maria >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On >>> Behalf >>> >> Of >>> >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, >>> 2014 >>> >> >>3:03 >>> >> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com>; >>> >> >> >>> >> >>>>>>>>> mohamed.boucadair@orange.com >>> <mailto:mohamed.boucadair@orange.com>; sfc@ietf.org >>> <mailto:sfc@ietf.org>; >>> >> >> >>> >> >>>>>>>>> mikebianc@aol.com <mailto:mikebianc@aol.com> >>> *Subject:* Re: [sfc] Service >>> >> Chains, >>> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Lucy, >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives >>> the >>> >> >> >>> >> >>>>>>>>> forwarding. I¹d >>> >> >> >>> >> >>>>> make >>> >> >> >>> >> >>>>>>>>> the minor change: the path identifier can be >>> used to >>> >> >> derive >>> >> >> >>> >> >>>>>>>>> the needed forwarding and associated transport. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to >>> >>simply >>> >> >> >>> >> >>>>>>>>> identify the service path (or graph) that >>> packets >>> >>must >>> >> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exact >>> >> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on >>> >>this >>> >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path >>> >> >> identifier >>> >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that >>> lookup can >>> >> >> result >>> >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) transport >>> next >>> >> >> >>> >> >>>>>>>>> hop(s). >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Paul >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong >>> >> >> >>> >> >>>>>>>>> <lucy.yong@huawei.com >>> <mailto:lucy.yong@huawei.com> >>> >> >> <mailto:lucy.yong@huawei.com> <mailto:lucy.yong@huawei.com%3e>> >>> >> >> >>> >> >>>>>>>>> wrote: >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only >>> use of >>> >> the >>> >> >> >>> >> >>>>>>>>> service path identifier to drive the forwarding >>> >> >>actions. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Lucy >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On >>> Behalf >>> >> >> >>> >> >>>>>>>>> Of*mohamed.boucadair@orange.com >>> <mailto:Of*mohamed.boucadair@orange.com> >>> >> >> >>> >> >>>>>>>>> <mailto:mohamed.boucadair@orange.com> >>> >> >> >>> *Sent:*Thursday, >>> >> >> >>> >> July >>> >> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:*mikebianc@aol.com >>> <mailto:*mikebianc@aol.com> >>> >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com>;jmh@joelhalpern.com >>> <mailto:mikebianc@aol.com%3e;jmh@joelhalpern.com> >>> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >>> <mailto:jmh@joelhalpern.com%3e;sfc@ietf.org> >>> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Subject:*Re: [sfc] >>> Service >>> >> >>Chains, >>> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Re-, >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a service >>> path >>> >> >> >>> >> >>>>>>>>> identifier. I object to use that identifier to >>> >>derive >>> >> >> >>> >> >>>>>>>>> forwarding actions. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full >>> knowledge of >>> >> >> every >>> >> >> >>> >> >>>>> available SFC >>> >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain >>> is not >>> >> >> >>> >> >>>>> required/justified >>> >> >> >>> >> >>>>>>>>> nor possible in various deployment contexts. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece >>> of >>> >> >> >>> >> >>>>>>>>> information >>> >> >> >>> >> >>>>> that will >>> >> >> >>> >> >>>>>>>>> be present in all deployments: that is the one >>> >> required >>> >> >> to >>> >> >> >>> >> >>>>>>>>> structure a service chain. How that information >>> is >>> >> >>used to >>> >> >> >>> >> >>>>>>>>> infer forwarding >>> >> >> >>> >> >>>>> actions >>> >> >> >>> >> >>>>>>>>> is a solution-oriented discussion. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Cheers, >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Med >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org]*De la >>> part >>> >> >> >>> >> >>>>> de*mikebianc@aol.com <mailto:de*mikebianc@aol.com> >>> >> >> >>> >> >>>>>>>>> <mailto:mikebianc@aol.com> *Envoyé :*mercredi 9 >>> >> >> juillet >>> >> >> >>> >> >>>>>>>>> 2014 22:03 *À :*jmh@joelhalpern.com >>> <mailto:*jmh@joelhalpern.com> >>> >> >> >>> >> >>>>>>>>> <mailto:jmh@joelhalpern.com>;sfc@ietf.org >>> <mailto:jmh@joelhalpern.com%3e;sfc@ietf.org> >>> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org> *Objet :*Re: [sfc] Service >>> >> >>Chains, >>> >> >> >>> >> >>>>>>>>> Paths, and Load Balancers >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference >>> between >>> >>SF >>> >> >> Chain >>> >> >> >>> >> >>>>>>>>> and SF >>> >> >> >>> >> >>>>> Path? >>> >> >> >>> >> >>>>>>>>> Other than clarifying the definition so that >>> it's >>> >> >>clear to >>> >> >> >>> >> >>>>> those not >>> >> >> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone >>> >>agrees >>> >> >>on >>> >> >> >>> >> >>>>>>>>> these terms. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear is >>> >>whether >>> >> >>it is >>> >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify >>> what >>> >> >>the ID >>> >> >> >>> >> >>>>>>>>> of the SFC Header >>> >> >> >>> >> >>>>> should >>> >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if this >>> draft >>> >> >>simply >>> >> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other >>> >>drafts >>> >> >>to >>> >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on >>> chain >>> >> or >>> >> >> >>> >> >>>>>>>>> path and the choice of chain or >>> >> >> >>> >> >>>>> path to >>> >> >> >>> >> >>>>>>>>> be negotiated in the control-plane. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would >>> have >>> >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported (or >>> make >>> >> >> one >>> >> >> >>> >> >>>>>>>>> required and the other optional) to avoid some >>> >> vendors >>> >> >> only >>> >> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>> >> >> >>> >>> >> >> >>> >> >>> >>>>>>>>>>>>>>>>> ----------------------------------------------------------- >>>>>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>>-- >>> >> >>>>>>>>>>>>--- >>> >> >> >>>>>>>>>>-- >>> >> >> >>> >>>>>>>-- >>> >> >> >>> >> >>>>>-- >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>>>> >>> >> >> >>> >> >>>>>>>>> *From:*jmh@joelhalpern.com >>> <mailto:*jmh@joelhalpern.com><jmh@joelhalpern.com >>> <mailto:jmh@joelhalpern.com> >>> >> >> >>> >> >>>>>>>>> >>> >> >> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com> >>> <mailto:jmh@joelhalpern.com%3cjmh@joelhalpern.com%3e>> >>> >> >> >>> >> >>>>>>>>> *To:*sfc@ietf.org >>> <mailto:*sfc@ietf.org><sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> >> >>>>>>>>> <mailto:sfc@ietf.org%3csfc@ietf.org> >>> <mailto:sfc@ietf.org%3csfc@ietf.org%3e>> >>> >> *Sent:*Tuesday, >>> >> >> July >>> >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, >>> and >>> >>Load >>> >> >> >>> >> >>>>>>>>> Balancers >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> I have been trying to figure out how to clearly >>> >>answer >>> >> >>a >>> >> >> >>> >> >>>>>>>>> number of comments that have been made about the >>> >> >> >>> proposed >>> >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get >>> >> working >>> >> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to >>> >> improve >>> >> >> the >>> >> >> >>> >> >>>>>>>>> wording so that readers who have not >>> participated in >>> >> >>the >>> >> >> WG >>> >> >> >>> >> >>>>>>>>> discussion will understnd it the way the >>> >> >> >>> >> >>>>> working >>> >> >> >>> >> >>>>>>>>> group intends. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain my >>> >> >>personal >>> >> >> >>> >> >>>>>>>>> view, and see if that helps. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> In this regard, it is important to keep in mind >>> that >>> >> >>what >>> >> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. >>> We >>> >>are >>> >> >> not >>> >> >> >>> >> >>>>>>>>> attempting to define the architecture for the >>> entire >>> >> >> >>> >> >>>>>>>>> solution for service chaining. That would >>> encompass >>> >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy functions, >>> >>virtual >>> >> >> >>> >> >>>>>>>>> machine and image management, and many other >>> >> >> aspects. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> As a result there are many things which clearly >>> need >>> >> to >>> >> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt >>> with >>> >> >>above >>> >> >> >>> >> >>>>>>>>> where we are >>> >> >> >>> >> >>>>> functioning, >>> >> >> >>> >> >>>>>>>>> and are not directly required by the work we are >>> >> doing. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> In order to get to service chain vs service >>> path, >>> >>as I >>> >> >> >>> >> >>>>>>>>> understand >>> >> >> >>> >> >>>>> them, >>> >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. There >>> are at >>> >> >>least >>> >> >> >>> >> >>>>>>>>> three different ways that load balancing can and >>> >>will >>> >> >> >>> >> >>>>>>>>> interact with service chaining. There probably >>> are >>> >> >>more. >>> >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all >>> of >>> >> >>these, >>> >> >> >>> >> >>>>>>>>> but not to mandate that any particular kind >>> >> >> >>> >> >>>>> be used >>> >> >> >>> >> >>>>>>>>> in any solution. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to the >>> end >>> >> >>user. >>> >> >> >>> >> >>>>>>>>> This is a service function. It receives user >>> >>packets, >>> >> >>and >>> >> >> >>> >> >>>>>>>>> modifies them (or >>> >> >> >>> >> >>>>> marks >>> >> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user >>> service >>> >> >>instance >>> >> >> >>> >> >>>>>>>>> to receive the users packet. This is an >>> important >>> >> >>service >>> >> >> >>> >> >>>>>>>>> function to be able to include in service >>> chaining. >>> >> >>It's >>> >> >> >>> >> >>>>>>>>> behavior may affect requirements on how service >>> >> >> chaining is >>> >> >> >>> >> >>>>>>>>> done. But it has very little impact on the >>> >> >>archtiecture. >>> >> >> >>> >> >>>>>>>>> From an architectural pe3rspective it is simply >>> a >>> >> >> >>> >> >>>>> service >>> >> >> >>> >> >>>>>>>>> function which may modify the underlying packet. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, >>> one >>> >>can >>> >> >>have >>> >> >> >>> >> >>>>>>>>> what >>> >> >> >>> >> >>>>> appears >>> >> >> >>> >> >>>>>>>>> to the service chaining architecture as a single >>> >>point >>> >> >>of >>> >> >> >>> >> >>>>>>>>> contact >>> >> >> >>> >> >>>>> for a >>> >> >> >>> >> >>>>>>>>> specific service function, but is actually >>> delivered >>> >> >>by a >>> >> >> >>> >> >>>>> collection of >>> >> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including >>> >>one or >>> >> >> >>> >> >>>>>>>>> several load balancers (for example using >>> VRRP-like >>> >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, >>> this is >>> >> >> >>> >> >>>>>>>>> invisible to the service chaining data plane >>> >> >>mechanisms. >>> >> >> It >>> >> >> >>> >> >>>>>>>>> is likely that it is visible to various control >>> >> >>mechanisms, >>> >> >> >>> >> >>>>>>>>> such as those responsible for scale-in, >>> scale-out, >>> >>and >>> >> >>vm >>> >> >> >>> >> >>>>>>>>> instantiation. The architectural impact of >>> >>permitting >>> >> >>this >>> >> >> >>> >> >>>>>>>>> is largely that we need to be careful that our >>> >> >>terminology >>> >> >> >>> >> >>>>>>>>> does not lead >>> >> >> >>> >> >>>>> readers to >>> >> >> >>> >> >>>>>>>>> think we are prohibiting it. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by >>> >>selecting >>> >> >> >>> >> >>>>>>>>> packet paths for the service chaining that >>> direct >>> >> >>traffic >>> >> >> >>> >> >>>>>>>>> to different places. We would not want to >>> require >>> >> that >>> >> >>a >>> >> >> >>> >> >>>>>>>>> given service function appear at only one place >>> in >>> >>the >>> >> >> >>> >> >>>>>>>>> network. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> It is of course the case that these may be >>> >>combined. I >>> >> >> tend >>> >> >> >>> >> >>>>>>>>> to >>> >> >> >>> >> >>>>> refer to >>> >> >> >>> >> >>>>>>>>> the collection of entities that appear to >>> service >>> >> >>chaining >>> >> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because >>> cluster >>> >>is >>> >> >>a >>> >> >> >>> >> >>>>>>>>> good term. But because I do not have another >>> one. >>> >> Thus, >>> >> >> the >>> >> >> >>> >> >>>>>>>>> point of type 3 load balancing >>> >> >> >>> >> >>>>> is to >>> >> >> >>> >> >>>>>>>>> direct different subsets of traffic to different >>> >> >>singular >>> >> >> >>> >> >>>>>>>>> or clustered service functions in different >>> places >>> >>in >>> >> >>the >>> >> >> >>> >> >>>>>>>>> network. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I talk >>> about >>> >> >> >>> >> >>>>>>>>> service chain and service path/ Service chain >>> is a >>> >> >> sequence >>> >> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset >>> of >>> >> >>packets. >>> >> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of >>> >>traffic >>> >> >>is >>> >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, and >>> >>firewall >>> >> >> >>> >> >>>>>>>>> while a different subset is to go directly to >>> the >>> >>cache >>> >> >> >>> >> >>>>> without >>> >> >> >>> >> >>>>>>>>> visiting any other service functions. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> That is not enough information to direct the >>> >>packets. >>> >> A >>> >> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence of >>> >> >>locations >>> >> >> >>> >> >>>>>>>>> in the network. Those locations will be >>> singular or >>> >> >> >>> >> >>>>>>>>> clustered service function delivery locations. >>> They >>> >> >>may be >>> >> >> >>> >> >>>>>>>>> addressed by IP address. They may be addressed >>> as >>> >> ports >>> >> >> on >>> >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that the >>> >> >>locations >>> >> >> >>> >> >>>>>>>>> may be known to the service chaining >>> infrastructure >>> >> and >>> >> >> the >>> >> >> >>> >> >>>>>>>>> transport. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>>> From the point of view of the work of the SFC >>> >>group, >>> >> >> we >>> >> >> >>> >> >>>>>>>>>> need to be >>> >> >> >>> >> >>>>>>>>> able to talk about the high level abstraction, >>> the >>> >> >>service >>> >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need >>> to >>> >> talk >>> >> >> >>> >> >>>>>>>>> about the actual data path packets will take in >>> the >>> >> >> >>> >> >>>>>>>>> network. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Several of the comments have said "but the whole >>> >> path >>> >> >> may >>> >> >> >>> >> >>>>>>>>> not be known at the front." This architecture >>> deals >>> >> >>with >>> >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item >>> (2) >>> >>on >>> >> >>load >>> >> >> >>> >> >>>>>>>>> balancers above, there can be decisions and >>> >>behaviors >>> >> >> which >>> >> >> >>> >> >>>>>>>>> are invisible to the service chaining >>> mechanisms (in >>> >> >>much >>> >> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is >>> largely >>> >> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The other >>> >> provision >>> >> >> we >>> >> >> >>> >> >>>>>>>>> make is >>> >> >> >>> >> >>>>> that >>> >> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain when >>> >> >> necessary. >>> >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. Based >>> on >>> >> >> >>> >> >>>>>>>>> information available at the re-classification >>> >>point. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> I hope that this helps explain what we are >>> after. >>> >>If it >>> >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the >>> working >>> >> >> group, >>> >> >> >>> >> >>>>>>>>> we can figure out what additional words are >>> needed >>> >> to >>> >> >> >>> >> >>>>>>>>> convey this. If the working group disagree with >>> the >>> >> >> intent, >>> >> >> >>> >> >>>>>>>>> then we will of course adjust to match the >>> working >>> >> >>group >>> >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not >>> sure >>> >> >>what to >>> >> >> >>> >> >>>>>>>>> try next. >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> Yours, Joel >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> >>> >> _______________________________________________ >>> >> >> sfc >>> >> >> >>> >> mailing >>> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >>> <mailto:sfc@ietf.org> >>> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>>> >>> >> _______________________________________________ >>> >> >> sfc >>> >> >> >>> >> mailing >>> >> >> >>> >> >>>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >>> <mailto:sfc@ietf.org> >>> >> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>>>>>>> >>> >> >> >>> >> >>>>>>>> >>> >> >> >>> >> >>>>>>>> >>> >> _______________________________________________ >>> >> >> sfc >>> >> >> >>> >> mailing >>> >> >> >>> >> >>>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>>>>>> >>> >> >> >>> >> >>>>>>> >>> >> >> >>> >> >>>>>>> _______________________________________________ >>> >> sfc >>> >> >> >>> >> mailing >>> >> >> >>> >> >>>>>>> list sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >>https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>>>>> >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>>> _______________________________________________ >>> >> sfc >>> >> >> >>> mailing >>> >> >> >>> >> list >>> >> >> >>> >> >>>>>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>>>> >>> >> >> >>> >> >>>>> >>> >> >> >>> >> >>>>> _______________________________________________ sfc >>> >> >> >>> mailing >>> >> >> >>> >> list >>> >> >> >>> >> >>>>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> _______________________________________________ sfc >>> >> >> mailing >>> >> >> >>> >> list >>> >> >> >>> >> >>>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> _______________________________________________ sfc >>> >> >> mailing >>> >> >> >>> >> list >>> >> >> >>> >> >>>> sfc@ietf.org <mailto:sfc@ietf.org> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>> >>> >> >> >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> >>> >> >> sfc mailing list >>> >> >> >>> >> >> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> >> >> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >> >>> >> >> >>> >> > >>> >> >> >>> >> >_______________________________________________ >>> >> >> >>> >> >sfc mailing list >>> >> >> >>> >> >sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> >> >https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >> >>> >> >> >>> >> _______________________________________________ >>> >> >> >>> >> sfc mailing list >>> >> >> >>> >> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> >> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> >>> >>> >> >> >>> _______________________________________________ >>> >> >> >>> sfc mailing list >>> >> >> >>> sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> > >>> >> >> >_______________________________________________ >>> >> >> >sfc mailing list >>> >> >> >sfc@ietf.org <mailto:sfc@ietf.org> >>> >> >> >https://www.ietf.org/mailman/listinfo/sfc >>> > >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org <mailto: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 Jul 14 08:35:03 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F71A0A91 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5udnPoUekrd for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:34:53 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A49B1A0A86 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:34:52 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id c98f3c35.2b990763e940.5802339.00-2449.16071859.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 15:34:52 +0000 (UTC) X-MXL-Hash: 53c3f89c28653d85-d92c0f1b3b021edd77a5999db0ba80044720abb3 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e58f3c35.0.5801513.00-2344.16069446.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 15:33:51 +0000 (UTC) X-MXL-Hash: 53c3f85f3bae6939-36c203447022543ada6c190d1cc8b786d3721ee4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EFXmgJ005906; Mon, 14 Jul 2014 11:33:49 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EFXa1J005703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 11:33:41 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 15:33:18 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 11:33:18 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2ffqZsyr0yw6EKJZWVG2s4yKJuf5vKAgAAF3oCAAANrgP//wMlg Date: Mon, 14 Jul 2014 15:33:18 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4B806@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> In-Reply-To: <CFE96A4C.2E4AC%jguichar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=y-ZxpICqmSAA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=AUd_NHdVAAAA:8 a=3oc9M9_CAAAA:8 a=z9tbli-vAAAA:8 ] X-AnalysisOut: [a=ABeY7kuGAAAA:8 a=48vgC7mUAAAA:8 a=qN95wPeSAAAA:8 a=bx5Yd] X-AnalysisOut: [VXAAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH86SAAAA:8 a=HYpruEjXlc1h] X-AnalysisOut: [sZxRd4kA:9 a=QEXdDO2ut3YA:10 a=eRsKL0hzPpUA:10 a=W_a9NTmGv] X-AnalysisOut: [3gA:10 a=JfD0Fch1gWkA:10 a=U8Ie8EnqySEA:10 a=oAXR_kdF8uMA:] X-AnalysisOut: [10 a=chC_agHSu74A:10 a=lZB815dzVvQA:10 a=paC5pjApGzsA:10 a] X-AnalysisOut: [=Hz7IrDYlS0cA:10 a=22WdJzMbkz4_OLOQ:21 a=MSBJNCn3fk-H9Q1F:] X-AnalysisOut: [21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fCpSlIaVeA4h4myDBZl0cQVwdHE Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:35:01 -0000 SSB3b3VsZCByZXdvcmQgdGhpcyBzZW50ZW5jZSBhcyBmb2xsb3dzOg0KDQoiV2hlbiBhbiBTRkMg aXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgdGhpcyByZXN1bHRzIGluIHNwZWNpZmlj IGluc3RhbmNlcyBvZiBTRnMgYmVpbmcgc2VsZWN0ZWQgdG8gY3JlYXRlIHRoZSBzZXJ2aWNlIHRv cG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRuKAmXMgbmV0d29yayBsb2NhdG9yc+KAnQ0KDQpN YXJpYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPiBTZW50OiBNb25kYXks IEp1bHkgMTQsIDIwMTQgMTE6MTIgQU0NCj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBE aXJlY3Q7IEx1Y3kgeW9uZzsgTkFQSUVSQUxBLCBNQVJJQSBIOw0KPiBYdXhpYW9odTsgbWlrZWJp YW5jQGFvbC5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+IGptaEBqb2VsaGFs cGVybi5jb207IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gUmVkZWZpbmUgdGhl IFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gQmFsYW5jZXJzDQo+ IA0KPiBRdWVzdGlvbjogd2hlcmUgZXhhY3RseSBkb2VzIGl0IHNwZWNpZnkgdGhhdCB0aGUgU0ZQ ICptdXN0KiBiZQ0KPiBwcmUtaW5zdGFudGlhdGVkPyBXaGF0IGV4YWN0bHkgaXMgd3Jvbmcgd2l0 aCB0aGUgd29yZGluZyDigJxXaGVuIGFuIFNGQyBpcw0KPiBpbnN0YW50aWF0ZWQgaW50byB0aGUg bmV0d29yayBpdCBpcyBuZWNlc3NhcnkgdG8gc2VsZWN0IHRoZSBzcGVjaWZpYw0KPiBpbnN0YW5j ZXMgb2YgU0ZzIHRoYXQgd2lsbCBiZSB1c2VkLCBhbmQgdG8gY3JlYXRlIHRoZSBzZXJ2aWNlIHRv cG9sb2d5IGZvcg0KPiB0aGF0IFNGQyB1c2luZyBTRuKAmXMgbmV0d29yayBsb2NhdG9yc+KAnT8g TGV04oCZcyB0cnkgdG8gYmUgc3BlY2lmaWMgcmF0aGVyDQo+IHRoYW4gZGFuY2luZyBhcm91bmQg dGhlIHdvcmRpbmcuDQo+IA0KPiBPbiA3LzE0LzE0LCAxMTowMCBBTSwgIlJvbiBQYXJrZXIiIDxS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPg0KPiB3cm90ZToNCj4gDQo+ID5IaSwgSm9l bCwNCj4gPg0KPiA+SSBxdW90ZSBmcm9tIHRoZSB0aGUgbWVyZ2VkIGFyY2hpdGVjdHVyZSBkcmFm dDoNCj4gPg0KPiA+PGJlZ2luIHF1b3RhdGlvbj4NCj4gPlNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4g KFNGQyk6ICBBIHNlcnZpY2UgRnVuY3Rpb24gY2hhaW4gZGVmaW5lcyBhbg0KPiA+ICAgICAgICBv cmRlcmVkIHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IG11c3QgYmUgYXBwbGllZCB0byBw YWNrZXRzDQo+ID4gICAgICAgIGFuZC9vciBmcmFtZXMgc2VsZWN0ZWQgYXMgYSByZXN1bHQgb2Yg Y2xhc3NpZmljYXRpb24uICBUaGUNCj4gPiAgICAgICAgaW1wbGllZCBvcmRlciBtYXkgbm90IGJl IGEgbGluZWFyIHByb2dyZXNzaW9uIGFzIHRoZQ0KPiA+ICAgICAgICBhcmNoaXRlY3R1cmUgYWxs b3dzIGZvciBub2RlcyB0aGF0IGNvcHkgdG8gbW9yZSB0aGFuIG9uZSBicmFuY2guDQo+ID4gICAg ICAgIFRoZSB0ZXJtIHNlcnZpY2UgY2hhaW4gaXMgb2Z0ZW4gdXNlZCBhcyBzaG9ydGhhbmQgZm9y IHNlcnZpY2UNCj4gPiAgICAgICAgZnVuY3Rpb24gY2hhaW4uDQo+ID4NCj4gPiAgIFNlcnZpY2Ug RnVuY3Rpb24gUGF0aCAoU0ZQKTogIFRoZSBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUN Cj4gPiAgICAgICAgbmV0d29yay4gIFBhY2tldHMgZm9sbG93IGEgc2VydmljZSBmdW5jdGlvbiBw YXRoIGZyb20gYQ0KPiA+ICAgICAgICBjbGFzc2lmaWVyIHRocm91Z2ggdGhlIHJlcXVpc2l0ZSBz ZXJ2aWNlIGZ1bmN0aW9ucw0KPiA+DQo+ID5XaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50 byB0aGUgbmV0d29yayBpdCBpcyBuZWNlc3NhcnkgdG8NCj4gPiAgIHNlbGVjdCB0aGUgc3BlY2lm aWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZQ0KPiA+ ICAgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MgbmV0d29yayBs b2NhdG9yLiAgVGh1cywNCj4gPiAgIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGlu IHRoZSBjcmVhdGlvbiBvZiBhIFNlcnZpY2UNCj4gPiAgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQg aXMgdXNlZCBmb3IgZm9yd2FyZGluZyBwYWNrZXRzIHRocm91Z2ggdGhlDQo+ID4gICBTRkMuICBJ biBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZSBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVk IFNGQy4NCj4gPg0KPiA+KFNlY3Rpb24gNC4zIFNGRikNCj4gPlNGUCBmb3J3YXJkaW5nIGluZm9y bWF0aW9uIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyDQo+ID4g ICB0aGF0IGlzIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYW4gU0ZQLg0KPiA+PGVuZCBxdW90 YXRpb24+DQo+ID4NCj4gPg0KPiA+TXkgcmVhZGluZyBvZiB0aGUgU2VjdGlvbiA0LjMsIGdpdmVu IHRoZSBkZWZpbml0aW9ucyBwcmVzZW50ZWQgYmVmb3JlIGl0LA0KPiA+aXMgdGhhdCBhbiBlbmQt dG8tZW5kIGZ1bGx5IGluc3RhbnRpYXRlZCBwYXRoIGlzIHNlbGVjdGVkIGFuZCB0aGVuIHVzZWQN Cj4gPnRvIHN0ZWVyIHRyYWZmaWMgdG8gdGhlIHJlcXVpc2l0ZSBTRkYncyBhbmQgU0Yncy4gICBX aGlsZSB0aG9zZQ0KPiA+ZGVmaW5pdGlvbnMgY291bGQgc3RpbGwgYXBwbHksIGV2ZW4gaW4gYSBk aXN0cmlidXRlZCBpbnN0YW5jZSBhc3NpZ25tZW50DQo+ID5hcHByb2FjaCwgdGhlIGNvbnRleHQg YXJvdW5kIHRob3NlIGRlZmluaXRpb25zIGNoYW5nZS4gICBBIHBhcnRpY3VsYXINCj4gPmZsb3cg d291bGQsIGluZGVlZCBzdGlsbCBmb2xsb3cgc29tZSBwYXJ0aWN1bGFyIHBhdGgsIGJ1dCB0aGVy ZSB3b3VsZCBiZQ0KPiA+bm8gbmVlZCB0byBhc3NvY2lhdGUgYSBwYXRoIElEIHRvIGl0IGFuZCB0 aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvDQo+ID4obGF0ZXIpIGJ1aWxkIGEgY29udHJvbCBwbGFu ZSBhcm91bmQgZGlzdHJpYnV0aW9uIG9mIHRoaXMgcGF0aCBJRCBhbmQNCj4gPm1haW50ZW5hbmNl IG9mIHRob3NlIHBhdGggSURzIGluIHRoZSBmYWNlIG9mIGluZXZpdGFibGUgZmFpbHVyZXMuDQo+ ID4NCj4gPkkgYW0gZXhwbG9yaW5nIHRoZSBhbHRlcm5hdGl2ZSB3aGVyZSBmb3J3YXJkaW5nIGlz IHBlcmZvcm1lZCBiYXNlZCBvbg0KPiB0aGUNCj4gPmFic3RyYWN0IFNGQyBJRCB3aXRob3V0IHJl cXVpcmluZyB0aGUgY29uY2VwdCBvZiBhIGNlbnRyYWxseSBrbm93biBTRlAgdG8NCj4gPmV4aXN0 IGF0IGFsbC4gICBJbiB0aGlzIGFsdGVybmF0aXZlIGFwcHJvYWNoLCB0aGUgaW5zdGFuY2Ugc2Vs ZWN0aW9uIGlzDQo+ID5kaXN0cmlidXRlZCB0byB0aGUgY2xhc3NpZmllciBhbmQgdGhlIFNGRidz LiAgIEFueSBkZXNpcmVkIHBvbGljeSB1c2VkIHRvDQo+ID5mbGF2b3IgaW5zdGFuY2Ugc2VsZWN0 aW9uIGlzIHN0aWxsIHN1cHBvcnRlZCwgYnV0IHN1Y2ggcG9saWN5IHdvdWxkLA0KPiA+aW5kZWVk LCBuZWVkIHRvIGJlIGF2YWlsYWJsZSB0byB0aGUgaW52b2x2ZWQgZW50aXRpZXMuICAgVGhpcyB3 b3VsZCBhbHNvDQo+ID5iZSBhbiBleGNlbGxlbnQgdXNlIG9mIG1ldGFkYXRhIHdoZXJlIHRoZSBp bml0aWFsIGluZ3Jlc3Mgbm9kZSBjb3VsZCBhZGQNCj4gPm9uZSBvciBtb3JlIHBpZWNlcyBvZiBt ZXRhZGF0YSB0aGF0IGRvd25zdHJlYW0gbm9kZXMgY291bGQgbWFrZSB1c2UNCj4gb2YgaW4NCj4g PnRoZWlyIHBvbGljeSBkZWNpc2lvbnMuDQo+ID4NCj4gPiAgICBSb24NCj4gPg0KPiA+DQo+ID4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+RnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBb bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KPiA+U2VudDogTW9uZGF5LCBKdWx5 IDE0LCAyMDE0IDEwOjM5IEFNDQo+ID5UbzogTHVjeSB5b25nOyBOQVBJRVJBTEEsIE1BUklBIEg7 IFJvbiBQYXJrZXI7IFh1eGlhb2h1Ow0KPiA+bWlrZWJpYW5jQGFvbC5jb207IGpndWljaGFyQGNp c2NvLmNvbTsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsNCj4gPmptaEBqb2VsaGFs cGVybi5jb207IHNmY0BpZXRmLm9yZw0KPiA+U3ViamVjdDogUmU6IFtzZmNdIFJlZGVmaW5lIHRo ZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+ID5CYWxhbmNlcnMN Cj4gPg0KPiA+Q2FuIHdlIGZpcnN0IGZpZ3VyZSBvdXQgd2hhdCB3ZSBtZWFuIGJ5IGEgc2Vydmlj ZSBwYXRoPw0KPiA+T25jZSB3ZSBoYXZlIHRoYXQsIEkgYmVsaWV2ZSB3ZSBjYW4gd29yayBvdXQg d2hhdCB3ZSB3YW50IHRoZQ0KPiA+YXJjaGl0ZWN0dXJlIHRvIHJlcXVpcmUgb2Ygc29sdXRpb25z IGluIHRlcm1zIG9mIGNhcnJ5aW5nIGluZm9ybWF0aW9uIGluDQo+ID50aGUgcGFja2V0LiAgQnV0 IHNpbmNlIGZvbGtzIGhhdmUgYmVlbiByZWFkaW5nIHRoZSBleGlzdGluZyBkZWZpbml0aW9ucw0K PiA+YW5kIGNvbWluZyB0byBkaWZmZXJlbnQgbWVhbmluZ3MsIGFuZCBoYXZlIGJlZW4gbm90aW5n IGNvcnJlY3RseQ0KPiA+Y29udHJhZGljdGlvbnMgaW4gdGhlIHdvcmRzIHdlIGNob3NlIGZvciB0 aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiwgSQ0KPiA+d291bGQgcmVhbGx5IGFwcHJlY2lhdGVkIGl0 IGlmIGZvbGtzIHdvdWxkIGNvbW1lbnQgb24gdGhlIGRlZmluaXRpb24gb2YNCj4gPnNlcnZpY2Ug ZnVuY3Rpb24gcGF0aCB0aGF0IEkgc2VudCB0byB0aGUgbGlzdC4NCj4gPg0KPiA+WW91cnMsDQo+ ID5Kb2VsDQo+ID4NCj4gPk9uIDcvMTQvMTQsIDk6MzAgQU0sIEx1Y3kgeW9uZyB3cm90ZToNCj4g Pj4gQ29ucXVlciB3aGF0IE1hcmlhIHNheXMuDQo+ID4+DQo+ID4+IEx1Y3kNCj4gPj4NCj4gPj4g KkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpO QVBJRVJBTEEsDQo+ID4+TUFSSUEgSA0KPiA+PiAqU2VudDoqIE1vbmRheSwgSnVseSAxNCwgMjAx NCA4OjIxIEFNDQo+ID4+ICpUbzoqIFJvbiBQYXJrZXI7IFh1eGlhb2h1OyBtaWtlYmlhbmNAYW9s LmNvbTsgamd1aWNoYXJAY2lzY28uY29tOw0KPiA+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmcNCj4gPj4gKlN1YmplY3Q6KiBS ZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k DQo+ID4+IExvYWQgQmFsYW5jZXJzDQo+ID4+DQo+ID4+IFRoZSBtZWFuaW5nIG9mIHRoZSBTRlAg SUQgaXMgcHJldHR5IGNsZWFyLCBhdCBsZWFzdCB0byBtZSDigJMgYW4gYWJzdHJhY3QNCj4gPj4g aWRlbnRpdHkgZm9yIHRoZSBleGFjdCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMg KGkuZS4sIFNGUCBJRCAxDQo+ID4+ID0ge1NGLUEtMSwgU0YtQi0zLCBTRi1DLTJ9KS4gICAgSW4g c29tZSB3YXlzLCBpdCBpcyBhIGNvbGxhcHNlZCDigJxsYWJlbA0KPiA+PiBzdGFja+KAnSDigJMg dGhlcmUgaXMgYSBzaW5nbGUgdGFnIGltcGx5aW5nIHNvbWUgc2VxdWVuY2Ugb2YgbmV0d29yaw0K PiA+PiBsb2NhdGlvbnMuICAgQnV0LCB0aGlzIGFsc28gaW1wbGllcywgYXQgbGVhc3QgdG8gbWUs IHRoYXQgdGhlcmUgaXMgYQ0KPiA+PiBjZW50cmFsIHBvaW50IG9mIHNlbGVjdGlvbiBmb3IgdGhp cyBlbmQgdG8gZW5kIHNlcXVlbmNlIChiYXJyaW5nDQo+ID4+IHJlY2xhc3NpZmljYXRpb24sIG9m IGNvdXJzZSkuICAgSSwgZm9yIG9uZSwgYW0gcXVlc3Rpb25pbmcgdGhhdA0KPiA+PiBpbXBsaWNh dGlvbi4gICAgSSBoYXZlIGJlZW4gdW5jb21mb3J0YWJsZSB3aXRoIHRoYXQgY2VudHJhbCBwb2lu dA0KPiA+PiBtZXRob2RvbG9neSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2YgZHlu YW1pYyBzY2FsZSBhbmQNCj4gPj4gdGltZWxpbmVzcyBvZiByZWFjdGlvbiB0byBmYWlsdXJlcy4N Cj4gPj4NCj4gPj4gPE1hcmlhPiBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5 IHRoZSBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQNCj4gPj4gc29tZXRoaW5nIGNhbGxlZCDigJxzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGggSUTigJ0gaXMgY2FycmllZCBpbiB0aGUgcGFja2V0LA0KPiA+PiBi ZWNhdXNlIGl0IGlzIG5vdCBuZWNlc3Nhcnkgb3IgdGhlIG9ubHkgd2F5IHRvIGltcGxlbWVudCBz ZXJ2aWNlDQo+ID4+IGNoYWluaW5nLiBUaGVyZSBtaWdodCBzb2x1dGlvbnMgdGhhdCB3b3VsZCBk byB0aGF0IGJ1dCBpdCBjYW5ub3QgYW5kDQo+ID4+IGRvZXNu4oCZdCBuZWVkIHRvIGJlIG1hbmRh dGVkLg0KPiA+Pg0KPiA+PiBNYXJpYQ0KPiA+Pg0KPiA+PiBBbiBhbHRlcm5hdGl2ZSBhcHByb2Fj aCBpcyB0byBzdGlsbCB1c2UgY2VudHJhbCBzZWxlY3Rpb24gdG8gc2VsZWN0IHRoZQ0KPiA+PiBj aGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNlIGZ1bmN0aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0Yt QSwgU0YtQiwNCj4gPj4gU0YtQ30pLCBidXQgYWxsb3cgdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxl Y3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQsDQo+ID4+IHJlYWxpemVkIGJ5IHRoZSBjbGFzc2lmaWVy IGFuZCB0aGUgU0ZGcy4NCj4gPj4NCj4gPj4gR2l2ZW4gYSB0b3BvbG9neSBsaWtlOg0KPiA+Pg0K PiA+PiBDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0y DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0zLS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00 DQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwN Cj4gPj4gICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KPiA+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4NCj4g Pj4gICAgICAgICAgICAgICAgICAgICAgU0ZGLUEtMSAgICAgICBTRkYtQS0yICAgICAgIFNTRi1C LTENCj4gPj4gU0ZGLUItMiAgICAgICAgIFNGRi1DLTEgICAgICAgU0ZGLUMtMiAgICAgICAgICAg ICAgICAgICBTRkYtQS0zDQo+ID4+DQo+ID4+IEFuZCBhc3N1bWluZyBhIG5ld2x5IHJlY29nbml6 ZWQgZmxvdywgdGhlIHNlcXVlbmNlIGNvdWxkIGdvDQo+IHNvbWV0aGluZw0KPiA+PiBsaWtlIHRo aXM6DQo+ID4+DQo+ID4+IDEgQ2xhc3NpZmllciBzZWxlY3RzIGNoYWluIFNGQyBJRCAxIHtTRi1B LCBTRi1CLCBTRi1DfQ0KPiA+Pg0KPiA+PiAyIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBhcyBo b3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1BDQo+ID4+DQo+ID4+IDMgQ2xhc3Np ZmllciBlbmNhcHN1bGF0ZXMgcGFja2V0IGluZGljYXRpbmcgY2hhaW4gSUQgPSAxLCBzZXJ2aWNl IGluZGV4DQo+ID4+PSAxDQo+ID4+DQo+ID4+IDQgQ2xhc3NpZmllciBwcm9ncmVzc2VzIHBhY2tl dCB0byBTRkYtMQ0KPiA+Pg0KPiA+PiA1IFNGRi0xLCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2Vydmlj ZSBpbmRleD0xLCBjaG9vc2VzIFNGRi1BLTIgYW1vbmdzdCBpdHMNCj4gPj4gYXZhaWxhYmxlIGlu c3RhbmNlcyBvZiBTRi1BDQo+ID4+DQo+ID4+IDYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1B LTENCj4gPj4NCj4gPj4gNyBTRkYtQS0xIHNlbmRzIHBhY2tldCBiYWNrIHRvIFNGRi0xDQo+ID4+ DQo+ID4+IDggU0ZGLTEgaW5jcmVtZW50cyBzZXJ2aWNlIGluZGV4IHRvIDINCj4gPj4NCj4gPj4g OCBTRkYtMSBzZWxlY3RzIFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9m IFNGLUINCj4gPj4NCj4gPj4gOSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMg0KPiA+ Pg0KPiA+PiAxMCBwcm9jZXNzIHJlcGVhdHMgcGVyIGFib3ZlIHVudGlsIFNGRi0zLCBhcyB0aGUg ZWdyZXNzIGJvcmRlciwNCj4gPj4gcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciByb3V0aW5nIHRh YmxlDQo+ID4+DQo+ID4+IFRoYW5rcy4NCj4gPj4NCj4gPj4gICAgIFJvbg0KPiA+Pg0KPiA+PiAq RnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKlh1 eGlhb2h1DQo+ID4+ICpTZW50OiogU3VuZGF5LCBKdWx5IDEzLCAyMDE0IDExOjMwIFBNDQo+ID4+ ICpUbzoqIG1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPiBq Z3VpY2hhckBjaXNjby5jb20NCj4gPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5 MjFAYXR0LmNvbQ0KPiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsNCj4gPj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbQ0KPiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ Ow0KPiA+PiBqbWhAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47 IFJvbiBQYXJrZXI7DQo+ID4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g Pj4gKlN1YmplY3Q6KiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZA0KPiA+PiBCYWxhbmNlcnMNCj4gPj4NCj4gPj4gQWdyZWUgdGhhdCB0 aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAgaW4gdGhlIGFyY2ggZHJhZnQgaXMgYSBi aXQNCj4gPj5jb25mdXNpbmcsIGp1c3QgYXMgd2hhdCB5b3UgaGFkIHBvaW50ZWQgb3V0Lg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGlu c3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZQ0KPiA+Pm5ldHdvcmsgc2hvdWxkIGJlIOKAnGFu IG9yZGVyZWQgbGlzdCBvZiBzZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0oc2VlDQo+ID4+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJj aC0wMSkuIE9mDQo+ID4+Y291cnNlLCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4gdGhlIGRh dGEgcGFja2V0IGlzIGFub3RoZXIgdGhpbmcNCj4gPj4oZS5nLiwgZWl0aGVyIHRocm91Z2ggYSBw YXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBsYWJlbCBzdGFjaykuIEhlcmUNCj4gPj50aGUgc2Vy dmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNGRiBhbmQgdGhl IE5GDQo+ID4+Y29tcG9uZW50cyBtYW5kYXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBh bmQgU0YgcHJveHkNCj4gY29tcG9uZW50cw0KPiA+Pm9wdGlvbmFsbHkuIFRoZSBzZXJ2aWNlIG5v ZGUgY291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aA0KPiBtdWx0aXBsZQ0KPiA+PlNG IGluc3RhbmNlcyBhbmQgdGhvc2UgU0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNG IHR5cGUgb3Igbm90Lg0KPiA+PiBJbiB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUg U0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUNCj4gPj4oZS5nLiwgU0YgWCkgYXJlIGF0 dGFjaGVkIHRvIGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlDQo+ID4+Y291 bGQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB3aGljaCBuZWVkcyBTRiBYIGFtb25nIHRob3NlIFNG IGluc3RhbmNlcw0KPiA+Pm9mIFNGIFggdHlwZSBsb2NhbGx5LiBNZWFud2hpbGUsIHRoZXJlIG1h eSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzDQo+ID4+d2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJs ZWQgZG9tYWluIHdoaWNoIGFyZSBlbWJlZGRlZCBvciBhdHRhY2hlZA0KPiB3aXRoDQo+ID4+dGhl IFNGDQo+ID4gIGluc3RhbmNlDQo+ID5zIG9mIHRoZSBzYW1lIFNGIHR5cGUuIEluIHRoaXMgd2F5 LCB0aGUgU0YgbG9hZC1iYWxhbmNpbmcgd291bGQgYmUgbWFkZQ0KPiA+dmVyeSBmbGV4aWJsZS4N Cj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+Pg0KPiA+PiBYaWFvaHUNCj4gPj4NCj4gPj4g KkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mDQo+ ID4+ICptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KPiA+PiAq U2VudDoqIFNhdHVyZGF5LCBKdWx5IDEyLCAyMDE0IDI6NDYgQU0NCj4gPj4gKlRvOiogamd1aWNo YXJAY2lzY28uY29tIDxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsNCj4gbW4xOTIxQGF0dC5j b20NCj4gPj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgam1oQGpv ZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tDQo+ID4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbT47IHNmY0BpZXRmLm9yZw0KPiA+PjxtYWlsdG86c2ZjQGlldGYub3JnPg0K PiA+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPiA+Pg0KPiA+PiBXb3VsZG4ndCB0aGF0IGJlIGNhbGxlZCB0aGUgInNlcnZp Y2UgY2hhaW4gaWRlbnRpZmllciIgdGhlbj8gIElmIHRoZQ0KPiA+PiBzZXJ2aWNlIGNoYWluIGlz IHRoZSBvcmRlcmVkIGxpc3Qgb2YgU0ZzIGFuZCB0aGUgc2VydmljZSBwYXRoIGlzIHRoZQ0KPiA+ PiBvcmRlcmVkIGxpc3Qgb2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBh ICJzZXJ2aWNlIHBhdGgNCj4gPj4gaWRlbnRpZmllciIgd291bGQgYmUgYW4gaWRlbnRpZmllciBm b3IgYSBzZXJ2aWNlICpwYXRoKiwgbm90IGEgc2VydmljZQ0KPiA+PiAqY2hhaW4qLg0KPiA+Pg0K PiA+Pg0KPiA+PiBBZ2FpbiwgSSB0aGluayB0aGlzIGlzIHdoZXJlIHRoZSBjb25mdXNpb24ga2Vl cHMgY3JlZXBpbmcgaW4uICBUaGUgdGVybXMNCj4gPj4gImNoYWluIiBhbmQgInBhdGgiIHNlZW0g aW5jb25zaXN0ZW50Lg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gKkZy b206ICpqZ3VpY2hhckBjaXNjby5jb208amd1aWNoYXJAY2lzY28uY29tDQo+ID4+IDxtYWlsdG86 amd1aWNoYXJAY2lzY28uY29tJTNjamd1aWNoYXJAY2lzY28uY29tPj4NCj4gPj4gKlRvOg0KPiA+ Pg0KPiA+PiptaWtlYmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9sLmNvbT4sbW4xOTIxQGF0dC5j b208bW4xOTIxQA0KPiBhdHQuY29tPixtb2hhDQo+ID4+bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqDQo+IG9lbGhhbHBlcm4uY28NCj4g Pj5tPGptaEBqb2VsaGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208 Um9uX1Bhcg0KPiBrZXJAYWZmaXJtZQ0KPiA+PmRuZXR3b3Jrcy5jb20+LHNmY0BpZXRmLm9yZzxz ZmNAaWV0Zi5vcmcNCj4gPj4NCj4gPj48bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNjbWlrZWJp YW5jQGFvbC5jb20lM2UsbW4xOTIxQGF0dC5jbw0KPiBtJTNjbW4xOTIxQA0KPiA+PmF0dC5jb20l M2UsbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQA0KPiBv cmFuZ2UuY29tJTNlDQo+ID4+LGptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4u Y29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtDQo+IGVkbmV0d29ya3MNCj4gPj4uY29tJTNjUm9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzZSxzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zg0KPiAu b3JnPj4NCj4gPj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkgMTEsIDIwMTQNCj4gPj4gKlN1YmplY3Q6 ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4g Pj4NCj4gPj4gWW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0 cyB0aGUgZm9yd2FyZGluZyBwYXRoDQo+ID4+IHRocm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFj dHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KPiA+PiBob3dldmVyIHBv aW50cyB0byB0aGUgc2VydmljZSBjaGFpbiBkYXRhIHN0cnVjdHVyZSBhbmQgdGhhdCBpcyB0aGVu DQo+ID4+IHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5l eHQtaG9wcyB0byB0aG9zZQ0KPiA+PiBpbnN0YW5jZXMgYXJlIGF2YWlsYWJsZSBhbmQgd2hhdGV2 ZXIgbG9hZCBkaXN0cmlidXRpb24gdGVjaG5pcXVlIGlzIGluDQo+ID4+IHBsYXkuIFdoZW4gaW5z dGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFpbiBpbnRvIHRoZSBuZXR3b3JrIHlvdSBtYXkgb3IN Cj4gPj4gbWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5IHdoaWNo IG5leHQtaG9wcyBtYXkgYmUNCj4gPj4gdXNlZCAod2hlcmUgYSBzaW5nbGUgbmV4dC1ob3Agd291 bGQgZWZmZWN0aXZlbHkgbmFpbCB1cCB0aGUgc2VydmljZSBwYXRoDQo+ID4+IGZvciB0aGF0IHNl cnZpY2UgY2hhaW4pIG9yIHlvdSBtYXkgc2ltcGx5IGFsbG93IHNvbWUgb3RoZXIgcHJvdG9jb2wg Lw0KPiA+PiBtZWNoYW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3Uu DQo+ID4+DQo+ID4+ICpGcm9tOiAqIm1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20+Ig0KPiA+PiA8bWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9s LmNvbT4+DQo+ID4+ICpEYXRlOiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNDQo+ ID4+ICpUbzogKkppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tIDxtYWlsdG86amd1aWNo YXJAY2lzY28uY29tPj4sDQo+ID4+ICJtbjE5MjFAYXR0LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQu Y29tPiIgPG1uMTkyMUBhdHQuY29tDQo+ID4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiwgIm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPiINCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sICJqbWhAam9lbGhhbHBlcm4uY29t DQo+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4iIDxqbWhAam9lbGhhbHBlcm4uY29t DQo+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LCAiUm9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbQ0KPiA+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20+Ig0KPiA+PiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPiA+PiA8bWFpbHRv OlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PiwgInNmY0BpZXRmLm9yZw0KPiA+PiA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ Pg0KPiA+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vycw0KPiA+Pg0KPiA+PiBJIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhl IGNvbmZ1c2lvbjoNCj4gPj4NCj4gPj4+IEkgZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkNCj4gPj4+ IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlv biB0aGVyZW9mKS4gSQ0KPiA+Pj4gYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg4oCc MTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0bw0KPiA+Pj5TMS0+UzItPlMzDQo+ID4+PiBh bmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KPiA+Pg0KPiA+PiBCeSBkZWZpbml0 aW9uLCBJIHVuZGVyc3Rvb2QgYSAic2VydmljZSBwYXRoIiB0byBiZSBhbiBvcmRlcmVkIGxpc3Qg b2YNCj4gPj4gc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5 b3UgdXNlIGEgInNlcnZpY2UgcGF0aA0KPiA+PiBpZGVudGlmaWVyIiB0byByZWZlciB0byBhIHNl cnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAiW2RvZXMgbm90XQ0KPiA+PiBzcGVjaWZ5 IHNwZWNpZmljIGluc3RhbmNlcyIuDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0K PiA+PiAqRnJvbTogKmpndWljaGFyQGNpc2NvLmNvbQ0KPiA+PiA8bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT48amd1aWNoYXJAY2lzY28uY29tDQo+ID4+PG1haWx0bzpqZ3VpY2hhckBjaXNjby5j b20+Pg0KPiA+PiAqVG86ICpOQVBJRVJBTEEsIE1BUklBIEg8bW4xOTIxQGF0dC5jb20NCj4gPj4g PG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4g Pj4NCj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuDQo+IGNvbQ0KPiA+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+PixKb2VsIE0uDQo+ID4+IEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+PixSb24NCj4gPj4gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb20NCj4gPj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tPj4sc2ZjQGlldGYub3JnDQo+ID4+IDxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPiA+PiAqU2VudDogKkZyaWRheSwgSnVseSAxMSwg MjAxNA0KPiA+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPiA+Pg0KPiA+PiBNYXJpYSwNCj4gPj4NCj4gPj4gSSB0aGluayBv ZiBpdCB0aGlzIHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBv aW50ZXINCj4gPj50bw0KPiA+PiBhIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8g bmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91DQo+IGRlZmluZQ0KPiA+PmENCj4gPj4gY2hhaW4s IGxldOKAmXMgc2F5IFMxIC0+UzItPiBTMywgeW91ICptaWdodCogd2hlbiBjcmVhdGluZyB0aGUg U0ZQIHNwZWNpZnkNCj4gPj4gdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRy YWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0DQo+ID4+U0ZQLg0KPiA+PiBIb3dldmVyLCB5 b3UgZG8gKm5vdCogaGF2ZSB0byBkbyB0aGlzIGZyb20gYW4gYXJjaGl0ZWN0dXJhbCBzdGFuZHBv aW50DQo+ID4+KEkNCj4gPj4gd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlvdSBkb27i gJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5KS4gWW91DQo+ID4+IGNvdWxkIHNpbXBseSBhc3Np Z24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBwb2ludCB0byBhIGdpdmVuIFNGQw0KPiA+ PmFuZA0KPiA+PiB0aGVuIHB1c2ggdGhhdCBpbmZvcm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBB dCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhDQo+ID4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRv IFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQgY29udGFpbg0KPiA+PnRoZQ0KPiA+ PiBuZXh0LWhvcHMgYXZhaWxhYmxlIGZvciBlYWNoIG9mIHRoZSBTRuKAmXMgd2l0aGluIHRoZSBT RkMgLSBob3cgeW91IGxlYXJuDQo+ID4+IHRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlv dSBjb3VsZCBwdXNoIHRoZW0gZG93biBmcm9tIGENCj4gPj5jZW50cmFsaXplZA0KPiA+PiBjb250 cm9sbGVyLCBjb25maWd1cmUgdGhlbSB0aHJvdWdoIENMSSwgbGVhcm4gdGhlbSBkeW5hbWljYWxs eSB0aHJvdWdoDQo+ID4+IHNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBn aXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvDQo+ID4+IHNheSB0aGF0IHRoZSBzZXJ2aWNl IHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYQ0KPiA+PnByaW9y aQ0KPiA+PiBhbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAoYW5kIHNvbWUgd291 bGQgc2F5IHJlY29tbWVuZGVkKQ0KPiB0bw0KPiA+PmRvDQo+ID4+IHNvLg0KPiA+Pg0KPiA+PiBM ZXTigJlzIHRha2UgYW4gZXhhbXBsZSB0byBob3BlZnVsbHkgbWFrZSB0aGlzIGNsZWFyOg0KPiA+ Pg0KPiA+PiBJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEpIFMx LT5TMi0+UzMuIEZvciBhcmd1bWVudHMNCj4gPj4gc2FrZSBsZXTigJlzIHNheSBJIHdhbnQgaXQg dG8gYmUgZnVsbHkgZHluYW1pYyBlLmcuIEkgZG9u4oCZdCB3YW50IHRvDQo+ID4+c3BlY2lmeQ0K PiA+PiBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmlu YXRpb24gdGhlcmVvZikuIEkNCj4gPj4gYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg 4oCcMTAw4oCdIHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0bw0KPiA+PlMxLT5TMi0+UzMNCj4gPj4g YW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEg c3RydWN0dXJlcyBhcmUNCj4gPj4gcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93 IGF0IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMNCj4gPj5hcnJpdmVzDQo+ID4+IHdpdGggc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRo ZSBkYXRhDQo+ID4+IHN0cnVjdHVyZSBhbmQgZmluZCB0aGF0IGl0IHBvaW50cyB0byBTMS0+UzIt PlMzIGFuZCB0aGUgaW5kZXggaW4gdGhlIFNGQw0KPiA+PiBlbmNhcHN1bGF0aW9uIHdpbGwgdGVs bCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkNCj4gPj53 ZQ0KPiA+PiBhcmUgYXQgUzIgaW4gdGhlIGNoYWluLiBUaGUgU0ZGIHdpbGwgbm93IGhhdmUgdG8g cmVzb2x2ZSB0aGUgbmV4dC1ob3AgdG8NCj4gPj4gUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8g ZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCj4gPj4NCj4gPj4gT24gNy8xMS8xNCwg MTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbQ0KPiA+PiA8bWFp bHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+ID4+DQo+ID4+ICA+SmltLA0KPiA+PiAgPg0K PiA+PiAgPkNvdWxkIHlvdSB0ZWxsIHVzIHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgYSAic2Vy dmljZSBwYXRoIiBhbmQgYQ0KPiA+PiAgPiJzZXJ2aWNlIHBhdGggaWRlbnRpZmllciI/DQo+ID4+ ICA+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9z ZW4gYXByaW9yaQ0KPiA+Pih3aGljaA0KPiA+PiAgPmlzIG15IGN1cnJlbnQgdW5kZXJzdGFuZGlu ZykgdGhlbiBpdCBpcyBub3QgU0ZGJ3MgbG9jYWwgZGVjaXNpb24gd2hpY2gNCj4gPj4gID5uZXh0 LWhvcCBTRkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi4NCj4gPj4gID4N Cj4gPj4gID5NYXJpYQ0KPiA+PiAgPg0KPiA+PiAgPg0KPiA+PiAgPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gID4+DQo+ID4+DQo+ID4+IEZyb206IEppbSBHdWljaGFyZCAoamd1 aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPiA+PiAgPj4gU2VudDogRnJpZGF5 LCBKdWx5IDExLCAyMDE0IDExOjE1IEFNDQo+ID4+ICA+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBI OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+IDxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT47IEpvZWwgTS4NCj4gPj4gID4+IEhhbHBlcm47IFJvbiBQYXJrZXI7 IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiAg Pj4NCj4gPj4gID4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQg d2h5IGEgc2VydmljZSBwYXRoDQo+ID4+aWRlbnRpZmllcg0KPiA+PiAgPj4gcHJldmVudHMgZnVs bCBkaXN0cmlidXRpb24gb2YgU0YgbmV4dC1ob3BzIG9yIHdoeSBjYWxsaW5nIGl0IGENCj4gPj5z ZXJ2aWNlDQo+ID4+ICA+PiBjaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0K PiA+PiAgPj4NCj4gPj4gID4+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJ QSBIIiA8bW4xOTIxQGF0dC5jb20NCj4gPj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3Rl Og0KPiA+PiAgPj4NCj4gPj4gID4+ID5EaXR0by4NCj4gPj4gID4+ID4NCj4gPj4gID4+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ICA+PiA+PiBGcm9tOiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+ID4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4NCj4gPj4gID4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4g Pj4gID4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPiA+PiAgPj4g Pj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwg TS4NCj4gPj5IYWxwZXJuOyBSb24NCj4gPj4gID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ICA+PiA+Pg0KPiA+PiAg Pj4gPj4gUmUtLA0KPiA+PiAgPj4gPj4NCj4gPj4gID4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBh dCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPiA+PiAgPj5kcmFm dC4NCj4gPj4gID4+ID4+DQo+ID4+ICA+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRl bnRpZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlDQo+ID4+ZnVsbA0KPiA+PiAgPj4g Pj5kaXN0cmlidXRlZA0KPiA+PiAgPj4gPj4gbW9kZWwgaXMgbm90IGFsbG93ZWQuDQo+ID4+ICA+ PiA+Pg0KPiA+PiAgPj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVk IHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4NCj4gPj5pdHNlbGYNCj4gPj4gID4+ID4+c2hvdWxkIGJl DQo+ID4+ICA+PiA+PiBwcm92aWRlZCBpbnN0ZWFkLg0KPiA+PiAgPj4gPj4NCj4gPj4gID4+ID4+ IENoZWVycywNCj4gPj4gID4+ID4+IE1lZA0KPiA+PiAgPj4gPj4NCj4gPj4gID4+ID4+ID4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gID4+ID4+ID5EZSA6IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEppbQ0KPiA+Pkd1aWNoYXJkDQo+ID4+ ICA+PiA+PiA+KGpndWljaGFyKQ0KPiA+PiAgPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBq dWlsbGV0IDIwMTQgMTY6MTgNCj4gPj4gID4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsg Sm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gID4+ID4+ID4NCj4gPj4gID4+ID4+ ID5PayBidXQgd2hlcmUgaW4gdGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcw0K PiA+PmZ1bmN0aW9uYWxpdHkNCj4gPj4gID4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0 byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxsKg0KPiA+PlNGRuKAmXMNCj4gPj4g ID4+ID4+ID53aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlkZW50 aWZpZXIgcG9pbnQgdG8NCj4gPj5hDQo+ID4+ICA+PiA+Pmxvb2t1cA0KPiA+PiAgPj4gPj4gPmlu dG8gdGhvc2UgbmV4dC1ob3BzIHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBh bSBub3QNCj4gPj4gID4+c3VyZQ0KPiA+PiAgPj4gPj5ob3cNCj4gPj4gID4+ID4+ID50aGUgYXJj aGl0ZWN0dXJlIHByZXZlbnRzIHRoYXQ/DQo+ID4+ICA+PiA+PiA+DQo+ID4+ICA+PiA+PiA+T24g Ny8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tDQo+ ID4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0KPiA+PiAgPj4gd3JvdGU6DQo+ID4+ICA+PiA+ PiA+DQo+ID4+ICA+PiA+PiA+PkFic29sdXRlbHkuDQo+ID4+ICA+PiA+PiA+Pg0KPiA+PiAgPj4g Pj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ICA+PiA+PiA+Pj4gRnJvbTog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4gPj5H dWljaGFyZA0KPiA+PiAgPj4gPj4gPj4+KGpndWljaGFyKQ0KPiA+PiAgPj4gPj4gPj4+IFNlbnQ6 IEZyaWRheSwgSnVseSAxMSwgMjAxNCA5OjU0IEFNDQo+ID4+ICA+PiA+PiA+Pj4gVG86IE5BUElF UkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOw0KPiA+PiBzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiA+PiA+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ICA+ PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9z YWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zDQo+ID4+dG8gbWUNCj4gPj4gID4+ID4+dGhhdCBp Zg0KPiA+PiAgPj4gPj4gPj4+IHlvdSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFz IHRvIHdoaWNoIHJlbW90ZSBTRkYgaXQNCj4gPj4gID4+d2lsbA0KPiA+PiAgPj4gPj51c2UNCj4g Pj4gID4+ID4+ID4+PmZvcg0KPiA+PiAgPj4gPj4gPj4+IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0 aGUgbmV4dCBTRiB3aXRoaW4gdGhlIGNoYWluIHRoZW4geW91DQo+ID4+ICA+PmJldHRlcg0KPiA+ PiAgPj4gPj5tYWtlDQo+ID4+ICA+PiA+PiA+Pj4gc3VyZSB0aGF0IHRoYXQgcmVtb3RlIFNGRiBo YXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljDQo+ID4+dG8NCj4gPj4gID4+ID4+cmVh Y2gNCj4gPj4gID4+ID4+ID4+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3Ig dGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXANCj4gPj50cm91YmxlLg0KPiA+ PiAgPj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gT24gNy8xMS8xNCwgOTo0OCBBTSwgIk5BUElF UkFMQSwgTUFSSUEgSCINCj4gPG1uMTkyMUBhdHQuY29tDQo+ID4+IDxtYWlsdG86bW4xOTIxQGF0 dC5jb20+Pg0KPiA+PiAgPj4gPj4gd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQg b25seSBpbg0KPiA+PiAgPj5yZWxldmFudA0KPiA+PiAgPj4gPj4gPj4+U0ZGcw0KPiA+PiAgPj4g Pj4gPj4+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+ID4+ICA+PiA+PiA+Pj4gPg0KPiA+PiAgPj4g Pj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ICA+PiA+PiA+Pj4gPj4g RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0N Cj4gPj4gID4+R3VpY2hhcmQNCj4gPj4gID4+ID4+ID4+PiA+PihqZ3VpY2hhcikNCj4gPj4gID4+ ID4+ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPiA+PiAgPj4g Pj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0K PiA+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPiA+PkJhbGFuY2Vycw0K PiA+PiAgPj4gPj4gPj4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlz IGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZQ0KPiA+PnVuZGVyc3Rvb2QNCj4gPj4gID4+ dGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj5wcm9wb3NhbA0KPiA+PiAgPj4gPj4gPj4+ID4+IGNvcnJl Y3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdlIG9mIGV2ZXJ5DQo+ID4+c2lu Z2xlDQo+ID4+ICA+PlNGDQo+ID4+ICA+PiA+PiA+Pj53aXRoaW4NCj4gPj4gID4+ID4+ID4+PiA+ PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmds ZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5DQo+ID4+dG8NCj4gPj4gID4+a25vdw0KPiA+PiAgPj4g Pj5hDQo+ID4+ICA+PiA+PiA+Pj4gPj5wcmlvcmkNCj4gPj4gID4+ID4+ID4+PiA+PiB3aGljaCBT RkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+ID4+ ICA+PnBvaW50DQo+ID4+ICA+PiA+PmluDQo+ID4+ICA+PiA+PiA+Pj50aW1lLg0KPiA+PiAgPj4g Pj4gPj4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2Vs IE0uIEhhbHBlcm4iDQo+ID4+IDxqbWhAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT4+DQo+ID4+ICA+PiA+PiB3cm90ZToNCj4gPj4gID4+ID4+ID4+PiA+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID5Sb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5v dGhlciBtYWpvcg0KPiA+PnByb2JsZW0NCj4gPj4gID4+d2l0aA0KPiA+PiAgPj4gPj50aGUNCj4g Pj4gID4+ID4+ID4+PiA+PnlvdXINCj4gPj4gID4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1 bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heQ0KPiA+Pm5vdA0KPiA+PiAg Pj4gPj4gPj4+dW5kZXJzdGFuZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID5pdC4pDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPg0KPiA+PiAgPj4gPj4gPj4+ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZG IHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvcg0KPiA+PnRoZQ0KPiA+PiAgPj4gPj5uZXh0 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0IChu b3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPiA+PiAgPj50byksDQo+ID4+ICA+PiA+PmluDQo+ID4+ ICA+PiA+PiA+Pj5ldmVyeQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRoYXQg Z29lcyB0aHJvdWdoIGl0Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhh dA0KPiA+Pm1lYW5zDQo+ID4+ICA+PiA+PnRoYXQNCj4gPj4gID4+ID4+ID4+PiA+PmV2ZXJ5DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5z aXRpdmUgYW5kIHN0YXRlZnVsDQo+ID4+bG9hZA0KPiA+PiAgPj4gPj4gPj4+YmFsYW5jZXIuDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93 IHNlbnNpdGl2ZSwgYW5kIC8NCj4gPj5vcg0KPiA+PiAgPj4gPj5zdGF0ZWZ1bC4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVy eSBTRkYgYmUgYQ0KPiA+PmZ1bGwsDQo+ID4+ICA+PiA+PmZsb3cNCj4gPj4gID4+ID4+ID4+PiA+ PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBh bg0KPiA+PiAgPj4gPj5hY2NlcHRhYmxlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24u DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPg0KPiA+PiAgPj4gPj4gPj4+ID4+ID5Zb3VycywNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Sm9lbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4gPj4g ID4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRy eWluZyB0byBtYWtlDQo+ID4+dGhpcw0KPiA+PiAgPj53b3JrDQo+ID4+ICA+PiA+PiA+Pj4gPj5z ZW5zaWJseQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52 aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQgdGhlDQo+ID4+ICA+PnNlcnZpY2UNCj4gPj4gID4+ID4+ ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBh YmlsaXRpZXMsDQo+ID4+ICA+PndpbGwNCj4gPj4gID4+ID4+YmUNCj4gPj4gID4+ID4+ID4+PiA+ PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZpY2UgY2hh aW5zDQo+ID4+ICA+PnRvIGJlDQo+ID4+ICA+PiA+PiA+Pj4gPj5kcml2ZW4gYnkNCj4gPj4gID4+ ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMs IGFuZCBlbmFibGUNCj4gPj4gID4+ID4+ID4+PnNlbGYtc2VsZWN0aW9uDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4gZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5 IHBvbGljeQ0KPiA+PiAgPj4gPj5kcml2ZS4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGlu IGFuDQo+ID4+YXJjaHRpZWN0dXJlDQo+ID4+ICA+PiA+PmRyaXZlbg0KPiA+PiAgPj4gPj4gPj4+ YnkNCj4gPj4gID4+ID4+ID4+PiA+PiA+PiBpbml0aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2Ny aWJlZCBzZXJ2aWNlIHBhdGhzLiBJdA0KPiA+PmlzDQo+ID4+ICA+PiA+PmhhcmRlcg0KPiA+PiAg Pj4gPj4gPj4+dG8NCj4gPj4gID4+ID4+ID4+PiA+PnNlZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZQ0KPiBhbGxv dw0KPiA+Pm1vcmUNCj4gPj4gID4+ID4+ID4+PiA+PiBkeW5hbWljaXR5DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4gaW4gdGhlIG5ldHdvcmsgYmVoYXZpb3IuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVy c3BlY3RpdmUgSSBkZXNjcmliZWQNCj4gPj5pcw0KPiA+PiAgPj4gPj5vdXRzaWRlDQo+ID4+ICA+ PiA+PiA+Pj5vZg0KPiA+PiAgPj4gPj4gPj4+ID4+dGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4g c2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+ ID4+ICA+PiA+PnRhc2tlZCB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+YWdyZWUNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pm9uLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRo YXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYQ0KPiA+PiAgPj5jZXJ0YWluDQo+ID4+ ICA+PiA+PiA+Pj53YXkuDQo+ID4+ICA+PiA+PiA+Pj4gPj5pdA0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVzIG15IHByZWZlcmVuY2VzLg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4gSm9lbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0 IHNlcnZpY2UNCj4gPj5pbnN0YW5jZXMNCj4gPj4gID4+ID4+IHRoYXQNCj4gPj4gID4+ID4+ID4+ PiA+Pm5lZWRzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5DQo+ ID4+ZXZlbg0KPiA+PiAgPj4gPj5hY3Jvc3MNCj4gPj4gID4+ID4+ID4+PmRhdGENCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBp cyBsYXJnZQ0KPiA+PmVub3VnaA0KPiA+PiAgPj5hbmQNCj4gPj4gID4+ID4+ID4+PiBjb21wbGV4 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQg aW50byBlYWNoIFNGRiBzZWVtcw0KPiA+Pmxpa2UgYQ0KPiA+PiAgPj4gPj4gPj4+ZGlmZmljdWx0 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMg dG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+ID4+ICA+PmR5bmFtaWMNCj4g Pj4gID4+ID4+ID4+PiByb3V0aW5nLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2Fs ZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPiA+PiAgPj53aGlj aA0KPiA+PiAgPj4gPj5hcmUNCj4gPj4gID4+ID4+ID4+PiA+PmJpZ2dlcg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkN Cj4gPj5pbXBsZW1lbnRlZD8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4gSXQgYWxzbyBzZWVtcyB0aGF0IGlmIGl0IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNh dGVkLA0KPiA+PnRoYXQNCj4gPj4gID4+aXMNCj4gPj4gID4+ID4+YQ0KPiA+PiAgPj4gPj4gPj4+ Z29vZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBzaWduIHRoYXQgaXQgaXMgdG9vIGNvbXBsaWNh dGVkLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBTZW50OiBU aHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRv OiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0Ow0KPiBtaWtlYmlhbmNAYW9sLmNvbQ0K PiA+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4gPj4gID4+SWFuDQo+ID4+ICA+PiA+ PiA+Pj5TbWl0aDsNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPiA+PiAgPj5CYWxhbmNlcnMNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gVGhpcyBpcyBhbiBhcmNo aXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZA0KPiA+PiAgPj5wcmVmZXINCj4g Pj4gID4+ID4+d2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj5hY3R1YWxseQ0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2li bGUNCj4gPj4gID4+ID4+aW1wbGVtZW50YXRpb25zLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBC ZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJvbA0KPiA+PiAg Pj4gPj5yZXF1aXJlbWVudHMNCj4gPj4gID4+ID4+ID4+PmFuZA0KPiA+PiAgPj4gPj4gPj4+ID4+ IHRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFt b3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlDQo+ID4+aW5zdGFuY2VzDQo+ID4+ICA+ PiA+PnRoYXQNCj4gPj4gID4+ID4+ID4+PiBuZWVkcw0KPiA+PiAgPj4gPj4gPj4+ID4+IHRvDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5l ZCwgcG90ZW50aWFsbHkgZXZlbg0KPiA+PiAgPj4gYWNyb3NzDQo+ID4+ICA+PiA+PiA+Pj5kYXRh DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZl IHNjb3BlLCBpcyBsYXJnZQ0KPiA+PmVub3VnaA0KPiA+PiAgPj5hbmQNCj4gPj4gID4+ID4+ID4+ PmNvbXBsZXgNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdl dCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMNCj4gPj5saWtlIGENCj4gPj4gID4+ID4+ID4+PmRp ZmZpY3VsdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IEpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4gQnV0IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gT24gNy8xMC8xNCwgOTozOCBQTSwg Um9uIFBhcmtlciB3cm90ZToNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNy dXggb2YgbXkgaXNzdWUuIElzIHRoZSBlbmQgdG8gZW5kDQo+ID4+ICA+PnNlbGVjdGlvbg0KPiA+ PiAgPj4gPj5vZg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2Vz IHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMNCj4gPj5ieSB0aGUNCj4gPj4gID4+ID4+ID4+ PiA+PmNsYXNzaWZpZXIpDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChw ZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZA0KPiA+PnN1YnNlcXVlbnRseQ0KPiA+PiAgPj4g Pj50aGUNCj4gPj4gID4+ID4+ID4+PiA+PlNGRnMpPw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g U3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4g Pj4gID4+QW5kDQo+ID4+ICA+PiA+PiA+Pj5zdXJlbHksDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbiIuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3Ig dGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoDQo+IGV2ZW4NCj4gPj4gID4+IHRob3VnaA0KPiA+PiAg Pj4gPj4gYQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gZ3JlYXRlciBhbW91bnQgb2YgZGF0YSAo Y2hhaW4gZGVmaW5pdGlvbnMgYW5kDQo+IHBlcmhhcHMNCj4gPj4gID4+bG9jYWwNCj4gPj4gID4+ ID4+ID4+PiA+PnNlbGVjdGlvbg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcG9saWN5KSBpcyBy ZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbg0KPiA+PnBvaW50cy4NCj4gPj4g ID4+ID4+VGhpcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVx dWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQNCj4gPj5hbGwuDQo+ID4+ICA+PiA+Pk15DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9h Y2ggaXMgcHJpbWFyaWx5DQo+ID4+ZHJpdmVuDQo+ID4+ICA+PmJ5DQo+ID4+ICA+PiA+PiA+Pj4g Pj5pbmNyZWFzZWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUg Z2xvYmFsIHBhdGggaWQgYXBwcm9hY2guIFdpdGggYQ0KPiA+PiAgPj5nbG9iYWwNCj4gPj4gID4+ ID4+ID4+PnBhdGgNCj4gPj4gID4+ID4+ID4+PiA+PmlkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQNCj4gPj5uZWVk aW5nIHRvDQo+ID4+ICA+PiA+PmFsdGVyDQo+ID4+ICA+PiA+PiA+Pj50aGUNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZl Y3RlZA0KPiA+PiAgPj5lbmQtdG8tZW5kDQo+ID4+ICA+PiA+PiA+Pj5wYXRoLg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFJvbg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dDQo+ ID4+IG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBbam1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0bzpqbWguZGlyZWN0 QGpvZWxoYWxwZXJuLmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPiA+PiAgPj4yMDE0 DQo+ID4+ICA+PiA+PiA2OjE1DQo+ID4+ICA+PiA+PiA+Pj4gUE0NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNvbQ0KPiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t PjsNCj4gPj4gSS5TbWl0aEBGNS5jb20gPG1haWx0bzpJLlNtaXRoQEY1LmNvbT47IHNmY0BpZXRm Lm9yZw0KPiA+PjxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gU3ViamVjdDoNCj4gPj4g ID4+ID4+IFJlOg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBj YXNlIG9mIFNGMQ0KPiA+Pm5lZWRpbmcNCj4gPj4gID4+dG8NCj4gPj4gID4+ID4+ID4+PiA+Pmlu Zmx1ZW5jZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdv dWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQNCj4gPj50aGUNCj4gPj4gID4+ZXhpdA0KPiA+PiAg Pj4gPj5mcm9tDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0byBr ZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+ID4+ICA+PiA+PmxvZ2ljYWxseQ0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkg ZGVzY3JpYmUgaG93DQo+ID4+dGhleQ0KPiA+PiAgPj4gPj4gY2hvb3NlDQo+ID4+ICA+PiA+PiA+ Pj50bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVtIGZvciAic2VydmljZSIg ZGVsaXZlcnkuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gWW91cnMsIEpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbQ0KPiA+PiA8bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tPiB3cm90ZToNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBJ IGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0DQo+ID4+c3VnZ2VzdHMg YW55DQo+ID4+ICA+PiA+PnNvcnQNCj4gPj4gID4+ID4+ID4+Pm9mDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRo ZQ0KPiA+PmVudGlyZQ0KPiA+PiAgPj4gPj5wYXRoDQo+ID4+ICA+PiA+PiA+Pj4oYWxsDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRp YXRpb24uIEkgYmVsaWV2ZQ0KPiA+PiAgPj50aGlzDQo+ID4+ICA+PiA+PiA+Pj5tZWFucw0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0 aGUgY2xhc3NpZmllcg0KPiA+PiAgPj5jaG9vc2VzIGENCj4gPj4gID4+ID4+U0YNCj4gPj4gID4+ ID4+ID4+PiA+PkNoYWluDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYW5kIHRoZSBORiBvciBh dCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueQ0KPiA+PmNhc2UsDQo+ID4+ICA+PiA+ PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9o aWJpdCBhIG1vcmUgZHluYW1pYyBTRlANCj4gPj53aGVyZQ0KPiA+PiAgPj4gPj4gU0ZJKG4pDQo+ ID4+ICA+PiA+PiA+Pj4gaXMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXRlcm1pbmVkIGF0 IHRoZSBTRkkobi0xKSBob3AuIEFjY29yZGluZyB0byB0aGUNCj4gPj5kcmFmdCwNCj4gPj4gID4+ ID4+dGhpcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNp ZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcNCj4gPj5TRlAgYXMNCj4gPj4gID4+ID4+ID4+PiBv cHBvc2VkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gdG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBj aG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZA0KPiA+Pmluc3RhbmNl IG9mDQo+ID4+ICA+PiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9m IHRoZSBjdXJyZW50IFNGQy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiBXaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0 d29yayBpdCBpcw0KPiA+PiAgPj4gPj5uZWNlc3NhcnkNCj4gPj4gID4+ID4+ID4+PnRvDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNG cyB0aGF0IHdpbGwgYmUNCj4gPj51c2VkLA0KPiA+PiAgPj4gPj5hbmQgdG8NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1 c2luZyBTRidzDQo+ID4+ICA+PiA+Pm5ldHdvcmsNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4g bG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4NCj4gPj50 aGUNCj4gPj4gID4+ID4+ID4+PmNyZWF0aW9uDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9m IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPiA+PiAgPj4g Pj5mb3J3YXJkaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0 aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzDQo+ID4+dGhlDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hp dGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZpY2F0aW9uIChvcg0KPiA+PiAgPj4gPj5ub24taW5p dGlhbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbikgYXMgd2VsbC4g QXMgcGFja2V0cyB0cmF2ZXJzZSBhbg0KPiA+PlNGUCwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkDQo+ID4+ YnkgYQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBj by1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPiA+PiAgPj4gPj5mdW5jdGlvbi4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxl Y3Rpb24gb2YgYQ0KPiA+Pm5ldw0KPiA+PiAgPj4gPj5TRlAsIGFuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3IgYm90aC4gVGhp cyBpcw0KPiA+PiAgPj4gPj5yZWZlcnJlZA0KPiA+PiAgPj4gPj4gPj4+dG8NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gYXMgImJyYW5jaGluZyIuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+Pg0KPiA+PiAgPj4gPj4gPj4+ DQo+ID4+ICA+PiA+Pg0KPiA+PiAgPj4NCj4gPj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiAgPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiAgPj4gPj4+Pj4+ Pj4+Pj4+LS0tDQo+ID4+ICA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+ID4+ID4+PiA+Pj4+ Pj4+LS0NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb20NCj4gPj4gPG1haWx0 bzoqSS5TbWl0aEBGNS5jb20+PEkuU21pdGhARjUuY29tIDxtYWlsdG86SS5TbWl0aEBGNS5jb20+ Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ICpUbzogKkpvZWwgSGFscGVybg0KPiA+PiAgPj4g RGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWlsdG86am1oLmRpcmVj dEBqb2VsaGFscGVybi5jb20+PixKb2VsDQo+ID4+ICA+PiA+PiBNLg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4NCj4gPj4gID4+ID4+ID4+Pg0KPiA+PiAgPj4g Pj4NCj4gPj4gID4+ID4+Pj4+SGFscGVybjxqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYQ0KPiA+PiA8bWFp bHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVhbmdAc2NlLg0KPiA+PiA8bWFpbHRvOmh1YW5n QHNjZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Y2E+LHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnDQo+ID4+ IDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQNCj4gPj4gID4+ID4+QmFsYW5jZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVl aW5nLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g SWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1zY2FsZSBkZXBsb3ltZW50cyAoYW5kDQo+ID4+ ICA+PnRoYXQgaXMNCj4gPj4gID4+ID4+ID4+PndoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucw0KPiA+ PmlzDQo+ID4+ICA+PiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0ZWN0dXJlIGJ1cmRlbmVkDQo+ID4+ d2l0aA0KPiA+PiAgPj4gdGhhdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRp b24uDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBU aGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mDQo+ID4+ICA+ PiA+PmFzcGlyYXRpb24NCj4gPj4gID4+ID4+IHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g c2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZQ0KPiA+PiAg Pj4gPj5hcmNoaXRlY3R1cmUNCj4gPj4gID4+ID4+ID4+Pi0NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcNCj4g Pj50aGF0IGFuDQo+ID4+ICA+PiA+PiA+Pj5hcmJpdHJhcnkNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0DQo+ ID4+aXNuJ3QNCj4gPj4gID4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlDQo+ ID4+bGFzdGluZw0KPiA+PiAgPj4gPj5pbXBhY3RzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LA0KPiA+ PiAgPj4gPj5hZGRyZXNzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtp bmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtDQo+ID4+bm90DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gcGFydGljdWxhcmx5IGVhZ2VyIHRvIGRlYWwgd2l0aC4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdA0KPiA+PiBbam1oLmRpcmVjdEBq b2VsaGFscGVybi5jb20gPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+ID4+ ICA+PiA+PlNlbnQ6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsDQo+ID4+TS4NCj4gPj4gID4+ID4+IEhh bHBlcm47DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhDQo+ ID4+IDxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsgc2ZjQGlldGYub3JnIDxtYWlsdG86 c2ZjQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW3NmY10NCj4gPj4gID4+ID4+U2Vydmlj ZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g SWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBpbg0KPiA+PnRo aXMNCj4gPj4gID4+ID4+cmVnYXJkLg0KPiA+PiAgPj4gPj4gPj4+SQ0KPiA+PiAgPj4gPj4gPj4+ ID4+YW0NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFy Y2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4gPj4gID4+ID4+cHJvaGliaXQNCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBh bSBvYmplY3RpbmcNCj4gPj50bw0KPiA+PiAgPj4gPj5IdWFuZydzDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVu dHMNCj4gPj5hcmUNCj4gPj4gID4+ID4+IHJlcXVpcmVkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBu b3QgdHJ5aW5nIHRvDQo+ID4+cHJvaGliaXQNCj4gPj4gID4+c3VjaA0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QNCj4g ZGVwZW5kcw0KPiA+PnVwb24NCj4gPj4gID4+ID4+IG1hbnkNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBoYXBwZW4gdG8N Cj4gPj4gID4+dGhpbmsNCj4gPj4gID4+ID4+dGhhdA0KPiA+PiAgPj4gPj4gPj4+ID4+dGhleQ0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0 aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcNCj4gPj5hdHRlbXB0aW5nIHRvDQo+ID4+ICA+ PiA+Pmtub3cNCj4gPj4gID4+ID4+ID4+PndoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBp cyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGgg d3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IEkgZGlzYWdyZWUuDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBo YXZlIHN0YXRlZnVsIGRldmljZXMgdGhhdCBtYW5hZ2UNCj4gPj50ZW5zIG9mDQo+ID4+ICA+PiA+ PiA+Pj5taWxsaW9ucw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQg ZGF0YQ0KPiA+PmNlbnRlcg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGVudmlyb25tZW50cyB0 b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlDQo+ID4+dGhhdCBpbg0KPiA+PiAgPj50 aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9J b1Qgd29ybGQgb2YgdG9tb3Jyb3cNCj4geW91DQo+ID4+ICA+PiBhcmUNCj4gPj4gID4+ID4+IG9u bHkNCj4gPj4gID4+ID4+ID4+PiA+PiBnb2luZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRv IGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIGVxdWFsbHkNCj4gPj4g ID4+c21hbGwNCj4gPj4gID4+ID4+ID4+PiBudW1iZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gb2YgYWN0aXZlIHNlcnZpY2UgcGF0aHM/DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9u ZSB3aWxsIGV2ZXIgbmVlZA0KPiA+Pm1vcmUNCj4gPj4gID4+IHRoYW4NCj4gPj4gID4+ID4+ID4+ PiA2NEsiDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IGNvbWZvcnQuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZw0KPiA+PiA8bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29tDQo+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT5dDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDQ6NDYgUE0gVG86DQo+ID4+ICA+PiA+PiA+Pj5odWFuZ0BzY2UuY2FybGV0b24uY2EgPG1h aWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0KPiA+PiBbc2Zj XSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+ID4+ICA+PmFuZA0KPiA+PiAgPj4gPj4gPj4+TG9h ZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwgbWVhbiB0aGF0 IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95DQo+ID4+dGhlDQo+ID4+ICA+PiA+PiA+Pj5hcmNo dGlldHVyZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRo ZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPiA+PiAgPj50aGVpcg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUg c3VjaA0KPiA+PmFic3VyZA0KPiA+PiAgPj4gdXNlDQo+ID4+ICA+PiA+PiBvZg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91 dCBob3cgdG8NCj4gPj53cml0ZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1 cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUNCj4gPj5hcmNoaXRlY3R1cmUNCj4gPj4gID4+ ZG9lcw0KPiA+PiAgPj4gPj4gPj4+cGVybWl0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1 Y2ggYWJ1c2UuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJl DQo+ID4+ICA+PiBwZXJtaXRzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBh cyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3INCj4gPj5yZXF1aXJlZCBieQ0KPiA+PiAg Pj4gPj50aGUNCj4gPj4gID4+ID4+ID4+PndvcmsuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IEl0IGlzbid0Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdy b3RlOg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAx MDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGwNCj4gPj4gID4+bWVhbg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91 dGluZw0KPiA+PiAgPj50YWJsZQ0KPiA+PiAgPj4gPj5vZiBhDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+PiBDaGFuZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4g SGFscGVybiB3cm90ZToNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBUaGUgYXJjaGl0ZWN0 dXJlIGFsbG93cyBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLA0KPiA+PmZyb20NCj4gPj4gID4+MQ0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCB0byAxNjAwMDAgc2Vydmlj ZSBwYXRocy4gSSB3b3VsZA0KPiA+PmhvcGUNCj4gPj4gID4+dGhhdA0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMg aWYNCj4gPj50aGV5DQo+ID4+ICA+PiA+PmNob29zZQ0KPiA+PiAgPj4gPj4gPj4+dG8NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5j aW5nIGFuZCBpbg0KPiA+PnN0ZWFkDQo+ID4+ICA+PiA+PiBwcm92aXNpb24NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNlcnZpY2UgcGF0aHMuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24g Ny8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIDQo+IHdyb3RlOg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRo ZXJlIHdpbGwgYmUgZm9yIGEgNA0KPiA+PmhvcA0KPiA+PiAgPj4gPj4gc2VydmljZQ0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhv cD8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gTWFyaWENCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAq T24NCj4gPj5CZWhhbGYNCj4gPj4gID4+IE9mDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBUaHVyc2RheSwgSnVseSAxMCwNCj4gPj4yMDE0 DQo+ID4+ICA+PiA+PjM6MDMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUE0gKlRvOiog THVjeSB5b25nICpDYzoqDQo+IGptaEBqb2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPjsNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+OyBzZmNAaWV0Zi5vcmcNCj4gPj48bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tDQo+IDxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+DQo+ID4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4gPj4gID4+ IENoYWlucywNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBMdWN5LA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGgg SUQgZHJpdmVzDQo+ID4+dGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRp bmcuIEnCuWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJl DQo+ID4+dXNlZCB0bw0KPiA+PiAgPj4gPj4gZGVyaXZlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZA0KPiB0cmFuc3BvcnQu DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bw0KPiA+ PiAgPj5zaW1wbHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZnkgdGhlIHNl cnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQNCj4gPj5wYWNrZXRzDQo+ID4+ICA+Pm11c3QNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVyc2UuIEJ5IGhhdmluZyBhIHBhdGggaWRl bnRpZmllciwgdGhlIGV4YWN0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0 aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvcg0KPiBvbg0KPiA+PiAgPj50aGlz DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJlIGlt cGxlbWVudGVkLiBUaGUNCj4gcGF0aA0KPiA+PiAgPj4gPj4gaWRlbnRpZmllcg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxvb2t1cCwg dGhhdA0KPiA+Pmxvb2t1cCBjYW4NCj4gPj4gID4+ID4+IHJlc3VsdA0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNw b3J0DQo+ID4+bmV4dA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBh dWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbQ0KPiA+PjxtYWlsdG86bHVj eS55b25nQGh1YXdlaS5jb20+DQo+ID4+ICA+PiA+PiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPg0KPiA8bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJTNlPj4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBu b3QgbWFuZGF0ZSBvbmx5DQo+ID4+dXNlIG9mDQo+ID4+ICA+PiB0aGUNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndh cmRpbmcNCj4gPj4gID4+ID4+YWN0aW9ucy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uDQo+ID4+QmVoYWxmDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gPG1haWx0bzpP Ziptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4+ICA+PiA+PiA+ Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPiA+PiAgPj4gPj4gPj4+ID4+IEp1bHkNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQgMjowNiBBTSAqVG86Km1pa2ViaWFuY0Bhb2wuY29t DQo+ID4+IDxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29t DQo+ID4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2U7am1oQGpvZWxoYWxwZXJuLmNvbT4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t PjtzZmNAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0Bp ZXRmLm9yZz4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5v cmc+ICpTdWJqZWN0OipSZTogW3NmY10NCj4gPj5TZXJ2aWNlDQo+ID4+ICA+PiA+PkNoYWlucywN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBSZS0sDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFRoZSBtZXJnZWQgZHJhZnQgY2FsbHMgb3V0IGV4cGxpY2l0bHkgYSBzZXJ2aWNl DQo+ID4+cGF0aA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9i amVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+ID4+ICA+PmRlcml2ZQ0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNG QyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbA0KPiA+Pmtub3dsZWRnZSBvZg0KPiA+PiAgPj4gPj4g ZXZlcnkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVk DQo+IGRvbWFpbg0KPiA+PmlzIG5vdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVpcmVk L2p1c3RpZmllZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3IgcG9zc2libGUgaW4g dmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNo b3VsZCByZWx5IG9uIHRoZSBwaWVjZQ0KPiA+Pm9mDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluZm9ybWF0aW9uDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0 aGF0IGlzIHRoZSBvbmUNCj4gPj4gID4+IHJlcXVpcmVkDQo+ID4+ICA+PiA+PiB0bw0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhh dCBpbmZvcm1hdGlvbg0KPiA+PmlzDQo+ID4+ICA+PiA+PnVzZWQgdG8NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IGFjdGlvbnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1dGlvbi1vcmll bnRlZCBkaXNjdXNzaW9uLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1lZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10qRGUgbGENCj4gPj5wYXJ0DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gZGUqbWlrZWJpYW5jQGFvbC5jb20NCj4gPG1haWx0bzpkZSptaWtlYmlhbmNAYW9sLmNv bT4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bT4gKkVudm95w6kNCj4gOiptZXJjcmVkaSA5DQo+ID4+ICA+PiA+PiBqdWlsbGV0DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIwMTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNv bQ0KPiA+PiA8bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPiA+ PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtz ZmNdIFNlcnZpY2UNCj4gPj4gID4+ID4+Q2hhaW5zLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElzIGFueW9uZSBzdGlsbCBxdWVzdGlv bmluZyB0aGUgZGlmZmVyZW5jZQ0KPiA+PmJldHdlZW4NCj4gPj4gID4+U0YNCj4gPj4gID4+ID4+ IENoYWluDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IFBhdGg/DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90aGVyIHRo YW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0DQo+ID4+aXQncw0KPiA+PiAgPj4g Pj5jbGVhciB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRob3NlIG5vdA0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhh dCBldmVyeW9uZQ0KPiA+PiAgPj5hZ3JlZXMNCj4gPj4gID4+ID4+b24NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhlc2UgdGVybXMuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRvIG1lLCB0aGUgb25lIHBvaW50IHRoYXQg aXMgc3RpbGwgdW5jbGVhciBpcw0KPiA+PiAgPj53aGV0aGVyDQo+ID4+ICA+PiA+Pml0IGlzDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCB0byB1 bHRpbWF0ZWx5IHNwZWNpZnkNCj4gPj53aGF0DQo+ID4+ICA+PiA+PnRoZSBJRA0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBvZiB0aGUgU0ZDIEhlYWRlcg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IHNob3VsZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWZlcmVuY2UgKHRo ZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMNCj4gPj5kcmFmdA0KPiA+PiAgPj4gPj5z aW1wbHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0 IGFtYmlndW91cywgYWxsb3dpbmcNCj4gb3RoZXINCj4gPj4gID4+ZHJhZnRzDQo+ID4+ICA+PiA+ PnRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMg Zm9yIGZvcndhcmRpbmcgYmFzZWQNCj4gb24NCj4gPj5jaGFpbg0KPiA+PiAgPj4gb3INCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBvcg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHBhdGggdG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSWYgdGhlIGxhdHRl ciAoYW1iaWd1b3VzKSwgdGhlbiB0aGUgZHJhZnQgd291bGQNCj4gPj5oYXZlDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBv cnRlZCAob3INCj4gPj5tYWtlDQo+ID4+ICA+PiA+PiBvbmUNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZQ0K PiA+PiAgPj4gdmVuZG9ycw0KPiA+PiAgPj4gPj4gb25seQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+Pg0KPiA+PiAgPj4g Pj4gPj4+DQo+ID4+ICA+PiA+Pg0KPiA+PiAgPj4NCj4gPj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+Pi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiAgPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPiA+PiAgPj4g Pj4+Pj4+Pj4+Pj4+LS0tDQo+ID4+ICA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+ID4+ID4+ PiA+Pj4+Pj4+LS0NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAqRnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRvOipqbWhAam9lbGhh bHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+DQo+ID4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2U+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZw0KPiA+PiA8bWFpbHRvOipz ZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+ DQo+ID4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4gPj4gID4+ ICpTZW50OipUdWVzZGF5LA0KPiA+PiAgPj4gPj4gSnVseQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsDQo+ ID4+YW5kDQo+ID4+ICA+PkxvYWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQmFsYW5j ZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+ ID4+ICA+PmFuc3dlcg0KPiA+PiAgPj4gPj5hDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlDQo+IGFib3V0IHRoZQ0KPiA+ PiAgPj4gPj4gPj4+IHByb3Bvc2VkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdl ZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4gPj4gID4+IHdvcmtp bmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgYWdyZWVtZW50IG9uIHRoZSBp bnRlbnQsIHdlIHdpbGwgd29yayB0bw0KPiA+PiAgPj4gaW1wcm92ZQ0KPiA+PiAgPj4gPj4gdGhl DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdo byBoYXZlIG5vdA0KPiA+PnBhcnRpY2lwYXRlZCBpbg0KPiA+PiAgPj4gPj50aGUNCj4gPj4gID4+ ID4+IFdHDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRl cnN0bmQgaXQgdGhlIHdheSB0aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRv IHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+ID4+ICA+PiA+PnBlcnNvbmFs DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxw cy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQNCj4g Pj50aGF0DQo+ID4+ICA+PiA+PndoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug YXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4NCj4gPj5XZQ0KPiA+ PiAgPj5hcmUNCj4gPj4gID4+ID4+IG5vdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh dHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUNCj4gPj5lbnRpcmUN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5p bmcuIFRoYXQgd291bGQNCj4gPj5lbmNvbXBhc3MNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KPiA+PiAg Pj52aXJ0dWFsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdl IG1hbmFnZW1lbnQsIGFuZCBtYW55DQo+IG90aGVyDQo+ID4+ICA+PiA+PiBhc3BlY3RzLg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBB cyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseQ0KPiA+Pm5lZWQN Cj4gPj4gID4+IHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRoZSBs YXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0DQo+ID4+d2l0aA0KPiA+PiAgPj4gPj5h Ym92ZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBmdW5jdGlvbmluZywNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UNCj4gYXJlDQo+ ID4+ICA+PiBkb2luZy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2Vy dmljZQ0KPiA+PnBhdGgsDQo+ID4+ICA+PmFzIEkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdW5kZXJzdGFuZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5n LiBUaGVyZQ0KPiA+PmFyZSBhdA0KPiA+PiAgPj4gPj5sZWFzdA0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbg0K PiBhbmQNCj4gPj4gID4+d2lsbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnRlcmFj dCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5DQo+ID4+YXJlDQo+ID4+ICA+ PiA+Pm1vcmUuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUg YXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwNCj4gPj5vZg0KPiA+PiAgPj4gPj50aGVzZSwN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55 IHBhcnRpY3VsYXIga2luZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGJlIHVzZWQNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFu Y2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlDQo+ID4+ZW5kDQo+ID4+ICA+PiA+PnVz ZXIuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0 aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+ID4+ICA+PnBhY2tldHMsDQo+ID4+ICA+PiA+PmFuZA0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW0s IG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyDQo+ID4+c2VydmljZQ0KPiA+PiAg Pj4gPj5pbnN0YW5jZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRo ZSB1c2VycyBwYWNrZXQuIFRoaXMgaXMgYW4NCj4gPj5pbXBvcnRhbnQNCj4gPj4gID4+ID4+c2Vy dmljZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRv IGluY2x1ZGUgaW4gc2VydmljZQ0KPiA+PmNoYWluaW5nLg0KPiA+PiAgPj4gPj5JdCdzDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRz IG9uIGhvdw0KPiBzZXJ2aWNlDQo+ID4+ICA+PiA+PiBjaGFpbmluZyBpcw0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0 aGUNCj4gPj4gID4+ID4+YXJjaHRpZWN0dXJlLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNpbXBseQ0KPiA+PmEN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGZ1bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcNCj4gcGFja2V0 Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywNCj4gPj5v bmUNCj4gPj4gID4+Y2FuDQo+ID4+ICA+PiA+PmhhdmUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gd2hhdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFz IGEgc2luZ2xlDQo+ID4+ICA+PnBvaW50DQo+ID4+ICA+PiA+Pm9mDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQg aXMgYWN0dWFsbHkNCj4gPj5kZWxpdmVyZWQNCj4gPj4gID4+ID4+YnkgYQ0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IGNvbGxlY3Rpb24gb2YNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVkaW5nDQo+ID4+ICA+ Pm9uZSBvcg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5j ZXJzIChmb3IgZXhhbXBsZSB1c2luZw0KPiA+PlZSUlAtbGlrZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksDQo+ ID4+dGhpcyBpcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhl IHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0KPiA+PiAgPj4gPj5tZWNoYW5pc21zLg0KPiA+ PiAgPj4gPj4gSXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQg aXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wNCj4gPj4gID4+ID4+bWVjaGFuaXNtcywN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBm b3Igc2NhbGUtaW4sDQo+ID4+c2NhbGUtb3V0LA0KPiA+PiAgPj5hbmQNCj4gPj4gID4+ID4+dm0N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5zdGFudGlhdGlvbi4gVGhlIGFyY2hpdGVj dHVyYWwgaW1wYWN0IG9mDQo+ID4+ICA+PnBlcm1pdHRpbmcNCj4gPj4gID4+ID4+dGhpcw0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBiZSBj YXJlZnVsIHRoYXQgb3VyDQo+ID4+ICA+PiA+PnRlcm1pbm9sb2d5DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWFk ZXJzIHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJp dGluZyBpdC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieQ0K PiA+PiAgPj5zZWxlY3RpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGFja2V0IHBh dGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0DQo+ID4+ZGlyZWN0DQo+ID4+ICA+PiA+ PnRyYWZmaWMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNl cy4gV2Ugd291bGQgbm90IHdhbnQgdG8NCj4gPj5yZXF1aXJlDQo+ID4+ICA+PiB0aGF0DQo+ID4+ ICA+PiA+PmENCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5j dGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UNCj4gPj5pbg0KPiA+PiAgPj50aGUNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBj YXNlIHRoYXQgdGhlc2UgbWF5IGJlDQo+ID4+ICA+PmNvbWJpbmVkLiBJDQo+ID4+ICA+PiA+PiB0 ZW5kDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gcmVmZXIgdG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGNvbGxlY3Rp b24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8NCj4gPj5zZXJ2aWNlDQo+ID4+ICA+PiA+PmNo YWluaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50IGFz IGEgY2x1c3Rlci4gTm90IGJlY2F1c2UNCj4gPj5jbHVzdGVyDQo+ID4+ICA+PmlzDQo+ID4+ICA+ PiA+PmENCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVz ZSBJIGRvIG5vdCBoYXZlIGFub3RoZXINCj4gPj5vbmUuDQo+ID4+ICA+PiBUaHVzLA0KPiA+PiAg Pj4gPj4gdGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBvaW50IG9mIHR5cGUgMyBs b2FkIGJhbGFuY2luZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRv IGRpZmZlcmVudA0KPiA+PiAgPj4gPj5zaW5ndWxhcg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBvciBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50DQo+ID4+cGxh Y2VzDQo+ID4+ICA+PmluDQo+ID4+ICA+PiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBuZXR3b3JrLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4g SSB0YWxrDQo+ID4+YWJvdXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBj aGFpbiBhbmQgc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluDQo+ID4+aXMgYQ0KPiA+PiAgPj4g Pj4gc2VxdWVuY2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5j dGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldA0KPiA+Pm9mDQo+ID4+ICA+PiA+PnBhY2tl dHMuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5 aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YNCj4gPj4gID4+dHJhZmZpYw0KPiA+PiAgPj4gPj5pcw0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBjaGFyZ2luZywgY29udGVu dCBpbnNwZWN0aW9uLCBhbmQNCj4gPj4gID4+ZmlyZXdhbGwNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5IHRvDQo+ ID4+dGhlDQo+ID4+ICA+PmNhY2hlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0aG91dA0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBm dW5jdGlvbnMuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhl DQo+ID4+ICA+PnBhY2tldHMuDQo+ID4+ICA+PiBBDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+ID4+ ICA+PiA+PmxvY2F0aW9ucw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0 d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUNCj4gPj5zaW5ndWxhciBvcg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBs b2NhdGlvbnMuDQo+ID4+VGhleQ0KPiA+PiAgPj4gPj5tYXkgYmUNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlDQo+IGFkZHJl c3NlZA0KPiA+PmFzDQo+ID4+ICA+PiBwb3J0cw0KPiA+PiAgPj4gPj4gb24NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0 aGF0IHRoZQ0KPiA+PiAgPj4gPj5sb2NhdGlvbnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nDQo+ID4+aW5mcmFzdHJ1Y3R1 cmUNCj4gPj4gID4+IGFuZA0KPiA+PiAgPj4gPj4gdGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHRyYW5zcG9ydC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsg b2YgdGhlIFNGQw0KPiA+PiAgPj5ncm91cCwNCj4gPj4gID4+ID4+IHdlDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRvIGJlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwNCj4gPj50aGUN Cj4gPj4gID4+ID4+c2VydmljZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwg d2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UNCj4gbmVlZA0KPiA+PnRvDQo+ID4+ ICA+PiB0YWxrDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwg ZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluDQo+ID4+dGhlDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2Fp ZCAiYnV0IHRoZQ0KPiB3aG9sZQ0KPiA+PiAgPj4gcGF0aA0KPiA+PiAgPj4gPj4gbWF5DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlz IGFyY2hpdGVjdHVyZQ0KPiA+PmRlYWxzDQo+ID4+ICA+PiA+PndpdGgNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGlu IGl0ZW0NCj4gPj4oMikNCj4gPj4gID4+b24NCj4gPj4gID4+ID4+bG9hZA0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMg YW5kDQo+ID4+ICA+PmJlaGF2aW9ycw0KPiA+PiAgPj4gPj4gd2hpY2gNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KPiA+ Pm1lY2hhbmlzbXMgKGluDQo+ID4+ICA+PiA+Pm11Y2gNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzDQo+ID4+bGFy Z2VseQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gcm91dGluZyBi ZXR3ZWVuIExBTnMuKSBUaGUgb3RoZXINCj4gPj4gID4+IHByb3Zpc2lvbg0KPiA+PiAgPj4gPj4g d2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFrZSBpcw0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVjbGFzc2lmaWNh dGlvbiBjYW4gYmUgZG9uZSBpbiBtaWQtY2hhaW4gd2hlbg0KPiA+PiAgPj4gPj4gbmVjZXNzYXJ5 Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMg dG8gYSBuZXcgY2hhaW4uIEJhc2VkDQo+ID4+b24NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPiA+PiAg Pj5wb2ludC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlDQo+ ID4+YWZ0ZXIuDQo+ID4+ICA+PklmIGl0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRv ZXMsIGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlDQo+ID4+d29ya2luZw0K PiA+PiAgPj4gPj4gZ3JvdXAsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBm aWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUNCj4gPj5uZWVkZWQNCj4gPj4gID4+ IHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29y a2luZyBncm91cCBkaXNhZ3JlZSB3aXRoDQo+ID4+dGhlDQo+ID4+ICA+PiA+PiBpbnRlbnQsDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW4gd2Ugd2lsbCBvZiBjb3Vyc2UgYWRqdXN0 IHRvIG1hdGNoIHRoZQ0KPiA+PndvcmtpbmcNCj4gPj4gID4+ID4+Z3JvdXANCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJ IGFtIG5vdA0KPiA+PnN1cmUNCj4gPj4gID4+ID4+d2hhdCB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiA+PiBzZmMN Cj4gPj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiA+PiBzZmMNCj4gPj4gID4+ ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ICA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAg Pj4gPj4gc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAg Pj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gID4+IHNmYw0KPiA+PiAgPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPiA+PiAgPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+IHNmYw0KPiA+PiAgPj4gPj4gPj4+IG1h aWxpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPiA+PiAgPj4g Pj4gPj4+IG1haWxpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNmYw0KPiA+PiAgPj4gPj4gbWFpbGluZw0KPiA+PiAgPj4g Pj4gPj4+ID4+IGxpc3QNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZyA8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMN Cj4gPj4gID4+ID4+IG1haWxpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gID4+ID4+ID4+PiA+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gID4+ID4+ID4+ PiA+PiA+c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiAgPj4g Pj4gPj4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+ID4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K PiA+PiAgPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+ID4+ICA+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgPj4gPj4gPj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4gPj4gID4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+ICA+PiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4gPj4gID4+ID4+ID4NCj4gPj4gID4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4g Pj4gID4+ID4+ID5zZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiA+ PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4NCj4g Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ ID4+DQoNCg== From nobody Mon Jul 14 08:35:26 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5A31A0A86 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 9V-VUm3AY-L1 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:35:12 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80891A0A91 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:35:12 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 4BA8F53DD2; Mon, 14 Jul 2014 08:35:07 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 08:35:07.256 -0700 x-echoworx-msg-id: 901ad8b7-c38d-4a95-98f5-e30413f0ec0a x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 406; Mon, 14 Jul 2014 08:35:07 -0700 (PDT) Received: from HUB021-CA-7.exch021.domain.local (unknown [10.254.4.109]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 205E053DDD; Mon, 14 Jul 2014 08:35:07 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 08:35:12 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2fdGB3ecdgo20an/XQiFB0eg5ugGT2A//+MLWCAAH0cgP//iwdggAB4EgD//4rtcA== Date: Mon, 14 Jul 2014 15:35:11 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B72EB@MBX021-W3-CA-2.exch021.domain.local> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> <CFE96D52.2E4D6%jguichar@cisco.com> In-Reply-To: <CFE96D52.2E4D6%jguichar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/e-LvYA-Jp_qKHVFU8SSa-A9FDTs Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:35:19 -0000 SmltLA0KDQo+PiAgIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKTogIFRoZSBpbnN0YW50aWF0 aW9uIG9mIGFuIFNGQyBpbiB0aGUNCj4+ICAgICAgICBuZXR3b3JrLiAgUGFja2V0cyBmb2xsb3cg YSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggZnJvbSBhDQo+PiAgICAgICAgY2xhc3NpZmllciB0aHJv dWdoIHRoZSByZXF1aXNpdGUgc2VydmljZSBmdW5jdGlvbnMNCg0KDQpJIGFtIHF1ZXN0aW9uaW5n IHdoZXRoZXIgU0ZQIG5lZWRzIHRvIGV4aXN0IGF0IGFuIGFyY2hpdGVjdHVyYWwgbGV2ZWwgYXQg YWxsLiAgIElmIGl0IGRvZXMgbm90LCB0aGVuIHRoZSBpc3N1ZSBvZiBwcmUtaW5zdGFudGlhdGlv biBpcyBtb290LiAgIEEgc3BlY2lmaWMgcmV3b3JkaW5nIG9mIHRoZSBzbmlwcGV0IGFib3ZlLCBt aW51cyB0aGUgZXhpc3RlbmNlIG9mIFNGUDoNCg0KU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZD KTogIFRoZSBvcmRlcmVkIHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IG11c3QgYmUgaW52 b2tlZCBmb3IgdGhlIGNsYXNzaWZpZWQgZmxvdy4gICBUaGUgZXhhY3QgcGF0aCB0aGF0IHdpbGwg YmUgZm9sbG93ZWQgdGhyb3VnaCB0aGUgbmV0d29yayBmb3IgYSBnaXZlbiBmbG93IGlzIGRldGVy bWluZWQgZHluYW1pY2FsbHkgb24gYW4gU0ZDLWhvcCBieSBTRkMtaG9wIGJhc2lzIHdpdGggdGhl IFNGQyBjbGFzc2lmaWVyIHNlbGVjdGluZyB0aGUgaW5pdGlhbCBTRkYsIHRoZSBpbml0aWFsIFNG RiBzZWxlY3RpbmcgdGhlIG5leHQgU0ZGLCBhbmQgc28gb24sIHdpdGggdGhlIFNGRiBob3N0aW5n IHRoZSBmaW5hbCBTRiBpbiB0aGUgY2hhaW4gdGFraW5nIG9uIHRoZSByb2xlIG9mIHRoZSBTRkMg ZWdyZXNzIG5vZGUuICAgVGhlIGNsYXNzaWZpZXIgYW5kIFNGRidzIFNIT1VMRCBtYWtlIHRoaXMg c2VsZWN0aW9uIHN0YXRlZnVsbHkgc3VjaCB0aGF0IHN1YnNlcXVlbnQgcGFja2V0cyBvZiB0aGUg ZmxvdyBpbnZva2UgdGhlIHNhbWUgU0YgaW5zdGFuY2VzLiAgIElmIHRoZXJlIGlzIGEgZmFpbHVy ZSwgdGhlIHN1cnZpdmluZyBjbGFzc2lmaWVyIGFuZCBTRkYncyBNQVkgbWFrZSBuZXcgc3RhdGVm dWwgc2VsZWN0aW9ucyBmb3IgZXhpc3RpbmcgZmxvd3MuDQoNCg0KICAgUm9uDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWls dG86amd1aWNoYXJAY2lzY28uY29tXSANClNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAxMToy MyBBTQ0KVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IEx1Y3kgeW9uZzsgTkFQ SUVSQUxBLCBNQVJJQSBIOyBYdXhpYW9odTsgbWlrZWJpYW5jQGFvbC5jb207IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IGptaEBqb2VsaGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KDQpNeSBwb2ludCBSb24gaXMgdGhhdCBzZXZlcmFsIHRp bWVzIGl0IGhhcyBiZWVuIGFzc2VydGVkIHRoYXQgdGhlIFNGUCBuZWVkcw0KdG8gYmUgcHJlLWlu c3RhbnRpYXRlZDsgYWdhaW4sIHdoZXJlIGRvZXMgaXQgc2F5IHRoYXQgYXMgSSBjYW7igJl0IHNl ZSBpdD8NCg0KT24gNy8xNC8xNCwgMTE6MTkgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCj5KaW0sDQo+DQo+SSBhbSBub3Qgd29yZHNt aXRoaW5nIGhlcmUsIGJ1dCByYXRoZXIgcXVlc3Rpb25pbmcgc29tZSBmdW5kYW1lbnRhbA0KPmFz c3VtcHRpb25zLg0KPg0KPlRoZSB2ZXJ5IGV4aXN0ZW5jZSBvZiB0aGUgc2VydmljZSBmdW5jdGlv biBwYXRoIGNvbmNlcHQgaXMgZnVuZGFtZW50YWwgdG8NCj50aGUgYXJjaGl0ZWN0dXJlLiAgICBB cyBhbiBhbmFsb2d5LCBpbiBhIHRyYWRpdGlvbmFsIEwzIHJvdXRlZCBuZXR3b3JrDQo+KGV4Y2Vw dGluZyBvYnNjdXJlIHNvdXJjZSByb3V0aW5nIG9wdGlvbnMpLCBvbmUgY291bGQgc3RpbGwgb2Jz ZXJ2ZSB0aGF0DQo+YSBwYXJ0aWN1bGFyIGZsb3cgaXMgZm9sbG93aW5nIGEgcGFydGljdWxhciBw YXRoIHRocm91Z2ggdGhlIG5ldHdvcmssIGJ1dA0KPnRoYXQgaXMgaW5jaWRlbnRhbCB0byB0aGUg YXJjaGl0ZWN0dXJlIHJhdGhlciB0aGFuIGZ1bmRhbWVudGFsIHRvIHRoZQ0KPmFyY2hpdGVjdHVy ZS4NCj4NCj4gICBSb24NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPlNl bnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAxMToxMiBBTQ0KPlRvOiBSb24gUGFya2VyOyBKb2Vs IEhhbHBlcm4gRGlyZWN0OyBMdWN5IHlvbmc7IE5BUElFUkFMQSwgTUFSSUEgSDsNCj5YdXhpYW9o dTsgbWlrZWJpYW5jQGFvbC5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+am1o QGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtzZmNdIFJlZGVm aW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+QmFsYW5j ZXJzDQo+DQo+UXVlc3Rpb246IHdoZXJlIGV4YWN0bHkgZG9lcyBpdCBzcGVjaWZ5IHRoYXQgdGhl IFNGUCAqbXVzdCogYmUNCj5wcmUtaW5zdGFudGlhdGVkPyBXaGF0IGV4YWN0bHkgaXMgd3Jvbmcg d2l0aCB0aGUgd29yZGluZyDigJxXaGVuIGFuIFNGQyBpcw0KPmluc3RhbnRpYXRlZCBpbnRvIHRo ZSBuZXR3b3JrIGl0IGlzIG5lY2Vzc2FyeSB0byBzZWxlY3QgdGhlIHNwZWNpZmljDQo+aW5zdGFu Y2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZSB0aGUgc2VydmljZSB0 b3BvbG9neSBmb3INCj50aGF0IFNGQyB1c2luZyBTRuKAmXMgbmV0d29yayBsb2NhdG9yc+KAnT8g TGV04oCZcyB0cnkgdG8gYmUgc3BlY2lmaWMgcmF0aGVyDQo+dGhhbiBkYW5jaW5nIGFyb3VuZCB0 aGUgd29yZGluZy4NCj4NCj5PbiA3LzE0LzE0LCAxMTowMCBBTSwgIlJvbiBQYXJrZXIiIDxSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPg0KPndyb3RlOg0KPg0KPj5IaSwgSm9lbCwNCj4+ DQo+PkkgcXVvdGUgZnJvbSB0aGUgdGhlIG1lcmdlZCBhcmNoaXRlY3R1cmUgZHJhZnQ6DQo+Pg0K Pj48YmVnaW4gcXVvdGF0aW9uPg0KPj5TZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpOiAgQSBz ZXJ2aWNlIEZ1bmN0aW9uIGNoYWluIGRlZmluZXMgYW4NCj4+ICAgICAgICBvcmRlcmVkIHNldCBv ZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IG11c3QgYmUgYXBwbGllZCB0byBwYWNrZXRzDQo+PiAg ICAgICAgYW5kL29yIGZyYW1lcyBzZWxlY3RlZCBhcyBhIHJlc3VsdCBvZiBjbGFzc2lmaWNhdGlv bi4gIFRoZQ0KPj4gICAgICAgIGltcGxpZWQgb3JkZXIgbWF5IG5vdCBiZSBhIGxpbmVhciBwcm9n cmVzc2lvbiBhcyB0aGUNCj4+ICAgICAgICBhcmNoaXRlY3R1cmUgYWxsb3dzIGZvciBub2RlcyB0 aGF0IGNvcHkgdG8gbW9yZSB0aGFuIG9uZSBicmFuY2guDQo+PiAgICAgICAgVGhlIHRlcm0gc2Vy dmljZSBjaGFpbiBpcyBvZnRlbiB1c2VkIGFzIHNob3J0aGFuZCBmb3Igc2VydmljZQ0KPj4gICAg ICAgIGZ1bmN0aW9uIGNoYWluLg0KPj4NCj4+ICAgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlAp OiAgVGhlIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZQ0KPj4gICAgICAgIG5ldHdvcmsu ICBQYWNrZXRzIGZvbGxvdyBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBmcm9tIGENCj4+ICAgICAg ICBjbGFzc2lmaWVyIHRocm91Z2ggdGhlIHJlcXVpc2l0ZSBzZXJ2aWNlIGZ1bmN0aW9ucw0KPj4N Cj4+V2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMgbmVj ZXNzYXJ5IHRvDQo+PiAgIHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0 IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZQ0KPj4gICB0aGUgc2VydmljZSB0b3BvbG9neSBm b3IgdGhhdCBTRkMgdXNpbmcgU0YncyBuZXR3b3JrIGxvY2F0b3IuICBUaHVzLA0KPj4gICBpbnN0 YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUgY3JlYXRpb24gb2YgYSBTZXJ2aWNl DQo+PiAgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3IgZm9yd2FyZGluZyBwYWNr ZXRzIHRocm91Z2ggdGhlDQo+PiAgIFNGQy4gIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhl IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4NCj4+KFNlY3Rpb24gNC4zIFNG RikNCj4+U0ZQIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2Vy dmljZSBwYXRoIGlkZW50aWZpZXINCj4+ICAgdGhhdCBpcyB1c2VkIHRvIHVuaXF1ZWx5IGlkZW50 aWZ5IGFuIFNGUC4NCj4+PGVuZCBxdW90YXRpb24+DQo+Pg0KPj4NCj4+TXkgcmVhZGluZyBvZiB0 aGUgU2VjdGlvbiA0LjMsIGdpdmVuIHRoZSBkZWZpbml0aW9ucyBwcmVzZW50ZWQgYmVmb3JlIGl0 LA0KPj5pcyB0aGF0IGFuIGVuZC10by1lbmQgZnVsbHkgaW5zdGFudGlhdGVkIHBhdGggaXMgc2Vs ZWN0ZWQgYW5kIHRoZW4gdXNlZA0KPj50byBzdGVlciB0cmFmZmljIHRvIHRoZSByZXF1aXNpdGUg U0ZGJ3MgYW5kIFNGJ3MuICAgV2hpbGUgdGhvc2UNCj4+ZGVmaW5pdGlvbnMgY291bGQgc3RpbGwg YXBwbHksIGV2ZW4gaW4gYSBkaXN0cmlidXRlZCBpbnN0YW5jZSBhc3NpZ25tZW50DQo+PmFwcHJv YWNoLCB0aGUgY29udGV4dCBhcm91bmQgdGhvc2UgZGVmaW5pdGlvbnMgY2hhbmdlLiAgIEEgcGFy dGljdWxhcg0KPj5mbG93IHdvdWxkLCBpbmRlZWQgc3RpbGwgZm9sbG93IHNvbWUgcGFydGljdWxh ciBwYXRoLCBidXQgdGhlcmUgd291bGQgYmUNCj4+bm8gbmVlZCB0byBhc3NvY2lhdGUgYSBwYXRo IElEIHRvIGl0IGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvDQo+PihsYXRlcikgYnVpbGQg YSBjb250cm9sIHBsYW5lIGFyb3VuZCBkaXN0cmlidXRpb24gb2YgdGhpcyBwYXRoIElEIGFuZA0K Pj5tYWludGVuYW5jZSBvZiB0aG9zZSBwYXRoIElEcyBpbiB0aGUgZmFjZSBvZiBpbmV2aXRhYmxl IGZhaWx1cmVzLg0KPj4NCj4+SSBhbSBleHBsb3JpbmcgdGhlIGFsdGVybmF0aXZlIHdoZXJlIGZv cndhcmRpbmcgaXMgcGVyZm9ybWVkIGJhc2VkIG9uIHRoZQ0KPj5hYnN0cmFjdCBTRkMgSUQgd2l0 aG91dCByZXF1aXJpbmcgdGhlIGNvbmNlcHQgb2YgYSBjZW50cmFsbHkga25vd24gU0ZQIHRvDQo+ PmV4aXN0IGF0IGFsbC4gICBJbiB0aGlzIGFsdGVybmF0aXZlIGFwcHJvYWNoLCB0aGUgaW5zdGFu Y2Ugc2VsZWN0aW9uIGlzDQo+PmRpc3RyaWJ1dGVkIHRvIHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUg U0ZGJ3MuICAgQW55IGRlc2lyZWQgcG9saWN5IHVzZWQgdG8NCj4+Zmxhdm9yIGluc3RhbmNlIHNl bGVjdGlvbiBpcyBzdGlsbCBzdXBwb3J0ZWQsIGJ1dCBzdWNoIHBvbGljeSB3b3VsZCwNCj4+aW5k ZWVkLCBuZWVkIHRvIGJlIGF2YWlsYWJsZSB0byB0aGUgaW52b2x2ZWQgZW50aXRpZXMuICAgVGhp cyB3b3VsZCBhbHNvDQo+PmJlIGFuIGV4Y2VsbGVudCB1c2Ugb2YgbWV0YWRhdGEgd2hlcmUgdGhl IGluaXRpYWwgaW5ncmVzcyBub2RlIGNvdWxkIGFkZA0KPj5vbmUgb3IgbW9yZSBwaWVjZXMgb2Yg bWV0YWRhdGEgdGhhdCBkb3duc3RyZWFtIG5vZGVzIGNvdWxkIG1ha2UgdXNlIG9mIGluDQo+PnRo ZWlyIHBvbGljeSBkZWNpc2lvbnMuDQo+Pg0KPj4gICAgUm9uDQo+Pg0KPj4NCj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbbWFpbHRvOmpt aC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXQ0KPj5TZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQg MTA6MzkgQU0NCj4+VG86IEx1Y3kgeW9uZzsgTkFQSUVSQUxBLCBNQVJJQSBIOyBSb24gUGFya2Vy OyBYdXhpYW9odTsNCj4+bWlrZWJpYW5jQGFvbC5jb207IGpndWljaGFyQGNpc2NvLmNvbTsgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsNCj4+am1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGll dGYub3JnDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj5CYWxhbmNlcnMNCj4+DQo+PkNhbiB3ZSBmaXJz dCBmaWd1cmUgb3V0IHdoYXQgd2UgbWVhbiBieSBhIHNlcnZpY2UgcGF0aD8NCj4+T25jZSB3ZSBo YXZlIHRoYXQsIEkgYmVsaWV2ZSB3ZSBjYW4gd29yayBvdXQgd2hhdCB3ZSB3YW50IHRoZQ0KPj5h cmNoaXRlY3R1cmUgdG8gcmVxdWlyZSBvZiBzb2x1dGlvbnMgaW4gdGVybXMgb2YgY2Fycnlpbmcg aW5mb3JtYXRpb24gaW4NCj4+dGhlIHBhY2tldC4gIEJ1dCBzaW5jZSBmb2xrcyBoYXZlIGJlZW4g cmVhZGluZyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbnMNCj4+YW5kIGNvbWluZyB0byBkaWZmZXJl bnQgbWVhbmluZ3MsIGFuZCBoYXZlIGJlZW4gbm90aW5nIGNvcnJlY3RseQ0KPj5jb250cmFkaWN0 aW9ucyBpbiB0aGUgd29yZHMgd2UgY2hvc2UgZm9yIHRoZSBleGlzdGluZyBkZWZpbml0aW9uLCBJ DQo+PndvdWxkIHJlYWxseSBhcHByZWNpYXRlZCBpdCBpZiBmb2xrcyB3b3VsZCBjb21tZW50IG9u IHRoZSBkZWZpbml0aW9uIG9mDQo+PnNlcnZpY2UgZnVuY3Rpb24gcGF0aCB0aGF0IEkgc2VudCB0 byB0aGUgbGlzdC4NCj4+DQo+PllvdXJzLA0KPj5Kb2VsDQo+Pg0KPj5PbiA3LzE0LzE0LCA5OjMw IEFNLCBMdWN5IHlvbmcgd3JvdGU6DQo+Pj4gQ29ucXVlciB3aGF0IE1hcmlhIHNheXMuDQo+Pj4N Cj4+PiBMdWN5DQo+Pj4NCj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddICpPbiBCZWhhbGYgT2YgKk5BUElFUkFMQSwNCj4+Pk1BUklBIEgNCj4+PiAqU2VudDoqIE1v bmRheSwgSnVseSAxNCwgMjAxNCA4OjIxIEFNDQo+Pj4gKlRvOiogUm9uIFBhcmtlcjsgWHV4aWFv aHU7IG1pa2ViaWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207DQo+Pj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnDQo+ Pj4gKlN1YmplY3Q6KiBSZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kDQo+Pj4gTG9hZCBCYWxhbmNlcnMNCj4+Pg0KPj4+IFRoZSBtZWFuaW5n IG9mIHRoZSBTRlAgSUQgaXMgcHJldHR5IGNsZWFyLCBhdCBsZWFzdCB0byBtZSDigJMgYW4gYWJz dHJhY3QNCj4+PiBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9u IGluc3RhbmNlcyAoaS5lLiwgU0ZQIElEDQo+Pj4xDQo+Pj4gPSB7U0YtQS0xLCBTRi1CLTMsIFNG LUMtMn0pLiAgICBJbiBzb21lIHdheXMsIGl0IGlzIGEgY29sbGFwc2VkIOKAnGxhYmVsDQo+Pj4g c3RhY2vigJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNl IG9mIG5ldHdvcmsNCj4+PiBsb2NhdGlvbnMuICAgQnV0LCB0aGlzIGFsc28gaW1wbGllcywgYXQg bGVhc3QgdG8gbWUsIHRoYXQgdGhlcmUgaXMgYQ0KPj4+IGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0 aW9uIGZvciB0aGlzIGVuZCB0byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcNCj4+PiByZWNsYXNzaWZp Y2F0aW9uLCBvZiBjb3Vyc2UpLiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQNCj4+ PiBpbXBsaWNhdGlvbi4gICAgSSBoYXZlIGJlZW4gdW5jb21mb3J0YWJsZSB3aXRoIHRoYXQgY2Vu dHJhbCBwb2ludA0KPj4+IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdvcmxkIGNvbXBsZXhpdGll cyBvZiBkeW5hbWljIHNjYWxlIGFuZA0KPj4+IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFp bHVyZXMuDQo+Pj4NCj4+PiA8TWFyaWE+IEkgYWdyZWUuIEl0IHNob3VsZCBub3QgYmUgbWFuZGF0 ZWQgYnkgdGhlIFNGQyBhcmNoaXRlY3R1cmUgdGhhdA0KPj4+IHNvbWV0aGluZyBjYWxsZWQg4oCc c2VydmljZSBmdW5jdGlvbiBwYXRoIElE4oCdIGlzIGNhcnJpZWQgaW4gdGhlIHBhY2tldCwNCj4+ PiBiZWNhdXNlIGl0IGlzIG5vdCBuZWNlc3Nhcnkgb3IgdGhlIG9ubHkgd2F5IHRvIGltcGxlbWVu dCBzZXJ2aWNlDQo+Pj4gY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxk IGRvIHRoYXQgYnV0IGl0IGNhbm5vdCBhbmQNCj4+PiBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5k YXRlZC4NCj4+Pg0KPj4+IE1hcmlhDQo+Pj4NCj4+PiBBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCBp cyB0byBzdGlsbCB1c2UgY2VudHJhbCBzZWxlY3Rpb24gdG8gc2VsZWN0IHRoZQ0KPj4+IGNoYWlu IG9mIGFic3RyYWN0IHNlcnZpY2UgZnVuY3Rpb25zIChpLmUuLCBTRkMgSUQgMSA9IHtTRi1BLCBT Ri1CLA0KPj4+IFNGLUN9KSwgYnV0IGFsbG93IHRoZSBhY3R1YWwgaW5zdGFuY2Ugc2VsZWN0aW9u IHRvIGJlIGRpc3RyaWJ1dGVkLA0KPj4+IHJlYWxpemVkIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCB0 aGUgU0ZGcy4NCj4+Pg0KPj4+IEdpdmVuIGEgdG9wb2xvZ3kgbGlrZToNCj4+Pg0KPj4+IENsYXNz aWZpZXIgLS0tLS0tLSAgU0ZGLTEgLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTINCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0tLS0tLS0tLS0tLS0tLS1TRkYtNA0KPj4+DQo+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfA0KPj4+ICAgICAgICAg ICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+PiB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pg0KPj4+ICAgICAgICAgICAgICAg ICAgICAgIFNGRi1BLTEgICAgICAgU0ZGLUEtMiAgICAgICBTU0YtQi0xDQo+Pj4gU0ZGLUItMiAg ICAgICAgIFNGRi1DLTEgICAgICAgU0ZGLUMtMiAgICAgICAgICAgICAgICAgICBTRkYtQS0zDQo+ Pj4NCj4+PiBBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5j ZSBjb3VsZCBnbyBzb21ldGhpbmcNCj4+PiBsaWtlIHRoaXM6DQo+Pj4NCj4+PiAxIENsYXNzaWZp ZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwgU0YtQiwgU0YtQ30NCj4+Pg0KPj4+IDIg Q2xhc3NpZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNl IG9mIFNGLUENCj4+Pg0KPj4+IDMgQ2xhc3NpZmllciBlbmNhcHN1bGF0ZXMgcGFja2V0IGluZGlj YXRpbmcgY2hhaW4gSUQgPSAxLCBzZXJ2aWNlIGluZGV4DQo+Pj49IDENCj4+Pg0KPj4+IDQgQ2xh c3NpZmllciBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMQ0KPj4+DQo+Pj4gNSBTRkYtMSwgc2Vl aW5nIGNoYWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3QN Cj4+Pml0cw0KPj4+IGF2YWlsYWJsZSBpbnN0YW5jZXMgb2YgU0YtQQ0KPj4+DQo+Pj4gNiBTRkYt MSBzZW5kcyBwYWNrZXQgdG8gU0ZGLUEtMQ0KPj4+DQo+Pj4gNyBTRkYtQS0xIHNlbmRzIHBhY2tl dCBiYWNrIHRvIFNGRi0xDQo+Pj4NCj4+PiA4IFNGRi0xIGluY3JlbWVudHMgc2VydmljZSBpbmRl eCB0byAyDQo+Pj4NCj4+PiA4IFNGRi0xIHNlbGVjdHMgU0ZGLTIgYXMgaG9zdGluZyBhdCBsZWFz dCBvbmUgaW5zdGFuY2Ugb2YgU0YtQg0KPj4+DQo+Pj4gOSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tl dCB0byBTRkYtMg0KPj4+DQo+Pj4gMTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBT RkYtMywgYXMgdGhlIGVncmVzcyBib3JkZXIsDQo+Pj4gcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBl ciByb3V0aW5nIHRhYmxlDQo+Pj4NCj4+PiBUaGFua3MuDQo+Pj4NCj4+PiAgICAgUm9uDQo+Pj4N Cj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYg T2YgKlh1eGlhb2h1DQo+Pj4gKlNlbnQ6KiBTdW5kYXksIEp1bHkgMTMsIDIwMTQgMTE6MzAgUE0N Cj4+PiAqVG86KiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsg amd1aWNoYXJAY2lzY28uY29tDQo+Pj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5 MjFAYXR0LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsNCj4+PiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47DQo+Pj4g am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBSb24gUGFy a2VyOw0KPj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAqU3ViamVj dDoqIFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkDQo+Pj4gQmFsYW5jZXJzDQo+Pj4NCj4+PiBBZ3JlZSB0aGF0IHRoZSBjdXJyZW50IGRl ZmluaXRpb24gb2YgdGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJpdA0KPj4+Y29uZnVz aW5nLCBqdXN0IGFzIHdoYXQgeW91IGhhZCBwb2ludGVkIG91dC4NCj4+Pg0KPj4+DQo+Pj4NCj4+ PiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4g U0ZDIGluIHRoZQ0KPj4+bmV0d29yayBzaG91bGQgYmUg4oCcYW4gb3JkZXJlZCBsaXN0IG9mIHNl cnZpY2Ugbm9kZXMgYW5kIFNGIElEc+KAnShzZWUNCj4+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEpLiBPZg0KPj4+Y291cnNl LCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4gdGhlIGRhdGEgcGFja2V0IGlzIGFub3RoZXIg dGhpbmcNCj4+PihlLmcuLCBlaXRoZXIgdGhyb3VnaCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBN UExTIGxhYmVsIHN0YWNrKS4gSGVyZQ0KPj4+dGhlIHNlcnZpY2Ugbm9kZSBtZWFucyB0aGUgZGV2 aWNlIHdoaWNoIGNvbnRhaW5zIHRoZSBTRkYgYW5kIHRoZSBORg0KPj4+Y29tcG9uZW50cyBtYW5k YXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBhbmQgU0YgcHJveHkgY29tcG9uZW50cw0K Pj4+b3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBiZSBhdHRhY2hlZCBvciBlbWJl ZGRlZCB3aXRoIG11bHRpcGxlDQo+Pj5TRiBpbnN0YW5jZXMgYW5kIHRob3NlIFNGIGluc3RhbmNl cyBjb3VsZCBiZSBvZiB0aGUgc2FtZSBTRiB0eXBlIG9yIG5vdC4NCj4+PiBJbiB0aGUgY2FzZSB3 aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNGIHR5cGUN Cj4+PihlLmcuLCBTRiBYKSBhcmUgYXR0YWNoZWQgdG8gYSBnaXZlbiBzZXJ2aWNlIG5vZGUsIHRo ZSBzZXJ2aWNlIG5vZGUNCj4+PmNvdWxkIGRpc3RyaWJ1dGUgdGhlIHRyYWZmaWMgd2hpY2ggbmVl ZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBpbnN0YW5jZXMNCj4+Pm9mIFNGIFggdHlwZSBsb2NhbGx5 LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzDQo+Pj53aXRo aW4gYSBnaXZlbiBTRkMtZW5hYmxlZCBkb21haW4gd2hpY2ggYXJlIGVtYmVkZGVkIG9yIGF0dGFj aGVkIHdpdGgNCj4+PnRoZSBTRg0KPj4gIGluc3RhbmNlDQo+PnMgb2YgdGhlIHNhbWUgU0YgdHlw ZS4gSW4gdGhpcyB3YXksIHRoZSBTRiBsb2FkLWJhbGFuY2luZyB3b3VsZCBiZSBtYWRlDQo+PnZl cnkgZmxleGlibGUuDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4NCj4+PiBYaWFvaHUNCj4+ Pg0KPj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFs ZiBPZg0KPj4+ICptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0K Pj4+ICpTZW50OiogU2F0dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTQ0KPj4+ICpUbzoqIGpn dWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT47IG1uMTkyMUBhdHQu Y29tDQo+Pj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBqbWhAam9l bGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbT47IHNmY0BpZXRmLm9yZw0KPj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4g KlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4+Pg0KPj4+IFdvdWxkbid0IHRoYXQgYmUgY2FsbGVkIHRoZSAic2VydmljZSBjaGFp biBpZGVudGlmaWVyIiB0aGVuPyAgSWYgdGhlDQo+Pj4gc2VydmljZSBjaGFpbiBpcyB0aGUgb3Jk ZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUNCj4+PiBvcmRlcmVk IGxpc3Qgb2YgU0YgaW5zdGFuY2VzLCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICJzZXJ2aWNl IHBhdGgNCj4+PiBpZGVudGlmaWVyIiB3b3VsZCBiZSBhbiBpZGVudGlmaWVyIGZvciBhIHNlcnZp Y2UgKnBhdGgqLCBub3QgYSBzZXJ2aWNlDQo+Pj4gKmNoYWluKi4NCj4+Pg0KPj4+DQo+Pj4gQWdh aW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGlu LiAgVGhlDQo+Pj50ZXJtcw0KPj4+ICJjaGFpbiIgYW5kICJwYXRoIiBzZWVtIGluY29uc2lzdGVu dC4NCj4+Pg0KPj4+IA0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiAqRnJvbTogKmpndWlj aGFyQGNpc2NvLmNvbTxqZ3VpY2hhckBjaXNjby5jb20NCj4+PiA8bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbT4+DQo+Pj4gKlRvOg0KPj4+IA0KPj4+Km1pa2Vi aWFuY0Bhb2wuY29tPG1pa2ViaWFuY0Bhb2wuY29tPixtbjE5MjFAYXR0LmNvbTxtbjE5MjFAYXR0 LmNvbT4sbW9oDQo+Pj5hDQo+Pj5tZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4sam1oQGpvZWxoYWxwZXJuLmMNCj4+Pm8NCj4+Pm08am1oQGpvZWxo YWxwZXJuLmNvbT4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxSb25fUGFya2VyQGFm ZmlybQ0KPj4+ZQ0KPj4+ZG5ldHdvcmtzLmNvbT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0K Pj4+IA0KPj4+PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFuY0Bhb2wuY29tJTNl LG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxDQo+Pj5ADQo+Pj5hdHQuY29tJTNlLG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTMNCj4+PmUN Cj4+PixqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZSxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29yaw0KPj4+cw0KPj4+LmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20lM2Usc2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4NCj4+PiAqU2VudDog KkZyaWRheSwgSnVseSAxMSwgMjAxNA0KPj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4NCj4+PiBZb3VyIGRlZmluaXRp b24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBhdGgN Cj4+PiB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBhY3R1YWxseSBmbG93LiBUaGUgc2Vydmlj ZSBwYXRoIGlkZW50aWZpZXINCj4+PiBob3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZSBjaGFp biBkYXRhIHN0cnVjdHVyZSBhbmQgdGhhdCBpcyB0aGVuDQo+Pj4gcmVzb2x2ZWQgdG8gc3BlY2lm aWMgaW5zdGFuY2VzIGJhc2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlDQo+Pj4gaW5z dGFuY2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVyIGxvYWQgZGlzdHJpYnV0aW9uIHRlY2hu aXF1ZSBpcyBpbg0KPj4+IHBsYXkuIFdoZW4gaW5zdGFudGlhdGluZyB0aGUgc2VydmljZSBjaGFp biBpbnRvIHRoZSBuZXR3b3JrIHlvdSBtYXkgb3INCj4+PiBtYXkgbm90IHVwZGF0ZSB0aGF0IGRh dGEgc3RydWN0dXJlIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBiZQ0KPj4+IHVzZWQg KHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxkIGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNl cnZpY2UNCj4+PnBhdGgNCj4+PiBmb3IgdGhhdCBzZXJ2aWNlIGNoYWluKSBvciB5b3UgbWF5IHNp bXBseSBhbGxvdyBzb21lIG90aGVyIHByb3RvY29sIC8NCj4+PiBtZWNoYW5pc20gdG8gcG9wdWxh dGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQo+Pj4NCj4+PiAqRnJvbTogKiJtaWtlYmlh bmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiINCj4+PiA8bWlrZWJpYW5jQGFv bC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQo+Pj4gKkRhdGU6ICpGcmlkYXksIEp1 bHkgMTEsIDIwMTQgYXQgMTI6MTggUE0NCj4+PiAqVG86ICpKaW0gR3VpY2hhcmQgPGpndWljaGFy QGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+LA0KPj4+ICJtbjE5MjFAYXR0 LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTkyMUBhdHQuY29tDQo+Pj4gPG1haWx0 bzptbjE5MjFAYXR0LmNvbT4+LCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sICJq bWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGpt aEBqb2VsaGFscGVybi5jb20NCj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+Ig0KPj4+IDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t DQo+Pj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sICJzZmNAaWV0 Zi5vcmcNCj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KPj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4NCj4+PiBJIHRoaW5rIHRoaXMgaXMgdGhlIHJv b3Qgb2YgdGhlIGNvbmZ1c2lvbjoNCj4+Pg0KPj4+PiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5 DQo+Pj4+IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21i aW5hdGlvbiB0aGVyZW9mKS4gSQ0KPj4+PiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmll ciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvDQo+Pj4+UzEtPlMyLT5TMw0KPj4+ PiBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KPj4+DQo+Pj4gQnkgZGVmaW5p dGlvbiwgSSB1bmRlcnN0b29kIGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJlZCBsaXN0 IG9mDQo+Pj4gc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5 b3UgdXNlIGEgInNlcnZpY2UgcGF0aA0KPj4+IGlkZW50aWZpZXIiIHRvIHJlZmVyIHRvIGEgc2Vy dmljZSAqY2hhaW4qIHRoYXQgc3BlY2lmaWNhbGx5ICJbZG9lcyBub3RdDQo+Pj4gc3BlY2lmeSBz cGVjaWZpYyBpbnN0YW5jZXMiLg0KPj4+DQo+Pj4gDQo+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pg0K Pj4+ICpGcm9tOiAqamd1aWNoYXJAY2lzY28uY29tDQo+Pj4gPG1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20+PGpndWljaGFyQGNpc2NvLmNvbQ0KPj4+PG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+ Pg0KPj4+ICpUbzogKk5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbQ0KPj4+IDxtYWls dG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tDQo+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sSm9lbCBN Lg0KPj4+IEhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PixSb24NCj4+PiBQYXJrZXI8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0K Pj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LHNmY0BpZXRmLm9y Zw0KPj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0 Zi5vcmc+Pg0KPj4+ICpTZW50OiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0DQo+Pj4gKlN1YmplY3Q6 ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ Pg0KPj4+IE1hcmlhLA0KPj4+DQo+Pj4gSSB0aGluayBvZiBpdCB0aGlzIHdheS4gVGhlIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50ZXINCj4+PnRvDQo+Pj4gYSBkYXRh IHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5leHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlv dSBkZWZpbmUNCj4+PmENCj4+PiBjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3Ug Km1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlANCj4+PnNwZWNpZnkNCj4+PiB0aGUgc3BlY2lm aWMgbmV4dC1ob3BzIHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91Z2ggZm9yIHRo YXQNCj4+PlNGUC4NCj4+PiBIb3dldmVyLCB5b3UgZG8gKm5vdCogaGF2ZSB0byBkbyB0aGlzIGZy b20gYW4gYXJjaGl0ZWN0dXJhbCBzdGFuZHBvaW50DQo+Pj4oSQ0KPj4+IHdpbGwgYXJndWUgdGhh dCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlv dQ0KPj4+IGNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBw b2ludCB0byBhIGdpdmVuIFNGQw0KPj4+YW5kDQo+Pj4gdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRp b24gaW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0KPj4+IHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQg Y29udGFpbg0KPj4+dGhlDQo+Pj4gbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUg U0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KPj4+IHRob3NlIG5leHQtaG9w cyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNoIHRoZW0gZG93biBmcm9tIGENCj4+PmNlbnRy YWxpemVkDQo+Pj4gY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJu IHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0KPj4+IHNvbWUgcHJvdG9jb2wgZXhjaGFuZ2UsIHdo YXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3JyZWN0IHRvDQo+Pj4gc2F5IHRo YXQgdGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3Nl biBhDQo+Pj5wcmlvcmkNCj4+PiBhbHRob3VnaCBpdCBpcyBwZXJmZWN0bHkgYWNjZXB0YWJsZSAo YW5kIHNvbWUgd291bGQgc2F5IHJlY29tbWVuZGVkKSB0bw0KPj4+ZG8NCj4+PiBzby4NCj4+Pg0K Pj4+IExldOKAmXMgdGFrZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6 DQo+Pj4NCj4+PiBJIGRlZmluZSBhbiBTRkMgKGxldOKAmXMgcmVmZXIgdG8gaXQgYXMgU0ZDLTEp IFMxLT5TMi0+UzMuIEZvciBhcmd1bWVudHMNCj4+PiBzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBp dCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8NCj4+PnNwZWNpZnkN Cj4+PiBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmlu YXRpb24gdGhlcmVvZikuIEkNCj4+PiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDi gJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvDQo+Pj5TMS0+UzItPlMzDQo+Pj4gYW5k IHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRhdGEgc3Ry dWN0dXJlcyBhcmUNCj4+PiBwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQg YSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYw0KPj4+YXJyaXZlcw0KPj4+IHdpdGggc2VydmljZSBw YXRoIGlkZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRh DQo+Pj4gc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5k IHRoZSBpbmRleCBpbiB0aGUNCj4+PlNGQw0KPj4+IGVuY2Fwc3VsYXRpb24gd2lsbCB0ZWxsIGl0 IGV4YWN0bHkgd2hlcmUgaXQgaXMgaW4gdGhlIGNoYWluLiBMZXTigJlzIHNheQ0KPj4+d2UNCj4+ PiBhcmUgYXQgUzIgaW4gdGhlIGNoYWluLiBUaGUgU0ZGIHdpbGwgbm93IGhhdmUgdG8gcmVzb2x2 ZSB0aGUgbmV4dC1ob3ANCj4+PnRvDQo+Pj4gUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0 ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCj4+Pg0KPj4+IE9uIDcvMTEvMTQsIDExOjI2 IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+PiA8bWFpbHRvOm1u MTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+Pj4NCj4+PiAgPkppbSwNCj4+PiAgPg0KPj4+ICA+Q291 bGQgeW91IHRlbGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICJzZXJ2aWNlIHBhdGgi IGFuZCBhDQo+Pj4gID4ic2VydmljZSBwYXRoIGlkZW50aWZpZXIiPw0KPj4+ICA+SWYgYSBzZXJ2 aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYXByaW9yaQ0K Pj4+KHdoaWNoDQo+Pj4gID5pcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcpIHRoZW4gaXQgaXMg bm90IFNGRidzIGxvY2FsIGRlY2lzaW9uDQo+Pj53aGljaA0KPj4+ICA+bmV4dC1ob3AgU0ZGIHRv IHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uDQo+Pj4gID4NCj4+PiAgPk1hcmlh DQo+Pj4gID4NCj4+PiAgPg0KPj4+ICA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ ICA+Pg0KPj4+DQo+Pj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb21dDQo+Pj4gID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMTox NSBBTQ0KPj4+ICA+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9l bCBNLg0KPj4+ICA+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+Pj4gID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ICA+Pg0KPj4+ICA+PiBJ4oCZbSBzb3JyeSBi dXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBhIHNlcnZpY2UgcGF0aA0KPj4+aWRl bnRpZmllcg0KPj4+ICA+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhv cHMgb3Igd2h5IGNhbGxpbmcgaXQgYQ0KPj4+c2VydmljZQ0KPj4+ICA+PiBjaGFpbiBpZGVudGlm aWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPw0KPj4+ICA+Pg0KPj4+ICA+PiBPbiA3LzExLzE0LCAx MDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tDQo+Pj4gPG1haWx0 bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPj4+ICA+Pg0KPj4+ICA+PiA+RGl0dG8uDQo+Pj4g ID4+ID4NCj4+PiAgPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiAgPj4gPj4g RnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IDxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+PiAgPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tXQ0KPj4+ICA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6 MzEgQU0NCj4+PiAgPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEs IE1BUklBIEg7IEpvZWwgTS4NCj4+PkhhbHBlcm47IFJvbg0KPj4+ICA+PiA+PiBQYXJrZXI7IHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4gPj4gU3ViamVjdDogUkU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gID4+ ID4+DQo+Pj4gID4+ID4+IFJlLSwNCj4+PiAgPj4gPj4NCj4+PiAgPj4gPj4gRm9yIHdoYXQgSSBj YW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNsZWFybHkgaW4gdGhlDQo+Pj4g ID4+ZHJhZnQuDQo+Pj4gID4+ID4+DQo+Pj4gID4+ID4+IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUNCj4+PmZ1bGwNCj4+PiAg Pj4gPj5kaXN0cmlidXRlZA0KPj4+ICA+PiA+PiBtb2RlbCBpcyBub3QgYWxsb3dlZC4NCj4+PiAg Pj4gPj4NCj4+PiAgPj4gPj4gU2V2ZXJhbCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVk IHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4NCj4+Pml0c2VsZg0KPj4+ICA+PiA+PnNob3VsZCBiZQ0K Pj4+ICA+PiA+PiBwcm92aWRlZCBpbnN0ZWFkLg0KPj4+ICA+PiA+Pg0KPj4+ICA+PiA+PiBDaGVl cnMsDQo+Pj4gID4+ID4+IE1lZA0KPj4+ICA+PiA+Pg0KPj4+ICA+PiA+PiA+LS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+Pj4gID4+ID4+ID5EZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEppbQ0KPj4+R3VpY2hhcmQNCj4+PiAgPj4gPj4gPihq Z3VpY2hhcikNCj4+PiAgPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQg MTY6MTgNCj4+PiAgPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBl cm47IFJvbiBQYXJrZXI7DQo+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4+ICA+PiA+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4+PiAgPj4gPj4gPg0KPj4+ICA+PiA+PiA+T2sgYnV0IHdoZXJlIGlu IHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMNCj4+PmZ1bmN0aW9uYWxpdHkN Cj4+PiAgPj4gPj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCog bmV4dC1ob3BzIHRvICphbGwqDQo+Pj5TRkbigJlzDQo+Pj4gID4+ID4+ID53aXRoaW4gdGhlIFNG QyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlkZW50aWZpZXIgcG9pbnQgdG8NCj4+PmEN Cj4+PiAgPj4gPj5sb29rdXANCj4+PiAgPj4gPj4gPmludG8gdGhvc2UgbmV4dC1ob3BzIHRvIHJl YWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbQ0KPj4+bm90DQo+Pj4gID4+c3VyZQ0K Pj4+ICA+PiA+Pmhvdw0KPj4+ICA+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0 Pw0KPj4+ICA+PiA+PiA+DQo+Pj4gID4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVS QUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29t Pj4NCj4+PiAgPj4gd3JvdGU6DQo+Pj4gID4+ID4+ID4NCj4+PiAgPj4gPj4gPj5BYnNvbHV0ZWx5 Lg0KPj4+ICA+PiA+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PiAgPj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSmltDQo+Pj5HdWljaGFyZA0KPj4+ICA+PiA+PiA+Pj4oamd1aWNoYXIp DQo+Pj4gID4+ID4+ID4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4+ ICA+PiA+PiA+Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24g UGFya2VyOw0KPj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+IFRoZW4gSSBtaXN1bmRl cnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMNCj4+PnRvIG1lDQo+ Pj4gID4+ID4+dGhhdCBpZg0KPj4+ICA+PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtl IGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRg0KPj4+aXQNCj4+PiAgPj53aWxsDQo+ Pj4gID4+ID4+dXNlDQo+Pj4gID4+ID4+ID4+PmZvcg0KPj4+ICA+PiA+PiA+Pj4gYSBnaXZlbiBm bG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UNCj4+PiAg Pj5iZXR0ZXINCj4+PiAgPj4gPj5tYWtlDQo+Pj4gID4+ID4+ID4+PiBzdXJlIHRoYXQgdGhhdCBy ZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMNCj4+PnRvDQo+Pj4g ID4+ID4+cmVhY2gNCj4+PiAgPj4gPj4gPj4+dGhlDQo+Pj4gID4+ID4+ID4+PiBuZXh0LW5leHQt U0YgZm9yIHRoZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwDQo+Pj50cm91Ymxl Lg0KPj4+ICA+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJO QVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbQ0KPj4+IDxtYWlsdG86bW4xOTIxQGF0 dC5jb20+Pg0KPj4+ICA+PiA+PiB3cm90ZToNCj4+PiAgPj4gPj4gPj4+DQo+Pj4gID4+ID4+ID4+ PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25s eSBpbg0KPj4+ICA+PnJlbGV2YW50DQo+Pj4gID4+ID4+ID4+PlNGRnMNCj4+PiAgPj4gPj4gPj4+ ID53aGVuIHRoZXkgImFycml2ZSIuDQo+Pj4gID4+ID4+ID4+PiA+DQo+Pj4gID4+ID4+ID4+PiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ICA+PiA+PiA+Pj4gPj4gRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+PiAgPj5H dWljaGFyZA0KPj4+ICA+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+Pj4gID4+ID4+ID4+PiA+PiBT ZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4+ICA+PiA+PiA+Pj4gPj4gVG86 IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnDQo+Pj4gPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4+QmFsYW5jZXJzDQo+Pj4gID4+ID4+ID4+PiA+ Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0 aGF0IGlmIEkgaGF2ZQ0KPj4+dW5kZXJzdG9vZA0KPj4+ICA+PnRoZQ0KPj4+ICA+PiA+PiA+Pj4g Pj5wcm9wb3NhbA0KPj4+ICA+PiA+PiA+Pj4gPj4gY29ycmVjdGx5IGFzIGl0IHdvdWxkIHJlcXVp cmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkNCj4+PnNpbmdsZQ0KPj4+ICA+PlNGDQo+Pj4gID4+ ID4+ID4+PndpdGhpbg0KPj4+ICA+PiA+PiA+Pj4gPj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+IGVu dGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5DQo+ Pj50bw0KPj4+ICA+Pmtub3cNCj4+PiAgPj4gPj5hDQo+Pj4gID4+ID4+ID4+PiA+PnByaW9yaQ0K Pj4+ICA+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZDwrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBz ZXJ2aWNlIGF0IGFueSBnaXZlbg0KPj4+ICA+PnBvaW50DQo+Pj4gID4+ID4+aW4NCj4+PiAgPj4g Pj4gPj4+dGltZS4NCj4+PiAgPj4gPj4gPj4+ID4+DQo+Pj4gID4+ID4+ID4+PiA+PiBPbiA3LzEw LzE0LCAxMTo1MyBQTSwgIkpvZWwgTS4gSGFscGVybiINCj4+PiA8am1oQGpvZWxoYWxwZXJuLmNv bSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4+ICA+PiA+PiB3cm90ZToNCj4+PiAg Pj4gPj4gPj4+ID4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlz LCBJIHJlYWxpemVkIGFub3RoZXIgbWFqb3INCj4+PnByb2JsZW0NCj4+PiAgPj53aXRoDQo+Pj4g ID4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PnlvdXINCj4+PiAgPj4gPj4gPj4+ID4+ID5wcm9w b3NhbCBhcyBJIHVuZGVyc3RhbmQgaXQuIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5DQo+Pj5u b3QNCj4+PiAgPj4gPj4gPj4+dW5kZXJzdGFuZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPml0LikNCj4+ PiAgPj4gPj4gPj4+ID4+ID4NCj4+PiAgPj4gPj4gPj4+ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVh Y2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvcg0KPj4+dGhlDQo+Pj4gID4+ID4+ bmV4dA0KPj4+ICA+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0 IChub3QgdGhlIG9uZSBpdA0KPj4+ZGVsaXZlcnMNCj4+PiAgPj50byksDQo+Pj4gID4+ID4+aW4N Cj4+PiAgPj4gPj4gPj4+ZXZlcnkNCj4+PiAgPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRo YXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4+ICA+PiA+PiA+Pj4gPj4gPg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRo YXQNCj4+Pm1lYW5zDQo+Pj4gID4+ID4+dGhhdA0KPj4+ICA+PiA+PiA+Pj4gPj5ldmVyeQ0KPj4+ ICA+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRp dmUgYW5kIHN0YXRlZnVsDQo+Pj5sb2FkDQo+Pj4gID4+ID4+ID4+PmJhbGFuY2VyLg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPkkgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNp dGl2ZSwgYW5kIC8NCj4+Pm9yDQo+Pj4gID4+ID4+c3RhdGVmdWwuDQo+Pj4gID4+ID4+ID4+PiA+ PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUg YQ0KPj4+ZnVsbCwNCj4+PiAgPj4gPj5mbG93DQo+Pj4gID4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZl LCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPj4+ICA+PiA+ PmFjY2VwdGFibGUNCj4+PiAgPj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPllvdXJzLA0KPj4+ICA+PiA+PiA+Pj4gPj4gPkpv ZWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4NCj4+PiAgPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAx MDowNiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gUGFy dCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlpbmcgdG8gbWFrZQ0KPj4+dGhp cw0KPj4+ICA+PndvcmsNCj4+PiAgPj4gPj4gPj4+ID4+c2Vuc2libHkNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQuIEkgZXhwZWN0IHRoYXQg dGhlDQo+Pj4gID4+c2VydmljZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQg b3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYNCj4+PmNhcGFiaWxpdGllcywNCj4+PiAgPj53aWxs DQo+Pj4gID4+ID4+YmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IG9yY2hlc3RyYXRlZCBhbmQgaW5z dGFsbGVkLiBJIGV4cGVjdCB0aGUgc2VydmljZQ0KPj4+Y2hhaW5zDQo+Pj4gID4+dG8gYmUNCj4+ PiAgPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBCU1MgdG9vbHMg dGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMsIGFuZCBlbmFibGUNCj4+PiAgPj4gPj4g Pj4+c2VsZi1zZWxlY3Rpb24NCj4+PiAgPj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhw ZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseQ0KPj4+cG9saWN5DQo+Pj4gID4+ID4+ZHJp dmUuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gSSBjYW4gc2Vl IGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4NCj4+PmFyY2h0aWVjdHVyZQ0KPj4+ ICA+PiA+PmRyaXZlbg0KPj4+ICA+PiA+PiA+Pj5ieQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gaW5p dGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQNCj4+Pmlz DQo+Pj4gID4+ID4+aGFyZGVyDQo+Pj4gID4+ID4+ID4+PnRvDQo+Pj4gID4+ID4+ID4+PiA+PnNl ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBi ZSBkb25lKSB3aGVuIHdlIGFsbG93DQo+Pj5tb3JlDQo+Pj4gID4+ID4+ID4+PiA+PiBkeW5hbWlj aXR5DQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBt b3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQNCj4+PmlzDQo+Pj4gID4+ID4+b3V0 c2lkZQ0KPj4+ICA+PiA+PiA+Pj5vZg0KPj4+ICA+PiA+PiA+Pj4gPj50aGUNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5n IHdlIGFyZQ0KPj4+ICA+PiA+PnRhc2tlZCB0bw0KPj4+ICA+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj5vbi4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNs YWltIHRoYXQgdmlzaW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYQ0KPj4+ICA+PmNlcnRhaW4N Cj4+PiAgPj4gPj4gPj4+d2F5Lg0KPj4+ICA+PiA+PiA+Pj4gPj5pdA0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMu DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gWW91cnMsDQo+Pj4g ID4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2Vy dmljZQ0KPj4+aW5zdGFuY2VzDQo+Pj4gID4+ID4+IHRoYXQNCj4+PiAgPj4gPj4gPj4+ID4+bmVl ZHMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj50bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3 aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5DQo+Pj5ldmVuDQo+ Pj4gID4+ID4+YWNyb3NzDQo+Pj4gID4+ID4+ID4+PmRhdGENCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlDQo+Pj5l bm91Z2gNCj4+PiAgPj5hbmQNCj4+PiAgPj4gPj4gPj4+IGNvbXBsZXgNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2Vl bXMNCj4+Pmxpa2UgYQ0KPj4+ICA+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBpcyBtb3JlIGNv bXBsaWNhdGVkIHRoYW4NCj4+PiAgPj5keW5hbWljDQo+Pj4gID4+ID4+ID4+PiByb3V0aW5nLA0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRp b24sIG9yIEROUywgYWxsIG9mDQo+Pj4gID4+d2hpY2gNCj4+PiAgPj4gPj5hcmUNCj4+PiAgPj4g Pj4gPj4+ID4+YmlnZ2VyDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gcHJvYmxlbXMgdGhhdCBoYXZl IGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5DQo+Pj5pbXBsZW1lbnRlZD8NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBp dCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwNCj4+PnRoYXQNCj4+PiAgPj5pcw0KPj4+ICA+ PiA+PmENCj4+PiAgPj4gPj4gPj4+Z29vZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhh dCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBl cm4uY29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA5OjQ1IFBNDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4gVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7DQo+Pj5taWtl YmlhbmNAYW9sLmNvbQ0KPj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Ow0KPj4+ICA+Pklh bg0KPj4+ICA+PiA+PiA+Pj5TbWl0aDsNCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDog UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+PiAgPj5CYWxhbmNl cnMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMg YW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQNCj4+PiAgPj5wcmVm ZXINCj4+PiAgPj4gPj53ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+PiBkZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9z c2libGUNCj4+PiAgPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4g QmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+PiAg Pj4gPj5yZXF1aXJlbWVudHMNCj4+PiAgPj4gPj4gPj4+YW5kDQo+Pj4gID4+ID4+ID4+PiA+PiB0 aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBmdW5jdGlvbmFsaXR5IG9mIFNGRnMuDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQg b2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPj4+aW5zdGFuY2VzDQo+Pj4gID4+ID4+dGhh dA0KPj4+ICA+PiA+PiA+Pj4gbmVlZHMNCj4+PiAgPj4gPj4gPj4+ID4+IHRvDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRp YWxseQ0KPj4+ZXZlbg0KPj4+ICA+PiBhY3Jvc3MNCj4+PiAgPj4gPj4gPj4+ZGF0YQ0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBp cyBsYXJnZQ0KPj4+ZW5vdWdoDQo+Pj4gID4+YW5kDQo+Pj4gID4+ID4+ID4+PmNvbXBsZXgNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBl YWNoIFNGRiBzZWVtcw0KPj4+bGlrZSBhDQo+Pj4gID4+ID4+ID4+PmRpZmZpY3VsdA0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4gSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4gQnV0 IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuIElzIHRoZSBl bmQgdG8gZW5kDQo+Pj4gID4+c2VsZWN0aW9uDQo+Pj4gID4+ID4+b2YNCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhh cHMNCj4+PmJ5IHRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj5jbGFzc2lmaWVyKQ0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZA0K Pj4+c3Vic2VxdWVudGx5DQo+Pj4gID4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PiA+PlNGRnMpPw0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0 bw0KPj4+cmVjbGFzc2lmaWNhdGlvbi4NCj4+PiAgPj5BbmQNCj4+PiAgPj4gPj4gPj4+c3VyZWx5 LA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUg YW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0 aW9uIi4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gTXkg b3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoDQo+Pj5ldmVuDQo+ Pj4gID4+IHRob3VnaA0KPj4+ICA+PiA+PiBhDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0 ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZA0KPj4+cGVyaGFwcw0KPj4+ ICA+PmxvY2FsDQo+Pj4gID4+ID4+ID4+PiA+PnNlbGVjdGlvbg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBwb2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uDQo+ Pj5wb2ludHMuDQo+Pj4gID4+ID4+VGhpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2Fj aCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdA0KPj4+YWxsLg0KPj4+ ICA+PiA+Pk15DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IHJhdGlvbmFsZSBmb3IgZmF2b3Jpbmcg dGhpcyBhcHByb2FjaCBpcyBwcmltYXJpbHkNCj4+PmRyaXZlbg0KPj4+ICA+PmJ5DQo+Pj4gID4+ ID4+ID4+PiA+PmluY3JlYXNlZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92 ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGENCj4+PiAgPj5nbG9iYWwNCj4+ PiAgPj4gPj4gPj4+cGF0aA0KPj4+ICA+PiA+PiA+Pj4gPj5pZA0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQNCj4+Pm5l ZWRpbmcgdG8NCj4+PiAgPj4gPj5hbHRlcg0KPj4+ICA+PiA+PiA+Pj50aGUNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVj dGVkDQo+Pj4gID4+ZW5kLXRvLWVuZA0KPj4+ICA+PiA+PiA+Pj5wYXRoLg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gW3NmYy1ib3Vu Y2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPj4+IG9uIGJlaGFs ZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbQ0KPj4+IDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5j b20+XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwNCj4+PiAgPj4yMDE0DQo+Pj4gID4+ID4+IDY6 MTUNCj4+PiAgPj4gPj4gPj4+IFBNDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlh bmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+PiBJLlNtaXRoQEY1LmNv bSA8bWFpbHRvOkkuU21pdGhARjUuY29tPjsgc2ZjQGlldGYub3JnDQo+Pj48bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+PiAgPj4gU3ViamVjdDoNCj4+PiAgPj4gPj4gUmU6DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRoZSB3YXkg dGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ugb2YgU0YxDQo+Pj5uZWVkaW5nDQo+Pj4g ID4+dG8NCj4+PiAgPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0DQo+Pj50 aGUNCj4+PiAgPj5leGl0DQo+Pj4gID4+ID4+ZnJvbQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBT RjEuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQg b2YgdGhlIGdvYWwgaXMgdG8ga2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucw0KPj4+ICA+PiA+ PmxvZ2ljYWxseQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0 aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cNCj4+PnRoZXkNCj4+PiAgPj4gPj4gY2hvb3Nl DQo+Pj4gID4+ID4+ID4+PnRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBm b3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbQ0K Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+IHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdA0KPj4+c3Vn Z2VzdHMgYW55DQo+Pj4gID4+ID4+c29ydA0KPj4+ICA+PiA+PiA+Pj5vZg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0 IHRoZQ0KPj4+ZW50aXJlDQo+Pj4gID4+ID4+cGF0aA0KPj4+ICA+PiA+PiA+Pj4oYWxsDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlh dGlvbi4gSQ0KPj4+YmVsaWV2ZQ0KPj4+ICA+PnRoaXMNCj4+PiAgPj4gPj4gPj4+bWVhbnMNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0 aGUgY2xhc3NpZmllcg0KPj4+ICA+PmNob29zZXMgYQ0KPj4+ICA+PiA+PlNGDQo+Pj4gID4+ID4+ ID4+PiA+PkNoYWluDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRo ZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55DQo+Pj5jYXNlLA0KPj4+ICA+PiA+PnRoZQ0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEg bW9yZSBkeW5hbWljIFNGUA0KPj4+d2hlcmUNCj4+PiAgPj4gPj4gU0ZJKG4pDQo+Pj4gID4+ID4+ ID4+PiBpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4t MSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlDQo+Pj5kcmFmdCwNCj4+PiAgPj4gPj50aGlzDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICJicmFuY2hp bmciIHRvIGEgbmV3DQo+Pj5TRlAgYXMNCj4+PiAgPj4gPj4gPj4+IG9wcG9zZWQNCj4+PiAgPj4g Pj4gPj4+ID4+IHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBm b3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZA0KPj4+aW5zdGFuY2Ugb2YNCj4+PiAgPj4gPj50aGUN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJn ZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBXaGVuIGFu IFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpcw0KPj4+ICA+PiA+Pm5l Y2Vzc2FyeQ0KPj4+ICA+PiA+PiA+Pj50bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNlbGVj dCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUNCj4+PnVzZWQsDQo+ Pj4gID4+ID4+YW5kIHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY3JlYXRlIHRoZSBzZXJ2 aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZw0KPj4+U0Yncw0KPj4+ICA+PiA+Pm5ldHdv cmsNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9u IG9mIHRoZSBTRkMgcmVzdWx0cyBpbg0KPj4+dGhlDQo+Pj4gID4+ID4+ID4+PmNyZWF0aW9uDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkg YW5kIGlzIHVzZWQgZm9yDQo+Pj4gID4+ID4+Zm9yd2FyZGluZw0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlz DQo+Pj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBk ZWZpbmVkIFNGQy4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9y DQo+Pj4gID4+ID4+bm9uLWluaXRpYWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lm aWNhdGlvbikgYXMgd2VsbC4gQXMgcGFja2V0cyB0cmF2ZXJzZSBhbg0KPj4+U0ZQLA0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5 IHBlcmZvcm1lZA0KPj4+YnkgYQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0 aW9uIGZ1bmN0aW9uIGNvLXJlc2lkZW50IHdpdGggYSBzZXJ2aWNlDQo+Pj4gID4+ID4+ZnVuY3Rp b24uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0 IGluIHRoZSBzZWxlY3Rpb24gb2YgYQ0KPj4+bmV3DQo+Pj4gID4+ID4+U0ZQLCBhbg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3Ig Ym90aC4gVGhpcyANCj4+PmlzDQo+Pj4gID4+ID4+cmVmZXJyZWQNCj4+PiAgPj4gPj4gPj4+dG8N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+Pg0KPj4+ICA+PiA+ PiA+Pj4NCj4+PiAgPj4gPj4NCj4+PiAgPj4NCj4+PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4+ICA+Pj4+Pj4+Pj4+Pj4+ Pi0tDQo+Pj4gID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4+ICA+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ PiAgPj4gPj4gPj4+ID4+Pj4+Pj4tLQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb20N Cj4+PiA8bWFpbHRvOipJLlNtaXRoQEY1LmNvbT48SS5TbWl0aEBGNS5jb20gPG1haWx0bzpJLlNt aXRoQEY1LmNvbT4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4N Cj4+PiAgPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzpq bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT4+LEpvZWwNCj4+PiAgPj4gPj4gTS4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4NCj4+PiAg Pj4gPj4NCj4+PiAgPj4gPj4+Pj5IYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20NCj4+PiA8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+PixodWFuZ0BzY2UuY2FybGV0b24uY2ENCj4+PiA8bWFp bHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVhbmdAc2NlLg0KPj4+IDxtYWlsdG86aHVhbmdA c2NlLiUwYj4+PiA+PiA+Pj4gPj4gY2FybGV0b24uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PmNh PixzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZw0KPj4+IDxt YWlsdG86c2ZjQGlldGYub3JnPj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+PiAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCANCj4+ PkxvYWQNCj4+PiAgPj4gPj5CYWxhbmNlcnMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBBY3R1YWxseSwgSSB0aGluayBJIGFtIGRpc2FncmVlaW5nLg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBw b3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj4+ICA+PnRoYXQg aXMNCj4+PiAgPj4gPj4gPj4+d2hhdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlv biBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgDQo+Pj5pcw0KPj4+ICA+ PiA+PiA+Pj5wcmVjb25jZWl2ZWQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3Vy ZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgDQo+Pj53aXRoDQo+Pj4gID4+ IHRoYXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNv bWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZg0KPj4+ICA+PiA+PmFzcGlyYXRpb24NCj4+ PiAgPj4gPj4gdG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNjYWxlIHRoYXQgaXMgYXBwcm9w cmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4+PiAgPj4gPj5hcmNoaXRlY3R1cmUNCj4+ PiAgPj4gPj4gPj4+LQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8g a25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIA0KPj4+dGhhdCBhbg0KPj4+ICA+PiA+PiA+ Pj5hcmJpdHJhcnkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG51bWJlciBpcyAidG9vIGZhciIs IHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYgaXQgDQo+Pj5pc24ndA0KPj4+ICA+PiA+PiA+Pj4g Pj5pbnRlbnRpb25hbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5m bHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBoYXZlIA0KPj4+bGFzdGluZw0KPj4+ICA+PiA+PmltcGFj dHMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUg bWl0aWdhdGlvbiwgDQo+Pj5lbGFzdGljaXR5LA0KPj4+ICA+PiA+PmFkZHJlc3MNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBw cm9ibGVtIA0KPj4+SSdtIA0KPj4+bm90DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1 bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJu IERpcmVjdA0KPj4+IFtqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaC5kaXJl Y3RAam9lbGhhbHBlcm4uY29tPl0NCj4+PiAgPj4gPj5TZW50Og0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyANCj4+ PkpvZWwgDQo+Pj5NLg0KPj4+ICA+PiA+PiBIYWxwZXJuOw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhDQo+Pj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24u Y2E+OyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogUmU6 IFtzZmNdDQo+Pj4gID4+ID4+U2VydmljZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRo IG1lIGF0IGFsbCBpbiANCj4+PnRoaXMNCj4+PiAgPj4gPj5yZWdhcmQuDQo+Pj4gID4+ID4+ID4+ PkkNCj4+PiAgPj4gPj4gPj4+ID4+YW0NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IG5vdCByZXF1 ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0dXJlIG9yIHRoZSBzb2x1dGlvbg0KPj4+ICA+PiA+PnBy b2hpYml0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lm aWMgZmFzaGlvbi4gSSBhbSANCj4+Pm9iamVjdGluZyANCj4+PnRvDQo+Pj4gID4+ID4+SHVhbmcn cw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0 aGF0IHN1Y2ggZGVwbG95bWVudHMgDQo+Pj5hcmUNCj4+PiAgPj4gPj4gcmVxdWlyZWQNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBl YXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gDQo+Pj5wcm9oaWJpdA0KPj4+ICA+PnN1Y2gNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRl YSBvciBub3QgDQo+Pj5kZXBlbmRzIA0KPj4+dXBvbg0KPj4+ICA+PiA+PiBtYW55DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4g SSBoYXBwZW4gdG8NCj4+PiAgPj50aGluaw0KPj4+ICA+PiA+PnRoYXQNCj4+PiAgPj4gPj4gPj4+ ID4+dGhleQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXJlIHVzdWFsbHkgYSBiYWQgaWRlYS4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhl IGFyY2h0aWVjdHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgDQo+Pj5hdHRlbXB0aW5nIHRvDQo+ Pj4gID4+ID4+a25vdw0KPj4+ICA+PiA+PiA+Pj53aGF0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3 cm90ZToNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUg c3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSANCj4+PnRlbnMgb2YNCj4+PiAgPj4gPj4gPj4+ bWlsbGlvbnMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIA0K Pj4+Y2VudGVyDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlv dSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSANCj4+PnRoYXQgaW4NCj4+PiAgPj50aGUNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBv ZiB0b21vcnJvdyANCj4+PnlvdQ0KPj4+ICA+PiBhcmUNCj4+PiAgPj4gPj4gb25seQ0KPj4+ICA+ PiA+PiA+Pj4gPj4gZ29pbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRvIGhhdmUgc21hbGwg bnVtYmVycyBvZiBzZXJ2aWNlIGNoYWlucyB3aXRoIA0KPj4+ZXF1YWxseQ0KPj4+ICA+PnNtYWxs DQo+Pj4gID4+ID4+ID4+PiBudW1iZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBvZiBhY3Rp dmUgc2VydmljZSBwYXRocz8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIg bmVlZCANCj4+Pm1vcmUNCj4+PiAgPj4gdGhhbg0KPj4+ICA+PiA+PiA+Pj4gNjRLIg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29tZm9ydC4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBGcm9tOiBzZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0 Zi5vcmcNCj4+PiA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEpv ZWwgTS4gSGFscGVybg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5j b20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4+ICA+PiA+PiA+ Pj5odWFuZ0BzY2UuY2FybGV0b24uY2EgPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4gU3ViamVjdDogUmU6DQo+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPj4+ICA+ PmFuZA0KPj4+ICA+PiA+PiA+Pj5Mb2FkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5j ZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBO bywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgDQo+Pj50aGUN Cj4+PiAgPj4gPj4gPj4+YXJjaHRpZXR1cmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0 aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPj4+ICA+PnRo ZWlyDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBk b2VzIG5vdCByZXF1aXJlIHN1Y2ggDQo+Pj5hYnN1cmQNCj4+PiAgPj4gdXNlDQo+Pj4gID4+ID4+ IG9mDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4g bm90IGZpZ3VyZSBvdXQgaG93IHRvIA0KPj4+d3JpdGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ PiBhcmNoaXRlY3R1cmFsIHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgDQo+Pj5hcmNoaXRlY3R1 cmUNCj4+PiAgPj5kb2VzDQo+Pj4gID4+ID4+ID4+PnBlcm1pdA0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0 aWVjdHVyZQ0KPj4+ICA+PiBwZXJtaXRzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRo aW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciANCj4+PnJlcXVpcmVkIGJ5DQo+ Pj4gID4+ID4+dGhlDQo+Pj4gID4+ID4+ID4+PndvcmsuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4gSXQgaXNuJ3QuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiBZb3VycywgSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90 ZToNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAg c2VydmljZSBjaGFpbnMsIGl0IA0KPj4+d2lsbA0KPj4+ICA+Pm1lYW4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4gMTYsMDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91 dGluZw0KPj4+ICA+PnRhYmxlDQo+Pj4gID4+ID4+b2YgYQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+PiBjb3JlIHJvdXRlci4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4gT24gMDcvMTAvMjAxNCAwMToxNSBQTSwgSm9lbCBNLiBIYWxwZXJu IHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxv d3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgDQo+Pj5mcm9tDQo+Pj4gID4+MQ0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJ IHdvdWxkIA0KPj4+aG9wZQ0KPj4+ICA+PnRoYXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgDQo+Pj50aGV5 DQo+Pj4gID4+ID4+Y2hvb3NlDQo+Pj4gID4+ID4+ID4+PnRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBhdm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiANCj4+ PnN0ZWFkDQo+Pj4gID4+ID4+IHByb3Zpc2lvbg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4g MTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDowNiBQTSwgTkFQ SUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWws DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgDQo+Pj40IA0K Pj4+aG9wDQo+Pj4gID4+ID4+IHNlcnZpY2UNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBj aGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1hcmlhDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiANCj4+PkJlaGFsZg0KPj4+ICA+PiBPZg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpQYXVsIFF1aW5uIChwYXVscSkgKlNlbnQ6KiBU aHVyc2RheSwgSnVseSAxMCwgDQo+Pj4yMDE0DQo+Pj4gID4+ID4+MzowMw0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4u Y29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgc2ZjQGlldGYub3JnIA0KPj4+PG1haWx0bzpzZmNA aWV0Zi5vcmc+Ow0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29t IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+DQo+Pj4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2Vy dmljZQ0KPj4+ICA+PiBDaGFpbnMsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6 IGEgcGF0aCBJRCBkcml2ZXMgDQo+Pj50aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBm b3J3YXJkaW5nLiBJwrlkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBj YW4gYmUgDQo+Pj51c2VkIHRvDQo+Pj4gID4+ID4+IGRlcml2ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQu DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgDQo+Pj50bw0K Pj4+ICA+PnNpbXBseQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBz ZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IA0KPj4+cGFja2V0cw0KPj4+ICA+Pm11c3QNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVu dGlmaWVyLCB0aGUgDQo+Pj5leGFjdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGly ZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciANCj4+Pm9uDQo+Pj4gID4+ dGhpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVhZCBjYW4gYmUgc2ltcGx5IGJl IGltcGxlbWVudGVkLiBUaGUgcGF0aA0KPj4+ICA+PiA+PiBpZGVudGlmaWVyDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRo YXQgDQo+Pj5sb29rdXAgY2FuDQo+Pj4gID4+ID4+IHJlc3VsdA0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQg DQo+Pj5uZXh0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24g SnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5b25nDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29tIA0KPj4+PG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4NCj4+PiAgPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4gPG1haWx0 bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUzZT4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g d3JvdGU6DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gQWdyZWUuIFRoZSBhcmNoLiBkb2Mgc2hvdWxkIG5vdCBtYW5kYXRlIG9ubHkgDQo+ Pj51c2Ugb2YNCj4+PiAgPj4gdGhlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vydmlj ZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmcNCj4+PiAgPj4gPj5hY3Rp b25zLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gTHVjeQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiAN Cj4+PkJlaGFsZg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4+PiA8bWFpbHRvOk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPj4+ICA+PiA+PiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPj4+ICA+PiA+ PiA+Pj4gPj4gSnVseQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYg QU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0KPj4+IDxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29t Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ O2ptaEBqb2VsaGFscGVybi5jb20NCj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNlO2pt aEBqb2VsaGFscGVybi5jb20+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+PiA8bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lM2U7c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIA0KPj4+U2VydmljZQ0KPj4+ ICA+PiA+PkNoYWlucywNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBSZS0sDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5 IGEgDQo+Pj5zZXJ2aWNlIA0KPj4+cGF0aA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlk ZW50aWZpZXIuIEkgb2JqZWN0IHRvIHVzZSB0aGF0IGlkZW50aWZpZXIgdG8NCj4+PiAgPj5kZXJp dmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1 aXJpbmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwgDQo+Pj5rbm93bGVkZ2Ugb2YNCj4+ PiAgPj4gPj4gZXZlcnkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGF2YWlsYWJsZSBTRkMNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMt ZW5hYmxlZCBkb21haW4gDQo+Pj5pcyBub3QNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlcXVp cmVkL2p1c3RpZmllZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBp biB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTRkMgZm9yd2FyZGluZyBhY3Rpb25zIHNo b3VsZCByZWx5IG9uIHRoZSANCj4+PnBpZWNlIA0KPj4+b2YNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6 IHRoYXQgaXMgdGhlIG9uZQ0KPj4+ICA+PiByZXF1aXJlZA0KPj4+ICA+PiA+PiB0bw0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0 IA0KPj4+aW5mb3JtYXRpb24gDQo+Pj5pcw0KPj4+ICA+PiA+PnVzZWQgdG8NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpbmZlciBmb3J3YXJkaW5nDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBhY3Rpb25zDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1dGlvbi1vcmll bnRlZCBkaXNjdXNzaW9uLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWVkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10qRGUgbGEgDQo+Pj5wYXJ0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBk ZSptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOmRlKm1pa2ViaWFuY0Bhb2wuY29tPg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOp IDoqbWVyY3JlZGkgOQ0KPj4+ICA+PiA+PiBqdWlsbGV0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzoq am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZw0KPj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXSANCj4+PlNlcnZpY2UNCj4+ PiAgPj4gPj5DaGFpbnMsDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBM b2FkIEJhbGFuY2Vycw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNl IA0KPj4+YmV0d2Vlbg0KPj4+ICA+PlNGDQo+Pj4gID4+ID4+IENoYWluDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYW5kIFNGDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBQYXRoPw0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5p dGlvbiBzbyB0aGF0IA0KPj4+aXQncw0KPj4+ICA+PiA+PmNsZWFyIHRvDQo+Pj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlh ciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZQ0KPj4+ICA+PmFncmVlcw0K Pj4+ICA+PiA+Pm9uDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlc2UgdGVybXMuDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBU byBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+PiAgPj53aGV0 aGVyDQo+Pj4gID4+ID4+aXQgaXMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50 ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IA0KPj4+d2hhdA0KPj4+ICA+ PiA+PnRoZSBJRA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVy DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzaG91bGQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgDQo+Pj5k cmFmdA0KPj4+ICA+PiA+PnNpbXBseQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVu ZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+Pj4gID4+ZHJhZnRz DQo+Pj4gID4+ID4+dG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBt ZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIA0KPj4+Y2hhaW4NCj4+PiAgPj4gb3IN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWlu IG9yDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0 ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IA0KPj4+d291bGQgDQo+Pj5oYXZlDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUg c3VwcG9ydGVkIChvciANCj4+Pm1ha2UNCj4+PiAgPj4gPj4gb25lDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29t ZQ0KPj4+ICA+PiB2ZW5kb3JzDQo+Pj4gID4+ID4+IG9ubHkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+DQo+Pj4gID4+ID4+ID4+ Pg0KPj4+ICA+PiA+Pg0KPj4+ICA+Pg0KPj4+ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4tDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+Pj4gID4+Pj4+Pj4+Pj4+Pj4+LS0N Cj4+PiAgPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+Pj4gID4+ID4+ID4+Pj4+Pj4+Pj4tLQ0KPj4+ICA+ PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb20NCj4+PiA8bWFpbHRvOipqbWhAam9lbGhh bHBlcm4uY29tPjxqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+IDxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4gPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZT4+DQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmcNCj4+PiA8bWFpbHRvOipzZmNAaWV0 Zi5vcmc+PHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4NCj4+PiA8 bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUzZT4+DQo+Pj4gID4+ICpTZW50OipU dWVzZGF5LA0KPj4+ICA+PiA+PiBKdWx5DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gOCwg MjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCANCj4+PmFuZA0KPj4+ ICA+PkxvYWQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBi ZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+Pj4gID4+YW5zd2VyDQo+ Pj4gID4+ID4+YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50 cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IA0KPj4+dGhlDQo+Pj4gID4+ID4+ID4+PiBwcm9w b3NlZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1lcmdlZCBhcmNodGllY3R1cmUgZHJh ZnQuIEFzc3VtaW5nIHdlIGNhbiBnZXQNCj4+PiAgPj4gd29ya2luZw0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsg dG8NCj4+PiAgPj4gaW1wcm92ZQ0KPj4+ICA+PiA+PiB0aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgDQo+Pj5wYXJ0aWNp cGF0ZWQgaW4NCj4+PiAgPj4gPj50aGUNCj4+PiAgPj4gPj4gV0cNCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Z3JvdXAgaW50ZW5kcy4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBs YWluIG15DQo+Pj4gID4+ID4+cGVyc29uYWwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2 aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0 YW50IHRvIGtlZXAgaW4gDQo+Pj5taW5kIA0KPj4+dGhhdA0KPj4+ICA+PiA+PndoYXQNCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBhcmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUg DQo+Pj5hcmNoaXRlY3R1cmUuIA0KPj4+V2UNCj4+PiAgPj5hcmUNCj4+PiAgPj4gPj4gbm90DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hp dGVjdHVyZSBmb3IgdGhlIA0KPj4+ZW50aXJlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g c29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291bGQgDQo+Pj5lbmNvbXBhc3MN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5k IHBvbGljeSBmdW5jdGlvbnMsDQo+Pj4gID4+dmlydHVhbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+Pj4g ID4+ID4+IGFzcGVjdHMuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2gg DQo+Pj5jbGVhcmx5IA0KPj4+bmVlZA0KPj4+ICA+PiB0bw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJlIA0KPj4+ZGVh bHQgDQo+Pj53aXRoDQo+Pj4gID4+ID4+YWJvdmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB3aGVyZSB3ZSBhcmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5 IHRoZSB3b3JrIHdlIA0KPj4+YXJlDQo+Pj4gID4+IGRvaW5nLg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIgdG8gZ2V0IHRv IHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSANCj4+PnBhdGgsDQo+Pj4gID4+YXMgSQ0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHVuZGVyc3RhbmQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IHRoZW0sDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBuZWVkIHRvIGZpcnN0IGRpc2N1 c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIA0KPj4+YXJlIGF0DQo+Pj4gID4+ID4+bGVhc3QNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQgd2F5cyB0aGF0IGxvYWQg YmFsYW5jaW5nIGNhbiANCj4+PmFuZA0KPj4+ICA+PndpbGwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHByb2JhYmx5IA0K Pj4+YXJlDQo+Pj4gID4+ID4+bW9yZS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUg cG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIA0KPj4+b2YNCj4+PiAg Pj4gPj50aGVzZSwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBidXQgbm90IHRvIG1hbmRh dGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1 c2VkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9h ZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSANCj4+PmVuZA0KPj4+ICA+ PiA+PnVzZXIuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNlcnZpY2Ug ZnVuY3Rpb24uIEl0IHJlY2VpdmVzIHVzZXINCj4+PiAgPj5wYWNrZXRzLA0KPj4+ICA+PiA+PmFu ZA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9yDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBtYXJrcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZW0s IG9yIC4uLikgc28gYXMgdG8gY2hvb3NlIGFuIGVuZCB1c2VyIA0KPj4+c2VydmljZQ0KPj4+ICA+ PiA+Pmluc3RhbmNlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUg dXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuIA0KPj4+aW1wb3J0YW50DQo+Pj4gID4+ID4+c2Vydmlj ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1bmN0aW9uIHRvIGJlIGFibGUgdG8gaW5j bHVkZSBpbiBzZXJ2aWNlIA0KPj4+Y2hhaW5pbmcuDQo+Pj4gID4+ID4+SXQncw0KPj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhv dyBzZXJ2aWNlDQo+Pj4gID4+ID4+IGNoYWluaW5nIGlzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+Pj4gID4+ ID4+YXJjaHRpZWN0dXJlLg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEZyb20gYW4gYXJj aGl0ZWN0dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgDQo+Pj5zaW1wbHkgDQo+Pj5hDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVu Y3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyANCj4+PnBhY2tldC4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIpIFRo ZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCANCj4+Pm9uZQ0KPj4+ICA+ PmNhbg0KPj4+ICA+PiA+PmhhdmUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGF0DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhcHBlYXJzDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgDQo+Pj5zaW5nbGUN Cj4+PiAgPj5wb2ludA0KPj4+ICA+PiA+Pm9mDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Y29udGFjdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgDQo+ Pj5kZWxpdmVyZWQNCj4+PiAgPj4gPj5ieSBhDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xs ZWN0aW9uIG9mDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNh bCBtYWNoaW5lcywgcG9zc2libHkgDQo+Pj5pbmNsdWRpbmcNCj4+PiAgPj5vbmUgb3INCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXZlcmFsIGxvYWQgYmFsYW5jZXJzIChmb3IgZXhhbXBs ZSB1c2luZyANCj4+PlZSUlAtbGlrZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRlY2hu aXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgDQo+Pj50aGlzIGlzDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5n IGRhdGEgcGxhbmUNCj4+PiAgPj4gPj5tZWNoYW5pc21zLg0KPj4+ICA+PiA+PiBJdA0KPj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFy aW91cyBjb250cm9sDQo+Pj4gID4+ID4+bWVjaGFuaXNtcywNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdWNoIGFzIHRob3NlIHJlc3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgDQo+Pj5zY2Fs ZS1vdXQsDQo+Pj4gID4+YW5kDQo+Pj4gID4+ID4+dm0NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbnN0YW50aWF0aW9uLiBUaGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4+PiAgPj5w ZXJtaXR0aW5nDQo+Pj4gID4+ID4+dGhpcw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlz IGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+PiAgPj4gPj50 ZXJtaW5vbG9neQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBs b2FkIGJhbGFuY2luZyBkb25lIGJ5DQo+Pj4gID4+c2VsZWN0aW5nDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gcGFja2V0IHBhdGhzIGZvciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IA0K Pj4+ZGlyZWN0DQo+Pj4gID4+ID4+dHJhZmZpYw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIA0KPj4+cmVxdWlyZQ0K Pj4+ICA+PiB0aGF0DQo+Pj4gID4+ID4+YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdp dmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25lIA0KPj4+cGxhY2UgDQo+Pj5p bg0KPj4+ICA+PnRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBp cyBvZiBjb3Vyc2UgdGhlIGNhc2UgdGhhdCB0aGVzZSBtYXkgYmUNCj4+PiAgPj5jb21iaW5lZC4g SQ0KPj4+ICA+PiA+PiB0ZW5kDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gDQo+Pj5zZXJ2aWNlDQo+ Pj4gID4+ID4+Y2hhaW5pbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmds ZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIA0KPj4+Y2x1c3Rlcg0KPj4+ICA+Pmlz DQo+Pj4gID4+ID4+YQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4gQnV0 IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90aGVyIA0KPj4+b25lLg0KPj4+ICA+PiBUaHVzLA0K Pj4+ICA+PiA+PiB0aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBl IDMgbG9hZCBiYWxhbmNpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMg dG8gDQo+Pj5kaWZmZXJlbnQNCj4+PiAgPj4gPj5zaW5ndWxhcg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgDQo+ Pj5wbGFjZXMNCj4+PiAgPj5pbg0KPj4+ICA+PiA+PnRoZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG5ldHdvcmsuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4g SSB0YWxrIA0KPj4+YWJvdXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGNo YWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gDQo+Pj5pcyBhDQo+Pj4gID4+ID4+ IHNlcXVlbmNlDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgbG9naWNhbCBmdW5jdGlv bnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCANCj4+Pm9mDQo+Pj4gID4+ID4+cGFja2V0cy4N Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWluZyB0 aGF0IHNvbWUgc3Vic2V0IG9mDQo+Pj4gID4+dHJhZmZpYw0KPj4+ICA+PiA+PmlzDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQgaW5zcGVj dGlvbiwgYW5kDQo+Pj4gID4+ZmlyZXdhbGwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gDQo+Pj50aGUNCj4+ PiAgPj5jYWNoZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0aG91dA0KPj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRo YXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlDQo+Pj4gID4+cGFja2V0 cy4NCj4+PiAgPj4gQQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBp cywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+Pj4gID4+ID4+bG9jYXRpb25zDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9u cyB3aWxsIGJlIA0KPj4+c2luZ3VsYXIgb3INCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBj bHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIA0KPj4+VGhleQ0K Pj4+ICA+PiA+Pm1heSBiZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFkZHJlc3NlZCBi eSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZSBhZGRyZXNzZWQgDQo+Pj5hcw0KPj4+ICA+PiBwb3J0 cw0KPj4+ICA+PiA+PiBvbg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhl cmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGUNCj4+PiAgPj4gPj5sb2NhdGlvbnMN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYXkgYmUga25vd24gdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgDQo+Pj5pbmZyYXN0cnVjdHVyZQ0KPj4+ICA+PiBhbmQNCj4+PiAgPj4gPj4gdGhl DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNwb3J0Lg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IEZyb20gdGhlIHBvaW50 IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQw0KPj4+ICA+Pmdyb3VwLA0KPj4+ICA+PiA+ PiB3ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBuZWVkIHRvIGJlDQo+Pj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJsZSB0byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3Ry YWN0aW9uLCANCj4+PnRoZQ0KPj4+ICA+PiA+PnNlcnZpY2UNCj4+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgDQo+Pj5u ZWVkIA0KPj4+dG8NCj4+PiAgPj4gdGFsaw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFi b3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIA0KPj4+aW4gDQo+Pj50 aGUNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0aGUg Y29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIA0KPj4+d2hvbGUNCj4+PiAgPj4gcGF0aA0KPj4+ ICA+PiA+PiBtYXkNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQg dGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgDQo+Pj5kZWFscw0KPj4+ICA+PiA+PndpdGgN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJz dCwgYXMgbm90ZWQgaW4gDQo+Pj5pdGVtIA0KPj4+KDIpDQo+Pj4gID4+b24NCj4+PiAgPj4gPj5s b2FkDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBj YW4gYmUgZGVjaXNpb25zIGFuZA0KPj4+ICA+PmJlaGF2aW9ycw0KPj4+ICA+PiA+PiB3aGljaA0K Pj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgDQo+Pj5tZWNoYW5pc21zIChpbg0KPj4+ICA+PiA+Pm11Y2gNCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4g aXMgDQo+Pj5sYXJnZWx5DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRv IHJvdXRpbmcgYmV0d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+Pj4gID4+IHByb3Zpc2lvbg0KPj4+ ICA+PiA+PiB3ZQ0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNz aWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuDQo+Pj4gID4+ID4+IG5lY2Vz c2FyeS4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tl dHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIA0KPj4+b24NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uDQo+Pj4g ID4+cG9pbnQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIGV4cGxhaW4gd2hhdCB3ZSBhcmUgDQo+ Pj5hZnRlci4NCj4+PiAgPj5JZiBpdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMs IGFuZCBpZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIA0KPj4+d29ya2luZw0KPj4+ ICA+PiA+PiBncm91cCwNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmlndXJl IG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIA0KPj4+bmVlZGVkDQo+Pj4gID4+IHRvDQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdy b3VwIGRpc2FncmVlIA0KPj4+d2l0aCANCj4+PnRoZQ0KPj4+ICA+PiA+PiBpbnRlbnQsDQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbiB3ZSB3aWxsIG9mIGNvdXJzZSBhZGp1c3QgdG8g bWF0Y2ggdGhlIA0KPj4+d29ya2luZw0KPj4+ICA+PiA+Pmdyb3VwDQo+Pj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5v dCANCj4+PnN1cmUNCj4+PiAgPj4gPj53aGF0IHRvDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdHJ5IG5leHQuDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiAgPj4gPj4gc2ZjDQo+Pj4gID4+ID4+ID4+ PiA+PiBtYWlsaW5nDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4gID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gID4+ID4+IHNmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+ICA+PiA+PiBzZmMNCj4+PiAgPj4gPj4gPj4+ID4+IG1h aWxpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWls dG86c2ZjQGlldGYub3JnPg0KPj4+ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ICA+PiBzZmMNCj4+PiAgPj4gPj4gPj4+ ID4+IG1haWxpbmcNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gID4+IHNmYw0KPj4+ICA+PiA+PiA+ Pj4gbWFpbGluZw0KPj4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+Pj4gID4+ID4+ID4+ PiBtYWlsaW5nDQo+Pj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gc2ZjDQo+Pj4gID4+ID4+IG1haWxpbmcNCj4+PiAgPj4gPj4gPj4+ID4+IGxpc3QN Cj4+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4+ ID4+ID4+PiA+PiA+Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4+ICA+PiA+PiBtYWlsaW5nDQo+ Pj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9y ZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4g Pj4+DQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+PiA+PiA+Pj4gPj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiAgPj4gPj4gPj4+ID4+ ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+PiAgPj4gPj4gPj4+ID4+ID4+IHNmY0BpZXRmLm9yZyA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiAgPj4gPj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPj4+ICA+ PiA+PiA+Pj4gPj4gPg0KPj4+ICA+PiA+PiA+Pj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gID4+ID4+ID4+PiA+PiA+c2ZjIG1haWxpbmcg bGlzdA0KPj4+ICA+PiA+PiA+Pj4gPj4gPnNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+PiAgPj4gPj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4gPj4NCj4+PiAgPj4gPj4gPj4+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gID4+ID4+ID4+PiA+PiBz ZmMgbWFpbGluZyBsaXN0DQo+Pj4gID4+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+Pj4NCj4+PiAgPj4gPj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gID4+ID4+ID4+PiBz ZmMgbWFpbGluZyBsaXN0DQo+Pj4gID4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+Pj4gID4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4+ICA+PiA+PiA+DQo+Pj4gID4+ID4+ID5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ICA+PiA+PiA+c2ZjIG1haWxpbmcgbGlz dA0KPj4+ICA+PiA+PiA+c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+ICA+ PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiAgPg0K Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4N Cj4NCg0K From nobody Mon Jul 14 08:36:38 2014 Return-Path: <lucy.yong@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135191A0A96 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 EEzqFH80mxbx for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 08:36:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD951A0A91 for <sfc@ietf.org>; Mon, 14 Jul 2014 08:36:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA50655; Mon, 14 Jul 2014 15:36:24 +0000 (GMT) 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; Mon, 14 Jul 2014 16:36:22 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 08:36:14 -0700 From: Lucy yong <lucy.yong@huawei.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HTo8BuVuTyW0ugIx3qXYbOUpugA2oA//+NmKCAAIhHgIAABd6AgAADa4CAAAIHAP//jHUA Date: Mon, 14 Jul 2014 15:36:13 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.109] 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/7tkcHOAHjVTCeNcutfNeznBhia8 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 15:36:36 -0000 SU1POiAgcXVvdGUgIlNGUCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGlzIGFzc29jaWF0ZWQgd2l0 aCBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyDQp0aGF0IGlzIHVzZWQgdG8gdW5pcXVlbHkgaWRl bnRpZnkgYW4gU0ZQIiBpcyBub3QgcHJvcGVyIGFzc3VtZWQgaW4gYXJjaGl0ZWN0dXJlIGRvYy4g IA0KDQpBcyBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGFuIFNGIGluIGFuIFNGQyBtYXkgaGF2 ZSBtdWx0aXBsZSBpbnN0YW5jZXMgdGhhdCBhcmUgYXZhaWxhYmxlIG9yIGJlIGluIHN0YW5kYnku IFNlbGVjdGlvbiBvZiB0aGUgaW5zdGFuY2UgZm9yIHRoZSBTRiBtYXkgYmUgZHluYW1pYyBiYXNl ZCBvbiB0aGUgZmxvdyBpbmZvLiBvbiBwYWNrZXQuIFRodXMsIHdlIGNhbiBub3QgcmVxdWlyZSBh IHNlcnZpY2UgcGF0aCBJRCB0byBpZGVudGl0eSBhbiBTRlAuDQoNCkx1Y3kNCg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0gDQpTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6 MjAgQU0NClRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgSm9lbCBIYWxwZXJuIERpcmVjdDsg THVjeSB5b25nOyBOQVBJRVJBTEEsIE1BUklBIEg7IFh1eGlhb2h1OyBtaWtlYmlhbmNAYW9sLmNv bTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgc2Zj QGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZp Y2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkppbSwNCg0KSSBhbSBub3Qg d29yZHNtaXRoaW5nIGhlcmUsIGJ1dCByYXRoZXIgcXVlc3Rpb25pbmcgc29tZSBmdW5kYW1lbnRh bCBhc3N1bXB0aW9ucy4NCg0KVGhlIHZlcnkgZXhpc3RlbmNlIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGggY29uY2VwdCBpcyBmdW5kYW1lbnRhbCB0byB0aGUgYXJjaGl0ZWN0dXJlLiAgICBB cyBhbiBhbmFsb2d5LCBpbiBhIHRyYWRpdGlvbmFsIEwzIHJvdXRlZCBuZXR3b3JrIChleGNlcHRp bmcgb2JzY3VyZSBzb3VyY2Ugcm91dGluZyBvcHRpb25zKSwgb25lIGNvdWxkIHN0aWxsIG9ic2Vy dmUgdGhhdCBhIHBhcnRpY3VsYXIgZmxvdyBpcyBmb2xsb3dpbmcgYSBwYXJ0aWN1bGFyIHBhdGgg dGhyb3VnaCB0aGUgbmV0d29yaywgYnV0IHRoYXQgaXMgaW5jaWRlbnRhbCB0byB0aGUgYXJjaGl0 ZWN0dXJlIHJhdGhlciB0aGFuIGZ1bmRhbWVudGFsIHRvIHRoZSBhcmNoaXRlY3R1cmUuDQoNCiAg IFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0gDQpTZW50OiBNb25kYXksIEp1 bHkgMTQsIDIwMTQgMTE6MTIgQU0NClRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0 OyBMdWN5IHlvbmc7IE5BUElFUkFMQSwgTUFSSUEgSDsgWHV4aWFvaHU7IG1pa2ViaWFuY0Bhb2wu Y29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KUXVlc3Rpb246IHdoZXJl IGV4YWN0bHkgZG9lcyBpdCBzcGVjaWZ5IHRoYXQgdGhlIFNGUCAqbXVzdCogYmUNCnByZS1pbnN0 YW50aWF0ZWQ/IFdoYXQgZXhhY3RseSBpcyB3cm9uZyB3aXRoIHRoZSB3b3JkaW5nIOKAnFdoZW4g YW4gU0ZDIGlzDQppbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpcyBuZWNlc3Nhcnkg dG8gc2VsZWN0IHRoZSBzcGVjaWZpYw0KaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNl ZCwgYW5kIHRvIGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3INCnRoYXQgU0ZDIHVzaW5n IFNG4oCZcyBuZXR3b3JrIGxvY2F0b3Jz4oCdPyBMZXTigJlzIHRyeSB0byBiZSBzcGVjaWZpYyBy YXRoZXINCnRoYW4gZGFuY2luZyBhcm91bmQgdGhlIHdvcmRpbmcuDQoNCk9uIDcvMTQvMTQsIDEx OjAwIEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdy b3RlOg0KDQo+SGksIEpvZWwsDQo+DQo+SSBxdW90ZSBmcm9tIHRoZSB0aGUgbWVyZ2VkIGFyY2hp dGVjdHVyZSBkcmFmdDoNCj4NCj48YmVnaW4gcXVvdGF0aW9uPg0KPlNlcnZpY2UgRnVuY3Rpb24g Q2hhaW4gKFNGQyk6ICBBIHNlcnZpY2UgRnVuY3Rpb24gY2hhaW4gZGVmaW5lcyBhbg0KPiAgICAg ICAgb3JkZXJlZCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBtdXN0IGJlIGFwcGxpZWQg dG8gcGFja2V0cw0KPiAgICAgICAgYW5kL29yIGZyYW1lcyBzZWxlY3RlZCBhcyBhIHJlc3VsdCBv ZiBjbGFzc2lmaWNhdGlvbi4gIFRoZQ0KPiAgICAgICAgaW1wbGllZCBvcmRlciBtYXkgbm90IGJl IGEgbGluZWFyIHByb2dyZXNzaW9uIGFzIHRoZQ0KPiAgICAgICAgYXJjaGl0ZWN0dXJlIGFsbG93 cyBmb3Igbm9kZXMgdGhhdCBjb3B5IHRvIG1vcmUgdGhhbiBvbmUgYnJhbmNoLg0KPiAgICAgICAg VGhlIHRlcm0gc2VydmljZSBjaGFpbiBpcyBvZnRlbiB1c2VkIGFzIHNob3J0aGFuZCBmb3Igc2Vy dmljZQ0KPiAgICAgICAgZnVuY3Rpb24gY2hhaW4uDQo+DQo+ICAgU2VydmljZSBGdW5jdGlvbiBQ YXRoIChTRlApOiAgVGhlIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZQ0KPiAgICAgICAg bmV0d29yay4gIFBhY2tldHMgZm9sbG93IGEgc2VydmljZSBmdW5jdGlvbiBwYXRoIGZyb20gYQ0K PiAgICAgICAgY2xhc3NpZmllciB0aHJvdWdoIHRoZSByZXF1aXNpdGUgc2VydmljZSBmdW5jdGlv bnMNCj4NCj5XaGVuIGFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBp cyBuZWNlc3NhcnkgdG8NCj4gICBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMg dGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0byBjcmVhdGUNCj4gICB0aGUgc2VydmljZSB0b3BvbG9n eSBmb3IgdGhhdCBTRkMgdXNpbmcgU0YncyBuZXR3b3JrIGxvY2F0b3IuICBUaHVzLA0KPiAgIGlu c3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluIHRoZSBjcmVhdGlvbiBvZiBhIFNlcnZp Y2UNCj4gIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yIGZvcndhcmRpbmcgcGFj a2V0cyB0aHJvdWdoIHRoZQ0KPiAgIFNGQy4gIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMgdGhl IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPg0KPihTZWN0aW9uIDQuMyBTRkYp DQo+U0ZQIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2Vydmlj ZSBwYXRoIGlkZW50aWZpZXINCj4gICB0aGF0IGlzIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkg YW4gU0ZQLg0KPjxlbmQgcXVvdGF0aW9uPg0KPg0KPg0KPk15IHJlYWRpbmcgb2YgdGhlIFNlY3Rp b24gNC4zLCBnaXZlbiB0aGUgZGVmaW5pdGlvbnMgcHJlc2VudGVkIGJlZm9yZSBpdCwNCj5pcyB0 aGF0IGFuIGVuZC10by1lbmQgZnVsbHkgaW5zdGFudGlhdGVkIHBhdGggaXMgc2VsZWN0ZWQgYW5k IHRoZW4gdXNlZA0KPnRvIHN0ZWVyIHRyYWZmaWMgdG8gdGhlIHJlcXVpc2l0ZSBTRkYncyBhbmQg U0Yncy4gICBXaGlsZSB0aG9zZQ0KPmRlZmluaXRpb25zIGNvdWxkIHN0aWxsIGFwcGx5LCBldmVu IGluIGEgZGlzdHJpYnV0ZWQgaW5zdGFuY2UgYXNzaWdubWVudA0KPmFwcHJvYWNoLCB0aGUgY29u dGV4dCBhcm91bmQgdGhvc2UgZGVmaW5pdGlvbnMgY2hhbmdlLiAgIEEgcGFydGljdWxhcg0KPmZs b3cgd291bGQsIGluZGVlZCBzdGlsbCBmb2xsb3cgc29tZSBwYXJ0aWN1bGFyIHBhdGgsIGJ1dCB0 aGVyZSB3b3VsZCBiZQ0KPm5vIG5lZWQgdG8gYXNzb2NpYXRlIGEgcGF0aCBJRCB0byBpdCBhbmQg dGhlcmUgd291bGQgYmUgbm8gbmVlZCB0bw0KPihsYXRlcikgYnVpbGQgYSBjb250cm9sIHBsYW5l IGFyb3VuZCBkaXN0cmlidXRpb24gb2YgdGhpcyBwYXRoIElEIGFuZA0KPm1haW50ZW5hbmNlIG9m IHRob3NlIHBhdGggSURzIGluIHRoZSBmYWNlIG9mIGluZXZpdGFibGUgZmFpbHVyZXMuDQo+DQo+ SSBhbSBleHBsb3JpbmcgdGhlIGFsdGVybmF0aXZlIHdoZXJlIGZvcndhcmRpbmcgaXMgcGVyZm9y bWVkIGJhc2VkIG9uIHRoZQ0KPmFic3RyYWN0IFNGQyBJRCB3aXRob3V0IHJlcXVpcmluZyB0aGUg Y29uY2VwdCBvZiBhIGNlbnRyYWxseSBrbm93biBTRlAgdG8NCj5leGlzdCBhdCBhbGwuICAgSW4g dGhpcyBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgdGhlIGluc3RhbmNlIHNlbGVjdGlvbiBpcw0KPmRp c3RyaWJ1dGVkIHRvIHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGJ3MuICAgQW55IGRlc2lyZWQg cG9saWN5IHVzZWQgdG8NCj5mbGF2b3IgaW5zdGFuY2Ugc2VsZWN0aW9uIGlzIHN0aWxsIHN1cHBv cnRlZCwgYnV0IHN1Y2ggcG9saWN5IHdvdWxkLA0KPmluZGVlZCwgbmVlZCB0byBiZSBhdmFpbGFi bGUgdG8gdGhlIGludm9sdmVkIGVudGl0aWVzLiAgIFRoaXMgd291bGQgYWxzbw0KPmJlIGFuIGV4 Y2VsbGVudCB1c2Ugb2YgbWV0YWRhdGEgd2hlcmUgdGhlIGluaXRpYWwgaW5ncmVzcyBub2RlIGNv dWxkIGFkZA0KPm9uZSBvciBtb3JlIHBpZWNlcyBvZiBtZXRhZGF0YSB0aGF0IGRvd25zdHJlYW0g bm9kZXMgY291bGQgbWFrZSB1c2Ugb2YgaW4NCj50aGVpciBwb2xpY3kgZGVjaXNpb25zLg0KPg0K PiAgICBSb24NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEpvZWwg SGFscGVybiBEaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCj5TZW50 OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6MzkgQU0NCj5UbzogTHVjeSB5b25nOyBOQVBJRVJB TEEsIE1BUklBIEg7IFJvbiBQYXJrZXI7IFh1eGlhb2h1Ow0KPm1pa2ViaWFuY0Bhb2wuY29tOyBq Z3VpY2hhckBjaXNjby5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+am1oQGpv ZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtzZmNdIFJlZGVmaW5l IHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+QmFsYW5jZXJz DQo+DQo+Q2FuIHdlIGZpcnN0IGZpZ3VyZSBvdXQgd2hhdCB3ZSBtZWFuIGJ5IGEgc2VydmljZSBw YXRoPw0KPk9uY2Ugd2UgaGF2ZSB0aGF0LCBJIGJlbGlldmUgd2UgY2FuIHdvcmsgb3V0IHdoYXQg d2Ugd2FudCB0aGUNCj5hcmNoaXRlY3R1cmUgdG8gcmVxdWlyZSBvZiBzb2x1dGlvbnMgaW4gdGVy bXMgb2YgY2FycnlpbmcgaW5mb3JtYXRpb24gaW4NCj50aGUgcGFja2V0LiAgQnV0IHNpbmNlIGZv bGtzIGhhdmUgYmVlbiByZWFkaW5nIHRoZSBleGlzdGluZyBkZWZpbml0aW9ucw0KPmFuZCBjb21p bmcgdG8gZGlmZmVyZW50IG1lYW5pbmdzLCBhbmQgaGF2ZSBiZWVuIG5vdGluZyBjb3JyZWN0bHkN Cj5jb250cmFkaWN0aW9ucyBpbiB0aGUgd29yZHMgd2UgY2hvc2UgZm9yIHRoZSBleGlzdGluZyBk ZWZpbml0aW9uLCBJDQo+d291bGQgcmVhbGx5IGFwcHJlY2lhdGVkIGl0IGlmIGZvbGtzIHdvdWxk IGNvbW1lbnQgb24gdGhlIGRlZmluaXRpb24gb2YNCj5zZXJ2aWNlIGZ1bmN0aW9uIHBhdGggdGhh dCBJIHNlbnQgdG8gdGhlIGxpc3QuDQo+DQo+WW91cnMsDQo+Sm9lbA0KPg0KPk9uIDcvMTQvMTQs IDk6MzAgQU0sIEx1Y3kgeW9uZyB3cm90ZToNCj4+IENvbnF1ZXIgd2hhdCBNYXJpYSBzYXlzLg0K Pj4NCj4+IEx1Y3kNCj4+DQo+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddICpPbiBCZWhhbGYgT2YgKk5BUElFUkFMQSwNCj4+TUFSSUEgSA0KPj4gKlNlbnQ6KiBNb25k YXksIEp1bHkgMTQsIDIwMTQgODoyMSBBTQ0KPj4gKlRvOiogUm9uIFBhcmtlcjsgWHV4aWFvaHU7 IG1pa2ViaWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNjby5jb207DQo+PiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tOyBqbWhAam9lbGhhbHBlcm4uY29tOyBzZmNAaWV0Zi5vcmcNCj4+ICpT dWJqZWN0OiogUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZA0KPj4gTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBUaGUgbWVhbmluZyBvZiB0aGUg U0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8gbWUg4oCTIGFuIGFic3RyYWN0DQo+ PiBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNl cyAoaS5lLiwgU0ZQIElEIDENCj4+ID0ge1NGLUEtMSwgU0YtQi0zLCBTRi1DLTJ9KS4gICAgSW4g c29tZSB3YXlzLCBpdCBpcyBhIGNvbGxhcHNlZCDigJxsYWJlbA0KPj4gc3RhY2vigJ0g4oCTIHRo ZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5ldHdvcmsNCj4+ IGxvY2F0aW9ucy4gICBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBsZWFzdCB0byBtZSwgdGhh dCB0aGVyZSBpcyBhDQo+PiBjZW50cmFsIHBvaW50IG9mIHNlbGVjdGlvbiBmb3IgdGhpcyBlbmQg dG8gZW5kIHNlcXVlbmNlIChiYXJyaW5nDQo+PiByZWNsYXNzaWZpY2F0aW9uLCBvZiBjb3Vyc2Up LiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQNCj4+IGltcGxpY2F0aW9uLiAgICBJ IGhhdmUgYmVlbiB1bmNvbWZvcnRhYmxlIHdpdGggdGhhdCBjZW50cmFsIHBvaW50DQo+PiBtZXRo b2RvbG9neSBkdWUgdG8gcmVhbC13b3JsZCBjb21wbGV4aXRpZXMgb2YgZHluYW1pYyBzY2FsZSBh bmQNCj4+IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMuDQo+Pg0KPj4gPE1hcmlh PiBJIGFncmVlLiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0 dXJlIHRoYXQNCj4+IHNvbWV0aGluZyBjYWxsZWQg4oCcc2VydmljZSBmdW5jdGlvbiBwYXRoIElE 4oCdIGlzIGNhcnJpZWQgaW4gdGhlIHBhY2tldCwNCj4+IGJlY2F1c2UgaXQgaXMgbm90IG5lY2Vz c2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVtZW50IHNlcnZpY2UNCj4+IGNoYWluaW5nLiBU aGVyZSBtaWdodCBzb2x1dGlvbnMgdGhhdCB3b3VsZCBkbyB0aGF0IGJ1dCBpdCBjYW5ub3QgYW5k DQo+PiBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZC4NCj4+DQo+PiBNYXJpYQ0KPj4NCj4+ IEFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIGlzIHRvIHN0aWxsIHVzZSBjZW50cmFsIHNlbGVjdGlv biB0byBzZWxlY3QgdGhlDQo+PiBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNlIGZ1bmN0aW9ucyAo aS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwNCj4+IFNGLUN9KSwgYnV0IGFsbG93IHRoZSBh Y3R1YWwgaW5zdGFuY2Ugc2VsZWN0aW9uIHRvIGJlIGRpc3RyaWJ1dGVkLA0KPj4gcmVhbGl6ZWQg YnkgdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkZzLg0KPj4NCj4+IEdpdmVuIGEgdG9wb2xvZ3kg bGlrZToNCj4+DQo+PiBDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0t LS0tIFNGRi0yDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0tLS0tLS0tLS0tLS0t LS1TRkYtNA0KPj4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg IHwNCj4+ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4NCj4+ICAg ICAgICAgICAgICAgICAgICAgIFNGRi1BLTEgICAgICAgU0ZGLUEtMiAgICAgICBTU0YtQi0xDQo+ PiBTRkYtQi0yICAgICAgICAgU0ZGLUMtMSAgICAgICBTRkYtQy0yICAgICAgICAgICAgICAgICAg IFNGRi1BLTMNCj4+DQo+PiBBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRo ZSBzZXF1ZW5jZSBjb3VsZCBnbyBzb21ldGhpbmcNCj4+IGxpa2UgdGhpczoNCj4+DQo+PiAxIENs YXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwgU0YtQiwgU0YtQ30NCj4+DQo+ PiAyIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0 YW5jZSBvZiBTRi1BDQo+Pg0KPj4gMyBDbGFzc2lmaWVyIGVuY2Fwc3VsYXRlcyBwYWNrZXQgaW5k aWNhdGluZyBjaGFpbiBJRCA9IDEsIHNlcnZpY2UgaW5kZXgNCj4+PSAxDQo+Pg0KPj4gNCBDbGFz c2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xDQo+Pg0KPj4gNSBTRkYtMSwgc2VlaW5n IGNoYWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3QgaXRz DQo+PiBhdmFpbGFibGUgaW5zdGFuY2VzIG9mIFNGLUENCj4+DQo+PiA2IFNGRi0xIHNlbmRzIHBh Y2tldCB0byBTRkYtQS0xDQo+Pg0KPj4gNyBTRkYtQS0xIHNlbmRzIHBhY2tldCBiYWNrIHRvIFNG Ri0xDQo+Pg0KPj4gOCBTRkYtMSBpbmNyZW1lbnRzIHNlcnZpY2UgaW5kZXggdG8gMg0KPj4NCj4+ IDggU0ZGLTEgc2VsZWN0cyBTRkYtMiBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBv ZiBTRi1CDQo+Pg0KPj4gOSBTRkYtMSBwcm9ncmVzc2VzIHBhY2tldCB0byBTRkYtMg0KPj4NCj4+ IDEwIHByb2Nlc3MgcmVwZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMsIGFzIHRoZSBlZ3Jlc3Mg Ym9yZGVyLA0KPj4gcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciByb3V0aW5nIHRhYmxlDQo+Pg0K Pj4gVGhhbmtzLg0KPj4NCj4+ICAgICBSb24NCj4+DQo+PiAqRnJvbToqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKlh1eGlhb2h1DQo+PiAqU2VudDoqIFN1 bmRheSwgSnVseSAxMywgMjAxNCAxMTozMCBQTQ0KPj4gKlRvOiogbWlrZWJpYW5jQGFvbC5jb20g PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47IGpndWljaGFyQGNpc2NvLmNvbQ0KPj4gPG1haWx0 bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQu Y29tPjsNCj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gPG1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPjsNCj4+IGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtlcjsNCj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+ICpTdWJqZWN0OiogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4+IEJhbGFuY2Vycw0KPj4NCj4+IEFncmVl IHRoYXQgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGluIHRoZSBhcmNoIGRyYWZ0 IGlzIGEgYml0DQo+PmNvbmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBoYWQgcG9pbnRlZCBvdXQu DQo+Pg0KPj4NCj4+DQo+PiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgU0ZQIGFzIGFuIGluc3Rh bnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZQ0KPj5uZXR3b3JrIHNob3VsZCBiZSDigJxhbiBvcmRl cmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBhbmQgU0YgSURz4oCdKHNlZQ0KPj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctcGNlLWJhc2VkLXNmYy1hcmNoLTAxKS4g T2YNCj4+Y291cnNlLCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4gdGhlIGRhdGEgcGFja2V0 IGlzIGFub3RoZXIgdGhpbmcNCj4+KGUuZy4sIGVpdGhlciB0aHJvdWdoIGEgcGF0aCBpZCBvciB0 aHJvdWdoIGFuIE1QTFMgbGFiZWwgc3RhY2spLiBIZXJlDQo+PnRoZSBzZXJ2aWNlIG5vZGUgbWVh bnMgdGhlIGRldmljZSB3aGljaCBjb250YWlucyB0aGUgU0ZGIGFuZCB0aGUgTkYNCj4+Y29tcG9u ZW50cyBtYW5kYXRvcmlseSB3aGlsZSBjb250YWluaW5nIHRoZSBTRiBhbmQgU0YgcHJveHkgY29t cG9uZW50cw0KPj5vcHRpb25hbGx5LiBUaGUgc2VydmljZSBub2RlIGNvdWxkIGJlIGF0dGFjaGVk IG9yIGVtYmVkZGVkIHdpdGggbXVsdGlwbGUNCj4+U0YgaW5zdGFuY2VzIGFuZCB0aG9zZSBTRiBp bnN0YW5jZXMgY291bGQgYmUgb2YgdGhlIHNhbWUgU0YgdHlwZSBvciBub3QuDQo+PiBJbiB0aGUg Y2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU0YgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIFNG IHR5cGUNCj4+KGUuZy4sIFNGIFgpIGFyZSBhdHRhY2hlZCB0byBhIGdpdmVuIHNlcnZpY2Ugbm9k ZSwgdGhlIHNlcnZpY2Ugbm9kZQ0KPj5jb3VsZCBkaXN0cmlidXRlIHRoZSB0cmFmZmljIHdoaWNo IG5lZWRzIFNGIFggYW1vbmcgdGhvc2UgU0YgaW5zdGFuY2VzDQo+Pm9mIFNGIFggdHlwZSBsb2Nh bGx5LiBNZWFud2hpbGUsIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBzZXJ2aWNlIG5vZGVzDQo+Pndp dGhpbiBhIGdpdmVuIFNGQy1lbmFibGVkIGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3IgYXR0 YWNoZWQgd2l0aA0KPj50aGUgU0YNCj4gIGluc3RhbmNlDQo+cyBvZiB0aGUgc2FtZSBTRiB0eXBl LiBJbiB0aGlzIHdheSwgdGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxkIGJlIG1hZGUNCj52ZXJ5 IGZsZXhpYmxlLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBYaWFvaHUNCj4+DQo+PiAq RnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4+ ICptaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gKlNlbnQ6 KiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2IEFNDQo+PiAqVG86KiBqZ3VpY2hhckBjaXNj by5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+OyBtbjE5MjFAYXR0LmNvbQ0KPj4gPG1h aWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGptaEBqb2VsaGFscGVybi5jb20N Cj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3 b3Jrcy5jb20NCj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT47IHNm Y0BpZXRmLm9yZw0KPj48bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ICpTdWJqZWN0OiogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gV291 bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNlIGNoYWluIGlkZW50aWZpZXIiIHRoZW4/ ICBJZiB0aGUNCj4+IHNlcnZpY2UgY2hhaW4gaXMgdGhlIG9yZGVyZWQgbGlzdCBvZiBTRnMgYW5k IHRoZSBzZXJ2aWNlIHBhdGggaXMgdGhlDQo+PiBvcmRlcmVkIGxpc3Qgb2YgU0YgaW5zdGFuY2Vz LCB0aGVuIEkgd291bGQgaW5mZXIgdGhhdCBhICJzZXJ2aWNlIHBhdGgNCj4+IGlkZW50aWZpZXIi IHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBhIHNlcnZp Y2UNCj4+ICpjaGFpbiouDQo+Pg0KPj4NCj4+IEFnYWluLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUg dGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGluZyBpbi4gIFRoZSB0ZXJtcw0KPj4gImNoYWluIiBh bmQgInBhdGgiIHNlZW0gaW5jb25zaXN0ZW50Lg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4N Cj4+ICpGcm9tOiAqamd1aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNpc2NvLmNvbQ0KPj4gPG1h aWx0bzpqZ3VpY2hhckBjaXNjby5jb20lM2NqZ3VpY2hhckBjaXNjby5jb20+Pg0KPj4gKlRvOg0K Pj4gDQo+PiptaWtlYmlhbmNAYW9sLmNvbTxtaWtlYmlhbmNAYW9sLmNvbT4sbW4xOTIxQGF0dC5j b208bW4xOTIxQGF0dC5jb20+LG1vaGENCj4+bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2VsaGFscGVybi5jbw0KPj5tPGptaEBqb2Vs aGFscGVybi5jb20+LFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208Um9uX1BhcmtlckBh ZmZpcm1lDQo+PmRuZXR3b3Jrcy5jb20+LHNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmcNCj4+IA0K Pj48bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNjbWlrZWJpYW5jQGFvbC5jb20lM2UsbW4xOTIx QGF0dC5jb20lM2NtbjE5MjFADQo+PmF0dC5jb20lM2UsbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2UNCj4+LGptaEBqb2VsaGFscGVy bi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cw0KPj4uY29tJTNjUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzZSxzZmNAaWV0Zi5v cmclM2NzZmNAaWV0Zi5vcmc+Pg0KPj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkgMTEsIDIwMTQNCj4+ ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+Pg0KPj4gWW91ciBkZWZpbml0aW9uIG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0 IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoDQo+PiB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2ls bCBhY3R1YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IGhvd2V2ZXIg cG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3RydWN0dXJlIGFuZCB0aGF0IGlzIHRo ZW4NCj4+IHJlc29sdmVkIHRvIHNwZWNpZmljIGluc3RhbmNlcyBiYXNlZCB1cG9uIHdoaWNoIG5l eHQtaG9wcyB0byB0aG9zZQ0KPj4gaW5zdGFuY2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVy IGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBpcyBpbg0KPj4gcGxheS4gV2hlbiBpbnN0YW50 aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1heSBvcg0KPj4g bWF5IG5vdCB1cGRhdGUgdGhhdCBkYXRhIHN0cnVjdHVyZSB0byBzcGVjaWZ5IHdoaWNoIG5leHQt aG9wcyBtYXkgYmUNCj4+IHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxkIGVmZmVj dGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aA0KPj4gZm9yIHRoYXQgc2VydmljZSBjaGFp bikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvDQo+PiBtZWNo YW5pc20gdG8gcG9wdWxhdGUgdGhlIGRhdGEgc3RydWN0dXJlIGZvciB5b3UuDQo+Pg0KPj4gKkZy b206ICoibWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4iDQo+PiA8 bWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4+DQo+PiAqRGF0ZTog KkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KPj4gKlRvOiAqSmltIEd1aWNoYXJk IDxqZ3VpY2hhckBjaXNjby5jb20gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwNCj4+ICJt bjE5MjFAYXR0LmNvbSA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTkyMUBhdHQuY29tDQo+ PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IiA8bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Pj4sICJqbWhAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ IiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4s ICJSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tDQo+PiA8bWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20+Ig0KPj4gPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20NCj4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+LCAic2ZjQGll dGYub3JnDQo+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+Pg0KPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+DQo+PiBJIHRoaW5rIHRoaXMgaXMgdGhlIHJvb3Qg b2YgdGhlIGNvbmZ1c2lvbjoNCj4+DQo+Pj4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0KPj4+ IHNwZWNpZmljIGluc3RhbmNlcyBvZiBTMSwgUzIsIGFuZCBTMyAob3Igc29tZSBjb21iaW5hdGlv biB0aGVyZW9mKS4gSQ0KPj4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEw MOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8NCj4+PlMxLT5TMi0+UzMNCj4+PiBhbmQgdGhl biBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KPj4NCj4+IEJ5IGRlZmluaXRpb24sIEkgdW5k ZXJzdG9vZCBhICJzZXJ2aWNlIHBhdGgiIHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZg0KPj4gc3Bl Y2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgInNl cnZpY2UgcGF0aA0KPj4gaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2aWNlICpjaGFpbiog dGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0NCj4+IHNwZWNpZnkgc3BlY2lmaWMgaW5zdGFu Y2VzIi4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiAqRnJvbTogKmpndWljaGFyQGNp c2NvLmNvbQ0KPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PGpndWljaGFyQGNpc2NvLmNv bQ0KPj48bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+DQo+PiAqVG86ICpOQVBJRVJBTEEsIE1B UklBIEg8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+LEpvZWwgTS4NCj4+IEhhbHBlcm48am1oQGpvZWxoYWxwZXJu LmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixSb24NCj4+IFBhcmtlcjxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tDQo+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNA aWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KPj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkg MTEsIDIwMTQNCj4+ICpTdWJqZWN0OiAqUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywg YW5kIExvYWQgQmFsYW5jZXJzDQo+Pg0KPj4gTWFyaWEsDQo+Pg0KPj4gSSB0aGluayBvZiBpdCB0 aGlzIHdheS4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIHNpbXBseSBhIHBvaW50ZXIN Cj4+dG8NCj4+IGEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhvcCBt YXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lDQo+PmENCj4+IGNoYWluLCBsZXTigJlzIHNheSBTMSAt PlMyLT4gUzMsIHlvdSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5DQo+PiB0 aGUgc3BlY2lmaWMgbmV4dC1ob3BzIHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91 Z2ggZm9yIHRoYXQNCj4+U0ZQLg0KPj4gSG93ZXZlciwgeW91IGRvICpub3QqIGhhdmUgdG8gZG8g dGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2ludA0KPj4oSQ0KPj4gd2lsbCBhcmd1 ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlvdSBkb27igJl0IGhhdmUgdG8gYXJjaGl0ZWN0dXJhbGx5 KS4gWW91DQo+PiBjb3VsZCBzaW1wbHkgYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg dG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMNCj4+YW5kDQo+PiB0aGVuIHB1c2ggdGhhdCBpbmZvcm1h dGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhDQo+PiBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciB0byBTRkMgbWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxk IGNvbnRhaW4NCj4+dGhlDQo+PiBuZXh0LWhvcHMgYXZhaWxhYmxlIGZvciBlYWNoIG9mIHRoZSBT RuKAmXMgd2l0aGluIHRoZSBTRkMgLSBob3cgeW91IGxlYXJuDQo+PiB0aG9zZSBuZXh0LWhvcHMg aXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhDQo+PmNlbnRyYWxp emVkDQo+PiBjb250cm9sbGVyLCBjb25maWd1cmUgdGhlbSB0aHJvdWdoIENMSSwgbGVhcm4gdGhl bSBkeW5hbWljYWxseSB0aHJvdWdoDQo+PiBzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3aGF0ZXZl ciAuLiBTbywgZ2l2ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bw0KPj4gc2F5IHRoYXQgdGhl IHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMgYXJlIGNob3NlbiBhDQo+ PnByaW9yaQ0KPj4gYWx0aG91Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21l IHdvdWxkIHNheSByZWNvbW1lbmRlZCkgdG8NCj4+ZG8NCj4+IHNvLg0KPj4NCj4+IExldOKAmXMg dGFrZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6DQo+Pg0KPj4gSSBk ZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBG b3IgYXJndW1lbnRzDQo+PiBzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBk eW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8NCj4+c3BlY2lmeQ0KPj4gc3BlY2lmaWMgaW5z dGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJ DQo+PiBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNp Y2FsbHkgcG9pbnRzIHRvDQo+PlMxLT5TMi0+UzMNCj4+IGFuZCB0aGVuIHB1c2ggdGhpcyBpbnRv IHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQo+PiBwb3B1 bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJh ZmZpYw0KPj5hcnJpdmVzDQo+PiB3aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhl IFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0KPj4gc3RydWN0dXJlIGFuZCBmaW5k IHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQo+ PiBlbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBj aGFpbi4gTGV04oCZcyBzYXkNCj4+d2UNCj4+IGFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBT RkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KPj4gUzMgYW5kIHdp bGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCj4+DQo+ PiBPbiA3LzExLzE0LCAxMToyNiBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQu Y29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQo+Pg0KPj4gID5KaW0sDQo+ PiAgPg0KPj4gID5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEg InNlcnZpY2UgcGF0aCIgYW5kIGENCj4+ICA+InNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIj8NCj4+ ICA+SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9z ZW4gYXByaW9yaQ0KPj4od2hpY2gNCj4+ICA+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0 aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPj4gID5uZXh0LWhvcCBT RkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi4NCj4+ICA+DQo+PiAgPk1h cmlhDQo+PiAgPg0KPj4gID4NCj4+ICA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g ID4+DQo+Pg0KPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hh ckBjaXNjby5jb21dDQo+PiAgPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDExOjE1IEFN DQo+PiAgPj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbQ0KPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgSm9lbCBNLg0K Pj4gID4+IEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ICA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+ICA+Pg0KPj4gID4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxs eSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoDQo+PmlkZW50aWZpZXINCj4+ ICA+PiBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0LWhvcHMgb3Igd2h5IGNh bGxpbmcgaXQgYQ0KPj5zZXJ2aWNlDQo+PiAgPj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkg ZGlmZmVyZW5jZT8NCj4+ICA+Pg0KPj4gID4+IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVS QUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+ PiB3cm90ZToNCj4+ICA+Pg0KPj4gID4+ID5EaXR0by4NCj4+ICA+PiA+DQo+PiAgPj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiA+PiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ PiAgPj4gPj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPj4gID4+ID4+ IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4gID4+ID4+IFRvOiBKaW0g R3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uDQo+PkhhbHBl cm47IFJvbg0KPj4gID4+ID4+IFBhcmtlcjsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gID4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+ID4+DQo+PiAgPj4gPj4gUmUtLA0KPj4gID4+ID4+ DQo+PiAgPj4gPj4gRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3Jp YmVkIGNsZWFybHkgaW4gdGhlDQo+PiAgPj5kcmFmdC4NCj4+ICA+PiA+Pg0KPj4gID4+ID4+IE1h bmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhh dCB0aGUNCj4+ZnVsbA0KPj4gID4+ID4+ZGlzdHJpYnV0ZWQNCj4+ICA+PiA+PiBtb2RlbCBpcyBu b3QgYWxsb3dlZC4NCj4+ICA+PiA+Pg0KPj4gID4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMg dGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluDQo+Pml0c2VsZg0KPj4gID4+ ID4+c2hvdWxkIGJlDQo+PiAgPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4NCj4+ICA+PiA+Pg0KPj4g ID4+ID4+IENoZWVycywNCj4+ICA+PiA+PiBNZWQNCj4+ICA+PiA+Pg0KPj4gID4+ID4+ID4tLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ICA+PiA+PiA+RGUgOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0NCj4+R3VpY2hhcmQNCj4+ICA+PiA+ PiA+KGpndWljaGFyKQ0KPj4gID4+ID4+ID5FbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAy MDE0IDE2OjE4DQo+PiAgPj4gPj4gPsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhh bHBlcm47IFJvbiBQYXJrZXI7DQo+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+PiAgPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4gPg0KPj4gID4+ID4+ID5PayBidXQgd2hlcmUgaW4g dGhlIGFyY2hpdGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcw0KPj5mdW5jdGlvbmFsaXR5DQo+ PiAgPj4gPj4gPnByb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCogbmV4 dC1ob3BzIHRvICphbGwqDQo+PlNGRuKAmXMNCj4+ICA+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9t YWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50IHRvDQo+PmENCj4+ICA+ PiA+Pmxvb2t1cA0KPj4gID4+ID4+ID5pbnRvIHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUg bmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0gbm90DQo+PiAgPj5zdXJlDQo+PiAgPj4gPj5ob3cN Cj4+ICA+PiA+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPj4gID4+ID4+ID4N Cj4+ICA+PiA+PiA+T24gNy8xMS8xNCwgOTo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1u MTkyMUBhdHQuY29tDQo+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+ICA+PiB3cm90ZToN Cj4+ICA+PiA+PiA+DQo+PiAgPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPj4gID4+ID4+ID4+DQo+PiAg Pj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiAgPj4gPj4gPj4+IEZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+Pkd1 aWNoYXJkDQo+PiAgPj4gPj4gPj4+KGpndWljaGFyKQ0KPj4gID4+ID4+ID4+PiBTZW50OiBGcmlk YXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4gID4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBN QVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7DQo+PiBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+ID4+ID4+Pg0KPj4g ID4+ID4+ID4+PiBUaGVuIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2 ZXIsIGl0IHNlZW1zDQo+PnRvIG1lDQo+PiAgPj4gPj50aGF0IGlmDQo+PiAgPj4gPj4gPj4+IHlv dSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYg aXQNCj4+ICA+PndpbGwNCj4+ICA+PiA+PnVzZQ0KPj4gID4+ID4+ID4+PmZvcg0KPj4gID4+ID4+ ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0 aGVuIHlvdQ0KPj4gID4+YmV0dGVyDQo+PiAgPj4gPj5tYWtlDQo+PiAgPj4gPj4gPj4+IHN1cmUg dGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYw0K Pj50bw0KPj4gID4+ID4+cmVhY2gNCj4+ICA+PiA+PiA+Pj50aGUNCj4+ICA+PiA+PiA+Pj4gbmV4 dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcA0KPj50 cm91YmxlLg0KPj4gID4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFN LCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4+IDxtYWlsdG86bW4xOTIx QGF0dC5jb20+Pg0KPj4gID4+ID4+IHdyb3RlOg0KPj4gID4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+ PiA+QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25s eSBpbg0KPj4gID4+cmVsZXZhbnQNCj4+ICA+PiA+PiA+Pj5TRkZzDQo+PiAgPj4gPj4gPj4+ID53 aGVuIHRoZXkgImFycml2ZSIuDQo+PiAgPj4gPj4gPj4+ID4NCj4+ICA+PiA+PiA+Pj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+ICA+Pkd1aWNoYXJk DQo+PiAgPj4gPj4gPj4+ID4+KGpndWljaGFyKQ0KPj4gID4+ID4+ID4+PiA+PiBTZW50OiBGcmlk YXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4gID4+ID4+ID4+PiA+PiBUbzogSm9lbCBNLiBI YWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gID4+ID4+ID4+PiA+PiBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZA0KPj5CYWxhbmNlcnMNCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+ Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZQ0K Pj51bmRlcnN0b29kDQo+PiAgPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj5wcm9wb3NhbA0KPj4gID4+ ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBv ZiBldmVyeQ0KPj5zaW5nbGUNCj4+ICA+PlNGDQo+PiAgPj4gPj4gPj4+d2l0aGluDQo+PiAgPj4g Pj4gPj4+ID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWluIGF0IGV2ZXJ5 IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5DQo+PnRvDQo+PiAgPj5rbm93DQo+PiAgPj4g Pj5hDQo+PiAgPj4gPj4gPj4+ID4+cHJpb3JpDQo+PiAgPj4gPj4gPj4+ID4+IHdoaWNoIFNGQ8K5 cyBhIGdpdmVuIFNGRiB3aWxsIG5lZWQgdG8gc2VydmljZSBhdCBhbnkgZ2l2ZW4NCj4+ICA+PnBv aW50DQo+PiAgPj4gPj5pbg0KPj4gID4+ID4+ID4+PnRpbWUuDQo+PiAgPj4gPj4gPj4+ID4+DQo+ PiAgPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBNLiBIYWxwZXJuIg0K Pj4gPGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ ICA+PiA+PiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPlJvbiwg dGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yDQo+PnByb2JsZW0N Cj4+ICA+PndpdGgNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PnlvdXINCj4+ICA+PiA+ PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5kZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRt aXQgSSBtYXkNCj4+bm90DQo+PiAgPj4gPj4gPj4+dW5kZXJzdGFuZA0KPj4gID4+ID4+ID4+PiA+ PiA+aXQuKQ0KPj4gID4+ID4+ID4+PiA+PiA+DQo+PiAgPj4gPj4gPj4+ID4+ID5UaGUgcHJvcG9z YWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2VyIGZvcg0KPj50aGUNCj4+ ICA+PiA+Pm5leHQNCj4+ICA+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xs b3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycw0KPj4gID4+dG8pLA0KPj4gID4+ID4+aW4N Cj4+ICA+PiA+PiA+Pj5ldmVyeQ0KPj4gID4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0 IGdvZXMgdGhyb3VnaCBpdC4NCj4+ICA+PiA+PiA+Pj4gPj4gPg0KPj4gID4+ID4+ID4+PiA+PiA+ U2luY2UgaXQgaGFzIHRvIGJlIGFibGUgdG8gd29yayB3aXRoIGFsbCBzZXJ2aWNlcywgdGhhdA0K Pj5tZWFucw0KPj4gID4+ID4+dGhhdA0KPj4gID4+ID4+ID4+PiA+PmV2ZXJ5DQo+PiAgPj4gPj4g Pj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0aXZlIGFuZCBz dGF0ZWZ1bA0KPj5sb2FkDQo+PiAgPj4gPj4gPj4+YmFsYW5jZXIuDQo+PiAgPj4gPj4gPj4+ID4+ ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAv DQo+Pm9yDQo+PiAgPj4gPj5zdGF0ZWZ1bC4NCj4+ICA+PiA+PiA+Pj4gPj4gPkJ1dCBoYXZpbmcg dGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkgU0ZGIGJlIGENCj4+ZnVsbCwNCj4+ ICA+PiA+PmZsb3cNCj4+ICA+PiA+PiA+Pj4gPj4gPnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQg YmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4NCj4+ICA+PiA+PmFjY2VwdGFibGUNCj4+ICA+ PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4NCj4+ICA+PiA+PiA+ Pj4gPj4gPllvdXJzLA0KPj4gID4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gID4+ID4+ID4+PiA+PiA+ DQo+PiAgPj4gPj4gPj4+ID4+ID5PbiA3LzEwLzE0LCAxMDowNiBQTSwgSm9lbCBNLiBIYWxwZXJu IHdyb3RlOg0KPj4gID4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMg dGhhdCBJIGFtIHRyeWluZyB0byBtYWtlDQo+PnRoaXMNCj4+ICA+PndvcmsNCj4+ICA+PiA+PiA+ Pj4gPj5zZW5zaWJseQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVk IGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj4gID4+c2VydmljZQ0KPj4gID4+ID4+ ID4+PiA+PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBh YmlsaXRpZXMsDQo+PiAgPj53aWxsDQo+PiAgPj4gPj5iZQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBv cmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gSSBleHBlY3QgdGhlIHNlcnZpY2UgY2hhaW5zDQo+ PiAgPj50byBiZQ0KPj4gID4+ID4+ID4+PiA+PmRyaXZlbiBieQ0KPj4gID4+ID4+ID4+PiA+PiA+ PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMsIGFuZCBlbmFibGUN Cj4+ICA+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gID4+ID4+ID4+PiA+PiA+PiBmcm9tIHRo ZXNlLiBJIGV4cGVjdCBzZXJ2aWNlIHBhdGhzIHRvIGJlIGhlYXZpbHkgcG9saWN5DQo+PiAgPj4g Pj5kcml2ZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gSSBjYW4g c2VlIGhvdyB0byBtYWtlIGFsbCBvZiB0aGF0IHdvcmsgaW4gYW4NCj4+YXJjaHRpZWN0dXJlDQo+ PiAgPj4gPj5kcml2ZW4NCj4+ICA+PiA+PiA+Pj5ieQ0KPj4gID4+ID4+ID4+PiA+PiA+PiBpbml0 aWFsIGNsYXNzaWZpY2F0aW9uIHRvIGRlc2NyaWJlZCBzZXJ2aWNlIHBhdGhzLiBJdA0KPj5pcw0K Pj4gID4+ID4+aGFyZGVyDQo+PiAgPj4gPj4gPj4+dG8NCj4+ICA+PiA+PiA+Pj4gPj5zZWUNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4gaG93IHRvIG1ha2UgaXQgd29yayAoYnV0IGl0IGNhbiBiZSBkb25l KSB3aGVuIHdlIGFsbG93DQo+Pm1vcmUNCj4+ICA+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4g ID4+ID4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0 IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkDQo+PmlzDQo+PiAgPj4gPj5vdXRzaWRlDQo+PiAgPj4g Pj4gPj4+b2YNCj4+ICA+PiA+PiA+Pj4gPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4gc2NvcGUg b2YgdGhlIHdvcmtpbmcgZ3JvdXAuIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+PiAgPj4g Pj50YXNrZWQgdG8NCj4+ICA+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pm9u Lg0KPj4gID4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFu cyB3ZSBoYXZlIHRvIGRvIGl0IGENCj4+ICA+PmNlcnRhaW4NCj4+ICA+PiA+PiA+Pj53YXkuDQo+ PiAgPj4gPj4gPj4+ID4+aXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3Bl Y3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPj4gID4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiAg Pj4gPj4gPj4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0s IElhbiBTbWl0aCB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPj5pbnN0YW5jZXMNCj4+ICA+PiA+PiB0 aGF0DQo+PiAgPj4gPj4gPj4+ID4+bmVlZHMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBw b3RlbnRpYWxseQ0KPj5ldmVuDQo+PiAgPj4gPj5hY3Jvc3MNCj4+ICA+PiA+PiA+Pj5kYXRhDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4gY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2Nv cGUsIGlzIGxhcmdlDQo+PmVub3VnaA0KPj4gID4+YW5kDQo+PiAgPj4gPj4gPj4+IGNvbXBsZXgN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50 byBlYWNoIFNGRiBzZWVtcw0KPj5saWtlIGENCj4+ICA+PiA+PiA+Pj5kaWZmaWN1bHQNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhhdCBp cyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4NCj4+ICA+PmR5bmFtaWMNCj4+ICA+PiA+PiA+Pj4gcm91 dGluZywNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hl c3RyYXRpb24sIG9yIEROUywgYWxsIG9mDQo+PiAgPj53aGljaA0KPj4gID4+ID4+YXJlDQo+PiAg Pj4gPj4gPj4+ID4+YmlnZ2VyDQo+PiAgPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhh dmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkNCj4+aW1wbGVtZW50ZWQ/DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gSXQgYWxzbyBzZWVtcyB0aGF0IGlmIGl0 IHJlYWxseSBpcyBtb3JlIGNvbXBsaWNhdGVkLA0KPj50aGF0DQo+PiAgPj5pcw0KPj4gID4+ID4+ YQ0KPj4gID4+ID4+ID4+Pmdvb2QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBp cyB0b28gY29tcGxpY2F0ZWQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tDQo+ PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gU2Vu dDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4g VG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IG1pa2ViaWFuY0Bhb2wuY29tDQo+ PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+ICA+Pklhbg0KPj4gID4+ID4+ID4+PlNt aXRoOw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQNCj4+ICA+PkJhbGFuY2Vycw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1ZS4g QW5kIG9uZSB0aGF0IEkgd291bGQNCj4+ICA+PnByZWZlcg0KPj4gID4+ID4+d2UNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVy IHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4gID4+ID4+aW1wbGVtZW50YXRp b25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBl ZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4+ICA+PiA+PnJlcXVpcmVtZW50cw0KPj4gID4+ID4+ID4+ PmFuZA0KPj4gID4+ID4+ID4+PiA+PiB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9u YWxpdHkgb2YgU0ZGcy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPj5pbnN0 YW5jZXMNCj4+ICA+PiA+PnRoYXQNCj4+ICA+PiA+PiA+Pj4gbmVlZHMNCj4+ICA+PiA+PiA+Pj4g Pj4gdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFp bnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gID4+IGFjcm9zcw0KPj4gID4+ID4+ID4+PmRh dGENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZl IHNjb3BlLCBpcyBsYXJnZQ0KPj5lbm91Z2gNCj4+ICA+PmFuZA0KPj4gID4+ID4+ID4+PmNvbXBs ZXgNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBp bnRvIGVhY2ggU0ZGIHNlZW1zDQo+Pmxpa2UgYQ0KPj4gID4+ID4+ID4+PmRpZmZpY3VsdA0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gWW91cnMsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ PiBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4gQnV0IGl0 IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+IFRoaXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuIElzIHRoZSBlbmQgdG8g ZW5kDQo+PiAgPj5zZWxlY3Rpb24NCj4+ICA+PiA+Pm9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g KHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMNCj4+Ynkg dGhlDQo+PiAgPj4gPj4gPj4+ID4+Y2xhc3NpZmllcikNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBv ciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZA0KPj5zdWJzZXF1ZW50 bHkNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PlNGRnMpPw0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRp b24uDQo+PiAgPj5BbmQNCj4+ICA+PiA+PiA+Pj5zdXJlbHksDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBk aXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiAgPj4gdGhvdWdoDQo+PiAgPj4gPj4gYQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRp b25zIGFuZCBwZXJoYXBzDQo+PiAgPj5sb2NhbA0KPj4gID4+ID4+ID4+PiA+PnNlbGVjdGlvbg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJp YnV0ZWQgZGVjaXNpb24NCj4+cG9pbnRzLg0KPj4gID4+ID4+VGhpcw0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0 DQo+PmFsbC4NCj4+ICA+PiA+Pk15DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZv ciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlzIHByaW1hcmlseQ0KPj5kcml2ZW4NCj4+ICA+PmJ5 DQo+PiAgPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcmVzaWxp ZW5jeSBvdmVyIHRoZSBnbG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0aCBhDQo+PiAgPj5nbG9i YWwNCj4+ICA+PiA+PiA+Pj5wYXRoDQo+PiAgPj4gPj4gPj4+ID4+aWQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+PiBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBvZiBhbiBpbnN0YW5jZSBhbmQNCj4+ bmVlZGluZyB0bw0KPj4gID4+ID4+YWx0ZXINCj4+ICA+PiA+PiA+Pj50aGUNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0 ZWQNCj4+ICA+PmVuZC10by1lbmQNCj4+ICA+PiA+PiA+Pj5wYXRoLg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIEZyb206IHNmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRm Lm9yZyA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0NCj4+IG9uIGJlaGFsZiBvZiBKb2Vs IEhhbHBlcm4gRGlyZWN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhh bHBlcm4uY29tDQo+PiA8bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPl0gU2VudDog VGh1cnNkYXksIEp1bHkgMTAsDQo+PiAgPj4yMDE0DQo+PiAgPj4gPj4gNjoxNQ0KPj4gID4+ID4+ ID4+PiBQTQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFp bHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+IEkuU21pdGhARjUuY29tIDxtYWlsdG86SS5TbWl0 aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmcNCj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4g U3ViamVjdDoNCj4+ICA+PiA+PiBSZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVs cyB0aGUgY2FzZSBvZiBTRjENCj4+bmVlZGluZw0KPj4gID4+dG8NCj4+ICA+PiA+PiA+Pj4gPj5p bmZsdWVuY2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291 bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdA0KPj50aGUNCj4+ICA+PmV4aXQNCj4+ICA+PiA+PmZy b20NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIGRpZmZl cmVudCBmdW5jdGlvbnMNCj4+ICA+PiA+PmxvZ2ljYWxseQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRlc2NyaWJlIGhvdw0KPj50 aGV5DQo+PiAgPj4gPj4gY2hvb3NlDQo+PiAgPj4gPj4gPj4+dG8NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBjb21wb3NlIHRoZW0gZm9yICJzZXJ2aWNlIiBkZWxpdmVyeS4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtl YmlhbmNAYW9sLmNvbQ0KPj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gd3JvdGU6DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0 IHRoYXQNCj4+c3VnZ2VzdHMgYW55DQo+PiAgPj4gPj5zb3J0DQo+PiAgPj4gPj4gPj4+b2YNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRp Y2F0ZSB0aGF0IHRoZQ0KPj5lbnRpcmUNCj4+ICA+PiA+PnBhdGgNCj4+ICA+PiA+PiA+Pj4oYWxs DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0 YW50aWF0aW9uLiBJIGJlbGlldmUNCj4+ICA+PnRoaXMNCj4+ICA+PiA+PiA+Pj5tZWFucw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhl IGNsYXNzaWZpZXINCj4+ICA+PmNob29zZXMgYQ0KPj4gID4+ID4+U0YNCj4+ICA+PiA+PiA+Pj4g Pj5DaGFpbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRl c3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55DQo+PmNhc2UsDQo+PiAgPj4gPj50aGUNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEgbW9yZSBkeW5h bWljIFNGUA0KPj53aGVyZQ0KPj4gID4+ID4+IFNGSShuKQ0KPj4gID4+ID4+ID4+PiBpcw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXRlcm1pbmVkIGF0IHRoZSBTRkkobi0xKSBob3AuIEFjY29y ZGluZyB0byB0aGUNCj4+ZHJhZnQsDQo+PiAgPj4gPj50aGlzDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IGJlaGF2aW9yIHdvdWxkIGJlIGNvbnNpZGVyZWQgImJyYW5jaGluZyIgdG8gYSBuZXcNCj4+ U0ZQIGFzDQo+PiAgPj4gPj4gPj4+IG9wcG9zZWQNCj4+ICA+PiA+PiA+Pj4gPj4gdG8NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4gY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2Vs ZWN0ZWQNCj4+aW5zdGFuY2Ugb2YNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8g dGhlIG5ldHdvcmsgaXQgaXMNCj4+ICA+PiA+Pm5lY2Vzc2FyeQ0KPj4gID4+ID4+ID4+PnRvDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBT RnMgdGhhdCB3aWxsIGJlDQo+PnVzZWQsDQo+PiAgPj4gPj5hbmQgdG8NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcg U0Yncw0KPj4gID4+ID4+bmV0d29yaw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gbG9jYXRvci4g VGh1cywgaW5zdGFudGlhdGlvbiBvZiB0aGUgU0ZDIHJlc3VsdHMgaW4NCj4+dGhlDQo+PiAgPj4g Pj4gPj4+Y3JlYXRpb24NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5j dGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4gID4+ID4+Zm9yd2FyZGluZw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdv cmRzLCBhbiBTRlAgaXMNCj4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0 aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNzaWZp Y2F0aW9uIChvcg0KPj4gID4+ID4+bm9uLWluaXRpYWwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuDQo+PlNGUCwN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlw aWNhbGx5IHBlcmZvcm1lZA0KPj5ieSBhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lm aWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPj4gID4+ID4+ZnVu Y3Rpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1 bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhDQo+Pm5ldw0KPj4gID4+ID4+U0ZQLCBhbg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBi b3RoLiBUaGlzIGlzDQo+PiAgPj4gPj5yZWZlcnJlZA0KPj4gID4+ID4+ID4+PnRvDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+PiBhcyAiYnJhbmNoaW5nIi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+Pj4NCj4+ICA+PiA+ Pg0KPj4gID4+DQo+PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4tLQ0K Pj4gID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ICA+PiA+Pj4+Pj4+Pj4+Pj4tLS0NCj4+ICA+PiA+PiA+ Pj4+Pj4+Pj4+LS0NCj4+ICA+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+LS0NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0 aEBGNS5jb20NCj4+IDxtYWlsdG86KkkuU21pdGhARjUuY29tPjxJLlNtaXRoQEY1LmNvbSA8bWFp bHRvOkkuU21pdGhARjUuY29tPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBI YWxwZXJuDQo+PiAgPj4gRGlyZWN0PGptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+PiA8bWFp bHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPj4gID4+ID4+IE0uDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+DQo+PiAgPj4gPj4gPj4+DQo+PiAg Pj4gPj4NCj4+ICA+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPj4saHVhbmdAc2NlLmNhcmxldG9uLmNhDQo+PiA8bWFpbHRv Omh1YW5nQHNjZS5jYXJsZXRvbi5jYT48aHVhbmdAc2NlLg0KPj4gPG1haWx0bzpodWFuZ0BzY2Uu JTBiPj4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj5jYT4sc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86 c2ZjQGlldGYub3JnPj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ICpTZW50 OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gKlN1Ympl Y3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPj4gID4+ID4+ QmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0t c2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj4gID4+dGhhdCBpcw0KPj4gID4+ID4+ID4+PndoYXQN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkg b2Ygc2VydmljZSBjaGFpbnMgDQo+PmlzDQo+PiAgPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1 cmUgYnVyZGVuZWQgDQo+PndpdGgNCj4+ICA+PiB0aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IHByZWNvbmNlcHRpb24uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IFRoZXJlIGhhcyB0byBiZSBzb21lIHBvaW50IG9mIGFpbSwgc29tZSBkZWdyZWUgb2YN Cj4+ICA+PiA+PmFzcGlyYXRpb24NCj4+ICA+PiA+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+ PiBzY2FsZSB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGUgbGlmZXNwYW4gb2YgdGhlDQo+PiAg Pj4gPj5hcmNoaXRlY3R1cmUNCj4+ICA+PiA+PiA+Pj4tDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IHlvdSBkb24ndCBoYXZlIHRvIGtub3cgd2hhdCBpdCBpcywgYnV0IGJ5IHNheWluZyANCj4+dGhh dCBhbg0KPj4gID4+ID4+ID4+PmFyYml0cmFyeQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBudW1i ZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IA0KPj5pc24ndA0K Pj4gID4+ID4+ID4+PiA+PmludGVudGlvbmFsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IC0gYSBs aW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZSANCj4+bGFzdGluZw0KPj4g ID4+ID4+aW1wYWN0cw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWdhcmRpbmcgc2NhbGUtb3V0 LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksDQo+PiAgPj4gPj5hZGRyZXNzDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGluZ3MuIFRoYXQgaXMg YSBwcm9ibGVtIEknbSANCj4+bm90DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJs eSBlYWdlciB0byBkZWFsIHdpdGguDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdA0KPj4g W2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVy bi5jb20+XQ0KPj4gID4+ID4+U2VudDoNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXks IEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsIA0KPj5NLg0KPj4gID4+ ID4+IEhhbHBlcm47DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5j YQ0KPj4gPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+OyBzZmNAaWV0Zi5vcmcgPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW3NmY10NCj4+ICA+PiA+PlNlcnZpY2UN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElhbiwgSSBk b24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gDQo+PnRoaXMNCj4+ICA+ PiA+PnJlZ2FyZC4NCj4+ICA+PiA+PiA+Pj5JDQo+PiAgPj4gPj4gPj4+ID4+YW0NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNoaXRlY3R1cmUgb3IgdGhl IHNvbHV0aW9uDQo+PiAgPj4gPj5wcm9oaWJpdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBs b3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgDQo+PnRvDQo+ PiAgPj4gPj5IdWFuZydzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90 ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIA0KPj5hcmUNCj4+ICA+PiA+PiByZXF1 aXJlZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBz YWlkIHJlcGVhdGVkbHksIEkgYW0gbm90IHRyeWluZyB0byANCj4+cHJvaGliaXQNCj4+ICA+PnN1 Y2gNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29v ZCBpZGVhIG9yIG5vdCBkZXBlbmRzIA0KPj51cG9uDQo+PiAgPj4gPj4gbWFueQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBo YXBwZW4gdG8NCj4+ICA+PnRoaW5rDQo+PiAgPj4gPj50aGF0DQo+PiAgPj4gPj4gPj4+ID4+dGhl eQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBCdXQgdGhlIGFyY2h0aWVj dHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgDQo+PmF0dGVtcHRpbmcgdG8NCj4+ICA+PiA+Pmtu b3cNCj4+ICA+PiA+PiA+Pj53aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBu b3QgZXBsb3lhYmxlLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBZb3VycywgSm9lbA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiBPbiA3LzEwLzE0LCA1OjAxIFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+IFdlIHJvdXRpbmVseSBoYXZlIHN0YXRlZnVsIGRldmljZXMgdGhh dCBtYW5hZ2UgDQo+PnRlbnMgb2YNCj4+ICA+PiA+PiA+Pj5taWxsaW9ucw0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4gb2YNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBp biBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIA0KPj5jZW50ZXINCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4gZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGlldmUg DQo+PnRoYXQgaW4NCj4+ICA+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2 L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2YgdG9tb3Jyb3cgeW91DQo+PiAgPj4gYXJlDQo+ PiAgPj4gPj4gb25seQ0KPj4gID4+ID4+ID4+PiA+PiBnb2luZw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5 DQo+PiAgPj5zbWFsbA0KPj4gID4+ID4+ID4+PiBudW1iZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3 aWxsIGV2ZXIgbmVlZCANCj4+bW9yZQ0KPj4gID4+IHRoYW4NCj4+ICA+PiA+PiA+Pj4gNjRLIg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZv cnQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gRnJvbTogc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0 Zi5vcmcNCj4+IDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9l bCBNLiBIYWxwZXJuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFtqbWhAam9lbGhhbHBlcm4uY29t IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT5dDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBT ZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4gID4+ID4+ID4+Pmh1 YW5nQHNjZS5jYXJsZXRvbi5jYSA8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1 YmplY3Q6IFJlOg0KPj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPj4gID4+YW5kDQo+ PiAgPj4gPj4gPj4+TG9hZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gTm8sIGl0IHdpbGwg bWVhbiB0aGF0IGlmIHNvbWVvbmUgdHJpZXMgdG8gZGVwbG95IA0KPj50aGUNCj4+ICA+PiA+PiA+ Pj5hcmNodGlldHVyZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5 LCB0aGV5IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4+ICA+PnRoZWlyDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUg c3VjaCANCj4+YWJzdXJkDQo+PiAgPj4gdXNlDQo+PiAgPj4gPj4gb2YNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0 byANCj4+d3JpdGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hpdGVjdHVyYWwgd29yZHMg dG8gcHJvaGliaXQgaXQsIHRoZSANCj4+YXJjaGl0ZWN0dXJlDQo+PiAgPj5kb2VzDQo+PiAgPj4g Pj4gPj4+cGVybWl0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3Qg cmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiAgPj4gcGVybWl0cw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRoaW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVp c3JlZCBvciANCj4+cmVxdWlyZWQgYnkNCj4+ICA+PiA+PnRoZQ0KPj4gID4+ID4+ID4+Pndvcmsu DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENo YW5nY2hlbmcgSHVhbmcgd3JvdGU6DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5l ZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMsIGl0IHdpbGwNCj4+ICA+Pm1lYW4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiAxNiwwMDAsMDAwIHBhdGhzLiBUaGF0IGlzIGxhcmdlciB0 aGFuIHRoZSByb3V0aW5nDQo+PiAgPj50YWJsZQ0KPj4gID4+ID4+b2YgYQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+IGNvcmUgcm91dGVyLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFs cGVybiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBh bGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgDQo+PmZyb20NCj4+ICA+PjENCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJ IHdvdWxkIA0KPj5ob3BlDQo+PiAgPj50aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IG9w ZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgDQo+PnRoZXkNCj4+ ICA+PiA+PmNob29zZQ0KPj4gID4+ID4+ID4+PnRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIA0KPj5zdGVhZA0K Pj4gID4+ID4+IHByb3Zpc2lvbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiAxNjAsMDAwIHNl cnZpY2UgcGF0aHMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEg SCB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBp ZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQgDQo+PmhvcA0KPj4gID4+ID4+IHNlcnZp Y2UNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0 IGVhY2ggaG9wPw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE1hcmlhDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAq T24gDQo+PkJlaGFsZg0KPj4gID4+IE9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1 bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIA0KPj4yMDE0DQo+PiAg Pj4gPj4zOjAzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBMdWN5IHlvbmcg KkNjOiogam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t PjsNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IHNmY0BpZXRmLm9y ZyANCj4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g bWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCj4+ICpTdWJqZWN0 OiogUmU6IFtzZmNdIFNlcnZpY2UNCj4+ICA+PiBDaGFpbnMsDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBh cyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIA0KPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIG1pbm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRp ZmllciBjYW4gYmUgDQo+PnVzZWQgdG8NCj4+ICA+PiA+PiBkZXJpdmUNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9yd2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3Bv cnQuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSXQgaXMgX25vdF8gdGhlIHRyYW5zcG9ydCwgYnV0IHJhdGhlciBpcyB1c2VkIHRvDQo+PiAg Pj5zaW1wbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNl IHBhdGggKG9yIGdyYXBoKSB0aGF0IA0KPj5wYWNrZXRzDQo+PiAgPj5tdXN0DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0 aGUgZXhhY3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVv cGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbg0KPj4gID4+dGhpcw0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRo DQo+PiAgPj4gPj4gaWRlbnRpZmllcg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlk ZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgDQo+Pmxvb2t1cCBjYW4NCj4+ICA+ PiA+PiByZXN1bHQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGEgb25lIG9yIG1vcmUg KGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgDQo+Pm5leHQNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGhvcChzKS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBQYXVsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT24gSnVsIDEwLCAyMDE0LCBhdCAxMTowNCBBTSwgTHVjeSB5 b25nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25nQGh1YXdlaS5jb20gDQo+ PjxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+DQo+PiAgPj4gPj4gPG1haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbT4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUzZT4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3cm90ZToNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3Qg bWFuZGF0ZSBvbmx5IA0KPj51c2Ugb2YNCj4+ICA+PiB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+ PiAgPj4gPj5hY3Rpb25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddKk9uIA0KPj5CZWhhbGYNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9mKm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IDxtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbT4NCj4+ICA+PiA+PiA+Pj4gKlNlbnQ6KlRodXJzZGF5LA0KPj4gID4+ ID4+ID4+PiA+PiBKdWx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxMCwgMjAxNCAyOjA2 IEFNICpUbzoqbWlrZWJpYW5jQGFvbC5jb20NCj4+IDxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29t Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47 am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhA am9lbGhhbHBlcm4uY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OnNmY0BpZXRmLm9yZz4gKlN1YmplY3Q6KlJlOiBbc2ZjXSANCj4+U2VydmljZQ0KPj4gID4+ID4+ Q2hhaW5zLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vycw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IFJlLSwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSAN Cj4+cGF0aA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3Qg dG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPj4gID4+ZGVyaXZlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUmVxdWlyaW5nIGEgU0ZDIHN5c3RlbSB0byBo YXZlIHRoZSBmdWxsIA0KPj5rbm93bGVkZ2Ugb2YNCj4+ICA+PiA+PiBldmVyeQ0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBm b3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gDQo+PmlzIG5vdA0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9qdXN0aWZpZWQNCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMu DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g U0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2UgDQo+Pm9mDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiB0aGF0IHdpbGwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4g YWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+ICA+PiByZXF1aXJlZA0KPj4gID4+ ID4+IHRvDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNo YWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiANCj4+aXMNCj4+ICA+PiA+PnVzZWQgdG8NCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4gYWN0aW9ucw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgYSBzb2x1dGlvbi1v cmllbnRlZCBkaXNjdXNzaW9uLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IENoZWVycywNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRGUgOipzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10qRGUgbGEgDQo+PnBhcnQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGUqbWlr ZWJpYW5jQGFvbC5jb20gPG1haWx0bzpkZSptaWtlYmlhbmNAYW9sLmNvbT4NCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpIDoqbWVy Y3JlZGkgOQ0KPj4gID4+ID4+IGp1aWxsZXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIw MTQgMjI6MDMgKsOAIDoqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzoqam1oQGpvZWxo YWxwZXJuLmNvbT4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l M2U7c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNA aWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlDQo+PiAgPj4gPj5DaGFpbnMsDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55 b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIA0KPj5iZXR3ZWVuDQo+PiAgPj5T Rg0KPj4gID4+ID4+IENoYWluDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gUGF0aD8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90 aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IA0KPj5pdCdzDQo+PiAg Pj4gPj5jbGVhciB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0 IGV2ZXJ5b25lDQo+PiAgPj5hZ3JlZXMNCj4+ICA+PiA+Pm9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGVzZSB0ZXJtcy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVu Y2xlYXIgaXMNCj4+ICA+PndoZXRoZXINCj4+ICA+PiA+Pml0IGlzDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5 IA0KPj53aGF0DQo+PiAgPj4gPj50aGUgSUQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9m IHRoZSBTRkMgSGVhZGVyDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNob3VsZA0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBp ZiB0aGlzIA0KPj5kcmFmdA0KPj4gID4+ID4+c2ltcGx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBpbnRlbmRzIHRvIGxlYXZlIHRoYXQgYW1iaWd1b3VzLCBhbGxvd2luZyBvdGhlcg0KPj4g ID4+ZHJhZnRzDQo+PiAgPj4gPj50bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGljdGF0 ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiANCj4+Y2hhaW4NCj4+ICA+ PiBvcg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBj aGFpbiBvcg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0 ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIA0KPj5oYXZlDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0 ZWQgKG9yIA0KPj5tYWtlDQo+PiAgPj4gPj4gb25lDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiByZXF1aXJlZCBhbmQgdGhlIG90aGVyIG9wdGlvbmFsKSB0byBhdm9pZCBzb21lDQo+PiAgPj4g dmVuZG9ycw0KPj4gID4+ID4+IG9ubHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBv cnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBwb3J0aW5nIFNGQy4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+Pg0KPj4gID4+ID4+ID4+Pg0KPj4gID4+ID4+DQo+PiAg Pj4NCj4+ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+PiAgPj4+ Pj4+Pj4+Pj4+Pj4tLQ0KPj4gID4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gID4+ID4+ID4+Pj4+Pj4+ Pj4tLQ0KPj4gID4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiAqRnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzoqam1oQGpv ZWxoYWxwZXJuLmNvbT48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNvbSUzZT4+DQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZw0KPj4gPG1haWx0bzoqc2ZjQGlldGYu b3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZz4NCj4+IDxtYWls dG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4+ICA+PiAqU2VudDoqVHVlc2Rh eSwNCj4+ICA+PiA+PiBKdWx5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpT dWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIA0KPj5hbmQNCj4+ICA+PkxvYWQN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0 byBmaWd1cmUgb3V0IGhvdyB0byBjbGVhcmx5DQo+PiAgPj5hbnN3ZXINCj4+ICA+PiA+PmENCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVl biBtYWRlIGFib3V0IHRoZQ0KPj4gID4+ID4+ID4+PiBwcm9wb3NlZA0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVyZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdl dA0KPj4gID4+IHdvcmtpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVl bWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+ICA+PiBpbXByb3ZlDQo+PiAg Pj4gPj4gdGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVh ZGVycyB3aG8gaGF2ZSBub3QgDQo+PnBhcnRpY2lwYXRlZCBpbg0KPj4gID4+ID4+dGhlDQo+PiAg Pj4gPj4gV0cNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gd2lsbCB1bmRl cnN0bmQgaXQgdGhlIHdheSB0aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3ZSBpbnRl bmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPj4gID4+ID4+cGVyc29uYWwNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpZXcsIGFuZCBzZWUgaWYgdGhhdCBoZWxwcy4NCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJl Z2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCANCj4+dGhhdA0KPj4gID4+ID4+ d2hhdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBk YXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gDQo+PldlDQo+PiAgPj5hcmUNCj4+ICA+PiA+PiBub3QN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcgdG8gZGVmaW5lIHRoZSBhcmNo aXRlY3R1cmUgZm9yIHRoZSANCj4+ZW50aXJlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBz b2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCANCj4+ZW5jb21wYXNzDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBv bGljeSBmdW5jdGlvbnMsDQo+PiAgPj52aXJ0dWFsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBvdGhlcg0KPj4gID4+ID4+ IGFzcGVjdHMuDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkg DQo+Pm5lZWQNCj4+ICA+PiB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZXhpc3QgaW4g dGhlIGxhcmdlciBzeXN0ZW0sIGJ1dCB3aGljaCBhcmUgZGVhbHQgDQo+PndpdGgNCj4+ICA+PiA+ PmFib3ZlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh bmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUNCj4+ICA+PiBk b2luZy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIA0KPj5wYXRo LA0KPj4gID4+YXMgSQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBu ZWVkIHRvIGZpcnN0IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIA0KPj5hcmUgYXQNCj4+ ICA+PiA+PmxlYXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlZSBkaWZmZXJlbnQg d2F5cyB0aGF0IGxvYWQgYmFsYW5jaW5nIGNhbiBhbmQNCj4+ICA+PndpbGwNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJv YmFibHkgDQo+PmFyZQ0KPj4gID4+ID4+bW9yZS4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgDQo+Pm9mDQo+ PiAgPj4gPj50aGVzZSwNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFu ZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYmUg dXNlZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEpIExvYWQg YmFsYW5jaW5nIGFzIGEgc2VydmljZSBwcm92aWRlZCB0byB0aGUgDQo+PmVuZA0KPj4gID4+ID4+ dXNlci4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0 aW9uLiBJdCByZWNlaXZlcyB1c2VyDQo+PiAgPj5wYWNrZXRzLA0KPj4gID4+ID4+YW5kDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtb2RpZmllcyB0aGVtIChvcg0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiBtYXJrcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlbSwgb3IgLi4uKSBz byBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgDQo+PnNlcnZpY2UNCj4+ICA+PiA+Pmluc3RhbmNl DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQu IFRoaXMgaXMgYW4gDQo+PmltcG9ydGFudA0KPj4gID4+ID4+c2VydmljZQ0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2Ug DQo+PmNoYWluaW5nLg0KPj4gID4+ID4+SXQncw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YmVoYXZpb3IgbWF5IGFmZmVjdCByZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4+ICA+PiA+ PiBjaGFpbmluZyBpcw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0IGhh cyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiAgPj4gPj5hcmNodGllY3R1cmUuDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZl IGl0IGlzIHNpbXBseSANCj4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzZXJ2aWNlDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRl cmx5aW5nIHBhY2tldC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBp cywgDQo+Pm9uZQ0KPj4gID4+Y2FuDQo+PiAgPj4gPj5oYXZlDQo+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiB3aGF0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBh IHNpbmdsZQ0KPj4gID4+cG9pbnQNCj4+ICA+PiA+Pm9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBjb250YWN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGZvciBhDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkg DQo+PmRlbGl2ZXJlZA0KPj4gID4+ID4+YnkgYQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xs ZWN0aW9uIG9mDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXJ0dWFsIG9yIHBoeXNpY2Fs IG1hY2hpbmVzLCBwb3NzaWJseSBpbmNsdWRpbmcNCj4+ICA+Pm9uZSBvcg0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcg DQo+PlZSUlAtbGlrZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBz aGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCANCj4+dGhpcyBpcw0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUN Cj4+ICA+PiA+Pm1lY2hhbmlzbXMuDQo+PiAgPj4gPj4gSXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sDQo+ PiAgPj4gPj5tZWNoYW5pc21zLA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0 aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIA0KPj5zY2FsZS1vdXQsDQo+PiAgPj5hbmQN Cj4+ICA+PiA+PnZtDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnN0YW50aWF0aW9uLiBU aGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YNCj4+ICA+PnBlcm1pdHRpbmcNCj4+ICA+PiA+PnRo aXMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3ZSBuZWVkIHRv IGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+ICA+PiA+PnRlcm1pbm9sb2d5DQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRl cnMgdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoaW5rIHdlIGFyZSBwcm9oaWJpdGlu ZyBpdC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5DQo+PiAgPj5z ZWxlY3RpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhl IHNlcnZpY2UgY2hhaW5pbmcgdGhhdCANCj4+ZGlyZWN0DQo+PiAgPj4gPj50cmFmZmljDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qg d2FudCB0byANCj4+cmVxdWlyZQ0KPj4gID4+IHRoYXQNCj4+ICA+PiA+PmENCj4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFyIGF0IG9ubHkgb25l IHBsYWNlIA0KPj5pbg0KPj4gID4+dGhlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3 b3JrLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPj4gID4+Y29t YmluZWQuIEkNCj4+ICA+PiA+PiB0ZW5kDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBlYXIgdG8gDQo+PnNlcnZpY2UN Cj4+ICA+PiA+PmNoYWluaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmds ZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIA0KPj5jbHVzdGVyDQo+PiAgPj5pcw0K Pj4gID4+ID4+YQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVj YXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIgDQo+Pm9uZS4NCj4+ICA+PiBUaHVzLA0KPj4gID4+ ID4+IHRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcG9pbnQgb2YgdHlwZSAzIGxvYWQg YmFsYW5jaW5nDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJl bnQNCj4+ICA+PiA+PnNpbmd1bGFyDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVz dGVyZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IA0KPj5wbGFjZXMNCj4+ICA+Pmlu DQo+PiAgPj4gPj50aGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTm93IHdp dGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayANCj4+YWJvdXQNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2Vy dmljZSBjaGFpbiANCj4+aXMgYQ0KPj4gID4+ID4+IHNlcXVlbmNlDQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0 IA0KPj5vZg0KPj4gID4+ID4+cGFja2V0cy4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0 IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQgc29tZSBzdWJzZXQgb2YNCj4+ICA+PnRyYWZm aWMNCj4+ICA+PiA+PmlzDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBnZXQgRFBJLCBj aGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQNCj4+ICA+PmZpcmV3YWxsDQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGly ZWN0bHkgdG8gDQo+PnRoZQ0KPj4gID4+Y2FjaGUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0 aG91dA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZp Y2UgZnVuY3Rpb25zLg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhl DQo+PiAgPj5wYWNrZXRzLg0KPj4gID4+IEENCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNl cnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+PiAgPj4gPj5s b2NhdGlvbnMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIHRoZSBuZXR3b3JrLiBUaG9z ZSBsb2NhdGlvbnMgd2lsbCBiZSANCj4+c2luZ3VsYXIgb3INCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gDQo+ PlRoZXkNCj4+ICA+PiA+Pm1heSBiZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWRkcmVz c2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCANCj4+YXMNCj4+ICA+PiBw b3J0cw0KPj4gID4+ID4+IG9uDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRo ZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+PiAgPj4gPj5sb2NhdGlvbnMN Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBj aGFpbmluZyANCj4+aW5mcmFzdHJ1Y3R1cmUNCj4+ICA+PiBhbmQNCj4+ICA+PiA+PiB0aGUNCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gRnJvbSB0aGUgcG9pbnQgb2Ygdmll dyBvZiB0aGUgd29yayBvZiB0aGUgU0ZDDQo+PiAgPj5ncm91cCwNCj4+ICA+PiA+PiB3ZQ0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgDQo+ PnRoZQ0KPj4gID4+ID4+c2VydmljZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4s IHdoaWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgDQo+PnRvDQo+PiAgPj4g dGFsaw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBh dGggcGFja2V0cyB3aWxsIHRha2UgaW4gDQo+PnRoZQ0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbmV0d29yay4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hv bGUNCj4+ICA+PiBwYXRoDQo+PiAgPj4gPj4gbWF5DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgDQo+PmRlYWxz DQo+PiAgPj4gPj53aXRoDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGlu IHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSANCj4+KDIpDQo+PiAgPj5vbg0KPj4g ID4+ID4+bG9hZA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0 aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZA0KPj4gID4+YmVoYXZpb3JzDQo+PiAgPj4gPj4gd2hp Y2gNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZp Y2UgY2hhaW5pbmcgDQo+Pm1lY2hhbmlzbXMgKGluDQo+PiAgPj4gPj5tdWNoDQo+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4g aXMgDQo+PmxhcmdlbHkNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byBy b3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gID4+IHByb3Zpc2lvbg0KPj4gID4+ ID4+IHdlDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoYXQNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRp b24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4+ICA+PiA+PiBuZWNlc3NhcnkuDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBu ZXcgY2hhaW4uIEJhc2VkIA0KPj5vbg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3Jt YXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPj4gID4+cG9pbnQuDQo+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBo b3BlIHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIA0KPj5hZnRlci4NCj4+ICA+ PklmIGl0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVu dCBpcyBhY2NlcHRhYmxlIHRvIHRoZSANCj4+d29ya2luZw0KPj4gID4+ID4+IGdyb3VwLA0KPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFs IHdvcmRzIGFyZSANCj4+bmVlZGVkDQo+PiAgPj4gdG8NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIA0KPj50 aGUNCj4+ICA+PiA+PiBpbnRlbnQsDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdl IHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgDQo+PndvcmtpbmcNCj4+ICA+PiA+ Pmdyb3VwDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlz IHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IA0KPj5zdXJlDQo+PiAgPj4gPj53aGF0IHRvDQo+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiBzZmMN Cj4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlz dCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gID4+ID4+IHNmYw0KPj4gID4+ID4+ID4+PiA+PiBtYWlsaW5n DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiBzZmMNCj4+ICA+PiA+PiA+Pj4gPj4gbWFpbGlu Zw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4+ICA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gID4+IHNmYw0KPj4gID4+ID4+ID4+PiA+PiBtYWlsaW5n DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiAgPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+ICA+PiBzZmMNCj4+ICA+PiA+PiA+Pj4gbWFpbGluZw0KPj4gID4+ ID4+ID4+PiA+PiBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gc2ZjDQo+PiAgPj4gPj4gPj4+IG1haWxpbmcNCj4+ICA+PiA+PiA+Pj4g Pj4gbGlzdA0KPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4gID4+ID4+ID4+PiA+PiA+Pj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+PiAgPj4gPj4gbWFpbGlu Zw0KPj4gID4+ID4+ID4+PiA+PiBsaXN0DQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYu b3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gID4+ID4+ID4+PiA+PiA+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0K Pj4gID4+ID4+IG1haWxpbmcNCj4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gID4+ID4+ID4+PiA+ PiA+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ ICA+PiA+PiA+Pj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+ID4+ID4+DQo+PiAgPj4gPj4gPj4+ID4+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAg Pj4gPj4gPj4+ID4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ICA+PiA+PiA+Pj4gPj4gPj4gc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gID4+ID4+ID4+PiA+PiA+ Pg0KPj4gID4+ID4+ID4+PiA+PiA+DQo+PiAgPj4gPj4gPj4+ID4+ID5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gID4+ID4+ID4+PiA+PiA+c2ZjIG1h aWxpbmcgbGlzdA0KPj4gID4+ID4+ID4+PiA+PiA+c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4gID4+ID4+ID4+PiA+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+ICA+PiA+PiA+Pj4gPj4NCj4+ICA+PiA+PiA+Pj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiA+Pj4gPj4g c2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiAgPj4gPj4gPj4+DQo+PiAgPj4gPj4gPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgPj4gPj4gPj4+IHNmYyBt YWlsaW5nIGxpc3QNCj4+ICA+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gID4+ID4+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4gID4+ID4+ID4NCj4+ICA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ICA+PiA+PiA+c2ZjIG1haWxpbmcgbGlzdA0KPj4gID4+ ID4+ID5zZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiAgPj4gPj4gPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiAgPg0KPj4NCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGlu ZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCg0K From nobody Mon Jul 14 09:07:04 2014 Return-Path: <tom.taylor.stds@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1450E1A0AB3 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:07:00 -0700 (PDT) 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 NF7w2-iRBecB for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:06:58 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AA01A0A9B for <sfc@ietf.org>; Mon, 14 Jul 2014 09:06:58 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id eb12so4469118oac.31 for <sfc@ietf.org>; Mon, 14 Jul 2014 09:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YRPcvdByn/6pv/zIk8IFykdQUlU+8BqEhaAiynkNcpY=; b=NdMOfPfM6Jq8wBwtx6ZparviNE0QY9i50sRpwiWxkM42LrIP2YzEL+3FhSySSn68QJ Qde3SIF0EqyUip+azhdgossT4uiexQfXEdeezkphchXGC08Fo53E0eWELjK3e4wY9yMj 48hd7zqdKciDWQUO2Kns+q938yJ5LejNMMBENI2Bj6HIzuWqLgl76IJQOo3CjCA45hfL I7vFcgifyFubhceyiv+dmH5sJa75RZdhFFmGk5yZ9XGaKGyUWLz8rkr+G/jQXA8/gNgP z6YzzAmF/KJ/VQXVZq18DmgQ6uruMoGszqaCuNopf8vqYVJomiHbeFYM9Dr5CAthSF9s oGGw== X-Received: by 10.60.57.166 with SMTP id j6mr3952655oeq.77.1405354018161; Mon, 14 Jul 2014 09:06:58 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id v8sm23930051obo.7.2014.07.14.09.06.57 for <sfc@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 09:06:57 -0700 (PDT) Message-ID: <53C40020.1030208@gmail.com> Date: Mon, 14 Jul 2014 12:06:56 -0400 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sfc@ietf.org References: <53BCAB74.4060801@joelhalpern.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8qIbItJYTDjI9miec2c2X82xyW4 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 16:07:00 -0000 A pre-assigned identifier could be useful if you want to introduce statefulness into the service-level routing. Tom Taylor On 14/07/2014 11:36 AM, Lucy yong wrote: > IMO: quote "SFP forwarding information is associated with a service path identifier > that is used to uniquely identify an SFP" is not proper assumed in architecture doc. > > As discussed in this thread, an SF in an SFC may have multiple instances that are available or be in standby. Selection of the instance for the SF may be dynamic based on the flow info. on packet. Thus, we can not require a service path ID to identity an SFP. > > Lucy > ... From nobody Mon Jul 14 09:15:50 2014 Return-Path: <lucy.yong@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450D51A0AD4 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 1BGh_nu7gNeN for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:15:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B8A1A0AD3 for <sfc@ietf.org>; Mon, 14 Jul 2014 09:15:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE41655; Mon, 14 Jul 2014 16:15:39 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 17:15:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 09:15:32 -0700 From: Lucy yong <lucy.yong@huawei.com> To: Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HTo8BuVuTyW0ugIx3qXYbOUpugA2oA//+NmKCAAIhHgIAABd6AgAADa4CAAAIHAP//jHUAgACAywD//4xL0A== Date: Mon, 14 Jul 2014 16:15:32 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BF802@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@dfweml701-chm.china.huawei.com> <53C40020.1030208@gmail.com> In-Reply-To: <53C40020.1030208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bmK4MWxHhCckp1c_I6oD8bLysEA Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 16:15:45 -0000 Yeah. But the architecture should not mandate it because you may also have = stateless used as well (as described in this thread). Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Monday, July 14, 2014 11:07 AM To: sfc@ietf.org Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Ba= lancers A pre-assigned identifier could be useful if you want to introduce stateful= ness into the service-level routing. Tom Taylor On 14/07/2014 11:36 AM, Lucy yong wrote: > IMO: quote "SFP forwarding information is associated with a service=20 > path identifier that is used to uniquely identify an SFP" is not proper a= ssumed in architecture doc. > > As discussed in this thread, an SF in an SFC may have multiple instances = that are available or be in standby. Selection of the instance for the SF m= ay be dynamic based on the flow info. on packet. Thus, we can not require a= service path ID to identity an SFP. > > Lucy > ... _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 14 09:42:46 2014 Return-Path: <paulq@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358061A0AEB for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 14VezNTIOBJ7 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 09:42:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07481A0AE5 for <sfc@ietf.org>; Mon, 14 Jul 2014 09:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=805; q=dns/txt; s=iport; t=1405356149; x=1406565749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XXu0OAVmVjTmPNNWOt5J6TptRrai3xpq+92rMn9CKuA=; b=HLmVIpqZswTObM0CDIlevvCHXfSoAiEd9DZ2PrrNU2o6+VcMMKgyyCUX UxSGrL7obz1VviBPv0MqwwjDNnwKobwHnjnCbzULlqzSU9Uhsw6Bls+Ni LPuz6aONLzw4QrlDQSdk9DVHEcecKKZWjGrDPi7lpDMH0fgzJhjP6oRml I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADoHxFOtJV2Y/2dsb2JhbABPAQmDDoEsyRYBgRYWdYQEAQEDATorFAULAgEIEiQQMhcOAgQOAwKIOgjIPReObwEoMweDLYEWAQSbDotqiDSDREGBbw X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208";a="339969197" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jul 2014 16:42:29 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6EGgTo4002263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 16:42:29 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 11:42:28 -0500 From: "Paul Quinn (paulq)" <paulq@cisco.com> To: Lucy yong <lucy.yong@huawei.com> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HMkQVg7ZKq7k+0R4rxjmeWw5uf4eMAgAAC0ACAABMPgIAABd6AgAADa4CAAAIHAIAABKuAgAASgwA= Date: Mon, 14 Jul 2014 16:42:28 +0000 Message-ID: <BA592CF2-065F-4790-829A-E16A6A891551@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7247@MBX021-W3-CA-2.exch021.domain.local> <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453BF7AB@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.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C6A70026B2DAC45820B99520DEF1896@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4u4PSpIfG5J0Bn2wmLr3d6k6tK0 Cc: "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 16:42:44 -0000 On Jul 14, 2014, at 11:36 AM, Lucy yong <lucy.yong@huawei.com> wrote: > IMO: quote "SFP forwarding information is associated with a service path= identifier > that is used to uniquely identify an SFP" is not proper assumed in archit= ecture doc. =20 >=20 > As discussed in this thread, an SF in an SFC may have multiple instances = that are available or be in standby. Selection of the instance for the SF m= ay be dynamic based on the flow info. on packet. Thus, we can not require a= service path ID to identity an SFP. That statement has no impact on the use of a path _identifier_. An identif= ier can map to available, redundant or successor instances. =20 Selection based on flow/packet info is orthogonal as well, and referenced i= n the architecture as classification. From nobody Mon Jul 14 10:24:10 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999251A0AEC for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 10:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lLBJ17WV_ONQ for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 10:23:56 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F68C1A0005 for <sfc@ietf.org>; Mon, 14 Jul 2014 10:23:56 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 8AED953E56; Mon, 14 Jul 2014 10:23:50 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 10:23:50.530 -0700 x-echoworx-msg-id: 475c2551-3a5f-414d-bf89-899440ddbaca x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 114; Mon, 14 Jul 2014 10:23:50 -0700 (PDT) Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 693F853E55; Mon, 14 Jul 2014 10:23:50 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 10:23:54 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3d+yX9HZ8tJTkGQvyL0uIwtppuf0Gxg Date: Mon, 14 Jul 2014 17:23:55 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7545@MBX021-W3-CA-2.exch021.domain.local> References: <53C3F5CD.5080105@joelhalpern.com> In-Reply-To: <53C3F5CD.5080105@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DALzbPyYn1dKNJIgdH9p-M3n4wU Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 17:23:59 -0000 Hi, Joel. I agree that policy may be used to affect the SFI selection. But I don't = view "path" as the appropriate way to express that. It has a connotation,= to me, that it is end-to-end. Perhaps the policy is concerned with affec= ting the selection of only one SF instance on the chain and is 'don't care'= regarding selection of the other SF instances on the chain. Expressing t= his type of partial policy requirement doesn't map very well to the path co= ncept, IMO. In this regard, I actually think it better to leave to implem= entation. Specifically, that instance selection is made SFC-hop by SFC-ho= p, but MAY be influenced by policy. Furthermore, that a policy identifier= MAY be conveyed amongst the SFC nodes (i.e., classifier and SFF's) to faci= litate policy-driven instance selection. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, July 14, 2014 11:23 AM To: sfc@ietf.org Subject: [sfc] Proposed redefinition of SFP In an earlier email I said: The way the draft uses the terms, and the way most discussions outside the = IETF SFC working group use the term, a service function chain is something = that you would discuss a policy about. Certain traffic from certain users = is supposed to receive a certain sequence of services, the service chain. At the policy level, that does not care where in the network that is delive= red. So as to allow control a level of influence, and to have flexibility = to have multiple representations in the network of that policy construct, w= e have the intermediate notion of service function path. If the control sy= stem does not need to apply any influence, then it uses one service path fo= r the service chain. If it needs a level of control, it instantiates a sui= table number of service paths in the control system, and rules for how thos= e are used. Then, the mapping in the SFF is based on that path, so as to enable the inf= luence of the control system. While still allowing several other layers of= traffic management as discussed. Yours, Joel To rephrase this a bit (and then if folks agree on the concept, we can pick= the wording): The SFP provides a level of indirection between the fully abstract notion o= f service path as a sequence of functions to be delivered, and the fully sp= ecified notion of exactly what instances of SFFs the packet will visit when= it actually traverses the network. By allowing the control components to specify the use of this level of indi= rection, the deployment may choose the degree of SFF instance selection aut= hority that is delegated to the network. Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 14 10:47:42 2014 Return-Path: <jguichar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565131AD62A for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 10:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 wX7PqfNfWOHt for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 10:47:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381FA1A0AF9 for <sfc@ietf.org>; Mon, 14 Jul 2014 10:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3146; q=dns/txt; s=iport; t=1405360060; x=1406569660; h=from:to:subject:date:message-id:mime-version; bh=oP1cO7/4Tb0cb4F/yBmVOmRagT075dVdweD/eJfrf6k=; b=LeNiM4rMdFu6VnJVDuvCuF7kghhU8fKpTU6ZRUG3qm8an84mWK9soHNO sQ179uUei4YEufJTZ5NJHW1LDMFJ6u8/3/1wfxBCN14bIpJkoaidGkb1B scAih5X/N22OgZBgsZ6w+Cq0UrW5d3gcOlRvoZf9yX7yy9PVoE1QmtDHZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FADQXxFOtJA2N/2dsb2JhbABZgkdHgSzKLxZ1hAqBCwEMDmYXEASIVaE6pnkXlBUFmw6UHoNEgjA X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208,217";a="339916582" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jul 2014 17:47:39 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6EHldkq032239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Mon, 14 Jul 2014 17:47:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 12:47:39 -0500 From: "Jim Guichard (jguichar)" <jguichar@cisco.com> To: "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Q== Date: Mon, 14 Jul 2014 17:47:38 +0000 Message-ID: <CFE98FD3.2E64E%jguichar@cisco.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.180] Content-Type: multipart/alternative; boundary="_000_CFE98FD32E64Ejguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RJCHMlEYqtTYRhmCr1LS3t5ZHmU Subject: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 17:47:41 -0000 --_000_CFE98FD32E64Ejguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k.=94 I=92d like to ask the WG as a whole, if this clarification is something tha= t we can get consensus on. If so, I=92ll ask Joel to provide specific text,= that reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_CFE98FD32E64Ejguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5DE4B34633503A44AD62674B64579A61@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px;"> <div style=3D"font-size: medium;">Dear WG:</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">There has been much debate over the last = few days with regards to SFC concepts. To try and form some consensus aroun= d terminology and concepts used to describe the architecture in the merged = architecture draft, Joel has kindly suggested the following:</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">"The SFP provides a level of indirec= tion between the fully abstract notion of service path as a sequence of fun= ctions to be delivered, and the fully specified notion of exactly what inst= ances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to s= pecify the use of this level of indirection, the deployment may choose the = degree of SFF instance selection authority that is delegated to the network= .=94</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">I=92d like to ask the WG as a whole, if t= his clarification is something that we can get consensus on. If so, I=92ll = ask Joel to provide specific text, that reflects the above, for inclusion i= n the merged architecture draft.</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">Thank You,</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">Jim</div> </body> </html> --_000_CFE98FD32E64Ejguicharciscocom_-- From nobody Mon Jul 14 11:03:09 2014 Return-Path: <david.i.allan@ericsson.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31C61AD62A for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:03:05 -0700 (PDT) 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 Wt17mu3gpKhp for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:02:58 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8601A0AF9 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:02:58 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-43-53c3c8ca98d3 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 54.C1.05330.AC8C3C35; Mon, 14 Jul 2014 14:10:51 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:02:53 -0400 From: David Allan I <david.i.allan@ericsson.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4Q Date: Mon, 14 Jul 2014 18:02:52 +0000 Message-ID: <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> References: <CFE98FD3.2E64E%jguichar@cisco.com> In-Reply-To: <CFE98FD3.2E64E%jguichar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C392A2F10eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXSPn+7pE4eDDe6cF7dYOk/d4smDrewO TB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8arGcsYC/aaVSzeto+pgfGYfhcjJ4eEgInE lyf72SBsMYkL99aD2UICRxklPvxx6WLkArKXM0r0rrnECJJgEzCQ2PP/C5gtIhAs8WruDzBb WEBdonF5DztEXEPixb9XTBC2kcTUmc+B4hwcLAKqEu07QkHCvAK+EmvmLWSE2KUvcfH4QlYQ mxNo/Mf2l2BjGIHu+X5qDdgYZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2ksSc19eYIerz JfY+3cIKsUtQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCR fRUjR2lxalluupHBJkZg5ByTYNPdwbjnpeUhRgEORiUeXoVVh4OFWBPLiitzDzFKc7AoifPO qp0XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR4i6nU3/w1azwuNUcXVmOO4677Epr2jZH 7eHKK/5VP7tDHjcsv7Zu2tlfu8M4Nv9RVwmf6GzkMT38ccO2prdbFwUt/PP5zLGYo0+Yf59Y LaPx31il9UfNnaeuhYfmv9v300PJ1uLkVp3a0k0fPr1tt+V67ntevoO1W6A86NNB0xt79k99 VOj6VomlOCPRUIu5qDgRAOJ0c/x9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8EeSbWFhEiXOkuLvLIVCaTw8bDI Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:03:07 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F10eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F10eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> sfc@ietf.org<br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </body> </html> --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F10eusaamb105erics_-- From nobody Mon Jul 14 11:05:51 2014 Return-Path: <kegray@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED91A0012 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 stTXl89HmuQV for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:05:48 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C701A1A0008 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4695; q=dns/txt; s=iport; t=1405361147; x=1406570747; h=from:to:subject:date:message-id:mime-version; bh=B8HmFvo3wKRJGJk5X0PWItFQkfHyiVYtzqFuL7Rwguc=; b=P/yvWM0eWgMXcsoD5IaOe/c7nAjdxIF4ksV9zOf6t/Q/dP5XpZZljNHl rzJpbetYccIwcXS4MA/6aK6Zd4nwUIZULK0eJbeVgemIPymhaltNKs3mG L8AycsVeo/yUagH2VtmStXC/AQ3H+FkvX7CU1IRMNkfe9QU5+Yt07l+lh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAHAbxFOtJV2T/2dsb2JhbABZgkdHgSzJF4EYFnWEAwECBIELAQgEDQECAQIoORQDBgoEARKIQsgtF486hFsFmw6UHoNEgjA X-IronPort-AV: E=Sophos; i="5.01,659,1400025600"; d="scan'208,217"; a="60727112" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 14 Jul 2014 18:05:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6EI5lkf017497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Mon, 14 Jul 2014 18:05:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 13:05:46 -0500 From: "Ken Gray (kegray)" <kegray@cisco.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn448fti8uoohh0GN6/teYCpD3g== Date: Mon, 14 Jul 2014 18:05:46 +0000 Message-ID: <CFE99092.3ACF3%kegray@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.60] Content-Type: multipart/alternative; boundary="_000_CFE990923ACF3kegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gnSHqtY8fvNekNSKEBAeMvASnLg Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:05:49 -0000 --_000_CFE990923ACF3kegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 It takes a village =85 of lawyers =85or so it would seem. But, fine/okay. From: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.c= om>> Date: Monday, July 14, 2014 1:47 PM To: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k.=94 I=92d like to ask the WG as a whole, if this clarification is something tha= t we can get consensus on. If so, I=92ll ask Joel to provide specific text,= that reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_CFE990923ACF3kegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <138D56735072AD4AB20F7FD201A89E65@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div>+1 </div> <div><br> </div> <div>It takes a village =85 of lawyers =85or so it would seem.  But, f= ine/okay.</div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>"Jim Guichard (jguichar)= " <<a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>>= <br> <span style=3D"font-weight:bold">Date: </span>Monday, July 14, 2014 1:47 PM= <br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:sfc@iet= f.org">sfc@ietf.org</a>" <<a href=3D"mailto:sfc@ietf.org">sfc@ietf.= org</a>><br> <span style=3D"font-weight:bold">Subject: </span>[sfc] SFC Terminology / Co= ncepts<br> </div> <div><br> </div> <div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px;"> <div style=3D"font-size: medium;">Dear WG:</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">There has been much debate over the last = few days with regards to SFC concepts. To try and form some consensus aroun= d terminology and concepts used to describe the architecture in the merged = architecture draft, Joel has kindly suggested the following:</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">"The SFP provides a level of indirec= tion between the fully abstract notion of service path as a sequence of fun= ctions to be delivered, and the fully specified notion of exactly what inst= ances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to s= pecify the use of this level of indirection, the deployment may choose the = degree of SFF instance selection authority that is delegated to the network= .=94</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">I=92d like to ask the WG as a whole, if t= his clarification is something that we can get consensus on. If so, I=92ll = ask Joel to provide specific text, that reflects the above, for inclusion i= n the merged architecture draft.</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">Thank You,</div> <div style=3D"font-size: medium;"><br> </div> <div style=3D"font-size: medium;">Jim</div> </div> </div> </span> </body> </html> --_000_CFE990923ACF3kegrayciscocom_-- From nobody Mon Jul 14 11:13:16 2014 Return-Path: <jeff.tantsura@ericsson.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7DA1A000F for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:13:14 -0700 (PDT) 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 vKfSW6um4x18 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:13:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625AD1A0008 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:13:12 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-eb-53c3c8c69810 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A3.E4.25146.6C8C3C35; Mon, 14 Jul 2014 14:10:47 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:13:10 -0400 From: Jeff Tantsura <jeff.tantsura@ericsson.com> To: David Allan I <david.i.allan@ericsson.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn49ET/hxc4nQekyOcsG2L5dcjw== Date: Mon, 14 Jul 2014 18:13:09 +0000 Message-ID: <02F3769C-8865-47CA-B1B3-709F34BB6ACE@ericsson.com> References: <CFE98FD3.2E64E%jguichar@cisco.com>, <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_02F3769C886547CAB1B3709F34BB6ACEericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgu7xE4eDDRb1iVgsnadu8eTBVnYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PYlwuMBYtsKp48OsfYwHjapIuRk0NCwETi 7u8mNghbTOLCvfVANheHkMBRRokvL5+DJYQEljNKLOo0B7HZBAwk/n87zgJiiwjoSay5+JsV xGYWCJa4+f4IWL2wgK7EsSP9TDA1PWf+w9VvfvqDGcRmEVCV+PF5FpjNK2AvsfnIAUaIXYUS 30/NYAexOQX8JG7+vAgWZwQ67vupNUwQu8Qlbj2ZzwRxtIDEkj3nmSFsUYmXj/9B3ZMssbDl LDvEfEGJkzOfsExgFJmFpH0WkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhFZfAEj+ypG jtLi1LLcdCPDTYzA2Dkmwea4g3HBJ8tDjAIcjEo8vAqrDgcLsSaWFVfmHmKU5mBREufVrJ4X LCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR/EdUvuWOzeo7jcyin2npXH/s/PeH8jmLf4HH fzOE/P096/K/K/bXeM8dSijIfW+7UK7kyHfRqQzcIgv6dFRf3ni4cc2EWw2Su7n9Fvic2Bvs q97dmCPpuiM68s8rtn1LZvd4vheMtJsdNvXii+M3/hsp+NT193rf/lghzn/6Gbv7D/c/r4rX KbEUZyQaajEXFScCADc+10J+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JF58-DIsoNScuMr7PQe2f1bBuhU Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:13:14 -0000 --_000_02F3769C886547CAB1B3709F34BB6ACEericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sounds good to me Regards, Jeff On Jul 14, 2014, at 11:03 AM, "David Allan I" <david.i.allan@ericsson.com<m= ailto:david.i.allan@ericsson.com>> wrote: I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter=85. D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k.=94 I=92d like to ask the WG as a whole, if this clarification is something tha= t we can get consensus on. If so, I=92ll ask Joel to provide specific text,= that reflects the above, for inclusion in the merged architecture draft. Thank You, Jim _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_02F3769C886547CAB1B3709F34BB6ACEericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body dir=3D"auto"> <div>Sounds good to me<br> <br> Regards, <div>Jeff</div> </div> <div><br> On Jul 14, 2014, at 11:03 AM, "David Allan I" <<a href=3D"mail= to:david.i.allan@ericsson.com">david.i.allan@ericsson.com</a>> wrote:<br= > <br> </div> <blockquote type=3D"cite"> <div> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter=85.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.=94<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I=92d l= ike to ask the WG as a whole, if this clarification is something that we ca= n get consensus on. If so, I=92ll ask Joel to provide specific text, that r= eflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </div> </blockquote> <blockquote type=3D"cite"> <div><span>_______________________________________________</span><br> <span>sfc mailing list</span><br> <span><a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a></span><br> <span><a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.iet= f.org/mailman/listinfo/sfc</a></span><br> </div> </blockquote> </body> </html> --_000_02F3769C886547CAB1B3709F34BB6ACEericssoncom_-- From nobody Mon Jul 14 11:16:19 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00971A0016 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:16:02 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 RQd4CcfyDTfz for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:15:57 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CC51B2789 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:15:47 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 9742A53E5E; Mon, 14 Jul 2014 11:15:41 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 11:15:41.571 -0700 x-echoworx-msg-id: 3399b494-4ceb-4af9-9ed6-49010f278426 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 595; Mon, 14 Jul 2014 11:15:41 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 6ED0153DF9; Mon, 14 Jul 2014 11:15:41 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 11:15:46 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHA= Date: Mon, 14 Jul 2014 18:15:46 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B771CMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/c7EsEQBhub-L3HC7vuOXI3W0gHg Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:16:03 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B771CMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B771CMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face =09{font-family:"Cambria Math"; =09panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face =09{font-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face =09{font-family:Tahoma; =09panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal =09{margin:0in; =09margin-bottom:.0001pt; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink =09{mso-style-priority:99; =09color:blue; =09text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed =09{mso-style-priority:99; =09color:purple; =09text-decoration:underline;} span.EmailStyle17 =09{mso-style-type:personal; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} span.EmailStyle18 =09{mso-style-type:personal; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} span.EmailStyle19 =09{mso-style-type:personal-compose; =09font-family:"Calibri","sans-serif"; =09color:windowtext;} .MsoChpDefault =09{mso-style-type:export-only; =09font-size:10.0pt;} @page WordSection1 =09{size:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 =09{page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [m= ailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); sfc@ietf.org<br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </body> </html> --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B771CMBX021W3CA2exch_-- From nobody Mon Jul 14 11:22:36 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648201A001B for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:22:32 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WXRDFi0UokUW for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:22:28 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D084E1A0012 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:22:28 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 3046253E41; Mon, 14 Jul 2014 11:22:23 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 11:22:23.146 -0700 x-echoworx-msg-id: e0fbf661-c2fd-44b6-8cb6-574f55182807 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 962; Mon, 14 Jul 2014 11:22:23 -0700 (PDT) Received: from HUB021-CA-4.exch021.domain.local (unknown [10.254.4.39]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 0C5D753E41; Mon, 14 Jul 2014 11:22:23 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 11:22:28 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUA== Date: Mon, 14 Jul 2014 18:22:27 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B778FMBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/phlYH8BxAkGXOdr3TBfEIM6xzro Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:22:32 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B778FMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is one missing word in my text. Please replace my proposed text wit= h: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the instance select= ion of one or more of the service functions in the SFC. Any SFC may have = any number of C-SFC's associated with it." Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B778FMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face =09{font-family:"Cambria Math"; =09panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face =09{font-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face =09{font-family:Tahoma; =09panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal =09{margin:0in; =09margin-bottom:.0001pt; =09font-size:12.0pt; =09font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink =09{mso-style-priority:99; =09color:blue; =09text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed =09{mso-style-priority:99; =09color:purple; =09text-decoration:underline;} span.EmailStyle17 =09{mso-style-type:personal; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} span.EmailStyle18 =09{mso-style-type:personal; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} span.EmailStyle19 =09{mso-style-type:personal; =09font-family:"Calibri","sans-serif"; =09color:windowtext;} span.EmailStyle20 =09{mso-style-type:personal-reply; =09font-family:"Calibri","sans-serif"; =09color:#1F497D;} .MsoChpDefault =09{mso-style-type:export-only; =09font-size:10.0pt;} @page WordSection1 =09{size:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 =09{page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">There is one missing word= in my text.   Please replace my proposed text with:<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the instance sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s assoc= iated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [m= ailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); sfc@ietf.org<br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </body> </html> --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8B778FMBX021W3CA2exch_-- From nobody Mon Jul 14 11:24:12 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9B1A000F for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjAkGbcG3mWh for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:24:05 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA231A0008 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:24:04 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 44024c35.2b995a8c3940.5937232.00-2456.16454035.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:24:04 +0000 (UTC) X-MXL-Hash: 53c42044618c6a91-4798fbef6071a7ea619b6883d3f4bac610f534e1 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 43024c35.0.5937017.00-2393.16453510.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:23:49 +0000 (UTC) X-MXL-Hash: 53c4203570979647-c723ef8384b0183feaec67fca1fe279b7223238d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EINllV018224; Mon, 14 Jul 2014 14:23:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EINblq017983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 14:23:42 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 18:23:19 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:23:19 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAALLEA== Date: Mon, 14 Jul 2014 18:23:18 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=_Ym7mv4qLp] X-AnalysisOut: [Ul1cJoXiYA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=FcnECAG] X-AnalysisOut: [95AkeAwrc:21 a=svWxbqqkO6uS93cP:21 a=yMhMjlubAAAA:8 a=SSmO] X-AnalysisOut: [FEACAAAA:8 a=ZgcmM0qAbuIeKXVM6ywA:9 a=gKO2Hq4RSVkA:10 a=Ui] X-AnalysisOut: [CQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=vv8dFI] X-AnalysisOut: [QymvYJvgwJ:21 a=spa3cJyoKN7zfwRa:21 a=eWtHfUWJtMiyewGm:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xOuCuXQ6HBghCo5aDoLKiYT6C00 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:24:09 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron, this is pretty good. I would propose to re-phrase the second sentence to: "The Constrained-SFC (= C-SFC) further allows for policy constraints to be added to the SFC affecti= ng the selection of one or more *specific* service function *instances* in = the SFC". Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21MISOUT7MSGUSRCF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle22 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Ron, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">this is pretty good.<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I would propose to re-phr= ase the second sentence to: “</span><span style=3D"font-size:11.0pt;f= ont-family:"Calibri","sans-serif";color:#1F497D">The Co= nstrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affec= ting the selection of one or more *<b>specific</b>* service function *<b>in= stances</b>* in the SFC”.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Maria</span><span style= =3D"font-size:11.0pt;font-family:"Calibri","sans-serif"= ;color:#1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); sfc@ietf.org<br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </div> </body> </html> --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21MISOUT7MSGUSRCF_-- From nobody Mon Jul 14 11:24:31 2014 Return-Path: <smkumar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097CD1A0016 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 AZ_pfKeMqkfM for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:24:11 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAC51A0008 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=232222; q=dns/txt; s=iport; t=1405362251; x=1406571851; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TLin1Yr5vhmsGakT8BwrN9hy34UmpjUNAmFuhx75s+Y=; b=c81aSVNVD3otKIwlRkLFS0VHGSa1kOWxu+sNAUGP8p/M2hQK1aQPGuLm h3oOOZrAgEF83CM0AJG3QE/ZUxkl5UHsP0R8dQlUkl7pEo7qz0ugdO2oP EBxE5crbZssQK0Vi6C0wVPmvbczmDf1Cu02PZTWDZbl80Dfs4yqhKY4fg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAOcfxFOtJV2U/2dsb2JhbABPAQmCR0dSWoJxrCOQYIFWAQmHQwEZfxZ1hAMBAQEDAQEBARcBCAQGOAIHAg4HBAIBBgIRAQIBAQEBIAEGAwICAiULFAMGCAIEARIbiBMDCQgNlCScKJdaF4l+gyCBUQEEIAwHCQoHBQEKAQIEgnGBTAWWKkmEG4FKiiCININEbAEBAYEAQQ X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208,217";a="339713303" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jul 2014 18:24:06 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6EIO6Po007403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 18:24:06 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.251]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 13:24:06 -0500 From: "Surendra Kumar (smkumar)" <smkumar@cisco.com> To: "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HMsWULUlpKnUqI6FXMZ7zAXpuf4eMA///Tf4A= Date: Mon, 14 Jul 2014 18:24:05 +0000 Message-ID: <CFE95ABE.4BE2B%smkumar@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.86.82] Content-Type: multipart/alternative; boundary="_000_CFE95ABE4BE2Bsmkumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/UT3tO7BVGdaA2TMm9equbsL8Ros Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:24:24 -0000 --_000_CFE95ABE4BE2Bsmkumarciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaWEsDQoNCklubGluZS4NCg0KRnJvbTogPE5BUElFUkFMQT4sIE1BUklBIEggPG1uMTkyMUBh dHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+DQpEYXRlOiBNb25kYXksIEp1bHkgMTQsIDIw MTQgNjoyMCBBTQ0KVG86IFJvbiBQYXJrZXIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PiwgWHV4aWFvaHUgPHh1 eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgIm1pa2ViaWFu Y0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4iIDxtaWtlYmlhbmNAYW9sLmNvbTxt YWlsdG86bWlrZWJpYW5jQGFvbC5jb20+PiwgIkppbSBHdWljaGFyZCAoamd1aWNoYXIpIiA8amd1 aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+PiwgIm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IiA8 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sICJz ZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCg0KVGhlIG1lYW5pbmcg b2YgdGhlIFNGUCBJRCBpcyBwcmV0dHkgY2xlYXIsIGF0IGxlYXN0IHRvIG1lIOKAkyBhbiBhYnN0 cmFjdCBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlcyAoaS5lLiwgU0ZQIElEIDEgPSB7U0YtQS0xLCBTRi1CLTMsIFNGLUMtMn0pLiAgICBJbiBz b21lIHdheXMsIGl0IGlzIGEgY29sbGFwc2VkIOKAnGxhYmVsIHN0YWNr4oCdIOKAkyB0aGVyZSBp cyBhIHNpbmdsZSB0YWcgaW1wbHlpbmcgc29tZSBzZXF1ZW5jZSBvZiBuZXR3b3JrIGxvY2F0aW9u cy4gICBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBsZWFzdCB0byBtZSwgdGhhdCB0aGVyZSBp cyBhIGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0aW9uIGZvciB0aGlzIGVuZCB0byBlbmQgc2VxdWVu Y2UgKGJhcnJpbmcgcmVjbGFzc2lmaWNhdGlvbiwgb2YgY291cnNlKS4gICBJLCBmb3Igb25lLCBh bSBxdWVzdGlvbmluZyB0aGF0IGltcGxpY2F0aW9uLiAgICBJIGhhdmUgYmVlbiB1bmNvbWZvcnRh YmxlIHdpdGggdGhhdCBjZW50cmFsIHBvaW50IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdvcmxk IGNvbXBsZXhpdGllcyBvZiBkeW5hbWljIHNjYWxlIGFuZCB0aW1lbGluZXNzIG9mIHJlYWN0aW9u IHRvIGZhaWx1cmVzLg0KDQo8TWFyaWE+IEkgYWdyZWUuIEl0IHNob3VsZCBub3QgYmUgbWFuZGF0 ZWQgYnkgdGhlIFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBzb21ldGhpbmcgY2FsbGVkIOKAnHNlcnZp Y2UgZnVuY3Rpb24gcGF0aCBJROKAnSBpcyBjYXJyaWVkIGluIHRoZSBwYWNrZXQsIGJlY2F1c2Ug aXQgaXMgbm90IG5lY2Vzc2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVtZW50IHNlcnZpY2Ug Y2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxkIGRvIHRoYXQgYnV0IGl0 IGNhbm5vdCBhbmQgZG9lc27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQuDQoNClNLPiBJIGRpc2Fn cmVlIG9uIHRoZSAibm90IG5lY2Vzc2FyeSIgcGFydCBhcyBpdCBsZWFkcyB0byBhIHZlcnkgaW5l ZmZpY2llbnQgbWV0aG9kLg0KTGV0J3MgcGFyayBhc2lkZSB0aGUgU0ZDIHZzIFNGUCBkZWJhdGUg YW5kIHNheSBTRkM9PVNGUCBmb3IgdGhpcyBleHBsYW5hdGlvbi4gQSBjbGFzc2lmaWVyIG1heSBk ZXRlcm1pbmUgU0ZQIElEIGJhc2VkIG9uIGEgbm9uLXRyaXZpYWwgZnVuY3Rpb24sIG1heSBiZSBh IERQSSwgYXMgcGFydCBvZiBpdHMgY2xhc3NpZmljYXRpb24uIE5vdCBjYXJyeWluZyB0aGUgSUQg cmVxdWlyZXMgcmVjbGFzc2lmaWNhdGlvbiBhZnRlciBldmVyeSBTRiBpbiBvcmRlciB0byBrZWVw IHRoZSBwYWNrZXRzIG9uIHRoZSByaWdodCBTRlAsIGluIHRoaXMgY2FzZSBhIERQSS4gRXZlbiB0 aGF0IHJlY2xhc3NpZmljYXRpb24gbWF5IGJlIHRvIGxhdGUgaWYgb25lIG9mIHRoZSBTRnMgdHJh bnNmb3JtZWQgdGhlIHBhY2tldC4gU28sIHlvdSBkbyBuZWVkIGEgU0ZQIElEIGZvciBjaGFpbmlu ZyB0byBiZSB1c2VmdWwuDQoNClNLPiBBbmQgZm9yIHRoZSBhcmd1bWVudCBhYm91dCBub3QgbmVl ZGluZyBTRlAgSUQgYnV0IG9ubHkgU0ZDIElELCBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcHJldmVu dCAxOjEgbWFwcGluZyBiZXR3ZWVuIHRoZW0uDQoNClN1cmVuZHJhLg0KDQpNYXJpYQ0KDQpBbiBh bHRlcm5hdGl2ZSBhcHByb2FjaCBpcyB0byBzdGlsbCB1c2UgY2VudHJhbCBzZWxlY3Rpb24gdG8g c2VsZWN0IHRoZSBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNlIGZ1bmN0aW9ucyAoaS5lLiwgU0ZD IElEIDEgPSB7U0YtQSwgU0YtQiwgU0YtQ30pLCBidXQgYWxsb3cgdGhlIGFjdHVhbCBpbnN0YW5j ZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQsIHJlYWxpemVkIGJ5IHRoZSBjbGFzc2lmaWVy IGFuZCB0aGUgU0ZGcy4NCg0KR2l2ZW4gYSB0b3BvbG9neSBsaWtlOg0KDQpDbGFzc2lmaWVyIC0t LS0tLS0gIFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0yIC0tLS0tLS0tLS0tLS0tLS0t LS0tIFNGRi0zLS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgU0ZGLUEtMSAg ICAgICBTRkYtQS0yICAgICAgIFNTRi1CLTEgICAgICAgIFNGRi1CLTIgICAgICAgICBTRkYtQy0x ICAgICAgIFNGRi1DLTIgICAgICAgICAgICAgICAgICAgU0ZGLUEtMw0KDQpBbmQgYXNzdW1pbmcg YSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBnbyBzb21ldGhpbmcg bGlrZSB0aGlzOg0KDQoxIENsYXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwg U0YtQiwgU0YtQ30NCjIgQ2xhc3NpZmllciBzZWxlY3RzIFNGRi0xIGFzIGhvc3RpbmcgYXQgbGVh c3Qgb25lIGluc3RhbmNlIG9mIFNGLUENCjMgQ2xhc3NpZmllciBlbmNhcHN1bGF0ZXMgcGFja2V0 IGluZGljYXRpbmcgY2hhaW4gSUQgPSAxLCBzZXJ2aWNlIGluZGV4ID0gMQ0KNCBDbGFzc2lmaWVy IHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xDQo1IFNGRi0xLCBzZWVpbmcgY2hhaW4gSUQ9MSwg c2VydmljZSBpbmRleD0xLCBjaG9vc2VzIFNGRi1BLTIgYW1vbmdzdCBpdHMgYXZhaWxhYmxlIGlu c3RhbmNlcyBvZiBTRi1BDQo2IFNGRi0xIHNlbmRzIHBhY2tldCB0byBTRkYtQS0xDQo3IFNGRi1B LTEgc2VuZHMgcGFja2V0IGJhY2sgdG8gU0ZGLTENCjggU0ZGLTEgaW5jcmVtZW50cyBzZXJ2aWNl IGluZGV4IHRvIDINCjggU0ZGLTEgc2VsZWN0cyBTRkYtMiBhcyBob3N0aW5nIGF0IGxlYXN0IG9u ZSBpbnN0YW5jZSBvZiBTRi1CDQo5IFNGRi0xIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0yDQox MCBwcm9jZXNzIHJlcGVhdHMgcGVyIGFib3ZlIHVudGlsIFNGRi0zLCBhcyB0aGUgZWdyZXNzIGJv cmRlciwgcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciByb3V0aW5nIHRhYmxlDQoNClRoYW5rcy4N Cg0KDQogICBSb24NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBTdW5kYXksIEp1bHkgMTMsIDIwMTQgMTE6MzAg UE0NClRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBqZ3Vp Y2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT47IG1uMTkyMUBhdHQuY29t PG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtlcjsgc2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSBSZWRlZmluZSB0aGUgU0ZQLy9SRTogU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KDQpBZ3JlZSB0aGF0IHRo ZSBjdXJyZW50IGRlZmluaXRpb24gb2YgdGhlIFNGUCBpbiB0aGUgYXJjaCBkcmFmdCBpcyBhIGJp dCBjb25mdXNpbmcsIGp1c3QgYXMgd2hhdCB5b3UgaGFkIHBvaW50ZWQgb3V0Lg0KDQoNCg0KSW4g bXkgdW5kZXJzdGFuZGluZywgdGhlIFNGUCBhcyBhbiBpbnN0YW50aWF0aW9uIG9mIGFuIFNGQyBp biB0aGUgbmV0d29yayBzaG91bGQgYmUg4oCcYW4gb3JkZXJlZCBsaXN0IG9mIHNlcnZpY2Ugbm9k ZXMgYW5kIFNGIElEc+KAnShzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUt c3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMSkuIE9mIGNvdXJzZSwgaG93IHRvIHJlcHJlc2Vu dCB0aGUgU0ZQIGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90aGVyIHRoaW5nIChlLmcuLCBlaXRo ZXIgdGhyb3VnaCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBNUExTIGxhYmVsIHN0YWNrKS4gSGVy ZSB0aGUgc2VydmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ugd2hpY2ggY29udGFpbnMgdGhlIFNG RiBhbmQgdGhlIE5GIGNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUg U0YgYW5kIFNGIHByb3h5IGNvbXBvbmVudHMgb3B0aW9uYWxseS4gVGhlIHNlcnZpY2Ugbm9kZSBj b3VsZCBiZSBhdHRhY2hlZCBvciBlbWJlZGRlZCB3aXRoIG11bHRpcGxlIFNGIGluc3RhbmNlcyBh bmQgdGhvc2UgU0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRoZSBzYW1lIFNGIHR5cGUgb3Igbm90 LiAgSW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIFNGIGluc3RhbmNlcyBvZiB0 aGUgc2FtZSBTRiB0eXBlIChlLmcuLCBTRiBYKSBhcmUgYXR0YWNoZWQgdG8gYSBnaXZlbiBzZXJ2 aWNlIG5vZGUsIHRoZSBzZXJ2aWNlIG5vZGUgY291bGQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB3 aGljaCBuZWVkcyBTRiBYIGFtb25nIHRob3NlIFNGIGluc3RhbmNlcyBvZiBTRiBYIHR5cGUgbG9j YWxseS4gTWVhbndoaWxlLCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc2VydmljZSBub2RlcyB3aXRo aW4gYSBnaXZlbiBTRkMtZW5hYmxlZCBkb21haW4gd2hpY2ggYXJlIGVtYmVkZGVkIG9yIGF0dGFj aGVkIHdpdGggdGhlIFNGIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlLiBJbiB0aGlzIHdh eSwgdGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxkIGJlIG1hZGUgdmVyeSBmbGV4aWJsZS4NCg0K DQpCZXN0IHJlZ2FyZHMsDQoNClhpYW9odQ0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPg0KU2VudDogU2F0dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTQ0KVG86 IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgbW4xOTIxQGF0 dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGptaEBqb2VsaGFscGVybi5j b208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KV291bGRuJ3QgdGhhdCBiZSBjYWxsZWQg dGhlICJzZXJ2aWNlIGNoYWluIGlkZW50aWZpZXIiIHRoZW4/ICBJZiB0aGUgc2VydmljZSBjaGFp biBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUg b3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywgdGhlbiBJIHdvdWxkIGluZmVyIHRoYXQgYSAi c2VydmljZSBwYXRoIGlkZW50aWZpZXIiIHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2Vy dmljZSAqcGF0aCosIG5vdCBhIHNlcnZpY2UgKmNoYWluKi4NCg0KQWdhaW4sIEkgdGhpbmsgdGhp cyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNyZWVwaW5nIGluLiAgVGhlIHRlcm1zICJj aGFpbiIgYW5kICJwYXRoIiBzZWVtIGluY29uc2lzdGVudC4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IGpndWljaGFyQGNpc2NvLmNvbTxqZ3VpY2hhckBjaXNjby5j b208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbT4+DQpUbzog bWlrZWJpYW5jQGFvbC5jb208bWlrZWJpYW5jQGFvbC5jb20+LG1uMTkyMUBhdHQuY29tPG1uMTky MUBhdHQuY29tPixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+LGptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbT4sUm9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tPixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUz Y21pa2ViaWFuY0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29tJTNjbW4xOTIxQGF0dC5jb20lM2Us bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20lM2Usam1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2UsUm9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20lM2Usc2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNA0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQpZb3VyIGRlZmluaXRpb24gb2Ygc2VydmljZSBwYXRoIGlzIGNvcnJlY3Qg YXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBhdGggdGhyb3VnaCB3aGljaCB0cmFmZmljIHdpbGwgYWN0 dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGhvd2V2ZXIgcG9pbnRzIHRv IHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3RydWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2 ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJhc2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRo b3NlIGluc3RhbmNlcyBhcmUgYXZhaWxhYmxlIGFuZCB3aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlv biB0ZWNobmlxdWUgaXMgaW4gcGxheS4gV2hlbiBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNo YWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1heSBvciBtYXkgbm90IHVwZGF0ZSB0aGF0IGRhdGEg c3RydWN0dXJlIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3BzIG1heSBiZSB1c2VkICh3aGVyZSBh IHNpbmdsZSBuZXh0LWhvcCB3b3VsZCBlZmZlY3RpdmVseSBuYWlsIHVwIHRoZSBzZXJ2aWNlIHBh dGggZm9yIHRoYXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1heSBzaW1wbHkgYWxsb3cgc29tZSBv dGhlciBwcm90b2NvbCAvIG1lY2hhbmlzbSB0byBwb3B1bGF0ZSB0aGUgZGF0YSBzdHJ1Y3R1cmUg Zm9yIHlvdS4NCg0KRnJvbTogIm1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9s LmNvbT4iIDxtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+Pg0KRGF0 ZTogRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNDQpUbzogSmltIEd1aWNoYXJkIDxq Z3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT4+LCAibW4xOTIxQGF0 dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5 MjFAYXR0LmNvbT4+LCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sICJqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208 bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IiA8Um9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+ LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkgdGhpbmsgdGhpcyBpcyB0aGUgcm9vdCBvZiB0aGUg Y29uZnVzaW9uOg0KDQo+IEkgZG9u4oCZdCB3YW50IHRvIHNwZWNpZnkNCj4gc3BlY2lmaWMgaW5z dGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJ DQo+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEwMOKAnSB0aGF0IGJhc2lj YWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KPiBhbmQgdGhlbiBwdXNoIHRoaXMgaW50byB0aGUg bmV0d29yaw0KDQpCeSBkZWZpbml0aW9uLCBJIHVuZGVyc3Rvb2QgYSAic2VydmljZSBwYXRoIiB0 byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0YgaW5zdGFuY2VzLiBJbiB0aGUgc3Rh dGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgInNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIiB0byByZWZl ciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxseSAiW2RvZXMgbm90XSBzcGVj aWZ5IHNwZWNpZmljIGluc3RhbmNlcyIuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT48 amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20+Pg0KVG86IE5BUElF UkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPj4sSm9lbCBNLiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+PixSb24gUGFya2VyPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3 b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+PixzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0DQpTdWJqZWN0OiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KTWFyaWEsDQoNCkkgdGhp bmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkg YSBwb2ludGVyIHRvDQphIGRhdGEgc3RydWN0dXJlIHRoYXQgY29udGFpbnMgU0YgdG8gbmV4dC1o b3AgbWFwcGluZ3MuIFdoZW4geW91IGRlZmluZSBhDQpjaGFpbiwgbGV04oCZcyBzYXkgUzEgLT5T Mi0+IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRoZSBTRlAgc3BlY2lmeQ0KdGhlIHNw ZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZv ciB0aGF0IFNGUC4NCkhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBh biBhcmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQgKEkNCndpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxk IGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdQ0KY291bGQgc2lt cGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIHBvaW50IHRvIGEgZ2l2ZW4g U0ZDIGFuZA0KdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRpb24gaW50byB0aGUgbmV0d29yay4gQXQg dGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0Kc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1h cHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWluIHRoZQ0KbmV4dC1ob3BzIGF2YWls YWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlvdSBsZWFy bg0KdGhvc2UgbmV4dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91IGNvdWxkIHB1c2ggdGhlbSBkb3du IGZyb20gYSBjZW50cmFsaXplZA0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBD TEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0Kc29tZSBwcm90b2NvbCBleGNoYW5n ZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90IGNvcnJlY3QgdG8NCnNheSB0 aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBjaG9z ZW4gYSBwcmlvcmkNCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlIChhbmQgc29t ZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvDQpzby4NCg0KTGV04oCZcyB0YWtlIGFuIGV4 YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoNCg0KSSBkZWZpbmUgYW4gU0ZDIChs ZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzItPlMzLiBGb3IgYXJndW1lbnRzDQpz YWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5hbWljIGUuZy4gSSBkb27i gJl0IHdhbnQgdG8gc3BlY2lmeQ0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMz IChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQphc3NpZ24gYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLT5TMi0+UzMN CmFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRh IHN0cnVjdHVyZXMgYXJlDQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBOb3cgYXQg YSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzDQp3aXRoIHNlcnZpY2UgcGF0aCBpZGVu dGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUgZGF0YQ0Kc3RydWN0 dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5TMi0+UzMgYW5kIHRoZSBpbmRleCBp biB0aGUgU0ZDDQplbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBpdCBleGFjdGx5IHdoZXJlIGl0IGlz IGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkgd2UNCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRo ZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bw0KUzMgYW5kIHdp bGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMzIGlzIHJlYWNoYWJsZS4NCg0KT24g Ny8xMS8xNCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxt YWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCg0KPkppbSwNCj4NCj5Db3VsZCB5b3UgdGVs bCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNlcnZpY2UgcGF0aCIgYW5kIGENCj4i c2VydmljZSBwYXRoIGlkZW50aWZpZXIiPw0KPklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQg YWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkgKHdoaWNoDQo+aXMgbXkgY3VycmVu dCB1bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGlj aA0KPm5leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLg0K Pg0KPk1hcmlhDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCg0KRnJv bTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUgQU0NCj4+IFRvOiBOQVBJRVJBTEEs IE1BUklBIEg7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+OyBKb2VsIE0uDQo+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4NCj4+IEnigJltIHNvcnJ5 IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50 aWZpZXINCj4+IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3 aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UNCj4+IGNoYWluIGlkZW50aWZpZXIgbWFrZXMgYW55IGRp ZmZlcmVuY2U/DQo+Pg0KPj4gT24gNy8xMS8xNCwgMTA6NTggQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCj4+DQo+ PiA+RGl0dG8uDQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4g RnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4NCj4+ID4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bV0NCj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4gPj4gVG86 IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFs cGVybjsgUm9uDQo+PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExv YWQgQmFsYW5jZXJzDQo+PiA+Pg0KPj4gPj4gUmUtLA0KPj4gPj4NCj4+ID4+IEZvciB3aGF0IEkg Y2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJlZCBjbGVhcmx5IGluIHRoZQ0KPj5k cmFmdC4NCj4+ID4+DQo+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBp cyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4+ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+ IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4gPj4NCj4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRo aXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2VsZg0KPj4gPj5z aG91bGQgYmUNCj4+ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+PiA+Pg0KPj4gPj4gQ2hlZXJzLA0K Pj4gPj4gTWVkDQo+PiA+Pg0KPj4gPj4gPi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4g Pj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg SmltIEd1aWNoYXJkDQo+PiA+PiA+KGpndWljaGFyKQ0KPj4gPj4gPkVudm95w6kgOiB2ZW5kcmVk aSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+ID4+ID7DgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsg Sm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4+ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPg0KPj4gPj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJj aGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj4+ID4+ID5wcm9o aWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICphbGwqIG5leHQtaG9wcyB0byAqYWxs KiBTRkbigJlzDQo+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUg cGF0aCBpZGVudGlmaWVyIHBvaW50IHRvIGENCj4+ID4+bG9va3VwDQo+PiA+PiA+aW50byB0aG9z ZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdA0K Pj5zdXJlDQo+PiA+Pmhvdw0KPj4gPj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8N Cj4+ID4+ID4NCj4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4+IHdyb3RlOg0KPj4g Pj4gPg0KPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPj4gPj4gPj4NCj4+ID4+ID4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkDQo+PiA+PiA+Pj4oamd1aWNoYXIp DQo+PiA+PiA+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+ID4+ID4+ PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ DQo+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2FsIDstKSAuLiBIb3dl dmVyLCBpdCBzZWVtcyB0byBtZQ0KPj4gPj50aGF0IGlmDQo+PiA+PiA+Pj4geW91IGFsbG93IGFu IFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3RlIFNGRiBpdA0KPj53aWxs DQo+PiA+PnVzZQ0KPj4gPj4gPj4+Zm9yDQo+PiA+PiA+Pj4gYSBnaXZlbiBmbG93IHRvIHJlYWNo IHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UNCj4+YmV0dGVyDQo+PiA+Pm1h a2UNCj4+ID4+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUgU0ZGIGhhcyB0aGUgbmVjZXNzYXJ5 IGZvcndhcmRpbmcgbG9naWMgdG8NCj4+ID4+cmVhY2gNCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+ IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lzZSB5b3UgYXJlIGluIGRlZXAg dHJvdWJsZS4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJ RVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+Pg0K Pj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+QWJzb2x1dGVseSBub3QuIFNlcnZp Y2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbg0KPj5yZWxldmFudA0KPj4gPj4g Pj4+U0ZGcw0KPj4gPj4gPj4+ID53aGVuIHRoZXkgImFycml2ZSIuDQo+PiA+PiA+Pj4gPg0KPj4g Pj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gPj4gRnJvbTog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0NCj4+R3Vp Y2hhcmQNCj4+ID4+ID4+PiA+PihqZ3VpY2hhcikNCj4+ID4+ID4+PiA+PiBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4gPj4gPj4+ID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47 IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gV2VsbCBJIHRoaW5rIGl0IGlzIGV2 ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0b29kDQo+PnRoZQ0KPj4gPj4gPj4+ ID4+cHJvcG9zYWwNCj4+ID4+ID4+PiA+PiBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBm dWxsIGtub3dsZWRnZSBvZiBldmVyeSBzaW5nbGUNCj4+U0YNCj4+ID4+ID4+PndpdGhpbg0KPj4g Pj4gPj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2lu Z2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG8NCj4+a25vdw0KPj4gPj5hDQo+PiA+PiA+Pj4g Pj5wcmlvcmkNCj4+ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBuZWVk IHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+PnBvaW50DQo+PiA+PmluDQo+PiA+PiA+Pj50aW1l Lg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gT24gNy8xMC8xNCwgMTE6NTMgUE0sICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPj4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gPlJvbiwgdGhp bmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9yIHByb2JsZW0NCj4+d2l0 aA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ID4+PiA+PiA+cHJvcG9zYWwgYXMg SSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3QNCj4+ID4+ID4+ PnVuZGVyc3RhbmQNCj4+ID4+ID4+PiA+PiA+aXQuKQ0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+ PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNl ciBmb3IgdGhlDQo+PiA+Pm5leHQNCj4+ID4+ID4+PiA+PiA+c2VydmljZSBmdW5jdGlvbiB0aGF0 IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzDQo+PnRvKSwNCj4+ID4+aW4NCj4+ ID4+ID4+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91 Z2ggaXQuDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUg YWJsZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+PiA+PnRoYXQNCj4+ ID4+ID4+PiA+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVs bCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQNCj4+ID4+ID4+PmJhbGFuY2VyLg0K Pj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBzZW5z aXRpdmUsIGFuZCAvIG9yDQo+PiA+PnN0YXRlZnVsLg0KPj4gPj4gPj4+ID4+ID5CdXQgaGF2aW5n IHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGwsDQo+PiA+ PmZsb3cNCj4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBz ZWVtcyB0byBtZSB0byBiZSBhbg0KPj4gPj5hY2NlcHRhYmxlDQo+PiA+PiA+Pj4gPj4gPmltcG9z aXRpb24uDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ID5Zb3VycywNCj4+ID4+ID4+PiA+ PiA+Sm9lbA0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+T24gNy8xMC8xNCwgMTA6MDYg UE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBl cnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMNCj4+d29yaw0KPj4g Pj4gPj4+ID4+c2Vuc2libHkNCj4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVk IGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4g Pj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVz LA0KPj53aWxsDQo+PiA+PmJlDQo+PiA+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0 YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0KPj50byBiZQ0KPj4gPj4gPj4+ID4+ ZHJpdmVuIGJ5DQo+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5n cyB0byBjbGllbnRzLCBhbmQgZW5hYmxlDQo+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4gPj4g Pj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmls eSBwb2xpY3kNCj4+ID4+ZHJpdmUuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBJ IGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUN Cj4+ID4+ZHJpdmVuDQo+PiA+PiA+Pj5ieQ0KPj4gPj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3Np ZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzDQo+PiA+PmhhcmRlcg0K Pj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PnNlZQ0KPj4gPj4gPj4+ID4+ID4+IGhvdyB0byBtYWtl IGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+PiA+PiA+ Pj4gPj4gZHluYW1pY2l0eQ0KPj4gPj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9y Lg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9z dCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlzDQo+PiA+Pm91dHNpZGUNCj4+ID4+ ID4+Pm9mDQo+PiA+PiA+Pj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29y a2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBhcmUNCj4+ID4+dGFza2VkIHRvDQo+ PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gPj4gPj4+ID4+ID4+b24uDQo+PiA+PiA+Pj4gPj4gPj4gU28g SSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhDQo+PmNl cnRhaW4NCj4+ID4+ID4+PndheS4NCj4+ID4+ID4+PiA+Pml0DQo+PiA+PiA+Pj4gPj4gPj4gaXMg anVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+PiA+PiA+ Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+PiBKb2VsDQo+ PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4g U21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5m b3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ID4+IHRoYXQNCj4+ID4+ID4+PiA+ Pm5lZWRzDQo+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+PiBiZSB3aWRlbHkg ZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW4NCj4+ID4+YWNyb3Nz DQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1p bmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+PmFuZA0KPj4gPj4gPj4+IGNvbXBs ZXgNCj4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRv IGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4g Pj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0 aGFuDQo+PmR5bmFtaWMNCj4+ID4+ID4+PiByb3V0aW5nLA0KPj4gPj4gPj4+ID4+ID4+PiBoeXBl ci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBvciBETlMsIGFsbCBvZg0KPj53aGlj aA0KPj4gPj5hcmUNCj4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4gPj4gPj4+ID4+ID4+PiBwcm9ibGVt cyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFibHkgaW1wbGVtZW50ZWQ/DQo+PiA+ PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCBy ZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPj5pcw0KPj4gPj5hDQo+PiA+PiA+Pj5n b29kDQo+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBpcyB0b28gY29tcGxpY2F0ZWQuDQo+ PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJu IFtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4+ID4+ ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4gPj4g Pj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgbWlrZWJpYW5j QGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4+SWFuDQo+PiA+PiA+Pj5TbWl0 aDsNCj4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiA+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMs IGFuZCBMb2FkDQo+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+ PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxkDQo+ PnByZWZlcg0KPj4gPj53ZQ0KPj4gPj4gPj4+ID4+ID4+PmFjdHVhbGx5DQo+PiA+PiA+Pj4gPj4g Pj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4g Pj5pbXBsZW1lbnRhdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+IEJlY2F1c2UgaXQgZG9lcyBoYXZl IGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+PiA+PnJlcXVpcmVtZW50cw0KPj4gPj4g Pj4+YW5kDQo+PiA+PiA+Pj4gPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkg b2YgU0ZGcy4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gRm9yIG1lLCB0aGUg YW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2VzDQo+PiA+PnRoYXQN Cj4+ID4+ID4+PiBuZWVkcw0KPj4gPj4gPj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+IGJlIHdp ZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbg0KPj4gYWNy b3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+IGNlbnRlcnMgd2l0aGluIGFuIGFk bWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+YW5kDQo+PiA+PiA+Pj5jb21w bGV4DQo+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRv IGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlmZmljdWx0DQo+PiA+PiA+Pj4gPj4g Pj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ ID4+ID4+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+Pj4gSm9lbA0KPj4gPj4gPj4+ID4+ID4+Pg0K Pj4gPj4gPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdy b3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMg dGhlIGVuZCB0byBlbmQNCj4+c2VsZWN0aW9uDQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+PiAo dG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGUN Cj4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4gPj4gPj4+PiBvciBob3AtYnktaG9w IChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJzZXF1ZW50bHkNCj4+ID4+dGhlDQo+ PiA+PiA+Pj4gPj5TRkZzKT8NCj4+ID4+ID4+PiA+PiA+Pj4+IFN1Y2ggc2VsZWN0aW9uIGlzIG5v dCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+PkFuZA0KPj4gPj4gPj4+c3VyZWx5 LA0KPj4gPj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBu b3QgcmVsZWdhdGVkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPj4g Pj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9y IHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiB0aG91Z2gNCj4+ID4+IGENCj4+ID4+ ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFu ZCBwZXJoYXBzDQo+PmxvY2FsDQo+PiA+PiA+Pj4gPj5zZWxlY3Rpb24NCj4+ID4+ID4+PiA+PiA+ Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24gcG9p bnRzLg0KPj4gPj5UaGlzDQo+PiA+PiA+Pj4gPj4gPj4+PiBhcHByb2FjaCBkb2VzIG5vdCByZXF1 aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+PiA+Pk15DQo+PiA+PiA+Pj4gPj4g Pj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRy aXZlbg0KPj5ieQ0KPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+PiA+PiA+Pj4gPj4gPj4+PiByZXNp bGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGENCj4+Z2xvYmFs DQo+PiA+PiA+Pj5wYXRoDQo+PiA+PiA+Pj4gPj5pZA0KPj4gPj4gPj4+ID4+ID4+Pj4gYXBwcm9h Y2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kIG5lZWRpbmcgdG8NCj4+ID4+ YWx0ZXINCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4gZ2xvYmFsIHBhdGggSUQgdGFi bGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkDQo+PmVuZC10by1lbmQNCj4+ID4+ID4+PnBh dGguDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUm9uDQo+PiA+PiA+Pj4g Pj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxw ZXJuIERpcmVjdA0KPj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5 IDEwLA0KPj4yMDE0DQo+PiA+PiA2OjE1DQo+PiA+PiA+Pj4gUE0NCj4+ID4+ID4+PiA+PiA+Pj4+ IFRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+OyBJLlNtaXRo QEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCj4+IFN1YmplY3Q6DQo+PiA+PiBSZToNCj4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4g Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0 aGUgY2FzZSBvZiBTRjEgbmVlZGluZw0KPj50bw0KPj4gPj4gPj4+ID4+aW5mbHVlbmNlDQo+PiA+ PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUgd291bGQgZG8gcmVjbGFzc2lmaWNh dGlvbiBhdCB0aGUNCj4+ZXhpdA0KPj4gPj5mcm9tDQo+PiA+PiA+Pj4gPj4gPj4+PiBTRjEuDQo+ PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0 byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+PiA+PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUg aG93IHRoZXkNCj4+ID4+IGNob29zZQ0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PiA+Pj4+IGNv bXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1p a2ViaWFuY0Bhb2wuY29tPiB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+PiBJIGRvbid0IHNlZSBh bnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueQ0KPj4gPj5zb3J0DQo+ PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNl ZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlDQo+PiA+PnBhdGgNCj4+ID4+ID4+PihhbGwN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlh dGlvbi4gSSBiZWxpZXZlDQo+PnRoaXMNCj4+ID4+ID4+Pm1lYW5zDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBjbGFzc2lmaWVyDQo+PmNo b29zZXMgYQ0KPj4gPj5TRg0KPj4gPj4gPj4+ID4+Q2hhaW4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBh bmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0IFNGRi4gSW4gYW55IGNhc2UsDQo+ PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdlIGRvZXMgc2VlbSB0byBwcm9oaWJp dCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNGSShuKQ0KPj4gPj4gPj4+IGlzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRp bmcgdG8gdGhlIGRyYWZ0LA0KPj4gPj50aGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYmVoYXZpb3Ig d291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBTRlAgYXMNCj4+ID4+ID4+ PiBvcHBvc2VkDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiBjaG9vc2luZyBh bmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZg0KPj4gPj50aGUN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVj dHVyZS0wMDoNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVk IGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ID4+bmVjZXNzYXJ5DQo+PiA+PiA+Pj50bw0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhh dCB3aWxsIGJlIHVzZWQsDQo+PiA+PmFuZCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjcmVhdGUg dGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MNCj4+ID4+bmV0d29y aw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRo ZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4+ID4+ID4+PmNyZWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIGFuZCBpcyB1c2VkIGZvcg0KPj4g Pj5mb3J3YXJkaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZD LiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBpbnN0 YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNh dGlvbiAob3INCj4+ID4+bm9uLWluaXRpYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmlj YXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4gU0ZQLA0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAtIHR5cGljYWxseSBwZXJmb3JtZWQg YnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNp ZGVudCB3aXRoIGEgc2VydmljZQ0KPj4gPj5mdW5jdGlvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g UmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBzZWxlY3Rpb24gb2YgYSBuZXcNCj4+ ID4+U0ZQLCBhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQg bWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4+ID4+cmVmZXJyZWQNCj4+ID4+ID4+PnRvDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0tLQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0t DQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPG1haWx0bzoqSS5TbWl0aEBGNS5jb20+PEku U21pdGhARjUuY29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g KlRvOiAqSm9lbCBIYWxwZXJuDQo+PiBEaXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208 bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPj4gPj4gTS4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4NCj4+ID4+DQo+PiA+Pj4+Pkhh bHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LGh1 YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjxodWFuZ0Bz Y2UuDQo8bWFpbHRvOmh1YW5nQHNjZS4lMGI+Pj4gPj4gPj4+ID4+IGNhcmxldG9uLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPjxzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ICpTZW50OiAq VGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ID4+ID4+PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PiA+PkJhbGFuY2Vycw0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsg SSBhbSBkaXNhZ3JlZWluZy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPj50 aGF0IGlzDQo+PiA+PiA+Pj53aGF0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gMTYgbWlsbGlvbiBmbG93 cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXMNCj4+ID4+ID4+PnByZWNvbmNl aXZlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNo aXRlY3R1cmUgYnVyZGVuZWQgd2l0aA0KPj4gdGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHByZWNv bmNlcHRpb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBUaGVyZSBo YXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mDQo+PiA+PmFzcGlyYXRp b24NCj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0 ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZQ0KPj4gPj5hcmNoaXRlY3R1cmUNCj4+ID4+ID4+Pi0N Cj4+ID4+ID4+PiA+PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1 dCBieSBzYXlpbmcgdGhhdCBhbg0KPj4gPj4gPj4+YXJiaXRyYXJ5DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gbnVtYmVyIGlzICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdCBpc24n dA0KPj4gPj4gPj4+ID4+aW50ZW50aW9uYWwNCj4+ID4+ID4+PiA+PiA+Pj4+PiAtIGEgbGltaXQg dGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZw0KPj4gPj5pbXBhY3Rz DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxlLW91dCwgZmFpbHVyZSBtaXRpZ2F0 aW9uLCBlbGFzdGljaXR5LA0KPj4gPj5hZGRyZXNzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc3BhY2Uu Li4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdA0KPj4gPj4g Pj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW2ptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5dDQo+PiA+ PlNlbnQ6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNTowNCBQ TSBUbzogSWFuIFNtaXRoOyBKb2VsIE0uDQo+PiA+PiBIYWxwZXJuOw0KPj4gPj4gPj4+ID4+ID4+ Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsg c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbc2ZjXQ0KPj4g Pj5TZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBJYW4sIEkgZG9u J3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxsIGluIHRoaXMNCj4+ID4+cmVnYXJk Lg0KPj4gPj4gPj4+SQ0KPj4gPj4gPj4+ID4+YW0NCj4+ID4+ID4+PiA+PiA+Pj4+PiBub3QgcmVx dWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+ID4+cHJvaGli aXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlv bi4gSSBhbSBvYmplY3RpbmcgdG8NCj4+ID4+SHVhbmcncw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJl YWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZQ0KPj4g Pj4gcmVxdWlyZWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUu DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBBcyBJIGhhdmUgc2FpZCBy ZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJvaGliaXQNCj4+c3VjaA0KPj4gPj4gPj4+ ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVw ZW5kcyB1cG9uDQo+PiA+PiBtYW55DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBvdXRzaWRl IG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+PnRoaW5rDQo+PiA+PnRoYXQN Cj4+ID4+ID4+PiA+PnRoZXkNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBp ZGVhLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNo dGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVtcHRpbmcgdG8NCj4+ID4+a25vdw0K Pj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlzIGFuZCBpcyBub3QgZXBsb3lhYmxl Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gWW91cnMsIEpvZWwNCj4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0s IElhbiBTbWl0aCB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3Rh dGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+PiA+PiA+Pj5taWxsaW9ucw0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBvZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3Mg aW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50ZXINCj4+ID4+ID4+PiA+PiA+Pj4+ PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGlu DQo+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lv VCB3b3JsZCBvZiB0b21vcnJvdyB5b3UNCj4+IGFyZQ0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ID4+ IGdvaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZp Y2UgY2hhaW5zIHdpdGggZXF1YWxseQ0KPj5zbWFsbA0KPj4gPj4gPj4+IG51bWJlcnMNCj4+ID4+ ID4+PiA+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBwYXRocz8NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25l IHdpbGwgZXZlciBuZWVkIG1vcmUNCj4+IHRoYW4NCj4+ID4+ID4+PiA2NEsiDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+IGZvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+ XSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+XQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4gPj4g Pj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+Ow0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gU3Vi amVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywNCj4+YW5kDQo+PiA+PiA+Pj5M b2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmll cyB0byBkZXBsb3kgdGhlDQo+PiA+PiA+Pj5hcmNodGlldHVyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNlZWQgdGhlIGxpbWl0cyBvZg0KPj50 aGVpcg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMg bm90IHJlcXVpcmUgc3VjaCBhYnN1cmQNCj4+IHVzZQ0KPj4gPj4gb2YNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQgaG93IHRvIHdy aXRlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQg aXQsIHRoZSBhcmNoaXRlY3R1cmUNCj4+ZG9lcw0KPj4gPj4gPj4+cGVybWl0DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcgdGhhdCB0aGUgYXJjaHRpZWN0dXJl DQo+PiBwZXJtaXRzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQg aXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4+ID4+dGhlDQo+PiA+PiA+Pj53b3Jr Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90 ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZp Y2UgY2hhaW5zLCBpdCB3aWxsDQo+Pm1lYW4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCww MDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcNCj4+dGFibGUNCj4+ID4+ b2YgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBl cm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3Mg YSByYW5nZSBvZiBkZXBsb3ltZW50cywgZnJvbQ0KPj4xDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4g c2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGUNCj4+dGhh dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBj b21wbGV4aXRpZXMgaWYgdGhleQ0KPj4gPj5jaG9vc2UNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2luZyBhbmQgaW4g c3RlYWQNCj4+ID4+IHByb3Zpc2lvbg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IDE2MCwwMDAgc2Vy dmljZSBwYXRocy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3Ig YSA0IGhvcA0KPj4gPj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiB3aXRo IDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAq T24gQmVoYWxmDQo+PiBPZg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1 bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ID4+MzowMw0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBMdWN5IHlvbmcgKkNjOiogam1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz47DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4gKlN1 YmplY3Q6KiBSZTogW3NmY10gU2VydmljZQ0KPj4gQ2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJ RCBkcml2ZXMgdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+ ID4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBtaW5vciBj aGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgdG8NCj4+ID4+IGRlcml2ZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0 ZWQgdHJhbnNwb3J0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8NCj4+ c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGgg KG9yIGdyYXBoKSB0aGF0IHBhY2tldHMNCj4+bXVzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0aGUgZXhhY3QNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9wbGUgc2VlbSB0byBiZSBhc2tpbmcg Zm9yIG9uDQo+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1w bHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRoDQo+PiA+PiBpZGVudGlmaWVyDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFuIGEgbG9va3VwLCB0aGF0IGxv b2t1cCBjYW4NCj4+ID4+IHJlc3VsdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiBhIG9uZSBv ciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0IG5leHQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBQYXVsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPg0KPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT48bWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tJTNlPj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3Vs ZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZg0KPj4gdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+PiA+PmFj dGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1 Y3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206 KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpPbiBCZWhhbGYNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86T2YqbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0 bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4gPj4gPj4+ICpTZW50OipUaHVyc2Rh eSwNCj4+ID4+ID4+PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6 MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86Km1pa2ViaWFuY0Bhb2wuY29tPg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjtqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4u Y29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ O3NmY0BpZXRmLm9yZzxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoq UmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZp Y2UgcGF0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1 c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+PmRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBm b3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8gaGF2ZSB0aGUgZnVsbCBrbm93bGVk Z2Ugb2YNCj4+ID4+IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxl ZCBkb21haW4gaXMgbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQg Y29udGV4dHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3 aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRz OiB0aGF0IGlzIHRoZSBvbmUNCj4+IHJlcXVpcmVkDQo+PiA+PiB0bw0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBp cw0KPj4gPj51c2VkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcN Cj4+ID4+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEg c29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRl IGxhIHBhcnQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86 ZGUqbWlrZWJpYW5jQGFvbC5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPj4gPj4ganVpbGxldA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb208 bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZzxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86 c2ZjQGlldGYub3JnPiAqT2JqZXQgOipSZTogW3NmY10gU2VydmljZQ0KPj4gPj5DaGFpbnMsDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXMgYW55b25lIHN0aWxsIHF1 ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4+U0YNCj4+ID4+IENoYWluDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPj4gPj4gPj4+ID4+ID4+Pj4+IFBhdGg/DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUgZGVmaW5pdGlvbiBz byB0aGF0IGl0J3MNCj4+ID4+Y2xlYXIgdG8NCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1z IHRoYXQgZXZlcnlvbmUNCj4+YWdyZWVzDQo+PiA+Pm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRoZXNlIHRlcm1zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMNCj4+d2hl dGhlcg0KPj4gPj5pdCBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRo aXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQNCj4+ID4+dGhlIElEDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2hv dWxkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBw YXRoKSwgb3IgaWYgdGhpcyBkcmFmdA0KPj4gPj5zaW1wbHkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXINCj4+ZHJh ZnRzDQo+PiA+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRpY3RhdGUgdGhlIG1lY2hhbmlz bXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4NCj4+IG9yDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4+ID4+ID4+PiA+PiA+Pj4+ PiBwYXRoIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNv bnRyb2wtcGxhbmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0IGJvdGggU0ZQIGFuZCBTRkMgYmUg c3VwcG9ydGVkIChvciBtYWtlDQo+PiA+PiBvbmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVx dWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZQ0KPj4gdmVuZG9ycw0K Pj4gPj4gb25seQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdXBwb3J0aW5nIFNGUCBhbmQgb3Ro ZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4g Pj4+DQo+PiA+Pg0KPj4NCj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4g Pj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+PiA+Pj4+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+Pj4+Pj4+LS0N Cj4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAqRnJvbToqam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86KmptaEBqb2Vs aGFscGVybi5jb20+PGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUz Y2ptaEBqb2VsaGFscGVybi5jb20lM2U+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqVG86KnNm Y0BpZXRmLm9yZzxtYWlsdG86KnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNj c2ZjQGlldGYub3JnPjxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnJTNlPj4NCj4+ ICpTZW50OipUdWVzZGF5LA0KPj4gPj4gSnVseQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAy MDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj5Mb2FkDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBo b3cgdG8gY2xlYXJseQ0KPj5hbnN3ZXINCj4+ID4+YQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBu dW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGUNCj4+ID4+ID4+ PiBwcm9wb3NlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRy YWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0DQo+PiB3b3JraW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+IGlt cHJvdmUNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQg cmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGluDQo+PiA+PnRoZQ0KPj4gPj4gV0cN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3aWxsIHVuZGVyc3RuZCBpdCB0aGUg d2F5IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHdvcmtpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkN Cj4+ID4+cGVyc29uYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlldywgYW5kIHNlZSBpZiB0 aGF0IGhlbHBzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0DQo+ PiA+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgYXJlIGRlZmluaW5nIGlzIHRoZSBk YXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UNCj4+YXJlDQo+PiA+PiBub3QNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhl IGVudGlyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFp bmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3MNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JT UywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rpb25zLA0KPj52aXJ0dWFsDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55 IG90aGVyDQo+PiA+PiBhc3BlY3RzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xl YXJseSBuZWVkDQo+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFy Z2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRoDQo+PiA+PmFib3ZlDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9u aW5nLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJl ZCBieSB0aGUgd29yayB3ZSBhcmUNCj4+IGRvaW5nLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2 cyBzZXJ2aWNlIHBhdGgsDQo+PmFzIEkNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFu ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVl ZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBUaGVyZSBhcmUgYXQNCj4+ID4+bGVh c3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2Fk IGJhbGFuY2luZyBjYW4gYW5kDQo+PndpbGwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJh Y3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseSBhcmUNCj4+ID4+bW9yZS4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNodGllY3R1cmUgaXMg dG8gcGVybWl0IGFsbCBvZg0KPj4gPj50aGVzZSwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZA0KPj4gPj4gPj4+ID4+ID4+ Pj4+IGJlIHVzZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNvbHV0aW9uLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFu Y2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZA0KPj4gPj51c2VyLg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQgcmVjZWl2ZXMg dXNlcg0KPj5wYWNrZXRzLA0KPj4gPj5hbmQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZp ZXMgdGhlbSAob3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBtYXJrcw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlDQo+ PiA+Pmluc3RhbmNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIHJlY2VpdmUgdGhlIHVzZXJz IHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQNCj4+ID4+c2VydmljZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFp bmluZy4NCj4+ID4+SXQncw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZm ZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZQ0KPj4gPj4gY2hhaW5pbmcgaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24g dGhlDQo+PiA+PmFyY2h0aWVjdHVyZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gRnJvbSBhbiBh cmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYQ0KPj4gPj4gPj4+ID4+ID4+ Pj4+IHNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gd2hpY2ggbWF5IG1v ZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBU aGF0IGlzLCBvbmUNCj4+Y2FuDQo+PiA+PmhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hh dA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8g dGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlDQo+PnBvaW50DQo+ PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBmb3IgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9u LCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkDQo+PiA+PmJ5IGENCj4+ID4+ID4+PiA+PiA+Pj4+ PiBjb2xsZWN0aW9uIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2lj YWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZw0KPj5vbmUgb3INCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1s aWtlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRk cmVzcy4pIG1vc3RseSwgdGhpcyBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbnZpc2libGUg dG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0KPj4gPj5tZWNoYW5pc21zLg0KPj4g Pj4gSXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlrZWx5IHRoYXQgaXQgaXMgdmlzaWJs ZSB0byB2YXJpb3VzIGNvbnRyb2wNCj4+ID4+bWVjaGFuaXNtcywNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwN Cj4+YW5kDQo+PiA+PnZtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRo ZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZg0KPj5wZXJtaXR0aW5nDQo+PiA+PnRoaXMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2FyZWZ1bCB0 aGF0IG91cg0KPj4gPj50ZXJtaW5vbG9neQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzIG5v dCBsZWFkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGVycyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5j aW5nIGRvbmUgYnkNCj4+c2VsZWN0aW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBw YXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+ID4+dHJhZmZpYw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQgcGxhY2VzLiBXZSB3b3VsZCBub3Qg d2FudCB0byByZXF1aXJlDQo+PiB0aGF0DQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g Z2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4NCj4+dGhl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRo ZXNlIG1heSBiZQ0KPj5jb21iaW5lZC4gSQ0KPj4gPj4gdGVuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZpY2UNCj4+ ID4+Y2hhaW5pbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBzaW5nbGUgcG9pbnQgYXMg YSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyDQo+PmlzDQo+PiA+PmENCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIg b25lLg0KPj4gVGh1cywNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBv ZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBpcyB0bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBk aWZmZXJlbnQNCj4+ID4+c2luZ3VsYXINCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb3IgY2x1c3Rl cmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwbGFjZXMNCj4+aW4NCj4+ID4+dGhl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRoYXQgc2FpZCwgd2hhdCBkbyBJIG1l YW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFp biBhbmQgc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGENCj4+ID4+IHNlcXVlbmNlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQg dG8gYSBzdWJzZXQgb2YNCj4+ID4+cGFja2V0cy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQg aXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZg0KPj50cmFmZmljDQo+ PiA+PmlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250 ZW50IGluc3BlY3Rpb24sIGFuZA0KPj5maXJld2FsbA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3 aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGlyZWN0bHkgdG8gdGhlDQo+PmNhY2hl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0aG91dA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNp dGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0 byBkaXJlY3QgdGhlDQo+PnBhY2tldHMuDQo+PiBBDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNl cnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNlcXVlbmNlIG9mDQo+PiA+PmxvY2F0 aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRp b25zIHdpbGwgYmUgc2luZ3VsYXIgb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVk IHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25zLiBUaGV5DQo+PiA+Pm1heSBiZQ0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkg YmUgYWRkcmVzc2VkIGFzDQo+PiBwb3J0cw0KPj4gPj4gb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZQ0KPj4gPj5s b2NhdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5IGJlIGtub3duIHRvIHRoZSBzZXJ2 aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlDQo+PiBhbmQNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRo ZSBTRkMNCj4+Z3JvdXAsDQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0 byBiZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2gg bGV2ZWwgYWJzdHJhY3Rpb24sIHRoZQ0KPj4gPj5zZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvDQo+ PiB0YWxrDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFib3V0IHRoZSBhY3R1YWwgZGF0YSBwYXRo IHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3Jr Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFs IG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUgd2hvbGUNCj4+IHBhdGgNCj4+ID4+ IG1heQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIg VGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMNCj4+ID4+d2l0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMgbm90ZWQgaW4gaXRlbSAoMikNCj4+ b24NCj4+ID4+bG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRo ZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kDQo+PmJlaGF2aW9ycw0KPj4gPj4gd2hpY2gNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBt ZWNoYW5pc21zIChpbg0KPj4gPj5tdWNoDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBzYW1l IHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFOcy4pIFRoZSBvdGhlcg0K Pj4gcHJvdmlzaW9uDQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiByZWNsYXNzaWZp Y2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuDQo+PiA+PiBuZWNlc3NhcnkuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJlY3QgcGFja2V0cyB0byBhIG5ldyBj aGFpbi4gQmFzZWQgb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYXZhaWxh YmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPj5wb2ludC4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyBleHBs YWluIHdoYXQgd2UgYXJlIGFmdGVyLg0KPj5JZiBpdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBk b2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3JraW5nDQo+PiA+ PiBncm91cCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBh ZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQNCj4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBkaXNhZ3JlZSB3aXRoIHRoZQ0KPj4g Pj4gaW50ZW50LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNl IGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZw0KPj4gPj5ncm91cA0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVuY2xlYXIsIEkgYW0gbm90IHN1 cmUNCj4+ID4+d2hhdCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBzZmMNCj4+ID4+ ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4g Pj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNmYw0KPj4gPj4gPj4+ID4+IG1h aWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gc2ZjDQo+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+ID4+PiBtYWlsaW5nDQo+PiA+PiA+Pj4g Pj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QN Cj4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHNmYw0KPj4gPj4gbWFpbGluZw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+ PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1h aWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+ID4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gPj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+DQo+PiA+PiA+Pj4gPj4gPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4g Pj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiA+c2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+PiA+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPj4+ID4+IHNmYyBtYWlsaW5n IGxpc3QNCj4+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ ID4+ID4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4gPj4+DQo+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+ID4+ID4+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4NCj4+ID4+ID5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ ID4+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0K --_000_CFE95ABE4BE2Bsmkumarciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <63CD102453D8A742B4FE88C767FDA904@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+ DQpNYXJpYSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQpJbmxpbmUuPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G cm9tOiA8L3NwYW4+Jmx0O05BUElFUkFMQSZndDssIE1BUklBIEggJmx0OzxhIGhyZWY9Im1haWx0 bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBKdWx5IDE0LCAyMDE0IDY6 MjAgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Sb24g UGFya2VyICZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCBYdXhpYW9odSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1YXdlaS5jb208 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlh bmNAYW9sLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4mZ3Q7LCAmcXVvdDtKaW0gR3VpY2hhcmQgKGpndWlj aGFyKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNo YXJAY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxu czp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRt bDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250 IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2lt U3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAx MSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBV SSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrm ibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAuYSwgbGkuYSwgZGl2LmEN Cgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5IVE1MQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7m oLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5DaGFyMA0KCXttc28t c3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpwLmEwLCBsaS5hMCwgZGl2LmEwDQoJe21zby1zdHlsZS1uYW1lOue6r+aWh+acrDsN Cgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3Vu O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4g MS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRp diBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5UaGUgbWVhbmluZyBvZiB0 aGUgU0ZQIElEIGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8gbWUg4oCTIGFuIGFic3RyYWN0 IGlkZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9mIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2Vz IChpLmUuLCBTRlAgSUQgMQ0KID0ge1NGLUEtMSwgU0YtQi0zLCBTRi1DLTJ9KS4mbmJzcDsmbmJz cDsmbmJzcDsgSW4gc29tZSB3YXlzLCBpdCBpcyBhIGNvbGxhcHNlZCDigJxsYWJlbCBzdGFja+KA nSDigJMgdGhlcmUgaXMgYSBzaW5nbGUgdGFnIGltcGx5aW5nIHNvbWUgc2VxdWVuY2Ugb2YgbmV0 d29yayBsb2NhdGlvbnMuJm5ic3A7Jm5ic3A7IEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxl YXN0IHRvIG1lLCB0aGF0IHRoZXJlIGlzIGEgY2VudHJhbCBwb2ludCBvZiBzZWxlY3Rpb24gZm9y IHRoaXMgZW5kIHRvIGVuZCBzZXF1ZW5jZQ0KIChiYXJyaW5nIHJlY2xhc3NpZmljYXRpb24sIG9m IGNvdXJzZSkuJm5ic3A7Jm5ic3A7IEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQgaW1w bGljYXRpb24uJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSBiZWVuIHVuY29tZm9ydGFibGUgd2l0 aCB0aGF0IGNlbnRyYWwgcG9pbnQgbWV0aG9kb2xvZ3kgZHVlIHRvIHJlYWwtd29ybGQgY29tcGxl eGl0aWVzIG9mIGR5bmFtaWMgc2NhbGUgYW5kIHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFp bHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4m bHQ7TWFyaWEmZ3Q7IEkgYWdyZWUuIEl0IHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgYnkgdGhlIFNG QyBhcmNoaXRlY3R1cmUgdGhhdCBzb21ldGhpbmcgY2FsbGVkIOKAnHNlcnZpY2UgZnVuY3Rpb24g cGF0aCBJROKAnSBpcyBjYXJyaWVkIGluIHRoZSBwYWNrZXQsIGJlY2F1c2UNCiBpdCBpcyBub3Qg bmVjZXNzYXJ5IG9yIHRoZSBvbmx5IHdheSB0byBpbXBsZW1lbnQgc2VydmljZSBjaGFpbmluZy4g VGhlcmUgbWlnaHQgc29sdXRpb25zIHRoYXQgd291bGQgZG8gdGhhdCBidXQgaXQgY2Fubm90IGFu ZCBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRlZC48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NClNLJmd0OyBJIGRpc2FncmVl IG9uIHRoZSAmcXVvdDtub3QgbmVjZXNzYXJ5JnF1b3Q7IHBhcnQgYXMgaXQgbGVhZHMgdG8gYSB2 ZXJ5IGluZWZmaWNpZW50IG1ldGhvZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 ICI+DQpMZXQncyBwYXJrIGFzaWRlIHRoZSBTRkMgdnMgU0ZQIGRlYmF0ZSBhbmQgc2F5IFNGQz09 U0ZQIGZvciB0aGlzIGV4cGxhbmF0aW9uLiBBIGNsYXNzaWZpZXIgbWF5IGRldGVybWluZSBTRlAg SUQgYmFzZWQgb24gYSBub24tdHJpdmlhbCBmdW5jdGlvbiwgbWF5IGJlIGEgRFBJLCBhcyBwYXJ0 IG9mIGl0cyBjbGFzc2lmaWNhdGlvbi4gTm90IGNhcnJ5aW5nIHRoZSBJRCByZXF1aXJlcyByZWNs YXNzaWZpY2F0aW9uIGFmdGVyIGV2ZXJ5IFNGIGluIG9yZGVyDQogdG8ga2VlcCB0aGUgcGFja2V0 cyBvbiB0aGUgcmlnaHQgU0ZQLCBpbiB0aGlzIGNhc2UgYSBEUEkuIEV2ZW4gdGhhdCByZWNsYXNz aWZpY2F0aW9uIG1heSBiZSB0byBsYXRlIGlmIG9uZSBvZiB0aGUgU0ZzIHRyYW5zZm9ybWVkIHRo ZSBwYWNrZXQuJm5ic3A7U28sIHlvdSBkbyBuZWVkIGEgU0ZQIElEIGZvciBjaGFpbmluZyB0byBi ZSB1c2VmdWwuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KU0smZ3Q7IEFuZCBmb3IgdGhlIGFy Z3VtZW50IGFib3V0IG5vdCBuZWVkaW5nIFNGUCBJRCBidXQgb25seSBTRkMgSUQsIGFyY2hpdGVj dHVyZSBkb2VzIG5vdCBwcmV2ZW50IDE6MSBtYXBwaW5nIGJldHdlZW4gdGhlbS48L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7ICI+DQpTdXJlbmRyYS48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7ICI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtc2l6ZTog MTFwdDsgIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1h cy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3Lncz Lm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyAiPk1hcmlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+ QW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gc3RpbGwgdXNlIGNlbnRyYWwgc2VsZWN0aW9u IHRvIHNlbGVjdCB0aGUgY2hhaW4gb2YgYWJzdHJhY3Qgc2VydmljZSBmdW5jdGlvbnMgKGkuZS4s IFNGQyBJRCAxID0ge1NGLUEsIFNGLUIsIFNGLUN9KSwgYnV0IGFsbG93IHRoZSBhY3R1YWwNCiBp bnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQsIHJlYWxpemVkIGJ5IHRoZSBjbGFz c2lmaWVyIGFuZCB0aGUgU0ZGcy4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyAiPkdpdmVuIGEgdG9wb2xvZ3kgbGlrZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj5DbGFzc2lmaWVyIC0tLS0tLS0mbmJzcDsg U0ZGLTEgLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZG LTMtLS0tLS0tLS0tLS0tLS0tLS0tU0ZGLTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtT RkYtQS0xJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO1NGRi1BLTImbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7U1NGLUItMSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTRkYtQi0yJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NGRi1DLTEmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7U0ZGLUMtMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTRkYtQS0zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7ICI+QW5kIGFzc3VtaW5nIGEgbmV3bHkgcmVjb2duaXplZCBmbG93LCB0aGUgc2VxdWVuY2Ug Y291bGQgZ28gc29tZXRoaW5nIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj4xIENsYXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0Yt QSwgU0YtQiwgU0YtQ308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgIj4yIENsYXNzaWZpZXIgc2VsZWN0cyBTRkYtMSBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBp bnN0YW5jZSBvZiBTRi1BPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7ICI+MyBDbGFzc2lmaWVyIGVuY2Fwc3VsYXRlcyBwYWNrZXQgaW5kaWNhdGluZyBjaGFpbiBJ RCA9IDEsIHNlcnZpY2UgaW5kZXggPSAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7ICI+NCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+NSBTRkYtMSwgc2Vl aW5nIGNoYWluIElEPTEsIHNlcnZpY2UgaW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3Qg aXRzIGF2YWlsYWJsZSBpbnN0YW5jZXMgb2YgU0YtQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyAiPjYgU0ZGLTEgc2VuZHMgcGFja2V0IHRvIFNGRi1BLTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj43IFNGRi1BLTEgc2Vu ZHMgcGFja2V0IGJhY2sgdG8gU0ZGLTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgIj44IFNGRi0xIGluY3JlbWVudHMgc2VydmljZSBpbmRleCB0byAyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+OCBTRkYtMSBzZWxlY3Rz IFNGRi0yIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj45IFNGRi0xIHByb2dyZXNzZXMg cGFja2V0IHRvIFNGRi0yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7ICI+MTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBTRkYtMywgYXMgdGhlIGVn cmVzcyBib3JkZXIsIHByb2dyZXNzZXMgdGhlIHBhY2tldCBwZXIgcm91dGluZyB0YWJsZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAiPlRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj4mbmJzcDsmbmJzcDsgUm9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgIj4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlh1eGlh b2h1PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVseSAxMywgMjAxNCAxMTozMCBQTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtlYmlhbmNA YW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPg0Kamd1aWNo YXJAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFA YXR0LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t Ij4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT47IFJvbiBQYXJrZXI7DQo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgcGFnZS1icmVhay1i ZWZvcmU6IGFsd2F5czsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNnB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+QWdyZWUg dGhhdCB0aGUgY3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBTRlAgaW4gdGhlIGFyY2ggZHJhZnQg aXMgYSBiaXQgY29uZnVzaW5nLCBqdXN0IGFzIHdoYXQgeW91IGhhZCBwb2ludGVkIG91dC4gPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBwYWdlLWJy ZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE2cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTZw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyAiPkluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBTRlAgYXMgYW4gaW5zdGFudGlhdGlvbiBv ZiBhbiBTRkMgaW4gdGhlIG5ldHdvcmsgc2hvdWxkIGJlIOKAnGFuIG9yZGVyZWQgbGlzdCBvZiBz ZXJ2aWNlIG5vZGVzIGFuZCBTRiBJRHPigJ0oc2VlPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNnB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7ICI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5n LXBjZS1iYXNlZC1zZmMtYXJjaC0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMTwvYT4pLiBPZiBjb3Vyc2UsIGhvdyB0byBy ZXByZXNlbnQgdGhlIFNGUCBpbiB0aGUgZGF0YSBwYWNrZXQgaXMgYW5vdGhlciB0aGluZyAoZS5n LiwgZWl0aGVyIHRocm91Z2ggYSBwYXRoIGlkIG9yIHRocm91Z2ggYW4gTVBMUyBsYWJlbCBzdGFj aykuIEhlcmUgdGhlIHNlcnZpY2Ugbm9kZSBtZWFucyB0aGUgZGV2aWNlIHdoaWNoIGNvbnRhaW5z IHRoZSBTRkYgYW5kIHRoZSBORiBjb21wb25lbnRzIG1hbmRhdG9yaWx5IHdoaWxlIGNvbnRhaW5p bmcgdGhlIFNGIGFuZCBTRiBwcm94eSBjb21wb25lbnRzIG9wdGlvbmFsbHkuIFRoZSBzZXJ2aWNl IG5vZGUgY291bGQgYmUgYXR0YWNoZWQgb3IgZW1iZWRkZWQgd2l0aCBtdWx0aXBsZSBTRiBpbnN0 YW5jZXMgYW5kIHRob3NlIFNGIGluc3RhbmNlcyBjb3VsZCBiZSBvZiB0aGUgc2FtZSBTRiB0eXBl IG9yIG5vdC4gJm5ic3A7SW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIFNGIGlu c3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlIChlLmcuLCBTRiBYKSBhcmUgYXR0YWNoZWQgdG8g YSBnaXZlbiBzZXJ2aWNlIG5vZGUsIHRoZSBzZXJ2aWNlIG5vZGUgY291bGQgZGlzdHJpYnV0ZSB0 aGUgdHJhZmZpYyB3aGljaCBuZWVkcyBTRiBYIGFtb25nIHRob3NlIFNGIGluc3RhbmNlcyBvZiBT RiBYIHR5cGUgbG9jYWxseS4gTWVhbndoaWxlLCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc2Vydmlj ZSBub2RlcyB3aXRoaW4gYSBnaXZlbiBTRkMtZW5hYmxlZCBkb21haW4gd2hpY2ggYXJlIGVtYmVk ZGVkIG9yIGF0dGFjaGVkIHdpdGggdGhlIFNGIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBl LiBJbiB0aGlzIHdheSwgdGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxkIGJlIG1hZGUgdmVyeSBm bGV4aWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTZwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTZwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTZwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7IGJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRl ci1sZWZ0LXdpZHRoOiAxLjVwdDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IHBhZGRpbmc6IDBp biAwaW4gMGluIDRwdDsgIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPiBzZmMg WzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gU2F0 dXJkYXksIEp1bHkgMTIsIDIwMTQgMjo0NiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1uMTkyMUBhdHQuY29tIj4NCm1uMTkyMUBhdHQuY29tPC9hPjsgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2Vs aGFscGVybi5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdv cmtzLmNvbSI+DQpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+V291bGRuJ3QgdGhh dCBiZSBjYWxsZWQgdGhlICZxdW90O3NlcnZpY2UgY2hhaW4gaWRlbnRpZmllciZxdW90OyB0aGVu PyAmbmJzcDtJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGcyBh bmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywg dGhlbiBJIHdvdWxkDQogaW5mZXIgdGhhdCBhICZxdW90O3NlcnZpY2UgcGF0aCBpZGVudGlmaWVy JnF1b3Q7IHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBh IHNlcnZpY2UgKmNoYWluKi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxicj4N CkFnYWluLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUgdGhlIGNvbmZ1c2lvbiBrZWVwcyBjcmVlcGlu ZyBpbi4gJm5ic3A7VGhlIHRlcm1zICZxdW90O2NoYWluJnF1b3Q7IGFuZCAmcXVvdDtwYXRoJnF1 b3Q7IHNlZW0gaW5jb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAl IiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbSI+ amd1aWNoYXJAY2lzY28uY29tJmx0O2pndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ VG86IDwvYj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2NtaWtlYmlhbmNAYW9s LmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21uMTkyMUBhdHQuY29tJTNlLG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJTNlLGptaEBqb2Vs aGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlLFJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJTNlLHNmY0BpZXRm Lm9yZyUzY3NmY0BpZXRmLm9yZyI+bWlrZWJpYW5jQGFvbC5jb20mbHQ7bWlrZWJpYW5jQGFvbC5j b20mZ3Q7LG1uMTkyMUBhdHQuY29tJmx0O21uMTkyMUBhdHQuY29tJmd0Oyxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7LGptaEBq b2VsaGFscGVybi5jb20mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssUm9uX1BhcmtlckBhZmZp cm1lZG5ldHdvcmtzLmNvbSZsdDtSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmd0Oyxz ZmNAaWV0Zi5vcmcmbHQ7c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+RnJp ZGF5LCBKdWx5IDExLCAyMDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WW91ciBkZWZpbml0aW9u IG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoIHRo cm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciBob3dldmVyIHBvaW50cyB0byB0aGUgc2VydmljZQ0KIGNoYWluIGRhdGEgc3Ry dWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJh c2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZhaWxhYmxl IGFuZCB3aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxheS4gV2hl biBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1h eSBvciBtYXkgbm90IHVwZGF0ZQ0KIHRoYXQgZGF0YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3aGlj aCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxkIGVm ZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aCBmb3IgdGhhdCBzZXJ2aWNlIGNoYWlu KSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVyIHByb3RvY29sIC8gbWVjaGFuaXNt IHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZSBmb3IgeW91Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Ni43NXB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0 Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyAiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogYmxhY2s7ICI+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5taWtl YmlhbmNAYW9sLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9s LmNvbSI+bWlrZWJpYW5jQGFvbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXks IEp1bHkgMTEsIDIwMTQgYXQgMTI6MTggUE08YnI+DQo8Yj5UbzogPC9iPkppbSBHdWljaGFyZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29t PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0 dC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTky MUBhdHQuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZxdW90Ow0KICZs dDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tIj5S b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJt YWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAi PkkgdGhpbmsgdGhpcyBpcyB0aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7ICI+Jmd0OyBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5PGJyPg0K Jmd0OyBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmlu YXRpb24gdGhlcmVvZikuIEk8YnI+DQomZ3Q7IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxi cj4NCiZndDsgYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcms8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PGJy Pg0KPGJyPg0KQnkgZGVmaW5pdGlvbiwgSSB1bmRlcnN0b29kIGEgJnF1b3Q7c2VydmljZSBwYXRo JnF1b3Q7IHRvIGJlIGFuIG9yZGVyZWQgbGlzdCBvZiBzcGVjaWZpYyBTRiBpbnN0YW5jZXMuIElu IHRoZSBzdGF0ZW1lbnQgYWJvdmUsIHlvdSB1c2UgYSAmcXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciZxdW90OyB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmljYWxs eSAmcXVvdDtbZG9lcyBub3RdIHNwZWNpZnkgc3BlY2lmaWMgaW5zdGFuY2VzJnF1b3Q7LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ni43NXB0Ij4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjoj OTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48Yj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNo YXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+ TkFQSUVSQUxBLCBNQVJJQSBIJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4x OTIxQGF0dC5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Jmd0OyxKb2VsIE0uIEhhbHBlcm4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyxSb24NCiBQYXJrZXImbHQ7 PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Oyw8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDogPC9iPkZyaWRheSwgSnVseSAxMSwgMjAx NDxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnM8YnI+DQo8YnI+DQpNYXJpYSw8YnI+DQo8YnI+DQpJIHRoaW5rIG9m IGl0IHRoaXMgd2F5LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgaXMgc2ltcGx5IGEgcG9p bnRlciB0bzxicj4NCmEgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBTRiB0byBuZXh0LWhv cCBtYXBwaW5ncy4gV2hlbiB5b3UgZGVmaW5lIGE8YnI+DQpjaGFpbiwgbGV0PHNwYW4gbGFuZz0i WkgtQ04iPuKAmTwvc3Bhbj5zIHNheSBTMSAtJmd0O1MyLSZndDsgUzMsIHlvdSAqbWlnaHQqIHdo ZW4gY3JlYXRpbmcgdGhlIFNGUCBzcGVjaWZ5PGJyPg0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0 aGF0IHlvdSB3YW50IHRyYWZmaWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC48YnI+DQpI b3dldmVyLCB5b3UgZG8gKm5vdCogaGF2ZSB0byBkbyB0aGlzIGZyb20gYW4gYXJjaGl0ZWN0dXJh bCBzdGFuZHBvaW50IChJPGJyPg0Kd2lsbCBhcmd1ZSB0aGF0IHlvdSBzaG91bGQgYnV0IHlvdSBk b248c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnQgaGF2ZSB0byBhcmNoaXRlY3R1cmFsbHkp LiBZb3U8YnI+DQpjb3VsZCBzaW1wbHkgYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIg dG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMgYW5kPGJyPg0KdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRp b24gaW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUgYTxicj4NCnNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIHRvIFNGQyBtYXBwaW5nIGFuZCBzYWlkIG1hcHBpbmcgd291bGQg Y29udGFpbiB0aGU8YnI+DQpuZXh0LWhvcHMgYXZhaWxhYmxlIGZvciBlYWNoIG9mIHRoZSBTRjxz cGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyB3aXRoaW4gdGhlIFNGQyAtIGhvdyB5b3UgbGVh cm48YnI+DQp0aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3UgY291bGQgcHVzaCB0aGVt IGRvd24gZnJvbSBhIGNlbnRyYWxpemVkPGJyPg0KY29udHJvbGxlciwgY29uZmlndXJlIHRoZW0g dGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaDxicj4NCnNvbWUgcHJv dG9jb2wgZXhjaGFuZ2UsIHdoYXRldmVyIC4uIFNvLCBnaXZlbiB0aGlzIGl0IGlzIG5vdCBjb3Jy ZWN0IHRvPGJyPg0Kc2F5IHRoYXQgdGhlIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBp bnN0YW5jZXMgYXJlIGNob3NlbiBhIHByaW9yaTxicj4NCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3Rs eSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvPGJyPg0K c28uPGJyPg0KPGJyPg0KTGV0PHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5zIHRha2UgYW4g ZXhhbXBsZSB0byBob3BlZnVsbHkgbWFrZSB0aGlzIGNsZWFyOjxicj4NCjxicj4NCkkgZGVmaW5l IGFuIFNGQyAobGV0PHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5zIHJlZmVyIHRvIGl0IGFz IFNGQy0xKSBTMS0mZ3Q7UzItJmd0O1MzLiBGb3IgYXJndW1lbnRzPGJyPg0Kc2FrZSBsZXQ8c3Bh biBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxseSBkeW5h bWljIGUuZy4gSSBkb248c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnQgd2FudCB0byBzcGVj aWZ5PGJyPg0Kc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNv bWJpbmF0aW9uIHRoZXJlb2YpLiBJPGJyPg0KYXNzaWduIGEgc2VydmljZSBwYXRoIGlkZW50aWZp ZXIgPHNwYW4gbGFuZz0iWkgtQ04iPuKAnDwvc3Bhbj4xMDA8c3BhbiBsYW5nPSJaSC1DTiI+4oCd PC9zcGFuPiB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtJmd0O1MyLSZndDtTMzxicj4NCmFu ZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0 cnVjdHVyZXMgYXJlPGJyPg0KcG9wdWxhdGVkIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gTm93IGF0 IGEgZ2l2ZW4gU0ZGLCB3aGVuIHRyYWZmaWMgYXJyaXZlczxicj4NCndpdGggc2VydmljZSBwYXRo IGlkZW50aWZpZXIgMTAwLCB0aGUgU0ZGIHdpbGwgbG9vayB0aGlzIHVwIGluIHRoZSBkYXRhPGJy Pg0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzMg YW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDPGJyPg0KZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwgaXQg ZXhhY3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldDxzcGFuIGxhbmc9IlpILUNOIj7i gJk8L3NwYW4+cyBzYXkgd2U8YnI+DQphcmUgYXQgUzIgaW4gdGhlIGNoYWluLiBUaGUgU0ZGIHdp bGwgbm93IGhhdmUgdG8gcmVzb2x2ZSB0aGUgbmV4dC1ob3AgdG88YnI+DQpTMyBhbmQgd2lsbCBk byBhIGxvb2t1cCB0byBkZXRlcm1pbmUgd2hlcmUgUzMgaXMgcmVhY2hhYmxlLjxicj4NCjxicj4N Ck9uIDcvMTEvMTQsIDExOjI2IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SmltLDxicj4NCiZndDs8YnI+DQomZ3Q7Q291bGQgeW91IHRl bGwgdXMgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhICZxdW90O3NlcnZpY2UgcGF0aCZxdW90 OyBhbmQgYTxicj4NCiZndDsmcXVvdDtzZXJ2aWNlIHBhdGggaWRlbnRpZmllciZxdW90Oz88YnI+ DQomZ3Q7SWYgYSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwgU0YgaW5zdGFuY2VzIGFyZSBj aG9zZW4gYXByaW9yaSAod2hpY2g8YnI+DQomZ3Q7aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5n KSB0aGVuIGl0IGlzIG5vdCBTRkYncyBsb2NhbCBkZWNpc2lvbiB3aGljaDxicj4NCiZndDtuZXh0 LWhvcCBTRkYgdG8gcGljay4gSXQgaXMgYSBjZW50cmFsaXplZCBkZWNpc2lvbi48YnI+DQomZ3Q7 PGJyPg0KJmd0O01hcmlhPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IDxicj4NCjxicj4NCkZyb206IEppbSBH dWljaGFyZCAoamd1aWNoYXIpIFs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29tIj5t YWlsdG86amd1aWNoYXJAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgMTE6MTUgQU08YnI+DQomZ3Q7Jmd0OyBUbzogTkFQSUVSQUxBLCBNQVJJ QSBIOyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IEpvZWwgTS48YnI+DQomZ3Q7Jmd0OyBIYWxwZXJu OyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSTxzcGFu IGxhbmc9IlpILUNOIj7igJk8L3NwYW4+bSBzb3JyeSBidXQgSSByZWFsbHkgZG9uPHNwYW4gbGFu Zz0iWkgtQ04iPuKAmTwvc3Bhbj50IHVuZGVyc3RhbmQgd2h5IGEgc2VydmljZSBwYXRoIGlkZW50 aWZpZXI8YnI+DQomZ3Q7Jmd0OyBwcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBTRiBuZXh0 LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgY2hhaW4gaWRl bnRpZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyBPbiA3LzExLzE0LCAxMDo1OCBBTSwgJnF1b3Q7TkFQSUVSQUxBLCBNQVJJQSBIJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBhdHQuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgJmd0O0RpdHRvLjxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+XTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxB LCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFBh cmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgUmUtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgRm9yIHdoYXQgSSBjYW4gc2F5IGF0IGJlc3QgdGhpcyBpcyBub3QgZGVzY3JpYmVkIGNs ZWFybHkgaW4gdGhlPGJyPg0KJmd0OyZndDtkcmFmdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1hbmRhdGluZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVy IGlzIGluIGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUgZnVsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ZGlzdHJpYnV0ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtb2RlbCBpcyBub3QgYWxsb3dlZC48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFNldmVyYWwgdm9p Y2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNlIGNoYWluIGl0c2Vs Zjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2hvdWxkIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg cHJvdmlkZWQgaW5zdGVhZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNZWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDstLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7RGUgOiBzZmMgWzxhIGhyZWY9Im1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0g RGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7KGpn dWljaGFyKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtFbnZveTxzcGFuIGxhbmc9IlpILUNO Ij7DqTwvc3Bhbj4gOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTg8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7w4AgOiBOQVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsg Um9uIFBhcmtlcjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09iamV0IDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPayBidXQgd2hlcmUgaW4gdGhlIGFyY2hp dGVjdHVyZSBzcGVjaWZpY2FsbHkgaXMgdGhpcyBmdW5jdGlvbmFsaXR5PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0O3Byb2hpYml0ZWQ/IElmIHlvdSB3YW50IHRvIGRpc3RyaWJ1dGUgKmFsbCog bmV4dC1ob3BzIHRvICphbGwqIFNGRjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+czxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDt3aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0 IHRoZSBwYXRoIGlkZW50aWZpZXIgcG9pbnQgdG8gYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9v a3VwPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O2ludG8gdGhvc2UgbmV4dC1ob3BzIHRvIHJl YWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBub3Q8YnI+DQomZ3Q7Jmd0O3N1cmU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hvdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDt0aGUg YXJjaGl0ZWN0dXJlIHByZXZlbnRzIHRoYXQ/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtPbiA3LzExLzE0LCA5OjU4IEFNLCAmcXVvdDtOQVBJ RVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+ bW4xOTIxQGF0dC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0O0Fic29sdXRlbHku PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBK aW0gR3VpY2hhcmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsoamd1aWNoYXIp PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVseSAx MSwgMjAxNCA5OjU0IEFNPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRvOiBO QVBJRVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGVuIEkgbWlzdW5kZXJzdGFu ZCB0aGUgcHJvcG9zYWwgOy0pIC4uIEhvd2V2ZXIsIGl0IHNlZW1zIHRvIG1lPGJyPg0KJmd0OyZn dDsgJmd0OyZndDt0aGF0IGlmPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHlv dSBhbGxvdyBhbiBTRkYgdG8gbWFrZSBhIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHJlbW90ZSBTRkYg aXQ8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2Zvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFp biB0aGVuIHlvdTxicj4NCiZndDsmZ3Q7YmV0dGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDttYWtl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHN1cmUgdGhhdCB0aGF0IHJlbW90 ZSBTRkYgaGFzIHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYyB0bzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7cmVhY2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbmV4dC1uZXh0LVNGIGZvciB0aGUgY2hh aW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0cm91YmxlLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBP biA3LzExLzE0LCA5OjQ4IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7QWJzb2x1dGVseSBu b3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBpbjxicj4NCiZndDsm Z3Q7cmVsZXZhbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtTRkZzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDt3aGVuIHRoZXkgJnF1b3Q7YXJyaXZl JnF1b3Q7Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEZyb206 IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSmltPGJyPg0KJmd0OyZndDtHdWljaGFy ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyhqZ3VpY2hhcik8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU2VudDogRnJpZGF5 LCBKdWx5IDExLCAyMDE0IDk6MjcgQU08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgVG86IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsgPGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgV2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRl cnN0b29kPGJyPg0KJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDtwcm9wb3NhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBjb3JyZWN0bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBl dmVyeSBzaW5nbGU8YnI+DQomZ3Q7Jmd0O1NGPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7d2l0aGluPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGVudGlyZSBT RkMgZG9tYWluIGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5IHRvPGJyPg0K Jmd0OyZndDtrbm93PGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7cHJpb3JpPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IHdoaWNoIFNGQzxzcGFuIGxhbmc9IlpILUNOIj7CuTwvc3Bhbj5z IGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbjxicj4NCiZndDsm Z3Q7cG9pbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7dGltZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgT24gNy8x MC8xNCwgMTE6NTMgUE0sICZxdW90O0pvZWwgTS4gSGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3RoZXIgbWFq b3IgcHJvYmxlbTxicj4NCiZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7eW91cjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7cHJvcG9zYWwgYXMgSSB1bmRl cnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1pdCBJIG1heSBub3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt1bmRlcnN0YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpdC4pPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0O1RoZSBwcm9wb3NhbCBoYXMgZWFjaCBTRkYgc2VydmUgYXMgdGhlIGxvYWQg YmFsYW5jZXIgZm9yIHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bmV4dDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2VydmljZSBmdW5jdGlvbiB0aGF0 IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJzPGJyPg0KJmd0OyZndDt0byksPGJy Pg0KJmd0OyZndDsgJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 O2V2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtz ZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtTaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGgg YWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZXZlcnk8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NGRiB3b3VsZCBoYXZlIHRvIGJl IGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtiYWxhbmNlci48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0O0kgYWh2ZSBubyBwcm9ibGVtIGlmIHNvbWUgU0ZGIGFyZSBm bG93IHNlbnNpdGl2ZSwgYW5kIC8gb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3N0YXRlZnVsLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7QnV0IGhhdmlu ZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBmdWxsLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7Zmxvdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7c2Vuc2l0aXZlLCBzdGF0ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0 byBtZSB0byBiZSBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNjZXB0YWJsZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW1wb3NpdGlvbi48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7WW91cnMsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtKb2VsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhh bHBlcm4gd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IFBhcnQgb2YgbXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRv IG1ha2UgdGhpczxicj4NCiZndDsmZ3Q7d29yazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O3NlbnNpYmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIGEgbW9yZSBvcmNoZXN0cmF0ZWQgZW52aXJvbm1lbnQu IEkgZXhwZWN0IHRoYXQgdGhlPGJyPg0KJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGZ1bmN0aW9ucywgYW5kIG92ZXIg dGltZSBwcm9iYWJseSB0aGUgU0ZGIGNhcGFiaWxpdGllcyw8YnI+DQomZ3Q7Jmd0O3dpbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2JlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IG9yY2hlc3RyYXRlZCBhbmQgaW5zdGFsbGVkLiBJIGV4cGVjdCB0 aGUgc2VydmljZSBjaGFpbnM8YnI+DQomZ3Q7Jmd0O3RvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmVuIGJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZl cmluZ3MgdG8gY2xpZW50cywgYW5kIGVuYWJsZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0O3NlbGYtc2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8g YmUgaGVhdmlseSBwb2xpY3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2RyaXZlLjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGNhbiBzZWUgaG93IHRv IG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2RyaXZlbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2J5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluaXRpYWwg Y2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuIEl0IGlzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtoYXJkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3NlZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBob3cgdG8gbWFr ZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxsb3cgbW9yZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkeW5hbWljaXR5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGluIHRoZSBuZXR3 b3JrIGJlaGF2aW9yLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNj cmliZWQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O291dHNpZGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3 ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Rhc2tlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2FncmVlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7b24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlzaW9u IG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYTxicj4NCiZndDsmZ3Q7Y2VydGFpbjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dheS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDtpdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBw cmVmZXJlbmNlcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsgT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBt ZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDtuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1h aW50YWluZWQsIHBvdGVudGlhbGx5IGV2ZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fjcm9zczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RhdGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhp biBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoPGJyPg0KJmd0OyZndDth bmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tcGxleDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGVub3Vn aCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2RpZmZpY3VsdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyY2hpdGVjdHVy ZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1vcmUgY29tcGxp Y2F0ZWQgdGhhbjxicj4NCiZndDsmZ3Q7ZHluYW1pYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyByb3V0aW5nLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaHlwZXItc2NhbGUgZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlv biwgb3IgRE5TLCBhbGwgb2Y8YnI+DQomZ3Q7Jmd0O3doaWNoPGJyPg0KJmd0OyZndDsgJmd0OyZn dDthcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtiaWdnZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRl ZD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxpY2F0ZWQs IHRoYXQ8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Z29vZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGlj YXRlZC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBK b2VsIE0uIEhhbHBlcm4gWzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUg UE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyA8YSBocmVmPSJtYWlsdG86 bWlrZWJpYW5jQGFvbC5jb20iPg0KbWlrZWJpYW5jQGFvbC5jb208L2E+Ozxicj4NCiZndDsmZ3Q7 SWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7U21pdGg7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4NCiZndDsmZ3Q7QmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg VGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlLiBBbmQgb25lIHRoYXQgSSB3b3VsZDxicj4N CiZndDsmZ3Q7cHJlZmVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDt3ZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthY3R1YWxseTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZGVjaWRl LCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVm ZmVjdCBvbiB0aGUgY29udHJvbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cmVxdWlyZW1lbnRzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25hbGl0eSBvZiBTRkZzLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZv ciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3RhbmNlczxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBuZWVkczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0 bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseSBldmVu PGJyPg0KJmd0OyZndDsgYWNyb3NzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgY2VudGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVu b3VnaDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Y29tcGxleDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2Vl bXMgbGlrZSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBh cmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBCdXQgaXQgaXMgYSBmYWly IHF1ZXN0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg VGhpcyBpcyB0aGUgY3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBlbmQ8YnI+DQomZ3Q7 Jmd0O3NlbGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAodG9wLWxldmVsKSBp bnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRyYWxseSAocGVyaGFwcyBieSB0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtjbGFzc2lmaWVyKTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGhvcC1i eS1ob3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7U0ZGcyk/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgU3VjaCBzZWxlY3Rpb24gaXMgbm90IGVxdWl2YWxlbnQgdG8gcmVj bGFzc2lmaWNhdGlvbi48YnI+DQomZ3Q7Jmd0O0FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0O3N1cmVseSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5k IG5vdCByZWxlZ2F0ZWQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtpbXBsZW1lbnRhdGlvbiZxdW90Oy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVu PGJyPg0KJmd0OyZndDsgdGhvdWdoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdyZWF0 ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzPGJyPg0KJmd0 OyZndDtsb2NhbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O3Nl bGVjdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVj aXNpb24gcG9pbnRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7VGhpczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoIGRv ZXMgbm90IHJlcXVpcmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0IGFsbC48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O015PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNoIGlz IHByaW1hcmlseSBkcml2ZW48YnI+DQomZ3Q7Jmd0O2J5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aW5jcmVhc2VkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVzaWxpZW5jeSBvdmVyIHRoZSBn bG9iYWwgcGF0aCBpZCBhcHByb2FjaC4gV2l0aCBhPGJyPg0KJmd0OyZndDtnbG9iYWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7aWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHByb2FjaCwgY29uc2lkZXIgZmFpbHVyZSBv ZiBhbiBpbnN0YW5jZSBhbmQgbmVlZGluZyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWx0ZXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBnbG9iYWwgcGF0aCBJ RCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0ZWQ8YnI+DQomZ3Q7Jmd0O2VuZC10by1l bmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwYXRoLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUm9u PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206 IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgSGFscGVybiBEaXJlY3Q8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBb PGEgaHJlZj0ibWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpv ZWxoYWxwZXJuLmNvbTwvYT5dIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLDxicj4NCiZndDsmZ3Q7 MjAxNDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IDY6MTU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgUE08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29t Ij5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+ DQpJLlNtaXRoQEY1LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0Ojxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IFJlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoZSBhcmNoaXRlY3R1cmUgbW9kZWxzIHRoZSBjYXNlIG9mIFNG MSBuZWVkaW5nPGJyPg0KJmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2luZmx1ZW5jZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBk byByZWNsYXNzaWZpY2F0aW9uIGF0IHRoZTxicj4NCiZndDsmZ3Q7ZXhpdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ZnJvbTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNGMS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8g a2VlcCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bG9naWNh bGx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3JpYmUg aG93IHRoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjaG9vc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbXBvc2UgdGhlbSBmb3IgJnF1b3Q7c2VydmljZSZx dW90OyBkZWxpdmVyeS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiA3LzEwLzE0 LCA2OjEwIFBNLCA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20iPm1pa2ViaWFuY0Bh b2wuY29tPC9hPiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFy Y2ggZHJhZnQgdGhhdCBzdWdnZXN0cyBhbnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NvcnQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaW1pdC4gSG93ZXZl ciwgaXQgZG9lcyBzZWVtIHRvIGluZGljYXRlIHRoYXQgdGhlIGVudGlyZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7cGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhhbGw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgU0ZJcykgbXVzdCBiZSBjaG9zZW4gYXQgU0ZDIGluc3RhbnRpYXRpb24uIEkgYmVsaWV2 ZTxicj4NCiZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O21l YW5zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGVpdGhlciBhdCB0aGUgY2xhc3NpZmllciBvciBtYXliZSB0aGUgY2xhc3Np Zmllcjxicj4NCiZndDsmZ3Q7Y2hvb3NlcyBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O0NoYWluPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkgY2FzZSw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJv aGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU0ZJ KG4pPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldGVy bWluZWQgYXQgdGhlIFNGSShuLTEpIGhvcC4gQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJl ZCAmcXVvdDticmFuY2hpbmcmcXVvdDsgdG8gYSBuZXcgU0ZQIGFzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IG9wcG9zZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hvb3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0 byB0aGUgc2VsZWN0ZWQgaW5zdGFuY2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBuZXh0LWhvcCBvZiB0aGUgY3VycmVudCBTRkMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0 LW1lcmdlZC1zZmMtYXJjaGl0ZWN0dXJlLTAwOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2hlbiBhbiBTRkMgaXMg aW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O25lY2Vzc2FyeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVz ZWQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDthbmQgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNyZWF0ZSB0aGUg c2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Ynczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bmV0d29yazxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbG9jYXRvci4gVGh1cywgaW5zdGFudGlhdGlvbiBv ZiB0aGUgU0ZDIHJlc3VsdHMgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Y3JlYXRpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlAp IGFuZCBpcyB1c2VkIGZvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Zm9yd2FyZGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcGFja2V0cyB0aHJvdWdoIHRoZSBTRkMuIEluIG90aGVyIHdvcmRzLCBhbiBTRlAgaXMg dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgU0ZDIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyByZWNsYXNz aWZpY2F0aW9uIChvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bm9uLWluaXRpYWw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNsYXNzaWZpY2F0aW9uKSBhcyB3ZWxsLiBBcyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCw8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZv cm1lZCBieSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVu dCB3aXRoIGEgc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZnVuY3Rpb24uPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5l dzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U0ZQLCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdXBkYXRlIG9mIHRo ZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiBUaGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtyZWZlcnJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhcyAmcXVvdDticmFuY2hpbmcmcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAqRnJvbTogPGEgaHJl Zj0ibWFpbHRvOipJLlNtaXRoQEY1LmNvbSI+KkkuU21pdGhARjUuY29tPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86SS5TbWl0aEBGNS5jb20iPkkuU21pdGhARjUuY29tPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg KlRvOiAqSm9lbCBIYWxwZXJuPGJyPg0KJmd0OyZndDsgRGlyZWN0Jmx0OzxhIGhyZWY9Im1haWx0 bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb208 L2E+Jmd0OyxKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7SGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpodWFuZ0Bz Y2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOmh1YW5nQHNjZS4lMGIiPmh1YW5nQHNjZS48YnI+DQo8L2E+Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGNhcmxldG9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2NhJmd0Oyw8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAqU2VudDogKlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTdWJqZWN0OiAq UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O0JhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY3R1YWxseSwgSSB0aGluayBJIGFt IGRpc2FncmVlaW5nLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgcG9zc2liaWxpdHkgb2YgbWVk aXVtLXNjYWxlIGRlcGxveW1lbnRzIChhbmQ8YnI+DQomZ3Q7Jmd0O3RoYXQgaXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2IG1pbGxpb24gZmxvd3Mg aXMgaW4gbXkgd29ybGQpIG9mIHNlcnZpY2UgY2hhaW5zIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7cHJlY29uY2VpdmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIGFuIGFic3VyZCBpZGVhLCB0 aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aDxicj4NCiZndDsmZ3Q7IHRoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcHJlY29uY2VwdGlvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgaGFzIHRvIGJlIHNv bWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YXNw aXJhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNjYWxlIHRoYXQgaXMg YXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2FyY2hpdGVjdHVyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Oy08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgeW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQg YW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthcmJpdHJhcnk8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg bnVtYmVyIGlzICZxdW90O3RvbyBmYXImcXVvdDssIHlvdSdyZSBjcmVhdGluZyAtIGV2ZW4gaWYg aXQgaXNuJ3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbnRl bnRpb25hbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0 IGhhdmUgbGFzdGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW1wYWN0czxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdh cmRpbmcgc2NhbGUtb3V0LCBmYWlsdXJlIG1pdGlnYXRpb24sIGVsYXN0aWNpdHksPGJyPg0KJmd0 OyZndDsgJmd0OyZndDthZGRyZXNzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwYWNlLi4uIGFsbCBraW5kcyBvZiB0aGlu Z3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFydGljdWxhcmx5IGVhZ2Vy IHRvIGRlYWwgd2l0aC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBGcm9tOiBKb2VsIEhhbHBlcm4gRGlyZWN0IFs8YSBocmVmPSJtYWlsdG86 am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9h Pl08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NlbnQ6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXJzZGF5LCBKdWx5IDEw LCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IEhhbHBlcm47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpodWFuZ0BzY2UuY2FybGV0b24u Y2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1YmplY3Q6IFJlOiBbc2ZjXTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7U2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1l IGF0IGFsbCBpbiB0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZWdhcmQuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7STxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0O2FtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCByZXF1ZXN0aW5nIHRoZSB0aGUgYXJjaGl0ZWN0 dXJlIG9yIHRoZSBzb2x1dGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7cHJvaGliaXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRv PGJyPg0KJmd0OyZndDsgJmd0OyZndDtIdWFuZydzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWRpbmcgb2YgbXkgbm90 ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRzIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IHJlcXVpcmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgQXMgSSBoYXZlIHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHBy b2hpYml0PGJyPg0KJmd0OyZndDtzdWNoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5ncy4gV2hldGhlciB0aGV5IGFy ZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg bWFueTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBXRy4gSSBo YXBwZW4gdG88YnI+DQomZ3Q7Jmd0O3RoaW5rPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7dGhleTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh cmUgdXN1YWxseSBhIGJhZCBpZGVhLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgdGhlIGFyY2h0aWVj dHVyZSBzaSBjYXJlZnVsbHkgYXZvaWRpbmcgYXR0ZW1wdGluZyB0bzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7a25vdzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaXMgYW5kIGlzIG5vdCBlcGxveWFibGUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2Vs PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZTo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEkgZGlzYWdyZWUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2Ugcm91 dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7bWlsbGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50 ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZW52aXJvbm1lbnRzIHRvZGF5LiBZb3UgY2FuJ3Qgc2VyaW91c2x5IGJlbGll dmUgdGhhdCBpbjxicj4NCiZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENsb3VkL0lQdjYvTW9iaWxpdHkv V2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3U8YnI+DQomZ3Q7Jmd0OyBhcmU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7IGdvaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGhhdmUgc21hbGwgbnVtYmVycyBvZiBzZXJ2aWNl IGNoYWlucyB3aXRoIGVxdWFsbHk8YnI+DQomZ3Q7Jmd0O3NtYWxsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7IG51bWJlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYWN0aXZlIHNlcnZpY2UgcGF0 aHM/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAm cXVvdDtubyBvbmUgd2lsbCBldmVyIG5lZWQgbW9yZTxicj4NCiZndDsmZ3Q7IHRoYW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgNjRLJnF1b3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3I8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY29tZm9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPnNmYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbPGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+ XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgNDo0NiBQTSBUbzo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86aHVhbmdA c2NlLmNhcmxldG9uLmNhIj5odWFuZ0BzY2UuY2FybGV0b24uY2E8L2E+Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiBTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLDxicj4NCiZndDsmZ3Q7YW5kPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7TG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTm8sIGl0IHdpbGwgbWVhbiB0aGF0IGlmIHNvbWVvbmUg dHJpZXMgdG8gZGVwbG95IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2Fy Y2h0aWV0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNl ZWQgdGhlIGxpbWl0cyBvZjxicj4NCiZndDsmZ3Q7dGhlaXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRldmljZXMu IFRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcmVxdWlyZSBzdWNoIGFic3VyZDxicj4NCiZndDsm Z3Q7IHVzZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlIHBh dGhzLiBTaW5jZSBJIGNhbiBub3QgZmlndXJlIG91dCBob3cgdG8gd3JpdGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFyY2hpdGVjdHVyYWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmU8YnI+ DQomZ3Q7Jmd0O2RvZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwZXJtaXQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHN1Y2ggYWJ1c2UuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGxlYXNl IGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0IHRoZSBhcmNodGllY3R1cmU8YnI+DQomZ3Q7Jmd0 OyBwZXJtaXRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb21ldGhpbmcgYXMgc2F5aW5nIGl0IGlzIGVpdGhlciBk ZWlzcmVkIG9yIHJlcXVpcmVkIGJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt3b3JrLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXNuJ3QuPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiA3LzEwLzE0LCA0OjM2IFBNLCBDaGFuZ2NoZW5nIEh1YW5nIHdyb3RlOjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3 aWxsPGJyPg0KJmd0OyZndDttZWFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYsMDAwLDAwMCBwYXRocy4g VGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZzxicj4NCiZndDsmZ3Q7dGFibGU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O29mIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb3JlIHJvdXRlci48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2Yg ZGVwbG95bWVudHMsIGZyb208YnI+DQomZ3Q7Jmd0OzE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vy dmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGU8YnI+DQomZ3Q7 Jmd0O3RoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0b3JzIGFyZSBwcmVwYXJlZCBmb3Ig dGhlIGNvbXBsZXhpdGllcyBpZiB0aGV5PGJyPg0KJmd0OyZndDsgJmd0OyZndDtjaG9vc2U8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh dm9pZCBhbnkgdXNlIG9mIGxvY2FsIGxvYWQgYmFsYW5jaW5nIGFuZCBpbiBzdGVhZDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNjAsMDAwIHNl cnZpY2UgcGF0aHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlv dXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcv MTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFBhdWwsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVyZSB3aWxsIGJlIGZvciBhIDQg aG9wPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFyaWE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5d ICpPbiBCZWhhbGY8YnI+DQomZ3Q7Jmd0OyBPZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlBh dWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDszOjAzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQTSAqVG86KiBMdWN5 IHlvbmcgKkNjOiogPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPg0Kam1oQGpv ZWxoYWxwZXJuLmNvbTwvYT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wu Y29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZTxi cj4NCiZndDsmZ3Q7IENoYWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBMdWN5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE92ZXJhbGwgSSBjb25jdXIsIGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nLiBJPHNwYW4gbGFuZz0iWkgtQ04i PsK5PC9zcGFuPmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFrZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIG1p bm9yIGNoYW5nZTogdGhlIHBhdGggaWRlbnRpZmllciBjYW4gYmUgdXNlZCB0bzxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IGRlcml2ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIG5lZWRlZCBm b3J3YXJkaW5nIGFuZCBhc3NvY2lhdGVkIHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBi dXQgcmF0aGVyIGlzIHVzZWQgdG88YnI+DQomZ3Q7Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaWRlbnRpZnkgdGhlIHNlcnZpY2UgcGF0aCAob3IgZ3JhcGgpIHRoYXQgcGFja2V0 czxicj4NCiZndDsmZ3Q7bXVzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhdmVyc2UuIEJ5 IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb248YnI+ DQomZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRocmVhZCBjYW4gYmUgc2lt cGx5IGJlIGltcGxlbWVudGVkLiBUaGUgcGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGlkZW50 aWZpZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0aGFu IGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyByZXN1bHQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdo dGVkKSB0cmFuc3BvcnQgbmV4dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaG9wKHMpLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdWw8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMTAsIDIw MTQsIGF0IDExOjA0IEFNLCBMdWN5IHlvbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWkuY29t PC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25n QGh1YXdlaS5jb20lM2UiPm1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDs8L2E+Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90IG1hbmRhdGUg b25seSB1c2Ugb2Y8YnI+DQomZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNl cnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nPGJyPg0KJmd0OyZn dDsgJmd0OyZndDthY3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEx1Y3k8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAqRnJvbToqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddKk9uIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uPC9hPiBCZWhhbGY8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPZiptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5PZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpTZW50OipUaHVyc2RheSw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSnVseTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgMTAsIDIwMTQgMjowNiBBTSAqVG86PGEgaHJlZj0ibWFpbHRvOiptaWtlYmlhbmNA YW9sLmNvbSI+Km1pa2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzZTtqbWhAam9lbGhhbHBlcm4u Y29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb20mZ3Q7O2ptaEBqb2VsaGFscGVybi5jb208L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lM2U7c2ZjQGlldGYub3JnIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7 c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0OyAqU3ViamVjdDoq UmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0NoYWlucyw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZS0sPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBv dXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaWRl bnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bzxicj4NCiZndDsmZ3Q7 ZGVyaXZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb3J3YXJkaW5nIGFjdGlvbnMuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVxdWlyaW5nIGEg U0ZDIHN5c3RlbSB0byBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvZjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7IGV2ZXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF2YWlsYWJsZSBTRkM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZvcndhcmRpbmcgcGF0aHMgd2l0aGluIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBpcyBub3Q8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcmVxdWlyZWQvanVzdGlmaWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3Ig cG9zc2libGUgaW4gdmFyaW91cyBkZXBsb3ltZW50IGNvbnRleHRzLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMg c2hvdWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZv cm1hdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IHdpbGw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHBy ZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmU8YnI+DQomZ3Q7Jmd0OyBy ZXF1aXJlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dXNlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mZXIg Zm9yd2FyZGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhY3Rpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBh IHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1lZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpEZSA6KnNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpEZSI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZTwvYT4gbGEg cGFydDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20iPmRlKm1p a2ViaWFuY0Bhb2wuY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZn dDsgKkVudm95PHNwYW4gbGFuZz0iWkgtQ04iPsOpPC9zcGFuPiA6Km1lcmNyZWRpIDk8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBqdWlsbGV0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyMDE0IDIy OjAzICrDgCA6PGEgaHJlZj0ibWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tIj4qam1oQGpvZWxo YWxwZXJuLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmciPm1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJmd0OztzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4m Z3Q7ICpPYmpldCA6KlJlOiBbc2ZjXSBTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtDaGFp bnMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXMgYW55b25l IHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW48YnI+DQomZ3Q7Jmd0O1NG PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgQ2hhaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCBTRjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBQYXRoPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXIgdGhhbiBj bGFyaWZ5aW5nIHRoZSBkZWZpbml0aW9uIHNvIHRoYXQgaXQnczxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7Y2xlYXIgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhvc2Ugbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBm YW1pbGlhciB3aXRoIHRoZSBkcmFmdCwgaXQgc2VlbXMgdGhhdCBldmVyeW9uZTxicj4NCiZndDsm Z3Q7YWdyZWVzPGJyPg0KJmd0OyZndDsgJmd0OyZndDtvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlc2UgdGVybXMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzPGJy Pg0KJmd0OyZndDt3aGV0aGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpdCBpczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhlIGludGVudCBvZiB0aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3Bl Y2lmeSB3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGUgSUQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG9mIHRoZSBTRkMgSGVhZGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNob3VsZDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcmVmZXJlbmNlICh0aGUgY2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzIGRy YWZ0PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaW1wbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGludGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyPGJyPg0KJmd0 OyZndDtkcmFmdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZvciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWlu PGJyPg0KJmd0OyZndDsgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhdGggYW5kIHRoZSBj aG9pY2Ugb2YgY2hhaW4gb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1wbGFuZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgbGF0dGVyIChhbWJpZ3VvdXMp LCB0aGVuIHRoZSBkcmFmdCB3b3VsZCBoYXZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1 aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQgKG9yIG1ha2U8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBvbmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVpcmVkIGFuZCB0 aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWU8YnI+DQomZ3Q7Jmd0OyB2ZW5kb3JzPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgb25seTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VwcG9y dGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7LS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICpGcm9tOjxhIGhyZWY9Im1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbSI+KmptaEBqb2VsaGFs cGVybi5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhA am9lbGhhbHBlcm4uY29tJTNlIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2Vs aGFscGVybi5jb20mZ3Q7PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpUbzo8YSBo cmVmPSJtYWlsdG86KnNmY0BpZXRmLm9yZyI+KnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmclM2Ui Pm1haWx0bzpzZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmcmZ3Q7PC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyAqU2VudDoqVHVlc2RheSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdWx5PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZDxicj4NCiZndDsmZ3Q7TG9hZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFs YW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGNsZWFybHk8YnI+DQomZ3Q7 Jmd0O2Fuc3dlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbnVtYmVyIG9mIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYWJvdXQgdGhlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHByb3Bvc2VkPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0PGJy Pg0KJmd0OyZndDsgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgYWdyZWVt ZW50IG9uIHRoZSBpbnRlbnQsIHdlIHdpbGwgd29yayB0bzxicj4NCiZndDsmZ3Q7IGltcHJvdmU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdvcmRp bmcgc28gdGhhdCByZWFkZXJzIHdobyBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IFdHPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHdvcmtpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIGludGVuZHMuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IHdoYXQgZG8g d2UgaW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3BlcnNvbmFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2aWV3LCBhbmQgc2VlIGlmIHRoYXQg aGVscHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFudCB0byBrZWVwIGluIG1pbmQgdGhhdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7d2hhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2UgYXJlIGRl ZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2U8YnI+DQomZ3Q7Jmd0O2Fy ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXR0 ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc29sdXRpb24gZm9yIHNlcnZpY2UgY2hhaW5pbmcuIFRoYXQgd291 bGQgZW5jb21wYXNzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPU1MvQlNTLCB2YXJpb3VzIGNv bnRyb2wgYW5kIHBvbGljeSBmdW5jdGlvbnMsPGJyPg0KJmd0OyZndDt2aXJ0dWFsPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBtYWNoaW5lIGFuZCBpbWFnZSBtYW5hZ2VtZW50LCBhbmQgbWFueSBv dGhlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGFzcGVjdHMuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQXMgYSByZXN1bHQgdGhlcmUgYXJlIG1hbnkg dGhpbmdzIHdoaWNoIGNsZWFybHkgbmVlZDxicj4NCiZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFs dCB3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDthYm92ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgd2hlcmUgd2UgYXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9uaW5nLDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW5kIGFyZSBub3QgZGlyZWN0bHkgcmVxdWlyZWQgYnkgdGhlIHdvcmsgd2UgYXJlPGJy Pg0KJmd0OyZndDsgZG9pbmcuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBw YXRoLDxicj4NCiZndDsmZ3Q7YXMgSTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdW5kZXJzdGFu ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB0aGVtLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBuZWVkIHRvIGZpcnN0 IGRpc2N1c3MgbG9hZCBiYWxhbmNpbmcuIFRoZXJlIGFyZSBhdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7bGVhc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRocmVlIGRpZmZlcmVudCB3YXlzIHRo YXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZDxicj4NCiZndDsmZ3Q7d2lsbDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJs eSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21vcmUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgcG9pbnQgb2YgdGhlIGFyY2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsIG9mPGJyPg0K Jmd0OyZndDsgJmd0OyZndDt0aGVzZSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ1dCBub3Qg dG8gbWFuZGF0ZSB0aGF0IGFueSBwYXJ0aWN1bGFyIGtpbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUgdXNlZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYW55IHNvbHV0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEpIExvYWQgYmFsYW5jaW5nIGFzIGEgc2Vy dmljZSBwcm92aWRlZCB0byB0aGUgZW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDt1c2VyLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBhIHNlcnZpY2UgZnVuY3Rpb24uIEl0IHJlY2Vp dmVzIHVzZXI8YnI+DQomZ3Q7Jmd0O3BhY2tldHMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDthbmQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vZGlmaWVzIHRoZW0gKG9yPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hcmtz PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBh biBlbmQgdXNlciBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbnN0YW5jZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFu IGltcG9ydGFudDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5p bmcuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtJdCdzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi ZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IGNoYWluaW5nIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb25lLiBC dXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2FyY2h0aWVjdHVyZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb20gYW4gYXJjaGl0ZWN0 dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWlu ZyBwYWNrZXQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsIG9uZTxicj4N CiZndDsmZ3Q7Y2FuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtoYXZlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcGVhcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRv IHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZTxicj4NCiZndDsm Z3Q7cG9pbnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBjb250YWN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvciBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVjaWZp YyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtieSBhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbGxlY3Rpb24gb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZzxi cj4NCiZndDsmZ3Q7b25lIG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXZlcmFsIGxvYWQg YmFsYW5jZXJzIChmb3IgZXhhbXBsZSB1c2luZyBWUlJQLWxpa2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBp czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW52aXNpYmxlIHRvIHRoZSBzZXJ2aWNlIGNoYWlu aW5nIGRhdGEgcGxhbmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21lY2hhbmlzbXMuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgSXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxpa2VseSB0aGF0 IGl0IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sPGJyPg0KJmd0OyZndDsgJmd0OyZndDtt ZWNoYW5pc21zLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBhcyB0aG9zZSByZXNwb25z aWJsZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwgPGJyPg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O3ZtPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnN0YW50aWF0aW9uLiBU aGUgYXJjaGl0ZWN0dXJhbCBpbXBhY3Qgb2YgPGJyPg0KJmd0OyZndDtwZXJtaXR0aW5nPGJyPg0K Jmd0OyZndDsgJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBsYXJnZWx5 IHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgb3VyPGJyPg0KJmd0OyZndDsgJmd0OyZn dDt0ZXJtaW5vbG9neTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9lcyBub3QgbGVhZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyByZWFkZXJzIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGluayB3ZSBhcmUgcHJv aGliaXRpbmcgaXQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNpbmcgZG9uZSBieSA8YnI+DQom Z3Q7Jmd0O3NlbGVjdGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFja2V0IHBhdGhzIGZv ciB0aGUgc2VydmljZSBjaGFpbmluZyB0aGF0IGRpcmVjdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 dHJhZmZpYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ug d291bGQgbm90IHdhbnQgdG8gcmVxdWlyZTxicj4NCiZndDsmZ3Q7IHRoYXQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdpdmVuIHNlcnZpY2UgZnVuY3Rp b24gYXBwZWFyIGF0IG9ubHkgb25lIHBsYWNlIGluIDxicj4NCiZndDsmZ3Q7dGhlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1h eSBiZSA8YnI+DQomZ3Q7Jmd0O2NvbWJpbmVkLiBJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGVu ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVmZXIgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRv IHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2NoYWluaW5nPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhcyBhIHNpbmdsZSBwb2ludCBhcyBhIGNsdXN0ZXIuIE5vdCBiZWNhdXNlIGNsdXN0 ZXIgPGJyPg0KJmd0OyZndDtpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJIGRvIG5vdCBoYXZlIGFub3RoZXIg b25lLjxicj4NCiZndDsmZ3Q7IFRodXMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGhlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaXMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0 cyBvZiB0cmFmZmljIHRvIGRpZmZlcmVudDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c2luZ3VsYXI8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBp biBkaWZmZXJlbnQgcGxhY2VzIDxicj4NCiZndDsmZ3Q7aW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQg ZG8gSSBtZWFuIHdoZW4gSSB0YWxrIGFib3V0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2 aWNlIGNoYWluIGFuZCBzZXJ2aWNlIHBhdGgvIFNlcnZpY2UgY2hhaW4gaXMgYTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IHNlcXVlbmNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBsb2dpY2Fs IGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0IG9mPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtwYWNrZXRzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgZXF1aXZhbGVudCBv ZiBzYXlpbmcgdGhhdCBzb21lIHN1YnNldCBvZiA8YnI+DQomZ3Q7Jmd0O3RyYWZmaWM8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBnZXQgRFBJLCBj aGFyZ2luZywgY29udGVudCBpbnNwZWN0aW9uLCBhbmQgPGJyPg0KJmd0OyZndDtmaXJld2FsbDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdv IGRpcmVjdGx5IHRvIHRoZSA8YnI+DQomZ3Q7Jmd0O2NhY2hlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdpdGhvdXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpc2l0aW5nIGFueSBvdGhlciBzZXJ2aWNlIGZ1bmN0aW9u cy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGF0 IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZSA8YnI+DQomZ3Q7Jmd0O3Bh Y2tldHMuPGJyPg0KJmd0OyZndDsgQTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VydmljZSBw YXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O2xvY2F0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gdGhlIG5ldHdvcmsuIFRo b3NlIGxvY2F0aW9ucyB3aWxsIGJlIHNpbmd1bGFyIG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O21heSBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWRkcmVz c2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBhczxicj4NCiZndDsmZ3Q7 IHBvcnRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhhdCB0aGU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2xvY2F0aW9uczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWF5IGJlIGtu b3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlPGJyPg0KJmd0OyZndDsg YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 cmFuc3BvcnQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyA8YnI+ DQomZ3Q7Jmd0O2dyb3VwLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHdlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgbmVlZCB0byBiZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWJsZSB0 byB0YWxrIGFib3V0IHRoZSBoaWdoIGxldmVsIGFic3RyYWN0aW9uLCB0aGU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNoYWluLCB3aGljaCBk cml2ZXMgdGhlIGZvcndhcmRpbmcuIEFuZCB3ZSBuZWVkIHRvPGJyPg0KJmd0OyZndDsgdGFsazxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0 cyB3aWxsIHRha2UgaW4gdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNldmVyYWwgb2Yg dGhlIGNvbW1lbnRzIGhhdmUgc2FpZCAmcXVvdDtidXQgdGhlIHdob2xlPGJyPg0KJmd0OyZndDsg cGF0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1heTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bm90IGJlIGtub3duIGF0IHRoZSBmcm9udC4mcXVvdDsgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3dpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQg aXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBpdGVtICgyKSA8YnI+DQomZ3Q7 Jmd0O29uPGJyPg0KJmd0OyZndDsgJmd0OyZndDtsb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kIDxicj4NCiZndDsm Z3Q7YmVoYXZpb3JzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2hpY2g8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgbWVjaGFuaXNt cyAoaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O211Y2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJnZWx5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2libGUgdG8gcm91dGluZyBiZXR3ZWVuIExBTnMuKSBU aGUgb3RoZXI8YnI+DQomZ3Q7Jmd0OyBwcm92aXNpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3 ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWFrZSBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFp biB3aGVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbmVjZXNzYXJ5Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRvIGEgbmV3IGNoYWluLiBCYXNlZCBv bjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSBy ZS1jbGFzc2lmaWNhdGlvbiA8YnI+DQomZ3Q7Jmd0O3BvaW50Ljxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhw bGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gPGJyPg0KJmd0OyZndDtJZiBpdDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZG9lcywgYW5kIGlmIHRoZSBpbnRlbnQgaXMgYWNjZXB0YWJsZSB0byB0aGUg d29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGdyb3VwLDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQ8 YnI+DQomZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29udmV5IHRoaXMuIElm IHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgaW50ZW50LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlbiB3ZSB3aWxsIG9mIGNvdXJz ZSBhZGp1c3QgdG8gbWF0Y2ggdGhlIHdvcmtpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2dyb3Vw PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxsIHVu Y2xlYXIsIEkgYW0gbm90IHN1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3doYXQgdG88YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyeSBuZXh0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLCBKb2VsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHNm Yzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1haWx0 bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZmM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5z ZmNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86 c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgc2ZjPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYzxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBzZmM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGxpc3Q8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h Pjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7c2ZjIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CFE95ABE4BE2Bsmkumarciscocom_-- From nobody Mon Jul 14 11:26:03 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58881A0016 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFXvnJYFAhER for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:25:54 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F8D1A0008 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:25:53 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 2b024c35.2ba313a38940.762979.00-2422.2107408.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:25:54 +0000 (UTC) X-MXL-Hash: 53c420b22ba4ba76-9213c0af4db4229a9dd8cfcd8d0cbde52bbb478c Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id aa024c35.0.762847.00-2053.2107054.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:25:48 +0000 (UTC) X-MXL-Hash: 53c420ac0c386c75-6c2118b8a56c4cf816d5d08ad5f074873a633627 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EIPj6r020574; Mon, 14 Jul 2014 14:25:46 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EIPb9f020445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 14:25:43 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 18:25:31 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:25:31 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAARkg Date: Mon, 14 Jul 2014 18:25:30 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA4C@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA4CMISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kf9lR3kD c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=_Ym7mv4qLp] X-AnalysisOut: [Ul1cJoXiYA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oU6_8gj] X-AnalysisOut: [E2l81_HST:21 a=cofe1QdHmSkL6baX:21 a=yMhMjlubAAAA:8 a=SSmO] X-AnalysisOut: [FEACAAAA:8 a=ZgcmM0qAbuIeKXVM6ywA:9 a=gKO2Hq4RSVkA:10 a=Ui] X-AnalysisOut: [CQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=sD3PwQ] X-AnalysisOut: [2W4ym9WCIO:21 a=9x1r6kOYstwiamIZ:21 a=HxdBNg8aI_SpPN-r:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9kTo8e8vkKp4Ww589_ssv89nrGM Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:26:00 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA4CMISOUT7MSGUSRCF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds very good. Maria From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:22 PM To: Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts There is one missing word in my text. Please replace my proposed text wit= h: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the instance select= ion of one or more of the service functions in the SFC. Any SFC may have = any number of C-SFC's associated with it." Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.or= g> Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA4CMISOUT7MSGUSRCF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Sounds very good.<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Maria<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:22 PM<br> <b>To:</b> Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org= <br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">There is one missing word= in my text.   Please replace my proposed text with:<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the instance sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s assoc= iated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ie= tf.org"> sfc@ietf.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </div> </body> </html> --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BA4CMISOUT7MSGUSRCF_-- From nobody Mon Jul 14 11:29:37 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F41A0025 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:29:34 -0700 (PDT) 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 30bRabQ0Fwqs for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:29:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E701A001B for <sfc@ietf.org>; Mon, 14 Jul 2014 11:29:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 34F0D24731A; Mon, 14 Jul 2014 11:29:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 131032472F1; Mon, 14 Jul 2014 11:29:24 -0700 (PDT) Message-ID: <53C42183.8040605@joelhalpern.com> Date: Mon, 14 Jul 2014 14:29:23 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/L16ojdSzDKa10NnP1HSy0JmRfr4 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:29:34 -0000 Maria, while the constraint (either C-SFC or SFP, whichever term the SG likes) may be selecting specific instances, it may be more general. The simplest example is that for a given service chain, one might have one SFP (or C-SFC) that causes the entire chain to be delivered at data-center-1 and a second SFP (or C-SFC) that causes the entire service chain to be delivered at data-center-2. Each data center has many instances running. And may even have multiple clusters in different PODs within the DC. Yes, the constraint may say use exactly this specific isntances, but it does not have to. Yours, Joel On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote: > Ron, > > this is pretty good. > > I would propose to re-phrase the second sentence to: “The > Constrained-SFC (C-SFC) further allows for policy constraints to be > added to the SFC affecting the selection of one or more **specific** > service function **instances** in the SFC”. > > Maria > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > *Sent:* Monday, July 14, 2014 2:16 PM > *To:* David Allan I; Jim Guichard (jguichar); sfc@ietf.org > *Subject:* Re: [sfc] SFC Terminology / Concepts > > I have a counter-proposal that eliminates the term “SFP” entirely: > > “The Service Function Chain (SFC) provides a fully abstract view of the > service functions to be invoked and the order in which they are to be > invoked for some particular flow or set of flows, without concern of > actual service function instance selection. The Constrained-SFC > (C-SFC) further allows for policy constraints to be added to the SFC > affecting the selection of one or more of the service functions in the > SFC. Any SFC may have any number of C-SFC’s associated with it.” > > Thanks. > > Ron > > "The SFP provides a level of indirection between the fully abstract > notion of service path as a sequence of functions to be delivered, and > the fully specified notion of exactly what instances of SFFs the packet > will visit when it actually traverses the network. By allowing the > control components to specify the use of this level of indirection, the > deployment may choose the degree of SFF instance selection authority > that is delegated to the network.” > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > *Sent:* Monday, July 14, 2014 2:03 PM > *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* Re: [sfc] SFC Terminology / Concepts > > I like that text, it strikes a good balance where an implementation has > the option of making scale and resiliency a local matter…. > > D > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, July 14, 2014 10:48 AM > *To:* sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* [sfc] SFC Terminology / Concepts > > Dear WG: > > There has been much debate over the last few days with regards to SFC > concepts. To try and form some consensus around terminology and concepts > used to describe the architecture in the merged architecture draft, Joel > has kindly suggested the following: > > "The SFP provides a level of indirection between the fully abstract > notion of service path as a sequence of functions to be delivered, and > the fully specified notion of exactly what instances of SFFs the packet > will visit when it actually traverses the network. By allowing the > control components to specify the use of this level of indirection, the > deployment may choose the degree of SFF instance selection authority > that is delegated to the network.” > > I’d like to ask the WG as a whole, if this clarification is something > that we can get consensus on. If so, I’ll ask Joel to provide specific > text, that reflects the above, for inclusion in the merged architecture > draft. > > Thank You, > > Jim > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 14 11:36:30 2014 Return-Path: <david.i.allan@ericsson.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE481A0035 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:36:27 -0700 (PDT) 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 KCmCS5dshqfp for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:36:23 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188CA1A002B for <sfc@ietf.org>; Mon, 14 Jul 2014 11:36:23 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-47-53c3d0a2f9d3 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.04.05330.2A0D3C35; Mon, 14 Jul 2014 14:44:18 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:36:21 -0400 From: David Allan I <david.i.allan@ericsson.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAAmRQ Date: Mon, 14 Jul 2014 18:36:21 +0000 Message-ID: <E6C17D2345AC7A45B7D054D407AA205C392A2F96@eusaamb105.ericsson.se> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C392A2F96eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPrO6iC4eDDW5NV7JYOk/d4sLTqcwW Tx5sZXdg9nhx5Rmzx5TfG1k9liz5yRTAHMVlk5Kak1mWWqRvl8CVsfjMBeaCl/MYKxae3cne wDiph7GLkZNDQsBEonPzZGYIW0ziwr31bF2MXBxCAkcZJVqmdDNCOMsZJe5t7WACqWITMJDY 8/8LWEJEoJFR4sal0ywgCWEBdYnG5T3sILaIgIbEi3+vgBo4gGw3iSVz7UDCLAKqEl83dYFt 5hXwlejsPcUKsWAqk8Tybb3sIPWcAtES33vDQGoYgS76fmoN2F5mAXGJW0/mM0FcKiCxZM95 qKtFJV4+/scKYStJzHl9jRmiPl/i9YFGFohdghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2J DcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAqPqmASb7g7GPS8tDzEKcDAq8fAq rDocLMSaWFZcmXuIUZqDRUmcd1btvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDoi7eHJ PimvX8Q5rHM+8FnDbl/UrUrLysYPt6VXsErv/FMuwznp0Vo2vXt7uyRP1RWasajtfczX/bW3 6O79wAP16iJPpd6q1SSkdNl5iRbvmzrTqiSEcW247opjvMWC0tWC14O4euKFip6a2fnvVy/O 2L3CSjJ1kszDie4q6fOtF7CJcb5SYinOSDTUYi4qTgQAwQUeZIsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LFrEJ38FKTi-4qXp08B5_sN295Q Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:36:27 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F96eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not that comfortable with this definition.... I like the flexibility that an SF can participate in more than one SC. Henc= e it makes sense to separate the concept of path and chain. And a C-SFC is simply an SFP IMO. I cannot envision how it would be express= ed differently. A scaled out SF simply being the analogy of a "loose hop" i= n the path, but with the "loose hop" having an identity. Make sense? Dave From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, July 14, 2014 11:22 AM To: Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org Subject: RE: SFC Terminology / Concepts There is one missing word in my text. Please replace my proposed text wit= h: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the instance select= ion of one or more of the service functions in the SFC. Any SFC may have = any number of C-SFC's associated with it." Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.or= g> Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F96eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I’m not that comfor= table with this definition….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like the flexibility th= at an SF can participate in more than one SC. Hence it makes sense to separ= ate the concept of path and chain. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">And a C-SFC is simply an = SFP IMO. I cannot envision how it would be expressed differently. A scaled = out SF simply being the analogy of a “loose hop” in the path, but with the “loose hop” having an identity. <o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Make sense?<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Dave<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Ron Park= er [mailto:Ron_Parker@affirmednetworks.com] <br> <b>Sent:</b> Monday, July 14, 2014 11:22 AM<br> <b>To:</b> Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org= <br> <b>Subject:</b> RE: SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">There is one missing word= in my text.   Please replace my proposed text with:<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the instance sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s assoc= iated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ie= tf.org"> sfc@ietf.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </body> </html> --_000_E6C17D2345AC7A45B7D054D407AA205C392A2F96eusaamb105erics_-- From nobody Mon Jul 14 11:37:21 2014 Return-Path: <tom.taylor.stds@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAC31A0049 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:37:20 -0700 (PDT) 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 7JdBzxnClF6r for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:37:18 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C336F1A0037 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:37:18 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id n16so4694240oag.15 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1oMBqLTHN66V0fiuziPiqN9YqXHf2h8aeaAQiqaIkiU=; b=Q9Iqm19GnVK/etRIPV/nzReYalm+IHYkbsIOpCh9VMyQQ+sRmetYrh/gE4xYdaQ5ix lv6DiRHrF219IJZLLe0KQFhT8Fv2Fu1qijZih6AvnQZPK5U+xDeeRj9DfEu6XrKNnCOT 6yB/+4Oaj+4q/dXG/YD+XJcCpngKJb45Mkkfkk98zHqYOhv+ziOLhsl8G0/pgj+yt2c5 lLkisJKmRb/Ik7iiXFM5LykHHb1wYYeN1AX7N1EWg4CWxxvkJiM3BVcMDfwuZ/PKf4XG mjMLdg+zmv9Ea+764g6/gH8WxKbMMYuAM25q3kEgs7tXMD3Pi8wpE5zOQkgUtsd1NBa9 B67A== X-Received: by 10.60.96.98 with SMTP id dr2mr20094009oeb.15.1405363038189; Mon, 14 Jul 2014 11:37:18 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id fu14sm275655oeb.9.2014.07.14.11.37.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 11:37:17 -0700 (PDT) Message-ID: <53C4235D.5010701@gmail.com> Date: Mon, 14 Jul 2014 14:37:17 -0400 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sfc@ietf.org, Ron Parker <Ron_Parker@affirmednetworks.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1-lC3mEwqNcoB6Vu3Oc2eCKNjmY Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:37:20 -0000 Your text scares me because it introduces some new concepts and assumptions. I'd rather go with Joel's formulation. Clarifying question on that: am I right in seeing the implication that when control assigns an SFP, the assignment is recorded by an identifier wwhich travels with the packet? Tom Taylor On 14/07/2014 2:22 PM, Ron Parker wrote: > There is one missing word in my text. Please replace my proposed text > with: > > “The Service Function Chain (SFC) provides a fully abstract view of the > service functions to be invoked and the order in which they are to be > invoked for some particular flow or set of flows, without concern of > actual service function instance selection. The Constrained-SFC > (C-SFC) further allows for policy constraints to be added to the SFC > affecting the instance selection of one or more of the service functions > in the SFC. Any SFC may have any number of C-SFC’s associated with it.” > > Thanks. > > Ron ... > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > *Sent:* Monday, July 14, 2014 2:03 PM > *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* Re: [sfc] SFC Terminology / Concepts > > I like that text, it strikes a good balance where an implementation has > the option of making scale and resiliency a local matter…. > > D > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, July 14, 2014 10:48 AM > *To:* sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* [sfc] SFC Terminology / Concepts > > Dear WG: > > There has been much debate over the last few days with regards to SFC > concepts. To try and form some consensus around terminology and concepts > used to describe the architecture in the merged architecture draft, Joel > has kindly suggested the following: > > "The SFP provides a level of indirection between the fully abstract > notion of service path as a sequence of functions to be delivered, and > the fully specified notion of exactly what instances of SFFs the packet > will visit when it actually traverses the network. By allowing the > control components to specify the use of this level of indirection, the > deployment may choose the degree of SFF instance selection authority > that is delegated to the network.” > > I’d like to ask the WG as a whole, if this clarification is something > that we can get consensus on. If so, I’ll ask Joel to provide specific > text, that reflects the above, for inclusion in the merged architecture > draft. > > Thank You, > > Jim > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jul 14 11:43:36 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3D11A004D for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOaoSOj5ElSE for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:43:26 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0A71A0045 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:43:25 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id dc424c35.2b990c646940.5951181.00-2436.16493707.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:43:25 +0000 (UTC) X-MXL-Hash: 53c424cd0aef80a9-8f9910871341fb0f51b87e4c5d724812ef9dd735 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 6c424c35.0.5951044.00-2335.16493340.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 18:43:19 +0000 (UTC) X-MXL-Hash: 53c424c71c43686c-cf681f6013c5c225e7ba1325eada9e7d7340acba Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EIhH4R014703; Mon, 14 Jul 2014 14:43:17 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EIh7SZ014545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 14:43:10 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 18:42:56 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 14:42:56 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAALLEIAARjeA///ATSA= Date: Mon, 14 Jul 2014 18:42:56 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA83@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C42183.8040605@joelhalpern.com> In-Reply-To: <53C42183.8040605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gqfbR3uhTkYA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ABeY7kuGAAAA:8 a=48vgC7mUAAAA:8 a=eV1QRH3CPTB4VFR] X-AnalysisOut: [elWkA:9 a=CjuIK1q_8ugA:10 a=chC_agHSu74A:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=p6qKL2q98h2rEmv2:21 a=UAV-4dcl5GKD3fYB:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dBO_qvf_DXMQiMGRP6oCiIeQNAo Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:43:30 -0000 Joel, for me, this is still about specific service instances to be chosen. Maria > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, July 14, 2014 2:29 PM > To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar= ); > sfc@ietf.org > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Maria, while the constraint (either C-SFC or SFP, whichever term the SG > likes) may be selecting specific instances, it may be more general. >=20 > The simplest example is that for a given service chain, one might have > one SFP (or C-SFC) that causes the entire chain to be delivered at > data-center-1 and a second SFP (or C-SFC) that causes the entire service > chain to be delivered at data-center-2. Each data center has many > instances running. And may even have multiple clusters in different > PODs within the DC. > Yes, the constraint may say use exactly this specific isntances, but it > does not have to. >=20 > Yours, > Joel >=20 > On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote: > > Ron, > > > > this is pretty good. > > > > I would propose to re-phrase the second sentence to: "The > > Constrained-SFC (C-SFC) further allows for policy constraints to be > > added to the SFC affecting the selection of one or more **specific** > > service function **instances** in the SFC". > > > > Maria > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > > *Sent:* Monday, July 14, 2014 2:16 PM > > *To:* David Allan I; Jim Guichard (jguichar); sfc@ietf.org > > *Subject:* Re: [sfc] SFC Terminology / Concepts > > > > I have a counter-proposal that eliminates the term "SFP" entirely: > > > > "The Service Function Chain (SFC) provides a fully abstract view of the > > service functions to be invoked and the order in which they are to be > > invoked for some particular flow or set of flows, without concern of > > actual service function instance selection. The Constrained-SFC > > (C-SFC) further allows for policy constraints to be added to the SFC > > affecting the selection of one or more of the service functions in the > > SFC. Any SFC may have any number of C-SFC's associated with it." > > > > Thanks. > > > > Ron > > > > "The SFP provides a level of indirection between the fully abstract > > notion of service path as a sequence of functions to be delivered, and > > the fully specified notion of exactly what instances of SFFs the packet > > will visit when it actually traverses the network. By allowing the > > control components to specify the use of this level of indirection, the > > deployment may choose the degree of SFF instance selection authority > > that is delegated to the network." > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > > *Sent:* Monday, July 14, 2014 2:03 PM > > *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > > *Subject:* Re: [sfc] SFC Terminology / Concepts > > > > I like that text, it strikes a good balance where an implementation has > > the option of making scale and resiliency a local matter.... > > > > D > > > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > > (jguichar) > > *Sent:* Monday, July 14, 2014 10:48 AM > > *To:* sfc@ietf.org <mailto:sfc@ietf.org> > > *Subject:* [sfc] SFC Terminology / Concepts > > > > Dear WG: > > > > There has been much debate over the last few days with regards to SFC > > concepts. To try and form some consensus around terminology and > concepts > > used to describe the architecture in the merged architecture draft, Joe= l > > has kindly suggested the following: > > > > "The SFP provides a level of indirection between the fully abstract > > notion of service path as a sequence of functions to be delivered, and > > the fully specified notion of exactly what instances of SFFs the packet > > will visit when it actually traverses the network. By allowing the > > control components to specify the use of this level of indirection, the > > deployment may choose the degree of SFF instance selection authority > > that is delegated to the network." > > > > I'd like to ask the WG as a whole, if this clarification is something > > that we can get consensus on. If so, I'll ask Joel to provide specific > > text, that reflects the above, for inclusion in the merged architecture > > draft. > > > > Thank You, > > > > Jim > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Mon Jul 14 11:43:58 2014 Return-Path: <ddolson@sandvine.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F31A005E for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6w0j0O8nys6 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:43:54 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id BF9741A0058 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:43:53 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Mon, 14 Jul 2014 14:43:53 -0400 From: Dave Dolson <ddolson@sandvine.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAALLEIAARjeA//+9UtA= Date: Mon, 14 Jul 2014 18:43:52 +0000 Message-ID: <E8355113905631478EFF04F5AA706E9830A2E533@wtl-exchp-2.sandvine.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C42183.8040605@joelhalpern.com> In-Reply-To: <53C42183.8040605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ilairm5Su56sklvjVEN-azbsqDM Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:43:56 -0000 I feel that the standardization effort needs to be primarily about the conc= rete *path*, in particular the packet formats and the rules for how SFFs se= lect the next hop(s). Because of that, I think the paths should have simple names (choosing SFP v= s. C-SFC). It may be just me, but I think we need to work bottom-up. I think we can have a standard without the abstract paths. The abstraction = almost feels like it could be vendor-specific in the Classifier. (I think the abstraction is very useful at the configuration layer, but not= essential to having packets moving.) I somewhat abashedly admit that I don't understand what Joel has written, e= specially, "the deployment may choose the degree of SFF instance selection = authority that is delegated to the network." What is "the deployment"? Vendor? Operator? Are the machines configuring th= emselves? What is "instance selection authority" ? Does this really mean, "the mapping from abstract SFC to SFP is left to imp= lementation." ? And therefore SFC-Classifier vendors can define variations= of abstraction? -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, July 14, 2014 2:29 PM To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar);= sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts Maria, while the constraint (either C-SFC or SFP, whichever term the SG=20 likes) may be selecting specific instances, it may be more general. The simplest example is that for a given service chain, one might have=20 one SFP (or C-SFC) that causes the entire chain to be delivered at=20 data-center-1 and a second SFP (or C-SFC) that causes the entire service=20 chain to be delivered at data-center-2. Each data center has many=20 instances running. And may even have multiple clusters in different=20 PODs within the DC. Yes, the constraint may say use exactly this specific isntances, but it=20 does not have to. Yours, Joel On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote: > Ron, > > this is pretty good. > > I would propose to re-phrase the second sentence to: "The > Constrained-SFC (C-SFC) further allows for policy constraints to be > added to the SFC affecting the selection of one or more **specific** > service function **instances** in the SFC". > > Maria > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > *Sent:* Monday, July 14, 2014 2:16 PM > *To:* David Allan I; Jim Guichard (jguichar); sfc@ietf.org > *Subject:* Re: [sfc] SFC Terminology / Concepts > > I have a counter-proposal that eliminates the term "SFP" entirely: > > "The Service Function Chain (SFC) provides a fully abstract view of the > service functions to be invoked and the order in which they are to be > invoked for some particular flow or set of flows, without concern of > actual service function instance selection. The Constrained-SFC > (C-SFC) further allows for policy constraints to be added to the SFC > affecting the selection of one or more of the service functions in the > SFC. Any SFC may have any number of C-SFC's associated with it." > > Thanks. > > Ron > > "The SFP provides a level of indirection between the fully abstract > notion of service path as a sequence of functions to be delivered, and > the fully specified notion of exactly what instances of SFFs the packet > will visit when it actually traverses the network. By allowing the > control components to specify the use of this level of indirection, the > deployment may choose the degree of SFF instance selection authority > that is delegated to the network." > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > *Sent:* Monday, July 14, 2014 2:03 PM > *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* Re: [sfc] SFC Terminology / Concepts > > I like that text, it strikes a good balance where an implementation has > the option of making scale and resiliency a local matter.... > > D > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Monday, July 14, 2014 10:48 AM > *To:* sfc@ietf.org <mailto:sfc@ietf.org> > *Subject:* [sfc] SFC Terminology / Concepts > > Dear WG: > > There has been much debate over the last few days with regards to SFC > concepts. To try and form some consensus around terminology and concepts > used to describe the architecture in the merged architecture draft, Joel > has kindly suggested the following: > > "The SFP provides a level of indirection between the fully abstract > notion of service path as a sequence of functions to be delivered, and > the fully specified notion of exactly what instances of SFFs the packet > will visit when it actually traverses the network. By allowing the > control components to specify the use of this level of indirection, the > deployment may choose the degree of SFF instance selection authority > that is delegated to the network." > > I'd like to ask the WG as a whole, if this clarification is something > that we can get consensus on. If so, I'll ask Joel to provide specific > text, that reflects the above, for inclusion in the merged architecture > draft. > > Thank You, > > Jim > > > > _______________________________________________ > sfc mailing 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 Jul 14 11:58:36 2014 Return-Path: <ddolson@sandvine.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B71A005B for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuYxAnZGz2ex for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 11:58:31 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id C77FC1A0061 for <sfc@ietf.org>; Mon, 14 Jul 2014 11:58:30 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Jul 2014 14:58:30 -0400 From: Dave Dolson <ddolson@sandvine.com> To: "sfc@ietf.org" <sfc@ietf.org>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "cpignata@cisco.com" <cpignata@cisco.com> Thread-Topic: Does SFF or SFC Proxy maintain flow state? Thread-Index: Ac+flZmPoVqRhMYfST+uEKhSnlnxIA== Date: Mon, 14 Jul 2014 18:58:29 +0000 Message-ID: <E8355113905631478EFF04F5AA706E9830A2E597@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.47] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830A2E597wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/593-m0IgeETT81IqLdvE_L2NAEM Subject: [sfc] Does SFF or SFC Proxy maintain flow state? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 18:58:33 -0000 --_000_E8355113905631478EFF04F5AA706E9830A2E597wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In draft-merged-sfc-architecture-00, section 4.3, <quote> The SFF component has the following primary responsibilities: ... 3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. When traffic arrives after being steered through an SFC-unaware SF, the SFF must perform re-classification of traffic to determine the SFP. A state-full SFF simplifies such classification to a flow lookup. <end quote> Is this correct? Shouldn't it be the SFC Proxy that maintains flow state in= order to re-classify traffic returning from an SFC-unaware SF? -Dave --_000_E8355113905631478EFF04F5AA706E9830A2E597wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">In draft-merged-sfc-architecture-00, section 4.3, <o= :p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><quote><o:p></o:p></p> <p class=3D"MsoNormal">   The SFF component has the following pri= mary responsibilities:<o:p></o:p></p> <p class=3D"MsoNormal">…<o:p></o:p></p> <p class=3D"MsoNormal">   3.  Maintaining flow state: In som= e cases, the SFF may be stateful.<o:p></o:p></p> <p class=3D"MsoNormal">       It creates flow= s and stores flow-centric information.  When<o:p></o:p></p> <p class=3D"MsoNormal">       traffic arrives= after being steered through an SFC-unaware SF,<o:p></o:p></p> <p class=3D"MsoNormal">       the SFF must pe= rform re-classification of traffic to determine<o:p></o:p></p> <p class=3D"MsoNormal">       the SFP.  = A state-full SFF simplifies such classification to a<o:p></o:p></p> <p class=3D"MsoNormal">       flow lookup.<o:= p></o:p></p> <p class=3D"MsoNormal"><end quote><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Is this correct? Shouldn’t it be the SFC Proxy= that maintains flow state in order to re-classify traffic returning from a= n SFC-unaware SF?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">-Dave<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_E8355113905631478EFF04F5AA706E9830A2E597wtlexchp2sandvi_-- From nobody Mon Jul 14 12:07:37 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A481A0071 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQyWUELRhBuk for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:07:18 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D694E1A006E for <sfc@ietf.org>; Mon, 14 Jul 2014 12:07:17 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 56a24c35.2b990da48940.5969358.00-2445.16545745.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 19:07:17 +0000 (UTC) X-MXL-Hash: 53c42a654906bf01-b34e1ee0db34126d348937b02ebc52c6f5a0e85d Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d1a24c35.0.5968599.00-2353.16543535.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 19:06:06 +0000 (UTC) X-MXL-Hash: 53c42a1e61091ae3-fe1a0ca0cfa15a750dea547f6a95c9bdfca98aff Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EJ64LT016391; Mon, 14 Jul 2014 15:06:05 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EJ5v74016260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 15:06:02 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 19:05:37 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 15:05:37 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn5DU2OzQZoFWE0KiLo/Wutu6nZuf7c5w Date: Mon, 14 Jul 2014 19:05:37 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BB01@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE95ABE.4BE2B%smkumar@cisco.com> In-Reply-To: <CFE95ABE.4BE2B%smkumar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BB01MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=y-ZxpICqmSAA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=3oc9M9_CAAAA:8 a=AUd_NHdVAAAA:8 a=z9tbli-vAAAA:8 a] X-AnalysisOut: [=ABeY7kuGAAAA:8 a=qN95wPeSAAAA:8 a=n2LCcfabAAAA:8 a=i0EeH8] X-AnalysisOut: [6SAAAA:8 a=7pAKWk10vR-fiIgiY1gA:9 a=QEXdDO2ut3YA:10 a=lZB8] X-AnalysisOut: [15dzVvQA:10 a=U8Ie8EnqySEA:10 a=JfD0Fch1gWkA:10 a=Hz7IrDYl] X-AnalysisOut: [S0cA:10 a=oAXR_kdF8uMA:10 a=chC_agHSu74A:10 a=paC5pjApGzsA] X-AnalysisOut: [:10 a=aQDv2Sx_jRYRPihD:21 a=ocM376H-yEzHjQ7Y:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=2nPu8lc9sz2ZRlofcA0A:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=Sf_gFPzhefAA:10 a=2ZwX20QFeR1ilB9d:21 a=ziXTD2YQJQ6] X-AnalysisOut: [eG88S:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9ySouRAgLYHOyY6b5AJgO-CDiGg Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 19:07:31 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BB01MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1lYW5pbmcgb2YgdGhlIFNGUCBJRCBpcyBwcmV0dHkgY2xlYXIsIGF0IGxlYXN0IHRvIG1l IOKAkyBhbiBhYnN0cmFjdCBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1 bmN0aW9uIGluc3RhbmNlcyAoaS5lLiwgU0ZQIElEIDEgPSB7U0YtQS0xLCBTRi1CLTMsIFNGLUMt Mn0pLiAgICBJbiBzb21lIHdheXMsIGl0IGlzIGEgY29sbGFwc2VkIOKAnGxhYmVsIHN0YWNr4oCd IOKAkyB0aGVyZSBpcyBhIHNpbmdsZSB0YWcgaW1wbHlpbmcgc29tZSBzZXF1ZW5jZSBvZiBuZXR3 b3JrIGxvY2F0aW9ucy4gICBCdXQsIHRoaXMgYWxzbyBpbXBsaWVzLCBhdCBsZWFzdCB0byBtZSwg dGhhdCB0aGVyZSBpcyBhIGNlbnRyYWwgcG9pbnQgb2Ygc2VsZWN0aW9uIGZvciB0aGlzIGVuZCB0 byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcgcmVjbGFzc2lmaWNhdGlvbiwgb2YgY291cnNlKS4gICBJ LCBmb3Igb25lLCBhbSBxdWVzdGlvbmluZyB0aGF0IGltcGxpY2F0aW9uLiAgICBJIGhhdmUgYmVl biB1bmNvbWZvcnRhYmxlIHdpdGggdGhhdCBjZW50cmFsIHBvaW50IG1ldGhvZG9sb2d5IGR1ZSB0 byByZWFsLXdvcmxkIGNvbXBsZXhpdGllcyBvZiBkeW5hbWljIHNjYWxlIGFuZCB0aW1lbGluZXNz IG9mIHJlYWN0aW9uIHRvIGZhaWx1cmVzLg0KDQo8TWFyaWE+IEkgYWdyZWUuIEl0IHNob3VsZCBu b3QgYmUgbWFuZGF0ZWQgYnkgdGhlIFNGQyBhcmNoaXRlY3R1cmUgdGhhdCBzb21ldGhpbmcgY2Fs bGVkIOKAnHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBJROKAnSBpcyBjYXJyaWVkIGluIHRoZSBwYWNr ZXQsIGJlY2F1c2UgaXQgaXMgbm90IG5lY2Vzc2FyeSBvciB0aGUgb25seSB3YXkgdG8gaW1wbGVt ZW50IHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9ucyB0aGF0IHdvdWxkIGRv IHRoYXQgYnV0IGl0IGNhbm5vdCBhbmQgZG9lc27igJl0IG5lZWQgdG8gYmUgbWFuZGF0ZWQuDQoN ClNLPiBJIGRpc2FncmVlIG9uIHRoZSAibm90IG5lY2Vzc2FyeSIgcGFydCBhcyBpdCBsZWFkcyB0 byBhIHZlcnkgaW5lZmZpY2llbnQgbWV0aG9kLg0KTGV0J3MgcGFyayBhc2lkZSB0aGUgU0ZDIHZz IFNGUCBkZWJhdGUgYW5kIHNheSBTRkM9PVNGUCBmb3IgdGhpcyBleHBsYW5hdGlvbi4gQSBjbGFz c2lmaWVyIG1heSBkZXRlcm1pbmUgU0ZQIElEIGJhc2VkIG9uIGEgbm9uLXRyaXZpYWwgZnVuY3Rp b24sIG1heSBiZSBhIERQSSwgYXMgcGFydCBvZiBpdHMgY2xhc3NpZmljYXRpb24uIE5vdCBjYXJy eWluZyB0aGUgSUQgcmVxdWlyZXMgcmVjbGFzc2lmaWNhdGlvbiBhZnRlciBldmVyeSBTRiBpbiBv cmRlciB0byBrZWVwIHRoZSBwYWNrZXRzIG9uIHRoZSByaWdodCBTRlAsIGluIHRoaXMgY2FzZSBh IERQSS4gRXZlbiB0aGF0IHJlY2xhc3NpZmljYXRpb24gbWF5IGJlIHRvIGxhdGUgaWYgb25lIG9m IHRoZSBTRnMgdHJhbnNmb3JtZWQgdGhlIHBhY2tldC4gU28sIHlvdSBkbyBuZWVkIGEgU0ZQIElE IGZvciBjaGFpbmluZyB0byBiZSB1c2VmdWwuDQoNClNLPiBBbmQgZm9yIHRoZSBhcmd1bWVudCBh Ym91dCBub3QgbmVlZGluZyBTRlAgSUQgYnV0IG9ubHkgU0ZDIElELCBhcmNoaXRlY3R1cmUgZG9l cyBub3QgcHJldmVudCAxOjEgbWFwcGluZyBiZXR3ZWVuIHRoZW0uDQoNCjxNYXJpYT4gVGhpcyBk aXNjdXNzaW9uIGlzIGFib3V0IFNGUCAoYW5kIFNGUCBJRCkgYXMgYSBzcGVjaWZpYywgcHJlLWRl ZmluZWQgc2VxdWVuY2Ugb2Ygc2VydmljZSBpbnN0YW5jZXMuDQpJIGJlbGlldmUgdGhhdCBTRlAg KGFuZCBpdHMgcmVwcmVzZW50YXRpb24gaW4gdGhlIHBhY2tldCkgaXMgbmVlZGVkIG9ubHkgd2hl biB0aGUgU0ZDcyBhcmUgc3ViamVjdCB0byB0cmFmZmljIGVuZ2luZWVyaW5nLiBUcnlpbmcgdG8g Zml0IHRoZSBTRlAgaW4gdGhlIGdlbmVyYWwgU0ZDIGFyY2hpdGVjdHVyZSwgd2l0aG91dCBzdGF0 aW5nIHdoYXQgaXQgaXMgZm9yLCBtYWtlcyBpdCBhbiBpbXBvc3NpYmxlIHRhc2suDQoNClN1cmVu ZHJhLg0KDQpNYXJpYQ0KDQpBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCBpcyB0byBzdGlsbCB1c2Ug Y2VudHJhbCBzZWxlY3Rpb24gdG8gc2VsZWN0IHRoZSBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNl IGZ1bmN0aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwgU0YtQ30pLCBidXQgYWxs b3cgdGhlIGFjdHVhbCBpbnN0YW5jZSBzZWxlY3Rpb24gdG8gYmUgZGlzdHJpYnV0ZWQsIHJlYWxp emVkIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgU0ZGcy4NCg0KR2l2ZW4gYSB0b3BvbG9neSBs aWtlOg0KDQpDbGFzc2lmaWVyIC0tLS0tLS0gIFNGRi0xIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNG Ri0yIC0tLS0tLS0tLS0tLS0tLS0tLS0tIFNGRi0zLS0tLS0tLS0tLS0tLS0tLS0tLVNGRi00DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgU0ZGLUEtMSAgICAgICBTRkYtQS0yICAgICAgIFNTRi1CLTEgICAgICAgIFNG Ri1CLTIgICAgICAgICBTRkYtQy0xICAgICAgIFNGRi1DLTIgICAgICAgICAgICAgICAgICAgU0ZG LUEtMw0KDQpBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVkIGZsb3csIHRoZSBzZXF1ZW5j ZSBjb3VsZCBnbyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQoxIENsYXNzaWZpZXIgc2VsZWN0cyBj aGFpbiBTRkMgSUQgMSB7U0YtQSwgU0YtQiwgU0YtQ30NCjIgQ2xhc3NpZmllciBzZWxlY3RzIFNG Ri0xIGFzIGhvc3RpbmcgYXQgbGVhc3Qgb25lIGluc3RhbmNlIG9mIFNGLUENCjMgQ2xhc3NpZmll ciBlbmNhcHN1bGF0ZXMgcGFja2V0IGluZGljYXRpbmcgY2hhaW4gSUQgPSAxLCBzZXJ2aWNlIGlu ZGV4ID0gMQ0KNCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0xDQo1IFNGRi0x LCBzZWVpbmcgY2hhaW4gSUQ9MSwgc2VydmljZSBpbmRleD0xLCBjaG9vc2VzIFNGRi1BLTIgYW1v bmdzdCBpdHMgYXZhaWxhYmxlIGluc3RhbmNlcyBvZiBTRi1BDQo2IFNGRi0xIHNlbmRzIHBhY2tl dCB0byBTRkYtQS0xDQo3IFNGRi1BLTEgc2VuZHMgcGFja2V0IGJhY2sgdG8gU0ZGLTENCjggU0ZG LTEgaW5jcmVtZW50cyBzZXJ2aWNlIGluZGV4IHRvIDINCjggU0ZGLTEgc2VsZWN0cyBTRkYtMiBh cyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBTRi1CDQo5IFNGRi0xIHByb2dyZXNz ZXMgcGFja2V0IHRvIFNGRi0yDQoxMCBwcm9jZXNzIHJlcGVhdHMgcGVyIGFib3ZlIHVudGlsIFNG Ri0zLCBhcyB0aGUgZWdyZXNzIGJvcmRlciwgcHJvZ3Jlc3NlcyB0aGUgcGFja2V0IHBlciByb3V0 aW5nIHRhYmxlDQoNClRoYW5rcy4NCg0KDQogICBSb24NCg0KDQpGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBTdW5kYXks IEp1bHkgMTMsIDIwMTQgMTE6MzAgUE0NClRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+OyBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2Nv LmNvbT47IG1uMTkyMUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT47IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uIFBhcmtl cjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSBSZWRl ZmluZSB0aGUgU0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCg0KDQpBZ3JlZSB0aGF0IHRoZSBjdXJyZW50IGRlZmluaXRpb24gb2YgdGhlIFNGUCBpbiB0 aGUgYXJjaCBkcmFmdCBpcyBhIGJpdCBjb25mdXNpbmcsIGp1c3QgYXMgd2hhdCB5b3UgaGFkIHBv aW50ZWQgb3V0Lg0KDQoNCg0KSW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIFNGUCBhcyBhbiBpbnN0 YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUgbmV0d29yayBzaG91bGQgYmUg4oCcYW4gb3JkZXJl ZCBsaXN0IG9mIHNlcnZpY2Ugbm9kZXMgYW5kIFNGIElEc+KAnShzZWUgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLXBjZS1iYXNlZC1zZmMtYXJjaC0wMSkuIE9mIGNv dXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQIGluIHRoZSBkYXRhIHBhY2tldCBpcyBhbm90 aGVyIHRoaW5nIChlLmcuLCBlaXRoZXIgdGhyb3VnaCBhIHBhdGggaWQgb3IgdGhyb3VnaCBhbiBN UExTIGxhYmVsIHN0YWNrKS4gSGVyZSB0aGUgc2VydmljZSBub2RlIG1lYW5zIHRoZSBkZXZpY2Ug d2hpY2ggY29udGFpbnMgdGhlIFNGRiBhbmQgdGhlIE5GIGNvbXBvbmVudHMgbWFuZGF0b3JpbHkg d2hpbGUgY29udGFpbmluZyB0aGUgU0YgYW5kIFNGIHByb3h5IGNvbXBvbmVudHMgb3B0aW9uYWxs eS4gVGhlIHNlcnZpY2Ugbm9kZSBjb3VsZCBiZSBhdHRhY2hlZCBvciBlbWJlZGRlZCB3aXRoIG11 bHRpcGxlIFNGIGluc3RhbmNlcyBhbmQgdGhvc2UgU0YgaW5zdGFuY2VzIGNvdWxkIGJlIG9mIHRo ZSBzYW1lIFNGIHR5cGUgb3Igbm90LiAgSW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRp cGxlIFNGIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlIChlLmcuLCBTRiBYKSBhcmUgYXR0 YWNoZWQgdG8gYSBnaXZlbiBzZXJ2aWNlIG5vZGUsIHRoZSBzZXJ2aWNlIG5vZGUgY291bGQgZGlz dHJpYnV0ZSB0aGUgdHJhZmZpYyB3aGljaCBuZWVkcyBTRiBYIGFtb25nIHRob3NlIFNGIGluc3Rh bmNlcyBvZiBTRiBYIHR5cGUgbG9jYWxseS4gTWVhbndoaWxlLCB0aGVyZSBtYXkgYmUgbXVsdGlw bGUgc2VydmljZSBub2RlcyB3aXRoaW4gYSBnaXZlbiBTRkMtZW5hYmxlZCBkb21haW4gd2hpY2gg YXJlIGVtYmVkZGVkIG9yIGF0dGFjaGVkIHdpdGggdGhlIFNGIGluc3RhbmNlcyBvZiB0aGUgc2Ft ZSBTRiB0eXBlLiBJbiB0aGlzIHdheSwgdGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxkIGJlIG1h ZGUgdmVyeSBmbGV4aWJsZS4NCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClhpYW9odQ0KDQoNCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbWlrZWJpYW5j QGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPg0KU2VudDogU2F0dXJkYXksIEp1bHkg MTIsIDIwMTQgMjo0NiBBTQ0KVG86IGpndWljaGFyQGNpc2NvLmNvbTxtYWlsdG86amd1aWNoYXJA Y2lzY28uY29tPjsgbW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPjsgbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT47IGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCg0KV291 bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNlIGNoYWluIGlkZW50aWZpZXIiIHRoZW4/ ICBJZiB0aGUgc2VydmljZSBjaGFpbiBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhl IHNlcnZpY2UgcGF0aCBpcyB0aGUgb3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywgdGhlbiBJ IHdvdWxkIGluZmVyIHRoYXQgYSAic2VydmljZSBwYXRoIGlkZW50aWZpZXIiIHdvdWxkIGJlIGFu IGlkZW50aWZpZXIgZm9yIGEgc2VydmljZSAqcGF0aCosIG5vdCBhIHNlcnZpY2UgKmNoYWluKi4N Cg0KQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBzIGNyZWVw aW5nIGluLiAgVGhlIHRlcm1zICJjaGFpbiIgYW5kICJwYXRoIiBzZWVtIGluY29uc2lzdGVudC4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGpndWljaGFyQGNpc2Nv LmNvbTxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSUzY2pndWlj aGFyQGNpc2NvLmNvbT4+DQpUbzogbWlrZWJpYW5jQGFvbC5jb208bWlrZWJpYW5jQGFvbC5jb20+ LG1uMTkyMUBhdHQuY29tPG1uMTkyMUBhdHQuY29tPixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+LGptaEBqb2VsaGFscGVybi5jb208am1o QGpvZWxoYWxwZXJuLmNvbT4sUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPixzZmNAaWV0Zi5vcmc8c2ZjQGlldGYub3JnPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFuY0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY29t JTNjbW4xOTIxQGF0dC5jb20lM2UsbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSUzY21vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Usam1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2Vs aGFscGVybi5jb20lM2UsUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSUzY1Jvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4N ClNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAxNA0KU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQpZb3VyIGRlZmluaXRpb24gb2Ygc2Vy dmljZSBwYXRoIGlzIGNvcnJlY3QgYXMgaXRzIHRoZSBmb3J3YXJkaW5nIHBhdGggdGhyb3VnaCB3 aGljaCB0cmFmZmljIHdpbGwgYWN0dWFsbHkgZmxvdy4gVGhlIHNlcnZpY2UgcGF0aCBpZGVudGlm aWVyIGhvd2V2ZXIgcG9pbnRzIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3RydWN0dXJlIGFu ZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJhc2VkIHVwb24g d2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZhaWxhYmxlIGFuZCB3aGF0 ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxheS4gV2hlbiBpbnN0YW50 aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1heSBvciBtYXkg bm90IHVwZGF0ZSB0aGF0IGRhdGEgc3RydWN0dXJlIHRvIHNwZWNpZnkgd2hpY2ggbmV4dC1ob3Bz IG1heSBiZSB1c2VkICh3aGVyZSBhIHNpbmdsZSBuZXh0LWhvcCB3b3VsZCBlZmZlY3RpdmVseSBu YWlsIHVwIHRoZSBzZXJ2aWNlIHBhdGggZm9yIHRoYXQgc2VydmljZSBjaGFpbikgb3IgeW91IG1h eSBzaW1wbHkgYWxsb3cgc29tZSBvdGhlciBwcm90b2NvbCAvIG1lY2hhbmlzbSB0byBwb3B1bGF0 ZSB0aGUgZGF0YSBzdHJ1Y3R1cmUgZm9yIHlvdS4NCg0KRnJvbTogIm1pa2ViaWFuY0Bhb2wuY29t PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4iIDxtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlr ZWJpYW5jQGFvbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBN DQpUbzogSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNp c2NvLmNvbT4+LCAibW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPiIgPG1uMTky MUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+LCAibW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4iIDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4s ICJqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiIgPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20+IiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxtYWlsdG86Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4+LCAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzZmNd IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkgdGhpbmsgdGhp cyBpcyB0aGUgcm9vdCBvZiB0aGUgY29uZnVzaW9uOg0KDQo+IEkgZG9u4oCZdCB3YW50IHRvIHNw ZWNpZnkNCj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNv bWJpbmF0aW9uIHRoZXJlb2YpLiBJDQo+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVy IOKAnDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8gUzEtPlMyLT5TMw0KPiBhbmQgdGhl biBwdXNoIHRoaXMgaW50byB0aGUgbmV0d29yaw0KDQpCeSBkZWZpbml0aW9uLCBJIHVuZGVyc3Rv b2QgYSAic2VydmljZSBwYXRoIiB0byBiZSBhbiBvcmRlcmVkIGxpc3Qgb2Ygc3BlY2lmaWMgU0Yg aW5zdGFuY2VzLiBJbiB0aGUgc3RhdGVtZW50IGFib3ZlLCB5b3UgdXNlIGEgInNlcnZpY2UgcGF0 aCBpZGVudGlmaWVyIiB0byByZWZlciB0byBhIHNlcnZpY2UgKmNoYWluKiB0aGF0IHNwZWNpZmlj YWxseSAiW2RvZXMgbm90XSBzcGVjaWZ5IHNwZWNpZmljIGluc3RhbmNlcyIuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBqZ3VpY2hhckBjaXNjby5jb208bWFpbHRv OmpndWljaGFyQGNpc2NvLmNvbT48amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBj aXNjby5jb20+Pg0KVG86IE5BUElFUkFMQSwgTUFSSUEgSDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86 bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4sSm9lbCBNLiBIYWxwZXJuPGptaEBq b2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PixSb24gUGFya2VyPFJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20+PixzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0DQpT dWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCg0KTWFyaWEsDQoNCkkgdGhpbmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2ludGVyIHRvDQphIGRhdGEgc3RydWN0dXJlIHRoYXQg Y29udGFpbnMgU0YgdG8gbmV4dC1ob3AgbWFwcGluZ3MuIFdoZW4geW91IGRlZmluZSBhDQpjaGFp biwgbGV04oCZcyBzYXkgUzEgLT5TMi0+IFMzLCB5b3UgKm1pZ2h0KiB3aGVuIGNyZWF0aW5nIHRo ZSBTRlAgc3BlY2lmeQ0KdGhlIHNwZWNpZmljIG5leHQtaG9wcyB0aGF0IHlvdSB3YW50IHRyYWZm aWMgdG8gZmxvdyB0aHJvdWdoIGZvciB0aGF0IFNGUC4NCkhvd2V2ZXIsIHlvdSBkbyAqbm90KiBo YXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRlY3R1cmFsIHN0YW5kcG9pbnQgKEkNCndpbGwg YXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIGFyY2hpdGVjdHVy YWxseSkuIFlvdQ0KY291bGQgc2ltcGx5IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVy IHRvIHBvaW50IHRvIGEgZ2l2ZW4gU0ZDIGFuZA0KdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRpb24g aW50byB0aGUgbmV0d29yay4gQXQgdGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0Kc2VydmljZSBwYXRo IGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3b3VsZCBjb250YWlu IHRoZQ0KbmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0 aGUgU0ZDIC0gaG93IHlvdSBsZWFybg0KdGhvc2UgbmV4dC1ob3BzIGlzIHVwIHRvIHlvdS4gWW91 IGNvdWxkIHB1c2ggdGhlbSBkb3duIGZyb20gYSBjZW50cmFsaXplZA0KY29udHJvbGxlciwgY29u ZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkgdGhyb3VnaA0K c29tZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMg bm90IGNvcnJlY3QgdG8NCnNheSB0aGF0IHRoZSBzZXJ2aWNlIHBhdGggbWVhbnMgdGhhdCBhbGwg U0YgaW5zdGFuY2VzIGFyZSBjaG9zZW4gYSBwcmlvcmkNCmFsdGhvdWdoIGl0IGlzIHBlcmZlY3Rs eSBhY2NlcHRhYmxlIChhbmQgc29tZSB3b3VsZCBzYXkgcmVjb21tZW5kZWQpIHRvIGRvDQpzby4N Cg0KTGV04oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoN Cg0KSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+UzIt PlMzLiBGb3IgYXJndW1lbnRzDQpzYWtlIGxldOKAmXMgc2F5IEkgd2FudCBpdCB0byBiZSBmdWxs eSBkeW5hbWljIGUuZy4gSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeQ0Kc3BlY2lmaWMgaW5zdGFu Y2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2YpLiBJDQph c3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0gdGhhdCBiYXNpY2FsbHkg cG9pbnRzIHRvIFMxLT5TMi0+UzMNCmFuZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3Jr IHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0cnVjdHVyZXMgYXJlDQpwb3B1bGF0ZWQgd2l0aCB0aGlz IGluZm9ybWF0aW9uLiBOb3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzDQp3 aXRoIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1 cCBpbiB0aGUgZGF0YQ0Kc3RydWN0dXJlIGFuZCBmaW5kIHRoYXQgaXQgcG9pbnRzIHRvIFMxLT5T Mi0+UzMgYW5kIHRoZSBpbmRleCBpbiB0aGUgU0ZDDQplbmNhcHN1bGF0aW9uIHdpbGwgdGVsbCBp dCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV04oCZcyBzYXkgd2UNCmFyZSBh dCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBTRkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBu ZXh0LWhvcCB0bw0KUzMgYW5kIHdpbGwgZG8gYSBsb29rdXAgdG8gZGV0ZXJtaW5lIHdoZXJlIFMz IGlzIHJlYWNoYWJsZS4NCg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICJOQVBJRVJBTEEsIE1BUklB IEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToNCg0KPkpp bSwNCj4NCj5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNl cnZpY2UgcGF0aCIgYW5kIGENCj4ic2VydmljZSBwYXRoIGlkZW50aWZpZXIiPw0KPklmIGEgc2Vy dmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGFwcmlvcmkg KHdoaWNoDQo+aXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nKSB0aGVuIGl0IGlzIG5vdCBTRkYn cyBsb2NhbCBkZWNpc2lvbiB3aGljaA0KPm5leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNl bnRyYWxpemVkIGRlY2lzaW9uLg0KPg0KPk1hcmlhDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4NCg0KRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpq Z3VpY2hhckBjaXNjby5jb21dDQo+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTE6MTUg QU0NCj4+IFRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBKb2VsIE0uDQo+PiBIYWxw ZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vy cw0KPj4NCj4+IEnigJltIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb27igJl0IHVuZGVyc3RhbmQgd2h5 IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4+IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9u IG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UNCj4+IGNoYWluIGlk ZW50aWZpZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+Pg0KPj4gT24gNy8xMS8xNCwgMTA6NTgg QU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0 dC5jb20+PiB3cm90ZToNCj4+DQo+PiA+RGl0dG8uDQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+IFttYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0NCj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAx NCAxMDozMSBBTQ0KPj4gPj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJRVJBTEEs IE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uDQo+PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2Ug Q2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+Pg0KPj4gPj4gUmUtLA0KPj4g Pj4NCj4+ID4+IEZvciB3aGF0IEkgY2FuIHNheSBhdCBiZXN0IHRoaXMgaXMgbm90IGRlc2NyaWJl ZCBjbGVhcmx5IGluIHRoZQ0KPj5kcmFmdC4NCj4+ID4+DQo+PiA+PiBNYW5kYXRpbmcgYSBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciBpcyBpbiBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4+ ID4+ZGlzdHJpYnV0ZWQNCj4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4gPj4NCj4+ID4+ IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0aGF0IHRoZSBzZXJ2aWNl IGNoYWluIGl0c2VsZg0KPj4gPj5zaG91bGQgYmUNCj4+ID4+IHByb3ZpZGVkIGluc3RlYWQuDQo+ PiA+Pg0KPj4gPj4gQ2hlZXJzLA0KPj4gPj4gTWVkDQo+PiA+Pg0KPj4gPj4gPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPj4gPj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+PiA+PiA+KGpndWljaGFyKQ0KPj4g Pj4gPkVudm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+ID4+ID7DgCA6 IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID5PYmpldCA6IFJlOiBbc2ZjXSBTZXJ2 aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPg0KPj4gPj4gPk9r IGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0 aW9uYWxpdHkNCj4+ID4+ID5wcm9oaWJpdGVkPyBJZiB5b3Ugd2FudCB0byBkaXN0cmlidXRlICph bGwqIG5leHQtaG9wcyB0byAqYWxsKiBTRkbigJlzDQo+PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9t YWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlmaWVyIHBvaW50IHRvIGENCj4+ID4+bG9v a3VwDQo+PiA+PiA+aW50byB0aG9zZSBuZXh0LWhvcHMgdG8gcmVhY2ggdGhlIG5leHQgU0YgaW4g dGhlIGNoYWluLCBJIGFtIG5vdA0KPj5zdXJlDQo+PiA+Pmhvdw0KPj4gPj4gPnRoZSBhcmNoaXRl Y3R1cmUgcHJldmVudHMgdGhhdD8NCj4+ID4+ID4NCj4+ID4+ID5PbiA3LzExLzE0LCA5OjU4IEFN LCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQu Y29tPj4NCj4+IHdyb3RlOg0KPj4gPj4gPg0KPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPj4gPj4gPj4N Cj4+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPj4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJk DQo+PiA+PiA+Pj4oamd1aWNoYXIpDQo+PiA+PiA+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAy MDE0IDk6NTQgQU0NCj4+ID4+ID4+PiBUbzogTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhh bHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhl IHByb3Bvc2FsIDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcyB0byBtZQ0KPj4gPj50aGF0IGlmDQo+ PiA+PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2gg cmVtb3RlIFNGRiBpdA0KPj53aWxsDQo+PiA+PnVzZQ0KPj4gPj4gPj4+Zm9yDQo+PiA+PiA+Pj4g YSBnaXZlbiBmbG93IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5 b3UNCj4+YmV0dGVyDQo+PiA+Pm1ha2UNCj4+ID4+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUg U0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8NCj4+ID4+cmVhY2gNCj4+ ID4+ID4+PnRoZQ0KPj4gPj4gPj4+IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVy d2lzZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IE9uIDcv MTEvMTQsIDk6NDggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWls dG86bW4xOTIxQGF0dC5jb20+Pg0KPj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+ QWJzb2x1dGVseSBub3QuIFNlcnZpY2UgY2hhaW5zIGNhbiBiZSBpbnN0YW50aWF0ZWQgb25seSBp bg0KPj5yZWxldmFudA0KPj4gPj4gPj4+U0ZGcw0KPj4gPj4gPj4+ID53aGVuIHRoZXkgImFycml2 ZSIuDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiA+Pj4gPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKaW0NCj4+R3VpY2hhcmQNCj4+ID4+ID4+PiA+PihqZ3VpY2hhcikNCj4+ID4+ ID4+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4gPj4gPj4+ID4+ IFRvOiBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPg0KPj4gPj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4g V2VsbCBJIHRoaW5rIGl0IGlzIGV2ZW4gd29yc2UgdGhhbiB0aGF0IGlmIEkgaGF2ZSB1bmRlcnN0 b29kDQo+PnRoZQ0KPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4+ID4+ID4+PiA+PiBjb3JyZWN0bHkg YXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBzaW5nbGUNCj4+U0YN Cj4+ID4+ID4+PndpdGhpbg0KPj4gPj4gPj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gZW50aXJlIFNG QyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG8NCj4+a25v dw0KPj4gPj5hDQo+PiA+PiA+Pj4gPj5wcmlvcmkNCj4+ID4+ID4+PiA+PiB3aGljaCBTRkPCuXMg YSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuDQo+PnBvaW50DQo+ PiA+PmluDQo+PiA+PiA+Pj50aW1lLg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+Pj4gPj4gT24gNy8x MC8xNCwgMTE6NTMgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+ID4+IHdyb3RlOg0KPj4gPj4gPj4+ID4+DQo+ PiA+PiA+Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVy IG1ham9yIHByb2JsZW0NCj4+d2l0aA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PnlvdXINCj4+ID4+ ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAoQW5kIEkgcmVhZGlseSBhZG1p dCBJIG1heSBub3QNCj4+ID4+ID4+PnVuZGVyc3RhbmQNCj4+ID4+ID4+PiA+PiA+aXQuKQ0KPj4g Pj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2 ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+PiA+Pm5leHQNCj4+ID4+ID4+PiA+PiA+ c2VydmljZSBmdW5jdGlvbiB0aGF0IGZvbGxvd3MgaXQgKG5vdCB0aGUgb25lIGl0IGRlbGl2ZXJz DQo+PnRvKSwNCj4+ID4+aW4NCj4+ID4+ID4+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPnNlcnZpY2Ug Y2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGggYWxsIHNlcnZpY2VzLCB0aGF0 IG1lYW5zDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PmV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPlNGRiB3 b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0YXRlZnVsIGxvYWQN Cj4+ID4+ID4+PmJhbGFuY2VyLg0KPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBz b21lIFNGRiBhcmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yDQo+PiA+PnN0YXRlZnVsLg0KPj4g Pj4gPj4+ID4+ID5CdXQgaGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5 IFNGRiBiZSBhIGZ1bGwsDQo+PiA+PmZsb3cNCj4+ID4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0 ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPj4gPj5hY2NlcHRhYmxl DQo+PiA+PiA+Pj4gPj4gPmltcG9zaXRpb24uDQo+PiA+PiA+Pj4gPj4gPg0KPj4gPj4gPj4+ID4+ ID5Zb3VycywNCj4+ID4+ID4+PiA+PiA+Sm9lbA0KPj4gPj4gPj4+ID4+ID4NCj4+ID4+ID4+PiA+ PiA+T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+ID4+ID4+ PiA+PiA+PiBQYXJ0IG9mIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBt YWtlIHRoaXMNCj4+d29yaw0KPj4gPj4gPj4+ID4+c2Vuc2libHkNCj4+ID4+ID4+PiA+PiA+PiBp biBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPj5z ZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5 IHRoZSBTRkYgY2FwYWJpbGl0aWVzLA0KPj53aWxsDQo+PiA+PmJlDQo+PiA+PiA+Pj4gPj4gPj4g b3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlucw0K Pj50byBiZQ0KPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+PiA+PiA+Pj4gPj4gPj4gQlNTIHRvb2xz IHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlDQo+PiA+PiA+Pj5z ZWxmLXNlbGVjdGlvbg0KPj4gPj4gPj4+ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZp Y2UgcGF0aHMgdG8gYmUgaGVhdmlseSBwb2xpY3kNCj4+ID4+ZHJpdmUuDQo+PiA+PiA+Pj4gPj4g Pj4NCj4+ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29y ayBpbiBhbiBhcmNodGllY3R1cmUNCj4+ID4+ZHJpdmVuDQo+PiA+PiA+Pj5ieQ0KPj4gPj4gPj4+ ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24gdG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMu IEl0IGlzDQo+PiA+PmhhcmRlcg0KPj4gPj4gPj4+dG8NCj4+ID4+ID4+PiA+PnNlZQ0KPj4gPj4g Pj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3 ZSBhbGxvdyBtb3JlDQo+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPj4gPj4gPj4+ID4+ID4+IGlu IHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPj4gPj4gPj4+ID4+ID4+DQo+PiA+PiA+Pj4gPj4gPj4g SGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNwZWN0aXZlIEkgZGVzY3JpYmVkIGlz DQo+PiA+Pm91dHNpZGUNCj4+ID4+ID4+Pm9mDQo+PiA+PiA+Pj4gPj50aGUNCj4+ID4+ID4+PiA+ PiA+PiBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cC4gaXQgaXMgbm90IHNvbWV0aGluZyB3ZSBh cmUNCj4+ID4+dGFza2VkIHRvDQo+PiA+PiA+Pj4gPj5hZ3JlZQ0KPj4gPj4gPj4+ID4+ID4+b24u DQo+PiA+PiA+Pj4gPj4gPj4gU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2aXNpb24gbWVhbnMgd2Ug aGF2ZSB0byBkbyBpdCBhDQo+PmNlcnRhaW4NCj4+ID4+ID4+PndheS4NCj4+ID4+ID4+PiA+Pml0 DQo+PiA+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhhdCBkcml2ZXMgbXkg cHJlZmVyZW5jZXMuDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBZb3VycywNCj4+ ID4+ID4+PiA+PiA+PiBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+PiA+PiBPbiA3 LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+PiBGb3Ig bWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5jZXMNCj4+ ID4+IHRoYXQNCj4+ID4+ID4+PiA+Pm5lZWRzDQo+PiA+PiA+Pj4gPj4gPj4+PnRvDQo+PiA+PiA+ Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlh bGx5IGV2ZW4NCj4+ID4+YWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+PiBj ZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoDQo+ PmFuZA0KPj4gPj4gPj4+IGNvbXBsZXgNCj4+ID4+ID4+PiA+PiA+Pj4+IGVub3VnaCB0aGF0IHRy eWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlm ZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+ID4+ ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQg aXMgbW9yZSBjb21wbGljYXRlZCB0aGFuDQo+PmR5bmFtaWMNCj4+ID4+ID4+PiByb3V0aW5nLA0K Pj4gPj4gPj4+ID4+ID4+PiBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0cmF0aW9uLCBv ciBETlMsIGFsbCBvZg0KPj53aGljaA0KPj4gPj5hcmUNCj4+ID4+ID4+PiA+PmJpZ2dlcg0KPj4g Pj4gPj4+ID4+ID4+PiBwcm9ibGVtcyB0aGF0IGhhdmUgYmVlbiBwcm9maXRhYmx5IGFuZCBzdGFi bHkgaW1wbGVtZW50ZWQ/DQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IEl0IGFs c28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPj5p cw0KPj4gPj5hDQo+PiA+PiA+Pj5nb29kDQo+PiA+PiA+Pj4gPj4gPj4+IHNpZ24gdGhhdCBpdCBp cyB0b28gY29tcGxpY2F0ZWQuDQo+PiA+PiA+Pj4gPj4gPj4+DQo+PiA+PiA+Pj4gPj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiA+PiA+Pj4g RnJvbTogSm9lbCBNLiBIYWxwZXJuIFtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPl0NCj4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgOTo0NSBQTQ0KPj4gPj4gPj4+ID4+ID4+PiBUbzogUm9uIFBhcmtlcjsgSm9lbCBIYWxw ZXJuIERpcmVjdDsgbWlrZWJpYW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsN Cj4+SWFuDQo+PiA+PiA+Pj5TbWl0aDsNCj4+ID4+ID4+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBT ZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFu ZCBvbmUgdGhhdCBJIHdvdWxkDQo+PnByZWZlcg0KPj4gPj53ZQ0KPj4gPj4gPj4+ID4+ID4+PmFj dHVhbGx5DQo+PiA+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGFs bG93IGFsbCBwb3NzaWJsZQ0KPj4gPj5pbXBsZW1lbnRhdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+ IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFqb3IgZWZmZWN0IG9uIHRoZSBjb250cm9sDQo+PiA+ PnJlcXVpcmVtZW50cw0KPj4gPj4gPj4+YW5kDQo+PiA+PiA+Pj4gPj4gdGhlDQo+PiA+PiA+Pj4g Pj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4gRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2Ug aW5zdGFuY2VzDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiBuZWVkcw0KPj4gPj4gPj4+ID4+IHRvDQo+ PiA+PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90 ZW50aWFsbHkgZXZlbg0KPj4gYWNyb3NzDQo+PiA+PiA+Pj5kYXRhDQo+PiA+PiA+Pj4gPj4gPj4+ IGNlbnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gN Cj4+YW5kDQo+PiA+PiA+Pj5jb21wbGV4DQo+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRy eWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4gPj4gPj4+ZGlm ZmljdWx0DQo+PiA+PiA+Pj4gPj4gPj4+IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLg0KPj4gPj4g Pj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBZb3VycywNCj4+ID4+ID4+PiA+PiA+Pj4gSm9l bA0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBCdXQgaXQgaXMgYSBmYWlyIHF1 ZXN0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pg0KPj4gPj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5 OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhpcyBpcyB0aGUg Y3J1eCBvZiBteSBpc3N1ZS4gSXMgdGhlIGVuZCB0byBlbmQNCj4+c2VsZWN0aW9uDQo+PiA+Pm9m DQo+PiA+PiA+Pj4gPj4gPj4+PiAodG9wLWxldmVsKSBpbnN0YW5jZXMgcGVyZm9ybWVkIGNlbnRy YWxseSAocGVyaGFwcyBieSB0aGUNCj4+ID4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+PiA+PiA+Pj4g Pj4gPj4+PiBvciBob3AtYnktaG9wIChwZXJoYXBzIGJ5IHRoZSBjbGFzc2lmaWVyIGFuZCBzdWJz ZXF1ZW50bHkNCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj5TRkZzKT8NCj4+ID4+ID4+PiA+PiA+Pj4+ IFN1Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+ PkFuZA0KPj4gPj4gPj4+c3VyZWx5LA0KPj4gPj4gPj4+ID4+ID4+Pj4gdGhpcyBpcyBhbiBhcmNo aXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+PiAi aW1wbGVtZW50YXRpb24iLg0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IE15 IG93biB2aWV3IGlzIHRvIGZhdm9yIHRoZSBkaXN0cmlidXRlZCBhcHByb2FjaCBldmVuDQo+PiB0 aG91Z2gNCj4+ID4+IGENCj4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEg KGNoYWluIGRlZmluaXRpb25zIGFuZCBwZXJoYXBzDQo+PmxvY2FsDQo+PiA+PiA+Pj4gPj5zZWxl Y3Rpb24NCj4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVxdWlyZWQgYXQgdGhvc2UgZGlz dHJpYnV0ZWQgZGVjaXNpb24gcG9pbnRzLg0KPj4gPj5UaGlzDQo+PiA+PiA+Pj4gPj4gPj4+PiBh cHByb2FjaCBkb2VzIG5vdCByZXF1aXJlIGFuIGVuZC10by1lbmQgcGF0aCBpZCBhdCBhbGwuDQo+ PiA+Pk15DQo+PiA+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBw cm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0KPj5ieQ0KPj4gPj4gPj4+ID4+aW5jcmVhc2VkDQo+ PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJv YWNoLiBXaXRoIGENCj4+Z2xvYmFsDQo+PiA+PiA+Pj5wYXRoDQo+PiA+PiA+Pj4gPj5pZA0KPj4g Pj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2Ug YW5kIG5lZWRpbmcgdG8NCj4+ID4+YWx0ZXINCj4+ID4+ID4+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+ Pj4gZ2xvYmFsIHBhdGggSUQgdGFibGUgZm9yIGVhY2ggYW5kIGV2ZXJ5IGFmZmVjdGVkDQo+PmVu ZC10by1lbmQNCj4+ID4+ID4+PnBhdGguDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4gUm9uDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+ID4+ID4+PiA+PiA+ Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBv biBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0KPj4gPj4gPj4+ID4+ID4+Pj4gW2ptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbT5d IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLA0KPj4yMDE0DQo+PiA+PiA2OjE1DQo+PiA+PiA+Pj4g UE0NCj4+ID4+ID4+PiA+PiA+Pj4+IFRvOiBtaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86bWlrZWJp YW5jQGFvbC5jb20+OyBJLlNtaXRoQEY1LmNvbTxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6DQo+PiA+PiBSZToNCj4+ ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFs YW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUg YXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZw0KPj50bw0KPj4gPj4g Pj4+ID4+aW5mbHVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+PiB0aGUgY2hhaW4gaXMgdGhhdCBvbmUg d291bGQgZG8gcmVjbGFzc2lmaWNhdGlvbiBhdCB0aGUNCj4+ZXhpdA0KPj4gPj5mcm9tDQo+PiA+ PiA+Pj4gPj4gPj4+PiBTRjEuDQo+PiA+PiA+Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4g UGFydCBvZiB0aGUgZ29hbCBpcyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+PiA+ PmxvZ2ljYWxseQ0KPj4gPj4gPj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMg Y2FuIGNsZWFybHkgZGVzY3JpYmUgaG93IHRoZXkNCj4+ID4+IGNob29zZQ0KPj4gPj4gPj4+dG8N Cj4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0K Pj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+ Pj4gPj4gPj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJp YW5jQGFvbC5jb208bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPiB3cm90ZToNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dl c3RzIGFueQ0KPj4gPj5zb3J0DQo+PiA+PiA+Pj5vZg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxpbWl0 LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlDQo+PiA+ PnBhdGgNCj4+ID4+ID4+PihhbGwNCj4+ID4+ID4+PiA+PiA+Pj4+PiBTRklzKSBtdXN0IGJlIGNo b3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBiZWxpZXZlDQo+PnRoaXMNCj4+ID4+ID4+Pm1l YW5zDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJl IHRoZSBjbGFzc2lmaWVyDQo+PmNob29zZXMgYQ0KPj4gPj5TRg0KPj4gPj4gPj4+ID4+Q2hhaW4N Cj4+ID4+ID4+PiA+PiA+Pj4+PiBhbmQgdGhlIE5GIG9yIGF0IHRoZSBsYXRlc3QgdGhlIGZpcnN0 IFNGRi4gSW4gYW55IGNhc2UsDQo+PiA+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IGxhbmd1YWdl IGRvZXMgc2VlbSB0byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmUNCj4+ID4+IFNG SShuKQ0KPj4gPj4gPj4+IGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0aGUg U0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LA0KPj4gPj50aGlzDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBh IG5ldyBTRlAgYXMNCj4+ID4+ID4+PiBvcHBvc2VkDQo+PiA+PiA+Pj4gPj4gdG8NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBp bnN0YW5jZSBvZg0KPj4gPj50aGUNCj4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0aGUg Y3VycmVudCBTRkMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBkcmFm dC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gV2hlbiBh biBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdvcmsgaXQgaXMNCj4+ID4+bmVjZXNz YXJ5DQo+PiA+PiA+Pj50bw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmlj IGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsDQo+PiA+PmFuZCB0bw0KPj4gPj4g Pj4+ID4+ID4+Pj4+PiBjcmVhdGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVz aW5nIFNGJ3MNCj4+ID4+bmV0d29yaw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiBUaHVz LCBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4+ID4+ID4+PmNyZWF0 aW9uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IG9mIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlAp IGFuZCBpcyB1c2VkIGZvcg0KPj4gPj5mb3J3YXJkaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHBh Y2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJbiBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUg c3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4+ID4+bm9uLWluaXRpYWwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2Ug YW4gU0ZQLA0KPj4gPj4gPj4+ID4+ID4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIG1heSBvY2N1ciAt IHR5cGljYWxseSBwZXJmb3JtZWQgYnkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNh dGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0KPj4gPj5mdW5jdGlvbi4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4gUmVjbGFzc2lmaWNhdGlvbiBtYXkgcmVzdWx0IGluIHRoZSBz ZWxlY3Rpb24gb2YgYSBuZXcNCj4+ID4+U0ZQLCBhbg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiB1cGRh dGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXMNCj4+ID4+cmVm ZXJyZWQNCj4+ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0K Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+Pg0KPj4gPj4NCj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+ID4+Pj4+Pj4+Pj4+Pi0t LQ0KPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4tLQ0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tPG1haWx0 bzoqSS5TbWl0aEBGNS5jb20+PEkuU21pdGhARjUuY29tPG1haWx0bzpJLlNtaXRoQEY1LmNvbT4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gKlRvOiAqSm9lbCBIYWxwZXJuDQo+PiBEaXJlY3Q8am1oLmRp cmVjdEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPj4s Sm9lbA0KPj4gPj4gTS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+DQo+PiA+PiA+ Pj4NCj4+ID4+DQo+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVhbmdAc2Nl LmNhcmxldG9uLmNhPjxodWFuZ0BzY2UuDQo8bWFpbHRvOmh1YW5nQHNjZS4lMGI+Pj4gPj4gPj4+ ID4+IGNhcmxldG9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPjxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+ID4+ID4+PiA+ PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBM b2FkDQo+PiA+PkJhbGFuY2Vycw0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWluZy4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUg ZGVwbG95bWVudHMgKGFuZA0KPj50aGF0IGlzDQo+PiA+PiA+Pj53aGF0DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gMTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMg aXMNCj4+ID4+ID4+PnByZWNvbmNlaXZlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFic3Vy ZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aA0KPj4gdGhhdA0KPj4g Pj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ ID4+PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVn cmVlIG9mDQo+PiA+PmFzcGlyYXRpb24NCj4+ID4+IHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gc2Nh bGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZQ0KPj4gPj5hcmNo aXRlY3R1cmUNCj4+ID4+ID4+Pi0NCj4+ID4+ID4+PiA+PiA+Pj4+PiB5b3UgZG9uJ3QgaGF2ZSB0 byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbg0KPj4gPj4gPj4+YXJiaXRy YXJ5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gbnVtYmVyIGlzICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0 aW5nIC0gZXZlbiBpZiBpdCBpc24ndA0KPj4gPj4gPj4+ID4+aW50ZW50aW9uYWwNCj4+ID4+ID4+ PiA+PiA+Pj4+PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUg bGFzdGluZw0KPj4gPj5pbXBhY3RzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxl LW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LA0KPj4gPj5hZGRyZXNzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gc3BhY2UuLi4gYWxsIGtpbmRzIG9mIHRoaW5ncy4gVGhhdCBpcyBhIHBy b2JsZW0gSSdtIG5vdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBk ZWFsIHdpdGguDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4g Pj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVy biBEaXJlY3QgW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWguZGlyZWN0QGpv ZWxoYWxwZXJuLmNvbT5dDQo+PiA+PlNlbnQ6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4gVGh1cnNkYXks IEp1bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsIE0uDQo+PiA+PiBIYWxw ZXJuOw0KPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxtYWlsdG86aHVh bmdAc2NlLmNhcmxldG9uLmNhPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IFN1 YmplY3Q6IFJlOiBbc2ZjXQ0KPj4gPj5TZXJ2aWNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+PiBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdpdGggbWUgYXQgYWxs IGluIHRoaXMNCj4+ID4+cmVnYXJkLg0KPj4gPj4gPj4+SQ0KPj4gPj4gPj4+ID4+YW0NCj4+ID4+ ID4+PiA+PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUg c29sdXRpb24NCj4+ID4+cHJvaGliaXQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZXBsb3ltZW50cyBp biB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3RpbmcgdG8NCj4+ID4+SHVhbmcncw0K Pj4gPj4gPj4+ID4+ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNo IGRlcGxveW1lbnRzIGFyZQ0KPj4gPj4gcmVxdWlyZWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiB0aGV5 IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+PiBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcgdG8gcHJvaGli aXQNCj4+c3VjaA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4gV2hldGhlciB0aGV5IGFyZSBh IGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uDQo+PiA+PiBtYW55DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRv DQo+PnRoaW5rDQo+PiA+PnRoYXQNCj4+ID4+ID4+PiA+PnRoZXkNCj4+ID4+ID4+PiA+PiA+Pj4+ PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4gQnV0IHRoZSBhcmNodGllY3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nIGF0dGVt cHRpbmcgdG8NCj4+ID4+a25vdw0KPj4gPj4gPj4+d2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGlz IGFuZCBpcyBub3QgZXBsb3lhYmxlLg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+ IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0aCB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4gSSBkaXNhZ3JlZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4g V2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNlcyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+ PiA+PiA+Pj5taWxsaW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZg0KPj4gPj4gPj4+ID4+ID4+ Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3MgbmV0d29yayBhbmQgZGF0YSBjZW50 ZXINCj4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJp b3VzbHkgYmVsaWV2ZSB0aGF0IGluDQo+PnRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IENsb3VkL0lQ djYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21vcnJvdyB5b3UNCj4+IGFyZQ0KPj4g Pj4gb25seQ0KPj4gPj4gPj4+ID4+IGdvaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdG8gaGF2ZSBz bWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseQ0KPj5zbWFsbA0KPj4g Pj4gPj4+IG51bWJlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+PiBvZiBhY3RpdmUgc2VydmljZSBwYXRo cz8NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91ciBzb3VuZHMg dG9vIG11Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUNCj4+IHRoYW4NCj4+ID4+ ID4+PiA2NEsiDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGZvcg0KPj4gPj4gPj4+ID4+ID4+Pj4+IGNv bWZvcnQuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJv bTogc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+XQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAx NCA0OjQ2IFBNIFRvOg0KPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhPG1haWx0bzpodWFu Z0BzY2UuY2FybGV0b24uY2E+Ow0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRo cywNCj4+YW5kDQo+PiA+PiA+Pj5Mb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IEJhbGFuY2Vycw0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFu IHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+PiA+PiA+Pj5hcmNodGlldHVy ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYXJ0aWN1bGFybHkgYmFkbHksIHRoZXkgd2lsbCBleGNl ZWQgdGhlIGxpbWl0cyBvZg0KPj50aGVpcg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBU aGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQNCj4+IHVzZQ0KPj4g Pj4gb2YNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90 IGZpZ3VyZSBvdXQgaG93IHRvIHdyaXRlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IGFyY2hpdGVjdHVy YWwgd29yZHMgdG8gcHJvaGliaXQgaXQsIHRoZSBhcmNoaXRlY3R1cmUNCj4+ZG9lcw0KPj4gPj4g Pj4+cGVybWl0DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHN1Y2ggYWJ1c2UuDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcg dGhhdCB0aGUgYXJjaHRpZWN0dXJlDQo+PiBwZXJtaXRzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+IHNv bWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4+ ID4+dGhlDQo+PiA+PiA+Pj53b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwg Q2hhbmdjaGVuZyBIdWFuZyB3cm90ZToNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVk IHRvIHN1cHBvcnQgMTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsDQo+Pm1lYW4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJv dXRpbmcNCj4+dGFibGUNCj4+ID4+b2YgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0 ZXIuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAx OjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhl IGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywgZnJvbQ0KPj4xDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBwYXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhz LiBJIHdvdWxkIGhvcGUNCj4+dGhhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9ycyBh cmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleQ0KPj4gPj5jaG9vc2UNCj4+ ID4+ID4+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBs b2FkIGJhbGFuY2luZyBhbmQgaW4gc3RlYWQNCj4+ID4+IHByb3Zpc2lvbg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+IDE2MCwwMDAgc2VydmljZSBwYXRocy4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1B UklBIEggd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwsDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRlbnRpZmll cnMgdGhlcmUgd2lsbCBiZSBmb3IgYSA0IGhvcA0KPj4gPj4gc2VydmljZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD8NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWENCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmDQo+PiBPZg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQN Cj4+ID4+MzowMw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQTSAqVG86KiBMdWN5IHlvbmcgKkNj Oiogam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz47DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1pa2ViaWFuY0Bhb2wuY29tPG1haWx0bzpt aWtlYmlhbmNAYW9sLmNvbT4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZQ0KPj4gQ2hhaW5z LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE92ZXJhbGwgSSBjb25jdXIs IGFzIHlvdSBzYXk6IGEgcGF0aCBJRCBkcml2ZXMgdGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGZvcndhcmRpbmcuIEnCuWQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZSBtaW5vciBjaGFuZ2U6IHRoZSBwYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVz ZWQgdG8NCj4+ID4+IGRlcml2ZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZv cndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQg cmF0aGVyIGlzIHVzZWQgdG8NCj4+c2ltcGx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50 aWZ5IHRoZSBzZXJ2aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0IHBhY2tldHMNCj4+bXVzdA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmF2ZXJzZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVy LCB0aGUgZXhhY3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5kaXJlY3Rpb24gdGhhdCBwZW9w bGUgc2VlbSB0byBiZSBhc2tpbmcgZm9yIG9uDQo+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRoDQo+PiA+PiBp ZGVudGlmaWVyDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHByb3ZpZGVzIG5vdGhpbmcgbW9yZSB0 aGFuIGEgbG9va3VwLCB0aGF0IGxvb2t1cCBjYW4NCj4+ID4+IHJlc3VsdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbiBhIG9uZSBvciBtb3JlIChlcXVhbCBvciB3ZWlnaHRlZCkgdHJhbnNwb3J0 IG5leHQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1 Y3kgeW9uZw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFp bHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPg0KPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2Vp LmNvbT48bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJTNlPj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gd3JvdGU6DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVl LiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZg0KPj4gdGhlDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRo ZSBmb3J3YXJkaW5nDQo+PiA+PmFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpP biBCZWhhbGYNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTxtYWlsdG86T2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4g Pj4gPj4+ICpTZW50OipUaHVyc2RheSwNCj4+ID4+ID4+PiA+PiBKdWx5DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbTxtYWlsdG86 Km1pa2ViaWFuY0Bhb2wuY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPjtqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzptaWtlYmlhbmNAYW9sLmNv bSUzZTtqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9yZzxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2Zj QGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNlcnZpY2UNCj4+ID4+Q2hhaW5zLA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlLSwNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBkcmFmdCBjYWxscyBv dXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVu dGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvDQo+PmRlcml2ZQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFJlcXVpcmluZyBhIFNGQyBzeXN0ZW0gdG8g aGF2ZSB0aGUgZnVsbCBrbm93bGVkZ2Ugb2YNCj4+ID4+IGV2ZXJ5DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4gYXZhaWxhYmxlIFNGQw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhz IHdpdGhpbiBhbiBTRkMtZW5hYmxlZCBkb21haW4gaXMgbm90DQo+PiA+PiA+Pj4gPj4gPj4+Pj4g cmVxdWlyZWQvanVzdGlmaWVkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBp biB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hvdWxkIHJlbHkg b24gdGhlIHBpZWNlIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4gdGhhdCB3aWxsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJlIHByZXNl bnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+IHJlcXVpcmVkDQo+PiA+ PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBI b3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4gPj51c2VkIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+PiBhY3Rpb25zDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhIHBhcnQNCj4+ID4+ID4+PiA+PiA+Pj4+PiBkZSptaWtl YmlhbmNAYW9sLmNvbTxtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+DQo+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ICpFbnZvecOpIDoqbWVyY3JlZGkg OQ0KPj4gPj4ganVpbGxldA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6 KmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+O3NmY0BpZXRmLm9y ZzxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqT2JqZXQgOipSZTogW3NmY10gU2Vy dmljZQ0KPj4gPj5DaGFpbnMsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gSXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4NCj4+ U0YNCj4+ID4+IENoYWluDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFuZCBTRg0KPj4gPj4gPj4+ ID4+ID4+Pj4+IFBhdGg/DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlm eWluZyB0aGUgZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4+ID4+Y2xlYXIgdG8NCj4+ID4+ID4+ PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0 aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQgZXZlcnlvbmUNCj4+YWdyZWVzDQo+PiA+Pm9uDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0 aWxsIHVuY2xlYXIgaXMNCj4+d2hldGhlcg0KPj4gPj5pdCBpcw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQN Cj4+ID4+dGhlIElEDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIHRoZSBTRkMgSGVhZGVyDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5j ZSAodGhlIGNoYWluIG9yIHRoZSBwYXRoKSwgb3IgaWYgdGhpcyBkcmFmdA0KPj4gPj5zaW1wbHkN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywg YWxsb3dpbmcgb3RoZXINCj4+ZHJhZnRzDQo+PiA+PnRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24gY2hhaW4NCj4+ IG9yDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4g b3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJl IG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4g dGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZSB0aGF0 IGJvdGggU0ZQIGFuZCBTRkMgYmUgc3VwcG9ydGVkIChvciBtYWtlDQo+PiA+PiBvbmUNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZv aWQgc29tZQ0KPj4gdmVuZG9ycw0KPj4gPj4gb25seQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBz dXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4N Cj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+DQo+PiA+Pg0KPj4NCj4+Pj4+Pj4+Pj4+Pj4+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+Pj4+Pj4+Pj4+Pj4tLQ0KPj4gPj4+Pj4+Pj4+Pj4+LS0tDQo+PiA+PiA+Pj4+Pj4+Pj4+LS0N Cj4+ID4+ID4+PiA+Pj4+Pj4+LS0NCj4+ID4+ID4+PiA+PiA+Pj4+Pi0tDQo+PiA+PiA+Pj4gPj4g Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+DQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqam1oQGpvZWxoYWxwZXJu LmNvbTxtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20+PGptaEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPjxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20lM2U+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiAqVG86KnNmY0BpZXRmLm9yZzxtYWlsdG86KnNmY0BpZXRmLm9yZz48c2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxt YWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPjxtYWlsdG86c2ZjQGlldGYub3JnJTNj c2ZjQGlldGYub3JnJTNlPj4NCj4+ICpTZW50OipUdWVzZGF5LA0KPj4gPj4gSnVseQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZA0KPj5Mb2FkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vycw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0 cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseQ0KPj5hbnN3ZXINCj4+ID4+YQ0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFk ZSBhYm91dCB0aGUNCj4+ID4+ID4+PiBwcm9wb3NlZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBt ZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0DQo+PiB3b3JraW5n DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3 ZSB3aWxsIHdvcmsgdG8NCj4+IGltcHJvdmUNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8gaGF2ZSBub3QgcGFydGljaXBhdGVkIGlu DQo+PiA+PnRoZQ0KPj4gPj4gV0cNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiB3 aWxsIHVuZGVyc3RuZCBpdCB0aGUgd2F5IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHdvcmtpbmcN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5kcy4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2UgaW50ZW5kPyBJIHdp bGwgdHJ5IHRvIGV4cGxhaW4gbXkNCj4+ID4+cGVyc29uYWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gdmlldywgYW5kIHNlZSBpZiB0aGF0IGhlbHBzLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRv IGtlZXAgaW4gbWluZCB0aGF0DQo+PiA+PndoYXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug YXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UNCj4+YXJlDQo+ PiA+PiBub3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0ZW1wdGluZyB0byBkZWZpbmUgdGhl IGFyY2hpdGVjdHVyZSBmb3IgdGhlIGVudGlyZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1 dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3MNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gT1NTL0JTUywgdmFyaW91cyBjb250cm9sIGFuZCBwb2xpY3kgZnVuY3Rp b25zLA0KPj52aXJ0dWFsDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hpbmUgYW5kIGltYWdl IG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+PiA+PiBhc3BlY3RzLg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0aGVyZSBhcmUg bWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkDQo+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdCB3aXRo DQo+PiA+PmFib3ZlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoZXJlIHdlIGFyZQ0KPj4gPj4g Pj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgYXJl IG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBhcmUNCj4+IGRvaW5nLg0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiBvcmRlciB0byBn ZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2aWNlIHBhdGgsDQo+PmFzIEkNCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gdW5kZXJzdGFuZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5nLiBU aGVyZSBhcmUgYXQNCj4+ID4+bGVhc3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlm ZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kDQo+PndpbGwNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9i YWJseSBhcmUNCj4+ID4+bW9yZS4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9m IHRoZSBhcmNodGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZg0KPj4gPj50aGVzZSwNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gYnV0IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIg a2luZA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGJlIHVzZWQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g aW4gYW55IHNvbHV0aW9uLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiAxKSBMb2FkIGJhbGFuY2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVu ZA0KPj4gPj51c2VyLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBm dW5jdGlvbi4gSXQgcmVjZWl2ZXMgdXNlcg0KPj5wYWNrZXRzLA0KPj4gPj5hbmQNCj4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4+ID4+ID4+PiA+PiA+Pj4+PiBtYXJr cw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBvciAuLi4pIHNvIGFzIHRvIGNob29zZSBh biBlbmQgdXNlciBzZXJ2aWNlDQo+PiA+Pmluc3RhbmNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvIHJlY2VpdmUgdGhlIHVzZXJzIHBhY2tldC4gVGhpcyBpcyBhbiBpbXBvcnRhbnQNCj4+ID4+ c2VydmljZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGlu Y2x1ZGUgaW4gc2VydmljZSBjaGFpbmluZy4NCj4+ID4+SXQncw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2VydmljZQ0KPj4g Pj4gY2hhaW5pbmcgaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2 ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhlDQo+PiA+PmFyY2h0aWVjdHVyZS4NCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gRnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1w bHkgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZnVuY3Rpb24gd2hpY2ggbWF5IG1vZGlmeSB0aGUgdW5kZXJseWluZyBwYWNrZXQuDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVy bmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUNCj4+Y2FuDQo+PiA+PmhhdmUNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hhdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFz IGEgc2luZ2xlDQo+PnBvaW50DQo+PiA+Pm9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRh Y3QNCj4+ID4+ID4+PiA+PiA+Pj4+PiBmb3IgYQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBzcGVj aWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVsaXZlcmVkDQo+PiA+PmJ5 IGENCj4+ID4+ID4+PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZw0KPj5v bmUgb3INCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2VycyAoZm9y IGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRlY2huaXF1 ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcw0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgZGF0YSBwbGFuZQ0K Pj4gPj5tZWNoYW5pc21zLg0KPj4gPj4gSXQNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGlr ZWx5IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2wNCj4+ID4+bWVjaGFuaXNt cywNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJsZSBmb3Ig c2NhbGUtaW4sIHNjYWxlLW91dCwNCj4+YW5kDQo+PiA+PnZtDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZg0KPj5wZXJtaXR0 aW5nDQo+PiA+PnRoaXMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdl IG5lZWQgdG8gYmUgY2FyZWZ1bCB0aGF0IG91cg0KPj4gPj50ZXJtaW5vbG9neQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGVycyB0 bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDMpIFRoZXJlIGNh biBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkNCj4+c2VsZWN0aW5nDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBk aXJlY3QNCj4+ID4+dHJhZmZpYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byBkaWZmZXJlbnQg cGxhY2VzLiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlDQo+PiB0aGF0DQo+PiA+PmENCj4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25s eSBvbmUgcGxhY2UgaW4NCj4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNv dXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZQ0KPj5jb21iaW5lZC4gSQ0KPj4gPj4gdGVu ZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRv DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQg YXBwZWFyIHRvIHNlcnZpY2UNCj4+ID4+Y2hhaW5pbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g YXMgYSBzaW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyDQo+Pmlz DQo+PiA+PmENCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ29vZCB0ZXJtLiBCdXQgYmVjYXVzZSBJ IGRvIG5vdCBoYXZlIGFub3RoZXIgb25lLg0KPj4gVGh1cywNCj4+ID4+IHRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+ID4+ID4+PiA+ PiA+Pj4+PiBpcyB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1 YnNldHMgb2YgdHJhZmZpYyB0byBkaWZmZXJlbnQNCj4+ID4+c2luZ3VsYXINCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudCBw bGFjZXMNCj4+aW4NCj4+ID4+dGhlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE5vdyB3aXRoIHRo YXQgc2FpZCwgd2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQNCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlz IGENCj4+ID4+IHNlcXVlbmNlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVu Y3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2YNCj4+ID4+cGFja2V0cy4NCj4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgZXF1aXZhbGVudCBvZiBzYXlpbmcgdGhhdCBzb21lIHN1 YnNldCBvZg0KPj50cmFmZmljDQo+PiA+PmlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdl dCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZA0KPj5maXJld2FsbA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMgdG8gZ28gZGly ZWN0bHkgdG8gdGhlDQo+PmNhY2hlDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gd2l0aG91dA0KPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgaXMgbm90 IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlDQo+PnBhY2tldHMuDQo+PiBBDQo+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpcywgaW4gc29tZSBmYXNoaW9uLCBhIHNl cXVlbmNlIG9mDQo+PiA+PmxvY2F0aW9ucw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbiB0aGUg bmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3INCj4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9jYXRpb25z LiBUaGV5DQo+PiA+Pm1heSBiZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZGRyZXNzZWQgYnkg SVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzDQo+PiBwb3J0cw0KPj4gPj4gb24N Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQg d2F5cyB0aGF0IHRoZQ0KPj4gPj5sb2NhdGlvbnMNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWF5 IGJlIGtub3duIHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGluZnJhc3RydWN0dXJlDQo+PiBhbmQN Cj4+ID4+IHRoZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0cmFuc3BvcnQuDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2 aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMNCj4+Z3JvdXAsDQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYmxlIHRv IHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZQ0KPj4gPj5zZXJ2aWNl DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluLCB3aGljaCBkcml2ZXMgdGhlIGZvcndhcmRp bmcuIEFuZCB3ZSBuZWVkIHRvDQo+PiB0YWxrDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFib3V0 IHRoZSBhY3R1YWwgZGF0YSBwYXRoIHBhY2tldHMgd2lsbCB0YWtlIGluIHRoZQ0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQgImJ1dCB0aGUg d2hvbGUNCj4+IHBhdGgNCj4+ID4+IG1heQ0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUg a25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBhcmNoaXRlY3R1cmUgZGVhbHMNCj4+ID4+d2l0aA0K Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwgYXMg bm90ZWQgaW4gaXRlbSAoMikNCj4+b24NCj4+ID4+bG9hZA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5kDQo+PmJlaGF2aW9y cw0KPj4gPj4gd2hpY2gNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXJlIGludmlzaWJsZSB0byB0 aGUgc2VydmljZSBjaGFpbmluZyBtZWNoYW5pc21zIChpbg0KPj4gPj5tdWNoDQo+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBs YXJnZWx5DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdl ZW4gTEFOcy4pIFRoZSBvdGhlcg0KPj4gcHJvdmlzaW9uDQo+PiA+PiB3ZQ0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBtYWtlIGlzDQo+PiA+PiA+Pj4gPj4gPj4+Pj4gdGhhdA0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVu DQo+PiA+PiBuZWNlc3NhcnkuDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoYXQgd2lsbCBkaXJl Y3QgcGFja2V0cyB0byBhIG5ldyBjaGFpbi4gQmFzZWQgb24NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbg0KPj5wb2lu dC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSSBob3Bl IHRoYXQgdGhpcyBoZWxwcyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLg0KPj5JZiBpdA0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxl IHRvIHRoZSB3b3JraW5nDQo+PiA+PiBncm91cCwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug Y2FuIGZpZ3VyZSBvdXQgd2hhdCBhZGRpdGlvbmFsIHdvcmRzIGFyZSBuZWVkZWQNCj4+IHRvDQo+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnZleSB0aGlzLiBJZiB0aGUgd29ya2luZyBncm91cCBk aXNhZ3JlZSB3aXRoIHRoZQ0KPj4gPj4gaW50ZW50LA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0 aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZw0KPj4gPj5n cm91cA0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhZ3JlZW1lbnRzLiBJZiB0aGlzIGlzIHN0aWxs IHVuY2xlYXIsIEkgYW0gbm90IHN1cmUNCj4+ID4+d2hhdCB0bw0KPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0cnkgbmV4dC4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gWW91cnMsIEpvZWwNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+PiBzZmMNCj4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGxpc3Qgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbGlzdCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcN Cj4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHNmYw0KPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4+IGxpc3Qgc2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4gPj4gPj4+ID4+ ID4+Pj4+Pg0KPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjDQo+PiA+PiA+Pj4gbWFpbGluZw0KPj4gPj4gPj4+ ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+ Pj4gPj4gPj4+Pj4+DQo+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+ID4+ID4+ PiBtYWlsaW5nDQo+PiA+PiA+Pj4gPj4gbGlzdA0KPj4gPj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gbWFpbGlu Zw0KPj4gPj4gPj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4gPj4gPj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4gPj4gbWFpbGluZw0KPj4gPj4g Pj4+ID4+IGxpc3QNCj4+ID4+ID4+PiA+PiA+Pj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4g Pj4+ID4+ID4+Pj4NCj4+ID4+ID4+PiA+PiA+Pj4NCj4+ID4+ID4+PiA+PiA+Pg0KPj4gPj4gPj4+ ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gPj4gPj4+ID4+ID4+IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4gPj4+ID4+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4gPj4NCj4+ID4+ID4+PiA+ PiA+DQo+PiA+PiA+Pj4gPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiA+ c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4gPj4gPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiA+PiA+Pj4gPj4NCj4+ID4+ID4+ PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Pj4gPj4+ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+PiA+PiBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+ID4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+PiA+PiA+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PiA+PiA+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+ID4NCj4+ID4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4g PnNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9y Zz4NCj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1h aWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BB01MISOUT7MSGUSRCF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0 IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2Ut MToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3Vu O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBs aS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNp bVN1bjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBw dDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEu MHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJTZWdvZSBVSSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hh cg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1p bHk6U2ltU3VuO30NCnAuYSwgbGkuYSwgZGl2LmENCgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG 5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDp ooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAuSFRNTCwg bGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsN Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLmEwLCBsaS5hMCwgZGl2LmEw DQoJe21zby1zdHlsZS1uYW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pys IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG1l YW5pbmcgb2YgdGhlIFNGUCBJRCBpcyBwcmV0dHkgY2xlYXIsIGF0IGxlYXN0IHRvIG1lIOKAkyBh biBhYnN0cmFjdCBpZGVudGl0eSBmb3IgdGhlIGV4YWN0IHNldCBvZiBzZXJ2aWNlIGZ1bmN0aW9u IGluc3RhbmNlcyAoaS5lLiwgU0ZQIElEIDEgPSB7U0YtQS0xLA0KIFNGLUItMywgU0YtQy0yfSku Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIHNvbWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFi ZWwgc3RhY2vigJ0g4oCTIHRoZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVl bmNlIG9mIG5ldHdvcmsgbG9jYXRpb25zLiZuYnNwOyZuYnNwOyBCdXQsIHRoaXMgYWxzbyBpbXBs aWVzLCBhdCBsZWFzdCB0byBtZSwgdGhhdCB0aGVyZSBpcyBhIGNlbnRyYWwgcG9pbnQgb2Ygc2Vs ZWN0aW9uIGZvciB0aGlzIGVuZCB0byBlbmQgc2VxdWVuY2UgKGJhcnJpbmcNCiByZWNsYXNzaWZp Y2F0aW9uLCBvZiBjb3Vyc2UpLiZuYnNwOyZuYnNwOyBJLCBmb3Igb25lLCBhbSBxdWVzdGlvbmlu ZyB0aGF0IGltcGxpY2F0aW9uLiZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgYmVlbiB1bmNvbWZv cnRhYmxlIHdpdGggdGhhdCBjZW50cmFsIHBvaW50IG1ldGhvZG9sb2d5IGR1ZSB0byByZWFsLXdv cmxkIGNvbXBsZXhpdGllcyBvZiBkeW5hbWljIHNjYWxlIGFuZCB0aW1lbGluZXNzIG9mIHJlYWN0 aW9uIHRvIGZhaWx1cmVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O01hcmlhJmd0OyBJIGFncmVl LiBJdCBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGJ5IHRoZSBTRkMgYXJjaGl0ZWN0dXJlIHRoYXQg c29tZXRoaW5nIGNhbGxlZCDigJxzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggSUTigJ0gaXMgY2Fycmll ZCBpbiB0aGUgcGFja2V0LCBiZWNhdXNlIGl0IGlzDQogbm90IG5lY2Vzc2FyeSBvciB0aGUgb25s eSB3YXkgdG8gaW1wbGVtZW50IHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIG1pZ2h0IHNvbHV0aW9u cyB0aGF0IHdvdWxkIGRvIHRoYXQgYnV0IGl0IGNhbm5vdCBhbmQgZG9lc27igJl0IG5lZWQgdG8g YmUgbWFuZGF0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5TSyZndDsgSSBkaXNhZ3JlZSBvbiB0aGUgJnF1b3Q7bm90IG5lY2Vz c2FyeSZxdW90OyBwYXJ0IGFzIGl0IGxlYWRzIHRvIGEgdmVyeSBpbmVmZmljaWVudCBtZXRob2Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5MZXQncyBwYXJrIGFz aWRlIHRoZSBTRkMgdnMgU0ZQIGRlYmF0ZSBhbmQgc2F5IFNGQz09U0ZQIGZvciB0aGlzIGV4cGxh bmF0aW9uLiBBIGNsYXNzaWZpZXIgbWF5IGRldGVybWluZSBTRlAgSUQgYmFzZWQgb24gYSBub24t dHJpdmlhbCBmdW5jdGlvbiwgbWF5IGJlIGEgRFBJLA0KIGFzIHBhcnQgb2YgaXRzIGNsYXNzaWZp Y2F0aW9uLiBOb3QgY2FycnlpbmcgdGhlIElEIHJlcXVpcmVzIHJlY2xhc3NpZmljYXRpb24gYWZ0 ZXIgZXZlcnkgU0YgaW4gb3JkZXIgdG8ga2VlcCB0aGUgcGFja2V0cyBvbiB0aGUgcmlnaHQgU0ZQ LCBpbiB0aGlzIGNhc2UgYSBEUEkuIEV2ZW4gdGhhdCByZWNsYXNzaWZpY2F0aW9uIG1heSBiZSB0 byBsYXRlIGlmIG9uZSBvZiB0aGUgU0ZzIHRyYW5zZm9ybWVkIHRoZSBwYWNrZXQuJm5ic3A7U28s IHlvdSBkbyBuZWVkDQogYSBTRlAgSUQgZm9yIGNoYWluaW5nIHRvIGJlIHVzZWZ1bC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U0smZ3Q7IEFuZCBmb3IgdGhlIGFyZ3VtZW50 IGFib3V0IG5vdCBuZWVkaW5nIFNGUCBJRCBidXQgb25seSBTRkMgSUQsIGFyY2hpdGVjdHVyZSBk b2VzIG5vdCBwcmV2ZW50IDE6MSBtYXBwaW5nIGJldHdlZW4gdGhlbS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZsdDtNYXJpYSZndDsgVGhpcyBkaXNjdXNzaW9uIGlzIGFib3V0IFNGUCAoYW5k IFNGUCBJRCkgYXMgYSBzcGVjaWZpYywgcHJlLWRlZmluZWQgc2VxdWVuY2Ugb2Ygc2VydmljZSBp bnN0YW5jZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0IFNG UCAoYW5kIGl0cyByZXByZXNlbnRhdGlvbiBpbiB0aGUgcGFja2V0KSBpcyBuZWVkZWQgb25seSB3 aGVuIHRoZSBTRkNzIGFyZSBzdWJqZWN0IHRvIHRyYWZmaWMgZW5naW5lZXJpbmcuIFRyeWluZyB0 byBmaXQgdGhlIFNGUCBpbiB0aGUgZ2VuZXJhbA0KIFNGQyBhcmNoaXRlY3R1cmUsIHdpdGhvdXQg c3RhdGluZyB3aGF0IGl0IGlzIGZvciwgbWFrZXMgaXQgYW4gaW1wb3NzaWJsZSB0YXNrLiA8bzpw Pg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlN1cmVuZHJhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1hcmlhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCBpcyB0byBzdGlsbCB1c2UgY2VudHJh bCBzZWxlY3Rpb24gdG8gc2VsZWN0IHRoZSBjaGFpbiBvZiBhYnN0cmFjdCBzZXJ2aWNlIGZ1bmN0 aW9ucyAoaS5lLiwgU0ZDIElEIDEgPSB7U0YtQSwgU0YtQiwgU0YtQ30pLCBidXQgYWxsb3cNCiB0 aGUgYWN0dWFsIGluc3RhbmNlIHNlbGVjdGlvbiB0byBiZSBkaXN0cmlidXRlZCwgcmVhbGl6ZWQg YnkgdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkZzLiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HaXZlbiBhIHRvcG9sb2d5IGxp a2U6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DbGFz c2lmaWVyIC0tLS0tLS0mbmJzcDsgU0ZGLTEgLS0tLS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTIgLS0t LS0tLS0tLS0tLS0tLS0tLS0gU0ZGLTMtLS0tLS0tLS0tLS0tLS0tLS0tU0ZGLTQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1NGRi1BLTEmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7U0ZGLUEtMiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtT U0YtQi0xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNGRi1CLTIm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U0ZGLUMtMSZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTRkYtQy0yJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNGRi1BLTM8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBhc3N1bWluZyBhIG5ld2x5 IHJlY29nbml6ZWQgZmxvdywgdGhlIHNlcXVlbmNlIGNvdWxkIGdvIHNvbWV0aGluZyBsaWtlIHRo aXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xIENs YXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwgU0YtQiwgU0YtQ308L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+MiBDbGFzc2lmaWVyIHNlbGVjdHMgU0ZGLTEgYXMgaG9zdGluZyBhdCBs ZWFzdCBvbmUgaW5zdGFuY2Ugb2YgU0YtQTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4zIENsYXNzaWZp ZXIgZW5jYXBzdWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2VydmljZSBp bmRleCA9IDE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NCBDbGFzc2lmaWVyIHByb2dyZXNzZXMgcGFj a2V0IHRvIFNGRi0xPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjUgU0ZGLTEsIHNlZWluZyBjaGFpbiBJ RD0xLCBzZXJ2aWNlIGluZGV4PTEsIGNob29zZXMgU0ZGLUEtMiBhbW9uZ3N0IGl0cyBhdmFpbGFi bGUgaW5zdGFuY2VzIG9mIFNGLUE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NiBTRkYtMSBzZW5kcyBw YWNrZXQgdG8gU0ZGLUEtMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj43IFNGRi1BLTEgc2VuZHMgcGFj a2V0IGJhY2sgdG8gU0ZGLTE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+OCBTRkYtMSBpbmNyZW1lbnRz IHNlcnZpY2UgaW5kZXggdG8gMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj44IFNGRi0xIHNlbGVjdHMg U0ZGLTIgYXMgaG9zdGluZyBhdCBsZWFzdCBvbmUgaW5zdGFuY2Ugb2YgU0YtQjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj45IFNGRi0xIHByb2dyZXNzZXMgcGFja2V0IHRvIFNGRi0yPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjEwIHByb2Nlc3MgcmVwZWF0cyBwZXIgYWJvdmUgdW50aWwgU0ZGLTMsIGFzIHRo ZSBlZ3Jlc3MgYm9yZGVyLCBwcm9ncmVzc2VzIHRoZSBwYWNrZXQgcGVyIHJvdXRpbmcgdGFibGU8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgUm9uPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gc2ZjIFs8YSBocmVmPSJtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlh1eGlhb2h1PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVs eSAxMywgMjAxNCAxMTozMCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tIj5taWtlYmlhbmNAYW9sLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpqZ3Vp Y2hhckBjaXNjby5jb20iPg0Kamd1aWNoYXJAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRv Om1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+OyA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJu LmNvbTwvYT47IFJvbiBQYXJrZXI7DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAv L1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFncmVlIHRoYXQgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGluIHRo ZSBhcmNoIGRyYWZ0IGlzIGEgYml0IGNvbmZ1c2luZywganVzdCBhcyB3aGF0IHlvdSBoYWQgcG9p bnRlZCBvdXQuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBteSB1bmRlcnN0YW5k aW5nLCB0aGUgU0ZQIGFzIGFuIGluc3RhbnRpYXRpb24gb2YgYW4gU0ZDIGluIHRoZSBuZXR3b3Jr IHNob3VsZCBiZSDigJxhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBhbmQgU0YgSURz 4oCdKHNlZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Ni4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gtMDE8L2E+KS4gT2YgY291 cnNlLCBob3cgdG8gcmVwcmVzZW50IHRoZSBTRlAgaW4gdGhlIGRhdGEgcGFja2V0IGlzIGFub3Ro ZXIgdGhpbmcgKGUuZy4sIGVpdGhlciB0aHJvdWdoIGEgcGF0aCBpZCBvciB0aHJvdWdoIGFuIE1Q TFMgbGFiZWwgc3RhY2spLiBIZXJlIHRoZSBzZXJ2aWNlIG5vZGUgbWVhbnMgdGhlIGRldmljZSB3 aGljaCBjb250YWlucyB0aGUgU0ZGIGFuZCB0aGUgTkYgY29tcG9uZW50cyBtYW5kYXRvcmlseSB3 aGlsZSBjb250YWluaW5nIHRoZSBTRiBhbmQgU0YgcHJveHkgY29tcG9uZW50cyBvcHRpb25hbGx5 LiBUaGUgc2VydmljZSBub2RlIGNvdWxkIGJlIGF0dGFjaGVkIG9yIGVtYmVkZGVkIHdpdGggbXVs dGlwbGUgU0YgaW5zdGFuY2VzIGFuZCB0aG9zZSBTRiBpbnN0YW5jZXMgY291bGQgYmUgb2YgdGhl IHNhbWUgU0YgdHlwZSBvciBub3QuICZuYnNwO0luIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBt dWx0aXBsZSBTRiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgU0YgdHlwZSAoZS5nLiwgU0YgWCkgYXJl IGF0dGFjaGVkIHRvIGEgZ2l2ZW4gc2VydmljZSBub2RlLCB0aGUgc2VydmljZSBub2RlIGNvdWxk IGRpc3RyaWJ1dGUgdGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBp bnN0YW5jZXMgb2YgU0YgWCB0eXBlIGxvY2FsbHkuIE1lYW53aGlsZSwgdGhlcmUgbWF5IGJlIG11 bHRpcGxlIHNlcnZpY2Ugbm9kZXMgd2l0aGluIGEgZ2l2ZW4gU0ZDLWVuYWJsZWQgZG9tYWluIHdo aWNoIGFyZSBlbWJlZGRlZCBvciBhdHRhY2hlZCB3aXRoIHRoZSBTRiBpbnN0YW5jZXMgb2YgdGhl IHNhbWUgU0YgdHlwZS4gSW4gdGhpcyB3YXksIHRoZSBTRiBsb2FkLWJhbGFuY2luZyB3b3VsZCBi ZSBtYWRlIHZlcnkgZmxleGlibGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJlc3QgcmVnYXJk cyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Y aWFvaHU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJpYW5j QGFvbC5jb208L2E+PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdWx5IDEyLCAyMDE0IDI6 NDYgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20i PmpndWljaGFyQGNpc2NvLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+ DQptbjE5MjFAYXR0LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPg0KUm9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm Y0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5Xb3VsZG4ndCB0aGF0IGJlIGNhbGxlZCB0aGUgJnF1b3Q7c2VydmljZSBjaGFpbiBpZGVu dGlmaWVyJnF1b3Q7IHRoZW4/ICZuYnNwO0lmIHRoZSBzZXJ2aWNlIGNoYWluIGlzIHRoZSBvcmRl cmVkIGxpc3Qgb2YgU0ZzIGFuZCB0aGUgc2VydmljZSBwYXRoIGlzIHRoZSBvcmRlcmVkIGxpc3Qg b2YgU0YgaW5zdGFuY2VzLA0KIHRoZW4gSSB3b3VsZCBpbmZlciB0aGF0IGEgJnF1b3Q7c2Vydmlj ZSBwYXRoIGlkZW50aWZpZXImcXVvdDsgd291bGQgYmUgYW4gaWRlbnRpZmllciBmb3IgYSBzZXJ2 aWNlICpwYXRoKiwgbm90IGEgc2VydmljZSAqY2hhaW4qLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxicj4NCkFnYWluLCBJIHRoaW5rIHRoaXMgaXMgd2hlcmUgdGhlIGNvbmZ1c2lvbiBr ZWVwcyBjcmVlcGluZyBpbi4gJm5ic3A7VGhlIHRlcm1zICZxdW90O2NoYWluJnF1b3Q7IGFuZCAm cXVvdDtwYXRoJnF1b3Q7IHNlZW0gaW5jb25zaXN0ZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbi1i b3R0b206Ni43NXB0Ij4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIi IHN0eWxlPSJjb2xvcjojOTk5OTk5IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PGEgaHJlZj0ibWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFy QGNpc2NvLmNvbSI+amd1aWNoYXJAY2lzY28uY29tJmx0O2pndWljaGFyQGNpc2NvLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20lM2Nt aWtlYmlhbmNAYW9sLmNvbSUzZSxtbjE5MjFAYXR0LmNvbSUzY21uMTkyMUBhdHQuY29tJTNlLG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t JTNlLGptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlLFJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t JTNlLHNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyI+bWlrZWJpYW5jQGFvbC5jb20mbHQ7bWlr ZWJpYW5jQGFvbC5jb20mZ3Q7LG1uMTkyMUBhdHQuY29tJmx0O21uMTkyMUBhdHQuY29tJmd0Oyxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20mZ3Q7LGptaEBqb2VsaGFscGVybi5jb20mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssUm9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSZsdDtSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tJmd0OyxzZmNAaWV0Zi5vcmcmbHQ7c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T ZW50OiA8L2I+RnJpZGF5LCBKdWx5IDExLCAyMDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WW91ciBkZWZpbml0aW9u IG9mIHNlcnZpY2UgcGF0aCBpcyBjb3JyZWN0IGFzIGl0cyB0aGUgZm9yd2FyZGluZyBwYXRoIHRo cm91Z2ggd2hpY2ggdHJhZmZpYyB3aWxsIGFjdHVhbGx5IGZsb3cuIFRoZSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciBob3dldmVyIHBvaW50cw0KIHRvIHRoZSBzZXJ2aWNlIGNoYWluIGRhdGEgc3Ry dWN0dXJlIGFuZCB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgdG8gc3BlY2lmaWMgaW5zdGFuY2VzIGJh c2VkIHVwb24gd2hpY2ggbmV4dC1ob3BzIHRvIHRob3NlIGluc3RhbmNlcyBhcmUgYXZhaWxhYmxl IGFuZCB3aGF0ZXZlciBsb2FkIGRpc3RyaWJ1dGlvbiB0ZWNobmlxdWUgaXMgaW4gcGxheS4gV2hl biBpbnN0YW50aWF0aW5nIHRoZSBzZXJ2aWNlIGNoYWluIGludG8gdGhlIG5ldHdvcmsgeW91IG1h eQ0KIG9yIG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3aGlj aCBuZXh0LWhvcHMgbWF5IGJlIHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxkIGVm ZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aCBmb3IgdGhhdCBzZXJ2aWNlIGNoYWlu KSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVyIHByb3RvY29sIC8gbWVjaGFuaXNt IHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZQ0KIGZvciB5b3UuIDwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjYuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZxdW90OzxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlr ZWJpYW5jQGFvbC5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5 LCBKdWx5IDExLCAyMDE0IGF0IDEyOjE4IFBNPGJyPg0KPGI+VG86IDwvYj5KaW0gR3VpY2hhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW4xOTIxQGF0dC5jb20iPm1uMTkyMUBh dHQuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5 MjFAYXR0LmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVvdDsNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+ Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20iPlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni43NXB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206Ni43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHRo aW5rIHRoaXMgaXMgdGhlIHJvb3Qgb2YgdGhlIGNvbmZ1c2lvbjo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZndDsgSSBkb27igJl0IHdhbnQgdG8gc3BlY2lmeTxicj4NCiZndDsgc3BlY2lmaWMg aW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0aW9uIHRoZXJlb2Yp LiBJPGJyPg0KJmd0OyBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciDigJwxMDDigJ0g dGhhdCBiYXNpY2FsbHkgcG9pbnRzIHRvIFMxLSZndDtTMi0mZ3Q7UzM8YnI+DQomZ3Q7IGFuZCB0 aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48YnI+DQo8YnI+DQpCeSBkZWZpbml0aW9uLCBJIHVuZGVyc3Rvb2QgYSAmcXVvdDtzZXJ2aWNl IHBhdGgmcXVvdDsgdG8gYmUgYW4gb3JkZXJlZCBsaXN0IG9mIHNwZWNpZmljIFNGIGluc3RhbmNl cy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91IHVzZSBhICZxdW90O3NlcnZpY2UgcGF0aCBp ZGVudGlmaWVyJnF1b3Q7IHRvIHJlZmVyIHRvIGEgc2VydmljZSAqY2hhaW4qIHRoYXQgc3BlY2lm aWNhbGx5ICZxdW90O1tkb2VzIG5vdF0gc3BlY2lmeSBzcGVjaWZpYyBpbnN0YW5jZXMmcXVvdDsu PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQiPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8aHIgc2l6ZT0iMSIg d2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiM5OTk5OTkiIGFsaWduPSJjZW50 ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo2Ljc1cHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJtYWlsdG86amd1aWNo YXJAY2lzY28uY29tIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpq Z3VpY2hhckBjaXNjby5jb20iPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86 IDwvYj5OQVBJRVJBTEEsIE1BUklBIEgmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29t Ij5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT4mZ3Q7LEpvZWwgTS4gSGFscGVybiZsdDs8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7LFJvbg0KIFBhcmtl ciZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+RnJpZGF5LCBKdWx5IDEx LCAyMDE0PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0 aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCjxicj4NCk1hcmlhLDxicj4NCjxicj4NCkkgdGhp bmsgb2YgaXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkg YSBwb2ludGVyIHRvPGJyPg0KYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5l eHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdSBkZWZpbmUgYTxicj4NCmNoYWluLCBsZXQ8c3BhbiBs YW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgc2F5IFMxIC0mZ3Q7UzItJmd0OyBTMywgeW91ICptaWdo dCogd2hlbiBjcmVhdGluZyB0aGUgU0ZQIHNwZWNpZnk8YnI+DQp0aGUgc3BlY2lmaWMgbmV4dC1o b3BzIHRoYXQgeW91IHdhbnQgdHJhZmZpYyB0byBmbG93IHRocm91Z2ggZm9yIHRoYXQgU0ZQLjxi cj4NCkhvd2V2ZXIsIHlvdSBkbyAqbm90KiBoYXZlIHRvIGRvIHRoaXMgZnJvbSBhbiBhcmNoaXRl Y3R1cmFsIHN0YW5kcG9pbnQgKEk8YnI+DQp3aWxsIGFyZ3VlIHRoYXQgeW91IHNob3VsZCBidXQg eW91IGRvbjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+dCBoYXZlIHRvIGFyY2hpdGVjdHVy YWxseSkuIFlvdTxicj4NCmNvdWxkIHNpbXBseSBhc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRlbnRp ZmllciB0byBwb2ludCB0byBhIGdpdmVuIFNGQyBhbmQ8YnI+DQp0aGVuIHB1c2ggdGhhdCBpbmZv cm1hdGlvbiBpbnRvIHRoZSBuZXR3b3JrLiBBdCB0aGUgU0ZGIGl0IHdpbGwgaGF2ZSBhPGJyPg0K c2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gU0ZDIG1hcHBpbmcgYW5kIHNhaWQgbWFwcGluZyB3 b3VsZCBjb250YWluIHRoZTxicj4NCm5leHQtaG9wcyBhdmFpbGFibGUgZm9yIGVhY2ggb2YgdGhl IFNGPHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5zIHdpdGhpbiB0aGUgU0ZDIC0gaG93IHlv dSBsZWFybjxicj4NCnRob3NlIG5leHQtaG9wcyBpcyB1cCB0byB5b3UuIFlvdSBjb3VsZCBwdXNo IHRoZW0gZG93biBmcm9tIGEgY2VudHJhbGl6ZWQ8YnI+DQpjb250cm9sbGVyLCBjb25maWd1cmUg dGhlbSB0aHJvdWdoIENMSSwgbGVhcm4gdGhlbSBkeW5hbWljYWxseSB0aHJvdWdoPGJyPg0Kc29t ZSBwcm90b2NvbCBleGNoYW5nZSwgd2hhdGV2ZXIgLi4gU28sIGdpdmVuIHRoaXMgaXQgaXMgbm90 IGNvcnJlY3QgdG88YnI+DQpzYXkgdGhhdCB0aGUgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxs IFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGEgcHJpb3JpPGJyPg0KYWx0aG91Z2ggaXQgaXMgcGVy ZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxkIHNheSByZWNvbW1lbmRlZCkgdG8gZG88 YnI+DQpzby48YnI+DQo8YnI+DQpMZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgdGFr ZSBhbiBleGFtcGxlIHRvIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXI6PGJyPg0KPGJyPg0KSSBk ZWZpbmUgYW4gU0ZDIChsZXQ8c3BhbiBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnMgcmVmZXIgdG8g aXQgYXMgU0ZDLTEpIFMxLSZndDtTMi0mZ3Q7UzMuIEZvciBhcmd1bWVudHM8YnI+DQpzYWtlIGxl dDxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyBzYXkgSSB3YW50IGl0IHRvIGJlIGZ1bGx5 IGR5bmFtaWMgZS5nLiBJIGRvbjxzcGFuIGxhbmc9IlpILUNOIj7igJk8L3NwYW4+dCB3YW50IHRv IHNwZWNpZnk8YnI+DQpzcGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNv bWUgY29tYmluYXRpb24gdGhlcmVvZikuIEk8YnI+DQphc3NpZ24gYSBzZXJ2aWNlIHBhdGggaWRl bnRpZmllciA8c3BhbiBsYW5nPSJaSC1DTiI+4oCcPC9zcGFuPjEwMDxzcGFuIGxhbmc9IlpILUNO Ij7igJ08L3NwYW4+IHRoYXQgYmFzaWNhbGx5IHBvaW50cyB0byBTMS0mZ3Q7UzItJmd0O1MzPGJy Pg0KYW5kIHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsgc28gdGhhdCB0aGUgU0ZGIGRh dGEgc3RydWN0dXJlcyBhcmU8YnI+DQpwb3B1bGF0ZWQgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBO b3cgYXQgYSBnaXZlbiBTRkYsIHdoZW4gdHJhZmZpYyBhcnJpdmVzPGJyPg0Kd2l0aCBzZXJ2aWNl IHBhdGggaWRlbnRpZmllciAxMDAsIHRoZSBTRkYgd2lsbCBsb29rIHRoaXMgdXAgaW4gdGhlIGRh dGE8YnI+DQpzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtJmd0O1MyLSZn dDtTMyBhbmQgdGhlIGluZGV4IGluIHRoZSBTRkM8YnI+DQplbmNhcHN1bGF0aW9uIHdpbGwgdGVs bCBpdCBleGFjdGx5IHdoZXJlIGl0IGlzIGluIHRoZSBjaGFpbi4gTGV0PHNwYW4gbGFuZz0iWkgt Q04iPuKAmTwvc3Bhbj5zIHNheSB3ZTxicj4NCmFyZSBhdCBTMiBpbiB0aGUgY2hhaW4uIFRoZSBT RkYgd2lsbCBub3cgaGF2ZSB0byByZXNvbHZlIHRoZSBuZXh0LWhvcCB0bzxicj4NClMzIGFuZCB3 aWxsIGRvIGEgbG9va3VwIHRvIGRldGVybWluZSB3aGVyZSBTMyBpcyByZWFjaGFibGUuPGJyPg0K PGJyPg0KT24gNy8xMS8xNCwgMTE6MjYgQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtKaW0sPGJyPg0KJmd0Ozxicj4NCiZndDtDb3VsZCB5 b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgJnF1b3Q7c2VydmljZSBwYXRo JnF1b3Q7IGFuZCBhPGJyPg0KJmd0OyZxdW90O3NlcnZpY2UgcGF0aCBpZGVudGlmaWVyJnF1b3Q7 Pzxicj4NCiZndDtJZiBhIHNlcnZpY2UgcGF0aCBtZWFucyB0aGF0IGFsbCBTRiBpbnN0YW5jZXMg YXJlIGNob3NlbiBhcHJpb3JpICh3aGljaDxicj4NCiZndDtpcyBteSBjdXJyZW50IHVuZGVyc3Rh bmRpbmcpIHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoPGJyPg0KJmd0 O25leHQtaG9wIFNGRiB0byBwaWNrLiBJdCBpcyBhIGNlbnRyYWxpemVkIGRlY2lzaW9uLjxicj4N CiZndDs8YnI+DQomZ3Q7TWFyaWE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgPGJyPg0KPGJyPg0KRnJvbTog SmltIEd1aWNoYXJkIChqZ3VpY2hhcikgWzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5j b20iPm1haWx0bzpqZ3VpY2hhckBjaXNjby5jb208L2E+XTxicj4NCiZndDsmZ3Q7IFNlbnQ6IEZy aWRheSwgSnVseSAxMSwgMjAxNCAxMToxNSBBTTxicj4NCiZndDsmZ3Q7IFRvOiBOQVBJRVJBTEEs IE1BUklBIEg7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgSm9lbCBNLjxicj4NCiZndDsmZ3Q7IEhh bHBlcm47IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMs IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJ PHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5tIHNvcnJ5IGJ1dCBJIHJlYWxseSBkb248c3Bh biBsYW5nPSJaSC1DTiI+4oCZPC9zcGFuPnQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllcjxicj4NCiZndDsmZ3Q7IHByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNG IG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyBjaGFp biBpZGVudGlmaWVyIG1ha2VzIGFueSBkaWZmZXJlbmNlPzxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IE9uIDcvMTEvMTQsIDEwOjU4IEFNLCAmcXVvdDtOQVBJRVJBTEEsIE1BUklBIEgmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbjE5MjFAYXR0LmNvbSI+bW4xOTIxQGF0dC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7RGl0dG8uPGJyPg0K Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT5dPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFN PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBOQVBJ RVJBTEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyBSZS0sPGJyPg0KJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmli ZWQgY2xlYXJseSBpbiB0aGU8YnI+DQomZ3Q7Jmd0O2RyYWZ0Ljxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZSBmdWxsPGJyPg0KJmd0OyZndDsgJmd0 OyZndDtkaXN0cmlidXRlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1vZGVsIGlzIG5vdCBhbGxv d2VkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgU2V2ZXJh bCB2b2ljZXMgaW4gdGhpcyB0aHJlYWQgaW5kaWNhdGVkIHRoYXQgdGhlIHNlcnZpY2UgY2hhaW4g aXRzZWxmPGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaG91bGQgYmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBwcm92aWRlZCBpbnN0ZWFkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IE1lZDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0Oy0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtEZSA6IHNmYyBbPGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBEZSBsYSBwYXJ0IGRlIEppbSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsoamd1aWNoYXIpPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O0Vudm95PHNwYW4gbGFuZz0i WkgtQ04iPsOpPC9zcGFuPiA6IHZlbmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxODxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDvDgCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxw ZXJuOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T2JqZXQgOiBSZTogW3NmY10gU2Vy dmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09rIGJ1dCB3aGVyZSBpbiB0aGUg YXJjaGl0ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHk8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAq YWxsKiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZGPHNwYW4gbGFuZz0iWkgtQ04iPuKAmTwvc3Bhbj5z PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O3dpdGhpbiB0aGUgU0ZDIGRvbWFpbiBhbmQgdGhl biBsZXQgdGhlIHBhdGggaWRlbnRpZmllciBwb2ludCB0byBhPGJyPg0KJmd0OyZndDsgJmd0OyZn dDtsb29rdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7aW50byB0aG9zZSBuZXh0LWhvcHMg dG8gcmVhY2ggdGhlIG5leHQgU0YgaW4gdGhlIGNoYWluLCBJIGFtIG5vdDxicj4NCiZndDsmZ3Q7 c3VyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 O3RoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0O09uIDcvMTEvMTQsIDk6NTggQU0sICZxdW90 O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQu Y29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7QWJzb2x1 dGVseS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIEppbSBHdWljaGFyZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyhqZ3Vp Y2hhcik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogRnJpZGF5LCBK dWx5IDExLCAyMDE0IDk6NTQgQU08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg VG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFRoZW4gSSBtaXN1bmRl cnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWU8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQgaWY8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgeW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVtb3Rl IFNGRiBpdDxicj4NCiZndDsmZ3Q7d2lsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dXNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Zm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IGEgZ2l2ZW4gZmxvdyB0byByZWFjaCB0aGUgbmV4dCBTRiB3aXRoaW4gdGhl IGNoYWluIHRoZW4geW91PGJyPg0KJmd0OyZndDtiZXR0ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O21ha2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VyZSB0aGF0IHRoYXQg cmVtb3RlIFNGRiBoYXMgdGhlIG5lY2Vzc2FyeSBmb3J3YXJkaW5nIGxvZ2ljIHRvPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtyZWFjaDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3Ro ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBuZXh0LW5leHQtU0YgZm9yIHRo ZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwIHRyb3VibGUuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IE9uIDcvMTEvMTQsIDk6NDggQU0sICZxdW90O05BUElFUkFMQSwgTUFSSUEgSCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1uMTkyMUBhdHQuY29tIj5tbjE5MjFAYXR0LmNvbTwvYT4mZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDtBYnNvbHV0 ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluPGJyPg0K Jmd0OyZndDtyZWxldmFudDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O1NGRnM8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O3doZW4gdGhleSAmcXVvdDth cnJpdmUmcXVvdDsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg RnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKaW08YnI+DQomZ3Q7Jmd0O0d1 aWNoYXJkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7KGpndWlj aGFyKTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBG cmlkYXksIEp1bHkgMTEsIDIwMTQgOToyNyBBTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENo YWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBXZWxsIEkgdGhpbmsgaXQgaXMgZXZlbiB3b3JzZSB0aGFuIHRoYXQgaWYgSSBoYXZl IHVuZGVyc3Rvb2Q8YnI+DQomZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O3Byb3Bvc2FsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IGNvcnJlY3RseSBhcyBpdCB3b3VsZCByZXF1aXJlIGZ1bGwga25vd2xlZGdl IG9mIGV2ZXJ5IHNpbmdsZTxicj4NCiZndDsmZ3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDt3aXRoaW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgZW50 aXJlIFNGQyBkb21haW4gYXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG88 YnI+DQomZ3Q7Jmd0O2tub3c8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtwcmlvcmk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgd2hpY2ggU0ZDPHNwYW4gbGFuZz0iWkgtQ04iPsK5PC9z cGFuPnMgYSBnaXZlbiBTRkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuPGJyPg0K Jmd0OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDt0aW1lLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBP biA3LzEwLzE0LCAxMTo1MyBQTSwgJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDtSb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6ZWQgYW5vdGhl ciBtYWpvciBwcm9ibGVtPGJyPg0KJmd0OyZndDt3aXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0 aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt5b3VyPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtwcm9wb3NhbCBhcyBJ IHVuZGVyc3RhbmQgaXQuIChBbmQgSSByZWFkaWx5IGFkbWl0IEkgbWF5IG5vdDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3VuZGVyc3RhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O2l0Lik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBzZXJ2ZSBhcyB0aGUg bG9hZCBiYWxhbmNlciBmb3IgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtuZXh0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZXJ2aWNlIGZ1bmN0aW9u IHRoYXQgZm9sbG93cyBpdCAobm90IHRoZSBvbmUgaXQgZGVsaXZlcnM8YnI+DQomZ3Q7Jmd0O3Rv KSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0O3NlcnZpY2UgY2hhaW4gdGhhdCBnb2VzIHRocm91Z2ggaXQuPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O1NpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsg d2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVhbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoYXQ8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtldmVyeTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7U0ZGIHdvdWxkIGhhdmUg dG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2JhbGFuY2VyLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7SSBhaHZlIG5vIHByb2JsZW0gaWYgc29tZSBTRkYg YXJlIGZsb3cgc2Vuc2l0aXZlLCBhbmQgLyBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c3RhdGVm dWwuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtCdXQg aGF2aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmVxdWlyZSB0aGF0IGV2ZXJ5IFNGRiBiZSBhIGZ1bGws PGJyPg0KJmd0OyZndDsgJmd0OyZndDtmbG93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJhbGFuY2VyIHNl ZW1zIHRvIG1lIHRvIGJlIGFuPGJyPg0KJmd0OyZndDsgJmd0OyZndDthY2NlcHRhYmxlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtpbXBvc2l0aW9uLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtZb3Vycyw8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O0pvZWw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7T24gNy8xMC8xNCwgMTA6MDYgUE0sIEpvZWwg TS4gSGFscGVybiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsgUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlp bmcgdG8gbWFrZSB0aGlzPGJyPg0KJmd0OyZndDt3b3JrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2Vuc2libHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBlbnZpcm9u bWVudC4gSSBleHBlY3QgdGhhdCB0aGU8YnI+DQomZ3Q7Jmd0O3NlcnZpY2U8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgZnVuY3Rpb25zLCBhbmQg b3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLDxicj4NCiZndDsmZ3Q7d2ls bDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsgb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhw ZWN0IHRoZSBzZXJ2aWNlIGNoYWluczxicj4NCiZndDsmZ3Q7dG8gYmU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtkcml2ZW4gYnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgQlNTIHRvb2xzIHRoYXQgZGVmaW5l IG9mZmVyaW5ncyB0byBjbGllbnRzLCBhbmQgZW5hYmxlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7c2VsZi1zZWxlY3Rpb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsgZnJvbSB0aGVzZS4gSSBleHBlY3Qgc2VydmljZSBwYXRo cyB0byBiZSBoZWF2aWx5IHBvbGljeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ZHJpdmUuPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IEkgY2FuIHNlZSBo b3cgdG8gbWFrZSBhbGwgb2YgdGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZTxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ZHJpdmVuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Ynk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW5p dGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRocy4gSXQgaXM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhcmRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7c2VlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGhvdyB0 byBtYWtlIGl0IHdvcmsgKGJ1dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGR5bmFtaWNpdHk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgaW4gdGhl IG5ldHdvcmsgYmVoYXZpb3IuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIG1vc3Qgb2YgdGhhdCBwZXJzcGVjdGl2ZSBJ IGRlc2NyaWJlZCBpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b3V0c2lkZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7IHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRo aW5nIHdlIGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGFza2VkIHRvPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7YWdyZWU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDtvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgU28gSSBkbyBub3QgY2xhaW0gdGhhdCB2 aXNpb24gbWVhbnMgd2UgaGF2ZSB0byBkbyBpdCBhPGJyPg0KJmd0OyZndDtjZXJ0YWluPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7d2F5Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IGlzIGp1c3QgdGhlIHBlcnNwZWN0aXZlIHRoYXQgZHJpdmVz IG15IHByZWZlcmVuY2VzLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsgSm9lbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBPbiA3LzEwLzE0LCA5OjU4IFBNLCBJYW4gU21pdGggd3JvdGU6PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Rm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFuY2Vz PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0O25lZWRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDt0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIHdpZGVseSBkaXN0cmlidXRlZCBh bmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZlbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7YWNy b3NzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGF0YTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNlbnRlcnMg d2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2g8YnI+DQomZ3Q7 Jmd0O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjb21wbGV4PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg ZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBh PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ZGlmZmljdWx0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXJjaGl0 ZWN0dXJlIHRvIHJlYWxpemUuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBj b21wbGljYXRlZCB0aGFuPGJyPg0KJmd0OyZndDtkeW5hbWljPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7IHJvdXRpbmcsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBoeXBlci1zY2FsZSBkYXRhIGNlbnRlciBvcmNoZXN0 cmF0aW9uLCBvciBETlMsIGFsbCBvZjxicj4NCiZndDsmZ3Q7d2hpY2g8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O2FyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2Jp Z2dlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5IGltcGxl bWVudGVkPzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGlj YXRlZCwgdGhhdDxicj4NCiZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2E8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtnb29kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBzaWduIHRoYXQgaXQgaXMgdG9vIGNv bXBsaWNhdGVkLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEZy b206IEpvZWwgTS4gSGFscGVybiBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i PmptaEBqb2VsaGFscGVybi5jb208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQg OTo0NSBQTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgVG86IFJvbiBQYXJrZXI7IEpvZWwgSGFscGVybiBEaXJlY3Q7IDxhIGhyZWY9Im1h aWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+DQptaWtlYmlhbmNAYW9sLmNvbTwvYT47PGJyPg0KJmd0 OyZndDtJYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtTbWl0aDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkPGJyPg0KJmd0OyZndDtCYWxhbmNl cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUuIEFuZCBvbmUgdGhhdCBJIHdvdWxk PGJyPg0KJmd0OyZndDtwcmVmZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3dlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FjdHVhbGx5PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBk ZWNpZGUsIHJhdGhlciB0aGFuIHRyeWluZyB0byBhbGxvdyBhbGwgcG9zc2libGU8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0O2ltcGxlbWVudGF0aW9ucy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJlY2F1c2UgaXQgZG9lcyBoYXZlIGEgbWFq b3IgZWZmZWN0IG9uIHRoZSBjb250cm9sPGJyPg0KJmd0OyZndDsgJmd0OyZndDtyZXF1aXJlbWVu dHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBmdW5jdGlvbmFsaXR5IG9mIFNGRnMu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgRm9yIG1lLCB0aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2UgaW5zdGFu Y2VzPGJyPg0KJmd0OyZndDsgJmd0OyZndDt0aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7IG5lZWRzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlhbGx5 IGV2ZW48YnI+DQomZ3Q7Jmd0OyBhY3Jvc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDtkYXRhPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFy Z2UgZW5vdWdoPGJyPg0KJmd0OyZndDthbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDtjb21wbGV4PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyBlbm91Z2ggdGhhdCB0cnlpbmcgdG8gZ2V0IHRoYXQgaW50byBlYWNoIFNG RiBzZWVtcyBsaWtlIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtkaWZmaWN1 bHQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7IGFyY2hpdGVjdHVyZSB0byByZWFsaXplLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IFlvdXJzLDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgSm9lbDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IEJ1dCBpdCBpcyBh IGZhaXIgcXVlc3Rpb24uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgOTozOCBQTSwgUm9uIFBhcmtlciB3cm90ZTo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiBJcyB0aGUgZW5kIHRvIGVuZDxicj4N CiZndDsmZ3Q7c2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDtvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICh0b3AtbGV2 ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0O2NsYXNzaWZpZXIpPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb3Ig aG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vic2VxdWVudGx5PGJy Pg0KJmd0OyZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDtTRkZzKT88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWNoIHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0 byByZWNsYXNzaWZpY2F0aW9uLjxicj4NCiZndDsmZ3Q7QW5kPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7c3VyZWx5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJhbCBpc3N1 ZSBhbmQgbm90IHJlbGVnYXRlZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O2ltcGxlbWVudGF0aW9uJnF1b3Q7Ljxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNo IGV2ZW48YnI+DQomZ3Q7Jmd0OyB0aG91Z2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBhPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Z3JlYXRlciBhbW91bnQgb2YgZGF0YSAoY2hhaW4gZGVmaW5pdGlvbnMgYW5kIHBlcmhhcHM8YnI+ DQomZ3Q7Jmd0O2xvY2FsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7c2VsZWN0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgcG9saWN5KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRl ZCBkZWNpc2lvbiBwb2ludHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDtUaGlzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBwcm9h Y2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8tZW5kIHBhdGggaWQgYXQgYWxsLjxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7TXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByYXRpb25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9h Y2ggaXMgcHJpbWFyaWx5IGRyaXZlbjxicj4NCiZndDsmZ3Q7Ynk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpbmNyZWFzZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXNpbGllbmN5IG92ZXIg dGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGE8YnI+DQomZ3Q7Jmd0O2dsb2JhbDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDtpZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcHJvYWNoLCBjb25zaWRlciBmYWls dXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDth bHRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RoZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGdsb2JhbCBw YXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZDxicj4NCiZndDsmZ3Q7ZW5k LXRvLWVuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3BhdGguPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBSb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g RnJvbTogc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2Zj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IFs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iPmptaC5kaXJl Y3RAam9lbGhhbHBlcm4uY29tPC9hPl0gU2VudDogVGh1cnNkYXksIEp1bHkgMTAsPGJyPg0KJmd0 OyZndDsyMDE0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgNjoxNTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyBQTTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5jQGFv bC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOkkuU21pdGhARjUu Y29tIj4NCkkuU21pdGhARjUuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgUmU6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgdGhlIGFyY2hpdGVjdHVyZSBtb2RlbHMgdGhlIGNhc2Ug b2YgU0YxIG5lZWRpbmc8YnI+DQomZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7aW5mbHVlbmNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNoYWluIGlzIHRoYXQgb25lIHdv dWxkIGRvIHJlY2xhc3NpZmljYXRpb24gYXQgdGhlPGJyPg0KJmd0OyZndDtleGl0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDtmcm9tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU0YxLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUGFydCBvZiB0aGUgZ29hbCBp cyB0byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDts b2dpY2FsbHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNj cmliZSBob3cgdGhleTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGNob29zZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY29tcG9zZSB0aGVtIGZvciAmcXVvdDtzZXJ2 aWNlJnF1b3Q7IGRlbGl2ZXJ5Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDcv MTAvMTQsIDY6MTAgUE0sIDxhIGhyZWY9Im1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSI+bWlrZWJp YW5jQGFvbC5jb208L2E+IHdyb3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0 aGUgYXJjaCBkcmFmdCB0aGF0IHN1Z2dlc3RzIGFueTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7c29y dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O29mPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpbWl0LiBI b3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUgZW50aXJlPGJyPg0KJmd0 OyZndDsgJmd0OyZndDtwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7KGFs bDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTRklzKSBtdXN0IGJlIGNob3NlbiBhdCBTRkMgaW5zdGFudGlhdGlvbi4gSSBi ZWxpZXZlPGJyPg0KJmd0OyZndDt0aGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7bWVhbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJlIHRoZSBj bGFzc2lmaWVyPGJyPg0KJmd0OyZndDtjaG9vc2VzIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O1NG PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYW5kIHRoZSBORiBvciBhdCB0aGUgbGF0ZXN0IHRoZSBmaXJzdCBTRkYuIEluIGFueSBjYXNl LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxhbmd1YWdlIGRvZXMgc2VlbSB0 byBwcm9oaWJpdCBhIG1vcmUgZHluYW1pYyBTRlAgd2hlcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyBTRkkobik8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgaXM8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg ZGV0ZXJtaW5lZCBhdCB0aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWhhdmlvciB3b3VsZCBiZSBjb25z aWRlcmVkICZxdW90O2JyYW5jaGluZyZxdW90OyB0byBhIG5ldyBTRlAgYXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgb3Bwb3NlZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJk aW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBvZjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dGhl PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG5leHQtaG9wIG9mIHRoZSBjdXJyZW50IFNGQy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg ZHJhZnQtbWVyZ2VkLXNmYy1hcmNoaXRlY3R1cmUtMDA6PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaGVuIGFuIFNG QyBpcyBpbnN0YW50aWF0ZWQgaW50byB0aGUgbmV0d29yayBpdCBpczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7bmVjZXNzYXJ5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHNlbGVjdCB0aGUgc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFNGcyB0aGF0IHdpbGwg YmUgdXNlZCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FuZCB0bzxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRl IHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtuZXR3b3JrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsb2NhdG9yLiBUaHVzLCBpbnN0YW50aWF0 aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDtjcmVhdGlvbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGgg KFNGUCkgYW5kIGlzIHVzZWQgZm9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtmb3J3YXJkaW5nPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNG UCBpcyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJl Y2xhc3NpZmljYXRpb24gKG9yPGJyPg0KJmd0OyZndDsgJmd0OyZndDtub24taW5pdGlhbDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFzIHBhY2tldHMgdHJhdmVyc2UgYW4g U0ZQLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkg cGVyZm9ybWVkIGJ5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsYXNzaWZpY2F0aW9uIGZ1bmN0aW9uIGNvLXJl c2lkZW50IHdpdGggYSBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDtmdW5jdGlvbi48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9m IGEgbmV3PGJyPg0KJmd0OyZndDsgJmd0OyZndDtTRlAsIGFuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1cGRhdGUg b2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMgaXM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3JlZmVycmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7dG88 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFzICZxdW90O2JyYW5jaGluZyZxdW90Oy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDstLS08YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICpGcm9tOiA8 YSBocmVmPSJtYWlsdG86KkkuU21pdGhARjUuY29tIj4qSS5TbWl0aEBGNS5jb208L2E+Jmx0Ozxh IGhyZWY9Im1haWx0bzpJLlNtaXRoQEY1LmNvbSI+SS5TbWl0aEBGNS5jb208L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAqVG86ICpKb2VsIEhhbHBlcm48YnI+DQomZ3Q7Jmd0OyBEaXJlY3QmbHQ7PGEgaHJlZj0i bWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJu LmNvbTwvYT4mZ3Q7LEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBNLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDtIYWxwZXJuJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssPGEgaHJlZj0ibWFpbHRvOmh1 YW5nQHNjZS5jYXJsZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPiZsdDs8YSBocmVm PSJtYWlsdG86aHVhbmdAc2NlLiUwYiI+aHVhbmdAc2NlLjxicj4NCjwvYT4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgY2FybGV0b24uPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Y2EmZ3Q7LDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQ8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlN1Ympl Y3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7QmFsYW5jZXJzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFjdHVhbGx5LCBJIHRoaW5r IEkgYW0gZGlzYWdyZWVpbmcuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBwb3NzaWJpbGl0eSBv ZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZDxicj4NCiZndDsmZ3Q7dGhhdCBpczxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3doYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTYgbWlsbGlvbiBm bG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMgaXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtwcmVjb25jZWl2ZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXMgYW4gYWJzdXJkIGlk ZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZCB3aXRoPGJyPg0KJmd0OyZndDsgdGhh dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBwcmVjb25jZXB0aW9uLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBoYXMgdG8g YmUgc29tZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mPGJyPg0KJmd0OyZndDsgJmd0OyZn dDthc3BpcmF0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2NhbGUgdGhh dCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFuIG9mIHRoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7YXJjaGl0ZWN0dXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7LTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB5b3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcg dGhhdCBhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O2FyYml0cmFyeTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBudW1iZXIgaXMgJnF1b3Q7dG9vIGZhciZxdW90OywgeW91J3JlIGNyZWF0aW5nIC0gZXZl biBpZiBpdCBpc24ndDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 O2ludGVudGlvbmFsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25z IHRoYXQgaGF2ZSBsYXN0aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDtpbXBhY3RzPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2FkZHJlc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BhY2UuLi4gYWxsIGtpbmRzIG9m IHRoaW5ncy4gVGhhdCBpcyBhIHByb2JsZW0gSSdtIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXJ0aWN1bGFybHkg ZWFnZXIgdG8gZGVhbCB3aXRoLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgWzxhIGhyZWY9Im1h aWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSI+am1oLmRpcmVjdEBqb2VsaGFscGVybi5j b208L2E+XTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7U2VudDo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgNTowNCBQTSBUbzogSWFuIFNtaXRoOyBKb2VsIE0uPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgSGFscGVybjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmh1YW5nQHNjZS5jYXJs ZXRvbi5jYSI+aHVhbmdAc2NlLmNhcmxldG9uLmNhPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gU3ViamVjdDogUmU6IFtzZmNdPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtTZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFu Y2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJYW4sIEkgZG9uJ3QgdGhpbmsgeW91IGRpc2FncmVlIHdp dGggbWUgYXQgYWxsIGluIHRoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3JlZ2FyZC48YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7YW08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNo aXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDtwcm9oaWJpdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBkZXBsb3ltZW50cyBpbiB0aGUgc3BlY2lmaWMgZmFzaGlvbi4gSSBhbSBvYmplY3Rp bmcgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0h1YW5nJ3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhZGluZyBvZiBt eSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVudHMgYXJlPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgcmVxdWlyZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhleSBieSB0aGUgYXJjaHRpZWN0dXJlLjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBBcyBJIGhhdmUgc2FpZCByZXBlYXRlZGx5LCBJIGFtIG5vdCB0cnlpbmcg dG8gcHJvaGliaXQ8YnI+DQomZ3Q7Jmd0O3N1Y2g8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhpbmdzLiBXaGV0aGVyIHRo ZXkgYXJlIGEgZ29vZCBpZGVhIG9yIG5vdCBkZXBlbmRzIHVwb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyBtYW55PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhY3RvcnMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhlIFdH LiBJIGhhcHBlbiB0bzxicj4NCiZndDsmZ3Q7dGhpbms8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3Ro YXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDt0aGV5PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCB0aGUgYXJj aHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvPGJyPg0KJmd0OyZn dDsgJmd0OyZndDtrbm93PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7d2hhdDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMs IEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdy b3RlOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSBkaXNhZ3JlZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBX ZSByb3V0aW5lbHkgaGF2ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2Y8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDttaWxsaW9uczxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2Y8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY29uY3VycmVudCBmbG93cyBpbiBib3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRh IGNlbnRlcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkg YmVsaWV2ZSB0aGF0IGluPGJyPg0KJmd0OyZndDt0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2xvdWQvSVB2Ni9Nb2Jp bGl0eS9XZWIyLjAvSW9UIHdvcmxkIG9mIHRvbW9ycm93IHlvdTxicj4NCiZndDsmZ3Q7IGFyZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG9ubHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgZ29pbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNl cnZpY2UgY2hhaW5zIHdpdGggZXF1YWxseTxicj4NCiZndDsmZ3Q7c21hbGw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbnVtYmVyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBhY3RpdmUgc2Vydmlj ZSBwYXRocz88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VyIHNvdW5kcyB0b28gbXVjaCBs aWtlICZxdW90O25vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlPGJyPg0KJmd0OyZndDsgdGhhbjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA2NEsmcXVvdDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGZvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBjb21mb3J0Ljxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEZyb206IHNmYzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNv bTwvYT5dPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBN IFRvOjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OzxhIGhyZWY9Im1haWx0bzpo dWFuZ0BzY2UuY2FybGV0b24uY2EiPmh1YW5nQHNjZS5jYXJsZXRvbi5jYTwvYT47PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsPGJyPg0KJmd0OyZndDthbmQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCYWxhbmNl cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29t ZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7YXJjaHRpZXR1cmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcnRpY3VsYXJseSBiYWRseSwgdGhleSB3aWxs IGV4Y2VlZCB0aGUgbGltaXRzIG9mPGJyPg0KJmd0OyZndDt0aGVpcjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV2 aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1Y2ggYWJzdXJkPGJyPg0K Jmd0OyZndDsgdXNlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcnZp Y2UgcGF0aHMuIFNpbmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVy ZTxicj4NCiZndDsmZ3Q7ZG9lczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3Bl cm1pdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc3VjaCBhYnVzZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQ bGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVjdHVyZTxicj4NCiZn dDsmZ3Q7IHBlcm1pdHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbWV0aGluZyBhcyBzYXlpbmcgaXQgaXMgZWl0 aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3dvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpc24n dC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3VycywgSm9lbDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3JvdGU6PGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2VydmljZSBjaGFpbnMs IGl0IHdpbGw8YnI+DQomZ3Q7Jmd0O21lYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxNiwwMDAsMDAwIHBh dGhzLiBUaGF0IGlzIGxhcmdlciB0aGFuIHRoZSByb3V0aW5nPGJyPg0KJmd0OyZndDt0YWJsZTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2YgYTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcmUgcm91dGVyLjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hhbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGFyY2hpdGVjdHVyZSBhbGxvd3MgYSByYW5n ZSBvZiBkZXBsb3ltZW50cywgZnJvbTxicj4NCiZndDsmZ3Q7MTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2UgcGF0aHMuIEkgd291bGQgaG9wZTxicj4N CiZndDsmZ3Q7dGhhdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvcGVyYXRvcnMgYXJlIHByZXBhcmVk IGZvciB0aGUgY29tcGxleGl0aWVzIGlmIHRoZXk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Nob29z ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0O3RvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgcHJvdmlzaW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE2MCww MDAgc2VydmljZSBwYXRocy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg T24gNy8xMC8xNCwgNDowNiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOjxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgUGF1bCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBIb3cgbWFueSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9y IGEgNCBob3A8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZXJ2aWNlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBjaGFpbiB3aXRoIDIwIGluc3RhbmNlcyBhdCBlYWNoIGhvcD88YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJpYTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9 Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0gKk9uIEJlaGFsZjxicj4NCiZndDsmZ3Q7IE9mPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OzM6MDM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBNICpUbzoq IEx1Y3kgeW9uZyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+DQpq bWhAam9lbGhhbHBlcm4uY29tPC9hPjs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT47PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bWlrZWJpYW5j QGFvbC5jb20iPm1pa2ViaWFuY0Bhb2wuY29tPC9hPiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2 aWNlPGJyPg0KJmd0OyZndDsgQ2hhaW5zLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMs IGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEx1Y3ksPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElEIGRyaXZl cyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcuIEk8c3BhbiBsYW5nPSJa SC1DTiI+wrk8L3NwYW4+ZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgZGVyaXZlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgbmVl ZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQgdHJhbnNwb3J0Ljxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3Bv cnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0bzxicj4NCiZndDsmZ3Q7c2ltcGx5PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBpZGVudGlmeSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBw YWNrZXRzPGJyPg0KJmd0OyZndDttdXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cmF2ZXJz ZS4gQnkgaGF2aW5nIGEgcGF0aCBpZGVudGlmaWVyLCB0aGUgZXhhY3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxlIHNlZW0gdG8gYmUgYXNraW5nIGZvciBv bjxicj4NCiZndDsmZ3Q7dGhpczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWFkIGNhbiBi ZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg aWRlbnRpZmllcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZXMgbm90aGluZyBtb3Jl IHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHJl c3VsdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Ig d2VpZ2h0ZWQpIHRyYW5zcG9ydCBuZXh0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBob3Aocyku PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF1bDxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEp1bCAx MCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdl aS5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWN5 LnlvbmdAaHVhd2VpLmNvbSUzZSI+bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tJmd0OzwvYT4m Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFncmVlLiBUaGUgYXJjaC4gZG9jIHNob3VsZCBub3QgbWFu ZGF0ZSBvbmx5IHVzZSBvZjxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gZHJpdmUgdGhlIGZvcndhcmRpbmc8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2FjdGlvbnMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgTHVjeTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICpGcm9tOipzZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10qT24iPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10qT248L2E+IEJlaGFsZjxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOk9mKm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20iPk9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iPm1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgKlNlbnQ6KlRodXJzZGF5LDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBKdWx5PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAxMCwgMjAxNCAyOjA2IEFNICpUbzo8YSBocmVmPSJtYWlsdG86Km1pa2Vi aWFuY0Bhb2wuY29tIj4qbWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNlO2ptaEBqb2VsaGFs cGVybi5jb20iPm1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSZndDs7am1oQGpvZWxoYWxwZXJuLmNv bTwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0Zi5vcmciPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Jmd0OztzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7ICpTdWJq ZWN0OipSZTogW3NmY10gU2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Q2hhaW5zLDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vyczxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlLSw8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgbWVyZ2VkIGRyYWZ0IGNh bGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpZGVudGlmaWVyLiBJIG9iamVjdCB0byB1c2UgdGhhdCBpZGVudGlmaWVyIHRvPGJyPg0KJmd0 OyZndDtkZXJpdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZvcndhcmRpbmcgYWN0aW9ucy48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZXF1aXJp bmcgYSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgZXZlcnk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXZhaWxhYmxlIFNGQzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZm9yd2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlz IG5vdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZXF1aXJlZC9qdXN0aWZpZWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG5vciBwb3NzaWJsZSBpbiB2YXJpb3VzIGRlcGxveW1lbnQgY29udGV4dHMuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0ZDIGZvcndhcmRpbmcgYWN0 aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ugb2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGluZm9ybWF0aW9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgd2lsbDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVudHM6IHRoYXQgaXMgdGhlIG9uZTxicj4NCiZndDsm Z3Q7IHJlcXVpcmVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hhaW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlz PGJyPg0KJmd0OyZndDsgJmd0OyZndDt1c2VkIHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp bmZlciBmb3J3YXJkaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFjdGlvbnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGlzIGEgc29sdXRpb24tb3JpZW50ZWQgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWVkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkRlIDoqc2ZjIFs8YSBocmVmPSJtYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddKkRlIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKkRlPC9h PiBsYSBwYXJ0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZSptaWtlYmlhbmNAYW9sLmNvbSI+ ZGUqbWlrZWJpYW5jQGFvbC5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tIj5tYWlsdG86bWlrZWJpYW5jQGFvbC5jb208 L2E+Jmd0OyAqRW52b3k8c3BhbiBsYW5nPSJaSC1DTiI+w6k8L3NwYW4+IDoqbWVyY3JlZGkgOTxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGp1aWxsZXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIw MTQgMjI6MDMgKsOAIDo8YSBocmVmPSJtYWlsdG86KmptaEBqb2VsaGFscGVybi5jb20iPipqbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZyI+bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20mZ3Q7O3NmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5tYWlsdG86c2ZjQGlldGYub3Jn PC9hPiZndDsgKk9iamV0IDoqUmU6IFtzZmNdIFNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O0NoYWlucyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJcyBh bnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbjxicj4NCiZndDsm Z3Q7U0Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBDaGFpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYW5kIFNGPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdGg/PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlciB0 aGFuIGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdCBpdCdzPGJyPg0KJmd0OyZndDsg Jmd0OyZndDtjbGVhciB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZhbWlsaWFyIHdpdGggdGhlIGRyYWZ0LCBpdCBzZWVtcyB0aGF0IGV2ZXJ5b25lPGJyPg0K Jmd0OyZndDthZ3JlZXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O29uPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0aGVzZSB0ZXJtcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIg aXM8YnI+DQomZ3Q7Jmd0O3doZXRoZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2l0IGlzPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0aW1hdGVs eSBzcGVjaWZ5IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZSBJRDxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgb2YgdGhlIFNGQyBIZWFkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2hvdWxkPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRo aXMgZHJhZnQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3NpbXBseTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgaW50ZW5kcyB0byBsZWF2ZSB0aGF0IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXI8YnI+ DQomZ3Q7Jmd0O2RyYWZ0czxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7dG88YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGRpY3RhdGUgdGhlIG1lY2hhbmlzbXMgZm9yIGZvcndhcmRpbmcgYmFzZWQgb24g Y2hhaW48YnI+DQomZ3Q7Jmd0OyBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGF0aCBhbmQg dGhlIGNob2ljZSBvZiBjaGFpbiBvcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYXRoIHRvPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiZSBuZWdvdGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElmIHRoZSBsYXR0ZXIgKGFtYmln dW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBhbmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7IG9uZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQg YW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZTxicj4NCiZndDsmZ3Q7IHZlbmRv cnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbmx5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz dXBwb3J0aW5nIFNGUCBhbmQgb3RoZXJzIG9ubHkgc3VwcG9ydGluZyBTRkMuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDstLS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LS08YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKkZyb206PGEgaHJlZj0ibWFpbHRvOipqbWhAam9lbGhhbHBlcm4uY29tIj4qam1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i PmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUz Y2ptaEBqb2VsaGFscGVybi5jb20lM2UiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNjam1o QGpvZWxoYWxwZXJuLmNvbSZndDs8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRv OjxhIGhyZWY9Im1haWx0bzoqc2ZjQGlldGYub3JnIj4qc2ZjQGlldGYub3JnPC9hPiZsdDs8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9y ZyUzZSI+bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyZndDs8L2E+Jmd0Ozxicj4N CiZndDsmZ3Q7ICpTZW50OipUdWVzZGF5LDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IEp1bHk8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDgsIDIwMTQgKlN1YmplY3Q6KltzZmNdIFNlcnZpY2UgQ2hh aW5zLCBQYXRocywgYW5kPGJyPg0KJmd0OyZndDtMb2FkPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBCYWxhbmNlcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseTxicj4N CiZndDsmZ3Q7YW5zd2VyPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBudW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZSBhYm91dCB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcHJvcG9zZWQ8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG1lcmdlZCBhcmNodGllY3R1cmUgZHJhZnQuIEFzc3VtaW5nIHdlIGNhbiBn ZXQ8YnI+DQomZ3Q7Jmd0OyB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBncm91cCBh Z3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvPGJyPg0KJmd0OyZndDsgaW1w cm92ZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg d29yZGluZyBzbyB0aGF0IHJlYWRlcnMgd2hvIGhhdmUgbm90IHBhcnRpY2lwYXRlZCBpbjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgV0c8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGRpc2N1c3Npb24gd2lsbCB1bmRlcnN0bmQgaXQgdGhlIHdheSB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgaW50ZW5kcy48 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgd2hh dCBkbyB3ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7cGVyc29uYWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZpZXcsIGFuZCBzZWUgaWYg dGhhdCBoZWxwcy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJbiB0aGlzIHJlZ2FyZCwgaXQgaXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0 PGJyPg0KJmd0OyZndDsgJmd0OyZndDt3aGF0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBh cmUgZGVmaW5pbmcgaXMgdGhlIGRhdGEgcGxhbmUgYXJjaGl0ZWN0dXJlLiBXZTxicj4NCiZndDsm Z3Q7YXJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbm90PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0ZWN0dXJlIGZvciB0aGUgZW50aXJlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhh dCB3b3VsZCBlbmNvbXBhc3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9TUy9CU1MsIHZhcmlv dXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucyw8YnI+DQomZ3Q7Jmd0O3ZpcnR1YWw8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hY2hpbmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBt YW55IG90aGVyPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgYXNwZWN0cy48YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCB0aGVyZSBhcmUg bWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkPGJyPg0KJmd0OyZndDsgdG88YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lzdGVtLCBidXQgd2hpY2ggYXJl IGRlYWx0IHdpdGg8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2Fib3ZlPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3aGVyZSB3ZSBhcmU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25pbmcsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3ZSBh cmU8YnI+DQomZ3Q7Jmd0OyBkb2luZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBvcmRlciB0byBnZXQgdG8gc2VydmljZSBjaGFpbiB2cyBzZXJ2 aWNlIHBhdGgsPGJyPg0KJmd0OyZndDthcyBJPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRl cnN0YW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG5lZWQgdG8g Zmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4gVGhlcmUgYXJlIGF0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDtsZWFzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhyZWUgZGlmZmVyZW50IHdh eXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kPGJyPg0KJmd0OyZndDt3aWxsPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcmFjdCB3aXRoIHNlcnZpY2UgY2hhaW5pbmcuIFRoZXJlIHBy b2JhYmx5IGFyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bW9yZS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBwb2ludCBvZiB0aGUgYXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2Y8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoZXNlLDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnV0 IG5vdCB0byBtYW5kYXRlIHRoYXQgYW55IHBhcnRpY3VsYXIga2luZDxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSB1c2Vk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBhbnkgc29sdXRpb24uPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMSkgTG9hZCBiYWxhbmNpbmcgYXMg YSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3VzZXIu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlvbi4gSXQg cmVjZWl2ZXMgdXNlcjxicj4NCiZndDsmZ3Q7cGFja2V0cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 O2FuZDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kaWZpZXMgdGhlbSAob3I8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg bWFya3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0sIG9yIC4uLikgc28gYXMgdG8gY2hv b3NlIGFuIGVuZCB1c2VyIHNlcnZpY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2luc3RhbmNlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byByZWNlaXZlIHRoZSB1c2VycyBwYWNrZXQuIFRoaXMg aXMgYW4gaW1wb3J0YW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzZXJ2aWNlPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBj aGFpbmluZy48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O0l0J3M8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGJlaGF2aW9yIG1heSBhZmZlY3QgcmVxdWlyZW1lbnRzIG9uIGhvdyBzZXJ2aWNlPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgY2hhaW5pbmcgaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRv bmUuIEJ1dCBpdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIHRoZTxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7YXJjaHRpZWN0dXJlLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBhbiBhcmNo aXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkgYTxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2aWNlPGJy Pg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRl cmx5aW5nIHBhY2tldC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAyKSBUaGVyZSBpcyBpbnRlcm5hbCBsb2FkIGJhbGFuY2luZy4gVGhhdCBpcywgb25l PGJyPg0KJmd0OyZndDtjYW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2hhdmU8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHdoYXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIGFzIGEgc2luZ2xlPGJyPg0K Jmd0OyZndDtwb2ludDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7b2Y8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNvbnRhY3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9yIGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNw ZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBpcyBhY3R1YWxseSBkZWxpdmVyZWQ8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0O2J5IGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29sbGVjdGlvbiBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywgcG9zc2libHkgaW5jbHVk aW5nPGJyPg0KJmd0OyZndDtvbmUgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldmVyYWwg bG9hZCBiYWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZTxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LCB0 aGlzIGlzPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2Ug Y2hhaW5pbmcgZGF0YSBwbGFuZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWVjaGFuaXNtcy48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbGlrZWx5 IHRoYXQgaXQgaXMgdmlzaWJsZSB0byB2YXJpb3VzIGNvbnRyb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0O21lY2hhbmlzbXMsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIHRob3NlIHJl c3BvbnNpYmxlIGZvciBzY2FsZS1pbiwgc2NhbGUtb3V0LCA8YnI+DQomZ3Q7Jmd0O2FuZDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7dm08YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbnRpYXRp b24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiA8YnI+DQomZ3Q7Jmd0O3Blcm1pdHRpbmc8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O3RoaXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGxh cmdlbHkgdGhhdCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXI8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0O3Rlcm1pbm9sb2d5PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBsZWFk PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHJlYWRlcnMgdG88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIHdlIGFy ZSBwcm9oaWJpdGluZyBpdC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAzKSBUaGVyZSBjYW4gYWxzbyBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IDxi cj4NCiZndDsmZ3Q7c2VsZWN0aW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGF0 aHMgZm9yIHRoZSBzZXJ2aWNlIGNoYWluaW5nIHRoYXQgZGlyZWN0PGJyPg0KJmd0OyZndDsgJmd0 OyZndDt0cmFmZmljPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byBkaWZmZXJlbnQgcGxhY2Vz LiBXZSB3b3VsZCBub3Qgd2FudCB0byByZXF1aXJlPGJyPg0KJmd0OyZndDsgdGhhdDxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7YTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZ2l2ZW4gc2VydmljZSBm dW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gPGJyPg0KJmd0OyZndDt0aGU8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgaXMgb2YgY291cnNlIHRoZSBjYXNlIHRoYXQgdGhl c2UgbWF5IGJlIDxicj4NCiZndDsmZ3Q7Y29tYmluZWQuIEk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyB0ZW5kPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZlciB0bzxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGNvbGxlY3Rpb24gb2YgZW50aXRpZXMgdGhhdCBhcHBl YXIgdG8gc2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Y2hhaW5pbmc8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFzIGEgc2luZ2xlIHBvaW50IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2Ug Y2x1c3RlciA8YnI+DQomZ3Q7Jmd0O2lzPGJyPg0KJmd0OyZndDsgJmd0OyZndDthPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUgYW5v dGhlciBvbmUuPGJyPg0KJmd0OyZndDsgVGh1cyw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IG9mIHR5cGUgMyBsb2FkIGJhbGFuY2luZzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBpcyB0bzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlyZWN0IGRpZmZlcmVudCBz dWJzZXRzIG9mIHRyYWZmaWMgdG8gZGlmZmVyZW50PGJyPg0KJmd0OyZndDsgJmd0OyZndDtzaW5n dWxhcjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rp b25zIGluIGRpZmZlcmVudCBwbGFjZXMgPGJyPg0KJmd0OyZndDtpbjxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7dGhlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdyB3aXRoIHRoYXQgc2FpZCwg d2hhdCBkbyBJIG1lYW4gd2hlbiBJIHRhbGsgYWJvdXQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNlcnZpY2UgY2hhaW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbiBpcyBhPGJyPg0K Jmd0OyZndDsgJmd0OyZndDsgc2VxdWVuY2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGxv Z2ljYWwgZnVuY3Rpb25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQgb2Y8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0O3BhY2tldHMuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBlcXVpdmFs ZW50IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIDxicj4NCiZndDsmZ3Q7dHJhZmZpYzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7aXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGdldCBE UEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCA8YnI+DQomZ3Q7Jmd0O2ZpcmV3 YWxsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGlsZSBhIGRpZmZlcmVudCBzdWJzZXQgaXMg dG8gZ28gZGlyZWN0bHkgdG8gdGhlIDxicj4NCiZndDsmZ3Q7Y2FjaGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aG91 dDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVu Y3Rpb25zLjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoYXQgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiB0byBkaXJlY3QgdGhlIDxicj4NCiZndDsm Z3Q7cGFja2V0cy48YnI+DQomZ3Q7Jmd0OyBBPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXJ2 aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZjxicj4NCiZndDsmZ3Q7 ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgbmV0d29y ay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2luZ3VsYXIgb3I8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNsdXN0ZXJlZCBzZXJ2aWNlIGZ1bmN0aW9uIGRlbGl2ZXJ5IGxvY2F0aW9ucy4gVGhl eTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bWF5IGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh ZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzPGJyPg0KJmd0 OyZndDsgcG9ydHM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW4gU0ZGLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZTxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7bG9jYXRpb25zPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkg YmUga25vd24gdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmU8YnI+DQomZ3Q7 Jmd0OyBhbmQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRyYW5zcG9ydC48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgd29yayBvZiB0aGUgU0ZD IDxicj4NCiZndDsmZ3Q7Z3JvdXAsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgd2U8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkIHRvIGJlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh YmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRoZTxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7c2VydmljZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhaW4sIHdo aWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlIG5lZWQgdG88YnI+DQomZ3Q7Jmd0OyB0 YWxrPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0aCBw YWNrZXRzIHdpbGwgdGFrZSBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsu PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2V2ZXJh bCBvZiB0aGUgY29tbWVudHMgaGF2ZSBzYWlkICZxdW90O2J1dCB0aGUgd2hvbGU8YnI+DQomZ3Q7 Jmd0OyBwYXRoPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWF5PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiZxdW90OyBUaGlzIGFyY2hpdGVjdHVyZSBk ZWFsczxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2l0aDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGhhdCBpc3N1ZSBpbiB0d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIDxicj4N CiZndDsmZ3Q7b248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0O2xvYWQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGJhbGFuY2VycyBhYm92ZSwgdGhlcmUgY2FuIGJlIGRlY2lzaW9ucyBhbmQgPGJyPg0K Jmd0OyZndDtiZWhhdmlvcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyB3aGljaDxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYXJlIGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBtZWNo YW5pc21zIChpbjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7bXVjaDxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlIHNhbWUgd2F5IHRoYXQgYnJpZGdpbmcgd2l0aGluIGEgTEFOIGlzIGxhcmdlbHk8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludmlzaWJsZSB0byByb3V0aW5nIGJldHdlZW4gTEFO cy4pIFRoZSBvdGhlcjxicj4NCiZndDsmZ3Q7IHByb3Zpc2lvbjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7IHdlPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlIGlzPGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlY2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlk LWNoYWluIHdoZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBuZWNlc3NhcnkuPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBuZXcgY2hhaW4uIEJh c2VkIG9uPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgYXQg dGhlIHJlLWNsYXNzaWZpY2F0aW9uIDxicj4NCiZndDsmZ3Q7cG9pbnQuPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBob3BlIHRoYXQgdGhpcyBoZWxw cyBleHBsYWluIHdoYXQgd2UgYXJlIGFmdGVyLiA8YnI+DQomZ3Q7Jmd0O0lmIGl0PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRv IHRoZSB3b3JraW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgZ3JvdXAsPGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlIG5l ZWRlZDxicj4NCiZndDsmZ3Q7IHRvPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7 ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb252ZXkgdGhp cy4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyBpbnRlbnQsPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVuIHdlIHdpbGwgb2Yg Y291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 Z3JvdXA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3Rp bGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZTxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7d2hhdCB0bzxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJ5IG5leHQuPGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+ bWFpbHRvOnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBtYWlsaW5n PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPm1h aWx0bzpzZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7IHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7Jmd0OyBtYWlsaW5nPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h Pjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgbWFpbGluZzxicj4NCiZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gc2ZjPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgbWFpbGluZzxicj4NCiZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBsaXN0PGJyPg0KJmd0OyZndDsg Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIHNmYzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IG1haWxp bmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgbGlzdDxicj4N CiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsg Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8 L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7Jmd0OyZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0 OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsgJmd0OyZndDsgJmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7ICZndDtzZmMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsgJmd0OyZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4BB01MISOUT7MSGUSRCF_-- From nobody Mon Jul 14 12:52:28 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C401A00A8 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:52:25 -0700 (PDT) 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 lLM3O1HVyAFD for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:52:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817DB1A00A3 for <sfc@ietf.org>; Mon, 14 Jul 2014 12:52:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6009524731E; Mon, 14 Jul 2014 12:52:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9508B24731D; Mon, 14 Jul 2014 12:52:21 -0700 (PDT) Message-ID: <53C434F4.7050208@joelhalpern.com> Date: Mon, 14 Jul 2014 15:52:20 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Taylor <tom.taylor.stds@gmail.com>, sfc@ietf.org, Ron Parker <Ron_Parker@affirmednetworks.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> In-Reply-To: <53C4235D.5010701@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/drSZpAcAXFWvLR3nWdrYTRnrnBA Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 19:52:25 -0000 The most likely realization of the architecture would be that the SFP assignment is recorded in an identifier which travels with the packet. Some folks seem to not want the architecture to mandate that. Yours, Joel On 7/14/14, 2:37 PM, Tom Taylor wrote: > Your text scares me because it introduces some new concepts and > assumptions. > > I'd rather go with Joel's formulation. Clarifying question on that: am I > right in seeing the implication that when control assigns an SFP, the > assignment is recorded by an identifier wwhich travels with the packet? > > Tom Taylor > > On 14/07/2014 2:22 PM, Ron Parker wrote: >> There is one missing word in my text. Please replace my proposed text >> with: >> >> “The Service Function Chain (SFC) provides a fully abstract view of the >> service functions to be invoked and the order in which they are to be >> invoked for some particular flow or set of flows, without concern of >> actual service function instance selection. The Constrained-SFC >> (C-SFC) further allows for policy constraints to be added to the SFC >> affecting the instance selection of one or more of the service functions >> in the SFC. Any SFC may have any number of C-SFC’s associated with it.” >> >> Thanks. >> >> Ron > ... > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >> *Sent:* Monday, July 14, 2014 2:03 PM >> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >> *Subject:* Re: [sfc] SFC Terminology / Concepts >> >> I like that text, it strikes a good balance where an implementation has >> the option of making scale and resiliency a local matter…. >> >> D >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >> (jguichar) >> *Sent:* Monday, July 14, 2014 10:48 AM >> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >> *Subject:* [sfc] SFC Terminology / Concepts >> >> Dear WG: >> >> There has been much debate over the last few days with regards to SFC >> concepts. To try and form some consensus around terminology and concepts >> used to describe the architecture in the merged architecture draft, Joel >> has kindly suggested the following: >> >> "The SFP provides a level of indirection between the fully abstract >> notion of service path as a sequence of functions to be delivered, and >> the fully specified notion of exactly what instances of SFFs the packet >> will visit when it actually traverses the network. By allowing the >> control components to specify the use of this level of indirection, the >> deployment may choose the degree of SFF instance selection authority >> that is delegated to the network.” >> >> I’d like to ask the WG as a whole, if this clarification is something >> that we can get consensus on. If so, I’ll ask Joel to provide specific >> text, that reflects the above, for inclusion in the merged architecture >> draft. >> >> Thank You, >> >> Jim >> >> >> >> _______________________________________________ >> sfc mailing 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 Jul 14 12:55:56 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2971A8BB2 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:55:53 -0700 (PDT) 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 pDMAe9qRD44I for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 12:55:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48741A00B9 for <sfc@ietf.org>; Mon, 14 Jul 2014 12:55:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B51D3247317; Mon, 14 Jul 2014 12:55:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 18CFC2472F1; Mon, 14 Jul 2014 12:55:44 -0700 (PDT) Message-ID: <53C435BF.7090803@joelhalpern.com> Date: Mon, 14 Jul 2014 15:55:43 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Dolson <ddolson@sandvine.com>, "sfc@ietf.org" <sfc@ietf.org>, "cpignata@cisco.com" <cpignata@cisco.com> References: <E8355113905631478EFF04F5AA706E9830A2E597@wtl-exchp-2.sandvine.com> In-Reply-To: <E8355113905631478EFF04F5AA706E9830A2E597@wtl-exchp-2.sandvine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Z-2tbt5GrJomkzUKqXbKkND9Rno Subject: Re: [sfc] Does SFF or SFC Proxy maintain flow state? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 19:55:53 -0000 The later part of that quote does look like it needs work. As you say, the Proxy is concerned with re-attaching information for SFC-unaware service functions. Yours, Joel On 7/14/14, 2:58 PM, Dave Dolson wrote: > In draft-merged-sfc-architecture-00, section 4.3, > > <quote> > > The SFF component has the following primary responsibilities: > > … > > 3. Maintaining flow state: In some cases, the SFF may be stateful. > > It creates flows and stores flow-centric information. When > > traffic arrives after being steered through an SFC-unaware SF, > > the SFF must perform re-classification of traffic to determine > > the SFP. A state-full SFF simplifies such classification to a > > flow lookup. > > <end quote> > > Is this correct? Shouldn’t it be the SFC Proxy that maintains flow state > in order to re-classify traffic returning from an SFC-unaware SF? > > -Dave > From nobody Mon Jul 14 13:15:37 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2D1A00C9 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Yq7GGQfYUpbP for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:15:31 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8401A00A3 for <sfc@ietf.org>; Mon, 14 Jul 2014 13:15:31 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 90DD753DFC; Mon, 14 Jul 2014 13:13:26 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 14 Jul 2014 13:13:26.572 -0700 x-echoworx-msg-id: 7a7a0681-a03b-49ad-b12c-43c82ecb3716 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 779; Mon, 14 Jul 2014 13:13:26 -0700 (PDT) Received: from HUB021-CA-1.exch021.domain.local (unknown [10.254.4.30]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 762D053DFC; Mon, 14 Jul 2014 13:13:26 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 13:15:30 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+AD//5CdkA== Date: Mon, 14 Jul 2014 20:15:30 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B7A76@MBX021-W3-CA-2.exch021.domain.local> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> In-Reply-To: <53C434F4.7050208@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tnWmcuzr64tHX9hf50uH3wuFGvc Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 20:15:34 -0000 I am not one of them. I see the chain ID or equivalent being required in = the packet. At a minimum, the SFF receiving the packet needs to know whi= ch is the currently required local SF, what is the next required SF (if any= ) and what is the SFF that reaches the next SF. Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, July 14, 2014 3:52 PM To: Tom Taylor; sfc@ietf.org; Ron Parker Subject: Re: [sfc] SFC Terminology / Concepts The most likely realization of the architecture would be that the SFP assig= nment is recorded in an identifier which travels with the packet. Some folks seem to not want the architecture to mandate that. Yours, Joel On 7/14/14, 2:37 PM, Tom Taylor wrote: > Your text scares me because it introduces some new concepts and=20 > assumptions. > > I'd rather go with Joel's formulation. Clarifying question on that: am=20 > I right in seeing the implication that when control assigns an SFP,=20 > the assignment is recorded by an identifier wwhich travels with the packe= t? > > Tom Taylor > > On 14/07/2014 2:22 PM, Ron Parker wrote: >> There is one missing word in my text. Please replace my proposed text >> with: >> >> "The Service Function Chain (SFC) provides a fully abstract view of=20 >> the service functions to be invoked and the order in which they are=20 >> to be invoked for some particular flow or set of flows, without concern = of >> actual service function instance selection. The Constrained-SFC >> (C-SFC) further allows for policy constraints to be added to the SFC=20 >> affecting the instance selection of one or more of the service functions >> in the SFC. Any SFC may have any number of C-SFC's associated with it.= " >> >> Thanks. >> >> Ron > ... > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >> *Sent:* Monday, July 14, 2014 2:03 PM >> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >> *Subject:* Re: [sfc] SFC Terminology / Concepts >> >> I like that text, it strikes a good balance where an implementation=20 >> has the option of making scale and resiliency a local matter.... >> >> D >> >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >> (jguichar) >> *Sent:* Monday, July 14, 2014 10:48 AM >> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >> *Subject:* [sfc] SFC Terminology / Concepts >> >> Dear WG: >> >> There has been much debate over the last few days with regards to SFC=20 >> concepts. To try and form some consensus around terminology and=20 >> concepts used to describe the architecture in the merged architecture=20 >> draft, Joel has kindly suggested the following: >> >> "The SFP provides a level of indirection between the fully abstract=20 >> notion of service path as a sequence of functions to be delivered,=20 >> and the fully specified notion of exactly what instances of SFFs the=20 >> packet will visit when it actually traverses the network. By allowing=20 >> the control components to specify the use of this level of=20 >> indirection, the deployment may choose the degree of SFF instance=20 >> selection authority that is delegated to the network." >> >> I'd like to ask the WG as a whole, if this clarification is something=20 >> that we can get consensus on. If so, I'll ask Joel to provide=20 >> specific text, that reflects the above, for inclusion in the merged=20 >> architecture draft. >> >> Thank You, >> >> Jim >> >> >> >> _______________________________________________ >> sfc mailing 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 Jul 14 13:22:36 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CD91B278D for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:22:32 -0700 (PDT) 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 LM2GQ9gLQiht for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:22:30 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43A21A0ACE for <sfc@ietf.org>; Mon, 14 Jul 2014 13:22:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 85EFB24731E; Mon, 14 Jul 2014 13:22:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 62EDB24730C; Mon, 14 Jul 2014 13:22:29 -0700 (PDT) Message-ID: <53C43C04.5060602@joelhalpern.com> Date: Mon, 14 Jul 2014 16:22:28 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C42183.8040605@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA83@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA83@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nz2KWuya9ZP0kKDNYzRLWBTF_10 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 20:22:32 -0000 Maria, the text allows, but does not mandate, the selecting of specific service instances. I can not tell whether you agree or disagree with either allowing or not mandating the behavior. Yours, Joel On 7/14/14, 2:42 PM, NAPIERALA, MARIA H wrote: > Joel, > > for me, this is still about specific service instances to be chosen. > > Maria >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, July 14, 2014 2:29 PM >> To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar); >> sfc@ietf.org >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Maria, while the constraint (either C-SFC or SFP, whichever term the SG >> likes) may be selecting specific instances, it may be more general. >> >> The simplest example is that for a given service chain, one might have >> one SFP (or C-SFC) that causes the entire chain to be delivered at >> data-center-1 and a second SFP (or C-SFC) that causes the entire service >> chain to be delivered at data-center-2. Each data center has many >> instances running. And may even have multiple clusters in different >> PODs within the DC. >> Yes, the constraint may say use exactly this specific isntances, but it >> does not have to. >> >> Yours, >> Joel >> >> On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote: >>> Ron, >>> >>> this is pretty good. >>> >>> I would propose to re-phrase the second sentence to: "The >>> Constrained-SFC (C-SFC) further allows for policy constraints to be >>> added to the SFC affecting the selection of one or more **specific** >>> service function **instances** in the SFC". >>> >>> Maria >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker >>> *Sent:* Monday, July 14, 2014 2:16 PM >>> *To:* David Allan I; Jim Guichard (jguichar); sfc@ietf.org >>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>> >>> I have a counter-proposal that eliminates the term "SFP" entirely: >>> >>> "The Service Function Chain (SFC) provides a fully abstract view of the >>> service functions to be invoked and the order in which they are to be >>> invoked for some particular flow or set of flows, without concern of >>> actual service function instance selection. The Constrained-SFC >>> (C-SFC) further allows for policy constraints to be added to the SFC >>> affecting the selection of one or more of the service functions in the >>> SFC. Any SFC may have any number of C-SFC's associated with it." >>> >>> Thanks. >>> >>> Ron >>> >>> "The SFP provides a level of indirection between the fully abstract >>> notion of service path as a sequence of functions to be delivered, and >>> the fully specified notion of exactly what instances of SFFs the packet >>> will visit when it actually traverses the network. By allowing the >>> control components to specify the use of this level of indirection, the >>> deployment may choose the degree of SFF instance selection authority >>> that is delegated to the network." >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >>> *Sent:* Monday, July 14, 2014 2:03 PM >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>> >>> I like that text, it strikes a good balance where an implementation has >>> the option of making scale and resiliency a local matter.... >>> >>> D >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Monday, July 14, 2014 10:48 AM >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>> *Subject:* [sfc] SFC Terminology / Concepts >>> >>> Dear WG: >>> >>> There has been much debate over the last few days with regards to SFC >>> concepts. To try and form some consensus around terminology and >> concepts >>> used to describe the architecture in the merged architecture draft, Joel >>> has kindly suggested the following: >>> >>> "The SFP provides a level of indirection between the fully abstract >>> notion of service path as a sequence of functions to be delivered, and >>> the fully specified notion of exactly what instances of SFFs the packet >>> will visit when it actually traverses the network. By allowing the >>> control components to specify the use of this level of indirection, the >>> deployment may choose the degree of SFF instance selection authority >>> that is delegated to the network." >>> >>> I'd like to ask the WG as a whole, if this clarification is something >>> that we can get consensus on. If so, I'll ask Joel to provide specific >>> text, that reflects the above, for inclusion in the merged architecture >>> draft. >>> >>> Thank You, >>> >>> Jim >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Mon Jul 14 13:29:59 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443461A0AA2 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E68F4REMEK2m for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 13:29:55 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CB01A0AA0 for <sfc@ietf.org>; Mon, 14 Jul 2014 13:29:55 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 3cd34c35.2b990b244940.6032841.00-2466.16726401.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 20:29:55 +0000 (UTC) X-MXL-Hash: 53c43dc321ad4a38-9b7ebde2debd3a58743e9fb873d90fdd6b2fc307 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id dbd34c35.0.6032804.00-2310.16726249.nbfkord-smmo06.seg.att.com (envelope-from <mn1921@att.com>); Mon, 14 Jul 2014 20:29:50 +0000 (UTC) X-MXL-Hash: 53c43dbe221b5e15-b76cd5ba68c462b747f6b4f30167b77d40600085 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EKTmkS002133; Mon, 14 Jul 2014 16:29:49 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6EKTgAg002084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 16:29:45 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 14 Jul 2014 20:29:22 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Mon, 14 Jul 2014 16:29:22 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAALLEIAARjeA///ATSCAAF9LAP//vtOA Date: Mon, 14 Jul 2014 20:29:22 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BBD2@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C42183.8040605@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA83@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C43C04.5060602@joelhalpern.com> In-Reply-To: <53C43C04.5060602@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=GY2ga3rL c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gqfbR3uhTkYA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ABeY7kuGAAAA:8 a=48vgC7mUAAAA:8 a=Qb18trLkHc12NtU] X-AnalysisOut: [s6psA:9 a=CjuIK1q_8ugA:10 a=chC_agHSu74A:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=Zve4QQ9dhpJt3Fah:21 a=IXpbKn_bLltz13F0:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/HtJDeeUTe6dEmn_KWAZOXzMYfnw Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Jul 2014 20:29:57 -0000 Joel, Which text are you referring to? Sorry but I got lost. Maria > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, July 14, 2014 4:22 PM > To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar= ); > sfc@ietf.org > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Maria, the text allows, but does not mandate, the selecting of specific > service instances. I can not tell whether you agree or disagree with > either allowing or not mandating the behavior. >=20 > Yours, > Joel >=20 > On 7/14/14, 2:42 PM, NAPIERALA, MARIA H wrote: > > Joel, > > > > for me, this is still about specific service instances to be chosen. > > > > Maria > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Monday, July 14, 2014 2:29 PM > >> To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard > (jguichar); > >> sfc@ietf.org > >> Subject: Re: [sfc] SFC Terminology / Concepts > >> > >> Maria, while the constraint (either C-SFC or SFP, whichever term the S= G > >> likes) may be selecting specific instances, it may be more general. > >> > >> The simplest example is that for a given service chain, one might have > >> one SFP (or C-SFC) that causes the entire chain to be delivered at > >> data-center-1 and a second SFP (or C-SFC) that causes the entire servi= ce > >> chain to be delivered at data-center-2. Each data center has many > >> instances running. And may even have multiple clusters in different > >> PODs within the DC. > >> Yes, the constraint may say use exactly this specific isntances, but i= t > >> does not have to. > >> > >> Yours, > >> Joel > >> > >> On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote: > >>> Ron, > >>> > >>> this is pretty good. > >>> > >>> I would propose to re-phrase the second sentence to: "The > >>> Constrained-SFC (C-SFC) further allows for policy constraints to be > >>> added to the SFC affecting the selection of one or more **specific** > >>> service function **instances** in the SFC". > >>> > >>> Maria > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Ron Parker > >>> *Sent:* Monday, July 14, 2014 2:16 PM > >>> *To:* David Allan I; Jim Guichard (jguichar); sfc@ietf.org > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >>> > >>> I have a counter-proposal that eliminates the term "SFP" entirely: > >>> > >>> "The Service Function Chain (SFC) provides a fully abstract view of t= he > >>> service functions to be invoked and the order in which they are to be > >>> invoked for some particular flow or set of flows, without concern of > >>> actual service function instance selection. The Constrained-SFC > >>> (C-SFC) further allows for policy constraints to be added to the SFC > >>> affecting the selection of one or more of the service functions in th= e > >>> SFC. Any SFC may have any number of C-SFC's associated with it." > >>> > >>> Thanks. > >>> > >>> Ron > >>> > >>> "The SFP provides a level of indirection between the fully abstract > >>> notion of service path as a sequence of functions to be delivered, an= d > >>> the fully specified notion of exactly what instances of SFFs the pack= et > >>> will visit when it actually traverses the network. By allowing the > >>> control components to specify the use of this level of indirection, t= he > >>> deployment may choose the degree of SFF instance selection authority > >>> that is delegated to the network." > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > >>> *Sent:* Monday, July 14, 2014 2:03 PM > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >>> > >>> I like that text, it strikes a good balance where an implementation h= as > >>> the option of making scale and resiliency a local matter.... > >>> > >>> D > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >>> (jguichar) > >>> *Sent:* Monday, July 14, 2014 10:48 AM > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* [sfc] SFC Terminology / Concepts > >>> > >>> Dear WG: > >>> > >>> There has been much debate over the last few days with regards to SFC > >>> concepts. To try and form some consensus around terminology and > >> concepts > >>> used to describe the architecture in the merged architecture draft, J= oel > >>> has kindly suggested the following: > >>> > >>> "The SFP provides a level of indirection between the fully abstract > >>> notion of service path as a sequence of functions to be delivered, an= d > >>> the fully specified notion of exactly what instances of SFFs the pack= et > >>> will visit when it actually traverses the network. By allowing the > >>> control components to specify the use of this level of indirection, t= he > >>> deployment may choose the degree of SFF instance selection authority > >>> that is delegated to the network." > >>> > >>> I'd like to ask the WG as a whole, if this clarification is something > >>> that we can get consensus on. If so, I'll ask Joel to provide specifi= c > >>> text, that reflects the above, for inclusion in the merged architectu= re > >>> draft. > >>> > >>> Thank You, > >>> > >>> Jim > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Mon Jul 14 17:52:03 2014 Return-Path: <oliver.huang@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8E01B27DA for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 17:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 EAcEDYLN0MiD for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 17:51:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A28D1B27D1 for <sfc@ietf.org>; Mon, 14 Jul 2014 17:51:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE64596; Tue, 15 Jul 2014 00:51:56 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 01:51:55 +0100 Received: from SZXEMA506-MBX.china.huawei.com ([169.254.3.72]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 08:51:51 +0800 From: "Huangyong (Oliver)" <oliver.huang@huawei.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAbLtA Date: Tue, 15 Jul 2014 00:51:49 +0000 Message-ID: <8172B566C79A4A4C8EB6C7B1F6529EFC46D3168B@szxema506-mbx.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.108.150] Content-Type: multipart/alternative; boundary="_000_8172B566C79A4A4C8EB6C7B1F6529EFC46D3168Bszxema506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZnCDCCLt0s1md3a6j1Pdmhefouo Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 00:52:01 -0000 --_000_8172B566C79A4A4C8EB6C7B1F6529EFC46D3168Bszxema506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree Ron's proposal. --------------------------- Huangyong (Oliver) Network research, Huawei From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Tuesday, July 15, 2014 2:22 AM To: Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts There is one missing word in my text. Please replace my proposed text wit= h: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the instance select= ion of one or more of the service functions in the SFC. Any SFC may have = any number of C-SFC's associated with it." Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.or= g> Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_8172B566C79A4A4C8EB6C7B1F6529EFC46D3168Bszxema506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:STXihei; panose-1:2 1 6 0 4 1 1 1 1 1;} @font-face {font-family:STXihei; panose-1:2 1 6 0 4 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"\6279\6CE8\6846\6587\672C Char"; margin:0cm; margin-bottom:.0001pt; font-size:9.0pt; font-family:"Times New Roman","serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.Char {mso-style-name:"\6279\6CE8\6846\6587\672C Char"; mso-style-priority:99; mso-style-link:\6279\6CE8\6846\6587\672C; font-family:SimSun;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D">Agree Ron&= #8217;s proposal.  <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:8.0pt;font-f= amily:"Calibri","sans-serif";color:#1F497D">-----------= ----------------<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog= raph"><span lang=3D"EN-US" style=3D"font-size:8.0pt;font-family:"Calib= ri","sans-serif";color:black">Huangyong (Oliver)<o:p></o:p><= /span></p> <p class=3D"MsoNormal" style=3D"text-align:justify;text-justify:inter-ideog= raph"><span lang=3D"EN-US" style=3D"font-size:8.0pt;font-family:"Calib= ri","sans-serif";color:black">Network research, Huawei</span= ><span lang=3D"EN-US" style=3D"font-size:8.0pt;font-family:"Calibri&qu= ot;,"sans-serif";color:black"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo= nt-family:"Tahoma","sans-serif"">From:</span></b><span = lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu= ot;sans-serif""> sfc [mailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Tuesday, July 15, 2014 2:22 AM<br> <b>To:</b> Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org= <br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">There is o= ne missing word in my text.   Please replace my proposed text wit= h:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">“The= Service Function Chain (SFC) provides a fully abstract view of the service= functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual servic= e function instance selection.   The Constrained-SFC (C-SFC) furt= her allows for policy constraints to be added to the SFC affecting the inst= ance selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFCR= 17;s associated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Thanks.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"> &nbs= p;  Ron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo= nt-family:"Calibri","sans-serif"">From:</span></b><span= lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri",&= quot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto= :sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ie= tf.org"> sfc@ietf.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">I have a c= ounter-proposal that eliminates the term “SFP” entirely:<o:p></= o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">“The= Service Function Chain (SFC) provides a fully abstract view of the service= functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual servic= e function instance selection.   The Constrained-SFC (C-SFC) furt= her allows for policy constraints to be added to the SFC affecting the sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s assoc= iated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Thanks.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"> &nbs= p;  Ron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">"The SFP provides a level of indirection between the fully abs= tract notion of service path as a sequence of functions to be delivered, an= d the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the net= work. By allowing the control components to specify the use of this level o= f indirection, the deployment may choose the degree of SFF instance selecti= on authority that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo= nt-family:"Calibri","sans-serif"">From:</span></b><span= lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri",&= quot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto= :sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">I like tha= t text, it strikes a good balance where an implementation has the option of= making scale and resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">D<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo= nt-family:"Tahoma","sans-serif"">From:</span></b><span = lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu= ot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:s= fc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Dear WG:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">There has been much debate over the last few days with regards to S= FC concepts. To try and form some consensus around terminology and concepts= used to describe the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:= p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">"The SFP provides a level of indirection between the fully abs= tract notion of service path as a sequence of functions to be delivered, an= d the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the net= work. By allowing the control components to specify the use of this level o= f indirection, the deployment may choose the degree of SFF instance selecti= on authority that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">I’d like to ask the WG as a whole, if this clarification is s= omething that we can get consensus on. If so, I’ll ask Joel to provid= e specific text, that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Thank You,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Jim<o:p></o:p></span></p> </div> </div> </body> </html> --_000_8172B566C79A4A4C8EB6C7B1F6529EFC46D3168Bszxema506mbxchi_-- From nobody Mon Jul 14 19:04:38 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F6B1B27E5 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 19:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Qk8yKwo20-SB for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 19:04:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E461B27E1 for <sfc@ietf.org>; Mon, 14 Jul 2014 19:04:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE68109; Tue, 15 Jul 2014 02:04:34 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 03:04:33 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 10:04:30 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eCUIwKY/CDCEqtraJ73Kn6IpugYkOA Date: Tue, 15 Jul 2014 02:04:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> References: <53C3F5CD.5080105@joelhalpern.com> In-Reply-To: <53C3F5CD.5080105@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cO1v5PNuYcpsL3v_nApKcS7YdPQ Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 02:04:37 -0000 Hi Joel, > To rephrase this a bit (and then if folks agree on the concept, we can pi= ck the > wording): >=20 > The SFP provides a level of indirection between the fully abstract notion= of > service path as a sequence of functions to be delivered, and the fully sp= ecified > notion of exactly what instances of SFFs the packet will visit when it ac= tually > traverses the network. Instances of SFFs or instances of SF? > By allowing the control components to specify the use of this level of in= direction, > the deployment may choose the degree of SFF instance selection authority = that > is delegated to the network. SFF instance or SF instance? Best regards, Xiaohu > Yours, > Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 14 19:31:18 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965651A026F for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 19:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZlRyx-CO0sex for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 19:31:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04C41A026C for <sfc@ietf.org>; Mon, 14 Jul 2014 19:31:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE69480; Tue, 15 Jul 2014 02:31:14 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 03:31:13 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 10:31:06 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAPOnkA== Date: Tue, 15 Jul 2014 02:31:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829315F@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> In-Reply-To: <53C434F4.7050208@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/WsPDMysJB9aiZQZP1xMnerNFCmM Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 02:31:17 -0000 Hi Joel, I believe we should make a clear definition of the SFP. As for how to carry= the SFP information in the data packets, there are many ways and therefore= it should not be specified in the arch draft. Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, July 15, 2014 3:52 AM > To: Tom Taylor; sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > The most likely realization of the architecture would be that the SFP ass= ignment > is recorded in an identifier which travels with the packet. >=20 > Some folks seem to not want the architecture to mandate that. >=20 > Yours, > Joel >=20 >=20 > On 7/14/14, 2:37 PM, Tom Taylor wrote: > > Your text scares me because it introduces some new concepts and > > assumptions. > > > > I'd rather go with Joel's formulation. Clarifying question on that: am > > I right in seeing the implication that when control assigns an SFP, > > the assignment is recorded by an identifier wwhich travels with the pac= ket? > > > > Tom Taylor > > > > On 14/07/2014 2:22 PM, Ron Parker wrote: > >> There is one missing word in my text. Please replace my proposed tex= t > >> with: > >> > >> "The Service Function Chain (SFC) provides a fully abstract view of > >> the service functions to be invoked and the order in which they are > >> to be invoked for some particular flow or set of flows, without concer= n of > >> actual service function instance selection. The Constrained-SFC > >> (C-SFC) further allows for policy constraints to be added to the SFC > >> affecting the instance selection of one or more of the service functio= ns > >> in the SFC. Any SFC may have any number of C-SFC's associated with i= t." > >> > >> Thanks. > >> > >> Ron > > ... > > > > > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I > >> *Sent:* Monday, July 14, 2014 2:03 PM > >> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >> *Subject:* Re: [sfc] SFC Terminology / Concepts > >> > >> I like that text, it strikes a good balance where an implementation > >> has the option of making scale and resiliency a local matter.... > >> > >> D > >> > >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >> (jguichar) > >> *Sent:* Monday, July 14, 2014 10:48 AM > >> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >> *Subject:* [sfc] SFC Terminology / Concepts > >> > >> Dear WG: > >> > >> There has been much debate over the last few days with regards to SFC > >> concepts. To try and form some consensus around terminology and > >> concepts used to describe the architecture in the merged architecture > >> draft, Joel has kindly suggested the following: > >> > >> "The SFP provides a level of indirection between the fully abstract > >> notion of service path as a sequence of functions to be delivered, > >> and the fully specified notion of exactly what instances of SFFs the > >> packet will visit when it actually traverses the network. By allowing > >> the control components to specify the use of this level of > >> indirection, the deployment may choose the degree of SFF instance > >> selection authority that is delegated to the network." > >> > >> I'd like to ask the WG as a whole, if this clarification is something > >> that we can get consensus on. If so, I'll ask Joel to provide > >> specific text, that reflects the above, for inclusion in the merged > >> architecture draft. > >> > >> Thank You, > >> > >> Jim > >> > >> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Mon Jul 14 20:07:49 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07D01B2804 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 15Reggxa3MR2 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:07:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7221B2802 for <sfc@ietf.org>; Mon, 14 Jul 2014 20:07:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA84340; Tue, 15 Jul 2014 03:07:43 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 04:07:42 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 11:07:33 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eCUIwKY/CDCEqtraJ73Kn6IpugYkOAgAAOE3A= Date: Tue, 15 Jul 2014 03:07:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293185@NKGEML512-MBS.china.huawei.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rDEGPzvJZPGTG4qojnbxNBEzvMg Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 03:07:47 -0000 Specially speaking, for a given SFF along the SPF, should it just be capabl= e of flexibly choosing one of the local SF instances of the current SF, or = should it further be capable of flexibly choose one of the SFFs to which at= least one instance of the next SF is attached? Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 15, 2014 10:05 AM > To: Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Hi Joel, >=20 > > To rephrase this a bit (and then if folks agree on the concept, we can > > pick the > > wording): > > > > The SFP provides a level of indirection between the fully abstract > > notion of service path as a sequence of functions to be delivered, and > > the fully specified notion of exactly what instances of SFFs the > > packet will visit when it actually traverses the network. >=20 > Instances of SFFs or instances of SF? >=20 > > By allowing the control components to specify the use of this level of > > indirection, the deployment may choose the degree of SFF instance > > selection authority that is delegated to the network. >=20 > SFF instance or SF instance? >=20 > Best regards, > Xiaohu >=20 > > Yours, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 14 20:52:26 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A711B2807 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 bPvxDt01WG0a for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:52:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBF91B2804 for <sfc@ietf.org>; Mon, 14 Jul 2014 20:52:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE74354; Tue, 15 Jul 2014 03:52:22 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 04:52:21 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 11:52:16 +0800 From: Qin Wu <bill.wu@huawei.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eBFXIXCro840Gjdu1FKIqnHZuggCsw Date: Tue, 15 Jul 2014 03:52:16 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA84582F8F@nkgeml501-mbs.china.huawei.com> References: <53C3F5CD.5080105@joelhalpern.com> In-Reply-To: <53C3F5CD.5080105@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/YHScbgE-MtbuG44ZstlMkz1gl0s Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 03:52:25 -0000 Sm9lbCdzIHByb3Bvc2FsIGlzIHZlcnkgY2xvc2UgdG8gd2hhdCBJIHRob3VnaHQsDQpCdXQgd2h5 IG5vdCB1c2Ugb3IgYWRkIGRlZmluaXRpb24gcHJvcG9zZWQgYnkgTWFyaWEgYXMgd2VsbA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAyNDQ0Lmh0 bWwNCg0KU2VydmljZSBmdW5jdGlvbiBwYXRoIGNhbiBiZSBlaXRoZXIgcHJlLWRldGVybWluZWQg b3IgZGV0ZXJtaW5lZCBkeW5hbWljYWxseSwgaS5lLiwgY2hvb3NpbmcgdGhlIGxvY2F0b3JzIG9m IHNlcnZpY2UgZXhwbGljaXQgU0YgaW5zdGFuY2VzLg0KVGhpcyB3aWxsIGJvdGggYWxsb3cgZmxl eGliaWxpdHkgaW4gdGhlIHNlbGVjdGlvbiBvZiBuZXh0LVNGRiB3aXRoaW4gdGhlIHBhdGgoaS5l LiwgbmV4dCBob3AgcGFyYWRpZ20pIGFuZCBhbGxvdyBjZW50cmFsIHN5c3RlbSB0byBkZWNpZGUg dGhlIHBhdGguDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9lbCBNLiBIYWxwZXJuDQq3 osvNyrG85DogMjAxNMTqN9TCMTTI1SAyMzoyMw0KytW8/sjLOiBzZmNAaWV0Zi5vcmcNCtb3zOI6 IFtzZmNdIFByb3Bvc2VkIHJlZGVmaW5pdGlvbiBvZiBTRlANCg0KSW4gYW4gZWFybGllciBlbWFp bCBJIHNhaWQ6DQoNClRoZSB3YXkgdGhlIGRyYWZ0IHVzZXMgdGhlIHRlcm1zLCBhbmQgdGhlIHdh eSBtb3N0IGRpc2N1c3Npb25zIG91dHNpZGUgdGhlIElFVEYgU0ZDIHdvcmtpbmcgZ3JvdXAgdXNl IHRoZSB0ZXJtLCBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgc29tZXRoaW5nIHRoYXQgeW91 IHdvdWxkIGRpc2N1c3MgYSBwb2xpY3kgYWJvdXQuICBDZXJ0YWluIHRyYWZmaWMgZnJvbSBjZXJ0 YWluIHVzZXJzIGlzIHN1cHBvc2VkIHRvIHJlY2VpdmUgYSBjZXJ0YWluIHNlcXVlbmNlIG9mIHNl cnZpY2VzLCB0aGUgc2VydmljZSBjaGFpbi4NCg0KQXQgdGhlIHBvbGljeSBsZXZlbCwgdGhhdCBk b2VzIG5vdCBjYXJlIHdoZXJlIGluIHRoZSBuZXR3b3JrIHRoYXQgaXMgZGVsaXZlcmVkLiAgU28g YXMgdG8gYWxsb3cgY29udHJvbCBhIGxldmVsIG9mIGluZmx1ZW5jZSwgYW5kIHRvIGhhdmUgZmxl eGliaWxpdHkgdG8gaGF2ZSBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMgaW4gdGhlIG5ldHdvcmsg b2YgdGhhdCBwb2xpY3kgY29uc3RydWN0LCB3ZSBoYXZlIHRoZSBpbnRlcm1lZGlhdGUgbm90aW9u IG9mIHNlcnZpY2UgZnVuY3Rpb24gcGF0aC4gIElmIHRoZSBjb250cm9sIHN5c3RlbSBkb2VzIG5v dCBuZWVkIHRvIGFwcGx5IGFueSBpbmZsdWVuY2UsIHRoZW4gaXQgdXNlcyBvbmUgc2VydmljZSBw YXRoIGZvciB0aGUgc2VydmljZSBjaGFpbi4gIElmIGl0IG5lZWRzIGEgbGV2ZWwgb2YgY29udHJv bCwgaXQgaW5zdGFudGlhdGVzIGEgc3VpdGFibGUgbnVtYmVyIG9mIHNlcnZpY2UgcGF0aHMgaW4g dGhlIGNvbnRyb2wgc3lzdGVtLCBhbmQgcnVsZXMgZm9yIGhvdyB0aG9zZSBhcmUgdXNlZC4NCg0K VGhlbiwgdGhlIG1hcHBpbmcgaW4gdGhlIFNGRiBpcyBiYXNlZCBvbiB0aGF0IHBhdGgsIHNvIGFz IHRvIGVuYWJsZSB0aGUgaW5mbHVlbmNlIG9mIHRoZSBjb250cm9sIHN5c3RlbS4gIFdoaWxlIHN0 aWxsIGFsbG93aW5nIHNldmVyYWwgb3RoZXIgbGF5ZXJzIG9mIHRyYWZmaWMgbWFuYWdlbWVudCBh cyBkaXNjdXNzZWQuDQoNCllvdXJzLA0KSm9lbA0KDQpUbyByZXBocmFzZSB0aGlzIGEgYml0IChh bmQgdGhlbiBpZiBmb2xrcyBhZ3JlZSBvbiB0aGUgY29uY2VwdCwgd2UgY2FuIHBpY2sgdGhlIHdv cmRpbmcpOg0KDQpUaGUgU0ZQIHByb3ZpZGVzIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2Vl biB0aGUgZnVsbHkgYWJzdHJhY3Qgbm90aW9uIG9mIHNlcnZpY2UgcGF0aCBhcyBhIHNlcXVlbmNl IG9mIGZ1bmN0aW9ucyB0byBiZSBkZWxpdmVyZWQsIGFuZCB0aGUgZnVsbHkgc3BlY2lmaWVkIG5v dGlvbiBvZiBleGFjdGx5IHdoYXQgaW5zdGFuY2VzIG9mIFNGRnMgdGhlIHBhY2tldCB3aWxsIHZp c2l0IHdoZW4gaXQgYWN0dWFsbHkgdHJhdmVyc2VzIHRoZSBuZXR3b3JrLg0KDQpCeSBhbGxvd2lu ZyB0aGUgY29udHJvbCBjb21wb25lbnRzIHRvIHNwZWNpZnkgdGhlIHVzZSBvZiB0aGlzIGxldmVs IG9mIGluZGlyZWN0aW9uLCB0aGUgZGVwbG95bWVudCBtYXkgY2hvb3NlIHRoZSBkZWdyZWUgb2Yg U0ZGIGluc3RhbmNlIHNlbGVjdGlvbiBhdXRob3JpdHkgdGhhdCBpcyBkZWxlZ2F0ZWQgdG8gdGhl IG5ldHdvcmsuDQoNCllvdXJzLA0KSm9lbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Jul 14 21:33:54 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089C1A0301 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 21:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fGFginTAL_1g for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 21:33:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C131A02FA for <sfc@ietf.org>; Mon, 14 Jul 2014 21:33:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE76872; Tue, 15 Jul 2014 04:33:46 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 05:33:45 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 12:33:40 +0800 From: Qin Wu <bill.wu@huawei.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAqfIA Date: Tue, 15 Jul 2014 04:33:40 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA84582FC9@nkgeml501-mbs.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84582FC9nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_mF0wPvc6tckALFr3vjoWJBJTXc Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 04:33:50 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84582FC9nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q2hhaW4gYW5kIFBhdGggYXJlIHN0aWxsIHR3byBkaWZmZXJlbnQgdGhpbmdzLiBDaGFuZ2UgdGhl IG5hbWUgb2YgcGF0aCBkb2VzbqGvdCBoZWxwLg0KSWYgSSBoYXZlIGEgY29uc3RyYWludCBiYXNl ZCBwYXRoLCBzaG91bGQgSSBpbnRlcnByZXQgaXQgYXMgY29uc3RyYWludCBiYXNlZCBjb25zdHJh aW50LVNGQz8gTm8NCg0KUmVnYXJkcyENCi1RaW4NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gUm9uIFBhcmtlcg0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjE1yNUg MjoyMg0KytW8/sjLOiBSb24gUGFya2VyOyBEYXZpZCBBbGxhbiBJOyBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTsgc2ZjQGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8g Q29uY2VwdHMNCg0KVGhlcmUgaXMgb25lIG1pc3Npbmcgd29yZCBpbiBteSB0ZXh0LiAgIFBsZWFz ZSByZXBsYWNlIG15IHByb3Bvc2VkIHRleHQgd2l0aDoNCg0KobBUaGUgU2VydmljZSBGdW5jdGlv biBDaGFpbiAoU0ZDKSBwcm92aWRlcyBhIGZ1bGx5IGFic3RyYWN0IHZpZXcgb2YgdGhlIHNlcnZp Y2UgZnVuY3Rpb25zIHRvIGJlIGludm9rZWQgYW5kIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IGFy ZSB0byBiZSBpbnZva2VkIGZvciBzb21lIHBhcnRpY3VsYXIgZmxvdyBvciBzZXQgb2YgZmxvd3Ms IHdpdGhvdXQgY29uY2VybiBvZiBhY3R1YWwgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBzZWxl Y3Rpb24uICAgVGhlIENvbnN0cmFpbmVkLVNGQyAoQy1TRkMpIGZ1cnRoZXIgYWxsb3dzIGZvciBw b2xpY3kgY29uc3RyYWludHMgdG8gYmUgYWRkZWQgdG8gdGhlIFNGQyBhZmZlY3RpbmcgdGhlIGlu c3RhbmNlIHNlbGVjdGlvbiBvZiBvbmUgb3IgbW9yZSBvZiB0aGUgc2VydmljZSBmdW5jdGlvbnMg aW4gdGhlIFNGQy4gICBBbnkgU0ZDIG1heSBoYXZlIGFueSBudW1iZXIgb2YgQy1TRkOhr3MgYXNz b2NpYXRlZCB3aXRoIGl0LqGxDQoNClRoYW5rcy4NCg0KICAgIFJvbg0KDQoNCg0KDQoNCkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtl cg0KU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDI6MTYgUE0NClRvOiBEYXZpZCBBbGxhbiBJ OyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCg0KSSBo YXZlIGEgY291bnRlci1wcm9wb3NhbCB0aGF0IGVsaW1pbmF0ZXMgdGhlIHRlcm0gobBTRlChsSBl bnRpcmVseToNCg0KobBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKSBwcm92aWRlcyBh IGZ1bGx5IGFic3RyYWN0IHZpZXcgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRvIGJlIGludm9r ZWQgYW5kIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IGFyZSB0byBiZSBpbnZva2VkIGZvciBzb21l IHBhcnRpY3VsYXIgZmxvdyBvciBzZXQgb2YgZmxvd3MsIHdpdGhvdXQgY29uY2VybiBvZiBhY3R1 YWwgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBzZWxlY3Rpb24uICAgVGhlIENvbnN0cmFpbmVk LVNGQyAoQy1TRkMpIGZ1cnRoZXIgYWxsb3dzIGZvciBwb2xpY3kgY29uc3RyYWludHMgdG8gYmUg YWRkZWQgdG8gdGhlIFNGQyBhZmZlY3RpbmcgdGhlIHNlbGVjdGlvbiBvZiBvbmUgb3IgbW9yZSBv ZiB0aGUgc2VydmljZSBmdW5jdGlvbnMgaW4gdGhlIFNGQy4gICBBbnkgU0ZDIG1heSBoYXZlIGFu eSBudW1iZXIgb2YgQy1TRkOhr3MgYXNzb2NpYXRlZCB3aXRoIGl0LqGxDQoNClRoYW5rcy4NCg0K ICAgIFJvbg0KDQoNCg0KIlRoZSBTRlAgcHJvdmlkZXMgYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBi ZXR3ZWVuIHRoZSBmdWxseSBhYnN0cmFjdCBub3Rpb24gb2Ygc2VydmljZSBwYXRoIGFzIGEgc2Vx dWVuY2Ugb2YgZnVuY3Rpb25zIHRvIGJlIGRlbGl2ZXJlZCwgYW5kIHRoZSBmdWxseSBzcGVjaWZp ZWQgbm90aW9uIG9mIGV4YWN0bHkgd2hhdCBpbnN0YW5jZXMgb2YgU0ZGcyB0aGUgcGFja2V0IHdp bGwgdmlzaXQgd2hlbiBpdCBhY3R1YWxseSB0cmF2ZXJzZXMgdGhlIG5ldHdvcmsuIEJ5IGFsbG93 aW5nIHRoZSBjb250cm9sIGNvbXBvbmVudHMgdG8gc3BlY2lmeSB0aGUgdXNlIG9mIHRoaXMgbGV2 ZWwgb2YgaW5kaXJlY3Rpb24sIHRoZSBkZXBsb3ltZW50IG1heSBjaG9vc2UgdGhlIGRlZ3JlZSBv ZiBTRkYgaW5zdGFuY2Ugc2VsZWN0aW9uIGF1dGhvcml0eSB0aGF0IGlzIGRlbGVnYXRlZCB0byB0 aGUgbmV0d29yay6hsQ0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGF2aWQgQWxsYW4gSQ0KU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0 IDI6MDMgUE0NClRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29u Y2VwdHMNCg0KSSBsaWtlIHRoYXQgdGV4dCwgaXQgc3RyaWtlcyBhIGdvb2QgYmFsYW5jZSB3aGVy ZSBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgdGhlIG9wdGlvbiBvZiBtYWtpbmcgc2NhbGUgYW5kIHJl c2lsaWVuY3kgYSBsb2NhbCBtYXR0ZXKhrS4NCg0KRA0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpT ZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMTA6NDggQU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdIFNGQyBUZXJtaW5vbG9neSAvIENvbmNl cHRzDQoNCkRlYXIgV0c6DQoNClRoZXJlIGhhcyBiZWVuIG11Y2ggZGViYXRlIG92ZXIgdGhlIGxh c3QgZmV3IGRheXMgd2l0aCByZWdhcmRzIHRvIFNGQyBjb25jZXB0cy4gVG8gdHJ5IGFuZCBmb3Jt IHNvbWUgY29uc2Vuc3VzIGFyb3VuZCB0ZXJtaW5vbG9neSBhbmQgY29uY2VwdHMgdXNlZCB0byBk ZXNjcmliZSB0aGUgYXJjaGl0ZWN0dXJlIGluIHRoZSBtZXJnZWQgYXJjaGl0ZWN0dXJlIGRyYWZ0 LCBKb2VsIGhhcyBraW5kbHkgc3VnZ2VzdGVkIHRoZSBmb2xsb3dpbmc6DQoNCiJUaGUgU0ZQIHBy b3ZpZGVzIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgZnVsbHkgYWJzdHJhY3Qg bm90aW9uIG9mIHNlcnZpY2UgcGF0aCBhcyBhIHNlcXVlbmNlIG9mIGZ1bmN0aW9ucyB0byBiZSBk ZWxpdmVyZWQsIGFuZCB0aGUgZnVsbHkgc3BlY2lmaWVkIG5vdGlvbiBvZiBleGFjdGx5IHdoYXQg aW5zdGFuY2VzIG9mIFNGRnMgdGhlIHBhY2tldCB3aWxsIHZpc2l0IHdoZW4gaXQgYWN0dWFsbHkg dHJhdmVyc2VzIHRoZSBuZXR3b3JrLiBCeSBhbGxvd2luZyB0aGUgY29udHJvbCBjb21wb25lbnRz IHRvIHNwZWNpZnkgdGhlIHVzZSBvZiB0aGlzIGxldmVsIG9mIGluZGlyZWN0aW9uLCB0aGUgZGVw bG95bWVudCBtYXkgY2hvb3NlIHRoZSBkZWdyZWUgb2YgU0ZGIGluc3RhbmNlIHNlbGVjdGlvbiBh dXRob3JpdHkgdGhhdCBpcyBkZWxlZ2F0ZWQgdG8gdGhlIG5ldHdvcmsuobENCg0KSaGvZCBsaWtl IHRvIGFzayB0aGUgV0cgYXMgYSB3aG9sZSwgaWYgdGhpcyBjbGFyaWZpY2F0aW9uIGlzIHNvbWV0 aGluZyB0aGF0IHdlIGNhbiBnZXQgY29uc2Vuc3VzIG9uLiBJZiBzbywgSaGvbGwgYXNrIEpvZWwg dG8gcHJvdmlkZSBzcGVjaWZpYyB0ZXh0LCB0aGF0IHJlZmxlY3RzIHRoZSBhYm92ZSwgZm9yIGlu Y2x1c2lvbiBpbiB0aGUgbWVyZ2VkIGFyY2hpdGVjdHVyZSBkcmFmdC4NCg0KVGhhbmsgWW91LA0K DQpKaW0NCg== --_000_B8F9A780D330094D99AF023C5877DABA84582FC9nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312"> <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:=CB=CE=CC=E5; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@=CB=CE=CC=E5"; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"=C5=FA=D7=A2=BF=F2=CE=C4=B1=BE Char"; margin:0cm; margin-bottom:.0001pt; font-size:9.0pt; font-family:"Times New Roman","serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.Char {mso-style-name:"=C5=FA=D7=A2=BF=F2=CE=C4=B1=BE Char"; mso-style-priority:99; mso-style-link:=C5=FA=D7=A2=BF=F2=CE=C4=B1=BE; font-family:=CB=CE=CC=E5;} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D">Chain and = Path are still two different things. Change the name of path doesn=A1=AFt h= elp.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D">If I have = a constraint based path, should I interpret it as constraint based constrai= nt-SFC? No<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D">Regards!<o= :p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-= family:"Calibri","sans-serif";color:#1F497D">-Qin<o:p><= /o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:=CB= =CE=CC=E5">=B7=A2=BC=FE=C8=CB<span lang=3D"EN-US">:</span></span></b><span = lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5"> sfc [ma= ilto:sfc-bounces@ietf.org] </span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5">=B4=FA= =B1=ED </span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-famil= y:=CB=CE=CC=E5">Ron Parker<br> </span><b><span style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5">=B7=A2= =CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:</span></span></b><span lang=3D"EN-= US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5"> 2014</span><span s= tyle=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5">=C4=EA<span lang=3D"EN-U= S">7</span>=D4=C2<span lang=3D"EN-US">15</span>=C8=D5<span lang=3D"EN-US"> 2:22<br> </span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"= EN-US"> Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org<br= > </span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"= > Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">There is o= ne missing word in my text.   Please replace my proposed text wit= h:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">=A1=B0The = Service Function Chain (SFC) provides a fully abstract view of the service = functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual servic= e function instance selection.   The Constrained-SFC (C-SFC) furt= her allows for policy constraints to be added to the SFC affecting the inst= ance selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC=A1= =AFs associated with it.=A1=B1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Thanks.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"> &nbs= p;  Ron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo= nt-family:"Calibri","sans-serif"">From:</span></b><span= lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri",&= quot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto= :sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ie= tf.org"> sfc@ietf.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">I have a c= ounter-proposal that eliminates the term =A1=B0SFP=A1=B1 entirely:<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">=A1=B0The = Service Function Chain (SFC) provides a fully abstract view of the service = functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual servic= e function instance selection.   The Constrained-SFC (C-SFC) furt= her allows for policy constraints to be added to the SFC affecting the sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC=A1=AFs associ= ated with it.=A1=B1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">Thanks.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"> &nbs= p;  Ron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">"The SFP provides a level of indirection between the fully abs= tract notion of service path as a sequence of functions to be delivered, an= d the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the net= work. By allowing the control components to specify the use of this level o= f indirection, the deployment may choose the degree of SFF instance selecti= on authority that is delegated to the network.=A1=B1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo= nt-family:"Calibri","sans-serif"">From:</span></b><span= lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri",&= quot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto= :sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">I like tha= t text, it strikes a good balance where an implementation has the option of= making scale and resiliency a local matter=A1=AD.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D">D<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D"><o:p> = ;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo= nt-family:"Tahoma","sans-serif"">From:</span></b><span = lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu= ot;sans-serif""> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:s= fc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Dear WG:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">There has been much debate over the last few days with regards to S= FC concepts. To try and form some consensus around terminology and concepts= used to describe the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:= p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">"The SFP provides a level of indirection between the fully abs= tract notion of service path as a sequence of functions to be delivered, an= d the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the net= work. By allowing the control components to specify the use of this level o= f indirection, the deployment may choose the degree of SFF instance selecti= on authority that is delegated to the network.=A1=B1<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">I=A1=AFd like to ask the WG as a whole, if this clarification is so= mething that we can get consensus on. If so, I=A1=AFll ask Joel to provide = specific text, that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Thank You,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:13.5pt;color= :black">Jim<o:p></o:p></span></p> </div> </div> </body> </html> --_000_B8F9A780D330094D99AF023C5877DABA84582FC9nkgeml501mbschi_-- From nobody Mon Jul 14 23:33:59 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE921B2819 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 23:33:55 -0700 (PDT) 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, FREEMAIL_FROM=0.001, J_CHICKENPOX_29=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 SDIlGttDpgiY for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 23:33:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E911A0309 for <sfc@ietf.org>; Mon, 14 Jul 2014 23:33:50 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id EE1961B8176; Tue, 15 Jul 2014 08:33:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id CBADA384055; Tue, 15 Jul 2014 08:33:48 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 08:33:48 +0200 From: <mohamed.boucadair@orange.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WtSqAftugz0CPuFwsDNNeGpuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AAtIh+4A== Date: Tue, 15 Jul 2014 06:33:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330032520@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> In-Reply-To: <CFE576DD.2D3DA%jguichar@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.15.53920 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/TAkqfDPtFiO8-b0AQ_1jkqJUfgo Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 06:33:55 -0000 SGkgSmltLA0KDQpCZWNhdXNlIHlvdSBjYW5ub3QgYXNzaWduIGFuIGlkZW50aWZpZXIgdG8gcGF0 aCB1bmxlc3MgaXQgaXMga25vd24gaW4gYWR2YW5jZS4gDQoNCkFueXdheSwgdGhpcyB0aHJlYWQg aGFzIHNob3duIHRoZSB0ZXJtaW5vbG9neSAocmVhZCBTRlApIGlzIG5vdCBhcHByb3ByaWF0ZSAr IHRoZSBjdXJyZW50IG1lcmdlZCBkcmFmdCBzZWVtcyB0byBhZG9wdCAocHJlZmVyID8pIGEgY2Vu dHJhbGl6ZWQgbW9kZWwuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPkRlwqA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJA Y2lzY28uY29tXQ0KPkVudm95w6nCoDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0IDE3OjE1DQo+ w4DCoDogTkFQSUVSQUxBLCBNQVJJQSBIOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb2Vs IE0uIEhhbHBlcm47IFJvbg0KPlBhcmtlcjsgc2ZjQGlldGYub3JnDQo+T2JqZXTCoDogUmU6IFtz ZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+DQo+SeKAmW0g c29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllcg0KPnByZXZlbnRzIGZ1bGwgZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBv ciB3aHkgY2FsbGluZyBpdCBhIHNlcnZpY2UNCj5jaGFpbiBpZGVudGlmaWVyIG1ha2VzIGFueSBk aWZmZXJlbmNlPw0KPg0KPk9uIDcvMTEvMTQsIDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBI IiA8bW4xOTIxQGF0dC5jb20+IHdyb3RlOg0KPg0KPj5EaXR0by4NCj4+DQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+Pj4gW21haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tXQ0KPj4+IFNlbnQ6IEZy aWRheSwgSnVseSAxMSwgMjAxNCAxMDozMSBBTQ0KPj4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbg0KPj4+IFBhcmtl cjsgc2ZjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4NCj4+PiBSZS0sDQo+Pj4NCj4+PiBGb3Igd2hh dCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0aGUg ZHJhZnQuDQo+Pj4NCj4+PiBNYW5kYXRpbmcgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBp biBpdHNlbGYgYSBoaW50IHRoYXQgdGhlIGZ1bGwNCj4+PmRpc3RyaWJ1dGVkDQo+Pj4gbW9kZWwg aXMgbm90IGFsbG93ZWQuDQo+Pj4NCj4+PiBTZXZlcmFsIHZvaWNlcyBpbiB0aGlzIHRocmVhZCBp bmRpY2F0ZWQgdGhhdCB0aGUgc2VydmljZSBjaGFpbiBpdHNlbGYNCj4+PnNob3VsZCBiZQ0KPj4+ IHByb3ZpZGVkIGluc3RlYWQuDQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4gTWVkDQo+Pj4NCj4+PiA+ LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gPkRlIDogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmltIEd1aWNoYXJkDQo+Pj4gPihqZ3VpY2hh cikNCj4+PiA+RW52b3nDqSA6IHZlbmRyZWRpIDExIGp1aWxsZXQgMjAxNCAxNjoxOA0KPj4+ID7D gCA6IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNA aWV0Zi5vcmcNCj4+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+PiA+DQo+Pj4gPk9rIGJ1dCB3aGVyZSBpbiB0aGUgYXJjaGl0 ZWN0dXJlIHNwZWNpZmljYWxseSBpcyB0aGlzIGZ1bmN0aW9uYWxpdHkNCj4+PiA+cHJvaGliaXRl ZD8gSWYgeW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZG 4oCZcw0KPj4+ID53aXRoaW4gdGhlIFNGQyBkb21haW4gYW5kIHRoZW4gbGV0IHRoZSBwYXRoIGlk ZW50aWZpZXIgcG9pbnQgdG8gYQ0KPj4+bG9va3VwDQo+Pj4gPmludG8gdGhvc2UgbmV4dC1ob3Bz IHRvIHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBub3Qgc3VyZQ0KPj4+aG93 DQo+Pj4gPnRoZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhhdD8NCj4+PiA+DQo+Pj4gPk9uIDcv MTEvMTQsIDk6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbT4gd3Jv dGU6DQo+Pj4gPg0KPj4+ID4+QWJzb2x1dGVseS4NCj4+PiA+Pg0KPj4+ID4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPj4+ID4+PihqZ3VpY2hhcikNCj4+ PiA+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6NTQgQU0NCj4+PiA+Pj4gVG86IE5B UElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5v cmcNCj4+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+Pj4gPj4+DQo+Pj4gPj4+IFRoZW4gSSBtaXN1bmRlcnN0YW5kIHRo ZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4+PnRoYXQgaWYNCj4+ PiA+Pj4geW91IGFsbG93IGFuIFNGRiB0byBtYWtlIGEgZGVjaXNpb24gYXMgdG8gd2hpY2ggcmVt b3RlIFNGRiBpdCB3aWxsDQo+Pj51c2UNCj4+PiA+Pj5mb3INCj4+PiA+Pj4gYSBnaXZlbiBmbG93 IHRvIHJlYWNoIHRoZSBuZXh0IFNGIHdpdGhpbiB0aGUgY2hhaW4gdGhlbiB5b3UgYmV0dGVyDQo+ Pj5tYWtlDQo+Pj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFzIHRoZSBuZWNlc3Nh cnkgZm9yd2FyZGluZyBsb2dpYyB0bw0KPj4+cmVhY2gNCj4+PiA+Pj50aGUNCj4+PiA+Pj4gbmV4 dC1uZXh0LVNGIGZvciB0aGUgY2hhaW4gYXMgb3RoZXJ3aXNlIHlvdSBhcmUgaW4gZGVlcCB0cm91 YmxlLg0KPj4+ID4+Pg0KPj4+ID4+PiBPbiA3LzExLzE0LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBN QVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+Pj4gd3JvdGU6DQo+Pj4gPj4+DQo+Pj4gPj4+ID5B YnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMgY2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGlu IHJlbGV2YW50DQo+Pj4gPj4+U0ZGcw0KPj4+ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPj4+ ID4+PiA+DQo+Pj4gPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gPj4+ID4+ IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmlt IEd1aWNoYXJkDQo+Pj4gPj4+ID4+KGpndWljaGFyKQ0KPj4+ID4+PiA+PiBTZW50OiBGcmlkYXks IEp1bHkgMTEsIDIwMTQgOToyNyBBTQ0KPj4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBS b24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4+PiA+Pj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gPj4+ID4+DQo+Pj4g Pj4+ID4+IFdlbGwgSSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUg dW5kZXJzdG9vZCB0aGUNCj4+PiA+Pj4gPj5wcm9wb3NhbA0KPj4+ID4+PiA+PiBjb3JyZWN0bHkg YXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeSBzaW5nbGUgU0YNCj4+ PiA+Pj53aXRoaW4NCj4+PiA+Pj4gPj50aGUNCj4+PiA+Pj4gPj4gZW50aXJlIFNGQyBkb21haW4g YXQgZXZlcnkgc2luZ2xlIFNGRiBhcyB0aGVyZSBpcyBubyB3YXkgdG8ga25vdw0KPj4+YQ0KPj4+ ID4+PiA+PnByaW9yaQ0KPj4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBTRkYgd2lsbCBu ZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuIHBvaW50DQo+Pj5pbg0KPj4+ID4+PnRpbWUuDQo+ Pj4gPj4+ID4+DQo+Pj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBNLiBIYWxw ZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+PiB3cm90ZToNCj4+PiA+Pj4gPj4NCj4+PiA+ Pj4gPj4gPlJvbiwgdGhpbmtpbmcgYWJvdXQgdGhpcywgSSByZWFsaXplZCBhbm90aGVyIG1ham9y IHByb2JsZW0gd2l0aA0KPj4+dGhlDQo+Pj4gPj4+ID4+eW91cg0KPj4+ID4+PiA+PiA+cHJvcG9z YWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkgbm90DQo+ Pj4gPj4+dW5kZXJzdGFuZA0KPj4+ID4+PiA+PiA+aXQuKQ0KPj4+ID4+PiA+PiA+DQo+Pj4gPj4+ ID4+ID5UaGUgcHJvcG9zYWwgaGFzIGVhY2ggU0ZGIHNlcnZlIGFzIHRoZSBsb2FkIGJhbGFuY2Vy IGZvciB0aGUNCj4+Pm5leHQNCj4+PiA+Pj4gPj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xs b3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxpdmVycyB0byksDQo+Pj5pbg0KPj4+ID4+PmV2ZXJ5 DQo+Pj4gPj4+ID4+ID5zZXJ2aWNlIGNoYWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4+ID4+ PiA+PiA+DQo+Pj4gPj4+ID4+ID5TaW5jZSBpdCBoYXMgdG8gYmUgYWJsZSB0byB3b3JrIHdpdGgg YWxsIHNlcnZpY2VzLCB0aGF0IG1lYW5zDQo+Pj50aGF0DQo+Pj4gPj4+ID4+ZXZlcnkNCj4+PiA+ Pj4gPj4gPlNGRiB3b3VsZCBoYXZlIHRvIGJlIGEgZnVsbCwgZmxvdyBzZW5zaXRpdmUgYW5kIHN0 YXRlZnVsIGxvYWQNCj4+PiA+Pj5iYWxhbmNlci4NCj4+PiA+Pj4gPj4gPkkgYWh2ZSBubyBwcm9i bGVtIGlmIHNvbWUgU0ZGIGFyZSBmbG93IHNlbnNpdGl2ZSwgYW5kIC8gb3INCj4+PnN0YXRlZnVs Lg0KPj4+ID4+PiA+PiA+QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBl dmVyeSBTRkYgYmUgYSBmdWxsLA0KPj4+Zmxvdw0KPj4+ID4+PiA+PiA+c2Vuc2l0aXZlLCBzdGF0 ZWZ1bCwgbG9hZCBiYWxhbmNlciBzZWVtcyB0byBtZSB0byBiZSBhbg0KPj4+YWNjZXB0YWJsZQ0K Pj4+ID4+PiA+PiA+aW1wb3NpdGlvbi4NCj4+PiA+Pj4gPj4gPg0KPj4+ID4+PiA+PiA+WW91cnMs DQo+Pj4gPj4+ID4+ID5Kb2VsDQo+Pj4gPj4+ID4+ID4NCj4+PiA+Pj4gPj4gPk9uIDcvMTAvMTQs IDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4gPj4+ID4+ID4+IFBhcnQgb2Yg bXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IEkgYW0gdHJ5aW5nIHRvIG1ha2UgdGhpcyB3b3JrDQo+ Pj4gPj4+ID4+c2Vuc2libHkNCj4+PiA+Pj4gPj4gPj4gaW4gYSBtb3JlIG9yY2hlc3RyYXRlZCBl bnZpcm9ubWVudC4gIEkgZXhwZWN0IHRoYXQgdGhlIHNlcnZpY2UNCj4+PiA+Pj4gPj4gPj4gZnVu Y3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJpbGl0aWVzLCB3aWxs DQo+Pj5iZQ0KPj4+ID4+PiA+PiA+PiBvcmNoZXN0cmF0ZWQgYW5kIGluc3RhbGxlZC4gIEkgZXhw ZWN0IHRoZSBzZXJ2aWNlIGNoYWlucyB0byBiZQ0KPj4+ID4+PiA+PmRyaXZlbiBieQ0KPj4+ID4+ PiA+PiA+PiBCU1MgdG9vbHMgdGhhdCBkZWZpbmUgb2ZmZXJpbmdzIHRvIGNsaWVudHMsIGFuZCBl bmFibGUNCj4+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4+ID4+PiA+PiA+PiBmcm9tIHRoZXNlLiAg SSBleHBlY3Qgc2VydmljZSBwYXRocyB0byBiZSBoZWF2aWx5IHBvbGljeQ0KPj4+ZHJpdmUuDQo+ Pj4gPj4+ID4+ID4+DQo+Pj4gPj4+ID4+ID4+IEkgY2FuIHNlZSBob3cgdG8gbWFrZSBhbGwgb2Yg dGhhdCB3b3JrIGluIGFuIGFyY2h0aWVjdHVyZQ0KPj4+ZHJpdmVuDQo+Pj4gPj4+YnkNCj4+PiA+ Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmliZWQgc2VydmljZSBwYXRo cy4gIEl0IGlzDQo+Pj5oYXJkZXINCj4+PiA+Pj50bw0KPj4+ID4+PiA+PnNlZQ0KPj4+ID4+PiA+ PiA+PiBob3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UgYWxs b3cgbW9yZQ0KPj4+ID4+PiA+PiBkeW5hbWljaXR5DQo+Pj4gPj4+ID4+ID4+IGluIHRoZSBuZXR3 b3JrIGJlaGF2aW9yLg0KPj4+ID4+PiA+PiA+Pg0KPj4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0 aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3BlY3RpdmUgSSBkZXNjcmliZWQgaXMNCj4+Pm91dHNpZGUN Cj4+PiA+Pj5vZg0KPj4+ID4+PiA+PnRoZQ0KPj4+ID4+PiA+PiA+PiBzY29wZSBvZiB0aGUgd29y a2luZyBncm91cC4gIGl0IGlzIG5vdCBzb21ldGhpbmcgd2UgYXJlDQo+Pj50YXNrZWQgdG8NCj4+ PiA+Pj4gPj5hZ3JlZQ0KPj4+ID4+PiA+PiA+Pm9uLg0KPj4+ID4+PiA+PiA+PiBTbyBJIGRvIG5v dCBjbGFpbSB0aGF0IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGEgY2VydGFpbg0KPj4+ ID4+PndheS4NCj4+PiA+Pj4gPj5pdA0KPj4+ID4+PiA+PiA+PiBpcyBqdXN0IHRoZSBwZXJzcGVj dGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4+PiA+Pj4gPj4gPj4NCj4+PiA+Pj4g Pj4gPj4gWW91cnMsDQo+Pj4gPj4+ID4+ID4+IEpvZWwNCj4+PiA+Pj4gPj4gPj4NCj4+PiA+Pj4g Pj4gPj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4+ID4+PiA+PiA+ Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNlIGluc3Rh bmNlcw0KPj4+IHRoYXQNCj4+PiA+Pj4gPj5uZWVkcw0KPj4+ID4+PiA+PiA+Pj4+dG8NCj4+PiA+ Pj4gPj4gPj4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQsIHBvdGVudGlh bGx5IGV2ZW4NCj4+PmFjcm9zcw0KPj4+ID4+PmRhdGENCj4+PiA+Pj4gPj4gPj4+PiBjZW50ZXJz IHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoIGFuZA0KPj4+ ID4+PiBjb21wbGV4DQo+Pj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0 aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhDQo+Pj4gPj4+ZGlmZmljdWx0DQo+Pj4gPj4+ ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+Pj4gPj4+ID4+ID4+Pg0KPj4+ID4+ PiA+PiA+Pj4gSSdtIGN1cmlvdXMgYXMgdG8gd2h5IHRoYXQgaXMgbW9yZSBjb21wbGljYXRlZCB0 aGFuIGR5bmFtaWMNCj4+PiA+Pj4gcm91dGluZywNCj4+PiA+Pj4gPj4gPj4+IGh5cGVyLXNjYWxl IGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxsIG9mIHdoaWNoDQo+Pj5hcmUN Cj4+PiA+Pj4gPj5iaWdnZXINCj4+PiA+Pj4gPj4gPj4+IHByb2JsZW1zIHRoYXQgaGF2ZSBiZWVu IHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8NCj4+PiA+Pj4gPj4gPj4+DQo+Pj4g Pj4+ID4+ID4+PiBJdCBhbHNvIHNlZW1zIHRoYXQgaWYgaXQgcmVhbGx5IGlzIG1vcmUgY29tcGxp Y2F0ZWQsIHRoYXQgaXMNCj4+PmENCj4+PiA+Pj5nb29kDQo+Pj4gPj4+ID4+ID4+PiBzaWduIHRo YXQgaXQgaXMgdG9vIGNvbXBsaWNhdGVkLg0KPj4+ID4+PiA+PiA+Pj4NCj4+PiA+Pj4gPj4gPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+Pj4gPj4gPj4+ IEZyb206IEpvZWwgTS4gSGFscGVybiBbam1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+PiA+Pj4gPj4g Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDk6NDUgUE0NCj4+PiA+Pj4gPj4gPj4+ IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsg SWFuDQo+Pj4gPj4+U21pdGg7DQo+Pj4gPj4+ID4+ID4+PiBzZmNAaWV0Zi5vcmcNCj4+PiA+Pj4g Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4+ID4+PiA+PiA+Pj4NCj4+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJj aGl0ZWN0dXJhbCBpc3N1ZS4gIEFuZCBvbmUgdGhhdCBJIHdvdWxkIHByZWZlcg0KPj4+d2UNCj4+ PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4g dHJ5aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4+aW1wbGVtZW50YXRpb25zLg0KPj4+ID4+ PiA+PiA+Pj4gQmVjYXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRy b2wNCj4+PnJlcXVpcmVtZW50cw0KPj4+ID4+PmFuZA0KPj4+ID4+PiA+PiB0aGUNCj4+PiA+Pj4g Pj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+PiA+Pj4gPj4gPj4+DQo+Pj4gPj4+ID4+ ID4+PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0 YW5jZXMNCj4+PnRoYXQNCj4+PiA+Pj4gbmVlZHMNCj4+PiA+Pj4gPj4gdG8NCj4+PiA+Pj4gPj4g Pj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50aWFsbHkgZXZl biBhY3Jvc3MNCj4+PiA+Pj5kYXRhDQo+Pj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdpdGhpbiBhbiBh ZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMgbGFyZ2UgZW5vdWdoIGFuZA0KPj4+ID4+PmNvbXBsZXgN Cj4+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQgdGhhdCBpbnRvIGVhY2gg U0ZGIHNlZW1zIGxpa2UgYQ0KPj4+ID4+PmRpZmZpY3VsdA0KPj4+ID4+PiA+PiA+Pj4gYXJjaGl0 ZWN0dXJlIHRvIHJlYWxpemUuDQo+Pj4gPj4+ID4+ID4+Pg0KPj4+ID4+PiA+PiA+Pj4gWW91cnMs DQo+Pj4gPj4+ID4+ID4+PiBKb2VsDQo+Pj4gPj4+ID4+ID4+Pg0KPj4+ID4+PiA+PiA+Pj4gQnV0 IGl0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+PiA+Pj4gPj4gPj4+DQo+Pj4gPj4+ID4+ID4+PiBP biA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4+ID4+PiA+PiA+Pj4+IFRo aXMgaXMgdGhlIGNydXggb2YgbXkgaXNzdWUuICAgSXMgdGhlIGVuZCB0byBlbmQgc2VsZWN0aW9u DQo+Pj5vZg0KPj4+ID4+PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBwZXJmb3JtZWQg Y2VudHJhbGx5IChwZXJoYXBzIGJ5IHRoZQ0KPj4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+Pj4gPj4+ ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVyaGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQgc3Vi c2VxdWVudGx5DQo+Pj50aGUNCj4+PiA+Pj4gPj5TRkZzKT8NCj4+PiA+Pj4gPj4gPj4+PiBTdWNo IHNlbGVjdGlvbiBpcyBub3QgZXF1aXZhbGVudCB0byByZWNsYXNzaWZpY2F0aW9uLiAgIEFuZA0K Pj4+ID4+PnN1cmVseSwNCj4+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwg aXNzdWUgYW5kIG5vdCByZWxlZ2F0ZWQgdG8NCj4+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRp b24iLg0KPj4+ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8g ZmF2b3IgdGhlIGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4gdGhvdWdoDQo+Pj4gYQ0KPj4+ID4+ PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNoYWluIGRlZmluaXRpb25zIGFuZCBw ZXJoYXBzIGxvY2FsDQo+Pj4gPj4+ID4+c2VsZWN0aW9uDQo+Pj4gPj4+ID4+ID4+Pj4gcG9saWN5 KSBpcyByZXF1aXJlZCBhdCB0aG9zZSBkaXN0cmlidXRlZCBkZWNpc2lvbiBwb2ludHMuDQo+Pj5U aGlzDQo+Pj4gPj4+ID4+ID4+Pj4gYXBwcm9hY2ggZG9lcyBub3QgcmVxdWlyZSBhbiBlbmQtdG8t ZW5kIHBhdGggaWQgYXQgYWxsLg0KPj4+TXkNCj4+PiA+Pj4gPj4gPj4+PiByYXRpb25hbGUgZm9y IGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbiBieQ0KPj4+ID4+PiA+ PmluY3JlYXNlZA0KPj4+ID4+PiA+PiA+Pj4+IHJlc2lsaWVuY3kgb3ZlciB0aGUgZ2xvYmFsIHBh dGggaWQgYXBwcm9hY2guICAgV2l0aCBhIGdsb2JhbA0KPj4+ID4+PnBhdGgNCj4+PiA+Pj4gPj5p ZA0KPj4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25zaWRlciBmYWlsdXJlIG9mIGFuIGluc3Rh bmNlIGFuZCBuZWVkaW5nIHRvDQo+Pj5hbHRlcg0KPj4+ID4+PnRoZQ0KPj4+ID4+PiA+PiA+Pj4+ IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNoIGFuZCBldmVyeSBhZmZlY3RlZCBlbmQtdG8t ZW5kDQo+Pj4gPj4+cGF0aC4NCj4+PiA+Pj4gPj4gPj4+Pg0KPj4+ID4+PiA+PiA+Pj4+IFJvbg0K Pj4+ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXyBGcm9tOiBzZmMNCj4+PiA+Pj4gPj4gPj4+PiBbc2ZjLWJvdW5jZXNA aWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIEhhbHBlcm4gRGlyZWN0DQo+Pj4gPj4+ID4+ID4+ Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tXSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwg MjAxNA0KPj4+IDY6MTUNCj4+PiA+Pj4gUE0NCj4+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5j QGFvbC5jb207IEkuU21pdGhARjUuY29tOyBzZmNAaWV0Zi5vcmcgU3ViamVjdDoNCj4+PiBSZToN Cj4+PiA+Pj4gPj4gPj4+PiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJh bGFuY2Vycw0KPj4+ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJj aGl0ZWN0dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0bw0KPj4+ID4+PiA+Pmlu Zmx1ZW5jZQ0KPj4+ID4+PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3VsZCBkbyBy ZWNsYXNzaWZpY2F0aW9uIGF0IHRoZSBleGl0DQo+Pj5mcm9tDQo+Pj4gPj4+ID4+ID4+Pj4gU0Yx Lg0KPj4+ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4gUGFydCBvZiB0aGUgZ29hbCBpcyB0 byBrZWVwIHRoZSBkaWZmZXJlbnQgZnVuY3Rpb25zDQo+Pj5sb2dpY2FsbHkNCj4+PiA+Pj4gPj4g Pj4+PiBzZXBhcmF0ZSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4gY2xlYXJseSBkZXNjcmliZSBob3cg dGhleQ0KPj4+IGNob29zZQ0KPj4+ID4+PnRvDQo+Pj4gPj4+ID4+ID4+Pj4gY29tcG9zZSB0aGVt IGZvciAic2VydmljZSIgZGVsaXZlcnkuDQo+Pj4gPj4+ID4+ID4+Pj4NCj4+PiA+Pj4gPj4gPj4+ PiBZb3VycywgSm9lbA0KPj4+ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4gT24gNy8xMC8x NCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20gd3JvdGU6DQo+Pj4gPj4+ID4+ID4+Pj4+IEkg ZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQgc3VnZ2VzdHMgYW55DQo+ Pj5zb3J0DQo+Pj4gPj4+b2YNCj4+PiA+Pj4gPj4gPj4+Pj4gbGltaXQuIEhvd2V2ZXIsIGl0IGRv ZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUNCj4+PnBhdGgNCj4+PiA+Pj4oYWxs DQo+Pj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0 aW9uLiAgSSBiZWxpZXZlIHRoaXMNCj4+PiA+Pj5tZWFucw0KPj4+ID4+PiA+PiA+Pj4+PiBlaXRo ZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhlIGNsYXNzaWZpZXIgY2hvb3NlcyBhDQo+ Pj5TRg0KPj4+ID4+PiA+PkNoYWluDQo+Pj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQg dGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiAgSW4gYW55IGNhc2UsDQo+Pj50aGUNCj4+PiA+Pj4g Pj4gPj4+Pj4gbGFuZ3VhZ2UgZG9lcyBzZWVtIHRvIHByb2hpYml0IGEgbW9yZSBkeW5hbWljIFNG UCB3aGVyZQ0KPj4+IFNGSShuKQ0KPj4+ID4+PiBpcw0KPj4+ID4+PiA+PiA+Pj4+PiBkZXRlcm1p bmVkIGF0IHRoZSBTRkkobi0xKSBob3AuICBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LA0KPj4+dGhp cw0KPj4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRlcmVkICJicmFuY2hp bmciIHRvIGEgbmV3IFNGUCBhcw0KPj4+ID4+PiBvcHBvc2VkDQo+Pj4gPj4+ID4+IHRvDQo+Pj4g Pj4+ID4+ID4+Pj4+IGNob29zaW5nIGFuZCB0aGVuIGZvcndhcmRpbmcgdG8gdGhlIHNlbGVjdGVk IGluc3RhbmNlIG9mDQo+Pj50aGUNCj4+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1 cnJlbnQgU0ZDLg0KPj4+ID4+PiA+PiA+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+PiBkcmFmdC1tZXJn ZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlz IGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+Pj5uZWNlc3NhcnkNCj4+PiA+ Pj50bw0KPj4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2Yg U0ZzIHRoYXQgd2lsbCBiZSB1c2VkLA0KPj4+YW5kIHRvDQo+Pj4gPj4+ID4+ID4+Pj4+PiBjcmVh dGUgdGhlIHNlcnZpY2UgdG9wb2xvZ3kgZm9yIHRoYXQgU0ZDIHVzaW5nIFNGJ3MNCj4+Pm5ldHdv cmsNCj4+PiA+Pj4gPj4gPj4+Pj4+IGxvY2F0b3IuICBUaHVzLCBpbnN0YW50aWF0aW9uIG9mIHRo ZSBTRkMgcmVzdWx0cyBpbiB0aGUNCj4+PiA+Pj5jcmVhdGlvbg0KPj4+ID4+PiA+PiA+Pj4+Pj4g b2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+Pj5mb3J3 YXJkaW5nDQo+Pj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhlIFNGQy4gSW4gb3Ro ZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUNCj4+PiA+Pj4gPj4gPj4+Pj4+IGluc3RhbnRpYXRpb24g b2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+ IFRoZSBTRkMgYXJjaGl0ZWN0dXJlIHN1cHBvcnRzIHJlY2xhc3NpZmljYXRpb24gKG9yDQo+Pj5u b24taW5pdGlhbA0KPj4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuICBB cyBwYWNrZXRzIHRyYXZlcnNlIGFuIFNGUCwNCj4+PiA+Pj4gPj4gPj4+Pj4+IHJlY2xhc3NpZmlj YXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZCBieSBhDQo+Pj4gPj4+ID4+ID4+ Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRoIGEgc2VydmljZQ0K Pj4+ZnVuY3Rpb24uDQo+Pj4gPj4+ID4+ID4+Pj4+PiBSZWNsYXNzaWZpY2F0aW9uIG1heSByZXN1 bHQgaW4gdGhlIHNlbGVjdGlvbiBvZiBhIG5ldw0KPj4+U0ZQLCBhbg0KPj4+ID4+PiA+PiA+Pj4+ Pj4gdXBkYXRlIG9mIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhLCBvciBib3RoLiAgVGhpcyBpcw0K Pj4+cmVmZXJyZWQNCj4+PiA+Pj50bw0KPj4+ID4+PiA+PiA+Pj4+Pj4gYXMgImJyYW5jaGluZyIu DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+ Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+DQo+Pj4gPj4+DQo+Pj4NCj4+Pj4+Pj4+Pj4+Pj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4tLS0NCj4+PiA+Pj4+Pj4+Pj4+LS0NCj4+PiA+Pj4gPj4+Pj4+ Pi0tDQo+Pj4gPj4+ID4+ID4+Pj4+LS0NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+ Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5j b208SS5TbWl0aEBGNS5jb20+DQo+Pj4gPj4+ID4+ID4+Pj4+ICpUbzogKkpvZWwgSGFscGVybiBE aXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpvZWwNCj4+PiBNLg0KPj4+ID4+PiA+ PiA+Pj4+Pg0KPj4+ID4+PiA+Pg0KPj4+ID4+Pg0KPj4+ID4+Pj4+SGFscGVybjxqbWhAam9lbGhh bHBlcm4uY29tPixodWFuZ0BzY2UuY2FybGV0b24uY2E8aHVhbmdAc2NlLg0KPj4+ID4+PiA+PiBj YXJsZXRvbi4NCj4+PiA+Pj4gPj4gPj4+Pj5jYT4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZz4N Cj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+ PiA+Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4+PiA+Pj4gPj4g Pj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZA0KPj4+QmFsYW5jZXJzDQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+IEFjdHVh bGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ ID4+ID4+Pj4+IElmIHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMg KGFuZCB0aGF0IGlzDQo+Pj4gPj4+d2hhdA0KPj4+ID4+PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZs b3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNoYWlucyBpcw0KPj4+ID4+PnByZWNvbmNl aXZlZA0KPj4+ID4+PiA+PiA+Pj4+PiBhcyBhbiBhYnN1cmQgaWRlYSwgdGhlbiB0aGUgYXJjaGl0 ZWN0dXJlIGJ1cmRlbmVkIHdpdGggdGhhdA0KPj4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9u Lg0KPj4+ID4+PiA+PiA+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+PiBUaGVyZSBoYXMgdG8gYmUgc29t ZSBwb2ludCBvZiBhaW0sIHNvbWUgZGVncmVlIG9mDQo+Pj5hc3BpcmF0aW9uDQo+Pj4gdG8NCj4+ PiA+Pj4gPj4gPj4+Pj4gc2NhbGUgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIGxpZmVzcGFu IG9mIHRoZQ0KPj4+YXJjaGl0ZWN0dXJlDQo+Pj4gPj4+LQ0KPj4+ID4+PiA+PiA+Pj4+PiB5b3Ug ZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgaXQgaXMsIGJ1dCBieSBzYXlpbmcgdGhhdCBhbg0KPj4+ ID4+PmFyYml0cmFyeQ0KPj4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3Un cmUgY3JlYXRpbmcgLSBldmVuIGlmIGl0IGlzbid0DQo+Pj4gPj4+ID4+aW50ZW50aW9uYWwNCj4+ PiA+Pj4gPj4gPj4+Pj4gLSBhIGxpbWl0IHRoYXQgaW5mbHVlbmNlcyBkZWNpc2lvbnMgdGhhdCBo YXZlIGxhc3RpbmcNCj4+PmltcGFjdHMNCj4+PiA+Pj4gPj4gPj4+Pj4gcmVnYXJkaW5nIHNjYWxl LW91dCwgZmFpbHVyZSBtaXRpZ2F0aW9uLCBlbGFzdGljaXR5LA0KPj4+YWRkcmVzcw0KPj4+ID4+ PiA+PiA+Pj4+PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxl bSBJJ20gbm90DQo+Pj4gPj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdp dGguDQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+ DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4N Cj4+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBq b2VsaGFscGVybi5jb21dDQo+Pj5TZW50Og0KPj4+ID4+PiA+PiA+Pj4+PiBUaHVyc2RheSwgSnVs eSAxMCwgMjAxNCA1OjA0IFBNIFRvOiBJYW4gU21pdGg7IEpvZWwgTS4NCj4+PiBIYWxwZXJuOw0K Pj4+ID4+PiA+PiA+Pj4+PiBodWFuZ0BzY2UuY2FybGV0b24uY2E7IHNmY0BpZXRmLm9yZyBTdWJq ZWN0OiBSZTogW3NmY10NCj4+PlNlcnZpY2UNCj4+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5zLCBQYXRo cywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+ IElhbiwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4gdGhpcw0K Pj4+cmVnYXJkLg0KPj4+ID4+PkkNCj4+PiA+Pj4gPj5hbQ0KPj4+ID4+PiA+PiA+Pj4+PiBub3Qg cmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRpb24NCj4+PnByb2hp Yml0DQo+Pj4gPj4+ID4+ID4+Pj4+IGRlcGxveW1lbnRzIGluIHRoZSBzcGVjaWZpYyBmYXNoaW9u LiBJIGFtIG9iamVjdGluZyB0bw0KPj4+SHVhbmcncw0KPj4+ID4+PiA+PiA+Pj4+PiByZWFkaW5n IG9mIG15IG5vdGUgYXMgc2F5aW5nIHRoYXQgc3VjaCBkZXBsb3ltZW50cyBhcmUNCj4+PiByZXF1 aXJlZA0KPj4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNodGllY3R1cmUuDQo+Pj4gPj4+ ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkg YW0gbm90IHRyeWluZyB0byBwcm9oaWJpdCBzdWNoDQo+Pj4gPj4+ID4+ID4+Pj4+IHRoaW5ncy4g V2hldGhlciB0aGV5IGFyZSBhIGdvb2QgaWRlYSBvciBub3QgZGVwZW5kcyB1cG9uDQo+Pj4gbWFu eQ0KPj4+ID4+PiA+PiA+Pj4+PiBmYWN0b3JzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBX Ry4gSSBoYXBwZW4gdG8gdGhpbmsNCj4+PnRoYXQNCj4+PiA+Pj4gPj50aGV5DQo+Pj4gPj4+ID4+ ID4+Pj4+IGFyZSB1c3VhbGx5IGEgYmFkIGlkZWEuDQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ ID4+ID4+Pj4+IEJ1dCB0aGUgYXJjaHRpZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRl bXB0aW5nIHRvDQo+Pj5rbm93DQo+Pj4gPj4+d2hhdA0KPj4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQg aXMgbm90IGVwbG95YWJsZS4NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4gWW91 cnMsIEpvZWwNCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwg NTowMSBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4+ID4+PiA+PiA+Pj4+Pj4gSSBkaXNhZ3JlZS4N Cj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2ZSBz dGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlIHRlbnMgb2YNCj4+PiA+Pj5taWxsaW9ucw0KPj4+ ID4+PiA+PiA+Pj4+Pj4gb2YNCj4+PiA+Pj4gPj4gPj4+Pj4gY29uY3VycmVudCBmbG93cyBpbiBi b3RoIGFjY2VzcyBuZXR3b3JrIGFuZCBkYXRhIGNlbnRlcg0KPj4+ID4+PiA+PiA+Pj4+PiBlbnZp cm9ubWVudHMgdG9kYXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZSB0aGF0IGluIHRoZQ0K Pj4+ID4+PiA+PiA+Pj4+PiBDbG91ZC9JUHY2L01vYmlsaXR5L1dlYjIuMC9Jb1Qgd29ybGQgb2Yg dG9tb3Jyb3cgeW91IGFyZQ0KPj4+IG9ubHkNCj4+PiA+Pj4gPj4gZ29pbmcNCj4+PiA+Pj4gPj4g Pj4+Pj4gdG8gaGF2ZSBzbWFsbCBudW1iZXJzIG9mIHNlcnZpY2UgY2hhaW5zIHdpdGggZXF1YWxs eSBzbWFsbA0KPj4+ID4+PiBudW1iZXJzDQo+Pj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2ZSBzZXJ2 aWNlIHBhdGhzPw0KPj4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+IFlvdXIgc291 bmRzIHRvbyBtdWNoIGxpa2UgIm5vIG9uZSB3aWxsIGV2ZXIgbmVlZCBtb3JlIHRoYW4NCj4+PiA+ Pj4gNjRLIg0KPj4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+Pj4gPj4+ID4+ID4+Pj4+IGNvbWZvcnQu DQo+Pj4gPj4+ID4+ID4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJvbTogc2ZjDQo+Pj4g Pj4+ID4+ID4+Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBKb2VsIE0u IEhhbHBlcm4NCj4+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2VsaGFscGVybi5jb21dDQo+Pj4gPj4+ ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCA0OjQ2IFBNIFRvOg0KPj4+ ID4+Pmh1YW5nQHNjZS5jYXJsZXRvbi5jYTsNCj4+PiA+Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9y ZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQNCj4+PiA+Pj5M b2FkDQo+Pj4gPj4+ID4+ID4+Pj4+PiBCYWxhbmNlcnMNCj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4g Pj4+ID4+ID4+Pj4+PiBObywgaXQgd2lsbCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBk ZXBsb3kgdGhlDQo+Pj4gPj4+YXJjaHRpZXR1cmUNCj4+PiA+Pj4gPj4gPj4+Pj4+IHBhcnRpY3Vs YXJseSBiYWRseSwgdGhleSB3aWxsIGV4Y2VlZCB0aGUgbGltaXRzIG9mIHRoZWlyDQo+Pj4gPj4+ ID4+ID4+Pj4+PiBkZXZpY2VzLiBUaGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3Vj aCBhYnN1cmQgdXNlDQo+Pj4gb2YNCj4+PiA+Pj4gPj4gPj4+Pj4+IHNlcnZpY2UgcGF0aHMuIFNp bmNlIEkgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZQ0KPj4+ID4+PiA+PiA+Pj4+Pj4g YXJjaGl0ZWN0dXJhbCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlIGFyY2hpdGVjdHVyZSBkb2Vz DQo+Pj4gPj4+cGVybWl0DQo+Pj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4+ID4+PiA+ PiA+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+IFBsZWFzZSBkbyBub3QgcmVhZCBteSBzYXlpbmcg dGhhdCB0aGUgYXJjaHRpZWN0dXJlIHBlcm1pdHMNCj4+PiA+Pj4gPj4gPj4+Pj4+IHNvbWV0aGlu ZyBhcyBzYXlpbmcgaXQgaXMgZWl0aGVyIGRlaXNyZWQgb3IgcmVxdWlyZWQgYnkNCj4+PnRoZQ0K Pj4+ID4+PndvcmsuDQo+Pj4gPj4+ID4+ID4+Pj4+PiBJdCBpc24ndC4NCj4+PiA+Pj4gPj4gPj4+ Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+PiBZb3VycywgSm9lbA0KPj4+ID4+PiA+PiA+Pj4+Pj4NCj4+ PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcgSHVhbmcgd3Jv dGU6DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4gSWYgeW91IG5lZWQgdG8gc3VwcG9ydCAxMDAgc2Vydmlj ZSBjaGFpbnMsIGl0IHdpbGwgbWVhbg0KPj4+ID4+PiA+PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0 aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRpbmcgdGFibGUNCj4+Pm9mIGENCj4+PiA+ Pj4gPj4gPj4+Pj4+PiBjb3JlIHJvdXRlci4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4+ID4+PiA+ PiA+Pj4+Pj4+IENoYW5nDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+PiBP biAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4gPj4+ID4+ ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFuZ2Ugb2YgZGVwbG95bWVudHMs IGZyb20gMQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZp Y2UgcGF0aHMuIEkgd291bGQgaG9wZSB0aGF0DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+IG9wZXJhdG9y cyBhcmUgcHJlcGFyZWQgZm9yIHRoZSBjb21wbGV4aXRpZXMgaWYgdGhleQ0KPj4+Y2hvb3NlDQo+ Pj4gPj4+dG8NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2Fk IGJhbGFuY2luZyBhbmQgaW4gc3RlYWQNCj4+PiBwcm92aXNpb24NCj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ID4+PiA+ PiA+Pj4+Pj4+PiBZb3VycywgSm9lbA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+ Pj4+Pj4+PiBPbiA3LzEwLzE0LCA0OjA2IFBNLCBOQVBJRVJBTEEsIE1BUklBIEggd3JvdGU6DQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVsLA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEhvdyBtYW55IHBhdGggaWRlbnRpZmllcnMgdGhlcmUgd2lsbCBiZSBmb3Ig YSA0IGhvcA0KPj4+IHNlcnZpY2UNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAg aW5zdGFuY2VzIGF0IGVhY2ggaG9wPw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE1hcmlhDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9m DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqUGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNk YXksIEp1bHkgMTAsIDIwMTQNCj4+PjM6MDMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoq IEx1Y3kgeW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tOw0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnOw0KPj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gbWlrZWJpYW5jQGFvbC5jb20gKlN1YmplY3Q6KiBSZTogW3NmY10gU2Vydmlj ZSBDaGFpbnMsDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJz DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTHVjeSwNCj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29uY3VyLCBh cyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9y d2FyZGluZy4gScK5ZA0KPj4+ID4+PiA+PiA+Pj4+PiBtYWtlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1c2VkIHRvDQo+ Pj4gZGVyaXZlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5k IGFzc29jaWF0ZWQgdHJhbnNwb3J0Lg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEl0IGlzIF9ub3RfIHRoZSB0cmFuc3BvcnQsIGJ1dCByYXRoZXIgaXMgdXNlZCB0 byBzaW1wbHkNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIHBhdGgg KG9yIGdyYXBoKSB0aGF0IHBhY2tldHMgbXVzdA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhdmVy c2UuIEJ5IGhhdmluZyBhIHBhdGggaWRlbnRpZmllciwgdGhlIGV4YWN0DQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBpbmRpcmVjdGlvbiB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3Igb24g dGhpcw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVt ZW50ZWQuIFRoZSBwYXRoDQo+Pj4gaWRlbnRpZmllcg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJv dmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRoYXQgbG9va3VwIGNhbg0KPj4+IHJl c3VsdA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2Vp Z2h0ZWQpIHRyYW5zcG9ydCBuZXh0DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBob3AocykuDQo+Pj4g Pj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bA0KPj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQg QU0sIEx1Y3kgeW9uZw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPGx1Y3kueW9uZ0BodWF3ZWkuY29t DQo+Pj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiB3cm90ZToNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEFncmVlLiBUaGUgYXJjaC4g ZG9jIHNob3VsZCBub3QgbWFuZGF0ZSBvbmx5IHVzZSBvZiB0aGUNCj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJkaW5nDQo+Pj5h Y3Rpb25zLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kN Cj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gT2YqbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPj4+ID4+PiAqU2VudDoqVGh1 cnNkYXksDQo+Pj4gPj4+ID4+IEp1bHkNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6 MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPiAqU3ViamVjdDoqUmU6IFtzZmNdIFNl cnZpY2UNCj4+PkNoYWlucywNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZS0s DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIG1lcmdlZCBk cmFmdCBjYWxscyBvdXQgZXhwbGljaXRseSBhIHNlcnZpY2UgcGF0aA0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0byBkZXJp dmUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZvcndhcmRpbmcgYWN0aW9ucy4NCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMgc3lzdGVtIHRv IGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mDQo+Pj4gZXZlcnkNCj4+PiA+Pj4gPj4gPj4+Pj4g YXZhaWxhYmxlIFNGQw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBwYXRocyB3aXRo aW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPj4+ID4+PiA+PiA+Pj4+PiByZXF1aXJl ZC9qdXN0aWZpZWQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5vciBwb3NzaWJsZSBpbiB2YXJpb3Vz IGRlcGxveW1lbnQgY29udGV4dHMuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91bGQgcmVseSBvbiB0aGUgcGllY2Ug b2YNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+Pj4gPj4+ID4+ID4+Pj4+IHRo YXQgd2lsbA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgcHJlc2VudCBpbiBhbGwgZGVwbG95bWVu dHM6IHRoYXQgaXMgdGhlIG9uZSByZXF1aXJlZA0KPj4+IHRvDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBzdHJ1Y3R1cmUgYSBzZXJ2aWNlIGNoYWluLiBIb3cgdGhhdCBpbmZvcm1hdGlvbiBpcw0KPj4+ dXNlZCB0bw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mZXIgZm9yd2FyZGluZw0KPj4+ID4+PiA+ PiA+Pj4+PiBhY3Rpb25zDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVu dGVkIGRpc2N1c3Npb24uDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gQ2hlZXJzLA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE1l ZA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+Pj4gPj4+ID4+ID4+Pj4+ IGRlKm1pa2ViaWFuY0Bhb2wuY29tDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOm1pa2Vi aWFuY0Bhb2wuY29tPiAqRW52b3nDqSA6Km1lcmNyZWRpIDkNCj4+PiBqdWlsbGV0DQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb20NCj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3Jn DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6 IFtzZmNdIFNlcnZpY2UNCj4+PkNoYWlucywNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBh bmQgTG9hZCBCYWxhbmNlcnMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBT Rg0KPj4+IENoYWluDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+PiA+Pj4gPj4gPj4+ Pj4gUGF0aD8NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IE90aGVyIHRoYW4gY2xhcmlmeWluZyB0aGUg ZGVmaW5pdGlvbiBzbyB0aGF0IGl0J3MNCj4+PmNsZWFyIHRvDQo+Pj4gPj4+ID4+ID4+Pj4+IHRo b3NlIG5vdA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0 IHNlZW1zIHRoYXQgZXZlcnlvbmUgYWdyZWVzDQo+Pj5vbg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g dGhlc2UgdGVybXMuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g VG8gbWUsIHRoZSBvbmUgcG9pbnQgdGhhdCBpcyBzdGlsbCB1bmNsZWFyIGlzIHdoZXRoZXINCj4+ Pml0IGlzDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8g dWx0aW1hdGVseSBzcGVjaWZ5IHdoYXQNCj4+PnRoZSBJRA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g b2YgdGhlIFNGQyBIZWFkZXINCj4+PiA+Pj4gPj4gPj4+Pj4gc2hvdWxkDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiByZWZlcmVuY2UgKHRoZSBjaGFpbiBvciB0aGUgcGF0aCksIG9yIGlmIHRoaXMgZHJh ZnQNCj4+PnNpbXBseQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZW5kcyB0byBsZWF2ZSB0aGF0 IGFtYmlndW91cywgYWxsb3dpbmcgb3RoZXIgZHJhZnRzDQo+Pj50bw0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gZGljdGF0ZSB0aGUgbWVjaGFuaXNtcyBmb3IgZm9yd2FyZGluZyBiYXNlZCBvbiBjaGFp biBvcg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcGF0aCBhbmQgdGhlIGNob2ljZSBvZiBjaGFpbiBv cg0KPj4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBuZWdv dGlhdGVkIGluIHRoZSBjb250cm9sLXBsYW5lLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0 IHdvdWxkIGhhdmUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlcXVpcmUgdGhhdCBib3RoIFNGUCBh bmQgU0ZDIGJlIHN1cHBvcnRlZCAob3IgbWFrZQ0KPj4+IG9uZQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gcmVxdWlyZWQgYW5kIHRoZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZSB2ZW5kb3Jz DQo+Pj4gb25seQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVy cyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+DQo+Pj4gPj4+DQo+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4tLS0NCj4+PiA+Pj4+Pj4+Pj4+LS0NCj4+ PiA+Pj4gPj4+Pj4+Pi0tDQo+Pj4gPj4+ID4+ID4+Pj4+LS0NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+ PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb208am1oQGpvZWxoYWxw ZXJuLmNvbQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoq c2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpz ZmNAaWV0Zi5vcmclM2NzZmNAaWV0Zi5vcmc+PiAqU2VudDoqVHVlc2RheSwNCj4+PiBKdWx5DQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpTdWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcg dG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseSBhbnN3ZXINCj4+PmENCj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG51bWJlciBvZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0K Pj4+ID4+PiBwcm9wb3NlZA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWVyZ2VkIGFyY2h0aWVjdHVy ZSBkcmFmdC4gQXNzdW1pbmcgd2UgY2FuIGdldCB3b3JraW5nDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBncm91cCBhZ3JlZW1lbnQgb24gdGhlIGludGVudCwgd2Ugd2lsbCB3b3JrIHRvIGltcHJvdmUN Cj4+PiB0aGUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdo byBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4NCj4+PnRoZQ0KPj4+IFdHDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+Pj4gPj4+ ID4+ID4+Pj4+IHdvcmtpbmcNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGludGVuZHMuDQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQnV0IHdoYXQgZG8gd2Ug aW50ZW5kPyBJIHdpbGwgdHJ5IHRvIGV4cGxhaW4gbXkNCj4+PnBlcnNvbmFsDQo+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gdGhpcyByZWdhcmQsIGl0IGlzIGltcG9ydGFu dCB0byBrZWVwIGluIG1pbmQgdGhhdA0KPj4+d2hhdA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2Ug YXJlIGRlZmluaW5nIGlzIHRoZSBkYXRhIHBsYW5lIGFyY2hpdGVjdHVyZS4gV2UgYXJlDQo+Pj4g bm90DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhdHRlbXB0aW5nIHRvIGRlZmluZSB0aGUgYXJjaGl0 ZWN0dXJlIGZvciB0aGUgZW50aXJlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzb2x1dGlvbiBmb3Ig c2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBhc3MNCj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywgdmlydHVh bA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbWFjaGluZSBhbmQgaW1hZ2UgbWFuYWdlbWVudCwgYW5k IG1hbnkgb3RoZXINCj4+PiBhc3BlY3RzLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IEFzIGEgcmVzdWx0IHRoZXJlIGFyZSBtYW55IHRoaW5ncyB3aGljaCBjbGVh cmx5IG5lZWQgdG8NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGV4aXN0IGluIHRoZSBsYXJnZXIgc3lz dGVtLCBidXQgd2hpY2ggYXJlIGRlYWx0IHdpdGgNCj4+PmFib3ZlDQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiB3aGVyZSB3ZSBhcmUNCj4+PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBhbmQgYXJlIG5vdCBkaXJlY3RseSByZXF1aXJlZCBieSB0aGUgd29yayB3 ZSBhcmUgZG9pbmcuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g SW4gb3JkZXIgdG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcyBJDQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+Pj4gPj4+ID4+ID4+Pj4+IHRoZW0sDQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2lu Zy4gVGhlcmUgYXJlIGF0DQo+Pj5sZWFzdA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhyZWUgZGlm ZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4gYW5kIHdpbGwNCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGludGVyYWN0IHdpdGggc2VydmljZSBjaGFpbmluZy4gVGhlcmUgcHJvYmFibHkg YXJlDQo+Pj5tb3JlLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhlIHBvaW50IG9mIHRoZSBhcmNo dGllY3R1cmUgaXMgdG8gcGVybWl0IGFsbCBvZg0KPj4+dGhlc2UsDQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+Pj4gPj4+ ID4+ID4+Pj4+IGJlIHVzZWQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4N Cj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAxKSBMb2FkIGJhbGFu Y2luZyBhcyBhIHNlcnZpY2UgcHJvdmlkZWQgdG8gdGhlIGVuZA0KPj4+dXNlci4NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCByZWNlaXZlcyB1c2Vy IHBhY2tldHMsDQo+Pj5hbmQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vZGlmaWVzIHRoZW0gKG9y DQo+Pj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBvciAu Li4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlciBzZXJ2aWNlDQo+Pj5pbnN0YW5jZQ0KPj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMgcGFja2V0LiBUaGlzIGlzIGFu IGltcG9ydGFudA0KPj4+c2VydmljZQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8g YmUgYWJsZSB0byBpbmNsdWRlIGluIHNlcnZpY2UgY2hhaW5pbmcuDQo+Pj5JdCdzDQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBvbiBob3cgc2Vy dmljZQ0KPj4+IGNoYWluaW5nIGlzDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQg aGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4+PmFyY2h0aWVjdHVyZS4NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+ICBGcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGUzcnNwZWN0aXZlIGl0IGlzIHNp bXBseSBhDQo+Pj4gPj4+ID4+ID4+Pj4+IHNlcnZpY2UNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGZ1 bmN0aW9uIHdoaWNoIG1heSBtb2RpZnkgdGhlIHVuZGVybHlpbmcgcGFja2V0Lg0KPj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxv YWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUgY2FuDQo+Pj5oYXZlDQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiB3aGF0DQo+Pj4gPj4+ID4+ID4+Pj4+IGFwcGVhcnMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBhIHNpbmdsZSBwb2ludA0K Pj4+b2YNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNvbnRhY3QNCj4+PiA+Pj4gPj4gPj4+Pj4gZm9y IGENCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24sIGJ1dCBp cyBhY3R1YWxseSBkZWxpdmVyZWQNCj4+PmJ5IGENCj4+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlv biBvZg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlydHVhbCBvciBwaHlzaWNhbCBtYWNoaW5lcywg cG9zc2libHkgaW5jbHVkaW5nIG9uZSBvcg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBs b2FkIGJhbGFuY2VycyAoZm9yIGV4YW1wbGUgdXNpbmcgVlJSUC1saWtlDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0ZWNobmlxdWVzIHRvIHNoYXJlIGEgTUFDIGFkZHJlc3MuKSBtb3N0bHksIHRoaXMg aXMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBkYXRhIHBsYW5lDQo+Pj5tZWNoYW5pc21zLg0KPj4+IEl0DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4+bWVj aGFuaXNtcywNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUg Zm9yIHNjYWxlLWluLCBzY2FsZS1vdXQsIGFuZA0KPj4+dm0NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJtaXR0aW5nDQo+ Pj50aGlzDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpcyBsYXJnZWx5IHRoYXQgd2UgbmVlZCB0byBi ZSBjYXJlZnVsIHRoYXQgb3VyDQo+Pj50ZXJtaW5vbG9neQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g ZG9lcyBub3QgbGVhZA0KPj4+ID4+PiA+PiA+Pj4+PiByZWFkZXJzIHRvDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMykgVGhlcmUgY2FuIGFsc28gYmUgbG9hZCBiYWxhbmNp bmcgZG9uZSBieSBzZWxlY3RpbmcNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRocyBm b3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+PnRyYWZmaWMNCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMuIFdlIHdvdWxkIG5vdCB3YW50IHRvIHJl cXVpcmUgdGhhdA0KPj4+YQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5j dGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2UgaW4gdGhlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBuZXR3b3JrLg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0 IGlzIG9mIGNvdXJzZSB0aGUgY2FzZSB0aGF0IHRoZXNlIG1heSBiZSBjb21iaW5lZC4gSQ0KPj4+ IHRlbmQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvDQo+Pj4gPj4+ID4+ID4+Pj4+IHJlZmVyIHRv DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgY29sbGVjdGlvbiBvZiBlbnRpdGllcyB0aGF0IGFw cGVhciB0byBzZXJ2aWNlDQo+Pj5jaGFpbmluZw0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXMgYSBz aW5nbGUgcG9pbnQgYXMgYSBjbHVzdGVyLiBOb3QgYmVjYXVzZSBjbHVzdGVyIGlzDQo+Pj5hDQo+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBnb29kIHRlcm0uIEJ1dCBiZWNhdXNlIEkgZG8gbm90IGhhdmUg YW5vdGhlciBvbmUuIFRodXMsDQo+Pj4gdGhlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBv ZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+PiA+Pj4gPj4gPj4+Pj4gaXMgdG8NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRpcmVjdCBkaWZmZXJlbnQgc3Vic2V0cyBvZiB0cmFmZmljIHRvIGRpZmZl cmVudA0KPj4+c2luZ3VsYXINCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9yIGNsdXN0ZXJlZCBzZXJ2 aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgcGxhY2VzIGluDQo+Pj50aGUNCj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IG5ldHdvcmsuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkgdGFsayBhYm91 dA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2VydmljZSBwYXRoLyBT ZXJ2aWNlIGNoYWluIGlzIGENCj4+PiBzZXF1ZW5jZQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gb2Yg bG9naWNhbCBmdW5jdGlvbnMgdG8gYmUgYXBwbGllZCB0byBhIHN1YnNldCBvZg0KPj4+cGFja2V0 cy4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIHRoYXQg c29tZSBzdWJzZXQgb2YgdHJhZmZpYw0KPj4+aXMNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdl dCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rpb24sIGFuZCBmaXJld2FsbA0KPj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gd2hpbGUgYSBkaWZmZXJlbnQgc3Vic2V0IGlzIHRvIGdvIGRpcmVjdGx5 IHRvIHRoZSBjYWNoZQ0KPj4+ID4+PiA+PiA+Pj4+PiB3aXRob3V0DQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiB2aXNpdGluZyBhbnkgb3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCBpcyBub3QgZW5vdWdoIGluZm9ybWF0 aW9uIHRvIGRpcmVjdCB0aGUgcGFja2V0cy4gQQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2Vydmlj ZSBwYXRoIGlzLCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4+PmxvY2F0aW9ucw0K Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdvcmsuIFRob3NlIGxvY2F0aW9ucyB3aWxs IGJlIHNpbmd1bGFyIG9yDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBm dW5jdGlvbiBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4+Pm1heSBiZQ0KPj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYWRkcmVzc2VkIGJ5IElQIGFkZHJlc3MuIFRoZXkgbWF5IGJlIGFkZHJlc3NlZCBh cyBwb3J0cw0KPj4+IG9uDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbiBTRkYuIFRoZXJlIGFyZSBt YW55IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhlDQo+Pj5sb2NhdGlvbnMNCj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0cnVjdHVy ZSBhbmQNCj4+PiB0aGUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYW5zcG9ydC4NCj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pj4gIEZyb20gdGhlIHBvaW50IG9mIHZp ZXcgb2YgdGhlIHdvcmsgb2YgdGhlIFNGQyBncm91cCwNCj4+PiB3ZQ0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFibGUgdG8gdGFsayBhYm91 dCB0aGUgaGlnaCBsZXZlbCBhYnN0cmFjdGlvbiwgdGhlDQo+Pj5zZXJ2aWNlDQo+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVzIHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVl ZCB0byB0YWxrDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRhdGEgcGF0 aCBwYWNrZXRzIHdpbGwgdGFrZSBpbiB0aGUNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsu DQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU2V2ZXJhbCBvZiB0 aGUgY29tbWVudHMgaGF2ZSBzYWlkICJidXQgdGhlIHdob2xlIHBhdGgNCj4+PiBtYXkNCj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IG5vdCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVj dHVyZSBkZWFscw0KPj4+d2l0aA0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhhdCBpc3N1ZSBpbiB0 d28gd2F5cy4gRmlyc3QsIGFzIG5vdGVkIGluIGl0ZW0gKDIpIG9uDQo+Pj5sb2FkDQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBiYWxhbmNlcnMgYWJvdmUsIHRoZXJlIGNhbiBiZSBkZWNpc2lvbnMgYW5k IGJlaGF2aW9ycw0KPj4+IHdoaWNoDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxl IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+Pj5tdWNoDQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiB0aGUgc2FtZSB3YXkgdGhhdCBicmlkZ2luZyB3aXRoaW4gYSBMQU4gaXMg bGFyZ2VseQ0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2Vl biBMQU5zLikgVGhlIG90aGVyIHByb3Zpc2lvbg0KPj4+IHdlDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBtYWtlIGlzDQo+Pj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJl Y2xhc3NpZmljYXRpb24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4+PiBuZWNlc3Nh cnkuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tldHMgdG8gYSBu ZXcgY2hhaW4uIEJhc2VkIG9uDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBhdmFp bGFibGUgYXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Lg0KPj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3 aGF0IHdlIGFyZSBhZnRlci4gSWYgaXQNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGRvZXMsIGFuZCBp ZiB0aGUgaW50ZW50IGlzIGFjY2VwdGFibGUgdG8gdGhlIHdvcmtpbmcNCj4+PiBncm91cCwNCj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0IHdoYXQgYWRkaXRpb25hbCB3b3Jk cyBhcmUgbmVlZGVkIHRvDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhl IHdvcmtpbmcgZ3JvdXAgZGlzYWdyZWUgd2l0aCB0aGUNCj4+PiBpbnRlbnQsDQo+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0byBtYXRjaCB0aGUgd29y a2luZw0KPj4+Z3JvdXANCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMg aXMgc3RpbGwgdW5jbGVhciwgSSBhbSBub3Qgc3VyZQ0KPj4+d2hhdCB0bw0KPj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gWW91cnMsIEpvZWwNCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IHNmYw0KPj4+ID4+PiA+PiBtYWlsaW5nDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBzZmMNCj4+PiA+Pj4gPj4gbWFpbGluZw0KPj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBzZmMNCj4+PiA+Pj4gPj4gbWFpbGluZw0KPj4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0Bp ZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4+ID4+PiA+PiA+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4+ ID4+PiA+PiBtYWlsaW5nDQo+Pj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcNCj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gPj4+ID4+ID4+ Pj4+Pj4NCj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+PiA+Pj4gbWFpbGluZw0K Pj4+ID4+PiA+PiBsaXN0DQo+Pj4gPj4+ID4+ID4+Pj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4g Pj4+ID4+ID4+Pj4+DQo+Pj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNmYw0KPj4+ID4+PiBtYWlsaW5nDQo+Pj4gPj4+ID4+IGxp c3QNCj4+PiA+Pj4gPj4gPj4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gPj4+ID4+ID4+Pj4NCj4+PiA+Pj4gPj4gPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+PiBtYWls aW5nDQo+Pj4gPj4+ID4+IGxpc3QNCj4+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+PiA+Pj4gPj4gPj4+Pg0KPj4+ ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHNmYw0KPj4+IG1haWxpbmcNCj4+PiA+Pj4gPj4gbGlzdA0KPj4+ID4+PiA+PiA+Pj4+IHNm Y0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ ID4+PiA+PiA+Pj4+DQo+Pj4gPj4+ID4+ID4+Pg0KPj4+ID4+PiA+PiA+Pg0KPj4+ID4+PiA+PiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+ PiA+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gPj4+ID4+ID4+IHNmY0BpZXRmLm9yZw0KPj4+ ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ ID4+PiA+PiA+Pg0KPj4+ID4+PiA+PiA+DQo+Pj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+PiA+PiA+c2ZjIG1haWxpbmcgbGlz dA0KPj4+ID4+PiA+PiA+c2ZjQGlldGYub3JnDQo+Pj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+PiA+Pg0KPj4+ID4+PiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+PiA+PiBzZmMg bWFpbGluZyBsaXN0DQo+Pj4gPj4+ID4+IHNmY0BpZXRmLm9yZw0KPj4+ID4+PiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4+Pg0KPj4+ID4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+PiBzZmMg bWFpbGluZyBsaXN0DQo+Pj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4+ID4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ID4NCj4+PiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+c2ZjIG1haWxpbmcgbGlzdA0K Pj4+ID5zZmNAaWV0Zi5vcmcNCj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCg0K From nobody Mon Jul 14 23:46:43 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FD61B2824 for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 23:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0hwdPYbbNMNX for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 23:46:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E183C1B2822 for <sfc@ietf.org>; Mon, 14 Jul 2014 23:46:38 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id BCABE19018D; Tue, 15 Jul 2014 08:46:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 950CA15805A; Tue, 15 Jul 2014 08:46:36 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 08:46:37 +0200 From: <mohamed.boucadair@orange.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zugr0Rw Date: Tue, 15 Jul 2014 06:46:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330032536@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> In-Reply-To: <CFE98FD3.2E64E%jguichar@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330032536OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.15.53920 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/o4JtsOMg_CHkSd-_w1bZnBzJ_Vs Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 06:46:42 -0000 --_000_787AE7BB302AE849A7480A190F8B9330032536OPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, The use of SFP is inappropriate. A path is a result of forwarding policies = that may not be known in advance. I'm for using the chain itself as the main abstract level and optionally al= low for customized forwarding polices to be provisioned to a subset of invo= lved SFFs if needed. These policies are meant to guide the instance selecti= on process for deployments requiring such complexity. So, I disagree with this proposal. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : lundi 14 juillet 2014 19:48 =C0 : sfc@ietf.org Objet : [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_787AE7BB302AE849A7480A190F8B9330032536OPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Courier New"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:10.0pt;font-fam= ily:"Courier New";color:#1F497D">Hi Jim,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-size:10.0pt;font-fam= ily:"Courier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">The use of SFP is inappropriate. A path is a= result of forwarding policies that may not be known in advance.<o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">I’m for using the chain itself as the = main abstract level and optionally allow for customized forwarding polices = to be provisioned to a subset of involved SFFs if needed. These policies are meant to guide the instance selection process for deplo= yments requiring such complexity. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">So, I disagree with this proposal.<o:p></o:p= ></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">Cheers,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">Med<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"FR" style=3D"font-size:10.0pt;font-= family:"Tahoma","sans-serif"">De :</span></b><span= lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma","= ;sans-serif""> sfc [mailto:sfc-bounces@ietf.org] <b>De la part de</b> Jim Guichard (jguichar)<br> <b>Envoy=E9 :</b> lundi 14 juillet 2014 19:48<br> <b>=C0 :</b> sfc@ietf.org<br> <b>Objet :</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </div> </body> </html> --_000_787AE7BB302AE849A7480A190F8B9330032536OPEXCLILM23corpor_-- From nobody Tue Jul 15 00:13:50 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42261B282A for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 00:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WQP0oAkU-e1w for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 00:13:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA1F1A0311 for <sfc@ietf.org>; Tue, 15 Jul 2014 00:13:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0613F2DC0BE; Tue, 15 Jul 2014 09:13:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9CBC9238048; Tue, 15 Jul 2014 09:13:39 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 09:13:39 +0200 From: <mohamed.boucadair@orange.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAzJTw Date: Tue, 15 Jul 2014 07:13:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933003256F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933003256FOPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.14.171220 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2jf93Zan1RMBAkQ6kpofuQoxX4I Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 07:13:45 -0000 --_000_787AE7BB302AE849A7480A190F8B933003256FOPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ron, all, This is much better. I'm for using the chain as the abstract level that will infer the forwardin= g actions by default + allow policies to constraint forwarding actions in s= ome nodes (if/when needed). A "path" will be the consequence of these forwa= rding actions. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Ron Parker Envoy=E9 : lundi 14 juillet 2014 20:22 =C0 : Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@ietf.org Objet : Re: [sfc] SFC Terminology / Concepts There is one missing word in my text. Please replace my proposed text wit= h: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the instance select= ion of one or more of the service functions in the SFC. Any SFC may have = any number of C-SFC's associated with it." Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, July 14, 2014 2:16 PM To: David Allan I; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.or= g> Subject: Re: [sfc] SFC Terminology / Concepts I have a counter-proposal that eliminates the term "SFP" entirely: "The Service Function Chain (SFC) provides a fully abstract view of the ser= vice functions to be invoked and the order in which they are to be invoked = for some particular flow or set of flows, without concern of actual service= function instance selection. The Constrained-SFC (C-SFC) further allows = for policy constraints to be added to the SFC affecting the selection of on= e or more of the service functions in the SFC. Any SFC may have any numbe= r of C-SFC's associated with it." Thanks. Ron "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of David Allan I Sent: Monday, July 14, 2014 2:03 PM To: Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter.... D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k." I'd like to ask the WG as a whole, if this clarification is something that = we can get consensus on. If so, I'll ask Joel to provide specific text, tha= t reflects the above, for inclusion in the merged architecture draft. Thank You, Jim --_000_787AE7BB302AE849A7480A190F8B933003256FOPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Texte de bulles Car"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.TextedebullesCar {mso-style-name:"Texte de bulles Car"; mso-style-priority:99; mso-style-link:"Texte de bulles"; font-family:"Tahoma","sans-serif";} span.EmailStyle23 {mso-style-type:personal-reply; font-family:"Courier New"; color:#993366;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366">Hi Ron, all,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366">This is much better. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366">I’m for using the chain as the abstrac= t level that will infer the forwarding actions by default + allow polic= ies to constraint forwarding actions in some nodes (if/when needed). A “path” will be the consequence of these forwarding = actions. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366">Cheers,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366">Med<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#993366"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"FR" style=3D"font-size:10.0pt;font-= family:"Tahoma","sans-serif"">De :</span></b><span= lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma","= ;sans-serif""> sfc [mailto:sfc-bounces@ietf.org] <b>De la part de</b> Ron Parker<br> <b>Envoy=E9 :</b> lundi 14 juillet 2014 20:22<br> <b>=C0 :</b> Ron Parker; David Allan I; Jim Guichard (jguichar); sfc@i= etf.org<br> <b>Objet :</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span><= /p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">There is one missing word= in my text.   Please replace my proposed text with:<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the instance sele= ction of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s assoc= iated with it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ron Parker<br> <b>Sent:</b> Monday, July 14, 2014 2:16 PM<br> <b>To:</b> David Allan I; Jim Guichard (jguichar); <a href=3D"mailto:sfc@ie= tf.org"> sfc@ietf.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I have a counter-proposal= that eliminates the term “SFP” entirely:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“The Service Functi= on Chain (SFC) provides a fully abstract view of the service functions to b= e invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service functio= n instance selection.   The Constrained-SFC (C-SFC) further allow= s for policy constraints to be added to the SFC affecting the selection of = one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated w= ith it.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    Ron<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif"">From:</span></b><span style=3D"font-= size:11.0pt;font-family:"Calibri","sans-serif""> sfc [<= a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>David Allan I<br> <b>Sent:</b> Monday, July 14, 2014 2:03 PM<br> <b>To:</b> Jim Guichard (jguichar); <a href=3D"mailto:sfc@ietf.org">sfc@iet= f.org</a><br> <b>Subject:</b> Re: [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I like that text, it stri= kes a good balance where an implementation has the option of making scale a= nd resiliency a local matter….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Monday, July 14, 2014 10:48 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] SFC Terminology / Concepts<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Dear WG= :<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">There h= as been much debate over the last few days with regards to SFC concepts. To= try and form some consensus around terminology and concepts used to descri= be the architecture in the merged architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">"T= he SFP provides a level of indirection between the fully abstract notion of= service path as a sequence of functions to be delivered, and the fully spe= cified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allo= wing the control components to specify the use of this level of indirection= , the deployment may choose the degree of SFF instance selection authority = that is delegated to the network.”<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">I’= ;d like to ask the WG as a whole, if this clarification is something that w= e can get consensus on. If so, I’ll ask Joel to provide specific text= , that reflects the above, for inclusion in the merged architecture draft.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Thank Y= ou,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black"><o:p>&n= bsp;</o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;color:black">Jim<o:p= ></o:p></span></p> </div> </div> </div> </body> </html> --_000_787AE7BB302AE849A7480A190F8B933003256FOPEXCLILM23corpor_-- From nobody Tue Jul 15 00:21:45 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B531B282B for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 00:21:44 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 G4B-Keq4ssoU for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 00:21:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395221B2824 for <sfc@ietf.org>; Tue, 15 Jul 2014 00:21:40 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id B1B5D190224; Tue, 15 Jul 2014 09:21:38 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 402E315805E; Tue, 15 Jul 2014 09:21:35 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 09:21:35 +0200 From: <mohamed.boucadair@orange.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//4wKAgAAU+ACAAN4W8A== Date: Tue, 15 Jul 2014 07:21:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> In-Reply-To: <53C434F4.7050208@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ELZZb_jO9RoprtMgrgGBNNyt4L4 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 07:21:44 -0000 Hi Joel, As mentioned in several messages, I'm personally for the use of the chain i= tself is the main information to be conveyed in packets to drive forwarding= actions.=20 I can understand that an identifier can be assigned to a path that is known= in advance, but if that path is not known I'm not sure how an identifier c= an be assigned to it! Joel, the use of "path" is really inappropriate to refer to distributed ins= tance selection process for packets bound to a given SFC.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: lundi 14 juillet 2014 21:52 >=C0=A0: Tom Taylor; sfc@ietf.org; Ron Parker >Objet=A0: Re: [sfc] SFC Terminology / Concepts > >The most likely realization of the architecture would be that the SFP >assignment is recorded in an identifier which travels with the packet. > >Some folks seem to not want the architecture to mandate that. > >Yours, >Joel > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: >> Your text scares me because it introduces some new concepts and >> assumptions. >> >> I'd rather go with Joel's formulation. Clarifying question on that: am I >> right in seeing the implication that when control assigns an SFP, the >> assignment is recorded by an identifier wwhich travels with the packet? >> >> Tom Taylor >> >> On 14/07/2014 2:22 PM, Ron Parker wrote: >>> There is one missing word in my text. Please replace my proposed text >>> with: >>> >>> "The Service Function Chain (SFC) provides a fully abstract view of the >>> service functions to be invoked and the order in which they are to be >>> invoked for some particular flow or set of flows, without concern of >>> actual service function instance selection. The Constrained-SFC >>> (C-SFC) further allows for policy constraints to be added to the SFC >>> affecting the instance selection of one or more of the service function= s >>> in the SFC. Any SFC may have any number of C-SFC's associated with >it." >>> >>> Thanks. >>> >>> Ron >> ... >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >>> *Sent:* Monday, July 14, 2014 2:03 PM >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>> >>> I like that text, it strikes a good balance where an implementation has >>> the option of making scale and resiliency a local matter.. >>> >>> D >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Monday, July 14, 2014 10:48 AM >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>> *Subject:* [sfc] SFC Terminology / Concepts >>> >>> Dear WG: >>> >>> There has been much debate over the last few days with regards to SFC >>> concepts. To try and form some consensus around terminology and concept= s >>> used to describe the architecture in the merged architecture draft, Joe= l >>> has kindly suggested the following: >>> >>> "The SFP provides a level of indirection between the fully abstract >>> notion of service path as a sequence of functions to be delivered, and >>> the fully specified notion of exactly what instances of SFFs the packet >>> will visit when it actually traverses the network. By allowing the >>> control components to specify the use of this level of indirection, the >>> deployment may choose the degree of SFF instance selection authority >>> that is delegated to the network." >>> >>> I'd like to ask the WG as a whole, if this clarification is something >>> that we can get consensus on. If so, I'll ask Joel to provide specific >>> text, that reflects the above, for inclusion in the merged architecture >>> draft. >>> >>> Thank You, >>> >>> Jim >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Tue Jul 15 01:49:21 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47C51A0375 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 01:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 yHZZaWTjZ17v for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 01:49:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C203A1A001A for <sfc@ietf.org>; Tue, 15 Jul 2014 01:49:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB13554; Tue, 15 Jul 2014 08:49:13 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 09:49:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 16:49:07 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA Date: Tue, 15 Jul 2014 08:49:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="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/XS8dW5ORlo731Y5fSwzDJc8cRHU Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 08:49:19 -0000 Hi Med, IMHO, the architecture should allow the classifier to specify 1) a partial SFP (i.e., some SFFs along that partial SFP need to locally de= termine the appropriate SFF for the next SF); 2) a complete SFP (i.e., the SFF for each SF in the SFC has been determined= by the centralized node); 3) an SFC (i.e., each SFF along the final SFP needs to locally determine th= e appropriate SFF for the next SF).=20 In fact, case 3) could be looked as an extreme of case 1). Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Tuesday, July 15, 2014 3:22 PM > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Hi Joel, >=20 > As mentioned in several messages, I'm personally for the use of the chain= itself is > the main information to be conveyed in packets to drive forwarding action= s. >=20 > I can understand that an identifier can be assigned to a path that is kno= wn in > advance, but if that path is not known I'm not sure how an identifier can= be > assigned to it! >=20 > Joel, the use of "path" is really inappropriate to refer to distributed i= nstance > selection process for packets bound to a given SFC. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf.or= g; Ron > >Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts > > > >The most likely realization of the architecture would be that the SFP > >assignment is recorded in an identifier which travels with the packet. > > > >Some folks seem to not want the architecture to mandate that. > > > >Yours, > >Joel > > > > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: > >> Your text scares me because it introduces some new concepts and > >> assumptions. > >> > >> I'd rather go with Joel's formulation. Clarifying question on that: > >> am I right in seeing the implication that when control assigns an > >> SFP, the assignment is recorded by an identifier wwhich travels with t= he > packet? > >> > >> Tom Taylor > >> > >> On 14/07/2014 2:22 PM, Ron Parker wrote: > >>> There is one missing word in my text. Please replace my proposed te= xt > >>> with: > >>> > >>> "The Service Function Chain (SFC) provides a fully abstract view of > >>> the service functions to be invoked and the order in which they are > >>> to be invoked for some particular flow or set of flows, without conce= rn of > >>> actual service function instance selection. The Constrained-SFC > >>> (C-SFC) further allows for policy constraints to be added to the SFC > >>> affecting the instance selection of one or more of the service functi= ons > >>> in the SFC. Any SFC may have any number of C-SFC's associated with > >it." > >>> > >>> Thanks. > >>> > >>> Ron > >> ... > >> > >> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan > >>> I > >>> *Sent:* Monday, July 14, 2014 2:03 PM > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >>> > >>> I like that text, it strikes a good balance where an implementation > >>> has the option of making scale and resiliency a local matter.. > >>> > >>> D > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > >>> (jguichar) > >>> *Sent:* Monday, July 14, 2014 10:48 AM > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* [sfc] SFC Terminology / Concepts > >>> > >>> Dear WG: > >>> > >>> There has been much debate over the last few days with regards to > >>> SFC concepts. To try and form some consensus around terminology and > >>> concepts used to describe the architecture in the merged > >>> architecture draft, Joel has kindly suggested the following: > >>> > >>> "The SFP provides a level of indirection between the fully abstract > >>> notion of service path as a sequence of functions to be delivered, > >>> and the fully specified notion of exactly what instances of SFFs the > >>> packet will visit when it actually traverses the network. By > >>> allowing the control components to specify the use of this level of > >>> indirection, the deployment may choose the degree of SFF instance > >>> selection authority that is delegated to the network." > >>> > >>> I'd like to ask the WG as a whole, if this clarification is > >>> something that we can get consensus on. If so, I'll ask Joel to > >>> provide specific text, that reflects the above, for inclusion in the > >>> merged architecture draft. > >>> > >>> Thank You, > >>> > >>> Jim > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 From nobody Tue Jul 15 02:33:58 2014 Return-Path: <meng.wei2@zte.com.cn> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420E1A037B; Tue, 15 Jul 2014 02:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 nejE1Frcg1Y2; Tue, 15 Jul 2014 02:33:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C9E101A0379; Tue, 15 Jul 2014 02:33:52 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 73D6312715AF; Tue, 15 Jul 2014 17:33:36 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 47B79CE06B7; Tue, 15 Jul 2014 17:33:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s6F9XRxk021178; Tue, 15 Jul 2014 17:33:27 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <OF5305A76D.233EFFF6-ON48257D16.0033771B-48257D16.00337AA0@LocalDomain> To: Xuxiaohu <xuxiaohu@huawei.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: <OFD5C5B29B.47046015-ON48257D16.0033DE4C-48257D16.00349316@zte.com.cn> From: meng.wei2@zte.com.cn Date: Tue, 15 Jul 2014 17:33:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-15 17:33:26, Serialize complete at 2014-07-15 17:33:26 Content-Type: multipart/alternative; boundary="=_alternative 0034931448257D16_=" X-MAIL: mse01.zte.com.cn s6F9XRxk021178 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/MAJASxecveXVlwFWhILU-_0NUq8 Cc: "sfc@ietf.org" <sfc@ietf.org>, sfc <sfc-bounces@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 09:33:55 -0000 This is a multipart message in MIME format. --=_alternative 0034931448257D16_= Content-Type: text/plain; charset="US-ASCII" Inline~ > Xuxiaohu <xuxiaohu@huawei.com> "sfc" <sfc-bounces@ietf.org> > > 2014-07-15 10:04 > > "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> > > > Re: [sfc] Proposed redefinition of SFP > > Hi Joel, > > > To rephrase this a bit (and then if folks agree on the concept, we > can pick the > > wording): > > > > The SFP provides a level of indirection between the fully abstractnotion of > > service path as a sequence of functions to be delivered, and the > fully specified > > notion of exactly what instances of SFFs the packet will visit > when it actually > > traverses the network. > > Instances of SFFs or instances of SF? [Wei]: I guess it means SF instances which are attached to SFFs. > > > By allowing the control components to specify the use of this > level of indirection, > > the deployment may choose the degree of SFF instance selection > authority that > > is delegated to the network. > > SFF instance or SF instance? > > Best regards, > Xiaohu > > > Yours, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --=_alternative 0034931448257D16_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Inline~</font> <br><font size=2><tt><br> > Xuxiaohu <xuxiaohu@huawei.com> </tt></font> <br><font size=2><tt>  "sfc" <sfc-bounces@ietf.org><br> > </tt></font> <br><font size=2><tt>> 2014-07-15 10:04</tt></font> <br> <br><font size=2><tt>> <br> > "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org></tt></font> <br><font size=2><tt>> <br> </tt></font> <br> <br><font size=2><tt>> <br> > Re: [sfc] Proposed redefinition of SFP</tt></font> <br><font size=2><tt>> <br> > Hi Joel,<br> > <br> > > To rephrase this a bit (and then if folks agree on the concept, we<br> > can pick the<br> > > wording):<br> > > <br> > > The SFP provides a level of indirection between the fully abstractnotion of<br> > > service path as a sequence of functions to be delivered, and the <br> > fully specified<br> > > notion of exactly what instances of SFFs the packet will visit <br> > when it actually<br> > > traverses the network.<br> > <br> > Instances of SFFs or instances of SF?</tt></font> <br> <br> <br> <br><font size=2><tt>[Wei]: I guess it means SF instances which are attached to SFFs.</tt></font> <br> <br> <br><font size=2><tt><br> > <br> > > By allowing the control components to specify the use of this <br> > level of indirection,<br> > > the deployment may choose the degree of SFF instance selection <br> > authority that<br> > > is delegated to the network.<br> > <br> > SFF instance or SF instance?<br> > <br> > Best regards,<br> > Xiaohu<br> > <br> > > Yours,<br> > > Joel<br> > > <br> > > _______________________________________________<br> > > sfc mailing list<br> > > sfc@ietf.org<br> > > https://www.ietf.org/mailman/listinfo/sfc<br> > <br> > _______________________________________________<br> > sfc mailing list<br> > sfc@ietf.org<br> > https://www.ietf.org/mailman/listinfo/sfc<br> </tt></font> --=_alternative 0034931448257D16_=-- From nobody Tue Jul 15 02:34:48 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF971B279E for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 02:34:46 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ALmOejME_fJg for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 02:34:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265BE1A037B for <sfc@ietf.org>; Tue, 15 Jul 2014 02:34:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5FCB2324045; Tue, 15 Jul 2014 11:34:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 396F427C064; Tue, 15 Jul 2014 11:34:42 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 11:34:42 +0200 From: <mohamed.boucadair@orange.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Ron Parker" <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//4wKAgAAU+ACAAN4W8P//+vAAgAAstoA= Date: Tue, 15 Jul 2014 09:34:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] 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.7.14.171220 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sprtb1JHSEWFma-U69jF7Kt9prw Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 09:34:46 -0000 Hi Xiaohu, Why a classifier will need specify a path a la ERO? Why it needs to have th= e full knowledge of the involved SF instances? Wouldn't this require the c= lassifier to be fed with additional information to drive its selection proc= ess? Is this complexity justified for all deployments? Cheers, Med >-----Message d'origine----- >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] >Envoy=E9=A0: mardi 15 juillet 2014 10:49 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor; sfc@ietf.o= rg; >Ron Parker >Objet=A0: RE: [sfc] SFC Terminology / Concepts > >Hi Med, > >IMHO, the architecture should allow the classifier to specify > >1) a partial SFP (i.e., some SFFs along that partial SFP need to locally >determine the appropriate SFF for the next SF); >2) a complete SFP (i.e., the SFF for each SF in the SFC has been determine= d >by the centralized node); >3) an SFC (i.e., each SFF along the final SFP needs to locally determine >the appropriate SFF for the next SF). > >In fact, case 3) could be looked as an extreme of case 1). > >Best regards, >Xiaohu > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Tuesday, July 15, 2014 3:22 PM >> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Hi Joel, >> >> As mentioned in several messages, I'm personally for the use of the chai= n >itself is >> the main information to be conveyed in packets to drive forwarding >actions. >> >> I can understand that an identifier can be assigned to a path that is >known in >> advance, but if that path is not known I'm not sure how an identifier ca= n >be >> assigned to it! >> >> Joel, the use of "path" is really inappropriate to refer to distributed >instance >> selection process for packets bound to a given SFC. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf.o= rg; Ron >> >Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts >> > >> >The most likely realization of the architecture would be that the SFP >> >assignment is recorded in an identifier which travels with the packet. >> > >> >Some folks seem to not want the architecture to mandate that. >> > >> >Yours, >> >Joel >> > >> > >> >On 7/14/14, 2:37 PM, Tom Taylor wrote: >> >> Your text scares me because it introduces some new concepts and >> >> assumptions. >> >> >> >> I'd rather go with Joel's formulation. Clarifying question on that: >> >> am I right in seeing the implication that when control assigns an >> >> SFP, the assignment is recorded by an identifier wwhich travels with >the >> packet? >> >> >> >> Tom Taylor >> >> >> >> On 14/07/2014 2:22 PM, Ron Parker wrote: >> >>> There is one missing word in my text. Please replace my proposed >text >> >>> with: >> >>> >> >>> "The Service Function Chain (SFC) provides a fully abstract view of >> >>> the service functions to be invoked and the order in which they are >> >>> to be invoked for some particular flow or set of flows, without >concern of >> >>> actual service function instance selection. The Constrained-SFC >> >>> (C-SFC) further allows for policy constraints to be added to the SFC >> >>> affecting the instance selection of one or more of the service >functions >> >>> in the SFC. Any SFC may have any number of C-SFC's associated with >> >it." >> >>> >> >>> Thanks. >> >>> >> >>> Ron >> >> ... >> >> >> >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan >> >>> I >> >>> *Sent:* Monday, July 14, 2014 2:03 PM >> >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts >> >>> >> >>> I like that text, it strikes a good balance where an implementation >> >>> has the option of making scale and resiliency a local matter.. >> >>> >> >>> D >> >>> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >> >>> (jguichar) >> >>> *Sent:* Monday, July 14, 2014 10:48 AM >> >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >> >>> *Subject:* [sfc] SFC Terminology / Concepts >> >>> >> >>> Dear WG: >> >>> >> >>> There has been much debate over the last few days with regards to >> >>> SFC concepts. To try and form some consensus around terminology and >> >>> concepts used to describe the architecture in the merged >> >>> architecture draft, Joel has kindly suggested the following: >> >>> >> >>> "The SFP provides a level of indirection between the fully abstract >> >>> notion of service path as a sequence of functions to be delivered, >> >>> and the fully specified notion of exactly what instances of SFFs the >> >>> packet will visit when it actually traverses the network. By >> >>> allowing the control components to specify the use of this level of >> >>> indirection, the deployment may choose the degree of SFF instance >> >>> selection authority that is delegated to the network." >> >>> >> >>> I'd like to ask the WG as a whole, if this clarification is >> >>> something that we can get consensus on. If so, I'll ask Joel to >> >>> provide specific text, that reflects the above, for inclusion in the >> >>> merged architecture draft. >> >>> >> >>> Thank You, >> >>> >> >>> Jim >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> sfc mailing list >> >>> sfc@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/sfc >> >>> >> >> >> >> _______________________________________________ >> >> sfc mailing list >> >> sfc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> > >> >_______________________________________________ >> >sfc mailing 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 Tue Jul 15 02:50:30 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0711B27E8 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 02:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 8Xi_hN6e6nFt for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 02:50:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066CA1B27F8 for <sfc@ietf.org>; Tue, 15 Jul 2014 02:50:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB20904; Tue, 15 Jul 2014 09:50:16 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 10:50:15 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 17:50:12 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcA== Date: Tue, 15 Jul 2014 09:50:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="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/sB7ViW_fxT0kMNfpF8Wc8g5WBZA Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 09:50:27 -0000 Hi Med, > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, July 15, 2014 5:35 PM > To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > Subject: RE: [sfc] SFC Terminology / Concepts >=20 > Hi Xiaohu, >=20 > Why a classifier will need specify a path a la ERO? Why it needs to have = the full In this way, the path selection process (i.e., selecting the appropriate SF= F for the next SF based on certain constraints) on the SFF is greatly simpl= ified. > knowledge of the involved SF instances? Wouldn't this require the classi= fier to > be fed with additional information to drive its selection process? Is thi= s The classifier could request the PCE to do the SFP computation (see http://= tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is no need for = the classifier to be fed with additional information.=20 > complexity justified for all deployments? As I have said, the architecture should allow the classifier to just impose= the SFC information on the selected packet as well. In this way, each SFF = needs to resolve the appropriate next SFF for the next SF to be executed. Best regards, Xiaohu > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 juill= et > >2014 10:49 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylo= r; > >sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology / Concepts > > > >Hi Med, > > > >IMHO, the architecture should allow the classifier to specify > > > >1) a partial SFP (i.e., some SFFs along that partial SFP need to > >locally determine the appropriate SFF for the next SF); > >2) a complete SFP (i.e., the SFF for each SF in the SFC has been > >determined by the centralized node); > >3) an SFC (i.e., each SFF along the final SFP needs to locally > >determine the appropriate SFF for the next SF). > > > >In fact, case 3) could be looked as an extreme of case 1). > > > >Best regards, > >Xiaohu > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >> mohamed.boucadair@orange.com > >> Sent: Tuesday, July 15, 2014 3:22 PM > >> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > >> Subject: Re: [sfc] SFC Terminology / Concepts > >> > >> Hi Joel, > >> > >> As mentioned in several messages, I'm personally for the use of the > >> chain > >itself is > >> the main information to be conveyed in packets to drive forwarding > >actions. > >> > >> I can understand that an identifier can be assigned to a path that is > >known in > >> advance, but if that path is not known I'm not sure how an identifier > >> can > >be > >> assigned to it! > >> > >> Joel, the use of "path" is really inappropriate to refer to > >> distributed > >instance > >> selection process for packets bound to a given SFC. > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halper= n > >> >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf= .org; > >> >Ron Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts > >> > > >> >The most likely realization of the architecture would be that the > >> >SFP assignment is recorded in an identifier which travels with the pa= cket. > >> > > >> >Some folks seem to not want the architecture to mandate that. > >> > > >> >Yours, > >> >Joel > >> > > >> > > >> >On 7/14/14, 2:37 PM, Tom Taylor wrote: > >> >> Your text scares me because it introduces some new concepts and > >> >> assumptions. > >> >> > >> >> I'd rather go with Joel's formulation. Clarifying question on that: > >> >> am I right in seeing the implication that when control assigns an > >> >> SFP, the assignment is recorded by an identifier wwhich travels > >> >> with > >the > >> packet? > >> >> > >> >> Tom Taylor > >> >> > >> >> On 14/07/2014 2:22 PM, Ron Parker wrote: > >> >>> There is one missing word in my text. Please replace my proposed > >text > >> >>> with: > >> >>> > >> >>> "The Service Function Chain (SFC) provides a fully abstract view > >> >>> of the service functions to be invoked and the order in which > >> >>> they are to be invoked for some particular flow or set of flows, > >> >>> without > >concern of > >> >>> actual service function instance selection. The Constrained-SFC > >> >>> (C-SFC) further allows for policy constraints to be added to the > >> >>> SFC affecting the instance selection of one or more of the > >> >>> service > >functions > >> >>> in the SFC. Any SFC may have any number of C-SFC's associated wi= th > >> >it." > >> >>> > >> >>> Thanks. > >> >>> > >> >>> Ron > >> >> ... > >> >> > >> >> > >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David > >> >>> Allan I > >> >>> *Sent:* Monday, July 14, 2014 2:03 PM > >> >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >> >>> > >> >>> I like that text, it strikes a good balance where an > >> >>> implementation has the option of making scale and resiliency a loc= al > matter.. > >> >>> > >> >>> D > >> >>> > >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim > >> >>> Guichard > >> >>> (jguichar) > >> >>> *Sent:* Monday, July 14, 2014 10:48 AM > >> >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >> >>> *Subject:* [sfc] SFC Terminology / Concepts > >> >>> > >> >>> Dear WG: > >> >>> > >> >>> There has been much debate over the last few days with regards to > >> >>> SFC concepts. To try and form some consensus around terminology > >> >>> and concepts used to describe the architecture in the merged > >> >>> architecture draft, Joel has kindly suggested the following: > >> >>> > >> >>> "The SFP provides a level of indirection between the fully > >> >>> abstract notion of service path as a sequence of functions to be > >> >>> delivered, and the fully specified notion of exactly what > >> >>> instances of SFFs the packet will visit when it actually > >> >>> traverses the network. By allowing the control components to > >> >>> specify the use of this level of indirection, the deployment may > >> >>> choose the degree of SFF instance selection authority that is dele= gated to > the network." > >> >>> > >> >>> I'd like to ask the WG as a whole, if this clarification is > >> >>> something that we can get consensus on. If so, I'll ask Joel to > >> >>> provide specific text, that reflects the above, for inclusion in > >> >>> the merged architecture draft. > >> >>> > >> >>> Thank You, > >> >>> > >> >>> Jim > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> sfc mailing list > >> >>> sfc@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/sfc > >> >>> > >> >> > >> >> _______________________________________________ > >> >> sfc mailing list > >> >> sfc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/sfc > >> >> > >> > > >> >_______________________________________________ > >> >sfc mailing 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 Tue Jul 15 03:08:48 2014 Return-Path: <hongyu.li@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAB21B283D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 03:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 unBLrmhG17lY for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 03:08:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E912F1A0379 for <sfc@ietf.org>; Tue, 15 Jul 2014 03:08:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB22864; Tue, 15 Jul 2014 10:08:42 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 11:08:41 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 18:08:35 +0800 From: "Hongyu Li (Julio)" <hongyu.li@huawei.com> To: Dave Dolson <ddolson@sandvine.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, David Allan I <david.i.allan@ericsson.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAALLEP//fQyAgAAEDACAAYZEgA== Date: Tue, 15 Jul 2014 10:08:34 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA4DAA2@SZXEMA509-MBX.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BA21@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C42183.8040605@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2E533@wtl-exchp-2.sandvine.com> In-Reply-To: <E8355113905631478EFF04F5AA706E9830A2E533@wtl-exchp-2.sandvine.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] 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/DOLDEqr983j-5kFV0dBAC_cxHck Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 10:08:46 -0000 SSdkIHZvdGUgZm9yIFNGUC4gRGVjb3VwbGluZyBTRlAgYW5kIFNGQyBpcyBtZWFuaW5nZnVsIGZv ciB0aGV5IGFyZSBkZXNjcmlwdGlvbnMgb2YgZGlmZmVyZW50IGxldmVscy4gV2hhdGV2ZXIgaG93 IGZhbmN5IHRoZSBkZWZpbml0aW9ucyBhcmUsIFNGQyBzaG91bGQgYmUgYW4gYWJzdHJhY3Rpb24g b2YgYSBzZXF1ZW5jZSBvZiBTRnMgd2l0aG91dCBhbnkgY3VlIG9mIGhvdyBpdCBpcyBpbXBsZW1l bnRlZCwgd2hpbGUgU0ZQIGlzIHRoZSBkYXRhcGF0aCBpbnN0YW50aWF0aW9uIGFuZCBpdCBpcyBk ZXNpZ24vaW1wbGVtZW50YXRpb24gcmVsYXRlZC4gDQoNClNvLCBpbiBnZW5lcmFsIEkgYWdyZWUg d2l0aCBKb2VsJ3MgcHJvcG9zYWwsIGJ1dCBJIGFsc28gc3VwcG9ydCBEYXZlJ3MgY29tbWVudCB0 byBjbGFyaWZ5IGl0IHNvbWVob3cuDQoNCkhvbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBEYXZlIERvbHNvbg0KU2VudDogVHVlc2RheSwgSnVseSAxNSwgMjAxNCAyOjQ0IEFNDQpUbzog Sm9lbCBNLiBIYWxwZXJuOyBOQVBJRVJBTEEsIE1BUklBIEg7IFJvbiBQYXJrZXI7IERhdmlkIEFs bGFuIEk7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KDQpJIGZlZWwgdGhhdCB0aGUgc3Rh bmRhcmRpemF0aW9uIGVmZm9ydCBuZWVkcyB0byBiZSBwcmltYXJpbHkgYWJvdXQgdGhlIGNvbmNy ZXRlICpwYXRoKiwgaW4gcGFydGljdWxhciB0aGUgcGFja2V0IGZvcm1hdHMgYW5kIHRoZSBydWxl cyBmb3IgaG93IFNGRnMgc2VsZWN0IHRoZSBuZXh0IGhvcChzKS4NCg0KQmVjYXVzZSBvZiB0aGF0 LCBJIHRoaW5rIHRoZSBwYXRocyBzaG91bGQgaGF2ZSBzaW1wbGUgbmFtZXMgKGNob29zaW5nIFNG UCB2cy4gQy1TRkMpLg0KDQpJdCBtYXkgYmUganVzdCBtZSwgYnV0IEkgdGhpbmsgd2UgbmVlZCB0 byB3b3JrIGJvdHRvbS11cC4NCkkgdGhpbmsgd2UgY2FuIGhhdmUgYSBzdGFuZGFyZCB3aXRob3V0 IHRoZSBhYnN0cmFjdCBwYXRocy4gVGhlIGFic3RyYWN0aW9uIGFsbW9zdCBmZWVscyBsaWtlIGl0 IGNvdWxkIGJlIHZlbmRvci1zcGVjaWZpYyBpbiB0aGUgQ2xhc3NpZmllci4NCg0KKEkgdGhpbmsg dGhlIGFic3RyYWN0aW9uIGlzIHZlcnkgdXNlZnVsIGF0IHRoZSBjb25maWd1cmF0aW9uIGxheWVy LCBidXQgbm90IGVzc2VudGlhbCB0byBoYXZpbmcgcGFja2V0cyBtb3ZpbmcuKQ0KDQoNCkkgc29t ZXdoYXQgYWJhc2hlZGx5IGFkbWl0IHRoYXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgSm9lbCBo YXMgd3JpdHRlbiwgZXNwZWNpYWxseSwgInRoZSBkZXBsb3ltZW50IG1heSBjaG9vc2UgdGhlIGRl Z3JlZSBvZiBTRkYgaW5zdGFuY2Ugc2VsZWN0aW9uIGF1dGhvcml0eSB0aGF0IGlzIGRlbGVnYXRl ZCB0byB0aGUgbmV0d29yay4iDQpXaGF0IGlzICJ0aGUgZGVwbG95bWVudCI/IFZlbmRvcj8gT3Bl cmF0b3I/IEFyZSB0aGUgbWFjaGluZXMgY29uZmlndXJpbmcgdGhlbXNlbHZlcz8NCldoYXQgaXMg Imluc3RhbmNlIHNlbGVjdGlvbiBhdXRob3JpdHkiID8NCg0KRG9lcyB0aGlzIHJlYWxseSBtZWFu LCAidGhlIG1hcHBpbmcgZnJvbSBhYnN0cmFjdCBTRkMgdG8gU0ZQIGlzIGxlZnQgdG8gaW1wbGVt ZW50YXRpb24uIiA/ICBBbmQgdGhlcmVmb3JlIFNGQy1DbGFzc2lmaWVyIHZlbmRvcnMgY2FuIGRl ZmluZSB2YXJpYXRpb25zIG9mIGFic3RyYWN0aW9uPw0KDQotRGF2ZQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0 IDI6MjkgUE0NClRvOiBOQVBJRVJBTEEsIE1BUklBIEg7IFJvbiBQYXJrZXI7IERhdmlkIEFsbGFu IEk7IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KDQpNYXJpYSwgd2hpbGUgdGhlIGNvbnN0 cmFpbnQgKGVpdGhlciBDLVNGQyBvciBTRlAsIHdoaWNoZXZlciB0ZXJtIHRoZSBTRw0KbGlrZXMp IG1heSBiZSBzZWxlY3Rpbmcgc3BlY2lmaWMgaW5zdGFuY2VzLCBpdCBtYXkgYmUgbW9yZSBnZW5l cmFsLg0KDQpUaGUgc2ltcGxlc3QgZXhhbXBsZSBpcyB0aGF0IGZvciBhIGdpdmVuIHNlcnZpY2Ug Y2hhaW4sIG9uZSBtaWdodCBoYXZlIG9uZSBTRlAgKG9yIEMtU0ZDKSB0aGF0IGNhdXNlcyB0aGUg ZW50aXJlIGNoYWluIHRvIGJlIGRlbGl2ZXJlZCBhdA0KZGF0YS1jZW50ZXItMSBhbmQgYSBzZWNv bmQgU0ZQIChvciBDLVNGQykgdGhhdCBjYXVzZXMgdGhlIGVudGlyZSBzZXJ2aWNlIGNoYWluIHRv IGJlIGRlbGl2ZXJlZCBhdCBkYXRhLWNlbnRlci0yLiAgRWFjaCBkYXRhIGNlbnRlciBoYXMgbWFu eSBpbnN0YW5jZXMgcnVubmluZy4gIEFuZCBtYXkgZXZlbiBoYXZlIG11bHRpcGxlIGNsdXN0ZXJz IGluIGRpZmZlcmVudCBQT0RzIHdpdGhpbiB0aGUgREMuDQpZZXMsIHRoZSBjb25zdHJhaW50IG1h eSBzYXkgdXNlIGV4YWN0bHkgdGhpcyBzcGVjaWZpYyBpc250YW5jZXMsIGJ1dCBpdCBkb2VzIG5v dCBoYXZlIHRvLg0KDQpZb3VycywNCkpvZWwNCg0KT24gNy8xNC8xNCwgMjoyMyBQTSwgTkFQSUVS QUxBLCBNQVJJQSBIIHdyb3RlOg0KPiBSb24sDQo+DQo+IHRoaXMgaXMgcHJldHR5IGdvb2QuDQo+ DQo+IEkgd291bGQgcHJvcG9zZSB0byByZS1waHJhc2UgdGhlIHNlY29uZCBzZW50ZW5jZSB0bzog IlRoZSANCj4gQ29uc3RyYWluZWQtU0ZDIChDLVNGQykgZnVydGhlciBhbGxvd3MgZm9yIHBvbGlj eSBjb25zdHJhaW50cyB0byBiZSANCj4gYWRkZWQgdG8gdGhlIFNGQyBhZmZlY3RpbmcgdGhlIHNl bGVjdGlvbiBvZiBvbmUgb3IgbW9yZSAqKnNwZWNpZmljKiogDQo+IHNlcnZpY2UgZnVuY3Rpb24g KippbnN0YW5jZXMqKiBpbiB0aGUgU0ZDIi4NCj4NCj4gTWFyaWENCj4NCj4gKkZyb206KnNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpSb24gUGFya2VyDQo+ ICpTZW50OiogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDI6MTYgUE0NCj4gKlRvOiogRGF2aWQgQWxs YW4gSTsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZw0KPiAqU3ViamVjdDoq IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPg0KPiBJIGhhdmUgYSBjb3Vu dGVyLXByb3Bvc2FsIHRoYXQgZWxpbWluYXRlcyB0aGUgdGVybSAiU0ZQIiBlbnRpcmVseToNCj4N Cj4gIlRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpIHByb3ZpZGVzIGEgZnVsbHkgYWJz dHJhY3QgdmlldyBvZiANCj4gdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRvIGJlIGludm9rZWQgYW5k IHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IGFyZSB0byANCj4gYmUgaW52b2tlZCBmb3Igc29tZSBw YXJ0aWN1bGFyIGZsb3cgb3Igc2V0IG9mIGZsb3dzLCB3aXRob3V0IGNvbmNlcm4gb2YNCj4gYWN0 dWFsIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2Ugc2VsZWN0aW9uLiAgIFRoZSBDb25zdHJhaW5l ZC1TRkMNCj4gKEMtU0ZDKSBmdXJ0aGVyIGFsbG93cyBmb3IgcG9saWN5IGNvbnN0cmFpbnRzIHRv IGJlIGFkZGVkIHRvIHRoZSBTRkMgDQo+IGFmZmVjdGluZyB0aGUgc2VsZWN0aW9uIG9mIG9uZSBv ciBtb3JlIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiB0aGUNCj4gU0ZDLiAgIEFueSBTRkMg bWF5IGhhdmUgYW55IG51bWJlciBvZiBDLVNGQydzIGFzc29jaWF0ZWQgd2l0aCBpdC4iDQo+DQo+ IFRoYW5rcy4NCj4NCj4gICAgICBSb24NCj4NCj4gIlRoZSBTRlAgcHJvdmlkZXMgYSBsZXZlbCBv ZiBpbmRpcmVjdGlvbiBiZXR3ZWVuIHRoZSBmdWxseSBhYnN0cmFjdCANCj4gbm90aW9uIG9mIHNl cnZpY2UgcGF0aCBhcyBhIHNlcXVlbmNlIG9mIGZ1bmN0aW9ucyB0byBiZSBkZWxpdmVyZWQsIGFu ZCANCj4gdGhlIGZ1bGx5IHNwZWNpZmllZCBub3Rpb24gb2YgZXhhY3RseSB3aGF0IGluc3RhbmNl cyBvZiBTRkZzIHRoZSANCj4gcGFja2V0IHdpbGwgdmlzaXQgd2hlbiBpdCBhY3R1YWxseSB0cmF2 ZXJzZXMgdGhlIG5ldHdvcmsuIEJ5IGFsbG93aW5nIA0KPiB0aGUgY29udHJvbCBjb21wb25lbnRz IHRvIHNwZWNpZnkgdGhlIHVzZSBvZiB0aGlzIGxldmVsIG9mIA0KPiBpbmRpcmVjdGlvbiwgdGhl IGRlcGxveW1lbnQgbWF5IGNob29zZSB0aGUgZGVncmVlIG9mIFNGRiBpbnN0YW5jZSANCj4gc2Vs ZWN0aW9uIGF1dGhvcml0eSB0aGF0IGlzIGRlbGVnYXRlZCB0byB0aGUgbmV0d29yay4iDQo+DQo+ ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAq RGF2aWQgQWxsYW4gSQ0KPiAqU2VudDoqIE1vbmRheSwgSnVseSAxNCwgMjAxNCAyOjAzIFBNDQo+ ICpUbzoqIEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFNGQyBUZXJtaW5vbG9neSAvIENvbmNl cHRzDQo+DQo+IEkgbGlrZSB0aGF0IHRleHQsIGl0IHN0cmlrZXMgYSBnb29kIGJhbGFuY2Ugd2hl cmUgYW4gaW1wbGVtZW50YXRpb24gDQo+IGhhcyB0aGUgb3B0aW9uIG9mIG1ha2luZyBzY2FsZSBh bmQgcmVzaWxpZW5jeSBhIGxvY2FsIG1hdHRlci4uLi4NCj4NCj4gRA0KPg0KPiAqRnJvbToqc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkppbSBHdWljaGFy ZA0KPiAoamd1aWNoYXIpDQo+ICpTZW50OiogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDEwOjQ4IEFN DQo+ICpUbzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gKlN1YmplY3Q6 KiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPg0KPiBEZWFyIFdHOg0KPg0KPiBU aGVyZSBoYXMgYmVlbiBtdWNoIGRlYmF0ZSBvdmVyIHRoZSBsYXN0IGZldyBkYXlzIHdpdGggcmVn YXJkcyB0byBTRkMgDQo+IGNvbmNlcHRzLiBUbyB0cnkgYW5kIGZvcm0gc29tZSBjb25zZW5zdXMg YXJvdW5kIHRlcm1pbm9sb2d5IGFuZCANCj4gY29uY2VwdHMgdXNlZCB0byBkZXNjcmliZSB0aGUg YXJjaGl0ZWN0dXJlIGluIHRoZSBtZXJnZWQgYXJjaGl0ZWN0dXJlIA0KPiBkcmFmdCwgSm9lbCBo YXMga2luZGx5IHN1Z2dlc3RlZCB0aGUgZm9sbG93aW5nOg0KPg0KPiAiVGhlIFNGUCBwcm92aWRl cyBhIGxldmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIGZ1bGx5IGFic3RyYWN0IA0KPiBu b3Rpb24gb2Ygc2VydmljZSBwYXRoIGFzIGEgc2VxdWVuY2Ugb2YgZnVuY3Rpb25zIHRvIGJlIGRl bGl2ZXJlZCwgYW5kIA0KPiB0aGUgZnVsbHkgc3BlY2lmaWVkIG5vdGlvbiBvZiBleGFjdGx5IHdo YXQgaW5zdGFuY2VzIG9mIFNGRnMgdGhlIA0KPiBwYWNrZXQgd2lsbCB2aXNpdCB3aGVuIGl0IGFj dHVhbGx5IHRyYXZlcnNlcyB0aGUgbmV0d29yay4gQnkgYWxsb3dpbmcgDQo+IHRoZSBjb250cm9s IGNvbXBvbmVudHMgdG8gc3BlY2lmeSB0aGUgdXNlIG9mIHRoaXMgbGV2ZWwgb2YgDQo+IGluZGly ZWN0aW9uLCB0aGUgZGVwbG95bWVudCBtYXkgY2hvb3NlIHRoZSBkZWdyZWUgb2YgU0ZGIGluc3Rh bmNlIA0KPiBzZWxlY3Rpb24gYXV0aG9yaXR5IHRoYXQgaXMgZGVsZWdhdGVkIHRvIHRoZSBuZXR3 b3JrLiINCj4NCj4gSSdkIGxpa2UgdG8gYXNrIHRoZSBXRyBhcyBhIHdob2xlLCBpZiB0aGlzIGNs YXJpZmljYXRpb24gaXMgc29tZXRoaW5nIA0KPiB0aGF0IHdlIGNhbiBnZXQgY29uc2Vuc3VzIG9u LiBJZiBzbywgSSdsbCBhc2sgSm9lbCB0byBwcm92aWRlIHNwZWNpZmljIA0KPiB0ZXh0LCB0aGF0 IHJlZmxlY3RzIHRoZSBhYm92ZSwgZm9yIGluY2x1c2lvbiBpbiB0aGUgbWVyZ2VkIA0KPiBhcmNo aXRlY3R1cmUgZHJhZnQuDQo+DQo+IFRoYW5rIFlvdSwNCj4NCj4gSmltDQo+DQo+DQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue Jul 15 03:51:53 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495771B2847 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 03:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 axRG2-DpYiAP for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 03:51:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A35F1B2846 for <sfc@ietf.org>; Tue, 15 Jul 2014 03:51:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHF14669; Tue, 15 Jul 2014 10:51:47 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 11:51:46 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 18:51:36 +0800 From: Qin Wu <bill.wu@huawei.com> To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Xuxiaohu <xuxiaohu@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAJqO4A== Date: Tue, 15 Jul 2014 10:51:36 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA845831D9@nkgeml501-mbs.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/myYHvSIKvHvO16Wc3L-t-uuGj34 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 10:51:52 -0000 SSBhZ3JlZSB3aXRoIE1lZCB0aGF0IHJlcXVpcmluZyBjbGFzc2lmaWVyIG1ha2UgdGhlIHNlY29u ZCBzZWxlY3Rpb24gYWRkIGNvbXBsZXhpdHkgYW5kIGlzIG5vdCBkZXNpcmFibGUuIFdoYXQgY2xh c3NpZmllciBvbmx5IG5lZWRzIHRvIGRvIGlzIGp1c3QgbWFwcGluZyBhIGdpdmVuIFNGQyB0byBh IHNwZWNpZmljIFNGUC4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N CuWPkeS7tuS6ujogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMTXml6Ug MTc6MzUNCuaUtuS7tuS6ujogWHV4aWFvaHU7IEpvZWwgTS4gSGFscGVybjsgVG9tIFRheWxvcjsg c2ZjQGlldGYub3JnOyBSb24gUGFya2VyDQrkuLvpopg6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xv Z3kgLyBDb25jZXB0cw0KDQpIaSBYaWFvaHUsDQoNCldoeSBhIGNsYXNzaWZpZXIgd2lsbCBuZWVk IHNwZWNpZnkgYSBwYXRoIGEgbGEgRVJPPyBXaHkgaXQgbmVlZHMgdG8gaGF2ZSB0aGUgZnVsbCBr bm93bGVkZ2UgIG9mIHRoZSBpbnZvbHZlZCBTRiBpbnN0YW5jZXM/IFdvdWxkbid0IHRoaXMgcmVx dWlyZSB0aGUgY2xhc3NpZmllciB0byBiZSBmZWQgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IHRvIGRyaXZlIGl0cyBzZWxlY3Rpb24gcHJvY2Vzcz8gSXMgdGhpcyBjb21wbGV4aXR5IGp1c3Rp ZmllZCBmb3IgYWxsIGRlcGxveW1lbnRzPw0KDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbV0gRW52b3nDqcKgOiBtYXJkaSAxNSBqdWlsbGV0IA0KPjIwMTQgMTA6NDkgw4DCoDogQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9lbCBNLiBIYWxwZXJuOyBUb20gVGF5bG9yOyANCj5z ZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXIgT2JqZXTCoDogUkU6IFtzZmNdIFNGQyBUZXJtaW5vbG9n eSAvIENvbmNlcHRzDQo+DQo+SGkgTWVkLA0KPg0KPklNSE8sIHRoZSBhcmNoaXRlY3R1cmUgc2hv dWxkIGFsbG93IHRoZSBjbGFzc2lmaWVyIHRvIHNwZWNpZnkNCj4NCj4xKSBhIHBhcnRpYWwgU0ZQ IChpLmUuLCBzb21lIFNGRnMgYWxvbmcgdGhhdCBwYXJ0aWFsIFNGUCBuZWVkIHRvIA0KPmxvY2Fs bHkgZGV0ZXJtaW5lIHRoZSBhcHByb3ByaWF0ZSBTRkYgZm9yIHRoZSBuZXh0IFNGKTsNCj4yKSBh IGNvbXBsZXRlIFNGUCAoaS5lLiwgdGhlIFNGRiBmb3IgZWFjaCBTRiBpbiB0aGUgU0ZDIGhhcyBi ZWVuIA0KPmRldGVybWluZWQgYnkgdGhlIGNlbnRyYWxpemVkIG5vZGUpOw0KPjMpIGFuIFNGQyAo aS5lLiwgZWFjaCBTRkYgYWxvbmcgdGhlIGZpbmFsIFNGUCBuZWVkcyB0byBsb2NhbGx5IA0KPmRl dGVybWluZSB0aGUgYXBwcm9wcmlhdGUgU0ZGIGZvciB0aGUgbmV4dCBTRikuDQo+DQo+SW4gZmFj dCwgY2FzZSAzKSBjb3VsZCBiZSBsb29rZWQgYXMgYW4gZXh0cmVtZSBvZiBjYXNlIDEpLg0KPg0K PkJlc3QgcmVnYXJkcywNCj5YaWFvaHUNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IA0KPj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4gU2VudDogVHVlc2RheSwgSnVs eSAxNSwgMjAxNCAzOjIyIFBNDQo+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBUb20gVGF5bG9yOyBz ZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXINCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgVGVybWlu b2xvZ3kgLyBDb25jZXB0cw0KPj4NCj4+IEhpIEpvZWwsDQo+Pg0KPj4gQXMgbWVudGlvbmVkIGlu IHNldmVyYWwgbWVzc2FnZXMsIEknbSBwZXJzb25hbGx5IGZvciB0aGUgdXNlIG9mIHRoZSANCj4+ IGNoYWluDQo+aXRzZWxmIGlzDQo+PiB0aGUgbWFpbiBpbmZvcm1hdGlvbiB0byBiZSBjb252ZXll ZCBpbiBwYWNrZXRzIHRvIGRyaXZlIGZvcndhcmRpbmcNCj5hY3Rpb25zLg0KPj4NCj4+IEkgY2Fu IHVuZGVyc3RhbmQgdGhhdCBhbiBpZGVudGlmaWVyIGNhbiBiZSBhc3NpZ25lZCB0byBhIHBhdGgg dGhhdCBpcw0KPmtub3duIGluDQo+PiBhZHZhbmNlLCBidXQgaWYgdGhhdCBwYXRoIGlzIG5vdCBr bm93biBJJ20gbm90IHN1cmUgaG93IGFuIGlkZW50aWZpZXIgDQo+PiBjYW4NCj5iZQ0KPj4gYXNz aWduZWQgdG8gaXQhDQo+Pg0KPj4gSm9lbCwgdGhlIHVzZSBvZiAicGF0aCIgaXMgcmVhbGx5IGlu YXBwcm9wcmlhdGUgdG8gcmVmZXIgdG8gDQo+PiBkaXN0cmlidXRlZA0KPmluc3RhbmNlDQo+PiBz ZWxlY3Rpb24gcHJvY2VzcyBmb3IgcGFja2V0cyBib3VuZCB0byBhIGdpdmVuIFNGQy4NCj4+DQo+ PiBDaGVlcnMsDQo+PiBNZWQNCj4+DQo+PiA+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ PiA+RGXCoDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg Sm9lbCBNLiBIYWxwZXJuIA0KPj4gPkVudm95w6nCoDogbHVuZGkgMTQganVpbGxldCAyMDE0IDIx OjUyIMOAwqA6IFRvbSBUYXlsb3I7IHNmY0BpZXRmLm9yZzsgDQo+PiA+Um9uIFBhcmtlciBPYmpl dMKgOiBSZTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+ID4NCj4+ID5UaGUg bW9zdCBsaWtlbHkgcmVhbGl6YXRpb24gb2YgdGhlIGFyY2hpdGVjdHVyZSB3b3VsZCBiZSB0aGF0 IHRoZSANCj4+ID5TRlAgYXNzaWdubWVudCBpcyByZWNvcmRlZCBpbiBhbiBpZGVudGlmaWVyIHdo aWNoIHRyYXZlbHMgd2l0aCB0aGUgcGFja2V0Lg0KPj4gPg0KPj4gPlNvbWUgZm9sa3Mgc2VlbSB0 byBub3Qgd2FudCB0aGUgYXJjaGl0ZWN0dXJlIHRvIG1hbmRhdGUgdGhhdC4NCj4+ID4NCj4+ID5Z b3VycywNCj4+ID5Kb2VsDQo+PiA+DQo+PiA+DQo+PiA+T24gNy8xNC8xNCwgMjozNyBQTSwgVG9t IFRheWxvciB3cm90ZToNCj4+ID4+IFlvdXIgdGV4dCBzY2FyZXMgbWUgYmVjYXVzZSBpdCBpbnRy b2R1Y2VzIHNvbWUgbmV3IGNvbmNlcHRzIGFuZCANCj4+ID4+IGFzc3VtcHRpb25zLg0KPj4gPj4N Cj4+ID4+IEknZCByYXRoZXIgZ28gd2l0aCBKb2VsJ3MgZm9ybXVsYXRpb24uIENsYXJpZnlpbmcg cXVlc3Rpb24gb24gdGhhdDoNCj4+ID4+IGFtIEkgcmlnaHQgaW4gc2VlaW5nIHRoZSBpbXBsaWNh dGlvbiB0aGF0IHdoZW4gY29udHJvbCBhc3NpZ25zIGFuIA0KPj4gPj4gU0ZQLCB0aGUgYXNzaWdu bWVudCBpcyByZWNvcmRlZCBieSBhbiBpZGVudGlmaWVyIHd3aGljaCB0cmF2ZWxzIA0KPj4gPj4g d2l0aA0KPnRoZQ0KPj4gcGFja2V0Pw0KPj4gPj4NCj4+ID4+IFRvbSBUYXlsb3INCj4+ID4+DQo+ PiA+PiBPbiAxNC8wNy8yMDE0IDI6MjIgUE0sIFJvbiBQYXJrZXIgd3JvdGU6DQo+PiA+Pj4gVGhl cmUgaXMgb25lIG1pc3Npbmcgd29yZCBpbiBteSB0ZXh0LiAgIFBsZWFzZSByZXBsYWNlIG15IHBy b3Bvc2VkDQo+dGV4dA0KPj4gPj4+IHdpdGg6DQo+PiA+Pj4NCj4+ID4+PiAiVGhlIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW4gKFNGQykgcHJvdmlkZXMgYSBmdWxseSBhYnN0cmFjdCB2aWV3IA0KPj4g Pj4+IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBiZSBpbnZva2VkIGFuZCB0aGUgb3JkZXIg aW4gd2hpY2ggDQo+PiA+Pj4gdGhleSBhcmUgdG8gYmUgaW52b2tlZCBmb3Igc29tZSBwYXJ0aWN1 bGFyIGZsb3cgb3Igc2V0IG9mIGZsb3dzLCANCj4+ID4+PiB3aXRob3V0DQo+Y29uY2VybiBvZg0K Pj4gPj4+IGFjdHVhbCBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIHNlbGVjdGlvbi4gICBUaGUg Q29uc3RyYWluZWQtU0ZDDQo+PiA+Pj4gKEMtU0ZDKSBmdXJ0aGVyIGFsbG93cyBmb3IgcG9saWN5 IGNvbnN0cmFpbnRzIHRvIGJlIGFkZGVkIHRvIHRoZSANCj4+ID4+PiBTRkMgYWZmZWN0aW5nIHRo ZSBpbnN0YW5jZSBzZWxlY3Rpb24gb2Ygb25lIG9yIG1vcmUgb2YgdGhlIA0KPj4gPj4+IHNlcnZp Y2UNCj5mdW5jdGlvbnMNCj4+ID4+PiBpbiB0aGUgU0ZDLiAgIEFueSBTRkMgbWF5IGhhdmUgYW55 IG51bWJlciBvZiBDLVNGQydzIGFzc29jaWF0ZWQgd2l0aA0KPj4gPml0LiINCj4+ID4+Pg0KPj4g Pj4+IFRoYW5rcy4NCj4+ID4+Pg0KPj4gPj4+ICAgICAgUm9uDQo+PiA+PiAuLi4NCj4+ID4+DQo+ PiA+Pg0KPj4gPj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9u IEJlaGFsZiBPZiAqRGF2aWQgDQo+PiA+Pj4gQWxsYW4gSQ0KPj4gPj4+ICpTZW50OiogTW9uZGF5 LCBKdWx5IDE0LCAyMDE0IDI6MDMgUE0NCj4+ID4+PiAqVG86KiBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKTsgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4gPj4+ICpTdWJqZWN0 OiogUmU6IFtzZmNdIFNGQyBUZXJtaW5vbG9neSAvIENvbmNlcHRzDQo+PiA+Pj4NCj4+ID4+PiBJ IGxpa2UgdGhhdCB0ZXh0LCBpdCBzdHJpa2VzIGEgZ29vZCBiYWxhbmNlIHdoZXJlIGFuIA0KPj4g Pj4+IGltcGxlbWVudGF0aW9uIGhhcyB0aGUgb3B0aW9uIG9mIG1ha2luZyBzY2FsZSBhbmQgcmVz aWxpZW5jeSBhIGxvY2FsIG1hdHRlci4uDQo+PiA+Pj4NCj4+ID4+PiBEDQo+PiA+Pj4NCj4+ID4+ PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2Yg KkppbSANCj4+ID4+PiBHdWljaGFyZA0KPj4gPj4+IChqZ3VpY2hhcikNCj4+ID4+PiAqU2VudDoq IE1vbmRheSwgSnVseSAxNCwgMjAxNCAxMDo0OCBBTQ0KPj4gPj4+ICpUbzoqIHNmY0BpZXRmLm9y ZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ID4+PiAqU3ViamVjdDoqIFtzZmNdIFNGQyBUZXJt aW5vbG9neSAvIENvbmNlcHRzDQo+PiA+Pj4NCj4+ID4+PiBEZWFyIFdHOg0KPj4gPj4+DQo+PiA+ Pj4gVGhlcmUgaGFzIGJlZW4gbXVjaCBkZWJhdGUgb3ZlciB0aGUgbGFzdCBmZXcgZGF5cyB3aXRo IHJlZ2FyZHMgdG8gDQo+PiA+Pj4gU0ZDIGNvbmNlcHRzLiBUbyB0cnkgYW5kIGZvcm0gc29tZSBj b25zZW5zdXMgYXJvdW5kIHRlcm1pbm9sb2d5IA0KPj4gPj4+IGFuZCBjb25jZXB0cyB1c2VkIHRv IGRlc2NyaWJlIHRoZSBhcmNoaXRlY3R1cmUgaW4gdGhlIG1lcmdlZCANCj4+ID4+PiBhcmNoaXRl Y3R1cmUgZHJhZnQsIEpvZWwgaGFzIGtpbmRseSBzdWdnZXN0ZWQgdGhlIGZvbGxvd2luZzoNCj4+ ID4+Pg0KPj4gPj4+ICJUaGUgU0ZQIHByb3ZpZGVzIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0 d2VlbiB0aGUgZnVsbHkgDQo+PiA+Pj4gYWJzdHJhY3Qgbm90aW9uIG9mIHNlcnZpY2UgcGF0aCBh cyBhIHNlcXVlbmNlIG9mIGZ1bmN0aW9ucyB0byBiZSANCj4+ID4+PiBkZWxpdmVyZWQsIGFuZCB0 aGUgZnVsbHkgc3BlY2lmaWVkIG5vdGlvbiBvZiBleGFjdGx5IHdoYXQgDQo+PiA+Pj4gaW5zdGFu Y2VzIG9mIFNGRnMgdGhlIHBhY2tldCB3aWxsIHZpc2l0IHdoZW4gaXQgYWN0dWFsbHkgDQo+PiA+ Pj4gdHJhdmVyc2VzIHRoZSBuZXR3b3JrLiBCeSBhbGxvd2luZyB0aGUgY29udHJvbCBjb21wb25l bnRzIHRvIA0KPj4gPj4+IHNwZWNpZnkgdGhlIHVzZSBvZiB0aGlzIGxldmVsIG9mIGluZGlyZWN0 aW9uLCB0aGUgZGVwbG95bWVudCBtYXkgDQo+PiA+Pj4gY2hvb3NlIHRoZSBkZWdyZWUgb2YgU0ZG IGluc3RhbmNlIHNlbGVjdGlvbiBhdXRob3JpdHkgdGhhdCBpcyBkZWxlZ2F0ZWQgdG8gdGhlIG5l dHdvcmsuIg0KPj4gPj4+DQo+PiA+Pj4gSSdkIGxpa2UgdG8gYXNrIHRoZSBXRyBhcyBhIHdob2xl LCBpZiB0aGlzIGNsYXJpZmljYXRpb24gaXMgDQo+PiA+Pj4gc29tZXRoaW5nIHRoYXQgd2UgY2Fu IGdldCBjb25zZW5zdXMgb24uIElmIHNvLCBJJ2xsIGFzayBKb2VsIHRvIA0KPj4gPj4+IHByb3Zp ZGUgc3BlY2lmaWMgdGV4dCwgdGhhdCByZWZsZWN0cyB0aGUgYWJvdmUsIGZvciBpbmNsdXNpb24g aW4gDQo+PiA+Pj4gdGhlIG1lcmdlZCBhcmNoaXRlY3R1cmUgZHJhZnQuDQo+PiA+Pj4NCj4+ID4+ PiBUaGFuayBZb3UsDQo+PiA+Pj4NCj4+ID4+PiBKaW0NCj4+ID4+Pg0KPj4gPj4+DQo+PiA+Pj4N Cj4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+PiBzZmNAaWV0Zi5vcmcNCj4+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gPj4+DQo+PiA+Pg0KPj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+ID4+IHNmY0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ID4+DQo+PiA+DQo+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5zZmMgbWFpbGluZyBs aXN0DQo+PiA+c2ZjQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Tue Jul 15 06:03:28 2014 Return-Path: <jguichar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1910A1B28A6 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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_29=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 2cjz93WI-Tws for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:03:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348DF1B289B for <sfc@ietf.org>; Tue, 15 Jul 2014 06:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53908; q=dns/txt; s=iport; t=1405429402; x=1406639002; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ze4virWonNSJjWD7hpQLIedC8WbswGwUGKKRQFUOPGQ=; b=hbu+4vmJmMfLzwHElkKyytkuulqOe6DD9rlIbslYl53UiuBYnVNbICVZ 5tA+MIoQBvirkYGcLJnt0s6QXQkXZvewu8kWDrTNVKhpwhM+l1OsfkObW Tasa3zVjOb69Puabdtuef62zTqlC9sbQ0yFWBOAO7nnbPpiROi1DSi8RQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAKIlxVOtJA2J/2dsb2JhbABPCoMOUlcEgnKsN5I3CodDARlyFnWEAwEBAQQBAQEXAQgRMQkCFQQCAQgRAQMBAQECAiMDAgICJQsUAQIGCAIEARIbiBMDEQ2xU5gVEwSBLIhSgyCBUQUsECICAgKCcYFMBZYzSoQbi2yIOYNEbIEEQQ X-IronPort-AV: E=Sophos;i="5.01,665,1400025600"; d="scan'208";a="340199234" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2014 13:03:20 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6FD3KNL032398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 13:03:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 08:03:19 -0500 From: "Jim Guichard (jguichar)" <jguichar@cisco.com> To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8WroN0eBUZEU28W13natmzZZuYfwEAgAC5UYCAAIXgAIAAQmiAgAARywCAAAKpgIAABekAgAACvoCAAAP/gIAAANwAgAADBQCAAA+agIAAAVyAgAA4uoCAAAHeAIAAA6SAgAACOACAAB3pgIAAXQWAgABJQoD//74/AIAARKEA///CHICAAEbeAIAAB9AA///BG4AAv2LoAAAFN5eA Date: Tue, 15 Jul 2014 13:03:19 +0000 Message-ID: <CFEA9D8F.2ED59%jguichar@cisco.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002FF98@OPEXCLILM23.corporate.adroot.infra.ftgroup> <2691CE0099834E4A9C5044EEC662BB9D453BE2F3@dfweml701-chm.china.huawei.com> <AB80AC85-4BA1-419E-88D7-23F2F7141FBE@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A632@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BEF475.7050205@joelhalpern.com> <53BEF96A.4050808@sce.carleton.ca> <53BEFBB7.2010400@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C4E8@SEAEMBX02.olympus.F5Net.com> <53BEFFCA.9070308@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83C526@SEAEMBX02.olympus.F5Net.com> <388152760.1775.1405030249479.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <53BF108D.4090509@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B4C0B@MBX021-W3-CA-2.exch021.domain.local> <53BF41B4.3080107@joelhalpern.com> <419417C345CA5F48BF45F0A23955A0634A83CB41@SEAEMBX02.olympus.F5Net.com> <53BF469E.9010108@joelhalpern.com> <53BF5FB5.6020906@joelhalpern.com> <CFE55D9F.2D1D0%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AC6B@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B9330032520@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330032520@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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.131.36.24] Content-Type: text/plain; charset="utf-8" Content-ID: <79114CE88A16554E80469F90FB971872@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/G-vvL-JTUG8ULk6VD093OavNpWY Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 13:03:27 -0000 SGkgTWVkLA0KDQpPbiA3LzE1LzE0LCAyOjMzIEFNLCAibW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSINCjxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPkhpIEppbSwN Cj4NCj5CZWNhdXNlIHlvdSBjYW5ub3QgYXNzaWduIGFuIGlkZW50aWZpZXIgdG8gcGF0aCB1bmxl c3MgaXQgaXMga25vd24gaW4NCj5hZHZhbmNlLg0KDQpKaW0+IHdoeSBub3Q/IFRoZSBpZGVudGlm aWVyIHNpbXBseSBwb2ludHMgdG8gYW4gaW5zdGFudGlhdGlvbiBvZiBhIGdpdmVuDQpjaGFpbiBp biB0aGUgbmV0d29yay4gVGhhdCBpbnN0YW50aWF0aW9uIG1heSBiZSBwcmUtZXN0YWJsaXNoZWQg b3IgbG9vc2UNCmUuZy4gVGhlIGFjdHVhbCBTRiBpbnN0YW5jZXMgdG8gYmUgdXNlZCBtYXkgb3Ig bWF5IG5vdCBiZSBkZXRlcm1pbmVkIGENCnByaW9yaS4gVGhlIGlkZW50aWZpZXIgcHJvdmlkZXMg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIHRvIGJlDQphYmxlIHRvIHJlc29sdmUg YSBnaXZlbiBpbnN0YW50aWF0aW9uIG9mIGEgY2hhaW4gYXMgdHJhZmZpYyBpcyBmb3J3YXJkZWQN CnRocm91Z2ggaXQuIA0KDQo+IA0KPg0KPkFueXdheSwgdGhpcyB0aHJlYWQgaGFzIHNob3duIHRo ZSB0ZXJtaW5vbG9neSAocmVhZCBTRlApIGlzIG5vdA0KPmFwcHJvcHJpYXRlICsgdGhlIGN1cnJl bnQgbWVyZ2VkIGRyYWZ0IHNlZW1zIHRvIGFkb3B0IChwcmVmZXIgPykgYQ0KPmNlbnRyYWxpemVk IG1vZGVsLg0KDQpKaW0+IEkgYW0gdW5jbGVhciBhcyB0byB3aHkgdGhlIG5vdGlvbiBvZiBjZW50 cmFsaXplZCBpcyBhc3N1bWVkPyBUaGUNCmFyY2hpdGVjdHVyZSBzaG91bGQgbm90IG1hbmRhdGUg Y2VudHJhbGl6ZWQgb3IgZGlzdHJpYnV0ZWQuIElzIHRoZSB3b3JkaW5nDQppbiB0aGUgZHJhZnQg b3IgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBjYXVzaW5nIHRoaXMgbWlzY29uY2VwdGlvbj8gVGhl DQphcmNoaXRlY3R1cmUgYXMgSSByZWFkIGl0IHNpbXBseSBzYXlzIHRoYXQgYW4gU0ZDIGlzIGRl ZmluZWQgYXMgYW4gb3JkZXJlZA0KbGlzdCBvZiBTRuKAmXMgYW5kIHRoZW4gb25lIG9yIG1vcmUg aW5zdGFudGlhdGlvbnMgb2YgdGhpcyBTRkMgbWF5IGJlIGFjdGl2ZQ0Kd2l0aGluIHRoZSBuZXR3 b3JrIGFuZCBpZGVudGlmaWNhdGlvbiBvZiB3aGljaCBwYXJ0aWN1bGFyIGluc3RhbnRpYXRpb24N CnRyYWZmaWMgaXMgZm9yd2FyZGVkIHRocm91Z2ggaXMgcHJvdmlkZWQgYnkgYSBzZXJ2aWNlIHBh dGggaWRlbnRpZmllci4NCg0KPiANCj4NCj5DaGVlcnMsDQo+TWVkDQo+DQo+Pi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPj5EZSA6IEppbSBHdWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86 amd1aWNoYXJAY2lzY28uY29tXQ0KPj5FbnZvecOpIDogdmVuZHJlZGkgMTEganVpbGxldCAyMDE0 IDE3OjE1DQo+PsOAIDogTkFQSUVSQUxBLCBNQVJJQSBIOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOOyBKb2VsIE0uIEhhbHBlcm47IFJvbg0KPj5QYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj5PYmpl dCA6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0K Pj4NCj4+SeKAmW0gc29ycnkgYnV0IEkgcmVhbGx5IGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgYSBz ZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KPj5wcmV2ZW50cyBmdWxsIGRpc3RyaWJ1dGlvbiBvZiBT RiBuZXh0LWhvcHMgb3Igd2h5IGNhbGxpbmcgaXQgYSBzZXJ2aWNlDQo+PmNoYWluIGlkZW50aWZp ZXIgbWFrZXMgYW55IGRpZmZlcmVuY2U/DQo+Pg0KPj5PbiA3LzExLzE0LCAxMDo1OCBBTSwgIk5B UElFUkFMQSwgTUFSSUEgSCIgPG1uMTkyMUBhdHQuY29tPiB3cm90ZToNCj4+DQo+Pj5EaXR0by4N Cj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4+IFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbV0NCj4+Pj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDEwOjMxIEFNDQo+Pj4+ IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0u IEhhbHBlcm47IFJvbg0KPj4+PiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBS RTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4+Pj4N Cj4+Pj4gUmUtLA0KPj4+Pg0KPj4+PiBGb3Igd2hhdCBJIGNhbiBzYXkgYXQgYmVzdCB0aGlzIGlz IG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0aGUgZHJhZnQuDQo+Pj4+DQo+Pj4+IE1hbmRhdGlu ZyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIGlzIGluIGl0c2VsZiBhIGhpbnQgdGhhdCB0aGUg ZnVsbA0KPj4+PmRpc3RyaWJ1dGVkDQo+Pj4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPj4+Pg0K Pj4+PiBTZXZlcmFsIHZvaWNlcyBpbiB0aGlzIHRocmVhZCBpbmRpY2F0ZWQgdGhhdCB0aGUgc2Vy dmljZSBjaGFpbiBpdHNlbGYNCj4+Pj5zaG91bGQgYmUNCj4+Pj4gcHJvdmlkZWQgaW5zdGVhZC4N Cj4+Pj4NCj4+Pj4gQ2hlZXJzLA0KPj4+PiBNZWQNCj4+Pj4NCj4+Pj4gPi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPj4+PiA+RGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBKaW0gR3VpY2hhcmQNCj4+Pj4gPihqZ3VpY2hhcikNCj4+Pj4gPkVu dm95w6kgOiB2ZW5kcmVkaSAxMSBqdWlsbGV0IDIwMTQgMTY6MTgNCj4+Pj4gPsOAIDogTkFQSUVS QUxBLCBNQVJJQSBIOyBKb2VsIE0uIEhhbHBlcm47IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZw0K Pj4+PiA+T2JqZXQgOiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4+Pj4gPg0KPj4+PiA+T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUg c3BlY2lmaWNhbGx5IGlzIHRoaXMgZnVuY3Rpb25hbGl0eQ0KPj4+PiA+cHJvaGliaXRlZD8gSWYg eW91IHdhbnQgdG8gZGlzdHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCogU0ZG4oCZcw0K Pj4+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlm aWVyIHBvaW50IHRvIGENCj4+Pj5sb29rdXANCj4+Pj4gPmludG8gdGhvc2UgbmV4dC1ob3BzIHRv IHJlYWNoIHRoZSBuZXh0IFNGIGluIHRoZSBjaGFpbiwgSSBhbSBub3Qgc3VyZQ0KPj4+Pmhvdw0K Pj4+PiA+dGhlIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPj4+PiA+DQo+Pj4+ID5PbiA3 LzExLzE0LCA5OjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+IHdy b3RlOg0KPj4+PiA+DQo+Pj4+ID4+QWJzb2x1dGVseS4NCj4+Pj4gPj4NCj4+Pj4gPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBHdWljaGFyZA0KPj4+PiA+Pj4oamd1aWNo YXIpDQo+Pj4+ID4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPj4+PiA+ Pj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsgSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBz ZmNAaWV0Zi5vcmcNCj4+Pj4gPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywg UGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+PiA+Pj4NCj4+Pj4gPj4+IFRoZW4gSSBtaXN1 bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCA7LSkgLi4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUNCj4+ Pj50aGF0IGlmDQo+Pj4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBh cyB0byB3aGljaCByZW1vdGUgU0ZGIGl0IHdpbGwNCj4+Pj51c2UNCj4+Pj4gPj4+Zm9yDQo+Pj4+ ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhlIG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0 aGVuIHlvdSBiZXR0ZXINCj4+Pj5tYWtlDQo+Pj4+ID4+PiBzdXJlIHRoYXQgdGhhdCByZW1vdGUg U0ZGIGhhcyB0aGUgbmVjZXNzYXJ5IGZvcndhcmRpbmcgbG9naWMgdG8NCj4+Pj5yZWFjaA0KPj4+ PiA+Pj50aGUNCj4+Pj4gPj4+IG5leHQtbmV4dC1TRiBmb3IgdGhlIGNoYWluIGFzIG90aGVyd2lz ZSB5b3UgYXJlIGluIGRlZXAgdHJvdWJsZS4NCj4+Pj4gPj4+DQo+Pj4+ID4+PiBPbiA3LzExLzE0 LCA5OjQ4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20+DQo+Pj4+IHdy b3RlOg0KPj4+PiA+Pj4NCj4+Pj4gPj4+ID5BYnNvbHV0ZWx5IG5vdC4gU2VydmljZSBjaGFpbnMg Y2FuIGJlIGluc3RhbnRpYXRlZCBvbmx5IGluDQo+Pj4+cmVsZXZhbnQNCj4+Pj4gPj4+U0ZGcw0K Pj4+PiA+Pj4gPndoZW4gdGhleSAiYXJyaXZlIi4NCj4+Pj4gPj4+ID4NCj4+Pj4gPj4+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4+PiA+PiBGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbQ0KPj4+Pkd1aWNoYXJkDQo+Pj4+ ID4+PiA+PihqZ3VpY2hhcikNCj4+Pj4gPj4+ID4+IFNlbnQ6IEZyaWRheSwgSnVseSAxMSwgMjAx NCA5OjI3IEFNDQo+Pj4+ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBz ZmNAaWV0Zi5vcmcNCj4+Pj4gPj4+ID4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlu cywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPj4+PiA+Pj4gPj4NCj4+Pj4gPj4+ID4+IFdl bGwgSSB0aGluayBpdCBpcyBldmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUgdW5kZXJzdG9v ZA0KPj4+PnRoZQ0KPj4+PiA+Pj4gPj5wcm9wb3NhbA0KPj4+PiA+Pj4gPj4gY29ycmVjdGx5IGFz IGl0IHdvdWxkIHJlcXVpcmUgZnVsbCBrbm93bGVkZ2Ugb2YgZXZlcnkgc2luZ2xlIFNGDQo+Pj4+ ID4+PndpdGhpbg0KPj4+PiA+Pj4gPj50aGUNCj4+Pj4gPj4+ID4+IGVudGlyZSBTRkMgZG9tYWlu IGF0IGV2ZXJ5IHNpbmdsZSBTRkYgYXMgdGhlcmUgaXMgbm8gd2F5IHRvDQo+Pj4+a25vdw0KPj4+ PmENCj4+Pj4gPj4+ID4+cHJpb3JpDQo+Pj4+ID4+PiA+PiB3aGljaCBTRkPCuXMgYSBnaXZlbiBT RkYgd2lsbCBuZWVkIHRvIHNlcnZpY2UgYXQgYW55IGdpdmVuIHBvaW50DQo+Pj4+aW4NCj4+Pj4g Pj4+dGltZS4NCj4+Pj4gPj4+ID4+DQo+Pj4+ID4+PiA+PiBPbiA3LzEwLzE0LCAxMTo1MyBQTSwg IkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4+IHdyb3RlOg0KPj4+ PiA+Pj4gPj4NCj4+Pj4gPj4+ID4+ID5Sb24sIHRoaW5raW5nIGFib3V0IHRoaXMsIEkgcmVhbGl6 ZWQgYW5vdGhlciBtYWpvciBwcm9ibGVtDQo+Pj4+d2l0aA0KPj4+PnRoZQ0KPj4+PiA+Pj4gPj55 b3VyDQo+Pj4+ID4+PiA+PiA+cHJvcG9zYWwgYXMgSSB1bmRlcnN0YW5kIGl0LiAgKEFuZCBJIHJl YWRpbHkgYWRtaXQgSSBtYXkgbm90DQo+Pj4+ID4+PnVuZGVyc3RhbmQNCj4+Pj4gPj4+ID4+ID5p dC4pDQo+Pj4+ID4+PiA+PiA+DQo+Pj4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNG RiBzZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3IgdGhlDQo+Pj4+bmV4dA0KPj4+PiA+Pj4g Pj4gPnNlcnZpY2UgZnVuY3Rpb24gdGhhdCBmb2xsb3dzIGl0IChub3QgdGhlIG9uZSBpdCBkZWxp dmVycyB0byksDQo+Pj4+aW4NCj4+Pj4gPj4+ZXZlcnkNCj4+Pj4gPj4+ID4+ID5zZXJ2aWNlIGNo YWluIHRoYXQgZ29lcyB0aHJvdWdoIGl0Lg0KPj4+PiA+Pj4gPj4gPg0KPj4+PiA+Pj4gPj4gPlNp bmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQgbWVh bnMNCj4+Pj50aGF0DQo+Pj4+ID4+PiA+PmV2ZXJ5DQo+Pj4+ID4+PiA+PiA+U0ZGIHdvdWxkIGhh dmUgdG8gYmUgYSBmdWxsLCBmbG93IHNlbnNpdGl2ZSBhbmQgc3RhdGVmdWwgbG9hZA0KPj4+PiA+ Pj5iYWxhbmNlci4NCj4+Pj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBh cmUgZmxvdyBzZW5zaXRpdmUsIGFuZCAvIG9yDQo+Pj4+c3RhdGVmdWwuDQo+Pj4+ID4+PiA+PiA+ QnV0IGhhdmluZyB0aGUgYXJjaGl0ZWN0dXJlIHJlcXVpcmUgdGhhdCBldmVyeSBTRkYgYmUgYSBm dWxsLA0KPj4+PmZsb3cNCj4+Pj4gPj4+ID4+ID5zZW5zaXRpdmUsIHN0YXRlZnVsLCBsb2FkIGJh bGFuY2VyIHNlZW1zIHRvIG1lIHRvIGJlIGFuDQo+Pj4+YWNjZXB0YWJsZQ0KPj4+PiA+Pj4gPj4g PmltcG9zaXRpb24uDQo+Pj4+ID4+PiA+PiA+DQo+Pj4+ID4+PiA+PiA+WW91cnMsDQo+Pj4+ID4+ PiA+PiA+Sm9lbA0KPj4+PiA+Pj4gPj4gPg0KPj4+PiA+Pj4gPj4gPk9uIDcvMTAvMTQsIDEwOjA2 IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4+ID4+PiA+PiA+PiBQYXJ0IG9mIG15IHBl cnNvbmFsIHZpZXcgaXMgdGhhdCBJIGFtIHRyeWluZyB0byBtYWtlIHRoaXMNCj4+Pj53b3JrDQo+ Pj4+ID4+PiA+PnNlbnNpYmx5DQo+Pj4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVk IGVudmlyb25tZW50LiAgSSBleHBlY3QgdGhhdCB0aGUNCj4+Pj5zZXJ2aWNlDQo+Pj4+ID4+PiA+ PiA+PiBmdW5jdGlvbnMsIGFuZCBvdmVyIHRpbWUgcHJvYmFibHkgdGhlIFNGRiBjYXBhYmlsaXRp ZXMsIHdpbGwNCj4+Pj5iZQ0KPj4+PiA+Pj4gPj4gPj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxs ZWQuICBJIGV4cGVjdCB0aGUgc2VydmljZSBjaGFpbnMgdG8NCj4+Pj5iZQ0KPj4+PiA+Pj4gPj5k cml2ZW4gYnkNCj4+Pj4gPj4+ID4+ID4+IEJTUyB0b29scyB0aGF0IGRlZmluZSBvZmZlcmluZ3Mg dG8gY2xpZW50cywgYW5kIGVuYWJsZQ0KPj4+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPj4+PiA+Pj4g Pj4gPj4gZnJvbSB0aGVzZS4gIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBw b2xpY3kNCj4+Pj5kcml2ZS4NCj4+Pj4gPj4+ID4+ID4+DQo+Pj4+ID4+PiA+PiA+PiBJIGNhbiBz ZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBhbiBhcmNodGllY3R1cmUNCj4+Pj5k cml2ZW4NCj4+Pj4gPj4+YnkNCj4+Pj4gPj4+ID4+ID4+IGluaXRpYWwgY2xhc3NpZmljYXRpb24g dG8gZGVzY3JpYmVkIHNlcnZpY2UgcGF0aHMuICBJdCBpcw0KPj4+PmhhcmRlcg0KPj4+PiA+Pj50 bw0KPj4+PiA+Pj4gPj5zZWUNCj4+Pj4gPj4+ID4+ID4+IGhvdyB0byBtYWtlIGl0IHdvcmsgKGJ1 dCBpdCBjYW4gYmUgZG9uZSkgd2hlbiB3ZSBhbGxvdyBtb3JlDQo+Pj4+ID4+PiA+PiBkeW5hbWlj aXR5DQo+Pj4+ID4+PiA+PiA+PiBpbiB0aGUgbmV0d29yayBiZWhhdmlvci4NCj4+Pj4gPj4+ID4+ ID4+DQo+Pj4+ID4+PiA+PiA+PiBIYXZpbmcgc2FpZCB0aGF0LCBtb3N0IG9mIHRoYXQgcGVyc3Bl Y3RpdmUgSSBkZXNjcmliZWQgaXMNCj4+Pj5vdXRzaWRlDQo+Pj4+ID4+Pm9mDQo+Pj4+ID4+PiA+ PnRoZQ0KPj4+PiA+Pj4gPj4gPj4gc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuICBpdCBpcyBu b3Qgc29tZXRoaW5nIHdlIGFyZQ0KPj4+PnRhc2tlZCB0bw0KPj4+PiA+Pj4gPj5hZ3JlZQ0KPj4+ PiA+Pj4gPj4gPj5vbi4NCj4+Pj4gPj4+ID4+ID4+IFNvIEkgZG8gbm90IGNsYWltIHRoYXQgdmlz aW9uIG1lYW5zIHdlIGhhdmUgdG8gZG8gaXQgYQ0KPj4+PmNlcnRhaW4NCj4+Pj4gPj4+d2F5Lg0K Pj4+PiA+Pj4gPj5pdA0KPj4+PiA+Pj4gPj4gPj4gaXMganVzdCB0aGUgcGVyc3BlY3RpdmUgdGhh dCBkcml2ZXMgbXkgcHJlZmVyZW5jZXMuDQo+Pj4+ID4+PiA+PiA+Pg0KPj4+PiA+Pj4gPj4gPj4g WW91cnMsDQo+Pj4+ID4+PiA+PiA+PiBKb2VsDQo+Pj4+ID4+PiA+PiA+Pg0KPj4+PiA+Pj4gPj4g Pj4gT24gNy8xMC8xNCwgOTo1OCBQTSwgSWFuIFNtaXRoIHdyb3RlOg0KPj4+PiA+Pj4gPj4gPj4+ PiBGb3IgbWUsIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZSBpbnN0YW5j ZXMNCj4+Pj4gdGhhdA0KPj4+PiA+Pj4gPj5uZWVkcw0KPj4+PiA+Pj4gPj4gPj4+PnRvDQo+Pj4+ ID4+PiA+PiA+Pj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50 aWFsbHkgZXZlbg0KPj4+PmFjcm9zcw0KPj4+PiA+Pj5kYXRhDQo+Pj4+ID4+PiA+PiA+Pj4+IGNl bnRlcnMgd2l0aGluIGFuIGFkbWluaXN0cmF0aXZlIHNjb3BlLCBpcyBsYXJnZSBlbm91Z2gNCj4+ Pj5hbmQNCj4+Pj4gPj4+IGNvbXBsZXgNCj4+Pj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5 aW5nIHRvIGdldCB0aGF0IGludG8gZWFjaCBTRkYgc2VlbXMgbGlrZSBhDQo+Pj4+ID4+PmRpZmZp Y3VsdA0KPj4+PiA+Pj4gPj4gPj4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+Pj4gPj4+ ID4+ID4+Pg0KPj4+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRvIHdoeSB0aGF0IGlzIG1v cmUgY29tcGxpY2F0ZWQgdGhhbiBkeW5hbWljDQo+Pj4+ID4+PiByb3V0aW5nLA0KPj4+PiA+Pj4g Pj4gPj4+IGh5cGVyLXNjYWxlIGRhdGEgY2VudGVyIG9yY2hlc3RyYXRpb24sIG9yIEROUywgYWxs IG9mIHdoaWNoDQo+Pj4+YXJlDQo+Pj4+ID4+PiA+PmJpZ2dlcg0KPj4+PiA+Pj4gPj4gPj4+IHBy b2JsZW1zIHRoYXQgaGF2ZSBiZWVuIHByb2ZpdGFibHkgYW5kIHN0YWJseSBpbXBsZW1lbnRlZD8N Cj4+Pj4gPj4+ID4+ID4+Pg0KPj4+PiA+Pj4gPj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBp dCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRlZCwgdGhhdA0KPj4+PmlzDQo+Pj4+YQ0KPj4+PiA+ Pj5nb29kDQo+Pj4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRlZC4N Cj4+Pj4gPj4+ID4+ID4+Pg0KPj4+PiA+Pj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gPj4+ID4+ID4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4g W2ptaEBqb2VsaGFscGVybi5jb21dDQo+Pj4+ID4+PiA+PiA+Pj4gU2VudDogVGh1cnNkYXksIEp1 bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPj4+PiA+Pj4gPj4gPj4+IFRvOiBSb24gUGFya2VyOyBKb2Vs IEhhbHBlcm4gRGlyZWN0OyBtaWtlYmlhbmNAYW9sLmNvbTsgSWFuDQo+Pj4+ID4+PlNtaXRoOw0K Pj4+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4+PiA+Pj4gPj4gPj4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+Pj4+QmFsYW5jZXJzDQo+ Pj4+ID4+PiA+PiA+Pj4NCj4+Pj4gPj4+ID4+ID4+PiBUaGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwg aXNzdWUuICBBbmQgb25lIHRoYXQgSSB3b3VsZA0KPj4+PnByZWZlcg0KPj4+PndlDQo+Pj4+ID4+ PiA+PiA+Pj5hY3R1YWxseQ0KPj4+PiA+Pj4gPj4gPj4+IGRlY2lkZSwgcmF0aGVyIHRoYW4gdHJ5 aW5nIHRvIGFsbG93IGFsbCBwb3NzaWJsZQ0KPj4+PmltcGxlbWVudGF0aW9ucy4NCj4+Pj4gPj4+ ID4+ID4+PiBCZWNhdXNlIGl0IGRvZXMgaGF2ZSBhIG1ham9yIGVmZmVjdCBvbiB0aGUgY29udHJv bA0KPj4+PnJlcXVpcmVtZW50cw0KPj4+PiA+Pj5hbmQNCj4+Pj4gPj4+ID4+IHRoZQ0KPj4+PiA+ Pj4gPj4gPj4+IGZ1bmN0aW9uYWxpdHkgb2YgU0ZGcy4NCj4+Pj4gPj4+ID4+ID4+Pg0KPj4+PiA+ Pj4gPj4gPj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBzZXJ2aWNl IGluc3RhbmNlcw0KPj4+PnRoYXQNCj4+Pj4gPj4+IG5lZWRzDQo+Pj4+ID4+PiA+PiB0bw0KPj4+ PiA+Pj4gPj4gPj4+IGJlIHdpZGVseSBkaXN0cmlidXRlZCBhbmQgbWFpbnRhaW5lZCwgcG90ZW50 aWFsbHkgZXZlbg0KPj4+PmFjcm9zcw0KPj4+PiA+Pj5kYXRhDQo+Pj4+ID4+PiA+PiA+Pj4gY2Vu dGVycyB3aXRoaW4gYW4gYWRtaW5pc3RyYXRpdmUgc2NvcGUsIGlzIGxhcmdlIGVub3VnaCBhbmQN Cj4+Pj4gPj4+Y29tcGxleA0KPj4+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBn ZXQgdGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zIGxpa2UgYQ0KPj4+PiA+Pj5kaWZmaWN1bHQNCj4+ Pj4gPj4+ID4+ID4+PiBhcmNoaXRlY3R1cmUgdG8gcmVhbGl6ZS4NCj4+Pj4gPj4+ID4+ID4+Pg0K Pj4+PiA+Pj4gPj4gPj4+IFlvdXJzLA0KPj4+PiA+Pj4gPj4gPj4+IEpvZWwNCj4+Pj4gPj4+ID4+ ID4+Pg0KPj4+PiA+Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+Pj4+ID4+ PiA+PiA+Pj4NCj4+Pj4gPj4+ID4+ID4+PiBPbiA3LzEwLzE0LCA5OjM4IFBNLCBSb24gUGFya2Vy IHdyb3RlOg0KPj4+PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4IG9mIG15IGlzc3VlLiAg IElzIHRoZSBlbmQgdG8gZW5kDQo+Pj4+c2VsZWN0aW9uDQo+Pj4+b2YNCj4+Pj4gPj4+ID4+ID4+ Pj4gKHRvcC1sZXZlbCkgaW5zdGFuY2VzIHBlcmZvcm1lZCBjZW50cmFsbHkgKHBlcmhhcHMgYnkg dGhlDQo+Pj4+ID4+PiA+PmNsYXNzaWZpZXIpDQo+Pj4+ID4+PiA+PiA+Pj4+IG9yIGhvcC1ieS1o b3AgKHBlcmhhcHMgYnkgdGhlIGNsYXNzaWZpZXIgYW5kIHN1YnNlcXVlbnRseQ0KPj4+PnRoZQ0K Pj4+PiA+Pj4gPj5TRkZzKT8NCj4+Pj4gPj4+ID4+ID4+Pj4gU3VjaCBzZWxlY3Rpb24gaXMgbm90 IGVxdWl2YWxlbnQgdG8gcmVjbGFzc2lmaWNhdGlvbi4NCj4+Pj5BbmQNCj4+Pj4gPj4+c3VyZWx5 LA0KPj4+PiA+Pj4gPj4gPj4+PiB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyYWwgaXNzdWUgYW5kIG5v dCByZWxlZ2F0ZWQgdG8NCj4+Pj4gPj4+ID4+ID4+Pj4gImltcGxlbWVudGF0aW9uIi4NCj4+Pj4g Pj4+ID4+ID4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4gTXkgb3duIHZpZXcgaXMgdG8gZmF2b3IgdGhl IGRpc3RyaWJ1dGVkIGFwcHJvYWNoIGV2ZW4NCj4+Pj50aG91Z2gNCj4+Pj4gYQ0KPj4+PiA+Pj4g Pj4gPj4+PiBncmVhdGVyIGFtb3VudCBvZiBkYXRhIChjaGFpbiBkZWZpbml0aW9ucyBhbmQgcGVy aGFwcw0KPj4+PmxvY2FsDQo+Pj4+ID4+PiA+PnNlbGVjdGlvbg0KPj4+PiA+Pj4gPj4gPj4+PiBw b2xpY3kpIGlzIHJlcXVpcmVkIGF0IHRob3NlIGRpc3RyaWJ1dGVkIGRlY2lzaW9uIHBvaW50cy4N Cj4+Pj5UaGlzDQo+Pj4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVpcmUgYW4g ZW5kLXRvLWVuZCBwYXRoIGlkIGF0IGFsbC4NCj4+Pj5NeQ0KPj4+PiA+Pj4gPj4gPj4+PiByYXRp b25hbGUgZm9yIGZhdm9yaW5nIHRoaXMgYXBwcm9hY2ggaXMgcHJpbWFyaWx5IGRyaXZlbg0KPj4+ PmJ5DQo+Pj4+ID4+PiA+PmluY3JlYXNlZA0KPj4+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92 ZXIgdGhlIGdsb2JhbCBwYXRoIGlkIGFwcHJvYWNoLiAgIFdpdGggYQ0KPj4+Pmdsb2JhbA0KPj4+ PiA+Pj5wYXRoDQo+Pj4+ID4+PiA+PmlkDQo+Pj4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoLCBjb25z aWRlciBmYWlsdXJlIG9mIGFuIGluc3RhbmNlIGFuZCBuZWVkaW5nIHRvDQo+Pj4+YWx0ZXINCj4+ Pj4gPj4+dGhlDQo+Pj4+ID4+PiA+PiA+Pj4+IGdsb2JhbCBwYXRoIElEIHRhYmxlIGZvciBlYWNo IGFuZCBldmVyeSBhZmZlY3RlZA0KPj4+PmVuZC10by1lbmQNCj4+Pj4gPj4+cGF0aC4NCj4+Pj4g Pj4+ID4+ID4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4gUm9uDQo+Pj4+ID4+PiA+PiA+Pj4+DQo+Pj4+ ID4+PiA+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gRnJv bTogc2ZjDQo+Pj4+ID4+PiA+PiA+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxm IG9mIEpvZWwgSGFscGVybiBEaXJlY3QNCj4+Pj4gPj4+ID4+ID4+Pj4gW2ptaC5kaXJlY3RAam9l bGhhbHBlcm4uY29tXSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0KPj4+PiA2OjE1DQo+ Pj4+ID4+PiBQTQ0KPj4+PiA+Pj4gPj4gPj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb207IEkuU21p dGhARjUuY29tOyBzZmNAaWV0Zi5vcmcNCj4+Pj5TdWJqZWN0Og0KPj4+PiBSZToNCj4+Pj4gPj4+ ID4+ID4+Pj4gW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMN Cj4+Pj4gPj4+ID4+ID4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0 dXJlIG1vZGVscyB0aGUgY2FzZSBvZiBTRjEgbmVlZGluZyB0bw0KPj4+PiA+Pj4gPj5pbmZsdWVu Y2UNCj4+Pj4gPj4+ID4+ID4+Pj4gdGhlIGNoYWluIGlzIHRoYXQgb25lIHdvdWxkIGRvIHJlY2xh c3NpZmljYXRpb24gYXQgdGhlDQo+Pj4+ZXhpdA0KPj4+PmZyb20NCj4+Pj4gPj4+ID4+ID4+Pj4g U0YxLg0KPj4+PiA+Pj4gPj4gPj4+Pg0KPj4+PiA+Pj4gPj4gPj4+PiBQYXJ0IG9mIHRoZSBnb2Fs IGlzIHRvIGtlZXAgdGhlIGRpZmZlcmVudCBmdW5jdGlvbnMNCj4+Pj5sb2dpY2FsbHkNCj4+Pj4g Pj4+ID4+ID4+Pj4gc2VwYXJhdGUgc28gdGhhdCBzb2x1dGlvbnMgY2FuIGNsZWFybHkgZGVzY3Jp YmUgaG93IHRoZXkNCj4+Pj4gY2hvb3NlDQo+Pj4+ID4+PnRvDQo+Pj4+ID4+PiA+PiA+Pj4+IGNv bXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRlbGl2ZXJ5Lg0KPj4+PiA+Pj4gPj4gPj4+Pg0KPj4+ PiA+Pj4gPj4gPj4+PiBZb3VycywgSm9lbA0KPj4+PiA+Pj4gPj4gPj4+Pg0KPj4+PiA+Pj4gPj4g Pj4+PiBPbiA3LzEwLzE0LCA2OjEwIFBNLCBtaWtlYmlhbmNAYW9sLmNvbSB3cm90ZToNCj4+Pj4g Pj4+ID4+ID4+Pj4+IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoZSBhcmNoIGRyYWZ0IHRoYXQg c3VnZ2VzdHMgYW55DQo+Pj4+c29ydA0KPj4+PiA+Pj5vZg0KPj4+PiA+Pj4gPj4gPj4+Pj4gbGlt aXQuIEhvd2V2ZXIsIGl0IGRvZXMgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBlbnRpcmUNCj4+ Pj5wYXRoDQo+Pj4+ID4+PihhbGwNCj4+Pj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hv c2VuIGF0IFNGQyBpbnN0YW50aWF0aW9uLiAgSSBiZWxpZXZlDQo+Pj4+dGhpcw0KPj4+PiA+Pj5t ZWFucw0KPj4+PiA+Pj4gPj4gPj4+Pj4gZWl0aGVyIGF0IHRoZSBjbGFzc2lmaWVyIG9yIG1heWJl IHRoZSBjbGFzc2lmaWVyIGNob29zZXMNCj4+Pj5hDQo+Pj4+U0YNCj4+Pj4gPj4+ID4+Q2hhaW4N Cj4+Pj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQgdGhlIGxhdGVzdCB0aGUgZmlyc3Qg U0ZGLiAgSW4gYW55IGNhc2UsDQo+Pj4+dGhlDQo+Pj4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBk b2VzIHNlZW0gdG8gcHJvaGliaXQgYSBtb3JlIGR5bmFtaWMgU0ZQIHdoZXJlDQo+Pj4+IFNGSShu KQ0KPj4+PiA+Pj4gaXMNCj4+Pj4gPj4+ID4+ID4+Pj4+IGRldGVybWluZWQgYXQgdGhlIFNGSShu LTEpIGhvcC4gIEFjY29yZGluZyB0byB0aGUgZHJhZnQsDQo+Pj4+dGhpcw0KPj4+PiA+Pj4gPj4g Pj4+Pj4gYmVoYXZpb3Igd291bGQgYmUgY29uc2lkZXJlZCAiYnJhbmNoaW5nIiB0byBhIG5ldyBT RlAgYXMNCj4+Pj4gPj4+IG9wcG9zZWQNCj4+Pj4gPj4+ID4+IHRvDQo+Pj4+ID4+PiA+PiA+Pj4+ PiBjaG9vc2luZyBhbmQgdGhlbiBmb3J3YXJkaW5nIHRvIHRoZSBzZWxlY3RlZCBpbnN0YW5jZSBv Zg0KPj4+PnRoZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4gbmV4dC1ob3Agb2YgdGhlIGN1cnJlbnQgU0ZD Lg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+IGRyYWZ0LW1lcmdlZC1zZmMt YXJjaGl0ZWN0dXJlLTAwOg0KPj4+PiA+Pj4gPj4gPj4+Pj4+IFdoZW4gYW4gU0ZDIGlzIGluc3Rh bnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIGl0IGlzDQo+Pj4+bmVjZXNzYXJ5DQo+Pj4+ID4+PnRv DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gc2VsZWN0IHRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgb2YgU0Zz IHRoYXQgd2lsbCBiZSB1c2VkLA0KPj4+PmFuZCB0bw0KPj4+PiA+Pj4gPj4gPj4+Pj4+IGNyZWF0 ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0Yncw0KPj4+Pm5ldHdv cmsNCj4+Pj4gPj4+ID4+ID4+Pj4+PiBsb2NhdG9yLiAgVGh1cywgaW5zdGFudGlhdGlvbiBvZiB0 aGUgU0ZDIHJlc3VsdHMgaW4gdGhlDQo+Pj4+ID4+PmNyZWF0aW9uDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4gb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlzIHVzZWQgZm9yDQo+Pj4+ Zm9yd2FyZGluZw0KPj4+PiA+Pj4gPj4gPj4+Pj4+IHBhY2tldHMgdGhyb3VnaCB0aGUgU0ZDLiBJ biBvdGhlciB3b3JkcywgYW4gU0ZQIGlzIHRoZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+IGluc3RhbnRp YXRpb24gb2YgdGhlIGRlZmluZWQgU0ZDLg0KPj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4+ID4+PiA+ PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAo b3INCj4+Pj5ub24taW5pdGlhbA0KPj4+PiA+Pj4gPj4gPj4+Pj4+IGNsYXNzaWZpY2F0aW9uKSBh cyB3ZWxsLiAgQXMgcGFja2V0cyB0cmF2ZXJzZSBhbiBTRlAsDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4g cmVjbGFzc2lmaWNhdGlvbiBtYXkgb2NjdXIgLSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IGENCj4+ Pj4gPj4+ID4+ID4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBmdW5jdGlvbiBjby1yZXNpZGVudCB3aXRo IGEgc2VydmljZQ0KPj4+PmZ1bmN0aW9uLg0KPj4+PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3NpZmlj YXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0aW9uIG9mIGEgbmV3DQo+Pj4+U0ZQLCBhbg0K Pj4+PiA+Pj4gPj4gPj4+Pj4+IHVwZGF0ZSBvZiB0aGUgYXNzb2NpYXRlZCBtZXRhZGF0YSwgb3Ig Ym90aC4gIFRoaXMgaXMNCj4+Pj5yZWZlcnJlZA0KPj4+PiA+Pj50bw0KPj4+PiA+Pj4gPj4gPj4+ Pj4+IGFzICJicmFuY2hpbmciLg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+ DQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+DQo+Pj4+ ID4+Pg0KPj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pi0tDQo+Pj4+Pj4+ Pj4+Pj4+Pi0tLQ0KPj4+PiA+Pj4+Pj4+Pj4+LS0NCj4+Pj4gPj4+ID4+Pj4+Pj4tLQ0KPj4+PiA+ Pj4gPj4gPj4+Pj4tLQ0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+ICpGcm9tOiAqSS5TbWl0aEBGNS5jb208SS5T bWl0aEBGNS5jb20+DQo+Pj4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4NCj4+Pj5E aXJlY3Q8am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+LEpvZWwNCj4+Pj4gTS4NCj4+Pj4gPj4+ ID4+ID4+Pj4+DQo+Pj4+ID4+PiA+Pg0KPj4+PiA+Pj4NCj4+Pj4gPj4+Pj5IYWxwZXJuPGptaEBq b2VsaGFscGVybi5jb20+LGh1YW5nQHNjZS5jYXJsZXRvbi5jYTxodWFuZ0BzY2UuDQo+Pj4+ID4+ PiA+PiBjYXJsZXRvbi4NCj4+Pj4gPj4+ID4+ID4+Pj4+Y2E+LHNmY0BpZXRmLm9yZzxzZmNAaWV0 Zi5vcmc+DQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ ID4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4gKlNlbnQ6ICpUaHVyc2RheSwgSnVseSAxMCwgMjAxNA0K Pj4+PiA+Pj4gPj4gPj4+Pj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBh dGhzLCBhbmQgTG9hZA0KPj4+PkJhbGFuY2Vycw0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ ID4+ID4+Pj4+IEFjdHVhbGx5LCBJIHRoaW5rIEkgYW0gZGlzYWdyZWVpbmcuDQo+Pj4+ID4+PiA+ PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4gSWYgdGhlIHBvc3NpYmlsaXR5IG9mIG1lZGl1bS1z Y2FsZSBkZXBsb3ltZW50cyAoYW5kIHRoYXQNCj4+Pj5pcw0KPj4+PiA+Pj53aGF0DQo+Pj4+ID4+ PiA+PiA+Pj4+PiAxNiBtaWxsaW9uIGZsb3dzIGlzIGluIG15IHdvcmxkKSBvZiBzZXJ2aWNlIGNo YWlucyBpcw0KPj4+PiA+Pj5wcmVjb25jZWl2ZWQNCj4+Pj4gPj4+ID4+ID4+Pj4+IGFzIGFuIGFi c3VyZCBpZGVhLCB0aGVuIHRoZSBhcmNoaXRlY3R1cmUgYnVyZGVuZWQgd2l0aA0KPj4+PnRoYXQN Cj4+Pj4gPj4+ID4+ID4+Pj4+IHByZWNvbmNlcHRpb24uDQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+ PiA+Pj4gPj4gPj4+Pj4gVGhlcmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRl Z3JlZSBvZg0KPj4+PmFzcGlyYXRpb24NCj4+Pj4gdG8NCj4+Pj4gPj4+ID4+ID4+Pj4+IHNjYWxl IHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4+Pj5hcmNoaXRl Y3R1cmUNCj4+Pj4gPj4+LQ0KPj4+PiA+Pj4gPj4gPj4+Pj4geW91IGRvbid0IGhhdmUgdG8ga25v dyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nIHRoYXQgYW4NCj4+Pj4gPj4+YXJiaXRyYXJ5DQo+ Pj4+ID4+PiA+PiA+Pj4+PiBudW1iZXIgaXMgInRvbyBmYXIiLCB5b3UncmUgY3JlYXRpbmcgLSBl dmVuIGlmIGl0IGlzbid0DQo+Pj4+ID4+PiA+PmludGVudGlvbmFsDQo+Pj4+ID4+PiA+PiA+Pj4+ PiAtIGEgbGltaXQgdGhhdCBpbmZsdWVuY2VzIGRlY2lzaW9ucyB0aGF0IGhhdmUgbGFzdGluZw0K Pj4+PmltcGFjdHMNCj4+Pj4gPj4+ID4+ID4+Pj4+IHJlZ2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1 cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4+Pj5hZGRyZXNzDQo+Pj4+ID4+PiA+PiA+Pj4+ PiBzcGFjZS4uLiBhbGwga2luZHMgb2YgdGhpbmdzLiBUaGF0IGlzIGEgcHJvYmxlbSBJJ20gbm90 DQo+Pj4+ID4+PiA+PiA+Pj4+PiBwYXJ0aWN1bGFybHkgZWFnZXIgdG8gZGVhbCB3aXRoLg0KPj4+ PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+ PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pg0K Pj4+PiA+Pj4gPj4gPj4+Pj4gRnJvbTogSm9lbCBIYWxwZXJuIERpcmVjdCBbam1oLmRpcmVjdEBq b2VsaGFscGVybi5jb21dDQo+Pj4+U2VudDoNCj4+Pj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBK dWx5IDEwLCAyMDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbCBNLg0KPj4+PiBIYWxwZXJu Ow0KPj4+PiA+Pj4gPj4gPj4+Pj4gaHVhbmdAc2NlLmNhcmxldG9uLmNhOyBzZmNAaWV0Zi5vcmcg U3ViamVjdDogUmU6IFtzZmNdDQo+Pj4+U2VydmljZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4gQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4g Pj4gPj4+Pj4gSWFuLCBJIGRvbid0IHRoaW5rIHlvdSBkaXNhZ3JlZSB3aXRoIG1lIGF0IGFsbCBp biB0aGlzDQo+Pj4+cmVnYXJkLg0KPj4+PiA+Pj5JDQo+Pj4+ID4+PiA+PmFtDQo+Pj4+ID4+PiA+ PiA+Pj4+PiBub3QgcmVxdWVzdGluZyB0aGUgdGhlIGFyY2hpdGVjdHVyZSBvciB0aGUgc29sdXRp b24NCj4+Pj5wcm9oaWJpdA0KPj4+PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNw ZWNpZmljIGZhc2hpb24uIEkgYW0gb2JqZWN0aW5nIHRvDQo+Pj4+SHVhbmcncw0KPj4+PiA+Pj4g Pj4gPj4+Pj4gcmVhZGluZyBvZiBteSBub3RlIGFzIHNheWluZyB0aGF0IHN1Y2ggZGVwbG95bWVu dHMgYXJlDQo+Pj4+IHJlcXVpcmVkDQo+Pj4+ID4+PiA+PiA+Pj4+PiB0aGV5IGJ5IHRoZSBhcmNo dGllY3R1cmUuDQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4gQXMgSSBoYXZl IHNhaWQgcmVwZWF0ZWRseSwgSSBhbSBub3QgdHJ5aW5nIHRvIHByb2hpYml0DQo+Pj4+c3VjaA0K Pj4+PiA+Pj4gPj4gPj4+Pj4gdGhpbmdzLiBXaGV0aGVyIHRoZXkgYXJlIGEgZ29vZCBpZGVhIG9y IG5vdCBkZXBlbmRzIHVwb24NCj4+Pj4gbWFueQ0KPj4+PiA+Pj4gPj4gPj4+Pj4gZmFjdG9ycyBv dXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvIHRoaW5rDQo+Pj4+dGhh dA0KPj4+PiA+Pj4gPj50aGV5DQo+Pj4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBp ZGVhLg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+IEJ1dCB0aGUgYXJjaHRp ZWN0dXJlIHNpIGNhcmVmdWxseSBhdm9pZGluZyBhdHRlbXB0aW5nIHRvDQo+Pj4+a25vdw0KPj4+ PiA+Pj53aGF0DQo+Pj4+ID4+PiA+PiA+Pj4+PiBpcyBhbmQgaXMgbm90IGVwbG95YWJsZS4NCj4+ Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPj4+PiA+Pj4g Pj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+IE9uIDcvMTAvMTQsIDU6MDEgUE0sIElhbiBTbWl0 aCB3cm90ZToNCj4+Pj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPj4+PiA+Pj4gPj4gPj4+ Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gV2Ugcm91dGluZWx5IGhhdmUgc3RhdGVmdWwgZGV2aWNl cyB0aGF0IG1hbmFnZSB0ZW5zIG9mDQo+Pj4+ID4+Pm1pbGxpb25zDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4gb2YNCj4+Pj4gPj4+ID4+ID4+Pj4+IGNvbmN1cnJlbnQgZmxvd3MgaW4gYm90aCBhY2Nlc3Mg bmV0d29yayBhbmQgZGF0YSBjZW50ZXINCj4+Pj4gPj4+ID4+ID4+Pj4+IGVudmlyb25tZW50cyB0 b2RheS4gWW91IGNhbid0IHNlcmlvdXNseSBiZWxpZXZlIHRoYXQgaW4NCj4+Pj50aGUNCj4+Pj4g Pj4+ID4+ID4+Pj4+IENsb3VkL0lQdjYvTW9iaWxpdHkvV2ViMi4wL0lvVCB3b3JsZCBvZiB0b21v cnJvdyB5b3UgYXJlDQo+Pj4+IG9ubHkNCj4+Pj4gPj4+ID4+IGdvaW5nDQo+Pj4+ID4+PiA+PiA+ Pj4+PiB0byBoYXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5 DQo+Pj4+c21hbGwNCj4+Pj4gPj4+IG51bWJlcnMNCj4+Pj4gPj4+ID4+ID4+Pj4+IG9mIGFjdGl2 ZSBzZXJ2aWNlIHBhdGhzPw0KPj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4g WW91ciBzb3VuZHMgdG9vIG11Y2ggbGlrZSAibm8gb25lIHdpbGwgZXZlciBuZWVkIG1vcmUNCj4+ Pj50aGFuDQo+Pj4+ID4+PiA2NEsiDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gZm9yDQo+Pj4+ID4+PiA+ PiA+Pj4+PiBjb21mb3J0Lg0KPj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4N Cj4+Pj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIEZyb206IHNmYw0KPj4+PiA+Pj4gPj4gPj4+Pj4+IFtzZmMtYm91bmNlc0BpZXRmLm9yZ10g b24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybg0KPj4+PiA+Pj4gPj4gPj4+Pj4gW2ptaEBqb2Vs aGFscGVybi5jb21dDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgNDo0NiBQTSBUbzoNCj4+Pj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhOw0KPj4+PiA+ Pj4gPj4gPj4+Pj4+IHNmY0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW3NmY10gU2VydmljZSBDaGFp bnMsIFBhdGhzLA0KPj4+PmFuZA0KPj4+PiA+Pj5Mb2FkDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gQmFs YW5jZXJzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+PiBObywgaXQgd2ls bCBtZWFuIHRoYXQgaWYgc29tZW9uZSB0cmllcyB0byBkZXBsb3kgdGhlDQo+Pj4+ID4+PmFyY2h0 aWV0dXJlDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5IHdpbGwg ZXhjZWVkIHRoZSBsaW1pdHMgb2YgdGhlaXINCj4+Pj4gPj4+ID4+ID4+Pj4+PiBkZXZpY2VzLiBU aGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHJlcXVpcmUgc3VjaCBhYnN1cmQNCj4+Pj51c2UNCj4+ Pj4gb2YNCj4+Pj4gPj4+ID4+ID4+Pj4+PiBzZXJ2aWNlIHBhdGhzLiBTaW5jZSBJIGNhbiBub3Qg ZmlndXJlIG91dCBob3cgdG8gd3JpdGUNCj4+Pj4gPj4+ID4+ID4+Pj4+PiBhcmNoaXRlY3R1cmFs IHdvcmRzIHRvIHByb2hpYml0IGl0LCB0aGUgYXJjaGl0ZWN0dXJlDQo+Pj4+ZG9lcw0KPj4+PiA+ Pj5wZXJtaXQNCj4+Pj4gPj4+ID4+ID4+Pj4+PiBzdWNoIGFidXNlLg0KPj4+PiA+Pj4gPj4gPj4+ Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gUGxlYXNlIGRvIG5vdCByZWFkIG15IHNheWluZyB0aGF0 IHRoZSBhcmNodGllY3R1cmUNCj4+Pj5wZXJtaXRzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gc29tZXRo aW5nIGFzIHNheWluZyBpdCBpcyBlaXRoZXIgZGVpc3JlZCBvciByZXF1aXJlZCBieQ0KPj4+PnRo ZQ0KPj4+PiA+Pj53b3JrLg0KPj4+PiA+Pj4gPj4gPj4+Pj4+IEl0IGlzbid0Lg0KPj4+PiA+Pj4g Pj4gPj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+IE9uIDcvMTAvMTQsIDQ6MzYgUE0sIENoYW5nY2hlbmcg SHVhbmcgd3JvdGU6DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQg MTAwIHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsIG1lYW4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4gMTYs MDAwLDAwMCBwYXRocy4gVGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgcm91dGluZyB0YWJsZQ0KPj4+ Pm9mIGENCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4gY29yZSByb3V0ZXIuDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+IENoYW5nDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+IE9uIDA3LzEwLzIwMTQgMDE6MTUgUE0sIEpvZWwgTS4gSGFscGVybiB3 cm90ZToNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+IFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGEgcmFu Z2Ugb2YgZGVwbG95bWVudHMsIGZyb20gMQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4gc2VydmljZSBw YXRoIHRvIDE2MDAwMCBzZXJ2aWNlIHBhdGhzLiBJIHdvdWxkIGhvcGUNCj4+Pj50aGF0DQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0 aWVzIGlmIHRoZXkNCj4+Pj5jaG9vc2UNCj4+Pj4gPj4+dG8NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+ IGF2b2lkIGFueSB1c2Ugb2YgbG9jYWwgbG9hZCBiYWxhbmNpbmcgYW5kIGluIHN0ZWFkDQo+Pj4+ IHByb3Zpc2lvbg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0K Pj4+PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ Pj4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4gT24gNy8xMC8xNCwgNDow NiBQTSwgTkFQSUVSQUxBLCBNQVJJQSBIIHdyb3RlOg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBh dWwsDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBIb3cgbWFu eSBwYXRoIGlkZW50aWZpZXJzIHRoZXJlIHdpbGwgYmUgZm9yIGEgNCBob3ANCj4+Pj4gc2Vydmlj ZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGNoYWluIHdpdGggMjAgaW5zdGFuY2VzIGF0IGVhY2gg aG9wPw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gTWFyaWEN Cj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPj4+Pk9mDQo+Pj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gKlBhdWwgUXVpbm4gKHBhdWxxKSAqU2VudDoqIFRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0DQo+Pj4+MzowMw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1Y3kg eW9uZyAqQ2M6KiBqbWhAam9lbGhhbHBlcm4uY29tOw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZzsNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbSAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+ Pj4+Q2hhaW5zLA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3ksDQo+ Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdmVyYWxsIEkgY29u Y3VyLCBhcyB5b3Ugc2F5OiBhIHBhdGggSUQgZHJpdmVzIHRoZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGZvcndhcmRpbmcuIEnCuWQNCj4+Pj4gPj4+ID4+ID4+Pj4+IG1ha2UNCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZSB1 c2VkIHRvDQo+Pj4+IGRlcml2ZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBuZWVkZWQgZm9y d2FyZGluZyBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQuDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0 aGVyIGlzIHVzZWQgdG8NCj4+Pj5zaW1wbHkNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBpZGVudGlm eSB0aGUgc2VydmljZSBwYXRoIChvciBncmFwaCkgdGhhdCBwYWNrZXRzDQo+Pj4+bXVzdA0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50aWZpZXIs IHRoZSBleGFjdA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluZGlyZWN0aW9uIHRoYXQgcGVvcGxl IHNlZW0gdG8gYmUgYXNraW5nIGZvciBvbiB0aGlzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhy ZWFkIGNhbiBiZSBzaW1wbHkgYmUgaW1wbGVtZW50ZWQuIFRoZSBwYXRoDQo+Pj4+IGlkZW50aWZp ZXINCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBwcm92aWRlcyBub3RoaW5nIG1vcmUgdGhhbiBhIGxv b2t1cCwgdGhhdCBsb29rdXAgY2FuDQo+Pj4+IHJlc3VsdA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluIGEgb25lIG9yIG1vcmUgKGVxdWFsIG9yIHdlaWdodGVkKSB0cmFuc3BvcnQgbmV4dA0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IGhvcChzKS4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IFBhdWwNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxsdWN5LnlvbmdAaHVhd2VpLmNvbQ0KPj4+PiA8bWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90 IG1hbmRhdGUgb25seSB1c2Ugb2YNCj4+Pj50aGUNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBzZXJ2 aWNlIHBhdGggaWRlbnRpZmllciB0byBkcml2ZSB0aGUgZm9yd2FyZGluZw0KPj4+PmFjdGlvbnMu DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBMdWN5DQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddKk9uIEJlaGFsZg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE9mKm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA8 bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+Pj4+ID4+PiAqU2VudDoqVGh1 cnNkYXksDQo+Pj4+ID4+PiA+PiBKdWx5DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMTAsIDIwMTQg MjowNiBBTSAqVG86Km1pa2ViaWFuY0Bhb2wuY29tDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1h aWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47c2ZjQGlldGYub3JnDQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpTdWJqZWN0OipSZTogW3Nm Y10gU2VydmljZQ0KPj4+PkNoYWlucywNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXRocywgYW5k IExvYWQgQmFsYW5jZXJzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBSZS0sDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBU aGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZSBwYXRoDQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmplY3QgdG8gdXNlIHRoYXQgaWRlbnRp ZmllciB0byBkZXJpdmUNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMu DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcg YSBTRkMgc3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwga25vd2xlZGdlIG9mDQo+Pj4+IGV2ZXJ5DQo+ Pj4+ID4+PiA+PiA+Pj4+PiBhdmFpbGFibGUgU0ZDDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9y d2FyZGluZyBwYXRocyB3aXRoaW4gYW4gU0ZDLWVuYWJsZWQgZG9tYWluIGlzIG5vdA0KPj4+PiA+ Pj4gPj4gPj4+Pj4gcmVxdWlyZWQvanVzdGlmaWVkDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9y IHBvc3NpYmxlIGluIHZhcmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy4NCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNGQyBmb3J3YXJkaW5nIGFjdGlvbnMgc2hv dWxkIHJlbHkgb24gdGhlIHBpZWNlIG9mDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3JtYXRp b24NCj4+Pj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJl IHByZXNlbnQgaW4gYWxsIGRlcGxveW1lbnRzOiB0aGF0IGlzIHRoZSBvbmUNCj4+Pj5yZXF1aXJl ZA0KPj4+PiB0bw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN0cnVjdHVyZSBhIHNlcnZpY2UgY2hh aW4uIEhvdyB0aGF0IGluZm9ybWF0aW9uIGlzDQo+Pj4+dXNlZCB0bw0KPj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4+Pj4gPj4+ID4+ID4+Pj4+IGFjdGlvbnMNCj4+Pj4g Pj4+ID4+ID4+Pj4+Pj4+PiBpcyBhIHNvbHV0aW9uLW9yaWVudGVkIGRpc2N1c3Npb24uDQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpEZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSpEZSBsYSBwYXJ0DQo+Pj4+ID4+PiA+PiA+Pj4+PiBkZSptaWtlYmlhbmNA YW9sLmNvbQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpFbnZvecOpIDoqbWVyY3JlZGkgOQ0KPj4+PiBqdWlsbGV0DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gMjAxNCAyMjowMyAqw4AgOipqbWhAam9lbGhhbHBlcm4uY29tDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4gKk9iamV0IDoqUmU6IFtzZmNdIFNl cnZpY2UNCj4+Pj5DaGFpbnMsDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF0aHMsIGFuZCBMb2Fk IEJhbGFuY2Vycw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4g SXMgYW55b25lIHN0aWxsIHF1ZXN0aW9uaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU0YNCj4+ Pj4gQ2hhaW4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4+Pj4gPj4+ID4+ID4+Pj4+ IFBhdGg/DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gT3RoZXIgdGhhbiBjbGFyaWZ5aW5nIHRoZSBk ZWZpbml0aW9uIHNvIHRoYXQgaXQncw0KPj4+PmNsZWFyIHRvDQo+Pj4+ID4+PiA+PiA+Pj4+PiB0 aG9zZSBub3QNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmYW1pbGlhciB3aXRoIHRoZSBkcmFmdCwg aXQgc2VlbXMgdGhhdCBldmVyeW9uZQ0KPj4+PmFncmVlcw0KPj4+Pm9uDQo+Pj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhlc2UgdGVybXMuDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlzIHN0aWxsIHVuY2xlYXIgaXMg d2hldGhlcg0KPj4+Pml0IGlzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdGhlIGludGVudCBvZiB0 aGlzIGRyYWZ0IHRvIHVsdGltYXRlbHkgc3BlY2lmeSB3aGF0DQo+Pj4+dGhlIElEDQo+Pj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4+Pj4gPj4+ID4+ID4+Pj4+IHNob3Vs ZA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlZmVyZW5jZSAodGhlIGNoYWluIG9yIHRoZSBwYXRo KSwgb3IgaWYgdGhpcyBkcmFmdA0KPj4+PnNpbXBseQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlu dGVuZHMgdG8gbGVhdmUgdGhhdCBhbWJpZ3VvdXMsIGFsbG93aW5nIG90aGVyDQo+Pj4+ZHJhZnRz DQo+Pj4+dG8NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZv ciBmb3J3YXJkaW5nIGJhc2VkIG9uIGNoYWluDQo+Pj4+b3INCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBwYXRoIGFuZCB0aGUgY2hvaWNlIG9mIGNoYWluIG9yDQo+Pj4+ID4+PiA+PiA+Pj4+PiBwYXRo IHRvDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmUgbmVnb3RpYXRlZCBpbiB0aGUgY29udHJvbC1w bGFuZS4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRo ZSBsYXR0ZXIgKGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUNCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0ZWQg KG9yIG1ha2UNCj4+Pj4gb25lDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVxdWlyZWQgYW5kIHRo ZSBvdGhlciBvcHRpb25hbCkgdG8gYXZvaWQgc29tZQ0KPj4+PnZlbmRvcnMNCj4+Pj4gb25seQ0K Pj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1cHBvcnRpbmcgU0ZQIGFuZCBvdGhlcnMgb25seSBzdXBw b3J0aW5nIFNGQy4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj4+ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4NCj4+Pj4gPj4+DQo+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4+Pj4+Pj4+Pj4+Pj4+LS0tDQo+Pj4+ID4+ Pj4+Pj4+Pj4tLQ0KPj4+PiA+Pj4gPj4+Pj4+Pi0tDQo+Pj4+ID4+PiA+PiA+Pj4+Pi0tDQo+Pj4+ ID4+PiA+PiA+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KmptaEBqb2VsaGFs cGVybi5jb208am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzY2ptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+ICpUbzoqc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9yZw0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPj4gKlNl bnQ6KlR1ZXNkYXksDQo+Pj4+IEp1bHkNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiA4LCAyMDE0ICpT dWJqZWN0Oipbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0KPj4+PkxvYWQNCj4+Pj4g Pj4+ID4+ID4+Pj4+Pj4+PiBCYWxhbmNlcnMNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBj bGVhcmx5DQo+Pj4+YW5zd2VyDQo+Pj4+YQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG51bWJlciBv ZiBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBtYWRlIGFib3V0IHRoZQ0KPj4+PiA+Pj4gcHJvcG9z ZWQNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQgYXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1 bWluZyB3ZSBjYW4gZ2V0DQo+Pj4+d29ya2luZw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3Vw IGFncmVlbWVudCBvbiB0aGUgaW50ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4+Pj5pbXByb3ZlDQo+ Pj4+IHRoZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdvcmRpbmcgc28gdGhhdCByZWFkZXJzIHdo byBoYXZlIG5vdCBwYXJ0aWNpcGF0ZWQgaW4NCj4+Pj50aGUNCj4+Pj4gV0cNCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJzdG5kIGl0IHRoZSB3YXkgdGhlDQo+Pj4+ ID4+PiA+PiA+Pj4+PiB3b3JraW5nDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZ3JvdXAgaW50ZW5k cy4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJ1dCB3aGF0 IGRvIHdlIGludGVuZD8gSSB3aWxsIHRyeSB0byBleHBsYWluIG15DQo+Pj4+cGVyc29uYWwNCj4+ Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMuDQo+Pj4+ID4+ PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJbiB0aGlzIHJlZ2FyZCwgaXQg aXMgaW1wb3J0YW50IHRvIGtlZXAgaW4gbWluZCB0aGF0DQo+Pj4+d2hhdA0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHdlIGFyZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUu IFdlDQo+Pj4+YXJlDQo+Pj4+IG5vdA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGF0dGVtcHRpbmcg dG8gZGVmaW5lIHRoZSBhcmNoaXRlY3R1cmUgZm9yIHRoZSBlbnRpcmUNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBzb2x1dGlvbiBmb3Igc2VydmljZSBjaGFpbmluZy4gVGhhdCB3b3VsZCBlbmNvbXBh c3MNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBPU1MvQlNTLCB2YXJpb3VzIGNvbnRyb2wgYW5kIHBv bGljeSBmdW5jdGlvbnMsDQo+Pj4+dmlydHVhbA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1hY2hp bmUgYW5kIGltYWdlIG1hbmFnZW1lbnQsIGFuZCBtYW55IG90aGVyDQo+Pj4+IGFzcGVjdHMuDQo+ Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCB0 aGVyZSBhcmUgbWFueSB0aGluZ3Mgd2hpY2ggY2xlYXJseSBuZWVkDQo+Pj4+dG8NCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFyZ2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBk ZWFsdCB3aXRoDQo+Pj4+YWJvdmUNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB3aGVyZSB3ZSBhcmUN Cj4+Pj4gPj4+ID4+ID4+Pj4+IGZ1bmN0aW9uaW5nLA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFu ZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlIGFyZQ0KPj4+PmRvaW5n Lg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSW4gb3JkZXIg dG8gZ2V0IHRvIHNlcnZpY2UgY2hhaW4gdnMgc2VydmljZSBwYXRoLCBhcw0KPj4+PkkNCj4+Pj4g Pj4+ID4+ID4+Pj4+Pj4+PiB1bmRlcnN0YW5kDQo+Pj4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgbmVlZCB0byBmaXJzdCBkaXNjdXNzIGxvYWQgYmFsYW5jaW5n LiBUaGVyZSBhcmUgYXQNCj4+Pj5sZWFzdA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRocmVlIGRp ZmZlcmVudCB3YXlzIHRoYXQgbG9hZCBiYWxhbmNpbmcgY2FuIGFuZCB3aWxsDQo+Pj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qgd2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJs eSBhcmUNCj4+Pj5tb3JlLg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoZSBwb2ludCBvZiB0aGUg YXJjaHRpZWN0dXJlIGlzIHRvIHBlcm1pdCBhbGwgb2YNCj4+Pj50aGVzZSwNCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBidXQgbm90IHRvIG1hbmRhdGUgdGhhdCBhbnkgcGFydGljdWxhciBraW5kDQo+ Pj4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gYW55IHNv bHV0aW9uLg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkg TG9hZCBiYWxhbmNpbmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZSBlbmQNCj4+Pj51c2Vy Lg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzZXJ2aWNlIGZ1bmN0aW9uLiBJdCBy ZWNlaXZlcyB1c2VyIHBhY2tldHMsDQo+Pj4+YW5kDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9k aWZpZXMgdGhlbSAob3INCj4+Pj4gPj4+ID4+ID4+Pj4+IG1hcmtzDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gdGhlbSwgb3IgLi4uKSBzbyBhcyB0byBjaG9vc2UgYW4gZW5kIHVzZXIgc2VydmljZQ0K Pj4+Pmluc3RhbmNlDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUgdXNlcnMg cGFja2V0LiBUaGlzIGlzIGFuIGltcG9ydGFudA0KPj4+PnNlcnZpY2UNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBmdW5jdGlvbiB0byBiZSBhYmxlIHRvIGluY2x1ZGUgaW4gc2VydmljZSBjaGFpbmlu Zy4NCj4+Pj5JdCdzDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYmVoYXZpb3IgbWF5IGFmZmVjdCBy ZXF1aXJlbWVudHMgb24gaG93IHNlcnZpY2UNCj4+Pj4gY2hhaW5pbmcgaXMNCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkb25lLiBCdXQgaXQgaGFzIHZlcnkgbGl0dGxlIGltcGFjdCBvbiB0aGUNCj4+ Pj5hcmNodGllY3R1cmUuDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gIEZyb20gYW4gYXJjaGl0ZWN0 dXJhbCBwZTNyc3BlY3RpdmUgaXQgaXMgc2ltcGx5IGENCj4+Pj4gPj4+ID4+ID4+Pj4+IHNlcnZp Y2UNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1 bmRlcmx5aW5nIHBhY2tldC4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IDIpIFRoZXJlIGlzIGludGVybmFsIGxvYWQgYmFsYW5jaW5nLiBUaGF0IGlzLCBvbmUg Y2FuDQo+Pj4+aGF2ZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoYXQNCj4+Pj4gPj4+ID4+ID4+ Pj4+IGFwcGVhcnMNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0byB0aGUgc2VydmljZSBjaGFpbmlu ZyBhcmNoaXRlY3R1cmUgYXMgYSBzaW5nbGUNCj4+Pj5wb2ludA0KPj4+Pm9mDQo+Pj4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gY29udGFjdA0KPj4+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uLCBidXQgaXMgYWN0dWFsbHkgZGVs aXZlcmVkDQo+Pj4+YnkgYQ0KPj4+PiA+Pj4gPj4gPj4+Pj4gY29sbGVjdGlvbiBvZg0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHZpcnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGlu Y2x1ZGluZyBvbmUNCj4+Pj5vcg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNldmVyYWwgbG9hZCBi YWxhbmNlcnMgKGZvciBleGFtcGxlIHVzaW5nIFZSUlAtbGlrZQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRlY2huaXF1ZXMgdG8gc2hhcmUgYSBNQUMgYWRkcmVzcy4pIG1vc3RseSwgdGhpcyBpcw0K Pj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludmlzaWJsZSB0byB0aGUgc2VydmljZSBjaGFpbmluZyBk YXRhIHBsYW5lDQo+Pj4+bWVjaGFuaXNtcy4NCj4+Pj4gSXQNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpcyBsaWtlbHkgdGhhdCBpdCBpcyB2aXNpYmxlIHRvIHZhcmlvdXMgY29udHJvbA0KPj4+Pm1l Y2hhbmlzbXMsDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3VjaCBhcyB0aG9zZSByZXNwb25zaWJs ZSBmb3Igc2NhbGUtaW4sIHNjYWxlLW91dCwNCj4+Pj5hbmQNCj4+Pj52bQ0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1cmFsIGltcGFjdCBvZiBwZXJt aXR0aW5nDQo+Pj4+dGhpcw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxhcmdlbHkgdGhhdCB3 ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdGhhdCBvdXINCj4+Pj50ZXJtaW5vbG9neQ0KPj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGRvZXMgbm90IGxlYWQNCj4+Pj4gPj4+ID4+ID4+Pj4+IHJlYWRlcnMgdG8N Cj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRpbmcgaXQuDQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAzKSBUaGVyZSBjYW4gYWxz byBiZSBsb2FkIGJhbGFuY2luZyBkb25lIGJ5IHNlbGVjdGluZw0KPj4+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHBhY2tldCBwYXRocyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdCBkaXJlY3QNCj4+ Pj50cmFmZmljDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZGlmZmVyZW50IHBsYWNlcy4gV2Ug d291bGQgbm90IHdhbnQgdG8gcmVxdWlyZQ0KPj4+PnRoYXQNCj4+Pj5hDQo+Pj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiBhcHBlYXIgYXQgb25seSBvbmUgcGxhY2Ug aW4NCj4+Pj50aGUNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSXQgaXMgb2YgY291cnNlIHRoZSBjYXNl IHRoYXQgdGhlc2UgbWF5IGJlIGNvbWJpbmVkLg0KPj4+PkkNCj4+Pj4gdGVuZA0KPj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRvDQo+Pj4+ID4+PiA+PiA+Pj4+PiByZWZlciB0bw0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9uIG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvIHNlcnZp Y2UNCj4+Pj5jaGFpbmluZw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGFzIGEgc2luZ2xlIHBvaW50 IGFzIGEgY2x1c3Rlci4gTm90IGJlY2F1c2UgY2x1c3Rlcg0KPj4+PmlzDQo+Pj4+YQ0KPj4+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4gQnV0IGJlY2F1c2UgSSBkbyBub3QgaGF2ZSBhbm90 aGVyIG9uZS4NCj4+Pj5UaHVzLA0KPj4+PiB0aGUNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2lu dCBvZiB0eXBlIDMgbG9hZCBiYWxhbmNpbmcNCj4+Pj4gPj4+ID4+ID4+Pj4+IGlzIHRvDQo+Pj4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZGlyZWN0IGRpZmZlcmVudCBzdWJzZXRzIG9mIHRyYWZmaWMgdG8g ZGlmZmVyZW50DQo+Pj4+c2luZ3VsYXINCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBvciBjbHVzdGVy ZWQgc2VydmljZSBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBsYWNlcyBpbg0KPj4+PnRoZQ0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4g Pj4+ID4+ID4+Pj4+Pj4+PiBOb3cgd2l0aCB0aGF0IHNhaWQsIHdoYXQgZG8gSSBtZWFuIHdoZW4g SSB0YWxrIGFib3V0DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBhbmQgc2Vy dmljZSBwYXRoLyBTZXJ2aWNlIGNoYWluIGlzIGENCj4+Pj4gc2VxdWVuY2UNCj4+Pj4gPj4+ID4+ ID4+Pj4+Pj4+PiBvZiBsb2dpY2FsIGZ1bmN0aW9ucyB0byBiZSBhcHBsaWVkIHRvIGEgc3Vic2V0 IG9mDQo+Pj4+cGFja2V0cy4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50 IG9mIHNheWluZyB0aGF0IHNvbWUgc3Vic2V0IG9mIA0KPj4+PnRyYWZmaWMNCj4+Pj5pcw0KPj4+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGdldCBEUEksIGNoYXJnaW5nLCBjb250ZW50IGluc3BlY3Rp b24sIGFuZCANCj4+Pj5maXJld2FsbA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdoaWxlIGEgZGlm ZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0byB0aGUgDQo+Pj4+Y2FjaGUNCj4+Pj4g Pj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aXNpdGluZyBhbnkg b3RoZXIgc2VydmljZSBmdW5jdGlvbnMuDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRo ZSANCj4+Pj5wYWNrZXRzLiBBDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlz LCBpbiBzb21lIGZhc2hpb24sIGEgc2VxdWVuY2Ugb2YNCj4+Pj5sb2NhdGlvbnMNCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+PiBpbiB0aGUgbmV0d29yay4gVGhvc2UgbG9jYXRpb25zIHdpbGwgYmUgc2lu Z3VsYXIgb3INCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjbHVzdGVyZWQgc2VydmljZSBmdW5jdGlv biBkZWxpdmVyeSBsb2NhdGlvbnMuIFRoZXkNCj4+Pj5tYXkgYmUNCj4+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBhZGRyZXNzZWQgYnkgSVAgYWRkcmVzcy4gVGhleSBtYXkgYmUgYWRkcmVzc2VkIGFzIA0K Pj4+PnBvcnRzDQo+Pj4+IG9uDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYW4gU0ZGLiBUaGVyZSBh cmUgbWFueSBkaWZmZXJlbnQgd2F5cyB0aGF0IHRoZQ0KPj4+PmxvY2F0aW9ucw0KPj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZyBpbmZyYXN0 cnVjdHVyZSANCj4+Pj5hbmQNCj4+Pj4gdGhlDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdHJhbnNw b3J0Lg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4+ICBGcm9t IHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9mIHRoZSBTRkMgDQo+Pj4+Z3JvdXAsDQo+ Pj4+IHdlDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4+IG5lZWQgdG8gYmUNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBhYmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sIHRo ZQ0KPj4+PnNlcnZpY2UNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBjaGFpbiwgd2hpY2ggZHJpdmVz IHRoZSBmb3J3YXJkaW5nLiBBbmQgd2UgbmVlZCB0byANCj4+Pj50YWxrDQo+Pj4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gYWJvdXQgdGhlIGFjdHVhbCBkYXRhIHBhdGggcGFja2V0cyB3aWxsIHRha2UgaW4g dGhlDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbmV0d29yay4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFNldmVyYWwgb2YgdGhlIGNvbW1lbnRzIGhhdmUgc2Fp ZCAiYnV0IHRoZSB3aG9sZSBwYXRoDQo+Pj4+IG1heQ0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5v dCBiZSBrbm93biBhdCB0aGUgZnJvbnQuIiBUaGlzIGFyY2hpdGVjdHVyZSBkZWFscw0KPj4+Pndp dGgNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGF0IGlzc3VlIGluIHR3byB3YXlzLiBGaXJzdCwg YXMgbm90ZWQgaW4gaXRlbSAoMikgDQo+Pj4+b24NCj4+Pj5sb2FkDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFuZCBiZWhhdmlv cnMNCj4+Pj4gd2hpY2gNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcmUgaW52aXNpYmxlIHRvIHRo ZSBzZXJ2aWNlIGNoYWluaW5nIG1lY2hhbmlzbXMgKGluDQo+Pj4+bXVjaA0KPj4+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcyBsYXJn ZWx5DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0d2VlbiBM QU5zLikgVGhlIG90aGVyIA0KPj4+PnByb3Zpc2lvbg0KPj4+PiB3ZQ0KPj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IG1ha2UgaXMNCj4+Pj4gPj4+ID4+ID4+Pj4+IHRoYXQNCj4+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiByZWNsYXNzaWZpY2F0aW9uIGNhbiBiZSBkb25lIGluIG1pZC1jaGFpbiB3aGVuDQo+Pj4+ IG5lY2Vzc2FyeS4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGF0IHdpbGwgZGlyZWN0IHBhY2tl dHMgdG8gYSBuZXcgY2hhaW4uIEJhc2VkIG9uDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW5mb3Jt YXRpb24gYXZhaWxhYmxlIGF0IHRoZSByZS1jbGFzc2lmaWNhdGlvbiBwb2ludC4NCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVs cHMgZXhwbGFpbiB3aGF0IHdlIGFyZSBhZnRlci4gSWYgDQo+Pj4+aXQNCj4+Pj4gPj4+ID4+ID4+ Pj4+Pj4+PiBkb2VzLCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZSB3b3Jr aW5nDQo+Pj4+IGdyb3VwLA0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGNhbiBmaWd1cmUgb3V0 IHdoYXQgYWRkaXRpb25hbCB3b3JkcyBhcmUgbmVlZGVkIHRvDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gY29udmV5IHRoaXMuIElmIHRoZSB3b3JraW5nIGdyb3VwIGRpc2FncmVlIHdpdGggdGhlDQo+ Pj4+IGludGVudCwNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNl IGFkanVzdCB0byBtYXRjaCB0aGUgd29ya2luZw0KPj4+Pmdyb3VwDQo+Pj4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gYWdyZWVtZW50cy4gSWYgdGhpcyBpcyBzdGlsbCB1bmNsZWFyLCBJIGFtIG5vdCBzdXJl DQo+Pj4+d2hhdCB0bw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyeSBuZXh0Lg0KPj4+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4+Pj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYw0KPj4+PiA+Pj4gPj4gbWFpbGlu Zw0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGxpc3Qgc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGll dGYub3JnPg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBzZmMNCj4+Pj4gPj4+ID4+IG1haWxpbmcNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNm Y0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjDQo+Pj4+ ID4+PiA+PiBtYWlsaW5nDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZw0K Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ID4+PiA+ PiA+Pj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+Pj4gPj4+ ID4+IG1haWxpbmcNCj4+Pj4gPj4+ID4+ID4+Pj4+Pj4gbGlzdCBzZmNAaWV0Zi5vcmcNCj4+Pj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiA+Pj4gPj4gPj4+ Pj4+Pg0KPj4+PiA+Pj4gPj4gPj4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+Pj4+ID4+PiBtYWlsaW5n DQo+Pj4+ID4+PiA+PiBsaXN0DQo+Pj4+ID4+PiA+PiA+Pj4+Pj4gc2ZjQGlldGYub3JnIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ID4+PiA+PiA+Pj4+Pj4N Cj4+Pj4gPj4+ID4+ID4+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4+Pj4gPj4+IG1haWxpbmcNCj4+Pj4g Pj4+ID4+IGxpc3QNCj4+Pj4gPj4+ID4+ID4+Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiA+Pj4gPj4gPj4+Pg0KPj4+PiA+Pj4g Pj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBz ZmMNCj4+Pj4gbWFpbGluZw0KPj4+PiA+Pj4gPj4gbGlzdA0KPj4+PiA+Pj4gPj4gPj4+PiBzZmNA aWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4g Pj4+ID4+ID4+Pj4NCj4+Pj4gPj4+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gc2ZjDQo+Pj4+IG1haWxpbmcNCj4+Pj4gPj4+ID4+IGxpc3QN Cj4+Pj4gPj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+Pj4+ID4+PiA+PiA+Pj4+DQo+Pj4+ID4+PiA+PiA+Pj4NCj4+Pj4g Pj4+ID4+ID4+DQo+Pj4+ID4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiA+ Pj4gPj4gPj4gc2ZjQGlldGYub3JnDQo+Pj4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+PiA+Pj4gPj4gPj4NCj4+Pj4gPj4+ID4+ID4NCj4+ Pj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiA+Pj4gPj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gPj4+ID4+ID5zZmNAaWV0Zi5v cmcNCj4+Pj4gPj4+ID4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPj4+PiA+Pj4gPj4NCj4+Pj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+ID4+PiA+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+ID4+ PiA+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+Pj4+ID4+Pg0KPj4+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+ Pj4gPj4+IHNmY0BpZXRmLm9yZw0KPj4+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+Pj4gPg0KPj4+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gPnNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gPnNmY0Bp ZXRmLm9yZw0KPj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4NCg0K From nobody Tue Jul 15 06:09:06 2014 Return-Path: <prvs=6273c163fd=phe@ciena.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C41B2887 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3oxvjowdiCd for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:08:57 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977C21A03C6 for <sfc@ietf.org>; Tue, 15 Jul 2014 06:08:57 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6FD56eV017172; Tue, 15 Jul 2014 09:08:47 -0400 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 1n4wearqdf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 09:08:47 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 15 Jul 2014 09:08:46 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 15 Jul 2014 09:08:45 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Tue, 15 Jul 2014 09:08:45 -0400 From: "He, Peng" <phe@ciena.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Tom Taylor" <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Date: Tue, 15 Jul 2014 09:08:41 -0400 Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpAgABLaIA= Message-ID: <B6D287BF58D35D4B882E012AD3E1756172E676B7@ONWVEXCHMB04.ciena.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20818.007 X-TM-AS-Result: No--36.389900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-15_03:2014-07-15,2014-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zwmo1yIpr2m67lDf2tE1XTlVLJs Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 13:09:02 -0000 Try to understand the three scenarios you listed: you mean the classifier c= an specify a (partial or complete) SFP which is a list of SFFs, then each S= FF will (locally) select one of the SF instances under itself for this SF. = For partial SFP case, each SFF will identify the SFI under itself and speci= fy (like a classifier) next SFF(s). The classifier (and SFF?) could obtain= this (SFF) 'path' information from either centralized point (e.g., PCE, c= ontroller), or, via a distributed control plane? For partial SFP, will ther= e be a re-classification to decide next SFF(s) or not?=20 Regards, Peng -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Tuesday, July 15, 2014 4:49 AM To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; sfc@ietf.org= ; Ron Parker Subject: Re: [sfc] SFC Terminology / Concepts Hi Med, IMHO, the architecture should allow the classifier to specify 1) a partial SFP (i.e., some SFFs along that partial SFP need to locally de= termine the appropriate SFF for the next SF); 2) a complete SFP (i.e., the SFF for each SF in the SFC has been determined= by the centralized node); 3) an SFC (i.e., each SFF along the final SFP needs to locally determine th= e appropriate SFF for the next SF).=20 In fact, case 3) could be looked as an extreme of case 1). Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Tuesday, July 15, 2014 3:22 PM > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Hi Joel, >=20 > As mentioned in several messages, I'm personally for the use of the=20 > chain itself is the main information to be conveyed in packets to drive f= orwarding actions. >=20 > I can understand that an identifier can be assigned to a path that is=20 > known in advance, but if that path is not known I'm not sure how an=20 > identifier can be assigned to it! >=20 > Joel, the use of "path" is really inappropriate to refer to=20 > distributed instance selection process for packets bound to a given SFC. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 > >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf.or= g;=20 > >Ron Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts > > > >The most likely realization of the architecture would be that the SFP=20 > >assignment is recorded in an identifier which travels with the packet. > > > >Some folks seem to not want the architecture to mandate that. > > > >Yours, > >Joel > > > > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: > >> Your text scares me because it introduces some new concepts and=20 > >> assumptions. > >> > >> I'd rather go with Joel's formulation. Clarifying question on that: > >> am I right in seeing the implication that when control assigns an=20 > >> SFP, the assignment is recorded by an identifier wwhich travels=20 > >> with the > packet? > >> > >> Tom Taylor > >> > >> On 14/07/2014 2:22 PM, Ron Parker wrote: > >>> There is one missing word in my text. Please replace my proposed te= xt > >>> with: > >>> > >>> "The Service Function Chain (SFC) provides a fully abstract view=20 > >>> of the service functions to be invoked and the order in which they=20 > >>> are to be invoked for some particular flow or set of flows, without c= oncern of > >>> actual service function instance selection. The Constrained-SFC > >>> (C-SFC) further allows for policy constraints to be added to the=20 > >>> SFC affecting the instance selection of one or more of the service fu= nctions > >>> in the SFC. Any SFC may have any number of C-SFC's associated with > >it." > >>> > >>> Thanks. > >>> > >>> Ron > >> ... > >> > >> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 > >>> Allan I > >>> *Sent:* Monday, July 14, 2014 2:03 PM > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >>> > >>> I like that text, it strikes a good balance where an=20 > >>> implementation has the option of making scale and resiliency a local = matter.. > >>> > >>> D > >>> > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 > >>> Guichard > >>> (jguichar) > >>> *Sent:* Monday, July 14, 2014 10:48 AM > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >>> *Subject:* [sfc] SFC Terminology / Concepts > >>> > >>> Dear WG: > >>> > >>> There has been much debate over the last few days with regards to=20 > >>> SFC concepts. To try and form some consensus around terminology=20 > >>> and concepts used to describe the architecture in the merged=20 > >>> architecture draft, Joel has kindly suggested the following: > >>> > >>> "The SFP provides a level of indirection between the fully=20 > >>> abstract notion of service path as a sequence of functions to be=20 > >>> delivered, and the fully specified notion of exactly what=20 > >>> instances of SFFs the packet will visit when it actually traverses=20 > >>> the network. By allowing the control components to specify the use=20 > >>> of this level of indirection, the deployment may choose the degree=20 > >>> of SFF instance selection authority that is delegated to the network.= " > >>> > >>> I'd like to ask the WG as a whole, if this clarification is=20 > >>> something that we can get consensus on. If so, I'll ask Joel to=20 > >>> provide specific text, that reflects the above, for inclusion in=20 > >>> the merged architecture draft. > >>> > >>> Thank You, > >>> > >>> Jim > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >> > >> _______________________________________________ > >> sfc mailing 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 15 06:17:59 2014 Return-Path: <bill.wu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807F51B27EF for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 7sK-hhxgZYZH for <sfc@ietfa.amsl.com>; Mon, 14 Jul 2014 20:44:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1117E1B27D5 for <sfc@ietf.org>; Mon, 14 Jul 2014 20:44:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE73936; Tue, 15 Jul 2014 03:44:30 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 04:44:28 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 11:44:19 +0800 From: Qin Wu <bill.wu@huawei.com> To: "NAPIERALA, MARIA H" <mn1921@att.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, "Joel Halpern Direct" <jmh.direct@joelhalpern.com>, Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mikebianc@aol.com" <mikebianc@aol.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers Thread-Index: AQHPn2HQNlH4+lTK50W4V3mtGdNmTJufB/UAgAAC0ACAABMPgIAABd6AgAADa4CAAAXiAIABUTxw Date: Tue, 15 Jul 2014 03:44:18 +0000 Message-ID: <B8F9A780D330094D99AF023C5877DABA84582F6E@nkgeml501-mbs.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B71C9@MBX021-W3-CA-2.exch021.domain.local> <CFE96A4C.2E4AC%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B806@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4B806@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] 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/xrZhTPKXdap1CB7gPrLoCXDTB5k X-Mailman-Approved-At: Tue, 15 Jul 2014 06:17:58 -0700 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 03:44:41 -0000 SWYgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIFNGUCwgSSBhYnNvbHV0 ZWx5IGFncmVlIHdpdGggeW91DQpTaW5jZSBhcyBJIHNhaWQgZWFybGllciwgU0ZDIGNhbiBiZSBy ZXByZXNlbnRlZCBieSBhIHNldCBvZiBpZGVudGlmaWVyIGNvcnJlc3BvbmRpbmcgdG8gU0YgaW4g dGhlIGNoYWluIHdoaWxlIFNGUCBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgDQpBIHNldCBvZiBsb2Nh dG9yIGNvcnJlc3BvbmRpbmcgdG8gU0ZJIGludm9rZWQgZm9yIGEgZ2l2ZW4gY2hhaW4uDQoNCi1R aW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBOQVBJRVJBTEEsIE1BUklBIEgNCuWPkemAgeaXtumXtDog MjAxNOW5tDfmnIgxNOaXpSAyMzozMw0K5pS25Lu25Lq6OiBKaW0gR3VpY2hhcmQgKGpndWljaGFy KTsgUm9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsgTHVjeSB5b25nOyBYdXhpYW9odTsg bWlrZWJpYW5jQGFvbC5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGptaEBqb2Vs aGFscGVybi5jb207IHNmY0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW3NmY10gUmVkZWZpbmUgdGhl IFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQoNCkkg d291bGQgcmV3b3JkIHRoaXMgc2VudGVuY2UgYXMgZm9sbG93czoNCg0KIldoZW4gYW4gU0ZDIGlz IGluc3RhbnRpYXRlZCBpbnRvIHRoZSBuZXR3b3JrIHRoaXMgcmVzdWx0cyBpbiBzcGVjaWZpYyBp bnN0YW5jZXMgb2YgU0ZzIGJlaW5nIHNlbGVjdGVkIHRvIGNyZWF0ZSB0aGUgc2VydmljZSB0b3Bv bG9neSBmb3IgdGhhdCBTRkMgdXNpbmcgU0bigJlzIG5ldHdvcmsgbG9jYXRvcnPigJ0NCg0KTWFy aWENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4gU2VudDogTW9uZGF5LCBK dWx5IDE0LCAyMDE0IDExOjEyIEFNDQo+IFRvOiBSb24gUGFya2VyOyBKb2VsIEhhbHBlcm4gRGly ZWN0OyBMdWN5IHlvbmc7IE5BUElFUkFMQSwgTUFSSUEgSDsNCj4gWHV4aWFvaHU7IG1pa2ViaWFu Y0Bhb2wuY29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOw0KPiBqbWhAam9lbGhhbHBl cm4uY29tOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIFJlZGVmaW5lIHRoZSBT RlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkDQo+IEJhbGFuY2Vycw0KPiAN Cj4gUXVlc3Rpb246IHdoZXJlIGV4YWN0bHkgZG9lcyBpdCBzcGVjaWZ5IHRoYXQgdGhlIFNGUCAq bXVzdCogYmUNCj4gcHJlLWluc3RhbnRpYXRlZD8gV2hhdCBleGFjdGx5IGlzIHdyb25nIHdpdGgg dGhlIHdvcmRpbmcg4oCcV2hlbiBhbiBTRkMgaXMNCj4gaW5zdGFudGlhdGVkIGludG8gdGhlIG5l dHdvcmsgaXQgaXMgbmVjZXNzYXJ5IHRvIHNlbGVjdCB0aGUgc3BlY2lmaWMNCj4gaW5zdGFuY2Vz IG9mIFNGcyB0aGF0IHdpbGwgYmUgdXNlZCwgYW5kIHRvIGNyZWF0ZSB0aGUgc2VydmljZSB0b3Bv bG9neSBmb3INCj4gdGhhdCBTRkMgdXNpbmcgU0bigJlzIG5ldHdvcmsgbG9jYXRvcnPigJ0/IExl dOKAmXMgdHJ5IHRvIGJlIHNwZWNpZmljIHJhdGhlcg0KPiB0aGFuIGRhbmNpbmcgYXJvdW5kIHRo ZSB3b3JkaW5nLg0KPiANCj4gT24gNy8xNC8xNCwgMTE6MDAgQU0sICJSb24gUGFya2VyIiA8Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj4gd3JvdGU6DQo+IA0KPiA+SGksIEpvZWws DQo+ID4NCj4gPkkgcXVvdGUgZnJvbSB0aGUgdGhlIG1lcmdlZCBhcmNoaXRlY3R1cmUgZHJhZnQ6 DQo+ID4NCj4gPjxiZWdpbiBxdW90YXRpb24+DQo+ID5TZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChT RkMpOiAgQSBzZXJ2aWNlIEZ1bmN0aW9uIGNoYWluIGRlZmluZXMgYW4NCj4gPiAgICAgICAgb3Jk ZXJlZCBzZXQgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBtdXN0IGJlIGFwcGxpZWQgdG8gcGFj a2V0cw0KPiA+ICAgICAgICBhbmQvb3IgZnJhbWVzIHNlbGVjdGVkIGFzIGEgcmVzdWx0IG9mIGNs YXNzaWZpY2F0aW9uLiAgVGhlDQo+ID4gICAgICAgIGltcGxpZWQgb3JkZXIgbWF5IG5vdCBiZSBh IGxpbmVhciBwcm9ncmVzc2lvbiBhcyB0aGUNCj4gPiAgICAgICAgYXJjaGl0ZWN0dXJlIGFsbG93 cyBmb3Igbm9kZXMgdGhhdCBjb3B5IHRvIG1vcmUgdGhhbiBvbmUgYnJhbmNoLg0KPiA+ICAgICAg ICBUaGUgdGVybSBzZXJ2aWNlIGNoYWluIGlzIG9mdGVuIHVzZWQgYXMgc2hvcnRoYW5kIGZvciBz ZXJ2aWNlDQo+ID4gICAgICAgIGZ1bmN0aW9uIGNoYWluLg0KPiA+DQo+ID4gICBTZXJ2aWNlIEZ1 bmN0aW9uIFBhdGggKFNGUCk6ICBUaGUgaW5zdGFudGlhdGlvbiBvZiBhbiBTRkMgaW4gdGhlDQo+ ID4gICAgICAgIG5ldHdvcmsuICBQYWNrZXRzIGZvbGxvdyBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0 aCBmcm9tIGENCj4gPiAgICAgICAgY2xhc3NpZmllciB0aHJvdWdoIHRoZSByZXF1aXNpdGUgc2Vy dmljZSBmdW5jdGlvbnMNCj4gPg0KPiA+V2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8g dGhlIG5ldHdvcmsgaXQgaXMgbmVjZXNzYXJ5IHRvDQo+ID4gICBzZWxlY3QgdGhlIHNwZWNpZmlj IGluc3RhbmNlcyBvZiBTRnMgdGhhdCB3aWxsIGJlIHVzZWQsIGFuZCB0byBjcmVhdGUNCj4gPiAg IHRoZSBzZXJ2aWNlIHRvcG9sb2d5IGZvciB0aGF0IFNGQyB1c2luZyBTRidzIG5ldHdvcmsgbG9j YXRvci4gIFRodXMsDQo+ID4gICBpbnN0YW50aWF0aW9uIG9mIHRoZSBTRkMgcmVzdWx0cyBpbiB0 aGUgY3JlYXRpb24gb2YgYSBTZXJ2aWNlDQo+ID4gIEZ1bmN0aW9uIFBhdGggKFNGUCkgYW5kIGlz IHVzZWQgZm9yIGZvcndhcmRpbmcgcGFja2V0cyB0aHJvdWdoIHRoZQ0KPiA+ICAgU0ZDLiAgSW4g b3RoZXIgd29yZHMsIGFuIFNGUCBpcyB0aGUgaW5zdGFudGlhdGlvbiBvZiB0aGUgZGVmaW5lZCBT RkMuDQo+ID4NCj4gPihTZWN0aW9uIDQuMyBTRkYpDQo+ID5TRlAgZm9yd2FyZGluZyBpbmZvcm1h dGlvbiBpcyBhc3NvY2lhdGVkIHdpdGggYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllcg0KPiA+ICAg dGhhdCBpcyB1c2VkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGFuIFNGUC4NCj4gPjxlbmQgcXVvdGF0 aW9uPg0KPiA+DQo+ID4NCj4gPk15IHJlYWRpbmcgb2YgdGhlIFNlY3Rpb24gNC4zLCBnaXZlbiB0 aGUgZGVmaW5pdGlvbnMgcHJlc2VudGVkIGJlZm9yZSBpdCwNCj4gPmlzIHRoYXQgYW4gZW5kLXRv LWVuZCBmdWxseSBpbnN0YW50aWF0ZWQgcGF0aCBpcyBzZWxlY3RlZCBhbmQgdGhlbiB1c2VkDQo+ ID50byBzdGVlciB0cmFmZmljIHRvIHRoZSByZXF1aXNpdGUgU0ZGJ3MgYW5kIFNGJ3MuICAgV2hp bGUgdGhvc2UNCj4gPmRlZmluaXRpb25zIGNvdWxkIHN0aWxsIGFwcGx5LCBldmVuIGluIGEgZGlz dHJpYnV0ZWQgaW5zdGFuY2UgYXNzaWdubWVudA0KPiA+YXBwcm9hY2gsIHRoZSBjb250ZXh0IGFy b3VuZCB0aG9zZSBkZWZpbml0aW9ucyBjaGFuZ2UuICAgQSBwYXJ0aWN1bGFyDQo+ID5mbG93IHdv dWxkLCBpbmRlZWQgc3RpbGwgZm9sbG93IHNvbWUgcGFydGljdWxhciBwYXRoLCBidXQgdGhlcmUg d291bGQgYmUNCj4gPm5vIG5lZWQgdG8gYXNzb2NpYXRlIGEgcGF0aCBJRCB0byBpdCBhbmQgdGhl cmUgd291bGQgYmUgbm8gbmVlZCB0bw0KPiA+KGxhdGVyKSBidWlsZCBhIGNvbnRyb2wgcGxhbmUg YXJvdW5kIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIHBhdGggSUQgYW5kDQo+ID5tYWludGVuYW5jZSBv ZiB0aG9zZSBwYXRoIElEcyBpbiB0aGUgZmFjZSBvZiBpbmV2aXRhYmxlIGZhaWx1cmVzLg0KPiA+ DQo+ID5JIGFtIGV4cGxvcmluZyB0aGUgYWx0ZXJuYXRpdmUgd2hlcmUgZm9yd2FyZGluZyBpcyBw ZXJmb3JtZWQgYmFzZWQgb24NCj4gdGhlDQo+ID5hYnN0cmFjdCBTRkMgSUQgd2l0aG91dCByZXF1 aXJpbmcgdGhlIGNvbmNlcHQgb2YgYSBjZW50cmFsbHkga25vd24gU0ZQIHRvDQo+ID5leGlzdCBh dCBhbGwuICAgSW4gdGhpcyBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgdGhlIGluc3RhbmNlIHNlbGVj dGlvbiBpcw0KPiA+ZGlzdHJpYnV0ZWQgdG8gdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBTRkYncy4g ICBBbnkgZGVzaXJlZCBwb2xpY3kgdXNlZCB0bw0KPiA+Zmxhdm9yIGluc3RhbmNlIHNlbGVjdGlv biBpcyBzdGlsbCBzdXBwb3J0ZWQsIGJ1dCBzdWNoIHBvbGljeSB3b3VsZCwNCj4gPmluZGVlZCwg bmVlZCB0byBiZSBhdmFpbGFibGUgdG8gdGhlIGludm9sdmVkIGVudGl0aWVzLiAgIFRoaXMgd291 bGQgYWxzbw0KPiA+YmUgYW4gZXhjZWxsZW50IHVzZSBvZiBtZXRhZGF0YSB3aGVyZSB0aGUgaW5p dGlhbCBpbmdyZXNzIG5vZGUgY291bGQgYWRkDQo+ID5vbmUgb3IgbW9yZSBwaWVjZXMgb2YgbWV0 YWRhdGEgdGhhdCBkb3duc3RyZWFtIG5vZGVzIGNvdWxkIG1ha2UgdXNlDQo+IG9mIGluDQo+ID50 aGVpciBwb2xpY3kgZGVjaXNpb25zLg0KPiA+DQo+ID4gICAgUm9uDQo+ID4NCj4gPg0KPiA+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206IEpvZWwgSGFscGVybiBEaXJlY3QgW21h aWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCj4gPlNlbnQ6IE1vbmRheSwgSnVseSAx NCwgMjAxNCAxMDozOSBBTQ0KPiA+VG86IEx1Y3kgeW9uZzsgTkFQSUVSQUxBLCBNQVJJQSBIOyBS b24gUGFya2VyOyBYdXhpYW9odTsNCj4gPm1pa2ViaWFuY0Bhb2wuY29tOyBqZ3VpY2hhckBjaXNj by5jb207DQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+ID5qbWhAam9lbGhhbHBl cm4uY29tOyBzZmNAaWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFJlOiBbc2ZjXSBSZWRlZmluZSB0aGUg U0ZQLy9SRTogU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZA0KPiA+QmFsYW5jZXJzDQo+ ID4NCj4gPkNhbiB3ZSBmaXJzdCBmaWd1cmUgb3V0IHdoYXQgd2UgbWVhbiBieSBhIHNlcnZpY2Ug cGF0aD8NCj4gPk9uY2Ugd2UgaGF2ZSB0aGF0LCBJIGJlbGlldmUgd2UgY2FuIHdvcmsgb3V0IHdo YXQgd2Ugd2FudCB0aGUNCj4gPmFyY2hpdGVjdHVyZSB0byByZXF1aXJlIG9mIHNvbHV0aW9ucyBp biB0ZXJtcyBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiBpbg0KPiA+dGhlIHBhY2tldC4gIEJ1dCBz aW5jZSBmb2xrcyBoYXZlIGJlZW4gcmVhZGluZyB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbnMNCj4g PmFuZCBjb21pbmcgdG8gZGlmZmVyZW50IG1lYW5pbmdzLCBhbmQgaGF2ZSBiZWVuIG5vdGluZyBj b3JyZWN0bHkNCj4gPmNvbnRyYWRpY3Rpb25zIGluIHRoZSB3b3JkcyB3ZSBjaG9zZSBmb3IgdGhl IGV4aXN0aW5nIGRlZmluaXRpb24sIEkNCj4gPndvdWxkIHJlYWxseSBhcHByZWNpYXRlZCBpdCBp ZiBmb2xrcyB3b3VsZCBjb21tZW50IG9uIHRoZSBkZWZpbml0aW9uIG9mDQo+ID5zZXJ2aWNlIGZ1 bmN0aW9uIHBhdGggdGhhdCBJIHNlbnQgdG8gdGhlIGxpc3QuDQo+ID4NCj4gPllvdXJzLA0KPiA+ Sm9lbA0KPiA+DQo+ID5PbiA3LzE0LzE0LCA5OjMwIEFNLCBMdWN5IHlvbmcgd3JvdGU6DQo+ID4+ IENvbnF1ZXIgd2hhdCBNYXJpYSBzYXlzLg0KPiA+Pg0KPiA+PiBMdWN5DQo+ID4+DQo+ID4+ICpG cm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqTkFQ SUVSQUxBLA0KPiA+Pk1BUklBIEgNCj4gPj4gKlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMTQg ODoyMSBBTQ0KPiA+PiAqVG86KiBSb24gUGFya2VyOyBYdXhpYW9odTsgbWlrZWJpYW5jQGFvbC5j b207IGpndWljaGFyQGNpc2NvLmNvbTsNCj4gPj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgc2ZjQGlldGYub3JnDQo+ID4+ICpTdWJqZWN0OiogUmU6 IFtzZmNdIFJlZGVmaW5lIHRoZSBTRlAvL1JFOiBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZA0K PiA+PiBMb2FkIEJhbGFuY2Vycw0KPiA+Pg0KPiA+PiBUaGUgbWVhbmluZyBvZiB0aGUgU0ZQIElE IGlzIHByZXR0eSBjbGVhciwgYXQgbGVhc3QgdG8gbWUg4oCTIGFuIGFic3RyYWN0DQo+ID4+IGlk ZW50aXR5IGZvciB0aGUgZXhhY3Qgc2V0IG9mIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIChp LmUuLCBTRlAgSUQgMQ0KPiA+PiA9IHtTRi1BLTEsIFNGLUItMywgU0YtQy0yfSkuICAgIEluIHNv bWUgd2F5cywgaXQgaXMgYSBjb2xsYXBzZWQg4oCcbGFiZWwNCj4gPj4gc3RhY2vigJ0g4oCTIHRo ZXJlIGlzIGEgc2luZ2xlIHRhZyBpbXBseWluZyBzb21lIHNlcXVlbmNlIG9mIG5ldHdvcmsNCj4g Pj4gbG9jYXRpb25zLiAgIEJ1dCwgdGhpcyBhbHNvIGltcGxpZXMsIGF0IGxlYXN0IHRvIG1lLCB0 aGF0IHRoZXJlIGlzIGENCj4gPj4gY2VudHJhbCBwb2ludCBvZiBzZWxlY3Rpb24gZm9yIHRoaXMg ZW5kIHRvIGVuZCBzZXF1ZW5jZSAoYmFycmluZw0KPiA+PiByZWNsYXNzaWZpY2F0aW9uLCBvZiBj b3Vyc2UpLiAgIEksIGZvciBvbmUsIGFtIHF1ZXN0aW9uaW5nIHRoYXQNCj4gPj4gaW1wbGljYXRp b24uICAgIEkgaGF2ZSBiZWVuIHVuY29tZm9ydGFibGUgd2l0aCB0aGF0IGNlbnRyYWwgcG9pbnQN Cj4gPj4gbWV0aG9kb2xvZ3kgZHVlIHRvIHJlYWwtd29ybGQgY29tcGxleGl0aWVzIG9mIGR5bmFt aWMgc2NhbGUgYW5kDQo+ID4+IHRpbWVsaW5lc3Mgb2YgcmVhY3Rpb24gdG8gZmFpbHVyZXMuDQo+ ID4+DQo+ID4+IDxNYXJpYT4gSSBhZ3JlZS4gSXQgc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBieSB0 aGUgU0ZDIGFyY2hpdGVjdHVyZSB0aGF0DQo+ID4+IHNvbWV0aGluZyBjYWxsZWQg4oCcc2Vydmlj ZSBmdW5jdGlvbiBwYXRoIElE4oCdIGlzIGNhcnJpZWQgaW4gdGhlIHBhY2tldCwNCj4gPj4gYmVj YXVzZSBpdCBpcyBub3QgbmVjZXNzYXJ5IG9yIHRoZSBvbmx5IHdheSB0byBpbXBsZW1lbnQgc2Vy dmljZQ0KPiA+PiBjaGFpbmluZy4gVGhlcmUgbWlnaHQgc29sdXRpb25zIHRoYXQgd291bGQgZG8g dGhhdCBidXQgaXQgY2Fubm90IGFuZA0KPiA+PiBkb2VzbuKAmXQgbmVlZCB0byBiZSBtYW5kYXRl ZC4NCj4gPj4NCj4gPj4gTWFyaWENCj4gPj4NCj4gPj4gQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2gg aXMgdG8gc3RpbGwgdXNlIGNlbnRyYWwgc2VsZWN0aW9uIHRvIHNlbGVjdCB0aGUNCj4gPj4gY2hh aW4gb2YgYWJzdHJhY3Qgc2VydmljZSBmdW5jdGlvbnMgKGkuZS4sIFNGQyBJRCAxID0ge1NGLUEs IFNGLUIsDQo+ID4+IFNGLUN9KSwgYnV0IGFsbG93IHRoZSBhY3R1YWwgaW5zdGFuY2Ugc2VsZWN0 aW9uIHRvIGJlIGRpc3RyaWJ1dGVkLA0KPiA+PiByZWFsaXplZCBieSB0aGUgY2xhc3NpZmllciBh bmQgdGhlIFNGRnMuDQo+ID4+DQo+ID4+IEdpdmVuIGEgdG9wb2xvZ3kgbGlrZToNCj4gPj4NCj4g Pj4gQ2xhc3NpZmllciAtLS0tLS0tICBTRkYtMSAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMg0K PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLSBTRkYtMy0tLS0tLS0tLS0tLS0tLS0tLS1TRkYtNA0K PiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8DQo+ ID4+ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4gPj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4+DQo+ID4+ ICAgICAgICAgICAgICAgICAgICAgIFNGRi1BLTEgICAgICAgU0ZGLUEtMiAgICAgICBTU0YtQi0x DQo+ID4+IFNGRi1CLTIgICAgICAgICBTRkYtQy0xICAgICAgIFNGRi1DLTIgICAgICAgICAgICAg ICAgICAgU0ZGLUEtMw0KPiA+Pg0KPiA+PiBBbmQgYXNzdW1pbmcgYSBuZXdseSByZWNvZ25pemVk IGZsb3csIHRoZSBzZXF1ZW5jZSBjb3VsZCBnbw0KPiBzb21ldGhpbmcNCj4gPj4gbGlrZSB0aGlz Og0KPiA+Pg0KPiA+PiAxIENsYXNzaWZpZXIgc2VsZWN0cyBjaGFpbiBTRkMgSUQgMSB7U0YtQSwg U0YtQiwgU0YtQ30NCj4gPj4NCj4gPj4gMiBDbGFzc2lmaWVyIHNlbGVjdHMgU0ZGLTEgYXMgaG9z dGluZyBhdCBsZWFzdCBvbmUgaW5zdGFuY2Ugb2YgU0YtQQ0KPiA+Pg0KPiA+PiAzIENsYXNzaWZp ZXIgZW5jYXBzdWxhdGVzIHBhY2tldCBpbmRpY2F0aW5nIGNoYWluIElEID0gMSwgc2VydmljZSBp bmRleA0KPiA+Pj0gMQ0KPiA+Pg0KPiA+PiA0IENsYXNzaWZpZXIgcHJvZ3Jlc3NlcyBwYWNrZXQg dG8gU0ZGLTENCj4gPj4NCj4gPj4gNSBTRkYtMSwgc2VlaW5nIGNoYWluIElEPTEsIHNlcnZpY2Ug aW5kZXg9MSwgY2hvb3NlcyBTRkYtQS0yIGFtb25nc3QgaXRzDQo+ID4+IGF2YWlsYWJsZSBpbnN0 YW5jZXMgb2YgU0YtQQ0KPiA+Pg0KPiA+PiA2IFNGRi0xIHNlbmRzIHBhY2tldCB0byBTRkYtQS0x DQo+ID4+DQo+ID4+IDcgU0ZGLUEtMSBzZW5kcyBwYWNrZXQgYmFjayB0byBTRkYtMQ0KPiA+Pg0K PiA+PiA4IFNGRi0xIGluY3JlbWVudHMgc2VydmljZSBpbmRleCB0byAyDQo+ID4+DQo+ID4+IDgg U0ZGLTEgc2VsZWN0cyBTRkYtMiBhcyBob3N0aW5nIGF0IGxlYXN0IG9uZSBpbnN0YW5jZSBvZiBT Ri1CDQo+ID4+DQo+ID4+IDkgU0ZGLTEgcHJvZ3Jlc3NlcyBwYWNrZXQgdG8gU0ZGLTINCj4gPj4N Cj4gPj4gMTAgcHJvY2VzcyByZXBlYXRzIHBlciBhYm92ZSB1bnRpbCBTRkYtMywgYXMgdGhlIGVn cmVzcyBib3JkZXIsDQo+ID4+IHByb2dyZXNzZXMgdGhlIHBhY2tldCBwZXIgcm91dGluZyB0YWJs ZQ0KPiA+Pg0KPiA+PiBUaGFua3MuDQo+ID4+DQo+ID4+ICAgICBSb24NCj4gPj4NCj4gPj4gKkZy b206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpYdXhp YW9odQ0KPiA+PiAqU2VudDoqIFN1bmRheSwgSnVseSAxMywgMjAxNCAxMTozMCBQTQ0KPiA+PiAq VG86KiBtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tPjsNCj4gamd1 aWNoYXJAY2lzY28uY29tDQo+ID4+IDxtYWlsdG86amd1aWNoYXJAY2lzY28uY29tPjsgbW4xOTIx QGF0dC5jb20NCj4gPG1haWx0bzptbjE5MjFAYXR0LmNvbT47DQo+ID4+IG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20NCj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsN Cj4gPj4gam1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+OyBS b24gUGFya2VyOw0KPiA+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ ICpTdWJqZWN0OiogW3NmY10gUmVkZWZpbmUgdGhlIFNGUC8vUkU6IFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQNCj4gPj4gQmFsYW5jZXJzDQo+ID4+DQo+ID4+IEFncmVlIHRoYXQgdGhl IGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgU0ZQIGluIHRoZSBhcmNoIGRyYWZ0IGlzIGEgYml0 DQo+ID4+Y29uZnVzaW5nLCBqdXN0IGFzIHdoYXQgeW91IGhhZCBwb2ludGVkIG91dC4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIFNGUCBhcyBhbiBpbnN0 YW50aWF0aW9uIG9mIGFuIFNGQyBpbiB0aGUNCj4gPj5uZXR3b3JrIHNob3VsZCBiZSDigJxhbiBv cmRlcmVkIGxpc3Qgb2Ygc2VydmljZSBub2RlcyBhbmQgU0YgSURz4oCdKHNlZQ0KPiA+Pmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1wY2UtYmFzZWQtc2ZjLWFyY2gt MDEpLiBPZg0KPiA+PmNvdXJzZSwgaG93IHRvIHJlcHJlc2VudCB0aGUgU0ZQIGluIHRoZSBkYXRh IHBhY2tldCBpcyBhbm90aGVyIHRoaW5nDQo+ID4+KGUuZy4sIGVpdGhlciB0aHJvdWdoIGEgcGF0 aCBpZCBvciB0aHJvdWdoIGFuIE1QTFMgbGFiZWwgc3RhY2spLiBIZXJlDQo+ID4+dGhlIHNlcnZp Y2Ugbm9kZSBtZWFucyB0aGUgZGV2aWNlIHdoaWNoIGNvbnRhaW5zIHRoZSBTRkYgYW5kIHRoZSBO Rg0KPiA+PmNvbXBvbmVudHMgbWFuZGF0b3JpbHkgd2hpbGUgY29udGFpbmluZyB0aGUgU0YgYW5k IFNGIHByb3h5DQo+IGNvbXBvbmVudHMNCj4gPj5vcHRpb25hbGx5LiBUaGUgc2VydmljZSBub2Rl IGNvdWxkIGJlIGF0dGFjaGVkIG9yIGVtYmVkZGVkIHdpdGgNCj4gbXVsdGlwbGUNCj4gPj5TRiBp bnN0YW5jZXMgYW5kIHRob3NlIFNGIGluc3RhbmNlcyBjb3VsZCBiZSBvZiB0aGUgc2FtZSBTRiB0 eXBlIG9yIG5vdC4NCj4gPj4gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlIFNG IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlDQo+ID4+KGUuZy4sIFNGIFgpIGFyZSBhdHRh Y2hlZCB0byBhIGdpdmVuIHNlcnZpY2Ugbm9kZSwgdGhlIHNlcnZpY2Ugbm9kZQ0KPiA+PmNvdWxk IGRpc3RyaWJ1dGUgdGhlIHRyYWZmaWMgd2hpY2ggbmVlZHMgU0YgWCBhbW9uZyB0aG9zZSBTRiBp bnN0YW5jZXMNCj4gPj5vZiBTRiBYIHR5cGUgbG9jYWxseS4gTWVhbndoaWxlLCB0aGVyZSBtYXkg YmUgbXVsdGlwbGUgc2VydmljZSBub2Rlcw0KPiA+PndpdGhpbiBhIGdpdmVuIFNGQy1lbmFibGVk IGRvbWFpbiB3aGljaCBhcmUgZW1iZWRkZWQgb3IgYXR0YWNoZWQNCj4gd2l0aA0KPiA+PnRoZSBT Rg0KPiA+ICBpbnN0YW5jZQ0KPiA+cyBvZiB0aGUgc2FtZSBTRiB0eXBlLiBJbiB0aGlzIHdheSwg dGhlIFNGIGxvYWQtYmFsYW5jaW5nIHdvdWxkIGJlIG1hZGUNCj4gPnZlcnkgZmxleGlibGUuDQo+ ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4NCj4gPj4gWGlhb2h1DQo+ID4+DQo+ID4+ICpG cm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZg0KPiA+ PiAqbWlrZWJpYW5jQGFvbC5jb20gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT4NCj4gPj4gKlNl bnQ6KiBTYXR1cmRheSwgSnVseSAxMiwgMjAxNCAyOjQ2IEFNDQo+ID4+ICpUbzoqIGpndWljaGFy QGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbT47DQo+IG1uMTkyMUBhdHQuY29t DQo+ID4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tDQo+ID4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGptaEBqb2Vs aGFscGVybi5jb20NCj4gPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjsgUm9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPiA+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20+OyBzZmNAaWV0Zi5vcmcNCj4gPj48bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g Pj4gKlN1YmplY3Q6KiBSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBC YWxhbmNlcnMNCj4gPj4NCj4gPj4gV291bGRuJ3QgdGhhdCBiZSBjYWxsZWQgdGhlICJzZXJ2aWNl IGNoYWluIGlkZW50aWZpZXIiIHRoZW4/ICBJZiB0aGUNCj4gPj4gc2VydmljZSBjaGFpbiBpcyB0 aGUgb3JkZXJlZCBsaXN0IG9mIFNGcyBhbmQgdGhlIHNlcnZpY2UgcGF0aCBpcyB0aGUNCj4gPj4g b3JkZXJlZCBsaXN0IG9mIFNGIGluc3RhbmNlcywgdGhlbiBJIHdvdWxkIGluZmVyIHRoYXQgYSAi c2VydmljZSBwYXRoDQo+ID4+IGlkZW50aWZpZXIiIHdvdWxkIGJlIGFuIGlkZW50aWZpZXIgZm9y IGEgc2VydmljZSAqcGF0aCosIG5vdCBhIHNlcnZpY2UNCj4gPj4gKmNoYWluKi4NCj4gPj4NCj4g Pj4NCj4gPj4gQWdhaW4sIEkgdGhpbmsgdGhpcyBpcyB3aGVyZSB0aGUgY29uZnVzaW9uIGtlZXBz IGNyZWVwaW5nIGluLiAgVGhlIHRlcm1zDQo+ID4+ICJjaGFpbiIgYW5kICJwYXRoIiBzZWVtIGlu Y29uc2lzdGVudC4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+ICpGcm9t OiAqamd1aWNoYXJAY2lzY28uY29tPGpndWljaGFyQGNpc2NvLmNvbQ0KPiA+PiA8bWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbSUzY2pndWljaGFyQGNpc2NvLmNvbT4+DQo+ID4+ICpUbzoNCj4gPj4N Cj4gPj4qbWlrZWJpYW5jQGFvbC5jb208bWlrZWJpYW5jQGFvbC5jb20+LG1uMTkyMUBhdHQuY29t PG1uMTkyMUANCj4gYXR0LmNvbT4sbW9oYQ0KPiA+Pm1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPixqbWhAag0KPiBvZWxoYWxwZXJuLmNvDQo+ID4+ bTxqbWhAam9lbGhhbHBlcm4uY29tPixSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPFJv bl9QYXINCj4ga2VyQGFmZmlybWUNCj4gPj5kbmV0d29ya3MuY29tPixzZmNAaWV0Zi5vcmc8c2Zj QGlldGYub3JnDQo+ID4+DQo+ID4+PG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbSUzY21pa2ViaWFu Y0Bhb2wuY29tJTNlLG1uMTkyMUBhdHQuY28NCj4gbSUzY21uMTkyMUANCj4gPj5hdHQuY29tJTNl LG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20lM2Ntb2hhbWVkLmJvdWNhZGFpckANCj4gb3Jh bmdlLmNvbSUzZQ0KPiA+PixqbWhAam9lbGhhbHBlcm4uY29tJTNjam1oQGpvZWxoYWxwZXJuLmNv bSUzZSxSb25fUGFya2VyQGFmZmlybQ0KPiBlZG5ldHdvcmtzDQo+ID4+LmNvbSUzY1Jvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2Usc2ZjQGlldGYub3JnJTNjc2ZjQGlldGYNCj4gLm9y Zz4+DQo+ID4+ICpTZW50OiAqRnJpZGF5LCBKdWx5IDExLCAyMDE0DQo+ID4+ICpTdWJqZWN0OiAq UmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ DQo+ID4+IFlvdXIgZGVmaW5pdGlvbiBvZiBzZXJ2aWNlIHBhdGggaXMgY29ycmVjdCBhcyBpdHMg dGhlIGZvcndhcmRpbmcgcGF0aA0KPiA+PiB0aHJvdWdoIHdoaWNoIHRyYWZmaWMgd2lsbCBhY3R1 YWxseSBmbG93LiBUaGUgc2VydmljZSBwYXRoIGlkZW50aWZpZXINCj4gPj4gaG93ZXZlciBwb2lu dHMgdG8gdGhlIHNlcnZpY2UgY2hhaW4gZGF0YSBzdHJ1Y3R1cmUgYW5kIHRoYXQgaXMgdGhlbg0K PiA+PiByZXNvbHZlZCB0byBzcGVjaWZpYyBpbnN0YW5jZXMgYmFzZWQgdXBvbiB3aGljaCBuZXh0 LWhvcHMgdG8gdGhvc2UNCj4gPj4gaW5zdGFuY2VzIGFyZSBhdmFpbGFibGUgYW5kIHdoYXRldmVy IGxvYWQgZGlzdHJpYnV0aW9uIHRlY2huaXF1ZSBpcyBpbg0KPiA+PiBwbGF5LiBXaGVuIGluc3Rh bnRpYXRpbmcgdGhlIHNlcnZpY2UgY2hhaW4gaW50byB0aGUgbmV0d29yayB5b3UgbWF5IG9yDQo+ ID4+IG1heSBub3QgdXBkYXRlIHRoYXQgZGF0YSBzdHJ1Y3R1cmUgdG8gc3BlY2lmeSB3aGljaCBu ZXh0LWhvcHMgbWF5IGJlDQo+ID4+IHVzZWQgKHdoZXJlIGEgc2luZ2xlIG5leHQtaG9wIHdvdWxk IGVmZmVjdGl2ZWx5IG5haWwgdXAgdGhlIHNlcnZpY2UgcGF0aA0KPiA+PiBmb3IgdGhhdCBzZXJ2 aWNlIGNoYWluKSBvciB5b3UgbWF5IHNpbXBseSBhbGxvdyBzb21lIG90aGVyIHByb3RvY29sIC8N Cj4gPj4gbWVjaGFuaXNtIHRvIHBvcHVsYXRlIHRoZSBkYXRhIHN0cnVjdHVyZSBmb3IgeW91Lg0K PiA+Pg0KPiA+PiAqRnJvbTogKiJtaWtlYmlhbmNAYW9sLmNvbSA8bWFpbHRvOm1pa2ViaWFuY0Bh b2wuY29tPiINCj4gPj4gPG1pa2ViaWFuY0Bhb2wuY29tIDxtYWlsdG86bWlrZWJpYW5jQGFvbC5j b20+Pg0KPiA+PiAqRGF0ZTogKkZyaWRheSwgSnVseSAxMSwgMjAxNCBhdCAxMjoxOCBQTQ0KPiA+ PiAqVG86ICpKaW0gR3VpY2hhcmQgPGpndWljaGFyQGNpc2NvLmNvbSA8bWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbT4+LA0KPiA+PiAibW4xOTIxQGF0dC5jb20gPG1haWx0bzptbjE5MjFAYXR0LmNv bT4iIDxtbjE5MjFAYXR0LmNvbQ0KPiA+PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4sICJtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4iDQo+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+IDxtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+LCAiam1oQGpvZWxoYWxwZXJuLmNvbQ0K PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+IiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0K PiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiwgIlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb20NCj4gPj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t PiINCj4gPj4gPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20NCj4gPj4gPG1haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sICJzZmNAaWV0Zi5vcmcNCj4gPj4gPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPj4N Cj4gPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9h ZCBCYWxhbmNlcnMNCj4gPj4NCj4gPj4gSSB0aGluayB0aGlzIGlzIHRoZSByb290IG9mIHRoZSBj b25mdXNpb246DQo+ID4+DQo+ID4+PiBJIGRvbuKAmXQgd2FudCB0byBzcGVjaWZ5DQo+ID4+PiBz cGVjaWZpYyBpbnN0YW5jZXMgb2YgUzEsIFMyLCBhbmQgUzMgKG9yIHNvbWUgY29tYmluYXRpb24g dGhlcmVvZikuIEkNCj4gPj4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKAnDEw MOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8NCj4gPj4+UzEtPlMyLT5TMw0KPiA+Pj4gYW5k IHRoZW4gcHVzaCB0aGlzIGludG8gdGhlIG5ldHdvcmsNCj4gPj4NCj4gPj4gQnkgZGVmaW5pdGlv biwgSSB1bmRlcnN0b29kIGEgInNlcnZpY2UgcGF0aCIgdG8gYmUgYW4gb3JkZXJlZCBsaXN0IG9m DQo+ID4+IHNwZWNpZmljIFNGIGluc3RhbmNlcy4gSW4gdGhlIHN0YXRlbWVudCBhYm92ZSwgeW91 IHVzZSBhICJzZXJ2aWNlIHBhdGgNCj4gPj4gaWRlbnRpZmllciIgdG8gcmVmZXIgdG8gYSBzZXJ2 aWNlICpjaGFpbiogdGhhdCBzcGVjaWZpY2FsbHkgIltkb2VzIG5vdF0NCj4gPj4gc3BlY2lmeSBz cGVjaWZpYyBpbnN0YW5jZXMiLg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4g Pj4gKkZyb206ICpqZ3VpY2hhckBjaXNjby5jb20NCj4gPj4gPG1haWx0bzpqZ3VpY2hhckBjaXNj by5jb20+PGpndWljaGFyQGNpc2NvLmNvbQ0KPiA+PjxtYWlsdG86amd1aWNoYXJAY2lzY28uY29t Pj4NCj4gPj4gKlRvOiAqTkFQSUVSQUxBLCBNQVJJQSBIPG1uMTkyMUBhdHQuY29tDQo+ID4+IDxt YWlsdG86bW4xOTIxQGF0dC5jb20+Pixtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+ DQo+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT48bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLg0KPiBjb20NCj4gPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj4sSm9lbCBNLg0KPiA+PiBIYWxwZXJuPGptaEBqb2VsaGFscGVybi5jb20gPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPj4sUm9uDQo+ID4+IFBhcmtlcjxSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tDQo+ID4+IDxtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNv bT4+LHNmY0BpZXRmLm9yZw0KPiA+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz48c2ZjQGlldGYub3Jn IDxtYWlsdG86c2ZjQGlldGYub3JnPj4NCj4gPj4gKlNlbnQ6ICpGcmlkYXksIEp1bHkgMTEsIDIw MTQNCj4gPj4gKlN1YmplY3Q6ICpSZTogW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQg TG9hZCBCYWxhbmNlcnMNCj4gPj4NCj4gPj4gTWFyaWEsDQo+ID4+DQo+ID4+IEkgdGhpbmsgb2Yg aXQgdGhpcyB3YXkuIFRoZSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciBpcyBzaW1wbHkgYSBwb2lu dGVyDQo+ID4+dG8NCj4gPj4gYSBkYXRhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIFNGIHRvIG5l eHQtaG9wIG1hcHBpbmdzLiBXaGVuIHlvdQ0KPiBkZWZpbmUNCj4gPj5hDQo+ID4+IGNoYWluLCBs ZXTigJlzIHNheSBTMSAtPlMyLT4gUzMsIHlvdSAqbWlnaHQqIHdoZW4gY3JlYXRpbmcgdGhlIFNG UCBzcGVjaWZ5DQo+ID4+IHRoZSBzcGVjaWZpYyBuZXh0LWhvcHMgdGhhdCB5b3Ugd2FudCB0cmFm ZmljIHRvIGZsb3cgdGhyb3VnaCBmb3IgdGhhdA0KPiA+PlNGUC4NCj4gPj4gSG93ZXZlciwgeW91 IGRvICpub3QqIGhhdmUgdG8gZG8gdGhpcyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgc3RhbmRwb2lu dA0KPiA+PihJDQo+ID4+IHdpbGwgYXJndWUgdGhhdCB5b3Ugc2hvdWxkIGJ1dCB5b3UgZG9u4oCZ dCBoYXZlIHRvIGFyY2hpdGVjdHVyYWxseSkuIFlvdQ0KPiA+PiBjb3VsZCBzaW1wbHkgYXNzaWdu IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgdG8gcG9pbnQgdG8gYSBnaXZlbiBTRkMNCj4gPj5h bmQNCj4gPj4gdGhlbiBwdXNoIHRoYXQgaW5mb3JtYXRpb24gaW50byB0aGUgbmV0d29yay4gQXQg dGhlIFNGRiBpdCB3aWxsIGhhdmUgYQ0KPiA+PiBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciB0byBT RkMgbWFwcGluZyBhbmQgc2FpZCBtYXBwaW5nIHdvdWxkIGNvbnRhaW4NCj4gPj50aGUNCj4gPj4g bmV4dC1ob3BzIGF2YWlsYWJsZSBmb3IgZWFjaCBvZiB0aGUgU0bigJlzIHdpdGhpbiB0aGUgU0ZD IC0gaG93IHlvdSBsZWFybg0KPiA+PiB0aG9zZSBuZXh0LWhvcHMgaXMgdXAgdG8geW91LiBZb3Ug Y291bGQgcHVzaCB0aGVtIGRvd24gZnJvbSBhDQo+ID4+Y2VudHJhbGl6ZWQNCj4gPj4gY29udHJv bGxlciwgY29uZmlndXJlIHRoZW0gdGhyb3VnaCBDTEksIGxlYXJuIHRoZW0gZHluYW1pY2FsbHkg dGhyb3VnaA0KPiA+PiBzb21lIHByb3RvY29sIGV4Y2hhbmdlLCB3aGF0ZXZlciAuLiBTbywgZ2l2 ZW4gdGhpcyBpdCBpcyBub3QgY29ycmVjdCB0bw0KPiA+PiBzYXkgdGhhdCB0aGUgc2VydmljZSBw YXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2VuIGENCj4gPj5wcmlvcmkN Cj4gPj4gYWx0aG91Z2ggaXQgaXMgcGVyZmVjdGx5IGFjY2VwdGFibGUgKGFuZCBzb21lIHdvdWxk IHNheSByZWNvbW1lbmRlZCkNCj4gdG8NCj4gPj5kbw0KPiA+PiBzby4NCj4gPj4NCj4gPj4gTGV0 4oCZcyB0YWtlIGFuIGV4YW1wbGUgdG8gaG9wZWZ1bGx5IG1ha2UgdGhpcyBjbGVhcjoNCj4gPj4N Cj4gPj4gSSBkZWZpbmUgYW4gU0ZDIChsZXTigJlzIHJlZmVyIHRvIGl0IGFzIFNGQy0xKSBTMS0+ UzItPlMzLiBGb3IgYXJndW1lbnRzDQo+ID4+IHNha2UgbGV04oCZcyBzYXkgSSB3YW50IGl0IHRv IGJlIGZ1bGx5IGR5bmFtaWMgZS5nLiBJIGRvbuKAmXQgd2FudCB0bw0KPiA+PnNwZWNpZnkNCj4g Pj4gc3BlY2lmaWMgaW5zdGFuY2VzIG9mIFMxLCBTMiwgYW5kIFMzIChvciBzb21lIGNvbWJpbmF0 aW9uIHRoZXJlb2YpLiBJDQo+ID4+IGFzc2lnbiBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIOKA nDEwMOKAnSB0aGF0IGJhc2ljYWxseSBwb2ludHMgdG8NCj4gPj5TMS0+UzItPlMzDQo+ID4+IGFu ZCB0aGVuIHB1c2ggdGhpcyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgdGhlIFNGRiBkYXRhIHN0 cnVjdHVyZXMgYXJlDQo+ID4+IHBvcHVsYXRlZCB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIE5vdyBh dCBhIGdpdmVuIFNGRiwgd2hlbiB0cmFmZmljDQo+ID4+YXJyaXZlcw0KPiA+PiB3aXRoIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIDEwMCwgdGhlIFNGRiB3aWxsIGxvb2sgdGhpcyB1cCBpbiB0aGUg ZGF0YQ0KPiA+PiBzdHJ1Y3R1cmUgYW5kIGZpbmQgdGhhdCBpdCBwb2ludHMgdG8gUzEtPlMyLT5T MyBhbmQgdGhlIGluZGV4IGluIHRoZSBTRkMNCj4gPj4gZW5jYXBzdWxhdGlvbiB3aWxsIHRlbGwg aXQgZXhhY3RseSB3aGVyZSBpdCBpcyBpbiB0aGUgY2hhaW4uIExldOKAmXMgc2F5DQo+ID4+d2UN Cj4gPj4gYXJlIGF0IFMyIGluIHRoZSBjaGFpbi4gVGhlIFNGRiB3aWxsIG5vdyBoYXZlIHRvIHJl c29sdmUgdGhlIG5leHQtaG9wIHRvDQo+ID4+IFMzIGFuZCB3aWxsIGRvIGEgbG9va3VwIHRvIGRl dGVybWluZSB3aGVyZSBTMyBpcyByZWFjaGFibGUuDQo+ID4+DQo+ID4+IE9uIDcvMTEvMTQsIDEx OjI2IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIxQGF0dC5jb20NCj4gPj4gPG1haWx0 bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KPiA+Pg0KPiA+PiAgPkppbSwNCj4gPj4gID4NCj4g Pj4gID5Db3VsZCB5b3UgdGVsbCB1cyB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgInNlcnZp Y2UgcGF0aCIgYW5kIGENCj4gPj4gID4ic2VydmljZSBwYXRoIGlkZW50aWZpZXIiPw0KPiA+PiAg PklmIGEgc2VydmljZSBwYXRoIG1lYW5zIHRoYXQgYWxsIFNGIGluc3RhbmNlcyBhcmUgY2hvc2Vu IGFwcmlvcmkNCj4gPj4od2hpY2gNCj4gPj4gID5pcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcp IHRoZW4gaXQgaXMgbm90IFNGRidzIGxvY2FsIGRlY2lzaW9uIHdoaWNoDQo+ID4+ICA+bmV4dC1o b3AgU0ZGIHRvIHBpY2suIEl0IGlzIGEgY2VudHJhbGl6ZWQgZGVjaXNpb24uDQo+ID4+ICA+DQo+ ID4+ICA+TWFyaWENCj4gPj4gID4NCj4gPj4gID4NCj4gPj4gID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+ICA+Pg0KPiA+Pg0KPiA+PiBGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWlj aGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4gPj4gID4+IFNlbnQ6IEZyaWRheSwg SnVseSAxMSwgMjAxNCAxMToxNSBBTQ0KPiA+PiAgPj4gVG86IE5BUElFUkFMQSwgTUFSSUEgSDsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+OyBKb2VsIE0uDQo+ID4+ICA+PiBIYWxwZXJuOyBSb24gUGFya2VyOyBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiBTdWJqZWN0OiBSZTog W3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4gPj4gID4+ DQo+ID4+ICA+PiBJ4oCZbSBzb3JyeSBidXQgSSByZWFsbHkgZG9u4oCZdCB1bmRlcnN0YW5kIHdo eSBhIHNlcnZpY2UgcGF0aA0KPiA+PmlkZW50aWZpZXINCj4gPj4gID4+IHByZXZlbnRzIGZ1bGwg ZGlzdHJpYnV0aW9uIG9mIFNGIG5leHQtaG9wcyBvciB3aHkgY2FsbGluZyBpdCBhDQo+ID4+c2Vy dmljZQ0KPiA+PiAgPj4gY2hhaW4gaWRlbnRpZmllciBtYWtlcyBhbnkgZGlmZmVyZW5jZT8NCj4g Pj4gID4+DQo+ID4+ICA+PiBPbiA3LzExLzE0LCAxMDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEg SCIgPG1uMTkyMUBhdHQuY29tDQo+ID4+IDxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90ZToN Cj4gPj4gID4+DQo+ID4+ICA+PiA+RGl0dG8uDQo+ID4+ICA+PiA+DQo+ID4+ICA+PiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiAgPj4gPj4gRnJvbTogbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbQ0KPiA+PiA8bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ DQo+ID4+ICA+PiA+PiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dDQo+ID4+ ICA+PiA+PiBTZW50OiBGcmlkYXksIEp1bHkgMTEsIDIwMTQgMTA6MzEgQU0NCj4gPj4gID4+ID4+ IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgTkFQSUVSQUxBLCBNQVJJQSBIOyBKb2VsIE0u DQo+ID4+SGFscGVybjsgUm9uDQo+ID4+ICA+PiA+PiBQYXJrZXI7IHNmY0BpZXRmLm9yZyA8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+IFN1YmplY3Q6IFJFOiBbc2ZjXSBTZXJ2aWNl IENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiAgPj4gPj4NCj4gPj4gID4+ ID4+IFJlLSwNCj4gPj4gID4+ID4+DQo+ID4+ICA+PiA+PiBGb3Igd2hhdCBJIGNhbiBzYXkgYXQg YmVzdCB0aGlzIGlzIG5vdCBkZXNjcmliZWQgY2xlYXJseSBpbiB0aGUNCj4gPj4gID4+ZHJhZnQu DQo+ID4+ICA+PiA+Pg0KPiA+PiAgPj4gPj4gTWFuZGF0aW5nIGEgc2VydmljZSBwYXRoIGlkZW50 aWZpZXIgaXMgaW4gaXRzZWxmIGEgaGludCB0aGF0IHRoZQ0KPiA+PmZ1bGwNCj4gPj4gID4+ID4+ ZGlzdHJpYnV0ZWQNCj4gPj4gID4+ID4+IG1vZGVsIGlzIG5vdCBhbGxvd2VkLg0KPiA+PiAgPj4g Pj4NCj4gPj4gID4+ID4+IFNldmVyYWwgdm9pY2VzIGluIHRoaXMgdGhyZWFkIGluZGljYXRlZCB0 aGF0IHRoZSBzZXJ2aWNlIGNoYWluDQo+ID4+aXRzZWxmDQo+ID4+ICA+PiA+PnNob3VsZCBiZQ0K PiA+PiAgPj4gPj4gcHJvdmlkZWQgaW5zdGVhZC4NCj4gPj4gID4+ID4+DQo+ID4+ICA+PiA+PiBD aGVlcnMsDQo+ID4+ICA+PiA+PiBNZWQNCj4gPj4gID4+ID4+DQo+ID4+ICA+PiA+PiA+LS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+ICA+PiA+PiA+RGUgOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKaW0NCj4gPj5HdWljaGFyZA0KPiA+PiAg Pj4gPj4gPihqZ3VpY2hhcikNCj4gPj4gID4+ID4+ID5FbnZvecOpIDogdmVuZHJlZGkgMTEganVp bGxldCAyMDE0IDE2OjE4DQo+ID4+ICA+PiA+PiA+w4AgOiBOQVBJRVJBTEEsIE1BUklBIEg7IEpv ZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2Zj QGlldGYub3JnPg0KPiA+PiAgPj4gPj4gPk9iamV0IDogUmU6IFtzZmNdIFNlcnZpY2UgQ2hhaW5z LCBQYXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ICA+PiA+PiA+DQo+ID4+ICA+PiA+PiA+ T2sgYnV0IHdoZXJlIGluIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWNhbGx5IGlzIHRoaXMNCj4g Pj5mdW5jdGlvbmFsaXR5DQo+ID4+ICA+PiA+PiA+cHJvaGliaXRlZD8gSWYgeW91IHdhbnQgdG8g ZGlzdHJpYnV0ZSAqYWxsKiBuZXh0LWhvcHMgdG8gKmFsbCoNCj4gPj5TRkbigJlzDQo+ID4+ICA+ PiA+PiA+d2l0aGluIHRoZSBTRkMgZG9tYWluIGFuZCB0aGVuIGxldCB0aGUgcGF0aCBpZGVudGlm aWVyIHBvaW50IHRvDQo+ID4+YQ0KPiA+PiAgPj4gPj5sb29rdXANCj4gPj4gID4+ID4+ID5pbnRv IHRob3NlIG5leHQtaG9wcyB0byByZWFjaCB0aGUgbmV4dCBTRiBpbiB0aGUgY2hhaW4sIEkgYW0g bm90DQo+ID4+ICA+PnN1cmUNCj4gPj4gID4+ID4+aG93DQo+ID4+ICA+PiA+PiA+dGhlIGFyY2hp dGVjdHVyZSBwcmV2ZW50cyB0aGF0Pw0KPiA+PiAgPj4gPj4gPg0KPiA+PiAgPj4gPj4gPk9uIDcv MTEvMTQsIDk6NTggQU0sICJOQVBJRVJBTEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbQ0KPiA+ PiA8bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4NCj4gPj4gID4+IHdyb3RlOg0KPiA+PiAgPj4gPj4g Pg0KPiA+PiAgPj4gPj4gPj5BYnNvbHV0ZWx5Lg0KPiA+PiAgPj4gPj4gPj4NCj4gPj4gID4+ID4+ ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiAgPj4gPj4gPj4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+ID4+R3Vp Y2hhcmQNCj4gPj4gID4+ID4+ID4+PihqZ3VpY2hhcikNCj4gPj4gID4+ID4+ID4+PiBTZW50OiBG cmlkYXksIEp1bHkgMTEsIDIwMTQgOTo1NCBBTQ0KPiA+PiAgPj4gPj4gPj4+IFRvOiBOQVBJRVJB TEEsIE1BUklBIEg7IEpvZWwgTS4gSGFscGVybjsgUm9uIFBhcmtlcjsNCj4gPj4gc2ZjQGlldGYu b3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gPj4gPj4+IFN1YmplY3Q6IFJlOiBb c2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiAgPj4g Pj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gVGhlbiBJIG1pc3VuZGVyc3RhbmQgdGhlIHByb3Bvc2Fs IDstKSAuLiBIb3dldmVyLCBpdCBzZWVtcw0KPiA+PnRvIG1lDQo+ID4+ICA+PiA+PnRoYXQgaWYN Cj4gPj4gID4+ID4+ID4+PiB5b3UgYWxsb3cgYW4gU0ZGIHRvIG1ha2UgYSBkZWNpc2lvbiBhcyB0 byB3aGljaCByZW1vdGUgU0ZGIGl0DQo+ID4+ICA+PndpbGwNCj4gPj4gID4+ID4+dXNlDQo+ID4+ ICA+PiA+PiA+Pj5mb3INCj4gPj4gID4+ID4+ID4+PiBhIGdpdmVuIGZsb3cgdG8gcmVhY2ggdGhl IG5leHQgU0Ygd2l0aGluIHRoZSBjaGFpbiB0aGVuIHlvdQ0KPiA+PiAgPj5iZXR0ZXINCj4gPj4g ID4+ID4+bWFrZQ0KPiA+PiAgPj4gPj4gPj4+IHN1cmUgdGhhdCB0aGF0IHJlbW90ZSBTRkYgaGFz IHRoZSBuZWNlc3NhcnkgZm9yd2FyZGluZyBsb2dpYw0KPiA+PnRvDQo+ID4+ICA+PiA+PnJlYWNo DQo+ID4+ICA+PiA+PiA+Pj50aGUNCj4gPj4gID4+ID4+ID4+PiBuZXh0LW5leHQtU0YgZm9yIHRo ZSBjaGFpbiBhcyBvdGhlcndpc2UgeW91IGFyZSBpbiBkZWVwDQo+ID4+dHJvdWJsZS4NCj4gPj4g ID4+ID4+ID4+Pg0KPiA+PiAgPj4gPj4gPj4+IE9uIDcvMTEvMTQsIDk6NDggQU0sICJOQVBJRVJB TEEsIE1BUklBIEgiDQo+IDxtbjE5MjFAYXR0LmNvbQ0KPiA+PiA8bWFpbHRvOm1uMTkyMUBhdHQu Y29tPj4NCj4gPj4gID4+ID4+IHdyb3RlOg0KPiA+PiAgPj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPkFic29sdXRlbHkgbm90LiBTZXJ2aWNlIGNoYWlucyBjYW4gYmUgaW5zdGFudGlhdGVkIG9u bHkgaW4NCj4gPj4gID4+cmVsZXZhbnQNCj4gPj4gID4+ID4+ID4+PlNGRnMNCj4gPj4gID4+ID4+ ID4+PiA+d2hlbiB0aGV5ICJhcnJpdmUiLg0KPiA+PiAgPj4gPj4gPj4+ID4NCj4gPj4gID4+ID4+ ID4+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiAgPj4gPj4gPj4+ID4+IEZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltDQo+ ID4+ICA+Pkd1aWNoYXJkDQo+ID4+ICA+PiA+PiA+Pj4gPj4oamd1aWNoYXIpDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDE0IDk6MjcgQU0NCj4gPj4gID4+ID4+ ID4+PiA+PiBUbzogSm9lbCBNLiBIYWxwZXJuOyBSb24gUGFya2VyOyBzZmNAaWV0Zi5vcmcNCj4g Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gU3ViamVjdDogUmU6 IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj5CYWxhbmNlcnMNCj4g Pj4gID4+ID4+ID4+PiA+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+IFdlbGwgSSB0aGluayBpdCBpcyBl dmVuIHdvcnNlIHRoYW4gdGhhdCBpZiBJIGhhdmUNCj4gPj51bmRlcnN0b29kDQo+ID4+ICA+PnRo ZQ0KPiA+PiAgPj4gPj4gPj4+ID4+cHJvcG9zYWwNCj4gPj4gID4+ID4+ID4+PiA+PiBjb3JyZWN0 bHkgYXMgaXQgd291bGQgcmVxdWlyZSBmdWxsIGtub3dsZWRnZSBvZiBldmVyeQ0KPiA+PnNpbmds ZQ0KPiA+PiAgPj5TRg0KPiA+PiAgPj4gPj4gPj4+d2l0aGluDQo+ID4+ICA+PiA+PiA+Pj4gPj50 aGUNCj4gPj4gID4+ID4+ID4+PiA+PiBlbnRpcmUgU0ZDIGRvbWFpbiBhdCBldmVyeSBzaW5nbGUg U0ZGIGFzIHRoZXJlIGlzIG5vIHdheQ0KPiA+PnRvDQo+ID4+ICA+Pmtub3cNCj4gPj4gID4+ID4+ YQ0KPiA+PiAgPj4gPj4gPj4+ID4+cHJpb3JpDQo+ID4+ICA+PiA+PiA+Pj4gPj4gd2hpY2ggU0ZD wrlzIGEgZ2l2ZW4gU0ZGIHdpbGwgbmVlZCB0byBzZXJ2aWNlIGF0IGFueSBnaXZlbg0KPiA+PiAg Pj5wb2ludA0KPiA+PiAgPj4gPj5pbg0KPiA+PiAgPj4gPj4gPj4+dGltZS4NCj4gPj4gID4+ID4+ ID4+PiA+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+IE9uIDcvMTAvMTQsIDExOjUzIFBNLCAiSm9lbCBN LiBIYWxwZXJuIg0KPiA+PiA8am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+Pg0KPiA+PiAgPj4gPj4gd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Um9uLCB0aGlua2luZyBhYm91dCB0aGlzLCBJIHJlYWxpemVkIGFub3Ro ZXIgbWFqb3INCj4gPj5wcm9ibGVtDQo+ID4+ICA+PndpdGgNCj4gPj4gID4+ID4+dGhlDQo+ID4+ ICA+PiA+PiA+Pj4gPj55b3VyDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPnByb3Bvc2FsIGFzIEkgdW5k ZXJzdGFuZCBpdC4gKEFuZCBJIHJlYWRpbHkgYWRtaXQgSSBtYXkNCj4gPj5ub3QNCj4gPj4gID4+ ID4+ID4+PnVuZGVyc3RhbmQNCj4gPj4gID4+ID4+ID4+PiA+PiA+aXQuKQ0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4NCj4gPj4gID4+ID4+ID4+PiA+PiA+VGhlIHByb3Bvc2FsIGhhcyBlYWNoIFNGRiBz ZXJ2ZSBhcyB0aGUgbG9hZCBiYWxhbmNlciBmb3INCj4gPj50aGUNCj4gPj4gID4+ID4+bmV4dA0K PiA+PiAgPj4gPj4gPj4+ID4+ID5zZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgZm9sbG93cyBpdCAobm90 IHRoZSBvbmUgaXQgZGVsaXZlcnMNCj4gPj4gID4+dG8pLA0KPiA+PiAgPj4gPj5pbg0KPiA+PiAg Pj4gPj4gPj4+ZXZlcnkNCj4gPj4gID4+ID4+ID4+PiA+PiA+c2VydmljZSBjaGFpbiB0aGF0IGdv ZXMgdGhyb3VnaCBpdC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+DQo+ID4+ICA+PiA+PiA+Pj4gPj4g PlNpbmNlIGl0IGhhcyB0byBiZSBhYmxlIHRvIHdvcmsgd2l0aCBhbGwgc2VydmljZXMsIHRoYXQN Cj4gPj5tZWFucw0KPiA+PiAgPj4gPj50aGF0DQo+ID4+ICA+PiA+PiA+Pj4gPj5ldmVyeQ0KPiA+ PiAgPj4gPj4gPj4+ID4+ID5TRkYgd291bGQgaGF2ZSB0byBiZSBhIGZ1bGwsIGZsb3cgc2Vuc2l0 aXZlIGFuZCBzdGF0ZWZ1bA0KPiA+PmxvYWQNCj4gPj4gID4+ID4+ID4+PmJhbGFuY2VyLg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID5JIGFodmUgbm8gcHJvYmxlbSBpZiBzb21lIFNGRiBhcmUgZmxvdyBz ZW5zaXRpdmUsIGFuZCAvDQo+ID4+b3INCj4gPj4gID4+ID4+c3RhdGVmdWwuDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPkJ1dCBoYXZpbmcgdGhlIGFyY2hpdGVjdHVyZSByZXF1aXJlIHRoYXQgZXZlcnkg U0ZGIGJlIGENCj4gPj5mdWxsLA0KPiA+PiAgPj4gPj5mbG93DQo+ID4+ICA+PiA+PiA+Pj4gPj4g PnNlbnNpdGl2ZSwgc3RhdGVmdWwsIGxvYWQgYmFsYW5jZXIgc2VlbXMgdG8gbWUgdG8gYmUgYW4N Cj4gPj4gID4+ID4+YWNjZXB0YWJsZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID5pbXBvc2l0aW9uLg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4NCj4gPj4gID4+ID4+ID4+PiA+PiA+WW91cnMsDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPkpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPk9uIDcvMTAvMTQsIDEwOjA2IFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4gUGFydCBvZiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgSSBhbSB0cnlp bmcgdG8gbWFrZQ0KPiA+PnRoaXMNCj4gPj4gID4+d29yaw0KPiA+PiAgPj4gPj4gPj4+ID4+c2Vu c2libHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+PiBpbiBhIG1vcmUgb3JjaGVzdHJhdGVkIGVudmly b25tZW50LiBJIGV4cGVjdCB0aGF0IHRoZQ0KPiA+PiAgPj5zZXJ2aWNlDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4gZnVuY3Rpb25zLCBhbmQgb3ZlciB0aW1lIHByb2JhYmx5IHRoZSBTRkYgY2FwYWJp bGl0aWVzLA0KPiA+PiAgPj53aWxsDQo+ID4+ICA+PiA+PmJlDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4gb3JjaGVzdHJhdGVkIGFuZCBpbnN0YWxsZWQuIEkgZXhwZWN0IHRoZSBzZXJ2aWNlIGNoYWlu cw0KPiA+PiAgPj50byBiZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ZHJpdmVuIGJ5DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4gQlNTIHRvb2xzIHRoYXQgZGVmaW5lIG9mZmVyaW5ncyB0byBjbGllbnRzLCBh bmQgZW5hYmxlDQo+ID4+ICA+PiA+PiA+Pj5zZWxmLXNlbGVjdGlvbg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+IGZyb20gdGhlc2UuIEkgZXhwZWN0IHNlcnZpY2UgcGF0aHMgdG8gYmUgaGVhdmlseSBw b2xpY3kNCj4gPj4gID4+ID4+ZHJpdmUuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+PiBJIGNhbiBzZWUgaG93IHRvIG1ha2UgYWxsIG9mIHRoYXQgd29yayBpbiBh bg0KPiA+PmFyY2h0aWVjdHVyZQ0KPiA+PiAgPj4gPj5kcml2ZW4NCj4gPj4gID4+ID4+ID4+PmJ5 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4gaW5pdGlhbCBjbGFzc2lmaWNhdGlvbiB0byBkZXNjcmli ZWQgc2VydmljZSBwYXRocy4gSXQNCj4gPj5pcw0KPiA+PiAgPj4gPj5oYXJkZXINCj4gPj4gID4+ ID4+ID4+PnRvDQo+ID4+ICA+PiA+PiA+Pj4gPj5zZWUNCj4gPj4gID4+ID4+ID4+PiA+PiA+PiBo b3cgdG8gbWFrZSBpdCB3b3JrIChidXQgaXQgY2FuIGJlIGRvbmUpIHdoZW4gd2UNCj4gYWxsb3cN Cj4gPj5tb3JlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gZHluYW1pY2l0eQ0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+IGluIHRoZSBuZXR3b3JrIGJlaGF2aW9yLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgbW9zdCBvZiB0aGF0IHBlcnNw ZWN0aXZlIEkgZGVzY3JpYmVkDQo+ID4+aXMNCj4gPj4gID4+ID4+b3V0c2lkZQ0KPiA+PiAgPj4g Pj4gPj4+b2YNCj4gPj4gID4+ID4+ID4+PiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+IHNj b3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBpdCBpcyBub3Qgc29tZXRoaW5nIHdlIGFyZQ0KPiA+ PiAgPj4gPj50YXNrZWQgdG8NCj4gPj4gID4+ID4+ID4+PiA+PmFncmVlDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj5vbi4NCj4gPj4gID4+ID4+ID4+PiA+PiA+PiBTbyBJIGRvIG5vdCBjbGFpbSB0aGF0 IHZpc2lvbiBtZWFucyB3ZSBoYXZlIHRvIGRvIGl0IGENCj4gPj4gID4+Y2VydGFpbg0KPiA+PiAg Pj4gPj4gPj4+d2F5Lg0KPiA+PiAgPj4gPj4gPj4+ID4+aXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+ PiBpcyBqdXN0IHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGRyaXZlcyBteSBwcmVmZXJlbmNlcy4NCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+IFlvdXJzLA0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+IEpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+IE9uIDcvMTAvMTQsIDk6NTggUE0sIElhbiBTbWl0aCB3cm90ZToNCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+IEZvciBtZSwgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBhYm91dCBz ZXJ2aWNlDQo+ID4+aW5zdGFuY2VzDQo+ID4+ICA+PiA+PiB0aGF0DQo+ID4+ICA+PiA+PiA+Pj4g Pj5uZWVkcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj50bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gYmUgd2lkZWx5IGRpc3RyaWJ1dGVkIGFuZCBtYWludGFpbmVkLCBwb3RlbnRpYWxseQ0KPiA+ PmV2ZW4NCj4gPj4gID4+ID4+YWNyb3NzDQo+ID4+ICA+PiA+PiA+Pj5kYXRhDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBzY29wZSwgaXMg bGFyZ2UNCj4gPj5lbm91Z2gNCj4gPj4gID4+YW5kDQo+ID4+ICA+PiA+PiA+Pj4gY29tcGxleA0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gZW5vdWdoIHRoYXQgdHJ5aW5nIHRvIGdldCB0aGF0IGlu dG8gZWFjaCBTRkYgc2VlbXMNCj4gPj5saWtlIGENCj4gPj4gID4+ID4+ID4+PmRpZmZpY3VsdA0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IEknbSBjdXJpb3VzIGFzIHRv IHdoeSB0aGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbg0KPiA+PiAgPj5keW5hbWljDQo+ID4+ ICA+PiA+PiA+Pj4gcm91dGluZywNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gaHlwZXItc2NhbGUg ZGF0YSBjZW50ZXIgb3JjaGVzdHJhdGlvbiwgb3IgRE5TLCBhbGwgb2YNCj4gPj4gID4+d2hpY2gN Cj4gPj4gID4+ID4+YXJlDQo+ID4+ICA+PiA+PiA+Pj4gPj5iaWdnZXINCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4gcHJvYmxlbXMgdGhhdCBoYXZlIGJlZW4gcHJvZml0YWJseSBhbmQgc3RhYmx5DQo+ ID4+aW1wbGVtZW50ZWQ/DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+IEl0IGFsc28gc2VlbXMgdGhhdCBpZiBpdCByZWFsbHkgaXMgbW9yZSBjb21wbGljYXRl ZCwNCj4gPj50aGF0DQo+ID4+ICA+PmlzDQo+ID4+ICA+PiA+PmENCj4gPj4gID4+ID4+ID4+Pmdv b2QNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gc2lnbiB0aGF0IGl0IGlzIHRvbyBjb21wbGljYXRl ZC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gU2VudDogVGh1 cnNkYXksIEp1bHkgMTAsIDIwMTQgOTo0NSBQTQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBUbzog Um9uIFBhcmtlcjsgSm9lbCBIYWxwZXJuIERpcmVjdDsNCj4gbWlrZWJpYW5jQGFvbC5jb20NCj4g Pj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47DQo+ID4+ICA+Pklhbg0KPiA+PiAgPj4gPj4g Pj4+U21pdGg7DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNl cnZpY2UgQ2hhaW5zLCBQYXRocywgYW5kIExvYWQNCj4gPj4gID4+QmFsYW5jZXJzDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IFRoaXMgaXMgYW4gYXJjaGl0 ZWN0dXJhbCBpc3N1ZS4gQW5kIG9uZSB0aGF0IEkgd291bGQNCj4gPj4gID4+cHJlZmVyDQo+ID4+ ICA+PiA+PndlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+YWN0dWFsbHkNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4gZGVjaWRlLCByYXRoZXIgdGhhbiB0cnlpbmcgdG8gYWxsb3cgYWxsIHBvc3NpYmxl DQo+ID4+ICA+PiA+PmltcGxlbWVudGF0aW9ucy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gQmVj YXVzZSBpdCBkb2VzIGhhdmUgYSBtYWpvciBlZmZlY3Qgb24gdGhlIGNvbnRyb2wNCj4gPj4gID4+ ID4+cmVxdWlyZW1lbnRzDQo+ID4+ICA+PiA+PiA+Pj5hbmQNCj4gPj4gID4+ID4+ID4+PiA+PiB0 aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gZnVuY3Rpb25hbGl0eSBvZiBTRkZzLg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBGb3IgbWUsIHRoZSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gYWJvdXQgc2VydmljZQ0KPiA+Pmluc3RhbmNlcw0KPiA+PiAgPj4g Pj50aGF0DQo+ID4+ICA+PiA+PiA+Pj4gbmVlZHMNCj4gPj4gID4+ID4+ID4+PiA+PiB0bw0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+PiBiZSB3aWRlbHkgZGlzdHJpYnV0ZWQgYW5kIG1haW50YWluZWQs IHBvdGVudGlhbGx5IGV2ZW4NCj4gPj4gID4+IGFjcm9zcw0KPiA+PiAgPj4gPj4gPj4+ZGF0YQ0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+PiBjZW50ZXJzIHdpdGhpbiBhbiBhZG1pbmlzdHJhdGl2ZSBz Y29wZSwgaXMgbGFyZ2UNCj4gPj5lbm91Z2gNCj4gPj4gID4+YW5kDQo+ID4+ICA+PiA+PiA+Pj5j b21wbGV4DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IGVub3VnaCB0aGF0IHRyeWluZyB0byBnZXQg dGhhdCBpbnRvIGVhY2ggU0ZGIHNlZW1zDQo+ID4+bGlrZSBhDQo+ID4+ICA+PiA+PiA+Pj5kaWZm aWN1bHQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4gYXJjaGl0ZWN0dXJlIHRvIHJlYWxpemUuDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IFlvdXJzLA0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+PiBKb2VsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+IEJ1dCBpdCBpcyBhIGZhaXIgcXVlc3Rpb24uDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+IE9uIDcvMTAvMTQsIDk6MzggUE0sIFJv biBQYXJrZXIgd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBUaGlzIGlzIHRoZSBjcnV4 IG9mIG15IGlzc3VlLiBJcyB0aGUgZW5kIHRvIGVuZA0KPiA+PiAgPj5zZWxlY3Rpb24NCj4gPj4g ID4+ID4+b2YNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ICh0b3AtbGV2ZWwpIGluc3RhbmNlcyBw ZXJmb3JtZWQgY2VudHJhbGx5IChwZXJoYXBzDQo+ID4+YnkgdGhlDQo+ID4+ICA+PiA+PiA+Pj4g Pj5jbGFzc2lmaWVyKQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gb3IgaG9wLWJ5LWhvcCAocGVy aGFwcyBieSB0aGUgY2xhc3NpZmllciBhbmQNCj4gPj5zdWJzZXF1ZW50bHkNCj4gPj4gID4+ID4+ dGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj5TRkZzKT8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFN1 Y2ggc2VsZWN0aW9uIGlzIG5vdCBlcXVpdmFsZW50IHRvIHJlY2xhc3NpZmljYXRpb24uDQo+ID4+ ICA+PkFuZA0KPiA+PiAgPj4gPj4gPj4+c3VyZWx5LA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g dGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsIGlzc3VlIGFuZCBub3QgcmVsZWdhdGVkIHRvDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb24iLg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IE15IG93biB2aWV3IGlzIHRvIGZhdm9yIHRo ZSBkaXN0cmlidXRlZCBhcHByb2FjaA0KPiBldmVuDQo+ID4+ICA+PiB0aG91Z2gNCj4gPj4gID4+ ID4+IGENCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGdyZWF0ZXIgYW1vdW50IG9mIGRhdGEgKGNo YWluIGRlZmluaXRpb25zIGFuZA0KPiBwZXJoYXBzDQo+ID4+ICA+PmxvY2FsDQo+ID4+ICA+PiA+ PiA+Pj4gPj5zZWxlY3Rpb24NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHBvbGljeSkgaXMgcmVx dWlyZWQgYXQgdGhvc2UgZGlzdHJpYnV0ZWQgZGVjaXNpb24NCj4gPj5wb2ludHMuDQo+ID4+ICA+ PiA+PlRoaXMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGFwcHJvYWNoIGRvZXMgbm90IHJlcXVp cmUgYW4gZW5kLXRvLWVuZCBwYXRoIGlkIGF0DQo+ID4+YWxsLg0KPiA+PiAgPj4gPj5NeQ0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4gcmF0aW9uYWxlIGZvciBmYXZvcmluZyB0aGlzIGFwcHJvYWNo IGlzIHByaW1hcmlseQ0KPiA+PmRyaXZlbg0KPiA+PiAgPj5ieQ0KPiA+PiAgPj4gPj4gPj4+ID4+ aW5jcmVhc2VkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiByZXNpbGllbmN5IG92ZXIgdGhlIGds b2JhbCBwYXRoIGlkIGFwcHJvYWNoLiBXaXRoIGENCj4gPj4gID4+Z2xvYmFsDQo+ID4+ICA+PiA+ PiA+Pj5wYXRoDQo+ID4+ICA+PiA+PiA+Pj4gPj5pZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g YXBwcm9hY2gsIGNvbnNpZGVyIGZhaWx1cmUgb2YgYW4gaW5zdGFuY2UgYW5kDQo+ID4+bmVlZGlu ZyB0bw0KPiA+PiAgPj4gPj5hbHRlcg0KPiA+PiAgPj4gPj4gPj4+dGhlDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+PiBnbG9iYWwgcGF0aCBJRCB0YWJsZSBmb3IgZWFjaCBhbmQgZXZlcnkgYWZmZWN0 ZWQNCj4gPj4gID4+ZW5kLXRvLWVuZA0KPiA+PiAgPj4gPj4gPj4+cGF0aC4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBSb24NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEZyb206IHNmYw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4g W3NmYy1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPiA+ PiBvbiBiZWhhbGYgb2YgSm9lbCBIYWxwZXJuIERpcmVjdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4gW2ptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWlsdG86am1oLmRpcmVjdEBq b2VsaGFscGVybi5jb20+XSBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwNCj4gPj4gID4+MjAxNA0K PiA+PiAgPj4gPj4gNjoxNQ0KPiA+PiAgPj4gPj4gPj4+IFBNDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+PiBUbzogbWlrZWJpYW5jQGFvbC5jb20NCj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47 DQo+ID4+IEkuU21pdGhARjUuY29tIDxtYWlsdG86SS5TbWl0aEBGNS5jb20+OyBzZmNAaWV0Zi5v cmcNCj4gPj48bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+IFN1YmplY3Q6DQo+ID4+ICA+ PiA+PiBSZToNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFtzZmNdIFNlcnZpY2UgQ2hhaW5zLCBQ YXRocywgYW5kIExvYWQgQmFsYW5jZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4gVGhlIHdheSB0aGUgYXJjaGl0ZWN0dXJlIG1vZGVscyB0aGUgY2Fz ZSBvZiBTRjENCj4gPj5uZWVkaW5nDQo+ID4+ICA+PnRvDQo+ID4+ICA+PiA+PiA+Pj4gPj5pbmZs dWVuY2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IHRoZSBjaGFpbiBpcyB0aGF0IG9uZSB3b3Vs ZCBkbyByZWNsYXNzaWZpY2F0aW9uIGF0DQo+ID4+dGhlDQo+ID4+ICA+PmV4aXQNCj4gPj4gID4+ ID4+ZnJvbQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4gU0YxLg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IFBhcnQgb2YgdGhlIGdvYWwgaXMgdG8ga2Vl cCB0aGUgZGlmZmVyZW50IGZ1bmN0aW9ucw0KPiA+PiAgPj4gPj5sb2dpY2FsbHkNCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+IHNlcGFyYXRlIHNvIHRoYXQgc29sdXRpb25zIGNhbiBjbGVhcmx5IGRl c2NyaWJlIGhvdw0KPiA+PnRoZXkNCj4gPj4gID4+ID4+IGNob29zZQ0KPiA+PiAgPj4gPj4gPj4+ dG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+IGNvbXBvc2UgdGhlbSBmb3IgInNlcnZpY2UiIGRl bGl2ZXJ5Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ IFlvdXJzLCBKb2VsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4gT24gNy8xMC8xNCwgNjoxMCBQTSwgbWlrZWJpYW5jQGFvbC5jb20NCj4gPj4gPG1haWx0 bzptaWtlYmlhbmNAYW9sLmNvbT4gd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gSSBk b24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGFyY2ggZHJhZnQgdGhhdA0KPiA+PnN1Z2dlc3RzIGFu eQ0KPiA+PiAgPj4gPj5zb3J0DQo+ID4+ICA+PiA+PiA+Pj5vZg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IGxpbWl0LiBIb3dldmVyLCBpdCBkb2VzIHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB0aGUN Cj4gPj5lbnRpcmUNCj4gPj4gID4+ID4+cGF0aA0KPiA+PiAgPj4gPj4gPj4+KGFsbA0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+IFNGSXMpIG11c3QgYmUgY2hvc2VuIGF0IFNGQyBpbnN0YW50aWF0 aW9uLiBJIGJlbGlldmUNCj4gPj4gID4+dGhpcw0KPiA+PiAgPj4gPj4gPj4+bWVhbnMNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+PiBlaXRoZXIgYXQgdGhlIGNsYXNzaWZpZXIgb3IgbWF5YmUgdGhl IGNsYXNzaWZpZXINCj4gPj4gID4+Y2hvb3NlcyBhDQo+ID4+ICA+PiA+PlNGDQo+ID4+ICA+PiA+ PiA+Pj4gPj5DaGFpbg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGFuZCB0aGUgTkYgb3IgYXQg dGhlIGxhdGVzdCB0aGUgZmlyc3QgU0ZGLiBJbiBhbnkNCj4gPj5jYXNlLA0KPiA+PiAgPj4gPj50 aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBsYW5ndWFnZSBkb2VzIHNlZW0gdG8gcHJvaGli aXQgYSBtb3JlIGR5bmFtaWMgU0ZQDQo+ID4+d2hlcmUNCj4gPj4gID4+ID4+IFNGSShuKQ0KPiA+ PiAgPj4gPj4gPj4+IGlzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZGV0ZXJtaW5lZCBhdCB0 aGUgU0ZJKG4tMSkgaG9wLiBBY2NvcmRpbmcgdG8gdGhlDQo+ID4+ZHJhZnQsDQo+ID4+ICA+PiA+ PnRoaXMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBiZWhhdmlvciB3b3VsZCBiZSBjb25zaWRl cmVkICJicmFuY2hpbmciIHRvIGEgbmV3DQo+ID4+U0ZQIGFzDQo+ID4+ICA+PiA+PiA+Pj4gb3Bw b3NlZA0KPiA+PiAgPj4gPj4gPj4+ID4+IHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gY2hv b3NpbmcgYW5kIHRoZW4gZm9yd2FyZGluZyB0byB0aGUgc2VsZWN0ZWQNCj4gPj5pbnN0YW5jZSBv Zg0KPiA+PiAgPj4gPj50aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBuZXh0LWhvcCBvZiB0 aGUgY3VycmVudCBTRkMuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBkcmFmdC1tZXJnZWQtc2ZjLWFyY2hpdGVjdHVyZS0wMDoNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gV2hlbiBhbiBTRkMgaXMgaW5zdGFudGlhdGVkIGludG8gdGhlIG5ldHdv cmsgaXQgaXMNCj4gPj4gID4+ID4+bmVjZXNzYXJ5DQo+ID4+ICA+PiA+PiA+Pj50bw0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+PiBzZWxlY3QgdGhlIHNwZWNpZmljIGluc3RhbmNlcyBvZiBTRnMg dGhhdCB3aWxsIGJlDQo+ID4+dXNlZCwNCj4gPj4gID4+ID4+YW5kIHRvDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IGNyZWF0ZSB0aGUgc2VydmljZSB0b3BvbG9neSBmb3IgdGhhdCBTRkMgdXNp bmcgU0Yncw0KPiA+PiAgPj4gPj5uZXR3b3JrDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IGxv Y2F0b3IuIFRodXMsIGluc3RhbnRpYXRpb24gb2YgdGhlIFNGQyByZXN1bHRzIGluDQo+ID4+dGhl DQo+ID4+ICA+PiA+PiA+Pj5jcmVhdGlvbg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBvZiBh IFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKSBhbmQgaXMgdXNlZCBmb3INCj4gPj4gID4+ID4+ Zm9yd2FyZGluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBwYWNrZXRzIHRocm91Z2ggdGhl IFNGQy4gSW4gb3RoZXIgd29yZHMsIGFuIFNGUCBpcw0KPiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+PiBpbnN0YW50aWF0aW9uIG9mIHRoZSBkZWZpbmVkIFNGQy4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gVGhlIFNGQyBhcmNoaXRl Y3R1cmUgc3VwcG9ydHMgcmVjbGFzc2lmaWNhdGlvbiAob3INCj4gPj4gID4+ID4+bm9uLWluaXRp YWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24pIGFzIHdlbGwuIEFz IHBhY2tldHMgdHJhdmVyc2UgYW4NCj4gPj5TRlAsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ IHJlY2xhc3NpZmljYXRpb24gbWF5IG9jY3VyIC0gdHlwaWNhbGx5IHBlcmZvcm1lZA0KPiA+PmJ5 IGENCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gY2xhc3NpZmljYXRpb24gZnVuY3Rpb24gY28t cmVzaWRlbnQgd2l0aCBhIHNlcnZpY2UNCj4gPj4gID4+ID4+ZnVuY3Rpb24uDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+IFJlY2xhc3NpZmljYXRpb24gbWF5IHJlc3VsdCBpbiB0aGUgc2VsZWN0 aW9uIG9mIGENCj4gPj5uZXcNCj4gPj4gID4+ID4+U0ZQLCBhbg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+PiB1cGRhdGUgb2YgdGhlIGFzc29jaWF0ZWQgbWV0YWRhdGEsIG9yIGJvdGguIFRoaXMg aXMNCj4gPj4gID4+ID4+cmVmZXJyZWQNCj4gPj4gID4+ID4+ID4+PnRvDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+IGFzICJicmFuY2hpbmciLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4NCj4gPj4gID4+ID4+ID4+Pg0K PiA+PiAgPj4gPj4NCj4gPj4gID4+DQo+ID4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+ID4+Pj4+Pj4+ Pj4+Pi0tLQ0KPiA+PiAgPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+ID4+ICA+PiA+PiA+Pj4gPj4+Pj4+ Pi0tDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+PiAqRnJvbTogKkkuU21pdGhARjUuY29tDQo+ID4+IDxtYWlsdG86 KkkuU21pdGhARjUuY29tPjxJLlNtaXRoQEY1LmNvbSA8bWFpbHRvOkkuU21pdGhARjUuY29tPj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiAqVG86ICpKb2VsIEhhbHBlcm4NCj4gPj4gID4+IERp cmVjdDxqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRvOmptaC5kaXJlY3RA am9lbGhhbHBlcm4uY29tPj4sSm9lbA0KPiA+PiAgPj4gPj4gTS4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ DQo+ID4+ICA+PiA+Pj4+PkhhbHBlcm48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20+PixodWFuZ0BzY2UuY2FybGV0b24uY2ENCj4gPj4gPG1haWx0 bzpodWFuZ0BzY2UuY2FybGV0b24uY2E+PGh1YW5nQHNjZS4NCj4gPj4gPG1haWx0bzpodWFuZ0Bz Y2UuJTBiPj4+ID4+ID4+PiA+PiBjYXJsZXRvbi4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PmNh PixzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+PHNmY0BpZXRmLm9yZw0KPiA+PiA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+ICpTZW50OiAqVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiAqU3ViamVjdDogKlJlOiBbc2ZjXSBTZXJ2aWNlIENoYWlucywgUGF0aHMsIGFu ZCBMb2FkDQo+ID4+ICA+PiA+PkJhbGFuY2Vycw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQWN0dWFsbHksIEkgdGhpbmsgSSBhbSBkaXNhZ3JlZWlu Zy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElm IHRoZSBwb3NzaWJpbGl0eSBvZiBtZWRpdW0tc2NhbGUgZGVwbG95bWVudHMgKGFuZA0KPiA+PiAg Pj50aGF0IGlzDQo+ID4+ICA+PiA+PiA+Pj53aGF0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g MTYgbWlsbGlvbiBmbG93cyBpcyBpbiBteSB3b3JsZCkgb2Ygc2VydmljZSBjaGFpbnMNCj4gPj5p cw0KPiA+PiAgPj4gPj4gPj4+cHJlY29uY2VpdmVkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4g YXMgYW4gYWJzdXJkIGlkZWEsIHRoZW4gdGhlIGFyY2hpdGVjdHVyZSBidXJkZW5lZA0KPiA+Pndp dGgNCj4gPj4gID4+IHRoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwcmVjb25jZXB0aW9u Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gVGhl cmUgaGFzIHRvIGJlIHNvbWUgcG9pbnQgb2YgYWltLCBzb21lIGRlZ3JlZSBvZg0KPiA+PiAgPj4g Pj5hc3BpcmF0aW9uDQo+ID4+ICA+PiA+PiB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNj YWxlIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBsaWZlc3BhbiBvZiB0aGUNCj4gPj4gID4+ ID4+YXJjaGl0ZWN0dXJlDQo+ID4+ICA+PiA+PiA+Pj4tDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4geW91IGRvbid0IGhhdmUgdG8ga25vdyB3aGF0IGl0IGlzLCBidXQgYnkgc2F5aW5nDQo+ID4+ dGhhdCBhbg0KPiA+PiAgPj4gPj4gPj4+YXJiaXRyYXJ5DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gbnVtYmVyIGlzICJ0b28gZmFyIiwgeW91J3JlIGNyZWF0aW5nIC0gZXZlbiBpZiBpdA0KPiA+ Pmlzbid0DQo+ID4+ICA+PiA+PiA+Pj4gPj5pbnRlbnRpb25hbA0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IC0gYSBsaW1pdCB0aGF0IGluZmx1ZW5jZXMgZGVjaXNpb25zIHRoYXQgaGF2ZQ0KPiA+ Pmxhc3RpbmcNCj4gPj4gID4+ID4+aW1wYWN0cw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHJl Z2FyZGluZyBzY2FsZS1vdXQsIGZhaWx1cmUgbWl0aWdhdGlvbiwgZWxhc3RpY2l0eSwNCj4gPj4g ID4+ID4+YWRkcmVzcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHNwYWNlLi4uIGFsbCBraW5k cyBvZiB0aGluZ3MuIFRoYXQgaXMgYSBwcm9ibGVtIEknbQ0KPiA+Pm5vdA0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+IHBhcnRpY3VsYXJseSBlYWdlciB0byBkZWFsIHdpdGguDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+IEZyb206IEpvZWwgSGFscGVybiBEaXJlY3QNCj4gPj4gW2ptaC5kaXJlY3RAam9l bGhhbHBlcm4uY29tIDxtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20+XQ0KPiA+PiAg Pj4gPj5TZW50Og0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IFRodXJzZGF5LCBKdWx5IDEwLCAy MDE0IDU6MDQgUE0gVG86IElhbiBTbWl0aDsgSm9lbA0KPiA+Pk0uDQo+ID4+ICA+PiA+PiBIYWxw ZXJuOw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IGh1YW5nQHNjZS5jYXJsZXRvbi5jYQ0KPiA+ PiA8bWFpbHRvOmh1YW5nQHNjZS5jYXJsZXRvbi5jYT47IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFtzZmNdDQo+ID4+ICA+PiA+PlNlcnZpY2UN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBDaGFpbnMsIFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNl cnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IElh biwgSSBkb24ndCB0aGluayB5b3UgZGlzYWdyZWUgd2l0aCBtZSBhdCBhbGwgaW4NCj4gPj50aGlz DQo+ID4+ICA+PiA+PnJlZ2FyZC4NCj4gPj4gID4+ID4+ID4+PkkNCj4gPj4gID4+ID4+ID4+PiA+ PmFtDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbm90IHJlcXVlc3RpbmcgdGhlIHRoZSBhcmNo aXRlY3R1cmUgb3IgdGhlIHNvbHV0aW9uDQo+ID4+ICA+PiA+PnByb2hpYml0DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZGVwbG95bWVudHMgaW4gdGhlIHNwZWNpZmljIGZhc2hpb24uIEkgYW0g b2JqZWN0aW5nDQo+ID4+dG8NCj4gPj4gID4+ID4+SHVhbmcncw0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IHJlYWRpbmcgb2YgbXkgbm90ZSBhcyBzYXlpbmcgdGhhdCBzdWNoIGRlcGxveW1lbnRz DQo+ID4+YXJlDQo+ID4+ICA+PiA+PiByZXF1aXJlZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IHRoZXkgYnkgdGhlIGFyY2h0aWVjdHVyZS4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IEFzIEkgaGF2ZSBzYWlkIHJlcGVhdGVkbHksIEkgYW0gbm90 IHRyeWluZyB0bw0KPiA+PnByb2hpYml0DQo+ID4+ICA+PnN1Y2gNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiB0aGluZ3MuIFdoZXRoZXIgdGhleSBhcmUgYSBnb29kIGlkZWEgb3Igbm90DQo+IGRl cGVuZHMNCj4gPj51cG9uDQo+ID4+ICA+PiA+PiBtYW55DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4gZmFjdG9ycyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUgV0cuIEkgaGFwcGVuIHRvDQo+ ID4+ICA+PnRoaW5rDQo+ID4+ICA+PiA+PnRoYXQNCj4gPj4gID4+ID4+ID4+PiA+PnRoZXkNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhcmUgdXN1YWxseSBhIGJhZCBpZGVhLg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQnV0IHRoZSBhcmNodGll Y3R1cmUgc2kgY2FyZWZ1bGx5IGF2b2lkaW5nDQo+ID4+YXR0ZW1wdGluZyB0bw0KPiA+PiAgPj4g Pj5rbm93DQo+ID4+ICA+PiA+PiA+Pj53aGF0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gaXMg YW5kIGlzIG5vdCBlcGxveWFibGUuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+PiBZb3VycywgSm9lbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gT24gNy8xMC8xNCwgNTowMSBQTSwgSWFuIFNtaXRoIHdy b3RlOg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJIGRpc2FncmVlLg0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBXZSByb3V0aW5lbHkgaGF2 ZSBzdGF0ZWZ1bCBkZXZpY2VzIHRoYXQgbWFuYWdlDQo+ID4+dGVucyBvZg0KPiA+PiAgPj4gPj4g Pj4+bWlsbGlvbnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gb2YNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBjb25jdXJyZW50IGZsb3dzIGluIGJvdGggYWNjZXNzIG5ldHdvcmsgYW5kIGRh dGENCj4gPj5jZW50ZXINCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBlbnZpcm9ubWVudHMgdG9k YXkuIFlvdSBjYW4ndCBzZXJpb3VzbHkgYmVsaWV2ZQ0KPiA+PnRoYXQgaW4NCj4gPj4gID4+dGhl DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gQ2xvdWQvSVB2Ni9Nb2JpbGl0eS9XZWIyLjAvSW9U IHdvcmxkIG9mIHRvbW9ycm93DQo+IHlvdQ0KPiA+PiAgPj4gYXJlDQo+ID4+ICA+PiA+PiBvbmx5 DQo+ID4+ICA+PiA+PiA+Pj4gPj4gZ29pbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0byBo YXZlIHNtYWxsIG51bWJlcnMgb2Ygc2VydmljZSBjaGFpbnMgd2l0aCBlcXVhbGx5DQo+ID4+ICA+ PnNtYWxsDQo+ID4+ICA+PiA+PiA+Pj4gbnVtYmVycw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ IG9mIGFjdGl2ZSBzZXJ2aWNlIHBhdGhzPw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBZb3VyIHNvdW5kcyB0b28gbXVjaCBsaWtlICJubyBvbmUg d2lsbCBldmVyIG5lZWQNCj4gPj5tb3JlDQo+ID4+ICA+PiB0aGFuDQo+ID4+ICA+PiA+PiA+Pj4g NjRLIg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBmb3INCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBjb21mb3J0Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IHNmYw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+PiBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZz5dIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBbam1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ XQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAx NCA0OjQ2IFBNIFRvOg0KPiA+PiAgPj4gPj4gPj4+aHVhbmdAc2NlLmNhcmxldG9uLmNhIDxtYWls dG86aHVhbmdAc2NlLmNhcmxldG9uLmNhPjsNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gc2Zj QGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPiBTdWJqZWN0OiBSZToNCj4gPj4gW3NmY10g U2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPiA+PiAgPj5hbmQNCj4gPj4gID4+ID4+ID4+PkxvYWQN Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gQmFsYW5jZXJzDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+IE5vLCBpdCB3aWxsIG1lYW4gdGhhdCBp ZiBzb21lb25lIHRyaWVzIHRvIGRlcGxveQ0KPiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+YXJjaHRp ZXR1cmUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gcGFydGljdWxhcmx5IGJhZGx5LCB0aGV5 IHdpbGwgZXhjZWVkIHRoZSBsaW1pdHMgb2YNCj4gPj4gID4+dGhlaXINCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4gZGV2aWNlcy4gVGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIHN1 Y2gNCj4gPj5hYnN1cmQNCj4gPj4gID4+IHVzZQ0KPiA+PiAgPj4gPj4gb2YNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gc2VydmljZSBwYXRocy4gU2luY2UgSSBjYW4gbm90IGZpZ3VyZSBvdXQg aG93IHRvDQo+ID4+d3JpdGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4gYXJjaGl0ZWN0dXJh bCB3b3JkcyB0byBwcm9oaWJpdCBpdCwgdGhlDQo+ID4+YXJjaGl0ZWN0dXJlDQo+ID4+ICA+PmRv ZXMNCj4gPj4gID4+ID4+ID4+PnBlcm1pdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzdWNo IGFidXNlLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+PiBQbGVhc2UgZG8gbm90IHJlYWQgbXkgc2F5aW5nIHRoYXQgdGhlIGFyY2h0aWVjdHVyZQ0K PiA+PiAgPj4gcGVybWl0cw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBzb21ldGhpbmcgYXMg c2F5aW5nIGl0IGlzIGVpdGhlciBkZWlzcmVkIG9yDQo+ID4+cmVxdWlyZWQgYnkNCj4gPj4gID4+ ID4+dGhlDQo+ID4+ICA+PiA+PiA+Pj53b3JrLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBJ dCBpc24ndC4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4gWW91cnMsIEpvZWwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4gT24gNy8xMC8xNCwgNDozNiBQTSwgQ2hhbmdjaGVuZyBIdWFuZyB3cm90 ZToNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+IElmIHlvdSBuZWVkIHRvIHN1cHBvcnQgMTAw IHNlcnZpY2UgY2hhaW5zLCBpdCB3aWxsDQo+ID4+ICA+Pm1lYW4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+IDE2LDAwMCwwMDAgcGF0aHMuIFRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHJvdXRp bmcNCj4gPj4gID4+dGFibGUNCj4gPj4gID4+ID4+b2YgYQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4gY29yZSByb3V0ZXIuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4gQ2hhbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBPbiAwNy8xMC8yMDE0IDAxOjE1IFBNLCBKb2VsIE0uIEhh bHBlcm4gd3JvdGU6DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gVGhlIGFyY2hpdGVjdHVy ZSBhbGxvd3MgYSByYW5nZSBvZiBkZXBsb3ltZW50cywNCj4gPj5mcm9tDQo+ID4+ICA+PjENCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggdG8gMTYwMDAwIHNlcnZpY2Ug cGF0aHMuIEkgd291bGQNCj4gPj5ob3BlDQo+ID4+ICA+PnRoYXQNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+PiBvcGVyYXRvcnMgYXJlIHByZXBhcmVkIGZvciB0aGUgY29tcGxleGl0aWVzIGlm DQo+ID4+dGhleQ0KPiA+PiAgPj4gPj5jaG9vc2UNCj4gPj4gID4+ID4+ID4+PnRvDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gYXZvaWQgYW55IHVzZSBvZiBsb2NhbCBsb2FkIGJhbGFuY2lu ZyBhbmQgaW4NCj4gPj5zdGVhZA0KPiA+PiAgPj4gPj4gcHJvdmlzaW9uDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4gMTYwLDAwMCBzZXJ2aWNlIHBhdGhzLg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4gWW91cnMsIEpvZWwNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+IE9uIDcv MTAvMTQsIDQ6MDYgUE0sIE5BUElFUkFMQSwgTUFSSUEgSA0KPiB3cm90ZToNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gUGF1bCwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gSG93IG1hbnkgcGF0aCBpZGVudGlmaWVycyB0aGVy ZSB3aWxsIGJlIGZvciBhIDQNCj4gPj5ob3ANCj4gPj4gID4+ID4+IHNlcnZpY2UNCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4gd2l0aCAyMCBpbnN0YW5jZXMgYXQgZWFjaCBob3A/ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE1hcmlhDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9u DQo+ID4+QmVoYWxmDQo+ID4+ICA+PiBPZg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiAq UGF1bCBRdWlubiAocGF1bHEpICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTAsDQo+ID4+MjAxNA0K PiA+PiAgPj4gPj4zOjAzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBNICpUbzoqIEx1 Y3kgeW9uZyAqQ2M6Kg0KPiBqbWhAam9lbGhhbHBlcm4uY29tDQo+ID4+IDxtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbT47DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPjsgc2ZjQGlldGYub3JnDQo+ID4+PG1haWx0bzpzZmNAaWV0Zi5vcmc+Ow0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiBtaWtlYmlhbmNAYW9sLmNvbQ0KPiA8bWFpbHRvOm1pa2ViaWFu Y0Bhb2wuY29tPg0KPiA+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTZXJ2aWNlDQo+ID4+ICA+PiBD aGFpbnMsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxh bmNlcnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gTHVjeSwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gT3ZlcmFsbCBJIGNvbmN1ciwgYXMgeW91IHNheTogYSBwYXRoIElE IGRyaXZlcw0KPiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5n LiBJwrlkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gbWFrZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiB0aGUgbWlub3IgY2hhbmdlOiB0aGUgcGF0aCBpZGVudGlmaWVyIGNhbiBiZQ0K PiA+PnVzZWQgdG8NCj4gPj4gID4+ID4+IGRlcml2ZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0aGUgbmVlZGVkIGZvcndhcmRpbmcgYW5kIGFzc29jaWF0ZWQNCj4gdHJhbnNwb3J0Lg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBJdCBpcyBfbm90XyB0aGUgdHJhbnNwb3J0LCBidXQgcmF0aGVyIGlzIHVzZWQgdG8NCj4gPj4g ID4+c2ltcGx5DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlkZW50aWZ5IHRoZSBzZXJ2 aWNlIHBhdGggKG9yIGdyYXBoKSB0aGF0DQo+ID4+cGFja2V0cw0KPiA+PiAgPj5tdXN0DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRyYXZlcnNlLiBCeSBoYXZpbmcgYSBwYXRoIGlkZW50 aWZpZXIsIHRoZSBleGFjdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBpbmRpcmVjdGlv biB0aGF0IHBlb3BsZSBzZWVtIHRvIGJlIGFza2luZyBmb3INCj4gb24NCj4gPj4gID4+dGhpcw0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aHJlYWQgY2FuIGJlIHNpbXBseSBiZSBpbXBs ZW1lbnRlZC4gVGhlDQo+IHBhdGgNCj4gPj4gID4+ID4+IGlkZW50aWZpZXINCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gcHJvdmlkZXMgbm90aGluZyBtb3JlIHRoYW4gYSBsb29rdXAsIHRo YXQNCj4gPj5sb29rdXAgY2FuDQo+ID4+ICA+PiA+PiByZXN1bHQNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4gaW4gYSBvbmUgb3IgbW9yZSAoZXF1YWwgb3Igd2VpZ2h0ZWQpIHRyYW5zcG9y dA0KPiA+Pm5leHQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaG9wKHMpLg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBQYXVs DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IE9uIEp1bCAxMCwgMjAxNCwgYXQgMTE6MDQgQU0sIEx1Y3kgeW9uZw0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiA8bHVjeS55b25nQGh1YXdlaS5jb20NCj4gPj48bWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPg0KPiA+PiAgPj4gPj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNv bT4NCj4gPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSUzZT4+DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBBZ3JlZS4gVGhlIGFyY2guIGRvYyBzaG91bGQgbm90 IG1hbmRhdGUgb25seQ0KPiA+PnVzZSBvZg0KPiA+PiAgPj4gdGhlDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIHRvIGRyaXZlIHRoZSBmb3J3YXJk aW5nDQo+ID4+ICA+PiA+PmFjdGlvbnMuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEx1Y3kNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSpPbg0KPiA+PkJlaGFsZg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBPZiptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4+IDxtYWlsdG86T2Yq bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiA+PiAgPj4gPj4gPj4+ ICpTZW50OipUaHVyc2RheSwNCj4gPj4gID4+ID4+ID4+PiA+PiBKdWx5DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IDEwLCAyMDE0IDI6MDYgQU0gKlRvOiptaWtlYmlhbmNAYW9sLmNvbQ0K PiA+PiA8bWFpbHRvOiptaWtlYmlhbmNAYW9sLmNvbT4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPG1haWx0bzptaWtlYmlhbmNAYW9sLmNvbT47am1oQGpvZWxoYWxwZXJuLmNvbQ0K PiA+PiA8bWFpbHRvOm1pa2ViaWFuY0Bhb2wuY29tJTNlO2ptaEBqb2VsaGFscGVybi5jb20+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT47 c2ZjQGlldGYub3JnDQo+ID4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUzZTtzZmNAaWV0 Zi5vcmc+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3Jn PiAqU3ViamVjdDoqUmU6IFtzZmNdDQo+ID4+U2VydmljZQ0KPiA+PiAgPj4gPj5DaGFpbnMsDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFBhdGhzLCBhbmQgTG9hZCBCYWxhbmNlcnMNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g UmUtLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+Pj4+PiBUaGUgbWVyZ2VkIGRyYWZ0IGNhbGxzIG91dCBleHBsaWNpdGx5IGEgc2VydmljZQ0K PiA+PnBhdGgNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaWRlbnRpZmllci4gSSBvYmpl Y3QgdG8gdXNlIHRoYXQgaWRlbnRpZmllciB0bw0KPiA+PiAgPj5kZXJpdmUNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rpb25zLg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBSZXF1aXJpbmcgYSBTRkMg c3lzdGVtIHRvIGhhdmUgdGhlIGZ1bGwNCj4gPj5rbm93bGVkZ2Ugb2YNCj4gPj4gID4+ID4+IGV2 ZXJ5DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gYXZhaWxhYmxlIFNGQw0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBmb3J3YXJkaW5nIHBhdGhzIHdpdGhpbiBhbiBTRkMtZW5hYmxlZA0K PiBkb21haW4NCj4gPj5pcyBub3QNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiByZXF1aXJlZC9q dXN0aWZpZWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbm9yIHBvc3NpYmxlIGluIHZh cmlvdXMgZGVwbG95bWVudCBjb250ZXh0cy4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gU0ZDIGZvcndhcmRpbmcgYWN0aW9ucyBzaG91 bGQgcmVseSBvbiB0aGUgcGllY2UNCj4gPj5vZg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBpbmZvcm1hdGlvbg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHRoYXQgd2lsbA0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZSBwcmVzZW50IGluIGFsbCBkZXBsb3ltZW50czogdGhh dCBpcyB0aGUgb25lDQo+ID4+ICA+PiByZXF1aXJlZA0KPiA+PiAgPj4gPj4gdG8NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3RydWN0dXJlIGEgc2VydmljZSBjaGFpbi4gSG93IHRoYXQg aW5mb3JtYXRpb24NCj4gPj5pcw0KPiA+PiAgPj4gPj51c2VkIHRvDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGluZmVyIGZvcndhcmRpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBh Y3Rpb25zDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGEgc29sdXRpb24tb3JpZW50 ZWQgZGlzY3Vzc2lvbi4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBNZWQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKkRlIDoqc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddKkRlIGxhDQo+ID4+cGFydA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IGRlKm1pa2ViaWFuY0Bhb2wuY29tDQo+IDxtYWlsdG86ZGUqbWlrZWJpYW5jQGFvbC5jb20+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86bWlrZWJpYW5jQGFvbC5jb20+ ICpFbnZvecOpDQo+IDoqbWVyY3JlZGkgOQ0KPiA+PiAgPj4gPj4ganVpbGxldA0KPiA+PiAgPj4g Pj4gPj4+ID4+ID4+Pj4+Pj4+PiAyMDE0IDIyOjAzICrDgCA6KmptaEBqb2VsaGFscGVybi5jb20N Cj4gPj4gPG1haWx0bzoqam1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPjtzZmNAaWV0Zi5vcmcNCj4gPj4g PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTNlO3NmY0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ICpPYmpldCA6KlJlOiBbc2Zj XSBTZXJ2aWNlDQo+ID4+ICA+PiA+PkNoYWlucywNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gUGF0aHMsIGFuZCBMb2FkIEJhbGFuY2Vycw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJcyBhbnlvbmUgc3RpbGwgcXVlc3Rpb25p bmcgdGhlIGRpZmZlcmVuY2UNCj4gPj5iZXR3ZWVuDQo+ID4+ICA+PlNGDQo+ID4+ICA+PiA+PiBD aGFpbg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhbmQgU0YNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBQYXRoPw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBPdGhlciB0aGFu IGNsYXJpZnlpbmcgdGhlIGRlZmluaXRpb24gc28gdGhhdA0KPiA+Pml0J3MNCj4gPj4gID4+ID4+ Y2xlYXIgdG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aG9zZSBub3QNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQsIGl0IHNlZW1zIHRoYXQg ZXZlcnlvbmUNCj4gPj4gID4+YWdyZWVzDQo+ID4+ICA+PiA+Pm9uDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoZXNlIHRlcm1zLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUbyBtZSwgdGhlIG9uZSBwb2ludCB0aGF0IGlz IHN0aWxsIHVuY2xlYXIgaXMNCj4gPj4gID4+d2hldGhlcg0KPiA+PiAgPj4gPj5pdCBpcw0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGUgaW50ZW50IG9mIHRoaXMgZHJhZnQgdG8gdWx0 aW1hdGVseSBzcGVjaWZ5DQo+ID4+d2hhdA0KPiA+PiAgPj4gPj50aGUgSUQNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gb2YgdGhlIFNGQyBIZWFkZXINCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+PiBzaG91bGQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gcmVmZXJlbmNlICh0aGUg Y2hhaW4gb3IgdGhlIHBhdGgpLCBvciBpZiB0aGlzDQo+ID4+ZHJhZnQNCj4gPj4gID4+ID4+c2lt cGx5DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGludGVuZHMgdG8gbGVhdmUgdGhhdCBh bWJpZ3VvdXMsIGFsbG93aW5nDQo+IG90aGVyDQo+ID4+ICA+PmRyYWZ0cw0KPiA+PiAgPj4gPj50 bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaWN0YXRlIHRoZSBtZWNoYW5pc21zIGZv ciBmb3J3YXJkaW5nIGJhc2VkDQo+IG9uDQo+ID4+Y2hhaW4NCj4gPj4gID4+IG9yDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhdGggYW5kIHRoZSBjaG9pY2Ugb2YgY2hhaW4gb3INCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBwYXRoIHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IGJlIG5lZ290aWF0ZWQgaW4gdGhlIGNvbnRyb2wtcGxhbmUuDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IElmIHRoZSBsYXR0ZXIg KGFtYmlndW91cyksIHRoZW4gdGhlIGRyYWZ0IHdvdWxkDQo+ID4+aGF2ZQ0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiByZXF1aXJlIHRoYXQgYm90aCBTRlAgYW5kIFNGQyBiZSBzdXBwb3J0 ZWQgKG9yDQo+ID4+bWFrZQ0KPiA+PiAgPj4gPj4gb25lDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHJlcXVpcmVkIGFuZCB0aGUgb3RoZXIgb3B0aW9uYWwpIHRvIGF2b2lkIHNvbWUNCj4g Pj4gID4+IHZlbmRvcnMNCj4gPj4gID4+ID4+IG9ubHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gc3VwcG9ydGluZyBTRlAgYW5kIG90aGVycyBvbmx5IHN1cHBvcnRpbmcgU0ZDLg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4NCj4gPj4gID4+ID4+ ID4+Pg0KPiA+PiAgPj4gPj4NCj4gPj4gID4+DQo+ID4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+Pj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+Pj4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+Pj4+Pj4+Pj4+Pj4+LS0NCj4gPj4gID4+ID4+ Pj4+Pj4+Pj4+Pi0tLQ0KPiA+PiAgPj4gPj4gPj4+Pj4+Pj4+Pi0tDQo+ID4+ICA+PiA+PiA+Pj4g Pj4+Pj4+Pi0tDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4tLQ0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gKkZyb206KmptaEBqb2VsaGFscGVybi5jb20NCj4gPj4gPG1haWx0bzoqam1oQGpvZWxoYWxw ZXJuLmNvbT48am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiA+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tPg0KPiA+PiA8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lM2NqbWhAam9lbGhhbHBlcm4uY29tJTNlPj4NCj4gPj4gID4+ ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gKlRvOipzZmNAaWV0Zi5vcmcNCj4gPj4gPG1haWx0bzoqc2Zj QGlldGYub3JnPjxzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnJTNjc2ZjQGlldGYub3JnPg0K PiA+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZyUzY3NmY0BpZXRmLm9yZyUzZT4+DQo+ID4+ICA+PiAq U2VudDoqVHVlc2RheSwNCj4gPj4gID4+ID4+IEp1bHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ Pj4+Pj4gOCwgMjAxNCAqU3ViamVjdDoqW3NmY10gU2VydmljZSBDaGFpbnMsIFBhdGhzLA0KPiA+ PmFuZA0KPiA+PiAgPj5Mb2FkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEJhbGFuY2Vy cw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBJIGhhdmUgYmVlbiB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gY2xlYXJseQ0KPiA+ PiAgPj5hbnN3ZXINCj4gPj4gID4+ID4+YQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBu dW1iZXIgb2YgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gbWFkZQ0KPiBhYm91dCB0aGUNCj4gPj4g ID4+ID4+ID4+PiBwcm9wb3NlZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtZXJnZWQg YXJjaHRpZWN0dXJlIGRyYWZ0LiBBc3N1bWluZyB3ZSBjYW4gZ2V0DQo+ID4+ICA+PiB3b3JraW5n DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdyb3VwIGFncmVlbWVudCBvbiB0aGUgaW50 ZW50LCB3ZSB3aWxsIHdvcmsgdG8NCj4gPj4gID4+IGltcHJvdmUNCj4gPj4gID4+ID4+IHRoZQ0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3b3JkaW5nIHNvIHRoYXQgcmVhZGVycyB3aG8g aGF2ZSBub3QNCj4gPj5wYXJ0aWNpcGF0ZWQgaW4NCj4gPj4gID4+ID4+dGhlDQo+ID4+ICA+PiA+ PiBXRw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkaXNjdXNzaW9uIHdpbGwgdW5kZXJz dG5kIGl0IHRoZSB3YXkgdGhlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gd29ya2luZw0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBncm91cCBpbnRlbmRzLg0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBCdXQgd2hhdCBkbyB3 ZSBpbnRlbmQ/IEkgd2lsbCB0cnkgdG8gZXhwbGFpbiBteQ0KPiA+PiAgPj4gPj5wZXJzb25hbA0K PiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB2aWV3LCBhbmQgc2VlIGlmIHRoYXQgaGVscHMu DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IEluIHRoaXMgcmVnYXJkLCBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kDQo+ID4+ dGhhdA0KPiA+PiAgPj4gPj53aGF0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHdlIGFy ZSBkZWZpbmluZyBpcyB0aGUgZGF0YSBwbGFuZSBhcmNoaXRlY3R1cmUuDQo+ID4+V2UNCj4gPj4g ID4+YXJlDQo+ID4+ICA+PiA+PiBub3QNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gYXR0 ZW1wdGluZyB0byBkZWZpbmUgdGhlIGFyY2hpdGVjdHVyZSBmb3IgdGhlDQo+ID4+ZW50aXJlDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNvbHV0aW9uIGZvciBzZXJ2aWNlIGNoYWluaW5n LiBUaGF0IHdvdWxkDQo+ID4+ZW5jb21wYXNzDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IE9TUy9CU1MsIHZhcmlvdXMgY29udHJvbCBhbmQgcG9saWN5IGZ1bmN0aW9ucywNCj4gPj4gID4+ dmlydHVhbA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBtYWNoaW5lIGFuZCBpbWFnZSBt YW5hZ2VtZW50LCBhbmQgbWFueQ0KPiBvdGhlcg0KPiA+PiAgPj4gPj4gYXNwZWN0cy4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gQXMg YSByZXN1bHQgdGhlcmUgYXJlIG1hbnkgdGhpbmdzIHdoaWNoIGNsZWFybHkNCj4gPj5uZWVkDQo+ ID4+ICA+PiB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbGFy Z2VyIHN5c3RlbSwgYnV0IHdoaWNoIGFyZSBkZWFsdA0KPiA+PndpdGgNCj4gPj4gID4+ID4+YWJv dmUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gd2hlcmUgd2UgYXJlDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4gZnVuY3Rpb25pbmcsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGFuZCBhcmUgbm90IGRpcmVjdGx5IHJlcXVpcmVkIGJ5IHRoZSB3b3JrIHdlDQo+IGFyZQ0KPiA+ PiAgPj4gZG9pbmcuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IEluIG9yZGVyIHRvIGdldCB0byBzZXJ2aWNlIGNoYWluIHZzIHNlcnZp Y2UNCj4gPj5wYXRoLA0KPiA+PiAgPj5hcyBJDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IHVuZGVyc3RhbmQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiB0aGVtLA0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBJIG5lZWQgdG8gZmlyc3QgZGlzY3VzcyBsb2FkIGJhbGFuY2luZy4g VGhlcmUNCj4gPj5hcmUgYXQNCj4gPj4gID4+ID4+bGVhc3QNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGhyZWUgZGlmZmVyZW50IHdheXMgdGhhdCBsb2FkIGJhbGFuY2luZyBjYW4NCj4g YW5kDQo+ID4+ICA+PndpbGwNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW50ZXJhY3Qg d2l0aCBzZXJ2aWNlIGNoYWluaW5nLiBUaGVyZSBwcm9iYWJseQ0KPiA+PmFyZQ0KPiA+PiAgPj4g Pj5tb3JlLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGUgcG9pbnQgb2YgdGhlIGFy Y2h0aWVjdHVyZSBpcyB0byBwZXJtaXQgYWxsDQo+ID4+b2YNCj4gPj4gID4+ID4+dGhlc2UsDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGJ1dCBub3QgdG8gbWFuZGF0ZSB0aGF0IGFueSBw YXJ0aWN1bGFyIGtpbmQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBiZSB1c2VkDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluIGFueSBzb2x1dGlvbi4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gMSkgTG9hZCBiYWxhbmNp bmcgYXMgYSBzZXJ2aWNlIHByb3ZpZGVkIHRvIHRoZQ0KPiA+PmVuZA0KPiA+PiAgPj4gPj51c2Vy Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBUaGlzIGlzIGEgc2VydmljZSBmdW5jdGlv bi4gSXQgcmVjZWl2ZXMgdXNlcg0KPiA+PiAgPj5wYWNrZXRzLA0KPiA+PiAgPj4gPj5hbmQNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gbW9kaWZpZXMgdGhlbSAob3INCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+PiBtYXJrcw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVtLCBv ciAuLi4pIHNvIGFzIHRvIGNob29zZSBhbiBlbmQgdXNlcg0KPiA+PnNlcnZpY2UNCj4gPj4gID4+ ID4+aW5zdGFuY2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gcmVjZWl2ZSB0aGUg dXNlcnMgcGFja2V0LiBUaGlzIGlzIGFuDQo+ID4+aW1wb3J0YW50DQo+ID4+ICA+PiA+PnNlcnZp Y2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gZnVuY3Rpb24gdG8gYmUgYWJsZSB0byBp bmNsdWRlIGluIHNlcnZpY2UNCj4gPj5jaGFpbmluZy4NCj4gPj4gID4+ID4+SXQncw0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBiZWhhdmlvciBtYXkgYWZmZWN0IHJlcXVpcmVtZW50cyBv biBob3cNCj4gc2VydmljZQ0KPiA+PiAgPj4gPj4gY2hhaW5pbmcgaXMNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gZG9uZS4gQnV0IGl0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gdGhl DQo+ID4+ICA+PiA+PmFyY2h0aWVjdHVyZS4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4g RnJvbSBhbiBhcmNoaXRlY3R1cmFsIHBlM3JzcGVjdGl2ZSBpdCBpcyBzaW1wbHkNCj4gPj5hDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gc2VydmljZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiBmdW5jdGlvbiB3aGljaCBtYXkgbW9kaWZ5IHRoZSB1bmRlcmx5aW5nDQo+IHBhY2tldC4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gMikgVGhlcmUgaXMgaW50ZXJuYWwgbG9hZCBiYWxhbmNpbmcuIFRoYXQgaXMsDQo+ID4+b25l DQo+ID4+ICA+PmNhbg0KPiA+PiAgPj4gPj5oYXZlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHdoYXQNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBhcHBlYXJzDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IHRvIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGFyY2hpdGVjdHVyZSBhcyBh IHNpbmdsZQ0KPiA+PiAgPj5wb2ludA0KPiA+PiAgPj4gPj5vZg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBjb250YWN0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gZm9yIGENCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiwgYnV0IGlz IGFjdHVhbGx5DQo+ID4+ZGVsaXZlcmVkDQo+ID4+ICA+PiA+PmJ5IGENCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+PiBjb2xsZWN0aW9uIG9mDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHZp cnR1YWwgb3IgcGh5c2ljYWwgbWFjaGluZXMsIHBvc3NpYmx5IGluY2x1ZGluZw0KPiA+PiAgPj5v bmUgb3INCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gc2V2ZXJhbCBsb2FkIGJhbGFuY2Vy cyAoZm9yIGV4YW1wbGUgdXNpbmcNCj4gPj5WUlJQLWxpa2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdGVjaG5pcXVlcyB0byBzaGFyZSBhIE1BQyBhZGRyZXNzLikgbW9zdGx5LA0KPiA+ PnRoaXMgaXMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHRoZSBz ZXJ2aWNlIGNoYWluaW5nIGRhdGEgcGxhbmUNCj4gPj4gID4+ID4+bWVjaGFuaXNtcy4NCj4gPj4g ID4+ID4+IEl0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGlzIGxpa2VseSB0aGF0IGl0 IGlzIHZpc2libGUgdG8gdmFyaW91cyBjb250cm9sDQo+ID4+ICA+PiA+Pm1lY2hhbmlzbXMsDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHN1Y2ggYXMgdGhvc2UgcmVzcG9uc2libGUgZm9y IHNjYWxlLWluLA0KPiA+PnNjYWxlLW91dCwNCj4gPj4gID4+YW5kDQo+ID4+ICA+PiA+PnZtDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGluc3RhbnRpYXRpb24uIFRoZSBhcmNoaXRlY3R1 cmFsIGltcGFjdCBvZg0KPiA+PiAgPj5wZXJtaXR0aW5nDQo+ID4+ICA+PiA+PnRoaXMNCj4gPj4g ID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaXMgbGFyZ2VseSB0aGF0IHdlIG5lZWQgdG8gYmUgY2Fy ZWZ1bCB0aGF0IG91cg0KPiA+PiAgPj4gPj50ZXJtaW5vbG9neQ0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBkb2VzIG5vdCBsZWFkDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4gcmVhZGVy cyB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGluayB3ZSBhcmUgcHJvaGliaXRp bmcgaXQuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IDMpIFRoZXJlIGNhbiBhbHNvIGJlIGxvYWQgYmFsYW5jaW5nIGRvbmUgYnkNCj4g Pj4gID4+c2VsZWN0aW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHBhY2tldCBwYXRo cyBmb3IgdGhlIHNlcnZpY2UgY2hhaW5pbmcgdGhhdA0KPiA+PmRpcmVjdA0KPiA+PiAgPj4gPj50 cmFmZmljDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRvIGRpZmZlcmVudCBwbGFjZXMu IFdlIHdvdWxkIG5vdCB3YW50IHRvDQo+ID4+cmVxdWlyZQ0KPiA+PiAgPj4gdGhhdA0KPiA+PiAg Pj4gPj5hDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdpdmVuIHNlcnZpY2UgZnVuY3Rp b24gYXBwZWFyIGF0IG9ubHkgb25lIHBsYWNlDQo+ID4+aW4NCj4gPj4gID4+dGhlDQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG5ldHdvcmsuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IEl0IGlzIG9mIGNvdXJzZSB0aGUgY2Fz ZSB0aGF0IHRoZXNlIG1heSBiZQ0KPiA+PiAgPj5jb21iaW5lZC4gSQ0KPiA+PiAgPj4gPj4gdGVu ZA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+ Pj4+IHJlZmVyIHRvDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHRoZSBjb2xsZWN0aW9u IG9mIGVudGl0aWVzIHRoYXQgYXBwZWFyIHRvDQo+ID4+c2VydmljZQ0KPiA+PiAgPj4gPj5jaGFp bmluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhcyBhIHNpbmdsZSBwb2ludCBhcyBh IGNsdXN0ZXIuIE5vdCBiZWNhdXNlDQo+ID4+Y2x1c3Rlcg0KPiA+PiAgPj5pcw0KPiA+PiAgPj4g Pj5hDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGdvb2QgdGVybS4gQnV0IGJlY2F1c2Ug SSBkbyBub3QgaGF2ZSBhbm90aGVyDQo+ID4+b25lLg0KPiA+PiAgPj4gVGh1cywNCj4gPj4gID4+ ID4+IHRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBwb2ludCBvZiB0eXBlIDMgbG9h ZCBiYWxhbmNpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+PiBpcyB0bw0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4+Pj4+PiBkaXJlY3QgZGlmZmVyZW50IHN1YnNldHMgb2YgdHJhZmZpYyB0byBk aWZmZXJlbnQNCj4gPj4gID4+ID4+c2luZ3VsYXINCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gb3IgY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb25zIGluIGRpZmZlcmVudA0KPiA+PnBsYWNl cw0KPiA+PiAgPj5pbg0KPiA+PiAgPj4gPj50aGUNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+ Pj4gbmV0d29yay4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gTm93IHdpdGggdGhhdCBzYWlkLCB3aGF0IGRvIEkgbWVhbiB3aGVuIEkg dGFsaw0KPiA+PmFib3V0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHNlcnZpY2UgY2hh aW4gYW5kIHNlcnZpY2UgcGF0aC8gU2VydmljZSBjaGFpbg0KPiA+PmlzIGENCj4gPj4gID4+ID4+ IHNlcXVlbmNlDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG9mIGxvZ2ljYWwgZnVuY3Rp b25zIHRvIGJlIGFwcGxpZWQgdG8gYSBzdWJzZXQNCj4gPj5vZg0KPiA+PiAgPj4gPj5wYWNrZXRz Lg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBJdCBpcyBlcXVpdmFsZW50IG9mIHNheWlu ZyB0aGF0IHNvbWUgc3Vic2V0IG9mDQo+ID4+ICA+PnRyYWZmaWMNCj4gPj4gID4+ID4+aXMNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdG8gZ2V0IERQSSwgY2hhcmdpbmcsIGNvbnRlbnQg aW5zcGVjdGlvbiwgYW5kDQo+ID4+ICA+PmZpcmV3YWxsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+IHdoaWxlIGEgZGlmZmVyZW50IHN1YnNldCBpcyB0byBnbyBkaXJlY3RseSB0bw0KPiA+ PnRoZQ0KPiA+PiAgPj5jYWNoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+IHdpdGhvdXQNCj4g Pj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gdmlzaXRpbmcgYW55IG90aGVyIHNlcnZpY2UgZnVu Y3Rpb25zLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBUaGF0IGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gZGlyZWN0IHRoZQ0K PiA+PiAgPj5wYWNrZXRzLg0KPiA+PiAgPj4gQQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+ PiBzZXJ2aWNlIHBhdGggaXMsIGluIHNvbWUgZmFzaGlvbiwgYSBzZXF1ZW5jZSBvZg0KPiA+PiAg Pj4gPj5sb2NhdGlvbnMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW4gdGhlIG5ldHdv cmsuIFRob3NlIGxvY2F0aW9ucyB3aWxsIGJlDQo+ID4+c2luZ3VsYXIgb3INCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pj4gY2x1c3RlcmVkIHNlcnZpY2UgZnVuY3Rpb24gZGVsaXZlcnkgbG9j YXRpb25zLg0KPiA+PlRoZXkNCj4gPj4gID4+ID4+bWF5IGJlDQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzLiBUaGV5IG1heSBiZQ0KPiBhZGRyZXNz ZWQNCj4gPj5hcw0KPiA+PiAgPj4gcG9ydHMNCj4gPj4gID4+ID4+IG9uDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGFuIFNGRi4gVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IHdheXMgdGhh dCB0aGUNCj4gPj4gID4+ID4+bG9jYXRpb25zDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IG1heSBiZSBrbm93biB0byB0aGUgc2VydmljZSBjaGFpbmluZw0KPiA+PmluZnJhc3RydWN0dXJl DQo+ID4+ICA+PiBhbmQNCj4gPj4gID4+ID4+IHRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+ Pj4+PiB0cmFuc3BvcnQuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4+PiBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JrIG9m IHRoZSBTRkMNCj4gPj4gID4+Z3JvdXAsDQo+ID4+ICA+PiA+PiB3ZQ0KPiA+PiAgPj4gPj4gPj4+ ID4+ID4+Pj4+Pj4+Pj4gbmVlZCB0byBiZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBh YmxlIHRvIHRhbGsgYWJvdXQgdGhlIGhpZ2ggbGV2ZWwgYWJzdHJhY3Rpb24sDQo+ID4+dGhlDQo+ ID4+ICA+PiA+PnNlcnZpY2UNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gY2hhaW4sIHdo aWNoIGRyaXZlcyB0aGUgZm9yd2FyZGluZy4gQW5kIHdlDQo+IG5lZWQNCj4gPj50bw0KPiA+PiAg Pj4gdGFsaw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBhYm91dCB0aGUgYWN0dWFsIGRh dGEgcGF0aCBwYWNrZXRzIHdpbGwgdGFrZSBpbg0KPiA+PnRoZQ0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+Pj4+PiBuZXR3b3JrLg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBTZXZlcmFsIG9mIHRoZSBjb21tZW50cyBoYXZlIHNhaWQg ImJ1dCB0aGUNCj4gd2hvbGUNCj4gPj4gID4+IHBhdGgNCj4gPj4gID4+ID4+IG1heQ0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBub3QgYmUga25vd24gYXQgdGhlIGZyb250LiIgVGhpcyBh cmNoaXRlY3R1cmUNCj4gPj5kZWFscw0KPiA+PiAgPj4gPj53aXRoDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IHRoYXQgaXNzdWUgaW4gdHdvIHdheXMuIEZpcnN0LCBhcyBub3RlZCBpbiBp dGVtDQo+ID4+KDIpDQo+ID4+ICA+Pm9uDQo+ID4+ICA+PiA+PmxvYWQNCj4gPj4gID4+ID4+ID4+ PiA+PiA+Pj4+Pj4+Pj4gYmFsYW5jZXJzIGFib3ZlLCB0aGVyZSBjYW4gYmUgZGVjaXNpb25zIGFu ZA0KPiA+PiAgPj5iZWhhdmlvcnMNCj4gPj4gID4+ID4+IHdoaWNoDQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPj4+Pj4+Pj4+IGFyZSBpbnZpc2libGUgdG8gdGhlIHNlcnZpY2UgY2hhaW5pbmcNCj4gPj5t ZWNoYW5pc21zIChpbg0KPiA+PiAgPj4gPj5tdWNoDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ Pj4+IHRoZSBzYW1lIHdheSB0aGF0IGJyaWRnaW5nIHdpdGhpbiBhIExBTiBpcw0KPiA+Pmxhcmdl bHkNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gaW52aXNpYmxlIHRvIHJvdXRpbmcgYmV0 d2VlbiBMQU5zLikgVGhlIG90aGVyDQo+ID4+ICA+PiBwcm92aXNpb24NCj4gPj4gID4+ID4+IHdl DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IG1ha2UgaXMNCj4gPj4gID4+ID4+ID4+PiA+ PiA+Pj4+PiB0aGF0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRp b24gY2FuIGJlIGRvbmUgaW4gbWlkLWNoYWluIHdoZW4NCj4gPj4gID4+ID4+IG5lY2Vzc2FyeS4N Cj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pj4gVGhhdCB3aWxsIGRpcmVjdCBwYWNrZXRzIHRv IGEgbmV3IGNoYWluLiBCYXNlZA0KPiA+Pm9uDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+ IGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhdCB0aGUgcmUtY2xhc3NpZmljYXRpb24NCj4gPj4gID4+ cG9pbnQuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4g Pj4+Pj4+Pj4+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgZXhwbGFpbiB3aGF0IHdlIGFyZQ0KPiA+ PmFmdGVyLg0KPiA+PiAgPj5JZiBpdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBkb2Vz LCBhbmQgaWYgdGhlIGludGVudCBpcyBhY2NlcHRhYmxlIHRvIHRoZQ0KPiA+PndvcmtpbmcNCj4g Pj4gID4+ID4+IGdyb3VwLA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB3ZSBjYW4gZmln dXJlIG91dCB3aGF0IGFkZGl0aW9uYWwgd29yZHMgYXJlDQo+ID4+bmVlZGVkDQo+ID4+ICA+PiB0 bw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBjb252ZXkgdGhpcy4gSWYgdGhlIHdvcmtp bmcgZ3JvdXAgZGlzYWdyZWUgd2l0aA0KPiA+PnRoZQ0KPiA+PiAgPj4gPj4gaW50ZW50LA0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiB0aGVuIHdlIHdpbGwgb2YgY291cnNlIGFkanVzdCB0 byBtYXRjaCB0aGUNCj4gPj53b3JraW5nDQo+ID4+ICA+PiA+Pmdyb3VwDQo+ID4+ICA+PiA+PiA+ Pj4gPj4gPj4+Pj4+Pj4+IGFncmVlbWVudHMuIElmIHRoaXMgaXMgc3RpbGwgdW5jbGVhciwgSSBh bSBub3QNCj4gPj5zdXJlDQo+ID4+ICA+PiA+PndoYXQgdG8NCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+Pj4gdHJ5IG5leHQuDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+ PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IFlvdXJzLCBKb2VsDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgPj4gPj4gc2ZjDQo+ ID4+ICA+PiA+PiA+Pj4gPj4gbWFpbGluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBs aXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgPj4gPj4gc2ZjDQo+ID4+ICA+PiA+ PiA+Pj4gPj4gbWFpbGluZw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4+PiBsaXN0IHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ICA+PiA+ PiA+Pj4gPj4gPj4+Pj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiAgPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+ ID4+IHNmYw0KPiA+PiAgPj4gPj4gPj4+ID4+IG1haWxpbmcNCj4gPj4gID4+ID4+ID4+PiA+PiA+ Pj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+ ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+Pj4NCj4gPj4gID4+ID4+ ID4+PiA+PiA+Pj4+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+ICA+PiBzZmMNCj4gPj4gID4+ID4+ID4+PiA+PiBtYWlsaW5nDQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+PiBsaXN0IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4gPj4gID4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pj4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiBzZmMNCj4gPj4gID4+ID4+ID4+PiBtYWls aW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pj4+DQo+ID4+ ICA+PiA+PiA+Pj4gPj4gPj4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+Pg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMNCj4gPj4gID4+ID4+ ID4+PiBtYWlsaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4+ DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBzZmMNCj4gPj4gID4+ID4+IG1haWxpbmcNCj4gPj4gID4+ID4+ ID4+PiA+PiBsaXN0DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+PiBzZmNAaWV0Zi5vcmcgPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+Pj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2ZjDQo+ ID4+ICA+PiA+PiBtYWlsaW5nDQo+ID4+ICA+PiA+PiA+Pj4gPj4gbGlzdA0KPiA+PiAgPj4gPj4g Pj4+ID4+ID4+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+PiAgPj4gPj4gPj4+ID4+ ID4+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pj4NCj4gPj4gID4+ID4+ID4+PiA+PiA+Pg0KPiA+ PiAgPj4gPj4gPj4+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+ICA+PiA+PiA+Pj4gPj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+PiAg Pj4gPj4gPj4+ID4+ID4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4g ID4+ID4+ID4+PiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiA+PiAgPj4gPj4gPj4+ID4+ID4+DQo+ID4+ICA+PiA+PiA+Pj4gPj4gPg0KPiA+PiAgPj4g Pj4gPj4+ID4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiAgPj4gPj4gPj4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+ID4+ICA+PiA+PiA+Pj4g Pj4gPnNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4gID4+ID4+ID4+PiA+ PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gPj4gID4+ID4+ ID4+PiA+Pg0KPiA+PiAgPj4gPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+ICA+PiA+PiA+Pj4gPj4gc2ZjIG1haWxpbmcgbGlzdA0K PiA+PiAgPj4gPj4gPj4+ID4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4g Pj4gID4+ID4+ID4+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiA+PiAgPj4gPj4gPj4+DQo+ID4+ICA+PiA+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+ID4+ID4+PiBzZmMgbWFpbGluZyBs aXN0DQo+ID4+ICA+PiA+PiA+Pj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K PiA+PiAgPj4gPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+ID4+ICA+PiA+PiA+DQo+ID4+ICA+PiA+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gID4+ID4+ID5zZmMgbWFpbGluZyBsaXN0DQo+ID4+ ICA+PiA+PiA+c2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+PiAgPj4gPj4g Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4+ICA+DQo+ID4+ DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYu b3JnPg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+ Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2Zj IG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0K From nobody Tue Jul 15 06:22:37 2014 Return-Path: <jguichar@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824A01B28B6 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 ae76omy9qYJQ for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:22:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE9B1B28B5 for <sfc@ietf.org>; Tue, 15 Jul 2014 06:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9535; q=dns/txt; s=iport; t=1405430552; x=1406640152; h=from:to:subject:date:message-id:mime-version; bh=2yiiFnA4O3OfWRtU7fu5bffgvjL2F/4hZHC9nGydkdU=; b=HhYvILtpELj1/7b0yDnDI7G8wuWBviE/d1R6RgBUHMS4eRmvDD8NPACb dBPgc9q6H8g93u2g7Po2VeRySLYHC2XCyJCERkhWXIEFdn6yEfVDa9Bd/ 8n1jWLPh8Bor+3k/DdU84jLnfOjqvZ08XxsI5MXVi2YaJSTYmvmIGLfHD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFAFAqxVOtJA2B/2dsb2JhbABPCoJHR1JXBMFth0GBDBZ1hAonAmIBAhhmFxAEHIg5DaI5pzsXjm9YhE4FmxiBS5Jag0RsAYFE X-IronPort-AV: E=Sophos;i="5.01,665,1400025600"; d="scan'208,217";a="340205112" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2014 13:22:30 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6FDMTc5025857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Tue, 15 Jul 2014 13:22:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 08:22:29 -0500 From: "Jim Guichard (jguichar)" <jguichar@cisco.com> To: "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: IETF90 Toronto SFC Agenda Thread-Index: AQHPoC/TWmyUq3V41kStUInid1a9jA== Importance: high X-Priority: 1 Date: Tue, 15 Jul 2014 13:22:29 +0000 Message-ID: <CFEAA350.2EDB4%jguichar@cisco.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.131.36.24] Content-Type: multipart/alternative; boundary="_000_CFEAA3502EDB4jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ekm9cIMzEv3YWvs85aos0bqvxjA Subject: [sfc] IETF90 Toronto SFC Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 13:22:35 -0000 --_000_CFEAA3502EDB4jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: Below is the draft agenda for SFC. Please note that we received more reques= ts for presentation slots than could reasonably be accommodated (we had to = turn down 7 requests). We based our selection on overall relevance and impo= rtance to the SFC charter and the immediate deliverables (at this point, ar= chitecture, requirements, OAM, encapsulation). A copy of the agenda is posted here -> https://datatracker.ietf.org/secr/pr= oceedings/90/sfc/. Please can presented forward copies of their presentatio= ns to Thomas and I so that we can upload them to the proceedings page prior= to the meeting. 0.00 Introduction (WG-chairs) - [10 minutes] - Update on PS progression (WG-chairs) - [5 minutes] - Agenda bashing, note-well, (WG-chairs) - [5 minutes] 00:10 SFC requirements discussion (presenters + open-mic) - [20 minutes] Purpose: Discuss how to progress requirements within the WG. Which document= s should requirements be included in? How do requirements drive our charter= ? How should requirements be structured and documented? - SFC requirements discussion (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ - SFC requirements Q&A (open-mic) - [10 minutes] 00:30 SFC architecture discussion (presenters + open-mic) - [20 minutes] Purpose: Identify current status of architecture work. How do we get to a s= ingle WG document? What gaps need filling from other existing documents? Wh= at other documents fall under the umbrella of architecture? - SFC architecture merge (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ - SFC architecture Q&A (open-mic) - [10 minutes] 00:50 SFC encapsulation - [30 minutes] Purpose: Discuss WG progression of SFC encapsulation. - Network Service Headers (NSH) (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ - Service Chain Header (SCH) (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ - SFC encapsulation Q&A (open-mic) - [10 minutes] 01:20 Service Function Chaining Operations, Administration and Maintenance = Framework - [30 minutes] Purpose: Present SFC OAM framework, which is an essential piece of the SFC = charter and work areas. - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.= txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] 01:50 Open Source SFC - [15 minutes] Purpose: Present a working SFC implementation as a start to investigation i= nto the control / management plane requirements that need to be addressed a= s part of the SFC charter and reported back to OPS. - Open Source SFC implementation (Reinaldo Penno) - [15 minutes] 02:05 SFC use cases - [20 minutes] Purpose: Review use case progression. Are further documents needed? What is= missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ - SFC use case Q&A (open-mic) - [10 minutes] 02:25 Closing (WG chairs) - [5 minutes] Thank You Jim & Thomas --_000_CFEAA3502EDB4jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <C2C20E72E07FC548A8876A1766012D8C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div> <div> <p style=3D"font-family: Calibri; font-size: medium; margin: 0px;">Dear WG:= </p> <p style=3D"font-family: Calibri; font-size: medium; margin: 0px; min-heigh= t: 14px;"> <br> </p> <p style=3D"font-family: Calibri; font-size: medium; margin: 0px;">Below is= the draft agenda for SFC. Please note that we received more requests for p= resentation slots than could reasonably be accommodated (we had to turn dow= n 7 requests). We based our selection on overall relevance and importance to the SFC charter and the immediate d= eliverables (at this point, architecture, requirements, OAM, encapsulation)= .</p> </div> <div style=3D"font-family: Calibri; font-size: medium;"> <pre style=3D"word-wrap: break-word;"><font face=3D"Calibri" style=3D"font-= size: 14px; white-space: pre-wrap;">A copy of the agenda is posted here -&g= t; </font><font face=3D"Calibri"><a href=3D"https://datatracker.ietf.org/se= cr/proceedings/90/sfc/" style=3D"color: rgb(0, 0, 0); font-size: 14px; whit= e-space: pre-wrap;">https://datatracker.ietf.org/secr/proceedings/90/sfc/</= a><span style=3D"white-space: pre-wrap;">. Please can presented forward cop= ies of their presentations to Thomas and I so that we can upload them to th= e proceedings page prior to the meeting. </span></font><font face=3D"Calibr= i" style=3D"font-size: 14px; white-space: pre-wrap;"><br></font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri"><u>0.00 <b>Introduction</b> (WG-chairs) - [10 min= utes]</u> - Update on PS progression (WG-chairs) - [5 minutes] - Agenda bashing, note-well, (WG-chairs) - [5 minutes] <u>00:10 <b>SFC requirements discussion</b> (presenters + open-mic) - [= 20 minutes]</u> Purpose: Discuss how to progress requirements within the WG. Which document= s should requirements be included in? How do requirements drive our charter= ? How should requirements be structured and documented?</font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">- SFC requirements discussion (Ron Parker) - [10 = minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/</fon= t></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><span style=3D"font-family: Calibri;">- SFC requirements Q&A (open-m= ic) - [10 minutes]</span></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri"><u>00:30 <b>SFC architecture discussion </b>(pres= enters + open-mic) - [20 minutes]</u> Purpose: Identify current status of architecture work. How do we get to a s= ingle WG document? What gaps need filling from other existing documents? Wh= at other documents fall under the umbrella of architecture? - SFC architecture merge (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ - SFC architecture Q&A (open-mic) - [10 minutes] <u>00:50 <b>SFC encapsulation</b> - [30 minutes]</u> Purpose: Discuss WG progression of SFC encapsulation.</font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">- Network Service Headers (NSH) (Paul Quinn) - [1= 0 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/<br></font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">- Service Chain Header (SCH) (Ron Parker) - [10 m= inutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ <br></font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">- SFC encapsulation Q&A (open-mic) - [10 minu= tes] <u>01:20 <b>Service Function Chaining Operations, Administration and Mainte= nance Framework</b> - [30 minutes]</u> Purpose: Present SFC OAM framework, which is an essential piece of the SFC = charter and work areas.=20 - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.= txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] <u>01:50 <b>Open Source SFC</b> - [15 minutes]</u> Purpose: Present a working SFC implementation as a start to investigation i= nto the control / management plane requirements that need to be addressed a= s part of the SFC charter and reported back to OPS.=20 - Open Source SFC implementation (Reinaldo Penno) - [15 minutes] <u>02:05 <b>SFC use cases</b> - [20 minutes]</u> Purpose: Review use case progression. Are further documents needed? What is= missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/<br></font></p= re> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">- SFC use case Q&A (open-mic) - [10 minutes] <u>02:25 <b>Closing</b> (WG chairs) - [5 minutes]</u></font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">Thank You</font></pre> <pre style=3D"font-size: 14px; word-wrap: break-word; white-space: pre-wrap= ;"><font face=3D"Calibri">Jim & Thomas</font></pre> </div> </div> </body> </html> --_000_CFEAA3502EDB4jguicharciscocom_-- From nobody Tue Jul 15 06:23:17 2014 Return-Path: <paulq@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B261B28B5 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 gtrm9QeNrgyX for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:23:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C3A1A03D3 for <sfc@ietf.org>; Tue, 15 Jul 2014 06:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9704; q=dns/txt; s=iport; t=1405430595; x=1406640195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ap34AqTObg3CfKBzGALwPcdOjjZYVpmw5CNPy7xxNz8=; b=UlfJeotrYtJFZCGRahns3kEqkH5xmyZnWNsTdFcKxyN3rhJRGFuwHUxN UeAdUje+V+yRg4QEA/0yIrFq6hM04k7kpDSaEcM0uqrlhX1TGveEEaUFq H+9J+lFieLOqlO9+88GzWQ14vwIHH5ixAQ6PH0YH4BUrJfhuI6V/SFxfc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAI0qxVOtJA2J/2dsb2JhbABZgkdHUlcEwWIBCYdDAYELFnWEAwEBAQQBAQELVwkLEAIBCBEBAwEBKAcnCxQDBggCBA4FiEINyXYTBI9HBAYBgy2BFgWbGJQlg0RsAYFE X-IronPort-AV: E=Sophos; i="5.01,665,1400025600"; d="scan'208,217"; a="60955863" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 15 Jul 2014 13:23:13 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6FDNDEM015110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 13:23:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 08:23:12 -0500 From: "Paul Quinn (paulq)" <paulq@cisco.com> To: David Allan I <david.i.allan@ericsson.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAGYV4A= Date: Tue, 15 Jul 2014 13:23:12 +0000 Message-ID: <0B93BBE2-4AC8-4098-92BF-B2B197BA767B@cisco.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.228] Content-Type: multipart/alternative; boundary="_000_0B93BBE24AC8409892BFB2B197BA767Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FO1hxb36agMB-5zEM_ksYRN_uJs Cc: "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 13:23:16 -0000 --_000_0B93BBE24AC8409892BFB2B197BA767Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree, there is no implication in the suggested text that mandates a stat= ic, a priori path, rather is provides the distinction between the fully abs= tract and the need to actually instantiate that abstraction in the network. For some reason, 3 or 4 people seem to be fixated on the term =93path=94 bu= t Joel has made it clear that this need not be, architecturally, a known fi= xed path, but rather, the selection may occur based on needed indirection a= t the nodes. Paul On Jul 14, 2014, at 2:02 PM, David Allan I <david.i.allan@ericsson.com<mail= to:david.i.allan@ericsson.com>> wrote: I like that text, it strikes a good balance where an implementation has the= option of making scale and resiliency a local matter=85. D From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 14, 2014 10:48 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] SFC Terminology / Concepts Dear WG: There has been much debate over the last few days with regards to SFC conce= pts. To try and form some consensus around terminology and concepts used to= describe the architecture in the merged architecture draft, Joel has kindl= y suggested the following: "The SFP provides a level of indirection between the fully abstract notion = of service path as a sequence of functions to be delivered, and the fully s= pecified notion of exactly what instances of SFFs the packet will visit whe= n it actually traverses the network. By allowing the control components to = specify the use of this level of indirection, the deployment may choose the= degree of SFF instance selection authority that is delegated to the networ= k.=94 I=92d like to ask the WG as a whole, if this clarification is something tha= t we can get consensus on. If so, I=92ll ask Joel to provide specific text,= that reflects the above, for inclusion in the merged architecture draft. Thank You, Jim _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_0B93BBE24AC8409892BFB2B197BA767Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <BDD36833F032504E85E6E962F2BAB4B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space;"> I agree, there is no implication in the suggested text that mandates a stat= ic, a priori path, rather is provides the distinction between the fully abs= tract and the need to actually instantiate that abstraction in the network. <div><br> </div> <div>For some reason, 3 or 4 people seem to be fixated on the term =93path= =94 but Joel has made it clear that this need not be, architecturally, a kn= own fixed path, but rather, the selection may occur based on needed indirec= tion at the nodes.</div> <div><br> </div> <div>Paul</div> <div><br> </div> <div><br> </div> <div><br> <div> <div>On Jul 14, 2014, at 2:02 PM, David Allan I <<a href=3D"mailto:david= .i.allan@ericsson.com">david.i.allan@ericsson.com</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <blockquote type=3D"cite"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"font-family: He= lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we= ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t= ext-align: start; text-indent: 0px; text-transform: none; white-space: norm= al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> <div class=3D"WordSection1" style=3D"page: WordSection1;"> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg= b(31, 73, 125);">I like that text, it strikes a good balance where an imple= mentation has the option of making scale and resiliency a local matter=85.<= o:p></o:p></span></div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg= b(31, 73, 125);"> </span></div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg= b(31, 73, 125);">D<o:p></o:p></span></div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg= b(31, 73, 125);"> </span></div> <div> <div style=3D"border-style: solid none none; border-top-color: rgb(181, 196= , 223); border-top-width: 1pt; padding: 3pt 0in 0in; position: static; z-in= dex: auto;"> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <b><span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif;">From:<= /span></b><span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif;"= ><span class=3D"Apple-converted-space"> </span>sfc [<a href=3D"mailto:= sfc-bounces@ietf.org" style=3D"color: purple; text-decoration: underline;">= mailto:sfc-bounces@ietf.org</a>]<span class=3D"Apple-converted-space"> = ;</span><b>On Behalf Of<span class=3D"Apple-converted-space"> </span></b>Jim Guicha= rd (jguichar)<br> <b>Sent:</b><span class=3D"Apple-converted-space"> </span>Monday, July= 14, 2014 10:48 AM<br> <b>To:</b><span class=3D"Apple-converted-space"> </span><a href=3D"mai= lto:sfc@ietf.org" style=3D"color: purple; text-decoration: underline;">sfc@= ietf.org</a><br> <b>Subject:</b><span class=3D"Apple-converted-space"> </span>[sfc] SFC= Terminology / Concepts<o:p></o:p></span></div> </div> </div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <o:p> </o:p></div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">Dear WG:<o:p></o:p></span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;"> </span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">There has been much debate over the last= few days with regards to SFC concepts. To try and form some consensus arou= nd terminology and concepts used to describe the architecture in the merged= architecture draft, Joel has kindly suggested the following:<o:p></o:p></span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;"> </span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">"The SFP provides a level of indire= ction between the fully abstract notion of service path as a sequence of fu= nctions to be delivered, and the fully specified notion of exactly what ins= tances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to s= pecify the use of this level of indirection, the deployment may choose the = degree of SFF instance selection authority that is delegated to the network= .=94<o:p></o:p></span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;"> </span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">I=92d like to ask the WG as a whole, if = this clarification is something that we can get consensus on. If so, I=92ll= ask Joel to provide specific text, that reflects the above, for inclusion = in the merged architecture draft.<o:p></o:p></span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;"> </span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">Thank You,<o:p></o:p></span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;"> </span></div> </div> <div> <div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time= s New Roman', serif;"> <span style=3D"font-size: 13.5pt;">Jim<o:p></o:p></span></div> </div> </div> _______________________________________________<br> sfc mailing list<br> <a href=3D"mailto:sfc@ietf.org" style=3D"color: purple; text-decoration: un= derline;">sfc@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" style=3D"color: purpl= e; text-decoration: underline;">https://www.ietf.org/mailman/listinfo/sfc</= a></div> </blockquote> </div> <br> </div> </body> </html> --_000_0B93BBE24AC8409892BFB2B197BA767Bciscocom_-- From nobody Tue Jul 15 06:45:27 2014 Return-Path: <jmh.direct@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B92F1A03CE for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:45:25 -0700 (PDT) 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 1eGtBwIQmV3X for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 06:45:23 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEAC1A03DE for <sfc@ietf.org>; Tue, 15 Jul 2014 06:45:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 6C382D4087F; Tue, 15 Jul 2014 06:45:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id CED70D40651; Tue, 15 Jul 2014 06:45:22 -0700 (PDT) Message-ID: <53C53070.7030706@joelhalpern.com> Date: Tue, 15 Jul 2014 09:45:20 -0400 From: Joel Halpern Direct <jmh.direct@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/irC82RAa9u9N1z3bUkUSgqc7diE Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 13:45:25 -0000 Since folks have requested that SFF have discretion on selecting next-SFF, it is important that the SFP scoping be able to restrict the set of SFFs which will be used for the traffic. At the same time, it is also true that the scoping can provide restriction on which instances (among those available to the SFF that could be used for the service chain) will be used. Net: It is important that the scoping allow for selecting SFFs. it is reasonable to also allow restriction on service function instantiations. I want to be careful because if there is a load balancer hanging off of the SFF, then I do not see how this scoping can affect the load balancer instance selection. When the SFF has an integral load balancer, then such restriction can take effect. Yours, Joel On 7/14/14, 10:04 PM, Xuxiaohu wrote: > Hi Joel, > >> To rephrase this a bit (and then if folks agree on the concept, we can pick the >> wording): >> >> The SFP provides a level of indirection between the fully abstract notion of >> service path as a sequence of functions to be delivered, and the fully specified >> notion of exactly what instances of SFFs the packet will visit when it actually >> traverses the network. > > Instances of SFFs or instances of SF? > >> By allowing the control components to specify the use of this level of indirection, >> the deployment may choose the degree of SFF instance selection authority that >> is delegated to the network. > > SFF instance or SF instance? > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 15 07:07:05 2014 Return-Path: <prvs=6273c163fd=phe@ciena.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD861A03F9 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfAbezO-AOFI for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 07:06:56 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9602F1B28B9 for <sfc@ietf.org>; Tue, 15 Jul 2014 07:06:54 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6FE2SDh000549; Tue, 15 Jul 2014 10:06:47 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 1n4nj6h8hw-3 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2014 10:06:47 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 15 Jul 2014 10:06:41 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Tue, 15 Jul 2014 10:06:23 -0400 From: "He, Peng" <phe@ciena.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "sfc@ietf.org" <sfc@ietf.org> Date: Tue, 15 Jul 2014 10:06:20 -0400 Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eCUIwKY/CDCEqtraJ73Kn6IpugYkOAgAAOE3CAALxWUA== Message-ID: <B6D287BF58D35D4B882E012AD3E1756172E67758@ONWVEXCHMB04.ciena.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293185@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293185@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20818.007 x-tm-as-result: No--37.028000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-15_04:2014-07-15,2014-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407150144 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RnPiJWSB01UrnsISRVAJjMr6g0o Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 14:07:01 -0000 I have the same question, will that still be SFF or re-classification? Regards, Peng -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Monday, July 14, 2014 11:08 PM To: Xuxiaohu; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Specially speaking, for a given SFF along the SPF, should it just be capabl= e of flexibly choosing one of the local SF instances of the current SF, or = should it further be capable of flexibly choose one of the SFFs to which at= least one instance of the next SF is attached? Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 15, 2014 10:05 AM > To: Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Hi Joel, >=20 > > To rephrase this a bit (and then if folks agree on the concept, we=20 > > can pick the > > wording): > > > > The SFP provides a level of indirection between the fully abstract=20 > > notion of service path as a sequence of functions to be delivered,=20 > > and the fully specified notion of exactly what instances of SFFs the=20 > > packet will visit when it actually traverses the network. >=20 > Instances of SFFs or instances of SF? >=20 > > By allowing the control components to specify the use of this level=20 > > of indirection, the deployment may choose the degree of SFF instance=20 > > selection authority that is delegated to the network. >=20 > SFF instance or SF instance? >=20 > Best regards, > Xiaohu >=20 > > Yours, > > Joel > > > > _______________________________________________ > > 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 nobody Tue Jul 15 07:29:07 2014 Return-Path: <jmh.direct@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE37C1B2875 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 07:29:03 -0700 (PDT) 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 eM6kfj9z2uQp for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 07:29:01 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C4F1A03FC for <sfc@ietf.org>; Tue, 15 Jul 2014 07:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id F0E3CD40724; Tue, 15 Jul 2014 07:29:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 65CFBD405C9; Tue, 15 Jul 2014 07:29:00 -0700 (PDT) Message-ID: <53C53AAA.5020200@joelhalpern.com> Date: Tue, 15 Jul 2014 10:28:58 -0400 From: Joel Halpern Direct <jmh.direct@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "He, Peng" <phe@ciena.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293185@NKGEML512-MBS.china.huawei.com> <B6D287BF58D35D4B882E012AD3E1756172E67758@ONWVEXCHMB04.ciena.com> In-Reply-To: <B6D287BF58D35D4B882E012AD3E1756172E67758@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZPtR6oj1BjuWcdqtvmybelIp4_E Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 14:29:03 -0000 Folks asked for this (SFF seelction in data plane) capability. From earlier discussion, I think that there is an intention to allow this in a semi-static fashion that does not require examination, or in conjunction with a suitable packet hash mechanism to enable stability of choice. Yours, Joel On 7/15/14, 10:06 AM, He, Peng wrote: > I have the same question, will that still be SFF or re-classification? > > > Regards, > Peng > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Monday, July 14, 2014 11:08 PM > To: Xuxiaohu; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP > > Specially speaking, for a given SFF along the SPF, should it just be capable of flexibly choosing one of the local SF instances of the current SF, or should it further be capable of flexibly choose one of the SFFs to which at least one instance of the next SF is attached? > > Best regards, > Xiaohu > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >> Sent: Tuesday, July 15, 2014 10:05 AM >> To: Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] Proposed redefinition of SFP >> >> Hi Joel, >> >>> To rephrase this a bit (and then if folks agree on the concept, we >>> can pick the >>> wording): >>> >>> The SFP provides a level of indirection between the fully abstract >>> notion of service path as a sequence of functions to be delivered, >>> and the fully specified notion of exactly what instances of SFFs the >>> packet will visit when it actually traverses the network. >> >> Instances of SFFs or instances of SF? >> >>> By allowing the control components to specify the use of this level >>> of indirection, the deployment may choose the degree of SFF instance >>> selection authority that is delegated to the network. >> >> SFF instance or SF instance? >> >> Best regards, >> Xiaohu >> >>> Yours, >>> Joel >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing 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 Tue Jul 15 08:07:06 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB861B28CF for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:06:56 -0700 (PDT) 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 yFXS88mb5mhO for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:06:52 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A74A1A0769 for <sfc@ietf.org>; Tue, 15 Jul 2014 08:06:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 3D80FD405C9; Tue, 15 Jul 2014 08:06:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 35968D40527; Tue, 15 Jul 2014 08:06:49 -0700 (PDT) Message-ID: <53C54389.9070200@joelhalpern.com> Date: Tue, 15 Jul 2014 11:06:49 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JA7p76tHdB5GwOnf8cSwHfmEOOY Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:06:57 -0000 My concern is that there are requests (which I happen to support) for allowing a degree of policy expression or scope restriction in what the classification communicates to the infrastructure about the service delivery. This needs to include restrictions on SFF selection and probably at least allow for restrictions on ctual instance selection. Given that the restriction includes the case "allow all", expressing the information in terms of this intermediate allows for the requirement, allows for the communication of the equivalent of the unlimited chain, and allows for expression of the exact choice when operations has selected that behavior. Communicating the chain does not add anything to this, and if it were used instead of the itnermediate it would remove the ability to meet the requirements. Yours, Joel On 7/15/14, 3:21 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > As mentioned in several messages, I'm personally for the use of the chain itself is the main information to be conveyed in packets to drive forwarding actions. > > I can understand that an identifier can be assigned to a path that is known in advance, but if that path is not known I'm not sure how an identifier can be assigned to it! > > Joel, the use of "path" is really inappropriate to refer to distributed instance selection process for packets bound to a given SFC. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoyé : lundi 14 juillet 2014 21:52 >> À : Tom Taylor; sfc@ietf.org; Ron Parker >> Objet : Re: [sfc] SFC Terminology / Concepts >> >> The most likely realization of the architecture would be that the SFP >> assignment is recorded in an identifier which travels with the packet. >> >> Some folks seem to not want the architecture to mandate that. >> >> Yours, >> Joel >> >> >> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>> Your text scares me because it introduces some new concepts and >>> assumptions. >>> >>> I'd rather go with Joel's formulation. Clarifying question on that: am I >>> right in seeing the implication that when control assigns an SFP, the >>> assignment is recorded by an identifier wwhich travels with the packet? >>> >>> Tom Taylor >>> >>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>> There is one missing word in my text. Please replace my proposed text >>>> with: >>>> >>>> "The Service Function Chain (SFC) provides a fully abstract view of the >>>> service functions to be invoked and the order in which they are to be >>>> invoked for some particular flow or set of flows, without concern of >>>> actual service function instance selection. The Constrained-SFC >>>> (C-SFC) further allows for policy constraints to be added to the SFC >>>> affecting the instance selection of one or more of the service functions >>>> in the SFC. Any SFC may have any number of C-SFC's associated with >> it." >>>> >>>> Thanks. >>>> >>>> Ron >>> ... >>> >>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>> >>>> I like that text, it strikes a good balance where an implementation has >>>> the option of making scale and resiliency a local matter.. >>>> >>>> D >>>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>>> (jguichar) >>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>>> *Subject:* [sfc] SFC Terminology / Concepts >>>> >>>> Dear WG: >>>> >>>> There has been much debate over the last few days with regards to SFC >>>> concepts. To try and form some consensus around terminology and concepts >>>> used to describe the architecture in the merged architecture draft, Joel >>>> has kindly suggested the following: >>>> >>>> "The SFP provides a level of indirection between the fully abstract >>>> notion of service path as a sequence of functions to be delivered, and >>>> the fully specified notion of exactly what instances of SFFs the packet >>>> will visit when it actually traverses the network. By allowing the >>>> control components to specify the use of this level of indirection, the >>>> deployment may choose the degree of SFF instance selection authority >>>> that is delegated to the network." >>>> >>>> I'd like to ask the WG as a whole, if this clarification is something >>>> that we can get consensus on. If so, I'll ask Joel to provide specific >>>> text, that reflects the above, for inclusion in the merged architecture >>>> draft. >>>> >>>> Thank You, >>>> >>>> Jim >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing 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 Tue Jul 15 08:28:50 2014 Return-Path: <tom.taylor.stds@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDEB1B2877 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:28:16 -0700 (PDT) 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 eiT5NQDx6u2t for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:27:52 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688BA1A04CD for <sfc@ietf.org>; Tue, 15 Jul 2014 08:27:51 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so2805633qgd.28 for <sfc@ietf.org>; Tue, 15 Jul 2014 08:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XtgVi7HHf5uK3LZ4SRwB9Lo5rFuhCrcS75P7XOZm5xQ=; b=ltxlNShxfkoAl0Kdt9ChOU7U+f8QidbybwBaRYWa9vmbQ4zZ2qenOvc2Tjl93zgOwS HOBAN7K7nJRNCWgx0cpoO4qp3ndXCvrojl0JAd+Glc9eNyP3ldikzmR0lsZaHqZjVjrd dZb0uKM3TcNVwKHRwVtez26wGZ6B1WTl2GLLhwoj89wV8l1FzYKySrQ7TeXB4UEw8ABN WjIHGjdMli2bUZ2ZFCWnIRKLgaEgz3G/vsADxr2dCYyyxctVAtCQusNXFECDl6vV80+A vKoQmXbsjoS8U7DfQGFnvs4tvELi6fN47jgEJIPs7QKs/7na3RGcmqhuCUzDUFUZmrkt +teg== X-Received: by 10.229.202.136 with SMTP id fe8mr15195744qcb.8.1405438070684; Tue, 15 Jul 2014 08:27:50 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id f23sm9991396qge.10.2014.07.15.08.27.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 08:27:50 -0700 (PDT) Message-ID: <53C54874.3030905@gmail.com> Date: Tue, 15 Jul 2014 11:27:48 -0400 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joel M. Halpern" <jmh@joelhalpern.com>, mohamed.boucadair@orange.com, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53C54389.9070200@joelhalpern.com> In-Reply-To: <53C54389.9070200@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AwH2owkLofha3nA5UNjiqfjI4nk Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:28:27 -0000 In that case I would go with Ron's text. There is an operational issue: where to insert constraints. Are they inserted at the ingress classifier only (and there can be multiple instances of those) or can they be added at intermediate points? A possible advantage of allowing constraints to be added further along the path is that it looks ahead to inter-domain operation. However, if done within a single domain it increases the administrative load because more entities have to be configured with policy information. My view of a path identifier is that it can optimize service-level forwarding by providing a function similar to that of the IPv6 Flow Label. At branch points (e.g., load balancers) the forwarding decision uses the path identifier rather than re-hashing some of the contents of the packet. I suppose instead of "path identifier" it would more properly be called "service flow identifier". Tom On 15/07/2014 11:06 AM, Joel M. Halpern wrote: > My concern is that there are requests (which I happen to support) for > allowing a degree of policy expression or scope restriction in what the > classification communicates to the infrastructure about the service > delivery. This needs to include restrictions on SFF selection and > probably at least allow for restrictions on ctual instance selection. > > Given that the restriction includes the case "allow all", expressing the > information in terms of this intermediate allows for the requirement, > allows for the communication of the equivalent of the unlimited chain, > and allows for expression of the exact choice when operations has > selected that behavior. > > Communicating the chain does not add anything to this, and if it were > used instead of the itnermediate it would remove the ability to meet the > requirements. > > Yours, > Joel > > On 7/15/14, 3:21 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >> >> As mentioned in several messages, I'm personally for the use of the >> chain itself is the main information to be conveyed in packets to >> drive forwarding actions. >> >> I can understand that an identifier can be assigned to a path that is >> known in advance, but if that path is not known I'm not sure how an >> identifier can be assigned to it! >> >> Joel, the use of "path" is really inappropriate to refer to >> distributed instance selection process for packets bound to a given SFC. >> >> Cheers, >> Med >> ... From nobody Tue Jul 15 08:29:26 2014 Return-Path: <ddolson@sandvine.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CAD1B28BA for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snRRq6oxcIea for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:28:46 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 71D051A04CD for <sfc@ietf.org>; Tue, 15 Jul 2014 08:28:16 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Tue, 15 Jul 2014 11:28:15 -0400 From: Dave Dolson <ddolson@sandvine.com> To: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eAqu6S/bXIpkC+b97vPZCJe5ugplkAgADDzwD//8n+gA== Date: Tue, 15 Jul 2014 15:28:14 +0000 Message-ID: <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> In-Reply-To: <53C53070.7030706@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QI0qxlhCfVgwe5ciAnsPvEvNPMc Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:29:04 -0000 Giving SFFs forwarding discretion troubles me, considering multiple vendors= and bidirectional traffic, and this is why: When an SFF has some freedom to choose the next-SFF, this amounts to an imp= licit (possibly opaque) forwarding rule. Consider implicit rules in the context of bidirectional traffic, when a sta= teful SF needs to see both directions of any given flow. For the bidirectional case, a stateful SF would need to be book-ended with = SFFs having compatible implicit forwarding rules. In this picture, SFF1 and SFF2 would need to have compatible implicit forwa= rding rules so that stateful SFFA and SFFB receive the same flows.=20 ("Compatible" may mean anti-symmetric, such as balancing by source IP in on= e case and destination IP in the other case. If the balancing is load-aware= , SFF1 and SFF2 would have to communicate about load-balancing choices.) +----+ +----+ +----+ -----|SFF1|----+----|SFFA|----+----|SFF2|---- +----+ | +----+ | +----+ | | | +----+ | +----|SFFB|----+ +----+ I suspect the above might make sense for a single-vendor solution, but I wo= uld hope that the standard allows the 4 SFFs to be from different vendors. If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit = forwarding rules; they should be explicitly configured; one method is to cr= eate explicit paths; another method would be standardizing the classificati= on rules used for load-balancing. If the above figure *is* a single-vendor solution (perhaps a server farm wi= th load-balancing), then the above figure can appear as a single SFF from t= he protocol point of view. Vendor load-balancing solution, presenting the scalable system as a single = SFF: +-----------------------------------------+ | | | +----+ +----+ +----+ | -----|LB1 |----+----|SF |----+----| LB2|---- | +----+ | +----+ | +----+ | | | | | | | +----+ | | | +----|SF |----+ | | +----+ | |SFF | +-----------------------------------------+ In summary, I have trouble with allowing "discretion" in forwarding between= SFFs. It should all be explicit. One could argue that it is useful for the unidirectional chaining cases, I = suppose. But explicit always works. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct Sent: Tuesday, July 15, 2014 9:45 AM To: Xuxiaohu; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Since folks have requested that SFF have discretion on selecting=20 next-SFF, it is important that the SFP scoping be able to restrict the=20 set of SFFs which will be used for the traffic. At the same time, it is also true that the scoping can provide=20 restriction on which instances (among those available to the SFF that=20 could be used for the service chain) will be used. Net: It is important that the scoping allow for selecting SFFs. it is=20 reasonable to also allow restriction on service function instantiations. I want to be careful because if there is a load balancer hanging off of=20 the SFF, then I do not see how this scoping can affect the load balancer=20 instance selection. When the SFF has an integral load balancer, then=20 such restriction can take effect. Yours, Joel On 7/14/14, 10:04 PM, Xuxiaohu wrote: > Hi Joel, > >> To rephrase this a bit (and then if folks agree on the concept, we can p= ick the >> wording): >> >> The SFP provides a level of indirection between the fully abstract notio= n of >> service path as a sequence of functions to be delivered, and the fully s= pecified >> notion of exactly what instances of SFFs the packet will visit when it a= ctually >> traverses the network. > > Instances of SFFs or instances of SF? > >> By allowing the control components to specify the use of this level of i= ndirection, >> the deployment may choose the degree of SFF instance selection authority= that >> is delegated to the network. > > SFF instance or SF instance? > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing 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 Tue Jul 15 08:36:55 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29A1B28C2 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 s23nrmdicMBz for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:36:50 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861981B2883 for <sfc@ietf.org>; Tue, 15 Jul 2014 08:36:50 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 4E32B53E02; Tue, 15 Jul 2014 08:36:43 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Tue, 15 Jul 2014 08:36:43.282 -0700 x-echoworx-msg-id: 8b8e7791-e541-42eb-8ea3-a8bfc8ab7bd6 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 853; Tue, 15 Jul 2014 08:36:43 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 2D81853E02; Tue, 15 Jul 2014 08:36:43 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 08:36:49 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Dave Dolson <ddolson@sandvine.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3d+yX9HZ8tJTkGQvyL0uIwtppug2KMAgADD0ACAABzAAP//i/vw Date: Tue, 15 Jul 2014 15:36:49 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> In-Reply-To: <E8355113905631478EFF04F5AA706E9830A2F517@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RTeUq60Rde-UgOOAAphDZ_R0LI8 Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:36:53 -0000 Hi, Dave. I agree that symmetrical is the more typical case. In order to do their j= obs, many SFF implementations will be stateful at the flow level. When le= arning a flow in the "forward" direction, it should be possible to discern = and retain the previous hop instance (i.e., an SFF or an ingress border nod= e/classifier) for purposes of managing the "reverse" flow in a symmetrical = manner. Whether this recognition of previous hop is solely at the transpo= rt layer or whether some protocol fields need to be introduced to NSH/SCH i= s for further consideration. Also, the architecture spec can call out thi= s mode of behavior explicitly in terms of SFF functional requirements. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, July 15, 2014 11:28 AM To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Giving SFFs forwarding discretion troubles me, considering multiple vendors= and bidirectional traffic, and this is why: When an SFF has some freedom to choose the next-SFF, this amounts to an imp= licit (possibly opaque) forwarding rule. Consider implicit rules in the context of bidirectional traffic, when a sta= teful SF needs to see both directions of any given flow. For the bidirectional case, a stateful SF would need to be book-ended with = SFFs having compatible implicit forwarding rules. In this picture, SFF1 and SFF2 would need to have compatible implicit forwa= rding rules so that stateful SFFA and SFFB receive the same flows.=20 ("Compatible" may mean anti-symmetric, such as balancing by source IP in on= e case and destination IP in the other case. If the balancing is load-aware= , SFF1 and SFF2 would have to communicate about load-balancing choices.) +----+ +----+ +----+ -----|SFF1|----+----|SFFA|----+----|SFF2|---- +----+ | +----+ | +----+ | | | +----+ | +----|SFFB|----+ +----+ I suspect the above might make sense for a single-vendor solution, but I wo= uld hope that the standard allows the 4 SFFs to be from different vendors. If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit = forwarding rules; they should be explicitly configured; one method is to cr= eate explicit paths; another method would be standardizing the classificati= on rules used for load-balancing. If the above figure *is* a single-vendor solution (perhaps a server farm wi= th load-balancing), then the above figure can appear as a single SFF from t= he protocol point of view. Vendor load-balancing solution, presenting the scalable system as a single = SFF: +-----------------------------------------+ | | | +----+ +----+ +----+ | -----|LB1 |----+----|SF |----+----| LB2|---- | +----+ | +----+ | +----+ | | | | | | | +----+ | | | +----|SF |----+ | | +----+ | |SFF | +-----------------------------------------+ In summary, I have trouble with allowing "discretion" in forwarding between= SFFs. It should all be explicit. One could argue that it is useful for the unidirectional chaining cases, I = suppose. But explicit always works. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct Sent: Tuesday, July 15, 2014 9:45 AM To: Xuxiaohu; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Since folks have requested that SFF have discretion on selecting next-SFF, = it is important that the SFP scoping be able to restrict the set of SFFs wh= ich will be used for the traffic. At the same time, it is also true that the scoping can provide restriction = on which instances (among those available to the SFF that could be used for= the service chain) will be used. Net: It is important that the scoping allow for selecting SFFs. it is reas= onable to also allow restriction on service function instantiations. I want to be careful because if there is a load balancer hanging off of the= SFF, then I do not see how this scoping can affect the load balancer insta= nce selection. When the SFF has an integral load balancer, then such restr= iction can take effect. Yours, Joel On 7/14/14, 10:04 PM, Xuxiaohu wrote: > Hi Joel, > >> To rephrase this a bit (and then if folks agree on the concept, we=20 >> can pick the >> wording): >> >> The SFP provides a level of indirection between the fully abstract=20 >> notion of service path as a sequence of functions to be delivered,=20 >> and the fully specified notion of exactly what instances of SFFs the=20 >> packet will visit when it actually traverses the network. > > Instances of SFFs or instances of SF? > >> By allowing the control components to specify the use of this level=20 >> of indirection, the deployment may choose the degree of SFF instance=20 >> selection authority that is delegated to the network. > > SFF instance or SF instance? > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing 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 Tue Jul 15 08:56:43 2014 Return-Path: <ddolson@sandvine.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A931A0A8D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5aUAe961S6I for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:56:38 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFA1B28BC for <sfc@ietf.org>; Tue, 15 Jul 2014 08:56:37 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Tue, 15 Jul 2014 11:56:37 -0400 From: Dave Dolson <ddolson@sandvine.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eAqu6S/bXIpkC+b97vPZCJe5ugplkAgADDzwD//8n+gIAAVSiA///BsFA= Date: Tue, 15 Jul 2014 15:56:37 +0000 Message-ID: <E8355113905631478EFF04F5AA706E9830A2F69F@wtl-exchp-2.sandvine.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Pos9hlShoO80m0zUn4n_-_yLymU Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:56:41 -0000 Ron, To clarify, are you suggesting SFFs remember flow state so as to be able to= make the correct decision in the opposite direction? (Like Ethernet MAC l= earning?) =20 -Dave -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Tuesday, July 15, 2014 11:37 AM To: Dave Dolson; Joel Halpern Direct; Xuxiaohu; sfc@ietf.org Subject: RE: [sfc] Proposed redefinition of SFP Hi, Dave. I agree that symmetrical is the more typical case. In order to do their j= obs, many SFF implementations will be stateful at the flow level. When le= arning a flow in the "forward" direction, it should be possible to discern = and retain the previous hop instance (i.e., an SFF or an ingress border nod= e/classifier) for purposes of managing the "reverse" flow in a symmetrical = manner. Whether this recognition of previous hop is solely at the transpo= rt layer or whether some protocol fields need to be introduced to NSH/SCH i= s for further consideration. Also, the architecture spec can call out thi= s mode of behavior explicitly in terms of SFF functional requirements. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, July 15, 2014 11:28 AM To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Giving SFFs forwarding discretion troubles me, considering multiple vendors= and bidirectional traffic, and this is why: When an SFF has some freedom to choose the next-SFF, this amounts to an imp= licit (possibly opaque) forwarding rule. Consider implicit rules in the context of bidirectional traffic, when a sta= teful SF needs to see both directions of any given flow. For the bidirectional case, a stateful SF would need to be book-ended with = SFFs having compatible implicit forwarding rules. In this picture, SFF1 and SFF2 would need to have compatible implicit forwa= rding rules so that stateful SFFA and SFFB receive the same flows.=20 ("Compatible" may mean anti-symmetric, such as balancing by source IP in on= e case and destination IP in the other case. If the balancing is load-aware= , SFF1 and SFF2 would have to communicate about load-balancing choices.) +----+ +----+ +----+ -----|SFF1|----+----|SFFA|----+----|SFF2|---- +----+ | +----+ | +----+ | | | +----+ | +----|SFFB|----+ +----+ I suspect the above might make sense for a single-vendor solution, but I wo= uld hope that the standard allows the 4 SFFs to be from different vendors. If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit = forwarding rules; they should be explicitly configured; one method is to cr= eate explicit paths; another method would be standardizing the classificati= on rules used for load-balancing. If the above figure *is* a single-vendor solution (perhaps a server farm wi= th load-balancing), then the above figure can appear as a single SFF from t= he protocol point of view. Vendor load-balancing solution, presenting the scalable system as a single = SFF: +-----------------------------------------+ | | | +----+ +----+ +----+ | -----|LB1 |----+----|SF |----+----| LB2|---- | +----+ | +----+ | +----+ | | | | | | | +----+ | | | +----|SF |----+ | | +----+ | |SFF | +-----------------------------------------+ In summary, I have trouble with allowing "discretion" in forwarding between= SFFs. It should all be explicit. One could argue that it is useful for the unidirectional chaining cases, I = suppose. But explicit always works. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct Sent: Tuesday, July 15, 2014 9:45 AM To: Xuxiaohu; sfc@ietf.org Subject: Re: [sfc] Proposed redefinition of SFP Since folks have requested that SFF have discretion on selecting next-SFF, = it is important that the SFP scoping be able to restrict the set of SFFs wh= ich will be used for the traffic. At the same time, it is also true that the scoping can provide restriction = on which instances (among those available to the SFF that could be used for= the service chain) will be used. Net: It is important that the scoping allow for selecting SFFs. it is reas= onable to also allow restriction on service function instantiations. I want to be careful because if there is a load balancer hanging off of the= SFF, then I do not see how this scoping can affect the load balancer insta= nce selection. When the SFF has an integral load balancer, then such restr= iction can take effect. Yours, Joel On 7/14/14, 10:04 PM, Xuxiaohu wrote: > Hi Joel, > >> To rephrase this a bit (and then if folks agree on the concept, we=20 >> can pick the >> wording): >> >> The SFP provides a level of indirection between the fully abstract=20 >> notion of service path as a sequence of functions to be delivered,=20 >> and the fully specified notion of exactly what instances of SFFs the=20 >> packet will visit when it actually traverses the network. > > Instances of SFFs or instances of SF? > >> By allowing the control components to specify the use of this level=20 >> of indirection, the deployment may choose the degree of SFF instance=20 >> selection authority that is delegated to the network. > > SFF instance or SF instance? > > Best regards, > Xiaohu > >> Yours, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing 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 Tue Jul 15 08:58:09 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B571B28C7 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 HXXDsB0xTG0I for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 08:58:05 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011F01B28BC for <sfc@ietf.org>; Tue, 15 Jul 2014 08:58:05 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id C4BEF53E8E; Tue, 15 Jul 2014 08:55:56 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Tue, 15 Jul 2014 08:55:56.776 -0700 x-echoworx-msg-id: d90a9127-aa51-4f77-a095-696f9e725f19 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 0; Tue, 15 Jul 2014 08:55:56 -0700 (PDT) Received: from HUB021-CA-5.exch021.domain.local (unknown [10.254.4.89]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id A7F9653E8E; Tue, 15 Jul 2014 08:55:56 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 08:58:04 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Dave Dolson <ddolson@sandvine.com> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3d+yX9HZ8tJTkGQvyL0uIwtppug2KMAgADD0ACAABzAAP//i/vwgAB784D//4sPuA== Date: Tue, 15 Jul 2014 15:58:04 +0000 Message-ID: <B8B3E329-A29E-4560-8E95-4E28AA5C480C@affirmednetworks.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local>, <E8355113905631478EFF04F5AA706E9830A2F69F@wtl-exchp-2.sandvine.com> In-Reply-To: <E8355113905631478EFF04F5AA706E9830A2F69F@wtl-exchp-2.sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/T6K8oKUsV7t5NebnSj61ZyxndUw Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 15:58:07 -0000 Yes. Also, learning of flow state will facilitate next SFF selection in t= he forward direction.=20 Ron > On Jul 15, 2014, at 11:56 AM, "Dave Dolson" <ddolson@sandvine.com> wrote: >=20 > Ron, > To clarify, are you suggesting SFFs remember flow state so as to be able = to make the correct decision in the opposite direction? (Like Ethernet MAC= learning?) =20 >=20 > -Dave >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 > Sent: Tuesday, July 15, 2014 11:37 AM > To: Dave Dolson; Joel Halpern Direct; Xuxiaohu; sfc@ietf.org > Subject: RE: [sfc] Proposed redefinition of SFP >=20 > Hi, Dave. >=20 > I agree that symmetrical is the more typical case. In order to do their= jobs, many SFF implementations will be stateful at the flow level. When = learning a flow in the "forward" direction, it should be possible to discer= n and retain the previous hop instance (i.e., an SFF or an ingress border n= ode/classifier) for purposes of managing the "reverse" flow in a symmetrica= l manner. Whether this recognition of previous hop is solely at the trans= port layer or whether some protocol fields need to be introduced to NSH/SCH= is for further consideration. Also, the architecture spec can call out t= his mode of behavior explicitly in terms of SFF functional requirements. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, July 15, 2014 11:28 AM > To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Giving SFFs forwarding discretion troubles me, considering multiple vendo= rs and bidirectional traffic, and this is why: >=20 > When an SFF has some freedom to choose the next-SFF, this amounts to an i= mplicit (possibly opaque) forwarding rule. > Consider implicit rules in the context of bidirectional traffic, when a s= tateful SF needs to see both directions of any given flow. >=20 > For the bidirectional case, a stateful SF would need to be book-ended wit= h SFFs having compatible implicit forwarding rules. >=20 > In this picture, SFF1 and SFF2 would need to have compatible implicit for= warding rules so that stateful SFFA and SFFB receive the same flows.=20 > ("Compatible" may mean anti-symmetric, such as balancing by source IP in = one case and destination IP in the other case. If the balancing is load-awa= re, SFF1 and SFF2 would have to communicate about load-balancing choices.) >=20 > +----+ +----+ +----+ > -----|SFF1|----+----|SFFA|----+----|SFF2|---- > +----+ | +----+ | +----+ > | | > | +----+ | > +----|SFFB|----+ > +----+ >=20 > I suspect the above might make sense for a single-vendor solution, but I = would hope that the standard allows the 4 SFFs to be from different vendors= . >=20 > If SFF1 and SFF2 are from different vendors, we shouldn't rely on implici= t forwarding rules; they should be explicitly configured; one method is to = create explicit paths; another method would be standardizing the classifica= tion rules used for load-balancing. >=20 > If the above figure *is* a single-vendor solution (perhaps a server farm = with load-balancing), then the above figure can appear as a single SFF from= the protocol point of view. >=20 > Vendor load-balancing solution, presenting the scalable system as a singl= e SFF: >=20 > +-----------------------------------------+ > | | > | +----+ +----+ +----+ | > -----|LB1 |----+----|SF |----+----| LB2|---- > | +----+ | +----+ | +----+ | > | | | | > | | +----+ | | > | +----|SF |----+ | > | +----+ | > |SFF | > +-----------------------------------------+ >=20 >=20 > In summary, I have trouble with allowing "discretion" in forwarding betwe= en SFFs. It should all be explicit. >=20 > One could argue that it is useful for the unidirectional chaining cases, = I suppose. But explicit always works. >=20 >=20 > David Dolson > Senior Software Architect, Sandvine Inc. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct > Sent: Tuesday, July 15, 2014 9:45 AM > To: Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Since folks have requested that SFF have discretion on selecting next-SFF= , it is important that the SFP scoping be able to restrict the set of SFFs = which will be used for the traffic. > At the same time, it is also true that the scoping can provide restrictio= n on which instances (among those available to the SFF that could be used f= or the service chain) will be used. >=20 > Net: It is important that the scoping allow for selecting SFFs. it is re= asonable to also allow restriction on service function instantiations. >=20 > I want to be careful because if there is a load balancer hanging off of t= he SFF, then I do not see how this scoping can affect the load balancer ins= tance selection. When the SFF has an integral load balancer, then such res= triction can take effect. >=20 > Yours, > Joel >=20 >> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >> Hi Joel, >>=20 >>> To rephrase this a bit (and then if folks agree on the concept, we=20 >>> can pick the >>> wording): >>>=20 >>> The SFP provides a level of indirection between the fully abstract=20 >>> notion of service path as a sequence of functions to be delivered,=20 >>> and the fully specified notion of exactly what instances of SFFs the=20 >>> packet will visit when it actually traverses the network. >>=20 >> Instances of SFFs or instances of SF? >>=20 >>> By allowing the control components to specify the use of this level=20 >>> of indirection, the deployment may choose the degree of SFF instance=20 >>> selection authority that is delegated to the network. >>=20 >> SFF instance or SF instance? >>=20 >> Best regards, >> Xiaohu >>=20 >>> Yours, >>> Joel >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 15 09:00:28 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC51B28D1 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mx8U7bYVRAVn for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:00:24 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BB1B28CF for <sfc@ietf.org>; Tue, 15 Jul 2014 09:00:24 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id CDED353E11; Tue, 15 Jul 2014 09:00:16 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Tue, 15 Jul 2014 09:00:16.811 -0700 x-echoworx-msg-id: fa58bb01-ffb9-4084-895a-919221366636 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 691; Tue, 15 Jul 2014 09:00:16 -0700 (PDT) Received: from HUB021-CA-8.exch021.domain.local (unknown [10.254.4.112]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id AE24253E04; Tue, 15 Jul 2014 09:00:16 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 09:00:23 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: Dave Dolson <ddolson@sandvine.com> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3d+yX9HZ8tJTkGQvyL0uIwtppug2KMAgADD0ACAABzAAP//i/vwgAB784D//4sPuIAAAKX6 Date: Tue, 15 Jul 2014 16:00:23 +0000 Message-ID: <CC9141A3-4E8D-4F67-9137-A97A01A4FA21@affirmednetworks.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local>, <E8355113905631478EFF04F5AA706E9830A2F69F@wtl-exchp-2.sandvine.com>, <B8B3E329-A29E-4560-8E95-4E28AA5C480C@affirmednetworks.com> In-Reply-To: <B8B3E329-A29E-4560-8E95-4E28AA5C480C@affirmednetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/miU_xqOh_yYC6wlraTMw1wcBjKo Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 16:00:26 -0000 And, I might also add, local SFI selection.=20 Ron > On Jul 15, 2014, at 11:58 AM, "Ron Parker" <Ron_Parker@affirmednetworks.c= om> wrote: >=20 > Yes. Also, learning of flow state will facilitate next SFF selection in= the forward direction.=20 >=20 > Ron >=20 >=20 >> On Jul 15, 2014, at 11:56 AM, "Dave Dolson" <ddolson@sandvine.com> wrote= : >>=20 >> Ron, >> To clarify, are you suggesting SFFs remember flow state so as to be able= to make the correct decision in the opposite direction? (Like Ethernet MA= C learning?) =20 >>=20 >> -Dave >>=20 >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 >> Sent: Tuesday, July 15, 2014 11:37 AM >> To: Dave Dolson; Joel Halpern Direct; Xuxiaohu; sfc@ietf.org >> Subject: RE: [sfc] Proposed redefinition of SFP >>=20 >> Hi, Dave. >>=20 >> I agree that symmetrical is the more typical case. In order to do thei= r jobs, many SFF implementations will be stateful at the flow level. When= learning a flow in the "forward" direction, it should be possible to disce= rn and retain the previous hop instance (i.e., an SFF or an ingress border = node/classifier) for purposes of managing the "reverse" flow in a symmetric= al manner. Whether this recognition of previous hop is solely at the tran= sport layer or whether some protocol fields need to be introduced to NSH/SC= H is for further consideration. Also, the architecture spec can call out = this mode of behavior explicitly in terms of SFF functional requirements. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, July 15, 2014 11:28 AM >> To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org >> Subject: Re: [sfc] Proposed redefinition of SFP >>=20 >> Giving SFFs forwarding discretion troubles me, considering multiple vend= ors and bidirectional traffic, and this is why: >>=20 >> When an SFF has some freedom to choose the next-SFF, this amounts to an = implicit (possibly opaque) forwarding rule. >> Consider implicit rules in the context of bidirectional traffic, when a = stateful SF needs to see both directions of any given flow. >>=20 >> For the bidirectional case, a stateful SF would need to be book-ended wi= th SFFs having compatible implicit forwarding rules. >>=20 >> In this picture, SFF1 and SFF2 would need to have compatible implicit fo= rwarding rules so that stateful SFFA and SFFB receive the same flows.=20 >> ("Compatible" may mean anti-symmetric, such as balancing by source IP in= one case and destination IP in the other case. If the balancing is load-aw= are, SFF1 and SFF2 would have to communicate about load-balancing choices.) >>=20 >> +----+ +----+ +----+ >> -----|SFF1|----+----|SFFA|----+----|SFF2|---- >> +----+ | +----+ | +----+ >> | | >> | +----+ | >> +----|SFFB|----+ >> +----+ >>=20 >> I suspect the above might make sense for a single-vendor solution, but I= would hope that the standard allows the 4 SFFs to be from different vendor= s. >>=20 >> If SFF1 and SFF2 are from different vendors, we shouldn't rely on implic= it forwarding rules; they should be explicitly configured; one method is to= create explicit paths; another method would be standardizing the classific= ation rules used for load-balancing. >>=20 >> If the above figure *is* a single-vendor solution (perhaps a server farm= with load-balancing), then the above figure can appear as a single SFF fro= m the protocol point of view. >>=20 >> Vendor load-balancing solution, presenting the scalable system as a sing= le SFF: >>=20 >> +-----------------------------------------+ >> | | >> | +----+ +----+ +----+ | >> -----|LB1 |----+----|SF |----+----| LB2|---- >> | +----+ | +----+ | +----+ | >> | | | | >> | | +----+ | | >> | +----|SF |----+ | >> | +----+ | >> |SFF | >> +-----------------------------------------+ >>=20 >>=20 >> In summary, I have trouble with allowing "discretion" in forwarding betw= een SFFs. It should all be explicit. >>=20 >> One could argue that it is useful for the unidirectional chaining cases,= I suppose. But explicit always works. >>=20 >>=20 >> David Dolson >> Senior Software Architect, Sandvine Inc. >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >> Sent: Tuesday, July 15, 2014 9:45 AM >> To: Xuxiaohu; sfc@ietf.org >> Subject: Re: [sfc] Proposed redefinition of SFP >>=20 >> Since folks have requested that SFF have discretion on selecting next-SF= F, it is important that the SFP scoping be able to restrict the set of SFFs= which will be used for the traffic. >> At the same time, it is also true that the scoping can provide restricti= on on which instances (among those available to the SFF that could be used = for the service chain) will be used. >>=20 >> Net: It is important that the scoping allow for selecting SFFs. it is r= easonable to also allow restriction on service function instantiations. >>=20 >> I want to be careful because if there is a load balancer hanging off of = the SFF, then I do not see how this scoping can affect the load balancer in= stance selection. When the SFF has an integral load balancer, then such re= striction can take effect. >>=20 >> Yours, >> Joel >>=20 >>> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >>> Hi Joel, >>>=20 >>>> To rephrase this a bit (and then if folks agree on the concept, we=20 >>>> can pick the >>>> wording): >>>>=20 >>>> The SFP provides a level of indirection between the fully abstract=20 >>>> notion of service path as a sequence of functions to be delivered,=20 >>>> and the fully specified notion of exactly what instances of SFFs the= =20 >>>> packet will visit when it actually traverses the network. >>>=20 >>> Instances of SFFs or instances of SF? >>>=20 >>>> By allowing the control components to specify the use of this level=20 >>>> of indirection, the deployment may choose the degree of SFF instance= =20 >>>> selection authority that is delegated to the network. >>>=20 >>> SFF instance or SF instance? >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> Yours, >>>> Joel >>>>=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 nobody Tue Jul 15 09:07:18 2014 Return-Path: <lucy.yong@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CEF1B28F4 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 efibi5O8f9Uc for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:07:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706D61B28F3 for <sfc@ietf.org>; Tue, 15 Jul 2014 09:06:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHF44638; Tue, 15 Jul 2014 16:06:36 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 17:06:35 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 09:06:23 -0700 From: Lucy yong <lucy.yong@huawei.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAgf2A//+U8eA= Date: Tue, 15 Jul 2014 16:06:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453BFCD8@dfweml701-chm.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53C54389.9070200@joelhalpern.com> In-Reply-To: <53C54389.9070200@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.65] 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/nAHEHQO4WM-q0EUZsMy6nYlvilU Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 16:07:15 -0000 Is following text clear assuming SFC and SFP term definition in the merged = arch are used? A SFC may have multiple instantiations in a SFC service network, i.e. multi= ple SFPs. A SFP selection may further constraint by the policies at the cla= ssifier. A SFP identifier in SFC header is inserted by the classifier to di= fferentiate from other SFPs. However, a set of SF instances in the SFP of a= SFC may be dynamically or statically selected when the traffic traverse th= e network. The network implementation must avoid the flow packets re-order = when the flow packets pass through the network. Lucy =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, July 15, 2014 10:07 AM To: mohamed.boucadair@orange.com; Tom Taylor; sfc@ietf.org; Ron Parker Subject: Re: [sfc] SFC Terminology / Concepts My concern is that there are requests (which I happen to support) for allow= ing a degree of policy expression or scope restriction in what the classifi= cation communicates to the infrastructure about the service delivery. This= needs to include restrictions on SFF selection and probably at least allow= for restrictions on ctual instance selection. Given that the restriction includes the case "allow all", expressing the in= formation in terms of this intermediate allows for the requirement, allows = for the communication of the equivalent of the unlimited chain, and allows = for expression of the exact choice when operations has selected that behavi= or. Communicating the chain does not add anything to this, and if it were used = instead of the itnermediate it would remove the ability to meet the require= ments. Yours, Joel On 7/15/14, 3:21 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > As mentioned in several messages, I'm personally for the use of the chain= itself is the main information to be conveyed in packets to drive forwardi= ng actions. > > I can understand that an identifier can be assigned to a path that is kno= wn in advance, but if that path is not known I'm not sure how an identifier= can be assigned to it! > > Joel, the use of "path" is really inappropriate to refer to distributed i= nstance selection process for packets bound to a given SFC. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org;=20 >> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >> >> The most likely realization of the architecture would be that the SFP=20 >> assignment is recorded in an identifier which travels with the packet. >> >> Some folks seem to not want the architecture to mandate that. >> >> Yours, >> Joel >> >> >> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>> Your text scares me because it introduces some new concepts and=20 >>> assumptions. >>> >>> I'd rather go with Joel's formulation. Clarifying question on that:=20 >>> am I right in seeing the implication that when control assigns an=20 >>> SFP, the assignment is recorded by an identifier wwhich travels with th= e packet? >>> >>> Tom Taylor >>> >>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>> There is one missing word in my text. Please replace my proposed tex= t >>>> with: >>>> >>>> "The Service Function Chain (SFC) provides a fully abstract view of=20 >>>> the service functions to be invoked and the order in which they are=20 >>>> to be invoked for some particular flow or set of flows, without concer= n of >>>> actual service function instance selection. The Constrained-SFC >>>> (C-SFC) further allows for policy constraints to be added to the=20 >>>> SFC affecting the instance selection of one or more of the service fun= ctions >>>> in the SFC. Any SFC may have any number of C-SFC's associated with >> it." >>>> >>>> Thanks. >>>> >>>> Ron >>> ... >>> >>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan=20 >>>> I >>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>> >>>> I like that text, it strikes a good balance where an implementation=20 >>>> has the option of making scale and resiliency a local matter.. >>>> >>>> D >>>> >>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>> Guichard >>>> (jguichar) >>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>>> *Subject:* [sfc] SFC Terminology / Concepts >>>> >>>> Dear WG: >>>> >>>> There has been much debate over the last few days with regards to=20 >>>> SFC concepts. To try and form some consensus around terminology and=20 >>>> concepts used to describe the architecture in the merged=20 >>>> architecture draft, Joel has kindly suggested the following: >>>> >>>> "The SFP provides a level of indirection between the fully abstract=20 >>>> notion of service path as a sequence of functions to be delivered,=20 >>>> and the fully specified notion of exactly what instances of SFFs=20 >>>> the packet will visit when it actually traverses the network. By=20 >>>> allowing the control components to specify the use of this level of=20 >>>> indirection, the deployment may choose the degree of SFF instance=20 >>>> selection authority that is delegated to the network." >>>> >>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>> something that we can get consensus on. If so, I'll ask Joel to=20 >>>> provide specific text, that reflects the above, for inclusion in=20 >>>> the merged architecture draft. >>>> >>>> Thank You, >>>> >>>> Jim >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Tue Jul 15 09:14:08 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D021B28C3 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjbBlrEHKqDK for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:14:03 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBA31A0A87 for <sfc@ietf.org>; Tue, 15 Jul 2014 09:14:03 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id b4355c35.2b68a6a10940.299636.00-2461.839856.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Tue, 15 Jul 2014 16:14:03 +0000 (UTC) X-MXL-Hash: 53c5534b4177709e-ab40fc3d721e4168ae9b9b622c291c98a308a14a Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 84355c35.0.299615.00-2287.839790.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Tue, 15 Jul 2014 16:14:01 +0000 (UTC) X-MXL-Hash: 53c553497d886ca6-1fc3f0a1f03150da0a03a047fdc5a605b6ddd7bb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6FGDxZK026135; Tue, 15 Jul 2014 12:14:00 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6FGDhV6025735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2014 12:13:50 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 15 Jul 2014 16:13:26 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 12:13:25 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Tom Taylor" <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAR5eAgAAU+ACAAMCSAIAAGHQAgAA4w6A= Date: Tue, 15 Jul 2014 16:13:25 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=YYkKEXtf c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gqfbR3uhTkYA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=6a4SMSUH4UMsWAU] X-AnalysisOut: [_EusA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA] X-AnalysisOut: [:10 a=F4eoByKhNURBZJQ0:21 a=Qr8Z_014vQ8-z4qE:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ALybeMXoKHomOBn3bfer97bxDoE Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 16:14:05 -0000 An SFC is traffic engineered or it is not traffic engineered. There is noth= ing in-between. Maria > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 15, 2014 4:49 AM > To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Hi Med, >=20 > IMHO, the architecture should allow the classifier to specify >=20 > 1) a partial SFP (i.e., some SFFs along that partial SFP need to locally > determine the appropriate SFF for the next SF); > 2) a complete SFP (i.e., the SFF for each SF in the SFC has been determin= ed > by the centralized node); > 3) an SFC (i.e., each SFF along the final SFP needs to locally determine = the > appropriate SFF for the next SF). >=20 > In fact, case 3) could be looked as an extreme of case 1). >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, July 15, 2014 3:22 PM > > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > > Subject: Re: [sfc] SFC Terminology / Concepts > > > > Hi Joel, > > > > As mentioned in several messages, I'm personally for the use of the cha= in > itself is > > the main information to be conveyed in packets to drive forwarding > actions. > > > > I can understand that an identifier can be assigned to a path that is > known in > > advance, but if that path is not known I'm not sure how an identifier c= an > be > > assigned to it! > > > > Joel, the use of "path" is really inappropriate to refer to distributed > instance > > selection process for packets bound to a given SFC. > > > > Cheers, > > Med > > > > >-----Message d'origine----- > > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > > >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf.= org; Ron > > >Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts > > > > > >The most likely realization of the architecture would be that the SFP > > >assignment is recorded in an identifier which travels with the packet. > > > > > >Some folks seem to not want the architecture to mandate that. > > > > > >Yours, > > >Joel > > > > > > > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: > > >> Your text scares me because it introduces some new concepts and > > >> assumptions. > > >> > > >> I'd rather go with Joel's formulation. Clarifying question on that: > > >> am I right in seeing the implication that when control assigns an > > >> SFP, the assignment is recorded by an identifier wwhich travels with > the > > packet? > > >> > > >> Tom Taylor > > >> > > >> On 14/07/2014 2:22 PM, Ron Parker wrote: > > >>> There is one missing word in my text. Please replace my proposed > text > > >>> with: > > >>> > > >>> "The Service Function Chain (SFC) provides a fully abstract view of > > >>> the service functions to be invoked and the order in which they are > > >>> to be invoked for some particular flow or set of flows, without > concern of > > >>> actual service function instance selection. The Constrained-SFC > > >>> (C-SFC) further allows for policy constraints to be added to the SF= C > > >>> affecting the instance selection of one or more of the service > functions > > >>> in the SFC. Any SFC may have any number of C-SFC's associated wit= h > > >it." > > >>> > > >>> Thanks. > > >>> > > >>> Ron > > >> ... > > >> > > >> > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan > > >>> I > > >>> *Sent:* Monday, July 14, 2014 2:03 PM > > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > > >>> > > >>> I like that text, it strikes a good balance where an implementation > > >>> has the option of making scale and resiliency a local matter.. > > >>> > > >>> D > > >>> > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichar= d > > >>> (jguichar) > > >>> *Sent:* Monday, July 14, 2014 10:48 AM > > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > > >>> *Subject:* [sfc] SFC Terminology / Concepts > > >>> > > >>> Dear WG: > > >>> > > >>> There has been much debate over the last few days with regards to > > >>> SFC concepts. To try and form some consensus around terminology > and > > >>> concepts used to describe the architecture in the merged > > >>> architecture draft, Joel has kindly suggested the following: > > >>> > > >>> "The SFP provides a level of indirection between the fully abstract > > >>> notion of service path as a sequence of functions to be delivered, > > >>> and the fully specified notion of exactly what instances of SFFs th= e > > >>> packet will visit when it actually traverses the network. By > > >>> allowing the control components to specify the use of this level of > > >>> indirection, the deployment may choose the degree of SFF instance > > >>> selection authority that is delegated to the network." > > >>> > > >>> I'd like to ask the WG as a whole, if this clarification is > > >>> something that we can get consensus on. If so, I'll ask Joel to > > >>> provide specific text, that reflects the above, for inclusion in th= e > > >>> merged architecture draft. > > >>> > > >>> Thank You, > > >>> > > >>> Jim > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > >> > > > > > >_______________________________________________ > > >sfc mailing 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 From nobody Tue Jul 15 09:26:39 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27E71A0A8D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:26:37 -0700 (PDT) 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 ASP_-hzxH3pc for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:26:35 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A6C1A0A87 for <sfc@ietf.org>; Tue, 15 Jul 2014 09:26:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id C25B0D4096E; Tue, 15 Jul 2014 09:26:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 572A3D408C7; Tue, 15 Jul 2014 09:26:32 -0700 (PDT) Message-ID: <53C55637.8010406@joelhalpern.com> Date: Tue, 15 Jul 2014 12:26:31 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H" <mn1921@att.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/eSOmSi4QOsMWoe5aBdGP39yCazo Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 16:26:38 -0000 There are several possible interpretations of this comment. Given that it is clear that traffic engineering may specify its results with different resolutions, the interpretation I end up with is that anything which specifies any constraints is "traffic engineered". If that is the intended meaning, then since the empty set is a valid set of constraints, then my approach is to always work in traffic-engineered spaces, where that traffic engineering may be trivial, complete, or in-between. Is that what you mean? Yours, Joel On 7/15/14, 12:13 PM, NAPIERALA, MARIA H wrote: > An SFC is traffic engineered or it is not traffic engineered. There is nothing in-between. > > Maria > >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >> Sent: Tuesday, July 15, 2014 4:49 AM >> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >> sfc@ietf.org; Ron Parker >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Hi Med, >> >> IMHO, the architecture should allow the classifier to specify >> >> 1) a partial SFP (i.e., some SFFs along that partial SFP need to locally >> determine the appropriate SFF for the next SF); >> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been determined >> by the centralized node); >> 3) an SFC (i.e., each SFF along the final SFP needs to locally determine the >> appropriate SFF for the next SF). >> >> In fact, case 3) could be looked as an extreme of case 1). >> >> Best regards, >> Xiaohu >> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Tuesday, July 15, 2014 3:22 PM >>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>> >>> Hi Joel, >>> >>> As mentioned in several messages, I'm personally for the use of the chain >> itself is >>> the main information to be conveyed in packets to drive forwarding >> actions. >>> >>> I can understand that an identifier can be assigned to a path that is >> known in >>> advance, but if that path is not known I'm not sure how an identifier can >> be >>> assigned to it! >>> >>> Joel, the use of "path" is really inappropriate to refer to distributed >> instance >>> selection process for packets bound to a given SFC. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>> Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; sfc@ietf.org; Ron >>>> Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>> >>>> The most likely realization of the architecture would be that the SFP >>>> assignment is recorded in an identifier which travels with the packet. >>>> >>>> Some folks seem to not want the architecture to mandate that. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>> Your text scares me because it introduces some new concepts and >>>>> assumptions. >>>>> >>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>> am I right in seeing the implication that when control assigns an >>>>> SFP, the assignment is recorded by an identifier wwhich travels with >> the >>> packet? >>>>> >>>>> Tom Taylor >>>>> >>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>> There is one missing word in my text. Please replace my proposed >> text >>>>>> with: >>>>>> >>>>>> "The Service Function Chain (SFC) provides a fully abstract view of >>>>>> the service functions to be invoked and the order in which they are >>>>>> to be invoked for some particular flow or set of flows, without >> concern of >>>>>> actual service function instance selection. The Constrained-SFC >>>>>> (C-SFC) further allows for policy constraints to be added to the SFC >>>>>> affecting the instance selection of one or more of the service >> functions >>>>>> in the SFC. Any SFC may have any number of C-SFC's associated with >>>> it." >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Ron >>>>> ... >>>>> >>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan >>>>>> I >>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> I like that text, it strikes a good balance where an implementation >>>>>> has the option of making scale and resiliency a local matter.. >>>>>> >>>>>> D >>>>>> >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>>>>> (jguichar) >>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Dear WG: >>>>>> >>>>>> There has been much debate over the last few days with regards to >>>>>> SFC concepts. To try and form some consensus around terminology >> and >>>>>> concepts used to describe the architecture in the merged >>>>>> architecture draft, Joel has kindly suggested the following: >>>>>> >>>>>> "The SFP provides a level of indirection between the fully abstract >>>>>> notion of service path as a sequence of functions to be delivered, >>>>>> and the fully specified notion of exactly what instances of SFFs the >>>>>> packet will visit when it actually traverses the network. By >>>>>> allowing the control components to specify the use of this level of >>>>>> indirection, the deployment may choose the degree of SFF instance >>>>>> selection authority that is delegated to the network." >>>>>> >>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>> provide specific text, that reflects the above, for inclusion in the >>>>>> merged architecture draft. >>>>>> >>>>>> Thank You, >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing 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 Tue Jul 15 09:36:57 2014 Return-Path: <mn1921@att.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC31A0A9A for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql8mnKi1k6xl for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 09:36:52 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1ED1A0A96 for <sfc@ietf.org>; Tue, 15 Jul 2014 09:36:51 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 4a855c35.2b688fb87940.318209.00-2411.893342.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Tue, 15 Jul 2014 16:36:52 +0000 (UTC) X-MXL-Hash: 53c558a474ba1b92-2027925f127a90be22e30446fc269fe181387f6d Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 48855c35.0.317886.00-2391.892397.nbfkord-smmo05.seg.att.com (envelope-from <mn1921@att.com>); Tue, 15 Jul 2014 16:36:22 +0000 (UTC) X-MXL-Hash: 53c558865d824f8a-89cb72cbeb1ce2b857c0207184fb04d307a6f377 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6FGaJZU027611; Tue, 15 Jul 2014 12:36:20 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6FGa93Q027449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2014 12:36:12 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 15 Jul 2014 16:35:58 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 12:35:58 -0400 From: "NAPIERALA, MARIA H" <mn1921@att.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAR5eAgAAU+ACAAMCSAIAAGHQAgAA4w6CAAEcKgP//vdxQ Date: Tue, 15 Jul 2014 16:35:58 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFF6@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> <53C55637.8010406@joelhalpern.com> In-Reply-To: <53C55637.8010406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=YYkKEXtf c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gqfbR3uhTkYA:10 a=ofMgfj31e3cA:10 a=a6lYbgGDhh4A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=ABeY7kuGAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=EPuUMzTSnkJqJP6xByoA:9 a=wPNLvfGTeEIA:10 a=chC_agHSu74A:] X-AnalysisOut: [10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10 a=y8MSiPZ1IG3HqS7m:] X-AnalysisOut: [21 a=cQxWH7PW197orOdQ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: <mn1921@att.com> X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9yWRDOz79nuMtaG7JAihUxlALZc Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 16:36:54 -0000 What I meant was that Xiaohu's case (3) is clearly different from (1) and (= 2). BTW, he did not (because he could not) use an SFP to describe it, becau= se it does not apply. I am still voting for text as proposed by Ron. =20 Maria > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, July 15, 2014 12:27 PM > To: NAPIERALA, MARIA H; Xuxiaohu; mohamed.boucadair@orange.com; > Tom Taylor; sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > There are several possible interpretations of this comment. >=20 > Given that it is clear that traffic engineering may specify its results > with different resolutions, the interpretation I end up with is that > anything which specifies any constraints is "traffic engineered". >=20 > If that is the intended meaning, then since the empty set is a valid set > of constraints, then my approach is to always work in traffic-engineered > spaces, where that traffic engineering may be trivial, complete, or > in-between. >=20 > Is that what you mean? >=20 > Yours, > Joel >=20 > On 7/15/14, 12:13 PM, NAPIERALA, MARIA H wrote: > > An SFC is traffic engineered or it is not traffic engineered. There is = nothing > in-between. > > > > Maria > > > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > >> Sent: Tuesday, July 15, 2014 4:49 AM > >> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > >> sfc@ietf.org; Ron Parker > >> Subject: Re: [sfc] SFC Terminology / Concepts > >> > >> Hi Med, > >> > >> IMHO, the architecture should allow the classifier to specify > >> > >> 1) a partial SFP (i.e., some SFFs along that partial SFP need to local= ly > >> determine the appropriate SFF for the next SF); > >> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been > determined > >> by the centralized node); > >> 3) an SFC (i.e., each SFF along the final SFP needs to locally determi= ne > the > >> appropriate SFF for the next SF). > >> > >> In fact, case 3) could be looked as an extreme of case 1). > >> > >> Best regards, > >> Xiaohu > >> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>> mohamed.boucadair@orange.com > >>> Sent: Tuesday, July 15, 2014 3:22 PM > >>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > >>> Subject: Re: [sfc] SFC Terminology / Concepts > >>> > >>> Hi Joel, > >>> > >>> As mentioned in several messages, I'm personally for the use of the > chain > >> itself is > >>> the main information to be conveyed in packets to drive forwarding > >> actions. > >>> > >>> I can understand that an identifier can be assigned to a path that is > >> known in > >>> advance, but if that path is not known I'm not sure how an identifier > can > >> be > >>> assigned to it! > >>> > >>> Joel, the use of "path" is really inappropriate to refer to distribut= ed > >> instance > >>> selection process for packets bound to a given SFC. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > >>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.or= g; Ron > >>>> Parker Objet : Re: [sfc] SFC Terminology / Concepts > >>>> > >>>> The most likely realization of the architecture would be that the SF= P > >>>> assignment is recorded in an identifier which travels with the packe= t. > >>>> > >>>> Some folks seem to not want the architecture to mandate that. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> > >>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: > >>>>> Your text scares me because it introduces some new concepts and > >>>>> assumptions. > >>>>> > >>>>> I'd rather go with Joel's formulation. Clarifying question on that: > >>>>> am I right in seeing the implication that when control assigns an > >>>>> SFP, the assignment is recorded by an identifier wwhich travels wit= h > >> the > >>> packet? > >>>>> > >>>>> Tom Taylor > >>>>> > >>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: > >>>>>> There is one missing word in my text. Please replace my proposed > >> text > >>>>>> with: > >>>>>> > >>>>>> "The Service Function Chain (SFC) provides a fully abstract view o= f > >>>>>> the service functions to be invoked and the order in which they ar= e > >>>>>> to be invoked for some particular flow or set of flows, without > >> concern of > >>>>>> actual service function instance selection. The Constrained-SFC > >>>>>> (C-SFC) further allows for policy constraints to be added to the S= FC > >>>>>> affecting the instance selection of one or more of the service > >> functions > >>>>>> in the SFC. Any SFC may have any number of C-SFC's associated > with > >>>> it." > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> Ron > >>>>> ... > >>>>> > >>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David > Allan > >>>>>> I > >>>>>> *Sent:* Monday, July 14, 2014 2:03 PM > >>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > >>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >>>>>> > >>>>>> I like that text, it strikes a good balance where an implementatio= n > >>>>>> has the option of making scale and resiliency a local matter.. > >>>>>> > >>>>>> D > >>>>>> > >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim > Guichard > >>>>>> (jguichar) > >>>>>> *Sent:* Monday, July 14, 2014 10:48 AM > >>>>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >>>>>> *Subject:* [sfc] SFC Terminology / Concepts > >>>>>> > >>>>>> Dear WG: > >>>>>> > >>>>>> There has been much debate over the last few days with regards to > >>>>>> SFC concepts. To try and form some consensus around terminology > >> and > >>>>>> concepts used to describe the architecture in the merged > >>>>>> architecture draft, Joel has kindly suggested the following: > >>>>>> > >>>>>> "The SFP provides a level of indirection between the fully abstrac= t > >>>>>> notion of service path as a sequence of functions to be delivered, > >>>>>> and the fully specified notion of exactly what instances of SFFs t= he > >>>>>> packet will visit when it actually traverses the network. By > >>>>>> allowing the control components to specify the use of this level o= f > >>>>>> indirection, the deployment may choose the degree of SFF instance > >>>>>> selection authority that is delegated to the network." > >>>>>> > >>>>>> I'd like to ask the WG as a whole, if this clarification is > >>>>>> something that we can get consensus on. If so, I'll ask Joel to > >>>>>> provide specific text, that reflects the above, for inclusion in t= he > >>>>>> merged architecture draft. > >>>>>> > >>>>>> Thank You, > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing 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 Tue Jul 15 10:00:41 2014 Return-Path: <sbarkai@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F21B28E8 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:00:33 -0700 (PDT) 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 vA2ykYGoSIs2 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:00:26 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45D11B28DE for <sfc@ietf.org>; Tue, 15 Jul 2014 10:00:26 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so125261pac.32 for <sfc@ietf.org>; Tue, 15 Jul 2014 10:00:26 -0700 (PDT) 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=QvoCigGlEJzuhUrYg+MhrIyGYGRBhnshkMxjW60Rd6M=; b=PbSAnehmF/YLeImvvLEopn8bDYZIhE3bnEiBAR1kYVmraVq35MNBqY42W9U6gr5k26 6V8SMUWxcT6STIL3nK5IV5C4R7FrnW7dsQOBBr9Ke2w3ebzbZMONGQEkoM9eJTmq2RUV FezoXw4RTg8omu17t3mkGsFLw13NrbAvPmhpVKiFDBDH7AhJQty2/PMQ34IOaC8LW5ah 1kElrpKFmgL3Vgdk3VDaZNVv83oXa+LZU8zsVzz8TgajpS1LAKxwTb/5xoGrOQIdByuL vv98WVXK5hvWiVRyYTK7ovbjvmptSt5eLhvLGu+jSvJ1UGzQs7I5NMm4/L9pLOmNxFgg yQ5Q== X-Received: by 10.66.154.164 with SMTP id vp4mr24373065pab.4.1405443626455; Tue, 15 Jul 2014 10:00:26 -0700 (PDT) Received: from [192.168.1.142] ([157.22.28.27]) by mx.google.com with ESMTPSA id qk9sm60054380pac.16.2014.07.15.10.00.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 10:00:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon <sbarkai@gmail.com> X-Mailer: iPhone Mail (11D257) In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> Date: Tue, 15 Jul 2014 10:00:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7238EF83-D293-4D8F-8A43-370B854BFE78@gmail.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> To: Ron Parker <Ron_Parker@affirmednetworks.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xVhf-PKcgYIVYECBM49AAAD68t8 Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>, Dave Dolson <ddolson@sandvine.com> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 17:00:33 -0000 Sound right. Most SFFs will latch to various flow fields as consistent balan= cing invariants per protocol and as a fast-path forwarding. SFFs can leverag= e also the chaining headers to help manage the context, workflow and reentra= ncy, and as additional local classification. --szb > On Jul 15, 2014, at 8:36 AM, Ron Parker <Ron_Parker@affirmednetworks.com> w= rote: >=20 > Hi, Dave. >=20 > I agree that symmetrical is the more typical case. In order to do their j= obs, many SFF implementations will be stateful at the flow level. When lea= rning a flow in the "forward" direction, it should be possible to discern an= d retain the previous hop instance (i.e., an SFF or an ingress border node/c= lassifier) for purposes of managing the "reverse" flow in a symmetrical mann= er. Whether this recognition of previous hop is solely at the transport la= yer or whether some protocol fields need to be introduced to NSH/SCH is for f= urther consideration. Also, the architecture spec can call out this mode o= f behavior explicitly in terms of SFF functional requirements. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, July 15, 2014 11:28 AM > To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Giving SFFs forwarding discretion troubles me, considering multiple vendor= s and bidirectional traffic, and this is why: >=20 > When an SFF has some freedom to choose the next-SFF, this amounts to an im= plicit (possibly opaque) forwarding rule. > Consider implicit rules in the context of bidirectional traffic, when a st= ateful SF needs to see both directions of any given flow. >=20 > For the bidirectional case, a stateful SF would need to be book-ended with= SFFs having compatible implicit forwarding rules. >=20 > In this picture, SFF1 and SFF2 would need to have compatible implicit forw= arding rules so that stateful SFFA and SFFB receive the same flows.=20 > ("Compatible" may mean anti-symmetric, such as balancing by source IP in o= ne case and destination IP in the other case. If the balancing is load-aware= , SFF1 and SFF2 would have to communicate about load-balancing choices.) >=20 > +----+ +----+ +----+ > -----|SFF1|----+----|SFFA|----+----|SFF2|---- > +----+ | +----+ | +----+ > | | > | +----+ | > +----|SFFB|----+ > +----+ >=20 > I suspect the above might make sense for a single-vendor solution, but I w= ould hope that the standard allows the 4 SFFs to be from different vendors. >=20 > If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit= forwarding rules; they should be explicitly configured; one method is to cr= eate explicit paths; another method would be standardizing the classificatio= n rules used for load-balancing. >=20 > If the above figure *is* a single-vendor solution (perhaps a server farm w= ith load-balancing), then the above figure can appear as a single SFF from t= he protocol point of view. >=20 > Vendor load-balancing solution, presenting the scalable system as a single= SFF: >=20 > +-----------------------------------------+ > | | > | +----+ +----+ +----+ | > -----|LB1 |----+----|SF |----+----| LB2|---- > | +----+ | +----+ | +----+ | > | | | | > | | +----+ | | > | +----|SF |----+ | > | +----+ | > |SFF | > +-----------------------------------------+ >=20 >=20 > In summary, I have trouble with allowing "discretion" in forwarding betwee= n SFFs. It should all be explicit. >=20 > One could argue that it is useful for the unidirectional chaining cases, I= suppose. But explicit always works. >=20 >=20 > David Dolson > Senior Software Architect, Sandvine Inc. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct > Sent: Tuesday, July 15, 2014 9:45 AM > To: Xuxiaohu; sfc@ietf.org > Subject: Re: [sfc] Proposed redefinition of SFP >=20 > Since folks have requested that SFF have discretion on selecting next-SFF,= it is important that the SFP scoping be able to restrict the set of SFFs wh= ich will be used for the traffic. > At the same time, it is also true that the scoping can provide restriction= on which instances (among those available to the SFF that could be used for= the service chain) will be used. >=20 > Net: It is important that the scoping allow for selecting SFFs. it is rea= sonable to also allow restriction on service function instantiations. >=20 > I want to be careful because if there is a load balancer hanging off of th= e SFF, then I do not see how this scoping can affect the load balancer insta= nce selection. When the SFF has an integral load balancer, then such restri= ction can take effect. >=20 > Yours, > Joel >=20 >> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >> Hi Joel, >>=20 >>> To rephrase this a bit (and then if folks agree on the concept, we=20 >>> can pick the >>> wording): >>>=20 >>> The SFP provides a level of indirection between the fully abstract=20 >>> notion of service path as a sequence of functions to be delivered,=20 >>> and the fully specified notion of exactly what instances of SFFs the=20 >>> packet will visit when it actually traverses the network. >>=20 >> Instances of SFFs or instances of SF? >>=20 >>> By allowing the control components to specify the use of this level=20 >>> of indirection, the deployment may choose the degree of SFF instance=20 >>> selection authority that is delegated to the network. >>=20 >> SFF instance or SF instance? >>=20 >> Best regards, >> Xiaohu >>=20 >>> Yours, >>> Joel >>>=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 nobody Tue Jul 15 10:03:01 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9C1A0ABB for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:02:59 -0700 (PDT) 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 TFX0sCBoaJYt for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:02:56 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9EF1B28E8 for <sfc@ietf.org>; Tue, 15 Jul 2014 10:02:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 6204ED404D1; Tue, 15 Jul 2014 10:02:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 67D0DD40527; Tue, 15 Jul 2014 10:02:51 -0700 (PDT) Message-ID: <53C55EBB.7020802@joelhalpern.com> Date: Tue, 15 Jul 2014 13:02:51 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sharon <sbarkai@gmail.com>, Ron Parker <Ron_Parker@affirmednetworks.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> <7238EF83-D293-4D8F-8A43-370B854BFE78@gmail.com> In-Reply-To: <7238EF83-D293-4D8F-8A43-370B854BFE78@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yN8Ko7XfG3hnGiHfxmjXWFOnZzM Cc: Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>, Dave Dolson <ddolson@sandvine.com> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 17:02:59 -0000 I was trying not to require that SFF be stateful load balancers. They certainly can be. But I had hoped tha tthe architecture would not mandate that. Yours, Joel On 7/15/14, 1:00 PM, Sharon wrote: > Sound right. Most SFFs will latch to various flow fields as consistent balancing invariants per protocol and as a fast-path forwarding. SFFs can leverage also the chaining headers to help manage the context, workflow and reentrancy, and as additional local classification. > > --szb > >> On Jul 15, 2014, at 8:36 AM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote: >> >> Hi, Dave. >> >> I agree that symmetrical is the more typical case. In order to do their jobs, many SFF implementations will be stateful at the flow level. When learning a flow in the "forward" direction, it should be possible to discern and retain the previous hop instance (i.e., an SFF or an ingress border node/classifier) for purposes of managing the "reverse" flow in a symmetrical manner. Whether this recognition of previous hop is solely at the transport layer or whether some protocol fields need to be introduced to NSH/SCH is for further consideration. Also, the architecture spec can call out this mode of behavior explicitly in terms of SFF functional requirements. >> >> Ron >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, July 15, 2014 11:28 AM >> To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org >> Subject: Re: [sfc] Proposed redefinition of SFP >> >> Giving SFFs forwarding discretion troubles me, considering multiple vendors and bidirectional traffic, and this is why: >> >> When an SFF has some freedom to choose the next-SFF, this amounts to an implicit (possibly opaque) forwarding rule. >> Consider implicit rules in the context of bidirectional traffic, when a stateful SF needs to see both directions of any given flow. >> >> For the bidirectional case, a stateful SF would need to be book-ended with SFFs having compatible implicit forwarding rules. >> >> In this picture, SFF1 and SFF2 would need to have compatible implicit forwarding rules so that stateful SFFA and SFFB receive the same flows. >> ("Compatible" may mean anti-symmetric, such as balancing by source IP in one case and destination IP in the other case. If the balancing is load-aware, SFF1 and SFF2 would have to communicate about load-balancing choices.) >> >> +----+ +----+ +----+ >> -----|SFF1|----+----|SFFA|----+----|SFF2|---- >> +----+ | +----+ | +----+ >> | | >> | +----+ | >> +----|SFFB|----+ >> +----+ >> >> I suspect the above might make sense for a single-vendor solution, but I would hope that the standard allows the 4 SFFs to be from different vendors. >> >> If SFF1 and SFF2 are from different vendors, we shouldn't rely on implicit forwarding rules; they should be explicitly configured; one method is to create explicit paths; another method would be standardizing the classification rules used for load-balancing. >> >> If the above figure *is* a single-vendor solution (perhaps a server farm with load-balancing), then the above figure can appear as a single SFF from the protocol point of view. >> >> Vendor load-balancing solution, presenting the scalable system as a single SFF: >> >> +-----------------------------------------+ >> | | >> | +----+ +----+ +----+ | >> -----|LB1 |----+----|SF |----+----| LB2|---- >> | +----+ | +----+ | +----+ | >> | | | | >> | | +----+ | | >> | +----|SF |----+ | >> | +----+ | >> |SFF | >> +-----------------------------------------+ >> >> >> In summary, I have trouble with allowing "discretion" in forwarding between SFFs. It should all be explicit. >> >> One could argue that it is useful for the unidirectional chaining cases, I suppose. But explicit always works. >> >> >> David Dolson >> Senior Software Architect, Sandvine Inc. >> >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct >> Sent: Tuesday, July 15, 2014 9:45 AM >> To: Xuxiaohu; sfc@ietf.org >> Subject: Re: [sfc] Proposed redefinition of SFP >> >> Since folks have requested that SFF have discretion on selecting next-SFF, it is important that the SFP scoping be able to restrict the set of SFFs which will be used for the traffic. >> At the same time, it is also true that the scoping can provide restriction on which instances (among those available to the SFF that could be used for the service chain) will be used. >> >> Net: It is important that the scoping allow for selecting SFFs. it is reasonable to also allow restriction on service function instantiations. >> >> I want to be careful because if there is a load balancer hanging off of the SFF, then I do not see how this scoping can affect the load balancer instance selection. When the SFF has an integral load balancer, then such restriction can take effect. >> >> Yours, >> Joel >> >>> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >>> Hi Joel, >>> >>>> To rephrase this a bit (and then if folks agree on the concept, we >>>> can pick the >>>> wording): >>>> >>>> The SFP provides a level of indirection between the fully abstract >>>> notion of service path as a sequence of functions to be delivered, >>>> and the fully specified notion of exactly what instances of SFFs the >>>> packet will visit when it actually traverses the network. >>> >>> Instances of SFFs or instances of SF? >>> >>>> By allowing the control components to specify the use of this level >>>> of indirection, the deployment may choose the degree of SFF instance >>>> selection authority that is delegated to the network. >>> >>> SFF instance or SF instance? >>> >>> Best regards, >>> Xiaohu >>> >>>> Yours, >>>> Joel >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing 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 Tue Jul 15 10:44:22 2014 Return-Path: <sbarkai@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301611A0AD5 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:44:20 -0700 (PDT) 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 C6hBf-t3TliY for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 10:44:18 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B911A0AAC for <sfc@ietf.org>; Tue, 15 Jul 2014 10:44:18 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so2226470pad.35 for <sfc@ietf.org>; Tue, 15 Jul 2014 10:44:18 -0700 (PDT) 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=49AFMt7K5kC5goAEIkvelzma5XGhmqRhFJVYMSXCYK8=; b=RMrvSSJsxOKLaBG4D/Nba7E8Vy3Hwixc7FdPMxInA6cYb4yosmnJ2K/WvhPlhtb/xF 2Ii/WTHBjfF3NDIsfxYlaZQUZtM4rPlPlABdevV80EIO/Go/ocZyZlFd+S3RHGiv5+GY ePy8YqSOKmiCw5ioB6vvog2nj14Zc1ZUZ9LiNk33wUDSfAZfbg6ppBbu0YEj/WqMgx2O 6un23mAYqVbha5DbkbeV89jYe9mFxJFvC44LeDbMDDy7pTfDwBpr1hxP//5to98PrDxV Y9SYlFXr3q30g9t/57PiSDQVYf2foRShUn79Xc1TxlCnvas6JnbaX2KB1GgP+l0Uq6si g0Mg== X-Received: by 10.70.37.225 with SMTP id b1mr24326502pdk.78.1405446257807; Tue, 15 Jul 2014 10:44:17 -0700 (PDT) Received: from [192.168.1.142] ([157.22.28.27]) by mx.google.com with ESMTPSA id nl8sm18847946pdb.2.2014.07.15.10.44.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 10:44:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon <sbarkai@gmail.com> X-Mailer: iPhone Mail (11D257) In-Reply-To: <53C55EBB.7020802@joelhalpern.com> Date: Tue, 15 Jul 2014 10:44:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <613FDC9A-6479-4118-A40E-F675DF850DAB@gmail.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> <7238EF83-D293-4D8F-8A43-370B854BFE78@gmail.com> <53C55EBB.7020802@joelhalpern.com> To: "Joel M. Halpern" <jmh@joelhalpern.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SE_N1HM5a4yPYutN67U8j6ClkT8 Cc: "sfc@ietf.org" <sfc@ietf.org>, Xuxiaohu <xuxiaohu@huawei.com>, Dave Dolson <ddolson@sandvine.com>, Ron Parker <Ron_Parker@affirmednetworks.com> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 17:44:20 -0000 Right Joel, understood that and it may be a good goal in terms of standard s= tructure. However in most use-case analysis of virtualized environment folks= will fast forward to a state-full session managing SFF discussion to clarif= y and educate themselves on how the standard copes with fluid-elastic resour= ce situation. So might as well incorporate Ron's language as optional guidan= ce.=20 --szb > On Jul 15, 2014, at 10:02 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrot= e: >=20 > I was trying not to require that SFF be stateful load balancers. > They certainly can be. But I had hoped tha tthe architecture would not ma= ndate that. > Yours, > Joel >=20 >> On 7/15/14, 1:00 PM, Sharon wrote: >> Sound right. Most SFFs will latch to various flow fields as consistent ba= lancing invariants per protocol and as a fast-path forwarding. SFFs can leve= rage also the chaining headers to help manage the context, workflow and reen= trancy, and as additional local classification. >>=20 >> --szb >>=20 >>> On Jul 15, 2014, at 8:36 AM, Ron Parker <Ron_Parker@affirmednetworks.com= > wrote: >>>=20 >>> Hi, Dave. >>>=20 >>> I agree that symmetrical is the more typical case. In order to do thei= r jobs, many SFF implementations will be stateful at the flow level. When l= earning a flow in the "forward" direction, it should be possible to discern a= nd retain the previous hop instance (i.e., an SFF or an ingress border node/= classifier) for purposes of managing the "reverse" flow in a symmetrical man= ner. Whether this recognition of previous hop is solely at the transport l= ayer or whether some protocol fields need to be introduced to NSH/SCH is for= further consideration. Also, the architecture spec can call out this mode= of behavior explicitly in terms of SFF functional requirements. >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Tuesday, July 15, 2014 11:28 AM >>> To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org >>> Subject: Re: [sfc] Proposed redefinition of SFP >>>=20 >>> Giving SFFs forwarding discretion troubles me, considering multiple vend= ors and bidirectional traffic, and this is why: >>>=20 >>> When an SFF has some freedom to choose the next-SFF, this amounts to an i= mplicit (possibly opaque) forwarding rule. >>> Consider implicit rules in the context of bidirectional traffic, when a s= tateful SF needs to see both directions of any given flow. >>>=20 >>> For the bidirectional case, a stateful SF would need to be book-ended wi= th SFFs having compatible implicit forwarding rules. >>>=20 >>> In this picture, SFF1 and SFF2 would need to have compatible implicit fo= rwarding rules so that stateful SFFA and SFFB receive the same flows. >>> ("Compatible" may mean anti-symmetric, such as balancing by source IP in= one case and destination IP in the other case. If the balancing is load-awa= re, SFF1 and SFF2 would have to communicate about load-balancing choices.) >>>=20 >>> +----+ +----+ +----+ >>> -----|SFF1|----+----|SFFA|----+----|SFF2|---- >>> +----+ | +----+ | +----+ >>> | | >>> | +----+ | >>> +----|SFFB|----+ >>> +----+ >>>=20 >>> I suspect the above might make sense for a single-vendor solution, but I= would hope that the standard allows the 4 SFFs to be from different vendors= . >>>=20 >>> If SFF1 and SFF2 are from different vendors, we shouldn't rely on implic= it forwarding rules; they should be explicitly configured; one method is to c= reate explicit paths; another method would be standardizing the classificati= on rules used for load-balancing. >>>=20 >>> If the above figure *is* a single-vendor solution (perhaps a server farm= with load-balancing), then the above figure can appear as a single SFF from= the protocol point of view. >>>=20 >>> Vendor load-balancing solution, presenting the scalable system as a sing= le SFF: >>>=20 >>> +-----------------------------------------+ >>> | | >>> | +----+ +----+ +----+ | >>> -----|LB1 |----+----|SF |----+----| LB2|---- >>> | +----+ | +----+ | +----+ | >>> | | | | >>> | | +----+ | | >>> | +----|SF |----+ | >>> | +----+ | >>> |SFF | >>> +-----------------------------------------+ >>>=20 >>>=20 >>> In summary, I have trouble with allowing "discretion" in forwarding betw= een SFFs. It should all be explicit. >>>=20 >>> One could argue that it is useful for the unidirectional chaining cases,= I suppose. But explicit always works. >>>=20 >>>=20 >>> David Dolson >>> Senior Software Architect, Sandvine Inc. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Direct= >>> Sent: Tuesday, July 15, 2014 9:45 AM >>> To: Xuxiaohu; sfc@ietf.org >>> Subject: Re: [sfc] Proposed redefinition of SFP >>>=20 >>> Since folks have requested that SFF have discretion on selecting next-SFF= , it is important that the SFP scoping be able to restrict the set of SFFs w= hich will be used for the traffic. >>> At the same time, it is also true that the scoping can provide restricti= on on which instances (among those available to the SFF that could be used f= or the service chain) will be used. >>>=20 >>> Net: It is important that the scoping allow for selecting SFFs. it is r= easonable to also allow restriction on service function instantiations. >>>=20 >>> I want to be careful because if there is a load balancer hanging off of t= he SFF, then I do not see how this scoping can affect the load balancer inst= ance selection. When the SFF has an integral load balancer, then such restr= iction can take effect. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >>>> Hi Joel, >>>>=20 >>>>> To rephrase this a bit (and then if folks agree on the concept, we >>>>> can pick the >>>>> wording): >>>>>=20 >>>>> The SFP provides a level of indirection between the fully abstract >>>>> notion of service path as a sequence of functions to be delivered, >>>>> and the fully specified notion of exactly what instances of SFFs the >>>>> packet will visit when it actually traverses the network. >>>>=20 >>>> Instances of SFFs or instances of SF? >>>>=20 >>>>> By allowing the control components to specify the use of this level >>>>> of indirection, the deployment may choose the degree of SFF instance >>>>> selection authority that is delegated to the network. >>>>=20 >>>> SFF instance or SF instance? >>>>=20 >>>> Best regards, >>>> Xiaohu >>>>=20 >>>>> Yours, >>>>> Joel >>>>>=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 nobody Tue Jul 15 11:10:45 2014 Return-Path: <linda.dunbar@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4FC1A04E7 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 11:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 tAnf1CzkFx6M for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 11:10:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080A81A0AD9 for <sfc@ietf.org>; Tue, 15 Jul 2014 11:10:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB66961; Tue, 15 Jul 2014 18:10:33 +0000 (GMT) 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; Tue, 15 Jul 2014 19:10:30 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml705-chm.china.huawei.com ([169.254.7.240]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 11:10:19 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: Ian Smith <I.Smith@F5.com>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8Yu6hrX+B2q06coaQPid25M5uXlPYAgACF5yCAAE1ZAP//wLSggAB+LwCAAAZngIAABK4AgAAAgACAAAEoAP//i9IAgAB47YD//4tgsAAPPlwAAA6ksRD//5MmAIABKX+AgAABkYCAAAXiAIABxGYAgABmtQCAANRKgIAAHRuAgAAdJQCAABCXgP/7yNwQ Date: Tue, 15 Jul 2014 18:10:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.165] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9CFE0dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XiEF9ZBduShavvVO3mX2d6Zfy6g Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 18:10:44 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9CFE0dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian, Try to clarify the terminology you used: Does "Selecting a decider" mean "selecting with SFFs"? Does "Selecting an actor" mean "the SFF that determine which local instance= s to use"? To me, there are two levels of decision: - Network level decision (which is pretty much same as today's rou= ter hops) - Node level decision (which local instance to use). Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com<mailto= :Ron_Parker@affirmednetworks.com>> wrote: Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; sfc@i= etf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com<mailto:er= ic.gray@ericsson.com>> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucadai= r@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucada= ir@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucad= air@orange.com>; NAPIERALA, >> MARIA H; >>> sfc@ietf.org<mailto:sfc@ietf.org> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.co= m>> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bouca= dair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bou= cadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.b= oucadair@orange.com>; >> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com<mailto:mo= hamed.boucadair@orange.com>; >>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org<mailto:sfc@ietf.org> >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org<mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645D9CFE0dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} p.emailquote, li.emailquote, div.emailquote {mso-style-name:emailquote; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:1.0pt; border:none; padding:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:568806440; mso-list-type:hybrid; mso-list-template-ids:-135481840 1182419374 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-start-at:800; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Calibri","sans-serif"; mso-fareast-font-family:SimSun; mso-bidi-font-family:"Times New Roman";} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Ian,<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Try to clarify the termin= ology you used:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Does “Selecting a d= ecider” mean “selecting with SFFs”? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Does “Selecting an = actor” mean “the SFF that determine which local instances to us= e”?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">To me, there are two leve= ls of decision:<o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level= 1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q= uot;Calibri","sans-serif";color:#1F497D"><span style=3D"mso-= list:Ignore">-<span style=3D"font:7.0pt "Times New Roman""> =          </span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:= "Calibri","sans-serif";color:#1F497D">Network level dec= ision (which is pretty much same as today’s router hops)<o:p></o:p></= span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level= 1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q= uot;Calibri","sans-serif";color:#1F497D"><span style=3D"mso-= list:Ignore">-<span style=3D"font:7.0pt "Times New Roman""> =          </span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:= "Calibri","sans-serif";color:#1F497D">Node level decisi= on (which local instance to use). <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ian Smith<br> <br> </span><o:p></o:p></p> </div> </div> <div> <p>But the actual point I was trying to make is that there is a consistent = semantic difference between 'selecting a decider' which is what you do if y= ou make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an a= ctor' which is what you do when you make a next hop selection amongst SFIs, and you should differentiate b= etween them.<o:p></o:p></p> <div> <p class=3D"MsoNormal">On Jul 12, 2014 1:43 PM, Ron Parker <<a href=3D"m= ailto:Ron_Parker@affirmednetworks.com">Ron_Parker@affirmednetworks.com</a>&= gt; wrote:<o:p></o:p></p> </div> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt">Ian,<br> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.= org</a>; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.= org</a>; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; <a href=3D"mailto:mohamed.boucadair@orange.com"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.= org</a><br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <<a href=3D"mailto:eric.gra= y@ericsson.com">eric.gray@ericsson.com</a>> wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com">mailto:mn1= 921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com">m= ohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-boun= ces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.co= m">mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orang= e.com">mohamed.boucadair@orange.com</a>; NAPIERALA,<br> >> MARIA H;<br> >>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com">Ron= _Parker@affirmednetworks.com</a>> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@o= range.com">mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com">Ron_Par= ker@affirmednetworks.com</a>> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> <a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucad= air@orange.com</a>;<br> >>>>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com">Ron_Par= ker@affirmednetworks.com</a>> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= >mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com">mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>> w= rote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com">mailto:jguichar@cisco.com</a>]<br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:moh= amed.boucadair@orange.com">mohamed.boucadair@orange.com</a>;<br> >> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com">mn1921@att.com</a>><b= r> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Joel= <br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; <a= href=3D"mailto:mohamed.boucadair@orange.com"> mohamed.boucadair@orange.com</a>;<br> >>>>>>>>>> <a href=3D"mailto:sfc@ietf.org">sf= c@ietf.org</a><br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> <a href=3D"mailto:sfc@ietf= .org">sfc@ietf.org</a><br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><b= r> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> <a href=3D"mailto:sfc@ietf.org= ">sfc@ietf.org</a><br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> <a href=3D"mailto:sfc@ietf.org">sfc@ie= tf.org</a><br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><b= r> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">= https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">http= s://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.= ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf= .org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc">https://www.ietf.org/= mailman/listinfo/sfc</a><o:p></o:p></span></p> </div> </div> </body> </html> --_000_4A95BA014132FF49AE685FAB4B9F17F645D9CFE0dfweml701chmchi_-- From nobody Tue Jul 15 11:32:09 2014 Return-Path: <I.Smith@f5.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECCC1A04E7 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 11:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 oaaIf7L4b89q for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 11:32:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF8F1A0AFD for <sfc@ietf.org>; Tue, 15 Jul 2014 11:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="121839094" X-IPAS-Result: AiAHADD7RVPAqArr/2dsb2JhbAAXQoJCf1e8RxeHNYE3dIIlAQEBAQIBAQEBCwwBSgkLBQcEAgEIEQEDAQEBChYBBgchBgsUAwYIAgQBDQUIE4dNAwkVile6Iw2HCRMEjFOBQiYGIQYEBgECBIMegRQElHGBf4xigX+If4FqQQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 15 Jul 2014 18:31:58 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 11:31:57 -0700 From: Ian Smith <I.Smith@F5.com> To: Linda Dunbar <linda.dunbar@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers Thread-Index: AQHPmx8RfE5WURD9LkKiG2QTwhLTGJuXx0EAgADJnoCAAAmiAIAABYCAgAAHGACAAAZngIAABK4AgAAAgACAAAEoAIAAAagAgAADF4CAAADNgIAABIUAgAADigCAAATDAIABKX+AgAABkICAAAXiAIABxGYAgABmtQCAANRKgP//pzgmgACTCAD//5s/V4AFIySA//+LUek= Date: Tue, 15 Jul 2014 18:31:57 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A8436F5@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A8436F5SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/I42rL8KP8b3twEz_E3xAhS9nqZY Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 18:32:06 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A8436F5SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Linda - "actor" is a generic way of talking about the part of a system that actuall= y _does_ the thing. In this context that means _a particular instance of a= service function_ "decider" is a generic way of talking about parts of the system that will m= ake decisions about which actor will be used. In this context it means a S= NF, SFF, or a control/policy plane decision engine _when they are selecting= SFIs_. I think of it as being three decisions: 1. the network - function selection (bridging and routing, anycast/multi= cast, tenant domain, etc.); 2. the service - function selection + service selection (policy route, l= abel switching, GSLB, virtual server destination (ip:port), traffic classif= ication, etc.); 3. the instance - function selection + service selection + instance sele= ction (LB pool member selection, DNS SRV & ENUM); ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 2:10 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel= M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Ian, Try to clarify the terminology you used: Does =93Selecting a decider=94 mean =93selecting with SFFs=94? Does =93Selecting an actor=94 mean =93the SFF that determine which local in= stances to use=94? To me, there are two levels of decision: - Network level decision (which is pretty much same as today=92s r= outer hops) - Node level decision (which local instance to use). Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com<mailto= :Ron_Parker@affirmednetworks.com>> wrote: Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; sfc@i= etf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com<mailto:er= ic.gray@ericsson.com>> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucadai= r@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucada= ir@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucad= air@orange.com>; NAPIERALA, >> MARIA H; >>> sfc@ietf.org<mailto:sfc@ietf.org> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.co= m>> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bouca= dair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bou= cadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.b= oucadair@orange.com>; >> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com<mailto:mo= hamed.boucadair@orange.com>; >>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org<mailto:sfc@ietf.org> >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org<mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A8436F5SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style>=0A= <!--=0A= @font-face=0A= {font-family:Wingdings}=0A= @font-face=0A= {font-family:SimSun}=0A= @font-face=0A= {font-family:"Cambria Math"}=0A= @font-face=0A= {font-family:Calibri}=0A= @font-face=0A= {font-family:Tahoma}=0A= p.MsoNormal, li.MsoNormal, div.MsoNormal=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= a:link, span.MsoHyperlink=0A= {color:blue;=0A= text-decoration:underline}=0A= a:visited, span.MsoHyperlinkFollowed=0A= {color:purple;=0A= text-decoration:underline}=0A= p=0A= {margin-right:0in;=0A= margin-left:0in;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= p.MsoAcetate, li.MsoAcetate, div.MsoAcetate=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:8.0pt;=0A= font-family:"Tahoma","sans-serif"}=0A= p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph=0A= {margin-top:0in;=0A= margin-right:0in;=0A= margin-bottom:0in;=0A= margin-left:.5in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= p.emailquote, li.emailquote, div.emailquote=0A= {margin-right:0in;=0A= margin-left:1.0pt;=0A= border:none;=0A= padding:0in;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= span.BalloonTextChar=0A= {font-family:"Tahoma","sans-serif"}=0A= span.EmailStyle21=0A= {font-family:"Calibri","sans-serif";=0A= color:#1F497D}=0A= .MsoChpDefault=0A= {font-size:10.0pt}=0A= @page WordSection1=0A= {margin:1.0in 1.0in 1.0in 1.0in}=0A= ol=0A= {margin-bottom:0in}=0A= ul=0A= {margin-bottom:0in}=0A= -->=0A= </style><style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin= -bottom:0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1" lang=3D"EN-US" link=3D"blue" vlink=3D"purple= "> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Linda -<br> <br> "actor" is a generic way of talking about the part of a system th= at actually _does_ the thing.  In this context that means _a particula= r instance of a service function_<br> "decider" is a generic way of talking about parts of the system t= hat will make decisions about which actor will be used.  In this conte= xt it means a SNF, SFF, or a control/policy plane decision engine _when the= y are selecting SFIs_.  <br> <br> I think of it as being three decisions:<br> <ol> <li>the network - function selection (bridging and routing, anycast/multica= st, tenant domain, etc.); <br> </li><li>the service - function selection + service selection (policy r= oute, label switching, GSLB, virtual server destination (ip:port), traffic = classification, etc.);<br> </li><li>the instance - function selection + service selection + in= stance selection (LB pool member selection, DNS SRV & ENUM);</li></ol> <p><br> </p> <p><br> </p> <p><br> </p> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <hr tabindex=3D"-1"> <div style=3D"direction: ltr;" id=3D"divRpF544851"><font color=3D"#000000" = face=3D"Tahoma" size=3D"2"><b>From:</b> Linda Dunbar [linda.dunbar@huawei.c= om]<br> <b>Sent:</b> Tuesday, July 15, 2014 2:10 PM<br> <b>To:</b> Ian Smith; Ron Parker<br> <b>Cc:</b> Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA = H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers<br> </font><br> </div> <div></div> <div> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Ian,</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Try to clarify the term= inology you used:</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Does =93Selecting a dec= ider=94 mean =93selecting with SFFs=94? </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Does =93Selecting an ac= tor=94 mean =93the SFF that determine which local instances to use=94?</spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">To me, there are two le= vels of decision:</span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt; font-family:"Calibri","sans-serif"; co= lor:#1F497D"><span style=3D"">-<span style=3D"font:7.0pt "Times New Ro= man"">          </span></span></span><span style=3D"font-size:11.0pt; font-family:"Cal= ibri","sans-serif"; color:#1F497D">Network level decision (w= hich is pretty much same as today=92s router hops)</span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt; font-family:"Calibri","sans-serif"; co= lor:#1F497D"><span style=3D"">-<span style=3D"font:7.0pt "Times New Ro= man"">          </span></span></span><span style=3D"font-size:11.0pt; font-family:"Cal= ibri","sans-serif"; color:#1F497D">Node level decision (whic= h local instance to use). </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Linda</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <div> <div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0i= n 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt; font-family:&quo= t;Tahoma","sans-serif"">From:</span></b><span style=3D"font-= size:10.0pt; font-family:"Tahoma","sans-serif""> sfc [m= ailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ian Smith<br> <br> </span></p> </div> </div> <div> <p>But the actual point I was trying to make is that there is a consistent = semantic difference between 'selecting a decider' which is what you do if y= ou make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an a= ctor' which is what you do when you make a next hop selection amongst SFIs, and you should differentiate b= etween them.</p> <div> <p class=3D"MsoNormal">On Jul 12, 2014 1:43 PM, Ron Parker <<a href=3D"m= ailto:Ron_Parker@affirmednetworks.com" target=3D"_blank">Ron_Parker@affirme= dnetworks.com</a>> wrote:</p> </div> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt">Ian,<br> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <<a href=3D"mailto:eric.gra= y@ericsson.com" target=3D"_blank">eric.gray@ericsson.com</a>> wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com" target=3D"= _blank">mailto:mn1921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com" t= arget=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blan= k">mailto:sfc-bounces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.co= m" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orang= e.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; NAPIERALA,<br> >> MARIA H;<br> >>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org= </a><br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" tar= get=3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@o= range.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_bla= nk">mohamed.boucadair@orange.com</a>;<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]= <br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:moh= amed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>]= On Behalf Of Joel<br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; <a= href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >>>>>>>>>> <a href=3D"mailto:sfc@ietf.org" ta= rget=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> <a href=3D"mailto:sfc@ietf= .org" target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> <a href=3D"mailto:sfc@ietf.org= " target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/list= info/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> <a href=3D"mailto:sfc@ietf.org" target= =3D"_blank">sfc@ietf.org</a><br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc= </a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">= sfc@ietf.org</a><br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf= .org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sfc</a></span></p> </div> </div> </div> </div> </div> </body> </html> --_000_419417C345CA5F48BF45F0A23955A0634A8436F5SEAEMBX02olympu_-- From nobody Tue Jul 15 12:47:44 2014 Return-Path: <tom.taylor.stds@gmail.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF4E1A006F for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 12:47:43 -0700 (PDT) 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 RP_OGWDSzxjA for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 12:47:42 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068D81A0027 for <sfc@ietf.org>; Tue, 15 Jul 2014 12:47:41 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so2865284qaj.7 for <sfc@ietf.org>; Tue, 15 Jul 2014 12:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=TEFu7NiaRSm1cKNignmHzBv2iCXWwOfUQF+NHu9PkMY=; b=QTELle4MfKgcysfsFn7jE0SoZm1zb6CrhvZ+elTSQHQeA6hInOntwfqkJEP7jt2jW2 KY2uIjBU00RXBHVfrJ5oseTskwn3ld7uek4rjfw0zpnPYLh9jYYcv5KqwV2GnvrD+8Kz i+63R0Vqv5dDLxo//VqEKCBMWmu+RO6Jq2OL2ahmJtYIYxCyYD7cDOAOina0j8tc9bs1 7ZhNxqSTpMDvXq2meBkllRiHBXws/QVEl3ZBum5ZHZBzwkMbWi8Nr87N0nyraCQIW9vx 8iYyyHxShTQF5VE22j82Xl8JWnULZSnUq0nAPH6JMDoszAt6IbCy6Bv8xno3Ch+ughDg UwbA== X-Received: by 10.224.26.68 with SMTP id d4mr34935590qac.61.1405453661203; Tue, 15 Jul 2014 12:47:41 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id d4sm27538984qag.5.2014.07.15.12.47.40 for <sfc@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 12:47:40 -0700 (PDT) Message-ID: <53C5855B.4050806@gmail.com> Date: Tue, 15 Jul 2014 15:47:39 -0400 From: Tom Taylor <tom.taylor.stds@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "sfc@ietf.org" <sfc@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/q7gphwj8cmmske12Vma4vun8HmM Subject: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 19:47:43 -0000 Section 3.3 of the problem statement has this to say about SFC metadata: <quote> Data plane metadata provides the ability to exchange information between logical classification points and service functions (and vice versa) and between service functions. As such metadata is not used as forwarding information to deliver packets along the service overlay. </quote> However, the definition of the SFF in the architecture document seems to contradict this, unless one assumes that the SFC encapsulation has more information than just SFC metadata. <quote> Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the SFC network forwarder to one or more connected service functions via information carried in the SFC encapsulation. </quote> Is this just a matter of adjusting the text, or is there a conflict of views buried here? Tom Taylor From nobody Tue Jul 15 12:58:02 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E881A0AFE for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 12:57:57 -0700 (PDT) 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 e0QA80t9vLr8 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 12:57:55 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AF11A0A8E for <sfc@ietf.org>; Tue, 15 Jul 2014 12:57:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 9992CD404D0; Tue, 15 Jul 2014 12:57:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 3E700D402BE; Tue, 15 Jul 2014 12:57:54 -0700 (PDT) Message-ID: <53C587C1.6080506@joelhalpern.com> Date: Tue, 15 Jul 2014 15:57:53 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> References: <53C5855B.4050806@gmail.com> In-Reply-To: <53C5855B.4050806@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AniRGbCCYR3UcA9SfY2FIwLqbM4 Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 19:57:57 -0000 The expectation and intention is that the piece of the SFC Encapsulation used for this is the identification of the service path. I believe there is other text in the architecture that reinforces the problem statement point that metadata is not used for the forwarding description in the absence of a classifier. Yours, Joel On 7/15/14, 3:47 PM, Tom Taylor wrote: > Section 3.3 of the problem statement has this to say about SFC metadata: > > <quote> > > Data plane metadata provides the ability to exchange information > between logical classification points and service functions (and vice > versa) and between service functions. As such metadata is not used > as forwarding information to deliver packets along the service > overlay. > > </quote> > > However, the definition of the SFF in the architecture document seems to > contradict this, unless one assumes that the SFC encapsulation has more > information than just SFC metadata. > > <quote> > > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the SFC network > forwarder to one or more connected service functions via > information carried in the SFC encapsulation. > > </quote> > > Is this just a matter of adjusting the text, or is there a conflict of > views buried here? > > Tom Taylor > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Jul 15 13:50:58 2014 Return-Path: <louis.fourie@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B7F1B2913 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 13:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QouAeklDhbuD for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 13:50:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2BA1B2912 for <sfc@ietf.org>; Tue, 15 Jul 2014 13:50:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB74710; Tue, 15 Jul 2014 20:50:52 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 21:50:51 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 13:50:46 -0700 From: Henry Fourie <louis.fourie@huawei.com> To: Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGWsHSJp0B971keJZOZ0s+maopuhmgHA Date: Tue, 15 Jul 2014 20:50:45 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AA22364@SJCEML702-CHM.china.huawei.com> References: <53C5855B.4050806@gmail.com> In-Reply-To: <53C5855B.4050806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pA3mSFaMIjs9wttdFqvbsH36Jpw Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 20:50:56 -0000 Tom, Both are correct, although not sufficiently explicit. The SFC encapsulation (or SFC headers: SCH/NSH) carries both steering infor= mation (Service Path ID) and service metadata. The SFF uses the steering information to deliver the packet to the correct = SF and the metadata is then processed by the SF. The SFF does not use the meta= data for steering.=20 - Louis -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Tuesday, July 15, 2014 12:48 PM To: sfc@ietf.org Subject: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Section 3.3 of the problem statement has this to say about SFC metadata: <quote> Data plane metadata provides the ability to exchange information between logical classification points and service functions (and vice versa) and between service functions. As such metadata is not used as forwarding information to deliver packets along the service overlay. </quote> However, the definition of the SFF in the architecture document seems to=20 contradict this, unless one assumes that the SFC encapsulation has more=20 information than just SFC metadata. <quote> Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the SFC network forwarder to one or more connected service functions via information carried in the SFC encapsulation. </quote> Is this just a matter of adjusting the text, or is there a conflict of=20 views buried here? Tom Taylor _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 15 15:24:47 2014 Return-Path: <linda.dunbar@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066C51A011D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 uytAaqV8czaU for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:24:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7121A0118 for <sfc@ietf.org>; Tue, 15 Jul 2014 15:24:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB78752; Tue, 15 Jul 2014 22:24:30 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 23:24:29 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 15:24:17 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: Ian Smith <I.Smith@F5.com>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00 Thread-Index: AQHPoHuEYDbTv1pBVkekax6+8QOUMQ== Date: Tue, 15 Jul 2014 22:24:17 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9D29E@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> <419417C345CA5F48BF45F0A23955A0634A8436F5@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A8436F5@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.165] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9D29Edfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ry_GkCPuoJFCIhHc5B_Cu_w1vvc Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 22:24:42 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D29Edfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian, Thank you very much for the clarification. So the "Actor" is the Service function internal processing, correct? Then the "Service Chains, Paths, and Load Balancers" in SFC context should = be all about the "Decider", correct? Since some service function instances are visible to Chain Classification = nodes and Service Chain orchestration system, some other times, it is a col= lection of Instances as one entity that is visible to the "Classification N= ode" or "Orchestration system". Therefore, some Chains have explicit information on which Service Function = instances to use; some Chains only have the information on which cluster of= instances to use; some chains have explicit information on which SFFs/SN n= odes to use; etc. http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00 is= the attempt to describe decisions by SFFs and SN. Any comments and suggest= ions? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith Sent: Tuesday, July 15, 2014 1:32 PM To: Linda Dunbar; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel= M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Linda - "actor" is a generic way of talking about the part of a system that actuall= y _does_ the thing. In this context that means _a particular instance of a= service function_ "decider" is a generic way of talking about parts of the system that will m= ake decisions about which actor will be used. In this context it means a S= NF, SFF, or a control/policy plane decision engine _when they are selecting= SFIs_. I think of it as being three decisions: 1. the network - function selection (bridging and routing, anycast/multi= cast, tenant domain, etc.); 2. the service - function selection + service selection (policy route, l= abel switching, GSLB, virtual server destination (ip:port), traffic classif= ication, etc.); 3. the instance - function selection + service selection + instance sele= ction (LB pool member selection, DNS SRV & ENUM); ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 2:10 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org<mailto:sfc@ietf.org>; Jim Guichard (jguichar); NAP= IERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com<mailto:moham= ed.boucadair@orange.com>; Eric Gray Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Ian, Try to clarify the terminology you used: Does "Selecting a decider" mean "selecting with SFFs"? Does "Selecting an actor" mean "the SFF that determine which local instance= s to use"? To me, there are two levels of decision: - Network level decision (which is pretty much same as today's rou= ter hops) - Node level decision (which local instance to use). Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com<mailto= :Ron_Parker@affirmednetworks.com>> wrote: Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; sfc@i= etf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com<mailto:er= ic.gray@ericsson.com>> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucadai= r@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucada= ir@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucad= air@orange.com>; NAPIERALA, >> MARIA H; >>> sfc@ietf.org<mailto:sfc@ietf.org> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.co= m>> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bouca= dair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bou= cadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.b= oucadair@orange.com>; >> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com<mailto:mo= hamed.boucadair@orange.com>; >>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org<mailto:sfc@ietf.org> >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org<mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D29Edfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} p.emailquote, li.emailquote, div.emailquote {mso-style-name:emailquote; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:1.0pt; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} p.msochpdefault, li.msochpdefault, div.msochpdefault {mso-style-name:msochpdefault; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Times New Roman","serif";} span.balloontextchar0 {mso-style-name:balloontextchar; font-family:"Tahoma","sans-serif";} span.emailstyle21 {mso-style-name:emailstyle21; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle25 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:2061202057; mso-list-template-ids:1846063166;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Ian, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thank you very much for t= he clarification. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">So the “Actor”= ; is the Service function internal processing, correct?<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Then the “Service C= hains, Paths, and Load Balancers” in SFC context should be all about = the  “Decider”, correct? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Since some  service = function instances are visible to Chain Classification nodes and Service Ch= ain orchestration system, some other times, it is a collection of Instances as one entity that is visible to the “Classification No= de” or “Orchestration system”. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Therefore, some Chains ha= ve explicit information on which Service Function instances to use; some Ch= ains only have the information on which cluster of instances to use; some chains have explicit information on which SFFs/SN nodes to us= e; etc. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><a href=3D"http://tools.i= etf.org/html/draft-dunbar-sfc-fun-instances-restoration-00">http://tools.ie= tf.org/html/draft-dunbar-sfc-fun-instances-restoration-00</a> is the attempt to describe decisions by SFFs and SN. Any comments and sugg= estions? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ian Smith<br> <b>Sent:</b> Tuesday, July 15, 2014 1:32 PM<br> <b>To:</b> Linda Dunbar; Ron Parker<br> <b>Cc:</b> Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA = H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray<br> <b>Subject:</b> Re: [sfc] Service Chains, Paths, and Load Balancers<o:p></o= :p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ta= homa","sans-serif";color:black">Linda -<br> <br> "actor" is a generic way of talking about the part of a system th= at actually _does_ the thing.  In this context that means _a particula= r instance of a service function_<br> "decider" is a generic way of talking about parts of the system t= hat will make decisions about which actor will be used.  In this conte= xt it means a SNF, SFF, or a control/policy plane decision engine _when the= y are selecting SFIs_.  <br> <br> I think of it as being three decisions:<o:p></o:p></span></p> <ol start=3D"1" type=3D"1"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l0 level1 lfo1"> <span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-s= erif"">the network - function selection (bridging and routing, anycast= /multicast, tenant domain, etc.); <o:p></o:p></span></li><li class=3D"MsoNormal" style=3D"color:black;mso-mar= gin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> <span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-s= erif"">the service - function selection + service selection (polic= y route, label switching, GSLB, virtual server destination (ip:port), traff= ic classification, etc.);<o:p></o:p></span></li><li class=3D"MsoNormal" sty= le=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-li= st:l0 level1 lfo1"> <span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-s= erif"">the instance - function selection + service selection += instance selection (LB pool member selection, DNS SRV & ENUM);<o:p></o= :p></span></li></ol> <p><span style=3D"color:black"><o:p> </o:p></span></p> <p><span style=3D"color:black"><o:p> </o:p></span></p> <p><span style=3D"color:black"><o:p> </o:p></span></p> <div> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:8.0pt;color:black"> <hr size=3D"3" width=3D"100%" align=3D"center"> </span></div> <div id=3D"divRpF544851"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon= t-size:10.0pt;font-family:"Tahoma","sans-serif";color:b= lack">From:</span></b><span style=3D"font-size:10.0pt;font-family:"Tah= oma","sans-serif";color:black"> Linda Dunbar [linda.dunbar@h= uawei.com]<br> <b>Sent:</b> Tuesday, July 15, 2014 2:10 PM<br> <b>To:</b> Ian Smith; Ron Parker<br> <b>Cc:</b> Sharon; <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>; Jim Gu= ichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.co= m</a>; Eric Gray<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers</span><= span style=3D"font-size:8.0pt;color:black"><o:p></o:p></span></p> </div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Ian,</span><span style=3D= "color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"> </span><span style= =3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Try to clarify the termin= ology you used:</span><span style=3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"> </span><span style= =3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Does “Selecting a d= ecider” mean “selecting with SFFs”? </span><span style=3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Does “Selecting an = actor” mean “the SFF that determine which local instances to us= e”?</span><span style=3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"> </span><span style= =3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">To me, there are two leve= ls of decision:</span><span style=3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D">-</span><span style=3D"font-size:7.0pt;color:#1F497D"> &nbs= p;        </span><span style=3D"font-size:11.0pt;font-family:"Calibri",&quo= t;sans-serif";color:#1F497D">Network level decision (which is pretty m= uch same as today’s router hops)</span><span style=3D"color:black"><o= :p></o:p></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D">-</span><span style=3D"font-size:7.0pt;color:#1F497D"> &nbs= p;        </span><span style=3D"font-size:11.0pt;font-family:"Calibri",&quo= t;sans-serif";color:#1F497D">Node level decision (which local instance= to use). </span><span style=3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"> </span><span style= =3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda</span><span style= =3D"color:black"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"> </span><span style= =3D"color:black"><o:p></o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon= t-size:10.0pt;font-family:"Tahoma","sans-serif";color:b= lack">From:</span></b><span style=3D"font-size:10.0pt;font-family:"Tah= oma","sans-serif";color:black"> sfc [<a href=3D"mailto:sfc-b= ounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ian Smith</span><span style=3D"color:black"><o:p></o:p>= </span></p> </div> </div> <div> <p><span style=3D"color:black">But the actual point I was trying to make is= that there is a consistent semantic difference between 'selecting a decide= r' which is what you do if you make a next- hop selection amongst SNFs and/= or SFFs, and 'selecting an actor' which is what you do when you make a next hop selection amongst SFIs, and = you should differentiate between them.<o:p></o:p></span></p> <div> <p class=3D"MsoNormal"><span style=3D"color:black">On Jul 12, 2014 1:43 PM,= Ron Parker <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<o:p></o:p></span= ></p> </div> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;color:black">Ian,<br= > <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <<a href=3D"mailto:eric.gra= y@ericsson.com" target=3D"_blank">eric.gray@ericsson.com</a>> wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com" target=3D"= _blank">mailto:mn1921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com" t= arget=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blan= k">mailto:sfc-bounces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.co= m" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orang= e.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; NAPIERALA,<br> >> MARIA H;<br> >>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org= </a><br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" tar= get=3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@o= range.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_bla= nk">mohamed.boucadair@orange.com</a>;<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]= <br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:moh= amed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>]= On Behalf Of Joel<br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; <a= href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >>>>>>>>>> <a href=3D"mailto:sfc@ietf.org" ta= rget=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> <a href=3D"mailto:sfc@ietf= .org" target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> <a href=3D"mailto:sfc@ietf.org= " target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/list= info/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> <a href=3D"mailto:sfc@ietf.org" target= =3D"_blank">sfc@ietf.org</a><br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc= </a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">= sfc@ietf.org</a><br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf= .org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sfc</a></span><span style=3D"color:black= "><o:p></o:p></span></p> </div> </div> </div> </div> </div> </div> </body> </html> --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D29Edfweml701chmchi_-- From nobody Tue Jul 15 15:48:28 2014 Return-Path: <I.Smith@f5.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C991B299D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 rtTAkxQZJHqO for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:48:19 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CD51B299C for <sfc@ietf.org>; Tue, 15 Jul 2014 15:48:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="121870863" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABZgkJ/V7xHF4c1gTd0giUBAQEBAgEBAQELDAFKCQsFBwQCAQgRAQMBAQEKFgECBAchBgsUAwYIAgQBDQUIE4dNAwkVxHoNhwkXjFOBQiYGIQYEBgECBIMegRQElHGBf4MjiT+Bf4dAgT+BakE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 15 Jul 2014 22:48:17 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 15:48:17 -0700 From: Ian Smith <I.Smith@F5.com> To: Linda Dunbar <linda.dunbar@huawei.com>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00 Thread-Index: AQHPoHuLSCiSZieF80+1PhTyGc3chZuhupRW Date: Tue, 15 Jul 2014 22:48:16 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A843871@SEAEMBX02.olympus.F5Net.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2EA2@MBX021-W3-CA-2.exch021.domain.local> <AFD06513-87F0-4AB8-AB58-646A0B3456C3@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F05@MBX021-W3-CA-2.exch021.domain.local> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B2F5E@MBX021-W3-CA-2.exch021.domain.local> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B62FD@MBX021-W3-CA-2.exch021.domain.local>, <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6483@MBX021-W3-CA-2.exch021.domain.local> <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> <419417C345CA5F48BF45F0A23955A0634A8436F5@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9D29E@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9D29E@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.157] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A843871SEAEMBX02olympu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4cKauUi9Pp_bJQ6yeh8DtJ-M1WI Cc: Sharon <sbarkai@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>, "NAPIERALA, MARIA H" <mn1921@att.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Eric Gray <eric.gray@ericsson.com> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 22:48:26 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A843871SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >"Then the =93Service Chains, Paths, and Load Balancers=94 in SFC context s= hould be all about >the =93Decider=94, correct?" No, Service Chains, Paths, (and perhaps Load Balancers) are higher level a= bstractions -- I think it would be more appropriate to leave the analogy at= the actual SNF or SFF nodes and not try and extend it into the abstract co= ncepts of "what is a service chain?" or "what is a path?". How you underst= and "Load Balancer" would impact whether you think it is or is not a subset= of SFF capabilities. If you do think of load balancing as reasonably bein= g part of a SFF, then it would be a decider. If you think of "a load balan= cer" as a service function that gets included in a chain, then it would be = an actor. I'll send comments on the draft separately. ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 6:24 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel= M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc= -fun-instances-restoration-00 Ian, Thank you very much for the clarification. So the =93Actor=94 is the Service function internal processing, correct? Then the =93Service Chains, Paths, and Load Balancers=94 in SFC context sho= uld be all about the =93Decider=94, correct? Since some service function instances are visible to Chain Classification = nodes and Service Chain orchestration system, some other times, it is a col= lection of Instances as one entity that is visible to the =93Classification= Node=94 or =93Orchestration system=94. Therefore, some Chains have explicit information on which Service Function = instances to use; some Chains only have the information on which cluster of= instances to use; some chains have explicit information on which SFFs/SN n= odes to use; etc. http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00 is= the attempt to describe decisions by SFFs and SN. Any comments and suggest= ions? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith Sent: Tuesday, July 15, 2014 1:32 PM To: Linda Dunbar; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel= M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Linda - "actor" is a generic way of talking about the part of a system that actuall= y _does_ the thing. In this context that means _a particular instance of a= service function_ "decider" is a generic way of talking about parts of the system that will m= ake decisions about which actor will be used. In this context it means a S= NF, SFF, or a control/policy plane decision engine _when they are selecting= SFIs_. I think of it as being three decisions: 1. the network - function selection (bridging and routing, anycast/multi= cast, tenant domain, etc.); 2. the service - function selection + service selection (policy route, l= abel switching, GSLB, virtual server destination (ip:port), traffic classif= ication, etc.); 3. the instance - function selection + service selection + instance sele= ction (LB pool member selection, DNS SRV & ENUM); ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 2:10 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org<mailto:sfc@ietf.org>; Jim Guichard (jguichar); NAP= IERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com<mailto:moham= ed.boucadair@orange.com>; Eric Gray Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Ian, Try to clarify the terminology you used: Does =93Selecting a decider=94 mean =93selecting with SFFs=94? Does =93Selecting an actor=94 mean =93the SFF that determine which local in= stances to use=94? To me, there are two levels of decision: - Network level decision (which is pretty much same as today=92s r= outer hops) - Node level decision (which local instance to use). Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker <Ron_Parker@affirmednetworks.com<mailto= :Ron_Parker@affirmednetworks.com>> wrote: Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; NA= PIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; sfc@i= etf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com<mailto:er= ic.gray@ericsson.com>> wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucadai= r@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucada= ir@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.boucad= air@orange.com>; NAPIERALA, >> MARIA H; >>> sfc@ietf.org<mailto:sfc@ietf.org> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.co= m>> wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bouca= dair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org>; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> <Ron_Parker@affirmednetworks.com<mailto:Ron_Parker@affirmednetworks.com= >> wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.bou= cadair@orange.com>; sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com<mailto:mohamed.b= oucadair@orange.com>; >> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> <mn1921@att.com<mailto:mn1921@att.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com<mailto:mo= hamed.boucadair@orange.com>; >>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org<mailto:sfc@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org<mailto:sfc@ietf.org> >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org<mailto:sfc@ietf.org> > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc --_000_419417C345CA5F48BF45F0A23955A0634A843871SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style>=0A= <!--=0A= @font-face=0A= {font-family:SimSun}=0A= @font-face=0A= {font-family:"Cambria Math"}=0A= @font-face=0A= {font-family:Calibri}=0A= @font-face=0A= {font-family:Tahoma}=0A= p.MsoNormal, li.MsoNormal, div.MsoNormal=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= a:link, span.MsoHyperlink=0A= {color:blue;=0A= text-decoration:underline}=0A= a:visited, span.MsoHyperlinkFollowed=0A= {color:purple;=0A= text-decoration:underline}=0A= p=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= p.MsoAcetate, li.MsoAcetate, div.MsoAcetate=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:8.0pt;=0A= font-family:"Tahoma","sans-serif"}=0A= p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph=0A= {margin-top:0in;=0A= margin-right:0in;=0A= margin-bottom:0in;=0A= margin-left:.5in;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= span.BalloonTextChar=0A= {font-family:"Tahoma","sans-serif"}=0A= p.emailquote, li.emailquote, div.emailquote=0A= {margin-top:0in;=0A= margin-right:0in;=0A= margin-bottom:0in;=0A= margin-left:1.0pt;=0A= margin-bottom:.0001pt;=0A= font-size:12.0pt;=0A= font-family:"Times New Roman","serif"}=0A= p.msochpdefault, li.msochpdefault, div.msochpdefault=0A= {margin:0in;=0A= margin-bottom:.0001pt;=0A= font-size:10.0pt;=0A= font-family:"Times New Roman","serif"}=0A= span.balloontextchar0=0A= {font-family:"Tahoma","sans-serif"}=0A= span.emailstyle21=0A= {font-family:"Calibri","sans-serif";=0A= color:#1F497D}=0A= span.EmailStyle25=0A= {font-family:"Calibri","sans-serif";=0A= color:#1F497D}=0A= .MsoChpDefault=0A= {font-size:10.0pt}=0A= @page WordSection1=0A= {margin:1.0in 1.0in 1.0in 1.0in}=0A= ol=0A= {margin-bottom:0in}=0A= ul=0A= {margin-bottom:0in}=0A= -->=0A= </style><style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin= -bottom:0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1" lang=3D"EN-US" link=3D"blue" vlink=3D"purple= "> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">>"<span style=3D"font-size:11.0pt; font-family:"Calibri= ","sans-serif"; color:#1F497D">Then the =93Service Chains, P= aths, and Load Balancers=94 in SFC context should be all about >the  =93Decider=94, correct?"<br> <br> No, Service Chains, Paths, (and  perhaps Load Balancers) are higher le= vel abstractions -- I think it would be more appropriate to leave the analo= gy at the actual SNF or SFF nodes and not try and extend it into the abstra= ct concepts of "what is a service chain?" or "what is a path?".  How you understand "Load Balanc= er" would impact whether you think it is or is not a subset of SFF cap= abilities.  If you do think of load balancing as reasonably being part= of a SFF, then it would be a decider.  If you think of "a load balancer" as a service function that gets included in a chain, then i= t would be an actor.<br> <br> <br> I'll send comments on the draft separately.<br> <br> </span> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <hr tabindex=3D"-1"> <div style=3D"direction: ltr;" id=3D"divRpF681169"><font color=3D"#000000" = face=3D"Tahoma" size=3D"2"><b>From:</b> Linda Dunbar [linda.dunbar@huawei.c= om]<br> <b>Sent:</b> Tuesday, July 15, 2014 6:24 PM<br> <b>To:</b> Ian Smith; Ron Parker<br> <b>Cc:</b> Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA = H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray<br> <b>Subject:</b> [sfc] Service Chains, Paths, and Load Balancers & draft= -dunbar-sfc-fun-instances-restoration-00<br> </font><br> </div> <div></div> <div> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Ian, </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Thank you very much for= the clarification. </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">So the =93Actor=94 is t= he Service function internal processing, correct?</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Then the =93Service Cha= ins, Paths, and Load Balancers=94 in SFC context should be all about the &n= bsp;=93Decider=94, correct? </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Since some  servic= e function instances are visible to Chain Classification nodes and Service = Chain orchestration system, some other times, it is a collection of Instances as one entity that is visible to the =93Classification Node= =94 or =93Orchestration system=94. </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Therefore, some Chains = have explicit information on which Service Function instances to use; some = Chains only have the information on which cluster of instances to use; some chains have explicit information on which SFFs/SN nodes to us= e; etc. </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"><a href=3D"http://tools= .ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00" target=3D"_bl= ank">http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-= 00</a> is the attempt to describe decisions by SFFs and SN. Any comments and sugg= estions? </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Linda </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span></p> <div> <div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0i= n 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt; font-family:&quo= t;Tahoma","sans-serif"">From:</span></b><span style=3D"font-= size:10.0pt; font-family:"Tahoma","sans-serif""> sfc [m= ailto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Ian Smith<br> <b>Sent:</b> Tuesday, July 15, 2014 1:32 PM<br> <b>To:</b> Linda Dunbar; Ron Parker<br> <b>Cc:</b> Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAPIERALA, MARIA = H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray<br> <b>Subject:</b> Re: [sfc] Service Chains, Paths, and Load Balancers</span><= /p> </div> </div> <p class=3D"MsoNormal"> </p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt; font-family:"T= ahoma","sans-serif"; color:black">Linda -<br> <br> "actor" is a generic way of talking about the part of a system th= at actually _does_ the thing.  In this context that means _a particula= r instance of a service function_<br> "decider" is a generic way of talking about parts of the system t= hat will make decisions about which actor will be used.  In this conte= xt it means a SNF, SFF, or a control/policy plane decision engine _when the= y are selecting SFIs_.  <br> <br> I think of it as being three decisions:</span></p> <ol start=3D"1" type=3D"1"> <li class=3D"MsoNormal" style=3D"color:black"><span style=3D"font-size:10.0= pt; font-family:"Tahoma","sans-serif"">the network - fu= nction selection (bridging and routing, anycast/multicast, tenant domain, e= tc.); </span></li><li class=3D"MsoNormal" style=3D"color:black"><span style=3D"fo= nt-size:10.0pt; font-family:"Tahoma","sans-serif"">the = service - function selection + service selection (policy route, label s= witching, GSLB, virtual server destination (ip:port), traffic classificatio= n, etc.);</span></li><li class=3D"MsoNormal" style=3D"color:black"><span styl= e=3D"font-size:10.0pt; font-family:"Tahoma","sans-serif"= ;">the instance - function selection + service selection + instance= selection (LB pool member selection, DNS SRV & ENUM);</span></li></ol> <p><span style=3D"color:black"> </span></p> <p><span style=3D"color:black"> </span></p> <p><span style=3D"color:black"> </span></p> <div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"font-size:8.0pt; color:black"> <hr align=3D"center" size=3D"3" width=3D"100%"> </span></div> <div id=3D"divRpF544851"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon= t-size:10.0pt; font-family:"Tahoma","sans-serif"; color= :black">From:</span></b><span style=3D"font-size:10.0pt; font-family:"= Tahoma","sans-serif"; color:black"> Linda Dunbar [linda.dunb= ar@huawei.com]<br> <b>Sent:</b> Tuesday, July 15, 2014 2:10 PM<br> <b>To:</b> Ian Smith; Ron Parker<br> <b>Cc:</b> Sharon; <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ie= tf.org</a>; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.b= oucadair@orange.com</a>; Eric Gray<br> <b>Subject:</b> RE: [sfc] Service Chains, Paths, and Load Balancers</span><= span style=3D"font-size:8.0pt; color:black"></span></p> </div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Ian,</span><span style= =3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span><span styl= e=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Try to clarify the term= inology you used:</span><span style=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span><span styl= e=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Does =93Selecting a dec= ider=94 mean =93selecting with SFFs=94? </span><span style=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Does =93Selecting an ac= tor=94 mean =93the SFF that determine which local instances to use=94?</spa= n><span style=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span><span styl= e=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">To me, there are two le= vels of decision:</span><span style=3D"color:black"></span></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt; font-family:"Calibri","sans-serif"; co= lor:#1F497D">-</span><span style=3D"font-size:7.0pt; color:#1F497D"> &= nbsp;        </span><span style=3D"font-size:11.0pt; font-family:"Calibri",&qu= ot;sans-serif"; color:#1F497D">Network level decision (which is pretty= much same as today=92s router hops)</span><span style=3D"color:black"></sp= an></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in"><span style=3D"f= ont-size:11.0pt; font-family:"Calibri","sans-serif"; co= lor:#1F497D">-</span><span style=3D"font-size:7.0pt; color:#1F497D"> &= nbsp;        </span><span style=3D"font-size:11.0pt; font-family:"Calibri",&qu= ot;sans-serif"; color:#1F497D">Node level decision (which local instan= ce to use). </span><span style=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span><span styl= e=3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D">Linda</span><span style= =3D"color:black"></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt; font-family:"C= alibri","sans-serif"; color:#1F497D"> </span><span styl= e=3D"color:black"></span></p> <div> <div style=3D"border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0i= n 0in 0in"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon= t-size:10.0pt; font-family:"Tahoma","sans-serif"; color= :black">From:</span></b><span style=3D"font-size:10.0pt; font-family:"= Tahoma","sans-serif"; color:black"> sfc [<a href=3D"mailto:s= fc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Ian Smith</span><span style=3D"color:black"></span></p> </div> </div> <div> <p><span style=3D"color:black">But the actual point I was trying to make is= that there is a consistent semantic difference between 'selecting a decide= r' which is what you do if you make a next- hop selection amongst SNFs and/= or SFFs, and 'selecting an actor' which is what you do when you make a next hop selection amongst SFIs, and = you should differentiate between them.</span></p> <div> <p class=3D"MsoNormal"><span style=3D"color:black">On Jul 12, 2014 1:43 PM,= Ron Parker <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:</span></p> </div> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt; color:black">Ian,<b= r> <br> I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.<br> <br>     Ron<br> <br> <br> <br> From: Ian Smith [I.Smith@F5.com]<br> Sent: Saturday, July 12, 2014 11:59 AM<br> To: Ron Parker; Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> <br> I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)<br> <br> <br> ________________________________________<br> From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]<br> Sent: Saturday, July 12, 2014 10:15 AM<br> To: Sharon; Eric Gray<br> Cc: Jim Guichard (jguichar); Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>; NAPIERALA, MARIA H<br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Sharon,<br> <br> One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.<br> <br>    Ron<br> <br> ________________________________________<br> From: Sharon [sbarkai@gmail.com]<br> Sent: Friday, July 11, 2014 9:35 PM<br> To: Eric Gray<br> Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> <br> Looks like it's almost there, no?<br> <br> If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:<br> <br> - classify and map the flow to the right subscriber-serviceChain<br> <br> - map the chain links to the SFFs signed up to execute an SF hop<br> <br> - carry the context and work flow  as meta data between SFFs<br> <br> Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.<br> <br> The way I read the docs it's almost there.<br> <br> --szb<br> <br> > On Jul 11, 2014, at 12:27 PM, Eric Gray <<a href=3D"mailto:eric.gra= y@ericsson.com" target=3D"_blank">eric.gray@ericsson.com</a>> wrote:<br> ><br> > Maria,<br> ><br> > So many fundamental problems.  What to do?<br> ><br> > I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF<br> > working group needs to focus on a set of problems they can solve in a = reasonable<br> > amount of time, without having to boil any oceans.<br> ><br> > Joel suggested an architectural approach that would allow any form of = distribution<br> > you might want, without requiring every solution to support all possib= ilities, and<br> > without impacting the ability of solutions to be optimized for whateve= r deployment<br> > scenario may apply in any specific case.<br> ><br> > Working out ways to optimize your particular deployment model seems to= be your<br> > problem (with support from your suppliers - whoever they might be) and= - it seems<br> > to me - the burden of making sure that the standards we define allows = optimization<br> > for that deployment falls on you (and them).<br> ><br> > Meanwhile, other providers and other vendors may seek to ensure that w= hatever<br> > we define allows at least some degree of optimization for their deploy= ments.<br> ><br> > This is the process.<br> ><br> > Is the architectural proposal Joel came up with sufficient as a starti= ng point?<br> ><br> > --<br> > Eric<br> ><br> > -----Original Message-----<br> > From: NAPIERALA, MARIA H [<a href=3D"mailto:mn1921@att.com" target=3D"= _blank">mailto:mn1921@att.com</a>]<br> > Sent: Thursday, July 10, 2014 12:29 PM<br> > To: Eric Gray; Jim Guichard (jguichar); Ron Parker<br> > Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.com" t= arget=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<br> > Importance: High<br> ><br> > Eric,<br> ><br> >> Load distribution is not the same as service function chaining and= -<br> >> while there may be problems to solve in this area - why would we<b= r> >> assume that SFC is supposed to solve them?<br> ><br> > Because this is the fundamental problem in service chaining in virtual= ized environments.<br> > I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.<br> ><br> >> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.<br> ><br> > How would you ensure it?<br> ><br> >><br> >> --<br> >> Eric<br> >><br> >> -----Original Message-----<br> >> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org" target=3D"_blan= k">mailto:sfc-bounces@ietf.org</a>] On Behalf Of NAPIERALA, MARIA<br> >> H<br> >> Sent: Thursday, July 10, 2014 12:02 PM<br> >> To: Jim Guichard (jguichar); Ron Parker<br> >> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orange.co= m" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<br> >><br> >> One of the main problems in "service chains" is how to i= mplement a<br> >> service that is conceptually one hop but scaled horizontally as 10= or<br> >> 100 different VMs.<br> >> So, IMO, if we are not addressing this problem than what are we so= lving.<br> >><br> >> Maria<br> >><br> >>> -----Original Message-----<br> >>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@cisc= o.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>> Sent: Wednesday, July 09, 2014 6:17 PM<br> >>> To: Ron Parker<br> >>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@orang= e.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; NAPIERALA,<br> >> MARIA H;<br> >>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org= </a><br> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<b= r> >>><br> >>> I should clarify that my statement was made as a personal opin= ion<br> >>> and it is up to the WG to evaluate if there exists anything at= the<br> >>> architectural level that is new and therefore needs to be addr= essed.<br> >>><br> >>> Sent from my iPhone<br> >>><br> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"<br> >>>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" tar= get=3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>><br> >>>> Jim,<br> >>>><br> >>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that<br> >>> this is a layered problem and that load balancing belongs at a= lower<br> >>> level, it seems to me that load balancing of the service funct= ions<br> >>> (not load balancer as a service function) should be an explici= t<br> >> consideration of the SFC<br> >>> architecture.    I say this not only from a sca= le perspective, but also with<br> >>> resiliency in mind.<br> >>>><br> >>>>  Ron<br> >>>><br> >>>><br> >>>> -----Original Message-----<br> >>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguichar@= cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>> Sent: Wednesday, July 09, 2014 5:48 PM<br> >>>> To: Ron Parker<br> >>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.boucadair@o= range.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a>;<br> >>> NAPIERALA, MARIA H<br> >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs<br> >>>><br> >>>> I would say that's implementation.<br> >>>><br> >>>> Sent from my iPhone<br> >>>><br> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"<br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>><br> >>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?<br> >>>>><br> >>>>> -----Original Message-----<br> >>>>> From: Jim Guichard (jguichar) [<a href=3D"mailto:jguic= har@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]<br> >>>>> Sent: Wednesday, July 09, 2014 5:29 PM<br> >>>>> To: Ron Parker<br> >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;<br> >>> <a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_bla= nk">mohamed.boucadair@orange.com</a>;<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers<br> >>>>><br> >>>>> Well of course not; in that case you load balance up a= level<br> >>>>> between<br> >>> those nodes and then locally.<br> >>>>><br> >>>>> Sent from my iPhone<br> >>>>><br> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"= <br> >>> <<a href=3D"mailto:Ron_Parker@affirmednetworks.com" target= =3D"_blank">Ron_Parker@affirmednetworks.com</a>> wrote:<br> >>>>>><br> >>>>>> Jim,<br> >>>>>><br> >>>>>> There may not be a single node through which all o= f the<br> >>>>>> instances can<br> >>> be reached (at some reasonable limit of L2 or L3 hops).<br> >>>>>><br> >>>>>> Ron<br> >>>>>><br> >>>>>><br> >>>>>> -----Original Message-----<br> >>>>>> From: sfc [<a href=3D"mailto:sfc-bounces@ietf.org"= target=3D"_blank">mailto:sfc-bounces@ietf.org</a>] On Behalf Of Jim<br> >>>>>> Guichard<br> >>>>>> (jguichar)<br> >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM<br> >>>>>> To: NAPIERALA, MARIA H<br> >>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:mohamed.bou= cadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>; <a href=3D"mailto:sfc@ietf.org" target=3D= "_blank">sfc@ietf.org</a><br> >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers<br> >>>>>><br> >>>>>> At the node through which the 20 instances are rea= chable. IOW<br> >>>>>> you<br> >>> don't have to individually address packets to each and every i= nstance.<br> >>>>>><br> >>>>>> Sent from my iPhone<br> >>>>>><br> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>> wrote:<br> >>>>>>><br> >>>>>>> Hi Jim,<br> >>>>>>><br> >>>>>>> When you say "locally", where is it?= <br> >>>>>>><br> >>>>>>> Maria<br> >>>>>>><br> >>>>>>>> -----Original Message-----<br> >>>>>>>> From: Jim Guichard (jguichar) [<a href=3D"= mailto:jguichar@cisco.com" target=3D"_blank">mailto:jguichar@cisco.com</a>]= <br> >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM<br> >>>>>>>> To: NAPIERALA, MARIA H<br> >>>>>>>> Cc: Joel M. Halpern; <a href=3D"mailto:moh= amed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers<br> >>>>>>>><br> >>>>>>>> Hi Maria,<br> >>>>>>>><br> >>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at<br> >>>>>>>> each hop then you can choose to load balan= ce among them<br> >>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is<br> >>>>>>>> that if for some very odd and certainly no= t recommended reason<br> >>>>>>>> you want to treat each instance separately= then the<br> >>>>>>>> architecture does not<br> >>> prevent it.<br> >>>>>>>><br> >>>>>>>> Sent from my iPhone<br> >>>>>>>><br> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"<br> >>> <<a href=3D"mailto:mn1921@att.com" target=3D"_blank">mn1921= @att.com</a>><br> >>>>>>>> wrote:<br> >>>>>>>><br> >>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed<br> >>>>>>>>>> separately, then the service chain= ing infrastructure would<br> >>>>>>>>>> treat them as such, and would use = distinct service paths.<br> >>>>>>>>><br> >>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each<br> >>>>>>>>> hop, then I have<br> >>>>>>>> to globally manage 160,000 service paths (= for one chain)?<br> >>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..<br> >>>>>>>>><br> >>>>>>>>> Maria<br> >>>>>>>>><br> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:<br> >>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall<br> >>>>>>>>>>> instances<br> >>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you<br> >>>>>>>>>> will decide (make a load balancing= decision) at the entry to<br> >>>>>>>>>> the chain which of those<br> >>>>>>>> 20<br> >>>>>>>>>> firewalls will be used by a partic= ular flow?<br> >>>>>>>>>>><br> >>>>>>>>>>> Maria<br> >>>>>>>>>>><br> >>>>>>>>>>>> -----Original Message-----= <br> >>>>>>>>>>>> From: sfc [<a href=3D"mail= to:sfc-bounces@ietf.org" target=3D"_blank">mailto:sfc-bounces@ietf.org</a>]= On Behalf Of Joel<br> >>>>>>>>>>>> Halpern<br> >>>>>>>> Direct<br> >>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM<br> >>>>>>>>>>>> To: NAPIERALA, MARIA H; <a= href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com</a>;<br> >>>>>>>>>> <a href=3D"mailto:sfc@ietf.org" ta= rget=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load<br> >>>>>>>>>>>> Balancers<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The archtiecture allows fo= r this local decision, while<br> >>>>>>>>>>>> still having the global de= cision that is directing the traffic.<br> >>>>>>>>>>>> That is, the global decisi= on directs the traffic to places<br> >>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.<br> >>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of<br> >>>>>>>>>>>> algorithms to distribute t= he traffic internally, without<br> >>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be<br> >>>>>>>>>>>> done in such a way that re= turn traffic, if delivered<br> >>>>>>>>>>>> globally to the same place= , can then be delivered to the<br> >>>>>>>>>>>> right internal<br> >>>>>>>>>>>> state.)<br> >>>>>>>>>>>><br> >>>>>>>>>>>> The definition of the serv= ice path is about how service<br> >>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the<br> >>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to<br> >>>>>>>>>>>> do that, and they can give= the same external interface.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> We could write the archite= cture pretending that it always<br> >>>>>>>>>>>> addresses singular instanc= es, but knowing that reality<br> >>>>>>>>>>>> would allow load balanced = clusters at those locations.<br> >>>>>>>>>>>> But that would be a mislea= ding architectural description<br> >>>>>>>>>>>> and might be read to outla= w some solutions that fall<br> >>>>>>>>>>>> within the goal the WG<br> >>> wishes to meet.<br> >>>>>>>>>>>><br> >>>>>>>>>>>> Yours,<br> >>>>>>>>>>>> Joel<br> >>>>>>>>>>>><br> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:<br> >>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators<br> >>>>>>>>>>>>>> can be<br> >>>>>>>>>> determined<br> >>>>>>>>>>>> in<br> >>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC<br> >>>>>>>>>>>>>> forwarding be base= d<br> >>>>>>>>>> on<br> >>>>>>>>>>>> the<br> >>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of<br> >>>>>>>>>>>>>> service function i= dentifiers). This is more compliant<br> >>>>>>>>>>>>>> with the<br> >>> LB constraints above:<br> >>>>>>>>>>>> deciding<br> >>>>>>>>>>>>>> which locator to u= se for a given flow will be a local<br> >>>>>>>>>>>>>> decision not a cen= tralized one.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.<br> >>>>>>>>>>>>><br> >>>>>>>>>>>>> Maria<br> >>>>>>>>>>>><br> >>>>>>>>>>>> __________________________= _____________________<br> >>>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>>> <a href=3D"mailto:sfc@ietf= .org" target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>>> <a href=3D"https://www.iet= f.org/mailman/listinfo/sfc" target=3D"_blank"> https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>>>>>>>><br> >>>>>>>>>>> ______________________________= _________________<br> >>>>>>>>>>> sfc mailing list<br> >>>>>>>>>>> <a href=3D"mailto:sfc@ietf.org= " target=3D"_blank">sfc@ietf.org</a><br> >>>>>>>>>>> <a href=3D"https://www.ietf.or= g/mailman/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/list= info/sfc</a><br> >>>>>>>>><br> >>>>>>>>> ______________________________________= _________<br> >>>>>>>>> sfc mailing list<br> >>>>>>>>> <a href=3D"mailto:sfc@ietf.org" target= =3D"_blank">sfc@ietf.org</a><br> >>>>>>>>> <a href=3D"https://www.ietf.org/mailma= n/listinfo/sfc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc= </a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> sfc mailing list<br> >>>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">= sfc@ietf.org</a><br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/s= fc" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> sfc mailing list<br> >>>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@= ietf.org</a><br> >>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >>>><br> >>>> _______________________________________________<br> >>>> sfc mailing list<br> >>>> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf= .org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" targ= et=3D"_blank">https://www.ietf.org/mailman/listinfo/sfc</a><br> >><br> >> _______________________________________________<br> >> sfc mailing list<br> >> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a>= <br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sfc</a><br> ><br> > _______________________________________________<br> > sfc mailing list<br> > <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/sfc</a><br> <br> _______________________________________________<br> sfc mailing list<br> <a href=3D"mailto:sfc@ietf.org" target=3D"_blank">sfc@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/sfc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/sfc</a></span><span style=3D"color:black= "></span></p> </div> </div> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_419417C345CA5F48BF45F0A23955A0634A843871SEAEMBX02olympu_-- From nobody Tue Jul 15 15:56:00 2014 Return-Path: <linda.dunbar@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ADD1B29A4 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 l9VFKOqE9vH9 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 15:55:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB1B1B29AE for <sfc@ietf.org>; Tue, 15 Jul 2014 15:55:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHF63786; Tue, 15 Jul 2014 22:55:53 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 23:55:52 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 15:55:38 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: IETF90 Toronto SFC Agenda Thread-Index: AQHPoC/TWmyUq3V41kStUInid1a9jJuhvkBg Date: Tue, 15 Jul 2014 22:55:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9D429@dfweml701-chm.china.huawei.com> References: <CFEAA350.2EDB4%jguichar@cisco.com> In-Reply-To: <CFEAA350.2EDB4%jguichar@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.165] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9D429dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pPa5-S1MQ0zoRG7hZ2uqpSrDLrQ Subject: Re: [sfc] IETF90 Toronto SFC Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 22:55:59 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D429dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim and Thomas, With so many drafts to SFC, why not asking for two or three meeting slots? It is not fair to " turn down 7 requests". What are the criteria of choosin= g which drafts to be discussed in the f2f meeting time? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, July 15, 2014 8:22 AM To: sfc@ietf.org Subject: [sfc] IETF90 Toronto SFC Agenda Importance: High Dear WG: Below is the draft agenda for SFC. Please note that we received more reques= ts for presentation slots than could reasonably be accommodated (we had to = turn down 7 requests). We based our selection on overall relevance and impo= rtance to the SFC charter and the immediate deliverables (at this point, ar= chitecture, requirements, OAM, encapsulation). A copy of the agenda is posted here -> https://datatracker.ietf.org/secr/pr= oceedings/90/sfc/. Please can presented forward copies of their presentatio= ns to Thomas and I so that we can upload them to the proceedings page prior= to the meeting. 0.00 Introduction (WG-chairs) - [10 minutes] - Update on PS progression (WG-chairs) - [5 minutes] - Agenda bashing, note-well, (WG-chairs) - [5 minutes] 00:10 SFC requirements discussion (presenters + open-mic) - [20 minutes] Purpose: Discuss how to progress requirements within the WG. Which document= s should requirements be included in? How do requirements drive our charter= ? How should requirements be structured and documented? - SFC requirements discussion (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ - SFC requirements Q&A (open-mic) - [10 minutes] 00:30 SFC architecture discussion (presenters + open-mic) - [20 minutes] Purpose: Identify current status of architecture work. How do we get to a s= ingle WG document? What gaps need filling from other existing documents? Wh= at other documents fall under the umbrella of architecture? - SFC architecture merge (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ - SFC architecture Q&A (open-mic) - [10 minutes] 00:50 SFC encapsulation - [30 minutes] Purpose: Discuss WG progression of SFC encapsulation. - Network Service Headers (NSH) (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ - Service Chain Header (SCH) (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ - SFC encapsulation Q&A (open-mic) - [10 minutes] 01:20 Service Function Chaining Operations, Administration and Maintenance = Framework - [30 minutes] Purpose: Present SFC OAM framework, which is an essential piece of the SFC = charter and work areas. - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.= txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] 01:50 Open Source SFC - [15 minutes] Purpose: Present a working SFC implementation as a start to investigation i= nto the control / management plane requirements that need to be addressed a= s part of the SFC charter and reported back to OPS. - Open Source SFC implementation (Reinaldo Penno) - [15 minutes] 02:05 SFC use cases - [20 minutes] Purpose: Review use case progression. Are further documents needed? What is= missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ - SFC use case Q&A (open-mic) - [10 minutes] 02:25 Closing (WG chairs) - [5 minutes] Thank You Jim & Thomas --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D429dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Jim and Thomas, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">With so many drafts to SF= C, why not asking for two or three meeting slots? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">It is not fair to “ </span><span style=3D"font-size:13.5pt;font-family:"Calibri",&quo= t;sans-serif";color:black">turn down 7 requests”</span><span sty= le=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&quo= t;;color:#1F497D">. What are the criteria of choosing which drafts to be di= scussed in the f2f meeting time? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Tuesday, July 15, 2014 8:22 AM<br> <b>To:</b> sfc@ietf.org<br> <b>Subject:</b> [sfc] IETF90 Toronto SFC Agenda<br> <b>Importance:</b> High<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:13.5= pt;font-family:"Calibri","sans-serif";color:black">Dear= WG:<o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 14px"><span style= =3D"font-size:13.5pt;font-family:"Calibri","sans-serif"= ;color:black"><o:p> </o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:13.5= pt;font-family:"Calibri","sans-serif";color:black">Belo= w is the draft agenda for SFC. Please note that we received more requests f= or presentation slots than could reasonably be accommodated (we had to turn down 7 requests). We based our selection on overall releva= nce and importance to the SFC charter and the immediate deliverables (at th= is point, architecture, requirements, OAM, encapsulation).<o:p></o:p></span= ></p> </div> <div> <pre style=3D"word-wrap: break-word"><span style=3D"font-size:7.0pt;font-fa= mily:"Calibri","sans-serif";color:black">A copy of the = agenda is posted here -> </span><span style=3D"font-family:"Calibri= ","sans-serif";color:black"><a href=3D"https://datatracker.i= etf.org/secr/proceedings/90/sfc/"><span style=3D"font-size:7.0pt;color:blac= k">https://datatracker.ietf.org/secr/proceedings/90/sfc/</span></a>. Please= can presented forward copies of their presentations to Thomas and I so tha= t we can upload them to the proceedings page prior to the meeting. </span><= span style=3D"color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size:7.0pt;font-family:"Calibri","sans-serif";col= or:black">0.00 <b>Introduction</b> (WG-chairs) - [10 minutes]</span></u><sp= an style=3D"font-size:7.0pt;font-family:"Calibri","sans-seri= f";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Update on PS progression (WG-chairs) - [5 mi= nutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Agenda bashing, note-well, (WG-chairs) - [5 = minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">00:10 <b>SFC requirements discussion</b> (p= resenters + open-mic) - [20 minutes]</span></u><span style=3D"font-size= :7.0pt;font-family:"Calibri","sans-serif";color:black">= <o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Discuss how to progress requirements = within the WG. Which documents should requirements be included in? How do r= equirements drive our charter? How should requirements be structured and do= cumented?</span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></sp= an></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC requirements discussion (Ron Parker) - [10 minutes]<o:p></o:p>= </span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-boucadair-sfc-requirements/">http://datatracker.ietf.org/= doc/draft-boucadair-sfc-requirements/</a></span><span style=3D"font-size:7.= 0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC requirements Q&A (open-mic) - [10 minutes]</span><span sty= le=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size:7.0pt;font-family:"Calibri","sans-serif";col= or:black">00:30 <b>SFC architecture discussion </b>(presenters + open-m= ic) - [20 minutes]</span></u><span style=3D"font-size:7.0pt;font-family:&qu= ot;Calibri","sans-serif";color:black"><o:p></o:p></span></pr= e> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Identify current status of architectu= re work. How do we get to a single WG document? What gaps need filling from= other existing documents? What other documents fall under the umbrella of = architecture?<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC architecture merge (Carlos Pignataro) - = [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-merged-sfc-architecture/">http://datatracker.ietf.org/doc= /draft-merged-sfc-architecture/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC architecture Q&A (open-mic) - [10 mi= nutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">00:50 <b>SFC encapsulation</b> - [30 minute= s]</span></u><span style=3D"font-size:7.0pt;font-family:"Calibri"= ,"sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Discuss WG progression of SFC encapsu= lation.</span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span= ></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- Network Service Headers (NSH) (Paul Quinn) - [10 minutes]<o:p></o:= p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-quinn-sfc-nsh/">http://datatracker.ietf.org/doc/draft-qui= nn-sfc-nsh/</a></span><span style=3D"font-size:7.0pt;color:black"><o:p></o:= p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- Service Chain Header (SCH) (Ron Parker) - [10 minutes]<o:p></o:p><= /span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-zhang-sfc-sch/">http://datatracker.ietf.org/doc/draft-zha= ng-sfc-sch/</a>          =        </span><span style=3D"font-size:7.0pt;= color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC encapsulation Q&A (open-mic) - [10 minutes]<o:p></o:p></sp= an></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">01:20 <b>Service Function Chaining Operatio= ns, Administration and Maintenance Framework</b> - [30 minutes]</span></u><= span style=3D"font-size:7.0pt;font-family:"Calibri","sans-se= rif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Present SFC OAM framework, which is a= n essential piece of the SFC charter and work areas. <o:p></o:p></span></pr= e> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Framework (Sam Aldrin) - [10 minutes= ]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://www.ietf.org/= internet-drafts/draft-aldrin-sfc-oam-framework-00.txt">http://www.ietf.org/= internet-drafts/draft-aldrin-sfc-oam-framework-00.txt</a><o:p></o:p></span>= </pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Requirements / Framework (Ramki Kris= hnan) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"https://ietf.org/doc= /draft-krishnan-sfc-oam-req-framework/">https://ietf.org/doc/draft-krishnan= -sfc-oam-req-framework/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Q&A (open-mic) - [10 minutes]<o:= p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">01:50 <b>Open Source SFC</b> - [15 minutes]= </span></u><span style=3D"font-size:7.0pt;font-family:"Calibri",&= quot;sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Present a working SFC implementation = as a start to investigation into the control / management plane requirement= s that need to be addressed as part of the SFC charter and reported back to= OPS. <o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Open Source SFC implementation (Reinaldo Pen= no) - [15 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">02:05 <b>SFC use cases</b> - [20 minutes]</= span></u><span style=3D"font-size:7.0pt;font-family:"Calibri",&qu= ot;sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Review use case progression. Are furt= her documents needed? What is missing from existing WG documents?<o:p></o:p= ></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC Generic Use Cases (Hongyu Li) - [10 minu= tes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-liu-sfc-use-cases/">http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases/</a></span><span style=3D"font-size:7.0pt;color:black"><= o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC use case Q&A (open-mic) - [10 minutes]<o:p></o:p></span></= pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">02:25 <b>Closing</b> (WG chairs) - [5 minut= es]</span></u><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span= ></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">Thank You</span><span style=3D"font-size:7.0pt;color:black"><o:p></o= :p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">Jim & Thomas</span><span style=3D"font-size:7.0pt;color:black"><= o:p></o:p></span></pre> </div> </div> </div> </body> </html> --_000_4A95BA014132FF49AE685FAB4B9F17F645D9D429dfweml701chmchi_-- From nobody Tue Jul 15 16:24:17 2014 Return-Path: <eric.gray@ericsson.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5068F1A0160 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 16:24:07 -0700 (PDT) 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 WSsTVwIWDlgI for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 16:24:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A686F1A0165 for <sfc@ietf.org>; Tue, 15 Jul 2014 16:24:02 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-84-53c56577212b Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 49.68.05330.77565C35; Tue, 15 Jul 2014 19:31:36 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 19:23:54 -0400 From: Eric Gray <eric.gray@ericsson.com> To: Linda Dunbar <linda.dunbar@huawei.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: IETF90 Toronto SFC Agenda Thread-Index: AQHPoC/TWmyUq3V41kStUInid1a9jJuhvkBggAAI31A= Date: Tue, 15 Jul 2014 23:23:54 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B0B998@eusaamb107.ericsson.se> References: <CFEAA350.2EDB4%jguichar@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645D9D429@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9D429@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF632B0B998eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPt25F6tFgg79rRCyWzlO3uNsykcni yYOt7A7MHlN+b2T1aDnyltVjyZKfTAHMUVw2Kak5mWWpRfp2CVwZm3f0shQcO85YsfifbAPj ui2MXYycHBICJhIX12xig7DFJC7cWw9kc3EICRxllNiw5C4ThLOcUeLQ3x8sIFVsAhoSx+6s BesWEaiW6Du5kgnEFhZQk5h4bgMrRFxd4uvtdSwQtpVE2/wPYPUsAqoSpy52soPYvAK+El/O /AXrFQKas+fzNrA4p0CYxL9bO8HmMAJd9P3UGrAaZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/ rBC2osS+/unsEPX5En17n0PtEpQ4OfMJywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+Z YewzBx4zIYsvYGRfxchRWpxalptuZLCJERhTxyTYdHcw7nlpeYhRgINRiYf3gfHRYCHWxLLi ytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJygvGbFx2WXJkzX/Mv4 lOfjblcR/f6ET5Vuys/CbRodXu2zqJNplFLdtUMo8MXbllctIuV5/z5PtBOJ4FoQbz5nqnJu z7qYILUZJ173e6zlVcu7p/hx+1aDu8FZmwOyUq5G9O6K02qtuawVV2/wdp2cb5gAs6+4fviK RSc/T73yRelQkr/rCyWW4oxEQy3mouJEADcpJheKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lufieCl8ZYJZlC3VZ5AG-PHdaj0 Subject: Re: [sfc] IETF90 Toronto SFC Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Jul 2014 23:24:07 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF632B0B998eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, Jim clearly explained the criteria used. -- Eric From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, July 15, 2014 6:56 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] IETF90 Toronto SFC Agenda Jim and Thomas, With so many drafts to SFC, why not asking for two or three meeting slots? It is not fair to " turn down 7 requests". What are the criteria of choosin= g which drafts to be discussed in the f2f meeting time? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, July 15, 2014 8:22 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] IETF90 Toronto SFC Agenda Importance: High Dear WG: Below is the draft agenda for SFC. Please note that we received more reques= ts for presentation slots than could reasonably be accommodated (we had to = turn down 7 requests). We based our selection on overall relevance and impo= rtance to the SFC charter and the immediate deliverables (at this point, ar= chitecture, requirements, OAM, encapsulation). A copy of the agenda is posted here -> https://datatracker.ietf.org/secr/pr= oceedings/90/sfc/. Please can presented forward copies of their presentatio= ns to Thomas and I so that we can upload them to the proceedings page prior= to the meeting. 0.00 Introduction (WG-chairs) - [10 minutes] - Update on PS progression (WG-chairs) - [5 minutes] - Agenda bashing, note-well, (WG-chairs) - [5 minutes] 00:10 SFC requirements discussion (presenters + open-mic) - [20 minutes] Purpose: Discuss how to progress requirements within the WG. Which document= s should requirements be included in? How do requirements drive our charter= ? How should requirements be structured and documented? - SFC requirements discussion (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ - SFC requirements Q&A (open-mic) - [10 minutes] 00:30 SFC architecture discussion (presenters + open-mic) - [20 minutes] Purpose: Identify current status of architecture work. How do we get to a s= ingle WG document? What gaps need filling from other existing documents? Wh= at other documents fall under the umbrella of architecture? - SFC architecture merge (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ - SFC architecture Q&A (open-mic) - [10 minutes] 00:50 SFC encapsulation - [30 minutes] Purpose: Discuss WG progression of SFC encapsulation. - Network Service Headers (NSH) (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ - Service Chain Header (SCH) (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ - SFC encapsulation Q&A (open-mic) - [10 minutes] 01:20 Service Function Chaining Operations, Administration and Maintenance = Framework - [30 minutes] Purpose: Present SFC OAM framework, which is an essential piece of the SFC = charter and work areas. - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.= txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] 01:50 Open Source SFC - [15 minutes] Purpose: Present a working SFC implementation as a start to investigation i= nto the control / management plane requirements that need to be addressed a= s part of the SFC charter and reported back to OPS. - Open Source SFC implementation (Reinaldo Penno) - [15 minutes] 02:05 SFC use cases - [20 minutes] Purpose: Review use case progression. Are further documents needed? What is= missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ - SFC use case Q&A (open-mic) - [10 minutes] 02:25 Closing (WG chairs) - [5 minutes] Thank You Jim & Thomas --_000_48E1A67CB9CA044EADFEAB87D814BFF632B0B998eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda,<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           Jim clear= ly explained the criteria used.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">--<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Eric<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [mai= lto:sfc-bounces@ietf.org] <b>On Behalf Of </b>Linda Dunbar<br> <b>Sent:</b> Tuesday, July 15, 2014 6:56 PM<br> <b>To:</b> Jim Guichard (jguichar); sfc@ietf.org<br> <b>Subject:</b> Re: [sfc] IETF90 Toronto SFC Agenda<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Jim and Thomas, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">With so many drafts to SF= C, why not asking for two or three meeting slots? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">It is not fair to “ </span><span style=3D"font-size:13.5pt;font-family:"Calibri",&quo= t;sans-serif";color:black">turn down 7 requests”</span><span sty= le=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&quo= t;;color:#1F497D">. What are the criteria of choosing which drafts to be di= scussed in the f2f meeting time? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Linda<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> sfc [<a = href=3D"mailto:sfc-bounces@ietf.org">mailto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Tuesday, July 15, 2014 8:22 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] IETF90 Toronto SFC Agenda<br> <b>Importance:</b> High<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:13.5= pt;font-family:"Calibri","sans-serif";color:black">Dear= WG:<o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 14px"><span style= =3D"font-size:13.5pt;font-family:"Calibri","sans-serif"= ;color:black"><o:p> </o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:13.5= pt;font-family:"Calibri","sans-serif";color:black">Belo= w is the draft agenda for SFC. Please note that we received more requests f= or presentation slots than could reasonably be accommodated (we had to turn down 7 requests). We based our selection on overall releva= nce and importance to the SFC charter and the immediate deliverables (at th= is point, architecture, requirements, OAM, encapsulation).<o:p></o:p></span= ></p> </div> <div> <pre style=3D"word-wrap: break-word"><span style=3D"font-size:7.0pt;font-fa= mily:"Calibri","sans-serif";color:black">A copy of the = agenda is posted here -> </span><span style=3D"font-family:"Calibri= ","sans-serif";color:black"><a href=3D"https://datatracker.i= etf.org/secr/proceedings/90/sfc/"><span style=3D"font-size:7.0pt;color:blac= k">https://datatracker.ietf.org/secr/proceedings/90/sfc/</span></a>. Please= can presented forward copies of their presentations to Thomas and I so tha= t we can upload them to the proceedings page prior to the meeting. </span><= span style=3D"color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size:7.0pt;font-family:"Calibri","sans-serif";col= or:black">0.00 <b>Introduction</b> (WG-chairs) - [10 minutes]</span></u><sp= an style=3D"font-size:7.0pt;font-family:"Calibri","sans-seri= f";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Update on PS progression (WG-chairs) - [5 mi= nutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Agenda bashing, note-well, (WG-chairs) - [5 = minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">00:10 <b>SFC requirements discussion</b> (p= resenters + open-mic) - [20 minutes]</span></u><span style=3D"font-size= :7.0pt;font-family:"Calibri","sans-serif";color:black">= <o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Discuss how to progress requirements = within the WG. Which documents should requirements be included in? How do r= equirements drive our charter? How should requirements be structured and do= cumented?</span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></sp= an></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC requirements discussion (Ron Parker) - [10 minutes]<o:p></o:p>= </span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-boucadair-sfc-requirements/">http://datatracker.ietf.org/= doc/draft-boucadair-sfc-requirements/</a></span><span style=3D"font-size:7.= 0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC requirements Q&A (open-mic) - [10 minutes]</span><span sty= le=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size:7.0pt;font-family:"Calibri","sans-serif";col= or:black">00:30 <b>SFC architecture discussion </b>(presenters + open-m= ic) - [20 minutes]</span></u><span style=3D"font-size:7.0pt;font-family:&qu= ot;Calibri","sans-serif";color:black"><o:p></o:p></span></pr= e> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Identify current status of architectu= re work. How do we get to a single WG document? What gaps need filling from= other existing documents? What other documents fall under the umbrella of = architecture?<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC architecture merge (Carlos Pignataro) - = [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-merged-sfc-architecture/">http://datatracker.ietf.org/doc= /draft-merged-sfc-architecture/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC architecture Q&A (open-mic) - [10 mi= nutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">00:50 <b>SFC encapsulation</b> - [30 minute= s]</span></u><span style=3D"font-size:7.0pt;font-family:"Calibri"= ,"sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Discuss WG progression of SFC encapsu= lation.</span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span= ></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- Network Service Headers (NSH) (Paul Quinn) - [10 minutes]<o:p></o:= p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-quinn-sfc-nsh/">http://datatracker.ietf.org/doc/draft-qui= nn-sfc-nsh/</a></span><span style=3D"font-size:7.0pt;color:black"><o:p></o:= p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- Service Chain Header (SCH) (Ron Parker) - [10 minutes]<o:p></o:p><= /span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-zhang-sfc-sch/">http://datatracker.ietf.org/doc/draft-zha= ng-sfc-sch/</a>          =        </span><span style=3D"font-size:7.0pt;= color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC encapsulation Q&A (open-mic) - [10 minutes]<o:p></o:p></sp= an></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">01:20 <b>Service Function Chaining Operatio= ns, Administration and Maintenance Framework</b> - [30 minutes]</span></u><= span style=3D"font-size:7.0pt;font-family:"Calibri","sans-se= rif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Present SFC OAM framework, which is a= n essential piece of the SFC charter and work areas. <o:p></o:p></span></pr= e> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Framework (Sam Aldrin) - [10 minutes= ]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://www.ietf.org/= internet-drafts/draft-aldrin-sfc-oam-framework-00.txt">http://www.ietf.org/= internet-drafts/draft-aldrin-sfc-oam-framework-00.txt</a><o:p></o:p></span>= </pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Requirements / Framework (Ramki Kris= hnan) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"https://ietf.org/doc= /draft-krishnan-sfc-oam-req-framework/">https://ietf.org/doc/draft-krishnan= -sfc-oam-req-framework/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC OAM Q&A (open-mic) - [10 minutes]<o:= p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">01:50 <b>Open Source SFC</b> - [15 minutes]= </span></u><span style=3D"font-size:7.0pt;font-family:"Calibri",&= quot;sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Present a working SFC implementation = as a start to investigation into the control / management plane requirement= s that need to be addressed as part of the SFC charter and reported back to= OPS. <o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- Open Source SFC implementation (Reinaldo Pen= no) - [15 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">02:05 <b>SFC use cases</b> - [20 minutes]</= span></u><span style=3D"font-size:7.0pt;font-family:"Calibri",&qu= ot;sans-serif";color:black"><o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">Purpose: Review use case progression. Are furt= her documents needed? What is missing from existing WG documents?<o:p></o:p= ></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">- SFC Generic Use Cases (Hongyu Li) - [10 minu= tes]<o:p></o:p></span></pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black">   * <a href=3D"http://datatracker.i= etf.org/doc/draft-liu-sfc-use-cases/">http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases/</a></span><span style=3D"font-size:7.0pt;color:black"><= o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">- SFC use case Q&A (open-mic) - [10 minutes]<o:p></o:p></span></= pre> <pre><span style=3D"font-size:7.0pt;font-family:"Calibri","s= ans-serif";color:black"><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size:7.0pt;font-family:"Calibri",&quo= t;sans-serif";color:black">02:25 <b>Closing</b> (WG chairs) - [5 minut= es]</span></u><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span= ></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">Thank You</span><span style=3D"font-size:7.0pt;color:black"><o:p></o= :p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size:7.0pt;font-family:"Calibri","sans-serif";color:= black">Jim & Thomas</span><span style=3D"font-size:7.0pt;color:black"><= o:p></o:p></span></pre> </div> </div> </div> </body> </html> --_000_48E1A67CB9CA044EADFEAB87D814BFF632B0B998eusaamb107erics_-- From nobody Tue Jul 15 17:27:07 2014 Return-Path: <kegray@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6233E1B29BC for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 17:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 ZHLtuUw71SXO for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 17:27:04 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202931B29C3 for <sfc@ietf.org>; Tue, 15 Jul 2014 17:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25185; q=dns/txt; s=iport; t=1405470424; x=1406680024; h=from:to:subject:date:message-id:mime-version; bh=6k+4mZLPbTxUHwnf/IELQQCSXZfdtPH9MGThAvMOd18=; b=ka0V7QhoJe7flndHQ9gjpAlbD8+axfQiajKLI1IZeqL3OnZmRV4A9OtD z+z4Lvo9WWxXY+YRkAmCGa/dhMObGqkRFpOkSEXpQTapRDZHJKDyGzgrI k7axF1WeQOXAQQeSEaUFVx6OgYZ0x2T65U8NDSkNQ/NtrIsbI0L2r28gT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQHALPFxVOtJV2S/2dsb2JhbABPCoJHR1JXBK9qkC+BYodAAYEQFnWEAwEBAQQnBkEdAQgRAQIBAQEhBzkUAwYKBAESCYg5DcotF45vSw0KhEQFmxiBS5Jag0RsAYFE X-IronPort-AV: E=Sophos; i="5.01,668,1400025600"; d="scan'208,217"; a="61143978" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 16 Jul 2014 00:27:03 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6G0R3eh006261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 00:27:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 19:27:03 -0500 From: "Ken Gray (kegray)" <kegray@cisco.com> To: Linda Dunbar <linda.dunbar@huawei.com>, "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] IETF90 Toronto SFC Agenda Thread-Index: AQHPoIypA3mmqPX5XUeiynVmfo0AYQ== Date: Wed, 16 Jul 2014 00:27:02 +0000 Message-ID: <CFEB3CD1.3B595%kegray@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.73] Content-Type: multipart/alternative; boundary="_000_CFEB3CD13B595kegrayciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/acb_GRTQ4AddgiP0Ft_MgEWexnU Subject: Re: [sfc] IETF90 Toronto SFC Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 00:27:06 -0000 --_000_CFEB3CD13B595kegrayciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Writing never guarantees an audience in any arena (or we'd all be authors). Given the work ahead and the AMAZING wander on the sfc mailing list around = architecture, I'm fully for sticking to core discussions in the time allott= ed. As to multiple sessions, I would suggest we get our stuff together as a gro= up around architecture and the rest of the core before we go barking about = other things. I think Joel is doing an excellent job, btw - medal=96of-val= our stuff. Let's focus and finish THAT. As for all the disappointed authors and for those wanting to stretch the fi= ve minute question period into forever =85 I encourage the WG chairs to get= a stamp that says "USE THE LIST" =85 get people to review your work =85 ci= rculate your opinion =85 on the list. Unless you've just had a stroke of g= enius that we've all got to hear. From: Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>= > Date: Tuesday, July 15, 2014 6:55 PM To: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com= >>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>> Subject: Re: [sfc] IETF90 Toronto SFC Agenda Jim and Thomas, With so many drafts to SFC, why not asking for two or three meeting slots? It is not fair to =93 turn down 7 requests=94. What are the criteria of cho= osing which drafts to be discussed in the f2f meeting time? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, July 15, 2014 8:22 AM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [sfc] IETF90 Toronto SFC Agenda Importance: High Dear WG: Below is the draft agenda for SFC. Please note that we received more reques= ts for presentation slots than could reasonably be accommodated (we had to = turn down 7 requests). We based our selection on overall relevance and impo= rtance to the SFC charter and the immediate deliverables (at this point, ar= chitecture, requirements, OAM, encapsulation). A copy of the agenda is posted here -> https://datatracker.ietf.org/secr/pr= oceedings/90/sfc/. Please can presented forward copies of their presentatio= ns to Thomas and I so that we can upload them to the proceedings page prior= to the meeting. 0.00 Introduction (WG-chairs) - [10 minutes] - Update on PS progression (WG-chairs) - [5 minutes] - Agenda bashing, note-well, (WG-chairs) - [5 minutes] 00:10 SFC requirements discussion (presenters + open-mic) - [20 minutes] Purpose: Discuss how to progress requirements within the WG. Which document= s should requirements be included in? How do requirements drive our charter= ? How should requirements be structured and documented? - SFC requirements discussion (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements/ - SFC requirements Q&A (open-mic) - [10 minutes] 00:30 SFC architecture discussion (presenters + open-mic) - [20 minutes] Purpose: Identify current status of architecture work. How do we get to a s= ingle WG document? What gaps need filling from other existing documents? Wh= at other documents fall under the umbrella of architecture? - SFC architecture merge (Carlos Pignataro) - [10 minutes] * http://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ - SFC architecture Q&A (open-mic) - [10 minutes] 00:50 SFC encapsulation - [30 minutes] Purpose: Discuss WG progression of SFC encapsulation. - Network Service Headers (NSH) (Paul Quinn) - [10 minutes] * http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ - Service Chain Header (SCH) (Ron Parker) - [10 minutes] * http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ - SFC encapsulation Q&A (open-mic) - [10 minutes] 01:20 Service Function Chaining Operations, Administration and Maintenance = Framework - [30 minutes] Purpose: Present SFC OAM framework, which is an essential piece of the SFC = charter and work areas. - SFC OAM Framework (Sam Aldrin) - [10 minutes] * http://www.ietf.org/internet-drafts/draft-aldrin-sfc-oam-framework-00.= txt - SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minutes] * https://ietf.org/doc/draft-krishnan-sfc-oam-req-framework/ - SFC OAM Q&A (open-mic) - [10 minutes] 01:50 Open Source SFC - [15 minutes] Purpose: Present a working SFC implementation as a start to investigation i= nto the control / management plane requirements that need to be addressed a= s part of the SFC charter and reported back to OPS. - Open Source SFC implementation (Reinaldo Penno) - [15 minutes] 02:05 SFC use cases - [20 minutes] Purpose: Review use case progression. Are further documents needed? What is= missing from existing WG documents? - SFC Generic Use Cases (Hongyu Li) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ - SFC use case Q&A (open-mic) - [10 minutes] 02:25 Closing (WG chairs) - [5 minutes] Thank You Jim & Thomas --_000_CFEB3CD13B595kegrayciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <20250420E06A7A41A5CED1F01A85E5BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div>Writing never guarantees an audience in any arena (or we'd all be auth= ors).</div> <div><br> </div> <div>Given the work ahead and the AMAZING wander on the sfc mailing list ar= ound architecture, I'm fully for sticking to core discussions in the time a= llotted.</div> <div><br> </div> <div>As to multiple sessions, I would suggest we get our stuff together as = a group around architecture and the rest of the core before we go barking a= bout other things.  I think Joel is doing an excellent job, btw - meda= l=96of-valour stuff.  Let's focus and finish THAT.</div> <div><br> </div> <div>As for all the disappointed authors and for those wanting to stretch t= he five minute question period into forever =85 I encourage the WG chairs t= o get a stamp that says "USE THE LIST" =85 get people to review y= our work =85 circulate your opinion =85 on the list.  Unless you've just had a stroke of genius that we've all got to hear= .</div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Linda Dunbar <<a href=3D"m= ailto:linda.dunbar@huawei.com">linda.dunbar@huawei.com</a>><br> <span style=3D"font-weight:bold">Date: </span>Tuesday, July 15, 2014 6:55 P= M<br> <span style=3D"font-weight:bold">To: </span>"Jim Guichard (jguichar)&q= uot; <<a href=3D"mailto:jguichar@cisco.com">jguichar@cisco.com</a>>, = "<a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a>" <<a href=3D= "mailto:sfc@ietf.org">sfc@ietf.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>Re: [sfc] IETF90 Toronto S= FC Agenda<br> </div> <div><br> </div> <div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micro= soft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" x= mlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:/= /www.w3.org/TR/REC-html40"> <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); ">Jim and Thomas, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); ">With so many drafts to SFC, why no= t asking for two or three meeting slots? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); ">It is not fair to =93 </span><span style=3D"font-size: 13.5pt; font-family: Calibri, sans-serif; = color: black; ">turn down 7 requests=94</span><span style=3D"font-size: 11p= t; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">. What are = the criteria of choosing which drafts to be discussed in the f2f meeting time? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); ">Linda<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: Calibri= , sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt; font-family: Taho= ma, sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; font-fami= ly: Tahoma, sans-serif; "> sfc [<a href=3D"mailto:sfc-bounces@ietf.org">mai= lto:sfc-bounces@ietf.org</a>] <b>On Behalf Of </b>Jim Guichard (jguichar)<br> <b>Sent:</b> Tuesday, July 15, 2014 8:22 AM<br> <b>To:</b> <a href=3D"mailto:sfc@ietf.org">sfc@ietf.org</a><br> <b>Subject:</b> [sfc] IETF90 Toronto SFC Agenda<br> <b>Importance:</b> High<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size: 13.= 5pt; font-family: Calibri, sans-serif; color: black; ">Dear WG:<o:p></o:p><= /span></p> <p style=3D"margin:0in;margin-bottom:.0001pt;min-height: 14px"><span style= =3D"font-size: 13.5pt; font-family: Calibri, sans-serif; color: black; "><o= :p> </o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size: 13.= 5pt; font-family: Calibri, sans-serif; color: black; ">Below is the draft a= genda for SFC. Please note that we received more requests for presentation = slots than could reasonably be accommodated (we had to turn down 7 requests). We based our selection on overall releva= nce and importance to the SFC charter and the immediate deliverables (at th= is point, architecture, requirements, OAM, encapsulation).<o:p></o:p></span= ></p> </div> <div> <pre style=3D"word-wrap: break-word"><span style=3D"font-size: 7pt; font-fa= mily: Calibri, sans-serif; color: black; ">A copy of the agenda is posted h= ere -> </span><span style=3D"font-family: Calibri, sans-serif; color: bl= ack; "><a href=3D"https://datatracker.ietf.org/secr/proceedings/90/sfc/"><s= pan style=3D"font-size:7.0pt;color:black">https://datatracker.ietf.org/secr= /proceedings/90/sfc/</span></a>. Please can presented forward copies of the= ir presentations to Thomas and I so that we can upload them to the proceedi= ngs page prior to the meeting. </span><span style=3D"color:black"><o:p></o:= p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size: 7pt; font-family: Calibri, sans-serif; color: black; ">0.00 <b>= Introduction</b> (WG-chairs) - [10 minutes]</span></u><span style=3D"font-s= ize: 7pt; font-family: Calibri, sans-serif; color: black; "><o:p></o:p></sp= an></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- Update on PS progression (WG-chairs) - [5 minutes]<o:p></o:p><= /span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- Agenda bashing, note-well, (WG-chairs) - [5 minutes]<o:p></o:p= ></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">00:10 <b>SFC requirements discussion</b> (presenters + op= en-mic) - [20 minutes]</span></u><span style=3D"font-size: 7pt; font-family= : Calibri, sans-serif; color: black; "><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Discuss how to progress requirements within the WG. Whi= ch documents should requirements be included in? How do requirements drive = our charter? How should requirements be structured and documented?</span><s= pan style=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- SFC requi= rements discussion (Ron Parker) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://datatracker.ietf.org/doc/draft-= boucadair-sfc-requirements/">http://datatracker.ietf.org/doc/draft-boucadai= r-sfc-requirements/</a></span><span style=3D"font-size:7.0pt;color:black"><= o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- SFC requi= rements Q&A (open-mic) - [10 minutes]</span><span style=3D"font-size:7.= 0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><u><span style=3D= "font-size: 7pt; font-family: Calibri, sans-serif; color: black; ">00:30 <b= >SFC architecture discussion </b>(presenters + open-mic) - [20 minutes]= </span></u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif;= color: black; "><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Identify current status of architecture work. How do we= get to a single WG document? What gaps need filling from other existing do= cuments? What other documents fall under the umbrella of architecture?<o:p>= </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC architecture merge (Carlos Pignataro) - [10 minutes]<o:p><= /o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://datatracker.ietf.org/doc/draft-= merged-sfc-architecture/">http://datatracker.ietf.org/doc/draft-merged-sfc-= architecture/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC architecture Q&A (open-mic) - [10 minutes]<o:p></o:p><= /span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">00:50 <b>SFC encapsulation</b> - [30 minutes]</span></u><span= style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color: black; "= ><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Discuss WG progression of SFC encapsulation.</span><spa= n style=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- Network S= ervice Headers (NSH) (Paul Quinn) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://datatracker.ietf.org/doc/draft-= quinn-sfc-nsh/">http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/</a></s= pan><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- Service C= hain Header (SCH) (Ron Parker) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://datatracker.ietf.org/doc/draft-= zhang-sfc-sch/">http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/</a>&nb= sp;            =     </span><span style=3D"font-size:7.0pt;color:black"><o:p>= </o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- SFC encap= sulation Q&A (open-mic) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">01:20 <b>Service Function Chaining Operations, Administration= and Maintenance Framework</b> - [30 minutes]</span></u><span style=3D"font= -size: 7pt; font-family: Calibri, sans-serif; color: black; "><o:p></o:p></= span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Present SFC OAM framework, which is an essential piece = of the SFC charter and work areas. <o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC OAM Framework (Sam Aldrin) - [10 minutes]<o:p></o:p></span= ></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://www.ietf.org/internet-drafts/dr= aft-aldrin-sfc-oam-framework-00.txt">http://www.ietf.org/internet-drafts/dr= aft-aldrin-sfc-oam-framework-00.txt</a><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC OAM Requirements / Framework (Ramki Krishnan) - [10 minute= s]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"https://ietf.org/doc/draft-krishnan-sf= c-oam-req-framework/">https://ietf.org/doc/draft-krishnan-sfc-oam-req-frame= work/</a><o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC OAM Q&A (open-mic) - [10 minutes]<o:p></o:p></span></p= re> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">01:50 <b>Open Source SFC</b> - [15 minutes]</span></u><span s= tyle=3D"font-size: 7pt; font-family: Calibri, sans-serif; color: black; "><= o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Present a working SFC implementation as a start to inve= stigation into the control / management plane requirements that need to be = addressed as part of the SFC charter and reported back to OPS. <o:p></o:p><= /span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- Open Source SFC implementation (Reinaldo Penno) - [15 minutes]= <o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">02:05 <b>SFC use cases</b> - [20 minutes]</span></u><span sty= le=3D"font-size: 7pt; font-family: Calibri, sans-serif; color: black; "><o:= p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">Purpose: Review use case progression. Are further documents need= ed? What is missing from existing WG documents?<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">- SFC Generic Use Cases (Hongyu Li) - [10 minutes]<o:p></o:p></s= pan></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; ">   * <a href=3D"http://datatracker.ietf.org/doc/draft-= liu-sfc-use-cases/">http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases= /</a></span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span><= /pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">- SFC use c= ase Q&A (open-mic) - [10 minutes]<o:p></o:p></span></pre> <pre><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; color= : black; "><o:p> </o:p></span></pre> <pre><u><span style=3D"font-size: 7pt; font-family: Calibri, sans-serif; co= lor: black; ">02:25 <b>Closing</b> (WG chairs) - [5 minutes]</span></u><spa= n style=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">Thank You</= span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span></pre> <pre style=3D"word-wrap: break-word;white-space:pre-wrap"><span style=3D"fo= nt-size: 7pt; font-family: Calibri, sans-serif; color: black; ">Jim & T= homas</span><span style=3D"font-size:7.0pt;color:black"><o:p></o:p></span><= /pre> </div> </div> </div> </div> </div> </span> </body> </html> --_000_CFEB3CD13B595kegrayciscocom_-- From nobody Tue Jul 15 18:19:25 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F91B29DF for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 18:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 jcha5fgGPw-a for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 18:19:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCD21B29D5 for <sfc@ietf.org>; Tue, 15 Jul 2014 18:19:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHF69835; Wed, 16 Jul 2014 01:19:17 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 02:19:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 09:19:13 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "NAPIERALA, MARIA H" <mn1921@att.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Ron Parker" <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA///+f4CAAR1JIA== Date: Wed, 16 Jul 2014 01:19:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293658@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4BFA8@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] 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/51cQo4E9T6uiT0PrPAp1oxGHeBU Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 01:19:22 -0000 To some extent, the shortest path forwarding can be looked as an extreme of= the explicit path forwarding since the former has only specify a single ex= plicit hop (that's the destination). Similarly, case 3 and 1 could be looke= d as two extremes of case 1. Best regards, Xiaohu > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Wednesday, July 16, 2014 12:13 AM > To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > sfc@ietf.org; Ron Parker > Subject: RE: [sfc] SFC Terminology / Concepts >=20 > An SFC is traffic engineered or it is not traffic engineered. There is no= thing > in-between. >=20 > Maria >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > > Sent: Tuesday, July 15, 2014 4:49 AM > > To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > > sfc@ietf.org; Ron Parker > > Subject: Re: [sfc] SFC Terminology / Concepts > > > > Hi Med, > > > > IMHO, the architecture should allow the classifier to specify > > > > 1) a partial SFP (i.e., some SFFs along that partial SFP need to > > locally determine the appropriate SFF for the next SF); > > 2) a complete SFP (i.e., the SFF for each SF in the SFC has been > > determined by the centralized node); > > 3) an SFC (i.e., each SFF along the final SFP needs to locally > > determine the appropriate SFF for the next SF). > > > > In fact, case 3) could be looked as an extreme of case 1). > > > > Best regards, > > Xiaohu > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: Tuesday, July 15, 2014 3:22 PM > > > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > > > Subject: Re: [sfc] SFC Terminology / Concepts > > > > > > Hi Joel, > > > > > > As mentioned in several messages, I'm personally for the use of the > > > chain > > itself is > > > the main information to be conveyed in packets to drive forwarding > > actions. > > > > > > I can understand that an identifier can be assigned to a path that > > > is > > known in > > > advance, but if that path is not known I'm not sure how an > > > identifier can > > be > > > assigned to it! > > > > > > Joel, the use of "path" is really inappropriate to refer to > > > distributed > > instance > > > selection process for packets bound to a given SFC. > > > > > > Cheers, > > > Med > > > > > > >-----Message d'origine----- > > > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. > > > >Halpern Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; > > > >sfc@ietf.org; Ron Parker Objet=A0: Re: [sfc] SFC Terminology / > > > >Concepts > > > > > > > >The most likely realization of the architecture would be that the > > > >SFP assignment is recorded in an identifier which travels with the p= acket. > > > > > > > >Some folks seem to not want the architecture to mandate that. > > > > > > > >Yours, > > > >Joel > > > > > > > > > > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: > > > >> Your text scares me because it introduces some new concepts and > > > >> assumptions. > > > >> > > > >> I'd rather go with Joel's formulation. Clarifying question on that= : > > > >> am I right in seeing the implication that when control assigns an > > > >> SFP, the assignment is recorded by an identifier wwhich travels > > > >> with > > the > > > packet? > > > >> > > > >> Tom Taylor > > > >> > > > >> On 14/07/2014 2:22 PM, Ron Parker wrote: > > > >>> There is one missing word in my text. Please replace my propose= d > > text > > > >>> with: > > > >>> > > > >>> "The Service Function Chain (SFC) provides a fully abstract view > > > >>> of the service functions to be invoked and the order in which > > > >>> they are to be invoked for some particular flow or set of flows, > > > >>> without > > concern of > > > >>> actual service function instance selection. The Constrained-SFC > > > >>> (C-SFC) further allows for policy constraints to be added to the > > > >>> SFC affecting the instance selection of one or more of the > > > >>> service > > functions > > > >>> in the SFC. Any SFC may have any number of C-SFC's associated w= ith > > > >it." > > > >>> > > > >>> Thanks. > > > >>> > > > >>> Ron > > > >> ... > > > >> > > > >> > > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David > > > >>> Allan I > > > >>> *Sent:* Monday, July 14, 2014 2:03 PM > > > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org > > > >>> <mailto:sfc@ietf.org> > > > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > > > >>> > > > >>> I like that text, it strikes a good balance where an > > > >>> implementation has the option of making scale and resiliency a lo= cal > matter.. > > > >>> > > > >>> D > > > >>> > > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim > > > >>> Guichard > > > >>> (jguichar) > > > >>> *Sent:* Monday, July 14, 2014 10:48 AM > > > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > > > >>> *Subject:* [sfc] SFC Terminology / Concepts > > > >>> > > > >>> Dear WG: > > > >>> > > > >>> There has been much debate over the last few days with regards > > > >>> to SFC concepts. To try and form some consensus around > > > >>> terminology > > and > > > >>> concepts used to describe the architecture in the merged > > > >>> architecture draft, Joel has kindly suggested the following: > > > >>> > > > >>> "The SFP provides a level of indirection between the fully > > > >>> abstract notion of service path as a sequence of functions to be > > > >>> delivered, and the fully specified notion of exactly what > > > >>> instances of SFFs the packet will visit when it actually > > > >>> traverses the network. By allowing the control components to > > > >>> specify the use of this level of indirection, the deployment may > > > >>> choose the degree of SFF instance selection authority that is del= egated > to the network." > > > >>> > > > >>> I'd like to ask the WG as a whole, if this clarification is > > > >>> something that we can get consensus on. If so, I'll ask Joel to > > > >>> provide specific text, that reflects the above, for inclusion in > > > >>> the merged architecture draft. > > > >>> > > > >>> Thank You, > > > >>> > > > >>> Jim > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> sfc mailing list > > > >>> sfc@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/sfc > > > >>> > > > >> > > > >> _______________________________________________ > > > >> sfc mailing list > > > >> sfc@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sfc > > > >> > > > > > > > >_______________________________________________ > > > >sfc mailing list > > > >sfc@ietf.org > > > >https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > > > sfc mailing 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 Tue Jul 15 18:21:49 2014 Return-Path: <kegray@cisco.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828AB1B29E1 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 18:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 K1rYO7rxm1jf for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 18:21:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B651B29E0 for <sfc@ietf.org>; Tue, 15 Jul 2014 18:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9288; q=dns/txt; s=iport; t=1405473702; x=1406683302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RZOk0U25U/ejpTlr1fcRaWLeEcU7lyQk2yetBPsaks0=; b=TEFefxE+N8YWA965M2kYBLn4LhxVuhbSmaiibsPkP58ss1Nco5rw2DUt tSYWiwq4Zce/E55cS/PJiv6Jt67DE1uc0Tiel8Z22/lkzVn6gLzUdDsvR MDGpD3QHfLzSBSA8Xq7tAYPSKqYGwy1OQysc/cEnRHUA7aBlrjaAMUtMx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGXSxVOtJV2b/2dsb2JhbABZgw5SVwTBbwqHQgGBEBZ1hAMBAQEEAQEBYggBCwwEAgEIEQEDAQEBJwcnCxQDBggCBAENBRuIJw3KIhMEjxgIKwcGhD0BBJYzSoQblCWDRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="61159348" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 16 Jul 2014 01:21:41 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6G1LfBY021406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 01:21:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 20:21:41 -0500 From: "Ken Gray (kegray)" <kegray@cisco.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Sharon <sbarkai@gmail.com>, "Ron Parker" <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eQPTi3lb5yrE6l3u0vB5cMHZugtxwAgADDzwCAABzAAIAAAmaAgAAXWwCAAACvgIAASEsA Date: Wed, 16 Jul 2014 01:21:41 +0000 Message-ID: <CFEB40E3.3B5D0%kegray@cisco.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local> <7238EF83-D293-4D8F-8A43-370B854BFE78@gmail.com> <53C55EBB.7020802@joelhalpern.com> In-Reply-To: <53C55EBB.7020802@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.73] Content-Type: text/plain; charset="Windows-1252" Content-ID: <DDF5E0E8B892324B88FE00EC5B1E0FC7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/O2eKR4eEbFaiJ2FSe30FfJtDYps Cc: Xuxiaohu <xuxiaohu@huawei.com>, Dave Dolson <ddolson@sandvine.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 01:21:45 -0000 Agreed. =20 In fact, I would argue that one of the functions of the SFP would be to minimize required state - particularly a widespread need to be a "speaker" (in the forwarder) in some quasi-routing or NH resolution protocol - as much as possible. Granted, some of the transport-based forwarding (not ruled out) may require and even deploy such a speaker. This goes back to our original (I mean MONTHS ago) discussion on the benefits of NOT classifying on every node if you can avoid it. Sure, you can DO these things =8A they are not explicitly ruled out either. ON a separate note, regarding the discussion of stateful load balancing and/or load balancing into stateful functions (I'm so happy that we've moved away from flattening elasticity into a million chains, that I can barely contain myself). For the most part, I simplify the load balancing function (in my small rat brain) and it's forwarder as conjoined and with a single network axis =8A the instances get and return traffic via the LB entity (even if it's on different logical ports) =8A thus, it knows what instance it sent flow X to= , and when the return path is traversed it does more of the same. That is, the path takes me to the SFF of the LB and between it and it's conjoined function, it picks an instance and in the return path is pretty much going to do the same in the same fashion (HA with a stateful pair is just a further abstraction. Granted, that's a simple picture. In Dave's admittedly more complex scenario, where the instances have a separate SFF which in turn does not have a simple path that returns via the LB (and it's conjoined SFF), at the very least SFF1 could indicate the flow rule (hash) and instance (local IP or MAC) selected to SFF2 (I think that's as close to standardizing loadbalancers as you're going to get). In the same way, I think you can use metadata at classification to help globally synchronize load balancing (and other path related goo that might rely on local decision making). On 7/15/14 1:02 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote: >I was trying not to require that SFF be stateful load balancers. >They certainly can be. But I had hoped tha tthe architecture would not >mandate that. >Yours, >Joel > >On 7/15/14, 1:00 PM, Sharon wrote: >> Sound right. Most SFFs will latch to various flow fields as consistent >>balancing invariants per protocol and as a fast-path forwarding. SFFs >>can leverage also the chaining headers to help manage the context, >>workflow and reentrancy, and as additional local classification. >> >> --szb >> >>> On Jul 15, 2014, at 8:36 AM, Ron Parker >>><Ron_Parker@affirmednetworks.com> wrote: >>> >>> Hi, Dave. >>> >>> I agree that symmetrical is the more typical case. In order to do >>>their jobs, many SFF implementations will be stateful at the flow >>>level. When learning a flow in the "forward" direction, it should be >>>possible to discern and retain the previous hop instance (i.e., an SFF >>>or an ingress border node/classifier) for purposes of managing the >>>"reverse" flow in a symmetrical manner. Whether this recognition of >>>previous hop is solely at the transport layer or whether some protocol >>>fields need to be introduced to NSH/SCH is for further consideration. >>>Also, the architecture spec can call out this mode of behavior >>>explicitly in terms of SFF functional requirements. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Tuesday, July 15, 2014 11:28 AM >>> To: Joel Halpern Direct; Xuxiaohu; sfc@ietf.org >>> Subject: Re: [sfc] Proposed redefinition of SFP >>> >>> Giving SFFs forwarding discretion troubles me, considering multiple >>>vendors and bidirectional traffic, and this is why: >>> >>> When an SFF has some freedom to choose the next-SFF, this amounts to >>>an implicit (possibly opaque) forwarding rule. >>> Consider implicit rules in the context of bidirectional traffic, when >>>a stateful SF needs to see both directions of any given flow. >>> >>> For the bidirectional case, a stateful SF would need to be book-ended >>>with SFFs having compatible implicit forwarding rules. >>> >>> In this picture, SFF1 and SFF2 would need to have compatible implicit >>>forwarding rules so that stateful SFFA and SFFB receive the same flows. >>> ("Compatible" may mean anti-symmetric, such as balancing by source IP >>>in one case and destination IP in the other case. If the balancing is >>>load-aware, SFF1 and SFF2 would have to communicate about >>>load-balancing choices.) >>> >>> +----+ +----+ +----+ >>> -----|SFF1|----+----|SFFA|----+----|SFF2|---- >>> +----+ | +----+ | +----+ >>> | | >>> | +----+ | >>> +----|SFFB|----+ >>> +----+ >>> >>> I suspect the above might make sense for a single-vendor solution, but >>>I would hope that the standard allows the 4 SFFs to be from different >>>vendors. >>> >>> If SFF1 and SFF2 are from different vendors, we shouldn't rely on >>>implicit forwarding rules; they should be explicitly configured; one >>>method is to create explicit paths; another method would be >>>standardizing the classification rules used for load-balancing. >>> >>> If the above figure *is* a single-vendor solution (perhaps a server >>>farm with load-balancing), then the above figure can appear as a single >>>SFF from the protocol point of view. >>> >>> Vendor load-balancing solution, presenting the scalable system as a >>>single SFF: >>> >>> +-----------------------------------------+ >>> | | >>> | +----+ +----+ +----+ | >>> -----|LB1 |----+----|SF |----+----| LB2|---- >>> | +----+ | +----+ | +----+ | >>> | | | | >>> | | +----+ | | >>> | +----|SF |----+ | >>> | +----+ | >>> |SFF | >>> +-----------------------------------------+ >>> >>> >>> In summary, I have trouble with allowing "discretion" in forwarding >>>between SFFs. It should all be explicit. >>> >>> One could argue that it is useful for the unidirectional chaining >>>cases, I suppose. But explicit always works. >>> >>> >>> David Dolson >>> Senior Software Architect, Sandvine Inc. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern >>>Direct >>> Sent: Tuesday, July 15, 2014 9:45 AM >>> To: Xuxiaohu; sfc@ietf.org >>> Subject: Re: [sfc] Proposed redefinition of SFP >>> >>> Since folks have requested that SFF have discretion on selecting >>>next-SFF, it is important that the SFP scoping be able to restrict the >>>set of SFFs which will be used for the traffic. >>> At the same time, it is also true that the scoping can provide >>>restriction on which instances (among those available to the SFF that >>>could be used for the service chain) will be used. >>> >>> Net: It is important that the scoping allow for selecting SFFs. it is >>>reasonable to also allow restriction on service function instantiations. >>> >>> I want to be careful because if there is a load balancer hanging off >>>of the SFF, then I do not see how this scoping can affect the load >>>balancer instance selection. When the SFF has an integral load >>>balancer, then such restriction can take effect. >>> >>> Yours, >>> Joel >>> >>>> On 7/14/14, 10:04 PM, Xuxiaohu wrote: >>>> Hi Joel, >>>> >>>>> To rephrase this a bit (and then if folks agree on the concept, we >>>>> can pick the >>>>> wording): >>>>> >>>>> The SFP provides a level of indirection between the fully abstract >>>>> notion of service path as a sequence of functions to be delivered, >>>>> and the fully specified notion of exactly what instances of SFFs the >>>>> packet will visit when it actually traverses the network. >>>> >>>> Instances of SFFs or instances of SF? >>>> >>>>> By allowing the control components to specify the use of this level >>>>> of indirection, the deployment may choose the degree of SFF instance >>>>> selection authority that is delegated to the network. >>>> >>>> SFF instance or SF instance? >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing 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 Tue Jul 15 19:58:03 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2751C1B2A30 for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 UK9PmqHjw-FX for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 19:58:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDE41B2A2E for <sfc@ietf.org>; Tue, 15 Jul 2014 19:57:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC07837; Wed, 16 Jul 2014 02:57:58 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 03:57:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 10:57:54 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "He, Peng" <phe@ciena.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Ron Parker" <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpAgABLaICAANseoA== Date: Wed, 16 Jul 2014 02:57:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <B6D287BF58D35D4B882E012AD3E1756172E676B7@ONWVEXCHMB04.ciena.com> In-Reply-To: <B6D287BF58D35D4B882E012AD3E1756172E676B7@ONWVEXCHMB04.ciena.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] 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/Pfws7gwWSlc2GEtG1KI5vE0qB8U Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 02:58:02 -0000 Hi Peng, > -----Original Message----- > From: He, Peng [mailto:phe@ciena.com] > Sent: Tuesday, July 15, 2014 9:09 PM > To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > sfc@ietf.org; Ron Parker > Subject: RE: [sfc] SFC Terminology / Concepts >=20 > Try to understand the three scenarios you listed: you mean the classifier= can > specify a (partial or complete) SFP which is a list of SFFs, then each SF= F will > (locally) select one of the SF instances under itself for this SF. For pa= rtial SFP case, In either case, the SFF should be capable of selecting the appropriate inst= ance of a given SF attached to itself. it's an internal load-balancing issu= e. > each SFF will identify the SFI under itself and specify (like a classifie= r) next SFF(s). > The classifier (and SFF?) could obtain this (SFF) 'path' information fro= m either > centralized point (e.g., PCE, controller), or, via a distributed control = plane? For > partial SFP, will there be a re-classification to decide next SFF(s) or n= ot? If you want the SFF to locally determine the appropriate SFF for the next S= F, the SFF should have the capability of resolving the SFF for the next SF = based on certain constraints. Of course, it needs to know some information = about the SFs in advance, e.g., the information about which SFFs a given SF= is attached. Best regards, Xiaohu =20 > Regards, > Peng >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 15, 2014 4:49 AM > To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; > sfc@ietf.org; Ron Parker > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Hi Med, >=20 > IMHO, the architecture should allow the classifier to specify >=20 > 1) a partial SFP (i.e., some SFFs along that partial SFP need to locally = determine > the appropriate SFF for the next SF); > 2) a complete SFP (i.e., the SFF for each SF in the SFC has been determin= ed by > the centralized node); > 3) an SFC (i.e., each SFF along the final SFP needs to locally determine = the > appropriate SFF for the next SF). >=20 > In fact, case 3) could be looked as an extreme of case 1). >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, July 15, 2014 3:22 PM > > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > > Subject: Re: [sfc] SFC Terminology / Concepts > > > > Hi Joel, > > > > As mentioned in several messages, I'm personally for the use of the > > chain itself is the main information to be conveyed in packets to drive > forwarding actions. > > > > I can understand that an identifier can be assigned to a path that is > > known in advance, but if that path is not known I'm not sure how an > > identifier can be assigned to it! > > > > Joel, the use of "path" is really inappropriate to refer to > > distributed instance selection process for packets bound to a given SFC= . > > > > Cheers, > > Med > > > > >-----Message d'origine----- > > >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > > >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@ietf.= org; > > >Ron Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts > > > > > >The most likely realization of the architecture would be that the SFP > > >assignment is recorded in an identifier which travels with the packet. > > > > > >Some folks seem to not want the architecture to mandate that. > > > > > >Yours, > > >Joel > > > > > > > > >On 7/14/14, 2:37 PM, Tom Taylor wrote: > > >> Your text scares me because it introduces some new concepts and > > >> assumptions. > > >> > > >> I'd rather go with Joel's formulation. Clarifying question on that: > > >> am I right in seeing the implication that when control assigns an > > >> SFP, the assignment is recorded by an identifier wwhich travels > > >> with the > > packet? > > >> > > >> Tom Taylor > > >> > > >> On 14/07/2014 2:22 PM, Ron Parker wrote: > > >>> There is one missing word in my text. Please replace my proposed = text > > >>> with: > > >>> > > >>> "The Service Function Chain (SFC) provides a fully abstract view > > >>> of the service functions to be invoked and the order in which they > > >>> are to be invoked for some particular flow or set of flows, without > concern of > > >>> actual service function instance selection. The Constrained-SFC > > >>> (C-SFC) further allows for policy constraints to be added to the > > >>> SFC affecting the instance selection of one or more of the service > functions > > >>> in the SFC. Any SFC may have any number of C-SFC's associated wit= h > > >it." > > >>> > > >>> Thanks. > > >>> > > >>> Ron > > >> ... > > >> > > >> > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David > > >>> Allan I > > >>> *Sent:* Monday, July 14, 2014 2:03 PM > > >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> > > >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > > >>> > > >>> I like that text, it strikes a good balance where an > > >>> implementation has the option of making scale and resiliency a loca= l > matter.. > > >>> > > >>> D > > >>> > > >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim > > >>> Guichard > > >>> (jguichar) > > >>> *Sent:* Monday, July 14, 2014 10:48 AM > > >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > > >>> *Subject:* [sfc] SFC Terminology / Concepts > > >>> > > >>> Dear WG: > > >>> > > >>> There has been much debate over the last few days with regards to > > >>> SFC concepts. To try and form some consensus around terminology > > >>> and concepts used to describe the architecture in the merged > > >>> architecture draft, Joel has kindly suggested the following: > > >>> > > >>> "The SFP provides a level of indirection between the fully > > >>> abstract notion of service path as a sequence of functions to be > > >>> delivered, and the fully specified notion of exactly what > > >>> instances of SFFs the packet will visit when it actually traverses > > >>> the network. By allowing the control components to specify the use > > >>> of this level of indirection, the deployment may choose the degree > > >>> of SFF instance selection authority that is delegated to the networ= k." > > >>> > > >>> I'd like to ask the WG as a whole, if this clarification is > > >>> something that we can get consensus on. If so, I'll ask Joel to > > >>> provide specific text, that reflects the above, for inclusion in > > >>> the merged architecture draft. > > >>> > > >>> Thank You, > > >>> > > >>> Jim > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > >> > > > > > >_______________________________________________ > > >sfc mailing 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 From nobody Tue Jul 15 22:57:55 2014 Return-Path: <ramk@Brocade.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43461B2A9D for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 22:57:53 -0700 (PDT) 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 UmeKVb8G8UIN for <sfc@ietfa.amsl.com>; Tue, 15 Jul 2014 22:57:52 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA49A1B2A7E for <sfc@ietf.org>; Tue, 15 Jul 2014 22:57:52 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G5fpue014049; Tue, 15 Jul 2014 22:57:52 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n335pj3nh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 22:57:52 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 22:57:52 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 22:57:51 -0700 From: ramki Krishnan <ramk@Brocade.com> To: "'sfc@ietf.org'" <sfc@ietf.org> Date: Tue, 15 Jul 2014 22:57:51 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76gAJEL9w Message-ID: <C7634EB63EFD984A978DFB46EA5174F2C14FFB9611@HQ1-EXCH01.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9611HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_02:2014-07-15,2014-07-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160073 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QSsOyCAfAuEzgbqjsEVcvKgu2Ho Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" <diego.r.lopez@telefonica.com>, "dilikris@in.ibm.com" <dilikris@in.ibm.com> Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 05:57:54 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9611HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9611HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Please find more= information on NFVRG including charter at - <a href=3D"http://trac.tools.i= etf.org/group/irtf/trac/wiki/nfvrg">http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg</a><o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p>= <p class=3DMsoNormal>Please find meeting location and agenda at - <a href= =3D"http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90">http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90</a><o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<o:p></o= :p></p><p class=3DMsoNormal>Ramki on behalf of the co-chairs<o:p></o:p></p>= </div></body></html>= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9611HQ1EXCH01corp_-- From nobody Wed Jul 16 01:00:22 2014 Return-Path: <hongyu.li@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783C11B2AA4 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 k7sL6VJnC5Go for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:00:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BBE1B2ABC for <sfc@ietf.org>; Wed, 16 Jul 2014 01:00:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHF99705; Wed, 16 Jul 2014 08:00:13 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 09:00:12 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 15:59:55 +0800 From: "Hongyu Li (Julio)" <hongyu.li@huawei.com> To: Ron Parker <Ron_Parker@affirmednetworks.com>, Dave Dolson <ddolson@sandvine.com> Thread-Topic: [sfc] Proposed redefinition of SFP Thread-Index: AQHPn3eBZVJ4XaOk7kuiPUnt9hd945uf3S4AgADD0ACAABzAAIAAAmaAgAAFiICAAABnAIAAAKaAgAGPjdA= Date: Wed, 16 Jul 2014 07:59:54 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA4E0A3@SZXEMA509-MBX.china.huawei.com> References: <53C3F5CD.5080105@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293145@NKGEML512-MBS.china.huawei.com> <53C53070.7030706@joelhalpern.com> <E8355113905631478EFF04F5AA706E9830A2F517@wtl-exchp-2.sandvine.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B8C8C@MBX021-W3-CA-2.exch021.domain.local>, <E8355113905631478EFF04F5AA706E9830A2F69F@wtl-exchp-2.sandvine.com>, <B8B3E329-A29E-4560-8E95-4E28AA5C480C@affirmednetworks.com> <CC9141A3-4E8D-4F67-9137-A97A01A4FA21@affirmednetworks.com> In-Reply-To: <CC9141A3-4E8D-4F67-9137-A97A01A4FA21@affirmednetworks.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] 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/eBpo6HW_GHPuLTf87xAtDI0qL4Y Cc: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Xuxiaohu <xuxiaohu@huawei.com>, "sfc@ietf.org" <sfc@ietf.org> Subject: Re: [sfc] Proposed redefinition of SFP X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 08:00:20 -0000 SSBkbyBoYXZlIGNvbmNlcm5zIG9uIHRoaXMgbGVhcm5pbmcgYmVoYXZpb3IsIGVzcGVjaWFsbHkg d2hlbiBpdCBtYXkgaW5mbHVlbmNlIFNGQyBmb3J3YXJkaW5nIHBhdGhzLiBTRkMgYnkgbmF0dXJl IGlzIGEgY3VzdG9taXplZCwgc2VydmljZS1vcmllbnRlZCBmb3J3YXJkaW5nLCB3aGljaCBpcyBk aWZmZXJlbnQgZnJvbSBub3JtYWwgTDIgZm9yd2FyZGluZyBvciBMMyByb3V0aW5nLiBTRkZzIGxl YXJuIHNvbWUgc3RhdGVzIGFuZCBkZWNpZGUgcmV2ZXJzZSBwYXRoIGFjY29yZGluZ2x5IG1heSBy ZXN1bHQgaW4gdW5leHBlY3RlZCBmb3J3YXJkaW5nIHBhdGguIEl0IHdvdWxkIGJlIG11Y2ggbW9y ZSBwZXJzdWFzaXZlIHRvIHByb3ZlIHN1Y2ggYWN0aW9uIGlzIHRvdGFsbHkgc2FmZSBhbmQgdW5k ZXIgY29udHJvbCB3aXRoIGEgY29tcGxldGUgc29sdXRpb24uDQoNCkhvbmd5dQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTYsIDIw MTQgMTI6MDAgQU0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IEpvZWwgSGFscGVybiBEaXJlY3Q7IFh1 eGlhb2h1OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBQcm9wb3NlZCByZWRlZmlu aXRpb24gb2YgU0ZQDQoNCkFuZCwgSSBtaWdodCBhbHNvIGFkZCwgbG9jYWwgU0ZJIHNlbGVjdGlv bi4gDQoNCiAgIFJvbg0KDQo+IE9uIEp1bCAxNSwgMjAxNCwgYXQgMTE6NTggQU0sICJSb24gUGFy a2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBZZXMu ICAgQWxzbywgbGVhcm5pbmcgb2YgZmxvdyBzdGF0ZSB3aWxsIGZhY2lsaXRhdGUgbmV4dCBTRkYg c2VsZWN0aW9uIGluIHRoZSBmb3J3YXJkIGRpcmVjdGlvbi4gDQo+IA0KPiAgIFJvbg0KPiANCj4g DQo+PiBPbiBKdWwgMTUsIDIwMTQsIGF0IDExOjU2IEFNLCAiRGF2ZSBEb2xzb24iIDxkZG9sc29u QHNhbmR2aW5lLmNvbT4gd3JvdGU6DQo+PiANCj4+IFJvbiwNCj4+IFRvIGNsYXJpZnksIGFyZSB5 b3Ugc3VnZ2VzdGluZyBTRkZzIHJlbWVtYmVyIGZsb3cgc3RhdGUgc28gYXMgdG8gYmUgDQo+PiBh YmxlIHRvIG1ha2UgdGhlIGNvcnJlY3QgZGVjaXNpb24gaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlv bj8gIChMaWtlIA0KPj4gRXRoZXJuZXQgTUFDIGxlYXJuaW5nPykNCj4+IA0KPj4gLURhdmUNCj4+ IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUm9uIFBhcmtl ciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+PiBTZW50OiBUdWVz ZGF5LCBKdWx5IDE1LCAyMDE0IDExOjM3IEFNDQo+PiBUbzogRGF2ZSBEb2xzb247IEpvZWwgSGFs cGVybiBEaXJlY3Q7IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbc2Zj XSBQcm9wb3NlZCByZWRlZmluaXRpb24gb2YgU0ZQDQo+PiANCj4+IEhpLCBEYXZlLg0KPj4gDQo+ PiBJIGFncmVlIHRoYXQgc3ltbWV0cmljYWwgaXMgdGhlIG1vcmUgdHlwaWNhbCBjYXNlLiAgIElu IG9yZGVyIHRvIGRvIHRoZWlyIGpvYnMsIG1hbnkgU0ZGIGltcGxlbWVudGF0aW9ucyB3aWxsIGJl IHN0YXRlZnVsIGF0IHRoZSBmbG93IGxldmVsLiAgIFdoZW4gbGVhcm5pbmcgYSBmbG93IGluIHRo ZSAiZm9yd2FyZCIgZGlyZWN0aW9uLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gZGlzY2VybiBh bmQgcmV0YWluIHRoZSBwcmV2aW91cyBob3AgaW5zdGFuY2UgKGkuZS4sIGFuIFNGRiBvciBhbiBp bmdyZXNzIGJvcmRlciBub2RlL2NsYXNzaWZpZXIpIGZvciBwdXJwb3NlcyBvZiBtYW5hZ2luZyB0 aGUgInJldmVyc2UiIGZsb3cgaW4gYSBzeW1tZXRyaWNhbCBtYW5uZXIuICAgV2hldGhlciB0aGlz IHJlY29nbml0aW9uIG9mIHByZXZpb3VzIGhvcCBpcyBzb2xlbHkgYXQgdGhlIHRyYW5zcG9ydCBs YXllciBvciB3aGV0aGVyIHNvbWUgcHJvdG9jb2wgZmllbGRzIG5lZWQgdG8gYmUgaW50cm9kdWNl ZCB0byBOU0gvU0NIIGlzIGZvciBmdXJ0aGVyIGNvbnNpZGVyYXRpb24uICAgQWxzbywgdGhlIGFy Y2hpdGVjdHVyZSBzcGVjIGNhbiBjYWxsIG91dCB0aGlzIG1vZGUgb2YgYmVoYXZpb3IgZXhwbGlj aXRseSBpbiB0ZXJtcyBvZiBTRkYgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMuDQo+PiANCj4+ICBS b24NCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNvbg0K Pj4gU2VudDogVHVlc2RheSwgSnVseSAxNSwgMjAxNCAxMToyOCBBTQ0KPj4gVG86IEpvZWwgSGFs cGVybiBEaXJlY3Q7IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2Zj XSBQcm9wb3NlZCByZWRlZmluaXRpb24gb2YgU0ZQDQo+PiANCj4+IEdpdmluZyBTRkZzIGZvcndh cmRpbmcgZGlzY3JldGlvbiB0cm91YmxlcyBtZSwgY29uc2lkZXJpbmcgbXVsdGlwbGUgdmVuZG9y cyBhbmQgYmlkaXJlY3Rpb25hbCB0cmFmZmljLCBhbmQgdGhpcyBpcyB3aHk6DQo+PiANCj4+IFdo ZW4gYW4gU0ZGIGhhcyBzb21lIGZyZWVkb20gdG8gY2hvb3NlIHRoZSBuZXh0LVNGRiwgdGhpcyBh bW91bnRzIHRvIGFuIGltcGxpY2l0IChwb3NzaWJseSBvcGFxdWUpIGZvcndhcmRpbmcgcnVsZS4N Cj4+IENvbnNpZGVyIGltcGxpY2l0IHJ1bGVzIGluIHRoZSBjb250ZXh0IG9mIGJpZGlyZWN0aW9u YWwgdHJhZmZpYywgd2hlbiBhIHN0YXRlZnVsIFNGIG5lZWRzIHRvIHNlZSBib3RoIGRpcmVjdGlv bnMgb2YgYW55IGdpdmVuIGZsb3cuDQo+PiANCj4+IEZvciB0aGUgYmlkaXJlY3Rpb25hbCBjYXNl LCBhIHN0YXRlZnVsIFNGIHdvdWxkIG5lZWQgdG8gYmUgYm9vay1lbmRlZCB3aXRoIFNGRnMgaGF2 aW5nIGNvbXBhdGlibGUgaW1wbGljaXQgZm9yd2FyZGluZyBydWxlcy4NCj4+IA0KPj4gSW4gdGhp cyBwaWN0dXJlLCBTRkYxIGFuZCBTRkYyIHdvdWxkIG5lZWQgdG8gaGF2ZSBjb21wYXRpYmxlIGlt cGxpY2l0IGZvcndhcmRpbmcgcnVsZXMgc28gdGhhdCBzdGF0ZWZ1bCBTRkZBIGFuZCBTRkZCIHJl Y2VpdmUgdGhlIHNhbWUgZmxvd3MuIA0KPj4gKCJDb21wYXRpYmxlIiBtYXkgbWVhbiBhbnRpLXN5 bW1ldHJpYywgc3VjaCBhcyBiYWxhbmNpbmcgYnkgc291cmNlIElQIA0KPj4gaW4gb25lIGNhc2Ug YW5kIGRlc3RpbmF0aW9uIElQIGluIHRoZSBvdGhlciBjYXNlLiBJZiB0aGUgYmFsYW5jaW5nIGlz IA0KPj4gbG9hZC1hd2FyZSwgU0ZGMSBhbmQgU0ZGMiB3b3VsZCBoYXZlIHRvIGNvbW11bmljYXRl IGFib3V0IA0KPj4gbG9hZC1iYWxhbmNpbmcgY2hvaWNlcy4pDQo+PiANCj4+ICAgICstLS0tKyAg ICAgICAgICstLS0tKyAgICAgICAgICstLS0tKw0KPj4gLS0tLS18U0ZGMXwtLS0tKy0tLS18U0ZG QXwtLS0tKy0tLS18U0ZGMnwtLS0tDQo+PiAgICArLS0tLSsgICAgfCAgICArLS0tLSsgICAgfCAg ICArLS0tLSsNCj4+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQo+PiAgICAgICAgICAg ICAgfCAgICArLS0tLSsgICAgfA0KPj4gICAgICAgICAgICAgICstLS0tfFNGRkJ8LS0tLSsNCj4+ ICAgICAgICAgICAgICAgICAgICstLS0tKw0KPj4gDQo+PiBJIHN1c3BlY3QgdGhlIGFib3ZlIG1p Z2h0IG1ha2Ugc2Vuc2UgZm9yIGEgc2luZ2xlLXZlbmRvciBzb2x1dGlvbiwgYnV0IEkgd291bGQg aG9wZSB0aGF0IHRoZSBzdGFuZGFyZCBhbGxvd3MgdGhlIDQgU0ZGcyB0byBiZSBmcm9tIGRpZmZl cmVudCB2ZW5kb3JzLg0KPj4gDQo+PiBJZiBTRkYxIGFuZCBTRkYyIGFyZSBmcm9tIGRpZmZlcmVu dCB2ZW5kb3JzLCB3ZSBzaG91bGRuJ3QgcmVseSBvbiBpbXBsaWNpdCBmb3J3YXJkaW5nIHJ1bGVz OyB0aGV5IHNob3VsZCBiZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQ7IG9uZSBtZXRob2QgaXMgdG8g Y3JlYXRlIGV4cGxpY2l0IHBhdGhzOyBhbm90aGVyIG1ldGhvZCB3b3VsZCBiZSBzdGFuZGFyZGl6 aW5nIHRoZSBjbGFzc2lmaWNhdGlvbiBydWxlcyB1c2VkIGZvciBsb2FkLWJhbGFuY2luZy4NCj4+ IA0KPj4gSWYgdGhlIGFib3ZlIGZpZ3VyZSAqaXMqIGEgc2luZ2xlLXZlbmRvciBzb2x1dGlvbiAo cGVyaGFwcyBhIHNlcnZlciBmYXJtIHdpdGggbG9hZC1iYWxhbmNpbmcpLCB0aGVuIHRoZSBhYm92 ZSBmaWd1cmUgY2FuIGFwcGVhciBhcyBhIHNpbmdsZSBTRkYgZnJvbSB0aGUgcHJvdG9jb2wgcG9p bnQgb2Ygdmlldy4NCj4+IA0KPj4gVmVuZG9yIGxvYWQtYmFsYW5jaW5nIHNvbHV0aW9uLCBwcmVz ZW50aW5nIHRoZSBzY2FsYWJsZSBzeXN0ZW0gYXMgYSBzaW5nbGUgU0ZGOg0KPj4gDQo+PiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiB8ICAgKy0tLS0rICAgICAgICAgKy0t LS0rICAgICAgICAgKy0tLS0rICB8DQo+PiAtLS0tLXxMQjEgfC0tLS0rLS0tLXxTRiAgfC0tLS0r LS0tLXwgTEIyfC0tLS0NCj4+IHwgICArLS0tLSsgICAgfCAgICArLS0tLSsgICAgfCAgICArLS0t LSsgIHwNCj4+IHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCj4+ IHwgICAgICAgICAgICAgfCAgICArLS0tLSsgICAgfCAgICAgICAgICAgIHwNCj4+IHwgICAgICAg ICAgICAgKy0tLS18U0YgIHwtLS0tKyAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgICAgICAg ICArLS0tLSsgICAgICAgICAgICAgICAgIHwNCj4+IHxTRkYgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCj4+IA0KPj4gDQo+PiBJbiBzdW1tYXJ5LCBJIGhhdmUgdHJvdWJsZSB3aXRoIGFs bG93aW5nICJkaXNjcmV0aW9uIiBpbiBmb3J3YXJkaW5nIGJldHdlZW4gU0ZGcy4gSXQgc2hvdWxk IGFsbCBiZSBleHBsaWNpdC4NCj4+IA0KPj4gT25lIGNvdWxkIGFyZ3VlIHRoYXQgaXQgaXMgdXNl ZnVsIGZvciB0aGUgdW5pZGlyZWN0aW9uYWwgY2hhaW5pbmcgY2FzZXMsIEkgc3VwcG9zZS4gQnV0 IGV4cGxpY2l0IGFsd2F5cyB3b3Jrcy4NCj4+IA0KPj4gDQo+PiBEYXZpZCBEb2xzb24NCj4+IFNl bmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2aW5lIEluYy4NCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIEhhbHBlcm4gDQo+PiBE aXJlY3QNCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMTQgOTo0NSBBTQ0KPj4gVG86IFh1 eGlhb2h1OyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBQcm9wb3NlZCByZWRl ZmluaXRpb24gb2YgU0ZQDQo+PiANCj4+IFNpbmNlIGZvbGtzIGhhdmUgcmVxdWVzdGVkIHRoYXQg U0ZGIGhhdmUgZGlzY3JldGlvbiBvbiBzZWxlY3RpbmcgbmV4dC1TRkYsIGl0IGlzIGltcG9ydGFu dCB0aGF0IHRoZSBTRlAgc2NvcGluZyBiZSBhYmxlIHRvIHJlc3RyaWN0IHRoZSBzZXQgb2YgU0ZG cyB3aGljaCB3aWxsIGJlIHVzZWQgZm9yIHRoZSB0cmFmZmljLg0KPj4gQXQgdGhlIHNhbWUgdGlt ZSwgaXQgaXMgYWxzbyB0cnVlIHRoYXQgdGhlIHNjb3BpbmcgY2FuIHByb3ZpZGUgcmVzdHJpY3Rp b24gb24gd2hpY2ggaW5zdGFuY2VzIChhbW9uZyB0aG9zZSBhdmFpbGFibGUgdG8gdGhlIFNGRiB0 aGF0IGNvdWxkIGJlIHVzZWQgZm9yIHRoZSBzZXJ2aWNlIGNoYWluKSB3aWxsIGJlIHVzZWQuDQo+ PiANCj4+IE5ldDogSXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHNjb3BpbmcgYWxsb3cgZm9yIHNl bGVjdGluZyBTRkZzLiAgaXQgaXMgcmVhc29uYWJsZSB0byBhbHNvIGFsbG93IHJlc3RyaWN0aW9u IG9uIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFudGlhdGlvbnMuDQo+PiANCj4+IEkgd2FudCB0byBi ZSBjYXJlZnVsIGJlY2F1c2UgaWYgdGhlcmUgaXMgYSBsb2FkIGJhbGFuY2VyIGhhbmdpbmcgb2Zm IG9mIHRoZSBTRkYsIHRoZW4gSSBkbyBub3Qgc2VlIGhvdyB0aGlzIHNjb3BpbmcgY2FuIGFmZmVj dCB0aGUgbG9hZCBiYWxhbmNlciBpbnN0YW5jZSBzZWxlY3Rpb24uICBXaGVuIHRoZSBTRkYgaGFz IGFuIGludGVncmFsIGxvYWQgYmFsYW5jZXIsIHRoZW4gc3VjaCByZXN0cmljdGlvbiBjYW4gdGFr ZSBlZmZlY3QuDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+Pj4gT24gNy8xNC8xNCwg MTA6MDQgUE0sIFh1eGlhb2h1IHdyb3RlOg0KPj4+IEhpIEpvZWwsDQo+Pj4gDQo+Pj4+IFRvIHJl cGhyYXNlIHRoaXMgYSBiaXQgKGFuZCB0aGVuIGlmIGZvbGtzIGFncmVlIG9uIHRoZSBjb25jZXB0 LCB3ZSANCj4+Pj4gY2FuIHBpY2sgdGhlDQo+Pj4+IHdvcmRpbmcpOg0KPj4+PiANCj4+Pj4gVGhl IFNGUCBwcm92aWRlcyBhIGxldmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIGZ1bGx5IGFi c3RyYWN0IA0KPj4+PiBub3Rpb24gb2Ygc2VydmljZSBwYXRoIGFzIGEgc2VxdWVuY2Ugb2YgZnVu Y3Rpb25zIHRvIGJlIGRlbGl2ZXJlZCwgDQo+Pj4+IGFuZCB0aGUgZnVsbHkgc3BlY2lmaWVkIG5v dGlvbiBvZiBleGFjdGx5IHdoYXQgaW5zdGFuY2VzIG9mIFNGRnMgDQo+Pj4+IHRoZSBwYWNrZXQg d2lsbCB2aXNpdCB3aGVuIGl0IGFjdHVhbGx5IHRyYXZlcnNlcyB0aGUgbmV0d29yay4NCj4+PiAN Cj4+PiBJbnN0YW5jZXMgb2YgU0ZGcyBvciBpbnN0YW5jZXMgb2YgU0Y/DQo+Pj4gDQo+Pj4+IEJ5 IGFsbG93aW5nIHRoZSBjb250cm9sIGNvbXBvbmVudHMgdG8gc3BlY2lmeSB0aGUgdXNlIG9mIHRo aXMgbGV2ZWwgDQo+Pj4+IG9mIGluZGlyZWN0aW9uLCB0aGUgZGVwbG95bWVudCBtYXkgY2hvb3Nl IHRoZSBkZWdyZWUgb2YgU0ZGIA0KPj4+PiBpbnN0YW5jZSBzZWxlY3Rpb24gYXV0aG9yaXR5IHRo YXQgaXMgZGVsZWdhdGVkIHRvIHRoZSBuZXR3b3JrLg0KPj4+IA0KPj4+IFNGRiBpbnN0YW5jZSBv ciBTRiBpbnN0YW5jZT8NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gWGlhb2h1DQo+Pj4g DQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+ IHNmY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4g c2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Wed Jul 16 01:40:39 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106891B29E4 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:40:38 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0mc1i0RbamZB for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:40:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7246E1B2ADD for <sfc@ietf.org>; Wed, 16 Jul 2014 01:40:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A272D3B4318; Wed, 16 Jul 2014 10:40:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8045127C058; Wed, 16 Jul 2014 10:40:33 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 16 Jul 2014 10:40:33 +0200 From: <mohamed.boucadair@orange.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPoD5q8Pl2nv4amkeW+iiVKhPLs5uiVvYg Date: Wed, 16 Jul 2014 08:40:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330033731@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53C54389.9070200@joelhalpern.com> In-Reply-To: <53C54389.9070200@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.7.16.64820 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/-aejgeprYKZacvPpcUXEoktgt-M Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 08:40:38 -0000 Hi Joel, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: mardi 15 juillet 2014 17:07 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Tom Taylor; sfc@ietf.org; Ron Parker >Objet=A0: Re: [sfc] SFC Terminology / Concepts > >My concern is that there are requests (which I happen to support) for >allowing a degree of policy expression or scope restriction in what the >classification communicates to the infrastructure about the service >delivery. This needs to include restrictions on SFF selection and >probably at least allow for restrictions on ctual instance selection. [Med] Several comments here: * These are constraints as expressed in Ron's counter-proposal, that I stil= l support.=20 * I understand that if it is presented as an ** optional ** feature, but no= t as the base model.=20 * At least many operator representatives who expressed their opinions in th= is thread are for a simple model that assumes a complete distributed forwar= ding model. You should also acknowledge that!=20 * The architecture should not be drawn only from the perspective of the fav= orite option you support.=20 * I'm for a requirement-driven approach + avoid over-specification + simpli= city. The simplicity argument suggests to go for a distributed model as the= base model.=20 * There are also implications on device procurement that we should not igno= re. The distributed model minimizes the need for another set of devices to = be deployed because advanced features must be centralized. The model should= not mandate a centralized approach; it can allow for it for those requirin= g it. This is again deployment-specific. > >Given that the restriction includes the case "allow all", expressing the >information in terms of this intermediate allows for the requirement, >allows for the communication of the equivalent of the unlimited chain, >and allows for expression of the exact choice when operations has >selected that behavior. [Med] Some comments here: =20 * a path has a connotation that we cannot ignore just because a term has be= en chosen in a given solution document (read nsh).=20 * we need to make progress and ACK there are issues with the proposed appro= ach in the merged draft and also the inaccurate terminology (read change SF= P). * there are various ways to communicate forwarding constraints to a node: (1) this can be conveyed in the packet itself (by including some kind of Ex= plicit Route Object as in RSVP-TE or a pointer to that object),=20 (2) by relying on the chain itself + provisioning constraints directly to a= subset of SFFs, (3) Etc. * A C-SFC can be expressed as an order list of elements: {element 1, elemen= t 2, element 3, .., element n} while an "element" can be structured as a Se= rvice Function Identifier or a Service Function Locator. > >Communicating the chain does not add anything to this, and if it were >used instead of the itnermediate it would remove the ability to meet the >requirements. [Med] Disagree. I do still think your analysis is biased with a solution in= mind. The chain information is sufficient for a full distributed model. Yo= u can consider the parallel with a native IP networks where forwarding acti= ons are undertaken based on the destination IP address. In a SFC domain, in= stead of using dest-IP, local forwarding actions can be rely solely on the = chain identifier. It is not because there are MPLS/MPLS-TE/IP TE solution t= hat every operational network must support those! > >Yours, >Joel > >On 7/15/14, 3:21 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, >> >> As mentioned in several messages, I'm personally for the use of the chai= n >itself is the main information to be conveyed in packets to drive >forwarding actions. >> >> I can understand that an identifier can be assigned to a path that is >known in advance, but if that path is not known I'm not sure how an >identifier can be assigned to it! >> >> Joel, the use of "path" is really inappropriate to refer to distributed >instance selection process for packets bound to a given SFC. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>> Envoy=E9 : lundi 14 juillet 2014 21:52 >>> =C0 : Tom Taylor; sfc@ietf.org; Ron Parker >>> Objet : Re: [sfc] SFC Terminology / Concepts >>> >>> The most likely realization of the architecture would be that the SFP >>> assignment is recorded in an identifier which travels with the packet. >>> >>> Some folks seem to not want the architecture to mandate that. >>> >>> Yours, >>> Joel >>> >>> >>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>> Your text scares me because it introduces some new concepts and >>>> assumptions. >>>> >>>> I'd rather go with Joel's formulation. Clarifying question on that: am >I >>>> right in seeing the implication that when control assigns an SFP, the >>>> assignment is recorded by an identifier wwhich travels with the packet= ? >>>> >>>> Tom Taylor >>>> >>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>> There is one missing word in my text. Please replace my proposed >text >>>>> with: >>>>> >>>>> "The Service Function Chain (SFC) provides a fully abstract view of >the >>>>> service functions to be invoked and the order in which they are to be >>>>> invoked for some particular flow or set of flows, without concern of >>>>> actual service function instance selection. The Constrained-SFC >>>>> (C-SFC) further allows for policy constraints to be added to the SFC >>>>> affecting the instance selection of one or more of the service >functions >>>>> in the SFC. Any SFC may have any number of C-SFC's associated with >>> it." >>>>> >>>>> Thanks. >>>>> >>>>> Ron >>>> ... >>>> >>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David Allan I >>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>> >>>>> I like that text, it strikes a good balance where an implementation >has >>>>> the option of making scale and resiliency a local matter.. >>>>> >>>>> D >>>>> >>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>>>> (jguichar) >>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>> >>>>> Dear WG: >>>>> >>>>> There has been much debate over the last few days with regards to SFC >>>>> concepts. To try and form some consensus around terminology and >concepts >>>>> used to describe the architecture in the merged architecture draft, >Joel >>>>> has kindly suggested the following: >>>>> >>>>> "The SFP provides a level of indirection between the fully abstract >>>>> notion of service path as a sequence of functions to be delivered, an= d >>>>> the fully specified notion of exactly what instances of SFFs the >packet >>>>> will visit when it actually traverses the network. By allowing the >>>>> control components to specify the use of this level of indirection, >the >>>>> deployment may choose the degree of SFF instance selection authority >>>>> that is delegated to the network." >>>>> >>>>> I'd like to ask the WG as a whole, if this clarification is something >>>>> that we can get consensus on. If so, I'll ask Joel to provide specifi= c >>>>> text, that reflects the above, for inclusion in the merged >architecture >>>>> draft. >>>>> >>>>> Thank You, >>>>> >>>>> Jim >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Wed Jul 16 01:44:47 2014 Return-Path: <hongyu.li@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92761A032F for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 LuGEmUl0xG-B for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:44:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E53C1A0306 for <sfc@ietf.org>; Wed, 16 Jul 2014 01:44:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG04892; Wed, 16 Jul 2014 08:44:38 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 09:44:37 +0100 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.59]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 16:44:33 +0800 From: "Hongyu Li (Julio)" <hongyu.li@huawei.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGcehAFWk0UlrkuDAFiCqbIQwJuiYWqQ Date: Wed, 16 Jul 2014 08:44:32 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> In-Reply-To: <53C587C1.6080506@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] 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/c8fVk4txp71JSRpGITHBnQQO-hg Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 08:44:44 -0000 SSBkbyBoYXZlIGEgZGlmZmVyZW50IHZpZXcuIE9uIHdoYXQgZ3JvdW5kIHNoYWxsIHdlIGV4Y2x1 ZGUgbWV0YWRhdGEgZnJvbSBmb3J3YXJkaW5nIGRlY2lzaW9uIGluIGEgUFMgZHJhZnQ/IEV2ZW4g aW4gYW4gYXJjaGl0ZWN0dXJlIGRyYWZ0LCBpdCBpcyBub3QgcXVpdGUgcHJvcGVyIHRvIGV4Y2x1 ZGUgdGhpcyBleHBsaWNpdGx5LiBBY3R1YWxseSwgdGhlIG1ldGFkYXRhIGNhbiBjb250YWluIHNv bWUgcHJlZGVmaW5lZCBpbmZvcm1hdGlvbiB1c2VmdWwgZm9yIHBhdGggc2VsZWN0aW9uIHdpdGhv dXQgaW52b2x2aW5nIGEgY29tcGxleCBjbGFzc2lmaWVyIGluIGEgU0ZGLiBJIGFtIG5vdCBzYXlp bmcgaXQgbXVzdCBiZSBzbywgYnV0IGl0IGlzIHRvbyBydXNoIHRvIGV4Y2x1ZGUgdGhpcyBpbiBl aXRoZXIgUFMgb3IgYXJjaCBkcmFmdC4NCg0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE2LCAyMDE0IDM6NTgg QU0NClRvOiBUb20gVGF5bG9yOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBJbmNv bnNpc3RlbmN5IHJlZ2FyZGluZyByb2xlIG9mIFNGQyBtZXRhZGF0YSBpbiBmb3J3YXJkaW5nPw0K DQpUaGUgZXhwZWN0YXRpb24gYW5kIGludGVudGlvbiBpcyB0aGF0IHRoZSBwaWVjZSBvZiB0aGUg U0ZDIEVuY2Fwc3VsYXRpb24gdXNlZCBmb3IgdGhpcyBpcyB0aGUgaWRlbnRpZmljYXRpb24gb2Yg dGhlIHNlcnZpY2UgcGF0aC4gIEkgYmVsaWV2ZSB0aGVyZSBpcyBvdGhlciB0ZXh0IGluIHRoZSBh cmNoaXRlY3R1cmUgdGhhdCByZWluZm9yY2VzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBwb2ludCB0 aGF0IG1ldGFkYXRhIGlzIG5vdCB1c2VkIGZvciB0aGUgZm9yd2FyZGluZyBkZXNjcmlwdGlvbiBp biB0aGUgYWJzZW5jZSBvZiBhIGNsYXNzaWZpZXIuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA3LzE1 LzE0LCAzOjQ3IFBNLCBUb20gVGF5bG9yIHdyb3RlOg0KPiBTZWN0aW9uIDMuMyBvZiB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgaGFzIHRoaXMgdG8gc2F5IGFib3V0IFNGQyBtZXRhZGF0YToNCj4NCj4g PHF1b3RlPg0KPg0KPiAgICAgRGF0YSBwbGFuZSBtZXRhZGF0YSBwcm92aWRlcyB0aGUgYWJpbGl0 eSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbg0KPiAgICAgYmV0d2VlbiBsb2dpY2FsIGNsYXNzaWZp Y2F0aW9uIHBvaW50cyBhbmQgc2VydmljZSBmdW5jdGlvbnMgKGFuZCB2aWNlDQo+ICAgICB2ZXJz YSkgYW5kIGJldHdlZW4gc2VydmljZSBmdW5jdGlvbnMuICBBcyBzdWNoIG1ldGFkYXRhIGlzIG5v dCB1c2VkDQo+ICAgICBhcyBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIHRvIGRlbGl2ZXIgcGFja2V0 cyBhbG9uZyB0aGUgc2VydmljZQ0KPiAgICAgb3ZlcmxheS4NCj4NCj4gPC9xdW90ZT4NCj4NCj4g SG93ZXZlciwgdGhlIGRlZmluaXRpb24gb2YgdGhlIFNGRiBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRv Y3VtZW50IHNlZW1zIA0KPiB0byBjb250cmFkaWN0IHRoaXMsIHVubGVzcyBvbmUgYXNzdW1lcyB0 aGF0IHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBoYXMgDQo+IG1vcmUgaW5mb3JtYXRpb24gdGhhbiBq dXN0IFNGQyBtZXRhZGF0YS4NCj4NCj4gPHF1b3RlPg0KPg0KPiAgICAgU2VydmljZSBGdW5jdGlv biBGb3J3YXJkZXIgKFNGRik6ICBBIHNlcnZpY2UgZnVuY3Rpb24gZm9yd2FyZGVyIGlzDQo+ICAg ICAgICAgIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRyYWZmaWMgcmVjZWl2ZWQgZnJvbSB0 aGUgU0ZDIG5ldHdvcmsNCj4gICAgICAgICAgZm9yd2FyZGVyIHRvIG9uZSBvciBtb3JlIGNvbm5l Y3RlZCBzZXJ2aWNlIGZ1bmN0aW9ucyB2aWENCj4gICAgICAgICAgaW5mb3JtYXRpb24gY2Fycmll ZCBpbiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24uDQo+DQo+IDwvcXVvdGU+DQo+DQo+IElzIHRoaXMg anVzdCBhIG1hdHRlciBvZiBhZGp1c3RpbmcgdGhlIHRleHQsIG9yIGlzIHRoZXJlIGEgY29uZmxp Y3Qgb2YgDQo+IHZpZXdzIGJ1cmllZCBoZXJlPw0KPg0KPiBUb20gVGF5bG9yDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5n IGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Jul 16 01:53:46 2014 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363B91B2AF0 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:53:42 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wJF6eIKrFXJc for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 01:53:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CEF1B2AEF for <sfc@ietf.org>; Wed, 16 Jul 2014 01:53:39 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 806B3C058D; Wed, 16 Jul 2014 10:53:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5595E158063; Wed, 16 Jul 2014 10:53:37 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Wed, 16 Jul 2014 10:53:37 +0200 From: <mohamed.boucadair@orange.com> To: Xuxiaohu <xuxiaohu@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, "Ron Parker" <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u08Pl2nv4amkeW+iiVKhPLs5uf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcIABgr0A Date: Wed, 16 Jul 2014 08:53:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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.7.16.63020 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/x2mZsJNquZtoZaOO62Qd62j-XKM Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 08:53:42 -0000 Hi Xiaohu, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] >Envoy=E9=A0: mardi 15 juillet 2014 11:50 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor; sfc@ietf.o= rg; >Ron Parker >Objet=A0: RE: [sfc] SFC Terminology / Concepts > >Hi Med, > >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: Tuesday, July 15, 2014 5:35 PM >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >> Subject: RE: [sfc] SFC Terminology / Concepts >> >> Hi Xiaohu, >> >> Why a classifier will need specify a path a la ERO? Why it needs to have >the full > >In this way, the path selection process (i.e., selecting the appropriate >SFF for the next SF based on certain constraints) on the SFF is greatly >simplified. [Med] This does not answer to my question why the "classifier" has specific= ally to take care of this? How multiple classifiers present in a given SFC-= enabled domain behave in order to distribute traffic among available Servic= e Function Nodes? How a classifier can distribute traffic without any confl= ict with other LBs that may be present in the forwarding path? > >> knowledge of the involved SF instances? Wouldn't this require the >classifier to >> be fed with additional information to drive its selection process? Is >this > >The classifier could request the PCE to do the SFP computation (see >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is no >need for the classifier to be fed with additional information. [Med] Functionally, the classifier will need a path computation component. = Whether these two are co-located or separated is implementation-specific. M= y concern is to require that path computation component as a mandatory comp= onent for the architecture. I think this is not justified. > >> complexity justified for all deployments? > >As I have said, the architecture should allow the classifier to just impos= e >the SFC information on the selected packet as well. In this way, each SFF >needs to resolve the appropriate next SFF for the next SF to be executed. [Med] Yes, I understood that from you initial list. My question is how to p= ackage all this together without imposing complexity to deployments that do= not require it. > >Best regards, >Xiaohu > >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 juil= let >> >2014 10:49 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Tayl= or; >> >sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology / Concepts >> > >> >Hi Med, >> > >> >IMHO, the architecture should allow the classifier to specify >> > >> >1) a partial SFP (i.e., some SFFs along that partial SFP need to >> >locally determine the appropriate SFF for the next SF); >> >2) a complete SFP (i.e., the SFF for each SF in the SFC has been >> >determined by the centralized node); >> >3) an SFC (i.e., each SFF along the final SFP needs to locally >> >determine the appropriate SFF for the next SF). >> > >> >In fact, case 3) could be looked as an extreme of case 1). >> > >> >Best regards, >> >Xiaohu >> > >> >> -----Original Message----- >> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> >> mohamed.boucadair@orange.com >> >> Sent: Tuesday, July 15, 2014 3:22 PM >> >> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >> >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> >> >> Hi Joel, >> >> >> >> As mentioned in several messages, I'm personally for the use of the >> >> chain >> >itself is >> >> the main information to be conveyed in packets to drive forwarding >> >actions. >> >> >> >> I can understand that an identifier can be assigned to a path that is >> >known in >> >> advance, but if that path is not known I'm not sure how an identifier >> >> can >> >be >> >> assigned to it! >> >> >> >> Joel, the use of "path" is really inappropriate to refer to >> >> distributed >> >instance >> >> selection process for packets bound to a given SFC. >> >> >> >> Cheers, >> >> Med >> >> >> >> >-----Message d'origine----- >> >> >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpe= rn >> >> >Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylor; sfc@iet= f.org; >> >> >Ron Parker Objet=A0: Re: [sfc] SFC Terminology / Concepts >> >> > >> >> >The most likely realization of the architecture would be that the >> >> >SFP assignment is recorded in an identifier which travels with the >packet. >> >> > >> >> >Some folks seem to not want the architecture to mandate that. >> >> > >> >> >Yours, >> >> >Joel >> >> > >> >> > >> >> >On 7/14/14, 2:37 PM, Tom Taylor wrote: >> >> >> Your text scares me because it introduces some new concepts and >> >> >> assumptions. >> >> >> >> >> >> I'd rather go with Joel's formulation. Clarifying question on that= : >> >> >> am I right in seeing the implication that when control assigns an >> >> >> SFP, the assignment is recorded by an identifier wwhich travels >> >> >> with >> >the >> >> packet? >> >> >> >> >> >> Tom Taylor >> >> >> >> >> >> On 14/07/2014 2:22 PM, Ron Parker wrote: >> >> >>> There is one missing word in my text. Please replace my propose= d >> >text >> >> >>> with: >> >> >>> >> >> >>> "The Service Function Chain (SFC) provides a fully abstract view >> >> >>> of the service functions to be invoked and the order in which >> >> >>> they are to be invoked for some particular flow or set of flows, >> >> >>> without >> >concern of >> >> >>> actual service function instance selection. The Constrained-SFC >> >> >>> (C-SFC) further allows for policy constraints to be added to the >> >> >>> SFC affecting the instance selection of one or more of the >> >> >>> service >> >functions >> >> >>> in the SFC. Any SFC may have any number of C-SFC's associated >with >> >> >it." >> >> >>> >> >> >>> Thanks. >> >> >>> >> >> >>> Ron >> >> >> ... >> >> >> >> >> >> >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >> >> >>> Allan I >> >> >>> *Sent:* Monday, July 14, 2014 2:03 PM >> >> >>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >> >> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts >> >> >>> >> >> >>> I like that text, it strikes a good balance where an >> >> >>> implementation has the option of making scale and resiliency a >local >> matter.. >> >> >>> >> >> >>> D >> >> >>> >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >> >> >>> Guichard >> >> >>> (jguichar) >> >> >>> *Sent:* Monday, July 14, 2014 10:48 AM >> >> >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >> >> >>> *Subject:* [sfc] SFC Terminology / Concepts >> >> >>> >> >> >>> Dear WG: >> >> >>> >> >> >>> There has been much debate over the last few days with regards to >> >> >>> SFC concepts. To try and form some consensus around terminology >> >> >>> and concepts used to describe the architecture in the merged >> >> >>> architecture draft, Joel has kindly suggested the following: >> >> >>> >> >> >>> "The SFP provides a level of indirection between the fully >> >> >>> abstract notion of service path as a sequence of functions to be >> >> >>> delivered, and the fully specified notion of exactly what >> >> >>> instances of SFFs the packet will visit when it actually >> >> >>> traverses the network. By allowing the control components to >> >> >>> specify the use of this level of indirection, the deployment may >> >> >>> choose the degree of SFF instance selection authority that is >delegated to >> the network." >> >> >>> >> >> >>> I'd like to ask the WG as a whole, if this clarification is >> >> >>> something that we can get consensus on. If so, I'll ask Joel to >> >> >>> provide specific text, that reflects the above, for inclusion in >> >> >>> the merged architecture draft. >> >> >>> >> >> >>> Thank You, >> >> >>> >> >> >>> Jim >> >> >>> >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> sfc mailing list >> >> >>> sfc@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> sfc mailing list >> >> >> sfc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >> > >> >> >_______________________________________________ >> >> >sfc mailing list >> >> >sfc@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> >> sfc mailing list >> >> sfc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 16 03:15:34 2014 Return-Path: <xuxiaohu@huawei.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC21B2B10 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 03:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 QPX3vZ-s0lpO for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 03:15:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FDA1B2B06 for <sfc@ietf.org>; Wed, 16 Jul 2014 03:15:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC48606; Wed, 16 Jul 2014 10:15:28 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 11:15:00 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 18:14:53 +0800 From: Xuxiaohu <xuxiaohu@huawei.com> To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>, Ron Parker <Ron_Parker@affirmednetworks.com> Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcIABADUAgACaNiA= Date: Wed, 16 Jul 2014 10:14:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082937A9@NKGEML512-MBS.china.huawei.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="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/_YdOGjtLh9PC908tn0Z7LQ3_btY Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 10:15:32 -0000 Hi Med, > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, July 16, 2014 4:54 PM > To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > Subject: RE: [sfc] SFC Terminology / Concepts >=20 > Hi Xiaohu, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 juill= et > >2014 11:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylo= r; > >sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology / Concepts > > > >Hi Med, > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > >> [mailto:mohamed.boucadair@orange.com] > >> Sent: Tuesday, July 15, 2014 5:35 PM > >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > >> Subject: RE: [sfc] SFC Terminology / Concepts > >> > >> Hi Xiaohu, > >> > >> Why a classifier will need specify a path a la ERO? Why it needs to > >> have > >the full > > > >In this way, the path selection process (i.e., selecting the > >appropriate SFF for the next SF based on certain constraints) on the > >SFF is greatly simplified. >=20 > [Med] This does not answer to my question why the "classifier" has specif= ically > to take care of this? How multiple classifiers present in a given SFC-ena= bled > domain behave in order to distribute traffic among available Service Func= tion > Nodes? How a classifier can distribute traffic without any conflict with = other LBs > that may be present in the forwarding path? >=20 > > > >> knowledge of the involved SF instances? Wouldn't this require the > >classifier to > >> be fed with additional information to drive its selection process? Is > >this > > > >The classifier could request the PCE to do the SFP computation (see > >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is > >no need for the classifier to be fed with additional information. >=20 > [Med] Functionally, the classifier will need a path computation component= . > Whether these two are co-located or separated is implementation-specific.= My > concern is to require that path computation component as a mandatory > component for the architecture. I think this is not justified. If the SFP computation is performed by the PCE, the classifier just needs t= o accept the computation result returned by the PCE and then impose the SFP= info on the selected packets. In other words, the classifier doesn't need = that SFP computation component anymore. Furthermore, if the classifier is j= ust allowed to impose the SFC info on the selected packet, it doesn't need = the SFP computation component as well. > >> complexity justified for all deployments? > > > >As I have said, the architecture should allow the classifier to just > >impose the SFC information on the selected packet as well. In this way, > >each SFF needs to resolve the appropriate next SFF for the next SF to be > executed. >=20 > [Med] Yes, I understood that from you initial list. My question is how to= package > all this together without imposing complexity to deployments that do not > require it. Since architecture allows three options, operators could make their own cho= ices accordingly. Best regards,. Xiaohu > >Best regards, > >Xiaohu > > > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 ju= illet > >> >2014 10:49 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom > >> >Taylor; sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology = / > >> >Concepts > >> > > >> >Hi Med, > >> > > >> >IMHO, the architecture should allow the classifier to specify > >> > > >> >1) a partial SFP (i.e., some SFFs along that partial SFP need to > >> >locally determine the appropriate SFF for the next SF); > >> >2) a complete SFP (i.e., the SFF for each SF in the SFC has been > >> >determined by the centralized node); > >> >3) an SFC (i.e., each SFF along the final SFP needs to locally > >> >determine the appropriate SFF for the next SF). > >> > > >> >In fact, case 3) could be looked as an extreme of case 1). > >> > > >> >Best regards, > >> >Xiaohu > >> > > >> >> -----Original Message----- > >> >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >> >> mohamed.boucadair@orange.com > >> >> Sent: Tuesday, July 15, 2014 3:22 PM > >> >> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > >> >> Subject: Re: [sfc] SFC Terminology / Concepts > >> >> > >> >> Hi Joel, > >> >> > >> >> As mentioned in several messages, I'm personally for the use of > >> >> the chain > >> >itself is > >> >> the main information to be conveyed in packets to drive forwarding > >> >actions. > >> >> > >> >> I can understand that an identifier can be assigned to a path that > >> >> is > >> >known in > >> >> advance, but if that path is not known I'm not sure how an > >> >> identifier can > >> >be > >> >> assigned to it! > >> >> > >> >> Joel, the use of "path" is really inappropriate to refer to > >> >> distributed > >> >instance > >> >> selection process for packets bound to a given SFC. > >> >> > >> >> Cheers, > >> >> Med > >> >> > >> >> >-----Message d'origine----- > >> >> >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. > >> >> >Halpern Envoy=E9=A0: lundi 14 juillet 2014 21:52 =C0=A0: Tom Taylo= r; > >> >> >sfc@ietf.org; Ron Parker Objet=A0: Re: [sfc] SFC Terminology / > >> >> >Concepts > >> >> > > >> >> >The most likely realization of the architecture would be that the > >> >> >SFP assignment is recorded in an identifier which travels with > >> >> >the > >packet. > >> >> > > >> >> >Some folks seem to not want the architecture to mandate that. > >> >> > > >> >> >Yours, > >> >> >Joel > >> >> > > >> >> > > >> >> >On 7/14/14, 2:37 PM, Tom Taylor wrote: > >> >> >> Your text scares me because it introduces some new concepts and > >> >> >> assumptions. > >> >> >> > >> >> >> I'd rather go with Joel's formulation. Clarifying question on th= at: > >> >> >> am I right in seeing the implication that when control assigns > >> >> >> an SFP, the assignment is recorded by an identifier wwhich > >> >> >> travels with > >> >the > >> >> packet? > >> >> >> > >> >> >> Tom Taylor > >> >> >> > >> >> >> On 14/07/2014 2:22 PM, Ron Parker wrote: > >> >> >>> There is one missing word in my text. Please replace my propo= sed > >> >text > >> >> >>> with: > >> >> >>> > >> >> >>> "The Service Function Chain (SFC) provides a fully abstract > >> >> >>> view of the service functions to be invoked and the order in > >> >> >>> which they are to be invoked for some particular flow or set > >> >> >>> of flows, without > >> >concern of > >> >> >>> actual service function instance selection. The Constrained-S= FC > >> >> >>> (C-SFC) further allows for policy constraints to be added to > >> >> >>> the SFC affecting the instance selection of one or more of the > >> >> >>> service > >> >functions > >> >> >>> in the SFC. Any SFC may have any number of C-SFC's associated > >with > >> >> >it." > >> >> >>> > >> >> >>> Thanks. > >> >> >>> > >> >> >>> Ron > >> >> >> ... > >> >> >> > >> >> >> > >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David > >> >> >>> Allan I > >> >> >>> *Sent:* Monday, July 14, 2014 2:03 PM > >> >> >>> *To:* Jim Guichard (jguichar); sfc@ietf.org > >> >> >>> <mailto:sfc@ietf.org> > >> >> >>> *Subject:* Re: [sfc] SFC Terminology / Concepts > >> >> >>> > >> >> >>> I like that text, it strikes a good balance where an > >> >> >>> implementation has the option of making scale and resiliency a > >local > >> matter.. > >> >> >>> > >> >> >>> D > >> >> >>> > >> >> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim > >> >> >>> Guichard > >> >> >>> (jguichar) > >> >> >>> *Sent:* Monday, July 14, 2014 10:48 AM > >> >> >>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> > >> >> >>> *Subject:* [sfc] SFC Terminology / Concepts > >> >> >>> > >> >> >>> Dear WG: > >> >> >>> > >> >> >>> There has been much debate over the last few days with regards > >> >> >>> to SFC concepts. To try and form some consensus around > >> >> >>> terminology and concepts used to describe the architecture in > >> >> >>> the merged architecture draft, Joel has kindly suggested the > following: > >> >> >>> > >> >> >>> "The SFP provides a level of indirection between the fully > >> >> >>> abstract notion of service path as a sequence of functions to > >> >> >>> be delivered, and the fully specified notion of exactly what > >> >> >>> instances of SFFs the packet will visit when it actually > >> >> >>> traverses the network. By allowing the control components to > >> >> >>> specify the use of this level of indirection, the deployment > >> >> >>> may choose the degree of SFF instance selection authority that > >> >> >>> is > >delegated to > >> the network." > >> >> >>> > >> >> >>> I'd like to ask the WG as a whole, if this clarification is > >> >> >>> something that we can get consensus on. If so, I'll ask Joel > >> >> >>> to provide specific text, that reflects the above, for > >> >> >>> inclusion in the merged architecture draft. > >> >> >>> > >> >> >>> Thank You, > >> >> >>> > >> >> >>> Jim > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> sfc mailing list > >> >> >>> sfc@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/sfc > >> >> >>> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> sfc mailing list > >> >> >> sfc@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/sfc > >> >> >> > >> >> > > >> >> >_______________________________________________ > >> >> >sfc mailing list > >> >> >sfc@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/sfc > >> >> > >> >> _______________________________________________ > >> >> sfc mailing list > >> >> sfc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 16 05:18:58 2014 Return-Path: <ramk@Brocade.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB46A1B29E9; Tue, 15 Jul 2014 18:42:06 -0700 (PDT) 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 Za5HDiCqiGyj; Tue, 15 Jul 2014 18:42:05 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0291B29E5; Tue, 15 Jul 2014 18:42:05 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G1UKRq005530; Tue, 15 Jul 2014 18:42:04 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n4uj9gj60-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 18:42:03 -0700 From: ramki Krishnan <ramk@Brocade.com> To: "nfvrg@ieft.org" <nfvrg@ieft.org>, "sdn@irtf.org" <sdn@irtf.org>, "nmrg@irtf.org" <nmrg@irtf.org>, "'sfc@ietf.org'" <sfc@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, "forces@ietf.org" <forces@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "bmwg@ietf.org" <bmwg@ietf.org> Date: Tue, 15 Jul 2014 18:42:01 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76g== Message-ID: <C7634EB63EFD984A978DFB46EA5174F2C14FFB95FC@HQ1-EXCH01.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-15_07:2014-07-15,2014-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160014 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2-CM2bhJV0rDhk3XuYR7oQ5Tzds X-Mailman-Approved-At: Wed, 16 Jul 2014 05:18:55 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" <diego.r.lopez@telefonica.com>, "dilikris@in.ibm.com" <dilikris@in.ibm.com> Subject: [sfc] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 01:42:07 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Please find more= information on NFVRG including charter at - <a href=3D"http://trac.tools.i= etf.org/group/irtf/trac/wiki/nfvrg">http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg</a><o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p>= <p class=3DMsoNormal>Please find meeting location and agenda at - <a href= =3D"http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90">http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90</a><o:p></o:p></p><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<o:p></o= :p></p><p class=3DMsoNormal>Ramki on behalf of the co-chairs<o:p></o:p></p>= </div></body></html>= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_-- From nobody Wed Jul 16 05:36:27 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566B61B2849 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 05:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eDvJnwkNeQUX for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 05:36:24 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF71C1B2836 for <sfc@ietf.org>; Wed, 16 Jul 2014 05:36:24 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 1AF5A53E52; Wed, 16 Jul 2014 05:34:13 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 16 Jul 2014 05:34:13.072 -0700 x-echoworx-msg-id: 352b2775-d088-44d4-8405-4675687231c4 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 670; Wed, 16 Jul 2014 05:34:13 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id EFF8B53E01; Wed, 16 Jul 2014 05:34:12 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 05:36:24 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Hongyu Li (Julio)" <hongyu.li@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGcZviim+pzeokmGAZvO4foLopui2N0A///KZ5A= Date: Wed, 16 Jul 2014 12:36:22 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8BA23F@MBX021-W3-CA-2.exch021.domain.local> References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Pbo9GwSTbq2iz9CjjoWk7A5D6A0 Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 12:36:26 -0000 Hongyu, I agree regarding the optional use of metatadata for forwarding.. For a n= ew flow, next SFF selection by an SFF SFF MUST be based on the chain ID and= MAY be based on metadata and/or locally known policy. Next SFI selection= by an SFF MUST be based on the chain ID and service function index within = the chain and MAY be based on metadata and/or locally known policy. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Hongyu Li (Julio) Sent: Wednesday, July 16, 2014 4:45 AM To: Joel M. Halpern; Tom Taylor; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? I do have a different view. On what ground shall we exclude metadata from f= orwarding decision in a PS draft? Even in an architecture draft, it is not = quite proper to exclude this explicitly. Actually, the metadata can contain= some predefined information useful for path selection without involving a = complex classifier in a SFF. I am not saying it must be so, but it is too r= ush to exclude this in either PS or arch draft. Hongyu -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 16, 2014 3:58 AM To: Tom Taylor; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? The expectation and intention is that the piece of the SFC Encapsulation us= ed for this is the identification of the service path. I believe there is = other text in the architecture that reinforces the problem statement point = that metadata is not used for the forwarding description in the absence of = a classifier. Yours, Joel On 7/15/14, 3:47 PM, Tom Taylor wrote: > Section 3.3 of the problem statement has this to say about SFC metadata: > > <quote> > > Data plane metadata provides the ability to exchange information > between logical classification points and service functions (and vice > versa) and between service functions. As such metadata is not used > as forwarding information to deliver packets along the service > overlay. > > </quote> > > However, the definition of the SFF in the architecture document seems=20 > to contradict this, unless one assumes that the SFC encapsulation has=20 > more information than just SFC metadata. > > <quote> > > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the SFC network > forwarder to one or more connected service functions via > information carried in the SFC encapsulation. > > </quote> > > Is this just a matter of adjusting the text, or is there a conflict of=20 > views buried here? > > Tom Taylor > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 16 05:45:10 2014 Return-Path: <jmh@joelhalpern.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9BD1B2861 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 05:45:08 -0700 (PDT) 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 qG3u7Yqsj1RN for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 05:45:06 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0091B2860 for <sfc@ietf.org>; Wed, 16 Jul 2014 05:45:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id BA84CD55539; Wed, 16 Jul 2014 05:45:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 1F947D55585; Wed, 16 Jul 2014 05:45:05 -0700 (PDT) Message-ID: <53C673D0.5040500@joelhalpern.com> Date: Wed, 16 Jul 2014 08:45:04 -0400 From: "Joel M. Halpern" <jmh@joelhalpern.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Hongyu Li (Julio)" <hongyu.li@huawei.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8BA23F@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <CDF2F015F4429F458815ED2A6C2B6B0B1A8BA23F@MBX021-W3-CA-2.exch021.domain.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/C9wo7Pb_JUCE11dIcS7CNl4LZmY Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 12:45:08 -0000 I see a major interoperability problem with this suggested flexibility. First, there are two possible readings of this "may" relative to SFF capabilities. One view is that all SFF MUST be able to use metadata for such forwarding, although some cases may not need to use it. That is a major requirement on SFF implementation. Another view is that the ability to use metadata at SFF to influence forwarding is an optional capability. If so, the question is then how the orchestration and management will be able to set up the chain IDs and metadata usage. Given that some SFF may not be able to use metadata for the decision, and some may do so in ill-defined fashions, I do not see how the control component can know what to do. If the metadata based behavior is not actually needed, then allowing for it complicates the system for no benefit. Hence this looks like it would require that all SFF be able to support metadata based classification. I would also note that one of the reasons that the architecture allows for re-classification is that such a construction makes it clear where additional information (metadata, packet contents, etc.) Keeping the SFF function itself relatively simple seems a big win. Requiring the SFF to have multiple capabilities including, as some have suggested, stateful forwarding, metadata based forwarding, and remote synchronization, seems like it will create something that is very difficult to implement or deploy. Yours, Joel On 7/16/14, 8:36 AM, Ron Parker wrote: > Hongyu, > > I agree regarding the optional use of metatadata for forwarding.. > For a new flow, next SFF selection by an SFF SFF MUST be based on the > chain ID and MAY be based on metadata and/or locally known policy. > Next SFI selection by an SFF MUST be based on the chain ID and > service function index within the chain and MAY be based on metadata > and/or locally known policy. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Hongyu Li (Julio) Sent: Wednesday, July 16, 2014 4:45 AM > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org Subject: Re: [sfc] > Inconsistency regarding role of SFC metadata in forwarding? > > I do have a different view. On what ground shall we exclude metadata > from forwarding decision in a PS draft? Even in an architecture > draft, it is not quite proper to exclude this explicitly. Actually, > the metadata can contain some predefined information useful for path > selection without involving a complex classifier in a SFF. I am not > saying it must be so, but it is too rush to exclude this in either PS > or arch draft. > > Hongyu > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Joel M. Halpern Sent: Wednesday, July 16, 2014 3:58 AM To: > Tom Taylor; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding > role of SFC metadata in forwarding? > > The expectation and intention is that the piece of the SFC > Encapsulation used for this is the identification of the service > path. I believe there is other text in the architecture that > reinforces the problem statement point that metadata is not used for > the forwarding description in the absence of a classifier. > > Yours, Joel > > On 7/15/14, 3:47 PM, Tom Taylor wrote: >> Section 3.3 of the problem statement has this to say about SFC >> metadata: >> >> <quote> >> >> Data plane metadata provides the ability to exchange information >> between logical classification points and service functions (and >> vice versa) and between service functions. As such metadata is not >> used as forwarding information to deliver packets along the >> service overlay. >> >> </quote> >> >> However, the definition of the SFF in the architecture document >> seems to contradict this, unless one assumes that the SFC >> encapsulation has more information than just SFC metadata. >> >> <quote> >> >> Service Function Forwarder (SFF): A service function forwarder is >> responsible for delivering traffic received from the SFC network >> forwarder to one or more connected service functions via >> information carried in the SFC encapsulation. >> >> </quote> >> >> Is this just a matter of adjusting the text, or is there a conflict >> of views buried here? >> >> Tom Taylor >> >> _______________________________________________ sfc mailing list >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ sfc mailing list > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 16 06:03:47 2014 Return-Path: <Ron_Parker@affirmednetworks.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13B81B2A08 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 06:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 isZ5Ug6S712U for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 06:03:42 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EF21B2A4A for <sfc@ietf.org>; Wed, 16 Jul 2014 06:03:42 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 7D5B753E6C; Wed, 16 Jul 2014 06:03:33 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Wed, 16 Jul 2014 06:03:33.478 -0700 x-echoworx-msg-id: f7dbb45f-e5f4-403c-94f3-a378b371bab1 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 411; Wed, 16 Jul 2014 06:03:33 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 5F2DB53E6C; Wed, 16 Jul 2014 06:03:33 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 06:03:42 -0700 From: Ron Parker <Ron_Parker@affirmednetworks.com> To: "Joel M. Halpern" <jmh@joelhalpern.com>, "Hongyu Li (Julio)" <hongyu.li@huawei.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "sfc@ietf.org" <sfc@ietf.org> Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoPPFBQ5mBxFi0UW+qWxJkdEomZuipt7g Date: Wed, 16 Jul 2014 13:03:41 +0000 Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B1A8BA350@MBX021-W3-CA-2.exch021.domain.local> References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8BA23F@MBX021-W3-CA-2.exch021.domain.local> <53C673D0.5040500@joelhalpern.com> In-Reply-To: <53C673D0.5040500@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] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/llYqL6-gvy2wfbS_Tri8q1u2WdA Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 13:03:45 -0000 Joel, Yes, you are correct that if the MAY is not universally implemented in some= particular deployment, then it will not be feasible. But that doesn't m= ean it isn't a worthwhile aspect of the architecture. In 3gpp core netwo= rks for example, we may want to constrain the SFI selection based on the AP= N. Metadata is an ideal way to communicate the APN membership to all of t= he involved entities. In general, the solution should be as simple as the problem domain and no s= impler. Service Function Chaining already exists in multiple forms. Th= e premise of this WG is that those forms are inadequate. My read on that = the inadequacy is along the lines of reliability, scale, flexibility, and y= es, ease of deployment. I'm trying to keep in mind that the architecture= /solution fits the needs of the problem space first, and then is as simple = as possible, second. =20 I also think that a major assumption that you and I may differ on and which= may flavor our viewpoints is regarding orchestration. While the term is = somewhat ambiguous, I generally take it to mean strong centralized control.= You've mentioned in a number of messages that particular architectural c= hoices would have a negative ramification on orchestration. But when I = look at some of those same architectural choices, I see them, instead, as h= aving negative ramifications on a fully distributed approach. I may have= mischaracterized your viewpoint, and I am certainly not casting aspersions= on your viewpoint. I'm just trying identify the source of some of these = disagreements. Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, July 16, 2014 8:45 AM To: Ron Parker; Hongyu Li (Julio); Tom Taylor; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? I see a major interoperability problem with this suggested flexibility. First, there are two possible readings of this "may" relative to SFF capabi= lities. One view is that all SFF MUST be able to use metadata for such for= warding, although some cases may not need to use it. That is a major requi= rement on SFF implementation. Another view is that the ability to use metadata at SFF to influence forwar= ding is an optional capability. If so, the question is then how the orchestration and management will be ab= le to set up the chain IDs and metadata usage. Given that some SFF may not= be able to use metadata for the decision, and some may do so in ill-define= d fashions, I do not see how the control component can know what to do. If= the metadata based behavior is not actually needed, then allowing for it c= omplicates the system for no benefit. Hence this looks like it would require that all SFF be able to support meta= data based classification. I would also note that one of the reasons that the architecture allows for = re-classification is that such a construction makes it clear where addition= al information (metadata, packet contents, etc.) Keeping the SFF function itself relatively simple seems a big win.=20 Requiring the SFF to have multiple capabilities including, as some have sug= gested, stateful forwarding, metadata based forwarding, and remote synchron= ization, seems like it will create something that is very difficult to impl= ement or deploy. Yours, Joel On 7/16/14, 8:36 AM, Ron Parker wrote: > Hongyu, > > I agree regarding the optional use of metatadata for forwarding.. > For a new flow, next SFF selection by an SFF SFF MUST be based on the=20 > chain ID and MAY be based on metadata and/or locally known policy. > Next SFI selection by an SFF MUST be based on the chain ID and service=20 > function index within the chain and MAY be based on metadata and/or=20 > locally known policy. > > Ron > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Hongyu Li (Julio) Sent: Wednesday, July 16, 2014 4:45 AM > To: Joel M. Halpern; Tom Taylor; sfc@ietf.org Subject: Re: [sfc]=20 > Inconsistency regarding role of SFC metadata in forwarding? > > I do have a different view. On what ground shall we exclude metadata=20 > from forwarding decision in a PS draft? Even in an architecture draft,=20 > it is not quite proper to exclude this explicitly. Actually, the=20 > metadata can contain some predefined information useful for path=20 > selection without involving a complex classifier in a SFF. I am not=20 > saying it must be so, but it is too rush to exclude this in either PS=20 > or arch draft. > > Hongyu > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of Joel M. Halpern Sent: Wednesday, July 16, 2014 3:58 AM To: > Tom Taylor; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding=20 > role of SFC metadata in forwarding? > > The expectation and intention is that the piece of the SFC=20 > Encapsulation used for this is the identification of the service path. = =20 > I believe there is other text in the architecture that reinforces the=20 > problem statement point that metadata is not used for the forwarding=20 > description in the absence of a classifier. > > Yours, Joel > > On 7/15/14, 3:47 PM, Tom Taylor wrote: >> Section 3.3 of the problem statement has this to say about SFC >> metadata: >> >> <quote> >> >> Data plane metadata provides the ability to exchange information=20 >> between logical classification points and service functions (and vice=20 >> versa) and between service functions. As such metadata is not used=20 >> as forwarding information to deliver packets along the service=20 >> overlay. >> >> </quote> >> >> However, the definition of the SFF in the architecture document seems=20 >> to contradict this, unless one assumes that the SFC encapsulation has=20 >> more information than just SFC metadata. >> >> <quote> >> >> Service Function Forwarder (SFF): A service function forwarder is=20 >> responsible for delivering traffic received from the SFC network=20 >> forwarder to one or more connected service functions via information=20 >> carried in the SFC encapsulation. >> >> </quote> >> >> Is this just a matter of adjusting the text, or is there a conflict=20 >> of views buried here? >> >> Tom Taylor >> >> _______________________________________________ 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 > From nobody Wed Jul 16 10:23:17 2014 Return-Path: <tnadeau@lucidvision.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C311A0043 for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 10:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 0RX7ZESdcGcY for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 10:23:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C626A1A00AB for <sfc@ietf.org>; Wed, 16 Jul 2014 10:23:13 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id A1E472823FF9; Wed, 16 Jul 2014 13:23:12 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_38EF5E00-7ECB-4A1E-82FB-F2E2FDF61026"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" <tnadeau@lucidvision.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> Date: Wed, 16 Jul 2014 13:23:12 -0400 Message-Id: <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> References: <CFE98FD3.2E64E%jguichar@cisco.com> <E6C17D2345AC7A45B7D054D407AA205C392A2F10@eusaamb105.ericsson.se> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B771C@MBX021-W3-CA-2.exch021.domain.local> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B778F@MBX021-W3-CA-2.exch021.domain.local> <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <B6D287BF58D35D4B882E012AD3E1756172E676B7@ONWVEXCHMB04.ciena.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> To: sfc-chairs@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RaBnflK1E6O1IW6lokZKAOaLkHs Cc: "sfc@ietf.org" <sfc@ietf.org>, "He, Peng" <phe@ciena.com>, Ron Parker <Ron_Parker@affirmednetworks.com>, Tom Taylor <tom.taylor.stds@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 17:23:16 -0000 --Apple-Mail=_38EF5E00-7ECB-4A1E-82FB-F2E2FDF61026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have gotten a bit lost in the SFF/SFC discussion, which seems = to have gotten needlessly complicated and convoluted IMHO.=20 Is it possible for the chairs to add this to the list of things = to discuss at the WG meeting or do we want to resolve this on the list = ahead of the meeting? --Tom On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu <xuxiaohu@huawei.com> = wrote: > Hi Peng, >=20 >> -----Original Message----- >> From: He, Peng [mailto:phe@ciena.com] >> Sent: Tuesday, July 15, 2014 9:09 PM >> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom = Taylor; >> sfc@ietf.org; Ron Parker >> Subject: RE: [sfc] SFC Terminology / Concepts >>=20 >> Try to understand the three scenarios you listed: you mean the = classifier can >> specify a (partial or complete) SFP which is a list of SFFs, then = each SFF will >> (locally) select one of the SF instances under itself for this SF. = For partial SFP case, >=20 > In either case, the SFF should be capable of selecting the appropriate = instance of a given SF attached to itself. it's an internal = load-balancing issue. >=20 >> each SFF will identify the SFI under itself and specify (like a = classifier) next SFF(s). >> The classifier (and SFF?) could obtain this (SFF) 'path' information = from either >> centralized point (e.g., PCE, controller), or, via a distributed = control plane? For >> partial SFP, will there be a re-classification to decide next SFF(s) = or not? >=20 > If you want the SFF to locally determine the appropriate SFF for the = next SF, the SFF should have the capability of resolving the SFF for the = next SF based on certain constraints. Of course, it needs to know some = information about the SFs in advance, e.g., the information about which = SFFs a given SF is attached. >=20 > Best regards, > Xiaohu >=20 >> Regards, >> Peng >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >> Sent: Tuesday, July 15, 2014 4:49 AM >> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >> sfc@ietf.org; Ron Parker >> Subject: Re: [sfc] SFC Terminology / Concepts >>=20 >> Hi Med, >>=20 >> IMHO, the architecture should allow the classifier to specify >>=20 >> 1) a partial SFP (i.e., some SFFs along that partial SFP need to = locally determine >> the appropriate SFF for the next SF); >> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been = determined by >> the centralized node); >> 3) an SFC (i.e., each SFF along the final SFP needs to locally = determine the >> appropriate SFF for the next SF). >>=20 >> In fact, case 3) could be looked as an extreme of case 1). >>=20 >> Best regards, >> Xiaohu >>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Tuesday, July 15, 2014 3:22 PM >>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Joel, >>>=20 >>> As mentioned in several messages, I'm personally for the use of the >>> chain itself is the main information to be conveyed in packets to = drive >> forwarding actions. >>>=20 >>> I can understand that an identifier can be assigned to a path that = is >>> known in advance, but if that path is not known I'm not sure how an >>> identifier can be assigned to it! >>>=20 >>> Joel, the use of "path" is really inappropriate to refer to >>> distributed instance selection process for packets bound to a given = SFC. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. = Halpern >>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; = sfc@ietf.org; >>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> The most likely realization of the architecture would be that the = SFP >>>> assignment is recorded in an identifier which travels with the = packet. >>>>=20 >>>> Some folks seem to not want the architecture to mandate that. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>=20 >>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>> Your text scares me because it introduces some new concepts and >>>>> assumptions. >>>>>=20 >>>>> I'd rather go with Joel's formulation. Clarifying question on = that: >>>>> am I right in seeing the implication that when control assigns an >>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>> with the >>> packet? >>>>>=20 >>>>> Tom Taylor >>>>>=20 >>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>> There is one missing word in my text. Please replace my = proposed text >>>>>> with: >>>>>>=20 >>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>> of the service functions to be invoked and the order in which = they >>>>>> are to be invoked for some particular flow or set of flows, = without >> concern of >>>>>> actual service function instance selection. The Constrained-SFC >>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>> SFC affecting the instance selection of one or more of the = service >> functions >>>>>> in the SFC. Any SFC may have any number of C-SFC's associated = with >>>> it." >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> Ron >>>>> ... >>>>>=20 >>>>>=20 >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>> Allan I >>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org <mailto:sfc@ietf.org> >>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>=20 >>>>>> I like that text, it strikes a good balance where an >>>>>> implementation has the option of making scale and resiliency a = local >> matter.. >>>>>>=20 >>>>>> D >>>>>>=20 >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>> *To:* sfc@ietf.org <mailto:sfc@ietf.org> >>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>=20 >>>>>> Dear WG: >>>>>>=20 >>>>>> There has been much debate over the last few days with regards to >>>>>> SFC concepts. To try and form some consensus around terminology >>>>>> and concepts used to describe the architecture in the merged >>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>=20 >>>>>> "The SFP provides a level of indirection between the fully >>>>>> abstract notion of service path as a sequence of functions to be >>>>>> delivered, and the fully specified notion of exactly what >>>>>> instances of SFFs the packet will visit when it actually = traverses >>>>>> the network. By allowing the control components to specify the = use >>>>>> of this level of indirection, the deployment may choose the = degree >>>>>> of SFF instance selection authority that is delegated to the = network." >>>>>>=20 >>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>> provide specific text, that reflects the above, for inclusion in >>>>>> the merged architecture draft. >>>>>>=20 >>>>>> Thank You, >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 --Apple-Mail=_38EF5E00-7ECB-4A1E-82FB-F2E2FDF61026 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 iQIcBAEBCgAGBQJTxrUAAAoJEPcO+I7eiUJZcjUP/1WJ46TCnFtTwnrF0Y84hPca XR1sS4U1y1K+DZXcn7/kJsVSfUleobvqsEdKCzaimE0Xb7DSQdvEZ93sENfc2HgR AjMdwOoyixq/ztzp75rxT5xgcSmBTbgPriNSDyt4HOGF6GrQkxBHVB3g0QaXsUOE EOpFDUF12egiy+le55yXpKgZRyBMMIZpvI4hz0G9NsmD3OSQ4VKJtm5TpyBccv9H sBScPpXrz1EGLY8XwIm6E6wDaj5g0U3JEq2+LntEURNTrQP2LUspiJsxAcWnR1MX euMSV2dYPLil6vAD1O1gC3OjZQhM05MCLJQep0VZ/DchoWEhMr5a6D2b8qv2AJ68 CAFeOjt9Olhf6g4LU5MhUc/7JdhP8P0gvkk5cG8H4p1WKWatLOJlOUn/jOOBmD4O coQpdoUaBajBiqmpfHIVySJ2wGztg7MDcCrA7pShIQ2KBcxy0SrBXIufbOoS6Ucg nxjn+pncCj+HrHEg8RFdKzHdpxS/YjJfNw9rZWOlUPhB8UD8mtnBIoW8dkl7iTCm GhNmu2JFqfGlv6KbJCplHTyItw84rUdSLyuFXwJbOUCQK7XqgP1Ir91s7pB56Vk1 2zKnSg1X9R1ebGQCW4bF+OR/4QzcU4awxxTL1wMkzm27M+3ilV7Za5LPD56wS2k4 Sr/afIsJ4VGNT86A6mib =MSI3 -----END PGP SIGNATURE----- --Apple-Mail=_38EF5E00-7ECB-4A1E-82FB-F2E2FDF61026-- From nobody Wed Jul 16 11:05:11 2014 Return-Path: <mikebianc@aol.com> X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0691A017D for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 11:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 uOxiUbatgsfZ for <sfc@ietfa.amsl.com>; Wed, 16 Jul 2014 11:05:08 -0700 (PDT) Received: from omr-d10.mx.aol.com (omr-d10.mx.aol.com [205.188.108.134]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63101A017A for <sfc@ietf.org>; Wed, 16 Jul 2014 11:05:08 -0700 (PDT) Received: from mtaout-aae01.mx.aol.com (mtaout-aae01.mx.aol.com [172.27.1.97]) by omr-d10.mx.aol.com (Outbound Mail Relay) with ESMTP id BA1D07003F607; Wed, 16 Jul 2014 14:05:07 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 200D2380000A7; Wed, 16 Jul 2014 14:05:06 -0400 (EDT) Date: Wed, 16 Jul 2014 14:05:05 -0400 From: "mikebianc@aol.com" <mikebianc@aol.com> To: jmh.direct@joelhalpern.com, sfc@ietf.org Message-ID: <452978986.12484.1405533905898.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <53C3EB85.2040405@joelhalpern.com> References: <53BCAB74.4060801@joelhalpern.com> <CFE563EB.2D260%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ACCB@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE5690F.2D2CE%jguichar@cisco.com> <787AE7BB302AE849A7480A190F8B93300316CC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D4AD47@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE576DD.2D3DA%jguichar@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4ADAE@MISOUT7MSGUSRCF.ITServices.sbc.com> <CFE57DBD.2D45C%jguichar@cisco.com> <501609620.3119.1405095525432.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <CFE587DA.2D547%jguichar@cisco.com> <1999503137.3366.1405104386850.JavaMail.tomcat@mgs-aaa01.mail.aol.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08292AB9@NKGEML512-MBS.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8B6D7C@MBX021-W3-CA-2.exch021.domain.local> <1D70D757A2C9D54D83B4CBD7625FA80E01D4B75B@MISOUT7MSGUSRCF.ITServices.sbc.com> <2691CE0099834E4A9C5044EEC662BB9D453BF5FB@dfweml701-chm.china.huawei.com> <53C3EB85.2040405@joelhalpern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12483_577178355.1405533905898" X-Originating-IP: 10.181.180.134, 10.181.180.134 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405533907; bh=4onXLM6MsB3H5JNWKZ/eneNhsFIcKmsOa7ZrBwpLEHw=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=h9YpJ9lEaOFws9LpsQNZcdS6jkmC/pyvkDxxpnxX1R/wlfqHbN07BsHzCygcNaXAq Rn3H02QsLE3+KXCSFpCY/+s/nWlfEqPfPLJAMcmwnBYF/XVSIah/+BNDP4gNNvurwG XFLl+pbluQBkpC5MLRoVve7EUrlALPuAwDL+oVX0= x-aol-sid: 3039ac1b016153c6bed24cf9 X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IwlbOqQlW984YIH0uw1ql8w_fDU Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining <sfc.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sfc/> List-Post: <mailto:sfc@ietf.org> List-Help: <mailto:sfc-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Jul 2014 18:05:10 -0000 ------=_Part_12483_577178355.1405533905898 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the definition in the merged draft in section 1.3 works and fits wi= th *most* of the document. =C2=A0It does not dictate as required, but does = allow for the specific SFIs to be predetermined on classification. =C2=A0It= also allows for the SFIs to be determined in a more dynamic fashion, "via = information contained in the SFC encapsulation".=C2=A0 The problem I see is that in section 2.3, the text seems to restrict this t= o the former option. =C2=A0If that text were reworded to be more like secti= on 4.8, then (at least to me) it would be more clear and less restrictive. From: jmh.direct@joelhalpern.com<jmh.direct@joelhalpern.com> To: Lucy yong<lucy.yong@huawei.com>,NAPIERALA, MARIA H<mn1921@att.com>,Ron = Parker<Ron_Parker@affirmednetworks.com>,Xuxiaohu<xuxiaohu@huawei.com>,mikeb= ianc@aol.com<mikebianc@aol.com>,jguichar@cisco.com<jguichar@cisco.com>,moha= med.boucadair@orange.com<mohamed.boucadair@orange.com>,jmh@joelhalpern.com<= jmh@joelhalpern.com>,sfc@ietf.org<sfc@ietf.org> Sent: Monday, July 14, 2014 Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load B= alancers Can we first figure out what we mean by a service path? Once we have that, I believe we can work out what we want the=20 architecture to require of solutions in terms of carrying information in=20 the packet. But since folks have been reading the existing definitions=20 and coming to different meanings, and have been noting correctly=20 contradictions in the words we chose for the existing definition, I=20 would really appreciated it if folks would comment on the definition of=20 service function path that I sent to the list. Yours, Joel ------=_Part_12483_577178355.1405533905898 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <font face=3D"'courier new', monospace" size=3D"2"><div><font face=3D"'cour= ier new', monospace" size=3D"2"><div>I think the definition in the merged d= raft in section 1.3 works and fits with *most* of the document.  It do= es not dictate as required, but does allow for the specific SFIs to be pred= etermined on classification.  It also allows for the SFIs to be determ= ined in a more dynamic fashion, "<span style=3D"color: rgb(0, 0, 0); font-s= ize: 1em; font-family: sans-serif, arial;">via information contained in the= SFC encapsulation</span>". </div><div><br></div><div>The problem I se= e is that in section 2.3, the text seems to restrict this to the former opt= ion.  If that text were reworded to be more like section 4.8, then (at= least to me) it would be more clear and less restrictive.</div></font><fon= t face=3D"'courier new', monospace" size=3D"2"></font><br><br></div></font>= <div class=3D""></div><br><br><br><hr style=3D"border:0;height:1px;color:#9= 99;background-color:#999;width:100%;margin:0 0 9px 0;padding:0;"><b>From: <= /b>jmh.direct@joelhalpern.com<jmh.direct@joelhalpern.com><br><b>To: <= /b>Lucy yong<lucy.yong@huawei.com>,NAPIERALA, MARIA H<mn1921@att.c= om>,Ron Parker<Ron_Parker@affirmednetworks.com>,Xuxiaohu<xuxiao= hu@huawei.com>,mikebianc@aol.com<mikebianc@aol.com>,jguichar@cisco= .com<jguichar@cisco.com>,mohamed.boucadair@orange.com<mohamed.bouc= adair@orange.com>,jmh@joelhalpern.com<jmh@joelhalpern.com>,sfc@iet= f.org<sfc@ietf.org><br><b>Sent: </b>Monday, July 14, 2014<br><b>Subje= ct: </b>Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Ba= lancers<br><br><title>Can we first figure out what we mean by a ser= vice path?
Once we have that, I believe we can work out what we want the=
architecture to require of solutions in terms of carrying information = in
the packet. But since folks have been reading the existing definiti= ons
and coming to different meanings, and have been noting correctly contradictions in the words we chose for the existing definition, I
w= ould really appreciated it if folks would comment on the definition of
= service function path that I sent to the list.

Yours,
Joel
------=_Part_12483_577178355.1405533905898-- From nobody Wed Jul 16 12:20: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 658091A01CB for ; Wed, 16 Jul 2014 11:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 SDOzPrpzFoE6 for ; Wed, 16 Jul 2014 11:59:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E280E1A0190 for ; Wed, 16 Jul 2014 11:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9685; q=dns/txt; s=iport; t=1405537146; x=1406746746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SQ9oJ06LnoHLc0sC6uHAVp6ogjRtCXmZP0wWkJF2DZk=; b=fUmptEDBdXdAJgmxi/2xE+ibRXtky0DqjZ7obEyInWOeED3RYP54Jaqq 4lsP9AGkHi+tCu2fvxeQAzA3i0W01wPu/5OZf48hrGEiAdtXMdR5LbHeN OvlqiTGUgUYJHBhvV8V/fJ3AubPKHNsfAINAQAILRaxNRxtaUSmeL4YId U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAArLxlOtJV2Q/2dsb2JhbABPCoMOUlcEwygKh0IBgQkWdoQDAQEBAwEBAQELVwkEBwwEAgEIEQEDAQEBJwcnCxQDBggCBAENBYg6CA3KVBMEjm8pLgUHBoQ9AQSKKoxYhBuULINEbIFF X-IronPort-AV: E=Sophos;i="5.01,673,1400025600"; d="scan'208";a="340586298" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2014 18:59:05 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6GIx4S1006501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 18:59:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 13:59:04 -0500 From: "Ken Gray (kegray)" To: "Thomas D. Nadeau" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAWFqAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQA///XuAA= Date: Wed, 16 Jul 2014 18:59:04 +0000 Message-ID: References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> In-Reply-To: <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.217] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <40B3AB731CE6674A8C54866D40688B5F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/muRH5p5XWLbv4FTXehnSAQWCn3k Cc: "sfc@ietf.org" , "He, Peng" , Ron Parker , Tom Taylor , "Joel M. Halpern" , "mohamed.boucadair@orange.com" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 16 Jul 2014 18:59:08 -0000 Joel, et. all, I think that some of the questions in architecture (SFP/SFC chasing it's tail) come as people look forward to the encapsulation/header document. That's probably unavoidable. When you read the NSH document, the SFP verbiage says that all participants MUST forward on the SP/SPI, but the document doesn't say how the SPI is derived/calculated (the vision here could be made clearer) or what it's relationship is to the transport path (I think you can't mix and match but can accommodate both within the header), should you opt for the transport header forwarding. It's obvious that some deployments prefer to use the transport header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which does play into the SPI or "other mechanisms" that populate a service table in the SFF). Perhaps the authors of NSH can suggest verbiage that makes the relationship between transport-based forwarding and service-based forwarding (SPI) clearer? This should eliminate/minimize the calls for redefinition/recasting our terminology and allow us to move on. On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: > > I have gotten a bit lost in the SFF/SFC discussion, which seems to have >gotten needlessly complicated and convoluted IMHO. > > Is it possible for the chairs to add this to the list of things to >discuss at the WG meeting or do we want to resolve this on the list ahead >of the meeting? > > --Tom > > >On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >wrote: > >> Hi Peng, >>=20 >>> -----Original Message----- >>> From: He, Peng [mailto:phe@ciena.com] >>> Sent: Tuesday, July 15, 2014 9:09 PM >>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: RE: [sfc] SFC Terminology / Concepts >>>=20 >>> Try to understand the three scenarios you listed: you mean the >>>classifier can >>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>SFF will >>> (locally) select one of the SF instances under itself for this SF. For >>>partial SFP case, >>=20 >> In either case, the SFF should be capable of selecting the appropriate >>instance of a given SF attached to itself. it's an internal >>load-balancing issue. >>=20 >>> each SFF will identify the SFI under itself and specify (like a >>>classifier) next SFF(s). >>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>from either >>> centralized point (e.g., PCE, controller), or, via a distributed >>>control plane? For >>> partial SFP, will there be a re-classification to decide next SFF(s) >>>or not? >>=20 >> If you want the SFF to locally determine the appropriate SFF for the >>next SF, the SFF should have the capability of resolving the SFF for the >>next SF based on certain constraints. Of course, it needs to know some >>information about the SFs in advance, e.g., the information about which >>SFFs a given SF is attached. >>=20 >> Best regards, >> Xiaohu >>=20 >>> Regards, >>> Peng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: Tuesday, July 15, 2014 4:49 AM >>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Med, >>>=20 >>> IMHO, the architecture should allow the classifier to specify >>>=20 >>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>locally determine >>> the appropriate SFF for the next SF); >>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>determined by >>> the centralized node); >>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>determine the >>> appropriate SFF for the next SF). >>>=20 >>> In fact, case 3) could be looked as an extreme of case 1). >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Hi Joel, >>>>=20 >>>> As mentioned in several messages, I'm personally for the use of the >>>> chain itself is the main information to be conveyed in packets to >>>>drive >>> forwarding actions. >>>>=20 >>>> I can understand that an identifier can be assigned to a path that is >>>> known in advance, but if that path is not known I'm not sure how an >>>> identifier can be assigned to it! >>>>=20 >>>> Joel, the use of "path" is really inappropriate to refer to >>>> distributed instance selection process for packets bound to a given >>>>SFC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org= ; >>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>=20 >>>>> The most likely realization of the architecture would be that the SFP >>>>> assignment is recorded in an identifier which travels with the >>>>>packet. >>>>>=20 >>>>> Some folks seem to not want the architecture to mandate that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>=20 >>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>> Your text scares me because it introduces some new concepts and >>>>>> assumptions. >>>>>>=20 >>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>> am I right in seeing the implication that when control assigns an >>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>> with the >>>> packet? >>>>>>=20 >>>>>> Tom Taylor >>>>>>=20 >>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>text >>>>>>> with: >>>>>>>=20 >>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>> of the service functions to be invoked and the order in which they >>>>>>> are to be invoked for some particular flow or set of flows, without >>> concern of >>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>> SFC affecting the instance selection of one or more of the service >>> functions >>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>with >>>>> it." >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> Ron >>>>>> ... >>>>>>=20 >>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>> Allan I >>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> I like that text, it strikes a good balance where an >>>>>>> implementation has the option of making scale and resiliency a >>>>>>>local >>> matter.. >>>>>>>=20 >>>>>>> D >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Dear WG: >>>>>>>=20 >>>>>>> There has been much debate over the last few days with regards to >>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>> and concepts used to describe the architecture in the merged >>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>=20 >>>>>>> "The SFP provides a level of indirection between the fully >>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>> delivered, and the fully specified notion of exactly what >>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>> the network. By allowing the control components to specify the use >>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>network." >>>>>>>=20 >>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>> the merged architecture draft. >>>>>>>=20 >>>>>>> Thank You, >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 Wed Jul 16 14:37: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 9D0651A00AF for ; Wed, 16 Jul 2014 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 1PQKblWgMc9j for ; Wed, 16 Jul 2014 14:37:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F5B1A0085 for ; Wed, 16 Jul 2014 14:37:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC97095; Wed, 16 Jul 2014 21:36:59 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 22:36:58 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 14:36:55 -0700 From: Henry Fourie To: "Ken Gray (kegray)" , "Thomas D. Nadeau" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAAayQD//7RAcA== Date: Wed, 16 Jul 2014 21:36:55 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AA232C6@SJCEML702-CHM.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.75] 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/CTluglMAUnPC1EO--fW5B5m2p-U Cc: "sfc@ietf.org" , "He, Peng" , Ron Parker , Tom Taylor , "Joel M. Halpern" , "mohamed.boucadair@orange.com" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 16 Jul 2014 21:37:05 -0000 Ken, The Service Chain Header draft https://datatracker.ietf.org/doc/draft-zh= ang-sfc-sch/ conveys the following intent: From section 4.2 Mandatory Fields: Path Identifier: Identifies a fully instantiated service function path. It represents a sequence of network locators, one for each service function that is to be invoked. Participating SFC entities MUST use this identifier when selecting the next hop for the packet or frame. >From section 4.4 Header Associated Operations: 3. Service Path Selection. The Service Network Forwarder (SNF) uses the Service Chain Identification information in the SCH to steer the traffic flow along the SFC path. 4. Service Function Instance Selection. The Service Function Forwarder (SFF) uses the Service Chain Identification information in the SCH to locate the service instance and forward the traffic flow to the service instance. The mapping of the Service Chain Identification to a service instance can be established through the management/control plane, which is out of scope of this document. >From section 4.2 Mandatory Fields: Path Identifier: Identifies a fully instantiated service function path. It represents a sequence of network locators, one for each service function that is to be invoked. Participating SFC entities MUST use this identifier when selecting the next hop for the packet or frame. >From section 4.4 Header Associated Operations: 3. Service Path Selection. The Service Network Forwarder (SNF) uses the Service Chain Identification information in the SCH to steer the traffic flow along the SFC path. 4. Service Function Instance Selection. The Service Function Forwarder (SFF) uses the Service Chain Identification information in the SCH to locate the service instance and forward the traffic flow to the service instance. The mapping of the Service Chain Identification to a service instance can be established through the management/control plane, which is out of scope of this document. - Louis -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau; sfc-chairs@ietf.org Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; mohame= d.boucadair@orange.com Subject: Re: [sfc] SFC Terminology / Concepts Joel, et. all, I think that some of the questions in architecture (SFP/SFC chasing it's tail) come as people look forward to the encapsulation/header document. That's probably unavoidable. When you read the NSH document, the SFP verbiage says that all participants MUST forward on the SP/SPI, but the document doesn't say how the SPI is derived/calculated (the vision here could be made clearer) or what it's relationship is to the transport path (I think you can't mix and match but can accommodate both within the header), should you opt for the transport header forwarding. It's obvious that some deployments prefer to use the transport header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which does play into the SPI or "other mechanisms" that populate a service table in the SFF). Perhaps the authors of NSH can suggest verbiage that makes the relationship between transport-based forwarding and service-based forwarding (SPI) clearer? This should eliminate/minimize the calls for redefinition/recasting our terminology and allow us to move on. On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: > > I have gotten a bit lost in the SFF/SFC discussion, which seems to have >gotten needlessly complicated and convoluted IMHO. > > Is it possible for the chairs to add this to the list of things to >discuss at the WG meeting or do we want to resolve this on the list ahead >of the meeting? > > --Tom > > >On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >wrote: > >> Hi Peng, >>=20 >>> -----Original Message----- >>> From: He, Peng [mailto:phe@ciena.com] >>> Sent: Tuesday, July 15, 2014 9:09 PM >>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: RE: [sfc] SFC Terminology / Concepts >>>=20 >>> Try to understand the three scenarios you listed: you mean the >>>classifier can >>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>SFF will >>> (locally) select one of the SF instances under itself for this SF. For >>>partial SFP case, >>=20 >> In either case, the SFF should be capable of selecting the appropriate >>instance of a given SF attached to itself. it's an internal >>load-balancing issue. >>=20 >>> each SFF will identify the SFI under itself and specify (like a >>>classifier) next SFF(s). >>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>from either >>> centralized point (e.g., PCE, controller), or, via a distributed >>>control plane? For >>> partial SFP, will there be a re-classification to decide next SFF(s) >>>or not? >>=20 >> If you want the SFF to locally determine the appropriate SFF for the >>next SF, the SFF should have the capability of resolving the SFF for the >>next SF based on certain constraints. Of course, it needs to know some >>information about the SFs in advance, e.g., the information about which >>SFFs a given SF is attached. >>=20 >> Best regards, >> Xiaohu >>=20 >>> Regards, >>> Peng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: Tuesday, July 15, 2014 4:49 AM >>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Med, >>>=20 >>> IMHO, the architecture should allow the classifier to specify >>>=20 >>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>locally determine >>> the appropriate SFF for the next SF); >>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>determined by >>> the centralized node); >>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>determine the >>> appropriate SFF for the next SF). >>>=20 >>> In fact, case 3) could be looked as an extreme of case 1). >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Hi Joel, >>>>=20 >>>> As mentioned in several messages, I'm personally for the use of the >>>> chain itself is the main information to be conveyed in packets to >>>>drive >>> forwarding actions. >>>>=20 >>>> I can understand that an identifier can be assigned to a path that is >>>> known in advance, but if that path is not known I'm not sure how an >>>> identifier can be assigned to it! >>>>=20 >>>> Joel, the use of "path" is really inappropriate to refer to >>>> distributed instance selection process for packets bound to a given >>>>SFC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org= ; >>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>=20 >>>>> The most likely realization of the architecture would be that the SFP >>>>> assignment is recorded in an identifier which travels with the >>>>>packet. >>>>>=20 >>>>> Some folks seem to not want the architecture to mandate that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>=20 >>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>> Your text scares me because it introduces some new concepts and >>>>>> assumptions. >>>>>>=20 >>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>> am I right in seeing the implication that when control assigns an >>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>> with the >>>> packet? >>>>>>=20 >>>>>> Tom Taylor >>>>>>=20 >>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>text >>>>>>> with: >>>>>>>=20 >>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>> of the service functions to be invoked and the order in which they >>>>>>> are to be invoked for some particular flow or set of flows, without >>> concern of >>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>> SFC affecting the instance selection of one or more of the service >>> functions >>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>with >>>>> it." >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> Ron >>>>>> ... >>>>>>=20 >>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>> Allan I >>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> I like that text, it strikes a good balance where an >>>>>>> implementation has the option of making scale and resiliency a >>>>>>>local >>> matter.. >>>>>>>=20 >>>>>>> D >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Dear WG: >>>>>>>=20 >>>>>>> There has been much debate over the last few days with regards to >>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>> and concepts used to describe the architecture in the merged >>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>=20 >>>>>>> "The SFP provides a level of indirection between the fully >>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>> delivered, and the fully specified notion of exactly what >>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>> the network. By allowing the control components to specify the use >>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>network." >>>>>>>=20 >>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>> the merged architecture draft. >>>>>>>=20 >>>>>>> Thank You, >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 From nobody Wed Jul 16 14:39: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 443AA1A0317 for ; Wed, 16 Jul 2014 14:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 0JGXadErg5GA for ; Wed, 16 Jul 2014 14:39:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79A81A008C for ; Wed, 16 Jul 2014 14:39:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKC97271; Wed, 16 Jul 2014 21:39:51 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 22:39:50 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 14:39:46 -0700 From: Henry Fourie To: "Ken Gray (kegray)" , "Thomas D. Nadeau" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAAayQD//7bEkA== Date: Wed, 16 Jul 2014 21:39:45 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.75] 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/GI-krnNCQuzQcfOyAim_zDpqFBE Cc: "sfc@ietf.org" , "He, Peng" , Ron Parker , Tom Taylor , "Joel M. Halpern" , "mohamed.boucadair@orange.com" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 16 Jul 2014 21:39:56 -0000 Ken, The Service chain Header draft https://datatracker.ietf.org/doc/draft-zha= ng-sfc-sch/ should answer some of your questions. In particular: In section 4.2 Mandatory Fields: Path Identifier: Identifies a fully instantiated service function path. It represents a sequence of network locators, one for each service function that is to be invoked. Participating SFC entities MUST use this identifier when selecting the next hop for the packet or frame. In section 4.4 Header Associated Operations: 3. Service Path Selection. The Service Network Forwarder (SNF) uses the Service Chain Identification information in the SCH to steer the traffic flow along the SFC path. 4. Service Function Instance Selection. The Service Function Forwarder (SFF) uses the Service Chain Identification information in the SCH to locate the service instance and forward the traffic flow to the service instance. The mapping of the Service Chain Identification to a service instance can be established through the management/control plane, which is out of scope of this document. - Louis -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau; sfc-chairs@ietf.org Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; mohame= d.boucadair@orange.com Subject: Re: [sfc] SFC Terminology / Concepts Joel, et. all, I think that some of the questions in architecture (SFP/SFC chasing it's tail) come as people look forward to the encapsulation/header document. That's probably unavoidable. When you read the NSH document, the SFP verbiage says that all participants MUST forward on the SP/SPI, but the document doesn't say how the SPI is derived/calculated (the vision here could be made clearer) or what it's relationship is to the transport path (I think you can't mix and match but can accommodate both within the header), should you opt for the transport header forwarding. It's obvious that some deployments prefer to use the transport header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which does play into the SPI or "other mechanisms" that populate a service table in the SFF). Perhaps the authors of NSH can suggest verbiage that makes the relationship between transport-based forwarding and service-based forwarding (SPI) clearer? This should eliminate/minimize the calls for redefinition/recasting our terminology and allow us to move on. On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: > > I have gotten a bit lost in the SFF/SFC discussion, which seems to have >gotten needlessly complicated and convoluted IMHO. > > Is it possible for the chairs to add this to the list of things to >discuss at the WG meeting or do we want to resolve this on the list ahead >of the meeting? > > --Tom > > >On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >wrote: > >> Hi Peng, >>=20 >>> -----Original Message----- >>> From: He, Peng [mailto:phe@ciena.com] >>> Sent: Tuesday, July 15, 2014 9:09 PM >>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: RE: [sfc] SFC Terminology / Concepts >>>=20 >>> Try to understand the three scenarios you listed: you mean the >>>classifier can >>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>SFF will >>> (locally) select one of the SF instances under itself for this SF. For >>>partial SFP case, >>=20 >> In either case, the SFF should be capable of selecting the appropriate >>instance of a given SF attached to itself. it's an internal >>load-balancing issue. >>=20 >>> each SFF will identify the SFI under itself and specify (like a >>>classifier) next SFF(s). >>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>from either >>> centralized point (e.g., PCE, controller), or, via a distributed >>>control plane? For >>> partial SFP, will there be a re-classification to decide next SFF(s) >>>or not? >>=20 >> If you want the SFF to locally determine the appropriate SFF for the >>next SF, the SFF should have the capability of resolving the SFF for the >>next SF based on certain constraints. Of course, it needs to know some >>information about the SFs in advance, e.g., the information about which >>SFFs a given SF is attached. >>=20 >> Best regards, >> Xiaohu >>=20 >>> Regards, >>> Peng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: Tuesday, July 15, 2014 4:49 AM >>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Med, >>>=20 >>> IMHO, the architecture should allow the classifier to specify >>>=20 >>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>locally determine >>> the appropriate SFF for the next SF); >>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>determined by >>> the centralized node); >>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>determine the >>> appropriate SFF for the next SF). >>>=20 >>> In fact, case 3) could be looked as an extreme of case 1). >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Hi Joel, >>>>=20 >>>> As mentioned in several messages, I'm personally for the use of the >>>> chain itself is the main information to be conveyed in packets to >>>>drive >>> forwarding actions. >>>>=20 >>>> I can understand that an identifier can be assigned to a path that is >>>> known in advance, but if that path is not known I'm not sure how an >>>> identifier can be assigned to it! >>>>=20 >>>> Joel, the use of "path" is really inappropriate to refer to >>>> distributed instance selection process for packets bound to a given >>>>SFC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org= ; >>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>=20 >>>>> The most likely realization of the architecture would be that the SFP >>>>> assignment is recorded in an identifier which travels with the >>>>>packet. >>>>>=20 >>>>> Some folks seem to not want the architecture to mandate that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>=20 >>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>> Your text scares me because it introduces some new concepts and >>>>>> assumptions. >>>>>>=20 >>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>> am I right in seeing the implication that when control assigns an >>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>> with the >>>> packet? >>>>>>=20 >>>>>> Tom Taylor >>>>>>=20 >>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>text >>>>>>> with: >>>>>>>=20 >>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>> of the service functions to be invoked and the order in which they >>>>>>> are to be invoked for some particular flow or set of flows, without >>> concern of >>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>> SFC affecting the instance selection of one or more of the service >>> functions >>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>with >>>>> it." >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> Ron >>>>>> ... >>>>>>=20 >>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>> Allan I >>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> I like that text, it strikes a good balance where an >>>>>>> implementation has the option of making scale and resiliency a >>>>>>>local >>> matter.. >>>>>>>=20 >>>>>>> D >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Dear WG: >>>>>>>=20 >>>>>>> There has been much debate over the last few days with regards to >>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>> and concepts used to describe the architecture in the merged >>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>=20 >>>>>>> "The SFP provides a level of indirection between the fully >>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>> delivered, and the fully specified notion of exactly what >>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>> the network. By allowing the control components to specify the use >>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>network." >>>>>>>=20 >>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>> the merged architecture draft. >>>>>>>=20 >>>>>>> Thank You, >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 From nobody Wed Jul 16 14:43: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 A0F4E1A0317 for ; Wed, 16 Jul 2014 14:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JxqfAGchA27B for ; Wed, 16 Jul 2014 14:43:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C021A008C for ; Wed, 16 Jul 2014 14:43:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG62227; Wed, 16 Jul 2014 21:43:00 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Jul 2014 22:43:00 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Wed, 16 Jul 2014 14:42:52 -0700 From: Henry Fourie To: "Ken Gray (kegray)" , "Thomas D. Nadeau" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAAayQD//7ftIA== Date: Wed, 16 Jul 2014 21:42:51 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AA232FD@SJCEML702-CHM.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.75] 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/UvaHlxey-P9_zk-9B0a0xGaHaO8 Cc: "sfc@ietf.org" , "He, Peng" , Ron Parker , Tom Taylor , "Joel M. Halpern" , "mohamed.boucadair@orange.com" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 16 Jul 2014 21:43:09 -0000 Ken, The Service Chain Header draft https://datatracker.ietf.org/doc/draft-z= hang-sfc-sch/ should answer some of your questions: In section 4.2 Mandatory Fields: Path Identifier: Identifies a fully instantiated service function path. It represents a sequence of network locators, one for each service function that is to be invoked. Participating SFC entities MUST use this identifier when selecting the next hop for the packet or frame. In section 4.4 Header Associated Operations: 3. Service Path Selection. The Service Network Forwarder (SNF) uses the Service Chain Identification information in the SCH to steer the traffic flow along the SFC path. 4. Service Function Instance Selection. The Service Function Forwarder (SFF) uses the Service Chain Identification information in the SCH to locate the service instance and forward the traffic flow to the service instance. The mapping of the Service Chain Identification to a service instance can be established through the management/control plane, which is out of scope of this document. - Louis -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau; sfc-chairs@ietf.org Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; mohame= d.boucadair@orange.com Subject: Re: [sfc] SFC Terminology / Concepts Joel, et. all, I think that some of the questions in architecture (SFP/SFC chasing it's tail) come as people look forward to the encapsulation/header document. That's probably unavoidable. When you read the NSH document, the SFP verbiage says that all participants MUST forward on the SP/SPI, but the document doesn't say how the SPI is derived/calculated (the vision here could be made clearer) or what it's relationship is to the transport path (I think you can't mix and match but can accommodate both within the header), should you opt for the transport header forwarding. It's obvious that some deployments prefer to use the transport header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which does play into the SPI or "other mechanisms" that populate a service table in the SFF). Perhaps the authors of NSH can suggest verbiage that makes the relationship between transport-based forwarding and service-based forwarding (SPI) clearer? This should eliminate/minimize the calls for redefinition/recasting our terminology and allow us to move on. On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: > > I have gotten a bit lost in the SFF/SFC discussion, which seems to have >gotten needlessly complicated and convoluted IMHO. > > Is it possible for the chairs to add this to the list of things to >discuss at the WG meeting or do we want to resolve this on the list ahead >of the meeting? > > --Tom > > >On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >wrote: > >> Hi Peng, >>=20 >>> -----Original Message----- >>> From: He, Peng [mailto:phe@ciena.com] >>> Sent: Tuesday, July 15, 2014 9:09 PM >>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: RE: [sfc] SFC Terminology / Concepts >>>=20 >>> Try to understand the three scenarios you listed: you mean the >>>classifier can >>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>SFF will >>> (locally) select one of the SF instances under itself for this SF. For >>>partial SFP case, >>=20 >> In either case, the SFF should be capable of selecting the appropriate >>instance of a given SF attached to itself. it's an internal >>load-balancing issue. >>=20 >>> each SFF will identify the SFI under itself and specify (like a >>>classifier) next SFF(s). >>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>from either >>> centralized point (e.g., PCE, controller), or, via a distributed >>>control plane? For >>> partial SFP, will there be a re-classification to decide next SFF(s) >>>or not? >>=20 >> If you want the SFF to locally determine the appropriate SFF for the >>next SF, the SFF should have the capability of resolving the SFF for the >>next SF based on certain constraints. Of course, it needs to know some >>information about the SFs in advance, e.g., the information about which >>SFFs a given SF is attached. >>=20 >> Best regards, >> Xiaohu >>=20 >>> Regards, >>> Peng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: Tuesday, July 15, 2014 4:49 AM >>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Med, >>>=20 >>> IMHO, the architecture should allow the classifier to specify >>>=20 >>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>locally determine >>> the appropriate SFF for the next SF); >>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>determined by >>> the centralized node); >>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>determine the >>> appropriate SFF for the next SF). >>>=20 >>> In fact, case 3) could be looked as an extreme of case 1). >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Hi Joel, >>>>=20 >>>> As mentioned in several messages, I'm personally for the use of the >>>> chain itself is the main information to be conveyed in packets to >>>>drive >>> forwarding actions. >>>>=20 >>>> I can understand that an identifier can be assigned to a path that is >>>> known in advance, but if that path is not known I'm not sure how an >>>> identifier can be assigned to it! >>>>=20 >>>> Joel, the use of "path" is really inappropriate to refer to >>>> distributed instance selection process for packets bound to a given >>>>SFC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org= ; >>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>=20 >>>>> The most likely realization of the architecture would be that the SFP >>>>> assignment is recorded in an identifier which travels with the >>>>>packet. >>>>>=20 >>>>> Some folks seem to not want the architecture to mandate that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>=20 >>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>> Your text scares me because it introduces some new concepts and >>>>>> assumptions. >>>>>>=20 >>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>> am I right in seeing the implication that when control assigns an >>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>> with the >>>> packet? >>>>>>=20 >>>>>> Tom Taylor >>>>>>=20 >>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>text >>>>>>> with: >>>>>>>=20 >>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>> of the service functions to be invoked and the order in which they >>>>>>> are to be invoked for some particular flow or set of flows, without >>> concern of >>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>> SFC affecting the instance selection of one or more of the service >>> functions >>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>with >>>>> it." >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> Ron >>>>>> ... >>>>>>=20 >>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>> Allan I >>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> I like that text, it strikes a good balance where an >>>>>>> implementation has the option of making scale and resiliency a >>>>>>>local >>> matter.. >>>>>>>=20 >>>>>>> D >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Dear WG: >>>>>>>=20 >>>>>>> There has been much debate over the last few days with regards to >>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>> and concepts used to describe the architecture in the merged >>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>=20 >>>>>>> "The SFP provides a level of indirection between the fully >>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>> delivered, and the fully specified notion of exactly what >>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>> the network. By allowing the control components to specify the use >>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>network." >>>>>>>=20 >>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>> the merged architecture draft. >>>>>>>=20 >>>>>>> Thank You, >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 From nobody Wed Jul 16 14:47: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 681BD1A0317 for ; Wed, 16 Jul 2014 14:47:04 -0700 (PDT) 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 Of7gqg_ujcpl for ; Wed, 16 Jul 2014 14:47:01 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FB11A008C for ; Wed, 16 Jul 2014 14:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id F261DD5559F; Wed, 16 Jul 2014 14:47:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.116.134.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 6F78CD55597; Wed, 16 Jul 2014 14:47:00 -0700 (PDT) Message-ID: <53C6F2D3.70805@joelhalpern.com> Date: Wed, 16 Jul 2014 17:46:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Henry Fourie , "sfc@ietf.org" References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> In-Reply-To: <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-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/CK_15sZv41nNGUmav5AC5a8SiuE Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 16 Jul 2014 21:47:04 -0000 I would hope that we can end up with an archtiecture document that is understandable and useful without resorting to a specific solution document. That is our goal. There probably are refinements needed to achieve that goal. Yours, Joel On 7/16/14, 5:39 PM, Henry Fourie wrote: > Ken, > The Service chain Header draft https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ > should answer some of your questions. In particular: > > In section 4.2 Mandatory Fields: > > Path Identifier: Identifies a fully instantiated service function > path. It represents a sequence of network locators, one for each > service function that is to be invoked. Participating SFC entities > MUST use this identifier when selecting the next hop for the > packet or frame. > > In section 4.4 Header Associated Operations: > > 3. Service Path Selection. The Service Network Forwarder (SNF) uses > the Service Chain Identification information in the SCH to steer > the traffic flow along the SFC path. > > 4. Service Function Instance Selection. The Service Function > Forwarder (SFF) uses the Service Chain Identification information > in the SCH to locate the service instance and forward the traffic > flow to the service instance. The mapping of the Service Chain > Identification to a service instance can be established through > the management/control plane, which is out of scope of this > document. > > - Louis > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) > Sent: Wednesday, July 16, 2014 11:59 AM > To: Thomas D. Nadeau; sfc-chairs@ietf.org > Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; mohamed.boucadair@orange.com > Subject: Re: [sfc] SFC Terminology / Concepts > > Joel, et. all, > > I think that some of the questions in architecture (SFP/SFC chasing it's > tail) come as people look forward to the encapsulation/header document. > That's probably unavoidable. > > When you read the NSH document, the SFP verbiage says that all > participants MUST forward on the SP/SPI, but the document doesn't say how > the SPI is derived/calculated (the vision here could be made clearer) or > what it's relationship is to the transport path (I think you can't mix and > match but can accommodate both within the header), should you opt for the > transport header forwarding. > > It's obvious that some deployments prefer to use the transport header for > forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which > does play into the SPI or "other mechanisms" that populate a service table > in the SFF). > > Perhaps the authors of NSH can suggest verbiage that makes the > relationship between transport-based forwarding and service-based > forwarding (SPI) clearer? > > This should eliminate/minimize the calls for redefinition/recasting our > terminology and allow us to move on. > > On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: > >> >> I have gotten a bit lost in the SFF/SFC discussion, which seems to have >> gotten needlessly complicated and convoluted IMHO. >> >> Is it possible for the chairs to add this to the list of things to >> discuss at the WG meeting or do we want to resolve this on the list ahead >> of the meeting? >> >> --Tom >> >> >> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >> wrote: >> >>> Hi Peng, >>> >>>> -----Original Message----- >>>> From: He, Peng [mailto:phe@ciena.com] >>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>> Taylor; >>>> sfc@ietf.org; Ron Parker >>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>> >>>> Try to understand the three scenarios you listed: you mean the >>>> classifier can >>>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>> SFF will >>>> (locally) select one of the SF instances under itself for this SF. For >>>> partial SFP case, >>> >>> In either case, the SFF should be capable of selecting the appropriate >>> instance of a given SF attached to itself. it's an internal >>> load-balancing issue. >>> >>>> each SFF will identify the SFI under itself and specify (like a >>>> classifier) next SFF(s). >>>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>> >from either >>>> centralized point (e.g., PCE, controller), or, via a distributed >>>> control plane? For >>>> partial SFP, will there be a re-classification to decide next SFF(s) >>>> or not? >>> >>> If you want the SFF to locally determine the appropriate SFF for the >>> next SF, the SFF should have the capability of resolving the SFF for the >>> next SF based on certain constraints. Of course, it needs to know some >>> information about the SFs in advance, e.g., the information about which >>> SFFs a given SF is attached. >>> >>> Best regards, >>> Xiaohu >>> >>>> Regards, >>>> Peng >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>> sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>> >>>> Hi Med, >>>> >>>> IMHO, the architecture should allow the classifier to specify >>>> >>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>> locally determine >>>> the appropriate SFF for the next SF); >>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>> determined by >>>> the centralized node); >>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>> determine the >>>> appropriate SFF for the next SF). >>>> >>>> In fact, case 3) could be looked as an extreme of case 1). >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com >>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>> >>>>> Hi Joel, >>>>> >>>>> As mentioned in several messages, I'm personally for the use of the >>>>> chain itself is the main information to be conveyed in packets to >>>>> drive >>>> forwarding actions. >>>>> >>>>> I can understand that an identifier can be assigned to a path that is >>>>> known in advance, but if that path is not known I'm not sure how an >>>>> identifier can be assigned to it! >>>>> >>>>> Joel, the use of "path" is really inappropriate to refer to >>>>> distributed instance selection process for packets bound to a given >>>>> SFC. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>>> Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; sfc@ietf.org; >>>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> The most likely realization of the architecture would be that the SFP >>>>>> assignment is recorded in an identifier which travels with the >>>>>> packet. >>>>>> >>>>>> Some folks seem to not want the architecture to mandate that. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> >>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>> Your text scares me because it introduces some new concepts and >>>>>>> assumptions. >>>>>>> >>>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>>> am I right in seeing the implication that when control assigns an >>>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>>> with the >>>>> packet? >>>>>>> >>>>>>> Tom Taylor >>>>>>> >>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>> text >>>>>>>> with: >>>>>>>> >>>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>>> of the service functions to be invoked and the order in which they >>>>>>>> are to be invoked for some particular flow or set of flows, without >>>> concern of >>>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>>> SFC affecting the instance selection of one or more of the service >>>> functions >>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>> with >>>>>> it." >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Ron >>>>>>> ... >>>>>>> >>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>>> Allan I >>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>> >>>>>>>> I like that text, it strikes a good balance where an >>>>>>>> implementation has the option of making scale and resiliency a >>>>>>>> local >>>> matter.. >>>>>>>> >>>>>>>> D >>>>>>>> >>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>>> Guichard >>>>>>>> (jguichar) >>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>> *To:* sfc@ietf.org >>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> There has been much debate over the last few days with regards to >>>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>>> and concepts used to describe the architecture in the merged >>>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>> >>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>>> delivered, and the fully specified notion of exactly what >>>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>>> the network. By allowing the control components to specify the use >>>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>> network." >>>>>>>> >>>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>>> the merged architecture draft. >>>>>>>> >>>>>>>> Thank You, >>>>>>>> >>>>>>>> Jim >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 16 22:53: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 29BE71A0652 for ; Wed, 16 Jul 2014 22:53:10 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JCUWkuhArLeX for ; Wed, 16 Jul 2014 22:53:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6371A04B8 for ; Wed, 16 Jul 2014 22:53:07 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 59C652AC261; Thu, 17 Jul 2014 07:53:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 3180AC804B; Thu, 17 Jul 2014 07:53:05 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 07:53:05 +0200 From: To: Xuxiaohu , "Joel M. Halpern" , Tom Taylor , "sfc@ietf.org" , "Ron Parker" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u08Pl2nv4amkeW+iiVKhPLs5uf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcIABADUAgACaNiCAAUppwA== Date: Thu, 17 Jul 2014 05:53:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300351AB@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082937A9@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082937A9@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.7.17.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0V4sPhVzi0MwhqnS-Cvpn_LXbOY Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 05:53:10 -0000 Hi Xiaohu, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] >Envoy=E9=A0: mercredi 16 juillet 2014 12:15 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor; sfc@ietf.o= rg; >Ron Parker >Objet=A0: RE: [sfc] SFC Terminology / Concepts > >Hi Med, > >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: Wednesday, July 16, 2014 4:54 PM >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >> Subject: RE: [sfc] SFC Terminology / Concepts >> >> Hi Xiaohu, >> >> Please see inline. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 juil= let >> >2014 11:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Tayl= or; >> >sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology / Concepts >> > >> >Hi Med, >> > >> >> -----Original Message----- >> >> From: mohamed.boucadair@orange.com >> >> [mailto:mohamed.boucadair@orange.com] >> >> Sent: Tuesday, July 15, 2014 5:35 PM >> >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >> >> Subject: RE: [sfc] SFC Terminology / Concepts >> >> >> >> Hi Xiaohu, >> >> >> >> Why a classifier will need specify a path a la ERO? Why it needs to >> >> have >> >the full >> > >> >In this way, the path selection process (i.e., selecting the >> >appropriate SFF for the next SF based on certain constraints) on the >> >SFF is greatly simplified. >> >> [Med] This does not answer to my question why the "classifier" has >specifically >> to take care of this? How multiple classifiers present in a given SFC- >enabled >> domain behave in order to distribute traffic among available Service >Function >> Nodes? How a classifier can distribute traffic without any conflict with >other LBs >> that may be present in the forwarding path? >> [Med] It seems you missed this one. >> > >> >> knowledge of the involved SF instances? Wouldn't this require the >> >classifier to >> >> be fed with additional information to drive its selection process? Is >> >this >> > >> >The classifier could request the PCE to do the SFP computation (see >> >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is >> >no need for the classifier to be fed with additional information. >> >> [Med] Functionally, the classifier will need a path computation >component. >> Whether these two are co-located or separated is implementation-specific= . >My >> concern is to require that path computation component as a mandatory >> component for the architecture. I think this is not justified. > >If the SFP computation is performed by the PCE, the classifier just needs >to accept the computation result returned by the PCE and then impose the >SFP info on the selected packets. In other words, the classifier doesn't >need that SFP computation component anymore. Furthermore, if the classifie= r >is just allowed to impose the SFC info on the selected packet, it doesn't >need the SFP computation component as well. [Med] But still, for the sake of interoperability, the classifier need to b= e prepared for such interface with an external PCE module, no? > >> >> complexity justified for all deployments? >> > >> >As I have said, the architecture should allow the classifier to just >> >impose the SFC information on the selected packet as well. In this way, >> >each SFF needs to resolve the appropriate next SFF for the next SF to b= e >> executed. >> >> [Med] Yes, I understood that from you initial list. My question is how t= o >package >> all this together without imposing complexity to deployments that do not >> require it. > >Since architecture allows three options, operators could make their own >choices accordingly. [Med] The problem is that packaging a lot of optional features will have an= impact on the overall complexity of the solution. This is why I'm question= ing having any possible feature as an optional part of the solution.=20 From nobody Wed Jul 16 22:57: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 E6B221A04B8 for ; Wed, 16 Jul 2014 22:57:06 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Wimuv_74_4yL for ; Wed, 16 Jul 2014 22:57:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890B91A0652 for ; Wed, 16 Jul 2014 22:57:03 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 97A3518C349; Thu, 17 Jul 2014 07:57:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 73D5135C045; Thu, 17 Jul 2014 07:57:01 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 17 Jul 2014 07:57:01 +0200 From: To: "Joel M. Halpern" , Henry Fourie , "sfc@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPoRqe8Pl2nv4amkeW+iiVKhPLs5ui7EkAgAAs5YCAAAIGgIAAqYlw Date: Thu, 17 Jul 2014 05:57:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> In-Reply-To: <53C6F2D3.70805@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] 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.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2dCX_LTEh19A58Ib0WGa3rm8qxc Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 05:57:07 -0000 Hi Joel, I fully agree with you about the goal.=20 Nevertheless, the merged document, as it currently stands, includes some so= lution hints that come mainly from nsh. I would really hope the document be= updated to be neutral.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9=A0: mercredi 16 juillet 2014 23:47 >=C0=A0: Henry Fourie; sfc@ietf.org >Objet=A0: Re: [sfc] SFC Terminology / Concepts > >I would hope that we can end up with an archtiecture document that is >understandable and useful without resorting to a specific solution >document. That is our goal. There probably are refinements needed to >achieve that goal. > >Yours, >Joel > >On 7/16/14, 5:39 PM, Henry Fourie wrote: >> Ken, >> The Service chain Header draft https://datatracker.ietf.org/doc/draft= - >zhang-sfc-sch/ >> should answer some of your questions. In particular: >> >> In section 4.2 Mandatory Fields: >> >> Path Identifier: Identifies a fully instantiated service function >> path. It represents a sequence of network locators, one for each >> service function that is to be invoked. Participating SFC entitie= s >> MUST use this identifier when selecting the next hop for the >> packet or frame. >> >> In section 4.4 Header Associated Operations: >> >> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >> the Service Chain Identification information in the SCH to steer >> the traffic flow along the SFC path. >> >> 4. Service Function Instance Selection. The Service Function >> Forwarder (SFF) uses the Service Chain Identification information >> in the SCH to locate the service instance and forward the traffic >> flow to the service instance. The mapping of the Service Chain >> Identification to a service instance can be established through >> the management/control plane, which is out of scope of this >> document. >> >> - Louis >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) >> Sent: Wednesday, July 16, 2014 11:59 AM >> To: Thomas D. Nadeau; sfc-chairs@ietf.org >> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >mohamed.boucadair@orange.com >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Joel, et. all, >> >> I think that some of the questions in architecture (SFP/SFC chasing it's >> tail) come as people look forward to the encapsulation/header document. >> That's probably unavoidable. >> >> When you read the NSH document, the SFP verbiage says that all >> participants MUST forward on the SP/SPI, but the document doesn't say ho= w >> the SPI is derived/calculated (the vision here could be made clearer) or >> what it's relationship is to the transport path (I think you can't mix >and >> match but can accommodate both within the header), should you opt for th= e >> transport header forwarding. >> >> It's obvious that some deployments prefer to use the transport header fo= r >> forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which >> does play into the SPI or "other mechanisms" that populate a service >table >> in the SFF). >> >> Perhaps the authors of NSH can suggest verbiage that makes the >> relationship between transport-based forwarding and service-based >> forwarding (SPI) clearer? >> >> This should eliminate/minimize the calls for redefinition/recasting our >> terminology and allow us to move on. >> >> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: >> >>> >>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >have >>> gotten needlessly complicated and convoluted IMHO. >>> >>> Is it possible for the chairs to add this to the list of things to >>> discuss at the WG meeting or do we want to resolve this on the list >ahead >>> of the meeting? >>> >>> --Tom >>> >>> >>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>> wrote: >>> >>>> Hi Peng, >>>> >>>>> -----Original Message----- >>>>> From: He, Peng [mailto:phe@ciena.com] >>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>>> Taylor; >>>>> sfc@ietf.org; Ron Parker >>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>> >>>>> Try to understand the three scenarios you listed: you mean the >>>>> classifier can >>>>> specify a (partial or complete) SFP which is a list of SFFs, then eac= h >>>>> SFF will >>>>> (locally) select one of the SF instances under itself for this SF. Fo= r >>>>> partial SFP case, >>>> >>>> In either case, the SFF should be capable of selecting the appropriate >>>> instance of a given SF attached to itself. it's an internal >>>> load-balancing issue. >>>> >>>>> each SFF will identify the SFI under itself and specify (like a >>>>> classifier) next SFF(s). >>>>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>> >from either >>>>> centralized point (e.g., PCE, controller), or, via a distributed >>>>> control plane? For >>>>> partial SFP, will there be a re-classification to decide next SFF(s) >>>>> or not? >>>> >>>> If you want the SFF to locally determine the appropriate SFF for the >>>> next SF, the SFF should have the capability of resolving the SFF for >the >>>> next SF based on certain constraints. Of course, it needs to know some >>>> information about the SFs in advance, e.g., the information about whic= h >>>> SFFs a given SF is attached. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> Regards, >>>>> Peng >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>>> sfc@ietf.org; Ron Parker >>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>> >>>>> Hi Med, >>>>> >>>>> IMHO, the architecture should allow the classifier to specify >>>>> >>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>>> locally determine >>>>> the appropriate SFF for the next SF); >>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>>> determined by >>>>> the centralized node); >>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>>> determine the >>>>> appropriate SFF for the next SF). >>>>> >>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> As mentioned in several messages, I'm personally for the use of the >>>>>> chain itself is the main information to be conveyed in packets to >>>>>> drive >>>>> forwarding actions. >>>>>> >>>>>> I can understand that an identifier can be assigned to a path that i= s >>>>>> known in advance, but if that path is not known I'm not sure how an >>>>>> identifier can be assigned to it! >>>>>> >>>>>> Joel, the use of "path" is really inappropriate to refer to >>>>>> distributed instance selection process for packets bound to a given >>>>>> SFC. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halper= n >>>>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.o= rg; >>>>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>>> >>>>>>> The most likely realization of the architecture would be that the >SFP >>>>>>> assignment is recorded in an identifier which travels with the >>>>>>> packet. >>>>>>> >>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>> Your text scares me because it introduces some new concepts and >>>>>>>> assumptions. >>>>>>>> >>>>>>>> I'd rather go with Joel's formulation. Clarifying question on that= : >>>>>>>> am I right in seeing the implication that when control assigns an >>>>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>>>> with the >>>>>> packet? >>>>>>>> >>>>>>>> Tom Taylor >>>>>>>> >>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>> There is one missing word in my text. Please replace my propose= d >>>>>>>>> text >>>>>>>>> with: >>>>>>>>> >>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>>>> of the service functions to be invoked and the order in which the= y >>>>>>>>> are to be invoked for some particular flow or set of flows, >without >>>>> concern of >>>>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>>>> SFC affecting the instance selection of one or more of the servic= e >>>>> functions >>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>> with >>>>>>> it." >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Ron >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>>>> Allan I >>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> I like that text, it strikes a good balance where an >>>>>>>>> implementation has the option of making scale and resiliency a >>>>>>>>> local >>>>> matter.. >>>>>>>>> >>>>>>>>> D >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>>>> Guichard >>>>>>>>> (jguichar) >>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>> *To:* sfc@ietf.org >>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> There has been much debate over the last few days with regards to >>>>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>>>> and concepts used to describe the architecture in the merged >>>>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>>> >>>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>>>> delivered, and the fully specified notion of exactly what >>>>>>>>> instances of SFFs the packet will visit when it actually traverse= s >>>>>>>>> the network. By allowing the control components to specify the us= e >>>>>>>>> of this level of indirection, the deployment may choose the degre= e >>>>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>>> network." >>>>>>>>> >>>>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>>>> the merged architecture draft. >>>>>>>>> >>>>>>>>> Thank You, >>>>>>>>> >>>>>>>>> Jim >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing 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 Jul 17 14:34: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 4DC831A0304 for ; Thu, 17 Jul 2014 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2riEHXQOcaM9 for ; Thu, 17 Jul 2014 14:33:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DFD1A0302 for ; Thu, 17 Jul 2014 14:33:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKE90356; Thu, 17 Jul 2014 21:33:56 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 22:33:55 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 14:33:47 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Henry Fourie , "sfc@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAAayQD//7mqdIAA/ikAgACQQXA= Date: Thu, 17 Jul 2014 21:33:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9F0EA@dfweml701-chm.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.170] 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/qcRDIfFO0zHDYhq8pJjuObM-Ywc Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 21:34:00 -0000 Agree with what Med said.=20 Cheers, Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 17, 2014 12:57 AM To: Joel M. Halpern; Henry Fourie; sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts Hi Joel, I fully agree with you about the goal.=20 Nevertheless, the merged document, as it currently stands, includes some so= lution hints that come mainly from nsh. I would really hope the document be= updated to be neutral.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >Envoy=E9=A0: mercredi 16 juillet 2014 23:47 =C0=A0: Henry Fourie; sfc@ietf= .org=20 >Objet=A0: Re: [sfc] SFC Terminology / Concepts > >I would hope that we can end up with an archtiecture document that is=20 >understandable and useful without resorting to a specific solution=20 >document. That is our goal. There probably are refinements needed to=20 >achieve that goal. > >Yours, >Joel > >On 7/16/14, 5:39 PM, Henry Fourie wrote: >> Ken, >> The Service chain Header draft=20 >> https://datatracker.ietf.org/doc/draft- >zhang-sfc-sch/ >> should answer some of your questions. In particular: >> >> In section 4.2 Mandatory Fields: >> >> Path Identifier: Identifies a fully instantiated service function >> path. It represents a sequence of network locators, one for each >> service function that is to be invoked. Participating SFC entitie= s >> MUST use this identifier when selecting the next hop for the >> packet or frame. >> >> In section 4.4 Header Associated Operations: >> >> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >> the Service Chain Identification information in the SCH to steer >> the traffic flow along the SFC path. >> >> 4. Service Function Instance Selection. The Service Function >> Forwarder (SFF) uses the Service Chain Identification information >> in the SCH to locate the service instance and forward the traffic >> flow to the service instance. The mapping of the Service Chain >> Identification to a service instance can be established through >> the management/control plane, which is out of scope of this >> document. >> >> - Louis >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray=20 >> (kegray) >> Sent: Wednesday, July 16, 2014 11:59 AM >> To: Thomas D. Nadeau; sfc-chairs@ietf.org >> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >mohamed.boucadair@orange.com >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Joel, et. all, >> >> I think that some of the questions in architecture (SFP/SFC chasing=20 >> it's >> tail) come as people look forward to the encapsulation/header document. >> That's probably unavoidable. >> >> When you read the NSH document, the SFP verbiage says that all=20 >> participants MUST forward on the SP/SPI, but the document doesn't say=20 >> how the SPI is derived/calculated (the vision here could be made=20 >> clearer) or what it's relationship is to the transport path (I think=20 >> you can't mix >and >> match but can accommodate both within the header), should you opt for=20 >> the transport header forwarding. >> >> It's obvious that some deployments prefer to use the transport header=20 >> for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup=20 >> (which does play into the SPI or "other mechanisms" that populate a=20 >> service >table >> in the SFF). >> >> Perhaps the authors of NSH can suggest verbiage that makes the=20 >> relationship between transport-based forwarding and service-based=20 >> forwarding (SPI) clearer? >> >> This should eliminate/minimize the calls for redefinition/recasting=20 >> our terminology and allow us to move on. >> >> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: >> >>> >>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >have >>> gotten needlessly complicated and convoluted IMHO. >>> >>> Is it possible for the chairs to add this to the list of things to=20 >>> discuss at the WG meeting or do we want to resolve this on the list >ahead >>> of the meeting? >>> >>> --Tom >>> >>> >>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu=20 >>> >>> wrote: >>> >>>> Hi Peng, >>>> >>>>> -----Original Message----- >>>>> From: He, Peng [mailto:phe@ciena.com] >>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom=20 >>>>> Taylor; sfc@ietf.org; Ron Parker >>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>> >>>>> Try to understand the three scenarios you listed: you mean the=20 >>>>> classifier can specify a (partial or complete) SFP which is a list=20 >>>>> of SFFs, then each SFF will >>>>> (locally) select one of the SF instances under itself for this SF.=20 >>>>> For partial SFP case, >>>> >>>> In either case, the SFF should be capable of selecting the=20 >>>> appropriate instance of a given SF attached to itself. it's an=20 >>>> internal load-balancing issue. >>>> >>>>> each SFF will identify the SFI under itself and specify (like a >>>>> classifier) next SFF(s). >>>>> The classifier (and SFF?) could obtain this (SFF) 'path'=20 >>>>> information >>>> >from either >>>>> centralized point (e.g., PCE, controller), or, via a distributed=20 >>>>> control plane? For partial SFP, will there be a re-classification=20 >>>>> to decide next SFF(s) or not? >>>> >>>> If you want the SFF to locally determine the appropriate SFF for=20 >>>> the next SF, the SFF should have the capability of resolving the=20 >>>> SFF for >the >>>> next SF based on certain constraints. Of course, it needs to know=20 >>>> some information about the SFs in advance, e.g., the information=20 >>>> about which SFFs a given SF is attached. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> Regards, >>>>> Peng >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor;=20 >>>>> sfc@ietf.org; Ron Parker >>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>> >>>>> Hi Med, >>>>> >>>>> IMHO, the architecture should allow the classifier to specify >>>>> >>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to=20 >>>>> locally determine the appropriate SFF for the next SF); >>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been=20 >>>>> determined by the centralized node); >>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally=20 >>>>> determine the appropriate SFF for the next SF). >>>>> >>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> As mentioned in several messages, I'm personally for the use of=20 >>>>>> the chain itself is the main information to be conveyed in=20 >>>>>> packets to drive >>>>> forwarding actions. >>>>>> >>>>>> I can understand that an identifier can be assigned to a path=20 >>>>>> that is known in advance, but if that path is not known I'm not=20 >>>>>> sure how an identifier can be assigned to it! >>>>>> >>>>>> Joel, the use of "path" is really inappropriate to refer to=20 >>>>>> distributed instance selection process for packets bound to a=20 >>>>>> given SFC. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M.=20 >>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor;=20 >>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology /=20 >>>>>>> Concepts >>>>>>> >>>>>>> The most likely realization of the architecture would be that=20 >>>>>>> the >SFP >>>>>>> assignment is recorded in an identifier which travels with the=20 >>>>>>> packet. >>>>>>> >>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>> Your text scares me because it introduces some new concepts and=20 >>>>>>>> assumptions. >>>>>>>> >>>>>>>> I'd rather go with Joel's formulation. Clarifying question on that= : >>>>>>>> am I right in seeing the implication that when control assigns=20 >>>>>>>> an SFP, the assignment is recorded by an identifier wwhich=20 >>>>>>>> travels with the >>>>>> packet? >>>>>>>> >>>>>>>> Tom Taylor >>>>>>>> >>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>> There is one missing word in my text. Please replace my propose= d >>>>>>>>> text >>>>>>>>> with: >>>>>>>>> >>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract=20 >>>>>>>>> view of the service functions to be invoked and the order in=20 >>>>>>>>> which they are to be invoked for some particular flow or set=20 >>>>>>>>> of flows, >without >>>>> concern of >>>>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>>>> (C-SFC) further allows for policy constraints to be added to=20 >>>>>>>>> the SFC affecting the instance selection of one or more of the=20 >>>>>>>>> service >>>>> functions >>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>> with >>>>>>> it." >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Ron >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 >>>>>>>>> Allan I >>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org=20 >>>>>>>>> >>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> I like that text, it strikes a good balance where an=20 >>>>>>>>> implementation has the option of making scale and resiliency a=20 >>>>>>>>> local >>>>> matter.. >>>>>>>>> >>>>>>>>> D >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>>>>>>> Guichard >>>>>>>>> (jguichar) >>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>> *To:* sfc@ietf.org >>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> There has been much debate over the last few days with regards=20 >>>>>>>>> to SFC concepts. To try and form some consensus around=20 >>>>>>>>> terminology and concepts used to describe the architecture in=20 >>>>>>>>> the merged architecture draft, Joel has kindly suggested the foll= owing: >>>>>>>>> >>>>>>>>> "The SFP provides a level of indirection between the fully=20 >>>>>>>>> abstract notion of service path as a sequence of functions to=20 >>>>>>>>> be delivered, and the fully specified notion of exactly what=20 >>>>>>>>> instances of SFFs the packet will visit when it actually=20 >>>>>>>>> traverses the network. By allowing the control components to=20 >>>>>>>>> specify the use of this level of indirection, the deployment=20 >>>>>>>>> may choose the degree of SFF instance selection authority that=20 >>>>>>>>> is delegated to the network." >>>>>>>>> >>>>>>>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>>>>>>> something that we can get consensus on. If so, I'll ask Joel=20 >>>>>>>>> to provide specific text, that reflects the above, for=20 >>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>> >>>>>>>>> Thank You, >>>>>>>>> >>>>>>>>> Jim >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing 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 Jul 17 15:02: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 A85451A0337 for ; Thu, 17 Jul 2014 15:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 whKTyb2h--Je for ; Thu, 17 Jul 2014 15:02:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727141A0302 for ; Thu, 17 Jul 2014 15:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15430; q=dns/txt; s=iport; t=1405634543; x=1406844143; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c4yw9uLtEk7IKufflXYu6Lt9ejLNWfskLsnOhhtULCE=; b=hh8QdmgH4tuVzqxfk4LeJiSLQogWKximkOp+MTpNNZ+VIeXUadJBQZz8 LMEDJkx0wjrQudo3T8k772C51DHhh1VMT6fzE5QX/0DqoQUorDNXoika4 YGysgoTkTttAlm5ulDQj3l3ZCk1sB+88rFmKOh5BPrh2CstU3KHki6IYX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADBHyFOtJA2B/2dsb2JhbABPCoMOUlfEBQqHQwGBCBZ2hAMBAQEDAQEBAQtXCQQHBQcEAgEIEQEDAQEBJwcnCxQDBggCBA4FG4gfCA3FXRMEjm8pLgUHBoMogRgFiiqMWoQblCyDRGw X-IronPort-AV: E=Sophos;i="5.01,680,1400025600"; d="scan'208";a="340946132" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2014 22:02:22 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6HM2Mnq031554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 22:02:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 17:02:21 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAWFqAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQA///XuACAAG/2gIAAAgWAgACI6QCAAQW8gP//tCs6 Date: Thu, 17 Jul 2014 22:02:21 +0000 Message-ID: <849C4D81-B08B-4A76-B203-4CA2FD110D84@cisco.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup>, <4A95BA014132FF49AE685FAB4B9F17F645D9F0EA@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9F0EA@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/rSRiEA3Qf-YrALpElTp7wC9XWKI Cc: Henry Fourie , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 22:02:28 -0000 I don't think you should write the document in ignorance of the proposed he= ader either. There's gonna be a header. Both proposals have a service pat= h element (devil's advocate - you have a draft unwritten for a header witho= ut a Service Path abstraction - normalize documents, you're still a minorit= y) and the question from both the editor and the chair were whether we coul= d come to consensus on the meaning of Service Path (which then began the od= dessy of trying to diferentiate it from Service Chain). I don't see hints = at a solution around the use of Service Path that are wildly different enou= gh to say one is favored over the other. I interpreted some of the comments about the Service Chain to be rooted in = the fear that one must forward on the Service Path (not appealing to transp= ort-header-centrists), which may/may_not have been clear. To return to the original question - I haven't really seen a compelling arg= ument why Joel's original proposition will not suffice. Sent from my iPhone > On Jul 17, 2014, at 5:34 PM, "Linda Dunbar" wro= te: >=20 > Agree with what Med said.=20 >=20 > Cheers, > Linda >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com > Sent: Thursday, July 17, 2014 12:57 AM > To: Joel M. Halpern; Henry Fourie; sfc@ietf.org > Subject: Re: [sfc] SFC Terminology / Concepts >=20 > Hi Joel, >=20 > I fully agree with you about the goal.=20 >=20 > Nevertheless, the merged document, as it currently stands, includes some = solution hints that come mainly from nsh. I would really hope the document = be updated to be neutral.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >> Envoy=E9 : mercredi 16 juillet 2014 23:47 =C0 : Henry Fourie; sfc@ietf.o= rg=20 >> Objet : Re: [sfc] SFC Terminology / Concepts >>=20 >> I would hope that we can end up with an archtiecture document that is=20 >> understandable and useful without resorting to a specific solution=20 >> document. That is our goal. There probably are refinements needed to=20 >> achieve that goal. >>=20 >> Yours, >> Joel >>=20 >>> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>> Ken, >>> The Service chain Header draft=20 >>> https://datatracker.ietf.org/doc/draft- >> zhang-sfc-sch/ >>> should answer some of your questions. In particular: >>>=20 >>> In section 4.2 Mandatory Fields: >>>=20 >>> Path Identifier: Identifies a fully instantiated service function >>> path. It represents a sequence of network locators, one for each >>> service function that is to be invoked. Participating SFC entitie= s >>> MUST use this identifier when selecting the next hop for the >>> packet or frame. >>>=20 >>> In section 4.4 Header Associated Operations: >>>=20 >>> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >>> the Service Chain Identification information in the SCH to steer >>> the traffic flow along the SFC path. >>>=20 >>> 4. Service Function Instance Selection. The Service Function >>> Forwarder (SFF) uses the Service Chain Identification information >>> in the SCH to locate the service instance and forward the traffic >>> flow to the service instance. The mapping of the Service Chain >>> Identification to a service instance can be established through >>> the management/control plane, which is out of scope of this >>> document. >>>=20 >>> - Louis >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray=20 >>> (kegray) >>> Sent: Wednesday, July 16, 2014 11:59 AM >>> To: Thomas D. Nadeau; sfc-chairs@ietf.org >>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >> mohamed.boucadair@orange.com >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Joel, et. all, >>>=20 >>> I think that some of the questions in architecture (SFP/SFC chasing=20 >>> it's >>> tail) come as people look forward to the encapsulation/header document. >>> That's probably unavoidable. >>>=20 >>> When you read the NSH document, the SFP verbiage says that all=20 >>> participants MUST forward on the SP/SPI, but the document doesn't say=20 >>> how the SPI is derived/calculated (the vision here could be made=20 >>> clearer) or what it's relationship is to the transport path (I think=20 >>> you can't mix >> and >>> match but can accommodate both within the header), should you opt for=20 >>> the transport header forwarding. >>>=20 >>> It's obvious that some deployments prefer to use the transport header=20 >>> for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup=20 >>> (which does play into the SPI or "other mechanisms" that populate a=20 >>> service >> table >>> in the SFF). >>>=20 >>> Perhaps the authors of NSH can suggest verbiage that makes the=20 >>> relationship between transport-based forwarding and service-based=20 >>> forwarding (SPI) clearer? >>>=20 >>> This should eliminate/minimize the calls for redefinition/recasting=20 >>> our terminology and allow us to move on. >>>=20 >>>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote= : >>>>=20 >>>>=20 >>>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >> have >>>> gotten needlessly complicated and convoluted IMHO. >>>>=20 >>>> Is it possible for the chairs to add this to the list of things to= =20 >>>> discuss at the WG meeting or do we want to resolve this on the list >> ahead >>>> of the meeting? >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu=20 >>>> >>>> wrote: >>>>=20 >>>>> Hi Peng, >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: He, Peng [mailto:phe@ciena.com] >>>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom=20 >>>>>> Taylor; sfc@ietf.org; Ron Parker >>>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>>>=20 >>>>>> Try to understand the three scenarios you listed: you mean the=20 >>>>>> classifier can specify a (partial or complete) SFP which is a list=20 >>>>>> of SFFs, then each SFF will >>>>>> (locally) select one of the SF instances under itself for this SF.=20 >>>>>> For partial SFP case, >>>>>=20 >>>>> In either case, the SFF should be capable of selecting the=20 >>>>> appropriate instance of a given SF attached to itself. it's an=20 >>>>> internal load-balancing issue. >>>>>=20 >>>>>> each SFF will identify the SFI under itself and specify (like a >>>>>> classifier) next SFF(s). >>>>>> The classifier (and SFF?) could obtain this (SFF) 'path'=20 >>>>>> information >>>>>> from either >>>>>> centralized point (e.g., PCE, controller), or, via a distributed=20 >>>>>> control plane? For partial SFP, will there be a re-classification=20 >>>>>> to decide next SFF(s) or not? >>>>>=20 >>>>> If you want the SFF to locally determine the appropriate SFF for=20 >>>>> the next SF, the SFF should have the capability of resolving the=20 >>>>> SFF for >> the >>>>> next SF based on certain constraints. Of course, it needs to know=20 >>>>> some information about the SFs in advance, e.g., the information=20 >>>>> about which SFFs a given SF is attached. >>>>>=20 >>>>> Best regards, >>>>> Xiaohu >>>>>=20 >>>>>> Regards, >>>>>> Peng >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor;=20 >>>>>> sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>=20 >>>>>> Hi Med, >>>>>>=20 >>>>>> IMHO, the architecture should allow the classifier to specify >>>>>>=20 >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to=20 >>>>>> locally determine the appropriate SFF for the next SF); >>>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been=20 >>>>>> determined by the centralized node); >>>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally=20 >>>>>> determine the appropriate SFF for the next SF). >>>>>>=20 >>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>>=20 >>>>>> Best regards, >>>>>> Xiaohu >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Hi Joel, >>>>>>>=20 >>>>>>> As mentioned in several messages, I'm personally for the use of=20 >>>>>>> the chain itself is the main information to be conveyed in=20 >>>>>>> packets to drive >>>>>> forwarding actions. >>>>>>>=20 >>>>>>> I can understand that an identifier can be assigned to a path=20 >>>>>>> that is known in advance, but if that path is not known I'm not=20 >>>>>>> sure how an identifier can be assigned to it! >>>>>>>=20 >>>>>>> Joel, the use of "path" is really inappropriate to refer to=20 >>>>>>> distributed instance selection process for packets bound to a=20 >>>>>>> given SFC. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Med >>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M.=20 >>>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor;=20 >>>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology /=20 >>>>>>>> Concepts >>>>>>>>=20 >>>>>>>> The most likely realization of the architecture would be that=20 >>>>>>>> the >> SFP >>>>>>>> assignment is recorded in an identifier which travels with the=20 >>>>>>>> packet. >>>>>>>>=20 >>>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>> Your text scares me because it introduces some new concepts and=20 >>>>>>>>> assumptions. >>>>>>>>>=20 >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on tha= t: >>>>>>>>> am I right in seeing the implication that when control assigns=20 >>>>>>>>> an SFP, the assignment is recorded by an identifier wwhich=20 >>>>>>>>> travels with the >>>>>>> packet? >>>>>>>>>=20 >>>>>>>>> Tom Taylor >>>>>>>>>=20 >>>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>> There is one missing word in my text. Please replace my propos= ed >>>>>>>>>> text >>>>>>>>>> with: >>>>>>>>>>=20 >>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract=20 >>>>>>>>>> view of the service functions to be invoked and the order in=20 >>>>>>>>>> which they are to be invoked for some particular flow or set=20 >>>>>>>>>> of flows, >> without >>>>>> concern of >>>>>>>>>> actual service function instance selection. The Constrained-SF= C >>>>>>>>>> (C-SFC) further allows for policy constraints to be added to=20 >>>>>>>>>> the SFC affecting the instance selection of one or more of the=20 >>>>>>>>>> service >>>>>> functions >>>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>>> with >>>>>>>> it." >>>>>>>>>>=20 >>>>>>>>>> Thanks. >>>>>>>>>>=20 >>>>>>>>>> Ron >>>>>>>>> ... >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 >>>>>>>>>> Allan I >>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org=20 >>>>>>>>>> >>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>>>=20 >>>>>>>>>> I like that text, it strikes a good balance where an=20 >>>>>>>>>> implementation has the option of making scale and resiliency a=20 >>>>>>>>>> local >>>>>> matter.. >>>>>>>>>>=20 >>>>>>>>>> D >>>>>>>>>>=20 >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>>>>>>>> Guichard >>>>>>>>>> (jguichar) >>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>>> *To:* sfc@ietf.org >>>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>>>=20 >>>>>>>>>> Dear WG: >>>>>>>>>>=20 >>>>>>>>>> There has been much debate over the last few days with regards=20 >>>>>>>>>> to SFC concepts. To try and form some consensus around=20 >>>>>>>>>> terminology and concepts used to describe the architecture in=20 >>>>>>>>>> the merged architecture draft, Joel has kindly suggested the fol= lowing: >>>>>>>>>>=20 >>>>>>>>>> "The SFP provides a level of indirection between the fully=20 >>>>>>>>>> abstract notion of service path as a sequence of functions to=20 >>>>>>>>>> be delivered, and the fully specified notion of exactly what=20 >>>>>>>>>> instances of SFFs the packet will visit when it actually=20 >>>>>>>>>> traverses the network. By allowing the control components to=20 >>>>>>>>>> specify the use of this level of indirection, the deployment=20 >>>>>>>>>> may choose the degree of SFF instance selection authority that=20 >>>>>>>>>> is delegated to the network." >>>>>>>>>>=20 >>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel=20 >>>>>>>>>> to provide specific text, that reflects the above, for=20 >>>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>>>=20 >>>>>>>>>> Thank You, >>>>>>>>>>=20 >>>>>>>>>> Jim >>>>>>>>>>=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 >>> _______________________________________________ >>> 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 nobody Thu Jul 17 16:12: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 A9AB61A037D for ; Thu, 17 Jul 2014 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 AY8cjc5I69F3 for ; Thu, 17 Jul 2014 16:11:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29331A0330 for ; Thu, 17 Jul 2014 16:11:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH64348; Thu, 17 Jul 2014 23:11:55 +0000 (GMT) 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, 18 Jul 2014 00:11:54 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 16:11:41 -0700 From: Linda Dunbar To: Ron Parker , "Hongyu Li (Julio)" , "Joel M. Halpern" , Tom Taylor , "sfc@ietf.org" Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGchCq5n8vwdREWBpvEK/3Dj6Zui2N0AgABAxgCAAcrIEA== Date: Thu, 17 Jul 2014 23:11:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Vdqmo7REjMsxX65TC2cQhbmPEjM Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 23:12:02 -0000 Ron,=20 You said: For a new flow, next SFF selection by an SFF SFF MUST be based on the ch= ain ID and MAY be based on metadata and/or locally known policy. Next SFI= selection by an SFF MUST be based on the chain ID and service function ind= ex within the chain and MAY be based on metadata and/or locally known polic= y. [Linda] "next SFI selection" criteria can even be based on packet size, lik= e an AntiDos system detects a threat (packet size=3D57) and needs to steer = all packets with size =3D 57 to Security Scrubbing Center. The next SFF se= lection can also be based on something else or in combination of Chain ID (= like traffic metrics, etc).=20 My point is that Chain ID is only to identify the Chain, but the selection = criteria can be based on various factors. =20 Linda From nobody Thu Jul 17 16:16: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 D913B1B283F for ; Thu, 17 Jul 2014 16:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jBfDFPyUCgtu for ; Thu, 17 Jul 2014 16:16:49 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E331B2818 for ; Thu, 17 Jul 2014 16:16:49 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 6061A53E33; Thu, 17 Jul 2014 16:16:46 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Thu, 17 Jul 2014 16:16:46.372 -0700 x-echoworx-msg-id: 43b28896-669a-4cb8-a7fc-8181bae42a79 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 735; Thu, 17 Jul 2014 16:16:46 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 410CB53E33; Thu, 17 Jul 2014 16:16:46 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Thu, 17 Jul 2014 16:16:49 -0700 From: Ron Parker To: Linda Dunbar , "Hongyu Li (Julio)" , "Joel M. Halpern" , Tom Taylor , "sfc@ietf.org" Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGcZviim+pzeokmGAZvO4foLopui2N0A///KZ5CAAro2gP//iwEQ Date: Thu, 17 Jul 2014 23:16:47 +0000 Message-ID: References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] x-source-routing-agent: Processed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/igRAMSER7m7dVJTnFEQ-NpsVZsM Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 23:16:51 -0000 Linda, I think that what you describe is more of a dynamic chain assignment. A p= articular chain either does or does not include a Service Function to perfo= rm Security Scrubbing Center. The ingress classifier may have taken your = packet size into account to choose an abstract chain that did, indeed, incl= ude your Security Scrubbing Center. But once selected and barring reclass= ification, the SFF's are obligated to respect the chain assignment selected= by the ingress classifier. Thus, the SFF's have freedom, with possible p= olicy constraints, to choose any instance of any particular service functio= n within the chain, but not to shift to a different chain that describes a = different sequence of service functions. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Thursday, July 17, 2014 7:12 PM To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; sfc@ietf.or= g Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? Ron,=20 You said: For a new flow, next SFF selection by an SFF SFF MUST be based on the ch= ain ID and MAY be based on metadata and/or locally known policy. Next SFI= selection by an SFF MUST be based on the chain ID and service function ind= ex within the chain and MAY be based on metadata and/or locally known polic= y. [Linda] "next SFI selection" criteria can even be based on packet size, lik= e an AntiDos system detects a threat (packet size=3D57) and needs to steer = all packets with size =3D 57 to Security Scrubbing Center. The next SFF se= lection can also be based on something else or in combination of Chain ID (= like traffic metrics, etc).=20 My point is that Chain ID is only to identify the Chain, but the selection = criteria can be based on various factors. =20 Linda From nobody Thu Jul 17 16:17: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 BFDCD1B2849 for ; Thu, 17 Jul 2014 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 3HeZbgtS1aGZ for ; Thu, 17 Jul 2014 16:17:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB5C1B2847 for ; Thu, 17 Jul 2014 16:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9062; q=dns/txt; s=iport; t=1405639039; x=1406848639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D+j4jlEJ9DB/AMGHupO/Vj9uLXXwmi1r9FvqwppYkbo=; b=etWGG0aMo+T8o8YHTZkq0YmxRYbVitn1y/MDdLk6fY7DonPvYOr4CaaD dceRXvEqoZMqblthYKYuous4lfs+8NMLJHmodW3p91uXFfjco83r42EYQ 2UssMqa2b1/tqv5Vx5MoKzaonYHBNH7bRUqLFl1rga3zVMby76Qc9QMlm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMVYyFOtJV2b/2dsb2JhbABPCoMOUlcExAEKh0MBgQkWdoQDAQEBAwEBAQELVwkLDAQCAQgRAQMBAQEnBycLFAMGCAIEAQ0FiDoIDcVSEwSJfoRxKS4FBwaEQAEEiiqMWoQblCyDRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,681,1400025600"; d="scan'208";a="340682000" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2014 23:17:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6HNHHVx007074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 23:17:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 18:17:16 -0500 From: "Jim Guichard (jguichar)" To: "Thomas D. Nadeau" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAWFqAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAGyK4A= Date: Thu, 17 Jul 2014 23:17:16 +0000 Message-ID: References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> In-Reply-To: <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.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.180] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <317725D68BF1254C977BD8E98FB4DDE3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CwETto-NqCM85xegNKZUKb-DHmw Cc: "sfc@ietf.org" , "He, Peng" , Ron Parker , Tom Taylor , "Joel M. Halpern" , "mohamed.boucadair@orange.com" Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 17 Jul 2014 23:17:21 -0000 Hi Thomas, I am not sure we will have time to fully discuss this during the face-to-face meeting as the agenda is already jam packed. Let=B9s continue the discussion on the list and see what Joel & Carlos are able to produce in terms of text and go from there. I would ask however that members of this WG that have not already commented on my email entitled =B3SFC Terminology / Concepts=B2 please do so so that we can better gauge consensu= s of the WG on this issue. On 7/16/14, 1:23 PM, "Thomas D. Nadeau" wrote: > > I have gotten a bit lost in the SFF/SFC discussion, which seems to have >gotten needlessly complicated and convoluted IMHO. > > Is it possible for the chairs to add this to the list of things to >discuss at the WG meeting or do we want to resolve this on the list ahead >of the meeting? > > --Tom > > >On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >wrote: > >> Hi Peng, >>=20 >>> -----Original Message----- >>> From: He, Peng [mailto:phe@ciena.com] >>> Sent: Tuesday, July 15, 2014 9:09 PM >>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: RE: [sfc] SFC Terminology / Concepts >>>=20 >>> Try to understand the three scenarios you listed: you mean the >>>classifier can >>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>SFF will >>> (locally) select one of the SF instances under itself for this SF. For >>>partial SFP case, >>=20 >> In either case, the SFF should be capable of selecting the appropriate >>instance of a given SF attached to itself. it's an internal >>load-balancing issue. >>=20 >>> each SFF will identify the SFI under itself and specify (like a >>>classifier) next SFF(s). >>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>from either >>> centralized point (e.g., PCE, controller), or, via a distributed >>>control plane? For >>> partial SFP, will there be a re-classification to decide next SFF(s) >>>or not? >>=20 >> If you want the SFF to locally determine the appropriate SFF for the >>next SF, the SFF should have the capability of resolving the SFF for the >>next SF based on certain constraints. Of course, it needs to know some >>information about the SFs in advance, e.g., the information about which >>SFFs a given SF is attached. >>=20 >> Best regards, >> Xiaohu >>=20 >>> Regards, >>> Peng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>> Sent: Tuesday, July 15, 2014 4:49 AM >>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>> sfc@ietf.org; Ron Parker >>> Subject: Re: [sfc] SFC Terminology / Concepts >>>=20 >>> Hi Med, >>>=20 >>> IMHO, the architecture should allow the classifier to specify >>>=20 >>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>locally determine >>> the appropriate SFF for the next SF); >>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>determined by >>> the centralized node); >>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>determine the >>> appropriate SFF for the next SF). >>>=20 >>> In fact, case 3) could be looked as an extreme of case 1). >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Hi Joel, >>>>=20 >>>> As mentioned in several messages, I'm personally for the use of the >>>> chain itself is the main information to be conveyed in packets to >>>>drive >>> forwarding actions. >>>>=20 >>>> I can understand that an identifier can be assigned to a path that is >>>> known in advance, but if that path is not known I'm not sure how an >>>> identifier can be assigned to it! >>>>=20 >>>> Joel, the use of "path" is really inappropriate to refer to >>>> distributed instance selection process for packets bound to a given >>>>SFC. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; sfc@ietf.org= ; >>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>=20 >>>>> The most likely realization of the architecture would be that the SFP >>>>> assignment is recorded in an identifier which travels with the >>>>>packet. >>>>>=20 >>>>> Some folks seem to not want the architecture to mandate that. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>=20 >>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>> Your text scares me because it introduces some new concepts and >>>>>> assumptions. >>>>>>=20 >>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>> am I right in seeing the implication that when control assigns an >>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>> with the >>>> packet? >>>>>>=20 >>>>>> Tom Taylor >>>>>>=20 >>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>text >>>>>>> with: >>>>>>>=20 >>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>> of the service functions to be invoked and the order in which they >>>>>>> are to be invoked for some particular flow or set of flows, without >>> concern of >>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>> SFC affecting the instance selection of one or more of the service >>> functions >>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>with >>>>> it." >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> Ron >>>>>> ... >>>>>>=20 >>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>> Allan I >>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> I like that text, it strikes a good balance where an >>>>>>> implementation has the option of making scale and resiliency a >>>>>>>local >>> matter.. >>>>>>>=20 >>>>>>> D >>>>>>>=20 >>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>> Guichard >>>>>>> (jguichar) >>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>> *To:* sfc@ietf.org >>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Dear WG: >>>>>>>=20 >>>>>>> There has been much debate over the last few days with regards to >>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>> and concepts used to describe the architecture in the merged >>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>=20 >>>>>>> "The SFP provides a level of indirection between the fully >>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>> delivered, and the fully specified notion of exactly what >>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>> the network. By allowing the control components to specify the use >>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>network." >>>>>>>=20 >>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>> the merged architecture draft. >>>>>>>=20 >>>>>>> Thank You, >>>>>>>=20 >>>>>>> Jim >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 Thu Jul 17 16:52: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 49C631B289A for ; Thu, 17 Jul 2014 16:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 X5MRTLnREWkF for ; Thu, 17 Jul 2014 16:52:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7391B288A for ; Thu, 17 Jul 2014 16:52:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH65947; Thu, 17 Jul 2014 23:52:44 +0000 (GMT) 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; Fri, 18 Jul 2014 00:52:43 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Thu, 17 Jul 2014 16:52:39 -0700 From: Linda Dunbar To: Ian Smith , Ron Parker Thread-Topic: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00 Thread-Index: AQHPoH7lGeOr8A7bbUm8JhoMq6uncJuk8JjA Date: Thu, 17 Jul 2014 23:52:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D9F404@dfweml701-chm.china.huawei.com> References: <53BCAB74.4060801@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933002F47A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1D70D757A2C9D54D83B4CBD7625FA80E01D42285@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BD9AC8.5080904@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D422DE@MISOUT7MSGUSRCF.ITServices.sbc.com> <53BDA558.1070701@joelhalpern.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4231E@MISOUT7MSGUSRCF.ITServices.sbc.com> <7270130A-0F3D-4382-930E-8B45B7970AFA@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D42351@MISOUT7MSGUSRCF.ITServices.sbc.com> <73BC1843-9166-40B6-A2C6-E1C4680171E6@cisco.com> <724FBB99-4DCB-4AD3-907E-B5CDDF59D6C2@cisco.com> <82BECD88-9441-4CA5-8F36-4B0CF4AFC86F@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A1A9@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B07115@eusaamb107.ericsson.se> <1D70D757A2C9D54D83B4CBD7625FA80E01D4A417@MISOUT7MSGUSRCF.ITServices.sbc.com> <48E1A67CB9CA044EADFEAB87D814BFF632B08B13@eusaamb107.ericsson.se>, <73000D2D-FDF1-45AD-AA39-6DD8D6B99822@gmail.com>, , <419417C345CA5F48BF45F0A23955A0634A83F17C@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A83F3F4@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9CFE0@dfweml701-chm.china.huawei.com> <419417C345CA5F48BF45F0A23955A0634A8436F5@SEAEMBX02.olympus.F5Net.com>, <4A95BA014132FF49AE685FAB4B9F17F645D9D29E@dfweml701-chm.china.huawei.com> <419417C345CA5F48BF45F0A23955A0634A843871@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A843871@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.170] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D9F404dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7CPZwIySCfXqDBr8XZLy-GyJ3pY Cc: Sharon , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Eric Gray Subject: Re: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-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: Thu, 17 Jul 2014 23:52:56 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D9F404dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian, You said: -- I think it would be more appropriate to leave the analogy at the actual = SNF or SFF nodes and not try and extend it into the abstract concepts of "w= hat is a service chain?" or "what is a path?". Are you saying that SFF or SNF can make local decision on what Service func= tions or instances to apply to a flow? i.e. the packets are identified (or = marked) by the Classifier node, and some SFF/SNF can be given a set of poli= cies on which Service Functions/instances are used to apply treatment for t= he identified flows? How you understand "Load Balancer" would impact whether you think it is or = is not a subset of SFF capabilities. If you do think of load balancing as = reasonably being part of a SFF, then it would be a decider. If you think o= f "a load balancer" as a service function that gets included in a chain, th= en it would be an actor. [Linda] Load Balancer is a loaded term. There are load balancer among clust= er of servers, or load balancer among set of links (e.g. ECMP). If SFC onl= y focuses on the "Decider" aspect, and leaves the "Actor" part out of the s= cope, everything will be easier. Linda I'll send comments on the draft separately. ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 6:24 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAP= IERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc= -fun-instances-restoration-00 Ian, Thank you very much for the clarification. So the "Actor" is the Service function internal processing, correct? Then the "Service Chains, Paths, and Load Balancers" in SFC context should = be all about the "Decider", correct? Since some service function instances are visible to Chain Classification = nodes and Service Chain orchestration system, some other times, it is a col= lection of Instances as one entity that is visible to the "Classification N= ode" or "Orchestration system". Therefore, some Chains have explicit information on which Service Function = instances to use; some Chains only have the information on which cluster of= instances to use; some chains have explicit information on which SFFs/SN n= odes to use; etc. http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00 is= the attempt to describe decisions by SFFs and SN. Any comments and suggest= ions? Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith Sent: Tuesday, July 15, 2014 1:32 PM To: Linda Dunbar; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAP= IERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Linda - "actor" is a generic way of talking about the part of a system that actuall= y _does_ the thing. In this context that means _a particular instance of a= service function_ "decider" is a generic way of talking about parts of the system that will m= ake decisions about which actor will be used. In this context it means a S= NF, SFF, or a control/policy plane decision engine _when they are selecting= SFIs_. I think of it as being three decisions: 1. the network - function selection (bridging and routing, anycast/multi= cast, tenant domain, etc.); 2. the service - function selection + service selection (policy route, l= abel switching, GSLB, virtual server destination (ip:port), traffic classif= ication, etc.); 3. the instance - function selection + service selection + instance sele= ction (LB pool member selection, DNS SRV & ENUM); ________________________________ From: Linda Dunbar [linda.dunbar@huawei.com] Sent: Tuesday, July 15, 2014 2:10 PM To: Ian Smith; Ron Parker Cc: Sharon; sfc@ietf.org; Jim Guichard (jguichar); NAP= IERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.com; Eric Gray Subject: RE: [sfc] Service Chains, Paths, and Load Balancers Ian, Try to clarify the terminology you used: Does "Selecting a decider" mean "selecting with SFFs"? Does "Selecting an actor" mean "the SFF that determine which local instance= s to use"? To me, there are two levels of decision: - Network level decision (which is pretty much same as today's rou= ter hops) - Node level decision (which local instance to use). Linda From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith But the actual point I was trying to make is that there is a consistent sem= antic difference between 'selecting a decider' which is what you do if you = make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an acto= r' which is what you do when you make a next hop selection amongst SFIs, an= d you should differentiate between them. On Jul 12, 2014 1:43 PM, Ron Parker > wrote: Ian, I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer. = It may reside on top of an IP-tunnel based overlay (i.e., commonly used def= inition of "SDN") or may reside directly on top of an L2 switched network o= r may reside directly on top of an L3 routed network or any combination of = those. Therefore, when a classifier selects an SFF or an SFF selects the= next SFF, or an SFF selects an SFI, it is doing so in the service overlay,= only. That is why I find it confusing to describe the selected SFF or SF= I as the "next-hop" because that term has such a strong L3 routing plane se= mantic. Ron From: Ian Smith [I.Smith@F5.com] Sent: Saturday, July 12, 2014 11:59 AM To: Ron Parker; Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org; NA= PIERALA, MARIA H Subject: RE: [sfc] Service Chains, Paths, and Load Balancers I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets) ________________________________________ From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Saturday, July 12, 2014 10:15 AM To: Sharon; Eric Gray Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com<= mailto:mohamed.boucadair@orange.com>; sfc@ietf.org; NA= PIERALA, MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Sharon, One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution. This gives us the hierarchical load balancing and resili= ency that has been discussed on the thread. For example, a chain has abst= ract service functions {A, B, C} and 2 distinct SFFs reach some number of A= instances, each, 2 distinct SFFs reach some number of B instances, each, e= tc. Let's further say that one of the SFF's that reaches instances of A = sees that the last of its A instances has gone down. The top-level load b= alancing must now avoid that SFF for purposes of invoking service function = A (i.e., with different procedures, potentially for existing flows vs new f= lows). Additionally, it may be beneficial for those SFF's to communicate = information back to the top level path selection logic (i.e., classifier) w= ith information that can be used for weighted load balancing. Ron ________________________________________ From: Sharon [sbarkai@gmail.com] Sent: Friday, July 11, 2014 9:35 PM To: Eric Gray Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@i= etf.org Subject: Re: [sfc] Service Chains, Paths, and Load Balancers Looks like it's almost there, no? If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system: - classify and map the flow to the right subscriber-serviceChain - map the chain links to the SFFs signed up to execute an SF hop - carry the context and work flow as meta data between SFFs Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed. The way I read the docs it's almost there. --szb > On Jul 11, 2014, at 12:27 PM, Eric Gray > wrote: > > Maria, > > So many fundamental problems. What to do? > > I didn't suggest "leaving it to implementation." I merely suggested that= each IETF > working group needs to focus on a set of problems they can solve in a rea= sonable > amount of time, without having to boil any oceans. > > Joel suggested an architectural approach that would allow any form of dis= tribution > you might want, without requiring every solution to support all possibili= ties, and > without impacting the ability of solutions to be optimized for whatever d= eployment > scenario may apply in any specific case. > > Working out ways to optimize your particular deployment model seems to be= your > problem (with support from your suppliers - whoever they might be) and - = it seems > to me - the burden of making sure that the standards we define allows opt= imization > for that deployment falls on you (and them). > > Meanwhile, other providers and other vendors may seek to ensure that what= ever > we define allows at least some degree of optimization for their deploymen= ts. > > This is the process. > > Is the architectural proposal Joel came up with sufficient as a starting = point? > > -- > Eric > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:mn1921@att.com] > Sent: Thursday, July 10, 2014 12:29 PM > To: Eric Gray; Jim Guichard (jguichar); Ron Parker > Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > Subject: RE: [sfc] Service Chains, Paths, and Load Balancers > Importance: High > > Eric, > >> Load distribution is not the same as service function chaining and - >> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them? > > Because this is the fundamental problem in service chaining in virtualize= d environments. > I would be cautious to leave it just to implementation because if fundame= ntals are wrong implementation might not be able to help. > >> I think SFC should be more concerned about ensuring that function >> chaining solutions do not preclude load distribution. > > How would you ensure it? > >> >> -- >> Eric >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA >> H >> Sent: Thursday, July 10, 2014 12:02 PM >> To: Jim Guichard (jguichar); Ron Parker >> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >> >> One of the main problems in "service chains" is how to implement a >> service that is conceptually one hop but scaled horizontally as 10 or >> 100 different VMs. >> So, IMO, if we are not addressing this problem than what are we solving. >> >> Maria >> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Wednesday, July 09, 2014 6:17 PM >>> To: Ron Parker >>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA, >> MARIA H; >>> sfc@ietf.org >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>> >>> I should clarify that my statement was made as a personal opinion >>> and it is up to the WG to evaluate if there exists anything at the >>> architectural level that is new and therefore needs to be addressed. >>> >>> Sent from my iPhone >>> >>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker" >>>> > wrote: >>>> >>>> Jim, >>>> >>>> Respectfully, I'm not comfortable with that. While it is easy to say= that >>> this is a layered problem and that load balancing belongs at a lower >>> level, it seems to me that load balancing of the service functions >>> (not load balancer as a service function) should be an explicit >> consideration of the SFC >>> architecture. I say this not only from a scale perspective, but also= with >>> resiliency in mind. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>> Sent: Wednesday, July 09, 2014 5:48 PM >>>> To: Ron Parker >>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; >>> NAPIERALA, MARIA H >>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>> >>>> I would say that's implementation. >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker" >>> > wrote: >>>>> >>>>> Agreed. But is that in scope for SFC or out of scope for SFC? >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>> Sent: Wednesday, July 09, 2014 5:29 PM >>>>> To: Ron Parker >>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern; >>> mohamed.boucadair@orange.com; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>> >>>>> Well of course not; in that case you load balance up a level >>>>> between >>> those nodes and then locally. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker" >>> > wrote: >>>>>> >>>>>> Jim, >>>>>> >>>>>> There may not be a single node through which all of the >>>>>> instances can >>> be reached (at some reasonable limit of L2 or L3 hops). >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim >>>>>> Guichard >>>>>> (jguichar) >>>>>> Sent: Wednesday, July 09, 2014 5:12 PM >>>>>> To: NAPIERALA, MARIA H >>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>> >>>>>> At the node through which the 20 instances are reachable. IOW >>>>>> you >>> don't have to individually address packets to each and every instance. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" >>> > wrote: >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> When you say "locally", where is it? >>>>>>> >>>>>>> Maria >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM >>>>>>>> To: NAPIERALA, MARIA H >>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; >> sfc@ietf.org >>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>>>>>> >>>>>>>> Hi Maria, >>>>>>>> >>>>>>>> Absolutely and categorically no! If you have 20 instances at >>>>>>>> each hop then you can choose to load balance among them >>>>>>>> locally resulting in exactly 4 paths. What Joel is saying is >>>>>>>> that if for some very odd and certainly not recommended reason >>>>>>>> you want to treat each instance separately then the >>>>>>>> architecture does not >>> prevent it. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H" >>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> I am saying that if the 20 virtual firewalls are deployed >>>>>>>>>> separately, then the service chaining infrastructure would >>>>>>>>>> treat them as such, and would use distinct service paths. >>>>>>>>> >>>>>>>>> If I have a 4 hop service chain with 20 instances at each >>>>>>>>> hop, then I have >>>>>>>> to globally manage 160,000 service paths (for one chain)? >>>>>>>> Well, we have yet to see a solution that work this way and scales.= . >>>>>>>>> >>>>>>>>> Maria >>>>>>>>> >>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>> I had in mind singular instances, say, 20 virtual firewall >>>>>>>>>>> instances >>>>>>>>>> somewhere in the middle of a chain. Are you saying that you >>>>>>>>>> will decide (make a load balancing decision) at the entry to >>>>>>>>>> the chain which of those >>>>>>>> 20 >>>>>>>>>> firewalls will be used by a particular flow? >>>>>>>>>>> >>>>>>>>>>> Maria >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel >>>>>>>>>>>> Halpern >>>>>>>> Direct >>>>>>>>>>>> Sent: Wednesday, July 09, 2014 3:41 PM >>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com; >>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load >>>>>>>>>>>> Balancers >>>>>>>>>>>> >>>>>>>>>>>> The archtiecture allows for this local decision, while >>>>>>>>>>>> still having the global decision that is directing the traffic= . >>>>>>>>>>>> That is, the global decision directs the traffic to places >>>>>>>>>>>> in the network. Those places may be singular or clusters. >>>>>>>>>>>> If they are clusters, those clusters can use any number of >>>>>>>>>>>> algorithms to distribute the traffic internally, without >>>>>>>>>>>> any effect on service chaining. (And yes, this can be >>>>>>>>>>>> done in such a way that return traffic, if delivered >>>>>>>>>>>> globally to the same place, can then be delivered to the >>>>>>>>>>>> right internal >>>>>>>>>>>> state.) >>>>>>>>>>>> >>>>>>>>>>>> The definition of the service path is about how service >>>>>>>>>>>> chaining will direct the traffic. it is not about how the >>>>>>>>>>>> internal load balancing is doen, as there are MANY ways to >>>>>>>>>>>> do that, and they can give the same external interface. >>>>>>>>>>>> >>>>>>>>>>>> We could write the architecture pretending that it always >>>>>>>>>>>> addresses singular instances, but knowing that reality >>>>>>>>>>>> would allow load balanced clusters at those locations. >>>>>>>>>>>> But that would be a misleading architectural description >>>>>>>>>>>> and might be read to outlaw some solutions that fall >>>>>>>>>>>> within the goal the WG >>> wishes to meet. >>>>>>>>>>>> >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIERALA, MARIA H wrote: >>>>>>>>>>>>>> [Med] I still disagree that an ordered list of locators >>>>>>>>>>>>>> can be >>>>>>>>>> determined >>>>>>>>>>>> in >>>>>>>>>>>>>> advance for all deployments. I suggest that SFC >>>>>>>>>>>>>> forwarding be based >>>>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>> service chain itself (characterized as an order list of >>>>>>>>>>>>>> service function identifiers). This is more compliant >>>>>>>>>>>>>> with the >>> LB constraints above: >>>>>>>>>>>> deciding >>>>>>>>>>>>>> which locator to use for a given flow will be a local >>>>>>>>>>>>>> decision not a centralized one. >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely. I cannot imagine how else it can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> Maria >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> sfc mailing list >>>>>>>>>>>> sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list >>>>>>>>>>> sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_4A95BA014132FF49AE685FAB4B9F17F645D9F404dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ian,

 

You said:=

 <= /p>

-- I think it would be more appropriate to le= ave the analogy at the actual SNF or SFF nodes and not try and extend it in= to the abstract concepts of "what is a service chain?" or "what is a path?". 

Are you saying that SFF or SNF can make local decision on what Service = functions or instances to apply to a flow? i.e. the packets are identified (or marked) by the Classifier node, and some SFF/SNF can be= given a set of policies on which Service Functions/instances are used to a= pply treatment for the identified flows?

 

How you understand "Load Balancer" would impact whether you= think it is or is not a subset of SFF capabilities.  If you do think of load balancing as reasonably being part of a SFF, then it would be a de= cider.  If you think of "a load balancer" as a service funct= ion that gets included in a chain, then it would be an actor.

 

[Linda] Load Balancer is a loaded term. There are load balancer among c= luster of servers, or load balancer among set of links  (e.g. ECMP). If SFC only focuses on the “Decider” aspect, and leaves= the “Actor” part out of the scope, everything will be easier.

Linda




I'll send comments on the draft separately.<= o:p>

From: Linda Dunbar [linda.dunbar@h= uawei.com]
Sent: Tuesday, July 15, 2014 6:24 PM
To: Ian Smith; Ron Parker
Cc: Sharon; sfc@ietf.org; Jim Gu= ichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.co= m; Eric Gray
Subject: [sfc] Service Chains, Paths, and Load Balancers & draft= -dunbar-sfc-fun-instances-restoration-00

Ian,

 

Thank you very much for t= he clarification.

So the “Actor”= ; is the Service function internal processing, correct?

 

Then the “Service C= hains, Paths, and Load Balancers” in SFC context should be all about = the  “Decider”, correct?

 

Since some  service = function instances are visible to Chain Classification nodes and Service Ch= ain orchestration system, some other times, it is a collection of Instances as one entity that is visible to the “Classification No= de” or “Orchestration system”.

 

Therefore, some Chains ha= ve explicit information on which Service Function instances to use; some Ch= ains only have the information on which cluster of instances to use; some chains have explicit information on which SFFs/SN nodes to us= e; etc.

 

http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00= is the attempt to describe decisions by SFFs and SN. Any comments and sugg= estions?

 

 

Linda

 

 

 

 

From: sfc [mailto:sfc-bou= nces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, July 15, 2014 1:32 PM
To: Linda Dunbar; Ron Parker
Cc: Sharon; sfc@ietf.org; Jim Gu= ichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; mohamed.boucadair@orange.co= m; Eric Gray
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

 =

Linda -

"actor" is a generic way of talking about the part of a system th= at actually _does_ the thing.  In this context that means _a particula= r instance of a service function_
"decider" is a generic way of talking about parts of the system t= hat will make decisions about which actor will be used.  In this conte= xt it means a SNF, SFF, or a control/policy plane decision engine _when the= y are selecting SFIs_. 

I think of it as being three decisions:<= o:p>

  1. the network - function selection (bridging and routing, anycast/mult= icast, tenant domain, etc.);
  2. the service - function selection + servic= e selection (policy route, label switching, GSLB, virtual server destinatio= n (ip:port), traffic classification, etc.);
  3. the instance -= function selection + service selection + instance selection (LB po= ol member selection, DNS SRV & ENUM);

 

 

 

From: Linda Dunbar [linda.dunbar@h= uawei.com]
Sent: Tuesday, July 15, 2014 2:10 PM
To: Ian Smith; Ron Parker
Cc: Sharon; sfc@ie= tf.org; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; mohamed.b= oucadair@orange.com; Eric Gray
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers<= span style=3D"color:black">

Ian,

 

Try to clarify the termin= ology you used:

 

Does “Selecting a d= ecider” mean “selecting with SFFs”?

Does “Selecting an = actor” mean “the SFF that determine which local instances to us= e”?

 

To me, there are two leve= ls of decision:

- &nbs= p;        Network level decision (which is pretty m= uch same as today’s router hops)

- &nbs= p;        Node level decision (which local instance= to use).

 

Linda

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ian Smith=

But the actual point I was trying to make is= that there is a consistent semantic difference between 'selecting a decide= r' which is what you do if you make a next- hop selection amongst SNFs and/= or SFFs, and 'selecting an actor' which is what you do when you make a next hop selection amongst SFIs, and = you should differentiate between them.

On Jul 12, 2014 1:43 PM,= Ron Parker <Ron_Parker@affirmednetworks.com> wrote:

Ian,
I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.&nbs= p;   It may reside on top of an IP-tunnel based overlay (i.e., co= mmonly used definition of "SDN") or may reside directly on top of= an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Theref= ore, when a classifier selects an SFF or an SFF selects the next SFF, or an= SFF selects an SFI, it is doing so in the service overlay, only. &nbs= p; That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong= L3 routing plane semantic.

    Ron



From: Ian Smith [I.Smith@F5.com]
Sent: Saturday, July 12, 2014 11:59 AM
To: Ron Parker; Sharon; Eric Gray
Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA, MARIA H
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

I'd call the distinction you are making that between infrastructure load ba= lancing (where SFFs or SNFs are the LB targets) and instance load balancing= (where SFIs are the LB targets)


________________________________________
From: sfc [sfc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com]
Sent: Saturday, July 12, 2014 10:15 AM
To: Sharon; Eric Gray
Cc: Jim Guichard (jguichar); Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org; NAPIERALA, MARIA H
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sharon,

One more item I'd add -- load balance amongst the SFFs in an overall hierar= chical solution.   This gives us the hierarchical load balancing = and resiliency that has been discussed on the thread.   For examp= le, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFF= s reach some number of B instances, each, etc.    Let's furt= her say that one of the SFF's that reaches instances of A sees that the las= t of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service fu= nction A (i.e., with different procedures, potentially for existing flows v= s new flows).   Additionally, it may be beneficial for those SFF'= s to communicate information back to the top level path selection logic (i.e., classifier) with information that can be= used for weighted load balancing.

   Ron

________________________________________
From: Sharon [sbarkai@gmail.com]
Sent: Friday, July 11, 2014 9:35 PM
To: Eric Gray
Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halper= n; mohamed.boucadair@orange.com; sfc@ietf.org
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Looks like it's almost there, no?

If each SFF behaves like a typical load-balancer for the SFs it aggregates,= then all is left is for the architecture to emerge these SFFs as one distr= ibuted system:

- classify and map the flow to the right subscriber-serviceChain

- map the chain links to the SFFs signed up to execute an SF hop

- carry the context and work flow  as meta data between SFFs

Such a system unbundles proprietary service nodes for virtualized environme= nts both in terms of capacity and in term of the functional procedures. No = centralized static setup needed.

The way I read the docs it's almost there.

--szb

> On Jul 11, 2014, at 12:27 PM, Eric Gray <eric.gray@ericsson.com> wrote:
>
> Maria,
>
> So many fundamental problems.  What to do?
>
> I didn't suggest "leaving it to implementation."  I mer= ely suggested that each IETF
> working group needs to focus on a set of problems they can solve in a = reasonable
> amount of time, without having to boil any oceans.
>
> Joel suggested an architectural approach that would allow any form of = distribution
> you might want, without requiring every solution to support all possib= ilities, and
> without impacting the ability of solutions to be optimized for whateve= r deployment
> scenario may apply in any specific case.
>
> Working out ways to optimize your particular deployment model seems to= be your
> problem (with support from your suppliers - whoever they might be) and= - it seems
> to me - the burden of making sure that the standards we define allows = optimization
> for that deployment falls on you (and them).
>
> Meanwhile, other providers and other vendors may seek to ensure that w= hatever
> we define allows at least some degree of optimization for their deploy= ments.
>
> This is the process.
>
> Is the architectural proposal Joel came up with sufficient as a starti= ng point?
>
> --
> Eric
>
> -----Original Message-----
> From: NAPIERALA, MARIA H [mailto:mn1921@att.com]
> Sent: Thursday, July 10, 2014 12:29 PM
> To: Eric Gray; Jim Guichard (jguichar); Ron Parker
> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers
> Importance: High
>
> Eric,
>
>> Load distribution is not the same as service function chaining and= -
>> while there may be problems to solve in this area - why would we >> assume that SFC is supposed to solve them?
>
> Because this is the fundamental problem in service chaining in virtual= ized environments.
> I would be cautious to leave it just to implementation because if fund= amentals are wrong implementation might not be able to help.
>
>> I think SFC should be more concerned about ensuring that function<= br> >> chaining solutions do not preclude load distribution.
>
> How would you ensure it?
>
>>
>> --
>> Eric
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of NAPIERALA, MARIA
>> H
>> Sent: Thursday, July 10, 2014 12:02 PM
>> To: Jim Guichard (jguichar); Ron Parker
>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
>>
>> One of the main problems in "service chains" is how to i= mplement a
>> service that is conceptually one hop but scaled horizontally as 10= or
>> 100 different VMs.
>> So, IMO, if we are not addressing this problem than what are we so= lving.
>>
>> Maria
>>
>>> -----Original Message-----
>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>> Sent: Wednesday, July 09, 2014 6:17 PM
>>> To: Ron Parker
>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; NAPIERALA,
>> MARIA H;
>>> sfc@ietf.org=
>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers >>>
>>> I should clarify that my statement was made as a personal opin= ion
>>> and it is up to the WG to evaluate if there exists anything at= the
>>> architectural level that is new and therefore needs to be addr= essed.
>>>
>>> Sent from my iPhone
>>>
>>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"
>>>> <Ron_Parker@affirmednetworks.com> wrote:
>>>>
>>>> Jim,
>>>>
>>>> Respectfully, I'm not comfortable with that.   W= hile it is easy to say that
>>> this is a layered problem and that load balancing belongs at a= lower
>>> level, it seems to me that load balancing of the service funct= ions
>>> (not load balancer as a service function) should be an explici= t
>> consideration of the SFC
>>> architecture.    I say this not only from a sca= le perspective, but also with
>>> resiliency in mind.
>>>>
>>>>  Ron
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>> Sent: Wednesday, July 09, 2014 5:48 PM
>>>> To: Ron Parker
>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org;
>>> NAPIERALA, MARIA H
>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balance= rs
>>>>
>>>> I would say that's implementation.
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"
>>> <Ron_Parker@affirmednetworks.com> wrote:
>>>>>
>>>>> Agreed.   But is that in scope for SFC or ou= t of scope for SFC?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]
>>>>> Sent: Wednesday, July 09, 2014 5:29 PM
>>>>> To: Ron Parker
>>>>> Cc: NAPIERALA, MARIA H; Joel M. Halpern;
>>> mohamed.boucadair@orange.com;
>>>>> sfc@= ietf.org
>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Bal= ancers
>>>>>
>>>>> Well of course not; in that case you load balance up a= level
>>>>> between
>>> those nodes and then locally.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"=
>>> <Ron_Parker@affirmednetworks.com> wrote:
>>>>>>
>>>>>> Jim,
>>>>>>
>>>>>> There may not be a single node through which all o= f the
>>>>>> instances can
>>> be reached (at some reasonable limit of L2 or L3 hops).
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim
>>>>>> Guichard
>>>>>> (jguichar)
>>>>>> Sent: Wednesday, July 09, 2014 5:12 PM
>>>>>> To: NAPIERALA, MARIA H
>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load= Balancers
>>>>>>
>>>>>> At the node through which the 20 instances are rea= chable. IOW
>>>>>> you
>>> don't have to individually address packets to each and every i= nstance.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, M= ARIA H"
>>> <mn1921= @att.com> wrote:
>>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> When you say "locally", where is it?=
>>>>>>>
>>>>>>> Maria
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=
>>>>>>>> Sent: Wednesday, July 09, 2014 5:06 PM
>>>>>>>> To: NAPIERALA, MARIA H
>>>>>>>> Cc: Joel M. Halpern; mohamed.boucadair@orange.com;
>> sfc@ietf.org=
>>>>>>>> Subject: Re: [sfc] Service Chains, Paths, = and Load Balancers
>>>>>>>>
>>>>>>>> Hi Maria,
>>>>>>>>
>>>>>>>> Absolutely and categorically no! If you ha= ve 20 instances at
>>>>>>>> each hop then you can choose to load balan= ce among them
>>>>>>>> locally resulting in exactly 4 paths. What= Joel is saying is
>>>>>>>> that if for some very odd and certainly no= t recommended reason
>>>>>>>> you want to treat each instance separately= then the
>>>>>>>> architecture does not
>>> prevent it.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERAL= A, MARIA H"
>>> <mn1921= @att.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>> I am saying that if the 20 virtual= firewalls are deployed
>>>>>>>>>> separately, then the service chain= ing infrastructure would
>>>>>>>>>> treat them as such, and would use = distinct service paths.
>>>>>>>>>
>>>>>>>>> If I have a 4 hop service chain with 2= 0 instances at each
>>>>>>>>> hop, then I have
>>>>>>>> to globally manage 160,000 service paths (= for one chain)?
>>>>>>>> Well, we have yet to see a solution that w= ork this way and scales..
>>>>>>>>>
>>>>>>>>> Maria
>>>>>>>>>
>>>>>>>>>>> On 7/9/14, 4:00 PM, NAPIERALA,= MARIA H wrote:
>>>>>>>>>>> I had in mind singular instanc= es, say, 20 virtual firewall
>>>>>>>>>>> instances
>>>>>>>>>> somewhere in the middle of a chain= . Are you saying that you
>>>>>>>>>> will decide (make a load balancing= decision) at the entry to
>>>>>>>>>> the chain which of those
>>>>>>>> 20
>>>>>>>>>> firewalls will be used by a partic= ular flow?
>>>>>>>>>>>
>>>>>>>>>>> Maria
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----=
>>>>>>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org]= On Behalf Of Joel
>>>>>>>>>>>> Halpern
>>>>>>>> Direct
>>>>>>>>>>>> Sent: Wednesday, July 09, = 2014 3:41 PM
>>>>>>>>>>>> To: NAPIERALA, MARIA H; mohamed.boucadair@orange.com;
>>>>>>>>>> sfc@ietf.org
>>>>>>>>>>>> Subject: Re: [sfc] Service= Chains, Paths, and Load
>>>>>>>>>>>> Balancers
>>>>>>>>>>>>
>>>>>>>>>>>> The archtiecture allows fo= r this local decision, while
>>>>>>>>>>>> still having the global de= cision that is directing the traffic.
>>>>>>>>>>>> That is, the global decisi= on directs the traffic to places
>>>>>>>>>>>> in the network.  Thos= e places may be singular or clusters.
>>>>>>>>>>>> If they are clusters, thos= e clusters can use any number of
>>>>>>>>>>>> algorithms to distribute t= he traffic internally, without
>>>>>>>>>>>> any effect on service chai= ning.  (And yes, this can be
>>>>>>>>>>>> done in such a way that re= turn traffic, if delivered
>>>>>>>>>>>> globally to the same place= , can then be delivered to the
>>>>>>>>>>>> right internal
>>>>>>>>>>>> state.)
>>>>>>>>>>>>
>>>>>>>>>>>> The definition of the serv= ice path is about how service
>>>>>>>>>>>> chaining will direct the t= raffic.  it is not about how the
>>>>>>>>>>>> internal load balancing is= doen, as there are MANY ways to
>>>>>>>>>>>> do that, and they can give= the same external interface.
>>>>>>>>>>>>
>>>>>>>>>>>> We could write the archite= cture pretending that it always
>>>>>>>>>>>> addresses singular instanc= es, but knowing that reality
>>>>>>>>>>>> would allow load balanced = clusters at those locations.
>>>>>>>>>>>> But that would be a mislea= ding architectural description
>>>>>>>>>>>> and might be read to outla= w some solutions that fall
>>>>>>>>>>>> within the goal the WG
>>> wishes to meet.
>>>>>>>>>>>>
>>>>>>>>>>>> Yours,
>>>>>>>>>>>> Joel
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/9/14, 3:06 PM, NAPIER= ALA, MARIA H wrote:
>>>>>>>>>>>>>> [Med] I still disa= gree that an ordered list of locators
>>>>>>>>>>>>>> can be
>>>>>>>>>> determined
>>>>>>>>>>>> in
>>>>>>>>>>>>>> advance for all de= ployments. I suggest that SFC
>>>>>>>>>>>>>> forwarding be base= d
>>>>>>>>>> on
>>>>>>>>>>>> the
>>>>>>>>>>>>>> service chain itse= lf (characterized as an order list of
>>>>>>>>>>>>>> service function i= dentifiers). This is more compliant
>>>>>>>>>>>>>> with the
>>> LB constraints above:
>>>>>>>>>>>> deciding
>>>>>>>>>>>>>> which locator to u= se for a given flow will be a local
>>>>>>>>>>>>>> decision not a cen= tralized one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Absolutely. I cannot i= magine how else it can be done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maria
>>>>>>>>>>>>
>>>>>>>>>>>> __________________________= _____________________
>>>>>>>>>>>> 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 mailing list
>>>>>>>>> sfc@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc=
>>>>>>
>>>>>> _______________________________________________ >>>>>> sfc mailing list
>>>>>> = sfc@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>
>>>>> _______________________________________________
>>>>> sfc mailing list
>>>>> sfc@= ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf= .org
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org=
>> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

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

--_000_4A95BA014132FF49AE685FAB4B9F17F645D9F404dfweml701chmchi_-- From nobody Thu Jul 17 18:59: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 451DF1A03A9; Thu, 17 Jul 2014 18:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 9SkSv6TXLqXK; Thu, 17 Jul 2014 18:59:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031BC1A01BA; Thu, 17 Jul 2014 18:59:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH71716; Fri, 18 Jul 2014 01:58:59 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 02:58:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 09:58:52 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPw== Date: Fri, 18 Jul 2014 01:58:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/b5CuxgdCaRVTqaGcIwDh1tnwEDs Cc: "" , "sfc@ietf.org" Subject: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 01:59:03 -0000 Hi all, I'm now considering how to carry metadata/context in an MPLS packet. I just= noticed that draft-guichard-mpls-metadata-00 (http://tools.ietf.org/html/d= raft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/con= text in an MPLS packet (see below): "3. Metadata Channel Header Format The presence of metadata within an MPLS packet must be indicated in the encapsulation. This document defines that the G-ACh Generic Associated Channel Label (GAL) [RFC5586] with label value 13 is utilized for this purpose. The GAL label provides a method to identify that a packet contains an "Associated Channel Header (ACH)" followed by a non-service payload. [RFC5586] identifies the G-ACh Generic Associated Channel by setting the first nibble of the ACH that immediately follows the bottom label in the stack if the GAL label is present, to 0001b. Further [RFC5586] expects that the ACH not be used to carry user data traffic. This document proposes an extension to allow the first nibble of the ACH to be set to 0000b and, when following the GAL, be interpreted using the semantics defined in [I-D.guichard-metadata-header] to allow metadata to be carried through the G-ACh channel." However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]: " The GAL MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, when present, the GAL MUST NOT appear more than once in the label stack." I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a Proto= col Type (PT) field immediately after the bottom of the MPLS label stack. W= ith such PT field, any kind of future MPLS payload (e.g., metadata header o= r NSH) can be easily identified. Best regards, Xiaohu From nobody Thu Jul 17 19:24: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 D0F3D1B27C9 for ; Thu, 17 Jul 2014 19:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pwhK6pg3FBhh for ; Thu, 17 Jul 2014 19:24:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB511B280A for ; Thu, 17 Jul 2014 19:24:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH73002; Fri, 18 Jul 2014 02:24:17 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 03:24:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 10:24:10 +0800 From: Xuxiaohu To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Tom Taylor , "sfc@ietf.org" , Ron Parker Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcIABADUAgACaNiCAAMWuAIAB1/RQ Date: Fri, 18 Jul 2014 02:24:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294147@NKGEML512-MBS.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082937A9@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B93300351AB@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300351AB@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="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/ndxb9XgFbf5qnYVriwN6csg-Ggw Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 02:24:22 -0000 Hi Med, > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, July 17, 2014 1:53 PM > To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > Subject: RE: [sfc] SFC Terminology / Concepts >=20 > Hi Xiaohu, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mercredi 16 ju= illet > >2014 12:15 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylo= r; > >sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology / Concepts > > > >Hi Med, > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > >> [mailto:mohamed.boucadair@orange.com] > >> Sent: Wednesday, July 16, 2014 4:54 PM > >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker > >> Subject: RE: [sfc] SFC Terminology / Concepts > >> > >> Hi Xiaohu, > >> > >> Please see inline. > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 ju= illet > >> >2014 11:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom > >> >Taylor; sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminology = / > >> >Concepts > >> > > >> >Hi Med, > >> > > >> >> -----Original Message----- > >> >> From: mohamed.boucadair@orange.com > >> >> [mailto:mohamed.boucadair@orange.com] > >> >> Sent: Tuesday, July 15, 2014 5:35 PM > >> >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron > >> >> Parker > >> >> Subject: RE: [sfc] SFC Terminology / Concepts > >> >> > >> >> Hi Xiaohu, > >> >> > >> >> Why a classifier will need specify a path a la ERO? Why it needs > >> >> to have > >> >the full > >> > > >> >In this way, the path selection process (i.e., selecting the > >> >appropriate SFF for the next SF based on certain constraints) on the > >> >SFF is greatly simplified. > >> > >> [Med] This does not answer to my question why the "classifier" has > >specifically > >> to take care of this? How multiple classifiers present in a given > >> SFC- > >enabled > >> domain behave in order to distribute traffic among available Service > >Function > >> Nodes? How a classifier can distribute traffic without any conflict > >> with > >other LBs > >> that may be present in the forwarding path? > >> >=20 > [Med] It seems you missed this one. As I has mentioned before, once the SFP is determined by the classifier in = advance, there is no need for subsequent SFFs to do complex path selection = work anymore (e.g., no need to maintain the SF->SFF mapping table and no ne= ed to resolve the appropriate SFF for the next SF on basis on certain const= raints). Of course, in order to optimize the traffic forwarding path (i.e.,= the SFP), a stateful PCE could be used to do the path computation work. By= the way, in the distributed and dynamic SFP selection process (i.e., each = SFF independently determine the appropriate SFF for the next SF), how to en= sure that optimization of the traffic forwarding path? > >> >> knowledge of the involved SF instances? Wouldn't this require the > >> >classifier to > >> >> be fed with additional information to drive its selection process? > >> >> Is > >> >this > >> > > >> >The classifier could request the PCE to do the SFP computation (see > >> >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there > >> >is no need for the classifier to be fed with additional information. > >> > >> [Med] Functionally, the classifier will need a path computation > >component. > >> Whether these two are co-located or separated is implementation-specif= ic. > >My > >> concern is to require that path computation component as a mandatory > >> component for the architecture. I think this is not justified. > > > >If the SFP computation is performed by the PCE, the classifier just > >needs to accept the computation result returned by the PCE and then > >impose the SFP info on the selected packets. In other words, the > >classifier doesn't need that SFP computation component anymore. > >Furthermore, if the classifier is just allowed to impose the SFC info > >on the selected packet, it doesn't need the SFP computation component as > well. >=20 > [Med] But still, for the sake of interoperability, the classifier need to= be prepared > for such interface with an external PCE module, no? Yes, the classifier should act as a PCC. > >> >> complexity justified for all deployments? > >> > > >> >As I have said, the architecture should allow the classifier to just > >> >impose the SFC information on the selected packet as well. In this > >> >way, each SFF needs to resolve the appropriate next SFF for the next > >> >SF to be > >> executed. > >> > >> [Med] Yes, I understood that from you initial list. My question is > >> how to > >package > >> all this together without imposing complexity to deployments that do > >> not require it. > > > >Since architecture allows three options, operators could make their own > >choices accordingly. >=20 > [Med] The problem is that packaging a lot of optional features will have = an > impact on the overall complexity of the solution. This is why I'm questio= ning > having any possible feature as an optional part of the solution. How about listing those three options in the architecture draft and saying = that either is applicable in some cases. Best regards, Xiaohu=20 From nobody Thu Jul 17 20: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 6EFAB1B286B; Thu, 17 Jul 2014 20:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zfwJrI66UM8C; Thu, 17 Jul 2014 20:17:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBE31A0495; Thu, 17 Jul 2014 20:17:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH76308; Fri, 18 Jul 2014 03:17:55 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 04:17:54 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 11:17:51 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoA= Date: Fri, 18 Jul 2014 03:17:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk> In-Reply-To: <1405653056176.39234@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CPHe8rxmUtf2b60iV_3s4lxpLcE Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:17:59 -0000 The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know. Best regards, Xiaohu > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Friday, July 18, 2014 11:11 AM > To: Xuxiaohu; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > How? A better question is "why?" >=20 > What has to be done in MPLS that cannot be done outside it? >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: mpls on behalf of Xuxiaohu > > Sent: Friday, 18 July 2014 11:58 AM > To: mpls@ietf.org > Cc: ; sfc@ietf.org > Subject: [mpls] How to carry metadata/context in an MPLS packet >=20 > Hi all, >=20 > I'm now considering how to carry metadata/context in an MPLS packet. I ju= st > noticed that draft-guichard-mpls-metadata-00 > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propo= ses > a way to carry metadata/context in an MPLS packet (see below): >=20 > "3. Metadata Channel Header Format >=20 > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. >=20 > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." >=20 > However, it seems that the special usage of the GAL as mentioned above st= ill > conflicts with the following statement quoted from [RFC5586]: >=20 > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." >=20 > I wonder whether the special usage of the GAL as proposed in the above dr= aft > would result in any backward compatibility issue. In addition, I wonder w= hether > it's worthwhile to reconsider the possibility of introducing a Protocol T= ype (PT) > field immediately after the bottom of the MPLS label stack. With such PT = field, > any kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily > identified. >=20 > Best regards, > Xiaohu >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 17 23:33: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 C198D1B28FC; Thu, 17 Jul 2014 23:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 JbBcOU5Ffr7q; Thu, 17 Jul 2014 23:33:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374361B28F9; Thu, 17 Jul 2014 23:33:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH87825; Fri, 18 Jul 2014 06:33:17 +0000 (GMT) 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, 18 Jul 2014 07:33:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 14:33:10 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVwAGdgOQ Date: Fri, 18 Jul 2014 06:33:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941BF@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> In-Reply-To: <1405653745773.33083@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ytHsRBYXUXEhOTpzTAK-1svxi4g Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:33:23 -0000 > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Friday, July 18, 2014 11:22 AM > To: Xuxiaohu; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > No, my "why" is "why have metadata in the MPLS header at all"? You could choose to carry the metadata context instead of the metadata itse= lf in the data packet (See section 3.5 of the following draft (http://tools= .ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8)). > Why does this have to be done inband? It doesn't have to be done inband. However, since In-band marking (see sect= ion 3.1 of the following draft (http://tools.ietf.org/html/draft-rijsman-sf= c-metadata-considerations-00#page-8)) ) is one of the approaches of metadat= a sharing, I'm just considering how to realize that in-band approach in the= MPLS case. Best regards, Xiaohu > I am questioning the basis for doing this. There is no "must" here. >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu > Sent: Friday, 18 July 2014 1:17 PM > To: Wood L Dr (Electronic Eng); mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > The presence of metadata within an MPLS packet must be indicated in the > encapsulation. I think that's the "why" you may want to know. >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:11 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > How? A better question is "why?" > > > > What has to be done in MPLS that cannot be done outside it? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls on behalf of Xuxiaohu > > > > Sent: Friday, 18 July 2014 11:58 AM > > To: mpls@ietf.org > > Cc: ; sfc@ietf.org > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > Hi all, > > > > I'm now considering how to carry metadata/context in an MPLS packet. I > > just noticed that draft-guichard-mpls-metadata-00 > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > > proposes a way to carry metadata/context in an MPLS packet (see below): > > > > "3. Metadata Channel Header Format > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. This document defines that the G-ACh Generic > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > utilized for this purpose. The GAL label provides a method to > > identify that a packet contains an "Associated Channel Header (ACH)" > > followed by a non-service payload. > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > > the first nibble of the ACH that immediately follows the bottom labe= l > > in the stack if the GAL label is present, to 0001b. Further > > [RFC5586] expects that the ACH not be used to carry user data > > traffic. This document proposes an extension to allow the first > > nibble of the ACH to be set to 0000b and, when following the GAL, be > > interpreted using the semantics defined in > > [I-D.guichard-metadata-header] to allow metadata to be carried > > through the G-ACh channel." > > > > However, it seems that the special usage of the GAL as mentioned above > > still conflicts with the following statement quoted from [RFC5586]: > > > > " The GAL MUST NOT appear in the label stack when transporting normal > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > appear more than once in the label stack." > > > > I wonder whether the special usage of the GAL as proposed in the above > > draft would result in any backward compatibility issue. In addition, I > > wonder whether it's worthwhile to reconsider the possibility of > > introducing a Protocol Type (PT) field immediately after the bottom of > > the MPLS label stack. With such PT field, any kind of future MPLS > > payload (e.g., metadata header or NSH) can be easily identified. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 17 23:42: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 01B921B2906; Thu, 17 Jul 2014 23:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2OIgelks77rO; Thu, 17 Jul 2014 23:42:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AB11B2904; Thu, 17 Jul 2014 23:42:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKF19478; Fri, 18 Jul 2014 06:42:08 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 07:42:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 14:41:56 +0800 From: Xuxiaohu To: Xuxiaohu , "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVwAGdgOQAAB4rkA= Date: Fri, 18 Jul 2014 06:41:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941CD@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/JwSMO26y_Wtyu5qVk91UGt25cNg Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:42:13 -0000 > -----Original Message----- > From: Xuxiaohu > Sent: Friday, July 18, 2014 2:33 PM > To: 'l.wood@surrey.ac.uk'; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 >=20 >=20 > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:22 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > No, my "why" is "why have metadata in the MPLS header at all"? >=20 > You could choose to carry the metadata context instead of the metadata it= self in > the data packet (See section 3.5 of the following draft > (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#= page- > 8)). >=20 > > Why does this have to be done inband? >=20 > It doesn't have to be done inband. However, since In-band marking (see se= ction > 3.1 of the following draft > (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#= page- > 8)) ) is one of the approaches of metadata sharing, I'm just considering = how to > realize that in-band approach in the MPLS case. >=20 > Best regards, > Xiaohu >=20 > > I am questioning the basis for doing this. There is no "must" here. By the way, you are right that carrying metadata or metadata context within= data packets is optional, rather than mandatory. Best regards, Xiaohu > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu > > Sent: Friday, 18 July 2014 1:17 PM > > To: Wood L Dr (Electronic Eng); mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. I think that's the "why" you may want to know. > > > > Best regards, > > Xiaohu > > > > > -----Original Message----- > > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > Sent: Friday, July 18, 2014 11:11 AM > > > To: Xuxiaohu; mpls@ietf.org > > > Cc: spring@ietf.org; sfc@ietf.org > > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > > > How? A better question is "why?" > > > > > > What has to be done in MPLS that cannot be done outside it? > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls on behalf of Xuxiaohu > > > > > > Sent: Friday, 18 July 2014 11:58 AM > > > To: mpls@ietf.org > > > Cc: ; sfc@ietf.org > > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > > > Hi all, > > > > > > I'm now considering how to carry metadata/context in an MPLS packet. > > > I just noticed that draft-guichard-mpls-metadata-00 > > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > > > proposes a way to carry metadata/context in an MPLS packet (see below= ): > > > > > > "3. Metadata Channel Header Format > > > > > > The presence of metadata within an MPLS packet must be indicated i= n > > > the encapsulation. This document defines that the G-ACh Generic > > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > > utilized for this purpose. The GAL label provides a method to > > > identify that a packet contains an "Associated Channel Header (ACH= )" > > > followed by a non-service payload. > > > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setti= ng > > > the first nibble of the ACH that immediately follows the bottom la= bel > > > in the stack if the GAL label is present, to 0001b. Further > > > [RFC5586] expects that the ACH not be used to carry user data > > > traffic. This document proposes an extension to allow the first > > > nibble of the ACH to be set to 0000b and, when following the GAL, = be > > > interpreted using the semantics defined in > > > [I-D.guichard-metadata-header] to allow metadata to be carried > > > through the G-ACh channel." > > > > > > However, it seems that the special usage of the GAL as mentioned > > > above still conflicts with the following statement quoted from [RFC55= 86]: > > > > > > " The GAL MUST NOT appear in the label stack when transporting norma= l > > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > > appear more than once in the label stack." > > > > > > I wonder whether the special usage of the GAL as proposed in the > > > above draft would result in any backward compatibility issue. In > > > addition, I wonder whether it's worthwhile to reconsider the > > > possibility of introducing a Protocol Type (PT) field immediately > > > after the bottom of the MPLS label stack. With such PT field, any > > > kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily > identified. > > > > > > Best regards, > > > Xiaohu > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jul 18 00:26: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 3E94E1A0198; Fri, 18 Jul 2014 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 2wW3sf9bamzH; Fri, 18 Jul 2014 00:26:53 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDA21A0195; Fri, 18 Jul 2014 00:26:53 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so4157525ieb.4 for ; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C+M5wQkfS8QrxXgvxHCtmQjOhx6rE5hLRCsCvC4FHEs=; b=tzl3iLewdy4ZVE0aQF0TCOuPI3/c/F06+JR5dpeSpjRJjLWk5EeCtSQ+RFoaWVxyc5 4wDfkwhfX9QkkBo2EzpT2wAK69m8O6O9d0SeYYMyuIwmUHuOH5iZt13z7epWMckX2MIW q/LCAHl+QVtWInQedm9yC3MVuTVpGkE2elMkql7X1O/IwJnoD7AmUS36jLT8zi6lmWaA Hw4CdYzlf3+mS6ZjdyIIRbULZYh8ohzgLA/avPcTEOYMbUs82QV0RdK6QyB7Tw5RbORP yTsudWgEBOimXS3tQgPSdDfJ0FppQxkhv9vJFpe+s8z7mb010BxPvjBeGPQm+2/ROkc3 +C0A== MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr35920569igb.29.1405668412382; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 09:26:52 +0200 X-Google-Sender-Auth: iizaAMQ0lVE2RL8TC1vgTCKRyYE Message-ID: From: Robert Raszuk To: Xuxiaohu , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c39c647f9c04fe72ae95 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/XFYQE_bWuzeL7QWjw_mwLEmk8Sw Cc: "mpls@ietf.org" , "" Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:26:55 -0000 --089e0112c39c647f9c04fe72ae95 Content-Type: text/plain; charset=UTF-8 All, Is the idea of using data plane to carry complete metadata is "the way" or "a way" of approaching the problem ? Has this been already discussed ? I would rather consider to carry metadata in control plane and only attach a reference_id (and only when it is needed) to the data plane. Rgs, R. On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introducing > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadata > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e0112c39c647f9c04fe72ae95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Is the idea of using data plane to carry complete metadata is "the way= " or "a way" of approaching the problem ? Has this been alre= ady discussed ?

I would rather consider to carry metadata in contro= l plane and only attach a reference_id (and only when it is needed) to the = data plane.=C2=A0

Rgs,
R.





On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <xuxiaohu@huawei.com&g= t; wrote:
Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propose= s a way to carry metadata/context in an MPLS packet (see below):

"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stac= k. With such PT field, any kind of future MPLS payload (e.g., metadata head= er or NSH) can be easily identified.

Best regards,
Xiaohu

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

--089e0112c39c647f9c04fe72ae95-- From nobody Fri Jul 18 00:43: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 283AE1A031B; Fri, 18 Jul 2014 00:43:43 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 n77wnU3Saj6y; Fri, 18 Jul 2014 00:43:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5857A1A0328; Fri, 18 Jul 2014 00:43:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH94291; Fri, 18 Jul 2014 07:43:37 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 08:43:09 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 15:43:06 +0800 From: Xuxiaohu To: Robert Raszuk , "sfc@ietf.org" Thread-Topic: [spring] How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltP///1YkA//95gUA= Date: Fri, 18 Jul 2014 07:43:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/W-BaVT378r8B_rdoXueDa-s3h0I Cc: "mpls@ietf.org" , "" Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:43:43 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJdCBzZWVtcyB0aGF0IHRoZSBjb25jZXB0IG9mIOKAnHJlZmVyZW5jZV9p ZOKAnSBsb29rcyBtdWNoIHNpbWlsYXIgd2l0aCB0aGUgY29uY2VwdCBvZiDigJxjb3JyZWxhdG9y 4oCdIGFzIGRlZmluZWQgaW4gc2VjdGlvbiAzLjMgb2YgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJpanNtYW4tc2ZjLW1ldGFkYXRhLWNvbnNpZGVyYXRpb25zLTAwI3BhZ2UtOCku IFRoYXTigJlzIHRoZSBjb250ZXh0IElEIG9mIHRoZSBtZXRhZGF0YSBJIG1lYW50Lg0KDQpJZiB0 aGF0ICDigJxyZWZlcmVuY2VfaWTigJ0gaXMgYXR0YWNoZWQgdG8gdGhlIE1QTFMgcGFja2V0LCBp dCBzZWVtcyB0aGF0IHlvdSBzdGlsbCBuZWVkIHNvbWUgd2F5IHRvIGluZGljYXRlIHRoZSBwcmVz ZW5jZSBvZiB0aGF0IOKAnHJlZmVyZW5jZV9pZOKAnSBpbiB0aGUgTVBMUyBwYWNrZXQuDQoNCkJl c3QgcmVnYXJkcywNClhpYW9odQ0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJy YXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogRnJpZGF5 LCBKdWx5IDE4LCAyMDE0IDM6MjcgUE0NClRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnDQpDYzog bXBsc0BpZXRmLm9yZzsgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBI b3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldA0KDQpBbGwsDQoN CklzIHRoZSBpZGVhIG9mIHVzaW5nIGRhdGEgcGxhbmUgdG8gY2FycnkgY29tcGxldGUgbWV0YWRh dGEgaXMgInRoZSB3YXkiIG9yICJhIHdheSIgb2YgYXBwcm9hY2hpbmcgdGhlIHByb2JsZW0gPyBI YXMgdGhpcyBiZWVuIGFscmVhZHkgZGlzY3Vzc2VkID8NCg0KSSB3b3VsZCByYXRoZXIgY29uc2lk ZXIgdG8gY2FycnkgbWV0YWRhdGEgaW4gY29udHJvbCBwbGFuZSBhbmQgb25seSBhdHRhY2ggYSBy ZWZlcmVuY2VfaWQgKGFuZCBvbmx5IHdoZW4gaXQgaXMgbmVlZGVkKSB0byB0aGUgZGF0YSBwbGFu ZS4NCg0KUmdzLA0KUi4NCg0KDQoNCg0KT24gRnJpLCBKdWwgMTgsIDIwMTQgYXQgMzo1OCBBTSwg WHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+ PiB3cm90ZToNCkhpIGFsbCwNCg0KSSdtIG5vdyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0 YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFm dC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwI3BhZ2UtNikgcHJvcG9zZXMgYSB3YXkgdG8g Y2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldCAoc2VlIGJlbG93KToNCg0K IjMuICBNZXRhZGF0YSBDaGFubmVsIEhlYWRlciBGb3JtYXQNCg0KICAgVGhlIHByZXNlbmNlIG9m IG1ldGFkYXRhIHdpdGhpbiBhbiBNUExTIHBhY2tldCBtdXN0IGJlIGluZGljYXRlZCBpbg0KICAg dGhlIGVuY2Fwc3VsYXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhhdCB0aGUgRy1BQ2gg R2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFubmVsIExhYmVsIChHQUwpIFtSRkM1NTg2XSB3aXRo IGxhYmVsIHZhbHVlIDEzIGlzDQogICB1dGlsaXplZCBmb3IgdGhpcyBwdXJwb3NlLiAgVGhlIEdB TCBsYWJlbCBwcm92aWRlcyBhIG1ldGhvZCB0bw0KICAgaWRlbnRpZnkgdGhhdCBhIHBhY2tldCBj b250YWlucyBhbiAiQXNzb2NpYXRlZCBDaGFubmVsIEhlYWRlciAoQUNIKSINCiAgIGZvbGxvd2Vk IGJ5IGEgbm9uLXNlcnZpY2UgcGF5bG9hZC4NCg0KICAgW1JGQzU1ODZdIGlkZW50aWZpZXMgdGhl IEctQUNoIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIGJ5IHNldHRpbmcNCiAgIHRoZSBmaXJz dCBuaWJibGUgb2YgdGhlIEFDSCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3MgdGhlIGJvdHRvbSBs YWJlbA0KICAgaW4gdGhlIHN0YWNrIGlmIHRoZSBHQUwgbGFiZWwgaXMgcHJlc2VudCwgdG8gMDAw MWIuICBGdXJ0aGVyDQogICBbUkZDNTU4Nl0gZXhwZWN0cyB0aGF0IHRoZSBBQ0ggbm90IGJlIHVz ZWQgdG8gY2FycnkgdXNlciBkYXRhDQogICB0cmFmZmljLiAgVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBhbiBleHRlbnNpb24gdG8gYWxsb3cgdGhlIGZpcnN0DQogICBuaWJibGUgb2YgdGhlIEFDSCB0 byBiZSBzZXQgdG8gMDAwMGIgYW5kLCB3aGVuIGZvbGxvd2luZyB0aGUgR0FMLCBiZQ0KICAgaW50 ZXJwcmV0ZWQgdXNpbmcgdGhlIHNlbWFudGljcyBkZWZpbmVkIGluDQogICBbSS1ELmd1aWNoYXJk LW1ldGFkYXRhLWhlYWRlcl0gdG8gYWxsb3cgbWV0YWRhdGEgdG8gYmUgY2FycmllZA0KICAgdGhy b3VnaCB0aGUgRy1BQ2ggY2hhbm5lbC4iDQoNCkhvd2V2ZXIsIGl0IHNlZW1zIHRoYXQgdGhlIHNw ZWNpYWwgdXNhZ2Ugb2YgdGhlIEdBTCBhcyBtZW50aW9uZWQgYWJvdmUgc3RpbGwgY29uZmxpY3Rz IHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgcXVvdGVkIGZyb20gW1JGQzU1ODZdOg0KDQoi ICBUaGUgR0FMIE1VU1QgTk9UIGFwcGVhciBpbiB0aGUgbGFiZWwgc3RhY2sgd2hlbiB0cmFuc3Bv cnRpbmcgbm9ybWFsDQogICB1c2VyLXBsYW5lIHBhY2tldHMuICBGdXJ0aGVybW9yZSwgd2hlbiBw cmVzZW50LCB0aGUgR0FMIE1VU1QgTk9UDQogICBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgaW4gdGhl IGxhYmVsIHN0YWNrLiINCg0KSSB3b25kZXIgd2hldGhlciB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0 aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRoZSBhYm92ZSBkcmFmdCB3b3VsZCByZXN1bHQgaW4gYW55 IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUuIEluIGFkZGl0aW9uLCBJIHdvbmRlciB3aGV0 aGVyIGl0J3Mgd29ydGh3aGlsZSB0byByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRy b2R1Y2luZyBhIFByb3RvY29sIFR5cGUgKFBUKSBmaWVsZCBpbW1lZGlhdGVseSBhZnRlciB0aGUg Ym90dG9tIG9mIHRoZSBNUExTIGxhYmVsIHN0YWNrLiBXaXRoIHN1Y2ggUFQgZmllbGQsIGFueSBr aW5kIG9mIGZ1dHVyZSBNUExTIHBheWxvYWQgKGUuZy4sIG1ldGFkYXRhIGhlYWRlciBvciBOU0gp IGNhbiBiZSBlYXNpbHkgaWRlbnRpZmllZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFp bGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2Jl cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHNlZW1zIHRoYXQgdGhl IGNvbmNlcHQgb2Yg4oCccmVmZXJlbmNlX2lk4oCdIGxvb2tzIG11Y2ggc2ltaWxhciB3aXRoIHRo ZSBjb25jZXB0IG9mIOKAnGNvcnJlbGF0b3LigJ0gYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMyBv ZiAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmlqc21hbi1zZmMt bWV0YWRhdGEtY29uc2lkZXJhdGlvbnMtMDAjcGFnZS04Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yaWpzbWFuLXNmYy1tZXRhZGF0YS1jb25zaWRlcmF0aW9ucy0wMCNwYWdlLTg8 L2E+KS4NCiBUaGF04oCZcyB0aGUgY29udGV4dCBJRCBvZiB0aGUgbWV0YWRhdGEgSSBtZWFudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhhdCAmbmJzcDvigJxyZWZl cmVuY2VfaWTigJ0gaXMgYXR0YWNoZWQgdG8gdGhlIE1QTFMgcGFja2V0LCBpdCBzZWVtcyB0aGF0 IHlvdSBzdGlsbCBuZWVkIHNvbWUgd2F5IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGF0 IOKAnHJlZmVyZW5jZV9pZOKAnSBpbg0KIHRoZSBNUExTIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJy YXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE4LCAy MDE0IDM6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBIb3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBp biBhbiBNUExTIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXMgdGhlIGlkZWEgb2YgdXNpbmcgZGF0YSBwbGFuZSB0 byBjYXJyeSBjb21wbGV0ZSBtZXRhZGF0YSBpcyAmcXVvdDt0aGUgd2F5JnF1b3Q7IG9yICZxdW90 O2Egd2F5JnF1b3Q7IG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRoaXMgYmVlbiBh bHJlYWR5IGRpc2N1c3NlZCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB3b3VsZCByYXRoZXIg Y29uc2lkZXIgdG8gY2FycnkgbWV0YWRhdGEgaW4gY29udHJvbCBwbGFuZSBhbmQgb25seSBhdHRh Y2ggYSByZWZlcmVuY2VfaWQgKGFuZCBvbmx5IHdoZW4gaXQgaXMgbmVlZGVkKSB0byB0aGUgZGF0 YSBwbGFuZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZ3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ui48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gRnJpLCBKdWwgMTgsIDIwMTQgYXQgMzo1OCBBTSwgWHV4aWFvaHUgJmx0OzxhIGhy ZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVA aHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPGJyPg0KPGJyPg0KSSdtIG5v dyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBh Y2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAw ICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1tcGxz LW1ldGFkYXRhLTAwI3BhZ2UtNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWd1aWNoYXJkLW1wbHMtbWV0YWRhdGEtMDAjcGFnZS02PC9hPikNCiBwcm9w b3NlcyBhIHdheSB0byBjYXJyeSBtZXRhZGF0YS9jb250ZXh0IGluIGFuIE1QTFMgcGFja2V0IChz ZWUgYmVsb3cpOjxicj4NCjxicj4NCiZxdW90OzMuICZuYnNwO01ldGFkYXRhIENoYW5uZWwgSGVh ZGVyIEZvcm1hdDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgcHJlc2VuY2Ugb2YgbWV0YWRh dGEgd2l0aGluIGFuIE1QTFMgcGFja2V0IG11c3QgYmUgaW5kaWNhdGVkIGluPGJyPg0KJm5ic3A7 ICZuYnNwO3RoZSBlbmNhcHN1bGF0aW9uLiAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhh dCB0aGUgRy1BQ2ggR2VuZXJpYzxicj4NCiZuYnNwOyAmbmJzcDtBc3NvY2lhdGVkIENoYW5uZWwg TGFiZWwgKEdBTCkgW1JGQzU1ODZdIHdpdGggbGFiZWwgdmFsdWUgMTMgaXM8YnI+DQombmJzcDsg Jm5ic3A7dXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gJm5ic3A7VGhlIEdBTCBsYWJlbCBwcm92 aWRlcyBhIG1ldGhvZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtpZGVudGlmeSB0aGF0IGEgcGFja2V0 IGNvbnRhaW5zIGFuICZxdW90O0Fzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXIgKEFDSCkmcXVvdDs8 YnI+DQombmJzcDsgJm5ic3A7Zm9sbG93ZWQgYnkgYSBub24tc2VydmljZSBwYXlsb2FkLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtbUkZDNTU4Nl0gaWRlbnRpZmllcyB0aGUgRy1BQ2ggR2VuZXJp YyBBc3NvY2lhdGVkIENoYW5uZWwgYnkgc2V0dGluZzxicj4NCiZuYnNwOyAmbmJzcDt0aGUgZmly c3QgbmliYmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBib3R0b20g bGFiZWw8YnI+DQombmJzcDsgJm5ic3A7aW4gdGhlIHN0YWNrIGlmIHRoZSBHQUwgbGFiZWwgaXMg cHJlc2VudCwgdG8gMDAwMWIuICZuYnNwO0Z1cnRoZXI8YnI+DQombmJzcDsgJm5ic3A7W1JGQzU1 ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRvIGNhcnJ5IHVzZXIgZGF0YTxi cj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljLiAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGFu IGV4dGVuc2lvbiB0byBhbGxvdyB0aGUgZmlyc3Q8YnI+DQombmJzcDsgJm5ic3A7bmliYmxlIG9m IHRoZSBBQ0ggdG8gYmUgc2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBmb2xsb3dpbmcgdGhlIEdBTCwg YmU8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJwcmV0ZWQgdXNpbmcgdGhlIHNlbWFudGljcyBkZWZp bmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1tJLUQuZ3VpY2hhcmQtbWV0YWRhdGEtaGVhZGVyXSB0 byBhbGxvdyBtZXRhZGF0YSB0byBiZSBjYXJyaWVkPGJyPg0KJm5ic3A7ICZuYnNwO3Rocm91Z2gg dGhlIEctQUNoIGNoYW5uZWwuJnF1b3Q7PGJyPg0KPGJyPg0KSG93ZXZlciwgaXQgc2VlbXMgdGhh dCB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIG1lbnRpb25lZCBhYm92ZSBzdGlsbCBj b25mbGljdHMgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBxdW90ZWQgZnJvbSBbUkZDNTU4 Nl06PGJyPg0KPGJyPg0KJnF1b3Q7ICZuYnNwO1RoZSBHQUwgTVVTVCBOT1QgYXBwZWFyIGluIHRo ZSBsYWJlbCBzdGFjayB3aGVuIHRyYW5zcG9ydGluZyBub3JtYWw8YnI+DQombmJzcDsgJm5ic3A7 dXNlci1wbGFuZSBwYWNrZXRzLiAmbmJzcDtGdXJ0aGVybW9yZSwgd2hlbiBwcmVzZW50LCB0aGUg R0FMIE1VU1QgTk9UPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGVhciBtb3JlIHRoYW4gb25jZSBpbiB0 aGUgbGFiZWwgc3RhY2suJnF1b3Q7PGJyPg0KPGJyPg0KSSB3b25kZXIgd2hldGhlciB0aGUgc3Bl Y2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRoZSBhYm92ZSBkcmFmdCB3b3Vs ZCByZXN1bHQgaW4gYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUuIEluIGFkZGl0aW9u LCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgd29ydGh3aGlsZSB0byByZWNvbnNpZGVyIHRoZSBwb3Nz aWJpbGl0eSBvZiBpbnRyb2R1Y2luZyBhIFByb3RvY29sIFR5cGUgKFBUKSBmaWVsZCBpbW1lZGlh dGVseQ0KIGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIE1QTFMgbGFiZWwgc3RhY2suIFdpdGggc3Vj aCBQVCBmaWVsZCwgYW55IGtpbmQgb2YgZnV0dXJlIE1QTFMgcGF5bG9hZCAoZS5nLiwgbWV0YWRh dGEgaGVhZGVyIG9yIE5TSCkgY2FuIGJlIGVhc2lseSBpZGVudGlmaWVkLjxicj4NCjxicj4NCkJl c3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_-- From nobody Fri Jul 18 00:55: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 AF8671A0A9C; Fri, 18 Jul 2014 00:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 CZ-z_aVq8Pxe; Fri, 18 Jul 2014 00:55:29 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBE71A04B0; Fri, 18 Jul 2014 00:55:29 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so319351igb.3 for ; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T2lFwYDmBtM8+2GnMLlSibOQnppEj96MkjPN+a1CPFI=; b=SxTGhQcPMeuE7o1JX6lyu98aMgzT0iD6Q8X86UvvEdhBwz643bZ8bSoo3j9XsdAQ5k QVMuK8TfvxZVhwrTDpT8DmBzIieolDz/arykbFNzc2T+pJBUzI4qX4aSBJuU5b37Hxe0 BtpCh8UIYU56tz2RjEo0zCVnWgnxFQl+eA+8QQHjMXeBzpMPuM+S5SsJVaeKxSup80Qt 05JUt+vGGJv3KZs3CD/Cs5ubjUQNcuzAbIUB/bnzKmRDDfIoe7Cgubm1vW+lAFhXxLRn X42PCzaGqiekdbE43W4WbmF1KFDWi+7Xgm6MLeOqx5fJ2+1B8wVm2YKKsprsEDG7OKA8 VhgQ== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr6110768igx.9.1405670128377; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 09:55:28 +0200 X-Google-Sender-Auth: TjbOLNw2LsOYkKzlqAbWOPnETgg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e0122a754ac645804fe7314bf Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IJ_UYIZCFAMIGNGyQ599pI7Isis Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:55:34 -0000 --089e0122a754ac645804fe7314bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xu, Yes indeed I do consider proposal from Bruno and Jerome as exact match to what I had in mind with their "correlator" to mine "reference_id". Just terminology nit. Except it is not section 3.3 but 3.5 ... "3.5. Hybrid in-band marking and out-of-band signaling Metadata can be signaled using a hybrid approach combining in-band marking and out-of-band signaling. Each data packet can carry a small fixed-length field which serves as a "correlator". An out-of-band signaling protocol can then be used to map the correlator value to the actual metadata value(s)." > If that =E2=80=9Creference_id=E2=80=9D is attached to the MPLS > packet, it seems that you still need some way to > indicate the presence of that =E2=80=9Creference_id=E2=80=9D in > the MPLS packet. I am not sure we need yet another point solution indicator. We already have two general purpose mechanism which seems like possible indicators which could be used here: * RFC 5331 - MPLS Upstream Label Assignment and Context-Specific Label Spac= e * RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labels Rgs, r. On Fri, Jul 18, 2014 at 9:43 AM, Xuxiaohu wrote: > Hi Robert, > > > > It seems that the concept of =E2=80=9Creference_id=E2=80=9D looks much si= milar with the > concept of =E2=80=9Ccorrelator=E2=80=9D as defined in section 3.3 of ( > http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#p= age-8). > That=E2=80=99s the context ID of the metadata I meant. > > > > If that =E2=80=9Creference_id=E2=80=9D is attached to the MPLS packet, i= t seems that you > still need some way to indicate the presence of that =E2=80=9Creference_i= d=E2=80=9D in the > MPLS packet. > > > > Best regards, > > Xiaohu > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Friday, July 18, 2014 3:27 PM > *To:* Xuxiaohu; sfc@ietf.org > *Cc:* mpls@ietf.org; > *Subject:* Re: [spring] How to carry metadata/context in an MPLS packet > > > > All, > > > > Is the idea of using data plane to carry complete metadata is "the way" o= r > "a way" of approaching the problem ? Has this been already discussed ? > > > > I would rather consider to carry metadata in control plane and only attac= h > a reference_id (and only when it is needed) to the data plane. > > > > Rgs, > > R. > > > > > > > > > > On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introduci= ng > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadat= a > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --089e0122a754ac645804fe7314bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xu,
Yes indeed I do consider proposal from Bruno and Je= rome as exact match to what I had in mind with their "correlator"= to mine "reference_id". Just terminology nit.=C2=A0

Except it is not = section 3.3 but 3.5 ...

"3.5. H= ybrid in-band marking and out-of-band signaling
Metadata can be signaled using a hybrid approach combining in-= band=C2= =A0marking and out-of-band signaling.
Each data packet can carry a small fixed-length field which se= rves=C2=A0= =C2=A0used to map the correlator value to the actual metadata value(s).&quo= t;


> If that =C2=A0=E2=80=9Creference= _id=E2=80=9D is attached to the MPLS=C2=A0
> packet, it seems = that you still need some way to=C2=A0
&g= t; indicate the presence of that =E2=80=9Creference_id=E2=80=9D in=C2=A0
> the=C2=A0MPLS packet.

I am not sure we need yet another point = solution indicator.=C2=A0
We already have two general purpose mechanism which seems like= possible indicators which could be used here:
* RFC 5331 -=C2=A0MPLS Upstream Label Assignment and Context-S= pecific Label Space
* RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labe= ls

Rgs,
r.

=

On Fri, Jul 18, 2014 at 9:43 AM, Xuxiaoh= u <xuxiaohu@huawei.com> wrote:

Hi Robert,=

=C2= =A0

It seems t= hat the concept of =E2=80=9Creference_id=E2=80=9D looks much similar with t= he concept of =E2=80=9Ccorrelator=E2=80=9D as defined in section 3.3 of (http://tools.ietf.org/html/draft-rijsman-sf= c-metadata-considerations-00#page-8). That=E2=80=99s the context ID of the metadata I meant.

=C2= =A0

If that = =C2=A0=E2=80=9Creference_id=E2=80=9D is attached to the MPLS packet, it see= ms that you still need some way to indicate the presence of that =E2=80=9Cr= eference_id=E2=80=9D in the MPLS packet.

=C2= =A0

Best regar= ds,

Xiaohu<= /u>

=C2= =A0

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, July 18, 2014 3:27 PM
To: Xuxiaohu; sfc@= ietf.org
Cc: mpls@ietf.org= ; <spring@ietf.= org>
Subject: Re: [spring] How to carry metadata/context in an MPLS packe= t

=C2=A0

All,

=C2=A0

Is the idea of using data plane to carry complete metadata i= s "the way" or "a way" of approaching the problem ? Has= this been already discussed ?

=C2=A0

I would rather consider to carry metadata in control plane a= nd only attach a reference_id (and only when it is needed) to the data plan= e.=C2=A0

=C2=A0

Rgs,

R.

=C2=A0

=C2=A0

=C2=A0

= =C2=A0

On Fri, Jul 18, 2014 at 3:58 AM= , Xuxiaohu <xux= iaohu@huawei.com> wrote:

Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/context in an MPLS packet (see below):
"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stack. With such PT field, any kind of = future MPLS payload (e.g., metadata header or NSH) can be easily identified= .

Best regards,
Xiaohu

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

=C2=A0


--089e0122a754ac645804fe7314bf-- From nobody Fri Jul 18 03:23: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 AE1591A0422; Thu, 17 Jul 2014 20:11:03 -0700 (PDT) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DGCejJ-K_QkV; Thu, 17 Jul 2014 20:11:01 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02191A0417; Thu, 17 Jul 2014 20:11:00 -0700 (PDT) Received: from [85.158.137.99:58985] by server-3.bemta-3.messagelabs.com id BC/A8-08876-24098C35; Fri, 18 Jul 2014 03:10:58 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-217.messagelabs.com!1405653058!22628557!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22524 invoked from network); 18 Jul 2014 03:10:58 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2014 03:10:58 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 18 Jul 2014 04:10:58 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 18 Jul 2014 04:10:57 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) with Microsoft SMTP Server (TLS) id 15.0.985.8; Fri, 18 Jul 2014 03:10:57 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0985.008; Fri, 18 Jul 2014 03:10:57 +0000 From: To: , Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZj Date: Fri, 18 Jul 2014 03:10:56 +0000 Message-ID: <1405653056176.39234@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(53754006)(377454003)(199002)(189002)(107046002)(54356999)(46102001)(19580395003)(50986999)(4396001)(95666004)(74482001)(99396002)(66066001)(86362001)(19580405001)(15395725005)(81342001)(81542001)(105586002)(76482001)(15975445006)(36756003)(20776003)(31966008)(85306003)(74502001)(92566001)(83072002)(83322001)(77982001)(15198665003)(85852003)(79102001)(64706001)(80022001)(74662001)(101416001)(76176999)(21056001)(15202345003)(2656002)(106356001)(87936001)(92726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB438; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB438.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/V8F-ufK2R2ujBV7P2jbapaHhE_M X-Mailman-Approved-At: Fri, 18 Jul 2014 03:23:24 -0700 Cc: spring@ietf.org, sfc@ietf.org Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:11:04 -0000 How? A better question is "why?"=0A= =0A= What has to be done in MPLS that cannot be done outside it?=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: mpls on behalf of Xuxiaohu =0A= Sent: Friday, 18 July 2014 11:58 AM=0A= To: mpls@ietf.org=0A= Cc: ; sfc@ietf.org=0A= Subject: [mpls] How to carry metadata/context in an MPLS packet=0A= =0A= Hi all,=0A= =0A= I'm now considering how to carry metadata/context in an MPLS packet. I just= noticed that draft-guichard-mpls-metadata-00 (http://tools.ietf.org/html/d= raft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/con= text in an MPLS packet (see below):=0A= =0A= "3. Metadata Channel Header Format=0A= =0A= The presence of metadata within an MPLS packet must be indicated in=0A= the encapsulation. This document defines that the G-ACh Generic=0A= Associated Channel Label (GAL) [RFC5586] with label value 13 is=0A= utilized for this purpose. The GAL label provides a method to=0A= identify that a packet contains an "Associated Channel Header (ACH)"=0A= followed by a non-service payload.=0A= =0A= [RFC5586] identifies the G-ACh Generic Associated Channel by setting=0A= the first nibble of the ACH that immediately follows the bottom label=0A= in the stack if the GAL label is present, to 0001b. Further=0A= [RFC5586] expects that the ACH not be used to carry user data=0A= traffic. This document proposes an extension to allow the first=0A= nibble of the ACH to be set to 0000b and, when following the GAL, be=0A= interpreted using the semantics defined in=0A= [I-D.guichard-metadata-header] to allow metadata to be carried=0A= through the G-ACh channel."=0A= =0A= However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:=0A= =0A= " The GAL MUST NOT appear in the label stack when transporting normal=0A= user-plane packets. Furthermore, when present, the GAL MUST NOT=0A= appear more than once in the label stack."=0A= =0A= I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a Proto= col Type (PT) field immediately after the bottom of the MPLS label stack. W= ith such PT field, any kind of future MPLS payload (e.g., metadata header o= r NSH) can be easily identified.=0A= =0A= Best regards,=0A= Xiaohu=0A= =0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Fri Jul 18 03:23: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 EC8611B286B; Thu, 17 Jul 2014 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tYvBqc935G2I; Thu, 17 Jul 2014 20:22:31 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.150]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777A41A0418; Thu, 17 Jul 2014 20:22:30 -0700 (PDT) Received: from [195.245.231.67:51838] by server-14.bemta-5.messagelabs.com id 1C/47-11783-5F298C35; Fri, 18 Jul 2014 03:22:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1405653747!39396238!6 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5082 invoked from network); 18 Jul 2014 03:22:28 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2014 03:22:28 -0000 Received: from EXHY011V.surrey.ac.uk (131.227.200.103) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 18 Jul 2014 04:22:27 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 18 Jul 2014 04:22:26 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.985.8; Fri, 18 Jul 2014 03:22:26 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0985.008; Fri, 18 Jul 2014 03:22:26 +0000 From: To: , Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVw== Date: Fri, 18 Jul 2014 03:22:26 +0000 Message-ID: <1405653745773.33083@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51444003)(53754006)(51704005)(13464003)(199002)(189002)(377454003)(83322001)(64706001)(66066001)(20776003)(76176999)(87936001)(15975445006)(50986999)(19580405001)(95666004)(54356999)(101416001)(105586002)(85306003)(107046002)(76482001)(46102001)(92566001)(36756003)(15395725005)(19580395003)(77982001)(74662001)(79102001)(86362001)(74502001)(4396001)(2656002)(106356001)(31966008)(92726001)(85852003)(81542001)(83072002)(81342001)(21056001)(15202345003)(99396002)(74482001)(15198665003)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY011v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY011v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/64VV57JTH1oUBnoqZsVRGzRqa_M X-Mailman-Approved-At: Fri, 18 Jul 2014 03:23:25 -0700 Cc: spring@ietf.org, sfc@ietf.org Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:22:33 -0000 No, my "why" is "why have metadata in the MPLS header at all"?=0A= =0A= Why does this have to be done inband?=0A= =0A= I am questioning the basis for doing this. There is no "must" here.=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: Xuxiaohu =0A= Sent: Friday, 18 July 2014 1:17 PM=0A= To: Wood L Dr (Electronic Eng); mpls@ietf.org=0A= Cc: spring@ietf.org; sfc@ietf.org=0A= Subject: RE: How to carry metadata/context in an MPLS packet=0A= =0A= The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know.=0A= =0A= Best regards,=0A= Xiaohu=0A= =0A= > -----Original Message-----=0A= > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]=0A= > Sent: Friday, July 18, 2014 11:11 AM=0A= > To: Xuxiaohu; mpls@ietf.org=0A= > Cc: spring@ietf.org; sfc@ietf.org=0A= > Subject: RE: How to carry metadata/context in an MPLS packet=0A= >=0A= > How? A better question is "why?"=0A= >=0A= > What has to be done in MPLS that cannot be done outside it?=0A= >=0A= > Lloyd Wood=0A= > http://about.me/lloydwood=0A= > ________________________________________=0A= > From: mpls on behalf of Xuxiaohu=0A= > =0A= > Sent: Friday, 18 July 2014 11:58 AM=0A= > To: mpls@ietf.org=0A= > Cc: ; sfc@ietf.org=0A= > Subject: [mpls] How to carry metadata/context in an MPLS packet=0A= >=0A= > Hi all,=0A= >=0A= > I'm now considering how to carry metadata/context in an MPLS packet. I ju= st=0A= > noticed that draft-guichard-mpls-metadata-00=0A= > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propo= ses=0A= > a way to carry metadata/context in an MPLS packet (see below):=0A= >=0A= > "3. Metadata Channel Header Format=0A= >=0A= > The presence of metadata within an MPLS packet must be indicated in=0A= > the encapsulation. This document defines that the G-ACh Generic=0A= > Associated Channel Label (GAL) [RFC5586] with label value 13 is=0A= > utilized for this purpose. The GAL label provides a method to=0A= > identify that a packet contains an "Associated Channel Header (ACH)"= =0A= > followed by a non-service payload.=0A= >=0A= > [RFC5586] identifies the G-ACh Generic Associated Channel by setting= =0A= > the first nibble of the ACH that immediately follows the bottom label= =0A= > in the stack if the GAL label is present, to 0001b. Further=0A= > [RFC5586] expects that the ACH not be used to carry user data=0A= > traffic. This document proposes an extension to allow the first=0A= > nibble of the ACH to be set to 0000b and, when following the GAL, be= =0A= > interpreted using the semantics defined in=0A= > [I-D.guichard-metadata-header] to allow metadata to be carried=0A= > through the G-ACh channel."=0A= >=0A= > However, it seems that the special usage of the GAL as mentioned above st= ill=0A= > conflicts with the following statement quoted from [RFC5586]:=0A= >=0A= > " The GAL MUST NOT appear in the label stack when transporting normal=0A= > user-plane packets. Furthermore, when present, the GAL MUST NOT=0A= > appear more than once in the label stack."=0A= >=0A= > I wonder whether the special usage of the GAL as proposed in the above dr= aft=0A= > would result in any backward compatibility issue. In addition, I wonder w= hether=0A= > it's worthwhile to reconsider the possibility of introducing a Protocol T= ype (PT)=0A= > field immediately after the bottom of the MPLS label stack. With such PT = field,=0A= > any kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily=0A= > identified.=0A= >=0A= > Best regards,=0A= > Xiaohu=0A= >=0A= > _______________________________________________=0A= > mpls mailing list=0A= > mpls@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Fri Jul 18 03:26: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 79BFC1A0191; Fri, 18 Jul 2014 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 VE9uPfGK0I17; Fri, 18 Jul 2014 03:26:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5AA1A0145; Fri, 18 Jul 2014 03:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4284; q=dns/txt; s=iport; t=1405679207; x=1406888807; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8NMaZACDXrznUwvN1bRNPQMd4OTz00GP+BebVjsgXpw=; b=F9WmcIN0jnuWVafDzEqw/R7RtIgrUfwuMIz+4NYU7mUHlkt2koZzVDT9 r+v1DkykYAQCoCS3RKlGmtg17cvZO2cEAMBNyhHFZRuoXKKihU47FD7H0 lBYARxpzUWT8LopBOjmVhaiJUWhYhrcqLOupeEcK/vt2dRgL4cVxeevOs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAAz2yFOtJV2P/2dsb2JhbABPCg6DAFJTBATEZAqHQ4EIFnaEAwEBAQQBAQE3LQcLDAYBCBEEAQEfCS4LFAkKBAENBYhCCAXEBReJfoRxXA2EQAWbIIFMjEeGGYMCQmyBRQ X-IronPort-AV: E=Sophos;i="5.01,684,1400025600"; d="scan'208";a="61946817" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 18 Jul 2014 10:26:46 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6IAQk32021073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 10:26:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 05:26:46 -0500 From: "Jim Guichard (jguichar)" To: "l.wood@surrey.ac.uk" , "xuxiaohu@huawei.com" , "mpls@ietf.org" Thread-Topic: [sfc] How to carry metadata/context in an MPLS packet Thread-Index: AQHPonLGRVDkgTbu6E6nM2i0L/u3EQ== Date: Fri, 18 Jul 2014 10:26:46 +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.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <79D924AD1CCAF24D944C4B91646872F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/uGVptDYrY-JFUZXk1HxU94hw6UI Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:26:49 -0000 Hi Lloyd, I believe that Xiaohu means that we need a way to *indicate* that metadata follows the bottom of the MPLS label stack. There are multiple ways to do that and as Robert quite rightly pointed out some mechanisms already exist such as reserved labels, special-purpose labels, context labels, my old draft (which FYI has expired) etc. On 7/17/14, 11:22 PM, "l.wood@surrey.ac.uk" wrote: >No, my "why" is "why have metadata in the MPLS header at all"? > >Why does this have to be done inband? > >I am questioning the basis for doing this. There is no "must" here. > >Lloyd Wood >http://about.me/lloydwood >________________________________________ >From: Xuxiaohu >Sent: Friday, 18 July 2014 1:17 PM >To: Wood L Dr (Electronic Eng); mpls@ietf.org >Cc: spring@ietf.org; sfc@ietf.org >Subject: RE: How to carry metadata/context in an MPLS packet > >The presence of metadata within an MPLS packet must be indicated in the >encapsulation. I think that's the "why" you may want to know. > >Best regards, >Xiaohu > >> -----Original Message----- >> From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] >> Sent: Friday, July 18, 2014 11:11 AM >> To: Xuxiaohu; mpls@ietf.org >> Cc: spring@ietf.org; sfc@ietf.org >> Subject: RE: How to carry metadata/context in an MPLS packet >> >> How? A better question is "why?" >> >> What has to be done in MPLS that cannot be done outside it? >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: mpls on behalf of Xuxiaohu >> >> Sent: Friday, 18 July 2014 11:58 AM >> To: mpls@ietf.org >> Cc: ; sfc@ietf.org >> Subject: [mpls] How to carry metadata/context in an MPLS packet >> >> Hi all, >> >> I'm now considering how to carry metadata/context in an MPLS packet. I >>just >> noticed that draft-guichard-mpls-metadata-00 >> (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) >>proposes >> a way to carry metadata/context in an MPLS packet (see below): >> >> "3. Metadata Channel Header Format >> >> The presence of metadata within an MPLS packet must be indicated in >> the encapsulation. This document defines that the G-ACh Generic >> Associated Channel Label (GAL) [RFC5586] with label value 13 is >> utilized for this purpose. The GAL label provides a method to >> identify that a packet contains an "Associated Channel Header (ACH)" >> followed by a non-service payload. >> >> [RFC5586] identifies the G-ACh Generic Associated Channel by setting >> the first nibble of the ACH that immediately follows the bottom label >> in the stack if the GAL label is present, to 0001b. Further >> [RFC5586] expects that the ACH not be used to carry user data >> traffic. This document proposes an extension to allow the first >> nibble of the ACH to be set to 0000b and, when following the GAL, be >> interpreted using the semantics defined in >> [I-D.guichard-metadata-header] to allow metadata to be carried >> through the G-ACh channel." >> >> However, it seems that the special usage of the GAL as mentioned above >>still >> conflicts with the following statement quoted from [RFC5586]: >> >> " The GAL MUST NOT appear in the label stack when transporting normal >> user-plane packets. Furthermore, when present, the GAL MUST NOT >> appear more than once in the label stack." >> >> I wonder whether the special usage of the GAL as proposed in the above >>draft >> would result in any backward compatibility issue. In addition, I wonder >>whether >> it's worthwhile to reconsider the possibility of introducing a Protocol >>Type (PT) >> field immediately after the bottom of the MPLS label stack. With such >>PT field, >> any kind of future MPLS payload (e.g., metadata header or NSH) can be >>easily >> identified. >> >> Best regards, >> Xiaohu >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 18 03:32: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 58A361A02AC; Fri, 18 Jul 2014 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 3qKpH3Ry7bMr; Fri, 18 Jul 2014 03:32:00 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DED1A015B; Fri, 18 Jul 2014 03:32:00 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so437038igb.11 for ; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Wg8hM8zV2Lt1xr3k3QA0ORZp6KMOD4WVf7lMt5EkJRs=; b=CfVhg/jDs8r6KT/R8boqMLc8xey2jMejneELhOsteTc0vfqibmpsFii/zfVA8ypFYv 7MOuQoFkXrfyO04+nuEHf25TzLlPAx+d3mHmgGEx0eXLbJWtlAkRI/z2fEM/Kw8D4vVL qh/Ex3bV6Rxfq6r9SPieReudNRY439chcDwpshz9vbbVReOpcB3DeFv8fRtyXUv4NG+P 4Z2vSPjrKCkP30naj7VwyqEBPJnnYt5bpA9mU3U2r76mo66sTHhvg6tfZ/cnRq1j8WAn 2wJH9doSD/UMc71FZ2PE1+J1hxwiVdXaEXojzdStfr1olnhO8TyNymlcu6C9IwSmRIgK 3HcA== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr7301657igb.21.1405679519463; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) In-Reply-To: <1405653745773.33083@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> Date: Fri, 18 Jul 2014 12:31:59 +0200 X-Google-Sender-Auth: 6-Ta-eolvAUYzakfS_e3j1eUdoA Message-ID: From: Robert Raszuk To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=089e013a0c686d018504fe754460 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6ae0iRqgppIXDPVWIdbt5ty1A94 Cc: mpls@ietf.org, spring@ietf.org, xuxiaohu@huawei.com, sfc@ietf.org Subject: Re: [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:32:02 -0000 --089e013a0c686d018504fe754460 Content-Type: text/plain; charset=UTF-8 Hi Lloyd, I think and I do hope that we see only mpls centric proposals as this is one encapsulation used in the networks. I hope other proposals will also address v6 encapsulations and that any encapsulation will use same metadata control plane. Best, R. On Jul 18, 2014 12:23 PM, wrote: > No, my "why" is "why have metadata in the MPLS header at all"? > > Why does this have to be done inband? > > I am questioning the basis for doing this. There is no "must" here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu > Sent: Friday, 18 July 2014 1:17 PM > To: Wood L Dr (Electronic Eng); mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet > > The presence of metadata within an MPLS packet must be indicated in the > encapsulation. I think that's the "why" you may want to know. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:11 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > How? A better question is "why?" > > > > What has to be done in MPLS that cannot be done outside it? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls on behalf of Xuxiaohu > > > > Sent: Friday, 18 July 2014 11:58 AM > > To: mpls@ietf.org > > Cc: ; sfc@ietf.org > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > Hi all, > > > > I'm now considering how to carry metadata/context in an MPLS packet. I > just > > noticed that draft-guichard-mpls-metadata-00 > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes > > a way to carry metadata/context in an MPLS packet (see below): > > > > "3. Metadata Channel Header Format > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. This document defines that the G-ACh Generic > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > utilized for this purpose. The GAL label provides a method to > > identify that a packet contains an "Associated Channel Header (ACH)" > > followed by a non-service payload. > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > > the first nibble of the ACH that immediately follows the bottom label > > in the stack if the GAL label is present, to 0001b. Further > > [RFC5586] expects that the ACH not be used to carry user data > > traffic. This document proposes an extension to allow the first > > nibble of the ACH to be set to 0000b and, when following the GAL, be > > interpreted using the semantics defined in > > [I-D.guichard-metadata-header] to allow metadata to be carried > > through the G-ACh channel." > > > > However, it seems that the special usage of the GAL as mentioned above > still > > conflicts with the following statement quoted from [RFC5586]: > > > > " The GAL MUST NOT appear in the label stack when transporting normal > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > appear more than once in the label stack." > > > > I wonder whether the special usage of the GAL as proposed in the above > draft > > would result in any backward compatibility issue. In addition, I wonder > whether > > it's worthwhile to reconsider the possibility of introducing a Protocol > Type (PT) > > field immediately after the bottom of the MPLS label stack. With such PT > field, > > any kind of future MPLS payload (e.g., metadata header or NSH) can be > easily > > identified. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --089e013a0c686d018504fe754460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Lloyd,

I think and I do hope that we see only mpls centric proposal= s as this is one encapsulation used in the networks.

I hope other proposals will also address v6 encapsulations a= nd that any encapsulation will use same metadata control plane.

Best,
R.

On Jul 18, 2014 12:23 PM, <l.wood@surrey.ac.uk> wrote:
No, my "why" is "why have metadata in the MPLS header at all= "?

Why does this have to be done inband?

I am questioning the basis for doing this. There is no "must" her= e.

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Xuxiaohu <xuxiaohu@huawei.c= om>
Sent: Friday, 18 July 2014 1:17 PM
To: Wood L =C2=A0Dr (Electronic Eng); mpls= @ietf.org
Cc: spring@ietf.org; sfc@ietf.org
Subject: RE: How to carry metadata/context in an MPLS packet

The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know.
Best regards,
Xiaohu

> -----Original Message-----
> From: l.wood@surrey.ac.uk [= mailto:l.wood@surrey.ac.uk]
> Sent: Friday, July 18, 2014 11:11 AM
> To: Xuxiaohu; mpls@ietf.org
> Cc: spring@ietf.org; sfc@ietf.org
> Subject: RE: How to carry metadata/context in an MPLS packet
>
> How? A better question is "why?"
>
> What has to be done in MPLS that cannot be done outside it?
>
> Lloyd Wood
> http://about.m= e/lloydwood
> ________________________________________
> From: mpls <mpls-bounces@i= etf.org> on behalf of Xuxiaohu
> <xuxiaohu@huawei.com>=
> Sent: Friday, 18 July 2014 11:58 AM
> To: mpls@ietf.org
> Cc: <spring@ietf.org>; sfc@ietf.org
> Subject: [mpls] How to carry metadata/context in an MPLS packet
>
> Hi all,
>
> I'm now considering how to carry metadata/context in an MPLS packe= t. I just
> noticed that draft-guichard-mpls-metadata-00
> (http://tools.ietf.org/html/draft-guichard-mpls-m= etadata-00#page-6) proposes
> a way to carry metadata/context in an MPLS packet (see below):
>
> "3. =C2=A0Metadata Channel Header Format
>
> =C2=A0 =C2=A0The presence of metadata within an MPLS packet must be in= dicated in
> =C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G= -ACh Generic
> =C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value= 13 is
> =C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a= method to
> =C2=A0 =C2=A0identify that a packet contains an "Associated Chann= el Header (ACH)"
> =C2=A0 =C2=A0followed by a non-service payload.
>
> =C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel= by setting
> =C2=A0 =C2=A0the first nibble of the ACH that immediately follows the = bottom label
> =C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2= =A0Further
> =C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user = data
> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to all= ow the first
> =C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following = the GAL, be
> =C2=A0 =C2=A0interpreted using the semantics defined in
> =C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be ca= rried
> =C2=A0 =C2=A0through the G-ACh channel."
>
> However, it seems that the special usage of the GAL as mentioned above= still
> conflicts with the following statement quoted from [RFC5586]:
>
> " =C2=A0The GAL MUST NOT appear in the label stack when transport= ing normal
> =C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the = GAL MUST NOT
> =C2=A0 =C2=A0appear more than once in the label stack."
>
> I wonder whether the special usage of the GAL as proposed in the above= draft
> would result in any backward compatibility issue. In addition, I wonde= r whether
> it's worthwhile to reconsider the possibility of introducing a Pro= tocol Type (PT)
> field immediately after the bottom of the MPLS label stack. With such = PT field,
> any kind of future MPLS payload (e.g., metadata header or NSH) can be = easily
> identified.
>
> Best regards,
> Xiaohu
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc
--089e013a0c686d018504fe754460-- From nobody Fri Jul 18 05:05: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 C28AB1B2970; Fri, 18 Jul 2014 05:05:36 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z4v3_gcWK1fO; Fri, 18 Jul 2014 05:05:33 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCCF1A0ABE; Fri, 18 Jul 2014 05:05:33 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D3F6653E19; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Fri, 18 Jul 2014 05:05:28.807 -0700 x-echoworx-msg-id: e780d1aa-f0b6-47f6-aee8-b5d2e1b686c1 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 819; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) Received: from HUB021-CA-3.exch021.domain.local (unknown [10.254.4.36]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id ACA6553E19; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0174.001; Fri, 18 Jul 2014 05:05:33 -0700 From: Ron Parker To: Robert Raszuk , Xuxiaohu , "sfc@ietf.org" Thread-Topic: [sfc] [spring] How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwAaH8sAAAUge5A= Date: Fri, 18 Jul 2014 12:05:32 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/agKsjlpqB9fvaMw1xjhQKFCQ2Sg Cc: "mpls@ietf.org" , "" Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 12:05:37 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpJbmJhbmQgaXMgb25lIHdheSAtLSBpdCBzaW1wbGlmaWVzIHRoaW5ncyBhdCB0 aGUgY29zdCBvZiBwYWNrZXQgZ3Jvd3RoLiAgIE91dC1vZi1iYW5kIChpLmUuLCBzaWduYWxpbmcp IGlzIGFub3RoZXIgd2F5IOKAkyBpdCBhZGRzIGNvbXBsZXhpdHkgYnV0IGRvZXNu4oCZdCBncm93 IHRoZSBkYXRhIHBsYW5lIHBhY2tldHMuICAgQ29uZ3J1ZW50IG91dC1vZi1iYW5kIGlzIGEgdmFy aWF0aW9uIG9uIG91dC1vZi1iYW5kIHRoYXQgbWF5IHBhcnRpYWxseSByZWR1Y2Ugb3V0LW9mLWJh bmQgY29tcGxleGl0eS4gICAgSSB0aGluayBtYW55IG9waW5pb25zIG9uIHRoZSB0aHJlYWQgaGF2 ZSBiZWVuIHRoYXQgYWxsIGFyZSBpbiBzY29wZSwgYXJjaGl0ZWN0dXJhbGx5LiAgICBEcmFmdC16 aGFuZy1zZmMtc2NoIChJIGFtIGEgY28tYXV0aG9yKSwgZm9yIGV4YW1wbGUsIGRlZmluZXMgaW5i YW5kIG1ldGFkYXRhIGV4cGxpY2l0bHksIGJ1dCBzdGF0ZXMgaW4gdGV4dCB0aGF0IG91dC1vZi1i YW5kIGlzIHBvc3NpYmxlLCB0b28uICAgIEnigJltIHN1cmUgdGhpcyB3aWxsIGJlIGEgdG9waWMg b2YgZGlzY3Vzc2lvbiB3aGVuIHdlIHN0YXJ0IGRpc2N1c3NpbmcgY29udHJvbCBwbGFuZSByZXF1 aXJlbWVudHMuDQoNCiAgIFJvbg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IEZyaWRheSwgSnVseSAxOCwg MjAxNCAzOjI3IEFNDQpUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9yZw0KQ2M6IG1wbHNAaWV0Zi5v cmc7IDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gW3NwcmluZ10gSG93IHRv IGNhcnJ5IG1ldGFkYXRhL2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQNCg0KQWxsLA0KDQpJcyB0 aGUgaWRlYSBvZiB1c2luZyBkYXRhIHBsYW5lIHRvIGNhcnJ5IGNvbXBsZXRlIG1ldGFkYXRhIGlz ICJ0aGUgd2F5IiBvciAiYSB3YXkiIG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRo aXMgYmVlbiBhbHJlYWR5IGRpc2N1c3NlZCA/DQoNCkkgd291bGQgcmF0aGVyIGNvbnNpZGVyIHRv IGNhcnJ5IG1ldGFkYXRhIGluIGNvbnRyb2wgcGxhbmUgYW5kIG9ubHkgYXR0YWNoIGEgcmVmZXJl bmNlX2lkIChhbmQgb25seSB3aGVuIGl0IGlzIG5lZWRlZCkgdG8gdGhlIGRhdGEgcGxhbmUuDQoN ClJncywNClIuDQoNCg0KDQoNCk9uIEZyaSwgSnVsIDE4LCAyMDE0IGF0IDM6NTggQU0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSBhbGwsDQoNCkknbSBub3cgY29uc2lkZXJpbmcgaG93IHRvIGNhcnJ5IG1ldGFkYXRh L2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQuIEkganVzdCBub3RpY2VkIHRoYXQgZHJhZnQtZ3Vp Y2hhcmQtbXBscy1tZXRhZGF0YS0wMCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z3VpY2hhcmQtbXBscy1tZXRhZGF0YS0wMCNwYWdlLTYpIHByb3Bvc2VzIGEgd2F5IHRvIGNhcnJ5 IG1ldGFkYXRhL2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQgKHNlZSBiZWxvdyk6DQoNCiIzLiAg TWV0YWRhdGEgQ2hhbm5lbCBIZWFkZXIgRm9ybWF0DQoNCiAgIFRoZSBwcmVzZW5jZSBvZiBtZXRh ZGF0YSB3aXRoaW4gYW4gTVBMUyBwYWNrZXQgbXVzdCBiZSBpbmRpY2F0ZWQgaW4NCiAgIHRoZSBl bmNhcHN1bGF0aW9uLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoYXQgdGhlIEctQUNoIEdlbmVy aWMNCiAgIEFzc29jaWF0ZWQgQ2hhbm5lbCBMYWJlbCAoR0FMKSBbUkZDNTU4Nl0gd2l0aCBsYWJl bCB2YWx1ZSAxMyBpcw0KICAgdXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gIFRoZSBHQUwgbGFi ZWwgcHJvdmlkZXMgYSBtZXRob2QgdG8NCiAgIGlkZW50aWZ5IHRoYXQgYSBwYWNrZXQgY29udGFp bnMgYW4gIkFzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXIgKEFDSCkiDQogICBmb2xsb3dlZCBieSBh IG5vbi1zZXJ2aWNlIHBheWxvYWQuDQoNCiAgIFtSRkM1NTg2XSBpZGVudGlmaWVzIHRoZSBHLUFD aCBHZW5lcmljIEFzc29jaWF0ZWQgQ2hhbm5lbCBieSBzZXR0aW5nDQogICB0aGUgZmlyc3Qgbmli YmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBib3R0b20gbGFiZWwN CiAgIGluIHRoZSBzdGFjayBpZiB0aGUgR0FMIGxhYmVsIGlzIHByZXNlbnQsIHRvIDAwMDFiLiAg RnVydGhlcg0KICAgW1JGQzU1ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRv IGNhcnJ5IHVzZXIgZGF0YQ0KICAgdHJhZmZpYy4gIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4g ZXh0ZW5zaW9uIHRvIGFsbG93IHRoZSBmaXJzdA0KICAgbmliYmxlIG9mIHRoZSBBQ0ggdG8gYmUg c2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBmb2xsb3dpbmcgdGhlIEdBTCwgYmUNCiAgIGludGVycHJl dGVkIHVzaW5nIHRoZSBzZW1hbnRpY3MgZGVmaW5lZCBpbg0KICAgW0ktRC5ndWljaGFyZC1tZXRh ZGF0YS1oZWFkZXJdIHRvIGFsbG93IG1ldGFkYXRhIHRvIGJlIGNhcnJpZWQNCiAgIHRocm91Z2gg dGhlIEctQUNoIGNoYW5uZWwuIg0KDQpIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZSBzcGVjaWFs IHVzYWdlIG9mIHRoZSBHQUwgYXMgbWVudGlvbmVkIGFib3ZlIHN0aWxsIGNvbmZsaWN0cyB3aXRo IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IHF1b3RlZCBmcm9tIFtSRkM1NTg2XToNCg0KIiAgVGhl IEdBTCBNVVNUIE5PVCBhcHBlYXIgaW4gdGhlIGxhYmVsIHN0YWNrIHdoZW4gdHJhbnNwb3J0aW5n IG5vcm1hbA0KICAgdXNlci1wbGFuZSBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIHdoZW4gcHJlc2Vu dCwgdGhlIEdBTCBNVVNUIE5PVA0KICAgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIGluIHRoZSBsYWJl bCBzdGFjay4iDQoNCkkgd29uZGVyIHdoZXRoZXIgdGhlIHNwZWNpYWwgdXNhZ2Ugb2YgdGhlIEdB TCBhcyBwcm9wb3NlZCBpbiB0aGUgYWJvdmUgZHJhZnQgd291bGQgcmVzdWx0IGluIGFueSBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IGlzc3VlLiBJbiBhZGRpdGlvbiwgSSB3b25kZXIgd2hldGhlciBp dCdzIHdvcnRod2hpbGUgdG8gcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YgaW50cm9kdWNp bmcgYSBQcm90b2NvbCBUeXBlIChQVCkgZmllbGQgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIGJvdHRv bSBvZiB0aGUgTVBMUyBsYWJlbCBzdGFjay4gV2l0aCBzdWNoIFBUIGZpZWxkLCBhbnkga2luZCBv ZiBmdXR1cmUgTVBMUyBwYXlsb2FkIChlLmcuLCBtZXRhZGF0YSBoZWFkZXIgb3IgTlNIKSBjYW4g YmUgZWFzaWx5IGlkZW50aWZpZWQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcg bGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvYmVydCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkluYmFuZCBpcyBvbmUgd2F5IC0tIGl0IHNpbXBsaWZpZXMgdGhpbmdzIGF0IHRo ZSBjb3N0IG9mIHBhY2tldCBncm93dGguJm5ic3A7Jm5ic3A7IE91dC1vZi1iYW5kIChpLmUuLCBz aWduYWxpbmcpIGlzIGFub3RoZXIgd2F5IOKAkyBpdCBhZGRzIGNvbXBsZXhpdHkgYnV0IGRvZXNu 4oCZdCBncm93DQogdGhlIGRhdGEgcGxhbmUgcGFja2V0cy4mbmJzcDsmbmJzcDsgQ29uZ3J1ZW50 IG91dC1vZi1iYW5kIGlzIGEgdmFyaWF0aW9uIG9uIG91dC1vZi1iYW5kIHRoYXQgbWF5IHBhcnRp YWxseSByZWR1Y2Ugb3V0LW9mLWJhbmQgY29tcGxleGl0eS4mbmJzcDsmbmJzcDsmbmJzcDsgSSB0 aGluayBtYW55IG9waW5pb25zIG9uIHRoZSB0aHJlYWQgaGF2ZSBiZWVuIHRoYXQgYWxsIGFyZSBp biBzY29wZSwgYXJjaGl0ZWN0dXJhbGx5LiZuYnNwOyZuYnNwOyZuYnNwOyBEcmFmdC16aGFuZy1z ZmMtc2NoIChJIGFtIGEgY28tYXV0aG9yKSwNCiBmb3IgZXhhbXBsZSwgZGVmaW5lcyBpbmJhbmQg bWV0YWRhdGEgZXhwbGljaXRseSwgYnV0IHN0YXRlcyBpbiB0ZXh0IHRoYXQgb3V0LW9mLWJhbmQg aXMgcG9zc2libGUsIHRvby4mbmJzcDsmbmJzcDsmbmJzcDsgSeKAmW0gc3VyZSB0aGlzIHdpbGwg YmUgYSB0b3BpYyBvZiBkaXNjdXNzaW9uIHdoZW4gd2Ugc3RhcnQgZGlzY3Vzc2luZyBjb250cm9s IHBsYW5lIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE4LCAyMDE0IDM6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IFh1 eGlhb2h1OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7ICZsdDtz cHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBbc3ByaW5n XSBIb3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXMgdGhlIGlkZWEgb2YgdXNpbmcgZGF0 YSBwbGFuZSB0byBjYXJyeSBjb21wbGV0ZSBtZXRhZGF0YSBpcyAmcXVvdDt0aGUgd2F5JnF1b3Q7 IG9yICZxdW90O2Egd2F5JnF1b3Q7IG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRo aXMgYmVlbiBhbHJlYWR5IGRpc2N1c3NlZCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgd291bGQgcmF0aGVyIGNvbnNpZGVyIHRvIGNhcnJ5 IG1ldGFkYXRhIGluIGNvbnRyb2wgcGxhbmUgYW5kIG9ubHkgYXR0YWNoIGEgcmVmZXJlbmNlX2lk IChhbmQgb25seSB3aGVuIGl0IGlzIG5lZWRlZCkgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJncyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDE4LCAyMDE0 IGF0IDM6NTggQU0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGws PGJyPg0KPGJyPg0KSSdtIG5vdyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0YWRhdGEvY29u dGV4dCBpbiBhbiBNUExTIHBhY2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFmdC1ndWljaGFy ZC1tcGxzLW1ldGFkYXRhLTAwICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwI3BhZ2UtNiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWd1aWNoYXJkLW1wbHMtbWV0YWRhdGEtMDAj cGFnZS02PC9hPikNCiBwcm9wb3NlcyBhIHdheSB0byBjYXJyeSBtZXRhZGF0YS9jb250ZXh0IGlu IGFuIE1QTFMgcGFja2V0IChzZWUgYmVsb3cpOjxicj4NCjxicj4NCiZxdW90OzMuICZuYnNwO01l dGFkYXRhIENoYW5uZWwgSGVhZGVyIEZvcm1hdDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUg cHJlc2VuY2Ugb2YgbWV0YWRhdGEgd2l0aGluIGFuIE1QTFMgcGFja2V0IG11c3QgYmUgaW5kaWNh dGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBlbmNhcHN1bGF0aW9uLiAmbmJzcDtUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhhdCB0aGUgRy1BQ2ggR2VuZXJpYzxicj4NCiZuYnNwOyAmbmJzcDtB c3NvY2lhdGVkIENoYW5uZWwgTGFiZWwgKEdBTCkgW1JGQzU1ODZdIHdpdGggbGFiZWwgdmFsdWUg MTMgaXM8YnI+DQombmJzcDsgJm5ic3A7dXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gJm5ic3A7 VGhlIEdBTCBsYWJlbCBwcm92aWRlcyBhIG1ldGhvZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtpZGVu dGlmeSB0aGF0IGEgcGFja2V0IGNvbnRhaW5zIGFuICZxdW90O0Fzc29jaWF0ZWQgQ2hhbm5lbCBI ZWFkZXIgKEFDSCkmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7Zm9sbG93ZWQgYnkgYSBub24tc2Vy dmljZSBwYXlsb2FkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtbUkZDNTU4Nl0gaWRlbnRpZmll cyB0aGUgRy1BQ2ggR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5uZWwgYnkgc2V0dGluZzxicj4NCiZu YnNwOyAmbmJzcDt0aGUgZmlyc3QgbmliYmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBm b2xsb3dzIHRoZSBib3R0b20gbGFiZWw8YnI+DQombmJzcDsgJm5ic3A7aW4gdGhlIHN0YWNrIGlm IHRoZSBHQUwgbGFiZWwgaXMgcHJlc2VudCwgdG8gMDAwMWIuICZuYnNwO0Z1cnRoZXI8YnI+DQom bmJzcDsgJm5ic3A7W1JGQzU1ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRv IGNhcnJ5IHVzZXIgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljLiAmbmJzcDtUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiB0byBhbGxvdyB0aGUgZmlyc3Q8YnI+DQombmJz cDsgJm5ic3A7bmliYmxlIG9mIHRoZSBBQ0ggdG8gYmUgc2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBm b2xsb3dpbmcgdGhlIEdBTCwgYmU8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJwcmV0ZWQgdXNpbmcg dGhlIHNlbWFudGljcyBkZWZpbmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1tJLUQuZ3VpY2hhcmQt bWV0YWRhdGEtaGVhZGVyXSB0byBhbGxvdyBtZXRhZGF0YSB0byBiZSBjYXJyaWVkPGJyPg0KJm5i c3A7ICZuYnNwO3Rocm91Z2ggdGhlIEctQUNoIGNoYW5uZWwuJnF1b3Q7PGJyPg0KPGJyPg0KSG93 ZXZlciwgaXQgc2VlbXMgdGhhdCB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIG1lbnRp b25lZCBhYm92ZSBzdGlsbCBjb25mbGljdHMgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBx dW90ZWQgZnJvbSBbUkZDNTU4Nl06PGJyPg0KPGJyPg0KJnF1b3Q7ICZuYnNwO1RoZSBHQUwgTVVT VCBOT1QgYXBwZWFyIGluIHRoZSBsYWJlbCBzdGFjayB3aGVuIHRyYW5zcG9ydGluZyBub3JtYWw8 YnI+DQombmJzcDsgJm5ic3A7dXNlci1wbGFuZSBwYWNrZXRzLiAmbmJzcDtGdXJ0aGVybW9yZSwg d2hlbiBwcmVzZW50LCB0aGUgR0FMIE1VU1QgTk9UPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGVhciBt b3JlIHRoYW4gb25jZSBpbiB0aGUgbGFiZWwgc3RhY2suJnF1b3Q7PGJyPg0KPGJyPg0KSSB3b25k ZXIgd2hldGhlciB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRo ZSBhYm92ZSBkcmFmdCB3b3VsZCByZXN1bHQgaW4gYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg aXNzdWUuIEluIGFkZGl0aW9uLCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgd29ydGh3aGlsZSB0byBy ZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRyb2R1Y2luZyBhIFByb3RvY29sIFR5cGUg KFBUKSBmaWVsZCBpbW1lZGlhdGVseQ0KIGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIE1QTFMgbGFi ZWwgc3RhY2suIFdpdGggc3VjaCBQVCBmaWVsZCwgYW55IGtpbmQgb2YgZnV0dXJlIE1QTFMgcGF5 bG9hZCAoZS5nLiwgbWV0YWRhdGEgaGVhZGVyIG9yIE5TSCkgY2FuIGJlIGVhc2lseSBpZGVudGlm aWVkLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_-- From nobody Fri Jul 18 05:47: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 6DB161A0A6D for ; Fri, 18 Jul 2014 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 jdHrDuFhhHfO for ; Fri, 18 Jul 2014 05:47:22 -0700 (PDT) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415B91B2979 for ; Fri, 18 Jul 2014 05:47:21 -0700 (PDT) Received: from mtaout-mcb01.mx.aol.com (mtaout-mcb01.mx.aol.com [172.26.50.173]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id 40F89700000BF; Fri, 18 Jul 2014 08:47:20 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-mcb01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E725C38000089; Fri, 18 Jul 2014 08:47:19 -0400 (EDT) Date: Fri, 18 Jul 2014 08:47:19 -0400 From: "mikebianc@aol.com" To: linda.dunbar@huawei.com, sfc@ietf.org Message-ID: <825388104.15672.1405687639597.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15671_2006854498.1405687639597" X-Originating-IP: 10.181.180.224, 10.181.180.224 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405687640; bh=Rgg5v0jpQ8l/t86O4fSvsIhM3ea5Rj1BOPexfmCIqaE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=GY93i55AfnhC+SkMcES1tN1o1VBIAS2CnK2fcgWl2C75ktxUNmjiZIkVKoJTKiIII o6ueac0/dFaQO/+lh4ZlOnAEcQyCjV6ZOBmltt1qoeBLe5pEyK5NTOClGvj9NApHQG l5dpdYN7yypkxLQQ/SUV0/wxyMM6NFHYZDTFEQ6k= x-aol-sid: 3039ac1a32ad53c9175702ac X-AOL-IP: 205.188.178.60 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LKS64yxTJIHbtGA4WLKEtb--ilk Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 12:47:23 -0000 ------=_Part_15671_2006854498.1405687639597 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe that the architecture draft would refer to this (inserting a scru= bber into the chain) as branching as it would technically be a new chain (a= ll SFIs of an SF would be the same and interchangeable). From: Ron_Parker@affirmednetworks.com To: Linda Dunbar,Hongyu Li (Julio),Joel M. Halpern,Tom Taylor,sfc@ietf.org Sent: Thursday, July 17, 2014 Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? Linda, I think that what you describe is more of a dynamic chain assignment. =C2= =A0 A particular chain either does or does not include a Service Function t= o perform Security Scrubbing Center. =C2=A0 The ingress classifier may have= taken your packet size into account to choose an abstract chain that did, = indeed, include your Security Scrubbing Center. =C2=A0 But once selected an= d barring reclassification, the SFF's are obligated to respect the chain as= signment selected by the ingress classifier. =C2=A0 Thus, the SFF's have fr= eedom, with possible policy constraints, to choose any instance of any part= icular service function within the chain, but not to shift to a different c= hain that describes a different sequence of service functions. =C2=A0 Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, July 17= , 2014 7:12 PMTo: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylo= r; sfc@ietf.orgSubject: RE: [sfc] Inconsistency regarding role of SFC metad= ata in forwarding?Ron, You said: =C2=A0 For a new flow, next SFF selection = by an SFF SFF MUST be based on the chain ID and MAY be based on metadata an= d/or locally known policy. =C2=A0 Next SFI selection by an SFF MUST be base= d on the chain ID and service function index within the chain and MAY be ba= sed on metadata and/or locally known policy.[Linda] "next SFI selection" cr= iteria can even be based on packet size, like an AntiDos system detects a t= hreat (packet size=3D57) and needs to steer all packets with size =3D 57 to= Security Scrubbing Center. The next SFF selection can also be based on so= mething else or in combination of Chain ID (like traffic metrics, etc). My = point is that Chain ID is only to identify the Chain, but the selection cri= teria can be based on various factors. =C2=A0 Linda________________________= _______________________sfc mailing listsfc@ietf.orghttps://www.ietf.org/mai= lman/listinfo/sfc ------=_Part_15671_2006854498.1405687639597 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I believe that the = architecture draft would refer to this (inserting a scrubber into the chain= ) as branching as it would technically be a new chain (all SFIs of an SF wo= uld be the same and interchangeable).





From: Ron_Parker= @affirmednetworks.com<Ron_Parker@affirmednetworks.com>
To: = Linda Dunbar<linda.dunbar@huawei.com>,Hongyu Li (Julio)<hongyu.li@= huawei.com>,Joel M. Halpern<jmh@joelhalpern.com>,Tom Taylor<tom= .taylor.stds@gmail.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 17, 2014
Subject: Re: [sfc] Inconsistency regardi= ng role of SFC metadata in forwarding?

Linda,

= I think that what you describe is more of a dynamic chain assignment.  = ; A particular chain either does or does not include a Service Function to = perform Security Scrubbing Center.   The ingress classifier may have t= aken your packet size into account to choose an abstract chain that did, in= deed, include your Security Scrubbing Center.   But once selected and = barring reclassification, the SFF's are obligated to respect the chain assi= gnment selected by the ingress classifier.   Thus, the SFF's have free= dom, with possible policy constraints, to choose any instance of any partic= ular service function within the chain, but not to shift to a different cha= in that describes a different sequence of service functions.

 = Ron


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


From: Lind= a Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Thursday, Ju= ly 17, 2014 7:12 PM
To: Ron Parker; Hongyu Li (Julio); Joel M= . Halpern; Tom Taylor; sfc@ietf.org
Subject: RE: [sfc] Incons= istency regarding role of SFC metadata in forwarding?

Ron,

You said:

  For a new flow, next SFF selection by an SFF SFF MUST be bas= ed on the chain ID and MAY be based on metadata and/or locally known policy= .   Next SFI selection by an SFF MUST be based on the chain ID and ser= vice function index within the chain and MAY be based on metadata and/or lo= cally known policy.

[Linda] "next SFI selectio= n" criteria can even be based on packet size, like an AntiDos system detect= s a threat (packet size=3D57) and needs to steer all packets with size =3D = 57 to Security Scrubbing Center. The next SFF selection can also be based = on something else or in combination of Chain ID (like traffic metrics, etc)= .

My point is that Chain ID is only to identi= fy the Chain, but the selection criteria can be based on various factors. &= nbsp;

Linda

____= ___________________________________________
sfc mailing list<= br class=3D"">sfc@ietf.org
https://www.ietf.org/mailman/listi= nfo/sfc
------=_Part_15671_2006854498.1405687639597-- From nobody Fri Jul 18 05:52: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 9A1631B29F3 for ; Fri, 18 Jul 2014 05:52:46 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xyHqHucAJ0p4 for ; Fri, 18 Jul 2014 05:52:44 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86CF1B2900 for ; Fri, 18 Jul 2014 05:52:44 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 0142A53DFB; Fri, 18 Jul 2014 05:52:40 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Fri, 18 Jul 2014 05:52:39.960 -0700 x-echoworx-msg-id: f41fa748-3f19-4b35-8dcb-dcb53eea536c x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 501; Fri, 18 Jul 2014 05:52:39 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D0BD853DFB; Fri, 18 Jul 2014 05:52:39 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Fri, 18 Jul 2014 05:52:44 -0700 From: Ron Parker To: "mikebianc@aol.com" , "linda.dunbar@huawei.com" , "sfc@ietf.org" Thread-Topic: [sfc] Inconsistency regarding role of SFC metadata in forwarding? Thread-Index: AQHPoGcZviim+pzeokmGAZvO4foLopui2N0A///KZ5CAAro2gP//iwEQgAFY4YD//4uZgA== Date: Fri, 18 Jul 2014 12:52:43 +0000 Message-ID: References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> <825388104.15672.1405687639597.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: <825388104.15672.1405687639597.JavaMail.tomcat@mgs-aad01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BCA90MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BUC9DYlGZJCbtBhLVFXxxzVJjNg Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 12:52:46 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BCA90MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1pa2UuDQoNCkkgYWdyZWUgdGhhdCB0aGlzIGlzIGJyYW5jaGluZy4gICBJcyB0aGUgbmV3 IGJyYW5jaCBkZXNjcmliZWQgYXMgYSBuZXcgY2hhaW4/ICAgSeKAmW0gbm90IHN1cmUuICAgQnV0 LCBicmFuY2hpbmcsIGluIHRoZSBhcmNoaXRlY3R1cmUsIG9jY3VycyB2aWEgcmVjbGFzc2lmaWNh dGlvbi4gICBJIHRoaW5rIExpbmRh4oCZcyBjYXNlIGlzIHN1cHBvcnRlZCwgYnV0IG9ubHkgaWYg dGhlIGJyYW5jaCBwb2ludCBpcyBhIGNsYXNzaWZpZXIuICAgSSB3YXMgdHJ5aW5nIHRvIHBvaW50 IG91dCB0aGF0IHRoZSBTRkYgZnVuY3Rpb24sIGFzIEkgZW52aXNpb24gaXQsIGlzIG5vdCBhbGxv d2VkIHRvIGJyYW5jaCAoYWx0aG91Z2ggYW5kIFNGRiBhbmQgY2xhc3NpZmllciBjb3VsZCBjZXJ0 YWlubHkgYmUgY28tbG9jYXRlZCkuDQoNCiAgIFJvbg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbWlrZWJpYW5jQGFvbC5jb20NClNlbnQ6 IEZyaWRheSwgSnVseSAxOCwgMjAxNCA4OjQ3IEFNDQpUbzogbGluZGEuZHVuYmFyQGh1YXdlaS5j b207IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIEluY29uc2lzdGVuY3kgcmVnYXJk aW5nIHJvbGUgb2YgU0ZDIG1ldGFkYXRhIGluIGZvcndhcmRpbmc/DQoNCkkgYmVsaWV2ZSB0aGF0 IHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgd291bGQgcmVmZXIgdG8gdGhpcyAoaW5zZXJ0aW5nIGEg c2NydWJiZXIgaW50byB0aGUgY2hhaW4pIGFzIGJyYW5jaGluZyBhcyBpdCB3b3VsZCB0ZWNobmlj YWxseSBiZSBhIG5ldyBjaGFpbiAoYWxsIFNGSXMgb2YgYW4gU0Ygd291bGQgYmUgdGhlIHNhbWUg YW5kIGludGVyY2hhbmdlYWJsZSkuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t JTNjUm9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+DQpUbzogTGluZGEgRHVuYmFyPGxp bmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+LEhv bmd5dSBMaSAoSnVsaW8pPGhvbmd5dS5saUBodWF3ZWkuY29tPG1haWx0bzpob25neXUubGlAaHVh d2VpLmNvbT4+LEpvZWwgTS4gSGFscGVybjxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tPj4sVG9tIFRheWxvcjx0b20udGF5bG9yLnN0ZHNAZ21haWwuY29tPG1h aWx0bzp0b20udGF5bG9yLnN0ZHNAZ21haWwuY29tPj4sc2ZjQGlldGYub3JnPHNmY0BpZXRmLm9y ZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE3LCAyMDE0DQpT dWJqZWN0OiBSZTogW3NmY10gSW5jb25zaXN0ZW5jeSByZWdhcmRpbmcgcm9sZSBvZiBTRkMgbWV0 YWRhdGEgaW4gZm9yd2FyZGluZz8NCg0KTGluZGEsDQoNCkkgdGhpbmsgdGhhdCB3aGF0IHlvdSBk ZXNjcmliZSBpcyBtb3JlIG9mIGEgZHluYW1pYyBjaGFpbiBhc3NpZ25tZW50LiAgIEEgcGFydGlj dWxhciBjaGFpbiBlaXRoZXIgZG9lcyBvciBkb2VzIG5vdCBpbmNsdWRlIGEgU2VydmljZSBGdW5j dGlvbiB0byBwZXJmb3JtIFNlY3VyaXR5IFNjcnViYmluZyBDZW50ZXIuICAgVGhlIGluZ3Jlc3Mg Y2xhc3NpZmllciBtYXkgaGF2ZSB0YWtlbiB5b3VyIHBhY2tldCBzaXplIGludG8gYWNjb3VudCB0 byBjaG9vc2UgYW4gYWJzdHJhY3QgY2hhaW4gdGhhdCBkaWQsIGluZGVlZCwgaW5jbHVkZSB5b3Vy IFNlY3VyaXR5IFNjcnViYmluZyBDZW50ZXIuICAgQnV0IG9uY2Ugc2VsZWN0ZWQgYW5kIGJhcnJp bmcgcmVjbGFzc2lmaWNhdGlvbiwgdGhlIFNGRidzIGFyZSBvYmxpZ2F0ZWQgdG8gcmVzcGVjdCB0 aGUgY2hhaW4gYXNzaWdubWVudCBzZWxlY3RlZCBieSB0aGUgaW5ncmVzcyBjbGFzc2lmaWVyLiAg IFRodXMsIHRoZSBTRkYncyBoYXZlIGZyZWVkb20sIHdpdGggcG9zc2libGUgcG9saWN5IGNvbnN0 cmFpbnRzLCB0byBjaG9vc2UgYW55IGluc3RhbmNlIG9mIGFueSBwYXJ0aWN1bGFyIHNlcnZpY2Ug ZnVuY3Rpb24gd2l0aGluIHRoZSBjaGFpbiwgYnV0IG5vdCB0byBzaGlmdCB0byBhIGRpZmZlcmVu dCBjaGFpbiB0aGF0IGRlc2NyaWJlcyBhIGRpZmZlcmVudCBzZXF1ZW5jZSBvZiBzZXJ2aWNlIGZ1 bmN0aW9ucy4NCg0KICBSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQoNCkZy b206IExpbmRhIER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KU2VudDog VGh1cnNkYXksIEp1bHkgMTcsIDIwMTQgNzoxMiBQTQ0KVG86IFJvbiBQYXJrZXI7IEhvbmd5dSBM aSAoSnVsaW8pOyBKb2VsIE0uIEhhbHBlcm47IFRvbSBUYXlsb3I7IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtzZmNdIEluY29uc2lzdGVuY3kgcmVnYXJk aW5nIHJvbGUgb2YgU0ZDIG1ldGFkYXRhIGluIGZvcndhcmRpbmc/DQoNClJvbiwNCg0KWW91IHNh aWQ6DQoNCiAgRm9yIGEgbmV3IGZsb3csIG5leHQgU0ZGIHNlbGVjdGlvbiBieSBhbiBTRkYgU0ZG IE1VU1QgYmUgYmFzZWQgb24gdGhlIGNoYWluIElEIGFuZCBNQVkgYmUgYmFzZWQgb24gbWV0YWRh dGEgYW5kL29yIGxvY2FsbHkga25vd24gcG9saWN5LiAgIE5leHQgU0ZJIHNlbGVjdGlvbiBieSBh biBTRkYgTVVTVCBiZSBiYXNlZCBvbiB0aGUgY2hhaW4gSUQgYW5kIHNlcnZpY2UgZnVuY3Rpb24g aW5kZXggd2l0aGluIHRoZSBjaGFpbiBhbmQgTUFZIGJlIGJhc2VkIG9uIG1ldGFkYXRhIGFuZC9v ciBsb2NhbGx5IGtub3duIHBvbGljeS4NCg0KW0xpbmRhXSAibmV4dCBTRkkgc2VsZWN0aW9uIiBj cml0ZXJpYSBjYW4gZXZlbiBiZSBiYXNlZCBvbiBwYWNrZXQgc2l6ZSwgbGlrZSBhbiBBbnRpRG9z IHN5c3RlbSBkZXRlY3RzIGEgdGhyZWF0IChwYWNrZXQgc2l6ZT01NykgYW5kIG5lZWRzIHRvIHN0 ZWVyIGFsbCBwYWNrZXRzIHdpdGggc2l6ZSA9IDU3IHRvIFNlY3VyaXR5IFNjcnViYmluZyBDZW50 ZXIuIFRoZSBuZXh0IFNGRiBzZWxlY3Rpb24gY2FuIGFsc28gYmUgYmFzZWQgb24gc29tZXRoaW5n IGVsc2Ugb3IgaW4gY29tYmluYXRpb24gb2YgQ2hhaW4gSUQgKGxpa2UgdHJhZmZpYyBtZXRyaWNz LCBldGMpLg0KDQpNeSBwb2ludCBpcyB0aGF0IENoYWluIElEIGlzIG9ubHkgdG8gaWRlbnRpZnkg dGhlIENoYWluLCBidXQgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBjYW4gYmUgYmFzZWQgb24gdmFy aW91cyBmYWN0b3JzLg0KDQpMaW5kYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpz ZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BCA90MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpLCBNaWtlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgdGhpcyBp cyBicmFuY2hpbmcuJm5ic3A7Jm5ic3A7IElzIHRoZSBuZXcgYnJhbmNoIGRlc2NyaWJlZCBhcyBh IG5ldyBjaGFpbj8mbmJzcDsmbmJzcDsgSeKAmW0gbm90IHN1cmUuJm5ic3A7Jm5ic3A7IEJ1dCwg YnJhbmNoaW5nLCBpbiB0aGUgYXJjaGl0ZWN0dXJlLCBvY2N1cnMgdmlhIHJlY2xhc3NpZmljYXRp b24uJm5ic3A7Jm5ic3A7DQogSSB0aGluayBMaW5kYeKAmXMgY2FzZSBpcyBzdXBwb3J0ZWQsIGJ1 dCBvbmx5IGlmIHRoZSBicmFuY2ggcG9pbnQgaXMgYSBjbGFzc2lmaWVyLiZuYnNwOyZuYnNwOyBJ IHdhcyB0cnlpbmcgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIFNGRiBmdW5jdGlvbiwgYXMgSSBlbnZp c2lvbiBpdCwgaXMgbm90IGFsbG93ZWQgdG8gYnJhbmNoIChhbHRob3VnaCBhbmQgU0ZGIGFuZCBj bGFzc2lmaWVyIGNvdWxkIGNlcnRhaW5seSBiZSBjby1sb2NhdGVkKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5taWtlYmlhbmNAYW9sLmNvbTxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTgsIDIwMTQgODo0NyBBTTxicj4NCjxiPlRvOjwv Yj4gbGluZGEuZHVuYmFyQGh1YXdlaS5jb207IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NmY10gSW5jb25zaXN0ZW5jeSByZWdhcmRpbmcgcm9sZSBvZiBTRkMgbWV0YWRh dGEgaW4gZm9yd2FyZGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIGJlbGlldmUgdGhhdCB0aGUg YXJjaGl0ZWN0dXJlIGRyYWZ0IHdvdWxkIHJlZmVyIHRvIHRoaXMgKGluc2VydGluZyBhIHNjcnVi YmVyIGludG8gdGhlIGNoYWluKSBhcyBicmFuY2hpbmcgYXMgaXQgd291bGQgdGVjaG5pY2FsbHkg YmUgYSBuZXcgY2hhaW4gKGFsbA0KIFNGSXMgb2YgYW4gU0Ygd291bGQgYmUgdGhlIHNhbWUgYW5k IGludGVyY2hhbmdlYWJsZSkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo2Ljc1cHQ7dGV4dC1hbGlnbjpjZW50ZXIiPg0K PGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJjb2xvcjojOTk5OTk5 IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ni43NXB0Ij48Yj5Gcm9tOiA8L2I+PGEgaHJlZj0ibWFpbHRvOlJvbl9QYXJr ZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20lM2NSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29t Ij5Sb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmx0O1Jvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxiPlRvOiA8L2I+TGluZGEgRHVuYmFyJmx0OzxhIGhy ZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5j b208L2E+Jmd0OyxIb25neXUgTGkgKEp1bGlvKSZsdDs8YSBocmVmPSJtYWlsdG86aG9uZ3l1Lmxp QGh1YXdlaS5jb20iPmhvbmd5dS5saUBodWF3ZWkuY29tPC9hPiZndDssSm9lbCBNLiBIYWxwZXJu Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4u Y29tPC9hPiZndDssVG9tDQogVGF5bG9yJmx0OzxhIGhyZWY9Im1haWx0bzp0b20udGF5bG9yLnN0 ZHNAZ21haWwuY29tIj50b20udGF5bG9yLnN0ZHNAZ21haWwuY29tPC9hPiZndDssc2ZjQGlldGYu b3JnJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U2VudDogPC9iPlRodXJzZGF5LCBKdWx5IDE3LCAyMDE0PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbc2ZjXSBJbmNvbnNpc3RlbmN5IHJlZ2FyZGluZyByb2xlIG9mIFNGQyBtZXRh ZGF0YSBpbiBmb3J3YXJkaW5nPzxicj4NCjxicj4NCkxpbmRhLDxicj4NCjxicj4NCkkgdGhpbmsg dGhhdCB3aGF0IHlvdSBkZXNjcmliZSBpcyBtb3JlIG9mIGEgZHluYW1pYyBjaGFpbiBhc3NpZ25t ZW50LiAmbmJzcDsgQSBwYXJ0aWN1bGFyIGNoYWluIGVpdGhlciBkb2VzIG9yIGRvZXMgbm90IGlu Y2x1ZGUgYSBTZXJ2aWNlIEZ1bmN0aW9uIHRvIHBlcmZvcm0gU2VjdXJpdHkgU2NydWJiaW5nIENl bnRlci4gJm5ic3A7IFRoZSBpbmdyZXNzIGNsYXNzaWZpZXIgbWF5IGhhdmUgdGFrZW4geW91ciBw YWNrZXQgc2l6ZSBpbnRvIGFjY291bnQgdG8gY2hvb3NlDQogYW4gYWJzdHJhY3QgY2hhaW4gdGhh dCBkaWQsIGluZGVlZCwgaW5jbHVkZSB5b3VyIFNlY3VyaXR5IFNjcnViYmluZyBDZW50ZXIuICZu YnNwOyBCdXQgb25jZSBzZWxlY3RlZCBhbmQgYmFycmluZyByZWNsYXNzaWZpY2F0aW9uLCB0aGUg U0ZGJ3MgYXJlIG9ibGlnYXRlZCB0byByZXNwZWN0IHRoZSBjaGFpbiBhc3NpZ25tZW50IHNlbGVj dGVkIGJ5IHRoZSBpbmdyZXNzIGNsYXNzaWZpZXIuICZuYnNwOyBUaHVzLCB0aGUgU0ZGJ3MgaGF2 ZSBmcmVlZG9tLCB3aXRoIHBvc3NpYmxlDQogcG9saWN5IGNvbnN0cmFpbnRzLCB0byBjaG9vc2Ug YW55IGluc3RhbmNlIG9mIGFueSBwYXJ0aWN1bGFyIHNlcnZpY2UgZnVuY3Rpb24gd2l0aGluIHRo ZSBjaGFpbiwgYnV0IG5vdCB0byBzaGlmdCB0byBhIGRpZmZlcmVudCBjaGFpbiB0aGF0IGRlc2Ny aWJlcyBhIGRpZmZlcmVudCBzZXF1ZW5jZSBvZiBzZXJ2aWNlIGZ1bmN0aW9ucy48YnI+DQo8YnI+ DQombmJzcDsgUm9uPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQo8YnI+DQo8YnI+DQpGcm9tOiBMaW5kYSBEdW5iYXIgWzxhIGhyZWY9Im1haWx0bzpsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbSI+bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPC9hPl0N Cjxicj4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE3LCAyMDE0IDc6MTIgUE08YnI+DQpUbzogUm9u IFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbyk7IEpvZWwgTS4gSGFscGVybjsgVG9tIFRheWxvcjsg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KU3Vi amVjdDogUkU6IFtzZmNdIEluY29uc2lzdGVuY3kgcmVnYXJkaW5nIHJvbGUgb2YgU0ZDIG1ldGFk YXRhIGluIGZvcndhcmRpbmc/PGJyPg0KPGJyPg0KUm9uLCA8YnI+DQo8YnI+DQpZb3Ugc2FpZDo8 YnI+DQo8YnI+DQombmJzcDsgRm9yIGEgbmV3IGZsb3csIG5leHQgU0ZGIHNlbGVjdGlvbiBieSBh biBTRkYgU0ZGIE1VU1QgYmUgYmFzZWQgb24gdGhlIGNoYWluIElEIGFuZCBNQVkgYmUgYmFzZWQg b24gbWV0YWRhdGEgYW5kL29yIGxvY2FsbHkga25vd24gcG9saWN5LiAmbmJzcDsgTmV4dCBTRkkg c2VsZWN0aW9uIGJ5IGFuIFNGRiBNVVNUIGJlIGJhc2VkIG9uIHRoZSBjaGFpbiBJRCBhbmQgc2Vy dmljZSBmdW5jdGlvbiBpbmRleCB3aXRoaW4gdGhlIGNoYWluIGFuZCBNQVkgYmUgYmFzZWQNCiBv biBtZXRhZGF0YSBhbmQvb3IgbG9jYWxseSBrbm93biBwb2xpY3kuPGJyPg0KPGJyPg0KW0xpbmRh XSAmcXVvdDtuZXh0IFNGSSBzZWxlY3Rpb24mcXVvdDsgY3JpdGVyaWEgY2FuIGV2ZW4gYmUgYmFz ZWQgb24gcGFja2V0IHNpemUsIGxpa2UgYW4gQW50aURvcyBzeXN0ZW0gZGV0ZWN0cyBhIHRocmVh dCAocGFja2V0IHNpemU9NTcpIGFuZCBuZWVkcyB0byBzdGVlciBhbGwgcGFja2V0cyB3aXRoIHNp emUgPSA1NyB0byBTZWN1cml0eSBTY3J1YmJpbmcgQ2VudGVyLiBUaGUgbmV4dCBTRkYgc2VsZWN0 aW9uIGNhbiBhbHNvIGJlIGJhc2VkIG9uIHNvbWV0aGluZw0KIGVsc2Ugb3IgaW4gY29tYmluYXRp b24gb2YgQ2hhaW4gSUQgKGxpa2UgdHJhZmZpYyBtZXRyaWNzLCBldGMpLiA8YnI+DQo8YnI+DQpN eSBwb2ludCBpcyB0aGF0IENoYWluIElEIGlzIG9ubHkgdG8gaWRlbnRpZnkgdGhlIENoYWluLCBi dXQgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBjYW4gYmUgYmFzZWQgb24gdmFyaW91cyBmYWN0b3Jz LiAmbmJzcDsNCjxicj4NCjxicj4NCkxpbmRhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BCA90MBX021W3CA2exch_-- From nobody Fri Jul 18 05:53: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 570F71B29F4 for ; Fri, 18 Jul 2014 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 KgnL0U_TXWRT for ; Fri, 18 Jul 2014 05:53:20 -0700 (PDT) Received: from omr-d06.mx.aol.com (omr-d06.mx.aol.com [205.188.109.203]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E780D1B29EF for ; Fri, 18 Jul 2014 05:53:19 -0700 (PDT) Received: from mtaout-aan02.mx.aol.com (mtaout-aan02.mx.aol.com [172.27.19.78]) by omr-d06.mx.aol.com (Outbound Mail Relay) with ESMTP id 39A9A70004112; Fri, 18 Jul 2014 08:53:19 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aan02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E4C563800008F; Fri, 18 Jul 2014 08:53:18 -0400 (EDT) Date: Fri, 18 Jul 2014 08:53:18 -0400 From: "mikebianc@aol.com" To: kegray@cisco.com, linda.dunbar@huawei.com Message-ID: <2000511592.15888.1405687998677.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: <849C4D81-B08B-4A76-B203-4CA2FD110D84@cisco.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup>, <4A95BA014132FF49AE685FAB4B9F17F645D9F0EA@dfweml701-chm.china.huawei.com> <849C4D81-B08B-4A76-B203-4CA2FD110D84@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15887_823617101.1405687998676" X-Originating-IP: 10.181.180.224, 10.181.180.224 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405687999; bh=qNmPaOZG/JSRp51nrBeCMEbfVXaux+yKcZt+KYgXZXs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=nZ1ZvMaCGp94I5ZGFz6tD0o3/S1qqMDfhYlbdDFDVsN8QomF7IZeitZ89KSKoRUsJ ddEhvgAcPMu8rlwmLI0Y6uFlwhxaeavfgJNrbwMIo+GJULAWULTVgRKsMITeiaWWy1 NEx20kNHYMBIZBGhEIx/TafaZvZk8ZbRGPbEcnJw= x-aol-sid: 3039ac1b134e53c918be56b0 X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zY8bTIphUBB1s3Vk2VXnM40drb0 Cc: sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 12:53:23 -0000 ------=_Part_15887_823617101.1405687998676 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Correct. =C2=A0The definition (sect 1.3) itself is very open and allows for= a number of header options: > delivering traffic . . . via information carried in the SFC encapsulation= . From: kegray@cisco.com To: Linda Dunbar cc: Henry Fourie,Joel M. Halpern,mohamed.boucadair@orange.com,sfc@ietf.org Sent: Thursday, July 17, 2014 Subject: Re: [sfc] SFC Terminology / Concepts I don't think you should write the document in ignorance of the proposed he= ader either. There's gonna be a header. Both proposals have a service pat= h element (devil's advocate - you have a draft unwritten for a header witho= ut a Service Path abstraction - normalize documents, you're still a minorit= y) and the question from both the editor and the chair were whether we coul= d come to consensus on the meaning of Service Path (which then began the od= dessy of trying to diferentiate it from Service Chain). I don't see hints = at a solution around the use of Service Path that are wildly different enou= gh to say one is favored over the other. I interpreted some of the comments about the Service Chain to be rooted in = the fear that one must forward on the Service Path (not appealing to transp= ort-header-centrists), which may/may_not have been clear. To return to the original question - I haven't really seen a compelling arg= ument why Joel's original proposition will not suffice. Sent from my iPhone >=20 On Jul 17, 2014, at 5:34 PM, "Linda Dunbar" wrote= :> > Agree with what Med said. > > Cheers,> Linda> > -----Original Message-= ----> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadai= r@orange.com> Sent: Thursday, July 17, 2014 12:57 AM> To: Joel M. Halpern; = Henry Fourie; sfc@ietf.org> Subject: Re: [sfc] SFC Terminology / Concepts> = > Hi Joel,> > I fully agree with you about the goal. > > Nevertheless, the = merged document, as it currently stands, includes some solution hints that = come mainly from nsh. I would really hope the document be updated to be neu= tral. > > Cheers,> Med> >> -----Message d'origine----->> De : sfc [mailto:s= fc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoy=C3=A9 : mercred= i 16 juillet 2014 23:47 =C3=80 : Henry Fourie; sfc@ietf.org >> Objet : Re: = [sfc] SFC Terminology / Concepts>> >> I would hope that we can end up with = an archtiecture document that is >> understandable and useful without resor= ting to a specific solution >> document. That is our goal. There probably= are refinements needed to >> achieve that goal.>> >> Yours,>> Joel>> >>> O= n 7/16/14, 5:39 PM, Henry Fourie wrote:>>> Ken,>>> =C2=A0 The Service chain= Header draft >>> https://datatracker.ietf.org/doc/draft->> zhang-sfc-sch/>= >> should answer some of your questions. In particular:>>> >>> In section 4= .2 Mandatory Fields:>>> >>> =C2=A0=C2=A0 Path Identifier: Identifies a full= y instantiated service function>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path. It = represents a sequence of network locators, one for each>>> =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 service function that is to be invoked. Participating SFC e= ntities>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST use this identifier when sel= ecting the next hop for the>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packet or fra= me.>>> >>> In section 4.4 Header Associated Operations:>>> >>> =C2=A0=C2=A0= 3. Service Path Selection. The Service Network Forwarder (SNF) uses>>> =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 the Service Chain Identification information in= the SCH to steer>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the traffic flow along = the SFC path.>>> >>> =C2=A0=C2=A0 4. Service Function Instance Selection. T= he Service Function>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Forwarder (SFF) uses = the Service Chain Identification information>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 in the SCH to locate the service instance and forward the traffic>>> = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flow to the service instance. The mapping of= the Service Chain>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identification to a se= rvice instance can be established through>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= the management/control plane, which is out of scope of this>>> =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 document.>>> >>> - Louis>>> >>> -----Original Messag= e----->>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray >>>= (kegray)>>> Sent: Wednesday, July 16, 2014 11:59 AM>>> To: Thomas D. Nadea= u; sfc-chairs@ietf.org>>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylo= r; Joel M. Halpern;>> mohamed.boucadair@orange.com>>> Subject: Re: [sfc] SF= C Terminology / Concepts>>> >>> Joel, et. all,>>> >>> I think that some of = the questions in architecture (SFP/SFC chasing >>> it's>>> tail) come as pe= ople look forward to the encapsulation/header document.>>> That's probably = unavoidable.>>> >>> When you read the NSH document, the SFP verbiage says t= hat all >>> participants MUST forward on the SP/SPI, but the document doesn= 't say >>> how the SPI is derived/calculated (the vision here could be made= >>> clearer) or what it's relationship is to the transport path (I think >= >> you can't mix>> and>>> match but can accommodate both within the header)= , should you opt for >>> the transport header forwarding.>>> >>> It's obvio= us that some deployments prefer to use the transport header >>> for forward= ing (SR, IGP/anycast) and some prefer a hop-by-hop lookup >>> (which does p= lay into the SPI or "other mechanisms" that populate a >>> service>> table>= >> in the SFF).>>> >>> Perhaps the authors of NSH can suggest verbiage that= makes the >>> relationship between transport-based forwarding and service-= based >>> forwarding (SPI) clearer?>>> >>> This should eliminate/minimize t= he calls for redefinition/recasting >>> our terminology and allow us to mov= e on.>>> >>>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote:>>>> >>>> >>>> =C2=A0=C2=A0 I have gotten a bit lost in the SFF/S= FC discussion, which seems to>> have>>>> gotten needlessly complicated and = convoluted IMHO.>>>> >>>> =C2=A0=C2=A0 Is it possible for the chairs to add= this to the list of things to >>>> discuss at the WG meeting or do we want= to resolve this on the list>> ahead>>>> of the meeting?>>>> >>>> =C2=A0=C2= =A0 --Tom>>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>>= > >>>> wrote:>>>> >>>>> Hi Peng,>>>>> >>>>>> -----Orig= inal Message----->>>>>> From: He, Peng [mailto:phe@ciena.com]>>>>>> Sent: T= uesday, July 15, 2014 9:09 PM>>>>>> To: Xuxiaohu; mohamed.boucadair@orange.= com; Joel M. Halpern; Tom >>>>>> Taylor; sfc@ietf.org; Ron Parker>>>>>> Sub= ject: RE: [sfc] SFC Terminology / Concepts>>>>>> >>>>>> Try to understand t= he three scenarios you listed: you mean the >>>>>> classifier can specify a= (partial or complete) SFP which is a list >>>>>> of SFFs, then each SFF wi= ll>>>>>> (locally) select one of the SF instances under itself for this SF.= >>>>>> For partial SFP case,>>>>> >>>>> In either case, the SFF should be = capable of selecting the >>>>> appropriate instance of a given SF attached = to itself. it's an >>>>> internal load-balancing issue.>>>>> >>>>>> each SF= F will identify the SFI under itself and specify (like a>>>>>> classifier) = next SFF(s).>>>>>> The classifier (and SFF?) could obtain this (SFF) 'path= ' >>>>>> information>>>>>> from either>>>>>> centralized point (e.g., PCE, = controller), or, via a distributed >>>>>> control plane? For partial SFP, w= ill there be a re-classification >>>>>> to decide next SFF(s) or not?>>>>> = >>>>> If you want the SFF to locally determine the appropriate SFF for >>>>= > the next SF, the SFF should have the capability of resolving the >>>>> SF= F for>> the>>>>> next SF based on certain constraints. Of course, it needs = to know >>>>> some information about the SFs in advance, e.g., the informat= ion >>>>> about which SFFs a given SF is attached.>>>>> >>>>> Best regards,= >>>>> Xiaohu>>>>> >>>>>> Regards,>>>>>> Peng>>>>>> >>>>>> >>>>>> >>>>>> ---= --Original Message----->>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Be= half Of Xuxiaohu>>>>>> Sent: Tuesday, July 15, 2014 4:49 AM>>>>>> To: moham= ed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>>>> sfc@ietf.org; = Ron Parker>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts>>>>>> >>>>>>= Hi Med,>>>>>> >>>>>> IMHO, the architecture should allow the classifier to= specify>>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial = SFP need to >>>>>> locally determine the appropriate SFF for the next SF);>= >>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>>= >> determined by the centralized node);>>>>>> 3) an SFC (i.e., each SFF alo= ng the final SFP needs to locally >>>>>> determine the appropriate SFF for = the next SF).>>>>>> >>>>>> In fact, case 3) could be looked as an extreme o= f case 1).>>>>>> >>>>>> Best regards,>>>>>> Xiaohu>>>>>> >>>>>>> -----Origi= nal Message----->>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf O= f >>>>>>> mohamed.boucadair@orange.com>>>>>>> Sent: Tuesday, July 15, 2014 = 3:22 PM>>>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker>>>= >>>> Subject: Re: [sfc] SFC Terminology / Concepts>>>>>>> >>>>>>> Hi Joel,>= >>>>>> >>>>>>> As mentioned in several messages, I'm personally for the use= of >>>>>>> the chain itself is the main information to be conveyed in >>>>= >>> packets to drive>>>>>> forwarding actions.>>>>>>> >>>>>>> I can underst= and that an identifier can be assigned to a path >>>>>>> that is known in a= dvance, but if that path is not known I'm not >>>>>>> sure how an identifie= r can be assigned to it!>>>>>>> >>>>>>> Joel, the use of "path" is really i= nappropriate to refer to >>>>>>> distributed instance selection process for= packets bound to a >>>>>>> given SFC.>>>>>>> >>>>>>> Cheers,>>>>>>> Med>>>= >>>> >>>>>>>> -----Message d'origine----->>>>>>>> De : sfc [mailto:sfc-boun= ces@ietf.org] De la part de Joel M. >>>>>>>> Halpern Envoy=C3=A9 : lundi 14= juillet 2014 21:52 =C3=80 : Tom Taylor; >>>>>>>> sfc@ietf.org; Ron Parker = Objet : Re: [sfc] SFC Terminology / >>>>>>>> Concepts>>>>>>>> >>>>>>>> The = most likely realization of the architecture would be that >>>>>>>> the>> SF= P>>>>>>>> assignment is recorded in an identifier which travels with the >>= >>>>>> packet.>>>>>>>> >>>>>>>> Some folks seem to not want the architectur= e to mandate that.>>>>>>>> >>>>>>>> Yours,>>>>>>>> Joel>>>>>>>> >>>>>>>> >>= >>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote:>>>>>>>>> Your text scares me= because it introduces some new concepts and >>>>>>>>> assumptions.>>>>>>>>= > >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on t= hat:>>>>>>>>> am I right in seeing the implication that when control assign= s >>>>>>>>> an SFP, the assignment is recorded by an identifier wwhich >>>>= >>>>> travels with the>>>>>>> packet?>>>>>>>>> >>>>>>>>> Tom Taylor>>>>>>>>= > >>>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote:>>>>>>>>>> There is on= e missing word in my text. =C2=A0 Please replace my proposed>>>>>>>>>> text= >>>>>>>>>> with:>>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) pro= vides a fully abstract >>>>>>>>>> view of the service functions to be invok= ed and the order in >>>>>>>>>> which they are to be invoked for some partic= ular flow or set >>>>>>>>>> of flows,>> without>>>>>> concern of>>>>>>>>>> = actual service function instance selection. =C2=A0 The Constrained-SFC>>>>>= >>>>> (C-SFC) further allows for policy constraints to be added to >>>>>>>>= >> the SFC affecting the instance selection of one or more of the >>>>>>>>>= > service>>>>>> functions>>>>>>>>>> in the SFC. =C2=A0 Any SFC may have any= number of C-SFC's associated>>>>>>>>>> with>>>>>>>> it.">>>>>>>>>> >>>>>>>= >>> Thanks.>>>>>>>>>> >>>>>>>>>> =C2=A0=C2=A0=C2=A0 Ron>>>>>>>>> ...>>>>>>>= >> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf= Of *David >>>>>>>>>> Allan I>>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 = PM>>>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>>>>> >>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts>>>= >>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where an >>>= >>>>>>> implementation has the option of making scale and resiliency a >>>>= >>>>>> local>>>>>> matter..>>>>>>>>>> >>>>>>>>>> D>>>>>>>>>> >>>>>>>>>> *Fr= om:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>>>>> Guichar= d>>>>>>>>>> (jguichar)>>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM>>>>= >>>>>> *To:* sfc@ietf.org >>>>>>>>>> *Subject:* [sfc] = SFC Terminology / Concepts>>>>>>>>>> >>>>>>>>>> Dear WG:>>>>>>>>>> >>>>>>>>= >> There has been much debate over the last few days with regards >>>>>>>>>= > to SFC concepts. To try and form some consensus around >>>>>>>>>> termino= logy and concepts used to describe the architecture in >>>>>>>>>> the merge= d architecture draft, Joel has kindly suggested the following:>>>>>>>>>> >>= >>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>= >>> abstract notion of service path as a sequence of functions to >>>>>>>>>= > be delivered, and the fully specified notion of exactly what >>>>>>>>>> i= nstances of SFFs the packet will visit when it actually >>>>>>>>>> traverse= s the network. By allowing the control components to >>>>>>>>>> specify the= use of this level of indirection, the deployment >>>>>>>>>> may choose the= degree of SFF instance selection authority that >>>>>>>>>> is delegated to= the network.">>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if t= his clarification is >>>>>>>>>> something that we can get consensus on. If = so, I'll ask Joel >>>>>>>>>> to provide specific text, that reflects the ab= ove, for >>>>>>>>>> inclusion in the merged architecture draft.>>>>>>>>>> >= >>>>>>>>> Thank You,>>>>>>>>>> >>>>>>>>>> Jim>>>>>>>>>> >>>>>>>>>> >>>>>>>>= >> >>>>>>>>>> _______________________________________________>>>>>>>>>> sfc= mailing list>>>>>>>>>> sfc@ietf.org>>>>>>>>>> https://www.ietf.org/mailman= /listinfo/sfc>>>>>>>>> >>>>>>>>> __________________________________________= _____>>>>>>>>> sfc mailing list>>>>>>>>> sfc@ietf.org>>>>>>>>> https://www.= 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.org>>>>= > https://www.ietf.org/mailman/listinfo/sfc>>> >>> ________________________= _______________________>>> sfc mailing list>>> sfc@ietf.org>>> https://www.= ietf.org/mailman/listinfo/sfc>> >> ________________________________________= _______>> sfc mailing list>> sfc@ietf.org>> https://www.ietf.org/mailman/li= stinfo/sfc> > _______________________________________________> sfc mailing = list> sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc> > __________= _____________________________________> sfc mailing list> sfc@ietf.org> http= s://www.ietf.org/mailman/listinfo/sfc______________________________________= _________sfc mailing listsfc@ietf.orghttps://www.ietf.org/mailman/listinfo/= sfc ------=_Part_15887_823617101.1405687998676 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Correct.  The = definition (sect 1.3) itself is very open and allows for a number of header= options:
=

>=
; delivering traffic . . . via information carried in the SFC encaps=
ulation.





From: kegray@cisco.com<kegray@cisco.com&= gt;
To: Linda Dunbar<linda.dunbar@huawei.com>
cc: Henry Fourie<louis.fourie@huawei.com>,Joel M. Halpern<jmh@joelhalpern.com>,mohamed.boucadair@orange.com<mohamed= .boucadair@orange.com>,sfc@ietf.org<sfc@ietf.org>
Sent: = Thursday, July 17, 2014
Subject: Re: [sfc] SFC Terminology / Conc= epts

I don't think you should write the document in i= gnorance of the proposed header either. There's gonna be a header. Both p= roposals have a service path element (devil's advocate - you have a draft u= nwritten for a header without a Service Path abstraction - normalize docume= nts, you're still a minority) and the question from both the editor and the= chair were whether we could come to consensus on the meaning of Service Pa= th (which then began the oddessy of trying to diferentiate it from Service = Chain). I don't see hints at a solution around the use of Service Path tha= t are wildly different enough to say one is favored over the other.

= I interpreted some of the comments about the Service Chain to be rooted in = the fear that one must forward on the Service Path (not appealing to transp= ort-header-centrists), which may/may_not have been clear.

To return = to the original question - I haven't really seen a compelling argument why = Joel's original proposition will not suffice.

Sent from my iPhone
>

On Jul 17, 2014, at 5:34 PM, "Linda Dunbar" &l= t;linda.dunbar@huawei.com> wrote:
>
>= Agree with what Med said.
>
> Cheers,<= br class=3D"">> Linda
>
> -----Origin= al Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com
> Sent: Thursday= , July 17, 2014 12:57 AM
> To: Joel M. Halpern; Henry Four= ie; sfc@ietf.org
> Subject: Re: [sfc] SFC Terminology / Co= ncepts
>
> Hi Joel,
> <= br class=3D"">> I fully agree with you about the goal.
&g= t;
> Nevertheless, the merged document, as it currently s= tands, includes some solution hints that come mainly from nsh. I would real= ly hope the document be updated to be neutral.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : sfc [mai= lto:sfc-bounces@ietf.org] De la part de Joel M. Halpern
>= > Envoy=C3=A9 : mercredi 16 juillet 2014 23:47 =C3=80 : Henry Fourie; sf= c@ietf.org
>> Objet : Re: [sfc] SFC Terminology / Conc= epts
>>
>> I would hope that we ca= n end up with an archtiecture document that is
>> unde= rstandable and useful without resorting to a specific solution
>> document. That is our goal. There probably are refinements ne= eded to
>> achieve that goal.
>> <= br class=3D"">>> Yours,
>> Joel
>= ;>
>>> On 7/16/14, 5:39 PM, Henry Fourie wrote:<= br class=3D"">>>> Ken,
>>>   The Servi= ce chain Header draft
>>> https://datatracker.ietf.= org/doc/draft-
>> zhang-sfc-sch/
>>= > should answer some of your questions. In particular:
>= ;>>
>>> In section 4.2 Mandatory Fields:
>>>
>>>    Path Identi= fier: Identifies a fully instantiated service function
>&g= t;>       path. It represents a sequence of net= work locators, one for each
>>>    &n= bsp;  service function that is to be invoked. Participating SFC entiti= es
>>>       MUST use this = identifier when selecting the next hop for the
>>> &= nbsp;     packet or frame.
>>> <= br class=3D"">>>> In section 4.4 Header Associated Operations:
>>>
>>>    3. Service= Path Selection. The Service Network Forwarder (SNF) uses
>= ;>>       the Service Chain Identification i= nformation in the SCH to steer
>>>    = ;   the traffic flow along the SFC path.
>>&g= t;
>>>    4. Service Function Instance Se= lection. The Service Function
>>>    =    Forwarder (SFF) uses the Service Chain Identification informat= ion
>>>       in the SCH to= locate the service instance and forward the traffic
>>= >       flow to the service instance. The mappi= ng of the Service Chain
>>>     =   Identification to a service instance can be established through
>>>       the management/contro= l plane, which is out of scope of this
>>>  &nb= sp;    document.
>>>
&= gt;>> - Louis
>>>
>>>= -----Original Message-----
>>> From: sfc [mailto:sf= c-bounces@ietf.org] On Behalf Of Ken Gray
>>> (kegr= ay)
>>> Sent: Wednesday, July 16, 2014 11:59 AM
>>> To: Thomas D. Nadeau; sfc-chairs@ietf.org
>>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel= M. Halpern;
>> mohamed.boucadair@orange.com
>>> Subject: Re: [sfc] SFC Terminology / Concepts
>>>
>>> Joel, et. all,
>>>
>>> I think that some of the question= s in architecture (SFP/SFC chasing
>>> it's
>>> tail) come as people look forward to the encapsulation/= header document.
>>> That's probably unavoidable.>>>
>>> When you read the NSH = document, the SFP verbiage says that all
>>> partic= ipants MUST forward on the SP/SPI, but the document doesn't say
>>> how the SPI is derived/calculated (the vision here could= be made
>>> clearer) or what it's relationship is = to the transport path (I think
>>> you can't mix>> and
>>> match but can accommoda= te both within the header), should you opt for
>>> = the transport header forwarding.
>>>
= >>> It's obvious that some deployments prefer to use the transport= header
>>> for forwarding (SR, IGP/anycast) and so= me prefer a hop-by-hop lookup
>>> (which does play = into the SPI or "other mechanisms" that populate a
>>&= gt; service
>> table
>>> in the = SFF).
>>>
>>> Perhaps the au= thors of NSH can suggest verbiage that makes the
>>>= ; relationship between transport-based forwarding and service-based
>>> forwarding (SPI) clearer?
>>> <= br class=3D"">>>> This should eliminate/minimize the calls for red= efinition/recasting
>>> our terminology and allow u= s to move on.
>>>
>>>> On= 7/16/14 1:23 PM, "Thomas D. Nadeau" <tnadeau@lucidvision.com> wrote:=
>>>>
>>>>
>>>>    I have gotten a bit lost in the SFF/SFC= discussion, which seems to
>> have
>&= gt;>> gotten needlessly complicated and convoluted IMHO.
>>>>
>>>>    Is it possi= ble for the chairs to add this to the list of things to
>= >>> discuss at the WG meeting or do we want to resolve this on the= list
>> ahead
>>>> of the me= eting?
>>>>
>>>>  = ;  --Tom
>>>>
>>>>= ;
>>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xu= xiaohu
>>>> <xuxiaohu@huawei.com>
>>>> wrote:
>>>>
>>>>> Hi Peng,
>>>>>
>>>>>> -----Original Message-----
>= ;>>>>> From: He, Peng [mailto:phe@ciena.com]
&= gt;>>>>> Sent: Tuesday, July 15, 2014 9:09 PM
= >>>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M= . Halpern; Tom
>>>>>> Taylor; sfc@ietf.org= ; Ron Parker
>>>>>> Subject: RE: [sfc] SFC = Terminology / Concepts
>>>>>>
>>>>>> Try to understand the three scenarios you listed= : you mean the
>>>>>> classifier can speci= fy a (partial or complete) SFP which is a list
>>>&= gt;>> of SFFs, then each SFF will
>>>>>&= gt; (locally) select one of the SF instances under itself for this SF.
>>>>>> For partial SFP case,
>= ;>>>>
>>>>> In either case, the S= FF should be capable of selecting the
>>>>> a= ppropriate instance of a given SF attached to itself. it's an
>>>>> internal load-balancing issue.
>>= ;>>>
>>>>>> each SFF will identif= y the SFI under itself and specify (like a
>>>>&g= t;> classifier) next SFF(s).
>>>>>> The = classifier (and SFF?) could obtain this (SFF) 'path'
>&g= t;>>>> information
>>>>>> from = either
>>>>>> centralized point (e.g., PCE,= controller), or, via a distributed
>>>>>>= control plane? For partial SFP, will there be a re-classification
>>>>>> to decide next SFF(s) or not?
>>>>>
>>>>> If you want the S= FF to locally determine the appropriate SFF for
>>>= >> the next SF, the SFF should have the capability of resolving the <= br class=3D"">>>>>> SFF for
>> the
>>>>> next SF based on certain constraints. Of cour= se, it needs to know
>>>>> some information a= bout the SFs in advance, e.g., the information
>>>&= gt;> about which SFFs a given SF is attached.
>>>= >>
>>>>> Best regards,
&g= t;>>>> Xiaohu
>>>>>
>>>>>> Regards,
>>>>>> P= eng
>>>>>>
>>>>&= gt;>
>>>>>>
>>>= >>> -----Original Message-----
>>>>>&= gt; From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
>>>>>> Sent: Tuesday, July 15, 2014 4:49 AM
>>>>>> To: mohamed.boucadair@orange.com; Joel M. H= alpern; Tom Taylor;
>>>>>> sfc@ietf.org; R= on Parker
>>>>>> Subject: Re: [sfc] SFC Ter= minology / Concepts
>>>>>>
&= gt;>>>>> Hi Med,
>>>>>>
>>>>>> IMHO, the architecture should allow the= classifier to specify
>>>>>>
>>>>>> 1) a partial SFP (i.e., some SFFs along that par= tial SFP need to
>>>>>> locally determine = the appropriate SFF for the next SF);
>>>>>>= ; 2) a complete SFP (i.e., the SFF for each SF in the SFC has been
>>>>>> determined by the centralized node);
>>>>>> 3) an SFC (i.e., each SFF along the final = SFP needs to locally
>>>>>> determine the = appropriate SFF for the next SF).
>>>>>> >>>>>> In fact, case 3) could be looked as a= n extreme of case 1).
>>>>>>
>>>>>> Best regards,
>>>>>&= gt; Xiaohu
>>>>>>
>>&g= t;>>>> -----Original Message-----
>>>>= ;>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of
>>>>>>> mohamed.boucadair@orange.com
>>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM
>>>>>>> To: Joel M. Halpern; Tom Taylor; sf= c@ietf.org; Ron Parker
>>>>>>> Subject: = Re: [sfc] SFC Terminology / Concepts
>>>>>>= >
>>>>>>> Hi Joel,
>= ;>>>>>>
>>>>>>> As me= ntioned in several messages, I'm personally for the use of
&= gt;>>>>>> the chain itself is the main information to be = conveyed in
>>>>>>> packets to drive>>>>>> forwarding actions.
>= >>>>>>
>>>>>>> I can = understand that an identifier can be assigned to a path
>= >>>>>> that is known in advance, but if that path is not = known I'm not
>>>>>>> sure how an ident= ifier can be assigned to it!
>>>>>>> >>>>>>> Joel, the use of "path" is really = inappropriate to refer to
>>>>>>> distr= ibuted instance selection process for packets bound to a
>= ;>>>>>> given SFC.
>>>>>>= >
>>>>>>> Cheers,
>= >>>>>> Med
>>>>>>> >>>>>>>> -----Message d'origine----->>>>>>>> De : sfc [mailto:sfc-bounces@i= etf.org] De la part de Joel M.
>>>>>>>&= gt; Halpern Envoy=C3=A9 : lundi 14 juillet 2014 21:52 =C3=80 : Tom Taylor; =
>>>>>>>> sfc@ietf.org; Ron Parker Ob= jet : Re: [sfc] SFC Terminology /
>>>>>>&g= t;> Concepts
>>>>>>>>
>>>>>>>> The most likely realization of the arch= itecture would be that
>>>>>>>> the<= br class=3D"">>> SFP
>>>>>>>> a= ssignment is recorded in an identifier which travels with the
>>>>>>>> packet.
>>>>&g= t;>>>
>>>>>>>> Some folks s= eem to not want the architecture to mandate that.
>>>= ;>>>>>
>>>>>>>> Yours= ,
>>>>>>>> Joel
>>= ;>>>>>>
>>>>>>>> <= br class=3D"">>>>>>>>>> On 7/14/14, 2:37 PM, Tom= Taylor wrote:
>>>>>>>>> Your text= scares me because it introduces some new concepts and
>&= gt;>>>>>>> assumptions.
>>>>= >>>>>
>>>>>>>>> I'= d rather go with Joel's formulation. Clarifying question on that:
>>>>>>>>> am I right in seeing the implica= tion that when control assigns
>>>>>>>&= gt;> an SFP, the assignment is recorded by an identifier wwhich
>>>>>>>>> travels with the
= >>>>>>> packet?
>>>>>>= >>>
>>>>>>>>> Tom Taylor=
>>>>>>>>>
>>= >>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote:>>>>>>>>>> There is one missing = word in my text.   Please replace my proposed
>>&g= t;>>>>>>> text
>>>>>>&= gt;>>> with:
>>>>>>>>>>= ;
>>>>>>>>>> "The Service Func= tion Chain (SFC) provides a fully abstract
>>>>&= gt;>>>>> view of the service functions to be invoked and the= order in
>>>>>>>>>> which the= y are to be invoked for some particular flow or set
>>= >>>>>>>> of flows,
>> without>>>>>> concern of
>>>= >>>>>>> actual service function instance selection. &n= bsp; The Constrained-SFC
>>>>>>>>>= > (C-SFC) further allows for policy constraints to be added to
>>>>>>>>>> the SFC affecting the instan= ce selection of one or more of the
>>>>>>&= gt;>>> service
>>>>>> functions>>>>>>>>>> in the SFC.   Any= SFC may have any number of C-SFC's associated
>>>&g= t;>>>>>> with
>>>>>>>&= gt; it."
>>>>>>>>>>
>>>>>>>>>> Thanks.
>&g= t;>>>>>>>>
>>>>>>&= gt;>>>     Ron
>>>>>&g= t;>>> ...
>>>>>>>>>
>>>>>>>>>
>>>&= gt;>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Be= half Of *David
>>>>>>>>>> Alla= n I
>>>>>>>>>> *Sent:* Monday, = July 14, 2014 2:03 PM
>>>>>>>>>>= ; *To:* Jim Guichard (jguichar); sfc@ietf.org
>>>&g= t;>>>>>> <mailto:sfc@ietf.org>
>&g= t;>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / C= oncepts
>>>>>>>>>>
>>>>>>>>>> I like that text, it strikes a = good balance where an
>>>>>>>>>&g= t; implementation has the option of making scale and resiliency a
>>>>>>>>>> local
>>= >>>> matter..
>>>>>>>>>= ;>
>>>>>>>>>> D
>>>>>>>>>>
>>>>= >>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behal= f Of *Jim
>>>>>>>>>> Guichard<= br class=3D"">>>>>>>>>>> (jguichar)
>>>>>>>>>> *Sent:* Monday, July 14, 201= 4 10:48 AM
>>>>>>>>>> *To:* sfc= @ietf.org <mailto:sfc@ietf.org>
>>>>>>= ;>>>> *Subject:* [sfc] SFC Terminology / Concepts
>>>>>>>>>>
>>>>&g= t;>>>>> Dear WG:
>>>>>>>&= gt;>>
>>>>>>>>>> There h= as been much debate over the last few days with regards
>= >>>>>>>>> to SFC concepts. To try and form some = consensus around
>>>>>>>>>> te= rminology and concepts used to describe the architecture in
= >>>>>>>>>> the merged architecture draft, Joe= l has kindly suggested the following:
>>>>>>= ;>>>>
>>>>>>>>>> "= The SFP provides a level of indirection between the fully
&g= t;>>>>>>>>> abstract notion of service path as a= sequence of functions to
>>>>>>>>&g= t;> be delivered, and the fully specified notion of exactly what
>>>>>>>>>> instances of SFFs the pack= et will visit when it actually
>>>>>>>&= gt;>> traverses the network. By allowing the control components to >>>>>>>>>> specify the use of th= is level of indirection, the deployment
>>>>>= >>>>> may choose the degree of SFF instance selection author= ity that
>>>>>>>>>> is delegat= ed to the network."
>>>>>>>>>> =
>>>>>>>>>> I'd like to ask the= WG as a whole, if this clarification is
>>>>>= ;>>>>> something that we can get consensus on. If so, I'll a= sk Joel
>>>>>>>>>> to provide = specific text, that reflects the above, for
>>>>= >>>>>> inclusion in the merged architecture draft.
>>>>>>>>>>
>>>= ;>>>>>>> Thank You,
>>>>>= >>>>>
>>>>>>>>>>= ; Jim
>>>>>>>>>>
>>>>>>>>>>
>>>>&g= t;>>>>>
>>>>>>>>>&= gt; _______________________________________________
>>&= gt;>>>>>>> sfc mailing list
>>>= >>>>>>> sfc@ietf.org
>>>>>= ;>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>>
>>>>>= >>>> _______________________________________________
>>>>>>>>> sfc mailing list
&= gt;>>>>>>>> sfc@ietf.org
>>>= >>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>>>>
>>>>>&= gt;>> _______________________________________________
&= gt;>>>>>>> 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/list= info/sfc
>>>>>>
>>>= >>> _______________________________________________
= >>>>>> sfc mailing list
>>>>>= ;> sfc@ietf.org
>>>>>> https://www.ietf.= org/mailman/listinfo/sfc
>>>>>
= >>>>> _______________________________________________
>>>>> sfc mailing list
>>>>= ;> sfc@ietf.org
>>>>> https://www.ietf.org/= mailman/listinfo/sfc
>>>
>>>= _______________________________________________
>>>= sfc mailing list
>>> sfc@ietf.org
>= ;>> https://www.ietf.org/mailman/listinfo/sfc
>> =
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org>> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________<= br class=3D"">> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
> > _______________________________________________
> sfc mailing list
> sfc@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/sfc

= _______________________________________________
sfc mailing l= ist
sfc@ietf.org
https://www.ietf.org/mailman/l= istinfo/sfc
------=_Part_15887_823617101.1405687998676-- From nobody Fri Jul 18 06:26: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 710B81B29D9 for ; Fri, 18 Jul 2014 06:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 9YbHa48hCR7l for ; Fri, 18 Jul 2014 06:26:23 -0700 (PDT) Received: from omr-m10.mx.aol.com (omr-m10.mx.aol.com [64.12.143.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44E31B2967 for ; Fri, 18 Jul 2014 06:26:22 -0700 (PDT) Received: from mtaout-aae01.mx.aol.com (mtaout-aae01.mx.aol.com [172.27.1.97]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id 6B1A97000008F; Fri, 18 Jul 2014 09:26:21 -0400 (EDT) Received: from mgs-aaa01.mail.aol.com (mgs-aaa01.mail.aol.com [149.174.106.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 1C7B338000084; Fri, 18 Jul 2014 09:26:21 -0400 (EDT) Date: Fri, 18 Jul 2014 09:26:20 -0400 From: "mikebianc@aol.com" To: Ron_Parker@affirmednetworks.com, linda.dunbar@huawei.com, sfc@ietf.org Message-ID: <1779049460.15977.1405689980928.JavaMail.tomcat@mgs-aaa01.mail.aol.com> In-Reply-To: References: <53C5855B.4050806@gmail.com> <53C587C1.6080506@joelhalpern.com> <6EB34CB5D82C4645B826C56144826EA97EA4E0F2@SZXEMA509-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D9F386@dfweml701-chm.china.huawei.com> <825388104.15672.1405687639597.JavaMail.tomcat@mgs-aad01.mail.aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15976_696980714.1405689980928" X-Originating-IP: 10.181.180.224, 10.181.180.224 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1405689981; bh=iU8VvRCX51csGv7ogsE6T9pHXm1sWksCW5jfAK7+9J0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=EaewMez6ksbQlOc4wO/hYAHBaGBCV8Hoe9qCjMWIr5cotaCIn0lu8PKvka54xqAh2 lOz3kVpIQfHbPo4t8DkDuaWs4o+FnA4+nTX1wKGJcm37eAl/t3ltQEHPzpjJ2Ud5ut 1uZzr4iVWYAGut3Hr0E8aMxPfGnmx9wtd40ca7Ho= x-aol-sid: 3039ac1b016153c9207d365b X-AOL-IP: 149.174.106.43 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2SLasY8nplqOth_ll-9oDgsvkiI Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 13:26:24 -0000 ------=_Part_15976_696980714.1405689980928 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable the draft reads, "typically performed by a classification=C2=A0function co-= resident with a service function", which does not exclude the SFF from recl= assifying. =C2=A0The implication is that a classifier is anything that perf= orms a classification function, thus if a classification function were co-r= esident with an SFF function, it could analogously perform the branching fu= nction. The new branch isn't directly described as a new chain, but the example pro= vided is only possible if it is a new chain per the definition of a chain. To be clear, I was agreeing with you and trying to point out the terminolog= y used in the arch draft to describe what Linda is suggesting. =C2=A0I, per= sonally, find it important to try to normalize the language used in discuss= ions to prevent people from arguing about points on which they agree (as en= tertaining as that might be). Of course, this is assuming I'm interpreting the draft properly and have no= t missed some text that limits the location of branching points or some oth= er crucial bit of information. From: Ron_Parker@affirmednetworks.com To: mikebianc@aol.com,linda.dunbar@huawei.com,sfc@ietf.org Sent: Friday, July 18, 2014 Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? Hi, Mike. =20 I agree that this is branching. Is the new branch described as a new chai= n? I=E2=80=99m not sure. But, branching, in the architecture, occurs vi= a reclassification. =20 I think Linda=E2=80=99s case is supported, but only if the branch point is= a classifier. I was trying to point out that the SFF function, as I envi= sion it, is not allowed to branch (although and SFF and classifier could ce= rtainly be co-located). =20 Ron =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com Sent: Friday, July 18, 2014 8:47 AM To: linda.dunbar@huawei.com; sfc@ietf.org Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? =20 I believe that the architecture draft would refer to this (inserting a scru= bber into the chain) as branching as it would technically be a new chain (a= ll SFIs of an SF would be the same and interchangeable). From: Ron_Parker@affirmednetworks.com To: Linda Dunbar,Hongyu Li (Julio),Joel M. Halpern,Tom Taylor,sfc@ietf.org Sent: Thursday, July 17, 2014 Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? Linda, I think that what you describe is more of a dynamic chain assignment. A p= articular chain either does or does not include a Service Function to perfo= rm Security Scrubbing Center. The ingress classifier may have taken your = packet size into account to choose an abstract chain that did, indeed, include your Security Scrubbing Center= . But once selected and barring reclassification, the SFF's are obligated= to respect the chain assignment selected by the ingress classifier. Thus= , the SFF's have freedom, with possible policy constraints, to choose any instance of any particular service funct= ion within the chain, but not to shift to a different chain that describes = a different sequence of service functions. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, July 17, 2014 7:12 PM To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor;=20 sfc@ietf.org Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng? Ron,=20 You said: For a new flow, next SFF selection by an SFF SFF MUST be based on the cha= in ID and MAY be based on metadata and/or locally known policy. Next SFI = selection by an SFF MUST be based on the chain ID and service function inde= x within the chain and MAY be based on metadata and/or locally known policy. [Linda] "next SFI selection" criteria can even be based on packet size, lik= e an AntiDos system detects a threat (packet size=3D57) and needs to steer = all packets with size =3D 57 to Security Scrubbing Center. The next SFF sel= ection can also be based on something else or in combination of Chain ID (like traffic metrics, etc).=20 My point is that Chain ID is only to identify the Chain, but the selection = criteria can be based on various factors. =20 Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_15976_696980714.1405689980928 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
the draft reads, "<= span style=3D"color: rgb(0, 0, 0); font-size: 1em; font-family: sans-serif,= arial;">typically performed by a classification func= tion co-resident with a service function", which does not exclude th= e SFF from reclassifying.  The implication is that a classifier is any= thing that performs a classification function, thus if a classification fun= ction were co-resident with an SFF function, it could analogously perform t= he branching function.

The new branch isn't direct= ly described as a new chain, but the example provided is only possible if i= t is a new chain per the definition of a chain.

To be clear, I was = agreeing with you and trying to point out the terminology used in the arch = draft to describe what Linda is suggesting.  I, personally, find it im= portant to try to normalize the language used in discussions to prevent peo= ple from arguing about points on which they agree (as entertaining as that = might be).

Of course, this is assuming I'm interpreting t= he draft properly and have not missed some text that limits the location of= branching points or some other crucial bit of information.



From: = Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com>
<= b>To: mikebianc@aol.com<mikebianc@aol.com>,linda.dunbar@huawei.co= m<linda.dunbar@huawei.com>,sfc@ietf.org<sfc@ietf.org>
Sen= t: Friday, July 18, 2014
Subject: RE: [sfc] Inconsistency reg= arding role of SFC metadata in forwarding?

Hi, Mike.

I agree that this is bran= ching. Is the new branch described as a new chain? I=E2=80=99m not sure= . But, branching, in the architecture, occurs via reclassification. =20 I think Linda=E2=80=99s case is supported, but only if the branch point is= a classifier. I was trying to point out that the SFF function, as I envi= sion it, is not allowed to branch (although and SFF and classifier could ce= rtainly be co-located).

Ron<= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mikebianc@aol.com<= /a>
Sent: Friday, July 18, 2014 8:47 AM
To: linda.dunbar@huawei.c= om; sfc@ietf.org
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in f= orwarding?

I believe that the architec= ture draft would refer to this (inserting a scrubber into the chain) as bra= nching as it would technically be a new chain (all SFIs of an SF would be the same and interchangeable).



From: Ron_Parker@affirmednetworks.com<Ron_Parker@affirmednetworks.com&g= t;
To: Linda Dunbar<linda= .dunbar@huawei.com>,Hongyu Li (Julio)<hongyu.li@huawei.com>,Joel M. Halpern<jmh@joelhalpern.com>,Tom Taylor<tom.taylor.stds@gma= il.com>,sfc@ietf.org<sfc@ietf.org>
Sent: Thursday, July 17, 2014
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in f= orwarding?

Linda,

I think that what you describe is more of a dynamic chain assignment. A p= articular chain either does or does not include a Service Function to perfo= rm Security Scrubbing Center. The ingress classifier may have taken your = packet size into account to choose an abstract chain that did, indeed, include your Security Scrubbing Center= . But once selected and barring reclassification, the SFF's are obligated= to respect the chain assignment selected by the ingress classifier. Thus= , the SFF's have freedom, with possible policy constraints, to choose any instance of any particular service funct= ion within the chain, but not to shift to a different chain that describes = a different sequence of service functions.

Ron


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


From: Linda Dunbar [mailto:linda= .dunbar@huawei.com]
Sent: Thursday, July 17, 2014 7:12 PM
To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; sfc@ietf.org
Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwardi= ng?

Ron,

You said:

For a new flow, next SFF selection by an SFF SFF MUST be based on the cha= in ID and MAY be based on metadata and/or locally known policy. Next SFI = selection by an SFF MUST be based on the chain ID and service function inde= x within the chain and MAY be based on metadata and/or locally known policy.

[Linda] "next SFI selection" criteria can even be based on packet size, lik= e an AntiDos system detects a threat (packet size=3D57) and needs to steer = all packets with size =3D 57 to Security Scrubbing Center. The next SFF sel= ection can also be based on something else or in combination of Chain ID (like traffic metrics, etc).

My point is that Chain ID is only to identify the Chain, but the selection = criteria can be based on various factors. =20

Linda

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

------=_Part_15976_696980714.1405689980928-- From nobody Fri Jul 18 07:17: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 D9E821A0AB8 for ; Fri, 18 Jul 2014 07:17:30 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 PHrNNPE6ieDs for ; Fri, 18 Jul 2014 07:17:27 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2E81B2907 for ; Fri, 18 Jul 2014 07:17:26 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 67c29c35.2b68ca449940.2192318.00-2489.6147958.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 18 Jul 2014 14:17:26 +0000 (UTC) X-MXL-Hash: 53c92c761b382621-c1fb460cbbe24ecb5b816c8d19855db324f9fe8c Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b5c29c35.0.2192015.00-2359.6147060.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 18 Jul 2014 14:17:01 +0000 (UTC) X-MXL-Hash: 53c92c5d4eea47e0-42fe5a7547390f1602665eaa4bbd3aa097792862 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6IEGwxn027804; Fri, 18 Jul 2014 10:16:58 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6IEGoWO027633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 10:16:52 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 18 Jul 2014 14:16:21 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Fri, 18 Jul 2014 10:16:20 -0400 From: "NAPIERALA, MARIA H" To: Xuxiaohu , "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Tom Taylor" , "sfc@ietf.org" , Ron Parker Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUP//fmyAgAAU+ACAAMCSAIAAlhpA//+PGQCAAIakcIABADUAgACaNiCAAMWuAIAB1/RQgADGFDA= Date: Fri, 18 Jul 2014 14:16:20 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4D5E6@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330032A9A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082932AE@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B9330033757@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082937A9@NKGEML512-MBS.china.huawei.com> <787AE7BB302AE849A7480A190F8B93300351AB@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294147@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294147@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.157.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=YYkKEXtf c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gqfbR3uhTkYA:10 a=ofMgfj31e3cA:10 a=0uyUlxCMDtUA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 ] X-AnalysisOut: [a=5wV3UnG4zAuj3tZQv6EA:9 a=wPNLvfGTeEIA:10 a=hPjdaMEvmhQA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/t7ETUXgUhJvRf7hHIvUDehKJ3x8 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 14:17:31 -0000 > > >> >-----Message d'origine----- > > >> >De=A0: Xuxiaohu [mailto:xuxiaohu@huawei.com] Envoy=E9=A0: mardi 15 > juillet > > >> >2014 11:50 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom > > >> >Taylor; sfc@ietf.org; Ron Parker Objet=A0: RE: [sfc] SFC Terminolog= y / > > >> >Concepts > > >> > > > >> >Hi Med, > > >> > > > >> >> -----Original Message----- > > >> >> From: mohamed.boucadair@orange.com > > >> >> [mailto:mohamed.boucadair@orange.com] > > >> >> Sent: Tuesday, July 15, 2014 5:35 PM > > >> >> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron > > >> >> Parker > > >> >> Subject: RE: [sfc] SFC Terminology / Concepts > > >> >> > > >> >> Hi Xiaohu, > > >> >> > > >> >> Why a classifier will need specify a path a la ERO? Why it needs > > >> >> to have > > >> >the full > > >> > > > >> >In this way, the path selection process (i.e., selecting the > > >> >appropriate SFF for the next SF based on certain constraints) on th= e > > >> >SFF is greatly simplified. > > >> > > >> [Med] This does not answer to my question why the "classifier" has > > >specifically > > >> to take care of this? How multiple classifiers present in a given > > >> SFC- > > >enabled > > >> domain behave in order to distribute traffic among available Service > > >Function > > >> Nodes? How a classifier can distribute traffic without any conflict > > >> with > > >other LBs > > >> that may be present in the forwarding path? > > >> > > > > [Med] It seems you missed this one. >=20 > As I has mentioned before, once the SFP is determined by the classifier i= n > advance, there is no need for subsequent SFFs to do complex path selectio= n > work anymore (e.g., no need to maintain the SF->SFF mapping table and no > need to resolve the appropriate SFF for the next SF on basis on certain > constraints).=20 Why is this complex? It works today pretty well.=20 And managing, e.g., 160K SFPs per chain is not complex? (4 hop chain with 2= 0 instances/SFFs at each hop) >Of course, in order to optimize the traffic forwarding path (i.e., > the SFP), a stateful PCE could be used to do the path computation work. B= y > the way, in the distributed and dynamic SFP selection process (i.e., each= SFF > independently determine the appropriate SFF for the next SF), how to > ensure that optimization of the traffic forwarding path? Carrying the path information in the packet is not the only way to implemen= t traffic engineering. An SFC system can be instructed to choose a specific SF instance. This is s= till a service chain, which just happens to use a specific SF instance (amo= ng many) as opposed to a service chain where that choice is arbitrary. > > >> >> knowledge of the involved SF instances? Wouldn't this require th= e > > >> >classifier to > > >> >> be fed with additional information to drive its selection process= ? > > >> >> Is > > >> >this > > >> > > > >> >The classifier could request the PCE to do the SFP computation (see > > >> >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there > > >> >is no need for the classifier to be fed with additional information= . > > >> > > >> [Med] Functionally, the classifier will need a path computation > > >component. > > >> Whether these two are co-located or separated is implementation- > specific. > > >My > > >> concern is to require that path computation component as a > mandatory > > >> component for the architecture. I think this is not justified. > > > > > >If the SFP computation is performed by the PCE, the classifier just > > >needs to accept the computation result returned by the PCE and then > > >impose the SFP info on the selected packets. In other words, the > > >classifier doesn't need that SFP computation component anymore. > > >Furthermore, if the classifier is just allowed to impose the SFC info > > >on the selected packet, it doesn't need the SFP computation component > as > > well. > > > > [Med] But still, for the sake of interoperability, the classifier need = to be > prepared > > for such interface with an external PCE module, no? >=20 > Yes, the classifier should act as a PCC. >=20 > > >> >> complexity justified for all deployments? > > >> > > > >> >As I have said, the architecture should allow the classifier to jus= t > > >> >impose the SFC information on the selected packet as well. In this > > >> >way, each SFF needs to resolve the appropriate next SFF for the nex= t > > >> >SF to be > > >> executed. > > >> > > >> [Med] Yes, I understood that from you initial list. My question is > > >> how to > > >package > > >> all this together without imposing complexity to deployments that do > > >> not require it. > > > > > >Since architecture allows three options, operators could make their ow= n > > >choices accordingly. > > > > [Med] The problem is that packaging a lot of optional features will hav= e > an > > impact on the overall complexity of the solution. This is why I'm > questioning > > having any possible feature as an optional part of the solution. >=20 > How about listing those three options in the architecture draft and sayin= g > that either is applicable in some cases. >=20 > Best regards, > Xiaohu >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 18 07:43: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 DB8811B29E0; Fri, 18 Jul 2014 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 I7JyERbXbMa3; Fri, 18 Jul 2014 07:43:31 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D291B29CE; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so4580563iec.17 for ; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UIrzvOQ2YUHjM0nbyOoriIY/J2pVyExkHxhyGNm2Mac=; b=rRoUMIS2vhZhjdbRik8myrWAYQR8q3Ox+Ob50Xh0INwZSlBH+vEd3SPOdXhe9Kabsn RK6XWpI4wLUTAMew0Ye//Y89dn5uFeXDCDEqmWTEbUit4J5el1EvMZdqg6GPNDeZXWML 8xER4qh23wY5edp4tsZJ76aNC2ybtYXkx1FVUrtDksA9mj0kGmjVHdK7ZnnXXHcmw7+t 1JV33p1qb6wxun4cTdrHGTYQiLtiVXDC3KUO3cYOkXBw9wKZolFh7SgOUA1KS0IZp1HY Qxv0zbTovaWU3WLTlfRH4KcqQuTf4oMJjazyPiD+MTX/3AlKkuEBvS/0W1mZaxhDb8Lm z9NA== MIME-Version: 1.0 X-Received: by 10.42.154.132 with SMTP id q4mr8214426icw.4.1405694610197; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 16:43:30 +0200 X-Google-Sender-Auth: nd42Y6V-GFoxs1lLKAjCXHLW2kI Message-ID: From: Robert Raszuk To: Ron Parker Content-Type: multipart/alternative; boundary=90e6ba6e87a6e7528504fe78c708 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yZufDItBg509IINfCvsAQ07hIE0 Cc: "mpls@ietf.org" , Xuxiaohu , "" , "sfc@ietf.org" Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:43:34 -0000 --90e6ba6e87a6e7528504fe78c708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ron, I would be very very carefull to place matadata inband (ie embed it in customer data packets) of data plane. Few reasons for consideration: - Adding anything over hundred bytes may become pretty overwhelming for small size customer packets - Adding anything over already maxed size packet may cause MTU issues and fragmentation (which in many cases is not possible in the middle of the network). Keep in mind also encrypted data. - Anything which is variable length in the data plane and which is opaque to the data plane causes additional data plane requirements which a lot of hardware may have a hard time to deal with - Inband transport provides no option to pre-populate the state at the backup devices / backup paths where no active traffic is traversing before any network event affecting primary path - A lot of appliances may not be able to be transparent to opaque variable length metadata resulting in metadata information loss. For all of the above reasons (and I am sure many more not listed above) I would keep customer data packets alone and when needed limit only insertion of a pointer to metadata context learned out-of-band. (Out-of-band is a bit misleading term here as metadata can happily travel via the same set of links as customer data. What it really means is out-of-customer-data-packets). Best regards, R. On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker wrote: > Robert, > > > > Inband is one way -- it simplifies things at the cost of packet growth. > Out-of-band (i.e., signaling) is another way =E2=80=93 it adds complexity= but > doesn=E2=80=99t grow the data plane packets. Congruent out-of-band is a= variation > on out-of-band that may partially reduce out-of-band complexity. I thi= nk > many opinions on the thread have been that all are in scope, > architecturally. Draft-zhang-sfc-sch (I am a co-author), for example, > defines inband metadata explicitly, but states in text that out-of-band i= s > possible, too. I=E2=80=99m sure this will be a topic of discussion whe= n we start > discussing control plane requirements. > > > > Ron > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Robert Raszuk > > *Sent:* Friday, July 18, 2014 3:27 AM > *To:* Xuxiaohu; sfc@ietf.org > *Cc:* mpls@ietf.org; > *Subject:* Re: [sfc] [spring] How to carry metadata/context in an MPLS > packet > > > > All, > > > > Is the idea of using data plane to carry complete metadata is "the way" o= r > "a way" of approaching the problem ? Has this been already discussed ? > > > > I would rather consider to carry metadata in control plane and only attac= h > a reference_id (and only when it is needed) to the data plane. > > > > Rgs, > > R. > > > > > > > > > > On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introduci= ng > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadat= a > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --90e6ba6e87a6e7528504fe78c708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --90e6ba6e87a6e7528504fe78c708-- From nobody Fri Jul 18 08:00: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 438E51B2A2C for ; Fri, 18 Jul 2014 08:00:41 -0700 (PDT) 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 byiPSKUwmfFJ for ; Fri, 18 Jul 2014 08:00:36 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97741B2A1C for ; Fri, 18 Jul 2014 08:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 8D149D40030; Fri, 18 Jul 2014 08:00:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-78.clppva.east.verizon.net [70.106.134.78]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id E99B2D40778; Fri, 18 Jul 2014 08:00:34 -0700 (PDT) Message-ID: <53C93690.8060508@joelhalpern.com> Date: Fri, 18 Jul 2014 11:00:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Henry Fourie , "sfc@ietf.org" References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vczcZ004YIOy3R5FsZZdqDpZqJk Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 15:00:41 -0000 I suspect that there are two separate but related issues. The architecture we proposed, and probably any useful archtiecture, does constrain solutions. In adopting an archtiecture, the working group makes some choices. At the same time, those constraints should general, not specific, and certainly not aimed at the NSH solution in particular. Yours, Joel On 7/17/14, 1:57 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > I fully agree with you about the goal. > > Nevertheless, the merged document, as it currently stands, includes some solution hints that come mainly from nsh. I would really hope the document be updated to be neutral. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >> Envoyé : mercredi 16 juillet 2014 23:47 >> À : Henry Fourie; sfc@ietf.org >> Objet : Re: [sfc] SFC Terminology / Concepts >> >> I would hope that we can end up with an archtiecture document that is >> understandable and useful without resorting to a specific solution >> document. That is our goal. There probably are refinements needed to >> achieve that goal. >> >> Yours, >> Joel >> >> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>> Ken, >>> The Service chain Header draft https://datatracker.ietf.org/doc/draft- >> zhang-sfc-sch/ >>> should answer some of your questions. In particular: >>> >>> In section 4.2 Mandatory Fields: >>> >>> Path Identifier: Identifies a fully instantiated service function >>> path. It represents a sequence of network locators, one for each >>> service function that is to be invoked. Participating SFC entities >>> MUST use this identifier when selecting the next hop for the >>> packet or frame. >>> >>> In section 4.4 Header Associated Operations: >>> >>> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >>> the Service Chain Identification information in the SCH to steer >>> the traffic flow along the SFC path. >>> >>> 4. Service Function Instance Selection. The Service Function >>> Forwarder (SFF) uses the Service Chain Identification information >>> in the SCH to locate the service instance and forward the traffic >>> flow to the service instance. The mapping of the Service Chain >>> Identification to a service instance can be established through >>> the management/control plane, which is out of scope of this >>> document. >>> >>> - Louis >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) >>> Sent: Wednesday, July 16, 2014 11:59 AM >>> To: Thomas D. Nadeau; sfc-chairs@ietf.org >>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >> mohamed.boucadair@orange.com >>> Subject: Re: [sfc] SFC Terminology / Concepts >>> >>> Joel, et. all, >>> >>> I think that some of the questions in architecture (SFP/SFC chasing it's >>> tail) come as people look forward to the encapsulation/header document. >>> That's probably unavoidable. >>> >>> When you read the NSH document, the SFP verbiage says that all >>> participants MUST forward on the SP/SPI, but the document doesn't say how >>> the SPI is derived/calculated (the vision here could be made clearer) or >>> what it's relationship is to the transport path (I think you can't mix >> and >>> match but can accommodate both within the header), should you opt for the >>> transport header forwarding. >>> >>> It's obvious that some deployments prefer to use the transport header for >>> forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which >>> does play into the SPI or "other mechanisms" that populate a service >> table >>> in the SFF). >>> >>> Perhaps the authors of NSH can suggest verbiage that makes the >>> relationship between transport-based forwarding and service-based >>> forwarding (SPI) clearer? >>> >>> This should eliminate/minimize the calls for redefinition/recasting our >>> terminology and allow us to move on. >>> >>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: >>> >>>> >>>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >> have >>>> gotten needlessly complicated and convoluted IMHO. >>>> >>>> Is it possible for the chairs to add this to the list of things to >>>> discuss at the WG meeting or do we want to resolve this on the list >> ahead >>>> of the meeting? >>>> >>>> --Tom >>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>>> wrote: >>>> >>>>> Hi Peng, >>>>> >>>>>> -----Original Message----- >>>>>> From: He, Peng [mailto:phe@ciena.com] >>>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>>>> Taylor; >>>>>> sfc@ietf.org; Ron Parker >>>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Try to understand the three scenarios you listed: you mean the >>>>>> classifier can >>>>>> specify a (partial or complete) SFP which is a list of SFFs, then each >>>>>> SFF will >>>>>> (locally) select one of the SF instances under itself for this SF. For >>>>>> partial SFP case, >>>>> >>>>> In either case, the SFF should be capable of selecting the appropriate >>>>> instance of a given SF attached to itself. it's an internal >>>>> load-balancing issue. >>>>> >>>>>> each SFF will identify the SFI under itself and specify (like a >>>>>> classifier) next SFF(s). >>>>>> The classifier (and SFF?) could obtain this (SFF) 'path' information >>>>> >from either >>>>>> centralized point (e.g., PCE, controller), or, via a distributed >>>>>> control plane? For >>>>>> partial SFP, will there be a re-classification to decide next SFF(s) >>>>>> or not? >>>>> >>>>> If you want the SFF to locally determine the appropriate SFF for the >>>>> next SF, the SFF should have the capability of resolving the SFF for >> the >>>>> next SF based on certain constraints. Of course, it needs to know some >>>>> information about the SFs in advance, e.g., the information about which >>>>> SFFs a given SF is attached. >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> Regards, >>>>>> Peng >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>>>> sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> IMHO, the architecture should allow the classifier to specify >>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>>>> locally determine >>>>>> the appropriate SFF for the next SF); >>>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>>>> determined by >>>>>> the centralized node); >>>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>>>> determine the >>>>>> appropriate SFF for the next SF). >>>>>> >>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>> >>>>>>> Hi Joel, >>>>>>> >>>>>>> As mentioned in several messages, I'm personally for the use of the >>>>>>> chain itself is the main information to be conveyed in packets to >>>>>>> drive >>>>>> forwarding actions. >>>>>>> >>>>>>> I can understand that an identifier can be assigned to a path that is >>>>>>> known in advance, but if that path is not known I'm not sure how an >>>>>>> identifier can be assigned to it! >>>>>>> >>>>>>> Joel, the use of "path" is really inappropriate to refer to >>>>>>> distributed instance selection process for packets bound to a given >>>>>>> SFC. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>>>>>>> Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; sfc@ietf.org; >>>>>>>> Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts >>>>>>>> >>>>>>>> The most likely realization of the architecture would be that the >> SFP >>>>>>>> assignment is recorded in an identifier which travels with the >>>>>>>> packet. >>>>>>>> >>>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> >>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>> Your text scares me because it introduces some new concepts and >>>>>>>>> assumptions. >>>>>>>>> >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on that: >>>>>>>>> am I right in seeing the implication that when control assigns an >>>>>>>>> SFP, the assignment is recorded by an identifier wwhich travels >>>>>>>>> with the >>>>>>> packet? >>>>>>>>> >>>>>>>>> Tom Taylor >>>>>>>>> >>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>> There is one missing word in my text. Please replace my proposed >>>>>>>>>> text >>>>>>>>>> with: >>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract view >>>>>>>>>> of the service functions to be invoked and the order in which they >>>>>>>>>> are to be invoked for some particular flow or set of flows, >> without >>>>>> concern of >>>>>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>>>>> (C-SFC) further allows for policy constraints to be added to the >>>>>>>>>> SFC affecting the instance selection of one or more of the service >>>>>> functions >>>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>>> with >>>>>>>> it." >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>>>>> Allan I >>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where an >>>>>>>>>> implementation has the option of making scale and resiliency a >>>>>>>>>> local >>>>>> matter.. >>>>>>>>>> >>>>>>>>>> D >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>>>>> Guichard >>>>>>>>>> (jguichar) >>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>>> *To:* sfc@ietf.org >>>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> There has been much debate over the last few days with regards to >>>>>>>>>> SFC concepts. To try and form some consensus around terminology >>>>>>>>>> and concepts used to describe the architecture in the merged >>>>>>>>>> architecture draft, Joel has kindly suggested the following: >>>>>>>>>> >>>>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>>>> abstract notion of service path as a sequence of functions to be >>>>>>>>>> delivered, and the fully specified notion of exactly what >>>>>>>>>> instances of SFFs the packet will visit when it actually traverses >>>>>>>>>> the network. By allowing the control components to specify the use >>>>>>>>>> of this level of indirection, the deployment may choose the degree >>>>>>>>>> of SFF instance selection authority that is delegated to the >>>>>>>>>> network." >>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel to >>>>>>>>>> provide specific text, that reflects the above, for inclusion in >>>>>>>>>> the merged architecture draft. >>>>>>>>>> >>>>>>>>>> Thank You, >>>>>>>>>> >>>>>>>>>> Jim >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing 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 Jul 18 10:00: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 920031A01C8 for ; Fri, 18 Jul 2014 10:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jZHHr_EE94J for ; Fri, 18 Jul 2014 10:00:11 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B3D1A0ABE for ; Fri, 18 Jul 2014 10:00:11 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu12so7709479vcb.20 for ; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GAUm7u5KXtbVG2kOGPrFLmfCQiLto7Go2sRohYl1PgA=; b=lXDRt15iEmOAvSQyV7Pu9RRBsjV6/4QPmh7oDdlP1FUh9WSAnjqjE5cJuShRsOa7/s 6WS3C1DfkJNW6SkvES+iFS3calOlzLNHVIR4HNgisZGNb6GIbRf4bvTXjRQxkkAz20S7 J5TDASZA3j2WbuR2ioOmu9fMtGzjPhc/rFZYuzy1F1MTmYGBxlpNEFKaczt/TABYVF2Z ETlLnGqAs/hwfYDGVKd/xIl8cLFwjGhFUGIMOCziufag/nuVBQXFZL2iXimUKfnesptn d8KdMpHUNgPlSypZk7VXvZBDeloJ/ZR5ZMS7MckgpOs2KsldHNYfS3T35Yihkexr0A0I iFGg== X-Gm-Message-State: ALoCoQmmzdRJlTsd5urFaD0FY27itBey2+D707OolZXRNlKC9WlDEuRNkqhb5P3QxihUo8HrPAVL X-Received: by 10.221.56.5 with SMTP id wa5mr4225748vcb.25.1405702810658; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Fri, 18 Jul 2014 09:59:50 -0700 (PDT) From: Jamal Hadi Salim Date: Fri, 18 Jul 2014 12:59:50 -0400 Message-ID: To: "forces@ietf.org" , "sdn@irtf.org" , nfvrg@irtf.org, vnfpool@ietf.org, nvo3@ietf.org, "i2rs@ietf.org" , sfc Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ds41Jih3vJaihchwM_5K4ui-KCc Subject: [sfc] BitsnBites ForCES PoC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 17:00:14 -0000 Folks, I am sorry for spamming all these lists. You are being spammed because you are a cousin of ForCES. We are planning to have a ForCES based NFV/SDN PoC demonstration at the Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). Given it is very hard to give a lot of details in the demo, Evangelos Haleplidis will present more details at the ForCES meeting Monday 15:20 at the Manitoba room. The official blurb is as follows: ------ SANA will demonstrate the proof-of-concept of the applicability of IETF's ForCES framework for both NFV management and SDN control. The ForCES data model will be utilized to describe VNFs, services and the infrastructure definition in a clear, formal and concise approach. The protocol will illustrate SDN control and NFV management of all modelled elements. The setup includes various NFV/SDN entities controlled and managed by the ForCES architecture execute under a singular simple programmatic API regardless of whether they are virtual or physical. The separation of hardware and software is illustrated by the same NF LFB data models implemented in: a)KVM virtual machines, b) Linux containers, c) linux kernel proper and d) ASIC based L2/3 (Broadcom chipset) in white box switches all working in unison. Infrastructure orchestration includes instantiating VMs, containers, applications and setup of basic network connectivity using appropriate ForCES LFBs. Service orchestration is again modelled by ForCES LFBs and both control and management activities for the services are driven by the ForCES protocol. We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service and the advantages gained from (SDN) separating the datapath components of S/PGW from the control as well as (NFV) separation of hardware from software. This PoC is further illustrated in: http://nfvwiki.etsi.org/index.php?title=ForCES_Applicability_for_NFV_and_integrated_SDN -------- Apologies again for the mass email. cheers, jamal From nobody Fri Jul 18 11:21: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 A17481A00EC; Fri, 18 Jul 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YJ3nMPABJmSY; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806F61A0091; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 18 Jul 2014 18:21:07 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0990.007; Fri, 18 Jul 2014 18:21:07 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [sfc] BitsnBites ForCES PoC Thread-Index: AQHPoqnB/0IwhlC/pky+GbkxV4TKYpumJMEQ Date: Fri, 18 Jul 2014 18:21:06 +0000 Message-ID: <5B1198B1-1EBF-40D6-BDE7-31A2AD498636@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.100.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(51704005)(24454002)(92726001)(83322001)(106116001)(74502001)(80022001)(79102001)(36756003)(101416001)(77982001)(110136001)(106356001)(19580395003)(19580405001)(16799955002)(81342001)(99396002)(82746002)(46102001)(15202345003)(87936001)(81542001)(50986999)(64706001)(76176999)(95666004)(54356999)(85852003)(99286002)(86362001)(15188155005)(83716003)(21056001)(74662001)(92566001)(76482001)(33656002)(31966008)(2656002)(15975445006)(4396001)(20776003)(83072002)(85306003)(105586002)(66066001)(107046002)(104396001)(19623215001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Z8oBi0mg0WNa7xKRr_yQx07MFhk Cc: "vnfpool@ietf.org" , "i2rs@ietf.org" , "sdn@irtf.org" , sfc , "nvo3@ietf.org" , "nfvrg@irtf.org" , "forces@ietf.org" Subject: Re: [sfc] BitsnBites ForCES PoC X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 18:21:11 -0000 Shameless self-aggrandizement=20 Sent from my iPhone > On Jul 18, 2014, at 1:00 PM, "Jamal Hadi Salim" wrote= : >=20 > Folks, >=20 > I am sorry for spamming all these lists. You are being spammed because > you are a cousin of ForCES. >=20 > We are planning to have a ForCES based NFV/SDN PoC demonstration at the > Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). > Given it is very hard to give a lot of details in the demo, Evangelos Hal= eplidis > will present more details at the ForCES meeting Monday 15:20 at the > Manitoba room. >=20 > The official blurb is as follows: > ------ > SANA will demonstrate the proof-of-concept of the applicability of > IETF's ForCES framework for both NFV management and SDN control. > The ForCES data model will be utilized to describe VNFs, services and the > infrastructure definition in a clear, formal and concise approach. > The protocol will illustrate SDN control and NFV management of all > modelled elements. >=20 > The setup includes various NFV/SDN entities controlled and managed by the > ForCES architecture execute under a singular simple programmatic API > regardless of whether they are virtual or physical. The > separation of hardware and software is illustrated by the same NF > LFB data models implemented in: > a)KVM virtual machines, b) Linux containers, c) linux kernel proper > and d) ASIC based L2/3 (Broadcom chipset) in white box switches > all working in unison. >=20 > Infrastructure orchestration includes instantiating VMs, containers, > applications and setup of basic network connectivity using appropriate > ForCES LFBs. > Service orchestration is again modelled by ForCES LFBs and > both control and management activities for the services are driven by > the ForCES protocol. >=20 > We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service > and the advantages > gained from (SDN) separating the datapath components of S/PGW from the co= ntrol > as well as (NFV) separation of hardware from software. >=20 > This PoC is further illustrated in: > http://nfvwiki.etsi.org/index.php?title=3DForCES_Applicability_for_NFV_an= d_integrated_SDN > -------- >=20 > Apologies again for the mass email. >=20 > cheers, > jamal >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 18 13:38: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 393E21A00C3 for ; Fri, 18 Jul 2014 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 eeNwdDKnf_Zg for ; Fri, 18 Jul 2014 13:38:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B73C1ABB2E for ; Fri, 18 Jul 2014 13:38:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHI48921; Fri, 18 Jul 2014 20:38:28 +0000 (GMT) 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; Fri, 18 Jul 2014 21:38:28 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 13:38:11 -0700 From: Lucy yong To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , Henry Fourie , "sfc@ietf.org" Thread-Topic: [sfc] SFC Terminology / Concepts Thread-Index: AQHPn4u0sZOdKSsleEeMQbCccLge6Zuf3D4QgAAByHCAAAOgUIAAeeGAgAAU+ACAAMCSAIAAGHUAgABIh4CAAOetgIAA8cQAgAAayQD//7mnrIAA/iwAgAIqMQD//+fDQA== Date: Fri, 18 Jul 2014 20:38:12 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C0EA9@dfweml701-chm.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53C93690.8060508@joelhalpern.com> In-Reply-To: <53C93690.8060508@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.216] 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/C2jXLkIE8oSi0vc35dbpn9i-Jc4 Subject: Re: [sfc] SFC Terminology / Concepts X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Jul 2014 20:38:34 -0000 =20 I suspect that there are two separate but related issues. The architecture we proposed, and probably any useful archtiecture, does co= nstrain solutions. In adopting an archtiecture, the working group makes so= me choices. [Lucy] not so sure. We should adopt an architecture without making solution= choices ahead. The architecture leads solution development, not the other = way. At the same time, those constraints should general, not specific, and certa= inly not aimed at the NSH solution in particular. [Lucy] Yes and Agree. Lucy =20 On 7/17/14, 1:57 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > I fully agree with you about the goal. > > Nevertheless, the merged document, as it currently stands, includes some = solution hints that come mainly from nsh. I would really hope the document = be updated to be neutral. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >> Envoy=E9 : mercredi 16 juillet 2014 23:47 =C0 : Henry Fourie;=20 >> sfc@ietf.org Objet : Re: [sfc] SFC Terminology / Concepts >> >> I would hope that we can end up with an archtiecture document that is=20 >> understandable and useful without resorting to a specific solution=20 >> document. That is our goal. There probably are refinements needed=20 >> to achieve that goal. >> >> Yours, >> Joel >> >> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>> Ken, >>> The Service chain Header draft=20 >>> https://datatracker.ietf.org/doc/draft- >> zhang-sfc-sch/ >>> should answer some of your questions. In particular: >>> >>> In section 4.2 Mandatory Fields: >>> >>> Path Identifier: Identifies a fully instantiated service function >>> path. It represents a sequence of network locators, one for eac= h >>> service function that is to be invoked. Participating SFC entit= ies >>> MUST use this identifier when selecting the next hop for the >>> packet or frame. >>> >>> In section 4.4 Header Associated Operations: >>> >>> 3. Service Path Selection. The Service Network Forwarder (SNF) use= s >>> the Service Chain Identification information in the SCH to stee= r >>> the traffic flow along the SFC path. >>> >>> 4. Service Function Instance Selection. The Service Function >>> Forwarder (SFF) uses the Service Chain Identification informati= on >>> in the SCH to locate the service instance and forward the traff= ic >>> flow to the service instance. The mapping of the Service Chain >>> Identification to a service instance can be established through >>> the management/control plane, which is out of scope of this >>> document. >>> >>> - Louis >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray=20 >>> (kegray) >>> Sent: Wednesday, July 16, 2014 11:59 AM >>> To: Thomas D. Nadeau; sfc-chairs@ietf.org >>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >> mohamed.boucadair@orange.com >>> Subject: Re: [sfc] SFC Terminology / Concepts >>> >>> Joel, et. all, >>> >>> I think that some of the questions in architecture (SFP/SFC chasing=20 >>> it's >>> tail) come as people look forward to the encapsulation/header document. >>> That's probably unavoidable. >>> >>> When you read the NSH document, the SFP verbiage says that all=20 >>> participants MUST forward on the SP/SPI, but the document doesn't=20 >>> say how the SPI is derived/calculated (the vision here could be made=20 >>> clearer) or what it's relationship is to the transport path (I think=20 >>> you can't mix >> and >>> match but can accommodate both within the header), should you opt=20 >>> for the transport header forwarding. >>> >>> It's obvious that some deployments prefer to use the transport=20 >>> header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop=20 >>> lookup (which does play into the SPI or "other mechanisms" that=20 >>> populate a service >> table >>> in the SFF). >>> >>> Perhaps the authors of NSH can suggest verbiage that makes the=20 >>> relationship between transport-based forwarding and service-based=20 >>> forwarding (SPI) clearer? >>> >>> This should eliminate/minimize the calls for redefinition/recasting=20 >>> our terminology and allow us to move on. >>> >>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: >>> >>>> >>>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >> have >>>> gotten needlessly complicated and convoluted IMHO. >>>> >>>> Is it possible for the chairs to add this to the list of things to=20 >>>> discuss at the WG meeting or do we want to resolve this on the list >> ahead >>>> of the meeting? >>>> >>>> --Tom >>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu=20 >>>> >>>> wrote: >>>> >>>>> Hi Peng, >>>>> >>>>>> -----Original Message----- >>>>>> From: He, Peng [mailto:phe@ciena.com] >>>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom=20 >>>>>> Taylor; sfc@ietf.org; Ron Parker >>>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Try to understand the three scenarios you listed: you mean the=20 >>>>>> classifier can specify a (partial or complete) SFP which is a=20 >>>>>> list of SFFs, then each SFF will >>>>>> (locally) select one of the SF instances under itself for this=20 >>>>>> SF. For partial SFP case, >>>>> >>>>> In either case, the SFF should be capable of selecting the=20 >>>>> appropriate instance of a given SF attached to itself. it's an=20 >>>>> internal load-balancing issue. >>>>> >>>>>> each SFF will identify the SFI under itself and specify (like a >>>>>> classifier) next SFF(s). >>>>>> The classifier (and SFF?) could obtain this (SFF) 'path'=20 >>>>>> information >>>>> >from either >>>>>> centralized point (e.g., PCE, controller), or, via a distributed=20 >>>>>> control plane? For partial SFP, will there be a re-classification=20 >>>>>> to decide next SFF(s) or not? >>>>> >>>>> If you want the SFF to locally determine the appropriate SFF for=20 >>>>> the next SF, the SFF should have the capability of resolving the=20 >>>>> SFF for >> the >>>>> next SF based on certain constraints. Of course, it needs to know=20 >>>>> some information about the SFs in advance, e.g., the information=20 >>>>> about which SFFs a given SF is attached. >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> Regards, >>>>>> Peng >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor;=20 >>>>>> sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> IMHO, the architecture should allow the classifier to specify >>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to=20 >>>>>> locally determine the appropriate SFF for the next SF); >>>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been=20 >>>>>> determined by the centralized node); >>>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally=20 >>>>>> determine the appropriate SFF for the next SF). >>>>>> >>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>> >>>>>>> Hi Joel, >>>>>>> >>>>>>> As mentioned in several messages, I'm personally for the use of=20 >>>>>>> the chain itself is the main information to be conveyed in=20 >>>>>>> packets to drive >>>>>> forwarding actions. >>>>>>> >>>>>>> I can understand that an identifier can be assigned to a path=20 >>>>>>> that is known in advance, but if that path is not known I'm not=20 >>>>>>> sure how an identifier can be assigned to it! >>>>>>> >>>>>>> Joel, the use of "path" is really inappropriate to refer to=20 >>>>>>> distributed instance selection process for packets bound to a=20 >>>>>>> given SFC. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M.=20 >>>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor;=20 >>>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology /=20 >>>>>>>> Concepts >>>>>>>> >>>>>>>> The most likely realization of the architecture would be that=20 >>>>>>>> the >> SFP >>>>>>>> assignment is recorded in an identifier which travels with the=20 >>>>>>>> packet. >>>>>>>> >>>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> >>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>> Your text scares me because it introduces some new concepts=20 >>>>>>>>> and assumptions. >>>>>>>>> >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on tha= t: >>>>>>>>> am I right in seeing the implication that when control assigns=20 >>>>>>>>> an SFP, the assignment is recorded by an identifier wwhich=20 >>>>>>>>> travels with the >>>>>>> packet? >>>>>>>>> >>>>>>>>> Tom Taylor >>>>>>>>> >>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>> There is one missing word in my text. Please replace my propos= ed >>>>>>>>>> text >>>>>>>>>> with: >>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract=20 >>>>>>>>>> view of the service functions to be invoked and the order in=20 >>>>>>>>>> which they are to be invoked for some particular flow or set=20 >>>>>>>>>> of flows, >> without >>>>>> concern of >>>>>>>>>> actual service function instance selection. The Constrained-SF= C >>>>>>>>>> (C-SFC) further allows for policy constraints to be added to=20 >>>>>>>>>> the SFC affecting the instance selection of one or more of=20 >>>>>>>>>> the service >>>>>> functions >>>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>>> with >>>>>>>> it." >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 >>>>>>>>>> Allan I >>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org=20 >>>>>>>>>> >>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where an=20 >>>>>>>>>> implementation has the option of making scale and resiliency=20 >>>>>>>>>> a local >>>>>> matter.. >>>>>>>>>> >>>>>>>>>> D >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>>>>>>>> Guichard >>>>>>>>>> (jguichar) >>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>>> *To:* sfc@ietf.org >>>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> There has been much debate over the last few days with=20 >>>>>>>>>> regards to SFC concepts. To try and form some consensus=20 >>>>>>>>>> around terminology and concepts used to describe the=20 >>>>>>>>>> architecture in the merged architecture draft, Joel has kindly s= uggested the following: >>>>>>>>>> >>>>>>>>>> "The SFP provides a level of indirection between the fully=20 >>>>>>>>>> abstract notion of service path as a sequence of functions to=20 >>>>>>>>>> be delivered, and the fully specified notion of exactly what=20 >>>>>>>>>> instances of SFFs the packet will visit when it actually=20 >>>>>>>>>> traverses the network. By allowing the control components to=20 >>>>>>>>>> specify the use of this level of indirection, the deployment=20 >>>>>>>>>> may choose the degree of SFF instance selection authority=20 >>>>>>>>>> that is delegated to the network." >>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel=20 >>>>>>>>>> to provide specific text, that reflects the above, for=20 >>>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>>> >>>>>>>>>> Thank You, >>>>>>>>>> >>>>>>>>>> Jim >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing 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 Sat Jul 19 17:45: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 1355A1B2B47 for ; Sat, 19 Jul 2014 17:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ayDzdTRTgA4Q for ; Sat, 19 Jul 2014 17:44:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFC11B2B48 for ; Sat, 19 Jul 2014 17:44:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKH12628; Sun, 20 Jul 2014 00:44:56 +0000 (GMT) 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; Sun, 20 Jul 2014 01:44:55 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Sat, 19 Jul 2014 17:44:48 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , Henry Fourie , "sfc@ietf.org" Thread-Topic: MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly Thread-Index: AQHPo7PONTAbQXo9v0momypO37O93g== Date: Sun, 20 Jul 2014 00:44:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.109] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/towEbgi_EID9jWGrzYUBXIfZGaI Subject: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 00:45:02 -0000 The MTU section of the merged-sfc-arch is one example showing what Med said= about the current architecture "including some solution hints that come ma= inly from nsh". An important part of SFC is the SFC header encapsulation.=20 Therefore, the MTU section should emphasize the importance of avoiding pack= ets fragmentation and reassembly because most service functions, especially= legacy L4-L7 service functions, don't expect fragmented packets. It is ver= y expensive for intermediate SFF/SN nodes to reassemble packets before pass= ing packets to Service Functions. E.g. The SFC header should avoid literall= y listing the addresses (especially IPv6 addresses) of the service function= s in a service function chain. But final MTU Section emphasizes that the modern systems can handle packets= fragmentation and reassembly, meaning NSH header (no matter how long) is n= o problem. I had a two separate conference calls with the authors of the SFC-architec= ture draft addressing suggested merging of some content from "legacy-l4-l7-= arch" to general "sfc-arch" (each lasted more than 1 hour).=20 One of the issues being discussed is the MTU section. Here is text that I s= uggested to merge with the general "sfc-arch": "Encapsulating SFC header to data packets has to take MTU size into conside= ration because most service functions, especially legacy L4-L7 service func= tions, don't expect fragmented packets.=20 It is very expensive for intermediate SFF/SN nodes to reassemble packets be= fore passing packets to Service Functions.=20 Therefore, the information carried by the SFC header has to be compact. The= SFC header should avoid literally listing the addresses (especially IPv6 a= ddresses) of the service functions in a service function chain." I sincerely hope that the authors can take this text (or variation of this = text) for the MTU section of sfc-arch.=20 Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, July 17, 2014 12:57 AM To: Joel M. Halpern; Henry Fourie; sfc@ietf.org Subject: Re: [sfc] SFC Terminology / Concepts Hi Joel, I fully agree with you about the goal.=20 Nevertheless, the merged document, as it currently stands, includes some so= lution hints that come mainly from nsh. I would really hope the document be= updated to be neutral.=20 Cheers, Med >-----Message d'origine----- >De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern=20 >Envoy=E9=A0: mercredi 16 juillet 2014 23:47 =C0=A0: Henry Fourie; sfc@ietf= .org=20 >Objet=A0: Re: [sfc] SFC Terminology / Concepts > >I would hope that we can end up with an archtiecture document that is=20 >understandable and useful without resorting to a specific solution=20 >document. That is our goal. There probably are refinements needed to=20 >achieve that goal. > >Yours, >Joel > >On 7/16/14, 5:39 PM, Henry Fourie wrote: >> Ken, >> The Service chain Header draft=20 >> https://datatracker.ietf.org/doc/draft- >zhang-sfc-sch/ >> should answer some of your questions. In particular: >> >> In section 4.2 Mandatory Fields: >> >> Path Identifier: Identifies a fully instantiated service function >> path. It represents a sequence of network locators, one for each >> service function that is to be invoked. Participating SFC entitie= s >> MUST use this identifier when selecting the next hop for the >> packet or frame. >> >> In section 4.4 Header Associated Operations: >> >> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >> the Service Chain Identification information in the SCH to steer >> the traffic flow along the SFC path. >> >> 4. Service Function Instance Selection. The Service Function >> Forwarder (SFF) uses the Service Chain Identification information >> in the SCH to locate the service instance and forward the traffic >> flow to the service instance. The mapping of the Service Chain >> Identification to a service instance can be established through >> the management/control plane, which is out of scope of this >> document. >> >> - Louis >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray=20 >> (kegray) >> Sent: Wednesday, July 16, 2014 11:59 AM >> To: Thomas D. Nadeau; sfc-chairs@ietf.org >> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >mohamed.boucadair@orange.com >> Subject: Re: [sfc] SFC Terminology / Concepts >> >> Joel, et. all, >> >> I think that some of the questions in architecture (SFP/SFC chasing=20 >> it's >> tail) come as people look forward to the encapsulation/header document. >> That's probably unavoidable. >> >> When you read the NSH document, the SFP verbiage says that all=20 >> participants MUST forward on the SP/SPI, but the document doesn't say=20 >> how the SPI is derived/calculated (the vision here could be made=20 >> clearer) or what it's relationship is to the transport path (I think=20 >> you can't mix >and >> match but can accommodate both within the header), should you opt for=20 >> the transport header forwarding. >> >> It's obvious that some deployments prefer to use the transport header=20 >> for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup=20 >> (which does play into the SPI or "other mechanisms" that populate a=20 >> service >table >> in the SFF). >> >> Perhaps the authors of NSH can suggest verbiage that makes the=20 >> relationship between transport-based forwarding and service-based=20 >> forwarding (SPI) clearer? >> >> This should eliminate/minimize the calls for redefinition/recasting=20 >> our terminology and allow us to move on. >> >> On 7/16/14 1:23 PM, "Thomas D. Nadeau" wrote: >> >>> >>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >have >>> gotten needlessly complicated and convoluted IMHO. >>> >>> Is it possible for the chairs to add this to the list of things to=20 >>> discuss at the WG meeting or do we want to resolve this on the list >ahead >>> of the meeting? >>> >>> --Tom >>> >>> >>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu=20 >>> >>> wrote: >>> >>>> Hi Peng, >>>> >>>>> -----Original Message----- >>>>> From: He, Peng [mailto:phe@ciena.com] >>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom=20 >>>>> Taylor; sfc@ietf.org; Ron Parker >>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>> >>>>> Try to understand the three scenarios you listed: you mean the=20 >>>>> classifier can specify a (partial or complete) SFP which is a list=20 >>>>> of SFFs, then each SFF will >>>>> (locally) select one of the SF instances under itself for this SF.=20 >>>>> For partial SFP case, >>>> >>>> In either case, the SFF should be capable of selecting the=20 >>>> appropriate instance of a given SF attached to itself. it's an=20 >>>> internal load-balancing issue. >>>> >>>>> each SFF will identify the SFI under itself and specify (like a >>>>> classifier) next SFF(s). >>>>> The classifier (and SFF?) could obtain this (SFF) 'path'=20 >>>>> information >>>> >from either >>>>> centralized point (e.g., PCE, controller), or, via a distributed=20 >>>>> control plane? For partial SFP, will there be a re-classification=20 >>>>> to decide next SFF(s) or not? >>>> >>>> If you want the SFF to locally determine the appropriate SFF for=20 >>>> the next SF, the SFF should have the capability of resolving the=20 >>>> SFF for >the >>>> next SF based on certain constraints. Of course, it needs to know=20 >>>> some information about the SFs in advance, e.g., the information=20 >>>> about which SFFs a given SF is attached. >>>> >>>> Best regards, >>>> Xiaohu >>>> >>>>> Regards, >>>>> Peng >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor;=20 >>>>> sfc@ietf.org; Ron Parker >>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>> >>>>> Hi Med, >>>>> >>>>> IMHO, the architecture should allow the classifier to specify >>>>> >>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to=20 >>>>> locally determine the appropriate SFF for the next SF); >>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been=20 >>>>> determined by the centralized node); >>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally=20 >>>>> determine the appropriate SFF for the next SF). >>>>> >>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> As mentioned in several messages, I'm personally for the use of=20 >>>>>> the chain itself is the main information to be conveyed in=20 >>>>>> packets to drive >>>>> forwarding actions. >>>>>> >>>>>> I can understand that an identifier can be assigned to a path=20 >>>>>> that is known in advance, but if that path is not known I'm not=20 >>>>>> sure how an identifier can be assigned to it! >>>>>> >>>>>> Joel, the use of "path" is really inappropriate to refer to=20 >>>>>> distributed instance selection process for packets bound to a=20 >>>>>> given SFC. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M.=20 >>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor;=20 >>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology /=20 >>>>>>> Concepts >>>>>>> >>>>>>> The most likely realization of the architecture would be that=20 >>>>>>> the >SFP >>>>>>> assignment is recorded in an identifier which travels with the=20 >>>>>>> packet. >>>>>>> >>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>> Your text scares me because it introduces some new concepts and=20 >>>>>>>> assumptions. >>>>>>>> >>>>>>>> I'd rather go with Joel's formulation. Clarifying question on that= : >>>>>>>> am I right in seeing the implication that when control assigns=20 >>>>>>>> an SFP, the assignment is recorded by an identifier wwhich=20 >>>>>>>> travels with the >>>>>> packet? >>>>>>>> >>>>>>>> Tom Taylor >>>>>>>> >>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>> There is one missing word in my text. Please replace my propose= d >>>>>>>>> text >>>>>>>>> with: >>>>>>>>> >>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract=20 >>>>>>>>> view of the service functions to be invoked and the order in=20 >>>>>>>>> which they are to be invoked for some particular flow or set=20 >>>>>>>>> of flows, >without >>>>> concern of >>>>>>>>> actual service function instance selection. The Constrained-SFC >>>>>>>>> (C-SFC) further allows for policy constraints to be added to=20 >>>>>>>>> the SFC affecting the instance selection of one or more of the=20 >>>>>>>>> service >>>>> functions >>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>> with >>>>>>> it." >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Ron >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 >>>>>>>>> Allan I >>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org=20 >>>>>>>>> >>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> I like that text, it strikes a good balance where an=20 >>>>>>>>> implementation has the option of making scale and resiliency a=20 >>>>>>>>> local >>>>> matter.. >>>>>>>>> >>>>>>>>> D >>>>>>>>> >>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>>>>>>> Guichard >>>>>>>>> (jguichar) >>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>> *To:* sfc@ietf.org >>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> There has been much debate over the last few days with regards=20 >>>>>>>>> to SFC concepts. To try and form some consensus around=20 >>>>>>>>> terminology and concepts used to describe the architecture in=20 >>>>>>>>> the merged architecture draft, Joel has kindly suggested the foll= owing: >>>>>>>>> >>>>>>>>> "The SFP provides a level of indirection between the fully=20 >>>>>>>>> abstract notion of service path as a sequence of functions to=20 >>>>>>>>> be delivered, and the fully specified notion of exactly what=20 >>>>>>>>> instances of SFFs the packet will visit when it actually=20 >>>>>>>>> traverses the network. By allowing the control components to=20 >>>>>>>>> specify the use of this level of indirection, the deployment=20 >>>>>>>>> may choose the degree of SFF instance selection authority that=20 >>>>>>>>> is delegated to the network." >>>>>>>>> >>>>>>>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>>>>>>> something that we can get consensus on. If so, I'll ask Joel=20 >>>>>>>>> to provide specific text, that reflects the above, for=20 >>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>> >>>>>>>>> Thank You, >>>>>>>>> >>>>>>>>> Jim >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing 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 Sat Jul 19 18:06: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 24B791B2B4A for ; Sat, 19 Jul 2014 18:06:04 -0700 (PDT) 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 zKzYQSCGF-Lz for ; Sat, 19 Jul 2014 18:06:01 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25CB1B2B49 for ; Sat, 19 Jul 2014 18:06:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CB25624746F; Sat, 19 Jul 2014 18:06:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-94b7.meeting.ietf.org (dhcp-94b7.meeting.ietf.org [31.133.148.183]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1C3222473E4; Sat, 19 Jul 2014 18:05:59 -0700 (PDT) Message-ID: <53CB15F7.6060305@joelhalpern.com> Date: Sat, 19 Jul 2014 21:05:59 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , "mohamed.boucadair@orange.com" , Henry Fourie , "sfc@ietf.org" References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/K7Z2zmXhhNPTdFTLN9geuWF61dE Subject: Re: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 01:06:04 -0000 I am sorry that we forgot to make the improvements we had discussed with you to the MTU section. We should have improved it as part of producing this draft. We will improve the text, making use of your text as much as we can. I expect that we will emphasis the fact that SF can not be expected to perform reassembly, and that having SFF or proxy functions do it for them is also very expensive. My inclination is to focus on your points about the importance of compactness, rather than particularly on L4-L7 or particularly on listing addresses. I think trying to get to specific about things to avoid will weaken the text, and cause contention. Yours, Joel On 7/19/14, 8:44 PM, Linda Dunbar wrote: > The MTU section of the merged-sfc-arch is one example showing what > Med said about the current architecture "including some solution > hints that come mainly from nsh". > > > An important part of SFC is the SFC header encapsulation. Therefore, > the MTU section should emphasize the importance of avoiding packets > fragmentation and reassembly because most service functions, > especially legacy L4-L7 service functions, don't expect fragmented > packets. It is very expensive for intermediate SFF/SN nodes to > reassemble packets before passing packets to Service Functions. E.g. > The SFC header should avoid literally listing the addresses > (especially IPv6 addresses) of the service functions in a service > function chain. > > But final MTU Section emphasizes that the modern systems can handle > packets fragmentation and reassembly, meaning NSH header (no matter > how long) is no problem. > > > I had a two separate conference calls with the authors of the > SFC-architecture draft addressing suggested merging of some content > from "legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than > 1 hour). > > One of the issues being discussed is the MTU section. Here is text > that I suggested to merge with the general "sfc-arch": > > "Encapsulating SFC header to data packets has to take MTU size into > consideration because most service functions, especially legacy L4-L7 > service functions, don't expect fragmented packets. It is very > expensive for intermediate SFF/SN nodes to reassemble packets before > passing packets to Service Functions. Therefore, the information > carried by the SFC header has to be compact. The SFC header should > avoid literally listing the addresses (especially IPv6 addresses) of > the service functions in a service function chain." > > I sincerely hope that the authors can take this text (or variation of > this text) for the MTU section of sfc-arch. > > Linda > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 17, 2014 > 12:57 AM To: Joel M. Halpern; Henry Fourie; sfc@ietf.org Subject: Re: > [sfc] SFC Terminology / Concepts > > Hi Joel, > > I fully agree with you about the goal. > > Nevertheless, the merged document, as it currently stands, includes > some solution hints that come mainly from nsh. I would really hope > the document be updated to be neutral. > > Cheers, Med > >> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] >> De la part de Joel M. Halpern Envoyé : mercredi 16 juillet 2014 >> 23:47 À : Henry Fourie; sfc@ietf.org Objet : Re: [sfc] SFC >> Terminology / Concepts >> >> I would hope that we can end up with an archtiecture document that >> is understandable and useful without resorting to a specific >> solution document. That is our goal. There probably are >> refinements needed to achieve that goal. >> >> Yours, Joel >> >> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>> Ken, The Service chain Header draft >>> https://datatracker.ietf.org/doc/draft- >> zhang-sfc-sch/ >>> should answer some of your questions. In particular: >>> >>> In section 4.2 Mandatory Fields: >>> >>> Path Identifier: Identifies a fully instantiated service >>> function path. It represents a sequence of network locators, one >>> for each service function that is to be invoked. Participating >>> SFC entities MUST use this identifier when selecting the next hop >>> for the packet or frame. >>> >>> In section 4.4 Header Associated Operations: >>> >>> 3. Service Path Selection. The Service Network Forwarder (SNF) >>> uses the Service Chain Identification information in the SCH to >>> steer the traffic flow along the SFC path. >>> >>> 4. Service Function Instance Selection. The Service Function >>> Forwarder (SFF) uses the Service Chain Identification >>> information in the SCH to locate the service instance and forward >>> the traffic flow to the service instance. The mapping of the >>> Service Chain Identification to a service instance can be >>> established through the management/control plane, which is out of >>> scope of this document. >>> >>> - Louis >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray) >>> Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau; >>> sfc-chairs@ietf.org Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom >>> Taylor; Joel M. Halpern; >> mohamed.boucadair@orange.com >>> Subject: Re: [sfc] SFC Terminology / Concepts >>> >>> Joel, et. all, >>> >>> I think that some of the questions in architecture (SFP/SFC >>> chasing it's tail) come as people look forward to the >>> encapsulation/header document. That's probably unavoidable. >>> >>> When you read the NSH document, the SFP verbiage says that all >>> participants MUST forward on the SP/SPI, but the document doesn't >>> say how the SPI is derived/calculated (the vision here could be >>> made clearer) or what it's relationship is to the transport path >>> (I think you can't mix >> and >>> match but can accommodate both within the header), should you opt >>> for the transport header forwarding. >>> >>> It's obvious that some deployments prefer to use the transport >>> header for forwarding (SR, IGP/anycast) and some prefer a >>> hop-by-hop lookup (which does play into the SPI or "other >>> mechanisms" that populate a service >> table >>> in the SFF). >>> >>> Perhaps the authors of NSH can suggest verbiage that makes the >>> relationship between transport-based forwarding and >>> service-based forwarding (SPI) clearer? >>> >>> This should eliminate/minimize the calls for >>> redefinition/recasting our terminology and allow us to move on. >>> >>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" >>> wrote: >>> >>>> >>>> I have gotten a bit lost in the SFF/SFC discussion, which seems >>>> to >> have >>>> gotten needlessly complicated and convoluted IMHO. >>>> >>>> Is it possible for the chairs to add this to the list of things >>>> to discuss at the WG meeting or do we want to resolve this on >>>> the list >> ahead >>>> of the meeting? >>>> >>>> --Tom >>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>>> wrote: >>>> >>>>> Hi Peng, >>>>> >>>>>> -----Original Message----- From: He, Peng >>>>>> [mailto:phe@ciena.com] Sent: Tuesday, July 15, 2014 9:09 >>>>>> PM To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. >>>>>> Halpern; Tom Taylor; sfc@ietf.org; Ron Parker Subject: RE: >>>>>> [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Try to understand the three scenarios you listed: you mean >>>>>> the classifier can specify a (partial or complete) SFP >>>>>> which is a list of SFFs, then each SFF will (locally) >>>>>> select one of the SF instances under itself for this SF. >>>>>> For partial SFP case, >>>>> >>>>> In either case, the SFF should be capable of selecting the >>>>> appropriate instance of a given SF attached to itself. it's >>>>> an internal load-balancing issue. >>>>> >>>>>> each SFF will identify the SFI under itself and specify >>>>>> (like a classifier) next SFF(s). The classifier (and SFF?) >>>>>> could obtain this (SFF) 'path' information from either >>>>>> centralized point (e.g., PCE, controller), or, via a >>>>>> distributed control plane? For partial SFP, will there be a >>>>>> re-classification to decide next SFF(s) or not? >>>>> >>>>> If you want the SFF to locally determine the appropriate SFF >>>>> for the next SF, the SFF should have the capability of >>>>> resolving the SFF for >> the >>>>> next SF based on certain constraints. Of course, it needs to >>>>> know some information about the SFs in advance, e.g., the >>>>> information about which SFFs a given SF is attached. >>>>> >>>>> Best regards, Xiaohu >>>>> >>>>>> Regards, Peng >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: >>>>>> Tuesday, July 15, 2014 4:49 AM To: >>>>>> mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>>>> sfc@ietf.org; Ron Parker Subject: Re: [sfc] SFC Terminology >>>>>> / Concepts >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> IMHO, the architecture should allow the classifier to >>>>>> specify >>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP >>>>>> need to locally determine the appropriate SFF for the next >>>>>> SF); 2) a complete SFP (i.e., the SFF for each SF in the >>>>>> SFC has been determined by the centralized node); 3) an SFC >>>>>> (i.e., each SFF along the final SFP needs to locally >>>>>> determine the appropriate SFF for the next SF). >>>>>> >>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>> >>>>>> Best regards, Xiaohu >>>>>> >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com Sent: Tuesday, July 15, 2014 >>>>>>> 3:22 PM To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; >>>>>>> Ron Parker Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>> >>>>>>> Hi Joel, >>>>>>> >>>>>>> As mentioned in several messages, I'm personally for the >>>>>>> use of the chain itself is the main information to be >>>>>>> conveyed in packets to drive >>>>>> forwarding actions. >>>>>>> >>>>>>> I can understand that an identifier can be assigned to a >>>>>>> path that is known in advance, but if that path is not >>>>>>> known I'm not sure how an identifier can be assigned to >>>>>>> it! >>>>>>> >>>>>>> Joel, the use of "path" is really inappropriate to refer >>>>>>> to distributed instance selection process for packets >>>>>>> bound to a given SFC. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Joel M. >>>>>>>> Halpern Envoyé : lundi 14 juillet 2014 21:52 À : Tom >>>>>>>> Taylor; sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC >>>>>>>> Terminology / Concepts >>>>>>>> >>>>>>>> The most likely realization of the architecture would >>>>>>>> be that the >> SFP >>>>>>>> assignment is recorded in an identifier which travels >>>>>>>> with the packet. >>>>>>>> >>>>>>>> Some folks seem to not want the architecture to mandate >>>>>>>> that. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> >>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>> Your text scares me because it introduces some new >>>>>>>>> concepts and assumptions. >>>>>>>>> >>>>>>>>> I'd rather go with Joel's formulation. Clarifying >>>>>>>>> question on that: am I right in seeing the >>>>>>>>> implication that when control assigns an SFP, the >>>>>>>>> assignment is recorded by an identifier wwhich >>>>>>>>> travels with the >>>>>>> packet? >>>>>>>>> >>>>>>>>> Tom Taylor >>>>>>>>> >>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>> There is one missing word in my text. Please >>>>>>>>>> replace my proposed text with: >>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) provides a fully >>>>>>>>>> abstract view of the service functions to be >>>>>>>>>> invoked and the order in which they are to be >>>>>>>>>> invoked for some particular flow or set of flows, >> without >>>>>> concern of >>>>>>>>>> actual service function instance selection. The >>>>>>>>>> Constrained-SFC (C-SFC) further allows for policy >>>>>>>>>> constraints to be added to the SFC affecting the >>>>>>>>>> instance selection of one or more of the service >>>>>> functions >>>>>>>>>> in the SFC. Any SFC may have any number of >>>>>>>>>> C-SFC's associated with >>>>>>>> it." >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>>>>>>>>> Of *David Allan I *Sent:* Monday, July 14, 2014 >>>>>>>>>> 2:03 PM *To:* Jim Guichard (jguichar); >>>>>>>>>> sfc@ietf.org *Subject:* Re: >>>>>>>>>> [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where >>>>>>>>>> an implementation has the option of making scale >>>>>>>>>> and resiliency a local >>>>>> matter.. >>>>>>>>>> >>>>>>>>>> D >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf >>>>>>>>>> Of *Jim Guichard (jguichar) *Sent:* Monday, July >>>>>>>>>> 14, 2014 10:48 AM *To:* sfc@ietf.org >>>>>>>>>> *Subject:* [sfc] SFC >>>>>>>>>> Terminology / Concepts >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> There has been much debate over the last few days >>>>>>>>>> with regards to SFC concepts. To try and form some >>>>>>>>>> consensus around terminology and concepts used to >>>>>>>>>> describe the architecture in the merged >>>>>>>>>> architecture draft, Joel has kindly suggested the >>>>>>>>>> following: >>>>>>>>>> >>>>>>>>>> "The SFP provides a level of indirection between >>>>>>>>>> the fully abstract notion of service path as a >>>>>>>>>> sequence of functions to be delivered, and the >>>>>>>>>> fully specified notion of exactly what instances of >>>>>>>>>> SFFs the packet will visit when it actually >>>>>>>>>> traverses the network. By allowing the control >>>>>>>>>> components to specify the use of this level of >>>>>>>>>> indirection, the deployment may choose the degree >>>>>>>>>> of SFF instance selection authority that is >>>>>>>>>> delegated to the network." >>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if this >>>>>>>>>> clarification is something that we can get >>>>>>>>>> consensus on. If so, I'll ask Joel to provide >>>>>>>>>> specific text, that reflects the above, for >>>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>>> >>>>>>>>>> Thank You, >>>>>>>>>> >>>>>>>>>> Jim >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ sfc mailing 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 Sat Jul 19 18:18: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 A09121B2B4D for ; Sat, 19 Jul 2014 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 sySawKoru3pw for ; Sat, 19 Jul 2014 18:18:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FE91B2B4B for ; Sat, 19 Jul 2014 18:18:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKH13819; Sun, 20 Jul 2014 01:18:29 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 20 Jul 2014 02:18:26 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Sat, 19 Jul 2014 18:18:08 -0700 From: Linda Dunbar To: Joel Halpern Direct , "mohamed.boucadair@orange.com" , Henry Fourie , "sfc@ietf.org" Thread-Topic: MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly Thread-Index: AQHPo7PONTAbQXo9v0momypO37O93puom3mA//+M/xA= Date: Sun, 20 Jul 2014 01:18:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA03D7@dfweml701-chm.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> <53CB15F7.6060305@joelhalpern.com> In-Reply-To: <53CB15F7.6060305@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.109] 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/U-gTTjdHBlElYcemJHXnaRq8r38 Subject: Re: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 01:18:34 -0000 Joel,=20 Thanks for the acknowledgement.=20 Linda -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Saturday, July 19, 2014 8:06 PM To: Linda Dunbar; mohamed.boucadair@orange.com; Henry Fourie; sfc@ietf.org Subject: Re: MTU section of merged-sfc-arch should emphasize the importance= of avoiding packets fragmentation/reassembly, not how modern systems can h= andle packets fragmentation/reassembly I am sorry that we forgot to make the improvements we had discussed with yo= u to the MTU section. We should have improved it as part of producing this= draft. We will improve the text, making use of your text as much as we can. I exp= ect that we will emphasis the fact that SF can not be expected to perform r= eassembly, and that having SFF or proxy functions do it for them is also ve= ry expensive. My inclination is to focus on your points about the importance of compactne= ss, rather than particularly on L4-L7 or particularly on=20 listing addresses. I think trying to get to specific about things to=20 avoid will weaken the text, and cause contention. Yours, Joel On 7/19/14, 8:44 PM, Linda Dunbar wrote: > The MTU section of the merged-sfc-arch is one example showing what Med=20 > said about the current architecture "including some solution hints=20 > that come mainly from nsh". > > > An important part of SFC is the SFC header encapsulation. Therefore,=20 > the MTU section should emphasize the importance of avoiding packets=20 > fragmentation and reassembly because most service functions,=20 > especially legacy L4-L7 service functions, don't expect fragmented=20 > packets. It is very expensive for intermediate SFF/SN nodes to=20 > reassemble packets before passing packets to Service Functions. E.g. > The SFC header should avoid literally listing the addresses=20 > (especially IPv6 addresses) of the service functions in a service=20 > function chain. > > But final MTU Section emphasizes that the modern systems can handle=20 > packets fragmentation and reassembly, meaning NSH header (no matter=20 > how long) is no problem. > > > I had a two separate conference calls with the authors of the=20 > SFC-architecture draft addressing suggested merging of some content=20 > from "legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than > 1 hour). > > One of the issues being discussed is the MTU section. Here is text=20 > that I suggested to merge with the general "sfc-arch": > > "Encapsulating SFC header to data packets has to take MTU size into=20 > consideration because most service functions, especially legacy L4-L7=20 > service functions, don't expect fragmented packets. It is very=20 > expensive for intermediate SFF/SN nodes to reassemble packets before=20 > passing packets to Service Functions. Therefore, the information=20 > carried by the SFC header has to be compact. The SFC header should=20 > avoid literally listing the addresses (especially IPv6 addresses) of=20 > the service functions in a service function chain." > > I sincerely hope that the authors can take this text (or variation of=20 > this text) for the MTU section of sfc-arch. > > Linda > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On=20 > Behalf Of mohamed.boucadair@orange.com Sent: Thursday, July 17, 2014 > 12:57 AM To: Joel M. Halpern; Henry Fourie; sfc@ietf.org Subject: Re: > [sfc] SFC Terminology / Concepts > > Hi Joel, > > I fully agree with you about the goal. > > Nevertheless, the merged document, as it currently stands, includes=20 > some solution hints that come mainly from nsh. I would really hope the=20 > document be updated to be neutral. > > Cheers, Med > >> -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org] De=20 >> la part de Joel M. Halpern Envoy=E9 : mercredi 16 juillet 2014 >> 23:47 =C0 : Henry Fourie; sfc@ietf.org Objet : Re: [sfc] SFC=20 >> Terminology / Concepts >> >> I would hope that we can end up with an archtiecture document that is=20 >> understandable and useful without resorting to a specific solution=20 >> document. That is our goal. There probably are refinements needed=20 >> to achieve that goal. >> >> Yours, Joel >> >> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>> Ken, The Service chain Header draft >>> https://datatracker.ietf.org/doc/draft- >> zhang-sfc-sch/ >>> should answer some of your questions. In particular: >>> >>> In section 4.2 Mandatory Fields: >>> >>> Path Identifier: Identifies a fully instantiated service function=20 >>> path. It represents a sequence of network locators, one for each=20 >>> service function that is to be invoked. Participating SFC entities=20 >>> MUST use this identifier when selecting the next hop for the packet=20 >>> or frame. >>> >>> In section 4.4 Header Associated Operations: >>> >>> 3. Service Path Selection. The Service Network Forwarder (SNF) uses=20 >>> the Service Chain Identification information in the SCH to steer the=20 >>> traffic flow along the SFC path. >>> >>> 4. Service Function Instance Selection. The Service Function=20 >>> Forwarder (SFF) uses the Service Chain Identification information in=20 >>> the SCH to locate the service instance and forward the traffic flow=20 >>> to the service instance. The mapping of the Service Chain=20 >>> Identification to a service instance can be established through the=20 >>> management/control plane, which is out of scope of this document. >>> >>> - Louis >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of Ken Gray (kegray) >>> Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau;=20 >>> sfc-chairs@ietf.org Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom=20 >>> Taylor; Joel M. Halpern; >> mohamed.boucadair@orange.com >>> Subject: Re: [sfc] SFC Terminology / Concepts >>> >>> Joel, et. all, >>> >>> I think that some of the questions in architecture (SFP/SFC chasing=20 >>> it's tail) come as people look forward to the encapsulation/header=20 >>> document. That's probably unavoidable. >>> >>> When you read the NSH document, the SFP verbiage says that all=20 >>> participants MUST forward on the SP/SPI, but the document doesn't=20 >>> say how the SPI is derived/calculated (the vision here could be made=20 >>> clearer) or what it's relationship is to the transport path (I think=20 >>> you can't mix >> and >>> match but can accommodate both within the header), should you opt=20 >>> for the transport header forwarding. >>> >>> It's obvious that some deployments prefer to use the transport=20 >>> header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop=20 >>> lookup (which does play into the SPI or "other mechanisms" that=20 >>> populate a service >> table >>> in the SFF). >>> >>> Perhaps the authors of NSH can suggest verbiage that makes the=20 >>> relationship between transport-based forwarding and service-based=20 >>> forwarding (SPI) clearer? >>> >>> This should eliminate/minimize the calls for redefinition/recasting=20 >>> our terminology and allow us to move on. >>> >>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" >>> wrote: >>> >>>> >>>> I have gotten a bit lost in the SFF/SFC discussion, which seems to >> have >>>> gotten needlessly complicated and convoluted IMHO. >>>> >>>> Is it possible for the chairs to add this to the list of things to=20 >>>> discuss at the WG meeting or do we want to resolve this on the list >> ahead >>>> of the meeting? >>>> >>>> --Tom >>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu=20 >>>> wrote: >>>> >>>>> Hi Peng, >>>>> >>>>>> -----Original Message----- From: He, Peng [mailto:phe@ciena.com]=20 >>>>>> Sent: Tuesday, July 15, 2014 9:09 PM To: Xuxiaohu;=20 >>>>>> mohamed.boucadair@orange.com; Joel M. >>>>>> Halpern; Tom Taylor; sfc@ietf.org; Ron Parker Subject: RE: >>>>>> [sfc] SFC Terminology / Concepts >>>>>> >>>>>> Try to understand the three scenarios you listed: you mean the=20 >>>>>> classifier can specify a (partial or complete) SFP which is a=20 >>>>>> list of SFFs, then each SFF will (locally) select one of the SF=20 >>>>>> instances under itself for this SF. >>>>>> For partial SFP case, >>>>> >>>>> In either case, the SFF should be capable of selecting the=20 >>>>> appropriate instance of a given SF attached to itself. it's an=20 >>>>> internal load-balancing issue. >>>>> >>>>>> each SFF will identify the SFI under itself and specify (like a=20 >>>>>> classifier) next SFF(s). The classifier (and SFF?) could obtain=20 >>>>>> this (SFF) 'path' information from either centralized point=20 >>>>>> (e.g., PCE, controller), or, via a distributed control plane? For=20 >>>>>> partial SFP, will there be a re-classification to decide next=20 >>>>>> SFF(s) or not? >>>>> >>>>> If you want the SFF to locally determine the appropriate SFF for=20 >>>>> the next SF, the SFF should have the capability of resolving the=20 >>>>> SFF for >> the >>>>> next SF based on certain constraints. Of course, it needs to know=20 >>>>> some information about the SFs in advance, e.g., the information=20 >>>>> about which SFFs a given SF is attached. >>>>> >>>>> Best regards, Xiaohu >>>>> >>>>>> Regards, Peng >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc=20 >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: >>>>>> Tuesday, July 15, 2014 4:49 AM To: >>>>>> mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor;=20 >>>>>> sfc@ietf.org; Ron Parker Subject: Re: [sfc] SFC Terminology /=20 >>>>>> Concepts >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> IMHO, the architecture should allow the classifier to specify >>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to=20 >>>>>> locally determine the appropriate SFF for the next SF); 2) a=20 >>>>>> complete SFP (i.e., the SFF for each SF in the SFC has been=20 >>>>>> determined by the centralized node); 3) an SFC (i.e., each SFF=20 >>>>>> along the final SFP needs to locally determine the appropriate=20 >>>>>> SFF for the next SF). >>>>>> >>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>> >>>>>> Best regards, Xiaohu >>>>>> >>>>>>> -----Original Message----- From: sfc=20 >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>> mohamed.boucadair@orange.com Sent: Tuesday, July 15, 2014 >>>>>>> 3:22 PM To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron=20 >>>>>>> Parker Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>> >>>>>>> Hi Joel, >>>>>>> >>>>>>> As mentioned in several messages, I'm personally for the use of=20 >>>>>>> the chain itself is the main information to be conveyed in=20 >>>>>>> packets to drive >>>>>> forwarding actions. >>>>>>> >>>>>>> I can understand that an identifier can be assigned to a path=20 >>>>>>> that is known in advance, but if that path is not known I'm not=20 >>>>>>> sure how an identifier can be assigned to it! >>>>>>> >>>>>>> Joel, the use of "path" is really inappropriate to refer to=20 >>>>>>> distributed instance selection process for packets bound to a=20 >>>>>>> given SFC. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Joel M. >>>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor;=20 >>>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology /=20 >>>>>>>> Concepts >>>>>>>> >>>>>>>> The most likely realization of the architecture would be that=20 >>>>>>>> the >> SFP >>>>>>>> assignment is recorded in an identifier which travels with the=20 >>>>>>>> packet. >>>>>>>> >>>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> >>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>> Your text scares me because it introduces some new concepts=20 >>>>>>>>> and assumptions. >>>>>>>>> >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on=20 >>>>>>>>> that: am I right in seeing the implication that when control=20 >>>>>>>>> assigns an SFP, the assignment is recorded by an identifier=20 >>>>>>>>> wwhich travels with the >>>>>>> packet? >>>>>>>>> >>>>>>>>> Tom Taylor >>>>>>>>> >>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>> There is one missing word in my text. Please >>>>>>>>>> replace my proposed text with: >>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract=20 >>>>>>>>>> view of the service functions to be invoked and the order in=20 >>>>>>>>>> which they are to be invoked for some particular flow or set=20 >>>>>>>>>> of flows, >> without >>>>>> concern of >>>>>>>>>> actual service function instance selection. The >>>>>>>>>> Constrained-SFC (C-SFC) further allows for policy constraints=20 >>>>>>>>>> to be added to the SFC affecting the instance selection of=20 >>>>>>>>>> one or more of the service >>>>>> functions >>>>>>>>>> in the SFC. Any SFC may have any number of >>>>>>>>>> C-SFC's associated with >>>>>>>> it." >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David=20 >>>>>>>>>> Allan I *Sent:* Monday, July 14, 2014 >>>>>>>>>> 2:03 PM *To:* Jim Guichard (jguichar); sfc@ietf.org=20 >>>>>>>>>> *Subject:* Re: >>>>>>>>>> [sfc] SFC Terminology / Concepts >>>>>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where an=20 >>>>>>>>>> implementation has the option of making scale and resiliency=20 >>>>>>>>>> a local >>>>>> matter.. >>>>>>>>>> >>>>>>>>>> D >>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim=20 >>>>>>>>>> Guichard (jguichar) *Sent:* Monday, July 14, 2014 10:48 AM=20 >>>>>>>>>> *To:* sfc@ietf.org *Subject:* [sfc] SFC=20 >>>>>>>>>> Terminology / Concepts >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> There has been much debate over the last few days with=20 >>>>>>>>>> regards to SFC concepts. To try and form some consensus=20 >>>>>>>>>> around terminology and concepts used to describe the=20 >>>>>>>>>> architecture in the merged architecture draft, Joel has=20 >>>>>>>>>> kindly suggested the >>>>>>>>>> following: >>>>>>>>>> >>>>>>>>>> "The SFP provides a level of indirection between the fully=20 >>>>>>>>>> abstract notion of service path as a sequence of functions to=20 >>>>>>>>>> be delivered, and the fully specified notion of exactly what=20 >>>>>>>>>> instances of SFFs the packet will visit when it actually=20 >>>>>>>>>> traverses the network. By allowing the control components to=20 >>>>>>>>>> specify the use of this level of indirection, the deployment=20 >>>>>>>>>> may choose the degree of SFF instance selection authority=20 >>>>>>>>>> that is delegated to the network." >>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is=20 >>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel=20 >>>>>>>>>> to provide specific text, that reflects the above, for=20 >>>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>>> >>>>>>>>>> Thank You, >>>>>>>>>> >>>>>>>>>> Jim >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ sfc mailing 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 Sat Jul 19 18:41: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 A601E1B2B52 for ; Sat, 19 Jul 2014 18:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OL9IiYmEz8SM for ; Sat, 19 Jul 2014 18:41:27 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A76D1A030C for ; Sat, 19 Jul 2014 18:41:27 -0700 (PDT) Received: from emg-ca-1-1 (localhost [127.0.0.1]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id 1072F53DF7; Sat, 19 Jul 2014 18:41:22 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Sat, 19 Jul 2014 18:41:22.004 -0700 x-echoworx-msg-id: 185e3e86-6904-4aa1-967b-9a15c65a27ce x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-1 (JAMES SMTP Server 2.3.2) with SMTP ID 988; Sat, 19 Jul 2014 18:41:21 -0700 (PDT) Received: from HUB021-CA-6.exch021.domain.local (unknown [10.254.4.92]) by emg-ca-1-1.localdomain (Postfix) with ESMTP id DE94B53DF7; Sat, 19 Jul 2014 18:41:21 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Sat, 19 Jul 2014 18:41:26 -0700 From: Ron Parker To: Linda Dunbar Thread-Topic: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly Thread-Index: AQHPo7Pakh5jn94fjk+h2QZLGyNNGZuopSuA Date: Sun, 20 Jul 2014 01:41:25 +0000 Message-ID: References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-source-routing-agent: Processed Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/gY6xYyWskI1rs49PzEDGwzcITlw Cc: Henry Fourie , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 01:41:30 -0000 TGluZGEsDQoNCkknbSBub3QgZGViYXRpbmcgdGhhdCBmcmFnbWVudGF0aW9uIHNob3VsZCBiZSBt aW5pbWl6ZWQuICAgQnV0LCB3cnQgbGVnYWN5IFNGJ3MgLS0gaWYgdGhlIHRyYW5zcG9ydCArIHNl cnZpY2UgZW5jYXBzIGluY3JlYXNlcyB0aGUgcGFja2V0IGVub3VnaCB0byBjYXVzZSBmcmFnbWVu dGF0aW9uLCB3b3VsZG4ndCBpdCBiZSBhdCB0aGUgdHJhbnNwb3J0IGxldmVsIGFuZCBub3QgYXQg dGhlIGxldmVsIG9mIHRoZSBvcmlnaW5hbCBwYWNrZXQ/ICAgW0dpdmVuIHRoYXQgaXQgY2FuIG9u bHkgYmUgc28gZm9yIGZyYWdtZW50YWJsZSB0cmFuc3BvcnRzIChpZSBpcHY0LCBpcHY2KV0uIA0K DQogICBSb24NCg0KDQo+IE9uIEp1bCAxOSwgMjAxNCwgYXQgODo0NSBQTSwgIkxpbmRhIER1bmJh ciIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IFRoZSBNVFUgc2VjdGlv biBvZiB0aGUgbWVyZ2VkLXNmYy1hcmNoIGlzIG9uZSBleGFtcGxlIHNob3dpbmcgd2hhdCBNZWQg c2FpZCBhYm91dCB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUgImluY2x1ZGluZyBzb21lIHNvbHV0 aW9uIGhpbnRzIHRoYXQgY29tZSBtYWlubHkgZnJvbSBuc2giLg0KPiANCj4gDQo+IEFuIGltcG9y dGFudCBwYXJ0IG9mIFNGQyBpcyB0aGUgU0ZDIGhlYWRlciBlbmNhcHN1bGF0aW9uLiANCj4gVGhl cmVmb3JlLCB0aGUgTVRVIHNlY3Rpb24gc2hvdWxkIGVtcGhhc2l6ZSB0aGUgaW1wb3J0YW5jZSBv ZiBhdm9pZGluZyBwYWNrZXRzIGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgYmVjYXVzZSBt b3N0IHNlcnZpY2UgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IGxlZ2FjeSBMNC1MNyBzZXJ2aWNlIGZ1 bmN0aW9ucywgZG9uJ3QgZXhwZWN0IGZyYWdtZW50ZWQgcGFja2V0cy4gSXQgaXMgdmVyeSBleHBl bnNpdmUgZm9yIGludGVybWVkaWF0ZSBTRkYvU04gbm9kZXMgdG8gcmVhc3NlbWJsZSBwYWNrZXRz IGJlZm9yZSBwYXNzaW5nIHBhY2tldHMgdG8gU2VydmljZSBGdW5jdGlvbnMuIEUuZy4gVGhlIFNG QyBoZWFkZXIgc2hvdWxkIGF2b2lkIGxpdGVyYWxseSBsaXN0aW5nIHRoZSBhZGRyZXNzZXMgKGVz cGVjaWFsbHkgSVB2NiBhZGRyZXNzZXMpIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBhIHNl cnZpY2UgZnVuY3Rpb24gY2hhaW4uDQo+IA0KPiBCdXQgZmluYWwgTVRVIFNlY3Rpb24gZW1waGFz aXplcyB0aGF0IHRoZSBtb2Rlcm4gc3lzdGVtcyBjYW4gaGFuZGxlIHBhY2tldHMgZnJhZ21lbnRh dGlvbiBhbmQgcmVhc3NlbWJseSwgbWVhbmluZyBOU0ggaGVhZGVyIChubyBtYXR0ZXIgaG93IGxv bmcpIGlzIG5vIHByb2JsZW0uDQo+IA0KPiANCj4gSSBoYWQgYSB0d28gc2VwYXJhdGUgY29uZmVy ZW5jZSBjYWxscyAgd2l0aCB0aGUgYXV0aG9ycyBvZiB0aGUgU0ZDLWFyY2hpdGVjdHVyZSBkcmFm dCBhZGRyZXNzaW5nIHN1Z2dlc3RlZCBtZXJnaW5nIG9mIHNvbWUgY29udGVudCBmcm9tICJsZWdh Y3ktbDQtbDctYXJjaCIgdG8gZ2VuZXJhbCAic2ZjLWFyY2giIChlYWNoIGxhc3RlZCBtb3JlIHRo YW4gMSBob3VyKS4gDQo+IA0KPiBPbmUgb2YgdGhlIGlzc3VlcyBiZWluZyBkaXNjdXNzZWQgaXMg dGhlIE1UVSBzZWN0aW9uLiBIZXJlIGlzIHRleHQgdGhhdCBJIHN1Z2dlc3RlZCB0byBtZXJnZSB3 aXRoIHRoZSBnZW5lcmFsICJzZmMtYXJjaCI6DQo+IA0KPiAiRW5jYXBzdWxhdGluZyBTRkMgaGVh ZGVyIHRvIGRhdGEgcGFja2V0cyBoYXMgdG8gdGFrZSBNVFUgc2l6ZSBpbnRvIGNvbnNpZGVyYXRp b24gYmVjYXVzZSBtb3N0IHNlcnZpY2UgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IGxlZ2FjeSBMNC1M NyBzZXJ2aWNlIGZ1bmN0aW9ucywgZG9uJ3QgZXhwZWN0IGZyYWdtZW50ZWQgcGFja2V0cy4gDQo+ IEl0IGlzIHZlcnkgZXhwZW5zaXZlIGZvciBpbnRlcm1lZGlhdGUgU0ZGL1NOIG5vZGVzIHRvIHJl YXNzZW1ibGUgcGFja2V0cyBiZWZvcmUgcGFzc2luZyBwYWNrZXRzIHRvIFNlcnZpY2UgRnVuY3Rp b25zLiANCj4gVGhlcmVmb3JlLCB0aGUgaW5mb3JtYXRpb24gY2FycmllZCBieSB0aGUgU0ZDIGhl YWRlciBoYXMgdG8gYmUgY29tcGFjdC4gVGhlIFNGQyBoZWFkZXIgc2hvdWxkIGF2b2lkIGxpdGVy YWxseSBsaXN0aW5nIHRoZSBhZGRyZXNzZXMgKGVzcGVjaWFsbHkgSVB2NiBhZGRyZXNzZXMpIG9m IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBhIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4uIg0KPiAN Cj4gSSBzaW5jZXJlbHkgaG9wZSB0aGF0IHRoZSBhdXRob3JzIGNhbiB0YWtlIHRoaXMgdGV4dCAo b3IgdmFyaWF0aW9uIG9mIHRoaXMgdGV4dCkgZm9yIHRoZSBNVFUgc2VjdGlvbiBvZiBzZmMtYXJj aC4gDQo+IA0KPiBMaW5kYQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE3LCAyMDE0IDEy OjU3IEFNDQo+IFRvOiBKb2VsIE0uIEhhbHBlcm47IEhlbnJ5IEZvdXJpZTsgc2ZjQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPiANCj4g SGkgSm9lbCwNCj4gDQo+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIGdvYWwuIA0K PiANCj4gTmV2ZXJ0aGVsZXNzLCB0aGUgbWVyZ2VkIGRvY3VtZW50LCBhcyBpdCBjdXJyZW50bHkg c3RhbmRzLCBpbmNsdWRlcyBzb21lIHNvbHV0aW9uIGhpbnRzIHRoYXQgY29tZSBtYWlubHkgZnJv bSBuc2guIEkgd291bGQgcmVhbGx5IGhvcGUgdGhlIGRvY3VtZW50IGJlIHVwZGF0ZWQgdG8gYmUg bmV1dHJhbC4gDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPj4gRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4gDQo+PiBFbnZvecOpIDogbWVyY3JlZGkgMTYganVp bGxldCAyMDE0IDIzOjQ3IMOAIDogSGVucnkgRm91cmllOyBzZmNAaWV0Zi5vcmcgDQo+PiBPYmpl dCA6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPj4gDQo+PiBJIHdvdWxk IGhvcGUgdGhhdCB3ZSBjYW4gZW5kIHVwIHdpdGggYW4gYXJjaHRpZWN0dXJlIGRvY3VtZW50IHRo YXQgaXMgDQo+PiB1bmRlcnN0YW5kYWJsZSBhbmQgdXNlZnVsIHdpdGhvdXQgcmVzb3J0aW5nIHRv IGEgc3BlY2lmaWMgc29sdXRpb24gDQo+PiBkb2N1bWVudC4gIFRoYXQgaXMgb3VyIGdvYWwuICBU aGVyZSBwcm9iYWJseSBhcmUgcmVmaW5lbWVudHMgbmVlZGVkIHRvIA0KPj4gYWNoaWV2ZSB0aGF0 IGdvYWwuDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+Pj4gT24gNy8xNi8xNCwgNToz OSBQTSwgSGVucnkgRm91cmllIHdyb3RlOg0KPj4+IEtlbiwNCj4+PiAgIFRoZSBTZXJ2aWNlIGNo YWluIEhlYWRlciBkcmFmdCANCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC0NCj4+IHpoYW5nLXNmYy1zY2gvDQo+Pj4gc2hvdWxkIGFuc3dlciBzb21lIG9mIHlvdXIg cXVlc3Rpb25zLiBJbiBwYXJ0aWN1bGFyOg0KPj4+IA0KPj4+IEluIHNlY3Rpb24gNC4yIE1hbmRh dG9yeSBGaWVsZHM6DQo+Pj4gDQo+Pj4gICAgUGF0aCBJZGVudGlmaWVyOiBJZGVudGlmaWVzIGEg ZnVsbHkgaW5zdGFudGlhdGVkIHNlcnZpY2UgZnVuY3Rpb24NCj4+PiAgICAgICBwYXRoLiBJdCBy ZXByZXNlbnRzIGEgc2VxdWVuY2Ugb2YgbmV0d29yayBsb2NhdG9ycywgb25lIGZvciBlYWNoDQo+ Pj4gICAgICAgc2VydmljZSBmdW5jdGlvbiB0aGF0IGlzIHRvIGJlIGludm9rZWQuIFBhcnRpY2lw YXRpbmcgU0ZDIGVudGl0aWVzDQo+Pj4gICAgICAgTVVTVCB1c2UgdGhpcyBpZGVudGlmaWVyIHdo ZW4gc2VsZWN0aW5nIHRoZSBuZXh0IGhvcCBmb3IgdGhlDQo+Pj4gICAgICAgcGFja2V0IG9yIGZy YW1lLg0KPj4+IA0KPj4+IEluIHNlY3Rpb24gNC40IEhlYWRlciBBc3NvY2lhdGVkIE9wZXJhdGlv bnM6DQo+Pj4gDQo+Pj4gICAgMy4gU2VydmljZSBQYXRoIFNlbGVjdGlvbi4gVGhlIFNlcnZpY2Ug TmV0d29yayBGb3J3YXJkZXIgKFNORikgdXNlcw0KPj4+ICAgICAgIHRoZSBTZXJ2aWNlIENoYWlu IElkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIGluIHRoZSBTQ0ggdG8gc3RlZXINCj4+PiAgICAg ICB0aGUgdHJhZmZpYyBmbG93IGFsb25nIHRoZSBTRkMgcGF0aC4NCj4+PiANCj4+PiAgICA0LiBT ZXJ2aWNlIEZ1bmN0aW9uIEluc3RhbmNlIFNlbGVjdGlvbi4gVGhlIFNlcnZpY2UgRnVuY3Rpb24N Cj4+PiAgICAgICBGb3J3YXJkZXIgKFNGRikgdXNlcyB0aGUgU2VydmljZSBDaGFpbiBJZGVudGlm aWNhdGlvbiBpbmZvcm1hdGlvbg0KPj4+ICAgICAgIGluIHRoZSBTQ0ggdG8gbG9jYXRlIHRoZSBz ZXJ2aWNlIGluc3RhbmNlIGFuZCBmb3J3YXJkIHRoZSB0cmFmZmljDQo+Pj4gICAgICAgZmxvdyB0 byB0aGUgc2VydmljZSBpbnN0YW5jZS4gVGhlIG1hcHBpbmcgb2YgdGhlIFNlcnZpY2UgQ2hhaW4N Cj4+PiAgICAgICBJZGVudGlmaWNhdGlvbiB0byBhIHNlcnZpY2UgaW5zdGFuY2UgY2FuIGJlIGVz dGFibGlzaGVkIHRocm91Z2gNCj4+PiAgICAgICB0aGUgbWFuYWdlbWVudC9jb250cm9sIHBsYW5l LCB3aGljaCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcw0KPj4+ICAgICAgIGRvY3VtZW50Lg0KPj4+ IA0KPj4+ICAtIExvdWlzDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtl biBHcmF5IA0KPj4+IChrZWdyYXkpDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE2LCAyMDE0 IDExOjU5IEFNDQo+Pj4gVG86IFRob21hcyBELiBOYWRlYXU7IHNmYy1jaGFpcnNAaWV0Zi5vcmcN Cj4+PiBDYzogc2ZjQGlldGYub3JnOyBIZSwgUGVuZzsgUm9uIFBhcmtlcjsgVG9tIFRheWxvcjsg Sm9lbCBNLiBIYWxwZXJuOw0KPj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPj4+IA0KPj4+IEpv ZWwsIGV0LiBhbGwsDQo+Pj4gDQo+Pj4gSSB0aGluayB0aGF0IHNvbWUgb2YgdGhlIHF1ZXN0aW9u cyBpbiBhcmNoaXRlY3R1cmUgKFNGUC9TRkMgY2hhc2luZyANCj4+PiBpdCdzDQo+Pj4gdGFpbCkg Y29tZSBhcyBwZW9wbGUgbG9vayBmb3J3YXJkIHRvIHRoZSBlbmNhcHN1bGF0aW9uL2hlYWRlciBk b2N1bWVudC4NCj4+PiBUaGF0J3MgcHJvYmFibHkgdW5hdm9pZGFibGUuDQo+Pj4gDQo+Pj4gV2hl biB5b3UgcmVhZCB0aGUgTlNIIGRvY3VtZW50LCB0aGUgU0ZQIHZlcmJpYWdlIHNheXMgdGhhdCBh bGwgDQo+Pj4gcGFydGljaXBhbnRzIE1VU1QgZm9yd2FyZCBvbiB0aGUgU1AvU1BJLCBidXQgdGhl IGRvY3VtZW50IGRvZXNuJ3Qgc2F5IA0KPj4+IGhvdyB0aGUgU1BJIGlzIGRlcml2ZWQvY2FsY3Vs YXRlZCAodGhlIHZpc2lvbiBoZXJlIGNvdWxkIGJlIG1hZGUgDQo+Pj4gY2xlYXJlcikgb3Igd2hh dCBpdCdzIHJlbGF0aW9uc2hpcCBpcyB0byB0aGUgdHJhbnNwb3J0IHBhdGggKEkgdGhpbmsgDQo+ Pj4geW91IGNhbid0IG1peA0KPj4gYW5kDQo+Pj4gbWF0Y2ggYnV0IGNhbiBhY2NvbW1vZGF0ZSBi b3RoIHdpdGhpbiB0aGUgaGVhZGVyKSwgc2hvdWxkIHlvdSBvcHQgZm9yIA0KPj4+IHRoZSB0cmFu c3BvcnQgaGVhZGVyIGZvcndhcmRpbmcuDQo+Pj4gDQo+Pj4gSXQncyBvYnZpb3VzIHRoYXQgc29t ZSBkZXBsb3ltZW50cyBwcmVmZXIgdG8gdXNlIHRoZSB0cmFuc3BvcnQgaGVhZGVyIA0KPj4+IGZv ciBmb3J3YXJkaW5nIChTUiwgSUdQL2FueWNhc3QpIGFuZCBzb21lIHByZWZlciBhIGhvcC1ieS1o b3AgbG9va3VwIA0KPj4+ICh3aGljaCBkb2VzIHBsYXkgaW50byB0aGUgU1BJIG9yICJvdGhlciBt ZWNoYW5pc21zIiB0aGF0IHBvcHVsYXRlIGEgDQo+Pj4gc2VydmljZQ0KPj4gdGFibGUNCj4+PiBp biB0aGUgU0ZGKS4NCj4+PiANCj4+PiBQZXJoYXBzIHRoZSBhdXRob3JzIG9mIE5TSCBjYW4gc3Vn Z2VzdCB2ZXJiaWFnZSB0aGF0IG1ha2VzIHRoZSANCj4+PiByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 cmFuc3BvcnQtYmFzZWQgZm9yd2FyZGluZyBhbmQgc2VydmljZS1iYXNlZCANCj4+PiBmb3J3YXJk aW5nIChTUEkpIGNsZWFyZXI/DQo+Pj4gDQo+Pj4gVGhpcyBzaG91bGQgZWxpbWluYXRlL21pbmlt aXplIHRoZSBjYWxscyBmb3IgcmVkZWZpbml0aW9uL3JlY2FzdGluZyANCj4+PiBvdXIgdGVybWlu b2xvZ3kgYW5kIGFsbG93IHVzIHRvIG1vdmUgb24uDQo+Pj4gDQo+Pj4+IE9uIDcvMTYvMTQgMToy MyBQTSwgIlRob21hcyBELiBOYWRlYXUiIDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4gd3JvdGU6 DQo+Pj4+IA0KPj4+PiANCj4+Pj4gICAgSSBoYXZlIGdvdHRlbiBhIGJpdCBsb3N0IGluIHRoZSBT RkYvU0ZDIGRpc2N1c3Npb24sIHdoaWNoIHNlZW1zIHRvDQo+PiBoYXZlDQo+Pj4+IGdvdHRlbiBu ZWVkbGVzc2x5IGNvbXBsaWNhdGVkIGFuZCBjb252b2x1dGVkIElNSE8uDQo+Pj4+IA0KPj4+PiAg ICBJcyBpdCBwb3NzaWJsZSBmb3IgdGhlIGNoYWlycyB0byBhZGQgdGhpcyB0byB0aGUgbGlzdCBv ZiB0aGluZ3MgdG8gDQo+Pj4+IGRpc2N1c3MgYXQgdGhlIFdHIG1lZXRpbmcgb3IgZG8gd2Ugd2Fu dCB0byByZXNvbHZlIHRoaXMgb24gdGhlIGxpc3QNCj4+IGFoZWFkDQo+Pj4+IG9mIHRoZSBtZWV0 aW5nPw0KPj4+PiANCj4+Pj4gICAgLS1Ub20NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiBKdWwgMTUs IDIwMTQ6MTA6NTcgUE0sIGF0IDEwOjU3IFBNLCBYdXhpYW9odSANCj4+Pj4gPHh1eGlhb2h1QGh1 YXdlaS5jb20+DQo+Pj4+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIFBlbmcsDQo+Pj4+PiANCj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IEhlLCBQZW5nIFtt YWlsdG86cGhlQGNpZW5hLmNvbV0NCj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE1LCAyMDE0 IDk6MDkgUE0NCj4+Pj4+PiBUbzogWHV4aWFvaHU7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b207IEpvZWwgTS4gSGFscGVybjsgVG9tIA0KPj4+Pj4+IFRheWxvcjsgc2ZjQGlldGYub3JnOyBS b24gUGFya2VyDQo+Pj4+Pj4gU3ViamVjdDogUkU6IFtzZmNdIFNGQyBUZXJtaW5vbG9neSAvIENv bmNlcHRzDQo+Pj4+Pj4gDQo+Pj4+Pj4gVHJ5IHRvIHVuZGVyc3RhbmQgdGhlIHRocmVlIHNjZW5h cmlvcyB5b3UgbGlzdGVkOiB5b3UgbWVhbiB0aGUgDQo+Pj4+Pj4gY2xhc3NpZmllciBjYW4gc3Bl Y2lmeSBhIChwYXJ0aWFsIG9yIGNvbXBsZXRlKSBTRlAgd2hpY2ggaXMgYSBsaXN0IA0KPj4+Pj4+ IG9mIFNGRnMsIHRoZW4gZWFjaCBTRkYgd2lsbA0KPj4+Pj4+IChsb2NhbGx5KSBzZWxlY3Qgb25l IG9mIHRoZSBTRiBpbnN0YW5jZXMgdW5kZXIgaXRzZWxmIGZvciB0aGlzIFNGLiANCj4+Pj4+PiBG b3IgcGFydGlhbCBTRlAgY2FzZSwNCj4+Pj4+IA0KPj4+Pj4gSW4gZWl0aGVyIGNhc2UsIHRoZSBT RkYgc2hvdWxkIGJlIGNhcGFibGUgb2Ygc2VsZWN0aW5nIHRoZSANCj4+Pj4+IGFwcHJvcHJpYXRl IGluc3RhbmNlIG9mIGEgZ2l2ZW4gU0YgYXR0YWNoZWQgdG8gaXRzZWxmLiBpdCdzIGFuIA0KPj4+ Pj4gaW50ZXJuYWwgbG9hZC1iYWxhbmNpbmcgaXNzdWUuDQo+Pj4+PiANCj4+Pj4+PiBlYWNoIFNG RiB3aWxsIGlkZW50aWZ5IHRoZSBTRkkgdW5kZXIgaXRzZWxmIGFuZCBzcGVjaWZ5IChsaWtlIGEN Cj4+Pj4+PiBjbGFzc2lmaWVyKSBuZXh0IFNGRihzKS4NCj4+Pj4+PiBUaGUgY2xhc3NpZmllciAo YW5kIFNGRj8pIGNvdWxkIG9idGFpbiB0aGlzICAoU0ZGKSAncGF0aCcgDQo+Pj4+Pj4gaW5mb3Jt YXRpb24NCj4+Pj4+PiBmcm9tIGVpdGhlcg0KPj4+Pj4+IGNlbnRyYWxpemVkIHBvaW50IChlLmcu LCBQQ0UsIGNvbnRyb2xsZXIpLCBvciwgdmlhIGEgZGlzdHJpYnV0ZWQgDQo+Pj4+Pj4gY29udHJv bCBwbGFuZT8gRm9yIHBhcnRpYWwgU0ZQLCB3aWxsIHRoZXJlIGJlIGEgcmUtY2xhc3NpZmljYXRp b24gDQo+Pj4+Pj4gdG8gZGVjaWRlIG5leHQgU0ZGKHMpIG9yIG5vdD8NCj4+Pj4+IA0KPj4+Pj4g SWYgeW91IHdhbnQgdGhlIFNGRiB0byBsb2NhbGx5IGRldGVybWluZSB0aGUgYXBwcm9wcmlhdGUg U0ZGIGZvciANCj4+Pj4+IHRoZSBuZXh0IFNGLCB0aGUgU0ZGIHNob3VsZCBoYXZlIHRoZSBjYXBh YmlsaXR5IG9mIHJlc29sdmluZyB0aGUgDQo+Pj4+PiBTRkYgZm9yDQo+PiB0aGUNCj4+Pj4+IG5l eHQgU0YgYmFzZWQgb24gY2VydGFpbiBjb25zdHJhaW50cy4gT2YgY291cnNlLCBpdCBuZWVkcyB0 byBrbm93IA0KPj4+Pj4gc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgU0ZzIGluIGFkdmFuY2Us IGUuZy4sIHRoZSBpbmZvcm1hdGlvbiANCj4+Pj4+IGFib3V0IHdoaWNoIFNGRnMgYSBnaXZlbiBT RiBpcyBhdHRhY2hlZC4NCj4+Pj4+IA0KPj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+Pj4gWGlhb2h1 DQo+Pj4+PiANCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+IFBlbmcNCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUN Cj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDE1LCAyMDE0IDQ6NDkgQU0NCj4+Pj4+PiBUbzog bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9lbCBNLiBIYWxwZXJuOyBUb20gVGF5bG9y OyANCj4+Pj4+PiBzZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXINCj4+Pj4+PiBTdWJqZWN0OiBSZTog W3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+Pj4+PiANCj4+Pj4+PiBIaSBNZWQs DQo+Pj4+Pj4gDQo+Pj4+Pj4gSU1ITywgdGhlIGFyY2hpdGVjdHVyZSBzaG91bGQgYWxsb3cgdGhl IGNsYXNzaWZpZXIgdG8gc3BlY2lmeQ0KPj4+Pj4+IA0KPj4+Pj4+IDEpIGEgcGFydGlhbCBTRlAg KGkuZS4sIHNvbWUgU0ZGcyBhbG9uZyB0aGF0IHBhcnRpYWwgU0ZQIG5lZWQgdG8gDQo+Pj4+Pj4g bG9jYWxseSBkZXRlcm1pbmUgdGhlIGFwcHJvcHJpYXRlIFNGRiBmb3IgdGhlIG5leHQgU0YpOw0K Pj4+Pj4+IDIpIGEgY29tcGxldGUgU0ZQIChpLmUuLCB0aGUgU0ZGIGZvciBlYWNoIFNGIGluIHRo ZSBTRkMgaGFzIGJlZW4gDQo+Pj4+Pj4gZGV0ZXJtaW5lZCBieSB0aGUgY2VudHJhbGl6ZWQgbm9k ZSk7DQo+Pj4+Pj4gMykgYW4gU0ZDIChpLmUuLCBlYWNoIFNGRiBhbG9uZyB0aGUgZmluYWwgU0ZQ IG5lZWRzIHRvIGxvY2FsbHkgDQo+Pj4+Pj4gZGV0ZXJtaW5lIHRoZSBhcHByb3ByaWF0ZSBTRkYg Zm9yIHRoZSBuZXh0IFNGKS4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBmYWN0LCBjYXNlIDMpIGNvdWxk IGJlIGxvb2tlZCBhcyBhbiBleHRyZW1lIG9mIGNhc2UgMSkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQmVz dCByZWdhcmRzLA0KPj4+Pj4+IFhpYW9odQ0KPj4+Pj4+IA0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIA0KPj4+Pj4+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMTQgMzoyMiBQTQ0KPj4+Pj4+PiBU bzogSm9lbCBNLiBIYWxwZXJuOyBUb20gVGF5bG9yOyBzZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXIN Cj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIFNGQyBUZXJtaW5vbG9neSAvIENvbmNlcHRzDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBIaSBKb2VsLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gQXMgbWVudGlvbmVk IGluIHNldmVyYWwgbWVzc2FnZXMsIEknbSBwZXJzb25hbGx5IGZvciB0aGUgdXNlIG9mIA0KPj4+ Pj4+PiB0aGUgY2hhaW4gaXRzZWxmIGlzIHRoZSBtYWluIGluZm9ybWF0aW9uIHRvIGJlIGNvbnZl eWVkIGluIA0KPj4+Pj4+PiBwYWNrZXRzIHRvIGRyaXZlDQo+Pj4+Pj4gZm9yd2FyZGluZyBhY3Rp b25zLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSSBjYW4gdW5kZXJzdGFuZCB0aGF0IGFuIGlkZW50aWZp ZXIgY2FuIGJlIGFzc2lnbmVkIHRvIGEgcGF0aCANCj4+Pj4+Pj4gdGhhdCBpcyBrbm93biBpbiBh ZHZhbmNlLCBidXQgaWYgdGhhdCBwYXRoIGlzIG5vdCBrbm93biBJJ20gbm90IA0KPj4+Pj4+PiBz dXJlIGhvdyBhbiBpZGVudGlmaWVyIGNhbiBiZSBhc3NpZ25lZCB0byBpdCENCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IEpvZWwsIHRoZSB1c2Ugb2YgInBhdGgiIGlzIHJlYWxseSBpbmFwcHJvcHJpYXRlIHRv IHJlZmVyIHRvIA0KPj4+Pj4+PiBkaXN0cmlidXRlZCBpbnN0YW5jZSBzZWxlY3Rpb24gcHJvY2Vz cyBmb3IgcGFja2V0cyBib3VuZCB0byBhIA0KPj4+Pj4+PiBnaXZlbiBTRkMuDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+IE1lZA0KPj4+Pj4+PiANCj4+Pj4+Pj4+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+Pj4+Pj4gRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb2VsIE0uIA0KPj4+Pj4+Pj4gSGFscGVybiBFbnZv ecOpIDogbHVuZGkgMTQganVpbGxldCAyMDE0IDIxOjUyIMOAIDogVG9tIFRheWxvcjsgDQo+Pj4+ Pj4+PiBzZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXIgT2JqZXQgOiBSZTogW3NmY10gU0ZDIFRlcm1p bm9sb2d5IC8gDQo+Pj4+Pj4+PiBDb25jZXB0cw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgbW9z dCBsaWtlbHkgcmVhbGl6YXRpb24gb2YgdGhlIGFyY2hpdGVjdHVyZSB3b3VsZCBiZSB0aGF0IA0K Pj4+Pj4+Pj4gdGhlDQo+PiBTRlANCj4+Pj4+Pj4+IGFzc2lnbm1lbnQgaXMgcmVjb3JkZWQgaW4g YW4gaWRlbnRpZmllciB3aGljaCB0cmF2ZWxzIHdpdGggdGhlIA0KPj4+Pj4+Pj4gcGFja2V0Lg0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBTb21lIGZvbGtzIHNlZW0gdG8gbm90IHdhbnQgdGhlIGFyY2hp dGVjdHVyZSB0byBtYW5kYXRlIHRoYXQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFlvdXJzLA0KPj4+ Pj4+Pj4gSm9lbA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBPbiA3LzE0LzE0LCAy OjM3IFBNLCBUb20gVGF5bG9yIHdyb3RlOg0KPj4+Pj4+Pj4+IFlvdXIgdGV4dCBzY2FyZXMgbWUg YmVjYXVzZSBpdCBpbnRyb2R1Y2VzIHNvbWUgbmV3IGNvbmNlcHRzIGFuZCANCj4+Pj4+Pj4+PiBh c3N1bXB0aW9ucy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJJ2QgcmF0aGVyIGdvIHdpdGggSm9l bCdzIGZvcm11bGF0aW9uLiBDbGFyaWZ5aW5nIHF1ZXN0aW9uIG9uIHRoYXQ6DQo+Pj4+Pj4+Pj4g YW0gSSByaWdodCBpbiBzZWVpbmcgdGhlIGltcGxpY2F0aW9uIHRoYXQgd2hlbiBjb250cm9sIGFz c2lnbnMgDQo+Pj4+Pj4+Pj4gYW4gU0ZQLCB0aGUgYXNzaWdubWVudCBpcyByZWNvcmRlZCBieSBh biBpZGVudGlmaWVyIHd3aGljaCANCj4+Pj4+Pj4+PiB0cmF2ZWxzIHdpdGggdGhlDQo+Pj4+Pj4+ IHBhY2tldD8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUb20gVGF5bG9yDQo+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IE9uIDE0LzA3LzIwMTQgMjoyMiBQTSwgUm9uIFBhcmtlciB3cm90ZToNCj4+Pj4+ Pj4+Pj4gVGhlcmUgaXMgb25lIG1pc3Npbmcgd29yZCBpbiBteSB0ZXh0LiAgIFBsZWFzZSByZXBs YWNlIG15IHByb3Bvc2VkDQo+Pj4+Pj4+Pj4+IHRleHQNCj4+Pj4+Pj4+Pj4gd2l0aDoNCj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ICJUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKSBwcm92 aWRlcyBhIGZ1bGx5IGFic3RyYWN0IA0KPj4+Pj4+Pj4+PiB2aWV3IG9mIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9ucyB0byBiZSBpbnZva2VkIGFuZCB0aGUgb3JkZXIgaW4gDQo+Pj4+Pj4+Pj4+IHdoaWNo IHRoZXkgYXJlIHRvIGJlIGludm9rZWQgZm9yIHNvbWUgcGFydGljdWxhciBmbG93IG9yIHNldCAN Cj4+Pj4+Pj4+Pj4gb2YgZmxvd3MsDQo+PiB3aXRob3V0DQo+Pj4+Pj4gY29uY2VybiBvZg0KPj4+ Pj4+Pj4+PiBhY3R1YWwgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSBzZWxlY3Rpb24uICAgVGhl IENvbnN0cmFpbmVkLVNGQw0KPj4+Pj4+Pj4+PiAoQy1TRkMpIGZ1cnRoZXIgYWxsb3dzIGZvciBw b2xpY3kgY29uc3RyYWludHMgdG8gYmUgYWRkZWQgdG8gDQo+Pj4+Pj4+Pj4+IHRoZSBTRkMgYWZm ZWN0aW5nIHRoZSBpbnN0YW5jZSBzZWxlY3Rpb24gb2Ygb25lIG9yIG1vcmUgb2YgdGhlIA0KPj4+ Pj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4gZnVuY3Rpb25zDQo+Pj4+Pj4+Pj4+IGluIHRoZSBTRkMu ICAgQW55IFNGQyBtYXkgaGF2ZSBhbnkgbnVtYmVyIG9mIEMtU0ZDJ3MgYXNzb2NpYXRlZA0KPj4+ Pj4+Pj4+PiB3aXRoDQo+Pj4+Pj4+PiBpdC4iDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGFu a3MuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAgICAgUm9uDQo+Pj4+Pj4+Pj4gLi4uDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqRGF2aWQgDQo+Pj4+Pj4+Pj4+IEFsbGFuIEkN Cj4+Pj4+Pj4+Pj4gKlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMTQgMjowMyBQTQ0KPj4+Pj4+ Pj4+PiAqVG86KiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3JnIA0KPj4+Pj4+ Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pj4+Pj4+Pj4gKlN1YmplY3Q6KiBSZTogW3Nm Y10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEkg bGlrZSB0aGF0IHRleHQsIGl0IHN0cmlrZXMgYSBnb29kIGJhbGFuY2Ugd2hlcmUgYW4gDQo+Pj4+ Pj4+Pj4+IGltcGxlbWVudGF0aW9uIGhhcyB0aGUgb3B0aW9uIG9mIG1ha2luZyBzY2FsZSBhbmQg cmVzaWxpZW5jeSBhIA0KPj4+Pj4+Pj4+PiBsb2NhbA0KPj4+Pj4+IG1hdHRlci4uDQo+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+PiBEDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAqRnJvbToqc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkppbSANCj4+Pj4+Pj4+ Pj4gR3VpY2hhcmQNCj4+Pj4+Pj4+Pj4gKGpndWljaGFyKQ0KPj4+Pj4+Pj4+PiAqU2VudDoqIE1v bmRheSwgSnVseSAxNCwgMjAxNCAxMDo0OCBBTQ0KPj4+Pj4+Pj4+PiAqVG86KiBzZmNAaWV0Zi5v cmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+Pj4+Pj4+ICpTdWJqZWN0OiogW3NmY10gU0ZD IFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IERlYXIgV0c6 DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGVyZSBoYXMgYmVlbiBtdWNoIGRlYmF0ZSBvdmVy IHRoZSBsYXN0IGZldyBkYXlzIHdpdGggcmVnYXJkcyANCj4+Pj4+Pj4+Pj4gdG8gU0ZDIGNvbmNl cHRzLiBUbyB0cnkgYW5kIGZvcm0gc29tZSBjb25zZW5zdXMgYXJvdW5kIA0KPj4+Pj4+Pj4+PiB0 ZXJtaW5vbG9neSBhbmQgY29uY2VwdHMgdXNlZCB0byBkZXNjcmliZSB0aGUgYXJjaGl0ZWN0dXJl IGluIA0KPj4+Pj4+Pj4+PiB0aGUgbWVyZ2VkIGFyY2hpdGVjdHVyZSBkcmFmdCwgSm9lbCBoYXMg a2luZGx5IHN1Z2dlc3RlZCB0aGUgZm9sbG93aW5nOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4g IlRoZSBTRlAgcHJvdmlkZXMgYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBiZXR3ZWVuIHRoZSBmdWxs eSANCj4+Pj4+Pj4+Pj4gYWJzdHJhY3Qgbm90aW9uIG9mIHNlcnZpY2UgcGF0aCBhcyBhIHNlcXVl bmNlIG9mIGZ1bmN0aW9ucyB0byANCj4+Pj4+Pj4+Pj4gYmUgZGVsaXZlcmVkLCBhbmQgdGhlIGZ1 bGx5IHNwZWNpZmllZCBub3Rpb24gb2YgZXhhY3RseSB3aGF0IA0KPj4+Pj4+Pj4+PiBpbnN0YW5j ZXMgb2YgU0ZGcyB0aGUgcGFja2V0IHdpbGwgdmlzaXQgd2hlbiBpdCBhY3R1YWxseSANCj4+Pj4+ Pj4+Pj4gdHJhdmVyc2VzIHRoZSBuZXR3b3JrLiBCeSBhbGxvd2luZyB0aGUgY29udHJvbCBjb21w b25lbnRzIHRvIA0KPj4+Pj4+Pj4+PiBzcGVjaWZ5IHRoZSB1c2Ugb2YgdGhpcyBsZXZlbCBvZiBp bmRpcmVjdGlvbiwgdGhlIGRlcGxveW1lbnQgDQo+Pj4+Pj4+Pj4+IG1heSBjaG9vc2UgdGhlIGRl Z3JlZSBvZiBTRkYgaW5zdGFuY2Ugc2VsZWN0aW9uIGF1dGhvcml0eSB0aGF0IA0KPj4+Pj4+Pj4+ PiBpcyBkZWxlZ2F0ZWQgdG8gdGhlIG5ldHdvcmsuIg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4g SSdkIGxpa2UgdG8gYXNrIHRoZSBXRyBhcyBhIHdob2xlLCBpZiB0aGlzIGNsYXJpZmljYXRpb24g aXMgDQo+Pj4+Pj4+Pj4+IHNvbWV0aGluZyB0aGF0IHdlIGNhbiBnZXQgY29uc2Vuc3VzIG9uLiBJ ZiBzbywgSSdsbCBhc2sgSm9lbCANCj4+Pj4+Pj4+Pj4gdG8gcHJvdmlkZSBzcGVjaWZpYyB0ZXh0 LCB0aGF0IHJlZmxlY3RzIHRoZSBhYm92ZSwgZm9yIA0KPj4+Pj4+Pj4+PiBpbmNsdXNpb24gaW4g dGhlIG1lcmdlZCBhcmNoaXRlY3R1cmUgZHJhZnQuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBU aGFuayBZb3UsDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBKaW0NCj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ Pj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IHNmYyBtYWlsaW5nIGxp c3QNCj4+Pj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gc2ZjIG1haWxpbmcg bGlzdA0KPj4+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+ PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3Jn DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+IA0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g c2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMg bWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Sun Jul 20 11:32: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 1BFA91B28FD for ; Sun, 20 Jul 2014 11:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 CsY_SywQxIcx for ; Sun, 20 Jul 2014 11:32:47 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83061B2820 for ; Sun, 20 Jul 2014 11:32:46 -0700 (PDT) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 20 Jul 2014 12:32:45 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 20 Jul 2014 12:32:44 -0600 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 64C8A19D8026 for ; Sun, 20 Jul 2014 12:32:33 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08026.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6KIVUIK10748300 for ; Sun, 20 Jul 2014 20:31:30 +0200 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6KIWh79028088 for ; Sun, 20 Jul 2014 12:32:43 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.81.69]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s6KIWgFf028049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 20 Jul 2014 12:32:43 -0600 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s6KIWf31012624 for ; Sun, 20 Jul 2014 14:32:41 -0400 Date: Sun, 20 Jul 2014 14:32:41 -0400 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: 14072018-0928-0000-0000-00000381C848 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CZ_cYssuAhlD_Adpeha85fEb4fo Subject: [sfc] On architecture constraining solutions (or not) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 18:32:48 -0000 At Fri, 18 Jul 2014 20:38:12 +0000, Lucy yong wrote: > > I suspect that there are two separate but related issues. > > > > The architecture we proposed, and probably any useful archtiecture, > > does constrain solutions. In adopting an archtiecture, the working > > group makes some choices. > [Lucy] not so sure. We should adopt an architecture without making > solution choices ahead. The architecture leads solution development, > not the other way. > At the same time, those constraints should general, not specific, and > certainly not aimed at the NSH solution in particular. > [Lucy] Yes and Agree. I want to call out this point, because it is important. IMO, the architecture absolutely can and should make choices that constrain solutions. An architecture that doesn't constrain solutions, seems to me to not be an architecture at all -- it suggests anything is allowed and nothing is disallowed. (I'm exaggerating a bit to make the point.) That said, the architecuture shouldn't exclude or prevent things that that the WG deems important to support. But it is neither the job of the WG (nor helpful) to try to support any/all hypothetical possibilities. We are supposed to be solving real problems with real requirements with a goal of developing real solutions. The architecture needs to support that. But no more. An important point of an architecture it to outline at a high level what will be supported and what won't be supported -- and to make choices at a high level about solution directions. By definition, that means solutions will be constrained. So yes, making architectural decisions that constrain solutions is OK. Of course, the WG should be aware it is making such choices and should be in agreement with making any such constraints. Thomas From nobody Sun Jul 20 16:46: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 7AA021B2A4E for ; Sun, 20 Jul 2014 16:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rI9ZogeVXdrI for ; Sun, 20 Jul 2014 16:46:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360021B297C for ; Sun, 20 Jul 2014 16:46:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKH70976; Sun, 20 Jul 2014 23:46:23 +0000 (GMT) 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; Mon, 21 Jul 2014 00:46:22 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Sun, 20 Jul 2014 16:46:08 -0700 From: Linda Dunbar To: Ron Parker Thread-Topic: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly Thread-Index: AQHPo7PONTAbQXo9v0momypO37O93puopWCAgAD6qKA= Date: Sun, 20 Jul 2014 23:46:08 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA072D@dfweml701-chm.china.huawei.com> References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F645DA011A@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.150.233] 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/Xxf5hLPT4D8xtky1-r0HGomXmHU Cc: Henry Fourie , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 23:46:30 -0000 Um9uLCANCg0KQW5zd2VyIGluc2VydGVkIGJlbG93Og0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb21dIA0KDQpMaW5kYSwNCg0KSSdtIG5vdCBkZWJhdGluZyB0aGF0IGZyYWdtZW50YXRpb24g c2hvdWxkIGJlIG1pbmltaXplZC4gICBCdXQsIHdydCBsZWdhY3kgU0YncyAtLSBpZiB0aGUgdHJh bnNwb3J0ICsgc2VydmljZSBlbmNhcHMgaW5jcmVhc2VzIHRoZSBwYWNrZXQgZW5vdWdoIHRvIGNh dXNlIGZyYWdtZW50YXRpb24sIHdvdWxkbid0IGl0IGJlIGF0IHRoZSB0cmFuc3BvcnQgbGV2ZWwg YW5kIG5vdCBhdCB0aGUgbGV2ZWwgb2YgdGhlIG9yaWdpbmFsIHBhY2tldD8gIA0KDQpbTGluZGFd IFdlIGFyZSBpbiBhZ3JlZW1lbnQgdGhhdCB0aGUgZnJhZ21lbnRhdGlvbiBhdCB0cmFuc3BvcnQg bGV2ZWwgcmVxdWlyZXMgdGhlIFNGRiBub2RlcyB0byByZWFzc2VtYmxlIGZyYWdtZW50ZWQgcGFj a2V0cyBiZWZvcmUgcGFzc2luZyB0byBTRiBub2Rlcy4gDQoNCg0KIFtHaXZlbiB0aGF0IGl0IGNh biBvbmx5IGJlIHNvIGZvciBmcmFnbWVudGFibGUgdHJhbnNwb3J0cyAoaWUgaXB2NCwgaXB2Nild LiANCg0KW0xpbmRhXSBSb3V0ZXJzIGRvIG5vdCBmcmFnbWVudCBJUHY2IHBhY2tldHMsIGFzIHRo ZXkgZG8gZm9yIElQdjQuIFNvIFNGQyBoZWFkZXIgZm9yIElQdjYgaGFzIHRvIGJlIG1vcmUgY29t cGFjdC4gDQoNCg0KDQoNCiAgIFJvbg0KDQoNCj4gT24gSnVsIDE5LCAyMDE0LCBhdCA4OjQ1IFBN LCAiTGluZGEgRHVuYmFyIiA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4g VGhlIE1UVSBzZWN0aW9uIG9mIHRoZSBtZXJnZWQtc2ZjLWFyY2ggaXMgb25lIGV4YW1wbGUgc2hv d2luZyB3aGF0IE1lZCBzYWlkIGFib3V0IHRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSAiaW5jbHVk aW5nIHNvbWUgc29sdXRpb24gaGludHMgdGhhdCBjb21lIG1haW5seSBmcm9tIG5zaCIuDQo+IA0K PiANCj4gQW4gaW1wb3J0YW50IHBhcnQgb2YgU0ZDIGlzIHRoZSBTRkMgaGVhZGVyIGVuY2Fwc3Vs YXRpb24uIA0KPiBUaGVyZWZvcmUsIHRoZSBNVFUgc2VjdGlvbiBzaG91bGQgZW1waGFzaXplIHRo ZSBpbXBvcnRhbmNlIG9mIGF2b2lkaW5nIHBhY2tldHMgZnJhZ21lbnRhdGlvbiBhbmQgcmVhc3Nl bWJseSBiZWNhdXNlIG1vc3Qgc2VydmljZSBmdW5jdGlvbnMsIGVzcGVjaWFsbHkgbGVnYWN5IEw0 LUw3IHNlcnZpY2UgZnVuY3Rpb25zLCBkb24ndCBleHBlY3QgZnJhZ21lbnRlZCBwYWNrZXRzLiBJ dCBpcyB2ZXJ5IGV4cGVuc2l2ZSBmb3IgaW50ZXJtZWRpYXRlIFNGRi9TTiBub2RlcyB0byByZWFz c2VtYmxlIHBhY2tldHMgYmVmb3JlIHBhc3NpbmcgcGFja2V0cyB0byBTZXJ2aWNlIEZ1bmN0aW9u cy4gRS5nLiBUaGUgU0ZDIGhlYWRlciBzaG91bGQgYXZvaWQgbGl0ZXJhbGx5IGxpc3RpbmcgdGhl IGFkZHJlc3NlcyAoZXNwZWNpYWxseSBJUHY2IGFkZHJlc3Nlcykgb2YgdGhlIHNlcnZpY2UgZnVu Y3Rpb25zIGluIGEgc2VydmljZSBmdW5jdGlvbiBjaGFpbi4NCj4gDQo+IEJ1dCBmaW5hbCBNVFUg U2VjdGlvbiBlbXBoYXNpemVzIHRoYXQgdGhlIG1vZGVybiBzeXN0ZW1zIGNhbiBoYW5kbGUgcGFj a2V0cyBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5LCBtZWFuaW5nIE5TSCBoZWFkZXIgKG5v IG1hdHRlciBob3cgbG9uZykgaXMgbm8gcHJvYmxlbS4NCj4gDQo+IA0KPiBJIGhhZCBhIHR3byBz ZXBhcmF0ZSBjb25mZXJlbmNlIGNhbGxzICB3aXRoIHRoZSBhdXRob3JzIG9mIHRoZSBTRkMtYXJj aGl0ZWN0dXJlIGRyYWZ0IGFkZHJlc3Npbmcgc3VnZ2VzdGVkIG1lcmdpbmcgb2Ygc29tZSBjb250 ZW50IGZyb20gImxlZ2FjeS1sNC1sNy1hcmNoIiB0byBnZW5lcmFsICJzZmMtYXJjaCIgKGVhY2gg bGFzdGVkIG1vcmUgdGhhbiAxIGhvdXIpLiANCj4gDQo+IE9uZSBvZiB0aGUgaXNzdWVzIGJlaW5n IGRpc2N1c3NlZCBpcyB0aGUgTVRVIHNlY3Rpb24uIEhlcmUgaXMgdGV4dCB0aGF0IEkgc3VnZ2Vz dGVkIHRvIG1lcmdlIHdpdGggdGhlIGdlbmVyYWwgInNmYy1hcmNoIjoNCj4gDQo+ICJFbmNhcHN1 bGF0aW5nIFNGQyBoZWFkZXIgdG8gZGF0YSBwYWNrZXRzIGhhcyB0byB0YWtlIE1UVSBzaXplIGlu dG8gY29uc2lkZXJhdGlvbiBiZWNhdXNlIG1vc3Qgc2VydmljZSBmdW5jdGlvbnMsIGVzcGVjaWFs bHkgbGVnYWN5IEw0LUw3IHNlcnZpY2UgZnVuY3Rpb25zLCBkb24ndCBleHBlY3QgZnJhZ21lbnRl ZCBwYWNrZXRzLiANCj4gSXQgaXMgdmVyeSBleHBlbnNpdmUgZm9yIGludGVybWVkaWF0ZSBTRkYv U04gbm9kZXMgdG8gcmVhc3NlbWJsZSBwYWNrZXRzIGJlZm9yZSBwYXNzaW5nIHBhY2tldHMgdG8g U2VydmljZSBGdW5jdGlvbnMuIA0KPiBUaGVyZWZvcmUsIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVk IGJ5IHRoZSBTRkMgaGVhZGVyIGhhcyB0byBiZSBjb21wYWN0LiBUaGUgU0ZDIGhlYWRlciBzaG91 bGQgYXZvaWQgbGl0ZXJhbGx5IGxpc3RpbmcgdGhlIGFkZHJlc3NlcyAoZXNwZWNpYWxseSBJUHY2 IGFkZHJlc3Nlcykgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGluIGEgc2VydmljZSBmdW5jdGlv biBjaGFpbi4iDQo+IA0KPiBJIHNpbmNlcmVseSBob3BlIHRoYXQgdGhlIGF1dGhvcnMgY2FuIHRh a2UgdGhpcyB0ZXh0IChvciB2YXJpYXRpb24gb2YgdGhpcyB0ZXh0KSBmb3IgdGhlIE1UVSBzZWN0 aW9uIG9mIHNmYy1hcmNoLiANCj4gDQo+IExpbmRhDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIA0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDE3LCAyMDE0IDEyOjU3IEFNDQo+IFRvOiBKb2VsIE0uIEhhbHBlcm47IEhlbnJ5IEZv dXJpZTsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kg LyBDb25jZXB0cw0KPiANCj4gSGkgSm9lbCwNCj4gDQo+IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3Ug YWJvdXQgdGhlIGdvYWwuIA0KPiANCj4gTmV2ZXJ0aGVsZXNzLCB0aGUgbWVyZ2VkIGRvY3VtZW50 LCBhcyBpdCBjdXJyZW50bHkgc3RhbmRzLCBpbmNsdWRlcyBzb21lIHNvbHV0aW9uIGhpbnRzIHRo YXQgY29tZSBtYWlubHkgZnJvbSBuc2guIEkgd291bGQgcmVhbGx5IGhvcGUgdGhlIGRvY3VtZW50 IGJlIHVwZGF0ZWQgdG8gYmUgbmV1dHJhbC4gDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4gDQo+PiBFbnZvecOp IDogbWVyY3JlZGkgMTYganVpbGxldCAyMDE0IDIzOjQ3IMOAIDogSGVucnkgRm91cmllOyANCj4+ IHNmY0BpZXRmLm9yZyBPYmpldCA6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0 cw0KPj4gDQo+PiBJIHdvdWxkIGhvcGUgdGhhdCB3ZSBjYW4gZW5kIHVwIHdpdGggYW4gYXJjaHRp ZWN0dXJlIGRvY3VtZW50IHRoYXQgaXMgDQo+PiB1bmRlcnN0YW5kYWJsZSBhbmQgdXNlZnVsIHdp dGhvdXQgcmVzb3J0aW5nIHRvIGEgc3BlY2lmaWMgc29sdXRpb24gDQo+PiBkb2N1bWVudC4gIFRo YXQgaXMgb3VyIGdvYWwuICBUaGVyZSBwcm9iYWJseSBhcmUgcmVmaW5lbWVudHMgbmVlZGVkIA0K Pj4gdG8gYWNoaWV2ZSB0aGF0IGdvYWwuDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+ Pj4gT24gNy8xNi8xNCwgNTozOSBQTSwgSGVucnkgRm91cmllIHdyb3RlOg0KPj4+IEtlbiwNCj4+ PiAgIFRoZSBTZXJ2aWNlIGNoYWluIEhlYWRlciBkcmFmdA0KPj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LQ0KPj4gemhhbmctc2ZjLXNjaC8NCj4+PiBzaG91bGQgYW5z d2VyIHNvbWUgb2YgeW91ciBxdWVzdGlvbnMuIEluIHBhcnRpY3VsYXI6DQo+Pj4gDQo+Pj4gSW4g c2VjdGlvbiA0LjIgTWFuZGF0b3J5IEZpZWxkczoNCj4+PiANCj4+PiAgICBQYXRoIElkZW50aWZp ZXI6IElkZW50aWZpZXMgYSBmdWxseSBpbnN0YW50aWF0ZWQgc2VydmljZSBmdW5jdGlvbg0KPj4+ ICAgICAgIHBhdGguIEl0IHJlcHJlc2VudHMgYSBzZXF1ZW5jZSBvZiBuZXR3b3JrIGxvY2F0b3Jz LCBvbmUgZm9yIGVhY2gNCj4+PiAgICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgaXMgdG8gYmUg aW52b2tlZC4gUGFydGljaXBhdGluZyBTRkMgZW50aXRpZXMNCj4+PiAgICAgICBNVVNUIHVzZSB0 aGlzIGlkZW50aWZpZXIgd2hlbiBzZWxlY3RpbmcgdGhlIG5leHQgaG9wIGZvciB0aGUNCj4+PiAg ICAgICBwYWNrZXQgb3IgZnJhbWUuDQo+Pj4gDQo+Pj4gSW4gc2VjdGlvbiA0LjQgSGVhZGVyIEFz c29jaWF0ZWQgT3BlcmF0aW9uczoNCj4+PiANCj4+PiAgICAzLiBTZXJ2aWNlIFBhdGggU2VsZWN0 aW9uLiBUaGUgU2VydmljZSBOZXR3b3JrIEZvcndhcmRlciAoU05GKSB1c2VzDQo+Pj4gICAgICAg dGhlIFNlcnZpY2UgQ2hhaW4gSWRlbnRpZmljYXRpb24gaW5mb3JtYXRpb24gaW4gdGhlIFNDSCB0 byBzdGVlcg0KPj4+ICAgICAgIHRoZSB0cmFmZmljIGZsb3cgYWxvbmcgdGhlIFNGQyBwYXRoLg0K Pj4+IA0KPj4+ICAgIDQuIFNlcnZpY2UgRnVuY3Rpb24gSW5zdGFuY2UgU2VsZWN0aW9uLiBUaGUg U2VydmljZSBGdW5jdGlvbg0KPj4+ICAgICAgIEZvcndhcmRlciAoU0ZGKSB1c2VzIHRoZSBTZXJ2 aWNlIENoYWluIElkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uDQo+Pj4gICAgICAgaW4gdGhlIFND SCB0byBsb2NhdGUgdGhlIHNlcnZpY2UgaW5zdGFuY2UgYW5kIGZvcndhcmQgdGhlIHRyYWZmaWMN Cj4+PiAgICAgICBmbG93IHRvIHRoZSBzZXJ2aWNlIGluc3RhbmNlLiBUaGUgbWFwcGluZyBvZiB0 aGUgU2VydmljZSBDaGFpbg0KPj4+ICAgICAgIElkZW50aWZpY2F0aW9uIHRvIGEgc2VydmljZSBp bnN0YW5jZSBjYW4gYmUgZXN0YWJsaXNoZWQgdGhyb3VnaA0KPj4+ICAgICAgIHRoZSBtYW5hZ2Vt ZW50L2NvbnRyb2wgcGxhbmUsIHdoaWNoIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzDQo+Pj4gICAg ICAgZG9jdW1lbnQuDQo+Pj4gDQo+Pj4gIC0gTG91aXMNCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2VuIEdyYXkNCj4+PiAoa2VncmF5KQ0KPj4+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAxNiwgMjAxNCAxMTo1OSBBTQ0KPj4+IFRvOiBUaG9tYXMgRC4gTmFkZWF1OyBzZmMt Y2hhaXJzQGlldGYub3JnDQo+Pj4gQ2M6IHNmY0BpZXRmLm9yZzsgSGUsIFBlbmc7IFJvbiBQYXJr ZXI7IFRvbSBUYXlsb3I7IEpvZWwgTS4gSGFscGVybjsNCj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4+PiBTdWJqZWN0OiBSZTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2Vw dHMNCj4+PiANCj4+PiBKb2VsLCBldC4gYWxsLA0KPj4+IA0KPj4+IEkgdGhpbmsgdGhhdCBzb21l IG9mIHRoZSBxdWVzdGlvbnMgaW4gYXJjaGl0ZWN0dXJlIChTRlAvU0ZDIGNoYXNpbmcgDQo+Pj4g aXQncw0KPj4+IHRhaWwpIGNvbWUgYXMgcGVvcGxlIGxvb2sgZm9yd2FyZCB0byB0aGUgZW5jYXBz dWxhdGlvbi9oZWFkZXIgZG9jdW1lbnQuDQo+Pj4gVGhhdCdzIHByb2JhYmx5IHVuYXZvaWRhYmxl Lg0KPj4+IA0KPj4+IFdoZW4geW91IHJlYWQgdGhlIE5TSCBkb2N1bWVudCwgdGhlIFNGUCB2ZXJi aWFnZSBzYXlzIHRoYXQgYWxsIA0KPj4+IHBhcnRpY2lwYW50cyBNVVNUIGZvcndhcmQgb24gdGhl IFNQL1NQSSwgYnV0IHRoZSBkb2N1bWVudCBkb2Vzbid0IA0KPj4+IHNheSBob3cgdGhlIFNQSSBp cyBkZXJpdmVkL2NhbGN1bGF0ZWQgKHRoZSB2aXNpb24gaGVyZSBjb3VsZCBiZSBtYWRlDQo+Pj4g Y2xlYXJlcikgb3Igd2hhdCBpdCdzIHJlbGF0aW9uc2hpcCBpcyB0byB0aGUgdHJhbnNwb3J0IHBh dGggKEkgdGhpbmsgDQo+Pj4geW91IGNhbid0IG1peA0KPj4gYW5kDQo+Pj4gbWF0Y2ggYnV0IGNh biBhY2NvbW1vZGF0ZSBib3RoIHdpdGhpbiB0aGUgaGVhZGVyKSwgc2hvdWxkIHlvdSBvcHQgDQo+ Pj4gZm9yIHRoZSB0cmFuc3BvcnQgaGVhZGVyIGZvcndhcmRpbmcuDQo+Pj4gDQo+Pj4gSXQncyBv YnZpb3VzIHRoYXQgc29tZSBkZXBsb3ltZW50cyBwcmVmZXIgdG8gdXNlIHRoZSB0cmFuc3BvcnQg DQo+Pj4gaGVhZGVyIGZvciBmb3J3YXJkaW5nIChTUiwgSUdQL2FueWNhc3QpIGFuZCBzb21lIHBy ZWZlciBhIGhvcC1ieS1ob3AgDQo+Pj4gbG9va3VwICh3aGljaCBkb2VzIHBsYXkgaW50byB0aGUg U1BJIG9yICJvdGhlciBtZWNoYW5pc21zIiB0aGF0IA0KPj4+IHBvcHVsYXRlIGEgc2VydmljZQ0K Pj4gdGFibGUNCj4+PiBpbiB0aGUgU0ZGKS4NCj4+PiANCj4+PiBQZXJoYXBzIHRoZSBhdXRob3Jz IG9mIE5TSCBjYW4gc3VnZ2VzdCB2ZXJiaWFnZSB0aGF0IG1ha2VzIHRoZSANCj4+PiByZWxhdGlv bnNoaXAgYmV0d2VlbiB0cmFuc3BvcnQtYmFzZWQgZm9yd2FyZGluZyBhbmQgc2VydmljZS1iYXNl ZCANCj4+PiBmb3J3YXJkaW5nIChTUEkpIGNsZWFyZXI/DQo+Pj4gDQo+Pj4gVGhpcyBzaG91bGQg ZWxpbWluYXRlL21pbmltaXplIHRoZSBjYWxscyBmb3IgcmVkZWZpbml0aW9uL3JlY2FzdGluZyAN Cj4+PiBvdXIgdGVybWlub2xvZ3kgYW5kIGFsbG93IHVzIHRvIG1vdmUgb24uDQo+Pj4gDQo+Pj4+ IE9uIDcvMTYvMTQgMToyMyBQTSwgIlRob21hcyBELiBOYWRlYXUiIDx0bmFkZWF1QGx1Y2lkdmlz aW9uLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiANCj4+Pj4gICAgSSBoYXZlIGdvdHRlbiBhIGJp dCBsb3N0IGluIHRoZSBTRkYvU0ZDIGRpc2N1c3Npb24sIHdoaWNoIHNlZW1zIA0KPj4+PiB0bw0K Pj4gaGF2ZQ0KPj4+PiBnb3R0ZW4gbmVlZGxlc3NseSBjb21wbGljYXRlZCBhbmQgY29udm9sdXRl ZCBJTUhPLg0KPj4+PiANCj4+Pj4gICAgSXMgaXQgcG9zc2libGUgZm9yIHRoZSBjaGFpcnMgdG8g YWRkIHRoaXMgdG8gdGhlIGxpc3Qgb2YgdGhpbmdzIA0KPj4+PiB0byBkaXNjdXNzIGF0IHRoZSBX RyBtZWV0aW5nIG9yIGRvIHdlIHdhbnQgdG8gcmVzb2x2ZSB0aGlzIG9uIHRoZSANCj4+Pj4gbGlz dA0KPj4gYWhlYWQNCj4+Pj4gb2YgdGhlIG1lZXRpbmc/DQo+Pj4+IA0KPj4+PiAgICAtLVRvbQ0K Pj4+PiANCj4+Pj4gDQo+Pj4+IE9uIEp1bCAxNSwgMjAxNDoxMDo1NyBQTSwgYXQgMTA6NTcgUE0s IFh1eGlhb2h1IA0KPj4+PiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+ IA0KPj4+Pj4gSGkgUGVuZywNCj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4gRnJvbTogSGUsIFBlbmcgW21haWx0bzpwaGVAY2llbmEuY29tXQ0KPj4+Pj4+ IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMTQgOTowOSBQTQ0KPj4+Pj4+IFRvOiBYdXhpYW9o dTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgSm9lbCBNLiBIYWxwZXJuOyBUb20gDQo+ Pj4+Pj4gVGF5bG9yOyBzZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXINCj4+Pj4+PiBTdWJqZWN0OiBS RTogW3NmY10gU0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+Pj4+PiANCj4+Pj4+PiBUcnkg dG8gdW5kZXJzdGFuZCB0aGUgdGhyZWUgc2NlbmFyaW9zIHlvdSBsaXN0ZWQ6IHlvdSBtZWFuIHRo ZSANCj4+Pj4+PiBjbGFzc2lmaWVyIGNhbiBzcGVjaWZ5IGEgKHBhcnRpYWwgb3IgY29tcGxldGUp IFNGUCB3aGljaCBpcyBhIA0KPj4+Pj4+IGxpc3Qgb2YgU0ZGcywgdGhlbiBlYWNoIFNGRiB3aWxs DQo+Pj4+Pj4gKGxvY2FsbHkpIHNlbGVjdCBvbmUgb2YgdGhlIFNGIGluc3RhbmNlcyB1bmRlciBp dHNlbGYgZm9yIHRoaXMgU0YuIA0KPj4+Pj4+IEZvciBwYXJ0aWFsIFNGUCBjYXNlLA0KPj4+Pj4g DQo+Pj4+PiBJbiBlaXRoZXIgY2FzZSwgdGhlIFNGRiBzaG91bGQgYmUgY2FwYWJsZSBvZiBzZWxl Y3RpbmcgdGhlIA0KPj4+Pj4gYXBwcm9wcmlhdGUgaW5zdGFuY2Ugb2YgYSBnaXZlbiBTRiBhdHRh Y2hlZCB0byBpdHNlbGYuIGl0J3MgYW4gDQo+Pj4+PiBpbnRlcm5hbCBsb2FkLWJhbGFuY2luZyBp c3N1ZS4NCj4+Pj4+IA0KPj4+Pj4+IGVhY2ggU0ZGIHdpbGwgaWRlbnRpZnkgdGhlIFNGSSB1bmRl ciBpdHNlbGYgYW5kIHNwZWNpZnkgKGxpa2UgYQ0KPj4+Pj4+IGNsYXNzaWZpZXIpIG5leHQgU0ZG KHMpLg0KPj4+Pj4+IFRoZSBjbGFzc2lmaWVyIChhbmQgU0ZGPykgY291bGQgb2J0YWluIHRoaXMg IChTRkYpICdwYXRoJyANCj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4+Pj4+IGZyb20gZWl0aGVyDQo+ Pj4+Pj4gY2VudHJhbGl6ZWQgcG9pbnQgKGUuZy4sIFBDRSwgY29udHJvbGxlciksIG9yLCB2aWEg YSBkaXN0cmlidXRlZCANCj4+Pj4+PiBjb250cm9sIHBsYW5lPyBGb3IgcGFydGlhbCBTRlAsIHdp bGwgdGhlcmUgYmUgYSByZS1jbGFzc2lmaWNhdGlvbiANCj4+Pj4+PiB0byBkZWNpZGUgbmV4dCBT RkYocykgb3Igbm90Pw0KPj4+Pj4gDQo+Pj4+PiBJZiB5b3Ugd2FudCB0aGUgU0ZGIHRvIGxvY2Fs bHkgZGV0ZXJtaW5lIHRoZSBhcHByb3ByaWF0ZSBTRkYgZm9yIA0KPj4+Pj4gdGhlIG5leHQgU0Ys IHRoZSBTRkYgc2hvdWxkIGhhdmUgdGhlIGNhcGFiaWxpdHkgb2YgcmVzb2x2aW5nIHRoZSANCj4+ Pj4+IFNGRiBmb3INCj4+IHRoZQ0KPj4+Pj4gbmV4dCBTRiBiYXNlZCBvbiBjZXJ0YWluIGNvbnN0 cmFpbnRzLiBPZiBjb3Vyc2UsIGl0IG5lZWRzIHRvIGtub3cgDQo+Pj4+PiBzb21lIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBTRnMgaW4gYWR2YW5jZSwgZS5nLiwgdGhlIGluZm9ybWF0aW9uIA0KPj4+ Pj4gYWJvdXQgd2hpY2ggU0ZGcyBhIGdpdmVuIFNGIGlzIGF0dGFjaGVkLg0KPj4+Pj4gDQo+Pj4+ PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+PiBYaWFvaHUNCj4+Pj4+IA0KPj4+Pj4+IFJlZ2FyZHMsDQo+ Pj4+Pj4gUGVuZw0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KPj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkg MTUsIDIwMTQgNDo0OSBBTQ0KPj4+Pj4+IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t OyBKb2VsIE0uIEhhbHBlcm47IFRvbSBUYXlsb3I7IA0KPj4+Pj4+IHNmY0BpZXRmLm9yZzsgUm9u IFBhcmtlcg0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25j ZXB0cw0KPj4+Pj4+IA0KPj4+Pj4+IEhpIE1lZCwNCj4+Pj4+PiANCj4+Pj4+PiBJTUhPLCB0aGUg YXJjaGl0ZWN0dXJlIHNob3VsZCBhbGxvdyB0aGUgY2xhc3NpZmllciB0byBzcGVjaWZ5DQo+Pj4+ Pj4gDQo+Pj4+Pj4gMSkgYSBwYXJ0aWFsIFNGUCAoaS5lLiwgc29tZSBTRkZzIGFsb25nIHRoYXQg cGFydGlhbCBTRlAgbmVlZCB0byANCj4+Pj4+PiBsb2NhbGx5IGRldGVybWluZSB0aGUgYXBwcm9w cmlhdGUgU0ZGIGZvciB0aGUgbmV4dCBTRik7DQo+Pj4+Pj4gMikgYSBjb21wbGV0ZSBTRlAgKGku ZS4sIHRoZSBTRkYgZm9yIGVhY2ggU0YgaW4gdGhlIFNGQyBoYXMgYmVlbiANCj4+Pj4+PiBkZXRl cm1pbmVkIGJ5IHRoZSBjZW50cmFsaXplZCBub2RlKTsNCj4+Pj4+PiAzKSBhbiBTRkMgKGkuZS4s IGVhY2ggU0ZGIGFsb25nIHRoZSBmaW5hbCBTRlAgbmVlZHMgdG8gbG9jYWxseSANCj4+Pj4+PiBk ZXRlcm1pbmUgdGhlIGFwcHJvcHJpYXRlIFNGRiBmb3IgdGhlIG5leHQgU0YpLg0KPj4+Pj4+IA0K Pj4+Pj4+IEluIGZhY3QsIGNhc2UgMykgY291bGQgYmUgbG9va2VkIGFzIGFuIGV4dHJlbWUgb2Yg Y2FzZSAxKS4NCj4+Pj4+PiANCj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4gWGlhb2h1DQo+ Pj4+Pj4gDQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+Pj4+Pj4+ IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+Pj4+Pj4gU2VudDogVHVlc2RheSwgSnVs eSAxNSwgMjAxNCAzOjIyIFBNDQo+Pj4+Pj4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IFRvbSBUYXls b3I7IHNmY0BpZXRmLm9yZzsgUm9uIFBhcmtlcg0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10g U0ZDIFRlcm1pbm9sb2d5IC8gQ29uY2VwdHMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhpIEpvZWwsDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBBcyBtZW50aW9uZWQgaW4gc2V2ZXJhbCBtZXNzYWdlcywgSSdtIHBl cnNvbmFsbHkgZm9yIHRoZSB1c2Ugb2YgDQo+Pj4+Pj4+IHRoZSBjaGFpbiBpdHNlbGYgaXMgdGhl IG1haW4gaW5mb3JtYXRpb24gdG8gYmUgY29udmV5ZWQgaW4gDQo+Pj4+Pj4+IHBhY2tldHMgdG8g ZHJpdmUNCj4+Pj4+PiBmb3J3YXJkaW5nIGFjdGlvbnMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJIGNh biB1bmRlcnN0YW5kIHRoYXQgYW4gaWRlbnRpZmllciBjYW4gYmUgYXNzaWduZWQgdG8gYSBwYXRo IA0KPj4+Pj4+PiB0aGF0IGlzIGtub3duIGluIGFkdmFuY2UsIGJ1dCBpZiB0aGF0IHBhdGggaXMg bm90IGtub3duIEknbSBub3QgDQo+Pj4+Pj4+IHN1cmUgaG93IGFuIGlkZW50aWZpZXIgY2FuIGJl IGFzc2lnbmVkIHRvIGl0IQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gSm9lbCwgdGhlIHVzZSBvZiAicGF0 aCIgaXMgcmVhbGx5IGluYXBwcm9wcmlhdGUgdG8gcmVmZXIgdG8gDQo+Pj4+Pj4+IGRpc3RyaWJ1 dGVkIGluc3RhbmNlIHNlbGVjdGlvbiBwcm9jZXNzIGZvciBwYWNrZXRzIGJvdW5kIHRvIGEgDQo+ Pj4+Pj4+IGdpdmVuIFNGQy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVk DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+Pj4+ PiBEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpv ZWwgTS4gDQo+Pj4+Pj4+PiBIYWxwZXJuIEVudm95w6kgOiBsdW5kaSAxNCBqdWlsbGV0IDIwMTQg MjE6NTIgw4AgOiBUb20gVGF5bG9yOyANCj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZzsgUm9uIFBhcmtl ciBPYmpldCA6IFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyANCj4+Pj4+Pj4+IENvbmNlcHRz DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoZSBtb3N0IGxpa2VseSByZWFsaXphdGlvbiBvZiB0aGUg YXJjaGl0ZWN0dXJlIHdvdWxkIGJlIHRoYXQgDQo+Pj4+Pj4+PiB0aGUNCj4+IFNGUA0KPj4+Pj4+ Pj4gYXNzaWdubWVudCBpcyByZWNvcmRlZCBpbiBhbiBpZGVudGlmaWVyIHdoaWNoIHRyYXZlbHMg d2l0aCB0aGUgDQo+Pj4+Pj4+PiBwYWNrZXQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFNvbWUgZm9s a3Mgc2VlbSB0byBub3Qgd2FudCB0aGUgYXJjaGl0ZWN0dXJlIHRvIG1hbmRhdGUgdGhhdC4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gWW91cnMsDQo+Pj4+Pj4+PiBKb2VsDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IE9uIDcvMTQvMTQsIDI6MzcgUE0sIFRvbSBUYXlsb3Igd3JvdGU6DQo+ Pj4+Pj4+Pj4gWW91ciB0ZXh0IHNjYXJlcyBtZSBiZWNhdXNlIGl0IGludHJvZHVjZXMgc29tZSBu ZXcgY29uY2VwdHMgDQo+Pj4+Pj4+Pj4gYW5kIGFzc3VtcHRpb25zLg0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IEknZCByYXRoZXIgZ28gd2l0aCBKb2VsJ3MgZm9ybXVsYXRpb24uIENsYXJpZnlpbmcg cXVlc3Rpb24gb24gdGhhdDoNCj4+Pj4+Pj4+PiBhbSBJIHJpZ2h0IGluIHNlZWluZyB0aGUgaW1w bGljYXRpb24gdGhhdCB3aGVuIGNvbnRyb2wgYXNzaWducyANCj4+Pj4+Pj4+PiBhbiBTRlAsIHRo ZSBhc3NpZ25tZW50IGlzIHJlY29yZGVkIGJ5IGFuIGlkZW50aWZpZXIgd3doaWNoIA0KPj4+Pj4+ Pj4+IHRyYXZlbHMgd2l0aCB0aGUNCj4+Pj4+Pj4gcGFja2V0Pw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+IFRvbSBUYXlsb3INCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gT24gMTQvMDcvMjAxNCAyOjIy IFBNLCBSb24gUGFya2VyIHdyb3RlOg0KPj4+Pj4+Pj4+PiBUaGVyZSBpcyBvbmUgbWlzc2luZyB3 b3JkIGluIG15IHRleHQuICAgUGxlYXNlIHJlcGxhY2UgbXkgcHJvcG9zZWQNCj4+Pj4+Pj4+Pj4g dGV4dA0KPj4+Pj4+Pj4+PiB3aXRoOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gIlRoZSBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpIHByb3ZpZGVzIGEgZnVsbHkgYWJzdHJhY3QgDQo+Pj4+ Pj4+Pj4+IHZpZXcgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHRvIGJlIGludm9rZWQgYW5kIHRo ZSBvcmRlciBpbiANCj4+Pj4+Pj4+Pj4gd2hpY2ggdGhleSBhcmUgdG8gYmUgaW52b2tlZCBmb3Ig c29tZSBwYXJ0aWN1bGFyIGZsb3cgb3Igc2V0IA0KPj4+Pj4+Pj4+PiBvZiBmbG93cywNCj4+IHdp dGhvdXQNCj4+Pj4+PiBjb25jZXJuIG9mDQo+Pj4+Pj4+Pj4+IGFjdHVhbCBzZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlIHNlbGVjdGlvbi4gICBUaGUgQ29uc3RyYWluZWQtU0ZDDQo+Pj4+Pj4+Pj4+ IChDLVNGQykgZnVydGhlciBhbGxvd3MgZm9yIHBvbGljeSBjb25zdHJhaW50cyB0byBiZSBhZGRl ZCB0byANCj4+Pj4+Pj4+Pj4gdGhlIFNGQyBhZmZlY3RpbmcgdGhlIGluc3RhbmNlIHNlbGVjdGlv biBvZiBvbmUgb3IgbW9yZSBvZiANCj4+Pj4+Pj4+Pj4gdGhlIHNlcnZpY2UNCj4+Pj4+PiBmdW5j dGlvbnMNCj4+Pj4+Pj4+Pj4gaW4gdGhlIFNGQy4gICBBbnkgU0ZDIG1heSBoYXZlIGFueSBudW1i ZXIgb2YgQy1TRkMncyBhc3NvY2lhdGVkDQo+Pj4+Pj4+Pj4+IHdpdGgNCj4+Pj4+Pj4+IGl0LiIN Cj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoYW5rcy4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ ICAgICBSb24NCj4+Pj4+Pj4+PiAuLi4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9m ICpEYXZpZCANCj4+Pj4+Pj4+Pj4gQWxsYW4gSQ0KPj4+Pj4+Pj4+PiAqU2VudDoqIE1vbmRheSwg SnVseSAxNCwgMjAxNCAyOjAzIFBNDQo+Pj4+Pj4+Pj4+ICpUbzoqIEppbSBHdWljaGFyZCAoamd1 aWNoYXIpOyBzZmNAaWV0Zi5vcmcgDQo+Pj4+Pj4+Pj4+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0K Pj4+Pj4+Pj4+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0 cw0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSSBsaWtlIHRoYXQgdGV4dCwgaXQgc3RyaWtlcyBh IGdvb2QgYmFsYW5jZSB3aGVyZSBhbiANCj4+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb24gaGFzIHRo ZSBvcHRpb24gb2YgbWFraW5nIHNjYWxlIGFuZCByZXNpbGllbmN5IA0KPj4+Pj4+Pj4+PiBhIGxv Y2FsDQo+Pj4+Pj4gbWF0dGVyLi4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEQNCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g Kk9uIEJlaGFsZiBPZiAqSmltIA0KPj4+Pj4+Pj4+PiBHdWljaGFyZA0KPj4+Pj4+Pj4+PiAoamd1 aWNoYXIpDQo+Pj4+Pj4+Pj4+ICpTZW50OiogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDEwOjQ4IEFN DQo+Pj4+Pj4+Pj4+ICpUbzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+ Pj4+Pj4+Pj4gKlN1YmplY3Q6KiBbc2ZjXSBTRkMgVGVybWlub2xvZ3kgLyBDb25jZXB0cw0KPj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gRGVhciBXRzoNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRo ZXJlIGhhcyBiZWVuIG11Y2ggZGViYXRlIG92ZXIgdGhlIGxhc3QgZmV3IGRheXMgd2l0aCANCj4+ Pj4+Pj4+Pj4gcmVnYXJkcyB0byBTRkMgY29uY2VwdHMuIFRvIHRyeSBhbmQgZm9ybSBzb21lIGNv bnNlbnN1cyANCj4+Pj4+Pj4+Pj4gYXJvdW5kIHRlcm1pbm9sb2d5IGFuZCBjb25jZXB0cyB1c2Vk IHRvIGRlc2NyaWJlIHRoZSANCj4+Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlIGluIHRoZSBtZXJnZWQg YXJjaGl0ZWN0dXJlIGRyYWZ0LCBKb2VsIGhhcyBraW5kbHkgc3VnZ2VzdGVkIHRoZSBmb2xsb3dp bmc6DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAiVGhlIFNGUCBwcm92aWRlcyBhIGxldmVsIG9m IGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIGZ1bGx5IA0KPj4+Pj4+Pj4+PiBhYnN0cmFjdCBub3Rp b24gb2Ygc2VydmljZSBwYXRoIGFzIGEgc2VxdWVuY2Ugb2YgZnVuY3Rpb25zIHRvIA0KPj4+Pj4+ Pj4+PiBiZSBkZWxpdmVyZWQsIGFuZCB0aGUgZnVsbHkgc3BlY2lmaWVkIG5vdGlvbiBvZiBleGFj dGx5IHdoYXQgDQo+Pj4+Pj4+Pj4+IGluc3RhbmNlcyBvZiBTRkZzIHRoZSBwYWNrZXQgd2lsbCB2 aXNpdCB3aGVuIGl0IGFjdHVhbGx5IA0KPj4+Pj4+Pj4+PiB0cmF2ZXJzZXMgdGhlIG5ldHdvcmsu IEJ5IGFsbG93aW5nIHRoZSBjb250cm9sIGNvbXBvbmVudHMgdG8gDQo+Pj4+Pj4+Pj4+IHNwZWNp ZnkgdGhlIHVzZSBvZiB0aGlzIGxldmVsIG9mIGluZGlyZWN0aW9uLCB0aGUgZGVwbG95bWVudCAN Cj4+Pj4+Pj4+Pj4gbWF5IGNob29zZSB0aGUgZGVncmVlIG9mIFNGRiBpbnN0YW5jZSBzZWxlY3Rp b24gYXV0aG9yaXR5IA0KPj4+Pj4+Pj4+PiB0aGF0IGlzIGRlbGVnYXRlZCB0byB0aGUgbmV0d29y ay4iDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBJJ2QgbGlrZSB0byBhc2sgdGhlIFdHIGFzIGEg d2hvbGUsIGlmIHRoaXMgY2xhcmlmaWNhdGlvbiBpcyANCj4+Pj4+Pj4+Pj4gc29tZXRoaW5nIHRo YXQgd2UgY2FuIGdldCBjb25zZW5zdXMgb24uIElmIHNvLCBJJ2xsIGFzayBKb2VsIA0KPj4+Pj4+ Pj4+PiB0byBwcm92aWRlIHNwZWNpZmljIHRleHQsIHRoYXQgcmVmbGVjdHMgdGhlIGFib3ZlLCBm b3IgDQo+Pj4+Pj4+Pj4+IGluY2x1c2lvbiBpbiB0aGUgbWVyZ2VkIGFyY2hpdGVjdHVyZSBkcmFm dC4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoYW5rIFlvdSwNCj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+IEppbQ0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBzZmNAaWV0Zi5vcmcN Cj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+IA0K Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+PiANCj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFp bGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGlu ZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0K From nobody Sun Jul 20 16:54: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 248521B2A53 for ; Sun, 20 Jul 2014 16:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 AeNEVuogmOvZ for ; Sun, 20 Jul 2014 16:54:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361A51B2959 for ; Sun, 20 Jul 2014 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17843; q=dns/txt; s=iport; t=1405900490; x=1407110090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AFKkIdH8GJBZ0DtEgbaW7D8gbOepBvOYCmQAHJd30Ko=; b=VkxSNS8dgqqlT1dHjFwyaRglK5jrnTMux/adTwTeZVPFosUZOxSQRyrq 29grnlfOMYCrQtPuWcZgJpEtGni/jW8ukIL9AQfmSIEgcj1Rg3HB02MTA XwcSW9+DeJ9YHz6jR6wucDxB46FEPKlF8yAACY2i49hfjZBIK7pipClZq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAHlVzFOtJA2H/2dsb2JhbABPCoMOUlvFIQqHRAGBCBZ2hAMBAQEEAQEBC1cCAQYEAQYMBAIBCBEBAwEBASMEBycLFAMGCAIEAQ0FG4gnDb9IEwSOb1cFBwaEQAEEiiuMXIQelC+CAoFCbIFF X-IronPort-AV: E=Sophos;i="5.01,697,1400025600"; d="scan'208";a="62501054" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 20 Jul 2014 23:54:49 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6KNsmOc004908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 23:54:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 20 Jul 2014 18:54:48 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar , Ron Parker Thread-Topic: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly Thread-Index: AQHPo7Pee23HwWTat0aRpuA0e2fRB5uog9iAgAFyIAD//79ZAA== Date: Sun, 20 Jul 2014 23:54:47 +0000 Message-ID: References: <53C4235D.5010701@gmail.com> <53C434F4.7050208@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330032583@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08293265@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082936DD@NKGEML512-MBS.china.huawei.com> <9BCE8FDC-221E-4F9E-9608-4FDE525ED0EC@lucidvision.com> <0F8583BBE82FA449A8B78417CC07559AA232DC@SJCEML702-CHM.china.huawei.com> <53C6F2D3.70805@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300351BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F645DA011A@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645DA072D@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA072D@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.21.82.85] 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/PkYbDod76WlbdYiCm23AVTNZG9M Cc: Henry Fourie , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Subject: Re: [sfc] MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 20 Jul 2014 23:54:53 -0000 So, we'd agree it's no special concern because it's SFC - only because of the generic, often-visited, often-cited concern when "the header is extend" (presumably - though, I wouldn't want to presume a solution)"? Out of curiosity, what non-fragmentable transport should we be concerned about? On 7/20/14 7:46 PM, "Linda Dunbar" wrote: >Ron,=20 > >Answer inserted below: > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >Linda, > >I'm not debating that fragmentation should be minimized. But, wrt >legacy SF's -- if the transport + service encaps increases the packet >enough to cause fragmentation, wouldn't it be at the transport level and >not at the level of the original packet? > >[Linda] We are in agreement that the fragmentation at transport level >requires the SFF nodes to reassemble fragmented packets before passing to >SF nodes.=20 > > > [Given that it can only be so for fragmentable transports (ie ipv4, >ipv6)].=20 > >[Linda] Routers do not fragment IPv6 packets, as they do for IPv4. So SFC >header for IPv6 has to be more compact. > > > > > Ron > > >> On Jul 19, 2014, at 8:45 PM, "Linda Dunbar" >>wrote: >>=20 >> The MTU section of the merged-sfc-arch is one example showing what Med >>said about the current architecture "including some solution hints that >>come mainly from nsh". >>=20 >>=20 >> An important part of SFC is the SFC header encapsulation. >> Therefore, the MTU section should emphasize the importance of avoiding >>packets fragmentation and reassembly because most service functions, >>especially legacy L4-L7 service functions, don't expect fragmented >>packets. It is very expensive for intermediate SFF/SN nodes to >>reassemble packets before passing packets to Service Functions. E.g. The >>SFC header should avoid literally listing the addresses (especially IPv6 >>addresses) of the service functions in a service function chain. >>=20 >> But final MTU Section emphasizes that the modern systems can handle >>packets fragmentation and reassembly, meaning NSH header (no matter how >>long) is no problem. >>=20 >>=20 >> I had a two separate conference calls with the authors of the >>SFC-architecture draft addressing suggested merging of some content from >>"legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than 1 >>hour).=20 >>=20 >> One of the issues being discussed is the MTU section. Here is text that >>I suggested to merge with the general "sfc-arch": >>=20 >> "Encapsulating SFC header to data packets has to take MTU size into >>consideration because most service functions, especially legacy L4-L7 >>service functions, don't expect fragmented packets. >> It is very expensive for intermediate SFF/SN nodes to reassemble >>packets before passing packets to Service Functions. >> Therefore, the information carried by the SFC header has to be compact. >>The SFC header should avoid literally listing the addresses (especially >>IPv6 addresses) of the service functions in a service function chain." >>=20 >> I sincerely hope that the authors can take this text (or variation of >>this text) for the MTU section of sfc-arch. >>=20 >> Linda >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Thursday, July 17, 2014 12:57 AM >> To: Joel M. Halpern; Henry Fourie; sfc@ietf.org >> Subject: Re: [sfc] SFC Terminology / Concepts >>=20 >> Hi Joel, >>=20 >> I fully agree with you about the goal. >>=20 >> Nevertheless, the merged document, as it currently stands, includes >>some solution hints that come mainly from nsh. I would really hope the >>document be updated to be neutral. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern >>> Envoy=E9 : mercredi 16 juillet 2014 23:47 =C0 : Henry Fourie; >>> sfc@ietf.org Objet : Re: [sfc] SFC Terminology / Concepts >>>=20 >>> I would hope that we can end up with an archtiecture document that is >>> understandable and useful without resorting to a specific solution >>> document. That is our goal. There probably are refinements needed >>> to achieve that goal. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 7/16/14, 5:39 PM, Henry Fourie wrote: >>>> Ken, >>>> The Service chain Header draft >>>> https://datatracker.ietf.org/doc/draft- >>> zhang-sfc-sch/ >>>> should answer some of your questions. In particular: >>>>=20 >>>> In section 4.2 Mandatory Fields: >>>>=20 >>>> Path Identifier: Identifies a fully instantiated service function >>>> path. It represents a sequence of network locators, one for each >>>> service function that is to be invoked. Participating SFC >>>>entities >>>> MUST use this identifier when selecting the next hop for the >>>> packet or frame. >>>>=20 >>>> In section 4.4 Header Associated Operations: >>>>=20 >>>> 3. Service Path Selection. The Service Network Forwarder (SNF) uses >>>> the Service Chain Identification information in the SCH to steer >>>> the traffic flow along the SFC path. >>>>=20 >>>> 4. Service Function Instance Selection. The Service Function >>>> Forwarder (SFF) uses the Service Chain Identification >>>>information >>>> in the SCH to locate the service instance and forward the >>>>traffic >>>> flow to the service instance. The mapping of the Service Chain >>>> Identification to a service instance can be established through >>>> the management/control plane, which is out of scope of this >>>> document. >>>>=20 >>>> - Louis >>>>=20 >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray >>>> (kegray) >>>> Sent: Wednesday, July 16, 2014 11:59 AM >>>> To: Thomas D. Nadeau; sfc-chairs@ietf.org >>>> Cc: sfc@ietf.org; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; >>> mohamed.boucadair@orange.com >>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>=20 >>>> Joel, et. all, >>>>=20 >>>> I think that some of the questions in architecture (SFP/SFC chasing >>>> it's >>>> tail) come as people look forward to the encapsulation/header >>>>document. >>>> That's probably unavoidable. >>>>=20 >>>> When you read the NSH document, the SFP verbiage says that all >>>> participants MUST forward on the SP/SPI, but the document doesn't >>>> say how the SPI is derived/calculated (the vision here could be made >>>> clearer) or what it's relationship is to the transport path (I think >>>> you can't mix >>> and >>>> match but can accommodate both within the header), should you opt >>>> for the transport header forwarding. >>>>=20 >>>> It's obvious that some deployments prefer to use the transport >>>> header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop >>>> lookup (which does play into the SPI or "other mechanisms" that >>>> populate a service >>> table >>>> in the SFF). >>>>=20 >>>> Perhaps the authors of NSH can suggest verbiage that makes the >>>> relationship between transport-based forwarding and service-based >>>> forwarding (SPI) clearer? >>>>=20 >>>> This should eliminate/minimize the calls for redefinition/recasting >>>> our terminology and allow us to move on. >>>>=20 >>>>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" >>>>>wrote: >>>>>=20 >>>>>=20 >>>>> I have gotten a bit lost in the SFF/SFC discussion, which seems >>>>> to >>> have >>>>> gotten needlessly complicated and convoluted IMHO. >>>>>=20 >>>>> Is it possible for the chairs to add this to the list of things >>>>> to discuss at the WG meeting or do we want to resolve this on the >>>>> list >>> ahead >>>>> of the meeting? >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>>>> >>>>> wrote: >>>>>=20 >>>>>> Hi Peng, >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: He, Peng [mailto:phe@ciena.com] >>>>>>> Sent: Tuesday, July 15, 2014 9:09 PM >>>>>>> To: Xuxiaohu; mohamed.boucadair@orange.com; Joel M. Halpern; Tom >>>>>>> Taylor; sfc@ietf.org; Ron Parker >>>>>>> Subject: RE: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Try to understand the three scenarios you listed: you mean the >>>>>>> classifier can specify a (partial or complete) SFP which is a >>>>>>> list of SFFs, then each SFF will >>>>>>> (locally) select one of the SF instances under itself for this SF. >>>>>>> For partial SFP case, >>>>>>=20 >>>>>> In either case, the SFF should be capable of selecting the >>>>>> appropriate instance of a given SF attached to itself. it's an >>>>>> internal load-balancing issue. >>>>>>=20 >>>>>>> each SFF will identify the SFI under itself and specify (like a >>>>>>> classifier) next SFF(s). >>>>>>> The classifier (and SFF?) could obtain this (SFF) 'path' >>>>>>> information >>>>>>> from either >>>>>>> centralized point (e.g., PCE, controller), or, via a distributed >>>>>>> control plane? For partial SFP, will there be a re-classification >>>>>>> to decide next SFF(s) or not? >>>>>>=20 >>>>>> If you want the SFF to locally determine the appropriate SFF for >>>>>> the next SF, the SFF should have the capability of resolving the >>>>>> SFF for >>> the >>>>>> next SF based on certain constraints. Of course, it needs to know >>>>>> some information about the SFs in advance, e.g., the information >>>>>> about which SFFs a given SF is attached. >>>>>>=20 >>>>>> Best regards, >>>>>> Xiaohu >>>>>>=20 >>>>>>> Regards, >>>>>>> Peng >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu >>>>>>> Sent: Tuesday, July 15, 2014 4:49 AM >>>>>>> To: mohamed.boucadair@orange.com; Joel M. Halpern; Tom Taylor; >>>>>>> sfc@ietf.org; Ron Parker >>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>>=20 >>>>>>> Hi Med, >>>>>>>=20 >>>>>>> IMHO, the architecture should allow the classifier to specify >>>>>>>=20 >>>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>>>>> locally determine the appropriate SFF for the next SF); >>>>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>>>>> determined by the centralized node); >>>>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>>>>> determine the appropriate SFF for the next SF). >>>>>>>=20 >>>>>>> In fact, case 3) could be looked as an extreme of case 1). >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Xiaohu >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com >>>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM >>>>>>>> To: Joel M. Halpern; Tom Taylor; sfc@ietf.org; Ron Parker >>>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts >>>>>>>>=20 >>>>>>>> Hi Joel, >>>>>>>>=20 >>>>>>>> As mentioned in several messages, I'm personally for the use of >>>>>>>> the chain itself is the main information to be conveyed in >>>>>>>> packets to drive >>>>>>> forwarding actions. >>>>>>>>=20 >>>>>>>> I can understand that an identifier can be assigned to a path >>>>>>>> that is known in advance, but if that path is not known I'm not >>>>>>>> sure how an identifier can be assigned to it! >>>>>>>>=20 >>>>>>>> Joel, the use of "path" is really inappropriate to refer to >>>>>>>> distributed instance selection process for packets bound to a >>>>>>>> given SFC. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. >>>>>>>>> Halpern Envoy=E9 : lundi 14 juillet 2014 21:52 =C0 : Tom Taylor; >>>>>>>>> sfc@ietf.org; Ron Parker Objet : Re: [sfc] SFC Terminology / >>>>>>>>> Concepts >>>>>>>>>=20 >>>>>>>>> The most likely realization of the architecture would be that >>>>>>>>> the >>> SFP >>>>>>>>> assignment is recorded in an identifier which travels with the >>>>>>>>> packet. >>>>>>>>>=20 >>>>>>>>> Some folks seem to not want the architecture to mandate that. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote: >>>>>>>>>> Your text scares me because it introduces some new concepts >>>>>>>>>> and assumptions. >>>>>>>>>>=20 >>>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on >>>>>>>>>>that: >>>>>>>>>> am I right in seeing the implication that when control assigns >>>>>>>>>> an SFP, the assignment is recorded by an identifier wwhich >>>>>>>>>> travels with the >>>>>>>> packet? >>>>>>>>>>=20 >>>>>>>>>> Tom Taylor >>>>>>>>>>=20 >>>>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote: >>>>>>>>>>> There is one missing word in my text. Please replace my >>>>>>>>>>>proposed >>>>>>>>>>> text >>>>>>>>>>> with: >>>>>>>>>>>=20 >>>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract >>>>>>>>>>> view of the service functions to be invoked and the order in >>>>>>>>>>> which they are to be invoked for some particular flow or set >>>>>>>>>>> of flows, >>> without >>>>>>> concern of >>>>>>>>>>> actual service function instance selection. The >>>>>>>>>>>Constrained-SFC >>>>>>>>>>> (C-SFC) further allows for policy constraints to be added to >>>>>>>>>>> the SFC affecting the instance selection of one or more of >>>>>>>>>>> the service >>>>>>> functions >>>>>>>>>>> in the SFC. Any SFC may have any number of C-SFC's associated >>>>>>>>>>> with >>>>>>>>> it." >>>>>>>>>>>=20 >>>>>>>>>>> Thanks. >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>> ... >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *David >>>>>>>>>>> Allan I >>>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM >>>>>>>>>>> *To:* Jim Guichard (jguichar); sfc@ietf.org >>>>>>>>>>> >>>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts >>>>>>>>>>>=20 >>>>>>>>>>> I like that text, it strikes a good balance where an >>>>>>>>>>> implementation has the option of making scale and resiliency >>>>>>>>>>> a local >>>>>>> matter.. >>>>>>>>>>>=20 >>>>>>>>>>> D >>>>>>>>>>>=20 >>>>>>>>>>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim >>>>>>>>>>> Guichard >>>>>>>>>>> (jguichar) >>>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM >>>>>>>>>>> *To:* sfc@ietf.org >>>>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts >>>>>>>>>>>=20 >>>>>>>>>>> Dear WG: >>>>>>>>>>>=20 >>>>>>>>>>> There has been much debate over the last few days with >>>>>>>>>>> regards to SFC concepts. To try and form some consensus >>>>>>>>>>> around terminology and concepts used to describe the >>>>>>>>>>> architecture in the merged architecture draft, Joel has kindly >>>>>>>>>>>suggested the following: >>>>>>>>>>>=20 >>>>>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>>>>> abstract notion of service path as a sequence of functions to >>>>>>>>>>> be delivered, and the fully specified notion of exactly what >>>>>>>>>>> instances of SFFs the packet will visit when it actually >>>>>>>>>>> traverses the network. By allowing the control components to >>>>>>>>>>> specify the use of this level of indirection, the deployment >>>>>>>>>>> may choose the degree of SFF instance selection authority >>>>>>>>>>> that is delegated to the network." >>>>>>>>>>>=20 >>>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel >>>>>>>>>>> to provide specific text, that reflects the above, for >>>>>>>>>>> inclusion in the merged architecture draft. >>>>>>>>>>>=20 >>>>>>>>>>> Thank You, >>>>>>>>>>>=20 >>>>>>>>>>> Jim >>>>>>>>>>>=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 >>>> _______________________________________________ >>>> 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 nobody Mon Jul 21 05:50: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 783591B2BC6 for ; Mon, 21 Jul 2014 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 VFQQm1UNJcuh for ; Mon, 21 Jul 2014 05:50:35 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.118]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCCE1B2BCC for ; Mon, 21 Jul 2014 05:50:33 -0700 (PDT) Received: from [193.109.255.99:16163] by server-14.bemta-14.messagelabs.com id C6/8A-02763-79C0DC35; Mon, 21 Jul 2014 12:50:31 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-13.tower-48.messagelabs.com!1405947030!10898909!1 X-Originating-IP: [195.232.224.73] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9301 invoked from network); 21 Jul 2014 12:50:31 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.224.73) by server-13.tower-48.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2014 12:50:31 -0000 Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailout04.vodafone.com (Postfix) with ESMTP id DFEAB800EF for ; Mon, 21 Jul 2014 14:50:29 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id CED3E800E6; Mon, 21 Jul 2014 14:50:29 +0200 (CEST) Received: from VOEXC19W.internal.vodafone.com (145.230.103.124) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Jul 2014 14:50:29 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.119]) by VOEXC19W.internal.vodafone.com ([145.230.103.124]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 14:50:28 +0200 From: "Haeffner, Walter, Vodafone DE" To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] On architecture constraining solutions (or not) Thread-Index: AQHPpEkGbYW9MsJrvk27vv98GilFw5uqdipA Date: Mon, 21 Jul 2014 12:50:28 +0000 Message-ID: References: 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/Nyj20dWm38yFUPImC46x1KTgnTY Cc: "Jim Guichard \(jguichar\) \(jguichar@cisco.com\)" Subject: Re: [sfc] On architecture constraining solutions (or not) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 21 Jul 2014 12:50:37 -0000 What some people are probably asking for is a functional design doc. But th= e WG didn't decide for that, although in systems design you typically have = the chain=20 requirements spec -> functional spec -> system architecture -> design specs= ...... The functional spec does not describe the internal machinery of a system bu= t its behavior and interaction with the outside. Like ingoing flow -> black= box action -> outgoing flow, where outgoing flow may mean specific modified= transport behavior, modified payload, something else. Architecture describes the information flow and information processing in s= ome more detail. Therefore an architecture doc is the first step towards on= e of probably multiple solutions.=20 Having this in mind Joel's merged architecture exactly does what an archite= cture doc should do. What do you think? Kind regards,=20 Walter =20 -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Thomas Narten Gesendet: Sonntag, 20. Juli 2014 20:33 An: sfc@ietf.org Betreff: [sfc] On architecture constraining solutions (or not) At Fri, 18 Jul 2014 20:38:12 +0000, Lucy yong wrote: > > I suspect that there are two separate but related issues. > >=20 > > The architecture we proposed, and probably any useful archtiecture,=20 > > does constrain solutions. In adopting an archtiecture, the working=20 > > group makes some choices. > [Lucy] not so sure. We should adopt an architecture without making=20 > solution choices ahead. The architecture leads solution development,=20 > not the other way. > At the same time, those constraints should general, not specific, and=20 > certainly not aimed at the NSH solution in particular. > [Lucy] Yes and Agree. I want to call out this point, because it is important. IMO, the architectu= re absolutely can and should make choices that constrain solutions. An arch= itecture that doesn't constrain solutions, seems to me to not be an archite= cture at all -- it suggests anything is allowed and nothing is disallowed. = (I'm exaggerating a bit to make the point.) That said, the architecuture shouldn't exclude or prevent things that that = the WG deems important to support. But it is neither the job of the WG (nor= helpful) to try to support any/all hypothetical possibilities. We are supp= osed to be solving real problems with real requirements with a goal of deve= loping real solutions. The architecture needs to support that. But no more. An important point of an architecture it to outline at a high level what wi= ll be supported and what won't be supported -- and to make choices at a hig= h level about solution directions. By definition, that means solutions will= be constrained. So yes, making architectural decisions that constrain solutions is OK. Of c= ourse, the WG should be aware it is making such choices and should be in ag= reement with making any such constraints. Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jul 21 07:51: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 2CF281A014D for ; Mon, 21 Jul 2014 07:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 v1aTkWFmVvIw for ; Mon, 21 Jul 2014 07:51:38 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6EF1A006D for ; Mon, 21 Jul 2014 07:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52; q=dns/txt; s=iport; t=1405954288; x=1407163888; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=yUd/Phqrz89B3LjzbfqquZlz708X4HmcNknDxMXAFRs=; b=jDdCmhiyM6GL/m0x4E4xPrxqKCBTVEY9IU41juX8kb4ejElMLFWcygwL c229PpL43tXR09Z34vwXvY+PB1f5utTuUhMAeDMMEfC2v53bIwBHI3Obe S6IyBMVkdTgRqH/U8O6TsZ5Cw0gsNS9i7UKEYtq2H76DlTHe/On7FILet Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoIALMozVOtJA2I/2dsb2JhbABZgw5SGj4DxUyHO4EjFnaEQkA9FhgDAgECAUsNCAEBiD4NmBymLBePaIQwBYorkHqBTYVIjRqDYIIV X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208";a="62695673" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 21 Jul 2014 14:51:27 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6LEpR6M002637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 14:51:27 GMT Received: from [10.82.237.27] (10.82.237.27) by xhc-rcd-x08.cisco.com (173.37.183.82) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Jul 2014 09:51:26 -0500 Message-ID: <53CD28F3.6050502@cisco.com> Date: Mon, 21 Jul 2014 10:51:31 -0400 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.82.237.27] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/rRJiPZeWUduJRx-92Yt6mrylIvk Subject: [sfc] SFC Yang Data Model Update (v06) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 21 Jul 2014 14:51:41 -0000 http://tools.ietf.org/html/draft-penno-sfc-yang-06 From nobody Mon Jul 21 12:33: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 9835A1A0387; Mon, 21 Jul 2014 12:33:44 -0700 (PDT) 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 Z9qBsqwAUQCB; Mon, 21 Jul 2014 12:33:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAE01A036B; Mon, 21 Jul 2014 12:33:43 -0700 (PDT) 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.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721193343.30086.20240.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 12:33:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/hFwnE054U-kpE1XA-WBuGTs4RKo Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-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: Mon, 21 Jul 2014 19:33:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases In Data Centers Authors : Surendra Kumar Mudassir Tufail Sumandra Majee Claudiu Captari Shunsuke Homma Filename : draft-ietf-sfc-dc-use-cases-01.txt Pages : 23 Date : 2014-07-21 Abstract: Data center operators deploy a variety of layer 4 through layer 7 service functions in both physical and virtual form factors. Most traffic originating, transiting, or terminating in the data center is subject to treatment by multiple service functions. This document describes use cases that demonstrate the applicability of Service Function Chaining (SFC) within a data center environment and provides SFC requirements for data center centric use cases, with primary focus on Enterprise data centers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-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 Mon Jul 21 17:31: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 3172F1A0151 for ; Mon, 21 Jul 2014 17:31:34 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dcFQSMT3Kq_E for ; Mon, 21 Jul 2014 17:31:31 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DD51A0114 for ; Mon, 21 Jul 2014 17:31:31 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id 1308153DDF for ; Mon, 21 Jul 2014 17:31:13 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Mon, 21 Jul 2014 17:31:12.948 -0700 x-echoworx-msg-id: 8edf55e7-bd9c-4a89-87cf-2539ee566531 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 726 for ; Mon, 21 Jul 2014 17:31:12 -0700 (PDT) Received: from HUB021-CA-2.exch021.domain.local (unknown [10.254.4.33]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D213E53DDF for ; Mon, 21 Jul 2014 17:31:12 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Mon, 21 Jul 2014 17:31:30 -0700 From: Ron Parker To: "sfc@ietf.org" Thread-Topic: Specific comments on draft-merged-sfc-architecture-00 Thread-Index: Ac+lPPxZRjqbIefMS3GBnQ71YZRhow== Date: Tue, 22 Jul 2014 00:31:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.149.201] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8C1317MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6SxnU0p9LGIh0jU4vdSstg2_NSE Subject: [sfc] Specific comments on draft-merged-sfc-architecture-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, 22 Jul 2014 00:31:34 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8C1317MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all. I've just given a complete re-read to the merged architecture draft and I'd= like to reinforce all of the thread comments that the editors have done a = great job. We've had quite an airing on some related topics, including instance select= ion, and the editors are likely taking these into account, already. At th= e risk of repeating, I'd like to provide a few specific comments based on m= y re-read, here: Section 2.3 (Service Function Paths) - this section does indeed adequately = define an SFP as either being fully constrained or partially constrained --= "This abstraction enables the binding of SFCs to specific instances, or s= et of like instances of SFs based on a range of policy attributes defined b= y the operator". However, the section then goes on to imply that an SFP i= s fully constrained - "and only when the SFP is created is one of those fi= rewall instances selected". As has been discussed on the thread, a sugg= estion was to allow for (but not require) distributed instance selection, p= resumably by the SFF's. Section 3 (Architectural Principles) - item 4 (Shared Metadata) - this item= calls out sharing between classifier and SF's and between SF's and SF's. = If distributed instance selection is supported, then it would be also usef= ul to share metadata between classifier and SFF's in order to facilitate po= licy driven distributed instance selection. Section 4.3 (SFF) - In cases where SFP is not fully constrained, additional= responsibilities would be added to the list of primary responsibilities - = selection of an SFI for the current SF in the chain when the SFP is not ful= ly constrained for that SF; section of an SFF hosting one or more instances= of the next SF when the SFP is not fully constrained for that SF. Section 4.9 (shared metadata) - similar comments as per Section 3, above, r= elated to interest by SFF of the metadata for purposes of facilitating poli= cy driven distributed instance selection. Thanks. Ron --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8C1317MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all.

 

I’ve just given a complete re-read to the merg= ed architecture draft and I’d like to reinforce all of the thread com= ments that the editors have done a great job.

 

We’ve had quite an airing on some related topi= cs, including instance selection, and the editors are likely taking these i= nto account, already.   At the risk of repeating, I’d like = to provide a few specific comments based on my re-read, here:

 

Section 2.3 (Service Functio=
n Paths) – this section does indeed adequately define an SFP as eithe=
r being fully constrained or partially constrained -- “This abstraction enables the binding of SFCs to specific inst=
ances,  or set of like instances of SFs based on a range of policy att=
ributes defined by the operator”.   However, the section th=
en goes on to imply that an SFP is fully constrained – “and onl=
y when the SFP  is created is one of those firewall instances selected=
”.     As has been discussed on the thread, a sug=
gestion was to allow for (but not require) distributed instance selection, =
presumably by the SFF’s.
 
Section 3 (Archi=
tectural Principles) – item 4 (Shared Metadata) – this item cal=
ls out sharing between classifier and SF’s and between SF’s and=
 SF’s.   If distributed instance selection is supported, th=
en it would be also useful to share metadata between classifier and SFFR=
17;s in order to facilitate policy driven distributed instance selection.

 

Section 4.3 (SFF) – In cases where SFP is not = fully constrained, additional responsibilities would be added to the list o= f primary responsibilities – selection of an SFI for the current SF i= n the chain when the SFP is not fully constrained for that SF; section of an SFF hosting one or more instances of the next S= F when the SFP is not fully constrained for that SF.

 

Section 4.9 (shared metadata) – similar commen= ts as per Section 3, above, related to interest by SFF of the metadata for = purposes of facilitating policy driven distributed instance selection.=

 

Thanks.

 

    Ron

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8C1317MBX021W3CA2exch_-- From nobody Tue Jul 22 14:39: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 2D6D81B2C82 for ; Tue, 22 Jul 2014 14:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 iCZ04GH-qpsG for ; Tue, 22 Jul 2014 14:39:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899B31B2B8E for ; Tue, 22 Jul 2014 14:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1340; q=dns/txt; s=iport; t=1406065160; x=1407274760; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E59KqDVlcJaSSgFmN73/D7IF40iP8DIJ5H1wDbO7BFs=; b=O2F7vaTYO7rODlBnDk4pt+RQDx6S7AMvnHZS41HD/KHN8ePm00YXyeWc rHnXlc3f6sbWlkkm/xA9orqS0UGDHv12INwRCgiTkjpAciV38RtoIX6jE md+t0NV84GWOPONLfAxnp9aqyPYMf9Rlms3O9Pq/q4+DGtt6UIv8+dCIF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFACfZzlOtJA2H/2dsb2JhbABZgw6BKQTOaAGBEhZ2hAMBAQEEgQUEAgEIEQECAQIBLjIXBggBAQQBEohCv38Xjxg6BoRAAQSORYhEhB6UM4NGbIFF X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="342147638" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 22 Jul 2014 21:39:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6MLdIfb007371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 21:39:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 16:39:18 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" , Dave Dolson , "sfc@ietf.org" Thread-Topic: Does SFF or SFC Proxy maintain flow state? Thread-Index: Ac+flZmPoVqRhMYfST+uEKhSnlnxIAAMeeGAAY2QuIA= Date: Tue, 22 Jul 2014 21:39:18 +0000 Message-ID: References: <53C435BF.7090803@joelhalpern.com> In-Reply-To: <53C435BF.7090803@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.228.111] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Qeubi-PyyFDssXAsxKmgrLm8ygQ Subject: Re: [sfc] Does SFF or SFC Proxy maintain flow state? X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 22 Jul 2014 21:39:23 -0000 I agree =8B thanks Dave. Fixing. Thanks, Carlos. -----Original Message----- From: Joel Halpern Date: Monday, July 14, 2014 at 3:55 PM To: Dave Dolson , "sfc@ietf.org" , Carlos Pignataro Subject: Re: Does SFF or SFC Proxy maintain flow state? >The later part of that quote does look like it needs work. As you say, >the Proxy is concerned with re-attaching information for SFC-unaware >service functions. > >Yours, >Joel > >On 7/14/14, 2:58 PM, Dave Dolson wrote: >> In draft-merged-sfc-architecture-00, section 4.3, >> >> >> >> The SFF component has the following primary responsibilities: >> >> =8A >> >> 3. Maintaining flow state: In some cases, the SFF may be stateful. >> >> It creates flows and stores flow-centric information. When >> >> traffic arrives after being steered through an SFC-unaware SF, >> >> the SFF must perform re-classification of traffic to determine >> >> the SFP. A state-full SFF simplifies such classification to a >> >> flow lookup. >> >> >> >> Is this correct? Shouldn=B9t it be the SFC Proxy that maintains flow sta= te >> in order to re-classify traffic returning from an SFC-unaware SF? >> >> -Dave >> From nobody Tue Jul 22 20:08: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 A57301A028E for ; Tue, 22 Jul 2014 20:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 pT5poXjgv22N for ; Tue, 22 Jul 2014 20:08:41 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086E51A0217 for ; Tue, 22 Jul 2014 20:08:37 -0700 (PDT) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 Jul 2014 21:08:36 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 22 Jul 2014 21:08:35 -0600 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id AEC543E4003D for ; Tue, 22 Jul 2014 21:08:34 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp07028.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6N370cZ6226404 for ; Wed, 23 Jul 2014 05:07:00 +0200 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6N38YD8006671 for ; Tue, 22 Jul 2014 21:08:34 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.110.87]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s6N38X9L006658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Jul 2014 21:08:34 -0600 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s6N38WO0006785 for ; Tue, 22 Jul 2014 23:08:32 -0400 Date: Tue, 22 Jul 2014 23:08:32 -0400 Message-ID: From: Thomas Narten To: sfc@ietf.org In-Reply-To: References: 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: 14072303-8236-0000-0000-0000040B8C3F Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/t2UbOT1M1ZEtoPLXFXZaSIfC6_w Subject: Re: [sfc] IPR Disclosure on SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 03:08:49 -0000 To close out this thread, there have been some clear voices to just note the IPR disclosure and continue working as we were chartered. There have also been some comments suggesting it might be nice to ask the IPR holder for additional clarifications. There have been no suggestions to stop or delay the SFC work. We will continue to proceed with the SFC work. We will take no aditional action at this time with respect to the disclosure. Specifically: 1) There is no formal mechanism in the IETF for asking IPR holders to "clarify" their disclosures. This is an intentional result stemming from long discussions over many years within the IETF that led to the current IETF IPR policies (i.e., RFC 3979 and related documents). 2) The IPR holder in this case has members who participate in the WG; it would be a reasonable to assume they have followed the discussions on this topic and are aware of the discussions on this topic. In the (very) few cases in the past when IETF WGs have "pushed back" on a particular IPR disclosure and have gotten the IPR holder to respond, it is a result of this sort of informal interaction. In other words, the discussion on this list has in effect been a vehicle to express a desire for additional clarification. The above said, there is not strong WG demand or consensus to pursue any approach other than moving forward and continuing our work. And certainly no demand to delay or stop work. Attempting to work around the IPR in specific solution drafts will of course be an option the WG can consider at the time there is a specific solution to consider. Thomas & Jim From nobody Wed Jul 23 07: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 47E401B286A for ; Wed, 23 Jul 2014 07:05:11 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dfYiVtJ3deRE for ; Wed, 23 Jul 2014 07:05:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D30F1B286E for ; Wed, 23 Jul 2014 07:05:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL35241; Wed, 23 Jul 2014 14:05:06 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:05:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 07:05:01 -0700 From: Linda Dunbar To: "sfc@ietf.org" Thread-Topic: Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQ== Date: Wed, 23 Jul 2014 14:05:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@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.157.77] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DA2A04dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VXCNBSoW4ISLNiqDSqdvmQpBYNs Subject: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:05:11 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DA2A04dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645DA2A04dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the SFP definition displayed at today SFC se= ssion is too complicated, more like lawyer’s wording than a term easi= ly understood by engineers (considering there are a lot of IETFers/engineer= s whose first language is not English).

 

Here is my suggested simpler wording:

 

Service Function Path (SFP):

SFP is a pathway traversing a sequence of service functions from ingress= to egress of the SFC-enabled domain, including sequence of SFFs and sequen= ce of SFs. This sequence can be specified precisely with exact sequence of SFFs and the sequence of SFs reached by e= ach SFF,  loosely specified with sets of SFFs/SFs, or somewhere in bet= ween.

 

Linda=

--_000_4A95BA014132FF49AE685FAB4B9F17F645DA2A04dfweml701chmchi_-- From nobody Wed Jul 23 07:30: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 CD99D1B2A21 for ; Wed, 23 Jul 2014 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 TN7whygEpfr6 for ; Wed, 23 Jul 2014 07:30:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234BF1B27CA for ; Wed, 23 Jul 2014 07:30:37 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6NEU7a9028046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jul 2014 09:30:07 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s6NEU7n8013224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Jul 2014 10:30:07 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.218]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 10:30:07 -0400 From: "Dolganow, Andrew (Andrew)" To: "sfc@ietf.org" Thread-Topic: Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoKZzKHOd1fHnEC4mx68Fzr5jQ== Date: Wed, 23 Jul 2014 14:30:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_CFF53D7756D4Candrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/1e9OF1HmA8RAlOK6xDBXKe2buqI Subject: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:30:44 -0000 --_000_CFF53D7756D4Candrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Following discussion during the meeting today, here is a specific comment o= n how to Change NSH to allow constant-size, easy-to-process in H/W Context = Header while also allowing for deployments that do not need to include the = header: 1. Keep existing format as per draft section 6 but rename from Mandatory= Context Header to Context Header 2. Make the presence of header optional and encode presence/absence usin= g a bit in Base header =96 proposed change text (in red): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CHP =96Context Header Present. If specified, Context Header as specified in= section 5 below follows directly Service Path Header Andrew --_000_CFF53D7756D4Candrewdolganowalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4C103124F16A5B4C93E77CAE4AC813D5@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Following discussion during the meeting today, here is a specific comm= ent on how to Change NSH to allow constant-size, easy-to-process in H/W Con= text Header while also allowing for deployments that do not need to include= the header:

  1. Keep existing format as per draft section 6 but rename from Mandatory C= ontext Header to Context Header 
  2. Make the presence of hea= der optional and encode presence/absence using  a bit in Base header = =96 proposed change text (in red):
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=
 7 8 9 0 1
     +-+-+-+-+---+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+
     |Ver|O|C|CHP|R|R|R|R|R|   Length  |    =
MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+

CHP =96Context Header Present. If specified, C= ontext Header as specified in section 5 below  follows directly Servic= e Path Header

Andrew

--_000_CFF53D7756D4Candrewdolganowalcatellucentcom_-- From nobody Wed Jul 23 07:34: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 A8F661B2905 for ; Wed, 23 Jul 2014 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 u8GEa7c8JXLN for ; Wed, 23 Jul 2014 07:34:27 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7C31B27CA for ; Wed, 23 Jul 2014 07:34:27 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6NEYOCx012169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jul 2014 09:34:26 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6NEYKXW010832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Jul 2014 16:34:23 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 16:34:00 +0200 From: "Henderickx, Wim (Wim)" To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoMkNjRx0c/3OEO/m6qB4Qj6jg== Date: Wed, 23 Jul 2014 14:34:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CFF53F86E2CCBwimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/xKdyJgLHuqRSWL5lHu60HTjPATs Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:34:29 -0000 --_000_CFF53F86E2CCBwimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree we should keep the header as small as possible and as such I also b= elieve we don=92t need the mandatory Ctxt field to be present. An alternative to the CHP bit could be to use length or MD-Type to indicate= its presence. From: , "Andrew (Andrew)" > Date: Wednesday 23 July 2014 10:30 To: "sfc@ietf.org" > Subject: [sfc] Change to Mandatory Context Header in NSH draft - optional p= resence Following discussion during the meeting today, here is a specific comment o= n how to Change NSH to allow constant-size, easy-to-process in H/W Context = Header while also allowing for deployments that do not need to include the = header: 1. Keep existing format as per draft section 6 but rename from Mandatory= Context Header to Context Header 2. Make the presence of header optional and encode presence/absence usin= g a bit in Base header =96 proposed change text (in red): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CHP =96Context Header Present. If specified, Context Header as specified in= section 5 below follows directly Service Path Header Andrew --_000_CFF53F86E2CCBwimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I agree we should keep the header as small as possible and as such I a= lso believe we don=92t need the mandatory Ctxt field to be present.
An alternative to the CHP bit could be to use length or MD-Type to ind= icate its presence. 

From: <Dolganow>, "Andre= w (Andrew)" <= andrew.dolganow@alcatel-lucent.com>
Date: Wednesday 23 July 2014 10:30<= br> To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Change to Mandatory = Context Header in NSH draft - optional presence

Following discussion during the meeting today, here is a specific comm= ent on how to Change NSH to allow constant-size, easy-to-process in H/W Con= text Header while also allowing for deployments that do not need to include= the header:

  1. Keep existing format as per draft section 6 but rename from Mandatory C= ontext Header to Context Header 
  2. Make the presence of hea= der optional and encode presence/absence using  a bit in Base header = =96 proposed change text (in red):
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=
 7 8 9 0 1
     +-+-+-+-+---+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+
     |Ver|O|C|CHP|R|R|R|R|R|   Length  |    =
MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+

CHP =96Context Header Present. If specified, C= ontext Header as specified in section 5 below  follows directly Servic= e Path Header

Andrew

 --_000_CFF53F86E2CCBwimhenderickxalcatellucentcom_-- From nobody Wed Jul 23 07:36: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 BB4321B2A31; Wed, 23 Jul 2014 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Mn0SRVH49E5N; Wed, 23 Jul 2014 07:36:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1968D1B2A2F; Wed, 23 Jul 2014 07:36:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN32216; Wed, 23 Jul 2014 14:36:20 +0000 (GMT) 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; Wed, 23 Jul 2014 15:36:20 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 22:36:14 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: Flexibility of SCH or NSH Thread-Index: Ac+mgVZ7EsuA1zKRSKKbmaoKloaCAA== Date: Wed, 23 Jul 2014 14:36:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296CF0@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.221] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qvIw8tKYtGaVFn7-SzfY2mzdT6g Cc: "spring@ietf.org" Subject: [sfc] Flexibility of SCH or NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:36:24 -0000 Hi all, I have said the following word at this thread (http://www.ietf.org/mail-arc= hive/web/sfc/current/msg02172.html): ************************ I'm glad to see that the Service Path Header is decoupled from the Base Hea= der of the NSH while the MD Type field is introduced. With such MD Type fie= ld, it becomes possible that the Base Header could be followed by 1) a Serv= ice Path Header, 2) a context header or 3) both. Option 1 would be used bet= ween SFFs in the case where metadata is not required to be shared. Option 2= would be used between SFFs and SFs in the case where SFs don't care about = the service path information at all. Option 3 would be used between SFFs in= the case where metadata is required to be shared. If you agree with the ab= ove possible usages, it may be helpful to allocate two additional MT Type c= odes besides 0x1 so as to indicate the above three options. ************************ Now I see the following text from (http://www.ietf.org/proceedings/90/slide= s/slides-90-sfc-1.pdf): Applicability: SCH text describes usage to optionally carry only chain forw= arding information; only metadata; or both. I believe the above flexibility is much worthwhile. In addition, opiton 2 (= i.e., only carry metadata or metadata correlation id) is also be meanful in= the case where the service path or chain informaiton has been carried some= where else rahter than in the SCH or NSH (http://www.ietf.org/proceedings/9= 0/slides/slides-90-spring-5.pptx). Best regards, Xiaohu= From nobody Wed Jul 23 07:40: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 70E1A1B2A4B for ; Wed, 23 Jul 2014 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 kq7MXHHkHxZx for ; Wed, 23 Jul 2014 07:40:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725701B2A68 for ; Wed, 23 Jul 2014 07:40:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6NEeBoR029480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jul 2014 14:40:11 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6NEeBAk025622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:40:11 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 23 Jul 2014 16:40:10 +0200 Received: from DEMUMBX009.nsn-intra.net ([169.254.9.174]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 16:40:10 +0200 From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: ext Linda Dunbar , "sfc@ietf.org" Thread-Topic: Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDw Date: Wed, 23 Jul 2014 14:40:10 +0000 Message-ID: <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@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.159.42.155] Content-Type: multipart/alternative; boundary="_000_9B067372C2434A429FBD4CF7F0E869FD20479D1EDEMUMBX009nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6223 X-purgate-ID: 151667::1406126411-000005B1-6526251A/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/n0fovbnN6FYCPECp2RiYmlfIfLI Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:40:44 -0000 --_000_9B067372C2434A429FBD4CF7F0E869FD20479D1EDEMUMBX009nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda --_000_9B067372C2434A429FBD4CF7F0E869FD20479D1EDEMUMBX009nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would propose to do = it even simpler

Service Function Path = (SFP):

SFP is a path traversing a sequence of service functions in a SFC-en= abled domain. The path includes a sequence of SFFs and/or SFs that can be e= xplicitly or loosely specified. In case of a loosely specification, at least the ingress and the egress SFFs and/o= r  SFs need to be specified.

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar
Sent: Wednesday, July 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Simpler description of Service Function Path

 

I think the SFP definition displayed at today SFC se= ssion is too complicated, more like lawyer’s wording than a term easi= ly understood by engineers (considering there are a lot of IETFers/engineer= s whose first language is not English).

 

Here is my suggested simpler wording:

 

Service Function Path (SFP):

SFP is a pathway traversing a sequence of service functions from ingre= ss to egress of the SFC-enabled domain, including sequence of SFFs and sequ= ence of SFs. This sequence can be specified precisely with exact sequence of SFFs and the sequence of SFs reached by e= ach SFF,  loosely specified with sets of SFFs/SFs, or somewhere in bet= ween.

 

Linda=

--_000_9B067372C2434A429FBD4CF7F0E869FD20479D1EDEMUMBX009nsnin_-- From nobody Wed Jul 23 07:45: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 DDA6E1A0A86 for ; Wed, 23 Jul 2014 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 oemowPX6lEkZ for ; Wed, 23 Jul 2014 07:45:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DB71A0495 for ; Wed, 23 Jul 2014 07:45:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN33015; Wed, 23 Jul 2014 14:45:18 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:45:18 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 22:45:13 +0800 From: Xuxiaohu To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoKZzKHOd1fHnEC4mx68Fzr5jZutun74 Date: Wed, 23 Jul 2014 14:45:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.221] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0DNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DpOIdQ9Ra2IDZNk9cvZqTgnV3Gk Subject: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwJcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:45:23 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0DNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpGdWxseSBhZ3JlZSB0aGF0IHRoZSBtZXRhZGF0YSByZWxhdGVkIGluZm9ybWF0 aW9uIGluY2x1ZGluZyB0aGUgY29udGV4dCBzaG91bGQgYmUgb3B0aW9uYWwsIHJhdGhlciB0aGFu IG1hbmRhdG9yeS4gSW4gYWRkaXRpb24sIEkgYmVsaWV2ZSB0aGUgc2VydmljZSBwYXRoIGhlYWRl ciBzaG91bGQgYWxzbyBiZSBvcHRpb25hbCwgaW4gb3RoZXIgd29yZHMsIHRoZSBOU0ggaXMgb25s eSB1c2VkIGZvciBjYXJyaW5nIHRoZSBtZXRhZGF0YSByZWxhdGVkIGluZm9ybWF0aW9uLg0KDQoN Cg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7Iyzogc2ZjIFtzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBEb2xnYW5vdywg QW5kcmV3IChBbmRyZXcpIFthbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tXQ0Kt6LL zcqxvOQ6IDIwMTTE6jfUwjIzyNUgMjI6MzANCsrVvP7Iyzogc2ZjQGlldGYub3JnDQrW98ziOiBb c2ZjXSBDaGFuZ2UgdG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9w dGlvbmFsIHByZXNlbmNlDQoNCkZvbGxvd2luZyBkaXNjdXNzaW9uIGR1cmluZyB0aGUgbWVldGlu ZyB0b2RheSwgaGVyZSBpcyBhIHNwZWNpZmljIGNvbW1lbnQgb24gaG93IHRvIENoYW5nZSBOU0gg dG8gYWxsb3cgY29uc3RhbnQtc2l6ZSwgZWFzeS10by1wcm9jZXNzIGluIEgvVyBDb250ZXh0IEhl YWRlciB3aGlsZSBhbHNvIGFsbG93aW5nIGZvciBkZXBsb3ltZW50cyB0aGF0IGRvIG5vdCBuZWVk IHRvIGluY2x1ZGUgdGhlIGhlYWRlcjoNCg0KDQogIDEuICBLZWVwIGV4aXN0aW5nIGZvcm1hdCBh cyBwZXIgZHJhZnQgc2VjdGlvbiA2IGJ1dCByZW5hbWUgZnJvbSBNYW5kYXRvcnkgQ29udGV4dCBI ZWFkZXIgdG8gQ29udGV4dCBIZWFkZXINCiAgMi4gIE1ha2UgdGhlIHByZXNlbmNlIG9mIGhlYWRl ciBvcHRpb25hbCBhbmQgZW5jb2RlIHByZXNlbmNlL2Fic2VuY2UgdXNpbmcgIGEgYml0IGluIEJh c2UgaGVhZGVyIKhDIHByb3Bvc2VkIGNoYW5nZSB0ZXh0IChpbiByZWQpOg0KDQogICAgICAwIDEg MiAzICA0ICA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgICArLSstKy0rLSstLS0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHxWZXJ8T3xDfENIUHxSfFJ8UnxSfFJ8ICAgTGVu Z3RoICB8ICAgIE1EIFR5cGUgICAgfCBOZXh0IFByb3RvY29sIHwNCiAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0K DQpDSFAgqENDb250ZXh0IEhlYWRlciBQcmVzZW50LiBJZiBzcGVjaWZpZWQsIENvbnRleHQgSGVh ZGVyIGFzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDUgYmVsb3cgIGZvbGxvd3MgZGlyZWN0bHkgU2Vy dmljZSBQYXRoIEhlYWRlcg0KDQpBbmRyZXcNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0DNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

Fully agree that the metadata related information including the context = should be optional, rather than mandatory. In addition, I believe the servi= ce path header should also be optional, in other words, the NSH is only use= d for carring the metadata related information.

 

Best regards,

Xiaohu

=B7=A2=BC=FE=C8=CB: sfc [sfc-bounces@ietf.= org] =B4=FA=B1=ED Dolganow, Andrew (Andrew) [andrew.dolganow@alcatel-lucent= .com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5 22:30
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Change to Mandatory Context Header in NSH draft = - optional presence

Following discussion during the meeting today, here is a specific comm= ent on how to Change NSH to allow constant-size, easy-to-process in H/W Con= text Header while also allowing for deployments that do not need to include= the header:

  1. Keep existing format as per draft section 6 but rename from Mandatory C= ontext Header to Context Header 
  2. Make the presence of header optional and encode presence/absence u= sing  a bit in Base header =A8C proposed change text (in red):
    3.       0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 =
7 8 9 0 1
     +-+-+-+-+---+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+
     |Ver|O|C|CHP|R|R|R|R|R|   Length  |    =
MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+

    CHP =A8CContext Header Present. If specified, = Context Header as specified in section 5 below  follows directly Servi= ce Path Header

Andrew

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0DNKGEML512MBSchi_-- From nobody Wed Jul 23 07:49: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 D40C71B29CE for ; Wed, 23 Jul 2014 07:48:59 -0700 (PDT) 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 olwVGtlZYbzt for ; Wed, 23 Jul 2014 07:48:58 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F751B27D1 for ; Wed, 23 Jul 2014 07:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id E4EAED554A6; Wed, 23 Jul 2014 07:48:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from dhcp-bb48.meeting.ietf.org (dhcp-bb48.meeting.ietf.org [31.133.187.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 2302DD40613; Wed, 23 Jul 2014 07:48:54 -0700 (PDT) Message-ID: <53CFCB55.4040408@joelhalpern.com> Date: Wed, 23 Jul 2014 10:48:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qVwzXjqhw41vh52CFGsNyW51jWk Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:49:00 -0000 I had read the MD-type as doing exactly this. So we should simply allocate an MD Type that means "no mandatory header." Yours, Joel On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: > Following discussion during the meeting today, here is a specific > comment on how to Change NSH to allow constant-size, easy-to-process in > H/W Context Header while also allowing for deployments that do not need > to include the header: > > 1. Keep existing format as per draft section 6 but rename from > Mandatory Context Header to Context Header > 2. Make the presence of header optional and encode presence/absence > using a bit in Base header – proposed change text (in red): > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > CHP –Context Header Present. If specified, Context Header as specified > in section 5 below follows directly Service Path Header > > Andrew > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 23 07:50: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 9F1FF1B2A1D for ; Wed, 23 Jul 2014 07:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 8XgzyVIK9rBl for ; Wed, 23 Jul 2014 07:50:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C791B29F6 for ; Wed, 23 Jul 2014 07:50:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN33378; Wed, 23 Jul 2014 14:50:04 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:50:03 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 22:49:57 +0800 From: Xuxiaohu To: "Henderickx, Wim (Wim)" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoM99gHcgYqlqk6zE24/qgQBr5utvK74 Date: Wed, 23 Jul 2014 14:49:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D1C@NKGEML512-MBS.china.huawei.com> References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.221] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D1CNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0wdB_k45GElJ-5VoRViGOAo1xH4 Subject: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:50:10 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D1CNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHNmYyBbc2ZjLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gSGVuZGVyaWNreCwgV2ltIChXaW0pIFt3aW0uaGVuZGVyaWNr eEBhbGNhdGVsLWx1Y2VudC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjPI1SAyMjozNA0KytW8 /sjLOiBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBzZmNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBb c2ZjXSBDaGFuZ2UgdG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9w dGlvbmFsIHByZXNlbmNlDQoNCkkgYWdyZWUgd2Ugc2hvdWxkIGtlZXAgdGhlIGhlYWRlciBhcyBz bWFsbCBhcyBwb3NzaWJsZSBhbmQgYXMgc3VjaCBJIGFsc28gYmVsaWV2ZSB3ZSBkb26hr3QgbmVl ZCB0aGUgbWFuZGF0b3J5IEN0eHQgZmllbGQgdG8gYmUgcHJlc2VudC4NCkFuIGFsdGVybmF0aXZl IHRvIHRoZSBDSFAgYml0IGNvdWxkIGJlIHRvIHVzZSBsZW5ndGggb3IgTUQtVHlwZSB0byBpbmRp Y2F0ZSBpdHMgcHJlc2VuY2UuDQoNCltYaWFvaHVdIEdyZWF0LiBVc2luZyB0aGUgTUQgVHlwZSBm aWVsZCB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2Ygc2VydmljZSBwYXRoIGhlYWRlciwgbWV0 YWRhdGEsIG9yICBib3RoIGhhcyBiZWVuIG1lbnRpb25lZCBpbiB0aGlzIGVtYWlsIChodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDIxNzIuaHRtbCku DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpGcm9tOiA8RG9sZ2Fub3c+LCAiQW5kcmV3IChB bmRyZXcpIiA8YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86YW5kcmV3 LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXkgMjMgSnVseSAy MDE0IDEwOjMwDQpUbzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIENoYW5nZSB0byBN YW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2UN Cg0KRm9sbG93aW5nIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBtZWV0aW5nIHRvZGF5LCBoZXJlIGlz IGEgc3BlY2lmaWMgY29tbWVudCBvbiBob3cgdG8gQ2hhbmdlIE5TSCB0byBhbGxvdyBjb25zdGFu dC1zaXplLCBlYXN5LXRvLXByb2Nlc3MgaW4gSC9XIENvbnRleHQgSGVhZGVyIHdoaWxlIGFsc28g YWxsb3dpbmcgZm9yIGRlcGxveW1lbnRzIHRoYXQgZG8gbm90IG5lZWQgdG8gaW5jbHVkZSB0aGUg aGVhZGVyOg0KDQoNCiAgMS4gIEtlZXAgZXhpc3RpbmcgZm9ybWF0IGFzIHBlciBkcmFmdCBzZWN0 aW9uIDYgYnV0IHJlbmFtZSBmcm9tIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlciB0byBDb250ZXh0 IEhlYWRlcg0KICAyLiAgTWFrZSB0aGUgcHJlc2VuY2Ugb2YgaGVhZGVyIG9wdGlvbmFsIGFuZCBl bmNvZGUgcHJlc2VuY2UvYWJzZW5jZSB1c2luZyAgYSBiaXQgaW4gQmFzZSBoZWFkZXIgqEMgcHJv cG9zZWQgY2hhbmdlIHRleHQgKGluIHJlZCk6DQoNCiAgICAgIDAgMSAyIDMgIDQgIDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICstKy0r LSstKy0tLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgfFZlcnxPfEN8Q0hQfFJ8UnxSfFJ8UnwgICBMZW5ndGggIHwgICAgTUQgVHlw ZSAgICB8IE5leHQgUHJvdG9jb2wgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCkNIUCCoQ0NvbnRleHQg SGVhZGVyIFByZXNlbnQuIElmIHNwZWNpZmllZCwgQ29udGV4dCBIZWFkZXIgYXMgc3BlY2lmaWVk IGluIHNlY3Rpb24gNSBiZWxvdyAgZm9sbG93cyBkaXJlY3RseSBTZXJ2aWNlIFBhdGggSGVhZGVy DQoNCkFuZHJldw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D1CNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

=B7=A2=BC=FE=C8=CB: sfc [sfc-bounces@ietf.= org] =B4=FA=B1=ED Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com]=
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5 22:34
=CA=D5=BC=FE=C8=CB: Dolganow, Andrew (Andrew); sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Change to Mandatory Context Header in NSH dr= aft - optional presence

I agree we should keep the header as small as possible and as such I a= lso believe we don=A1=AFt need the mandatory Ctxt field to be present.
An alternative to the CHP bit could be to use length or MD-Type to ind= icate its presence. 
 
[Xiaohu] Great. Using the MD Type field to indicate the presence of se= rvice path header, metadata, or  both has been mentioned in this = email (http://www.ietf.org/mail-archive/web/sfc/current/msg02172.html).
 
Best regards,
Xiaohu

From: <Dolganow>, "Andr= ew (Andrew)" <andrew.dolganow@alcatel-lucent.com>
Date: Wednesday 23 July 2014 10:30=
To: "sfc@ietf.org" <sfc@ietf.org>
Subject: [sfc] Change to Mandatory= Context Header in NSH draft - optional presence

Following discussion during the meeting today, here is a specific comm= ent on how to Change NSH to allow constant-size, easy-to-process in H/W Con= text Header while also allowing for deployments that do not need to include= the header:

  1. Keep existing format as per draft section 6 but rename from Mandatory C= ontext Header to Context Header 
  2. Make the presence of header optional and encode presence/absence u= sing  a bit in Base header =A8C proposed change text (in red):
    3.       0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 =
7 8 9 0 1
     +-+-+-+-+---+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+
     |Ver|O|C|CHP|R|R|R|R|R|   Length  |    =
MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+

    CHP =A8CContext Header Present. If specified, = Context Header as specified in section 5 below  follows directly Servi= ce Path Header

Andrew

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D1CNKGEML512MBSchi_-- From nobody Wed Jul 23 07:50: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 AE5A91B29CE for ; Wed, 23 Jul 2014 07:50:39 -0700 (PDT) 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 wpQINgeCl_Ug for ; Wed, 23 Jul 2014 07:50:38 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F681B2A03 for ; Wed, 23 Jul 2014 07:50:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id E59241C8C977; Wed, 23 Jul 2014 07:50:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from dhcp-bb48.meeting.ietf.org (dhcp-bb48.meeting.ietf.org [31.133.187.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 7068F1C8C974; Wed, 23 Jul 2014 07:50:37 -0700 (PDT) Message-ID: <53CFCBBC.1050708@joelhalpern.com> Date: Wed, 23 Jul 2014 10:50:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" References: <53CFCB55.4040408@joelhalpern.com> In-Reply-To: <53CFCB55.4040408@joelhalpern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/4pzSs7x1wXdygIEE565oZBHCmsk Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:50:39 -0000 Clarification, not "none", but "only SFP ID + SFP Index present." Yours, Joel On 7/23/14, 10:48 AM, Joel M. Halpern wrote: > I had read the MD-type as doing exactly this. So we should simply > allocate an MD Type that means "no mandatory header." > > Yours, > Joel > > On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >> Following discussion during the meeting today, here is a specific >> comment on how to Change NSH to allow constant-size, easy-to-process in >> H/W Context Header while also allowing for deployments that do not need >> to include the header: >> >> 1. Keep existing format as per draft section 6 but rename from >> Mandatory Context Header to Context Header >> 2. Make the presence of header optional and encode presence/absence >> using a bit in Base header – proposed change text (in red): >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> CHP –Context Header Present. If specified, Context Header as specified >> in section 5 below follows directly Service Path Header >> >> Andrew >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 23 07:54: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 80DF31B27B7 for ; Wed, 23 Jul 2014 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 OwBtmCQ_o_tS for ; Wed, 23 Jul 2014 07:54:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557DC1A0495 for ; Wed, 23 Jul 2014 07:54:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL39359; Wed, 23 Jul 2014 14:54:09 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:54:08 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 07:53:56 -0700 From: Lucy yong To: "Joel M. Halpern" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVK8qun5O3hbkONXzULFkEs+puuMzoA//+L5yA= Date: Wed, 23 Jul 2014 14:53:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> In-Reply-To: <53CFCBBC.1050708@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pum-mCdC32igTjGNiDQElgUxOW8 Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:54:12 -0000 We also need the option in header where only metadata present, i.e. no SFP = ID + Index present. Lucy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 23, 2014 9:51 AM To: Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence Clarification, not "none", but "only SFP ID + SFP Index present." Yours, Joel On 7/23/14, 10:48 AM, Joel M. Halpern wrote: > I had read the MD-type as doing exactly this. So we should simply=20 > allocate an MD Type that means "no mandatory header." > > Yours, > Joel > > On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >> Following discussion during the meeting today, here is a specific=20 >> comment on how to Change NSH to allow constant-size, easy-to-process=20 >> in H/W Context Header while also allowing for deployments that do not=20 >> need to include the header: >> >> 1. Keep existing format as per draft section 6 but rename from >> Mandatory Context Header to Context Header 2. Make the presence=20 >> of header optional and encode presence/absence >> using a bit in Base header - proposed change text (in red): >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + >> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol = | >> =20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> CHP -Context Header Present. If specified, Context Header as=20 >> specified in section 5 below follows directly Service Path Header >> >> Andrew >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 07:57: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 D7FD01B28CB for ; Wed, 23 Jul 2014 07:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.75 X-Spam-Level: * X-Spam-Status: No, score=1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0irvUFcq8N2k for ; Wed, 23 Jul 2014 07:57:48 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9831B28C4 for ; Wed, 23 Jul 2014 07:57:47 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 76dcfc35.2b1fb608f940.3596619.00-2461.10022556.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 23 Jul 2014 14:57:43 +0000 (UTC) X-MXL-Hash: 53cfcd675282ec89-e6dcda6b340a683acbf04c2d48c8a12f2d2bf843 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 35dcfc35.0.3596413.00-2240.10021949.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 23 Jul 2014 14:57:25 +0000 (UTC) X-MXL-Hash: 53cfcd551c0c2431-1a52b4c7422c83c8538afc8dcd9a49841ad69e54 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6NEvQSa012543; Wed, 23 Jul 2014 10:57:27 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6NEvF3C012354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 10:57:21 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Jul 2014 14:56:53 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 10:56:53 -0400 From: "NAPIERALA, MARIA H" To: Xuxiaohu , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFk?= =?gb2312?Q?er_in_NSH_draft_-_optional=09presence?= Thread-Index: AQHPpoTAX4IQUDhXLEy5zwSgXKX+f5utv0/Q Date: Wed, 23 Jul 2014 14:56:52 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1MISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Tf4hQ2sh c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=6wLx3WpyTnIA:10 a=ofMgfj31e3cA:10 a=jPJDawAOAc8A:10 a=a6l] X-AnalysisOut: [YbgGDhh4A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=9e5zr8Vsu5HpF3g] X-AnalysisOut: [FbxQA:9 a=mFyHDrcPJccA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA] X-AnalysisOut: [:10 a=Tcq1PRizppYA:10 a=IwBL9yMKFGHOOUi_:21 a=9FHOENQVlTbN] X-AnalysisOut: [Jixm:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=J8u8s-0B_rkOD6] X-AnalysisOut: [4xpm0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0] X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=l5sMVIBZFbk4dBnS:21 a=_MT2TFvh0P9] X-AnalysisOut: [f1tUk:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/r0Mmg_OybS3lqCORL6PSf4PQM44 Subject: Re: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwJcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:57:51 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1MISOUT7MSGUSRCF_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzLCBpdCBzaG91bGQgYmUgYW4gb3B0aW9uIHRvIGNhcnJ5IG9ubHkgbWV0YWRhdGEgYnV0IG5v dCB0aGUgU0ZQIGluZm9ybWF0aW9uLg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMs IDIwMTQgMTA6NDUgQU0NClRvOiBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBzZmNAaWV0Zi5v cmcNClN1YmplY3Q6IFtzZmNdILTwuLQ6IENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFk ZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2UNCg0KDQpIaSwNCg0KDQoNCkZ1bGx5 IGFncmVlIHRoYXQgdGhlIG1ldGFkYXRhIHJlbGF0ZWQgaW5mb3JtYXRpb24gaW5jbHVkaW5nIHRo ZSBjb250ZXh0IHNob3VsZCBiZSBvcHRpb25hbCwgcmF0aGVyIHRoYW4gbWFuZGF0b3J5LiBJbiBh ZGRpdGlvbiwgSSBiZWxpZXZlIHRoZSBzZXJ2aWNlIHBhdGggaGVhZGVyIHNob3VsZCBhbHNvIGJl IG9wdGlvbmFsLCBpbiBvdGhlciB3b3JkcywgdGhlIE5TSCBpcyBvbmx5IHVzZWQgZm9yIGNhcnJp bmcgdGhlIG1ldGFkYXRhIHJlbGF0ZWQgaW5mb3JtYXRpb24uDQoNCg0KDQpCZXN0IHJlZ2FyZHMs DQoNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBz ZmMgW3NmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERvbGdhbm93LCBBbmRyZXcgKEFuZHJldykg W2FuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb21dDQq3osvNyrG85DogMjAxNMTqN9TC MjPI1SAyMjozMA0KytW8/sjLOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCtb3 zOI6IFtzZmNdIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgaW4gTlNIIGRyYWZ0 IC0gb3B0aW9uYWwgcHJlc2VuY2UNCkZvbGxvd2luZyBkaXNjdXNzaW9uIGR1cmluZyB0aGUgbWVl dGluZyB0b2RheSwgaGVyZSBpcyBhIHNwZWNpZmljIGNvbW1lbnQgb24gaG93IHRvIENoYW5nZSBO U0ggdG8gYWxsb3cgY29uc3RhbnQtc2l6ZSwgZWFzeS10by1wcm9jZXNzIGluIEgvVyBDb250ZXh0 IEhlYWRlciB3aGlsZSBhbHNvIGFsbG93aW5nIGZvciBkZXBsb3ltZW50cyB0aGF0IGRvIG5vdCBu ZWVkIHRvIGluY2x1ZGUgdGhlIGhlYWRlcjoNCg0KDQogIDEuICBLZWVwIGV4aXN0aW5nIGZvcm1h dCBhcyBwZXIgZHJhZnQgc2VjdGlvbiA2IGJ1dCByZW5hbWUgZnJvbSBNYW5kYXRvcnkgQ29udGV4 dCBIZWFkZXIgdG8gQ29udGV4dCBIZWFkZXINCiAgMi4gIE1ha2UgdGhlIHByZXNlbmNlIG9mIGhl YWRlciBvcHRpb25hbCBhbmQgZW5jb2RlIHByZXNlbmNlL2Fic2VuY2UgdXNpbmcgIGEgYml0IGlu IEJhc2UgaGVhZGVyIKhDIHByb3Bvc2VkIGNoYW5nZSB0ZXh0IChpbiByZWQpOg0KDQogICAgICAw IDEgMiAzICA0ICA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KDQogICAgICstKy0rLSstKy0tLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICB8VmVyfE98Q3xDSFB8UnxSfFJ8UnxS fCAgIExlbmd0aCAgfCAgICBNRCBUeXBlICAgIHwgTmV4dCBQcm90b2NvbCB8DQoNCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KQ0hQIKhDQ29udGV4dCBIZWFkZXIgUHJlc2VudC4gSWYgc3BlY2lmaWVkLCBDb250 ZXh0IEhlYWRlciBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1IGJlbG93ICBmb2xsb3dzIGRpcmVj dGx5IFNlcnZpY2UgUGF0aCBIZWFkZXINCg0KQW5kcmV3DQoNCg== --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1MISOUT7MSGUSRCF_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yes, it should be an o= ption to carry only metadata but not the SFP information.=

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Wednesday, July 23, 2014 10:45 AM
To: Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: [sfc] =B4=F0=B8=B4: Change to Mandatory C= ontext Header in NSH draft - optional presence

 

Hi,

 

Fully agree that the metadata related informatio= n including the context should be optional, rather than mandatory. In addit= ion, I believe the service path header should also be optional, in other words, the NSH is only used for carring the metada= ta related information.

 

Best regards,

Xiaohu

=B7=A2=BC=FE= =C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED Dolganow, Andrew (Andrew) [andrew.dolganow@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Change to Mandatory Context Header in NSH draft - optional presence<= /span>

Following discussion during the meeting t= oday, here is a specific comment on how to Change NSH to allow constant-siz= e, easy-to-process in H/W Context Header while also allowing for deployments that do not need to include the header:<= /p>

 

  1. K= eep existing format as per draft section 6 but rename from Mandatory Contex= t Header to Context Header 
  2. M= ake the presence of header optional and encode presence/absence using  = ;a bit in Base header =A8C proposed change text (in red):= 
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+---+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |Ver|O|C|CHP|R|R|R|=
R|R|   Length  |    MD Type   =
 | Next Protocol |
     +-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;

 

CHP =A8CContext Header Present. If specifie= d, Context Header as specified in section 5 below  follows directly Se= rvice Path Header

 

Andrew<= /p>

 

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1MISOUT7MSGUSRCF_-- From nobody Wed Jul 23 07:58: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 A74DF1B2A6B for ; Wed, 23 Jul 2014 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 SdSQIelqhaBd for ; Wed, 23 Jul 2014 07:58:43 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289F01B28C8 for ; Wed, 23 Jul 2014 07:58:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208,217";a="122814424" X-IPAS-Result: AqIEADD7RVPAqArr/2dsb2JhbABZgkKBVsQTgTd0giUBAQEBA4EJAgEIEQECAQIoBzIUAwYIAgQBEtQZF45bGIQ4BK5Qgis Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 23 Jul 2014 14:58:33 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 07:58:32 -0700 From: Sumandra Majee To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoaStVnxDblMPkqv0Un8DuCBjg== Date: Wed, 23 Jul 2014 14:58:32 +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: [172.18.40.2] Content-Type: multipart/alternative; boundary="_000_CFF54494253BDsmajeef5com_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nvK6MSNbajxUW5Lo6ObyNqTTr1U Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 14:58:47 -0000 --_000_CFF54494253BDsmajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Generally agree. But at this point this could be very well be TLV., mandoto= ry TLV. However I would stress that an appropriate document ( use case/architecture= ) actually captures the relevant required metadata for common use cases. A) Subscriber ID in Gi LAN B) Classification results C) ?? Sumandra From: , "Andrew (Andrew)" > Date: Wednesday, July 23, 2014 at 10:30 AM To: "sfc@ietf.org" > Subject: [sfc] Change to Mandatory Context Header in NSH draft - optional p= resence Following discussion during the meeting today, here is a specific comment o= n how to Change NSH to allow constant-size, easy-to-process in H/W Context = Header while also allowing for deployments that do not need to include the = header: 1. Keep existing format as per draft section 6 but rename from Mandatory= Context Header to Context Header 2. Make the presence of header optional and encode presence/absence usin= g a bit in Base header =96 proposed change text (in red): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CHP =96Context Header Present. If specified, Context Header as specified in= section 5 below follows directly Service Path Header Andrew --_000_CFF54494253BDsmajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Generally agree. But at this point this could be very well be TLV., ma= ndotory TLV.  

However I would stress that an appropriate document ( use case/archite= cture  ) actually captures the relevant required metadata for common u= se cases.
  A) Subscriber ID in Gi LAN
  B) Classification results 
  C) ??

Sumandra



From: <Dolganow>, "Andre= w (Andrew)" <= andrew.dolganow@alcatel-lucent.com>
Date: Wednesday, July 23, 2014 at 1= 0:30 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Change to Mandatory = Context Header in NSH draft - optional presence

Following discussion during the meeting today, here is a specific comm= ent on how to Change NSH to allow constant-size, easy-to-process in H/W Con= text Header while also allowing for deployments that do not need to include= the header:

  1. Keep existing format as per draft section 6 but rename from Mandatory C= ontext Header to Context Header 
  2. Make the presence of hea= der optional and encode presence/absence using  a bit in Base header = =96 proposed change text (in red):
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=
 7 8 9 0 1
     +-+-+-+-+---+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+
     |Ver|O|C|CHP|R|R|R|R|R|   Length  |    =
MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+

CHP =96Context Header Present. If specified, C= ontext Header as specified in section 5 below  follows directly Servic= e Path Header

Andrew

 --_000_CFF54494253BDsmajeef5com_-- From nobody Wed Jul 23 08:00: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 B79A51B2A8F for ; Wed, 23 Jul 2014 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.05 X-Spam-Level: **** X-Spam-Status: No, score=4.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 BjlhG-XYqOkK for ; Wed, 23 Jul 2014 08:00:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E821B28C8 for ; Wed, 23 Jul 2014 08:00:07 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-1b-53cf788d80e1 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A5.C0.25146.D887FC35; Wed, 23 Jul 2014 10:55:41 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 11:00:00 -0400 From: Eric Gray To: "NAPIERALA, MARIA H" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFk?= =?gb2312?Q?er_in_NSH_draft_-_optional=09presence?= Thread-Index: AQHPpoTDbKi2y6CJ0Um5GbblKPa225uuArEA//+90lI= Date: Wed, 23 Jul 2014 14:59:59 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1@MISOUT7MSGUSRCF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E3C85E5EA14A4D2EA54F597678A102D2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLrHW7e34nywweFvqhbrX+5hsdg4uY3R 4smDrewWW8+vYnRg8Wh9tpfV42X/HEaPliNvWT2WLPnJFMASxWWTkpqTWZZapG+XwJWx9OVF xoJZDYwVzZ8fsDcw/ivtYuTkkBAwkbj0fRMbhC0mceHeeiCbi0NI4CijxJ0Hr5khnOWMEoen rGECqWIT0JA4dmctI4gtIqAp8ffcfkaQImaBVkaJPRPnsII4wgLdjBJdByaAzRIR6GGU+DXz OBtEi5XE7dZ/YKNYBFQlPjzYBxbnFbCXOPF7IwvEvpuMEr//vWYBSXAKREmsXDMPrIgR6MLv pyDuYBYQl7j1ZD4TxOUCEkv2nGeGsEUlXj7+B3QGB1BNssSPncYQ8wUlTs58wjKBUWQWku5Z CFWzkFRBlGhJzGv4zQRhK0pM6X7IDmFrSlyZfAjK1pZYtvA18wJG9lWMHKXFqWW56UaGmxiB 0XZMgs1xB+OCT5aHGAU4GJV4eBXMzgULsSaWFVfmHmKU5mBREufVrJ4XLCSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoFxVvOMmpt+l59UCGd9y17/oPbmpqyMBqZZJmd0wp7qTfnPp1n+ffXK hS8vriiY91jzq89ikaCKZm0fw9na9U7/T3jO/FTbqhv3IUvKvV7o3rz1XAosv1ecnzwx7dUu SRZmp29B278rXNrQx771gOWBPW9951XPtTqvtqb0/VKzD+oOL9rMmy23KLEUZyQaajEXFScC AKWMXAeXAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7tM3eay_iLl3ZNnoe5WpwkC99wU Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" Subject: Re: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwJcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:00:08 -0000 --_000_E3C85E5EA14A4D2EA54F597678A102D2ericssoncom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TWFyaWEvTHVjeS9ldGMuDQoNCkNhbiB5b3UgY2xhcmlmeSB3aGF0IG1ldGEtZGF0YSB0aGVyZSB3 b3VsZCBiZSBiZXlvbmQgU0ZQIGluZm9ybWF0aW9uPw0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpP biBKdWwgMjMsIDIwMTQsIGF0IDEwOjU4IEFNLCAiTkFQSUVSQUxBLCBNQVJJQSBIIiA8bW4xOTIx QGF0dC5jb208bWFpbHRvOm1uMTkyMUBhdHQuY29tPj4gd3JvdGU6DQoNClllcywgaXQgc2hvdWxk IGJlIGFuIG9wdGlvbiB0byBjYXJyeSBvbmx5IG1ldGFkYXRhIGJ1dCBub3QgdGhlIFNGUCBpbmZv cm1hdGlvbi4NCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBYdXhpYW9odQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjQ1IEFN DQpUbzogRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSC08Li0OiBDaGFuZ2UgdG8gTWFuZGF0b3J5IENvbnRl eHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNlbmNlDQoNCg0KSGksDQoNCg0K DQpGdWxseSBhZ3JlZSB0aGF0IHRoZSBtZXRhZGF0YSByZWxhdGVkIGluZm9ybWF0aW9uIGluY2x1 ZGluZyB0aGUgY29udGV4dCBzaG91bGQgYmUgb3B0aW9uYWwsIHJhdGhlciB0aGFuIG1hbmRhdG9y eS4gSW4gYWRkaXRpb24sIEkgYmVsaWV2ZSB0aGUgc2VydmljZSBwYXRoIGhlYWRlciBzaG91bGQg YWxzbyBiZSBvcHRpb25hbCwgaW4gb3RoZXIgd29yZHMsIHRoZSBOU0ggaXMgb25seSB1c2VkIGZv ciBjYXJyaW5nIHRoZSBtZXRhZGF0YSByZWxhdGVkIGluZm9ybWF0aW9uLg0KDQoNCg0KQmVzdCBy ZWdhcmRzLA0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrei vP7Iyzogc2ZjIFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmc+XSC0+rHtIERvbGdhbm93LCBBbmRyZXcgKEFuZHJldykgW2FuZHJldy5kb2xnYW5vd0BhbGNh dGVsLWx1Y2VudC5jb208bWFpbHRvOmFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb20+ XQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjIzyNUgMjI6MzANCsrVvP7Iyzogc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQrW98ziOiBbc2ZjXSBDaGFuZ2UgdG8gTWFuZGF0b3J5IENvbnRl eHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNlbmNlDQpGb2xsb3dpbmcgZGlz Y3Vzc2lvbiBkdXJpbmcgdGhlIG1lZXRpbmcgdG9kYXksIGhlcmUgaXMgYSBzcGVjaWZpYyBjb21t ZW50IG9uIGhvdyB0byBDaGFuZ2UgTlNIIHRvIGFsbG93IGNvbnN0YW50LXNpemUsIGVhc3ktdG8t cHJvY2VzcyBpbiBIL1cgQ29udGV4dCBIZWFkZXIgd2hpbGUgYWxzbyBhbGxvd2luZyBmb3IgZGVw bG95bWVudHMgdGhhdCBkbyBub3QgbmVlZCB0byBpbmNsdWRlIHRoZSBoZWFkZXI6DQoNCg0KICAx LiAgS2VlcCBleGlzdGluZyBmb3JtYXQgYXMgcGVyIGRyYWZ0IHNlY3Rpb24gNiBidXQgcmVuYW1l IGZyb20gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIHRvIENvbnRleHQgSGVhZGVyDQogIDIuICBN YWtlIHRoZSBwcmVzZW5jZSBvZiBoZWFkZXIgb3B0aW9uYWwgYW5kIGVuY29kZSBwcmVzZW5jZS9h YnNlbmNlIHVzaW5nICBhIGJpdCBpbiBCYXNlIGhlYWRlciCoQyBwcm9wb3NlZCBjaGFuZ2UgdGV4 dCAoaW4gcmVkKToNCg0KICAgICAgMCAxIDIgMyAgNCAgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCg0KICAgICArLSstKy0rLSstLS0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAg fFZlcnxPfEN8Q0hQfFJ8UnxSfFJ8UnwgICBMZW5ndGggIHwgICAgTUQgVHlwZSAgICB8IE5leHQg UHJvdG9jb2wgfA0KDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCkNIUCCoQ0NvbnRleHQgSGVhZGVyIFByZXNl bnQuIElmIHNwZWNpZmllZCwgQ29udGV4dCBIZWFkZXIgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24g NSBiZWxvdyAgZm9sbG93cyBkaXJlY3RseSBTZXJ2aWNlIFBhdGggSGVhZGVyDQoNCkFuZHJldw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1h aWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_E3C85E5EA14A4D2EA54F597678A102D2ericssoncom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Maria/Lucy/etc.

Can you clarify what meta-data there would be beyond SFP information?<= br>
Sent from my iPad

On Jul 23, 2014, at 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Yes, it should be an o= ption to carry only metadata but not the SFP information.=

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Wednesday, July 23, 2014 10:45 AM
To: Dolganow, Andrew (Andrew); sfc@i= etf.org
Subject: [sfc] =B4=F0=B8=B4: Change to Mandatory C= ontext Header in NSH draft - optional presence

 

Hi,

 

Fully agree that the metadata related informatio= n including the context should be optional, rather than mandatory. In addit= ion, I believe the service path header should also be optional, in other words, the NSH is only used for carring the metada= ta related information.

 

Best regards,

Xiaohu

=B7=A2=BC=FE= =C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED Dolganow, Andrew (Andre= w) [andrew.dolganow@alc= atel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Change to Mandatory Context Header in NSH draft - optional presence<= /span>

Following discussion during the meeting t= oday, here is a specific comment on how to Change NSH to allow constant-siz= e, easy-to-process in H/W Context Header while also allowing for deployments that do not need to include the header:<= /p>

 

  1. K= eep existing format as per draft section 6 but rename from Mandatory Contex= t Header to Context Header 
  2. M= ake the presence of header optional and encode presence/absence using  = ;a bit in Base header =A8C proposed change text (in red):= 
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+---+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |Ver|O|C|CHP|R|R|R|=
R|R|   Length  |    MD Type   =
 | Next Protocol |
     +-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;

 

CHP =A8CContext Header Present. If specifie= d, Context Header as specified in section 5 below  follows directly Se= rvice Path Header

 

Andrew<= /p>

 

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_E3C85E5EA14A4D2EA54F597678A102D2ericssoncom_-- From nobody Wed Jul 23 08: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 5922A1B2AAA for ; Wed, 23 Jul 2014 08:00:18 -0700 (PDT) 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 Zl5GNF_KA41M for ; Wed, 23 Jul 2014 08:00:15 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12A81B2A90 for ; Wed, 23 Jul 2014 08:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 7BAB5D554D0; Wed, 23 Jul 2014 08:00:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from dhcp-bb48.meeting.ietf.org (dhcp-bb48.meeting.ietf.org [31.133.187.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id D96B3D40789; Wed, 23 Jul 2014 08:00:12 -0700 (PDT) Message-ID: <53CFCDFC.6020602@joelhalpern.com> Date: Wed, 23 Jul 2014 11:00:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lucy yong , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sycPsCu02i3y412o88vvtzcXLqM Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:00:18 -0000 We could allow the null case. But is there a significant advantage in omitting the SFP-ID + Path Inex, when it is not needed? WHen we get to the details of the solution behavior, I would like it to be clear that the index does not need to be updated if it is not being used. (i.e. what it indexes are the places that use the Path ID + index, which is well-defined.) But I don't mind having the 4 bytes there. It seems to significantly improve interoperability. Yours, Joel On 7/23/14, 10:53 AM, Lucy yong wrote: > We also need the option in header where only metadata present, i.e. no SFP ID + Index present. > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 23, 2014 9:51 AM > To: Dolganow, Andrew (Andrew); sfc@ietf.org > Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence > > Clarification, not "none", but "only SFP ID + SFP Index present." > > Yours, > Joel > > On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >> I had read the MD-type as doing exactly this. So we should simply >> allocate an MD Type that means "no mandatory header." >> >> Yours, >> Joel >> >> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>> Following discussion during the meeting today, here is a specific >>> comment on how to Change NSH to allow constant-size, easy-to-process >>> in H/W Context Header while also allowing for deployments that do not >>> need to include the header: >>> >>> 1. Keep existing format as per draft section 6 but rename from >>> Mandatory Context Header to Context Header 2. Make the presence >>> of header optional and encode presence/absence >>> using a bit in Base header - proposed change text (in red): >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> CHP -Context Header Present. If specified, Context Header as >>> specified in section 5 below follows directly Service Path Header >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 23 08:00: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 AED271B2AC5 for ; Wed, 23 Jul 2014 08:00:48 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 p_4EEMXvBkSG for ; Wed, 23 Jul 2014 08:00:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A648A1B2AC1 for ; Wed, 23 Jul 2014 08:00:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN34195; Wed, 23 Jul 2014 15:00:40 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:00:39 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 08:00:23 -0700 From: Lucy yong To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , Linda Dunbar , "sfc@ietf.org" Thread-Topic: Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCA= Date: Wed, 23 Jul 2014 15:00:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> In-Reply-To: <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.60] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453C2C2Fdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/IjGEB5eGoBomEHcl9jzarQG139w Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:00:49 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453C2C2Fdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda --_000_2691CE0099834E4A9C5044EEC662BB9D453C2C2Fdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How about:<= /span>

 

SFP is a path traversing a sequence of service functions in a SFC-enab= led domain. The path includes a sequence of SFFs and/or SFs that can be exp= licitly or loosely specified.  

 

Lucy

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, July 23, 2014 9:40 AM
To: Linda Dunbar; sfc@ietf.org
Subject: Re: [sfc] Simpler description of Service Function Path=

 

I would propose to do = it even simpler

Service Function Path = (SFP):

SFP is a path traversing a sequence of service functions in a SFC-enab= led domain. The path includes a sequence of SFFs and/or SFs that can be exp= licitly or loosely specified. In case of a loosely specification, at least the ingress and the egress SFFs and/o= r  SFs need to be specified.

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar
Sent: Wednesday, July 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Simpler description of Service Function Path

 

I think the SFP definition displayed at today SFC se= ssion is too complicated, more like lawyer’s wording than a term easi= ly understood by engineers (considering there are a lot of IETFers/engineer= s whose first language is not English).

 

Here is my suggested simpler wording:

 

Service Function Path (SFP):

SFP is a pathway traversing a sequence of service functions from ingress= to egress of the SFC-enabled domain, including sequence of SFFs and sequen= ce of SFs. This sequence can be specified precisely with exact sequence of SFFs and the sequence of SFs reached by e= ach SFF,  loosely specified with sets of SFFs/SFs, or somewhere in bet= ween.

 

Linda=

--_000_2691CE0099834E4A9C5044EEC662BB9D453C2C2Fdfweml701chmchi_-- From nobody Wed Jul 23 08:05: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 3880B1B2ACE for ; Wed, 23 Jul 2014 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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.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 u8jMqRTesHqX for ; Wed, 23 Jul 2014 08:05:07 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2601B2ADD for ; Wed, 23 Jul 2014 08:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1406127907; x=1437663907; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HW8nIxVRRnkNBBd4hf9vUgKGnaDBtNmhYDajF4uyBaE=; b=SkHdJPHmnGR8V4npq09x3h/6jnXai43qSjtB5dlr9BIhfzN15WG+MvOs Gmbd72DT7tNYZWMwMvHSbU9umFG2qxjKzbQuYprGITtuIkqYz+kUg7X+d YggBjH59yuF9lvQVFjNk/TnBEpQQzJ1+ysYUG14pzEmnlfIESHFdJRRt5 w=; X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="122917631" X-IPAS-Result: Aq8EAL3Oz1PAqArr/2dsb2JhbABZg2BXBMc/HAqHRQGBIXaEAwEBAQEDAQEBaxcEAgEIEQQBAQEnBycLFAkIAgQBEhuINMAeEwSPUgaEQAWKLakIbIFF Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 23 Jul 2014 15:04:47 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 23 Jul 2014 08:04:47 -0700 From: Sumandra Majee To: "Joel M. Halpern" , Lucy yong , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVBGLnCTbQ2Ike9bSjADbTpMpuuMzoAgAAA7YCAAAHCAP//vlAA Date: Wed, 23 Jul 2014 15:04:46 +0000 Message-ID: References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@joelhalpern.com> In-Reply-To: <53CFCDFC.6020602@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: [172.18.40.3] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53C7284E96E9B4428B6261E2A23AF92C@F5.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DhDk6f6am_dB5fioh9BP37XER84 Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:05:09 -0000 e could allow the null case. But is there a significant advantage in omitting the SFP-ID + Path Inex, when it is not needed? [SM] Flow aware devices may not need it on every packet. Since the draft doesn=B9t explicitly talk about pkt based vs. flow aware services, I would like to see the NULL case supported also. On 7/23/14, 11:00 AM, "Joel M. Halpern" wrote: >We could allow the null case. But is there a significant advantage in >omitting the SFP-ID + Path Inex, when it is not needed? > >WHen we get to the details of the solution behavior, I would like it to >be clear that the index does not need to be updated if it is not being >used. (i.e. what it indexes are the places that use the Path ID + >index, which is well-defined.) > >But I don't mind having the 4 bytes there. It seems to significantly >improve interoperability. > >Yours, >Joel > >On 7/23/14, 10:53 AM, Lucy yong wrote: >> We also need the option in header where only metadata present, i.e. no >>SFP ID + Index present. >> Lucy >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, July 23, 2014 9:51 AM >> To: Dolganow, Andrew (Andrew); sfc@ietf.org >> Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - >>optional presence >> >> Clarification, not "none", but "only SFP ID + SFP Index present." >> >> Yours, >> Joel >> >> On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >>> I had read the MD-type as doing exactly this. So we should simply >>> allocate an MD Type that means "no mandatory header." >>> >>> Yours, >>> Joel >>> >>> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>>> Following discussion during the meeting today, here is a specific >>>> comment on how to Change NSH to allow constant-size, easy-to-process >>>> in H/W Context Header while also allowing for deployments that do not >>>> need to include the header: >>>> >>>> 1. Keep existing format as per draft section 6 but rename from >>>> Mandatory Context Header to Context Header 2. Make the presence >>>> of header optional and encode presence/absence >>>> using a bit in Base header - proposed change text (in red): >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>0 1 >>>> =20 >>>>+-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next >>>>Protocol | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> CHP -Context Header Present. If specified, Context Header as >>>> specified in section 5 below follows directly Service Path Header >>>> >>>> Andrew >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 08:09: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 500E61B28F5 for ; Wed, 23 Jul 2014 08:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 917Tk00sp0n3 for ; Wed, 23 Jul 2014 08:09:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B251C1B27D1 for ; Wed, 23 Jul 2014 08:09:25 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6NF9Ngf001282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 10:09:24 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6NF9MWK000963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 11:09:23 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.218]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 11:09:22 -0400 From: "Dolganow, Andrew (Andrew)" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoKZzKHOd1fHnEC4mx68Fzr5jQ== Date: Wed, 23 Jul 2014 15:09:22 +0000 Message-ID: References: <53CFCB55.4040408@joelhalpern.com> In-Reply-To: <53CFCB55.4040408@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <25EEB18CFB27E8449630228E6FF5F93F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Kxc_uAAH9fWWWl3BHVX8G-xIQVY Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:09:27 -0000 The reason I am proposing to use reserved bit is that having 7 reserved bits seems an overkill (especially since we have version as well to evolve in the future). Alternatively we could shrink the number of reserved bits and allocate the freed-up bits to MD Type for example to allow more broad use of MD Type.=20 Andrew On 2014-07-23, 10:48 AM, "Joel M. Halpern" wrote: >I had read the MD-type as doing exactly this. So we should simply >allocate an MD Type that means "no mandatory header." > >Yours, >Joel > >On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >> Following discussion during the meeting today, here is a specific >> comment on how to Change NSH to allow constant-size, easy-to-process in >> H/W Context Header while also allowing for deployments that do not need >> to include the header: >> >> 1. Keep existing format as per draft section 6 but rename from >> Mandatory Context Header to Context Header >> 2. Make the presence of header optional and encode presence/absence >> using a bit in Base header =AD proposed change text (in red): >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> =20 >>+-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol >>| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> CHP =ADContext Header Present. If specified, Context Header as specified >> in section 5 below follows directly Service Path Header >> >> Andrew >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Wed Jul 23 08:10: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 3DBA61B2912 for ; Wed, 23 Jul 2014 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 DND7W7vgiuQy for ; Wed, 23 Jul 2014 08:10:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFD11B27D1 for ; Wed, 23 Jul 2014 08:10:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN34954; Wed, 23 Jul 2014 15:10:23 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:10:22 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 23:10:11 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Lucy yong , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVFEF6zK70v8ESVlSVcKDPl65utN8UAgAAA7YCAAAHCAIAAhzYY Date: Wed, 23 Jul 2014 15:10:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296E24@NKGEML512-MBS.china.huawei.com> References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com>, <53CFCDFC.6020602@joelhalpern.com> In-Reply-To: <53CFCDFC.6020602@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.221] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/KN2fJsIFJZI5j6Evj72PPMJ3T5w Subject: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:10:28 -0000 SU1ITywgdGhlIHNlcnZpY2UgaW5kZXggc2hvdWxkIGJlIG1lYW5pbmdmdWwgZXZlbiBpbiB0aGUg Y2FzZSB3aGVyZSBvbmx5IG1ldGFkYXRhIGlzIGNhcnJpZWQuIEZvciBpbnN0YW5jZSwgdGhhdCBp bmRleCBjb3VsZCBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgZW5kIG9mIHRoZSBjaGFpbiBvciBw YXRoIHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBzdHJpcHBpbmcgdGhlIG1ldGFkYXRhLiBJbiBv dGhlciB3b3JkLCB0aGUgc2VydmljZSBpbmRleCBzaG91bGQgYmUgZGVjb3VwbGVkIGZyb20gdGhl IHBhdGggaWQgYW5kIHRoZSBtZXRhZGF0YS4gTWF5YmUgdGhlIEJhc2UgaGVhZGVyIGlzIHRoZSBy aWdodCBwbGFjZSB0byBob2xkIHRoYXQgaW5kZXguIEFsdGVybmF0aXZlbHksIHRoZSBzZXJ2aWNl IHBhdGggaGVhZGVyIGNhbiBzdGlsbCBiZSByZW1haW5lZCBidXQgb25seSB0aGUgc2VydmljZSBp bmRleCBwYXJ0IHdvdWxkIGJlIHVzZWQgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHBhdGggb3IgY2hh aW4gaW5mb3JtYXRpb24gaGFzIGJlZW4gY2FycmllZCBzb21ld2hlcmUgZWxzZSBvdGhlciB0aGFu IHRoZSBzZXJ2aWNlIHBhdGggaGVhZGVyLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzogc2ZjIFtzZmMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBKb2VsIE0uIEhhbHBlcm4gW2ptaEBqb2VsaGFscGVybi5jb21d DQq3osvNyrG85DogMjAxNMTqN9TCMjPI1SAyMzowMA0KytW8/sjLOiBMdWN5IHlvbmc7IERvbGdh bm93LCBBbmRyZXcgKEFuZHJldyk7IHNmY0BpZXRmLm9yZw0K1vfM4jogUmU6IFtzZmNdIENoYW5n ZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJl c2VuY2UNCg0KV2UgY291bGQgYWxsb3cgdGhlIG51bGwgY2FzZS4gIEJ1dCBpcyB0aGVyZSBhIHNp Z25pZmljYW50IGFkdmFudGFnZSBpbg0Kb21pdHRpbmcgdGhlIFNGUC1JRCArIFBhdGggSW5leCwg d2hlbiBpdCBpcyBub3QgbmVlZGVkPw0KDQpXSGVuIHdlIGdldCB0byB0aGUgZGV0YWlscyBvZiB0 aGUgc29sdXRpb24gYmVoYXZpb3IsIEkgd291bGQgbGlrZSBpdCB0bw0KYmUgY2xlYXIgdGhhdCB0 aGUgaW5kZXggZG9lcyBub3QgbmVlZCB0byBiZSB1cGRhdGVkIGlmIGl0IGlzIG5vdCBiZWluZw0K dXNlZC4gIChpLmUuIHdoYXQgaXQgaW5kZXhlcyBhcmUgdGhlIHBsYWNlcyB0aGF0IHVzZSB0aGUg UGF0aCBJRCArDQppbmRleCwgd2hpY2ggaXMgd2VsbC1kZWZpbmVkLikNCg0KQnV0IEkgZG9uJ3Qg bWluZCBoYXZpbmcgdGhlIDQgYnl0ZXMgdGhlcmUuICBJdCBzZWVtcyB0byBzaWduaWZpY2FudGx5 DQppbXByb3ZlIGludGVyb3BlcmFiaWxpdHkuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA3LzIzLzE0 LCAxMDo1MyBBTSwgTHVjeSB5b25nIHdyb3RlOg0KPiBXZSBhbHNvIG5lZWQgdGhlIG9wdGlvbiBp biBoZWFkZXIgd2hlcmUgb25seSBtZXRhZGF0YSBwcmVzZW50LCBpLmUuIG5vIFNGUCBJRCArIElu ZGV4IHByZXNlbnQuDQo+IEx1Y3kNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2Vs IE0uIEhhbHBlcm4NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDk6NTEgQU0NCj4g VG86IERvbGdhbm93LCBBbmRyZXcgKEFuZHJldyk7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3NmY10gQ2hhbmdlIHRvIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlciBpbiBOU0ggZHJhZnQg LSBvcHRpb25hbCBwcmVzZW5jZQ0KPg0KPiBDbGFyaWZpY2F0aW9uLCBub3QgIm5vbmUiLCBidXQg Im9ubHkgU0ZQIElEICsgU0ZQIEluZGV4IHByZXNlbnQuIg0KPg0KPiBZb3VycywNCj4gSm9lbA0K Pg0KPiBPbiA3LzIzLzE0LCAxMDo0OCBBTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gSSBo YWQgcmVhZCB0aGUgTUQtdHlwZSBhcyBkb2luZyBleGFjdGx5IHRoaXMuICBTbyB3ZSBzaG91bGQg c2ltcGx5DQo+PiBhbGxvY2F0ZSBhbiBNRCBUeXBlIHRoYXQgbWVhbnMgIm5vIG1hbmRhdG9yeSBo ZWFkZXIuIg0KPj4NCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4NCj4+IE9uIDcvMjMvMTQsIDEwOjMw IEFNLCBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpIHdyb3RlOg0KPj4+IEZvbGxvd2luZyBkaXNj dXNzaW9uIGR1cmluZyB0aGUgbWVldGluZyB0b2RheSwgaGVyZSBpcyBhIHNwZWNpZmljDQo+Pj4g Y29tbWVudCBvbiBob3cgdG8gQ2hhbmdlIE5TSCB0byBhbGxvdyBjb25zdGFudC1zaXplLCBlYXN5 LXRvLXByb2Nlc3MNCj4+PiBpbiBIL1cgQ29udGV4dCBIZWFkZXIgd2hpbGUgYWxzbyBhbGxvd2lu ZyBmb3IgZGVwbG95bWVudHMgdGhhdCBkbyBub3QNCj4+PiBuZWVkIHRvIGluY2x1ZGUgdGhlIGhl YWRlcjoNCj4+Pg0KPj4+ICAgMS4gS2VlcCBleGlzdGluZyBmb3JtYXQgYXMgcGVyIGRyYWZ0IHNl Y3Rpb24gNiBidXQgcmVuYW1lIGZyb20NCj4+PiAgICAgIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRl ciB0byBDb250ZXh0IEhlYWRlciAgMi4gTWFrZSB0aGUgcHJlc2VuY2UNCj4+PiBvZiBoZWFkZXIg b3B0aW9uYWwgYW5kIGVuY29kZSBwcmVzZW5jZS9hYnNlbmNlDQo+Pj4gICAgICB1c2luZyAgYSBi aXQgaW4gQmFzZSBoZWFkZXIgLSBwcm9wb3NlZCBjaGFuZ2UgdGV4dCAoaW4gcmVkKToNCj4+Pg0K Pj4+ICAgICAgICAgMCAxIDIgMyAgNCAgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCj4+PiAgICAgICAgKy0rLSstKy0rLS0tKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4+ICAgICAgICB8 VmVyfE98Q3xDSFB8UnxSfFJ8UnxSfCAgIExlbmd0aCAgfCAgICBNRCBUeXBlICAgIHwgTmV4dCBQ cm90b2NvbCB8DQo+Pj4NCj4+PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPj4+DQo+Pj4NCj4+PiBDSFAgLUNvbnRleHQg SGVhZGVyIFByZXNlbnQuIElmIHNwZWNpZmllZCwgQ29udGV4dCBIZWFkZXIgYXMNCj4+PiBzcGVj aWZpZWQgaW4gc2VjdGlvbiA1IGJlbG93ICBmb2xsb3dzIGRpcmVjdGx5IFNlcnZpY2UgUGF0aCBI ZWFkZXINCj4+Pg0KPj4+IEFuZHJldw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlz dA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM= From nobody Wed Jul 23 08:10: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 721FC1B27D1 for ; Wed, 23 Jul 2014 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 H3QGkhcmIl0c for ; Wed, 23 Jul 2014 08:10:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2421B2912 for ; Wed, 23 Jul 2014 08:10:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL40694; Wed, 23 Jul 2014 15:10:50 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:10:49 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 08:10:38 -0700 From: Cathy Zhang To: "Joel M. Halpern" , Lucy yong , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVHdundES31ZUOXHbeg3m3/YJuuMzoAgAAA7YCAAAHCAP//jB5A Date: Wed, 23 Jul 2014 15:10:38 +0000 Message-ID: References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@joelhalpern.com> In-Reply-To: <53CFCDFC.6020602@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_0xjc-UhvVOsnwsRZdSylGIca0Y Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:10:53 -0000 I agree with Joel. For better interoperability, we can just keep the 4 byte= s and set them to 0 to indicate "only metadata present". Actually "only met= adata present" is addressed in SCH header draft presented in today's meetin= g.=20 Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 23, 2014 8:00 AM To: Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence We could allow the null case. But is there a significant advantage in=20 omitting the SFP-ID + Path Inex, when it is not needed? WHen we get to the details of the solution behavior, I would like it to=20 be clear that the index does not need to be updated if it is not being=20 used. (i.e. what it indexes are the places that use the Path ID +=20 index, which is well-defined.) But I don't mind having the 4 bytes there. It seems to significantly=20 improve interoperability. Yours, Joel On 7/23/14, 10:53 AM, Lucy yong wrote: > We also need the option in header where only metadata present, i.e. no SF= P ID + Index present. > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 23, 2014 9:51 AM > To: Dolganow, Andrew (Andrew); sfc@ietf.org > Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - opti= onal presence > > Clarification, not "none", but "only SFP ID + SFP Index present." > > Yours, > Joel > > On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >> I had read the MD-type as doing exactly this. So we should simply >> allocate an MD Type that means "no mandatory header." >> >> Yours, >> Joel >> >> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>> Following discussion during the meeting today, here is a specific >>> comment on how to Change NSH to allow constant-size, easy-to-process >>> in H/W Context Header while also allowing for deployments that do not >>> need to include the header: >>> >>> 1. Keep existing format as per draft section 6 but rename from >>> Mandatory Context Header to Context Header 2. Make the presence >>> of header optional and encode presence/absence >>> using a bit in Base header - proposed change text (in red): >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 >>> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protoco= l | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> CHP -Context Header Present. If specified, Context Header as >>> specified in section 5 below follows directly Service Path Header >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 08:16: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 095421B2862 for ; Wed, 23 Jul 2014 08:16:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GejV9BrbcVFs for ; Wed, 23 Jul 2014 08:16:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C841B2AD3 for ; Wed, 23 Jul 2014 08:16:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN35391; Wed, 23 Jul 2014 15:16:25 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:16:16 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 08:16:13 -0700 From: Cathy Zhang To: "Henderickx, Wim (Wim)" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoM+vL3tn2ifbUuNY1AXq6MpkputxDwg Date: Wed, 23 Jul 2014 15:16:12 +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.47.138.19] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F6BFCASJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/U7LVsVzOjlcDGN2AVBl4DOvtHIk Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:16:38 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F6BFCASJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Metadata Length field serves the purpose well. Cathy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Wednesday, July 23, 2014 7:34 AM To: Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence I agree we should keep the header as small as possible and as such I also b= elieve we don't need the mandatory Ctxt field to be present. An alternative to the CHP bit could be to use length or MD-Type to indicate= its presence. From: , "Andrew (Andrew)" > Date: Wednesday 23 July 2014 10:30 To: "sfc@ietf.org" > Subject: [sfc] Change to Mandatory Context Header in NSH draft - optional p= resence Following discussion during the meeting today, here is a specific comment o= n how to Change NSH to allow constant-size, easy-to-process in H/W Context = Header while also allowing for deployments that do not need to include the = header: 1. Keep existing format as per draft section 6 but rename from Mandatory= Context Header to Context Header 2. Make the presence of header optional and encode presence/absence usin= g a bit in Base header - proposed change text (in red): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CHP -Context Header Present. If specified, Context Header as specified in s= ection 5 below follows directly Service Path Header Andrew --_000_A2C96F6779E6A041BC7023CC207FC99418F6BFCASJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Metadata Length field = serves the purpose well.

 

Cathy

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 23, 2014 7:34 AM
To: Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -= optional presence

 

I agree= we should keep the header as small as possible and as such I also believe = we don’t need the mandatory Ctxt field to be present.

An alte= rnative to the CHP bit could be to use length or MD-Type to indicate its pr= esence. 

&n= bsp;

From: <Dolganow>, "Andrew (Andrew)" <<= a href=3D"mailto:andrew.dolganow@alcatel-lucent.com">andrew.dolganow@alcate= l-lucent.com>
Date: Wednesday 23 July 2014 10:30
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] Change to Mandatory Context Header in NSH draft - opt= ional presence

&n= bsp;

Followi= ng discussion during the meeting today, here is a specific comment on how t= o Change NSH to allow constant-size, easy-to-process in H/W Context Header = while also allowing for deployments that do not need to include the header:

&n= bsp;

  1. Keep existing format as per draft section = 6 but rename from Mandatory Context Header to Context Header 
  2. Make the presence of header optional and e= ncode presence/absence using  a bit in Base header – proposed ch= ange text (in red):
  &=
nbsp;   0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2=
 3 4 5 6 7 8 9 0 1
  &=
nbsp;  +-+-+-+-+---+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+
  &=
nbsp;  |Ver|O|C|CHP|R|R|R|R|R|   Length  |    M=
D Type    | Next Protocol |
  &=
nbsp;  +-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+

&n= bsp;

CHP ̵= 1;Context Header Present. If specified, Context Header as specified in sect= ion 5 below  follows directly Service Path Header

&n= bsp;

Andrew

&n= bsp;

--_000_A2C96F6779E6A041BC7023CC207FC99418F6BFCASJCEML702CHMchi_-- From nobody Wed Jul 23 08:17: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 902191B28A3 for ; Wed, 23 Jul 2014 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 o1Hif1viZVcM for ; Wed, 23 Jul 2014 08:17:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645471B2837 for ; Wed, 23 Jul 2014 08:17:43 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6NFHb7J004022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 10:17:38 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6NFHbAi032272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 11:17:37 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.218]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 11:17:37 -0400 From: "Dolganow, Andrew (Andrew)" To: Cathy Zhang , "Joel M. Halpern" , Lucy yong , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoKZzKHOd1fHnEC4mx68Fzr5jQ== Date: Wed, 23 Jul 2014 15:17:37 +0000 Message-ID: References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@joelhalpern.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.4.3.140616 x-originating-ip: [135.5.27.18] 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/DfhCFoci8dCALqccv8iSvJan4Yw Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:17:50 -0000 Agree. More so, we should define =B3Null=B2 encoding of each SFP header fields: either SFP ID or Service Index or both could be set to 0. That way we will provide max flexibility and at the same time allow easy interop. Andrew On 2014-07-23, 11:10 AM, "Cathy Zhang" wrote: >I agree with Joel. For better interoperability, we can just keep the 4 >bytes and set them to 0 to indicate "only metadata present". Actually >"only metadata present" is addressed in SCH header draft presented in >today's meeting.=20 > >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Wednesday, July 23, 2014 8:00 AM >To: Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org >Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - >optional presence > >We could allow the null case. But is there a significant advantage in >omitting the SFP-ID + Path Inex, when it is not needed? > >WHen we get to the details of the solution behavior, I would like it to >be clear that the index does not need to be updated if it is not being >used. (i.e. what it indexes are the places that use the Path ID + >index, which is well-defined.) > >But I don't mind having the 4 bytes there. It seems to significantly >improve interoperability. > >Yours, >Joel > >On 7/23/14, 10:53 AM, Lucy yong wrote: >> We also need the option in header where only metadata present, i.e. no >>SFP ID + Index present. >> Lucy >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Wednesday, July 23, 2014 9:51 AM >> To: Dolganow, Andrew (Andrew); sfc@ietf.org >> Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - >>optional presence >> >> Clarification, not "none", but "only SFP ID + SFP Index present." >> >> Yours, >> Joel >> >> On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >>> I had read the MD-type as doing exactly this. So we should simply >>> allocate an MD Type that means "no mandatory header." >>> >>> Yours, >>> Joel >>> >>> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>>> Following discussion during the meeting today, here is a specific >>>> comment on how to Change NSH to allow constant-size, easy-to-process >>>> in H/W Context Header while also allowing for deployments that do not >>>> need to include the header: >>>> >>>> 1. Keep existing format as per draft section 6 but rename from >>>> Mandatory Context Header to Context Header 2. Make the presence >>>> of header optional and encode presence/absence >>>> using a bit in Base header - proposed change text (in red): >>>> >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>>>0 1 >>>> =20 >>>>+-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next >>>>Protocol | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> CHP -Context Header Present. If specified, Context Header as >>>> specified in section 5 below follows directly Service Path Header >>>> >>>> Andrew >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 08:18:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA101B289F for ; Wed, 23 Jul 2014 08:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 XpXkuxWZg_Zf for ; Wed, 23 Jul 2014 08:18:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D0C1B2837 for ; Wed, 23 Jul 2014 08:18:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN35600; Wed, 23 Jul 2014 15:18:44 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 16:18:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml702-chm.china.huawei.com ([169.254.4.217]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 08:18:25 -0700 From: Lucy yong To: Cathy Zhang , "Joel M. Halpern" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVK8qun5O3hbkONXzULFkEs+puuMzoA//+L5yCAAHbIAIAAAuoA//+Nl1A= Date: Wed, 23 Jul 2014 15:18:25 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C2C97@dfweml701-chm.china.huawei.com> References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@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.47.130.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Redn8VaDiXf6vHZZB10ksqkdBhk Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:18:48 -0000 Just set SP ID 0. Use index for TTL purpose. Lucy -----Original Message----- From: Cathy Zhang=20 Sent: Wednesday, July 23, 2014 10:11 AM To: Joel M. Halpern; Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: RE: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence I agree with Joel. For better interoperability, we can just keep the 4 byte= s and set them to 0 to indicate "only metadata present". Actually "only met= adata present" is addressed in SCH header draft presented in today's meetin= g.=20 Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 23, 2014 8:00 AM To: Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence We could allow the null case. But is there a significant advantage in omit= ting the SFP-ID + Path Inex, when it is not needed? WHen we get to the details of the solution behavior, I would like it to be = clear that the index does not need to be updated if it is not being used. = (i.e. what it indexes are the places that use the Path ID + index, which is= well-defined.) But I don't mind having the 4 bytes there. It seems to significantly impro= ve interoperability. Yours, Joel On 7/23/14, 10:53 AM, Lucy yong wrote: > We also need the option in header where only metadata present, i.e. no SF= P ID + Index present. > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 23, 2014 9:51 AM > To: Dolganow, Andrew (Andrew); sfc@ietf.org > Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -=20 > optional presence > > Clarification, not "none", but "only SFP ID + SFP Index present." > > Yours, > Joel > > On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >> I had read the MD-type as doing exactly this. So we should simply=20 >> allocate an MD Type that means "no mandatory header." >> >> Yours, >> Joel >> >> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>> Following discussion during the meeting today, here is a specific=20 >>> comment on how to Change NSH to allow constant-size, easy-to-process=20 >>> in H/W Context Header while also allowing for deployments that do=20 >>> not need to include the header: >>> >>> 1. Keep existing format as per draft section 6 but rename from >>> Mandatory Context Header to Context Header 2. Make the=20 >>> presence of header optional and encode presence/absence >>> using a bit in Base header - proposed change text (in red): >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 >>> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protoco= l | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> CHP -Context Header Present. If specified, Context Header as=20 >>> specified in section 5 below follows directly Service Path Header >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 08:40: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 B3E6A1B2AF9 for ; Wed, 23 Jul 2014 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 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.001, 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 lJf0grIa29p2 for ; Wed, 23 Jul 2014 08:40:15 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id E75841B2AF2 for ; Wed, 23 Jul 2014 08:40:14 -0700 (PDT) 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 s6NFeErI013855 for ; Thu, 24 Jul 2014 00:40:14 +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 2B71CE0113 for ; Thu, 24 Jul 2014 00:40:14 +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 1FA94E0112 for ; Thu, 24 Jul 2014 00:40:14 +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 s6NFe6Wr011161 for ; Thu, 24 Jul 2014 00:40:14 +0900 Message-ID: <53CFD79C.5050809@lab.ntt.co.jp> Date: Thu, 24 Jul 2014 00:41:16 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <20140721193343.30086.20240.idtracker@ietfa.amsl.com> In-Reply-To: <20140721193343.30086.20240.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: sfc@ietf.org X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DuTb9ja5yfvj86UYjQS14LtF7iY Subject: Re: [sfc] I-D Action: draft-ietf-sfc-dc-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, 23 Jul 2014 15:40:17 -0000 Hi all, We updated dc-use-cases draft. We had added a topic of inter-dc use case. Please chacke it. And, if you have any commets or questions, please let us know. Thanks, Shunsuke (2014/07/22 4:33), internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Service Function Chaining Working Group of the IETF. > > Title : Service Function Chaining Use Cases In Data Centers > Authors : Surendra Kumar > Mudassir Tufail > Sumandra Majee > Claudiu Captari > Shunsuke Homma > Filename : draft-ietf-sfc-dc-use-cases-01.txt > Pages : 23 > Date : 2014-07-21 > > Abstract: > Data center operators deploy a variety of layer 4 through layer 7 > service functions in both physical and virtual form factors. Most > traffic originating, transiting, or terminating in the data center is > subject to treatment by multiple service functions. > > This document describes use cases that demonstrate the applicability > of Service Function Chaining (SFC) within a data center environment > and provides SFC requirements for data center centric use cases, with > primary focus on Enterprise data centers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-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/ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Jul 23 08:53: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 96F5C1B28A4 for ; Wed, 23 Jul 2014 08:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.75 X-Spam-Level: * X-Spam-Status: No, score=1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 cZr47SwfYrhY for ; Wed, 23 Jul 2014 08:53:11 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372381B284B for ; Wed, 23 Jul 2014 08:53:11 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 36adfc35.2b1fade82940.3639376.00-2437.10144945.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 23 Jul 2014 15:53:07 +0000 (UTC) X-MXL-Hash: 53cfda631f8b6383-12b2ccfa6b4ef08c8f9857cb3830fa69cfee19a5 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id d5adfc35.0.3639325.00-2009.10144798.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 23 Jul 2014 15:53:02 +0000 (UTC) X-MXL-Hash: 53cfda5e21c6f19a-547a850a2028333a430720c311437ba1f8eb1d8f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6NFr4YP029494; Wed, 23 Jul 2014 11:53:05 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6NFqooT029236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 11:52:58 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Jul 2014 15:52:39 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.228]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 11:52:38 -0400 From: "NAPIERALA, MARIA H" To: Eric Gray Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFk?= =?gb2312?Q?er_in_NSH_draft_-_optional=09presence?= Thread-Index: AQHPpoTAX4IQUDhXLEy5zwSgXKX+f5utv0/QgABEQYD//8uoQA== Date: Wed, 23 Jul 2014 15:52:38 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E01D4F3FE@MISOUT7MSGUSRCF.ITServices.sbc.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.224] Content-Type: multipart/alternative; boundary="_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F3FEMISOUT7MSGUSRCF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Tf4hQ2sh c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=6wLx3WpyTnIA:10 a=ofMgfj31e3cA:10 a=jPJDawAOAc8A:10 a=a6l] X-AnalysisOut: [YbgGDhh4A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 ] X-AnalysisOut: [a=Ln_7bjIe0W9Isglj1m4A:9 a=mFyHDrcPJccA:10 a=f7GxY0FH8QIA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=3FZX-ydVlcEA:10 a] X-AnalysisOut: [=Tcq1PRizppYA:10 a=tDMobnI6euWnODbb:21 a=EwyqpJSjCnMBvHyD:] X-AnalysisOut: [21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=fUNs6-oXi_Nb4MLxX74] X-AnalysisOut: [A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 ] X-AnalysisOut: [a=frz4AuCg-hUA:10 a=ebvFeClOwRvpSCSq:21 a=gNLKlsf9r07aVtTx] X-AnalysisOut: [:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ei1H5yTrU1b8rTXq-8EBVoc0Asw Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" Subject: Re: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwJcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 15:53:13 -0000 --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F3FEMISOUT7MSGUSRCF_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ZS5nLiwgYXBwbGljYXRpb24gSUQsIHN1YnNjcmliZXIgSUQuDQoNCkZyb206IEVyaWMgR3JheSBb bWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMs IDIwMTQgMTE6MDAgQU0NClRvOiBOQVBJRVJBTEEsIE1BUklBIEgNCkNjOiBYdXhpYW9odTsgRG9s Z2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g tPC4tDogQ2hhbmdlIHRvIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlciBpbiBOU0ggZHJhZnQgLSBv cHRpb25hbCBwcmVzZW5jZQ0KDQpNYXJpYS9MdWN5L2V0Yy4NCg0KQ2FuIHlvdSBjbGFyaWZ5IHdo YXQgbWV0YS1kYXRhIHRoZXJlIHdvdWxkIGJlIGJleW9uZCBTRlAgaW5mb3JtYXRpb24/DQoNClNl bnQgZnJvbSBteSBpUGFkDQoNCk9uIEp1bCAyMywgMjAxNCwgYXQgMTA6NTggQU0sICJOQVBJRVJB TEEsIE1BUklBIEgiIDxtbjE5MjFAYXR0LmNvbTxtYWlsdG86bW4xOTIxQGF0dC5jb20+PiB3cm90 ZToNClllcywgaXQgc2hvdWxkIGJlIGFuIG9wdGlvbiB0byBjYXJyeSBvbmx5IG1ldGFkYXRhIGJ1 dCBub3QgdGhlIFNGUCBpbmZvcm1hdGlvbi4NCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5 IDIzLCAyMDE0IDEwOjQ1IEFNDQpUbzogRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSC08Li0OiBDaGFuZ2Ug dG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNl bmNlDQoNCg0KSGksDQoNCg0KDQpGdWxseSBhZ3JlZSB0aGF0IHRoZSBtZXRhZGF0YSByZWxhdGVk IGluZm9ybWF0aW9uIGluY2x1ZGluZyB0aGUgY29udGV4dCBzaG91bGQgYmUgb3B0aW9uYWwsIHJh dGhlciB0aGFuIG1hbmRhdG9yeS4gSW4gYWRkaXRpb24sIEkgYmVsaWV2ZSB0aGUgc2VydmljZSBw YXRoIGhlYWRlciBzaG91bGQgYWxzbyBiZSBvcHRpb25hbCwgaW4gb3RoZXIgd29yZHMsIHRoZSBO U0ggaXMgb25seSB1c2VkIGZvciBjYXJyaW5nIHRoZSBtZXRhZGF0YSByZWxhdGVkIGluZm9ybWF0 aW9uLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCreivP7Iyzogc2ZjIFtzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIERvbGdhbm93LCBBbmRyZXcgKEFuZHJldykgW2Fu ZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bh bGNhdGVsLWx1Y2VudC5jb20+XQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjIzyNUgMjI6MzANCsrVvP7I yzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQrW98ziOiBbc2ZjXSBDaGFuZ2Ug dG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNl bmNlDQpGb2xsb3dpbmcgZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIG1lZXRpbmcgdG9kYXksIGhlcmUg aXMgYSBzcGVjaWZpYyBjb21tZW50IG9uIGhvdyB0byBDaGFuZ2UgTlNIIHRvIGFsbG93IGNvbnN0 YW50LXNpemUsIGVhc3ktdG8tcHJvY2VzcyBpbiBIL1cgQ29udGV4dCBIZWFkZXIgd2hpbGUgYWxz byBhbGxvd2luZyBmb3IgZGVwbG95bWVudHMgdGhhdCBkbyBub3QgbmVlZCB0byBpbmNsdWRlIHRo ZSBoZWFkZXI6DQoNCg0KICAxLiAgS2VlcCBleGlzdGluZyBmb3JtYXQgYXMgcGVyIGRyYWZ0IHNl Y3Rpb24gNiBidXQgcmVuYW1lIGZyb20gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIHRvIENvbnRl eHQgSGVhZGVyDQogIDIuICBNYWtlIHRoZSBwcmVzZW5jZSBvZiBoZWFkZXIgb3B0aW9uYWwgYW5k IGVuY29kZSBwcmVzZW5jZS9hYnNlbmNlIHVzaW5nICBhIGJpdCBpbiBCYXNlIGhlYWRlciCoQyBw cm9wb3NlZCBjaGFuZ2UgdGV4dCAoaW4gcmVkKToNCg0KICAgICAgMCAxIDIgMyAgNCAgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCg0KICAgICAr LSstKy0rLSstLS0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQoNCiAgICAgfFZlcnxPfEN8Q0hQfFJ8UnxSfFJ8UnwgICBMZW5ndGggIHwgICAg TUQgVHlwZSAgICB8IE5leHQgUHJvdG9jb2wgfA0KDQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCkNIUCCoQ0Nv bnRleHQgSGVhZGVyIFByZXNlbnQuIElmIHNwZWNpZmllZCwgQ29udGV4dCBIZWFkZXIgYXMgc3Bl Y2lmaWVkIGluIHNlY3Rpb24gNSBiZWxvdyAgZm9sbG93cyBkaXJlY3RseSBTZXJ2aWNlIFBhdGgg SGVhZGVyDQoNCkFuZHJldw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K --_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F3FEMISOUT7MSGUSRCF_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

e.g., application ID, = subscriber ID.

 

From: Eric Gra= y [mailto:eric.gray@ericsson.com]
Sent: Wednesday, July 23, 2014 11:00 AM
To: NAPIERALA, MARIA H
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] =B4=F0=B8=B4: Change to Mandato= ry Context Header in NSH draft - optional presence

 

Maria/Lucy/etc.

 

Can you clarify what meta-data there would be beyond= SFP information?

Sent from my iPad


On Jul 23, 2014, at 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Yes, it should be an o= ption to carry only metadata but not the SFP information.=

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Wednesday, July 23, 2014 10:45 AM
To: Dolganow, Andrew (Andrew); sfc@i= etf.org
Subject: [sfc] =B4=F0=B8=B4: Change to Mandatory C= ontext Header in NSH draft - optional presence

 

Hi,

 

Fully agree that the metadata related informatio= n including the context should be optional, rather than mandatory. In addit= ion, I believe the service path header should also be optional, in other words, the NSH is only used for carring the metada= ta related information.

 

Best regards,

Xiaohu

=B7=A2=BC=FE= =C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED Dolganow, Andrew (Andre= w) [andrew.dolganow@alc= atel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Change to Mandatory Context Header in NSH draft - optional presence<= /span>

Following discussion during the meeting t= oday, here is a specific comment on how to Change NSH to allow constant-siz= e, easy-to-process in H/W Context Header while also allowing for deployments that do not need to include the header:<= /p>

 

  1. K= eep existing format as per draft section 6 but rename from Mandatory Contex= t Header to Context Header 
  2. M= ake the presence of header optional and encode presence/absence using  = ;a bit in Base header =A8C proposed change text (in red):= 
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+---+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |Ver|O|C|CHP|R|R|R|=
R|R|   Length  |    MD Type   =
 | Next Protocol |
     +-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;

 

CHP =A8CContext Header Present. If specifie= d, Context Header as specified in section 5 below  follows directly Se= rvice Path Header

 

Andrew

 

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

--_000_1D70D757A2C9D54D83B4CBD7625FA80E01D4F3FEMISOUT7MSGUSRCF_-- From nobody Wed Jul 23 09:03: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 4A1A51B293A for ; Wed, 23 Jul 2014 09:03:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wB_LcRzXlINH for ; Wed, 23 Jul 2014 09:03:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1C91B2936 for ; Wed, 23 Jul 2014 09:03:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN38788; Wed, 23 Jul 2014 16:03:44 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 17:03:43 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 09:03:38 -0700 From: Linda Dunbar To: "sfc@ietf.org" Thread-Topic: Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture Thread-Index: Ac+mj6rt4GD2XbZYQgCzbZ2AyFkevg== Date: Wed, 23 Jul 2014 16:03:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@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.157.77] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DA2D2Adfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SSWCJzMgJF3Fxf_pIned-2ZvUN4 Subject: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:03:47 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DA2D2Adfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand the concerns of authors of merged-arch not wanting to explicit= ly define the "Service Function Instance". However, the term "Service Funct= ion Instance" has been used extensively on mailing list and in many SFC dra= fts. Having a proper definition can make many drafts more clear. Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG. "Service Function Instance: One instantiation of a service function. Some S= F instances are visible to SFF. Sometimes a collection of service function = instances can appear as one single entity to SFF. One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions." What do people think? Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645DA2D2Adfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I understand the concerns of authors of merged-arch = not wanting to explicitly define the “Service Function Instance”= ;. However, the term “Service Function Instance” has been used = extensively on mailing list and in many SFC drafts. Having a proper definition can make many drafts more clear.

 

Here is the Service function Instances defined by dr= aft-dunbar-sfc-legacy-l4-l7-chain-architecture. Want to get feedback from t= he SFC WG.

 

“Service Function Instance: One instantiation = of a service function. Some SF instances are visible to SFF. Sometimes a co= llection of service function instances can appear as one single entity to S= FF.

One service function could have multiple identical i= nstances. For a service function with different functional instantiations, = e.g. one instantiation applies policy-set-A (NAT44-A) and other applies pol= icy-set-B (NAT44-B), they are considered as two different service functions."

 

What do people think?

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645DA2D2Adfweml701chmchi_-- From nobody Wed Jul 23 09: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 B92B11A00E1 for ; Wed, 23 Jul 2014 09:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 qN3MEnhs-oX1 for ; Wed, 23 Jul 2014 09:06:57 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D11B27ED for ; Wed, 23 Jul 2014 09:06:51 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::c8c4:1c2a:2ea3:e874%14]) with mapi id 14.01.0438.000; Wed, 23 Jul 2014 12:06:50 -0400 From: Dave Dolson To: Lucy yong , Cathy Zhang , "Joel M. Halpern" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVDlRWU0ZyWjEueiud5gYYZ85uuAO8AgAAA7oCAAAHBAIAAAuoAgAACLYD//8fZoA== Date: Wed, 23 Jul 2014 16:06:49 +0000 Message-ID: References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C97@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453C2C97@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lhCqw9mbRqTI8yM1mUFTfpqU2_I Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 16:07:02 -0000 What is the next hop when receiving such a packet? I think the forwarding table for ID 0 would need to be configured. But then any ID could be used, and 0 is just a convention vs. a special cas= e that the protocol needs to define. So, I'm saying: - there is no need for any specification of service chaining without a chai= n ID. ID is always required, but you can have only one chain if you wish. - Keep it simple; avoid special cases. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, July 23, 2014 11:18 AM To: Cathy Zhang; Joel M. Halpern; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence Just set SP ID 0. Use index for TTL purpose. Lucy -----Original Message----- From: Cathy Zhang Sent: Wednesday, July 23, 2014 10:11 AM To: Joel M. Halpern; Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: RE: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence I agree with Joel. For better interoperability, we can just keep the 4 byte= s and set them to 0 to indicate "only metadata present". Actually "only met= adata present" is addressed in SCH header draft presented in today's meetin= g.=20 Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 23, 2014 8:00 AM To: Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence We could allow the null case. But is there a significant advantage in omit= ting the SFP-ID + Path Inex, when it is not needed? WHen we get to the details of the solution behavior, I would like it to be = clear that the index does not need to be updated if it is not being used. = (i.e. what it indexes are the places that use the Path ID + index, which is= well-defined.) But I don't mind having the 4 bytes there. It seems to significantly impro= ve interoperability. Yours, Joel On 7/23/14, 10:53 AM, Lucy yong wrote: > We also need the option in header where only metadata present, i.e. no SF= P ID + Index present. > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 23, 2014 9:51 AM > To: Dolganow, Andrew (Andrew); sfc@ietf.org > Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -=20 > optional presence > > Clarification, not "none", but "only SFP ID + SFP Index present." > > Yours, > Joel > > On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >> I had read the MD-type as doing exactly this. So we should simply=20 >> allocate an MD Type that means "no mandatory header." >> >> Yours, >> Joel >> >> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>> Following discussion during the meeting today, here is a specific=20 >>> comment on how to Change NSH to allow constant-size, easy-to-process=20 >>> in H/W Context Header while also allowing for deployments that do=20 >>> not need to include the header: >>> >>> 1. Keep existing format as per draft section 6 but rename from >>> Mandatory Context Header to Context Header 2. Make the=20 >>> presence of header optional and encode presence/absence >>> using a bit in Base header - proposed change text (in red): >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 >>> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protoco= l | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> CHP -Context Header Present. If specified, Context Header as=20 >>> specified in section 5 below follows directly Service Path Header >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 09:08: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 0CBD41A0067 for ; Wed, 23 Jul 2014 09:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 J5X0ZolGfCHQ for ; Wed, 23 Jul 2014 09:08:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3231A0029 for ; Wed, 23 Jul 2014 09:08:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN39098; Wed, 23 Jul 2014 16:08:38 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 17:08:38 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 09:08:28 -0700 From: Henry Fourie To: Eric Gray , "NAPIERALA, MARIA H" Thread-Topic: =?gb2312?B?W3NmY10gtPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFk?= =?gb2312?Q?er_in_NSH_draft_-_optional=09presence?= Thread-Index: AQHPpoaIuIJXANgJcUSfWsS/GlmTUJuuNdeA//+c3jA= Date: Wed, 23 Jul 2014 16:08:27 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AA2859B@SJCEML702-CHM.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296D0D@NKGEML512-MBS.china.huawei.com>, <1D70D757A2C9D54D83B4CBD7625FA80E01D4F2D1@MISOUT7MSGUSRCF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.62] Content-Type: multipart/alternative; boundary="_000_0F8583BBE82FA449A8B78417CC07559AA2859BSJCEML702CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/zGe2eLVr2zyiZwchJ0PgZlYD2qo Cc: Xuxiaohu , "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" Subject: Re: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwJcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 16:08:43 -0000 --_000_0F8583BBE82FA449A8B78417CC07559AA2859BSJCEML702CHMchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RXJpYywNCiAgTDcgcGFyYW1ldGVycyBleHRyYWN0ZWQgZnJvbSBhIHBhY2tldCBieSBhIERQSSBl bmdpbmUgYW5kIHRyYW5zcG9ydGVkIHRvIGRvd25zdHJlYW0gU0ZzLg0KIFJlc3VsdHMgZnJvbSBT RiBwcm9jZXNzaW5nIHBhc3NlZCB0byBhIGRvd25zdHJlYW0gU0YNCg0KDQotICAgICAgICAgIExv dWlzDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRXJpYyBHcmF5DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgODowMCBBTQ0KVG86 IE5BUElFUkFMQSwgTUFSSUEgSA0KQ2M6IFh1eGlhb2h1OyBEb2xnYW5vdywgQW5kcmV3IChBbmRy ZXcpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSC08Li0OiBDaGFuZ2UgdG8gTWFu ZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNlbmNlDQoN Ck1hcmlhL0x1Y3kvZXRjLg0KDQpDYW4geW91IGNsYXJpZnkgd2hhdCBtZXRhLWRhdGEgdGhlcmUg d291bGQgYmUgYmV5b25kIFNGUCBpbmZvcm1hdGlvbj8NCg0KU2VudCBmcm9tIG15IGlQYWQNCg0K T24gSnVsIDIzLCAyMDE0LCBhdCAxMDo1OCBBTSwgIk5BUElFUkFMQSwgTUFSSUEgSCIgPG1uMTky MUBhdHQuY29tPG1haWx0bzptbjE5MjFAYXR0LmNvbT4+IHdyb3RlOg0KWWVzLCBpdCBzaG91bGQg YmUgYW4gb3B0aW9uIHRvIGNhcnJ5IG9ubHkgbWV0YWRhdGEgYnV0IG5vdCB0aGUgU0ZQIGluZm9y bWF0aW9uLg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFh1eGlhb2h1DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgMTA6NDUgQU0N ClRvOiBEb2xnYW5vdywgQW5kcmV3IChBbmRyZXcpOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdILTwuLQ6IENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4 dCBIZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2UNCg0KDQpIaSwNCg0KDQoN CkZ1bGx5IGFncmVlIHRoYXQgdGhlIG1ldGFkYXRhIHJlbGF0ZWQgaW5mb3JtYXRpb24gaW5jbHVk aW5nIHRoZSBjb250ZXh0IHNob3VsZCBiZSBvcHRpb25hbCwgcmF0aGVyIHRoYW4gbWFuZGF0b3J5 LiBJbiBhZGRpdGlvbiwgSSBiZWxpZXZlIHRoZSBzZXJ2aWNlIHBhdGggaGVhZGVyIHNob3VsZCBh bHNvIGJlIG9wdGlvbmFsLCBpbiBvdGhlciB3b3JkcywgdGhlIE5TSCBpcyBvbmx5IHVzZWQgZm9y IGNhcnJpbmcgdGhlIG1ldGFkYXRhIHJlbGF0ZWQgaW5mb3JtYXRpb24uDQoNCg0KDQpCZXN0IHJl Z2FyZHMsDQoNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8 /sjLOiBzZmMgW3NmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Zz5dILT6se0gRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KSBbYW5kcmV3LmRvbGdhbm93QGFsY2F0 ZWwtbHVjZW50LmNvbTxtYWlsdG86YW5kcmV3LmRvbGdhbm93QGFsY2F0ZWwtbHVjZW50LmNvbT5d DQq3osvNyrG85DogMjAxNMTqN9TCMjPI1SAyMjozMA0KytW8/sjLOiBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NCtb3zOI6IFtzZmNdIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4 dCBIZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2UNCkZvbGxvd2luZyBkaXNj dXNzaW9uIGR1cmluZyB0aGUgbWVldGluZyB0b2RheSwgaGVyZSBpcyBhIHNwZWNpZmljIGNvbW1l bnQgb24gaG93IHRvIENoYW5nZSBOU0ggdG8gYWxsb3cgY29uc3RhbnQtc2l6ZSwgZWFzeS10by1w cm9jZXNzIGluIEgvVyBDb250ZXh0IEhlYWRlciB3aGlsZSBhbHNvIGFsbG93aW5nIGZvciBkZXBs b3ltZW50cyB0aGF0IGRvIG5vdCBuZWVkIHRvIGluY2x1ZGUgdGhlIGhlYWRlcjoNCg0KDQogIDEu ICBLZWVwIGV4aXN0aW5nIGZvcm1hdCBhcyBwZXIgZHJhZnQgc2VjdGlvbiA2IGJ1dCByZW5hbWUg ZnJvbSBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgdG8gQ29udGV4dCBIZWFkZXINCiAgMi4gIE1h a2UgdGhlIHByZXNlbmNlIG9mIGhlYWRlciBvcHRpb25hbCBhbmQgZW5jb2RlIHByZXNlbmNlL2Fi c2VuY2UgdXNpbmcgIGEgYml0IGluIEJhc2UgaGVhZGVyIKhDIHByb3Bvc2VkIGNoYW5nZSB0ZXh0 IChpbiByZWQpOg0KDQogICAgICAwIDEgMiAzICA0ICA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQogICAgICstKy0rLSstKy0tLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICB8 VmVyfE98Q3xDSFB8UnxSfFJ8UnxSfCAgIExlbmd0aCAgfCAgICBNRCBUeXBlICAgIHwgTmV4dCBQ cm90b2NvbCB8DQoNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KQ0hQIKhDQ29udGV4dCBIZWFkZXIgUHJlc2Vu dC4gSWYgc3BlY2lmaWVkLCBDb250ZXh0IEhlYWRlciBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1 IGJlbG93ICBmb2xsb3dzIGRpcmVjdGx5IFNlcnZpY2UgUGF0aCBIZWFkZXINCg0KQW5kcmV3DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_0F8583BBE82FA449A8B78417CC07559AA2859BSJCEML702CHMchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Eric,

  L7 parameters e= xtracted from a packet by a DPI engine and transported to downstream SFs.

 Results from SF = processing passed to a downstream SF

 

-  = ;        Louis

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Wednesday, July 23, 2014 8:00 AM
To: NAPIERALA, MARIA H
Cc: Xuxiaohu; Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] =B4=F0=B8=B4: Change to Mandato= ry Context Header in NSH draft - optional presence

 

Maria/Lucy/etc.

 

Can you clarify what meta-data there would be beyond= SFP information?

Sent from my iPad


On Jul 23, 2014, at 10:58 AM, "NAPIERALA, MARIA H" <mn1921@att.com> wrote:

Yes, it should be an o= ption to carry only metadata but not the SFP information.=

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Wednesday, July 23, 2014 10:45 AM
To: Dolganow, Andrew (Andrew); sfc@i= etf.org
Subject: [sfc] =B4=F0=B8=B4: Change to Mandatory C= ontext Header in NSH draft - optional presence

 

Hi,

 

Fully agree that the metadata related informatio= n including the context should be optional, rather than mandatory. In addit= ion, I believe the service path header should also be optional, in other words, the NSH is only used for carring the metada= ta related information.

 

Best regards,

Xiaohu

=B7=A2=BC=FE= =C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED Dolganow, Andrew (Andre= w) [andrew.dolganow@alc= atel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] Change to Mandatory Context Header in NSH draft - optional presence<= /span>

Following discussion during the meeting t= oday, here is a specific comment on how to Change NSH to allow constant-siz= e, easy-to-process in H/W Context Header while also allowing for deployments that do not need to include the header:<= /p>

 

  1. K= eep existing format as per draft section 6 but rename from Mandatory Contex= t Header to Context Header 
  2. M= ake the presence of header optional and encode presence/absence using  = ;a bit in Base header =A8C proposed change text (in red):= 
      0 1 2 3  4  5 6 7 8 9 0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+---+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;
     |Ver|O|C|CHP|R|R|R|=
R|R|   Length  |    MD Type   =
 | Next Protocol |
     +-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;

 

CHP =A8CContext Header Present. If specifie= d, Context Header as specified in section 5 below  follows directly Se= rvice Path Header

 

Andrew

 

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

--_000_0F8583BBE82FA449A8B78417CC07559AA2859BSJCEML702CHMchina_-- From nobody Wed Jul 23 09:15: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 B5CF11B28AF for ; Wed, 23 Jul 2014 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 QlqYjgaT0GEp for ; Wed, 23 Jul 2014 09:15:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6BE1B27C7 for ; Wed, 23 Jul 2014 09:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13271; q=dns/txt; s=iport; t=1406132134; x=1407341734; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eaGW4j06cKEJmul1NRPAmZowkdkZPJs6LKEijDobzCg=; b=liv8Th+9Dj7CLBT7p2mWtXsFF1ED1KqNiOfHB7BzyLYjumrWRfnyU4rk 3o7ARBEW1CnrNZoTDApk6ck1zP1MWZP9dQx2woY0wm1DVHSbWwcMkA9xe Jt8AqjFJkYcpWXbLiwGSV5RDQZp7ov5uFcd5aklYKlIx9bcSxNvahAtbY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAGPez1OtJV2P/2dsb2JhbABZgkdHUlcEx1sBCYdFAYELFnaEAwEBAQQBAQFrCxACAQgRBAEBKAcnCxQJCAEBBA4FiEINwEwTBI9LBgGDLoEYBY5FjGiMAIhAg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208,217";a="342241428" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2014 16:15:34 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6NGFX0U004653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:15:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 11:15:33 -0500 From: "Carlos Pignataro (cpignata)" To: Lucy yong Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCAADQr7AA== Date: Wed, 23 Jul 2014 16:15:32 +0000 Message-ID: <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@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.117.115.53] Content-Type: multipart/alternative; boundary="_000_009CF5B2040E455EBAD48296FDE28497ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RFtNMjhWP5CC6nSX-klP8PVTP-8 Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 16:15:37 -0000 --_000_009CF5B2040E455EBAD48296FDE28497ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=92s wording than a term easily understood by engineers = (considering there are a lot of IETFers/engineers whose first language is n= ot English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_009CF5B2040E455EBAD48296FDE28497ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <47D6F209CDDDA1439612391003A68735@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Lucy, Linda, Nurit,

I do not think that a self-referencing definition will help -- i.e., I= am sure "A service function path is a path traversing service functio= ns" is correct but it's not particularly clarifying...

Stepping back a bit, this (proposed by Joel) is where we are and what = was discussed on the list and presented today.

   Service Function Path (SFP):  The SFP = ;provides a level of indirection
        between the fully abstract notion of servi= ce chain as a sequence
        of functions to be delivered, and the full= y specified notion of
        exactly what instances of SFFs the packet = will visit when it
        actually traverses the network.  = ;By allowing the control
        components to specify the use of this leve= l of indirection, the
        deployment may choose the degree of SFF/SF= instance selection
        authority that is delegated to the network= .

I agree it's perhaps not the easiest English to parse, but nonetheless= is inclusive of all discussion and captures all key points, while excludes= noise. 

What specific concerns do you have with this definition? (i.e., what m= eaning is missing?)

Thanks,

Carlos.

On Jul 23, 2014, at 11:00 AM, Lucy yong <lucy.yong@huawei.com> wrote:

How about:
 
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified.  
 
Lucy
 
 
From:<= /span> sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, = Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, J= uly 23, 2014 9:40 AM
To: Linda Dunbar; = sfc@ietf.org
Subject: Re: [sfc]= Simpler description of Service Function Path
 
I would propose to do it even simp= ler
Service Function Path (SFP):<= /o:p>
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified. In case o= f a loosely specification, at least the ingress and the egress SFFs and/or  SFs need to be specified.
 
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of ext Linda = Dunbar
Sent: Wednesday, J= uly 23, 2014 5:05 PM
To: sfc@= ietf.org
Subject: [sfc] Sim= pler description of Service Function Path
 
I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=92s wording than a term easily understood by engineers = (considering there are a lot of IETFers/engineers whose first language is n= ot English).
 
Here is my suggested simpler wording:
 
Service Function Path (SFP):
SFP is a pathway traversing a sequence of service function= s from ingress to egress of the SFC-enabled domain, including sequence of S= FFs and sequence of SFs. This sequence can be specified precisely with exac= t sequence of SFFs and the sequence of SFs reached by each SFF,  loosely specified with sets of SFFs/SFs,= or somewhere in between.
 
Linda
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_009CF5B2040E455EBAD48296FDE28497ciscocom_-- From nobody Wed Jul 23 09:15: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 093DE1B29A0 for ; Wed, 23 Jul 2014 09:15:40 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 X5xfkdknj2ic for ; Wed, 23 Jul 2014 09:15:37 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id A29591B27C6 for ; Wed, 23 Jul 2014 09:15:37 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.01.0339.001; Wed, 23 Jul 2014 12:15:36 -0400 From: Dave Dolson To: Linda Dunbar , "sfc@ietf.org" Thread-Topic: Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture Thread-Index: Ac+mj6rt4GD2XbZYQgCzbZ2AyFkevgAATqoA Date: Wed, 23 Jul 2014 16:15:36 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830A53547wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/fYLdrei3ZrRygiSEZJ13GlkqVj0 Subject: Re: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:15:40 -0000 --_000_E8355113905631478EFF04F5AA706E9830A53547wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a vendor wishes to make hidden instances for scaling purposes, I think i= t would be simpler to call the set of instances a single SF. This avoids th= e "sometimes" in the definition. "Service Function Instance: One instantiation of a service function. SF ins= tances are visible to an SFF. One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions." From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, July 23, 2014 12:04 PM To: sfc@ietf.org Subject: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy= -l4-l7-chain-architecture I understand the concerns of authors of merged-arch not wanting to explicit= ly define the "Service Function Instance". However, the term "Service Funct= ion Instance" has been used extensively on mailing list and in many SFC dra= fts. Having a proper definition can make many drafts more clear. Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG. "Service Function Instance: One instantiation of a service function. Some S= F instances are visible to SFF. Sometimes a collection of service function = instances can appear as one single entity to SFF. One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions." What do people think? Linda --_000_E8355113905631478EFF04F5AA706E9830A53547wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If a vendor wishes to = make hidden instances for scaling purposes, I think it would be simpler to = call the set of instances a single SF. This avoids the “sometimesR= 21; in the definition.

 

“Service Function Instance: One instantiation = of a service function. SF instances are visible to an SFF.

One service function could have multiple identical i= nstances. For a service function with different functional instantiations, = e.g. one instantiation applies policy-set-A (NAT44-A) and other applies pol= icy-set-B (NAT44-B), they are considered as two different service functions."

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, July 23, 2014 12:04 PM
To: sfc@ietf.org
Subject: [sfc] Service Function Instance defined by draft-dunbar-sfc= -legacy-l4-l7-chain-architecture

 

I understand the concerns of authors of merged-arch = not wanting to explicitly define the “Service Function Instance”= ;. However, the term “Service Function Instance” has been used = extensively on mailing list and in many SFC drafts. Having a proper definition can make many drafts more clear.

 

Here is the Service function Instances defined by dr= aft-dunbar-sfc-legacy-l4-l7-chain-architecture. Want to get feedback from t= he SFC WG.

 

“Service Function Instance: One instantiation = of a service function. Some SF instances are visible to SFF. Sometimes a co= llection of service function instances can appear as one single entity to S= FF.

One service function could have multiple identical i= nstances. For a service function with different functional instantiations, = e.g. one instantiation applies policy-set-A (NAT44-A) and other applies pol= icy-set-B (NAT44-B), they are considered as two different service functions."

 

What do people think?

 

Linda

 

--_000_E8355113905631478EFF04F5AA706E9830A53547wtlexchp2sandvi_-- From nobody Wed Jul 23 09:24: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 802D21A014E for ; Wed, 23 Jul 2014 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 AqlzhAS3hpgN for ; Wed, 23 Jul 2014 09:24:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC96B1A0084 for ; Wed, 23 Jul 2014 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7011; q=dns/txt; s=iport; t=1406132652; x=1407342252; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gAbA1Y+/MpH8EmXmYjDpgMXSZb3/Unso8/DwomBiYgM=; b=gbXU9zvDBUrQFCd+fOFJxw6jXH5sISC8BkfFdxxJIw9l0JBN98XVirlU fG6NJ9eXSJqN/JbkWqiFmzdiaVml+gdStD2bKV2uUX2KBmUp3Wwz9EGH2 b/FT1yexzZpSDGiFUlHCMAl5PjM48DG/qecMZe6rPp5HSiRwswARbu/6Y Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAL3gz1OtJV2R/2dsb2JhbABZgkdHUlcEx1sBCYdFAYELFnaEBAEBBAEBAWsLEAIBCBItBycLFAMOAQEEDgWIQg3AURMEj0cEB4MugRgFjkWMaIwAiECCA4FFbIFF X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208,217";a="342287125" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jul 2014 16:24:11 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6NGOBXt005099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:24:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 11:24:10 -0500 From: "Carlos Pignataro (cpignata)" To: Linda Dunbar Thread-Topic: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture Thread-Index: Ac+mj6rt4GD2XbZYQgCzbZ2AyFkevgALMZAA Date: Wed, 23 Jul 2014 16:24:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@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.117.115.53] Content-Type: multipart/alternative; boundary="_000_C6DF797B4F5A4C64BDCDA477C6CCDCDDciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/i5x24UjdDRA8L04oykJDZLcS9zk Cc: "sfc@ietf.org" Subject: Re: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:24:13 -0000 --_000_C6DF797B4F5A4C64BDCDA477C6CCDCDDciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I would resist the urge to compete with Merriam-Webster and attempt to crea= te the largest dictionary in an RFC format. I sense we are going a bit over= board with adding definitions... Why would we want to add more definitions, particularly for phrases that ar= e not used in merged-sfc-arch? Conversely, if there is a document that needs the term =93Service Function = Instance=94 it should, by all means, define it within that context. merged-= sfc-arch should not have the goal of defining any potential SFC term that m= ight be used in some context. In other words, merged-sfc-arch should include the base set of terms (i.e.,= the ones are used within the architecture), and companion documents can au= gment as needed. Just my view. Thanks, Carlos. On Jul 23, 2014, at 12:03 PM, Linda Dunbar > wrote: I understand the concerns of authors of merged-arch not wanting to explicit= ly define the =93Service Function Instance=94. However, the term =93Service= Function Instance=94 has been used extensively on mailing list and in many= SFC drafts. Having a proper definition can make many drafts more clear. Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG. =93Service Function Instance: One instantiation of a service function. Some= SF instances are visible to SFF. Sometimes a collection of service functio= n instances can appear as one single entity to SFF. One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions." What do people think? Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C6DF797B4F5A4C64BDCDA477C6CCDCDDciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <022BB9A6B8F53740ADE05C201B009E6A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I would resist the urge to compete with Merriam-Webster and attempt to crea= te the largest dictionary in an RFC format. I sense we are going a bit over= board with adding definitions...

Why would we want to add more definitions, particularly for phrases th= at are not used in merged-sfc-arch?

Conversely, if there is a document that needs the term =93Service= Function Instance=94 it should, by all means, define it within that contex= t. merged-sfc-arch should not have the goal of defining any potential SFC t= erm that might be used in some context.

In other words, merged-sfc-arch should include the base set of terms (= i.e., the ones are used within the architecture), and companion documents c= an augment as needed.

Just my view.

Thanks,

Carlos. 

On Jul 23, 2014, at 12:03 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

I understand the concerns of authors of merged-arch not wanting to explicit= ly define the =93Service Function Instance=94. However, the term =93Service= Function Instance=94 has been used extensively on mailing list and in many= SFC drafts. Having a proper definition can make many drafts more clear.
 
Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG.
 
=93Service Function Instance: One instantiation of a service function. Some= SF instances are visible to SFF. Sometimes a collection of service functio= n instances can appear as one single entity to SFF.
One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions."
 
What do people think?
 
Linda
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_C6DF797B4F5A4C64BDCDA477C6CCDCDDciscocom_-- From nobody Wed Jul 23 09:40: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 DAF911B294A for ; Wed, 23 Jul 2014 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 CYmfB1OXgNSc for ; Wed, 23 Jul 2014 09:40:11 -0700 (PDT) Received: from omr-d05.mx.aol.com (omr-d05.mx.aol.com [205.188.109.202]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FC01A0022 for ; Wed, 23 Jul 2014 09:40:10 -0700 (PDT) Received: from mtaout-mbd01.mx.aol.com (mtaout-mbd01.mx.aol.com [172.26.252.13]) by omr-d05.mx.aol.com (Outbound Mail Relay) with ESMTP id C196D700000A8; Wed, 23 Jul 2014 12:40:09 -0400 (EDT) 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-mbd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7A2AD380000A6; Wed, 23 Jul 2014 12:40:09 -0400 (EDT) Date: Wed, 23 Jul 2014 12:40:09 -0400 From: "mikebianc@aol.com" To: cpignata@cisco.com Message-ID: <1531752076.24329.1406133609307.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24328_1937260149.1406133609307" X-Originating-IP: 10.181.180.89, 10.181.180.89 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1406133609; bh=AQnX/exqZucTbaIxEQTbt/ymVvxmZTxcsG78DumFqlE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=X5tzm4+S3br2UGWBqyPHpWMV6oAg7+O2BPiw73g/9wMk/qt6789Rmfj1Hwlyh61FD XALPjO8WxAMjs4sF5vXpmxIfD2pyvoSWZ5oKtjALZOXPBKa7afTDksm7uLZDS74Smw ak6DbeLn38M8c1BNc9YXIcm6KMgdXNBruobuGv5k= x-aol-sid: 3039ac1afc0d53cfe569430d X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2HHMW9LQUIliR1h3KuD_g-qDCd0 Cc: sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 16:40:13 -0000 ------=_Part_24328_1937260149.1406133609307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed. =C2=A0 I think this is well written, clear, and neither restrictive= nor suggestive of any particular implementation. =C2=A0 From: cpignata@cisco.com To: Lucy yong cc: Sprecher, Nurit (NSN - IL/Hod HaSharon),sfc@iet= f.org,Linda Dunbar Sent: Wednesday, July 23, 2014 Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e.=20 What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong wrote: How about: =20 SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. =20 =20 Lucy =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar;=20 sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path =20 I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the ingress and the egress SFFs and/or SFs need to be specified. =20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path =20 I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=E2=80=99s wording than a term easily understood by engi= neers (considering there are a lot of IETFers/engineers whose first languag= e is not English). =20 Here is my suggested simpler wording: =20 Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets of SFFs/SFs, or s= omewhere in between. =20 Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ------=_Part_24328_1937260149.1406133609307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Agreed.   = I think this is well written, clear, and neither restrictive nor suggestive= of any particular implementation.  


From: cpignata@cisco.com<cpignata@cisco.com= >
To: Lucy yong<lucy.yong@huawei.com>
cc: Spre= cher, Nurit (NSN - IL/Hod HaSharon)<nurit.sprecher@nsn.com>,sfc@ietf.= org<sfc@ietf.org>,Linda Dunbar<linda.dunbar@huawei.com>
S= ent: Wednesday, July 23, 2014
Subject: Re: [sfc] Simpler desc= ription of Service Function Path

Lucy, Linda, Nurit,

I do not think that a self-referencing definition will help -- i.e., I= am sure "A service function path is a path traversing service functions" i= s correct but it's not particularly clarifying...

Stepping back a bit, this (proposed by Joel) is where we are and what = was discussed on the list and presented today.

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

I agree it's perhaps not the easiest English to parse, but nonetheless= is inclusive of all discussion and captures all key points, while excludes= noise.

What specific concerns do you have with this definition? (i.e., what m= eaning is missing?)

Thanks,

Carlos.


How about:
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified.
Lucy
From:<= /span> sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit= (NSN - IL/Hod HaSharon)
Sent: Wednesday, July 2= 3, 2014 9:40 AM
To: Linda Dunbar; sfc@ietf.org
Subject: Re: [sfc] Simp= ler description of Service Function Path
I would propose to do it even simp= ler
Service Function Path (SFP):<= /o:p>
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified. In case o= f a loosely specification, at least the ingress and the egress SFFs and/or SFs need to be specified.
From:<= /span> sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunba= r
Sent: Wednesday, July 2= 3, 2014 5:05 PM
To: sfc@ietf.= org
Subject: [sfc] Simpler = description of Service Function Path
I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=E2=80=99s wording than a term easily understood by engi= neers (considering there are a lot of IETFers/engineers whose first languag= e is not English).
Here is my suggested simpler wording:
Service Function Path (SFP):
SFP is a pathway traversing a sequence of service function= s from ingress to egress of the SFC-enabled domain, including sequence of S= FFs and sequence of SFs. This sequence can be specified precisely with exac= t sequence of SFFs and the sequence of SFs reached by each SFF, loosely specified with sets of SFFs/SFs, or s= omewhere in between.
Linda
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

------=_Part_24328_1937260149.1406133609307-- From nobody Wed Jul 23 10:16: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 64C991A0270 for ; Wed, 23 Jul 2014 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 4v_gOhf6ZMq0 for ; Wed, 23 Jul 2014 10:16:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CF71B2B84 for ; Wed, 23 Jul 2014 10:16:01 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6NHFvel003097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 12:15:57 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6NHFuKV013013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 13:15:57 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.218]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 13:15:56 -0400 From: "Dolganow, Andrew (Andrew)" To: "mikebianc@aol.com" , "cpignata@cisco.com" Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: AQHPppnDLxH5GCKgNEWxbGGKrDrekw== Date: Wed, 23 Jul 2014 17:15:55 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> <1531752076.24329.1406133609307.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: <1531752076.24329.1406133609307.JavaMail.tomcat@mgs-aam01.mail.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_CFF5646956E02andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/18tNKa1NpqFmteIQsHrgeAJNANM Cc: "sfc@ietf.org" Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 17:16:30 -0000 --_000_CFF5646956E02andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with definition to be clear and flexible. If people really want to = change it , then here is an attempt to shorten theexisting definitions rath= er than replacing it: Service Function Path (SFP): The SFP provides a level of indirection betwee= n service chain (an abstract sequence of functions to be delivered) and SFF= s the packet will visit when it actually traverses the network. The use of this level of indirection, allow= s flexibility in a degree of SFF/SF instance selection that can be delegat= ed to the network. Andrew On 2014-07-23, 12:40 PM, "mikebianc@aol.com" wrot= e: Agreed. I think this is well written, clear, and neither restrictive nor = suggestive of any particular implementation. ________________________________ From: cpignata@cisco.com> To: Lucy yong> cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)>,sfc@ietf.org>,Linda Dunbar> Sent: Wednesday, July 23, 2014 Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From:sfc [mailto:sfc-bounces@ietf.org]On Behalf Of Sprecher, Nurit (NSN - I= L/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From:sfc [mailto:sfc-bounces@ietf.org]On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=92s wording than a term easily understood by engineers = (considering there are a lot of IETFers/engineers whose first language is n= ot English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets = of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CFF5646956E02andrewdolganowalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I agree with definition to be clear and flexible. If people really wan= t to change it , then here is an attempt to shorten theexisting definitions= rather than replacing it:

Service Function Path (SFP): The SFP provides a level of indirection&n= bsp;between service chain (an abstract sequence of functions to be del= ivered) and SFFs the packet will visit when it
actually traverses the network. The use of this level of indirection, allow= s flexibility in a degree of SFF/SF instance selection  that can be de= legated to the network.

Andrew

On 2014-07-23, 12:40 PM, "mi= kebianc@aol.com" wrote:


Agreed.   I think this is well written, clear, and neither restrictive= nor suggestive of any particular implementation.  


From: cpignata@cisco.com&l= t;cpignata@cisco.com>
To: Lucy yong<lucy.yong@h= uawei.com>
cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)<nurit.sprecher@nsn.com>,sfc@ietf.org<sfc@ietf.org>,Linda Dunbar<linda.dun= bar@huawei.com>
Sent: Wednesday, July 23, 2014
Subject: Re: [sfc] Simpler description of Service Function Path

Lucy, Linda, Nurit,

I do not think that a self-referencing definition will help -- i.e., I= am sure "A service function path is a path traversing service functio= ns" is correct but it's not particularly clarifying...

Stepping back a bit, this (proposed by Joel) is where we are and what = was discussed on the list and presented today.

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

I agree it's perhaps not the easiest English to parse, but nonetheless= is inclusive of all discussion and captures all key points, while excludes= noise.

What specific concerns do you have with this definition? (i.e., what m= eaning is missing?)

Thanks,

Carlos.

On Jul 23, 2014, at 11:00 AM, Lucy yong <lucy.yong@huawei.com> wrote:

How about:
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified.
Lucy
From:<= /span>sfc [mailto:sfc-bounces@ietf.org]On Behalf Of Sprecher, Nurit= (NSN - IL/Hod HaSharon)
Sent: Wednesday, July 2= 3, 2014 9:40 AM
To: Linda Dunbar; sfc@ietf.org
Subject: Re: [sfc] Simp= ler description of Service Function Path
I would propose to do it even simp= ler
Service Function Path (SFP):<= /o:p>
SFP is a path traversing a sequenc= e of service functions in a SFC-enabled domain. The path includes a sequenc= e of SFFs and/or SFs that can be explicitly or loosely specified. In case o= f a loosely specification, at least the ingress and the egress SFFs and/or SFs need to be specified.
From:<= /span>sfc [mailto= :sfc-bounces@ietf.org]O= n Behalf Of ext Linda Dunba= r
Sent: Wednesday, July 2= 3, 2014 5:05 PM
To: sfc@ietf.= org
Subject: [sfc] Simpler = description of Service Function Path
I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=92s wording than a term easily understood by engineers = (considering there are a lot of IETFers/engineers whose first language is n= ot English).
Here is my suggested simpler wording:
Service Function Path (SFP):
SFP is a pathway traversing a sequence of service function= s from ingress to egress of the SFC-enabled domain, including sequence of S= FFs and sequence of SFs. This sequence can be specified precisely with exac= t sequence of SFFs and the sequence of SFs reached by each SFF, loosely specified with sets of SFFs/SFs, or so= mewhere in between.
Linda
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 --_000_CFF5646956E02andrewdolganowalcatellucentcom_-- From nobody Wed Jul 23 10:20: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 E87BC1B2BBA for ; Wed, 23 Jul 2014 10:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 S3PHdMBrAtbG for ; Wed, 23 Jul 2014 10:20:20 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099F61A02F7 for ; Wed, 23 Jul 2014 10:18:28 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BEB70600DF; Wed, 23 Jul 2014 19:18:25 +0200 (CEST) Received: from ESTGVMSP112.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 9FDE9600CC; Wed, 23 Jul 2014 19:18:25 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.54) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 23 Jul 2014 19:18:24 +0200 Received: from DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) by DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 17:18:22 +0000 Received: from DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) by DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 17:18:22 +0000 From: DIEGO LOPEZ GARCIA To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture Thread-Index: Ac+mj6rt4GD2XbZYQgCzbZ2AyFkevgALMZAA//+7UYA= Date: Wed, 23 Jul 2014 17:18:22 +0000 Message-ID: <6EE20653-9756-498D-BE5E-84EC500AE18C@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@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: [31.133.161.176] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(164054003)(199002)(24454002)(252514010)(377454003)(110136001)(85852003)(76482001)(107046002)(86362001)(79102001)(54356999)(15975445006)(83072002)(46102001)(36756003)(16236675004)(33656002)(106356001)(50986999)(76176999)(64706001)(21056001)(77982001)(2656002)(81342001)(87936001)(74662001)(83716003)(92726001)(66066001)(95666004)(20776003)(15202345003)(82746002)(81542001)(92566001)(105586002)(85306003)(19580405001)(19580395003)(99396002)(31966008)(19617315012)(4396001)(80022001)(83322001)(101416001)(74502001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB252; H:DB3PR06MB252.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_6EE206539756498DBE5E84EC500AE18Ctelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DVYF9h01gjcdTgwbnYkNy8F0R1Q Cc: "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:20:31 -0000 --_000_6EE206539756498DBE5E84EC500AE18Ctelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I fully support this. I was starting to have the same concerns Carlos has j= ust expressed. Be goode, On 23 Jul 2014, at 12:24 , Carlos Pignataro (cpignata) > wrote: I would resist the urge to compete with Merriam-Webster and attempt to crea= te the largest dictionary in an RFC format. I sense we are going a bit over= board with adding definitions... Why would we want to add more definitions, particularly for phrases that ar= e not used in merged-sfc-arch? Conversely, if there is a document that needs the term =93Service Function = Instance=94 it should, by all means, define it within that context. merged-= sfc-arch should not have the goal of defining any potential SFC term that m= ight be used in some context. In other words, merged-sfc-arch should include the base set of terms (i.e.,= the ones are used within the architecture), and companion documents can au= gment as needed. Just my view. Thanks, Carlos. On Jul 23, 2014, at 12:03 PM, Linda Dunbar > wrote: I understand the concerns of authors of merged-arch not wanting to explicit= ly define the =93Service Function Instance=94. However, the term =93Service= Function Instance=94 has been used extensively on mailing list and in many= SFC drafts. Having a proper definition can make many drafts more clear. Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG. =93Service Function Instance: One instantiation of a service function. Some= SF instances are visible to SFF. Sometimes a collection of service functio= n instances can appear as one single entity to SFF. One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions." What do people think? Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- PLEASE NOTE MY NEW EMAIL ADDRESS "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_6EE206539756498DBE5E84EC500AE18Ctelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I fully support this. I was starting to have the same concerns Carlos has j= ust expressed.

Be goode,

On 23 Jul 2014, at 12:24 , Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

I would resist the urge to compete with= Merriam-Webster and attempt to create the largest dictionary in an RFC for= mat. I sense we are going a bit overboard with adding definitions...

Why would we want to add more definitions, particularly for phrases th= at are not used in merged-sfc-arch?

Conversely, if there is a document that needs the term =93Service= Function Instance=94 it should, by all means, define it within that contex= t. merged-sfc-arch should not have the goal of defining any potential SFC t= erm that might be used in some context.

In other words, merged-sfc-arch should include the base set of terms (= i.e., the ones are used within the architecture), and companion documents c= an augment as needed.

Just my view.

Thanks,

Carlos. 

On Jul 23, 2014, at 12:03 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

I understand the concerns of authors of merged-arch not wanting to explicit= ly define the =93Service Function Instance=94. However, the term =93Service= Function Instance=94 has been used extensively on mailing list and in many= SFC drafts. Having a proper definition can make many drafts more clear.
 
Here is the Service function Instances defined by draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture. Want to get feedback from the SFC WG.
 
=93Service Function Instance: One instantiation of a service function. Some= SF instances are visible to SFF. Sometimes a collection of service functio= n instances can appear as one single entity to SFF.
One service function could have multiple identical instances. For a service= function with different functional instantiations, e.g. one instantiation = applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), th= ey are considered as two different service functions."
 
What do people think?
 
Linda
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc<= /div>

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

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_6EE206539756498DBE5E84EC500AE18Ctelefonicacom_-- From nobody Wed Jul 23 10:25: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 3C31E1A0314 for ; Wed, 23 Jul 2014 10:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 yp27MaHpMOQ6 for ; Wed, 23 Jul 2014 10:25:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6021A02F1 for ; Wed, 23 Jul 2014 10:25:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL49251; Wed, 23 Jul 2014 17:25:01 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 18:25:00 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 10:24:50 -0700 From: Lucy yong To: Dave Dolson , Cathy Zhang , "Joel M. Halpern" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoVK8qun5O3hbkONXzULFkEs+puuMzoA//+L5yCAAHbIAIAAAuoA//+Nl1CAAIIbgP//nieA Date: Wed, 23 Jul 2014 17:24:49 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C2D8C@dfweml701-chm.china.huawei.com> References: <53CFCB55.4040408@joelhalpern.com> <53CFCBBC.1050708@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C03@dfweml701-chm.china.huawei.com> <53CFCDFC.6020602@joelhalpern.com> <2691CE0099834E4A9C5044EEC662BB9D453C2C97@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.132.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/pyO-sRslSuOQy3p8W6vksp_t3Ng Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 17:25:06 -0000 In this case, other info such as outer label is used as the lookup key. Suggest defining SP ID 0 as of NULL.=20 Lucy -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Wednesday, July 23, 2014 11:07 AM To: Lucy yong; Cathy Zhang; Joel M. Halpern; Dolganow, Andrew (Andrew); sfc= @ietf.org Subject: RE: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence What is the next hop when receiving such a packet? I think the forwarding table for ID 0 would need to be configured. But then any ID could be used, and 0 is just a convention vs. a special cas= e that the protocol needs to define. So, I'm saying: - there is no need for any specification of service chaining without a chai= n ID. ID is always required, but you can have only one chain if you wish. - Keep it simple; avoid special cases. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, July 23, 2014 11:18 AM To: Cathy Zhang; Joel M. Halpern; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence Just set SP ID 0. Use index for TTL purpose. Lucy -----Original Message----- From: Cathy Zhang Sent: Wednesday, July 23, 2014 10:11 AM To: Joel M. Halpern; Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: RE: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence I agree with Joel. For better interoperability, we can just keep the 4 byte= s and set them to 0 to indicate "only metadata present". Actually "only met= adata present" is addressed in SCH header draft presented in today's meetin= g.=20 Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, July 23, 2014 8:00 AM To: Lucy yong; Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - option= al presence We could allow the null case. But is there a significant advantage in omit= ting the SFP-ID + Path Inex, when it is not needed? WHen we get to the details of the solution behavior, I would like it to be = clear that the index does not need to be updated if it is not being used. = (i.e. what it indexes are the places that use the Path ID + index, which is= well-defined.) But I don't mind having the 4 bytes there. It seems to significantly impro= ve interoperability. Yours, Joel On 7/23/14, 10:53 AM, Lucy yong wrote: > We also need the option in header where only metadata present, i.e. no SF= P ID + Index present. > Lucy > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, July 23, 2014 9:51 AM > To: Dolganow, Andrew (Andrew); sfc@ietf.org > Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -=20 > optional presence > > Clarification, not "none", but "only SFP ID + SFP Index present." > > Yours, > Joel > > On 7/23/14, 10:48 AM, Joel M. Halpern wrote: >> I had read the MD-type as doing exactly this. So we should simply=20 >> allocate an MD Type that means "no mandatory header." >> >> Yours, >> Joel >> >> On 7/23/14, 10:30 AM, Dolganow, Andrew (Andrew) wrote: >>> Following discussion during the meeting today, here is a specific=20 >>> comment on how to Change NSH to allow constant-size, easy-to-process=20 >>> in H/W Context Header while also allowing for deployments that do=20 >>> not need to include the header: >>> >>> 1. Keep existing format as per draft section 6 but rename from >>> Mandatory Context Header to Context Header 2. Make the=20 >>> presence of header optional and encode presence/absence >>> using a bit in Base header - proposed change text (in red): >>> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 >>> +-+-+-+-+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>> |Ver|O|C|CHP|R|R|R|R|R| Length | MD Type | Next Protoco= l | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> CHP -Context Header Present. If specified, Context Header as=20 >>> specified in section 5 below follows directly Service Path Header >>> >>> Andrew >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 23 10:45: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 8201E1B2BAD for ; Wed, 23 Jul 2014 10:44:52 -0700 (PDT) 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 q2Nejr6la9k4 for ; Wed, 23 Jul 2014 10:44:50 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA311B2BEE for ; Wed, 23 Jul 2014 10:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id E9D2B260AD2; Wed, 23 Jul 2014 10:44:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from dhcp-955b.meeting.ietf.org (dhcp-955b.meeting.ietf.org [31.133.149.91]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 5E7E6260ACE; Wed, 23 Jul 2014 10:44:32 -0700 (PDT) Message-ID: <53CFF47F.4010603@joelhalpern.com> Date: Wed, 23 Jul 2014 13:44:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Linda Dunbar , "sfc@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DA2D2A@dfweml701-chm.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/DoWA_NQvN4R6kXqh3cHilm4SUaE Subject: Re: [sfc] Service Function Instance defined by draft-dunbar-sfc-legacy-l4-l7-chain-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:44:52 -0000 I am concerned that in most discussions people expect service chaining to work in terms of what is being called service function instances. If we define the instances to mean the real individual instance (which is the most understandable definition), then every time we talk about it we are going to have to say SFI or cluster. This is because what appears as one entity to service chaining is what we need to refer to in most discussions. If we want a term for this, we should have a term that actually corresponds to what we need to discuss. I have not so far been able to think of a term that is not a mouthful that we could use. As an example of an ugly term, we could use Service Function Realization (SFR?). If we need to name this, presumably because we expect other documents to use it, then we need to give it a useable name that describes what we need to discuss. Yours, Joel On 7/23/14, 12:03 PM, Linda Dunbar wrote: > I understand the concerns of authors of merged-arch not wanting to > explicitly define the “Service Function Instance”. However, the term > “Service Function Instance” has been used extensively on mailing list > and in many SFC drafts. Having a proper definition can make many drafts > more clear. > > Here is the Service function Instances defined by > draft-dunbar-sfc-legacy-l4-l7-chain-architecture. Want to get feedback > from the SFC WG. > > “Service Function Instance: One instantiation of a service function. > Some SF instances are visible to SFF. Sometimes a collection of service > function instances can appear as one single entity to SFF. > > One service function could have multiple identical instances. For a > service function with different functional instantiations, e.g. one > instantiation applies policy-set-A (NAT44-A) and other applies > policy-set-B (NAT44-B), they are considered as two different service > functions." > > What do people think? > > Linda > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jul 23 11:22: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 2F85A1A0460 for ; Wed, 23 Jul 2014 11:22:16 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 usCTzkANBpuu for ; Wed, 23 Jul 2014 11:22:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4F01B2AE8 for ; Wed, 23 Jul 2014 11:22:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN46065; Wed, 23 Jul 2014 18:22:03 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 19:22:02 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.129]) by dfweml706-chm.china.huawei.com ([169.254.8.145]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 11:21:52 -0700 From: Lucy yong To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCAADQr7AAAF9CNQ Date: Wed, 23 Jul 2014 18:21:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453C2E27@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> In-Reply-To: <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.165] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D453C2E27dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/jjs6lCbumyLnJsHKzG-bEsrewZM Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 18:22:16 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D453C2E27dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel's proposed text is clear and does not miss anything. Easier reading wa= s suggested. Lucy From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, July 23, 2014 11:16 AM To: Lucy yong Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_2691CE0099834E4A9C5044EEC662BB9D453C2E27dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joel’s proposed tex= t is clear and does not miss anything. Easier reading was suggested.=

Lucy

 <= /p>

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Wednesday, July 23, 2014 11:16 AM
To: Lucy yong
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); Linda Dunbar; sfc@ietf.= org
Subject: Re: [sfc] Simpler description of Service Function Path=

 

Lucy, Linda, Nurit,

 

I do not think that a self-referencing definition wi= ll help -- i.e., I am sure "A service function path is a path traversi= ng service functions" is correct but it's not particularly clarifying.= ..

 

Stepping back a bit, this (proposed by Joel) is wher= e we are and what was discussed on the list and presented today.=

 

   Service = Function Path (SFP):  The SFP provides a level of indir= ection
        between the fully abstract notion of servi= ce chain as a sequence
        of functions to be delivered, and the full= y specified notion of
        exactly what instances of SFFs the packet = will visit when it
        actually traverses the network.  = ;By allowing the control
        components to specify the use of this leve= l of indirection, the
        deployment may choose the degree of SFF/SF= instance selection
        authority that is delegated to the network= .

I agree it's perhaps not the easiest English to pars= e, but nonetheless is inclusive of all discussion and captures all key poin= ts, while excludes noise. 

 

What specific concerns do you have with this definit= ion? (i.e., what meaning is missing?)

 

Thanks,

 

Carlos.

 

On Jul 23, 2014, at 11:00 AM, Lucy yong <lucy.yong@huawei.com> wrote:



How about:

 

SFP is a path traversing = a sequence of service functions in a SFC-enabled domain. The path includes = a sequence of SFFs and/or SFs that can be explicitly or loosely specified.  

 

Lucy<= o:p>

 

 

From: sfc [mailto:sfc-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Sprecher, Nurit (NSN - IL/Hod = HaSharon)
Sent: Wednesday, J= uly 23, 2014 9:40 AM
To: Linda Dunbar; = sfc@ietf.org
Subject: Re: [sfc]= Simpler description of Service Function Path

 

I would propose to do it = even simpler

Service Function Path (SF= P):

SFP is a path traversing = a sequence of service functions in a SFC-enabled domain. The path includes = a sequence of SFFs and/or SFs that can be explicitly or loosely specified. In case of a loosely specification, at least the ingres= s and the egress SFFs and/or  SFs need to be specified.

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of ext Linda Dunbar
Sent: Wednesday, J= uly 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Sim= pler description of Service Function Path

 

I think the SFP definition displayed at= today SFC session is too complicated, more like lawyer’s wording tha= n a term easily understood by engineers (considering there are a lot of IETFers/engineers whose first language is not English).

 

Here is my suggested simpler wording:

 

Service Function Path (SFP):=

SFP is a pathway traversing a sequence = of service functions from ingress to egress of the SFC-enabled domain, incl= uding sequence of SFFs and sequence of SFs. This sequence can be specified precisely with exact sequence of SFFs and the sequence of= SFs reached by each SFF,  loosely specified with sets of SFFs/SFs, or= somewhere in between.

 

Linda

______________________________________= _________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 

--_000_2691CE0099834E4A9C5044EEC662BB9D453C2E27dfweml701chmchi_-- From nobody Wed Jul 23 11:44: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 E32FA1B29A4 for ; Wed, 23 Jul 2014 11:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 IirY-DqjBrE1 for ; Wed, 23 Jul 2014 11:44:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3321A0026 for ; Wed, 23 Jul 2014 11:44:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN47074; Wed, 23 Jul 2014 18:44:25 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 19:44:24 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 02:44:13 +0800 From: Xuxiaohu To: Cathy Zhang , "Henderickx, Wim (Wim)" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoM99gHcgYqlqk6zE24/qgQBr5utPvAAgAC+7X8= Date: Wed, 23 Jul 2014 18:44:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72@NKGEML512-MBS.china.huawei.com> References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.202] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8N5pHqiHa00WFHzF9xqqpD9biBs Subject: [sfc] =?gb2312?b?tPC4tDogIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBI?= =?gb2312?b?ZWFkZXIgaW4gTlNIIGRyYWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2U=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 18:44:29 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGlkIHlvdSBtZWFuIHRoZSBMZW5ndGggZmllbGQgaW4gdGhlIFZhcmlhYmxlIENvbnRleHQgSGVh ZGVycyBieSBNZXRhZGF0YSBMZW5ndGggZmllbGQ/IElmIHNvLCBkbyB5b3Ugd2FudCB0byB1c2Ug YSBmaWVsZCBpbiB0aGUgb3B0aW9uYWwgdmFyaWFibGUgbGVuZ3RoIGNvbnRleHQgaGVhZGVycyB0 byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIGZvdXIgNC1ieXRlDQpjb250ZXh0IGhlYWRl ciBvdXRzaWRlIG9mIHRoZSBvcHRpb25hbCB2YXJpYWJsZSBsZW5ndGggY29udGV4dCBoZWFkZXJz Pw0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQq3orz+yMs6IHNmYyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g Q2F0aHkgWmhhbmcgW0NhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCreiy83KsbzkOiAyMDE0xOo3 1MIyM8jVIDIzOjE2DQrK1bz+yMs6IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgRG9sZ2Fub3csIEFu ZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gQ2hhbmdlIHRvIE1h bmRhdG9yeSBDb250ZXh0IEhlYWRlciBpbiBOU0ggZHJhZnQgLSBvcHRpb25hbCBwcmVzZW5jZQ0K DQpNZXRhZGF0YSBMZW5ndGggZmllbGQgc2VydmVzIHRoZSBwdXJwb3NlIHdlbGwuDQoNCkNhdGh5 DQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SGVuZGVyaWNreCwgV2ltIChXaW0pDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNzoz NCBBTQ0KVG86IERvbGdhbm93LCBBbmRyZXcgKEFuZHJldyk7IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzZmNdIENoYW5nZSB0byBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgaW4gTlNIIGRy YWZ0IC0gb3B0aW9uYWwgcHJlc2VuY2UNCg0KSSBhZ3JlZSB3ZSBzaG91bGQga2VlcCB0aGUgaGVh ZGVyIGFzIHNtYWxsIGFzIHBvc3NpYmxlIGFuZCBhcyBzdWNoIEkgYWxzbyBiZWxpZXZlIHdlIGRv bqGvdCBuZWVkIHRoZSBtYW5kYXRvcnkgQ3R4dCBmaWVsZCB0byBiZSBwcmVzZW50Lg0KQW4gYWx0 ZXJuYXRpdmUgdG8gdGhlIENIUCBiaXQgY291bGQgYmUgdG8gdXNlIGxlbmd0aCBvciBNRC1UeXBl IHRvIGluZGljYXRlIGl0cyBwcmVzZW5jZS4NCg0KRnJvbTogPERvbGdhbm93PiwgIkFuZHJldyAo QW5kcmV3KSIgPGFuZHJldy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFuZHJl dy5kb2xnYW5vd0BhbGNhdGVsLWx1Y2VudC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5IDIzIEp1bHkg MjAxNCAxMDozMA0KVG86ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc2ZjXSBDaGFuZ2UgdG8g TWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNlbmNl DQoNCkZvbGxvd2luZyBkaXNjdXNzaW9uIGR1cmluZyB0aGUgbWVldGluZyB0b2RheSwgaGVyZSBp cyBhIHNwZWNpZmljIGNvbW1lbnQgb24gaG93IHRvIENoYW5nZSBOU0ggdG8gYWxsb3cgY29uc3Rh bnQtc2l6ZSwgZWFzeS10by1wcm9jZXNzIGluIEgvVyBDb250ZXh0IEhlYWRlciB3aGlsZSBhbHNv IGFsbG93aW5nIGZvciBkZXBsb3ltZW50cyB0aGF0IGRvIG5vdCBuZWVkIHRvIGluY2x1ZGUgdGhl IGhlYWRlcjoNCg0KDQogIDEuICBLZWVwIGV4aXN0aW5nIGZvcm1hdCBhcyBwZXIgZHJhZnQgc2Vj dGlvbiA2IGJ1dCByZW5hbWUgZnJvbSBNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXIgdG8gQ29udGV4 dCBIZWFkZXINCiAgMi4gIE1ha2UgdGhlIHByZXNlbmNlIG9mIGhlYWRlciBvcHRpb25hbCBhbmQg ZW5jb2RlIHByZXNlbmNlL2Fic2VuY2UgdXNpbmcgIGEgYml0IGluIEJhc2UgaGVhZGVyIKhDIHBy b3Bvc2VkIGNoYW5nZSB0ZXh0IChpbiByZWQpOg0KDQogICAgICAwIDEgMiAzICA0ICA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQogICAgICst Ky0rLSstKy0tLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCg0KICAgICB8VmVyfE98Q3xDSFB8UnxSfFJ8UnxSfCAgIExlbmd0aCAgfCAgICBN RCBUeXBlICAgIHwgTmV4dCBQcm90b2NvbCB8DQoNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KQ0hQIKhDQ29u dGV4dCBIZWFkZXIgUHJlc2VudC4gSWYgc3BlY2lmaWVkLCBDb250ZXh0IEhlYWRlciBhcyBzcGVj aWZpZWQgaW4gc2VjdGlvbiA1IGJlbG93ICBmb2xsb3dzIGRpcmVjdGx5IFNlcnZpY2UgUGF0aCBI ZWFkZXINCg0KQW5kcmV3DQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Did you mean the Length field in the Variable Context Headers by Metadata Length field? If so, do you want to use a field in the optional variable length context headers to indicate the presence of= the four 4-byte
context header outside of the optional varia= ble length context headers?

&nb= sp;

Best regards,

Xiaohu



=B7=A2=BC=FE=C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED = Cathy Zhang [Cathy.H.Zhang@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5 23:16
=CA=D5=BC=FE=C8=CB: Henderickx, Wim (Wim); Dolganow, Andrew (Andrew)= ; sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Change to Mandatory Context Header in NSH dr= aft - optional presence

Metadata Length field= serves the purpose well.

 

Cathy

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 23, 2014 7:34 AM
To: Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -= optional presence

 

I ag= ree we should keep the header as small as possible and as such I also belie= ve we don=A1=AFt need the mandatory Ctxt field to be present.

An a= lternative to the CHP bit could be to use length or MD-Type to indicate its= presence. 

 

From: <Dolganow>, "Andrew (Andrew)" <= ;an= drew.dolganow@alcatel-lucent.com>
Date: Wednesday 23 July 2014 10:30
To: "sfc@ietf= .org" <sfc@ie= tf.org>
Subject: [sfc] Change to Mandatory Context Header in NSH draft - opt= ional presence

 

Foll= owing discussion during the meeting today, here is a specific comment on ho= w to Change NSH to allow constant-size, easy-to-process in H/W Context Head= er while also allowing for deployments that do not need to include the header:

 

  1. Keep existing format as per draft section 6 but rename from Mandatory= Context Header to Context Header 
  2. Make the presence of header optional and encode presence/absence= using  a bit in Base header =A8C proposed change text (in red):
  =
;    0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
 2 3 4 5 6 7 8 9 0 1
  =
;   +-+-+-+-+---+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+

  =
;   |Ver|O|C|CHP|R|R|R|R|R|   Length  |  &nbs=
p; MD Type    | Next Protocol |


  =
;   +-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+

 

CHP = =A8CContext Header Present. If specified, Context Header as specified in se= ction 5 below  follows directly Service Path Header

 

Andrew=

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72NKGEML512MBSchi_-- From nobody Wed Jul 23 11: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 723A01A00E9 for ; Wed, 23 Jul 2014 11:54:24 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 n2aP76-SZY3Q for ; Wed, 23 Jul 2014 11:54:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D171A0320 for ; Wed, 23 Jul 2014 11:54:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL53372; Wed, 23 Jul 2014 18:54:11 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 19:54:10 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 02:53:59 +0800 From: Jiangyuanlong To: "Carlos Pignataro (cpignata)" , Lucy yong Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCAADQr7AAAF1RkQ Date: Wed, 23 Jul 2014 18:53:58 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EB@szxema506-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> In-Reply-To: <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.227] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EBszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0-hhPUr3d6lBzJGZgXGlCe-x9n4 Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jul 2014 18:54:24 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EBszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carlos, Maybe I miss something, I see "instances of SFF" and 'SFF/SF instance" in t= he definition of SFP, but could not find any use of "SFF instance" in the t= exts. Are you proposing that both SFF and SF are abstracted concepts? Why we intr= oduce "SFF instance" but never use it in the context? Regards, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Thursday, July 24, 2014 12:16 AM To: Lucy yong Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EBszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carlos,

 

Maybe I miss something, I see &= #8220;instances of SFF” and ‘SFF/SF instance” in the defi= nition of SFP, but could not find any use of “SFF instance” in = the texts.

Are you proposing that both SFF and SF are abstrac= ted concepts? Why we introduce “SFF instance” but never use it in the context?

 

Regards,

Yuanlong

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Thursday, July 24, 2014 12:16 AM
To: Lucy yong
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dun= bar
Subject: Re: [sfc] Simpler description of Service Function Path=

 

Lucy, Linda, Nurit, =

 

I do not think that a self-refe= rencing definition will help -- i.e., I am sure "A service function pa= th is a path traversing service functions" is correct but it's not par= ticularly clarifying...

 

Stepping back a bit, this (prop= osed by Joel) is where we are and what was discussed on the list and presen= ted today.

 

=    Service Function Path (SFP):  The SFP prov= ides a level of indirection
        between the fully abstract notion of servi= ce chain as a sequence
        of functions to be delivered, and the full= y specified notion of
        exactly what instances of SFFs the packet = will visit when it
        actually traverses the network.  = ;By allowing the control
        components to specify the use of this leve= l of indirection, the
        deployment may choose the degree of SFF/SF= instance selection
        authority that is delegated to the network= .

I agree it's perhaps not the ea= siest English to parse, but nonetheless is inclusive of all discussion and = captures all key points, while excludes noise. 

 

What specific concerns do you h= ave with this definition? (i.e., what meaning is missing?)

 

Thanks,

 

Carlos.

 

On Jul 23, 2014, at 11:00 AM, L= ucy yong <lucy.yong@huawei.com> wrote:



How about:=

 

SFP is a path traversing a sequence of service functions= in a SFC-enabled domain. The path includes a sequence of SFFs and/or SFs that can be explicitly or loosely specified.  

 

Lucy

 

 

From: sfc [mailto:sfc-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Sprecher, Nurit (NSN - IL/Hod = HaSharon)
Sent: Wednesday, J= uly 23, 2014 9:40 AM
To: Linda Dunbar; = sfc@ietf.org
Subject: Re: [sfc]= Simpler description of Service Function Path

 =

I would pr= opose to do it even simpler

Service Fu= nction Path (SFP):

SFP is a path traversing a sequence of service functions= in a SFC-enabled domain. The path includes a sequence of SFFs and/or SFs that can be explicitly or loosely specified. In case of a loose= ly specification, at least the ingress and the egress SFFs and/or  SFs= need to be specified.=

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of ext Linda Dunbar
Sent: Wednesday, J= uly 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Sim= pler description of Service Function Path

 =

I think the SFP definiti= on displayed at today SFC session is too complicated, more like lawyer̵= 7;s wording than a term easily understood by engineers (considering there are a lot of IETFers/engineers whose first language is not English).=

 =

Here is my suggested sim= pler wording:

 =

Service Function Path (S= FP):

SFP is a pathway traversing a sequence of service functions from ingre= ss to egress of the SFC-enabled domain, including sequence of SFFs and sequence of SFs. This sequence can be specified precisely with ex= act sequence of SFFs and the sequence of SFs reached by each SFF,  loo= sely specified with sets of SFFs/SFs, or somewhere in between.

 =

Linda

_______________________= ________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EBszxema506mbschi_-- From nobody Thu Jul 24 07:48: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 9F5661A03B7 for ; Thu, 24 Jul 2014 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 n4yqfIOXrFPn for ; Thu, 24 Jul 2014 07:48:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED9C1A036E for ; Thu, 24 Jul 2014 07:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25057; q=dns/txt; s=iport; t=1406213297; x=1407422897; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GLs1HxPsuIUr072bNPgwR/FxqyUDA6m37IodVrjP5VQ=; b=V4NzpyQ1ex3HM/LHJSFBCTM2MqHXIZYBMPiBkhnyCG3BQouRMnMuF/Ed xDzxH834QRtdv1J4adAOEUbO7NMRSZhHWnS75+iZQgl015TvLooprJTzD SMVj2dFVS3QMQYJA4VbGi+WDdpThpnPpf5MttjI0Wmq/H9sXYAC0hxYQi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIMb0VOtJV2T/2dsb2JhbABZgkdHUlcEySkBCYdFAYENFneEAwEBAQQBAQFrCxACAQgRBAEBIQcHJwsUCQgBAQQOBYhCDcBpEwSPRwQGAYMugRgFjkiMa4wCiECDSGyBRQ X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208,217";a="342623699" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jul 2014 14:48:16 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEmGNK025145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 14:48:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:48:15 -0500 From: "Carlos Pignataro (cpignata)" To: Jiangyuanlong Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCAADQr7AAAF1RkQAClpuoA= Date: Thu, 24 Jul 2014 14:48:14 +0000 Message-ID: <9C41B423-3E82-4B3E-BE06-F86856F2A0A4@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EB@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EB@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/alternative; boundary="_000_9C41B4233E824B3EBE06F86856F2A0A4ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/a633cFDkKG6aC489SO-NHpi6Aoc Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Jul 2014 14:48:19 -0000 --_000_9C41B4233E824B3EBE06F86856F2A0A4ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Yuanlong, This is a good callout -- thanks. We will scrub through the use of "instanc= e" as part of incorporating the SFP definition and feedback. Thanks! Carlos. On Jul 23, 2014, at 2:53 PM, Jiangyuanlong > wrote: Hi Carlos, Maybe I miss something, I see =93instances of SFF=94 and =91SFF/SF instance= =94 in the definition of SFP, but could not find any use of =93SFF instance= =94 in the texts. Are you proposing that both SFF and SF are abstracted concepts? Why we intr= oduce =93SFF instance=94 but never use it in the context? Regards, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Thursday, July 24, 2014 12:16 AM To: Lucy yong Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer=92s wording than a term easily understood by engineers = (considering there are a lot of IETFers/engineers whose first language is n= ot English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_9C41B4233E824B3EBE06F86856F2A0A4ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Yuanlong,

This is a good callout -- thanks. We will scrub through the use of &qu= ot;instance" as part of incorporating the SFP definition and feedback.=

Thanks!

Carlos.

On Jul 23, 2014, at 2:53 PM, Jiangyuanlong <jiangyuanlong@huawei.com> wrote:

Hi Carlos,
 
Maybe I miss something, I see =93instances of SFF=94 a= nd =91SFF/SF instance=94 in the definition of SFP, but could not find any u= se of =93SFF instance=94 in the texts.
Are you proposing that both SFF and SF are abstr= acted concepts? Why we introduce =93SFF instance=94 but never u= se it in the context?
 
Regards,
Yuanlong
 
From: = sfc [mailto:sfc-bounces@ietf= .org] On Behalf Of Carlos Pig= nataro (cpignata)
Sent: Thursday, Ju= ly 24, 2014 12:16 AM
To: Lucy yong
Cc: Sprecher, Nuri= t (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc]= Simpler description of Service Function Path
 
Lucy, Linda, Nurit,
 
I do not think that a self-referencing definition will= help -- i.e., I am sure "A service function path is a path traversing= service functions" is correct but it's not particularly clarifying...=
 
Stepping back a bit, this (proposed by Joel) is where = we are and what was discussed on the list and presented today.
 

   Service Function Path (SFP):  T= he SFP provides a level of indirection
        between the fully abstract notion of servi= ce chain as a sequence
        of functions to be delivered, and the full= y specified notion of
        exactly what instances of SFFs the packet = will visit when it
        actually traverses the network.  = ;By allowing the control
        components to specify the use of this leve= l of indirection, the
        deployment may choose the degree of SFF/SF= instance selection
        authority that is delegated to the network= .

I agree it's perhaps not the easiest English to parse,= but nonetheless is inclusive of all discussion and captures all key points= , while excludes noise. 
 
What specific concerns do you have with this definitio= n? (i.e., what meaning is missing?)
 
Thanks,
 
Carlos.
 
On Jul 23, 2014, at 11:00 AM, Lucy yong <lucy.yong@huawei.com> wrote:


How about:<= /div>
 
SFP is a path traversing a sequence of serv= ice functions in a SFC-enabled domain. The path includes a sequence of SFFs= and/or SFs that can be explicitly or loosely specified.  
 
Lucy
 
 
From:&nbs= p;sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, J= uly 23, 2014 9:40 AM
To: Linda Dunbar;<= span class=3D"Apple-converted-space"> sfc@ietf.org
Subject: Re: [sfc]= Simpler description of Service Function Path
 
I would propose to do it even simpler
Service Function Path (SFP):<= o:p>
SFP is a path traversing a sequence of serv= ice functions in a SFC-enabled domain. The path includes a sequence of SFFs= and/or SFs that can be explicitly or loosely specified. In case of a loosely specification, at least the ingres= s and the egress SFFs and/or  SFs need to be specified.<= o:p>
 
 
From:&nbs= p;sfc [mailto:sfc-bounces@ietf.= org] On Beh= alf Of ext Linda Dunbar
Sent: Wednesday, J= uly 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Sim= pler description of Service Function Path<= /div>
 
I think the SFP definition displayed at today SFC session is too com= plicated, more like lawyer=92s wording than a term easily understood by eng= ineers (considering there are a lot of IETFers/engineers whose first language is not English).<= /div>
 
Here is my suggested simpler wording:
 
Service Function Path (SFP):
SFP is a pathway traversing a sequence of service functions from ing= ress to egress of the SFC-enabled domain, including sequence of SFFs and se= quence of SFs. This sequence can be specified precisely with exact sequence of SFFs and the sequence of SFs re= ached by each SFF,  loosely specified with sets of SFFs/SFs, or somewh= ere in between.
 
Linda
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_9C41B4233E824B3EBE06F86856F2A0A4ciscocom_-- From nobody Thu Jul 24 09:45: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 80FC71A03F2 for ; Thu, 24 Jul 2014 09:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Or0fiYJAHC-a for ; Thu, 24 Jul 2014 09:45:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D611F1A0453 for ; Thu, 24 Jul 2014 09:45:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHO37063; Thu, 24 Jul 2014 16:45:03 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 17:45:02 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 09:44:51 -0700 From: Cathy Zhang To: Xuxiaohu , "Henderickx, Wim (Wim)" , "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: [sfc] Change to Mandatory Context Header in NSH draft - optional presence Thread-Index: AQHPpoM+vL3tn2ifbUuNY1AXq6MpkputxDwggACwSICAAPnzsA== Date: Thu, 24 Jul 2014 16:44:50 +0000 Message-ID: References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296F72@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.110] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418F6C6B5SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ss3Zz5hay70tSWFnx-8_hv1i2C8 Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional presence X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Jul 2014 16:45:09 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418F6C6B5SJCEML702CHMchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB3YXMgcmVmZXJyaW5nIHRvIHRoZSChsG1ldGFkYXRhIGxlbmd0aKGxIGZpZWxkIGRlZmluZWQg aW4gU0NIIGRyYWZ0IChhcyBzaG93biBpbiBGaWd1cmUgMSBhbmQgZGVzY3JpYmVkIGluIHNlY3Rp b24gNC4yIG9mIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2Zj LXNjaC8/aW5jbHVkZV90ZXh0PTEpLg0KDQpDYXRoeQ0KDQpGcm9tOiBYdXhpYW9odQ0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDExOjQ0IEFNDQpUbzogQ2F0aHkgWmhhbmc7IEhlbmRl cmlja3gsIFdpbSAoV2ltKTsgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2ZjQGlldGYub3Jn DQpTdWJqZWN0OiC08Li0OiBbc2ZjXSBDaGFuZ2UgdG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVy IGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNlbmNlDQoNCg0KRGlkIHlvdSBtZWFuIHRoZSBM ZW5ndGggZmllbGQgaW4gdGhlIFZhcmlhYmxlIENvbnRleHQgSGVhZGVycyBieSBNZXRhZGF0YSBM ZW5ndGggZmllbGQ/IElmIHNvLCBkbyB5b3Ugd2FudCB0byB1c2UgYSBmaWVsZCBpbiB0aGUgb3B0 aW9uYWwgdmFyaWFibGUgbGVuZ3RoIGNvbnRleHQgaGVhZGVycyB0byBpbmRpY2F0ZSB0aGUgcHJl c2VuY2Ugb2YgdGhlIGZvdXIgNC1ieXRlDQpjb250ZXh0IGhlYWRlciBvdXRzaWRlIG9mIHRoZSBv cHRpb25hbCB2YXJpYWJsZSBsZW5ndGggY29udGV4dCBoZWFkZXJzPw0KDQoNCg0KQmVzdCByZWdh cmRzLA0KDQpYaWFvaHUNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IHNmYyBbc2ZjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQ2F0aHkgWmhhbmcgW0NhdGh5 LkguWmhhbmdAaHVhd2VpLmNvbV0NCreiy83KsbzkOiAyMDE0xOo31MIyM8jVIDIzOjE2DQrK1bz+ yMs6IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgRG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KTsgc2Zj QGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gQ2hhbmdlIHRvIE1hbmRhdG9yeSBDb250ZXh0IEhl YWRlciBpbiBOU0ggZHJhZnQgLSBvcHRpb25hbCBwcmVzZW5jZQ0KTWV0YWRhdGEgTGVuZ3RoIGZp ZWxkIHNlcnZlcyB0aGUgcHVycG9zZSB3ZWxsLg0KDQpDYXRoeQ0KDQpGcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbmRlcmlja3gsIFdpbSAoV2lt KQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDc6MzQgQU0NClRvOiBEb2xnYW5vdywg QW5kcmV3IChBbmRyZXcpOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBDaGFuZ2Ug dG8gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIGluIE5TSCBkcmFmdCAtIG9wdGlvbmFsIHByZXNl bmNlDQoNCkkgYWdyZWUgd2Ugc2hvdWxkIGtlZXAgdGhlIGhlYWRlciBhcyBzbWFsbCBhcyBwb3Nz aWJsZSBhbmQgYXMgc3VjaCBJIGFsc28gYmVsaWV2ZSB3ZSBkb26hr3QgbmVlZCB0aGUgbWFuZGF0 b3J5IEN0eHQgZmllbGQgdG8gYmUgcHJlc2VudC4NCkFuIGFsdGVybmF0aXZlIHRvIHRoZSBDSFAg Yml0IGNvdWxkIGJlIHRvIHVzZSBsZW5ndGggb3IgTUQtVHlwZSB0byBpbmRpY2F0ZSBpdHMgcHJl c2VuY2UuDQoNCkZyb206IDxEb2xnYW5vdz4sICJBbmRyZXcgKEFuZHJldykiIDxhbmRyZXcuZG9s Z2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzphbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1s dWNlbnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSAyMyBKdWx5IDIwMTQgMTA6MzANClRvOiAic2Zj QGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NmY10gQ2hhbmdlIHRvIE1hbmRhdG9yeSBDb250ZXh0IEhl YWRlciBpbiBOU0ggZHJhZnQgLSBvcHRpb25hbCBwcmVzZW5jZQ0KDQpGb2xsb3dpbmcgZGlzY3Vz c2lvbiBkdXJpbmcgdGhlIG1lZXRpbmcgdG9kYXksIGhlcmUgaXMgYSBzcGVjaWZpYyBjb21tZW50 IG9uIGhvdyB0byBDaGFuZ2UgTlNIIHRvIGFsbG93IGNvbnN0YW50LXNpemUsIGVhc3ktdG8tcHJv Y2VzcyBpbiBIL1cgQ29udGV4dCBIZWFkZXIgd2hpbGUgYWxzbyBhbGxvd2luZyBmb3IgZGVwbG95 bWVudHMgdGhhdCBkbyBub3QgbmVlZCB0byBpbmNsdWRlIHRoZSBoZWFkZXI6DQoNCg0KICAxLiAg S2VlcCBleGlzdGluZyBmb3JtYXQgYXMgcGVyIGRyYWZ0IHNlY3Rpb24gNiBidXQgcmVuYW1lIGZy b20gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVyIHRvIENvbnRleHQgSGVhZGVyDQogIDIuICBNYWtl IHRoZSBwcmVzZW5jZSBvZiBoZWFkZXIgb3B0aW9uYWwgYW5kIGVuY29kZSBwcmVzZW5jZS9hYnNl bmNlIHVzaW5nICBhIGJpdCBpbiBCYXNlIGhlYWRlciCoQyBwcm9wb3NlZCBjaGFuZ2UgdGV4dCAo aW4gcmVkKToNCg0KICAgICAgMCAxIDIgMyAgNCAgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCg0KICAgICArLSstKy0rLSstLS0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgfFZl cnxPfEN8Q0hQfFJ8UnxSfFJ8UnwgICBMZW5ndGggIHwgICAgTUQgVHlwZSAgICB8IE5leHQgUHJv dG9jb2wgfA0KDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCkNIUCCoQ0NvbnRleHQgSGVhZGVyIFByZXNlbnQu IElmIHNwZWNpZmllZCwgQ29udGV4dCBIZWFkZXIgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNSBi ZWxvdyAgZm9sbG93cyBkaXJlY3RseSBTZXJ2aWNlIFBhdGggSGVhZGVyDQoNCkFuZHJldw0KDQo= --_000_A2C96F6779E6A041BC7023CC207FC99418F6C6B5SJCEML702CHMchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable --_000_A2C96F6779E6A041BC7023CC207FC99418F6C6B5SJCEML702CHMchi_-- From nobody Thu Jul 24 10:43: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 398311A854D for ; Thu, 24 Jul 2014 10:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 ywTIK0mj9yaY for ; Thu, 24 Jul 2014 10:43:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD901A0B10 for ; Thu, 24 Jul 2014 10:43:41 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s6OHhdap011515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jul 2014 12:43:40 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s6OHhdaX022331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 13:43:39 -0400 Received: from US70TWXCHMBA07.zam.alcatel-lucent.com ([169.254.1.245]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 13:43:39 -0400 From: "Almalki, Safa (Safa)" To: "sfc@ietf.org" Thread-Topic: draft-merged-sfc-architecture-00 & Classifiers. Thread-Index: Ac+nZqkeKkU/juZaSkWcc6fywiPbKQ== Date: Thu, 24 Jul 2014 17:43:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_F87472FCEB015941BCB7501455B7F9CA4ACA8C69US70TWXCHMBA07z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3-2yfkxNYFAL9i9nxdPZLCU1kBM Subject: [sfc] draft-merged-sfc-architecture-00 & Classifiers. X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Jul 2014 17:43:53 -0000 --_000_F87472FCEB015941BCB7501455B7F9CA4ACA8C69US70TWXCHMBA07z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I second Ron's; Good job Joel & Reinaldo. Regarding classifiers: it would be nice to include it for illustration in t= he various figures, e.g. figure #5, as there is no explicit assumption with= in the document that SFF includes (or excludes) classification. Regards, /Safa. --_000_F87472FCEB015941BCB7501455B7F9CA4ACA8C69US70TWXCHMBA07z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I second Ron’s; Good job Joel & Reinaldo.

 

Regarding classifiers: it would be nice to include it for = illustration in the various figures, e.g. figure #5, as there is no explici= t assumption within the document that SFF includes (or excludes) classification.

 

Regards,

/Safa.

--_000_F87472FCEB015941BCB7501455B7F9CA4ACA8C69US70TWXCHMBA07z_-- From nobody Thu Jul 24 10:45: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 C5D321B279D for ; Thu, 24 Jul 2014 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 y_VTSnl4UqJv for ; Thu, 24 Jul 2014 10:45:00 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8A01A0AF4 for ; Thu, 24 Jul 2014 10:44:40 -0700 (PDT) Received: from dhcp-9565.meeting.ietf.org ([31.133.149.101]:54054 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XAN4E-0003o5-Hk; Thu, 24 Jul 2014 17:44:34 +0000 From: "Russ White" To: "'Dolganow, Andrew \(Andrew\)'" , , References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> <1531752076.24329.1406133609307.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: Date: Thu, 24 Jul 2014 13:44:28 -0400 Message-ID: <05c301cfa766$ecd35790$c67a06b0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ6RVRovzxvdQzIHqmAnWHFqzr+1gJhzmrIAi3uRzsCEKwnHQKwpw/GAfig7EyZ//SWsA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GYpw91UtNrwSrHD3VWAJDvFw9Us Cc: sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Jul 2014 17:45:06 -0000 > Service Function Path (SFP): The SFP provides a level of indirection between > service chain (an abstract sequence of functions to be > delivered) and SFFs the packet will visit when it actually traverses the > network. The use of this level of indirection, allows flexibility in a degree of > SFF/SF instance selection that can be delegated to the network. Or perhaps: Service Function Path (SFP): A sequence of functions through which traffic must be delivered in traversing the network. The SFP is an indirect or abstract topology representation, allowing flexibility in the actual instances of service functions delegated to perform the actual functions. Or something more along these lines... IMHO, the language is getting a bit "technical" for someone who's approaching these documents for the first time to grock, so we need to put things in less self-referential terms entirely (if possible). :-) Russ From nobody Thu Jul 24 11:18: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 D03721B27C4 for ; Thu, 24 Jul 2014 11:18:46 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 uBmfow7AHXsm for ; Thu, 24 Jul 2014 11:18:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FBE1B27B5 for ; Thu, 24 Jul 2014 11:18:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKM49899; Thu, 24 Jul 2014 18:18:41 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 19:18:39 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 25 Jul 2014 02:18:27 +0800 From: Jiangyuanlong To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: Ac+mfxjQoPQaTr3RRZ+E41fxxtClqQABNiDwAADHzCAADQr7AAAF1RkQAClpuoAAA1SqAA== Date: Thu, 24 Jul 2014 18:18:26 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50@szxema506-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EB@szxema506-mbs.china.huawei.com> <9C41B423-3E82-4B3E-BE06-F86856F2A0A4@cisco.com> In-Reply-To: <9C41B423-3E82-4B3E-BE06-F86856F2A0A4@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.33] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/9X1o-CmeHWsSuT-3IKD7umGVBVo Cc: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , Lucy yong , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 24 Jul 2014 18:18:46 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50szxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the hard work, and I hope the result can also be reflected i= n the PS draft. Cheers, Yuanlong From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Thursday, July 24, 2014 10:48 PM To: Jiangyuanlong Cc: Lucy yong; Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda= Dunbar Subject: Re: [sfc] Simpler description of Service Function Path Hi, Yuanlong, This is a good callout -- thanks. We will scrub through the use of "instanc= e" as part of incorporating the SFP definition and feedback. Thanks! Carlos. On Jul 23, 2014, at 2:53 PM, Jiangyuanlong > wrote: Hi Carlos, Maybe I miss something, I see "instances of SFF" and 'SFF/SF instance" in t= he definition of SFP, but could not find any use of "SFF instance" in the t= exts. Are you proposing that both SFF and SF are abstracted concepts? Why we intr= oduce "SFF instance" but never use it in the context? Regards, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig= nata) Sent: Thursday, July 24, 2014 12:16 AM To: Lucy yong Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path Lucy, Linda, Nurit, I do not think that a self-referencing definition will help -- i.e., I am s= ure "A service function path is a path traversing service functions" is cor= rect but it's not particularly clarifying... Stepping back a bit, this (proposed by Joel) is where we are and what was d= iscussed on the list and presented today. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF/SF instance selection authority that is delegated to the network. I agree it's perhaps not the easiest English to parse, but nonetheless is i= nclusive of all discussion and captures all key points, while excludes nois= e. What specific concerns do you have with this definition? (i.e., what meanin= g is missing?) Thanks, Carlos. On Jul 23, 2014, at 11:00 AM, Lucy yong > wrote: How about: SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. Lucy From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= IL/Hod HaSharon) Sent: Wednesday, July 23, 2014 9:40 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Simpler description of Service Function Path I would propose to do it even simpler Service Function Path (SFP): SFP is a path traversing a sequence of service functions in a SFC-enabled d= omain. The path includes a sequence of SFFs and/or SFs that can be explicit= ly or loosely specified. In case of a loosely specification, at least the i= ngress and the egress SFFs and/or SFs need to be specified. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar Sent: Wednesday, July 23, 2014 5:05 PM To: sfc@ietf.org Subject: [sfc] Simpler description of Service Function Path I think the SFP definition displayed at today SFC session is too complicate= d, more like lawyer's wording than a term easily understood by engineers (c= onsidering there are a lot of IETFers/engineers whose first language is not= English). Here is my suggested simpler wording: Service Function Path (SFP): SFP is a pathway traversing a sequence of service functions from ingress to= egress of the SFC-enabled domain, including sequence of SFFs and sequence = of SFs. This sequence can be specified precisely with exact sequence of SFF= s and the sequence of SFs reached by each SFF, loosely specified with sets= of SFFs/SFs, or somewhere in between. Linda _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50szxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you = for the hard work, and I hope  the result can also be reflected in the= PS draft.

 = ;

Cheers,

Yuanlong

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Thursday, July 24, 2014 10:48 PM
To: Jiangyuanlong
Cc: Lucy yong; Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org= ; Linda Dunbar
Subject: Re: [sfc] Simpler description of Service Function Path=

 

Hi, Yuanlong, <= /span>

 

This is a good callout -- thank= s. We will scrub through the use of "instance" as part of incorpo= rating the SFP definition and feedback.

 

Thanks!

 

Carlos.

 

On Jul 23, 2014, at 2:53 PM, Ji= angyuanlong <jiangyuanlong@h= uawei.com> wrote:



Hi Carlos,

 

Maybe I miss something, I see &= #8220;instances of SFF” and ‘SFF/SF instance” in the defi= nition of SFP, but could not find any use of “SFF instance” in = the texts.

Are you proposing&= nbsp;that both SFF and SF are abstracted concepts? Why we introduce “SFF instance”= ; but never use it in the context?

 

Regards,

Yuanlong

 

From: sfc [mailto:sfc-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Carlos Pignataro (cpignata) Sent: Thursday, Ju= ly 24, 2014 12:16 AM
To: Lucy yong
Cc: Sprecher, Nuri= t (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar
Subject: Re: [sfc]= Simpler description of Service Function Path

 

Lucy, Linda, Nurit,<= /span>

 

I do not think that a self-refe= rencing definition will help -- i.e., I am sure "A service function pa= th is a path traversing service functions" is correct but it's not par= ticularly clarifying...

 

Stepping back a bit, this (prop= osed by Joel) is where we are and what was discussed on the list and presen= ted today.

 

=    Service Function Path (SFP):  The SFP prov= ides a level of indirection
        between the fully abstract notion of servi= ce chain as a sequence
        of functions to be delivered, and the full= y specified notion of
        exactly what instances of SFFs the packet = will visit when it
        actually traverses the network.  = ;By allowing the control
        components to specify the use of this leve= l of indirection, the
        deployment may choose the degree of SFF/SF= instance selection
        authority that is delegated to the network= .

I agree it's perhaps not the ea= siest English to parse, but nonetheless is inclusive of all discussion and = captures all key points, while excludes noise. 

 

What specific concerns do you h= ave with this definition? (i.e., what meaning is missing?)

 

Thanks,

 

Carlos.

 

On Jul 23, 2014, at 11:00 AM, L= ucy yong <lucy.yong@huawei.com> wrote:




How about:=

 

SFP is a p= ath traversing a sequence of service functions in a SFC-enabled domain. The= path includes a sequence of SFFs and/or SFs that can be explicitly or loosely specified.  =

 

Lucy

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, J= uly 23, 2014 9:40 AM
To: Linda Dunbar;<= span class=3D"apple-converted-space"> sfc@ietf.org
Subject: Re: [sfc]= Simpler description of Service Function Path

 

I would pr= opose to do it even simpler

Service Fu= nction Path (SFP):

SFP is a p= ath traversing a sequence of service functions in a SFC-enabled domain. The= path includes a sequence of SFFs and/or SFs that can be explicitly or loosely specified. In case of a loosely specification, at least the ing= ress and the egress SFFs and/or  SFs need to be specified.

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of ext Linda Dunbar
Sent: Wednesday, J= uly 23, 2014 5:05 PM
To: sfc@ietf.org
Subject: [sfc] Sim= pler description of Service Function Path<= /o:p>

 

I think the SFP definiti= on displayed at today SFC session is too complicated, more like lawyer̵= 7;s wording than a term easily understood by engineers (considering there are a lot of IETFers/engineers whose first language is not English).=

 

Here is my suggested sim= pler wording:

 

Service Function Path (S= FP):

SFP is a pathway travers= ing a sequence of service functions from ingress to egress of the SFC-enabl= ed domain, including sequence of SFFs and sequence of SFs. This sequence can be specified precisely with exact sequence of SFFs and t= he sequence of SFs reached by each SFF,  loosely specified with sets o= f SFFs/SFs, or somewhere in between.=

 

Linda

_______________________= ________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50szxema506mbschi_-- From nobody Fri Jul 25 12:32: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 91F881A03BA for ; Fri, 25 Jul 2014 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 1-P6RhNcQiNz for ; Fri, 25 Jul 2014 12:32:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182441A02D5 for ; Fri, 25 Jul 2014 12:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5015; q=dns/txt; s=iport; t=1406316763; x=1407526363; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REcRM2kVZ0XcRFDL7wIEVuXbQ2soYB37C7ULqFTm7o4=; b=XFNWtOXHXiGt0lhLH40/uATOe/RrywDi0o9H//QUVSUtTuww15fT02MZ 87JZRgskgqi+K6QlsDYyllPNClWyq6uqqy1djnCPII+xArKcvYigLpSmd 3+Urp2PteBxgPOCj9R4eeXVxO4ek1rM6vXmIlEpiwiQoBnKJZzIDbuOl5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAFWw0lOtJA2H/2dsb2JhbABZgw5SVwTLagqHRQGBEBZ3hAMBAQEDAQEBAWsLBQsCAQgRBAEBAScHJwsUCQgCBA4FiDoIDb9HEwSPGDMHgy6BGwEEm0eMBohEg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="339805151" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2014 19:32:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6PJWgHV016697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 19:32:42 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 14:32:41 -0500 From: "Darrel Lewis (darlewis)" To: Jiangyuanlong Thread-Topic: [sfc] Simpler description of Service Function Path Thread-Index: AQHPqD8zUfCQa6lH7kOsdmAyt5NW2A== Date: Fri, 25 Jul 2014 19:32:41 +0000 Message-ID: <49A3FDF7-C856-449C-816D-7C139D582B2E@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DA2A04@dfweml701-chm.china.huawei.com> <9B067372C2434A429FBD4CF7F0E869FD20479D1E@DEMUMBX009.nsn-intra.net> <2691CE0099834E4A9C5044EEC662BB9D453C2C2F@dfweml701-chm.china.huawei.com> <009CF5B2-040E-455E-BAD4-8296FDE28497@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7807EB@szxema506-mbs.china.huawei.com> <9C41B423-3E82-4B3E-BE06-F86856F2A0A4@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A780E50@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.109] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4D7EF75CE6BD4D49B4677109A928C882@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Q1ta6a4YSRK57jvSUBk7x1Hnv1A Cc: "Darrel Lewis \(darlewis\)" , "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" , "sfc@ietf.org" , "Carlos Pignataro \(cpignata\)" , Lucy yong , Linda Dunbar Subject: Re: [sfc] Simpler description of Service Function Path X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 25 Jul 2014 19:32:45 -0000 Yes, and I hope even more fervently, that we can move beyond the definition= of terms to the definition of content. -D On Jul 24, 2014, at 11:18 AM, Jiangyuanlong wrot= e: > Thank you for the hard work, and I hope the result can also be reflected= in the PS draft. > =20 > Cheers, > Yuanlong > =20 > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 > Sent: Thursday, July 24, 2014 10:48 PM > To: Jiangyuanlong > Cc: Lucy yong; Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Lin= da Dunbar > Subject: Re: [sfc] Simpler description of Service Function Path > =20 > Hi, Yuanlong, > =20 > This is a good callout -- thanks. We will scrub through the use of "insta= nce" as part of incorporating the SFP definition and feedback. > =20 > Thanks! > =20 > Carlos. > =20 > On Jul 23, 2014, at 2:53 PM, Jiangyuanlong wro= te: >=20 >=20 > Hi Carlos, > =20 > Maybe I miss something, I see =93instances of SFF=94 and =91SFF/SF instan= ce=94 in the definition of SFP, but could not find any use of =93SFF instan= ce=94 in the texts. > Are you proposing that both SFF and SF are abstracted concepts? Why we in= troduce =93SFF instance=94 but never use it in the context? > =20 > Regards, > Yuanlong > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cp= ignata) > Sent: Thursday, July 24, 2014 12:16 AM > To: Lucy yong > Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Simpler description of Service Function Path > =20 > Lucy, Linda, Nurit, > =20 > I do not think that a self-referencing definition will help -- i.e., I am= sure "A service function path is a path traversing service functions" is c= orrect but it's not particularly clarifying... > =20 > Stepping back a bit, this (proposed by Joel) is where we are and what was= discussed on the list and presented today. > =20 > Service Function Path (SFP): The SFP provides a level of indirection > between the fully abstract notion of service chain as a sequence > of functions to be delivered, and the fully specified notion of > exactly what instances of SFFs the packet will visit when it > actually traverses the network. By allowing the control > components to specify the use of this level of indirection, the > deployment may choose the degree of SFF/SF instance selection > authority that is delegated to the network. >=20 > I agree it's perhaps not the easiest English to parse, but nonetheless is= inclusive of all discussion and captures all key points, while excludes no= ise.=20 > =20 > What specific concerns do you have with this definition? (i.e., what mean= ing is missing?) > =20 > Thanks, > =20 > Carlos. > =20 > On Jul 23, 2014, at 11:00 AM, Lucy yong wrote: >=20 >=20 >=20 > How about: > =20 > SFP is a path traversing a sequence of service functions in a SFC-enabled= domain. The path includes a sequence of SFFs and/or SFs that can be explic= itly or loosely specified. =20 > =20 > Lucy > =20 > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN= - IL/Hod HaSharon) > Sent: Wednesday, July 23, 2014 9:40 AM > To: Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] Simpler description of Service Function Path > =20 > I would propose to do it even simpler > Service Function Path (SFP): > SFP is a path traversing a sequence of service functions in a SFC-enabled= domain. The path includes a sequence of SFFs and/or SFs that can be explic= itly or loosely specified. In case of a loosely specification, at least the= ingress and the egress SFFs and/or SFs need to be specified. > =20 > =20 > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of ext Linda Dunbar > Sent: Wednesday, July 23, 2014 5:05 PM > To: sfc@ietf.org > Subject: [sfc] Simpler description of Service Function Path > =20 > I think the SFP definition displayed at today SFC session is too complica= ted, more like lawyer=92s wording than a term easily understood by engineer= s (considering there are a lot of IETFers/engineers whose first language is= not English). > =20 > Here is my suggested simpler wording: > =20 > Service Function Path (SFP): > SFP is a pathway traversing a sequence of service functions from ingress = to egress of the SFC-enabled domain, including sequence of SFFs and sequenc= e of SFs. This sequence can be specified precisely with exact sequence of S= FFs and the sequence of SFs reached by each SFF, loosely specified with se= ts of SFFs/SFs, or somewhere in between. > =20 > Linda > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 30 18:55: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 566CB1A030A; Wed, 30 Jul 2014 18:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rO_OWvq_6Mew; Wed, 30 Jul 2014 18:55:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039101A01CA; Wed, 30 Jul 2014 18:55:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT53142; Thu, 31 Jul 2014 01:55:19 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 02:55:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 09:55:15 +0800 From: Xuxiaohu To: "Larry Kreeger (kreeger)" , Dino Farinacci , Marc Binderberger Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPrD8x8HabDXKfWkOqJ8h/w9M6lZu5abCw Date: Thu, 31 Jul 2014 01:55:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829A473@NKGEML512-MBS.china.huawei.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/6NcEHyuw6ajwkiREEZEZI6QQKIU Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , "sfc@ietf.org" , Tom Herbert Subject: Re: [sfc] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 01:55:24 -0000 > >And NSH is a service protocol and should run above the transport layer > >so should have its own port and can address packets anywhere. >=20 > I think the intent of NSH is to be generic enough to work at different la= yers. > The recent addition of the Metadata Type field in the NSH header allows f= or it to > be used for purposes beyond SFC. It could theoretically be used to essen= tially > extend the header of the layer below it (e.g. > VXLAN/LISP). e.g. I think this could be used for Tom to carry his 64 bit= VNI > authentication. Hi Larry, If the Metadata Type field in the NSH header is going to be used for purpos= es beyond SFC, it seem much better to make the metadata-specific header and= the service-path header as independent as possible from the beginning.=20 Best regards, Xiaohu From nobody Thu Jul 31 18:38: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 1FC1B1A0368; Thu, 31 Jul 2014 18:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MfPbxyzy9kFL; Thu, 31 Jul 2014 18:37:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B7E1A0373; Thu, 31 Jul 2014 18:37:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKT71851; Fri, 01 Aug 2014 01:37:49 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:37:47 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:37:37 +0800 From: Xuxiaohu To: "Nobo Akiya (nobo)" , Lizhenbin , "draft-li-mpls-global-label-usecases@tools.ietf.org" Thread-Topic: Comments on draft-li-mpls-global-label-usecases Thread-Index: Ac+pyGOnOvdR466BTIiQqApCOmu/xgBMxX8pAFXSx/AAAgpoUAApuexAAAjFzTA= Date: Fri, 1 Aug 2014 01:37:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829BA49@NKGEML512-MBS.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08233D1D@nkgeml506-mbx.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829A43F@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/QZE-xwUizD1CtMBJMzzyUEqcvE0 Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [sfc] Comments on draft-li-mpls-global-label-usecases X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 01 Aug 2014 01:37:59 -0000 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Friday, August 01, 2014 7:33 AM > To: Xuxiaohu; Lizhenbin; draft-li-mpls-global-label-usecases@tools.ietf.o= rg > Cc: mpls@ietf.org > Subject: RE: Comments on draft-li-mpls-global-label-usecases >=20 > Hi Xiaohu, >=20 > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Wednesday, July 30, 2014 9:40 PM > > To: Nobo Akiya (nobo); Lizhenbin; draft-li-mpls-global-label- > > usecases@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: RE: Comments on draft-li-mpls-global-label-usecases > > > > > 2. Service Chaining > > > > > > Why not let SFC folks to do their work, which SFC will then work on > > > the MPLS data plane without any changes to the MPLS data plane nor > > > architecture, certainly doesn't require any "global label" as this > > > use case is describing. Unless the SFC WG require the "global label" > > > (which it doesn't) or the MPLS WG is re-chartered to pick up > > > creation of a tangent SFC solution specifically for MPLS, I don't > > > think this use case is > > valid. > > > [Robin] SFC WG truly works on some new header for service functions. > > > We need to work out the when MPLS dataplane applied, what the > > > possible problem and the solution. I think MPLS has been widely > > > deployed in the existing network and SFC is the possible useful use > > > case in MPLS network which should be taken into account in the MPLS > > > world. MPLS global label is one of the possible solutions. This does > > > not preclude other > > solutions. > > > > [NOBO] SFC is data plane agnostic. When SFC runs on MPLS data plane, > > there is no need to use global labels to describe service functions. > > > > Hi Nobo, > > > > It's fine that SFC is data plane agnostic. In the MPLS-SPRING-based > > SFC approach > > (http://www.ietf.org/proceedings/90/slides/slides-90-spring- > > 5.pdf) where the SFC-specific header is implemented in the form of an > > MPLS label stack, the SFC-encapsulated packet (i.e., the MPLS packet) > > could still be transported between service nodes over any transport > > such as MPLS, IP (e.g., MPLS-over-UDP or MPLS-over-GRE) or even > > Ethernet. To some extent, the MPLS-SPRING-based SFC approach is data pl= ane > agnostic as well. > > > > As had been mentioned in the above PDF, if it's the SFP information > > that is encoded in the MPLS label stack, there is no need for global > > labels. However, provided that some operators did want to encode the > > SFC information, rather than the SFP information in the MPLS label > > stack, the only feasible way to realize such goal is to use global > > labels. Here the global labels just need to be unique within the > > SFC-enabled domain, in other words, they are domain-wide unique > > labels. Just like the global label usage proposed in the segment > > routing mechanism, it only requires that a common label block, > > referred to as SF Label Block (SFLB) is reserved by all service nodes > > and Classifiers for SF SIDs. The domain-wide unique label for a given > > SF would be automatically determined by adding the SF ID to the first l= abel > value of the above SFLB. >=20 > You are creating a framework document based on a use case document that > includes use cases from another use case document that is still an indivi= dual > document. I understand the diff between SFC vs. SFs on SR and complicatio= ns of > NSH on the latter, but the way you are claiming this as a use case seems > premature. Let the SFC folks do their work. Let the SPRING folks do their= work. > Let's focus our energy into helping to progress the two. If either of tho= se spin off > real inter-WG requirements, then we probably won't even need separate use > case documents to start discussing solutions to address those requirement= s. In > other words, let's not take use cases w/o WG consensus to drive additiona= l use > cases to drive solutions. Hi Nobo, I'm not creating a framework doc. I'm just expressing a different opinion f= rom your argument as below: > > [NOBO] SFC is data plane agnostic. When SFC runs on MPLS data plane, > > there is no need to use global labels to describe service functions. That is: even when SFC runs on MPLS data plane, it's still feasible to use = the MPLS label stack to describe the SFP or the SFC information. Furthermor= e, in the latter case (i.e., encoding SFC information in the label stack), = using global labels (i.e., domain-wide unique label) to indicate SFs is the= only choice. Otherwise, the SFF (contained in the service node device) may= need to swap the whole label stack. BTW, global labels (i.e., domain-wide = unique label) just need to be processed by classifiers and service nodes. T= he underlay could be IP networks (e.g., using MPLS-in-UDP). It doesn't requ= ire any change to the existing data plane. In other words, it's just a netw= ork configuration issue. Hence I really don't understand why you and some o= ther guys are so strongly opposing the usage of global labels.=20 Best regards, Xiaohu > Thanks! >=20 > -Nobo >=20 > > > > Best regards, > > Xiaohu

I was referring to the= =A1=B0metadata length=A1=B1 field defined in SCH draft (as shown in Figure= 1 and described in section 4.2 of http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/?include_text=3D= 1).

 

Cathy

 

From: Xuxiaohu
Sent: Wednesday, July 23, 2014 11:44 AM
To: Cathy Zhang; Henderickx, Wim (Wim); Dolganow, Andrew (Andrew); s= fc@ietf.org
Subject: =B4=F0=B8=B4: [sfc] Change to Mandatory C= ontext Header in NSH draft - optional presence

 

Did you mean the Length field in the Variable Co= ntext Headers by Metadata Length field? If so, do you want = to use a field in the optional variable length context headers to indicate the presence of the four 4-byte
context header outside of the optional variable length context headers?

 

Best regards,

Xiaohu

 =

=B7=A2=BC=FE= =C8=CB: sfc [sfc-bounces@ietf.org] =B4=FA=B1=ED Cathy Zhang [Cathy.H.Zhang@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C223=C8=D5=CA=D5=BC=FE=C8=CB: Henderickx, Wim (Wim); Dolganow, Andrew (Andrew); sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Change to Mandatory Context Header in NSH draft - optional prese= nce

Metadata Length field = serves the purpose well.

 =

Cathy

 =

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Wednesday, July 23, 2014 7:34 AM
To: Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] Change to Mandatory Context Header in NSH draft -= optional presence

 =

I agree= we should keep the header as small as possible and as such I also believe = we don=A1=AFt need the mandatory Ctxt field to be present.

An alte= rnative to the CHP bit could be to use length or MD-Type to indicate its pr= esence. 

 =

From: <Dolganow>, "Andrew (Andrew)" <<= a href=3D"mailto:andrew.dolganow@alcatel-lucent.com" target=3D"_blank">andr= ew.dolganow@alcatel-lucent.com>
Date: Wednesday 23 July 2014 10:30
To: "sfc@ietf= .org" <sfc@ie= tf.org>
Subject: [sfc] Change to Mandatory Context Header in NSH draft - opt= ional presence

 =

Followi= ng discussion during the meeting today, here is a specific comment on how t= o Change NSH to allow constant-size, easy-to-process in H/W Context Header = while also allowing for deployments that do not need to include the header:=

 =

  1. Keep existing format as per draft section 6 but= rename from Mandatory Context Header to Context Header 
  2. Make the presence of header opt= ional and encode presence/absence using  a bit in Base header =A8C pro= posed change text (in red):
  &=
nbsp;   0 1 2 3  4  5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2=
 3 4 5 6 7 8 9 0 1
  &=
nbsp;  +-+-+-+-+---+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+-+-+-+
  &=
nbsp;  |Ver|O|C|CHP|R|R|R|R|R|   Length  |    M=
D Type    | Next Protocol |
  &=
nbsp;  +-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+

 =

CHP =A8CC= ontext Header Present. If specified, Context Header as specified in section= 5 below  follows directly Service Path Header

 =

Andrew

 =

Hi Ron,

I would be very very carefull to place matadata inband (ie embed it in cust= omer data packets) of data plane.=C2=A0

Few reasons for consideration:

-= Adding anything over hundred bytes may become pretty overwhelming for smal= l size customer packets

- Adding anything over already maxed = size packet may cause MTU issues and fragmentation (which in many cases is = not possible in the middle of the network). Keep in mind also encrypted dat= a.

- Anything which is variable length i= n the data plane and which is opaque to the data plane causes additional da= ta plane requirements which a lot of hardware may have a hard time to deal = with

- Inband transport provides no option= to pre-populate the state at the backup devices / backup paths where no ac= tive traffic is traversing before any network event affecting primary path<= /div>

- A lot of appliances may not be able= to be transparent to opaque variable length metadata resulting in metadata= information loss.=C2=A0

For all of the above reasons (and I a= m sure many more not listed above) I would keep customer data packets alone= and when needed limit only insertion of a pointer to metadata context lear= ned out-of-band. (Out-of-band is a bit misleading term here as metadata can= happily travel via the same set of links as customer data. What it really = means is out-of-customer-data-packets).=C2=A0

Best regards,
R.



On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:

Robert,

=C2=A0

Inband is one way -- it s= implifies things at the cost of packet growth.=C2=A0=C2=A0 Out-of-band (i.e= ., signaling) is another way =E2=80=93 it adds complexity but doesn=E2=80= =99t grow the data plane packets.=C2=A0=C2=A0 Congruent out-of-band is a variation o= n out-of-band that may partially reduce out-of-band complexity.=C2=A0=C2=A0= =C2=A0 I think many opinions on the thread have been that all are in scope,= architecturally.=C2=A0=C2=A0=C2=A0 Draft-zhang-sfc-sch (I am a co-author), for example, defines inband metadata explicitly, but states in text that o= ut-of-band is possible, too.=C2=A0=C2=A0=C2=A0 I=E2=80=99m sure this will b= e a topic of discussion when we start discussing control plane requirements= .

=C2=A0

=C2=A0=C2=A0 Ron

=C2=A0

From: sfc [m= ailto:sfc-bounces= @ietf.org] On Behalf Of Robert Raszuk


Sent: Friday, July 18, 2014 3:27 AM
To: Xuxiaohu; sfc@= ietf.org
Cc: mpls@ietf.org= ; <spring@ietf.= org>
Subject: Re: [sfc] [spring] How to carry metadata/context in a= n MPLS packet

=C2=A0

= All,

= =C2=A0

= Is the idea of using data plane to carry complete metadata is "the way= " or "a way" of approaching the problem ? Has this been alre= ady discussed ?

= =C2=A0

= I would rather consider to carry metadata in control plane and only attach = a reference_id (and only when it is needed) to the data plane.=C2=A0=

= =C2=A0

= Rgs,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0<= /p>

On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <xuxiaohu@huawei.com&= gt; wrote:

Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/context in an MPLS packet (see below):
"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stack. With such PT field, any kind of = future MPLS payload (e.g., metadata header or NSH) can be easily identified= .

Best regards,
Xiaohu

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

=C2=A0